#六、RAG、检索、重排与知识增强
#代表笔试题
- 什么是 RAG，为什么它能缓解幻觉？
- 一个标准 RAG pipeline 包含哪些环节？
- embedding model 在 RAG 中的作用是什么？
- chunk size 和 overlap 会怎样影响召回质量？
- 什么是 hybrid retrieval？
- reranker 和 retriever 有什么不同？
#就地速答
- 问：什么是 RAG，为什么它能缓解幻觉？
答：RAG（Retrieval-Augmented Generation，检索增强生成）本质上是把“查资料”和“生成答案”接在一起：用户提问后，系统先去外部知识库里找相关证据，再把这些证据连同问题一起交给大模型生成回答。这样做的关键价值，不是让模型突然更聪明，而是把原本只能靠参数记忆回答的问题，改成“可以边查边答”。详见后文“### 61. 什么是 RAG，为什么它能缓解幻觉？”。
- 问：一个标准 RAG pipeline 包含哪些环节？
答：一个标准 RAG pipeline 通常至少包括 8 个环节：文档采集与清洗、文档切块、向量化或混合索引构建、用户 query 处理、召回、重排、上下文构造、答案生成，之后还应接上评测和引用约束。面试时最好不要只背名词，而要顺着数据流讲：原始文档先被清洗并切成可检索片段，这些片段被编码后进入索引；用户问题进来后，系统先做召回，再用 reranker 精排，把最重要的证据拼成 prompt，最后交给生成模型回答。详见后文“### 62. 一个标准 RAG pipeline 包含哪些环节？”。
- 问：embedding model 在 RAG 中的作用是什么？
答：embedding model 的作用，是把 query 和文档片段都映射到同一个向量空间里，让语义相近的内容在空间里更接近，从而支持向量检索。换句话说，它决定了系统能不能从“用户说的话”和“知识库里的表达”之间建立语义桥梁。比如用户问“合同违约后怎么赔”，文档里写的是“违约责任与损害赔偿”，如果 embedding 不够好，系统就可能根本召不回来。详见后文“### 63. embedding model 在 RAG 中的作用是什么？”。
- 问：chunk size 和 overlap 会怎样影响召回质量？
答：chunk size 和 overlap 本质上是在平衡“证据完整性”和“检索粒度”。chunk 太小，会把本来连在一起的证据切碎，导致单个片段语义不完整；chunk 太大，又会把无关上下文一起塞进去，导致召回向量变得模糊、噪声增加、上下文成本上升。overlap 的作用是防止关键信息刚好被切在边界上，因此相邻 chunk 会保留一部分重叠内容。详见后文“### 64. chunk size 和 overlap 会怎样影响召回质量？”。
- 问：什么是 hybrid retrieval？
答：hybrid retrieval 指的是把向量检索和词法检索结合起来一起用。向量检索擅长找“语义上相似”的内容，哪怕表述不完全一致也能召回；词法检索例如
BM25更擅长关键词、实体名、数字、专业缩写这类精确匹配。两者结合的目的，就是减少单一路径的盲区。详见后文“### 65. 什么是 hybrid retrieval？”。 - 问：reranker 和 retriever 有什么不同？
答：retriever 和 reranker 的分工可以概括成一句话：retriever 负责“别漏掉”，reranker 负责“排得准”。retriever 面对的是海量文档，目标是在很短时间内从大库里粗召回一小批候选，所以它更看重速度和覆盖率；reranker 面对的是已经缩小后的候选集，会用更重的模型、更细的 query-document 交互去重新排序，因此更看重精度和相关性。详见后文“### 66. reranker 和 retriever 有什么不同？”。
#代表面试题
- 你做过的 RAG 为什么效果不好，是召回差、重排差还是生成阶段利用不好？
- 为什么不是所有知识注入问题都应该用 RAG？
- 如果一个知识库有百万文档，你会怎么做索引、召回、重排和增量更新？
- GraphRAG 解决的是什么问题，它相比普通向量检索到底多了什么能力？
- “Lost in the Middle” 在 RAG 中怎么缓解？
- 你如何评估 RAG，不只是看最终答案对不对？
#就地速答
- 问：你做过的 RAG 为什么效果不好，是召回差、重排差还是生成阶段利用不好？
答：这类题最忌讳的回答，是笼统说“RAG 效果不好，可能模型不行”。标准答法一定要分层定位。第一层先看召回：正确证据到底有没有被找回来，如果根本没召回到，那问题在 embedding、索引或 query rewrite；第二层看重排：证据虽然找回来了，但是否被排到足够靠前的位置，如果高价值 chunk 排名太后，生成模型大概率用不到；第三层再看生成利用：证据已经进 prompt 了，模型是否真的引用、整合、约束在证据之上。详见后文“### 67. 你做过的 RAG 为什么效果不好，是召回差、重排差还是生成阶段利用不好？”。
- 问：为什么不是所有知识注入问题都应该用 RAG？
答：因为 RAG 解决的是“外部知识如何动态接入”问题，而不是所有模型能力问题。若系统的短板主要是知识更新快、文档量大、需要证据可追溯，那 RAG 非常合适；但如果问题本质是输出格式不稳、角色风格不对、工具调用流程不会、推理习惯不好，这些更偏行为模式的问题，单靠检索外部文档并不能根治。详见后文“### 68. 为什么不是所有知识注入问题都应该用 RAG？”。
- 问：如果一个知识库有百万文档，你会怎么做索引、召回、重排和增量更新？
答：面对百万文档，不能再用“单索引 + 单召回”思路。更稳妥的做法通常是：先做文档清洗与结构化切块，再建立向量索引和词法索引的混合检索体系；查询阶段先粗召回出一批候选，再用 reranker 精排；同时按业务重要性做冷热分层，把高频、时效性强的数据放在更快的索引层，低频长尾数据放在大库里。详见后文“### 69. 如果一个知识库有百万文档，你会怎么做索引、召回、重排和增量更新？”。
- 问：GraphRAG 解决的是什么问题，它相比普通向量检索到底多了什么能力？
答：GraphRAG 主要解决的是普通向量检索难以稳健处理的“跨文档关系、多跳推理、实体网络”问题。普通向量检索回答的是“哪段文本和 query 语义最像”，它很擅长局部相关性；但如果问题需要把多个实体、事件、时间线、因果关系串起来，仅靠相似度往往不够。详见后文“### 70. GraphRAG 解决的是什么问题，它相比普通向量检索到底多了什么能力？”。
- 问：“Lost in the Middle” 在 RAG 中怎么缓解？
答：缓解
Lost in the Middle的关键，不是继续往 prompt 里塞更多材料，而是让最关键证据更靠前、更集中、更结构化。常见做法包括：用更强的 reranker 把高价值 chunk 排到最前；控制上下文长度，避免低价值材料把证据稀释掉；按主题分组或先做摘要，让证据结构更清晰；必要时采用分步检索或 iterative retrieval，而不是一次性把所有材料拼进去。详见后文“### 71. “Lost in the Middle” 在 RAG 中怎么缓解？”。 - 问：你如何评估 RAG，不只是看最终答案对不对？
答：评估 RAG 至少要分三层。第一层是召回层：正确证据有没有被召回，top-k 命中率、recall、MRR 这类指标能帮助判断“找没找到”；第二层是利用层：模型最终回答是否真正忠实于证据，是否引用了正确片段，是否把无关噪声带进了答案；第三层才是任务层：最终答案对不对、有没有帮助、用户是否满意。详见后文“### 72. 你如何评估 RAG，不只是看最终答案对不对？”。
#这一块真正考什么
- 是否知道 RAG 不是一个单点技巧，而是一条检索系统 + 生成系统的联合链路。
- 是否能够对失败案例做模块级定位。
#作答抓手
回答 RAG 问题时，尽量按 数据入库 -> 切分 -> 表征 -> 召回 -> 重排 -> 上下文拼装 -> 生成 -> 评测 的顺序说。