在知识库问答这类场景中，RAG 已成为当下最主流的 LLM 应用范式。如何为大模型提供既全面又精准的上下文信息，一直是业界持续探索的方向。传统 RAG 解决方案存在一个固有缺陷：在编码信息时，上下文信息容易丢失，导致系统难以从知识库中有效检索出相关内容。因此，核心挑战转变为：如何更好地保留并利用上下文信息？ Anthropic 研究团队最近提出了一种名为“Contextual Retrieval（上下文检索）”的创新方法，在该领域取得了显著突破。他们发布了一篇技术文章[1]详细阐述了技术细节，通过上下文嵌入（Contextual Embeddings）和上下文 BM25（Contextual BM25），可将检索失败率降低 49%；再结合重排序（reranking），失败率可进一步降至 67%。下面我们来深入解析这一方法。

上下文检索的创新点

传统 RAG 系统在分割文档时，很容易破坏上下文连贯性，导致检索到的信息分块缺乏必要的背景说明。例如，假设有一个财务信息知识库，用户提问：“ACME 公司在 2023 年第二季度的收入增长是多少？”某个相关分块可能写着：“公司的收入比上一季度增长了 3%。”——但仅凭这句话，无法确定具体是哪家公司、哪个时间段。这使得检索或利用该信息变得非常困难。 研究团队尝试了一些业内流行的改进方案，例如在分块中添加文档摘要（adding generic document summaries to chunks）[2]、假设文档嵌入（hypothetical document embedding）[3]、基于摘要的索引（summary-based indexing）[4]，但效果均不理想。 随后他们转换思路：在嵌入之前，先为每个分块附加一段独特的解释性上下文（Contextual Embeddings），同时构建 BM25 索引（Contextual BM25），以此解决上下文缺失问题。例如： 原始分块 = “公司的收入比上一季度增长了3%。” 上下文化分块 = “这个分块来自ACME公司在2023年第二季度的SEC文件；上一季度的收入为3.14亿美元。公司的收入比上一季度增长了3%。” 这样一来，检索准确性显著提升，尤其是在处理包含特定标识符或技术术语的查询时。

如何实现上下文检索

手动为知识库中成千上万个分块逐一添加上下文并不现实。研究团队采用 Claude 模型，通过特定的提示来为每个分块生成简洁的上下文。生成的上下文通常只有 50-100 个 token，然后将其附加到分块中，再进行嵌入和 BM25 索引创建。 以下是官方 prompt 示例： ```html {{WHOLE_DOCUMENT}} Here is the chunk we want to situate within the whole document {{CHUNK_CONTENT}} 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. ``` 具体实现步骤如下： 1. **生成上下文**：首先让 Claude 为每个分块生成上下文。例如，某个分块内容是“公司的收入比上一季度增长了3%”，Claude 生成的上下文可能是：“这个分块来自ACME公司在2023年第二季度的SEC文件；上一季度的收入为3.14亿美元。公司的收入比上一季度增长了3%。” 2. **添加上下文到分块**：将生成的上下文直接附加到原始分块中，使每个分块拥有充分的背景信息。 3. **创建嵌入**：接着使用嵌入模型（如 Voyage 或 Gemini）将上下文化分块转换为向量嵌入。这些向量是高维空间中的点，代表文本的语义含义。 4. **创建 BM25 索引**：同时为上下文化分块创建 BM25 索引，这是一种基于词频和逆文档频率的检索算法，能有效衡量文本与查询之间的相关性。 5. **存储和检索**：嵌入向量和 BM25 索引分别存储在向量数据库和 BM25 索引库中。用户输入查询后，系统可以同时利用两者进行检索，找到最相关的上下文化分块。 6. **重排序**：检索到相关分块后，使用重排序技术进行过滤和排序，确保最相关的分块才被传递给生成模型。这一步能大幅提升检索的准确性和相关性。 在实现上下文检索时，研究团队特别强调了几点注意事项： * **分块策略**：文档的分割方式——包括分块大小、边界设定、重叠程度——都会影响检索性能。 * **嵌入模型**：选择合适的模型至关重要，Gemini[5] 和 Voyage[6] 在测试中表现更为突出。 * **自定义上下文提示**：通用提示在大多数场景下已足够，但特定场景可能需要定制提示才能获得更优结果。 * **分块的数量**：增加提供给模型的分块数量，确实能提高找到相关信息的概率。但过多信息也可能使模型“分心”，因此需要设置上限。研究团队测试了提供 5、10、20 个分块，发现 20 个在三个选项中表现最佳，不过具体应用场景仍需自行尝试。 * **持续评估**：将上下文化的分块传递给响应生成器，同时区分上下文与分块本身，有助于优化响应生成。

效果如何

实验结果令人信服： * 上下文嵌入使前 20 个分块的检索失败率降低了 35%（从 5.7% 降至 3.7%）。 * 上下文嵌入与上下文 BM25 双管齐下，前 20 个分块的检索失败率降低了 49%（从 5.7% 降至 2.9%）。 此外，利用提示缓存技术可以有效控制成本。假设每块 800 token，文档 8k token，上下文指令 50 token，每块上下文 100 token，生成上下文化块的一次性成本约为每百万文档 token 1.02 美元。

联合重排序进一步提升性能

在传统 RAG 中，AI 系统从知识库检索到大量潜在相关的信息分块。当知识库规模庞大时，一次检索可能返回数百个分块，相关性和重要性参差不齐。重排序是一种常用的过滤技术，可以确保只有最相关的分块被传递给模型。 实验结果显示：重排序后的上下文嵌入和上下文 BM25，使前 20 个分块的检索失败率降低了 67%（从 5.7% 降至 1.9%）。 然而，需要注意的是，重排序在运行时增加了额外步骤，即使所有分块可以并行评分，也会带来一定的延迟，尤其是在重排序大量分块时。是使用更多分块换取更好性能，还是使用更少分块降低延迟和成本，这需要在具体场景中通过多次测试来找到平衡点。

总结

研究团队通过大量实验，为提升 RAG 性能指明了一条新路径，也为开发者提供了实践的新方向。 关键经验总结如下： 1. 嵌入 + BM25 比单独使用嵌入效果更好（向量检索与文本检索应结合使用）。 2. Voyage 和 Gemini 是测试中表现最佳的嵌入模型。 3. 向模型传递前 20 个分块，比仅传递前 10 个或前 5 个更有效。 4. 为分块添加上下文，显著提高了检索准确性。 5. 重排序远优于不进行重排序。 6. 所有这些改进措施可以叠加使用：上下文嵌入（选用 Voyage 或 Gemini）、上下文 BM25、重排序，并将前 20 个分块加入提示，能够实现最大的性能提升。 对此方法感兴趣的读者，可以按照 cookbook[7] 的指导直接上手体验。