大模型面试必考RAG：从链路拆解到检索重排与幻觉控制的工程实战追问

1. 为什么RAG成了面试里的“必考题”这两年只要简历上写了“大模型应用”“知识库问答”“智能客服”这类关键词面试官几乎一定会往RAG方向追问。原因很直接微调成本高、周期长而RAG检索增强生成能用相对低的代价把私有知识接进模型还能随时更新数据、给出引用来源。企业落地时最关心的“幻觉控制”“数据新鲜度”“成本可控”这三件事RAG都能沾上边。但真正面过几轮的人会发现面试官问RAG从来不是让你背定义。他们更想确认一件事你到底有没有亲手搭过、调过、被坑过。因为RAG看起来简单——检索、拼接、生成三步走可一旦上线召回不准、答案跑偏、延迟飙升、成本失控问题一个接一个。能把这些坑讲清楚的人才是真正做过的人。这篇内容我按面试里最高频的六个追问方向来拆从整体链路、检索环节、切分策略、重排、生成阶段控制到效果评估与优化。每一块我都会先讲清楚“面试官到底想听什么”再补上“实际做的时候该怎么做”最后给一些我踩过的坑和应对思路。适合正在准备大模型岗位面试的朋友也适合刚接手RAG项目、想少走弯路的同学。提示下面所有案例和项目均为虚构代称仅用于说明技术思路不涉及任何真实机构或项目。2. 第一问完整讲一下RAG的链路别只背三步2.1 面试官想确认的是“你有没有全局观”很多人一上来就说“检索文档、拼进prompt、让模型回答”。这话没错但太粗。面试官接着就会问文档从哪来怎么存检索靠什么检索完直接拼吗拼多少模型答完怎么保证没瞎编这一串问题下来只背三步的人立刻就露馅了。我习惯把RAG拆成两条链路来讲离线索引链路和在线查询链路。离线链路负责把原始文档变成可检索的向量和索引在线链路负责把用户问题变成最终答案。两条链路分开讲面试官会觉得你脑子里有工程结构而不是只会调API。离线索引链路大致是数据采集 → 清洗解析 → 文本切分 → 向量化 → 存入向量库同时可能还要建关键词索引做混合检索。在线查询链路是用户提问 → 查询改写/扩展 → 检索召回 → 重排 → 上下文组装 → 生成 → 后处理与引用标注。这两条链路里任何一环出问题最终答案都会崩。2.2 每一步的“隐藏考点”面试官在听你讲链路时其实在偷偷打分。比如你说“文本切分”他会想你知道固定长度切分和语义切分的区别吗你说“向量化”他会想你知道embedding模型选型要考虑维度、语言、领域吗你说“检索”他会想你知道稠密检索和稀疏检索各自的短板吗我一般会这样回答先给一张链路图口头描述即可然后主动点出每个环节最容易出问题的地方。比如清洗解析阶段PDF里的表格、页眉页脚、多栏排版经常把文本搞乱如果不处理后面检索再准也是垃圾进垃圾出。再比如向量化阶段如果文档是中文而用了偏英文的embedding模型召回率会明显下降。主动暴露这些细节面试官会觉得你是真做过。2.3 一个容易被忽略的点索引更新很多候选人讲完链路就停了但面试官很可能会追问“你的知识库更新了怎么办全量重建还是增量更新”这个问题直接区分了“做过demo”和“做过系统”。实际项目里全量重建索引成本高、耗时长通常只适合数据量小或更新频率低的场景。更常见的做法是增量更新新文档进来单独切分、向量化、插入向量库同时给旧文档打上版本或失效标记。但增量更新会带来一致性问题——如果文档被修改旧向量怎么删如果删除失败检索时会不会召回过期内容这些都要在设计阶段想清楚。注意面试时如果被问到索引更新千万别只说“重新跑一遍”。要讲清楚更新策略、一致性保障和回滚方案这才是工程思维。3. 第二问检索召回不准你从哪些方向排查3.1 先分清是“召回不到”还是“排不上来”检索不准分两种一种是正确文档根本没被召回另一种是召回了但排在很后面被截断掉了。这两种问题的排查方向完全不同。前者要查embedding质量、切分粒度、查询表达后者要查排序策略、相似度阈值、top-k设置。我一般会先做一个离线评估准备一批“问题-正确文档”对跑一遍检索看正确文档的召回率和排名分布。如果召回率低说明检索环节有问题如果召回率高但MRR低说明排序有问题。这个评估集不用很大几十到几百条就能看出趋势。3.2 查询改写用户问的和文档写的往往不是一套词用户提问经常很口语“这个功能怎么收费”而文档里写的是“计费规则说明”。字面重叠很少纯向量检索也可能因为表达差异召回不准。这时候查询改写就派上用场了。常见做法有几种一是用大模型把用户问题改写成多个不同表述分别检索再合并结果二是做查询扩展补充同义词和相关术语三是做HyDE先让模型生成一个假设答案再用这个答案去检索。HyDE的思路很巧妙假设答案和真实文档在语义空间里更接近相当于用“文档的语言”去检索文档。但查询改写不是免费的每次改写都增加一次模型调用延迟和成本都会上升。我的经验是对延迟敏感的场景可以用轻量模型做改写或者只对短查询、模糊查询触发改写长查询和明确查询直接检索。3.3 混合检索稠密和稀疏各补各的短板纯向量检索擅长语义匹配但对专有名词、编号、代码这类精确匹配不敏感。比如用户问“错误码 E1024 怎么解决”向量检索可能召回一堆泛泛的错误处理文档而真正包含E1024的那篇反而排不上来。这时候就需要稀疏检索如BM25来兜底。混合检索的常见做法是一路稠密检索一路稀疏检索然后对两路结果做融合。融合可以用加权求和也可以用RRF倒数排名融合。RRF的好处是不需要调权重对两路分数的量纲不敏感实践里比较稳。检索方式擅长短板适用场景稠密检索语义相似、口语化提问精确匹配弱、专有名词差概念解释、开放问答稀疏检索关键词、编号、代码语义泛化差、同义词弱精确查找、术语检索混合检索兼顾两者实现复杂、需调融合大多数生产场景3.4 切分粒度太大噪声多太小上下文碎切分粒度直接影响召回质量。切得太大一个chunk里混了好几个主题向量表示被稀释检索时容易召回但不精准切得太小语义不完整检索到了也拼不出完整答案。我的经验是先按文档结构切标题、段落、列表再对超长段落做二次切分同时保留一定的重叠窗口。重叠是为了避免关键信息刚好被切在边界上。重叠比例一般10%到20%比较常见太大则冗余严重检索结果重复度高。4. 第三问重排到底解决了什么问题什么时候必须上4.1 重排的本质是“用更贵的模型做更细的排序”检索阶段通常用双塔模型问题和文档分别编码速度快但交互浅。重排阶段用交叉编码器把问题和文档拼在一起过模型能捕捉更细的语义交互但计算量大只能对少量候选做。所以典型流程是检索召回top 50到100重排后取top 3到5送给生成模型。这样既保证了召回广度又保证了送入上下文的精度。面试官如果问“为什么不能直接检索top 5”你就可以从双塔和交叉编码器的差异来解释。4.2 什么时候重排收益最大不是所有场景都值得上重排。如果检索召回本身就很准重排提升有限如果候选里噪声很多重排能明显把正确文档顶上来。我的判断标准是看检索top 10里正确文档的比例。如果正确文档经常排在5到10名重排收益大如果经常排在前2重排意义不大。另外重排模型也有领域适配问题。通用重排模型在垂直领域可能表现一般如果有标注数据微调重排模型往往比微调生成模型性价比更高。4.3 重排的延迟账要算清楚重排是典型的“用延迟换质量”。交叉编码器对每个候选都要过一次模型top 100重排可能增加几百毫秒甚至更多。线上服务如果对延迟敏感就要控制重排候选数量或者用蒸馏后的小模型做重排。我踩过的一个坑是为了追求效果把重排候选开到200结果P99延迟直接翻倍用户体验明显下降。后来改成先粗排到50再重排取5效果只掉了一点点延迟降了一半多。这个权衡一定要在面试里体现出来说明你不仅看效果也看工程约束。5. 第四问上下文组装和生成阶段怎么控制幻觉5.1 上下文不是越多越好很多人觉得检索到的东西全塞进去模型总能挑出对的。实际上上下文越长模型越容易迷失而且无关内容会干扰判断。更麻烦的是长上下文意味着更高的token成本和更长的首字延迟。我的做法是重排后只取top 3到5并且对每个chunk做长度控制。如果某个chunk特别长只保留和问题最相关的部分。另外给每个chunk加上来源标识方便生成时引用也方便出问题时追溯。5.2 提示词里必须写清楚“不知道就说不知道”RAG最怕模型拿着检索到的片段强行编答案。提示词里一定要明确只根据提供的上下文回答上下文没有的信息不要编如果不确定就说明无法回答。这句话看起来简单但能挡掉相当一部分幻觉。还可以加一些约束比如要求模型引用来源编号要求回答结构化要求先判断问题是否在知识范围内。这些约束会增加一点token消耗但换来的是可控性。5.3 生成后的校验不能省生成完不是就结束了。线上系统通常还要做后处理检查引用是否真实存在、检查答案是否和上下文矛盾、检查是否触发了敏感内容。有些团队会用另一个模型做事实一致性校验成本高但更稳。我的经验是至少要做引用校验。如果模型说“根据文档A”但文档A根本没被检索到这就是明显的问题。引用校验能快速发现这类错误也能给用户展示可点击的来源提升信任感。6. 第五问RAG的效果到底怎么评估6.1 离线评估和在线评估要分开看离线评估用标注集看召回率、MRR、答案准确率、忠实度等指标。在线评估看用户反馈、点击率、追问率、人工抽检。两者缺一不可离线评估能快速迭代在线评估能发现真实问题。面试官如果问“你怎么知道RAG变好了”只回答“感觉答案更准了”是远远不够的。要能说出具体指标和评估方法。6.2 检索指标和生成指标要拆开检索看召回率、精确率、MRR、NDCG生成看忠实度、答案相关性、完整性。拆开的好处是能定位问题如果检索指标好但生成指标差问题在生成阶段如果检索指标就差后面再优化生成也没用。我一般会建一个评估流水线固定一批问题每次改动后自动跑检索和生成评估对比指标变化。这样能避免“改了一个地方感觉好了其实别的地方坏了”。6.3 人工评估不可替代自动指标再全也替代不了人工看。尤其是答案的流畅度、有用性、是否答非所问这些很难用自动指标完全覆盖。我的做法是每周抽一批线上问题人工看记录bad case归类后决定优化方向。提示面试时如果能讲出“我每周会看多少条bad case主要问题集中在哪几类”会比只讲指标更有说服力。7. 第六问如果让你优化你按什么优先级来7.1 先修数据再调模型RAG的问题里很大一部分根源在数据。文档解析错误、切分不合理、元数据缺失这些不修后面怎么调模型都事倍功半。我通常先做数据质量审计抽样看解析后的文本是否干净、切分后的chunk是否语义完整、元数据是否齐全。7.2 再优化检索最后动生成检索是RAG的上限。检索不到正确内容生成模型再强也变不出来。所以优化顺序一般是数据 → 切分 → 检索 → 重排 → 生成。生成阶段的优化提示词、校验通常成本低、见效快但天花板也低。7.3 成本和延迟始终是约束任何优化都不能忽略成本和延迟。增加重排、增加查询改写、增加校验都会推高延迟和费用。我的习惯是给每个优化项算一笔账提升多少指标增加多少延迟和成本值不值得。面试时能讲清楚这个权衡会显得很成熟。优化方向典型收益典型代价优先级数据清洗高一次性人力最高切分优化高需重新索引高混合检索中高实现复杂高重排中延迟增加中提示词优化中几乎无中生成后校验中延迟和成本中低8. 面试里那些“答得好但没答到点上”的瞬间面过几轮之后我发现RAG面试的难点不在于知不知道某个概念而在于能不能把概念放到工程场景里讲清楚。比如“混合检索”谁都能说两句但面试官更想听的是你什么时候决定上混合检索融合权重怎么定上了之后召回率变化多少有没有带来新的问题还有一个常见误区是过度追求“最新方法”。面试官问优化思路有人上来就讲各种前沿论文里的复杂方案但连基础的切分和检索都没调好。实际项目里把数据清洗干净、把切分做合理、把混合检索调稳就能解决大部分问题。花哨的方法往往是在基础做扎实之后才考虑的。最后分享一个我自己的习惯每次面试前我会把做过的RAG项目按“背景-方案-取舍-结果-反思”五段式整理一遍。不背稿但确保每个环节都能讲出为什么这么选、当时还有什么备选、最后效果如何。这样不管面试官从哪个角度切进来都能接得住。RAG这个方向还在快速变化但工程判断力和踩坑经验永远是面试里最值钱的部分。