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）负责精确匹配，两路结果融合。
融合常用RRF（Reciprocal Rank Fusion），它不依赖分数归一化，只看排名，实现简单又稳：
def rrf_fusion(vector_results, keyword_results, k=60): 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(), key=lambda x: x[1], reverse=True)实测下来，混合检索在专有名词密集的场景里，召回率能比纯向量提升一大截。这是我认为投入产出比最高的一招，面试时能讲清楚 RRF 的原理，基本就稳了。
4.3 Query 改写和扩展
用户的问题往往很短、很口语，直接拿去检索效果差。可以在检索前做Query 改写：把“这个咋弄”改写成“XX 功能的操作步骤”。也可以用多查询扩展，让模型生成几个同义问法，分别检索再合并，提升召回覆盖面。代价是延迟增加，所以要权衡。
5. 第四问：重排（Rerank）为什么不能省
5.1 召回和精排是两回事
向量检索是“粗筛”，它快，但精度有限。Rerank 是“精排”，用一个更强的交叉编码器（Cross-Encoder）把 Query 和每个候选块一起打分，精度高但慢。所以标准做法是：向量检索召回 Top-50，Rerank 精排出 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 连问你自己就能答得比标准答案还漂亮。
