#模块六：RAG、检索、重排与知识增强

#61. 什么是 RAG，为什么它能缓解幻觉？

#标准答案

RAG（Retrieval-Augmented Generation，检索增强生成）本质上是把“查资料”和“生成答案”接在一起：用户提问后，系统先去外部知识库里找相关证据，再把这些证据连同问题一起交给大模型生成回答。这样做的关键价值，不是让模型突然更聪明，而是把原本只能靠参数记忆回答的问题，改成“可以边查边答”。

它能缓解幻觉，核心有三层原因。第一，外部知识可以实时更新，模型不用把所有新知识都塞进参数里；第二，回答时有显式证据，模型更容易围绕真实材料组织答案；第三，很多企业场景需要可追溯性，RAG 可以把”答案从哪来”也一起给出来。但要注意，RAG 只是降低幻觉概率，不是自动消灭幻觉：如果检索错了、证据排序错了，或者模型拿到证据却没真正利用好，仍然会答错。

#深度解析

1. RAG 与 Fine-tuning 的本质区别

关键洞察：RAG 和 Fine-tuning 不是互斥的，而是互补的。一个完整的系统通常是”RAG 提供知识 + Fine-tuning 提供行为”。

2. RAG 失败的三层诊断法

当 RAG 效果不好时，按这个顺序排查：

第一层：召回层（Retrieval）

• 正确证据是否在 top-k 中？
• 排查方法：看检索结果的 recall@k
• 根因：embedding 不好、query 表述与文档不匹配、chunk 切分破坏了语义完整性

第二层：重排序层（Reranking）

• 正确证据是否在前列？
• 排查方法：看 MRR（Mean Reciprocal Rank）
• 根因：reranker 模型不够强、分数校准不好

第三层：生成层（Generation）

• 模型是否真正利用了证据？
• 排查方法：看 faithfulness（答案与证据的一致性）
• 根因：prompt 中没有强制引用、证据被噪声淹没、模型”幻觉”忽略了证据

3. Query Rewrite 的作用

用户原始 query：”这玩意怎么用？” —— 模型无法理解”这玩意”指什么。

Query rewrite 把模糊 query 改写成适合检索的形式：

• “这玩意” → 根据对话历史推断指代对象
• “怎么用” → 扩展为”使用步骤、配置方法、常见问题”

常见 rewrite 策略：

• HyDE（Hypothetical Document Embedding）：让模型先生成一个假设的回答，再用这个回答去检索
• Multi-query：把一个问题改写成多个不同表述，分别检索后合并结果
• Step-back：先问一个更通用的”原理级”问题，再基于原理检索具体细节

4. 面试官常见深挖追问

• ”RAG 的检索结果有 10 段，怎么决定把哪些放进 prompt？”
  • 答：不是简单取 top-k，而是综合考虑：1）相关性分数阈值，低于阈值的直接丢弃；2）多样性，避免多段内容重复；3）长度预算，根据模型窗口倒推能放多少；4）时序/逻辑顺序，按文档结构或时间线组织，而不是按相关度随机排列。

• ”如果检索到的证据互相矛盾，RAG 怎么办？”
  • 答：这是 RAG 的深水区。简单做法是在 prompt 中告诉模型”以下信息可能矛盾，请综合判断”；进阶做法是在检索层做冲突检测，标记矛盾证据，甚至让模型先生成”证据冲突分析”再回答。

• ”RAG 的 embedding 模型和生成模型需要配对吗？”
  • 答：理想情况下应该考虑匹配。如果生成模型是中文为主的，embedding 也选中文优化过的；如果生成模型是代码模型，embedding 最好也懂代码语义。但这不是绝对的——通用 embedding（如 BGE、GTE）在大多数场景下已经足够。关键是评测：在真实业务数据上测 recall，选召回率最高的。

#62. 一个标准 RAG pipeline 包含哪些环节？

#标准答案

一个标准 RAG pipeline 通常至少包括 8 个环节：文档采集与清洗、文档切块、向量化或混合索引构建、用户 query 处理、召回、重排、上下文构造、答案生成，之后还应接上评测和引用约束。面试时最好不要只背名词，而要顺着数据流讲：原始文档先被清洗并切成可检索片段，这些片段被编码后进入索引；用户问题进来后，系统先做召回，再用 reranker 精排，把最重要的证据拼成 prompt，最后交给生成模型回答。

真正高质量的回答，还应补一句：RAG 不是单点技巧，而是一条联合链路，所以任何一层出问题都会让最终答案变差。比如切块过碎会让证据丢失，召回不准会找不到材料，重排差会把噪声顶到前面，上下文拼装差会让模型“看到了却没用好”。

#深度解析

1. RAG Pipeline 的数据流详解

原始文档
  ↓ [文档采集与清洗]
清洗后的文档（去噪、去重、格式统一）
  ↓ [文档切块]
文档片段 chunks（如每段 512 token，overlap 50 token）
  ↓ [向量化/索引]
向量数据库索引（如 FAISS、Milvus、Pinecone）
  ↓ [用户 Query 进入]
用户问题
  ↓ [Query 处理]
改写/扩展后的 query（如 HyDE、multi-query）
  ↓ [召回]
Top-k 候选片段（如 top-100）
  ↓ [重排序]
精排后的 top-n 片段（如 top-5）
  ↓ [上下文构造]
Prompt = System + 问题 + "参考信息:" + top-n 片段
  ↓ [答案生成]
模型生成回答
  ↓ [评测]
评估回答质量（正确性、忠实度、完整性）

2. 每个环节的常见失败模式

3. 评测 RAG 的分层指标

4. 面试官常见深挖追问

• "RAG 系统里，召回和重排为什么通常是两个独立模型？"
  • 答：因为它们的优化目标不同。召回模型（bi-encoder）追求"快+覆盖"——把海量文档快速筛到几百个候选；重排模型（cross-encoder）追求"准+精细"——用 query 和文档的细粒度交互判断相关性。如果把重排器当召回器用，太慢；如果把召回器当重排器用，太粗。

• "如果知识库每天更新，RAG 的索引怎么增量更新？"
  • 答：1）新增文档：直接编码入库；2）修改文档：删除旧 chunk 的向量，插入新 chunk；3）删除文档：删除对应的所有 chunk 向量。挑战在于 chunk 的增删可能改变相邻 chunk 的 overlap，需要重新计算边界 chunk。

• "RAG 里的 embedding 模型需要自己训练吗？"
  • 答：通常不需要从零训练。通用 embedding（如 BGE、GTE、E5）在大多数场景已经足够。但在垂直领域（如法律、医疗），通用 embedding 可能召不回专业术语，这时可以用领域数据做继续训练或对比学习微调。判断标准不是固定阈值，而是看真实 query-document 对上的 recall、误召回类型、业务风险和成本；如果通用模型在关键切片上明显漏召回，才值得做领域微调或换模型。

#63. embedding model 在 RAG 中的作用是什么？

#标准答案

embedding model 的作用，是把 query 和文档片段都映射到同一个向量空间里，让语义相近的内容在空间里更接近，从而支持向量检索。换句话说，它决定了系统能不能从“用户说的话”和“知识库里的表达”之间建立语义桥梁。比如用户问“合同违约后怎么赔”，文档里写的是“违约责任与损害赔偿”，如果 embedding 不够好，系统就可能根本召不回来。

它之所以关键，是因为 RAG 的第一步不是生成，而是”先找对材料”。embedding model 选得不好，后面 reranker、prompt、生成模型再强也很难救。所以回答时最好再补一句：embedding 的好坏不仅影响召回率，还影响多语言能力、专业术语匹配、长文档切块效果，以及整个系统的延迟和索引成本。

#深度解析

1. 召回与重排的两种打分架构：Bi-Encoder vs Cross-Encoder

这里要避免一个常见误解：只有 Bi-Encoder 这类稠密召回模型会产出可预计算、可入库的文档 embedding；Cross-Encoder 通常不是 embedding model，而是对给定 query-doc 对直接打相关性分数的 reranker。Bi-Encoder 更快，是因为文档向量可以预计算并索引，查询时只需编码 query 然后做最近邻搜索。

2. embedding 训练的核心：对比学习（Contrastive Learning）

训练目标：让正样本（相关的 query-doc 对）在向量空间中靠近，负样本远离。

InfoNCE Loss:
L = -log[ exp(sim(q, d⁺)/τ) / Σ exp(sim(q, dᵢ)/τ) ]

其中：
- q: query 向量
- d⁺: 正样本 doc 向量
- dᵢ: 所有候选 doc 向量（含负样本）
- τ: 温度系数，控制分布锐度
- sim: 余弦相似度

负样本构造策略（关键！）：

3. embedding model 选择决策树

选择 embedding 模型：
├─ 通用中文场景
│   └─ BGE / GTE / E5 系列中文或多语言模型，按业务评测选型
├─ 通用英文场景
│   └─ GTE-large / E5-large / OpenAI text-embedding-3
├─ 多语言混合
│   └─ E5-multilingual / BGE-m3
├─ 专业领域（法律/医疗/代码）
│   └─ 领域微调：基于通用模型 + 领域数据对比学习
└─ 延迟极度敏感
    └─ 小模型：GTE-base / BGE-small，或 ONNX 量化

4. embedding 维度与索引成本的权衡

重要：OpenAI 的 text-embedding-3 支持维度截断（如从 3072 截到 512），在精度和速度间灵活取舍。

5. embedding 效果评估指标

6. 面试官常见深挖追问

• ”为什么 Cross-Encoder 比 Bi-Encoder 精确，但不能用于召回？”
  • 答：Cross-Encoder 把 query 和 doc 一起输入 Transformer，注意力层可以直接交互（如 query 的 “赔偿” 和 doc 的 “违约责任” 形成 attention），所以打分更准。但它需要为每个 query-doc 对跑一次前向传播，无法预计算。面对百万级文档库，O(N×M) 的复杂度不可接受。

• ”embedding 模型对 chunk size 敏感吗？”
  • 答：非常敏感。Bi-Encoder 把整段文本压缩成一个固定维度向量（如 768-d）。如果 chunk 太长（>512 tokens），后面的内容会被”平均”掉，信息稀释；如果 chunk 太短，上下文缺失。所以 embedding model 的 max sequence length 和 chunk size 要匹配。

• ”同一个 embedding 模型，为什么在不同领域表现差异很大？”
  • 答：embedding 模型在通用语料上训练，学到的语义表示偏向通用分布。遇到专业术语、领域缩写、特定表达时，向量可能偏离真实语义。解决方案：1）领域微调（在领域数据上做对比学习）；2）领域术语扩展（把术语映射到通用概念）；3）混合检索（BM25 + 向量）。

• ”如何评估 embedding 质量？需要标注多少数据？”
  • 答：最小可用方案：准备 100-500 个 query-doc 对（含正负样本），计算 Recall@10 和 MRR。如果指标低于 0.7，说明 embedding 召回能力不足，需要优化模型、切分策略或增加训练数据。

#64. chunk size 和 overlap 会怎样影响召回质量？

#标准答案

chunk size 和 overlap 本质上是在平衡“证据完整性”和“检索粒度”。chunk 太小，会把本来连在一起的证据切碎，导致单个片段语义不完整；chunk 太大，又会把无关上下文一起塞进去，导致召回向量变得模糊、噪声增加、上下文成本上升。overlap 的作用是防止关键信息刚好被切在边界上，因此相邻 chunk 会保留一部分重叠内容。

但 overlap 也不是越大越好。重叠太大时，索引中会出现大量近重复片段，既增加存储和计算成本，也会让检索结果里反复出现同样内容，挤占真正有价值的候选。所以面试里最好把答案讲成：chunk size 决定颗粒度，overlap 决定边界稳健性，两者都要围绕文档结构、问题类型和模型上下文窗口来调。

#深度解析

1. Chunk Size 的定量影响

假设一篇 1000 词的文档，用不同 chunk size 切分：

规律：

• chunk 太小 → 语义断裂，单个片段无法独立回答问题
• chunk 太大 → 向量被噪声稀释，检索时匹配精度下降
• Sweet spot：通常 200-500 tokens，具体取决于文档类型

2. 不同文档类型的 Chunk 策略

3. Overlap 的设计原理

Overlap 解决的是"边界切断"问题：

文档："...人工智能在医疗领域的应用包括影像诊断和药物研发..."

Chunk 1 (0-100)："...人工智能在医疗领域的应用包括影像诊"
Chunk 2 (80-180)："断和药物研发..."

无 overlap 时，"影像诊断"被切成两半，两个 chunk 都语义不完整。
Overlap=20 时：
Chunk 1 (0-100)："...人工智能在医疗领域的应用包括影像诊断"
Chunk 2 (80-180)："应用包括影像诊断和药物研发..."

推荐 overlap：chunk size 的 10-20%（如 chunk=256，overlap=25-50 tokens）。

4. 高级 Chunk 策略

• 语义切分（Semantic Chunking）：不用固定长度，而用句子/段落边界，确保每个 chunk 语义完整
• 层次切分（Hierarchical Chunking）：大 chunk（如 512）用于粗检索，小 chunk（如 128）用于精定位
• 上下文增强（Contextual Retrieval）：每个 chunk 附带文档级上下文摘要，帮助 embedding 理解局部语义

5. 面试官常见深挖追问

• "如果一个问题的答案跨越了两个 chunk，RAG 怎么保证召回完整？"
  • 答：1）overlap 让相邻 chunk 共享边界信息；2） parent-child 检索（先召回大 chunk，再在大 chunk 内定位小 chunk）；3）多跳检索（先找到一个 chunk，再用其中的实体/引用去检索下一个 chunk）。

• "Chunk size 对 embedding 质量有什么影响？"
  • 答：embedding 模型通常有最优输入长度（如 512 tokens）。chunk 太长超过这个长度会被截断，导致尾部信息丢失；chunk 太短则 embedding 的语义表示不够丰富（如 "深度学习是" 这个不完整句子 embedding 后没有意义）。理想 chunk 长度应接近 embedding 模型的最优长度。

• "如果文档是结构化数据（如表格、JSON），怎么 chunk？"
  • 答：不能简单按长度切。表格应按行/块切，保留表头上下文；JSON 应按对象切；代码应按函数/类切。核心原则：chunk 的边界必须是语义边界，不能是任意字符位置。

#65. 什么是 hybrid retrieval？

#标准答案

hybrid retrieval 指的是把向量检索和词法检索结合起来一起用。向量检索擅长找“语义上相似”的内容，哪怕表述不完全一致也能召回；词法检索例如 BM25 更擅长关键词、实体名、数字、专业缩写这类精确匹配。两者结合的目的，就是减少单一路径的盲区。

它通常比纯向量或纯关键词更稳，因为真实业务里两种需求都会出现。比如法规条款号、报错码、商品型号这类问题，关键词检索往往更强；而用户换种说法提问时，向量检索又更有优势。所以回答时最好补一句：hybrid retrieval 的价值不只是”多加一路”，而是把召回覆盖率和精确性一起抬高，为后续 reranker 提供更好的候选集。

#深度解析

1. BM25 的核心原理

BM25（Best Match 25）是经典词法检索算法，基于 TF-IDF 改进：

score(q, d) = Σ IDF(q_i) * [f(q_i, d) * (k1 + 1)] / [f(q_i, d) + k1 * (1 - b + b * |d|/avgdl)]

• f(q_i, d)：词 q_i 在文档 d 中的词频
• IDF(q_i)：逆文档频率（稀有词权重高）
• k1：控制词频饱和度（通常 1.2-2.0）
• b：控制文档长度归一化（通常 0.75）

与向量检索的本质区别：

• BM25 只关心”有没有出现这个词”和”出现了多少次”
• 向量检索关心”语义是否相近”（即使词不同，意思相近也能召回）

2. Hybrid Retrieval 的融合策略

两种检索各返回一组候选，需要融合成一个统一排序：

RRF 是最鲁棒的方法，因为它只使用排名而不是原始分数，避免了不同检索器分数尺度不一致的问题。

3. 向量检索 vs 关键词检索的盲区对比

4. 实际工程实现

主流方案：

• Elasticsearch + 向量插件：传统 BM25 + HNSW 向量索引，同一平台查询
• Pinecone/Weaviate/Milvus：原生支持 hybrid search，内置 RRF
• 自研方案：向量库和关键词库独立查询，服务层做 RRF 融合

5. 面试官常见深挖追问

• ”Hybrid retrieval 里，α（向量权重）选多大合适？”
  • 答：没有统一答案，需要通过验证集调参。一般原则：如果用户查询包含很多专业术语/实体/代码，α 应该偏小（更依赖关键词）；如果查询是开放式自然语言，α 应该偏大（更依赖语义）。也可以通过查询分类器动态调整 α。

• ”RRF 中的 k 参数有什么影响？”
  • 答：k 是平滑常数（通常取 60）。k 越大，高排名的优势越不明显（更平等）；k 越小，第一名和第二名的差距越大。k=60 是经验值，能在”尊重高排名”和”给低排名机会”之间取得平衡。

• ”如果关键词检索召回 100 个、向量检索召回 100 个，融合后取多少个给 reranker？”
  • 答：通常取 top-50 到 top-100。太多会增加 reranker 成本（reranker 通常比 retriever 慢 10-100 倍），太少可能漏掉正确证据。最佳值通过实验确定：固定 reranker 和生成模型，改变候选数，看最终答案准确率的变化曲线，找到拐点。

#66. reranker 和 retriever 有什么不同？

#标准答案

retriever 和 reranker 的分工可以概括成一句话：retriever 负责“别漏掉”，reranker 负责“排得准”。retriever 面对的是海量文档，目标是在很短时间内从大库里粗召回一小批候选，所以它更看重速度和覆盖率；reranker 面对的是已经缩小后的候选集，会用更重的模型、更细的 query-document 交互去重新排序，因此更看重精度和相关性。

为什么要分两层？因为如果一开始就用很重的交互模型去扫全库，成本太高；但如果只有 retriever，很多相似但不够关键的文档会排在前面，真正证据可能被埋掉。面试里高分回答通常会补一句：RAG 里生成模型往往只真正利用前几个 chunk，所以 reranker 常常决定”最后 20% 的效果上限”。

#深度解析

1. Bi-Encoder vs Cross-Encoder：两种排序范式

核心区别：Bi-Encoder 是”分别理解再比较”，Cross-Encoder 是”放在一起理解关系”。

2. 为什么 Reranker 精度更高？

假设 query=”苹果的营养价值”，doc1=”苹果公司发布新款 iPhone”，doc2=”每天吃苹果有助于健康”。

• Bi-Encoder：分别编码 query 和两个 doc，用向量相似度比较。”苹果”这个词在 query 和 doc1 中都高频出现，可能错误地把 doc1 排前面。
• Cross-Encoder：把 “query [SEP] doc” 拼接后输入模型，模型能看到 “苹果” 和 “营养价值” 的共现关系，更容易判断 doc2 更相关。

3. 两阶段检索的成本分析

假设知识库有 100 万文档：

如果没有 reranker，LLM 需要处理 top-100（成本大增）；如果只用 reranker 扫全库，100 万 × 200ms = 55 小时，不可行。

4. 高级 Reranker：ColBERT 的 Late Interaction

ColBERT 是一种折中方案：

• 离线阶段：把 query 和 doc 分别编码成 token 级别的向量序列（不是整个文档一个向量）
• 在线阶段：计算 query 每个 token 和 doc 每个 token 的相似度，取最大匹配和

优点：比 Bi-Encoder 精度高（token 级交互），比 Cross-Encoder 快（离线预计算 doc 向量）。

5. 面试官常见深挖追问

• ”Reranker 的输入长度通常有限制（如 512 tokens），如果 doc 很长怎么办？”
  • 答：1）只对 doc 的前 512 tokens 做 rerank（假设关键信息在开头）；2）把长 doc 切分成多个 passage，分别和 query 做 rerank，取最高分；3）先用检索定位到相关段落，再对段落做 rerank。实践中方法 2 最常用。

• ”如果 retriever 已经把正确文档排到了第 50 名，reranker 能救回来吗？”
  • 答：取决于 reranker 的质量和候选集大小。如果 reranker 只处理 top-20，那第 50 名就救不回来了。所以 retriever 的 recall@100 必须足够高——reranker 负责 precision，不负责召回。如果正确文档根本没进候选集，reranker 无能为力。

• ”什么情况下可以去掉 reranker，只用 retriever？”
  • 答：1）对延迟极度敏感（reranker 增加 100-500ms）；2）文档本身很短（如 FAQ），retriever 已经足够精确；3）成本敏感（reranker 需要额外 GPU）；4）候选集很小（如 <10 个）。但大多数生产 RAG 系统保留 reranker，因为它对最终效果的提升通常 worth the cost。

#67. 你做过的 RAG 为什么效果不好，是召回差、重排差还是生成阶段利用不好？

#标准答案

这类题最忌讳的回答，是笼统说“RAG 效果不好，可能模型不行”。标准答法一定要分层定位。第一层先看召回：正确证据到底有没有被找回来，如果根本没召回到，那问题在 embedding、索引或 query rewrite；第二层看重排：证据虽然找回来了，但是否被排到足够靠前的位置，如果高价值 chunk 排名太后，生成模型大概率用不到；第三层再看生成利用：证据已经进 prompt 了，模型是否真的引用、整合、约束在证据之上。

如果想显得更像做过项目，可以继续补一条定位链：坏例抽样 -> 标注文档是否存在正确证据 -> 检查 top-k 召回命中 -> 检查 rerank 后排序 -> 检查最终 prompt 结构和输出引用情况。这样答，面试官会觉得你不是只知道 RAG 名词，而是真的会查链路。

#深度解析

1. 分层诊断的具体操作

2. 常见故障模式与根因

3. 坏例分析的标准流程

Step 1: 抽样 50-100 个 bad case
Step 2: 人工判断"正确答案应该是什么"
Step 3: 检查知识库中是否存在正确证据
   └─ 不存在 → 知识库缺口，需要补充文档
   └─ 存在但没召回 → 召回问题
Step 4: 如果召回了，检查是否在 top-5
   └─ 不在 top-5 → 重排问题
   └─ 在 top-5 但模型没用 → 生成利用问题
Step 5: 统计各层问题比例，优先解决占比最高的

4. 量化指标参考

5. 面试官常见深挖追问

• "如果召回层没问题，但生成层总是忽略证据，怎么解决？"
  • 答：1）Prompt 工程：明确要求"基于以下证据回答"，并规定引用格式（如 [doc_id]）；2）SFT：构造带引用的训练数据，让模型学会引用；3）RLHF：对引用准确的回答给更高奖励；4）后处理：用规则检查答案中是否出现引用标记，无引用则拒绝或重试。

• "RAG 效果不好的 case 中，召回问题、重排问题、生成问题各占多少比例？"
  • 答：行业经验（因领域而异）：召回问题约占 40-50%（最常见），重排问题约占 20-30%，生成利用问题约占 20-30%。所以优化 RAG 通常从召回开始，因为"没找到"比"找到了没用"更根本。

• "如果一个 bad case 在召回层、重排层、生成层都有问题，先修哪一层？"
  • 答：从下往上修。先生成层（最容易、成本最低：改 prompt）；再重排层（中等成本：换/训 reranker）；最后召回层（最难：可能需改 embedding、重建索引）。但也有例外——如果召回层问题极严重（recall@10 < 50%），应该先修召回，因为上层优化建立在召回质量之上。

#68. 为什么不是所有知识注入问题都应该用 RAG？

#标准答案

因为 RAG 解决的是“外部知识如何动态接入”问题，而不是所有模型能力问题。若系统的短板主要是知识更新快、文档量大、需要证据可追溯，那 RAG 非常合适；但如果问题本质是输出格式不稳、角色风格不对、工具调用流程不会、推理习惯不好，这些更偏行为模式的问题，单靠检索外部文档并不能根治。

所以面试里最好把边界讲清：RAG 更像外挂知识库，fine-tuning 更像改模型习惯，系统工程则解决权限、流程和观测问题。真正成熟的判断不是”RAG 高级所以都该上”，而是先分清你缺的是知识、行为、流程，还是三者都有。

#深度解析

1. RAG 的适用边界矩阵

2. RAG 的成本结构

如果问题用 SFT 就能解决（如固定格式的报告生成），引入 RAG 会增加不必要的复杂度和延迟。

3. “知识”vs”行为”的本质区别

4. 混合方案：RAG + SFT 的组合

生产系统通常不是二选一：

• RAG 负责：动态知识、证据溯源、大规模文档
• SFT 负责：输出格式、角色风格、工具调用流程
• Prompt 负责：安全边界、引用格式、回答长度

5. 面试官常见深挖追问

• ”如果一个客服系统回答风格不对，应该 RAG 还是 SFT？”
  • 答：SFT。风格是行为问题，不是知识问题。RAG 只能提供”说什么内容”的材料，不能改变”怎么说”的风格。需要收集符合期望风格的对话数据做 SFT，或者通过 system prompt 约束输出格式。

• ”如果模型总是回答'根据我的知识...'而不是引用检索到的文档，这是 RAG 问题还是模型问题？”
  • 答：是模型行为问题。模型没有学会”基于证据回答”的行为模式。解决：1）Prompt 明确要求引用；2）SFT 数据中加入带引用的回答示例；3）后处理检查引用标记。RAG 系统本身可能工作正常（召回到了正确文档），但生成模型没有利用。

• ”RAG 和 Fine-tuning 在成本上怎么比较？”
  • 答：RAG 的持续维护成本高（索引更新、检索调优），但增量知识更新便宜（改文档即可）；SFT 的一次性训练成本高，但部署后维护成本低（除非需要更新行为）。知识频繁变化 → RAG 更划算；行为需要精确控制 → SFT 更直接。

#69. 如果一个知识库有百万文档，你会怎么做索引、召回、重排和增量更新？

#标准答案

面对百万文档，不能再用“单索引 + 单召回”思路。更稳妥的做法通常是：先做文档清洗与结构化切块，再建立向量索引和词法索引的混合检索体系；查询阶段先粗召回出一批候选，再用 reranker 精排；同时按业务重要性做冷热分层，把高频、时效性强的数据放在更快的索引层，低频长尾数据放在大库里。

增量更新也要单独设计。新增或变更文档应支持局部重切块、局部重编码和局部写入，而不是每次全量重建；但为了避免索引长期漂移或碎片化，仍应定期全量重建。面试时如果你能主动讲到”召回质量、更新延迟、存储成本、线上 SLA”要一起平衡，会比只说”建个向量库”成熟得多。

#深度解析

1. 百万级文档的系统架构

┌─────────────────────────────────────────┐
│              查询层 (Query Layer)         │
│  Query Rewrite → Intent Classification    │
└──────────────────┬──────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│            检索层 (Retrieval Layer)       │
│  ┌──────────┐    ┌──────────┐          │
│  │ 向量索引  │ ←→ │ 词法索引  │          │
│  │ (HNSW)   │    │ (BM25)   │          │
│  └──────────┘    └──────────┘          │
│         ↓ 混合召回 top-200              │
└──────────────────┬──────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│            重排层 (Rerank Layer)          │
│     Cross-Encoder Reranker              │
│         ↓ top-5 给 LLM                  │
└──────────────────┬──────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│           生成层 (Generation Layer)       │
│         LLM + 引用生成                   │
└─────────────────────────────────────────┘

2. 索引设计的分层策略

3. 向量索引算法选择

百万级文档推荐：HNSW + PQ 组合，平衡召回率和查询速度。

4. 增量更新策略

推荐：批量增量为主 + 定期全量重建（如每天增量，每周全量）。

5. 面试官常见深挖追问

• ”百万文档建一次索引要多久？需要多少资源？”
  • 答：以 BGE-large 编码（512 维向量）为例：单张 A100 编码速度约 1000-5000 文档/秒（取决于文档长度）。100 万文档约需 200-1000 GPU 分钟（3-16 小时）。HNSW 索引构建约需 1-4 小时。总时间约 1 天，需要 1-4 张 A100。存储：100 万 × 512 维 × 4 字节 ≈ 2 GB（向量）+ 原文档存储。

• ”如果文档每天更新 1%，增量更新和全量重建怎么选？”
  • 答：增量更新足够。每天 1 万文档的局部更新对 HNSW 索引影响很小。但建议每月做一次全量重建，因为：1）增量写入可能导致索引结构非最优；2）删除文档后索引中留有”空洞”；3）长期累积的碎片会影响查询性能。

• ”向量库选型：Milvus、Pinecone、Weaviate、Qdrant 怎么选？”
  • 答：Pinecone 是托管服务，最快上手但成本较高；Milvus 功能最全（支持混合检索、多模态、分布式），适合大规模自建；Weaviate 原生支持模块化（可直接集成 embedding 模型）；Qdrant 轻量高效，适合中小规模。百万级自建推荐 Milvus 或 Qdrant；不想运维推荐 Pinecone。

#70. GraphRAG 解决的是什么问题，它相比普通向量检索到底多了什么能力？

#标准答案

GraphRAG 主要解决的是普通向量检索难以稳健处理的“跨文档关系、多跳推理、实体网络”问题。普通向量检索回答的是“哪段文本和 query 语义最像”，它很擅长局部相关性；但如果问题需要把多个实体、事件、时间线、因果关系串起来，仅靠相似度往往不够。

GraphRAG 多出来的能力，是把知识组织成节点和边，让系统不仅知道”这段像不像”，还知道”这个实体和那个实体有什么关系””哪些证据应该沿着图继续扩展”。因此它更适合企业知识图谱、复杂调查、跨文档分析等场景。但它也更复杂，若问题本身只是单跳问答，GraphRAG 可能只是把系统做重了。

#深度解析

1. GraphRAG 的典型流程（以微软 GraphRAG 为例）

Step 1: 文档切分 → 文本 chunk
Step 2: 实体抽取（LLM）→ 识别人物、组织、地点、事件
Step 3: 关系抽取（LLM）→ “A 是 B 的 CEO”、”C 收购了 D”
Step 4: 构建知识图谱 → 节点=实体，边=关系
Step 5: 社区检测 → 把相关实体聚成社区
Step 6: 生成社区摘要 → 每个社区一段高层总结
Step 7: 查询时 → 先在社区摘要层定位，再深入具体实体

2. 向量检索 vs GraphRAG 的能力对比

3. GraphRAG 的适用场景

4. GraphRAG 的局限

• 构建成本高：需要 LLM 抽取实体和关系，百万文档可能需数万次 LLM 调用
• 抽取误差累积：实体识别错误会导致图结构错误，影响下游查询
• 动态更新复杂：新文档加入后，可能需要重新抽取和建图
• 查询延迟高：图遍历 + LLM 生成摘要，延迟通常是向量检索的 5-10 倍

5. 面试官常见深挖追问

• ”GraphRAG 和知识图谱 + RAG 的混合方案有什么区别？”
  • 答：本质类似，但 GraphRAG 更强调”从非结构化文本自动抽取图谱”，而传统知识图谱通常是人工或半自动构建的。GraphRAG 的卖点是”无需预定义 schema，LLM 自动发现实体和关系”。但代价是抽取质量不稳定，且难以保证一致性。

• ”GraphRAG 的社区检测是做什么的？为什么需要它？”
  • 答：社区检测（如 Louvain 算法）把图谱中紧密连接的实体聚成社区。目的：1）降维——百万实体直接查询太慢，先定位到相关社区再深入；2）全局视角——社区摘要提供跨文档的高层概览，回答”总结”类问题。没有社区检测，GraphRAG 就退化为普通实体关系查询。

• ”如果文档每天都在变，GraphRAG 怎么增量更新？”
  • 答：是难点。新文档需要：1）抽取新实体/关系；2）合并到现有图谱（实体对齐：判断”张三”和”Mr. Zhang”是否同一人）；3）更新社区结构和摘要。实体对齐（Entity Resolution）是最大挑战——错误合并会导致图谱污染，不合并会导致信息碎片化。通常需要规则 + 模型结合的混合策略。

#71. “Lost in the Middle” 在 RAG 中怎么缓解？

#标准答案

缓解 Lost in the Middle 的关键，不是继续往 prompt 里塞更多材料，而是让最关键证据更靠前、更集中、更结构化。常见做法包括：用更强的 reranker 把高价值 chunk 排到最前；控制上下文长度，避免低价值材料把证据稀释掉；按主题分组或先做摘要，让证据结构更清晰；必要时采用分步检索或 iterative retrieval，而不是一次性把所有材料拼进去。

如果想回答得更工程化，可以补一句：这个问题说明长上下文能力和检索质量不是一回事。模型形式上支持 128K，也不代表它会平均利用每一段证据。所以 RAG 的优化重点常常不在“加大窗口”，而在“把对的证据摆到对的位置”。

#深度解析

1. "Lost in the Middle" 的实验证据

2023 年斯坦福论文《Lost in the Middle》的定量发现：

• 当上下文包含 20 个文档时，关键信息在开头的准确率 ~90%
• 关键信息在结尾的准确率 ~85%
• 关键信息在中间（第 10-15 位）的准确率骤降到 ~50%

这说明：LLM 不是"看不完"，而是"注意力分配不均匀"——开头和结尾有位置偏置（positional bias），中间信息被忽略。

2. 缓解策略的效果对比

3. 为什么"加大窗口"不是解决方案？

常见误区："模型支持 128K，我把所有召回的 chunk 都塞进去不就好了？"

问题：

• 128K 上下文 ≠ 128K 的有效利用能力
• 即使装得下，注意力分配仍然不均匀
• 更多 chunk = 更多噪声 = 中间信息被进一步稀释

正确思路：在有限且精心选择的上下文里放置最关键证据，而不是盲目扩大窗口。

4. 高级策略：Iterative Retrieval

不是一次性检索所有证据，而是多轮交互：

Round 1: 检索 "公司 A 的 CEO 是谁" → 得到 "张三"
Round 2: 检索 "张三 公司 B" → 发现张三同时是 B 的顾问
Round 3: 检索 "公司 A 和 B 的关系" → 发现关联交易

优点：每轮上下文很短（2-3 个 chunk），不存在"Lost in the Middle" 缺点：延迟增加（多轮检索 + 多轮生成）

5. 面试官常见深挖追问

• "如果 reranker 已经把正确证据排到了第 2 位，模型仍然忽略它，怎么办？"
  • 答：这是生成层问题。可能原因：1）模型训练时没有"必须引用前 3 个证据"的约束；2）prompt 没有明确要求引用。解决：在 prompt 中加入"请基于以下证据回答，并引用 [doc_id]"的强制要求，或做 citation-aware SFT。

• "Lost in the Middle 和 Recency Bias 有什么区别？"
  • 答：Recency Bias（近因偏置）是模型更关注最近看到的内容（如对话末尾）；Lost in the Middle 是模型忽略中间位置的内容。两者相关但不完全相同。在 RAG 中，如果所有证据同时放入 prompt，表现出来的是 Lost in the Middle（中间证据被忽略）；如果是多轮对话，可能同时有 Recency Bias（更关注最近几轮的证据）。

• "为什么有些模型（如 Gemini 1.5 Pro）号称能解决 Lost in the Middle？"
  • 答：通过改进注意力机制（如稀疏 attention、位置编码优化）和更长的训练序列，这些模型在"大海捞针"测试（needle in haystack）中表现更好。但注意："能找到针"≠"能综合所有信息做出最佳判断"。即使模型能从 128K 中找到关键句，它仍然可能不善于综合分散在全文中的多段证据。所以 RAG 优化仍然重要。

#72. 你如何评估 RAG，不只是看最终答案对不对？

#标准答案

评估 RAG 至少要分三层。第一层是召回层：正确证据有没有被召回，top-k 命中率、recall、MRR 这类指标能帮助判断“找没找到”；第二层是利用层：模型最终回答是否真正忠实于证据，是否引用了正确片段，是否把无关噪声带进了答案；第三层才是任务层：最终答案对不对、有没有帮助、用户是否满意。

如果只看最终答案，很难定位问题到底出在检索、重排还是生成。一个成熟的回答还可以补一句：线上还应结合人工坏例审查、引用一致性检查、用户反馈和失败类型聚类，形成闭环，而不是把 RAG 当成一次性的离线 benchmark 任务。

#深度解析

1. RAG 评估的三层指标体系

2. 端到端评估 vs 组件评估

推荐：开发阶段用组件评估定位问题，上线后用端到端评估监控效果。

3. 自动评估方法

RAGAS 指标计算：

• faithfulness = 回答中的陈述能被证据支持的比例
• answer_relevancy = 回答与问题的相关性
• context_precision = 上下文中相关 chunk 的比例
• context_recall = 回答问题所需信息在上下文中的覆盖度

4. 线上闭环评估体系

离线评估（开发期）
  ├─ 自动指标（RAGAS）→ 快速迭代
  ├─ LLM Judge → 主观质量
  └─ 人工抽检 →  ground truth

线上评估（部署期）
  ├─ 实时指标：延迟、错误率、引用率
  ├─ 用户反馈：点赞/点踩、满意度
  ├─ 坏例聚类：自动归类失败模式
  └─ 定期人工审计：深度分析

5. 面试官常见深挖追问

• "RAGAS 的 faithfulness 怎么自动计算？"
  • 答：步骤：1）用 LLM 把回答拆成独立陈述；2）对每个陈述，检查上下文中是否有证据支持；3）支持的陈述数 / 总陈述数 = faithfulness。自动化但依赖 LLM 的判断质量，可能有偏差。

• "如果一个 RAG 系统 offline 指标很好，但线上用户满意度低，可能是什么原因？"
  • 答：1）offline 测试集与线上分布不一致（数据漂移）；2）offline 指标没覆盖用户体验维度（如回答太长、太正式）；3）线上有离线没遇到的 edge case；4）延迟问题——offline 不计延迟，线上慢导致用户不满。解决：增加线上 A/B 测试、收集用户反馈、定期用线上数据更新测试集。

• "怎么设计一个'可复现'的 RAG 评估流程？"
  • 答：1）固定测试集（含 query、标准证据、参考答案）；2）固定评估指标和计算脚本；3）固定模型版本和配置；4）记录每次实验的完整配置（prompt、chunk size、top-k、reranker）；5）用版本控制管理测试集和评估代码。关键是：任何改动都要能通过相同的评估流程量化影响。

#73. Contextual Retrieval、Parent-Child 和 Multi-hop RAG 分别解决什么问题？

#标准答案

这三个方法都在解决传统 RAG 的同一个核心问题：单个 chunk 往往既不够完整，也不一定能单跳命中。Contextual Retrieval 给每个 chunk 补上来自整篇文档的上下文说明，让原本孤立的片段在 embedding 和 BM25 中更可检索；Parent-Child Retrieval 用小 chunk 做精确召回，但把对应的大段 parent chunk 或章节放进上下文，兼顾召回粒度和证据完整性；Multi-hop RAG 则把一个复杂问题拆成多次检索，每一跳根据上一跳找到的实体、条件或中间结论继续查。

面试里不要把它们背成三个工具名，而要讲清适用场景：如果 chunk 离开原文后指代不明，用 contextual retrieval；如果答案跨段落但直接用大 chunk 会召回不准，用 parent-child；如果问题天然需要多文档、多实体、多条件串联，用 multi-hop。它们的共同代价是 ingestion 成本、检索延迟和评测复杂度都会上升，所以要用坏例和指标证明值得引入。

#深度解析

1. 三种增强策略的输入输出

2. 为什么它们比“top-k 调大”更稳

简单把 top-k 调大，只是把更多候选塞进上下文，不能保证候选有正确粒度，也不能保证模型能利用它们。Contextual Retrieval 改的是 chunk 的可检索语义，Parent-Child 改的是“召回粒度”和“阅读粒度”的错配，Multi-hop 改的是复杂问题的一次性召回假设。它们分别在 ingestion、retrieval 和 query planning 三个位置增加结构，而不是在最后阶段堆材料。

3. 如何判断该不该上这些增强

• 抽样 bad case，先标注错误证据是否存在于知识库，以及直接 top-k 是否能召回。
• 如果正确 chunk 被召回但缺上下文，优先试 parent-child 或 contextual retrieval。
• 如果正确证据分散在多个文档且单跳 query 总是只命中其中一部分，优先试 query decomposition / multi-hop。
• 如果只是 embedding 对术语不敏感，先补 BM25、术语表、领域 embedding 或 reranker，不要直接上复杂图谱。

4. 面试官常见深挖追问

• “Contextual Retrieval 会不会污染原文？”
  • 答：会有风险，所以上下文说明应作为可追踪的辅助字段保存，不能覆盖原始 chunk。评测时要同时看 retrieval recall 和 citation faithfulness：如果检索靠摘要命中，但最终引用原文不支持结论，就说明 contextual summary 过度推断了。

• “Parent-Child Retrieval 和直接大 chunk 有什么区别？”
  • 答：直接大 chunk 用同一个粒度同时承担召回和阅读，容易向量稀释；parent-child 把两个目标拆开：child 小，方便精确命中；parent 大，方便模型读完整证据。这是粒度解耦，不是单纯调大 chunk size。

• “Multi-hop RAG 最大的工程风险是什么？”
  • 答：错误传播。第一跳如果实体识别错，后面会围绕错误方向继续检索。工程上要保存每跳 query、证据、判断和终止原因，并允许 verifier 判定“证据不足，停止继续扩展”。

#74. RAG 召回错了怎么办？Self-RAG、CRAG 和 verifier 型纠错链路怎么设计？

#标准答案

RAG 的关键脆弱点是：生成质量高度依赖检索质量。一旦检索到的证据不相关、过时或互相冲突，模型可能基于错误材料生成更“自信”的错误答案。纠错型 RAG 的核心思路，是在生成前或生成中加入一个 evidence verifier：先判断召回证据是否足够、是否相关、是否冲突，再决定直接回答、重新检索、改写 query、扩大检索源，或者拒答。

Self-RAG 更强调模型在生成过程中学会“何时检索、证据是否支持、答案是否应继续修正”；CRAG 更像在传统 RAG 外面加一个轻量检索评估器，把 retrieved documents 分成正确、模糊、错误等状态，再触发不同处理路径。工程面试里可以把它们抽象成一套通用链路：retrieve -> verify -> route -> generate -> cite -> post-verify。重点不是背论文名，而是能把“证据不可信时怎么办”讲清楚。

#深度解析

1. 纠错型 RAG 的状态机

query
  -> initial retrieval
  -> evidence verifier
       ├─ relevant & sufficient
       │    -> generate with citation
       ├─ partially relevant / ambiguous
       │    -> query rewrite + second retrieval
       ├─ conflicting evidence
       │    -> conflict summary + ask for scope / answer with caveat
       ├─ irrelevant evidence
       │    -> fallback search / broaden source / refuse
       └─ permission or freshness risk
            -> filtered retrieval / index refresh / safe refusal

2. verifier 应该看什么

3. Self-RAG / CRAG 的工程化抽象

Self-RAG 的价值在于把检索是否需要、证据是否支持和答案是否应修正变成模型可学习的控制信号；CRAG 的价值在于承认检索会错，并把“错了以后怎么走”显式建成路由策略。生产系统不一定要复现论文训练流程，但应吸收它们的思想：证据进入生成前先被评分，生成后再被引用校验，错误样本要回流到检索评测集。

4. 面试官常见深挖追问

• “verifier 本身如果错了怎么办？”
  • 答：verifier 也要被评测。可以用人工标注的 evidence relevance / sufficiency 数据集校准它，重要场景用规则、reranker、LLM judge 多信号投票，并记录 verifier 版本。不要让一个黑盒 judge 成为新的单点故障。

• “RAG 纠错会不会让延迟太高？”
  • 答：会，所以应按风险分层。低风险 FAQ 可以一跳检索直接答；高风险法律、金融、权限相关问题才启用 verifier、二次检索和引用校验。纠错链路是按失败代价启用，不是所有请求全量启用。

#75. 企业知识库 RAG 的权限、版本、缓存和日志怎么设计？

#标准答案

企业知识库 RAG 的难点不是“向量库能不能查”，而是每一次回答都要满足四个约束：用户只能看到有权限的材料，答案基于正确版本，缓存不会跨租户或跨权限泄漏，出问题时能复现整条链路。因此权限、版本、缓存和日志必须从入库开始设计，而不是上线后补。

一个可靠设计通常是：入库时为每个 chunk 保存 tenant、owner、ACL、classification、document_id、chunk_id、version、updated_at、source_url、hash；查询时先做身份解析和 metadata filter，再检索和重排；缓存 key 必须包含租户、用户权限摘要、索引版本、prompt 版本和模型版本；日志要保存 query、rewrite、top-k、rerank、prompt evidence ids、final citation、拒答原因和工具调用结果。这样才能回答“为什么这个用户昨天看到了这个答案”。

#深度解析

1. 元数据不是附属字段，而是安全边界

2. 缓存必须按权限和版本失效

RAG 缓存常见有 query 结果缓存、embedding 缓存、rerank 结果缓存、prompt / answer 缓存。危险点在于：两个用户问同一句话，不代表他们有权看到同一批证据；同一用户今天和昨天问同一句话，也不代表文档版本相同。因此 cache key 至少要包含 tenant、权限摘要、index_version、document_version watermark、retrieval config、prompt version 和 model id。高风险场景宁可少缓存，也不能跨权限复用答案。

3. 日志要能复现，而不是只留最终答案

trace_id
  user / tenant / permission snapshot
  raw query
  rewritten queries
  index version + retrieval config
  top-k doc ids + scores
  reranked doc ids + scores
  packed context doc ids + token counts
  model / prompt version
  final answer + citations
  verifier result / refusal reason
  latency / token cost / cache hit

没有这些 trace，线上 bad case 只能靠猜。成熟团队会把失败样本自动进入 eval set：召回漏了就补 retrieval eval，引用错了就补 faithfulness eval，权限异常就补安全回归。

4. 面试官常见深挖追问

• “权限过滤是在向量检索前做，还是检索后做？”
  • 答：原则上越早越好。能下推到 metadata filter 就下推；如果向量库不支持复杂 ACL，至少要先按租户和粗粒度密级切索引，再在 rerank / packing 前做精细过滤。不能等生成后再删，因为无权证据已经影响了答案。

• “文档删除后，历史日志还能不能保留引用内容？”
  • 答：要区分审计日志和可见内容。审计侧可以保留不可逆 hash、doc_id、版本和访问事件；原文快照要遵循数据保留和删除策略，必要时做加密、访问审批或脱敏。不能为了可复现而无限期保存敏感全文。