Contextual Retrieval 是什么？给 Chunk 补上下文为什么能提升 RAG 召回？
面试怎么回答
切分后每个 Chunk 丢失了在原文中的上下文，比如「该季度营收增长 3%」不知道是哪家公司哪个季度，向量和用户问题不像，就检索不到。Contextual Retrieval 是在入库前，把整篇文档和 Chunk 一起交给模型，为每个 Chunk 生成一小段上下文说明拼在前面，再分别建向量索引和 BM25 索引。代价是入库时每个 Chunk 要调一次模型，可以用提示词缓存共享文档前缀来降成本，而且只影响离线入库、不影响在线延迟。成本敏感时先用规则补标题、章节路径和元数据。最后在评测集上对比原始、规则和模型三种方式的召回率和准确率来决定。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一份财报被切成很多块，其中一块写着：「该季度营收同比增长 3%」。单看这一块，你不知道是哪家公司、哪个季度。用户问「A 公司 2025 年二季度营收增长多少」，这一块的向量和问题并不像，检索很可能找不到它。Contextual Retrieval（上下文检索）就是解决这个问题的一种方法。
问题的根源
切分时，每个 Chunk 丢失了它在整篇文档中的上下文：属于哪份文档、哪一章、在讨论什么对象。Chunk 越小，问题越明显。
做法
在向量化和建立关键词索引之前，为每个 Chunk 生成一小段上下文说明，拼在 Chunk 前面：
「这段内容来自 A 公司 2025 年第二季度财报的营收分析部分，讨论的是季度营收同比变化。」该季度营收同比增长 3%……
具体做法是把整篇文档和这个 Chunk 一起交给模型，让它写出这段说明。然后：
- 向量索引用「上下文 + Chunk」生成 Embedding；
- BM25 关键词索引也基于「上下文 + Chunk」建立。
Anthropic 在 2024 年公开过这种方法，并报告结合混合检索和重排后，检索失败率有明显下降。
代价和优化
- 成本：每个 Chunk 都要调用一次模型，而且输入包括整篇文档。利用提示词缓存（同一篇文档的多个 Chunk 共用文档前缀）可以大幅降低成本；
- 离线一次性：这是入库时的开销，只在文档新增或更新时发生，不影响在线查询的延迟；
- 存储：索引会稍大一些。
更简单的替代方案
如果成本敏感，可以先用规则补上下文，效果也不错：
- 拼上文档标题、章节路径（「数据安全制度 > 第三章 权限申请 > 3.2 敏感数据」）；
- 拼上文档的元数据：业务域、时间、产品名。
先做规则版，再评估用模型生成的上下文能额外提升多少。
怎么验证
在检索评测集上对比三组：原始 Chunk、规则补上下文、模型生成上下文，看 Recall@K 和最终回答准确率，再结合成本决定。