开场：RAG 的瓶颈不在向量模型，而在 Chunk 本身

RAG 的核心假设是「检索到正确的 Chunk 就能给出正确的答案」。但实践中发现了一个根本性问题：切 Chunk 的过程本身就会丢失关键信息。Contextual Retrieval 正是为了解决这个问题。

一句话速览：在检索前先给 Chunk 加上下文，Anthropic 的 RAG 升级方案。

一、传统 RAG 的核心问题：Chunk 脱离上下文后变得模糊不清

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

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

典型案例

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

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

完整文档 → 切成 Chunks → 上下文丢失 → 检索模糊

二、Contextual Retrieval 的核心思路：在 Embedding 前加上下文前缀

思路非常直观：在对 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 1：Contextual Embeddings

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

Layer 2：Contextual BM25

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

Layer 3：Reranking

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

四、效果数据：49% → 67%

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

五、成本权衡：没有免费的午餐

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

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

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

结语

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