스크립트
00:00:00大家好，感谢大家今天的光临。欢迎来到一场“空无一物”的演讲。抱歉，应该是一场关于
00:00:21检索的演讲。我叫 Yuval，在 AI21 工作，本质上是一家 AI 研究所。今天，
00:00:29我想和大家聊聊大多数人都不太愿意讨论的话题，那就是分块（Chunking）。
00:00:37我希望在演讲结束前让大家相信，分块并没有过时，而且是大有可为的。
00:00:45事实上，无论你是在 X、领英还是其他地方，可能都看到过“RAG 已死”的论调，对吧？
00:00:53我想人们最近还宣判了 MCP 的死刑。然后 RAG 又死了一次。原生检索万岁，
00:01:00原生搜索万岁。有时你不得不扪心自问，RAG 到底还能死多少次？
00:01:07对吧？即使有人站出来说“RAG 没死”，比如 LlamaIndex 的 CEO Jerry，
00:01:14他们也总得宣判点别的技术死刑。而显然，这个倒霉蛋就是分块。就像在说“别在这上面投入了，”
00:01:23“别做分块了”。人们说分块已死的原因在于，现在大家都在用
00:01:30智能体搜索了，对吧？有了 grep，有了 ls，有了 find。这些固然都很棒，
00:01:36但当你拥有海量数据和纷繁多样的查询时，这些依然远远不够。
00:01:46稍等一下。好的。我认为很多人不喜欢聊
00:01:51分块的主要原因，是因为它不是有趣的那部分，对吧？在任何 RAG 或文件系统中，
00:02:00我们都有两个阶段。第一阶段可以说相当枯燥。那是你一开始就要做的工作，
00:02:07面对海量数据，你必须进行预处理，必须确定分块大小。然后
00:02:13你得把所有东西存入向量数据库。另一部分则是检索，本质上就是
00:02:20针对每次查询实时发生的过程。这部分做起来容易得多，对吧？它更容易
00:02:25进行优化。你可以拿来所有的查询，然后调整 max K、抱歉，是 top K，也可以尝试
00:02:32混合搜索等等。做检索调优可要有意思得多，对吧？
00:02:40所以我认为，如果我们非要宣判点什么死刑，非有什么要被淘汰的话，那可能
00:02:47恰恰是检索调优。是的，智能体搜索很可能已经终结了它。但是，即使我们
00:02:55接受智能体搜索终结了检索调优这一事实，在面对海量数据时，
00:03:02它依然不够好用。它的成本非常高昂，我想这点已经不必我多说了。榨干 Token
00:03:09如今人尽皆知。而底层的核心问题在于，如果数据本身
00:03:17在你的文件夹和目录中没有以恰当的方式组织，你得到的结果依然会
00:03:25非常低效。让我们来看一个应景的例子吧。现在正值国际足联世界杯。我们
00:03:33设想有一个包含历届世界杯所有数据的数据集。每个目录分别代表，比如说，
00:03:4098 年那一届、2002 年那一届等等。但如果你的查询是“哪支球队赢得的世界杯
00:03:50冠军最多？”，你根本无法直接去某一个文件夹读取。你必须遍历每个文件夹，查看谁夺了冠，
00:03:57然后汇总在一起，这效率极低。希望直接给出的答案是巴西队，至少
00:04:03在本次演讲的当下是如此。所以检索其实并没有消亡。我们在
00:04:13这场讲座中不打算宣判任何东西的死刑。它只是沦为了底层的水管工程。我相信任何做过
00:04:21RAG 系统的人都深有体会。第一天，或者第一周，严谨点的话甚至是第一个月，
00:04:29你选定某种分块大小，比如 512。然后可能还会设置一些重叠率，
00:04:36对吧，10%、20% 等等，把所有东西建好索引，然后就彻底抛诸脑后了。而且你也知道，
00:04:43我们经常讨论固定分块策略：如果分块切得太大，
00:04:49确实，你能保留全局全貌，这固然不错，但会丢失大量细节。所有的
00:04:54分块都无法获得具有辨识度的向量表示。而如果你把分块选得太小，
00:05:00就会丢失大局全貌。这样一来，效率必然会大打折扣。这一切都说明，
00:05:07分块本质上就是一种有损压缩。无论怎么做，我们都在舍弃一部分信息。
00:05:15因此我敢断言：根本不存在“正确”的分块大小。很多做数据的人可能会反驳说：
00:05:23“不对啊，我们有这个语料库，有这个数据集，我们针对它进行了优化，系统在这个
00:05:29数据集上表现极其出色。”我们曾经也这么认为。我们在这方面有很丰富的经验，
00:05:35涉及许多不同类型的智能体、系统和工作流，你完全可以——
00:05:40想想看基准测试，把模型过拟合到一个基准测试上是多么容易。
00:05:48但在 RAG 中行不通。这根本不会奏效。你无法真正按数据集来优化它。接下来我将
00:05:54向大家展示它为何是依赖于具体查询的。我凭什么这么肯定？为什么敢下这样的结论？
00:06:00因为我们做了实验，进行了测试，现在我将向大家展示成果。我们所做的，
00:06:06并不是去空谈针对每个数据集的最佳分块大小，而是实地去探索。我们拿来一个
00:06:14数据集并复制了多份，在这个实验中是六份。在每一次复制中，
00:06:23在每一个实例里，分块大小都不相同。我们有一个分块大小为 2000 的数据库，
00:06:28一个分块大小为 1000 的数据库，以此类推。我们对几个数据集都进行了测试，
00:06:36包括会议纪要数据集 QMSUM，小说问答
00:06:41数据集 NarrativeQA，以及《宋飞正传》数据集——关于“空无一物”的琐事。开个玩笑，它其实是关于
00:06:49《宋飞正传》剧本台词的问答数据集。算是我们内部构建的一个恶搞数据集，我们
00:06:56也公开发布了，如果有人需要，文末有链接。我们在所有这些数据集上做了测试，看看究竟会发生什么。
00:07:03首先，我们只是想看看对于每个数据集而言，哪个分块大小表现最好。这里
00:07:10展示的是来自《宋飞正传》数据集的一个例子：本质上完全不同的两个查询，
00:07:16会因为分块大小的不同而得到截然不同的结果。第一个问题是：
00:07:24Jerry 最喜欢的衬衫叫什么名字？可以看到这是一个非常聚焦、非常具体的问题。
00:07:28它的答案往往非常局限。这种问题用较小的分块大小
00:07:33效果最好。你可以看到，在 100 Token 固定分块
00:07:43与更大的分块之间，排名第一与排到 50 名开外的巨大差距。而像“Jerry 把谁描述为他的宿敌和纯粹的邪恶？”
00:07:50这样的问题，虽然我甚至不算《宋飞正传》的铁粉，我也知道是 Newman。但如果去查阅
00:07:56剧本台词，它并不是那么容易被直接找出来的。你可以看到情况完全改变了，对吧？如果你使用
00:08:02小分块，就根本找不到答案。于是我们在跑完了
00:08:10所有这些测试之后注意到一点，我们心想：如果我们有一个预知者，或者说神灯精灵，
00:08:19能够针对每个查询告诉我们最佳检索分块大小，那会怎样？这就是所谓的“Oracle”实验。
00:08:25我们想借此看看潜在的性能上限。这并不是说我们现在已经具备了
00:08:33构建这种系统的能力，我们只是想看看这里到底蕴藏着多大的潜力。大家可以在
00:08:38这张图表里看到，所有蓝色的——首先，纵轴是召回率，越高越好；
00:08:46横轴是检索到的分块数量，也就是 Recall@K 对比 K。大家看到的那些蓝色线条可能
00:08:52很难互相区分，但每一条都代表某种固定分块大小的性能。而橙色线条则是
00:09:01Oracle 线。这是我们在每个查询上都选取表现最好的一种尺寸所得出的结果。你可以看到这种情况
00:09:09在多个数据集上均有体现。在很多数据集中，你实际上能看到蓝色线条互相交错，
00:09:16这意味着对于许多数据集来说，确实没有任何单一分块大小能占据绝对优势。而更
00:09:24有意思的是其中蕴藏的巨大潜力。橙色线条与所有蓝色线条之间的差距
00:09:30非常显著。我说的显著，是指仅仅通过改进分块策略，
00:09:38就能获得大约 20% 到 40% 的提升。而且顺便提一句，这还是极其简单的策略。这个差距，就是你随意选择
00:09:47512 或 1000 之类的尺寸所付出的代价，对吧？这个数字本就随意。而这正是你失去的性能。我认为
00:09:56这里的问题有点棘手，因为它属于一种信息缺失问题——我们在每个阶段都没有掌握所需的信息。
00:10:07这是什么意思呢？如果看索引构建阶段，
00:10:12虽然此时我对分块大小有绝对控制权，但我根本不知道未来的查询会是什么。
00:10:18我可以去猜，可以估算，也可以尝试，但我无法预知查询，因此也就无法
00:10:25据此去调整分块大小。而在检索阶段，虽然此时拿到了具体查询，
00:10:31我却无法控制分块大小了，对吧？它早已固定了。显然我也不可能
00:10:37针对每个查询把整个流程从头到尾重跑一遍。于是我们研究了先前的方案，比如 Anthropic 著名的
00:10:47语境检索（Contextual Retrieval），他们对每个分块进行信息丰富；以及其他试图改善每个分块
00:10:54潜在空间的方案。但这不是我们选择的方向。所有这些方法依然停留在
00:11:01“使用单一固定分块大小”的模式中，而我们采取了截然不同的方法。我们心想：既然能兼容多种尺寸，
00:11:08为什么非要死守一种呢？我们将其称为多尺度索引（Multi-Scale Indexing）。本质上，我们只是在
00:11:16实践之前提到的思路。我们读取数据库，将其复制多份，并以不同的
00:11:26分块大小或窗口大小进行切分。这是在索引阶段完成的。到了检索时，
00:11:34我们同时查询所有这些切分。假设我们有 n 份数据库副本与不同的窗口大小，现在针对每个查询，
00:11:43就需要执行 6 次不同的检索调用。抱歉，准确来说是 n 次。那该如何将它们结合起来呢？我们显然无法
00:11:52依赖 Oracle，对吧？Oracle 只是用来测试潜力上限的。在现实中，
00:11:57我们并不知道答案。但我们能做的是设计某种合并算法。这时大家可能会问：
00:12:06如果这么做，问题会出在哪？问题在于我们得到了 n 组排序结果，
00:12:13但这都是分块维度的排序。而不同尺寸的分块之间其实缺乏可比性，
00:12:19对吧？因此我们选择了一种当今非常流行的做法。许多
00:12:25RAG系统实际上都是这样运作的：与其仅仅检索文本块，
00:12:30在匹配到文本块时，我们会检索整篇文档，对吧？当上下文窗口变大时，我们希望提供
00:12:35越来越多的上下文。而现在这种情况下，针对完全相同的文档，我们有了n个排序，因为它们
00:12:44不再是文本块了。这样我们就能进行比较了。在这种情况下，你可以把检索本质上
00:12:50看作一种投票。明白了吗？所以它不完全是排序。我们不是只跑一次排序然后再做重排序，
00:12:56而是针对相关文档拥有n组不同的排序结果，我们希望将它们
00:13:03统合为一体。这就是为什么我们使用一种叫做RRF（倒数排名融合）的方法，它基本上
00:13:11就是一个简单的公式。我们尝试过几种方法，这个效果最好。正如你们所见，它不是
00:13:17一个模型，也不需要做什么特别的处理。具体来说，这只是一个
00:13:23完全不费时间的简易脚本。这就是完整系统的样子。我们先进行
00:13:32n次索引，然后对每个数据库执行查询，并使用RRF将它们全部
00:13:40融合在一起。至于结果，你们也能猜到非常好。否则我也不会站在这里，
00:13:48显得这么自信满满了，对吧？大家可以看到，我们在多个数据集上进行了测试，包括QMSum、
00:13:56Narrative QA、Seinfeld以及Finance Bench。测试了所有这些数据集，它都打平或击败了最佳的
00:14:05固定分块大小。我们来看图表。这里可能有点看不清，我会慢慢讲解。这里的每一行
00:14:12代表文本块大小。你可以看到50、100等等。最下面一行是我们的方法。就是这行，那个
00:14:21基于所有分块查询并融合的方法。而每一列是某个截断位置的召回率。比如Recall@1、
00:14:312、3，一直到10。在这里你可以看出两点，对吧？首先，无论在
00:14:39哪一个截断位置的召回率下，我们的方法依然胜出。你可能觉得这很简单，但要将
00:14:46所有结果有效融合在一起，绝非轻而易举的事。另外你还能看到，检索质量
00:14:53实际上提升了。从热力图上可以看到颜色变得绿得多。再次说明，这只是
00:14:58我想放大展示的内容。在这里你可以看到全部四个数据集，我们都取得了
00:15:06更好的结果。在很多指标上确实提升了20%、30%甚至40%。此外还有一些
00:15:14没在这里展示的结果，比如在MTEB上的评测。大家可以看我们的博客，我稍后会贴出链接，我们在那里
00:15:22同样取得了大幅提升，根据数据集的不同，增幅大约在10%到40%之间。
00:15:30不过我也很务实，我绝不会声称这样做是零成本的。显然，代价是存在的，
00:15:36对吧？天下没有免费的午餐，凡事皆有代价。没错，它的代价就是额外的内存占用。
00:15:43它需要2到5倍的O(1)开销，对吧？也就是常数级的额外内存，因为你必须保留
00:15:51数据库的所有那些副本。但是仔细想想，在延迟方面，它其实并不会
00:15:59造成太大影响，因为所有的检索部分都可以并行处理。而且RRF融合部分也根本花不了多少时间。
00:16:10我想说的是，这是我们做的一个非常棒的研究项目，并且取得了非常酷的成果。
00:16:16但仍有事情可做，对吧？还有改进的空间，还有未来的工作要做。更具体地说，
00:16:23我们想搞清楚到底需要多少种分块大小，以及选择哪些尺寸，对吧？坦白讲，我们之前采用50、100、
00:16:32200等等，其实是相当随意的。所以我们确实需要弄清楚如何计算这些，
00:16:40以及如何精确知道需要多少份副本。此外，还要探索RRF之外的可能，对吧？我们之所以
00:16:46使用RRF，是因为它在我们尝试过的方法中效果最好，但这并不意味着就没有
00:16:52更好的方案了。如果最后让我留给大家一句话，我想说：智能体并没有消灭
00:16:59检索。没有什么是真正消亡的。算了吧，那只是基础设施而已。而糟糕的地方在于，它是
00:17:072022年的基础设施。只要运用非常简单的方法，你就可以让你的RAG系统或者任何涉及
00:17:17数据存储与检索的系统提升20%到40%，而且同样不需要任何过于
00:17:26复杂的手段。所以如果你想了解更多内容，可以去阅读我们的博客。那里还提供了示例
00:17:34代码以及Seinfeld数据集。我的分享就到这里。我是Yuval，非常感谢各位的聆听。
00:17:47我们下次再见。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기