最近我在帮团队面试算法工程师好几个候选人简历里都写着“熟悉 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 和扫描件扫描件先过 OCROCR 质量差会导致切出来的内容乱码检索自然全崩。表格类内容最麻烦。把整个表格塞进一个 chunk向量化时可能因为维度太大被稀释把表格转成键值对描述再入库检索效果更稳。比如一个“产品型号-价格-库存”的表格转成“型号 X 的价格是 Y当前库存为 Z”这样的自然语言描述。还有一点值得注意文档里的图片和图表。RAG 主链路对图片无能为力要么用多模态模型抽取图片的文字信息要么放弃图片内容。我在处理某技术手册时把流程图里的关键步骤单独转成文本段落效果比直接丢原文好得多。3.3 切分参数和检索质量的关联切分参数和检索质量的关系可以用一个简单实验说明。同一份文档用 chunk_size256 和 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 之间起步。另一种是 RRFReciprocal 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 的核心难点不在“搭建”而在“诊断”。能快速定位链路里的薄弱环节懂每个环节的参数对最终效果的影响趋势遇到问题有系统化的排查思路这比背熟几个框架用法更有价值。面试时把你的排查思路讲清楚通常比讲原理更能让面试官认可。