最近我在帮团队面试算法工程师，好几个候选人简历里都写着“熟悉 RAG”，但一轮问下来，真正能把“检索增强生成”讲清楚、讲透的人不多。很多人背熟了“向量数据库 + 大模型”的组合，却解释不了为什么要切分文档、为什么召回结果不准、怎么评估效果好还是坏。这不是个别现象，而是整个行业对 RAG 的理解还停留在“会用框架”的层面。
RAG 说到底就是“先检索，再生成”，用来解决大模型知识过期、幻觉、专业领域回答不精准的问题。它不修改模型参数，而是通过外部知识库把正确答案“喂”给模型，让模型基于这些材料作答。对这个技术的理解程度，直接决定了一个候选人能不能解决实际问题。
这篇文章我把面试中最高频的 6 个问题整理出来，从基础原理到工程落地，从简单检索到混合优化的完整链路，结合我实际面试候选人和自己做过项目的经验来做拆解。不管你是准备面试的开发者，还是正在搭建 RAG 系统的工程师，这 6 个问题吃透了，基本能应对大多数场景。
1. RAG 第一问：为什么需要 RAG？和微调到底怎么选？
1.1 RAG 解决的核心矛盾
面试官问“为什么需要 RAG”，其实是在考察你对大模型局限性的认知深度。大模型有两个天生缺陷：一是知识截止于训练数据，二是所有回答都是基于概率生成，无法保证事实性。所谓的“幻觉”，本质上是模型在编造看起来合理但实际不存在的内容。
RAG 的思路很直接：模型不懂的知识，通过检索系统从外部知识库里找出来，再把找到的内容作为上下文喂给模型。模型不改变自己的参数，但每次回答都能拿到最新的、针对性的资料。这套机制同时解决了知识时效性和事实准确性的问题，成本还低。
我面试时遇到过一个候选人，说“RAG 就是把 PDF 丢进向量数据库然后拼 prompt”，这个概括方向没错，但太粗糙。他没说清楚的是：PDF 怎么转文本、文本怎么切分、向量化用什么模型、检索用什么相似度算法、召回结果怎么重排、最终 prompt 怎么构造。任何一环出了问题，回答质量都会崩。
1.2 RAG 和微调的边界
这个问题的经典误区是二选一。从业者应该清晰地认识到：
- 微调改变的是模型的“行为方式”和“表达能力”，比如让模型学会某种输出格式、语气风格或领域术语，但模型记住的知识仍然是训练时见过的，没法靠微调塞入大规模实时更新的知识。
- RAG 改变的是模型的“知识来源”，每次推理时动态注入最新、最准确的资料，适合知识密集型场景，但对模型的推理能力没有提升。
用生活化的类比来说：微调是让一个人学会用专业术语写报告，RAG 是给这个人一本随时更新的参考手册。写方案时缺了数据，翻手册就能补上；但手册再好，这个人本身表达不清晰，写出来还是乱。
我在实际项目里的经验是：先上 RAG 解决问题，如果发现模型对领域的“语言风格”适应度差，比如医学报告、法律文书的表达习惯不对，再考虑微调。RAG 上手快、迭代方便、不会破坏模型原有能力，这些优势在项目早期非常宝贵。
1.3 面试官真正想听到的回答
完整的回答应该包含三个层次。第一层是定义：RAG 是检索增强生成，通过外部检索为生成模型提供相关证据。第二层是动机：大模型存在知识过时、幻觉、缺乏专业深度的问题，RAG 用低成本方式引入实时外部知识。第三层是边界：和微调互补，RAG 管知识更新与事实约束，微调管行为模式与风格迁移。
有了这个逻辑，无论面试官后续怎么深挖，你都有清晰的线索可以延伸。
2. RAG 第二问：完整链路里每一步到底在做什么？
2.1 从文档到答案的五个阶段
RAG 的标准流程可以拆成五个环节：加载、切分、向量化、检索、生成。每一个环节都有独立的优化空间，面试官会沿着这条链路逐层追问。
加载阶段是把不同格式的数据提取成纯文本。PDF、Word、HTML、Markdown 各有各的解析难点，PDF 里扫描件需要 OCR， Word 里嵌套的表格需要特殊处理， HTML 要去除标签保留正文。这一步的产出质量直接影响后续所有环节。
切分阶段是把长文本拆成适合检索的片段。切太大会让噪声变多，切太小会丢失完整语义，需要根据文本结构、模型上下文窗口、业务查询习惯做权衡。向量化是用 Embedding 模型把文本片段映射成高维向量，理论上语义相近的文本在向量空间里距离也近。
检索阶段是把用户的查询也转成向量，通过相似度计算找到最相关的 K 个片段。生成阶段是将检索到的片段和原始问题一起交给大模型，模型综合这些上下文来生成答案。整个链路里，前四步决定“能否找到正确答案”，最后一步决定“能否把答案表达好”。
2.2 核心参数的选择逻辑
我在自己的项目里常用的初始参数组合是：分片长度 512 字符左右，chunk 之间重叠 20% 到 25%，TopK 召回取 4 到 6 个片段。这个组合不一定最优，但作为基线跑测试非常稳。
为什么要设置重叠区域，很多人没想明白。文本在切分点处可能把一个完整的逻辑单元拦腰截断，上一段的末尾信息跑到下一段的开头，重叠能保证这段跨边界的信息至少在两个 chunk 里出现，检索时命中概率更高。
Embedding 模型的选择也有讲究。通用模型处理专业领域文本时会出现“域偏移”，就是模型在训练时没见过这批领域词汇，映射出来的向量位置不可靠。我踩过的坑是在医疗术语上用了通用向量模型，召回出的片段和问题毫不相关，后来换成领域适配过的模型才解决。
2.3 流程中容易忽视的问题
很多初次搭建 RAG 的人会忽略“文档本身的更新问题”。知识库里新增了一版文档，旧版没删掉，检索时新旧内容同时命中，模型就会给出前后矛盾的答案。这个问题的解法是给每个 chunk 打上来源元数据，在召回时叠加过滤条件，只取最新版本的内容。
另一个被忽视的细节是查询文本的预处理。用户输入的问题可能包含干扰词、口语化表达，甚至错别字。直接把原始查询拿去检索，效果往往不稳。我习惯在检索前加一层查询改写，把口语问题转成结构化表述，或从 5W1H 的维度做 query 扩展。这一步不属于 RAG 标准流程，但能显着提升召回质量。
3. RAG 第三问：文本切分到底怎么切才合理？
3.1 三种切分策略的适用场景
固定长度切分最简单，按固定字符数硬切，加一点冗余重叠。这个方案对规整的书面文本有效，比如新闻报道、技术文档。但对于代码、表格、对话记录这类结构复杂的文本，固定长度会切得七零八落，语义丢失严重。
递归切分是 LangChain 里推荐的默认方式，它的逻辑是先按章节、再按段落、再按句子的优先级层层分隔，尽量让每个 chunk 保持完整语义。这个方式比固定长度聪明，但遇到没有标准结构的文本，效果也会打折。
语义切分是更高级的方案，用 Embedding 模型的语义变化来识别切分点，比如检测到话题转折时切一刀。这种方式质量最高，但计算成本也高，不适合海量文档的初次索引。实践中我一般在核心业务数据上用语义切分，对辅助性资料用递归切分，成本和效果找平衡。
3.2 不同文档类型的处理细节
不同格式的文档要有不同的处理方式。Markdown 或结构化 HTML 可以按标题层级切，人为维护好标题的情况下，切出来的 chunk 天然干净，层级关系清晰。PDF 要区分文本型 PDF 和扫描件，扫描件先过 OCR，OCR 质量差会导致切出来的内容乱码，检索自然全崩。
表格类内容最麻烦。把整个表格塞进一个 chunk，向量化时可能因为维度太大被稀释，把表格转成键值对描述再入库，检索效果更稳。比如一个“产品型号-价格-库存”的表格，转成“型号 X 的价格是 Y，当前库存为 Z”这样的自然语言描述。
还有一点值得注意：文档里的图片和图表。RAG 主链路对图片无能为力，要么用多模态模型抽取图片的文字信息，要么放弃图片内容。我在处理某技术手册时，把流程图里的关键步骤单独转成文本段落，效果比直接丢原文好得多。
3.3 切分参数和检索质量的关联
切分参数和检索质量的关系可以用一个简单实验说明。同一份文档，用 chunk_size=256 和 1024 分别建索引，对同一组测试问题跑召回率。256 的情况精确率偏高但召回率低，因为每个片段信息量太少，一个完整答案被拆到两个 chunk 里，任何一个单独拿出来都不够用；1024 的情况正好相反，片段大，信息全，但噪声多，相似度被无关内容稀释。
这就是为什么要在切分时考虑下游“使用方式”。如果你预期用户问的是短问题、单一知识点，小 chunk 合适；如果预期是综述性、多论点的问题，大 chunk 加召回后重排更合适。一个成熟的项目通常准备两套参数，根据查询类型做路由，而不是一套参数打天下。
4. RAG 第四问：向量检索不够用，混合检索和重排怎么落地？
4.1 纯向量检索的局限
面试时常见的问题是“向量检索看起来很完美，为什么还要混合检索？”答案在于向量检索的失效模式。向量模型擅长找语义相近的内容，但面对精确匹配场景会失手：一个产品的编号、一个法律条文编号、一个生僻的专业术语，这些文本往往没有充分的语义上下文，Embedding 模型对它们的映射并不稳定，常常召不回来。
我处理过一个事故：用户问“XX 型号的功率是多少”，向量检索召回的是“XX 型号的尺寸和重量”，因为“功率”这个词的向量和“尺寸”在一段描述里距离更近，纯向量检索就这么跑偏了。换成“BM25 精确匹配 + 向量语义召回”的混合模式后，这个问题立刻解决。
4.2 混合检索的权重设计
混合检索的关键是三件事：用哪些检索器、怎么融合分数、TopK 怎么分配。常见的组合是 BM25 稀疏检索器加 Dense Vector 稠密检索器。BM25 擅长精确词匹配，Dense 擅长语义泛化，两者互补。
分数融合有两种思路。一种是加权求和：final_score = a * bm25_score + (1-a) * vector_score，通过实验调 a 的取值，一般从 0.3 到 0.5 之间起步。另一种是 RRF（Reciprocal Rank Fusion），先对两种检索结果分别排名，再按排名倒数加权融合，不需要统一分数的分布区间，更加鲁棒。
我项目里用的是 RRF 方案，因为 BM25 的分值和余弦相似度的数值范围不一致，直接加权求和需要做归一化，否则权重不好调；RRF 只关心名次，省了这一层麻烦。
4.3 重排序的必要性与实现
混合检索完事了吗？还没有。检索阶段拿到的可能是 20 到 50 个候选结果，真正用户需要的只有前几个。召回阶段的排序基于的是向量相似度或词频统计，这个排序不是“对回答问题最有帮助的顺序”，必须用重排序模型重新打分。
重排序模型有两种做法。一种是拿大模型当 reranker，把候选段落和问题拼接后让模型打分，效果好但速度慢，适合离线评测。另一种是用专门的交叉编码器模型，比双塔 Encoder 慢但精度高，比大模型快得多，适合线上实时调用。
我常用的方案是：召回 50 个候选，混合检索粗排到 20 个，再用交叉编码器精排到 Top 5，最后把 Top 5 拼进 prompt。这个链路在效果和延迟之间比较均衡。面试中如果能把这个漏斗式的设计讲清楚，基本能证明真正做过 RAG 系统。
5. RAG 第五问：怎么评测 RAG 系统好不好用？
5.1 关键评测指标
RAG 系统的评测不是简单看“答得对不对”，而是要拆成多个维度来看。业界常用 Ragas 框架，以及各种自建指标，但核心都围绕四件事：召回完整性、上下文相关性、答案忠实性、答案相关性。
- 召回完整性（Recall）：标准答案中的要点有多少出现在被召回的上下文里。这条决定“材料给没给够”。
- 上下文相关性（Context Precision）：召回的上下文里有多少是对回答问题真正有用的。这条决定“材料里有没有掺水”。
- 答案忠实性（Faithfulness）：模型生成的答案里有多少信息能从上下文中找到依据。这条决定“模型有没有自由发挥瞎编”。
- 答案相关性（Answer Relevance）：模型生成的答案是不是针对用户的问题，而不是答非所问。
这四个指标是层层递进的。第一步看检索有没有把答案材料找回来，第二步看材料里有没有噪声，第三步看模型有没有忠实使用材料，第四步看最终答案是不是用户要的。任何一步不达标，整体效果都好不了。
5.2 评测集的构建方法
评测 RAG 最烧钱的不是指标计算，而是评测集的构建。一个合格的评测集至少要有 100 到 200 条“问题-标准答案-参考文档”三元组。
构建方式有三条路径。一是从业务日志里捞真实的高频问题，让标注人员基于内部文档写标准答案，这是最贴近实际场景的方式。二是从文档反推，抽取关键段落，让人工基于段落内容设计问题，这种方式能快速铺量，但问题类型容易单调。三是大模型辅助生成候选问题，再由人工筛选修正，效率最高，但需要人工兜底防幻觉问题。
我提一个容易踩的坑：评测集不能只覆盖“知识库内有标准答案”的问题。还要加入“知识库中无答案”的问题，用来测试系统会不会硬答。一个只追求召回率的 RAG，往往在无解问题上也硬凑答案，这才是上线后被投诉的元凶。
5.3 自动化评测和人工评测的配合
业内比较认同的自动化指标计算方式是使用大模型作为裁判，但要用严格设计的评分 prompt，让裁判模型先抽取“答案中的关键断言”，再逐条验证这些断言是否在上下文中有依据。这个过程能算出忠实的量化分数。
自动化评测可以做批量回归，把系统每次改动后的指标变化记录下来，防止优化 A 问题却搞坏 B 问题。但自动化评测也有盲区，比如答案的风格、条理性、专业术语的使用是否得体，这些自动化指标很难捕捉。
我的实践是用一个轻量级标注平台，挑 50 条评测集做每周人工回归，看每一轮生成的完整对话过程，记录失败模式。人工评测的结论往往能反过来指导自动化指标的权重调整，比如发现“答案相关但语气生硬”是高频差评，就会在自动化指标里加重对冗余表达的惩罚。
6. RAG 第六问：线上优化策略都有哪些方向？
6.1 面向查询侧的优化
线上优化从查询侧开始，因为查询质量决定检索上限。Query 改写是常见手段：用户问“这个怎么退？”，需要改写成“这款产品的退款流程是什么”，检索效果立刻不一样。实现改写可以用一个小模型，也可以用通用大模型做指令扩写，控制在几十毫秒级别。
查询路由是另一种思路。一个知识库里可能有法务文档、HR 政策、技术手册，全部放进同一个索引，检索时互相干扰。路由层根据用户问题先判断属于哪个分类，再路由到对应的子索引，最后只在一个子集里检索。这个方案的效果提升非常明显，相当于把大检索空间拆成了几个小检索空间，每个空间里的内容更内聚。
6.2 面向索引侧的优化
索引侧优化先讲多路召回。前面讲的混合检索本身就是在索引侧做文章。更进一步的方案是：对同一批文档用多个不同特性的 Embedding 模型都做一次索引，检索时在各路索引里分别找候选，再做融合。不同模型对语义的敏感度不同，多路召回可以降低单一模型的偏差。
索引侧的另一个容易被忽视的点是增量更新。业务文档每天都在变，每次全量重建索引成本太高，不更新又会让新内容“看不见”。解决思路是建立增量队列，新文档先进入一个独立的“热索引”，和全量索引并行检索，再定期把热索引合并进全量索引。这个方案在数据达到一定规模后是必需品。
6.3 缓存与工程级优化
RAG 系统上线后，大量重复查询的比例很高。给检索结果和生成结果都加一层缓存，能省掉大量重复计算。缓存键不只是用户的原始问题，还应该包含查询改写后的结果和召回结果摘要，确保内容变化后不会命中旧缓存。
工程层面还有几个细节值得注意。召回结果的扫描要限制在确定的 Top 范围内，避免每次把整个向量库都扫一遍。生成阶段要设置合理的最大 token 数，防止长答案把延迟拉爆。检索超时要有兜底策略，比如超时后降级为纯模型回答，保证用户请求不会失败。这些点单独拿出来都很小，但在高并发场景里决定了系统能不能扛住线上压力。
6.4 排查 RAG 效果差的系统化思路
最后补一个排查清单，当 RAG 效果差时按顺序检查：“查询改写是否正确”是第一步，很多问题在入口就偏了；“索引里有没有正确答案”是第二步，数据缺失再好的检索也没用；然后依次检查召回候选里有没有正确答案，排序是否把正确答案排到了末尾，重排有没有把它重新捞回来，prompt 构造时上下文有没有被截断，最终模型是不是被噪声信息干扰。
这个排查路径本质上是在定位“问题的瓶颈到底出在哪一环”。RAG 链路长，任何一个环节都可能出问题，排查时切忌一上来就调模型参数。我见过很多团队花两周调 Embedding 模型，最后发现是文档解析阶段没把扫描件转成可检索文本，纯属无用功。
从实际经验来说，RAG 的核心难点不在“搭建”，而在“诊断”。能快速定位链路里的薄弱环节，懂每个环节的参数对最终效果的影响趋势，遇到问题有系统化的排查思路，这比背熟几个框架用法更有价值。面试时把你的排查思路讲清楚，通常比讲原理更能让面试官认可。
