rag contextual-retrieval bm25 prompt-caching retrieval

RAG的上下文检索：67%这一数据背后隐藏了什么，它需要付出什么代价，以及何时会失效。

RAG的上下文检索：如何通过前置词解决孤立片段问题，为何67%这一数据反映了三次变更，提示缓存能节省什么，以及它在何时会失效。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 13 分钟2903 词

来源: Your RAG Chunk Doesn’t Know Whose Revenue Grew 3% — Contextual Retrieval

“该公司的营收较上一季度增长了3%。”一个向量数据库可以存储成千上万条类似这样的句子，但在明确指出涉及的是哪家公司以及哪个季度之前，这些句子实际上都毫无用处。

问题并不出在生成最终答案的模型上，而在于那些没有标识信息就进入索引的数据片段。任何基于文件、合同、技术文档或源代码构建的RAG流程都存在风险，因为这些资料在众多地方重复出现相同的语言模式，使得检索系统无法区分这些重复内容。

这种解决方案的成本很低。其价格以每百万个标记的美元数计算，只需在构建索引时生成一句文本即可。在Anthropic的测试中，这样的前缀可将检索失败率降低多达67%。不过这个惊人的数字背后其实存在一定的结构问题，而且用于展示该效果的用例后来也被找到了反例。此外还有四种情况，其成本支出难以得到合理解释。

核心理念简述

当索引将文档分割成数百个标记的片段时，某些片段会丢失主题和时间范围。诸如“营收增长3%”这样的表述既没有说明具体公司，也没有说明具体季度，而任何嵌入模型都无法恢复这些信息，因为文本里并不存在相关内容。

上下文检索在索引阶段一次性解决该问题。语言模型会看到整份文档以及其中的一个片段，然后它会生成一段50到100个标记长的简短描述前缀，说明该片段的内容、涉及的对象以及时间。

许多摘要生成过程会跳过第二步，而这一步其实非常重要。处理后的文本会被输入到向量索引和BM25索引中，后者是一种早于嵌入技术的词频排序器，它匹配的是确切的单词而非含义。因此，通过一次性的索引操作即可修复搜索流程中的两个环节，无需为每次查询额外付费。

在Anthropic的测试中，仅嵌入描述前缀就使检索失败率降低了35%；而结合BM25和重新排序的完整流程则将失败率降低了67%。提示词缓存使得这一方案成本低廉，因为整份文档只需读取一次，无需为每个片段重复读取。

这种技术并非适用于所有情况，而这正是它有趣之处所在。首先就是其机制以及提示词本身。

为片段赋予标识的前缀

直觉先于机制出现。从文档中截取的片段就如同从活页夹中撕下的一页纸，没有标题、案件编号或日期。单独阅读的话，人们根本无法判断是哪家公司的营收增长了，以及何时增长的。嵌入模型也面临同样的空白状况，只不过它没有办法标记这一点。

该机制负责补充缺失的标题。在索引时，模型会接收两个输入——完整的源文档及其中的一个片段，它的唯一任务就是撰写一段简短的上下文，将该片段置于整体文档之中。

Anthropic的提示词只需几行即可表达：

<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the
overall document for the purposes of improving search retrieval of the
chunk. Answer only with the succinct context and nothing else.

将该方法应用于示例文本块后，输出可能为：“该文本块来自ACME Corp 2023年第二季度业绩的SEC备案文件；上一季度的营收为3.14亿美元。”紧随其后的是原文中的3%增长相关表述。大约一百个词元就能将零散的片段转化为带有关键信息的完整记录。

处理后的丰富文本会被写入两个索引中：一个是嵌入索引（上下文嵌入），另一个是关键词索引（上下文BM25）。由于每个文本块中都明确写出了ACME这个名字，BM25能够在报告的任意页面中匹配到这家公司，而此前仅能在封面部分找到相关提及。

这也不是首次尝试的方案。Anthropic早前曾报告过将通用文档摘要附加到数据块上的实验，但效果“极为有限”；此外还尝试过使用HyDE和基于摘要的索引方法，效果同样不佳（Anthropic，2024年9月）。最终仅保留了前缀方案。

摘要与前缀的区别在于实现机制。一个摘要会被文档中的所有数据块共享，因此无法区分同一份年度报告中的A数据块与B数据块，而每个定位前缀都是为文档中的特定位置专门编写的。

由文件、合同、技术文档或代码库构成的语料库中，往往存在在多处重复出现的语言模式，而这正是当前数据块难以被准确识别的原因。仅使用嵌入前缀就能将错误率降低35%，而这还只是第一层优化效果。

一个数字中的阶梯结构

通常认为“67%”是某种单一技术带来的效果。但已发布的表格显示的数据并非如此，这些数据更像是逐步提升的曲线，而非一次性跃升的结果。

评估结果以“1减去recall@20”的方式计算：即正确片段未能进入前二十名的查询比例。Anthropic将此称为失败率，并针对代码库、小说、arXiv论文以及科学出版物分别报告了这一数值。

共有四种配置，它们是逐层构建的：

基准配置，仅使用原始片段的简单嵌入模型：5.7%的查询失败。
仅使用上下文嵌入模型：3.7%，仅通过前缀处理就实现了35%的降低。
加入上下文BM25模型：2.9%，累计降低幅度达49%，其中关键词索引进一步提升了效果。
加入重排机制：1.9%，这就是所谓67%这一数据的来源，得益于最后的这一层处理。

重排模型是一种第二层模型，它会同时读取查询语句和候选片段。虽然其处理速度比第一轮慢，但精确度要高得多。在此示例中，它将150个候选项缩减到了20个。上述四个数据均来自测试中最强的嵌入模型Gemini Text 004，并非Anthropic测试过的所有嵌入模型的平均值。

这种拆分方式改变了决策结果，而不仅仅是描述方式。那些已经在生产环境中使用混合搜索与重排技术的团队应当意识到，仅依靠上下文理解就能将准确率提升到接近35%，而非67%，因为另外两个层级本来就需要付费。将这一数值视为单一因素的影响很容易出错，实际上大部分的准确率提升都源于标准检索组件在正常发挥作用。

一篇 Hacker News 的帖子提出了一个重要的警示：没有人公布过在相同测试中纯 BM25 的表现如何，也完全没有提供任何背景信息。没有这一数据，就无法确定 49% 的提升中有多少归因于词汇索引中的上下文信息，又有多少来自纯混合搜索。

引用数据时的陷阱

任何引用这些结果的人都可能陷入计算陷阱。Anthropic 的指南中包含了一个规模较小的数据集，包含 9 个代码库和 248 个查询，其评估标准是另一种指标：Pass@20 的得分从基线的 90% 提升到了完整系统的 97%。由于数据集和评估标准不同，将这类数据与之前的数据混为一谈纯属错误。

这种优化并非没有代价。在索引过程中需要花费资金，但有一种机制使得该成本维持在接近 1 美元而非 1000 美元。

为何是 1 美元而非 1000 美元

考虑一下那种简单的方法。一份包含8,000个标记的文档会被分割成十个部分。由于没有任何优化，每次调用都会重新读取整个文档，因此相同的文本要被处理十次，仅用于描述十个不同的段落。

正是这样的成本结构使得这一想法多年来都无法实现。早在其优势被衡量之前，人们就认为这是纯粹的暴力方法，并在预算审批中予以否决。

提示词缓存改变了这一计算方式。文档会以固定前缀的形式仅发送一次。第一次请求需要支付大约为基础价格1.25倍的缓存写入费用，而之后对该文档的每次请求则只需支付大约为基础价格十分之一的缓存读取费用。

以典型的数据块和文档大小为基准，上下文处理费用为每百万个源文本标记1.02美元，该数值是结合800标记的数据块及8,000标记的文档这些输入条件得出的，而这类成本的具体数值其实很少被公开。因此我们可以用实际数值重新计算，而无需盲目信赖官方数据。

在一个包含737个数据块的烹饪书示例中，近62%的输入标记来自缓存，总处理费用从大约9.20美元降至大约2.85美元。实现三分之二费用节省的并非更先进的模型，而是仅读取一次文档这一操作。

决定一切的排序细节

一个实际细节决定了上述方案能否实现。缓存机制基于前缀匹配，因此同一文档的所有数据块必须依次处理才能复用同一个缓存条目。不同文档之间可以并行处理，每个文档对应一个处理线程，但将多个文档的数据块混放在同一个队列中则不可行。典型的简单处理流程会将数据块分配到共享的线程池中，这样缓存只能偶尔被访问，从而需要支付全额费用。

该图表还需一处警示：1.02美元是2024年该型号的定价，这一数值并非固定不变。下一代同型号产品的输入费用是其四倍，因此若不重新计算报价就直接使用此数字，便是过时的价格。

对于用作示例的SEC申报文件而言，其成本效益看起来相当不错。然而有人对同一类型的文件进行测试后却得到了相反的结果。

一个未能通过自身测试的典型案例

从这里开始是大多数总结都会跳过的部分。

该示例使用了SEC提交文件中的部分内容，但所列的领域范围并未涵盖这些文件。其中提到了代码库、小说、arXiv及科学出版物，因此这些财务文件仅作为叙述性示例，而非实际测试的语料库。

其他人填补了这一空白，却得出了相反的结果。Snowflake的工程师们（Tarakad、Yu、Samdani、Merrick，2025年3月）以约23,000份真实的10-K和10-Q文件作为语料库，并通过大约500个手工编写的查询来评估他们的处理流程。

该团队通过为每段内容添加由模型生成的独特且内容丰富的摘要——他们将其称为上下文检索——使得其中一个模型的得分下降了5.8分，另一个模型则下降了0.4分。最终结果是性能下降，同时计算成本也大幅上升。

当廉价的元数据优于昂贵的模型时

更有趣的是同一实验中的其他发现：通过注入文档级别的元数据，即公司名称、提交日期和表格类型，无需调用任何语言模型，就能将答案准确率从约50%至60%提升到72%至75%的水平。

这种对比恰恰说明了问题所在——该问题确实存在，因为相关模块确实无法识别所属公司。然而最廉价的解决方案却比最昂贵的更有效，因为公司名称在整个提交过程中保持不变，且添加该信息无需任何模型。

这种比较并非完全一致的重复实验，这一点应当明确说明。Snowflake使用了自身的提示词、嵌入模型、分块大小及评估方式，因此这些结果无法像来自同一测试工具那样直接对比。不过由于涉及的是同一类型的文档，所以这些对比仍具有参考价值。

另有两项研究结果让人们的热情有所降温。一项基于T²-RAGBench的2026年基准测试与Snowflake的研究无关，它测试了包含表格的金融文档的上下文化处理能力。研究显示，密集检索方式可使召回率提升2.8个百分点，而混合检索方式则能提升2.2个百分点（arXiv）。这一提升是真实且可重复的，远未达到67%的水平。

同一项涵盖7,318份文档中的23,000多个查询的基准测试还揭示了一个令处理报告的人士担忧的问题：剩余的错误大多源于表格结构不匹配。文本前缀无法解决这一问题，因为它只能准确标记出那些仍无法读取的内容片段。

第二点与计算成本相关。ConTEB（2025）将类Anthropic的方法与专为该任务训练的嵌入模型进行了对比。训练后的模型平均得分略高，处理每份文档的速度也快约一百倍（arXiv）。两者之间的质量差异很小，因为在某些数据集上，如保险领域的语料库，前缀法能取得压倒性优势，而在其他数据集上则仅以微弱差距落败。训练后的模型真正带来的优势在于更低的计算成本。

还存在另一种设计方案。Late Chunking（Jina AI，2024年9月）通过在更低层级对整份文档进行嵌入处理，仅在Transformer之后再将其分割成片段，且无需调用语言模型，从而解决相同问题。它的结构缺陷在于没有为关键词索引添加任何内容，因此失去了Contextual BM25所提供的一半优势。

对于大多数企业语料库而言，这种不对称性比度量差距更能决定选择方案。这属于主观判断，而所引用的ConTEB基准并未直接对其进行测试，因为BM25并不在其评估的组件之列。

一旦某个示范案例被证明存在反例，那么关键问题就变成了该技术在何处失效，以及如何能在五分钟内检查某个特定语料库。

在投入资金前进行五分钟测试

应从测试开始而非直接实现。从索引中随机选取十个片段，分别单独阅读。如果能够说明每个片段的主题及其来源，那就说明这些片段已具备上下文，而添加前缀只会增加标记数而非信息量。

这项测试无需编写代码，只需五分钟即可完成。它也是唯一与实际数据相关、而非基于他人数据的证据。

有四种已知情况下该技术无法发挥作用：

语料库规模低于二十万个标记。 在这种规模下，Anthropic的建议是将整个知识库直接放入提示词中，完全跳过检索步骤。上下文增强功能适用于语料库无法容纳在上下文窗口内的情况。
本身已独立的片段。 常见问题解答对、产品卡片和词典条目都已明确说明了主题，前缀仅起到重复说明的作用。
频繁变动的语料库。 若文档内容稳定，则只需支付一次费用；而每周都会更新的文档则需每周重新付费。
表格和财务报告。 若问题是表格结构导致，而非公司名称缺失，那么相关片段虽会被准确描述，但依然无法被正确解析。

这种框架适合三行显示。小型且稳定的语料库适合通过缓存处理长上下文；而包含模糊片段的大型语料库则适合用于上下文检索。简短且独立的条目则适合普通的混合搜索，无需额外费用。

采用的顺序很重要，这也是最常导致失望的原因。上下文化提升了混合搜索的价值，但并不会取代它。没有采用BM25和重排技术的团队应首先引入这些技术，若跳过这个顺序，就相当于在还缺少基础功能的情况下购买了更高阶的服务。

应在部署之前计算成本，而非之后。相关公式已经公开，片段和文档的大小也是已知的，唯一真正的未知因素就是处理流程是否真的能命中缓存。

设计评审时需要考虑的内容

回到开头那句话。“营收增长了3%”这一表述从来都没有错，只是它缺乏具体语境。解决办法既不是更智能的模型，也不是更好的嵌入技术，而只是在索引时追加一个标题而已。

无论答案生成模型多么强大，没有上下文的文本片段都是无用的。问题出在索引环节，而非幻觉现象。
三种干预措施共同作用才能达到67%的成效，而非仅靠其中一种。仅前缀处理就能带来近35%的提升，其余效果则来自混合搜索与重排序技术。
提示词缓存让这项技术得以低成本应用，而非依靠更强大的模型；若不进行逐文档处理，这些节省的成本就会消失。
示例中使用的文档类型存在已记录的反例：在SEC提交的文件中，廉价的文档元数据表现优于昂贵的逐片段模型调用方式。

对真实索引进行五分钟的检测比任何新闻标题都更有价值。需分别读取十个数据块。

实际上，只需按顺序执行三步操作：首先进行十个数据块的测试，判断语料库是否属于四种负面情况之一，之后再使用已公布的公式计算索引成本。只有第三步需要预算，而前两步则决定了是否有必要申请预算。

有一个问题不可避免。Anthropic将结果明细以静态PDF的形式放在附录中，而非原始数据集，那些试图复现这些数据的独立团队认为这存在可复现性问题。此外，针对英语以外语言语料库的第一手评估也极为罕见。在这些问题得到解决之前，这里的每一个数据都源自特定的实验环境，而非物理定律，而目前最缺乏的正是针对非英语语料库的实际应用测试数据。