1 为什么生产 RAG 经常要把“检索用块”和“生成用块”分开
P1 · rag
🏷 标签：rag, chunking, retrieval, generation
1️⃣ 考察意图
面试官想考察你对 RAG 系统“检索精度”与“生成质量”之间根本矛盾的认知深度。这不是背概念题，而是工程取舍与系统设计题。刁钻点在于：候选人能否跳出“块大小”的单一维度，理解检索和生成对上下文粒度的不同需求。答好了，能展示你对生产级 RAG 的实战理解，包括索引设计、检索策略和上下文窗口管理的权衡，以及处理“语义漂移”和“信息碎片化”等实际坑的能力。
2️⃣ 标准答
核心矛盾：检索需要高精度、低噪声的小块；生成需要丰富上下文、避免碎片化的大块。生产 RAG 必须分离二者，否则会陷入“块大小”的尴尬平衡。
为什么不能用一个块大小？
- 小块（128-256 tokens）检索：语义聚焦，BM25 或 Dense Embedding（如 BGE-small）匹配时，噪声少，命中率高。例如，检索“苹果公司2023年营收”，小块“苹果2023年营收为3832亿美元”直接命中，大块“苹果公司2023年发布了iPhone 15，营收为3832亿美元，其中服务业务增长...”会引入“iPhone 15”等无关词，降低检索精度。
- 大块（512-1024 tokens）生成：LLM 需要完整上下文来推理。小块“苹果2023年营收为3832亿美元”单独给 LLM，它不知道这是否包含服务收入、汇率影响等，容易产生幻觉。大块提供因果链和背景，生成更准确。
工程取舍：小块检索提升 Recall@K（比如从 0.7 到 0.85），但牺牲了生成时的上下文完整性。大块生成提升 F1 分数（比如从 0.6 到 0.75），但检索时噪声增加。分离设计就是用空间换时间：建两套索引，或检索后动态扩展上下文。
实际落地的坑 + 解法：
- 坑 1：双块索引的存储和延迟成本。建两套索引（小块用于检索，大块用于生成）意味着双倍存储和检索时多一次查询。解法：检索后上下文扩展。只建小块索引，检索到 Top-K 小块后，根据其文档 ID 或父块 ID，从原始文档中拉取对应的大块（比如父块 512 tokens）。这只需一次检索，延迟增加可控（<50ms）。
- 坑 2：小块和大块的映射断裂。小块可能跨大块边界，导致拉取的大块不完整。解法：滑动窗口 + 重叠分块。分块时，小块之间重叠 10-20 tokens，并记录每个小块所属的父块 ID（如“doc_id + chunk_index”）。检索到小块后，按父块 ID 拉取完整大块，确保上下文连续。
- 坑 3：大块超出 LLM 上下文窗口。比如用 GPT-4 的 8K 窗口，大块 1024 tokens 没问题，但若用 4K 窗口的模型，大块可能超限。解法：动态截断 + 重要性排序。检索到多个大块后，按与查询的相关性排序，只取 Top-3 大块，并截断到模型窗口的 80%（留余量给 prompt 和 query）。
具体实现方案：
- 方案 A：双块索引。建两个索引：小块索引（128 tokens，用 BGE-large 或 ColBERT 做向量检索）和大块索引（512 tokens，用 BM25 或稀疏检索）。检索时，先从小块索引拿 Top-10，再从大块索引拿 Top-3 作为生成上下文。优点：精度高；缺点：存储翻倍，维护复杂。
- 方案 B：检索后上下文扩展（推荐）。只建小块索引（256 tokens，用 HNSW 索引）。检索到 Top-5 小块后，用“父块 ID”拉取对应大块（1024 tokens）。优点：存储减半，延迟低；缺点：小块映射逻辑需精心设计。
总结：分离设计是生产 RAG 的标配，核心是用小块保证检索精度，用大块保证生成质量。推荐检索后上下文扩展，兼顾性能和效果。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，检索和生成对上下文粒度的需求不同——小块（128-256 tokens）能提高检索精度，减少噪声；大块（512-1024 tokens）能提供完整上下文，避免生成碎片化。第二，工程取舍上，双块索引或检索后上下文扩展是常见方案，我推荐后者，因为它存储成本低、延迟可控。第三，实际落地要注意小块和大块的映射断裂，用滑动窗口和父块 ID 解决。总结一句：分离设计平衡了检索效率和生成质量，是生产级 RAG 的标配。”
4️⃣ 高频追问 & 应对
追问 1：如果用户查询很长（比如 500 tokens），你的小块检索策略还管用吗？
长查询会稀释语义焦点，导致小块检索精度下降。解法：查询压缩。用一个小模型（如 BART 或 T5-small）将长查询压缩成 50-100 tokens 的摘要，再检索小块。或者用 HyDE（假设文档嵌入）：让 LLM 先生成一个假设文档，再用该文档嵌入检索。这能提升长查询的 Recall@K 约 10-15%。但注意，压缩会丢失细节，需根据场景权衡。
追问 2：你的检索后上下文扩展方案中，大块大小怎么确定？有没有自适应方法？
固定大块大小（如 512 tokens）是次优解。自适应方法：动态窗口。根据检索到的小块数量和相关度分数，动态调整大块大小。例如，如果 Top-5 小块都来自同一文档段落，则拉取整个段落（可能 1024 tokens）；如果分散，则只拉取每个小块周围 256 tokens。这可以用一个简单的规则引擎实现，或训练一个小模型预测最佳窗口大小。但自适应会增加延迟，适合对质量要求高、对延迟不敏感的场景。
追问 3：如果我用的是 Mamba 或 RWKV 这类线性注意力模型，块大小限制是否还重要？
线性注意力模型理论上支持无限上下文，但实际中仍有性能瓶颈。Mamba 的隐藏状态大小有限（如 4096），长上下文会导致信息遗忘。所以块大小仍然重要，但可以更大（如 2048 tokens）。分离设计依然有效：小块检索（256 tokens）保证精度，大块生成（2048 tokens）利用长上下文优势。但要注意，线性模型对噪声更敏感，大块中无关信息会污染生成，所以检索后需加一个 reranker（如 Cohere Rerank 3）过滤噪声。
5️⃣ 避坑 · 常见错误答法
- ❌ “块大小统一设为 512 tokens，既检索又生成，简单高效。” → ✅ “统一块大小会陷入尴尬平衡：512 tokens 对检索来说太大（噪声多），对生成来说可能不够（上下文不完整）。生产 RAG 必须分离，用小块检索、大块生成，或用检索后上下文扩展。”
- ❌ “双块索引就是建两个索引，检索时分别查，然后合并结果。” → ✅ “双块索引不是简单合并，而是分工：小块索引负责高精度召回，大块索引负责提供生成上下文。合并时需去重和排序，否则会引入冗余和噪声。推荐检索后上下文扩展，更轻量。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中遇到检索精度和生成质量的矛盾”切入，举例你如何用检索后上下文扩展解决，并给出 Recall@K 和 F1 的对比数据。强调你处理过小块映射断裂的坑。
- 如果你只做过传统 NLP：用“信息检索中的精确匹配 vs 语义理解”类比。小块像关键词匹配（高精度），大块像段落理解（高召回）。迁移到 RAG，就是 BM25 和 Dense Retrieval 的互补，你理解这种 trade-off。
- 如果你是校招无项目：聚焦论文复现。提到你读过《Lost in the Middle》和《RAPTOR》论文，理解上下文位置对生成的影响。用一个小 demo（如用 LangChain 实现双块 RAG）展示你的动手能力。
- 《Lost in the Middle: How Language Models Use Long Contexts》—— 理解上下文位置对生成质量的影响
- 《RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval》—— 分层块结构，解决块大小矛盾
- 《HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels》—— 长查询压缩的替代方案
- LangChain 文档：Parent Document Retriever —— 检索后上下文扩展的官方实现
- Cohere Rerank 3 博客：How to Build a Production-Grade RAG System —— 生产级 RAG 的最佳实践