1. 为什么 RAG 成了面试的“必考题”这两年只要简历上写了“大模型应用”“知识库问答”“智能客服”这类关键词面试官几乎一定会往 RAG 上引。原因很直接微调成本高、更新慢、容易胡说而 RAG 用外挂知识库的方式把“记忆”和“推理”拆开了。企业落地时最关心的三件事——知识能实时更新、回答有据可查、成本可控——RAG 恰好都能接住。但面试里真正拉开差距的不是“你知道 RAG 是什么”而是你能不能把一条完整链路拆开讲清楚每一环的取舍。我面过也带过不少人发现很多人卡在同一个地方能把流程背下来但一问“为什么这么切块”“召回不准怎么办”“幻觉怎么压”就开始含糊。这篇就把 RAG 面试里最高频的 6 个连环追问从原理到优化一次讲透适合准备面试的同学也适合正在搭知识库、想少踩坑的开发者。先说清楚一个前提RAG 不是“向量库 大模型”这么简单。它是一条数据工程 检索 生成的复合链路任何一环掉链子最终答案都会崩。下面我按面试官最常问的顺序一层层往下拆。2. 第一问RAG 的整体链路到底怎么跑2.1 离线索引和在线检索是两条独立的线很多人一上来就讲“用户提问→向量检索→喂给大模型”这没错但漏了最关键的一半离线索引。完整的 RAG 应该分成两条线。离线侧负责“把知识变成可检索的形态”文档加载PDF、Word、网页、数据库记录统一读进来。清洗去页眉页脚、去乱码、去重复段落这一步最脏最累。切块Chunking把长文档切成合适大小的片段。向量化Embedding用嵌入模型把每个块转成向量。入库向量 原文 元数据一起写进向量库。在线侧负责“用户来了怎么答”Query 处理改写、扩展、意图识别。召回向量检索必要时加关键词检索。重排Rerank把粗召回的结果精排。组装 Prompt把 Top-K 片段塞进上下文。生成大模型基于上下文作答并附引用。面试时如果你能把“离线”和“在线”分开讲面试官基本会认为你真正落地过而不是只看过几篇科普。2.2 为什么这个拆分很重要因为两条线的优化手段完全不同。离线侧的问题通常是“切块不合理、元数据缺失”在线侧的问题通常是“召回不准、上下文太长、模型不听话”。如果你不拆开排查问题时就会一团乱麻。我见过一个团队回答质量差所有人都在调 Prompt最后发现根因是 PDF 切块把表格切碎了检索出来的片段本身就是残缺的。链路拆得清问题才定位得快这是面试里最能体现工程素养的一点。3. 第二问切块Chunking到底怎么切才合理3.1 切块是 RAG 里最被低估的一环面试官问切块其实是在考你对“语义完整性”的理解。切太大检索精度下降噪声多切太小语义不完整模型拼不出答案。常见策略有这么几种策略做法适用场景缺点固定长度按 token 数硬切结构规整的文本容易切断句子递归切分按段落→句子逐级切通用文档需调参语义切分按语义相似度断点长文、报告计算成本高结构化切分按标题/表格切手册、规范依赖文档结构我个人的经验是没有万能切法只有匹配文档类型的切法。技术文档按标题层级切客服问答按一问一答切合同按条款切。别偷懒用一套参数打天下。3.2 重叠Overlap和元数据别忽略切块时一定要留10%~20% 的重叠防止关键信息正好卡在切口上被切断。比如块大小 500 token重叠 80 token这样跨块的句子至少有一个块能完整包含。更重要的是元数据。每个块除了文本和向量还应该带上来源文件、章节标题、页码、时间戳。为什么因为后面重排、过滤、引用都要用。用户问“最新的政策是什么”你如果没有时间戳元数据根本没法按时间过滤。元数据是 RAG 从“能用”到“好用”的分水岭面试时主动提这一点加分很明显。4. 第三问向量检索召回不准怎么优化4.1 先搞清楚“不准”是哪一种不准召回问题分两类该召回的没召回漏召和召回了不相关的误召。这两类的解法完全不同面试时先分类再给方案逻辑会非常清晰。漏召的常见原因嵌入模型和领域不匹配、Query 和文档用词差异大、切块太碎。误召的常见原因向量空间里语义相近但主题无关、Top-K 设太大、缺少过滤条件。4.2 混合检索是性价比最高的优化纯向量检索对“专有名词、型号、编号”这类精确匹配很弱。比如用户问“X200 型号的参数”向量检索可能召回一堆“参数”相关但型号不对的块。这时候**混合检索Hybrid Search**就派上用场了向量检索负责语义关键词检索如 BM25负责精确匹配两路结果融合。融合常用RRFReciprocal Rank Fusion它不依赖分数归一化只看排名实现简单又稳def rrf_fusion(vector_results, keyword_results, k60): scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) for rank, doc in enumerate(keyword_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)实测下来混合检索在专有名词密集的场景里召回率能比纯向量提升一大截。这是我认为投入产出比最高的一招面试时能讲清楚 RRF 的原理基本就稳了。4.3 Query 改写和扩展用户的问题往往很短、很口语直接拿去检索效果差。可以在检索前做Query 改写把“这个咋弄”改写成“XX 功能的操作步骤”。也可以用多查询扩展让模型生成几个同义问法分别检索再合并提升召回覆盖面。代价是延迟增加所以要权衡。5. 第四问重排Rerank为什么不能省5.1 召回和精排是两回事向量检索是“粗筛”它快但精度有限。Rerank 是“精排”用一个更强的交叉编码器Cross-Encoder把 Query 和每个候选块一起打分精度高但慢。所以标准做法是向量检索召回 Top-50Rerank 精排出 Top-5再喂给大模型。为什么不能直接用向量检索的 Top-5因为向量检索是双塔结构Query 和文档分别编码交互发生在最后一步信息损失大。而 Cross-Encoder 让 Query 和文档在编码阶段就充分交互判断更准。这是精度和速度的经典权衡面试时能讲清双塔和交叉编码器的区别说明你懂底层。5.2 Rerank 的实操注意点候选数量要够召回 20 个去重排和召回 100 个去重排效果差很多。一般 50~100 起步。延迟要评估Rerank 是串行的候选越多越慢线上要压到可接受范围。别用生成模型做重排让大模型逐个打分太慢太贵专用 Rerank 模型才是正解。我踩过的坑是一开始省掉 Rerank觉得向量分数够用结果回答经常“答非所问”。加上 Rerank 后同样的知识库答案准确率肉眼可见地提升。如果你的 RAG 效果卡在瓶颈先别急着换大模型加个 Rerank 试试。6. 第五问上下文塞不下、模型不听话怎么办6.1 上下文窗口不是越大越好很多人以为“把 Top-20 全塞进去模型总能找到答案”。实际上上下文越长模型越容易迷失Lost in the Middle——关键信息在中间位置时模型反而容易忽略。而且长上下文成本高、延迟大。正确做法是精挑细选Rerank 后取 Top-3 到 Top-5保证每个块都高度相关。如果确实需要更多信息可以做上下文压缩把每个块里和 Query 无关的句子删掉只留核心内容。6.2 让模型“有据可查、无据不答”幻觉是 RAG 面试的必问点。压制幻觉的核心是Prompt 约束 引用机制。Prompt 里要明确写只根据提供的资料回答资料中没有的内容直接说“根据现有资料无法回答”不要编造。同时要求模型标注引用来源比如“根据《XX 文档》第 3 节……”。这样既方便用户核实也能倒逼模型基于事实作答。还有一个技巧给模型“拒答”的出口。很多幻觉是因为模型被逼着必须回答。你给它一个体面的拒答方式它反而更老实。实测下来加了拒答约束后编造答案的比例明显下降。7. 第六问怎么评估和持续优化 RAG 效果7.1 没有评估就没有优化面试官问评估是想看你有没有“闭环思维”。RAG 评估要分检索和生成两层检索层召回率、命中率、MRR平均倒数排名。生成层答案相关性、忠实度是否忠于原文、完整性。忠实度尤其重要它衡量的是“答案有没有超出检索到的内容”是幻觉的量化指标。7.2 评估数据集怎么来最实用的是人工构造一批“问题-标准答案-相关文档”三元组覆盖高频问题和边界情况。规模不用大几十到几百条就能看出问题。然后每次改动换切块、加 Rerank、改 Prompt都跑一遍对比指标。没有这套基准你的优化就是盲调。7.3 常见问题速查表现象可能原因排查方向答非所问召回不准检查切块、加混合检索答案残缺切块太碎增大块或加重叠编造内容上下文不足或 Prompt 松加拒答约束、查召回回答慢上下文太长减 Top-K、加压缩专有名词错纯向量检索上混合检索这张表我建议直接背下来面试时遇到“你怎么排查”这类问题按表走一遍条理非常清楚。8. 面试里真正加分的几个细节前面六问是主干但真正让面试官记住你的往往是这些细节。第一主动提成本。RAG 不是免费的嵌入、检索、重排、生成每一步都有成本。能说清楚“什么场景用大模型、什么场景用小模型、什么场景直接走检索不生成”说明你有工程视角。第二提缓存。高频问题可以缓存答案相同 Query 直接返回省下整条链路。这是线上系统的常规操作但很多人面试时想不到。第三提安全。知识库可能包含敏感信息检索时要按用户权限过滤。元数据里带上权限标签检索时加过滤条件这是企业级 RAG 的必备能力。第四承认取舍。没有完美的 RAG只有匹配场景的 RAG。面试时能说“这个方案在我这个场景下更合适因为……”比背标准答案强得多。9. 我踩过的几个真实坑最后分享几个我自己落地时踩过的坑都是文档里不会写的。坑一嵌入模型换了向量库没重建。换了嵌入模型后新旧向量不在同一空间检索直接崩。记住换嵌入模型必须全量重建索引。坑二PDF 里的表格被切碎。通用切块对表格很不友好后来改成表格单独提取、单独成块效果才正常。坑三Top-K 设太大反而更差。一开始觉得召回越多越好结果噪声把模型带偏。后来老老实实加 Rerank、减 Top-K答案质量反而上去了。坑四忽略 Query 的语言和文档不一致。用户用中文问文档是英文跨语言检索效果差。要么用多语言嵌入模型要么先翻译 Query。这些坑的共同点是问题都不在模型而在数据和链路。RAG 的功夫八成在检索之前。如果你正在准备面试我的建议是别只背流程找一个小知识库亲手搭一遍把切块、检索、重排、评估都跑通。跑通一遍上面这 6 连问你自己就能答得比标准答案还漂亮。