Anthropic 推出上下文检索：给文本块补全背景，RAG 错误率降 67%

做过检索增强生成（RAG）的开发者，大概都吃过这种暗亏：辛辛苦苦把上百页财报切成几百 token 的小块存进向量数据库，结果问模型某家公司第二季度营收涨了多少，系统硬是翻不出来。

翻不出来的根源特别尴尬。切片里可能清清楚楚写着「公司营收环比增长了 3%」，但因为切片时丢了上下文，这段话里既没有公司名字，也没有具体年份。向量检索对不上，精准搜索也抓瞎。

Anthropic 提出了一个叫「语境检索」（Contextual Retrieval）的方案，核心思路简单到让人意外：在把文本块送去计算向量和建索引之前，先让小模型给每个块在开头拼上一段 50 到 100 token 的全局背景说明。

给每个文本块补上一段自我介绍

传统 RAG 遇到这种上下文断裂，往往束手无策。Anthropic 的做法是拉来 Claude 3 Haiku，让它先读一遍整篇文档，然后为每一个切片写一段简短的定位描述。

比如原来孤零零的「营收环比增长 3%」，被模型处理后，开头就会加上「这段内容出自 ACME 公司 2023 年第二季度财报」。处理完的切片，再分别去做向量嵌入和 BM25 关键词索引。

这里保留老牌算法 BM25 是个很务实的细节。纯向量模型虽然擅长理解意思，但经常抓不住特定的错误代码或型号。要是用户搜一个「TS-999」，向量模型可能只找来一大堆通用的故障排查指南，而 BM25 却能凭着精确字符把目标直接捞出来。

Anthropic 在代码库、小说、ArXiv 论文和科学论文上的测试表明，单用语境向量检索就能把 top-20 的检索失败率降低 35%。如果把语境向量和语境 BM25 结合，失败率直接降了 49%；要是再加一道重排序，失败率降幅能达到 67%。

用提示词缓存把预处理成本打下来

很多团队之前不是想不到这个思路，而是算力账根本算不过来。几十万个切片，每个都要让大模型读一遍整篇长文档来补上下文，API 账单分分钟爆表。

Anthropic 这次能跑通，关键在于他们前阵子刚上线的 Prompt Caching（提示词缓存）。处理同一篇文档的不同切片时，长文档只需要写入缓存一次，后续调用直接复用。

按照他们的测算，拿 8000 token 的文档切成 800 token 的块来算，处理一百万 token 的文档，生成上下文的一次性成本大概只需要 1.02 美元。

如果你的知识库体量更小，连 20 万 token（大约 500 页材料）都不到，Anthropic 甚至建议干脆别折腾 RAG 了。直接用提示词缓存把全部内容一股脑塞进 prompt，延迟能降低两倍以上，费用还能省 90%。

为什么重要

对正在搭建企业知识库或垂直客服的团队来说，这套方案几乎是目前性价比最高的一剂止痛药。RAG 最让人头疼的就是召回准确率卡在瓶颈期，花几块钱给存量文档跑一遍批量预处理，就能让召回失败率腰斩，这笔投入无论怎么算都很划算。

对行业来说，Anthropic 实际上在纠偏一种盲目追求复杂架构的风气。过去一年里，为了解决切片丢失上下文的问题，业界折腾出了图 RAG、多级递归切片、甚至一堆复杂的自主检索智能体，把管道搞得无比臃肿。

我们认为，Anthropic 走得极其聪明的地方在于，他们用极度廉价的轻量模型把问题在「数据准备阶段」就给抹平了，甚至还顺手盘活了传统 BM25 算法。不过看起来这套方案也有局限，它的成本优势高度依赖提示词缓存，而且只适合相对静态的知识库；如果你的数据每分每秒都在高频增删变动，每次更新都要重新跑一遍上下文生成，维护成本和复杂度依然不可小觑。