1. RAG 面试为什么成了技术岗的“必考题”RAG检索增强生成这两年从论文里的一个概念变成了招聘市场上实打实的硬通货。你去看现在的大模型应用岗位不管是做对话系统、知识库问答、智能客服还是做企业级搜索JD 里几乎都会写一条“熟悉 RAG 架构有检索优化经验优先”。面试官也不傻他们知道微调成本高、周期长而 RAG 是能快速落地、能解释、能迭代的方案所以面试里问得特别细。我前阵子帮几个朋友做模拟面试发现一个很普遍的问题很多人能说出“RAG 就是先检索再生成”但一问到“检索器怎么选”“召回率上不去怎么办”“幻觉怎么压”“多路召回怎么融合”就开始含糊了。这恰恰是面试官区分“用过”和“懂”的分水岭。这篇文章我打算把 RAG 面试里最高频的六个问题拆开讲从原理到优化从选型到踩坑尽量还原真实面试的追问逻辑。不管你是准备跳槽还是刚接手一个知识库项目这些内容都能直接拿去用。先说一下这六个问题的来源。它们不是我从某一份面经里抄的而是我过去两年参与面试、被面试、以及和同行交流时反复出现的核心考点。我把它归纳成一条线原理理解 → 检索优化 → 生成控制 → 评估迭代。这条线走下来基本能覆盖一个 RAG 岗位 80% 的技术追问。下面逐个展开。2. 第一问RAG 的基本流程和核心组件到底是什么2.1 别只背“检索生成”要讲清楚数据流面试官问“介绍一下 RAG”很多人张口就是“检索增强生成先检索相关文档再让大模型生成答案”。这句话没错但太薄了。面试官想听的是你对数据流的理解。一个完整的 RAG 系统至少包含四个阶段索引、检索、增强、生成。索引阶段要把原始文档切块、向量化、存进向量库检索阶段要根据用户 query 去向量库里找 top-k 相似块增强阶段要把检索结果和原始问题拼成 prompt生成阶段才是大模型输出答案。我一般会用一个类比来解释RAG 就像开卷考试。索引是把教材拆成小卡片放进抽屉检索是根据题目去抽屉里找相关卡片增强是把卡片内容抄到答题纸上生成是结合卡片和题目写出答案。这个类比面试官一听就懂而且能自然引出后面的优化点——卡片切得好不好、抽屉找得准不准、抄的时候有没有抄错、写答案时有没有被卡片带偏。2.2 核心组件拆解每个环节都有坑具体到组件索引阶段的核心是文档切分策略和嵌入模型选择。切分不是随便按 500 字一刀切要考虑语义完整性。我见过一个项目把技术文档按固定长度切结果一个函数的定义和它的参数说明被切到两个块里检索时只召回一半生成答案自然缺胳膊少腿。嵌入模型的选择也很关键中文场景下有些通用模型对专业术语的区分度不够比如“召回率”和“准确率”在向量空间里离得很近检索时容易混。检索阶段的核心是相似度度量和top-k 策略。余弦相似度是最常用的但也不是万能。如果向量没有归一化点积和余弦的结果会不一样。top-k 的 k 值也不是拍脑袋定的k 太小召回不足k 太大噪声多还会撑爆 prompt 长度。我通常建议从 k5 开始调结合评估指标再微调。增强阶段最容易被忽视的是prompt 模板设计。检索结果怎么塞进 prompt塞多少要不要加指令让模型“只根据检索内容回答”这些都会影响最终效果。生成阶段则要关注模型选型和温度参数。温度太高答案发散温度太低答案死板。知识库问答场景我一般建议温度设在 0.1 到 0.3 之间。注意面试时如果只讲流程不讲组件面试官会觉得你停留在概念层如果只讲组件不讲数据流又会显得零散。最好的方式是先画一条数据流再在每个节点上点出关键组件和常见问题。3. 第二问检索效果差召回率上不去怎么排查3.1 先定位是“索引问题”还是“检索问题”召回率上不去很多人第一反应是换嵌入模型。但根据我的经验七成以上的召回问题出在索引阶段而不是检索阶段。所以排查顺序应该是先看文档切分再看嵌入质量最后才看检索策略。怎么判断你可以拿一批已知答案的问题手动去看向量库里有没有包含答案的块。如果没有那就是索引阶段就没把答案切进去换什么检索器都没用。文档切分常见的问题有三个切得太碎、切得太粗、切断了语义。切得太碎一个块只有一两句话向量表达的信息量不足检索时区分度低切得太粗一个块上千字里面混了好几个主题向量被平均了反而匹配不准。切断语义是最隐蔽的比如把“步骤如下”和具体步骤切开检索到“步骤如下”这个块模型根本不知道步骤是什么。3.2 嵌入模型的选型和微调如果索引没问题那就要看嵌入模型。通用嵌入模型在垂直领域往往不够用因为它的训练数据里专业术语的分布和你的业务数据不一样。这时候有两个方向一是换一个在相关领域表现更好的模型二是用业务数据做微调。微调嵌入模型需要构造正负样本对正样本是问题和它对应的答案块负样本是问题和无关块。这个工作量大但效果通常比换模型更明显。还有一个容易被忽略的点是查询改写。用户的原始 query 往往很短、很口语直接拿去检索效果不好。可以先让大模型把 query 改写成更规范的检索语句或者生成多个相关查询做多路召回。我实测下来查询改写对召回率的提升有时候比换模型还大而且成本低得多。3.3 混合检索向量不是唯一的路纯向量检索有个天然缺陷它对关键词精确匹配不敏感。比如用户问“XX 型号的额定功率是多少”向量检索可能召回一堆讲功率的文档但就是漏掉那个具体型号。这时候需要引入关键词检索比如 BM25和向量检索做混合。混合的方式有两种一种是并行召回后融合排序另一种是先关键词过滤再向量排序。融合排序常用的算法是 RRF倒数排名融合它不依赖分数归一化实现简单效果稳定。排查方向常见症状优先动作文档切分答案块不在库里调整切分粒度按语义切嵌入模型相似问题召回不一致换领域模型或微调查询表达短 query 召回差加查询改写或多路召回检索策略关键词漏召回引入 BM25 做混合实操心得排查召回问题时先别急着调参。拿 20 个 bad case手动看每个 case 的检索结果归类是切分问题、嵌入问题还是策略问题。这个动作花不了半小时但能省掉你盲目试错的一整天。4. 第三问检索到了但答案不对幻觉怎么压4.1 幻觉的来源不止一个很多人把幻觉归咎于大模型“胡说”但在 RAG 场景里幻觉的来源至少有三个检索内容本身有噪声、prompt 没有约束、模型过度依赖自身知识。检索内容有噪声比如召回了相关但不完全匹配的块模型会强行把这些块拼成一个答案结果就是似是而非。prompt 没有约束模型可能忽略检索内容直接用自己的参数知识回答。模型过度依赖自身知识在检索内容不充分时它会“脑补”缺失部分。所以压幻觉不能只靠一句“请根据以下内容回答”。我通常会在 prompt 里加三层约束第一层是角色约束告诉模型它是一个严谨的知识库助手第二层是内容约束明确“只使用提供的资料不要引入外部知识”第三层是格式约束要求模型在答案里标注引用来源比如“根据资料 1”。标注引用这个动作很关键它强迫模型去核对检索内容而不是自由发挥。4.2 检索质量决定生成质量的上限有一句话我经常在团队里说检索是上限生成是下限。检索内容不对prompt 写得再好也救不回来。所以压幻觉的第一步永远是提升检索精度。除了前面说的混合检索还可以加重排序。向量检索召回 top-20然后用一个交叉编码器对这 20 个块重新打分取 top-5 送给模型。交叉编码器比向量相似度更准因为它能同时看 query 和文档的交互信息但计算量大所以只适合做精排。另一个技巧是设置相关性阈值。如果检索结果的相似度分数低于某个阈值就判定为“没有找到相关资料”让模型直接回答“根据现有资料无法回答”。这个动作看起来简单但能挡掉大量幻觉。我见过一个项目加了阈值过滤之后幻觉率直接降了一半。4.3 生成阶段的参数和策略生成阶段能调的参数不多但每个都关键。温度前面说了知识问答建议 0.1 到 0.3。top-p可以设在 0.9 左右保持一定的多样性但又不至于发散。最大生成长度要限制防止模型长篇大论跑偏。还有一个策略是分步生成先让模型判断检索内容是否足够回答问题如果不够就直接说不够如果够再生成答案。这个两步走的方式比一步到位更稳。注意不要指望一个 prompt 解决所有幻觉。幻觉是系统性问题需要检索、排序、prompt、参数四层一起发力。面试时如果你能说出“检索是上限生成是下限”这句话面试官会知道你是有实战经验的。5. 第四问多路召回和融合排序怎么设计5.1 为什么要多路召回单路召回有个根本矛盾召回率和精度难以兼得。向量检索擅长语义匹配但对关键词不敏感BM25 擅长关键词匹配但不懂语义。如果只用一路要么漏召回要么噪声多。多路召回的思路是让不同检索器各自召回一批结果然后融合排序取长补短。常见的组合是向量加 BM25进阶一点可以加知识图谱检索或规则检索。多路召回的关键不是“路越多越好”而是每路要有差异化。如果两路检索器的结果高度重叠那加了一路等于没加还增加了计算成本。所以设计多路召回时要先分析每路的召回特点确保它们覆盖不同的 query 类型。比如向量检索覆盖语义类问题BM25 覆盖专有名词类问题规则检索覆盖结构化查询。5.2 融合排序的三种主流方案融合排序我用过三种方案各有适用场景。第一种是加权分数融合把每路的相似度分数归一化后加权求和。这个方案简单但归一化方式对结果影响很大不同检索器的分数分布不一样归一化不好反而会拖累效果。第二种是RRF 倒数排名融合不看分数只看排名每路召回的第 n 名得 1/(kn) 分k 通常取 60。这个方案不依赖分数归一化鲁棒性强是我最常用的。第三种是交叉编码器精排把多路召回的结果合并后用交叉编码器统一打分。这个方案效果最好但计算成本最高适合对精度要求极高的场景。融合方案优点缺点适用场景加权分数融合实现简单依赖归一化各路分数分布接近RRF鲁棒性强丢失分数信息通用场景首选交叉编码器精排精度最高计算成本高高精度要求5.3 去重和截断的细节多路召回后一定要做去重。不同检索器可能召回同一个块如果不去重这个块在融合排序里会被重复计分导致它被过度加权。去重可以用文档 ID 或内容哈希。去重之后是截断根据 prompt 长度限制和模型上下文窗口决定最终送几个块给模型。我一般会留 20% 的余量防止 prompt 超长被截断。实操心得RRF 的 k 值不是固定的可以根据你的召回数量调整。召回数量多的时候k 可以设大一点让排名靠后的结果也有机会召回数量少的时候k 设小一点突出头部结果。我一般从 60 开始试根据评估结果微调。6. 第五问RAG 的评估怎么做才靠谱6.1 评估不能只看最终答案很多人评估 RAG 只看最终答案对不对这太粗了。RAG 是个多阶段系统最终答案错可能是检索没召回也可能是召回但排序不对还可能是生成跑偏。所以评估要分层检索层看召回率和精度生成层看答案相关性和忠实度端到端看用户满意度。分层评估的好处是你能定位问题出在哪个环节而不是笼统地说“效果不好”。检索层的评估需要构造问题-答案块的标注数据。这个数据不用多一两百条就能看出趋势。召回率看的是答案块有没有被召回精度看的是召回结果里有多少是相关的。生成层的评估可以用大模型做裁判让一个强模型给答案打分维度包括相关性、忠实度、完整性。忠实度特别重要它衡量答案是否完全基于检索内容有没有编造。6.2 自动化评估和人工评估的配合全自动评估省事但不够准。全人工评估准但成本高。我的做法是自动评估做日常监控人工评估做关键节点。日常迭代时用自动评估跑一批固定测试集看指标有没有下降。版本发布前抽一批 case 做人工评估重点看边界情况和 bad case。自动评估的指标要固定不能每次换否则没法对比。还有一个技巧是构造对抗测试集。专门找那些容易出错的 query比如多跳问题、否定问题、时间敏感问题。这些 case 在常规测试集里占比低但恰恰是区分系统好坏的关键。我一般会留 20% 的测试集给对抗样本。6.3 评估指标的取舍召回率和精度往往此消彼长怎么取舍取决于业务场景。知识库问答场景我倾向于精度优先因为召回噪声会直接导致幻觉。搜索场景可以召回优先因为用户自己会筛选。忠实度和相关性也有取舍有时候答案很忠实但不够相关有时候很相关但有点自由发挥。我的经验是忠实度是底线相关性是目标。忠实度不达标相关性再高也不能用。注意评估不是一次性的要持续做。每次改切分、换模型、调 prompt都要跑一遍评估。没有评估的优化都是盲调今天调好了明天可能又坏了。7. 第六问RAG 的优化方向和未来演进7.1 从“能用”到“好用”的优化路径RAG 系统上线只是开始优化是长期的事。我一般把优化分成三个阶段第一阶段解决召回问题确保答案在库里能被找到第二阶段解决排序问题确保找到的答案排在前头第三阶段解决生成问题确保答案准确、简洁、有引用。每个阶段的优化手段不一样不要跳步。召回没解决就去调 prompt那是白费力气。进阶优化方向有几个自适应检索让模型自己判断要不要检索、检索几次迭代检索根据第一轮检索结果生成更好的查询再做第二轮图增强检索把文档之间的关系也纳入检索范围。这些方向在学术上很热但落地时要考虑成本和收益不是越复杂越好。7.2 成本、延迟和效果的三角平衡RAG 系统有个绕不开的三角成本、延迟、效果。多路召回效果好但成本高交叉编码器精排效果好但延迟高大模型生成效果好但 token 消耗大。优化不是把每个指标都拉满而是找到业务能接受的平衡点。比如客服场景延迟要求高那就不能用太重的精排内部知识库场景延迟容忍度高可以上更复杂的方案。我通常的做法是先定延迟和成本预算再在预算内最大化效果。比如延迟预算 2 秒那就把检索和排序控制在 500 毫秒内留 1.5 秒给生成。如果生成超时就降级到更小的模型或更短的 prompt。这个降级策略一定要提前设计不能等线上出问题再补。7.3 面试里怎么回答“未来演进”面试官问未来演进不是要你背论文而是看你有没有技术判断力。我的回答框架是短期看工程优化中期看架构演进长期看范式变化。短期就是把切分、检索、排序、生成每个环节做扎实中期是引入自适应检索和迭代检索让系统更智能长期是关注端到端的检索生成一体化模型减少中间环节的信息损失。这个回答既有落地性又有前瞻性面试官一般会比较认可。实操心得优化 RAG 最忌讳“一把抓”。每次只改一个变量跑评估看指标变化再决定下一步。我见过一个团队同时换了嵌入模型、改了切分策略、调了 prompt结果效果变差了根本不知道是哪个改动导致的。控制变量是优化的基本功。8. 面试之外的实战建议聊完六个问题再说几句面试之外的话。RAG 这个领域变化很快今天的最佳实践明天可能就被新方案替代。但有些东西是不变的对数据的理解、对评估的重视、对成本的敏感。我见过很多项目技术选型很先进但数据质量一塌糊涂最后效果还不如一个简单的 BM25 加规则。所以别迷信新技术先把基础打牢。另外面试时不要只回答“是什么”要多说“为什么”和“怎么选”。比如问到你为什么用 RRF 而不是加权融合你可以说因为 RRF 不依赖分数归一化鲁棒性更强而且实现简单。这种回答能体现你的思考深度。还有遇到不会的问题不要硬编可以说“这个方向我了解不多但我会从某某角度去排查”面试官更看重你的思路而不是标准答案。最后分享一个我自己的习惯每次做完一个 RAG 项目我都会整理一份 bad case 集记录每个问题的现象、原因和解决方案。这份集子既是复盘材料也是下次面试的素材库。面试官问“你遇到过什么难题”你随手就能讲出一个有细节、有排查过程、有解决结果的案例这比背任何面经都管用。
