跨国深谈← 返回←分块没死:用多尺度索引把 RAG 提升 20-40%

分块没死:用多尺度索引把 RAG 提升 20-40%

关联

人物 Yuval Belfer

公司 AI21

概念 分块 · RAG · 智能体搜索 · 多尺度索引 · RRF · Oracle 实验

这一集是 AI21(一家 AI 研究实验室)的 Yuval 带来的一场短演讲，聊的是大多数 RAG 从业者不爱谈的话题：分块(chunking,把长文档切成小段再建索引的做法)。当下流行的说法是「RAG 已死」，连坚持 RAG 没死的人(比如 LlamaIndex 的 CEO Jerry)也要顺手干掉点什么——而那个「点什么」就是分块：既然现在人人都在用智能体搜索(grep、ls、find 这类工具)，谁还需要认真分块呢？

Yuval 的回应分两步：第一，智能体搜索确实可能杀死了「检索调优」——每次查询时调 top K、玩混合搜索那套玩法；但当你数据量大、查询种类多时，grep 和 find 仍然不够，而且智能体搜索很烧钱。第二，真正该被认真对待的分块，恰恰被大家当成「无聊的管道工程」忽略了。

分块本质是一种有损压缩，而且没有正确答案

每个 RAG 系统都有两个阶段：无聊的索引阶段(预处理数据、定块大小、存进向量数据库)，和有趣的检索阶段(每次查询时做调优)。大家的做法通常是第一天选个块大小——比如 512,加 10-20% 的重叠(overlap,相邻块之间重复的部分)，建完索引就忘。

但块太大，你能拿到全貌却丢失细节，各块也得不到有意义的 embedding(把文本变成向量、让相似内容在向量空间里靠近的技术)；块太小，细节保住了，大局丢了。所以分块本质上是种有损压缩，怎么做都会丢东西。

更有争议的主张是：不存在正确的块大小。你可能说「我们针对自己的语料库优化过」——但 Yuval 认为这不像调模型那样容易对基准过拟合，RAG 根本无法按数据集优化，因为最优块大小是依赖查询的。

实验证据：Oracle 实验

他们拿数据集复制六份，每份用不同块大小(2000、1000……

)建库，用了四个数据集：QMSUM(会议转写)、NarrativeQA(小说问答)、FinanceBench,还有一个内部自建、已公开的 Seinfeld 剧本冷知识数据集。结果直观易懂：问「Jerry 最喜欢的衬衫叫什么」这种聚焦问题，小块大小表现最好(rank 1 对比 rank 50 以下)；而问「Jerry 把谁描述为他的宿敌和纯粹的邪恶」这种需要跨上下文理解的问题，小块根本找不到答案。两个性质不同的查询，最优块大小完全不同。

然后是关键的 Oracle 实验：假设有个精灵，能对每个查询直接告诉你用哪个块大小检索最好(这只是测潜力上限，不是真系统)。结果橙色的 Oracle 线远高于所有固定块大小的蓝线——差距在 20% 到 40%,而这仅仅来自一个很简单的分块策略选择。你随手定下的 512 或 1000,成本就是这么多。

为什么没人做对？Yuval 把它归结为一个信息错位问题：索引阶段你能控制块大小，但不知道未来的查询是什么；检索阶段你手上有查询，但块大小已经定死了。

方法：多尺度索引 + RRF 融合

既然要押注，为什么要押一个而不押多个？他们的做法是**多尺度索引**：把数据库复制 N 份，分别用不同窗口大小分块建索引；检索时对每份库都查一遍(可以完全并行，不增加延迟)。

难点在于怎么合并——不同大小的块彼此不可比。解法是不比较块，而是像如今很多 RAG 系统那样，拿到块后回溯取出整个文档，于是 N 个块排名变成了对同一批文档的 N 个排名，这就可比了。

「这种情况下，检索本质上就是投票。」

合并用的是 RRF(Reciprocal Rank Fusion,倒数排名融合，一个把多个排名列表融合成一个的简单公式)，试过的几种方法里它效果最好，而且只是个几乎不花时间的简单脚本，不是模型。

结果与代价

在四个数据集上，该方法匹配或打败了最好的固定块大小，且在所有 recall@k(检索前 k 条的命中率)指标上都赢，很多项提升 20、30 甚至 40%;在博客里还有 MTab 上的结果，提升 10-40% 不等。代价是额外内存——要保留数据库的多份副本(一个常数级别的开销)，但延迟基本不受影响。未解的问题：该用多少个块大小、具体选哪些(目前 50、100、200 这套取值相当随意)，以及有没有比 RRF 更好的融合方法。

本集带走

• 别再找「最佳块大小」了：实验证明最优块大小依赖查询而非数据集，固定块大小的选择本身就是 20-40% 召回率的代价。
• 多尺度索引可以直接抄：同一份数据按多个块大小建多份索引，检索时全部并行查询，取出整文档后用 RRF 融合排名——简单脚本即可，延迟几乎不变，代价只是额外内存。
• 把信息错位记在心里：索引时不知道查询、查询时改不了索引，这是所有 RAG 系统的结构性矛盾，解法是让同一个决策点同时拥有两边的信息。
• 智能体没杀死检索：检索只是沦为了基础设施——而且是 2022 年水平的基础设施，用简单方法就能白拿 20-40% 的提升。

所以我要主张，如果我们必须干掉某个东西，如果有什么必须死，那很可能是检索调优。
So I will claim that if we have to kill something, if something has to be dead, then it’s probably retrieval tuning.
—— Yuval Belfer · [02:40]

所以这告诉我们的是，分块本质上是一种有损压缩。
So what this tells us is that chunking is essentially a lossy compression.
—— Yuval Belfer · [05:05]

而我要声称，不存在正确的块大小。
And I will claim that there is no right chunk size.
—— Yuval Belfer · [05:15]

它们都停留在固定块大小的模式里，而我们采取了不同的做法，我们说：既然可以选定多个，为什么要只选定一个呢？
All of them just stayed in the model of let’s work with a fixed chunk size, whereas we took a different approach, and we said, why commit to one where we can commit to several?
—— Yuval Belfer · [10:59]

在这种情况下，你可以把检索本质上就理解为投票。
In this case, you can think of retrieval as essentially just voting.
—— Yuval Belfer · [12:48]

如果我需要给你们留下一句话，我会说智能体并没有杀死检索。
And if I need to leave you with something, I would say that agents didn’t kill retrieval.
—— Yuval Belfer · [16:54]

用非常简单的方法，你可以把你的 RAG 系统或者任何涉及存储数据然后再检索的东西提升 20 到 40%。
And with really simple methods, you can take your RAG system or anything that has to do with storing data and then retrieve it with 20 to 40%.
—— Yuval Belfer · [17:10]