Contextual Retrieval 的设计理念围绕“解决传统检索痛点、兼容现有架构、兼顾精准性与落地性”展开，核心是通过上下文补全、自动化适配、模块化叠加，在不重构现有RAG框架的前提下，大幅提升检索准确性与规模化能力。
1. 痛点导向：直击传统RAG的“上下文缺失”核心矛盾
传统RAG为适配检索效率，需将文档拆分为短文本块，但拆分后单个文本块往往丢失关键背景（如主体、时间、场景），导致“信息碎片化”——即便嵌入模型（语义匹配）与BM25（精确匹配）结合，也难以精准关联查询与文本块（例如“ACME公司2023Q2营收增长”无法匹配仅含“营收增长3%”的无上下文文本块）。
因此，设计的核心出发点是**“补全而非重构”**：不否定RAG“拆分-嵌入-检索”的核心流程，而是针对“文本块上下文缺失”这一单一痛点，通过最小化改造（为文本块添加上下文），让检索系统能“理解文本块的归属与背景”，从根源上降低检索失败率。
2. 精准适配：专属上下文优于泛化信息，拒绝无效补充
设计过程中明确“上下文的价值在于‘精准匹配检索需求’”，而非泛化的文档摘要：
- 摒弃“为文本块添加通用文档摘要”的思路（原文实验证明该方式收效甚微），转而生成仅针对单个文本块的专属上下文——需包含“文本块所属文档核心信息（如来源、主题）+ 文本块未明确的关键背景（如公司、时间、前提条件）”，确保上下文能直接补全检索时所需的匹配维度；
- 上下文要求“简洁紧凑（50-100词元）”，避免冗余信息干扰检索模型的语义编码或BM25的词法匹配，平衡“补全上下文”与“检索效率”。
3. 兼容复用：依托现有RAG技术栈，降低落地成本
设计理念强调“兼容而非颠覆”，充分复用传统RAG已验证的有效组件：
- 保留“嵌入模型（语义匹配）+ BM25（精确匹配）”的核心组合，仅在“文本块预处理阶段”增加“上下文 prepend”步骤，形成“情境嵌入”与“情境BM25”，无需重构检索流程；
- 支持与现有优化技术（重排序、优质嵌入模型如Gemini/Voyage）模块化叠加——不否定已有技术的价值，而是让“上下文补全”成为增强模块，通过“情境化+重排序+优质嵌入”的叠加效应，最大化性能提升（失败率降低67%的核心逻辑）。
4. 自动化与规模化：借助大模型实现高效落地，控制成本
针对“知识库文本块数量庞大（数千至数百万），手动标注上下文不现实”的问题，设计理念融入“自动化生成+成本可控”的考量：
- 依托Claude大模型的理解能力，通过标准化提示词（输入完整文档+目标文本块，输出专属上下文）自动化生成上下文，避免人工干预，支持大规模知识库处理；
- 结合Claude的“提示词缓存”功能，仅需一次性加载完整文档到缓存，无需重复传入文档内容生成上下文，将成本控制在“每百万文档词元1.02美元”，解决“自动化生成可能导致高成本”的落地障碍。
5. 分层适配：按需选择方案，兼顾不同知识库规模
设计理念并非“一刀切”，而是根据知识库规模提供灵活适配的路径：
- 针对小知识库（<20万词元，约500页）：优先推荐“完整文档嵌入+提示词缓存”，无需复杂检索流程，以“简洁方案”满足低成本、高效率需求；
- 针对大知识库（超出上下文窗口）：采用Contextual Retrieval，通过“上下文补全+RAG架构”实现规模化检索，确保“扩展性”与“准确性”兼顾，避免“为规模化牺牲检索质量”。
6. 结果导向：以“检索成功率”为核心，聚焦下游任务价值
设计的最终目标是“提升AI模型的下游任务性能”（如客服响应准确性、法律案例检索效率），而非单纯优化检索技术指标：
- 评估指标聚焦“1 - recall@20”（前20个文本块中未检索到相关信息的比例），直接关联“用户查询能否获取有效信息”；
- 强调“检索结果需服务于生成模型”，例如通过“区分上下文与文本块本身”提升响应生成质量，让检索优化最终转化为用户可感知的AI输出效果。
7. 引入情境检索(Contextual Retrieval)细节
2024年9月19日 00:00:00 Anthropic 工程团队
要让AI模型在特定场景下发挥作用，它通常需要获取背景知识。例如，客户支持聊天机器人需要了解其服务的特定业务相关知识，而法律分析机器人则需要掌握大量过往案例信息。
开发者通常会采用检索增强生成(Retrieval-Augmented Generation, RAG)技术来扩充AI模型的知识储备。RAG通过从知识库中检索相关信息并将其附加到用户的提示词中，显著提升模型的响应质量。但问题在于，传统RAG解决方案在对信息进行编码时会丢失上下文，这往往导致系统无法从知识库中检索到相关信息。
Anthropic引入了一种能大幅优化RAG检索环节的方法——「情境检索(Contextual Retrieval)」。该方法包含两项子技术：**情境嵌入(Contextual Embeddings)和情境BM25(Contextual BM25)**。使用这种方法可使检索失败率降低49%；若结合重排序技术，检索失败率可进一步降低67%。这些改进极大提升了检索准确性，并直接转化为下游任务的性能优化。
关于直接使用更长提示词的说明
有时最简单的解决方案就是最佳方案。如果你的知识库规模小于200,000个词元(约500页内容)，无需使用RAG或类似方法，直接将整个知识库纳入给模型的提示词即可。
几周前，我们为Claude推出了提示词缓存(prompt caching)功能，让这种方式的效率大幅提升，成本显著降低。现在，开发者可以在API调用之间缓存常用提示词，延迟降低两倍以上，成本最高可降低90%(你可以通过阅读提示词缓存使用指南了解其工作原理)。
然而，当知识库规模扩大时，你就需要更具扩展性的解决方案——这正是情境检索的用武之地。
RAG基础知识：适配更大规模知识库
对于无法放入上下文窗口的大型知识库，RAG是常规解决方案。RAG通过以下步骤对知识库进行预处理：
- 将知识库(即文档集合)拆分为较小的文本块，通常不超过几百个词元；
- 使用嵌入模型将这些文本块转换为能够编码语义的向量嵌入；
- 将这些嵌入存储在向量数据库中，以便通过语义相似度进行搜索。
在运行时，当用户向模型输入查询时，向量数据库会根据与查询的语义相似度查找最相关的文本块，随后这些最相关的文本块会被添加到发送给生成模型的提示词中。
尽管嵌入模型擅长捕捉语义关联，但它们可能会遗漏关键的精确匹配。幸运的是，有一种较早期的技术可以在这类场景中提供帮助。最佳匹配25(Best Matching 25, BM25)是一种排序函数，它通过词法匹配查找精确的单词或短语匹配，尤其适用于包含唯一标识符或专业术语的查询。
BM25基于词频-逆文档频率(TF-IDF)概念构建。TF-IDF用于衡量某个单词在一个文档集合中的重要性，而BM25对其进行了优化——它会考虑文档长度，并对词频应用饱和函数，从而避免常用词在结果中占据主导地位。
以下示例可说明BM25如何弥补语义嵌入的不足：假设用户在技术支持数据库中查询“错误代码TS-999”，嵌入模型可能会找到与错误代码相关的通用内容，但可能会遗漏“TS-999”这一精确匹配；而BM25会直接搜索该特定文本字符串，从而定位到相关文档。
通过以下步骤结合嵌入技术和BM25，RAG解决方案能更准确地检索到最适用的文本块：
- 将知识库(即文档集合)拆分为较小的文本块，通常不超过几百个词元；
- 为这些文本块生成TF-IDF编码和语义嵌入；
- 使用BM25查找基于精确匹配的顶级文本块；
- 使用嵌入查找基于语义相似度的顶级文本块；
- 通过排序融合技术合并并去重步骤3和步骤4的结果；
- 将前K个文本块添加到提示词中，以生成响应。
通过同时利用BM25和嵌入模型，传统RAG系统能够提供更全面、准确的结果，在精确术语匹配和广泛语义理解之间取得平衡。
标准检索增强生成(RAG)系统，该系统同时使用嵌入和最佳匹配25(BM25)进行信息检索。词频-逆文档频率(TF-IDF)用于衡量单词重要性，是BM25的基础。
这种方法能让你以经济高效的方式扩展到海量知识库，远超单个提示词所能容纳的范围。但这些传统RAG系统存在一个显著局限：它们往往会破坏上下文。
传统RAG中的上下文难题
在传统RAG中，为了实现高效检索，文档通常会被拆分为较小的文本块。尽管这种方法在许多应用中表现良好，但当单个文本块缺乏足够上下文时，问题就会出现。
例如，假设你的知识库中嵌入了一系列财务信息(如美国证券交易委员会(SEC)文件)，而你收到这样一个问题：“ACME公司2023年第二季度的营收增长率是多少？”
一个相关的文本块可能包含这样的内容：“该公司营收较上一季度增长3%。” 但这个文本块本身没有说明它所指的是哪家公司，也没有明确相关时间段，这使得检索正确信息或有效利用该信息变得困难。
引入情境检索(Contextual Retrieval)
情境检索通过在嵌入每个文本块(“情境嵌入”)和创建BM25索引(“情境BM25”)之前，为每个文本块添加针对该块的解释性上下文，从而解决了这一问题。
回到前面提到的SEC文件集合示例，以下是一个文本块的转换示例：
original_chunk = "The company's revenue grew by 3% over the previous quarter."contextualized_chunk = "This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter." ``````plaintext 原始文本块 = "该公司营收较上一季度增长3%。"情境化文本块 = "本文本块来自ACME公司2023年第二季度业绩的SEC文件；上一季度营收为3.14亿美元。该公司营收较上一季度增长3%。"值得注意的是，过去也有其他利用上下文改善检索的方法被提出，包括：为文本块添加通用文档摘要(我们进行了实验，但收效甚微)、假设文档嵌入(hypothetical document embedding)和基于摘要的索引(summary-based indexing)(我们进行了评估，发现性能较低)。这些方法与本文提出的情境检索存在差异。
实现情境检索
显然，手动标注知识库中数千甚至数百万个文本块的工作量极大。为了实现情境检索，我们借助了Claude的能力。我们编写了一个提示词，指导模型利用整个文档的上下文，为每个文本块提供简洁的、针对该块的上下文说明。我们使用以下Claude 3 Haiku提示词为每个文本块生成上下文：
<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. ``````plaintext <document>{{完整文档}}</document>以下是需要在整个文档中定位的文本块<chunk>{{文本块内容}}</chunk>请提供简短简洁的上下文，将该文本块置于整个文档中，以提高该文本块的搜索检索效率。仅需回答简洁的上下文，无需其他内容。生成的上下文文本通常为50-100个词元，在对文本块进行嵌入和创建BM25索引之前，会将其添加到文本块的开头。
实际的预处理流程如下：
利用提示词缓存降低情境检索的成本
得益于我们前面提到的特殊提示词缓存功能，在Claude上实现情境检索的成本极低。通过提示词缓存，你无需为每个文本块都传入参考文档——只需将文档加载到缓存中一次，之后引用之前缓存的内容即可。假设文本块为800词元、文档为8000词元、上下文指令为50词元、每个文本块的上下文为100词元，生成情境化文本块的一次性成本为每百万文档词元1.02美元。
方法论
我们在多个知识领域(代码库、小说、arXiv论文、科学论文)、多种嵌入模型、检索策略和评估指标下进行了实验。附录II中提供了我们在每个领域使用的部分问题和答案示例。
下图展示了在所有知识领域中的平均性能，使用的是表现最佳的嵌入配置(Gemini Text 004)，并检索前20个文本块。我们采用“1减去召回率@20”作为评估指标，该指标用于衡量在前20个文本块中未能检索到相关文档的比例。完整结果详见附录——在我们评估的所有嵌入-来源组合中，情境化处理均提升了性能。
性能改进
我们的实验结果表明：
情境嵌入使前20个文本块的检索失败率降低了35%(从5.7%降至3.7%)；
结合情境嵌入和情境BM25，前20个文本块的检索失败率降低了49%(从5.7%降至2.9%)。
结合情境嵌入和情境BM25，前20个文本块的检索失败率降低了49%。
实现注意事项
在实现情境检索时，需要注意以下几点：
- 文本块边界：考虑如何将文档拆分为文本块。文本块大小、边界和重叠度的选择都会影响检索性能¹；
- 嵌入模型：尽管情境检索在我们测试的所有嵌入模型中都能提升性能，但部分模型可能受益更多。我们发现Gemini和Voyage嵌入的效果尤为显著；
- 自定义情境化提示词：我们提供的通用提示词效果良好，但针对特定领域或用例定制提示词可能会获得更好的结果(例如，包含可能仅在知识库其他文档中定义的关键术语表)；
- 文本块数量：在上下文窗口中添加更多文本块会增加包含相关信息的概率，但过多信息可能会分散模型的注意力，因此存在一定限制。我们尝试了传入5个、10个和20个文本块，发现20个是这些选项中性能最佳的(详见附录中的对比)，但仍建议根据你的具体用例进行实验；
- 务必进行评估：将情境化文本块传入模型时，区分上下文和文本块本身，可能会提升响应生成效果。
通过重排序进一步提升性能
最后，我们可以将情境检索与另一种技术结合，以获得更显著的性能提升。在传统RAG中，AI系统会搜索知识库以找到潜在相关的信息文本块。对于大型知识库，这种初始检索通常会返回大量相关性和重要性各异的文本块——有时多达数百个。
重排序是一种常用的过滤技术，用于确保只有最相关的文本块被传递给模型。重排序能带来更好的响应效果，并降低成本和延迟(因为模型需要处理的信息更少)。其关键步骤如下：
- 执行初始检索，获取最具潜在相关性的文本块(我们选取了前150个)；
- 将前N个文本块与用户的查询一起传入重排序模型；
- 重排序模型根据每个文本块与提示词的相关性和重要性进行评分，然后选择前K个文本块(我们选取了前20个)；
- 将前K个文本块作为上下文传入模型，以生成最终结果。
结合情境检索和重排序，最大化检索准确性。
性能改进
市场上有多种重排序模型，我们的测试使用了Cohere重排序模型。Voyage也提供了重排序模型，但我们暂无时间进行测试。实验结果表明，在多个领域中，添加重排序步骤能进一步优化检索效果。
具体而言，经重排序的情境嵌入和情境BM25使前20个文本块的检索失败率降低了67%(从5.7%降至1.9%)。
经重排序的情境嵌入和情境BM25使前20个文本块的检索失败率降低了67%。
成本和延迟考虑
重排序需要考虑的一个重要因素是其对延迟和成本的影响，尤其是在对大量文本块进行重排序时。由于重排序在运行时增加了一个额外步骤，不可避免地会带来少量延迟——尽管重排序模型会并行对所有文本块进行评分。重排序更多文本块以获得更好性能与重排序更少文本块以降低延迟和成本之间存在内在权衡。我们建议根据你的具体用例进行不同设置的实验，以找到最佳平衡点。
结论
我们进行了大量测试，对比了上述所有技术的不同组合(嵌入模型、是否使用BM25、是否使用情境检索、是否使用重排序以及检索的前K个结果总数)，并覆盖了多种数据集类型。以下是我们的核心发现总结：
- 嵌入+BM25的效果优于单独使用嵌入；
- 在我们测试的嵌入模型中，Voyage和Gemini的表现最佳；
- 向模型传入前20个文本块比仅传入前10个或前5个更有效；
- 为文本块添加上下文能大幅提升检索准确性；
- 重排序优于不重排序；
- 这些优势可以叠加：要最大化性能提升，可将情境嵌入(来自Voyage或Gemini)与情境BM25结合，再加上重排序步骤，并向提示词中添加20个文本块。
我们鼓励所有使用知识库的开发者通过我们的使用指南(cookbook)尝试这些方法，以解锁更高水平的性能。
附录I
以下是不同数据集、嵌入提供商、是否结合BM25与嵌入、是否使用情境检索以及是否使用重排序的检索@20结果细分。
附录II提供了检索@10和@5的结果细分，以及每个数据集的示例问题和答案。
不同数据集和嵌入提供商的“1减去召回率@20”结果。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
