Contextual Retrieval：更好的 RAG

Q: 「Contextual Retrieval：更好的 RAG」要解决的关键问题是什么？

在检索前先给 Chunk 加上下文，Anthropic 的 RAG 升级方案 让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。 写下一个问题：试完这个方法后，你能用什么证据回答它？

本页解决的问题

先给结论

「Contextual Retrieval：更好的 RAG」要解决的关键问题是什么？

在检索前先给 Chunk 加上下文，Anthropic 的 RAG 升级方案

判断标准

让这个结论先证明自己值得留下。把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。

下一步

写下一个问题：试完这个方法后，你能用什么证据回答它？

常见误区

结论听起来很完整，却没有检查最关键的假设。

传统 RAG 的核心问题

传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷：

Chunk 脱离上下文后变得模糊不清

文档被切成 Chunk 后，每个 Chunk 失去了它在原文中的位置信息。一段在原文中意义清晰的文本，单独拿出来可能完全无法理解。

典型案例

"The company's Q2 revenue increased by 3% over the previous quarter."

哪个公司？哪一年？Q1 的基准是多少？这个增长率在行业中算好还是差？所有这些关键上下文，都在切 Chunk 时丢失了。向量检索可能找到了这个 Chunk，但它本身携带的信息严重不足。

完整文档

切成 Chunks

上下文丢失

检索模糊

Contextual Retrieval 的核心思路

在 Embedding 前，用 LLM 给每个 Chunk 加上上下文前缀

思路非常直观：在对 Chunk 做向量化之前，先用 LLM 阅读整篇文档，然后为每个 Chunk 生成一段简短的上下文描述作为前缀。这样每个 Chunk 在被检索时都自带了必要的语境信息。

BEFORE -- 裸 Chunk

"The company's Q2 revenue increased by 3% over the previous quarter."

谁？什么时候？无从得知。

AFTER -- 带上下文的 Chunk

"This chunk is from the company's 2024 Annual Report, specifically the Financial Performance section. The company's Q2 revenue increased by 3% over the previous quarter."

LLM 生成的前缀自动补充了来源、时间、章节。

三层递进优化

LAYER 01

Contextual Embeddings

给每个 Chunk 加上下文前缀后再做向量化。前缀包含文档标题、章节位置、关键实体等信息。向量检索时，Chunk 自带语境，语义匹配更精准。

LAYER 02

Contextual BM25

传统的 BM25 关键词检索也加上上下文前缀。前缀中的关键词（如公司名、年份）让 BM25 能匹配到原本因缺少语境而无法命中的 Chunk。向量检索 + BM25 双路召回，互补盲区。

LAYER 03

Reranking

检索后，用 Reranker 模型对候选 Chunk 重新排序。Reranker 能更精确地判断 Chunk 与查询的相关性，把最相关的结果排到前面。三层叠加效果最佳。

效果数据

检索失败率降低幅度

仅 Contextual Embeddings

49%

Contextual Embeddings + BM25 + Reranking

67%

67% 的检索失败率降低意味着什么？假设之前每 100 次检索有 30 次找不到正确的 Chunk（失败率 30%），优化后失败率降到约 10%，三分之二的检索错误被消除了。对于依赖 RAG 的生产系统来说，这是质的飞跃。

成本权衡

没有免费的午餐

预处理成本增加：每个 Chunk 都需要一次额外的 LLM 调用来生成上下文前缀。对于大规模文档库，这个预处理成本不可忽视。

Prompt Caching 可以降低成本：同一篇文档的不同 Chunk 共享相同的文档级上下文。利用 Prompt Caching，可以避免重复发送整篇文档内容。

适合高准确率场景：如果你的 RAG 系统对准确率要求极高（如法律文档检索、医疗知识问答、金融合规查询），额外的预处理成本是值得的。对于容错率高的场景（如闲聊推荐），可能不划算。

RAG 不是切 Chunk 加向量检索就够了，每个 Chunk 要自带上下文。Contextual Retrieval 的核心洞察：检索的质量瓶颈在 Chunk 本身的信息完整性，换更强的向量模型帮助有限。给 Chunk 补上丢失的语境，检索失败率可以降低三分之二。

「传统 RAG 的核心问题」为什么能找到相关内容

「传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。

相似度不是答案，召回之后还要核对

在「传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。

先区分找得到和找得准

把「传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。

从「传统 RAG 的核心问题」走到「Contextual Retrieval 的核心思路」

「传统 RAG 的核心问题」先把问题落在「传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷」上；到了「Contextual Retrieval 的核心思路」，讨论继续推进到「在 Embedding 前，用 LLM 给每个 Chunk 加上上下文前缀思路非常直观：在对 Chunk 做向量化之前，先用 LLM 阅读整篇文档，然后为每个 Chunk 生成一段简短的上下文描述作为前缀。这样每个 Chunk 在被检索时都自带了必要的语境信息。 BEFORE -- 裸 Chunk "The company's Q2 revenue increased by 3% over the previous…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。

把这条判断带到下一个场景

检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。

「传统 RAG 的核心问题」：传统 RAG 的工作流程是：把文档切成小块（Chunk），对每个 Chunk 做向量化，用户提问时检索最相似的 Chunk，然后把 Chunk 喂给 LLM 生成答案。这个流程有一个致命缺陷
「Contextual Retrieval 的核心思路」：在 Embedding 前，用 LLM 给每个 Chunk 加上上下文前缀思路非常直观：在对 Chunk 做向量化之前，先用 LLM 阅读整篇文档，然后为每个 Chunk 生成一段简短的上下文描述作为前缀。这样每个 Chunk 在被检索时都自带了必要的语境信息。 BEFORE -- 裸 Chunk "The company's Q2 revenue increased by 3% over the previous…
「成本权衡」：没有免费的午餐预处理成本增加：每个 Chunk 都需要一次额外的 LLM 调用来生成上下文前缀。对于大规模文档库，这个预处理成本不可忽视。 Prompt Caching 可以降低成本：同一篇文档的不同 Chunk 共享相同的文档级上下文。利用 Prompt Caching，可以避免重复发送整篇文档内容。适合高准确率场景：如果你的 RAG 系统对准确率要求极高（如法律文档检索、医疗知识问答、金融合规查询），额…

最后的「成本权衡」把讨论落到「没有免费的午餐预处理成本增加：每个 Chunk 都需要一次额外的 LLM 调用来生成上下文前缀。对于大规模文档库，这个预处理成本不可忽视。 Prompt Caching 可以降低成本：同一篇文档的不同 Chunk 共享相同的文档级上下文。利用 Prompt Caching，可以避免重复发送整篇文档内容。适合高准确率场景：如果你的 RAG 系统对准确率要求极高（如法律文档检索、医疗知识问答、金融合规查询），额…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录

文章讨论

读到这里，留下一个判断。

把刚想明白的地方、还没想通的问题，留给下一位一起学习的人。

↗

正在讨论 Contextual Retrieval：更好的 RAG 可靠 Agent 的工程模式

3条讨论文章讨论 · 与共学社区同步

在共学社区查看

Asha Morgan内容编辑2026年8月20日

观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。

文章讨论7 有帮助

Lin Harper独立开发者2026年8月18日

观点观点

读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助

Kiki Moore产品运营2026年8月15日

问题问题

如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。

文章讨论4 有帮助