引入 Contextual Retrieval

导读

本文介绍 Contextual Retrieval：在文档切块前为每个 chunk 添加上下文说明，结合 BM25 与 embedding 检索，显著降低 RAG 系统检索失败率。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• 传统 RAG 切块会让 chunk 失去文档级背景，导致检索时语义不完整。
• Contextual Retrieval 在每个 chunk 前加入简短上下文，说明它来自哪份文档和讨论什么。
• 这种上下文可由 Claude 预处理生成，并存入检索索引。
• 方法可与 embedding search、BM25 和 reranking 结合。
• 目标是降低 retrieval failure rate，让生成阶段拿到更相关证据。
• contextual embeddings 与 contextual BM25 处理的是不同检索信号。
• 上下文生成需要平衡信息量和 token/storage 成本。
• RAG 质量不仅取决于模型，还取决于 chunking、indexing、retrieval 和 reranking。

正文

原文主线

本文介绍 Contextual Retrieval：在文档切块前为每个 chunk 添加上下文说明，结合 BM25 与 embedding 检索，显著降低 RAG 系统检索失败率。

传统 RAG 的切块问题

RAG 系统通常把长文档切成 chunks，再用 embedding 或关键词检索相关片段。问题是 chunk 一旦离开原文档，很多上下文会丢失：代词指代、章节主题、表格含义、术语定义、时间范围都可能不再清楚。

当用户查询需要这些背景时，检索系统可能错过正确 chunk，或者把缺乏上下文的 chunk 交给模型，导致生成阶段只能猜。

Contextual Retrieval 怎么做

Contextual Retrieval 的方法是在索引前为每个 chunk 生成简短说明，描述它在原文档中的位置和含义。例如说明该片段来自某份财报的风险章节，讨论某地区营收变化，而不是只保存原始段落。

这些上下文与原 chunk 一起进入索引。检索时，embedding search 和 BM25 都能利用额外背景，更容易匹配用户问题。

与 BM25、embedding、rerank 的组合

embedding 擅长语义相似，BM25 擅长关键词精确匹配。Contextual Retrieval 不要求二选一，而是让两者都获得更完整文本。随后可以用 reranker 对候选结果重新排序，进一步提高相关性。

这提醒我们，RAG 不是单一技术点。chunking、context generation、indexing、hybrid search、reranking、prompt assembly 每一步都会影响最终答案。

成本与质量权衡

为每个 chunk 生成上下文会增加预处理成本、索引存储和 token 使用。因此上下文不宜过长，应聚焦能帮助检索的文档级信息。不同文档类型需要不同模板：合同、财报、代码文档、研究论文的上下文线索并不一样。

团队应通过 retrieval eval 衡量收益：看正确答案所需 chunk 是否被召回、排序是否前移、生成答案是否减少幻觉。

深度解读

Contextual Retrieval 的核心洞见很朴素：检索失败常常不是因为模型不懂，而是因为我们把材料切碎后抹掉了意义。它把一部分理解工作提前到索引阶段，用模型为数据加语境，再让传统检索受益。对企业知识库来说，这比单纯换更大的 embedding 模型更可控，因为它改善的是数据表示。RAG 的竞争力越来越像信息架构能力，而不是只看生成模型。

落地启示

• 为 chunk 添加文档级上下文，而不是只保存原始片段。
• 结合 BM25、embedding 和 reranking，而不是二选一。
• 针对合同、财报、代码文档等类型设计不同上下文模板。
• 用 retrieval eval 测召回率和排序提升。
• 控制上下文长度，避免成本超过收益。