RAG面试高频六问：从原理到线上排查的实战解析

RAG 这两年从论文里的概念一路杀进生产环境，现在几乎成了大模型应用岗位面试的必考区。我前后参与过几轮团队招聘，也帮朋友做过模拟面试，发现一个很普遍的现象：很多人能把 RAG 的流程背得滚瓜烂熟，但一问到“为什么这么设计”“线上出问题怎么排查”，立刻就卡壳了。这篇文章我打算把 RAG 面试里最高频的六个问题拆开讲透，从最基础的原理，到检索优化、重排、评估、幻觉治理，再到线上排查，全部覆盖。不管你是准备面试的候选人，还是正在搭 RAG 系统的工程师，都能从里面找到能直接用的东西。我会尽量用大白话把每个技术选择背后的“为什么”讲清楚，而不是只丢结论。

1. 先搞清楚 RAG 到底解决了什么问题

1.1 大模型的三个硬伤和 RAG 的定位

要理解 RAG，得先理解它为什么会出现。大模型本身有三个绕不过去的硬伤：第一，知识有截止日期，训练完之后新发生的事情它不知道；第二，私有数据它没见过，你公司内部的文档、工单、产品手册，它一概不知；第三，它会一本正经地胡说八道，也就是幻觉。这三个问题如果靠重新训练或者微调来解决，成本高得离谱，而且数据一更新就得重来。

RAG 的思路其实特别朴素：既然模型不知道，那我就在它回答问题之前，先把相关资料找出来塞给它，让它“开卷考试”。这个思路听起来简单，但真正落地的时候，难点全在“怎么找得准”和“怎么塞得对”上。面试官问 RAG 原理，其实不是想听你背“检索增强生成”这五个字，而是想看你能不能把这条链路上的每个环节讲明白。

一个完整的 RAG 流程可以拆成两大阶段。离线阶段做的是知识库构建：把各种格式的文档解析出来，切成合适大小的块，用嵌入模型转成向量，存进向量数据库。在线阶段做的是查询响应：用户提问后，把问题也转成向量，去数据库里找最相似的若干块，拼进提示词，交给大模型生成答案。这两段里，离线阶段决定了知识库的质量上限，在线阶段决定了实际体验的下限。

提示：面试时如果只讲在线阶段，很容易被追问“那你的知识库是怎么建的”。离线构建的质量往往才是 RAG 效果的天花板，这一点一定要主动提。

1.2 为什么是“检索 + 生成”而不是纯生成或纯检索

有人会问，既然检索这么麻烦，为什么不直接微调模型让它记住？或者干脆只做检索，把原文返回给用户？这两个方案我都实际试过，各有各的死穴。

纯微调的问题是，知识更新成本极高。你每加一批新文档就得重新训练一轮，而且微调后的模型依然可能幻觉，因为它本质还是在“凭记忆答题”。更麻烦的是，微调容易让模型在通用能力上退化，也就是所谓的灾难性遗忘。而纯检索的问题是，用户拿到一堆文档片段还得自己读、自己拼，体验很差，尤其是需要归纳总结、多跳推理的问题，检索本身给不出答案。

RAG 的价值就在于它把两者的优势拼在了一起：检索负责“事实准确”，生成负责“表达流畅”。模型不需要记住所有知识，它只需要学会“根据给定的材料回答问题”。这样一来，知识更新只需要更新向量库，成本从“训练”降到了“写库”，这是数量级的差别。

1.3 一个最小可用的 RAG 链路长什么样

为了后面讲优化有个基准，我先把一个最小可用的 RAG 链路列出来。这个版本能跑通，但效果一般，后面所有的优化都是在这个基础上做加法。

# 离线：构建知识库 chunks = split_documents(raw_docs, chunk_size=500, overlap=50) vectors = embed_model.encode(chunks) vector_db.add(vectors, chunks) # 在线：查询响应 query_vec = embed_model.encode(user_query) top_k_chunks = vector_db.search(query_vec, top_k=5) prompt = build_prompt(user_query, top_k_chunks) answer = llm.generate(prompt)

这个链路里，chunk_size、top_k、嵌入模型的选择、提示词的写法，每一个都是可以调优的旋钮。面试里被问到的优化问题，本质上都是在问“你会拧哪个旋钮，为什么”。我见过不少人一上来就说“用重排”，但问他为什么，答不上来。重排解决的是“召回结果排序不准”的问题，如果你的召回本身就没把正确内容捞出来，重排也救不了。所以优化的顺序很重要，得先保证召回，再谈排序。

2. 文档切分：最容易被低估的环节

2.1 切分粒度为什么直接决定检索质量

文档切分是 RAG 里最不起眼、但影响最大的环节。我踩过的坑里，有一半以上跟切分有关。切分粒度太粗，一个块里混了好几个主题，检索出来噪音大，模型容易被无关内容带偏；切分太细，一个完整的语义被切碎，检索到的片段缺头少尾，模型拼不出完整答案。

举个具体的例子。假设你有一份产品手册，里面有一段讲“退款政策”，包含适用条件、流程、时限三个部分。如果你按固定 500 字硬切，很可能把“适用条件”切在一个块里，“流程和时限”切在另一个块里。用户问“退款要多久”，检索到的块只有时限没有条件，模型可能给出一个不完整的答案。这就是典型的切分破坏了语义完整性。

我的经验是，切分要尽量沿着文档的自然结构走。Markdown 按标题层级切，PDF 按段落和章节切，代码文档按函数切。固定长度切分只作为兜底方案，而且要配合重叠（overlap）来缓解边界信息丢失。重叠比例一般设在 10% 到 20% 之间，太小起不到衔接作用，太大又会引入冗余、增加检索噪音。

2.2 不同文档类型的切分策略对照

不同类型的文档，切分策略差别很大。我整理了一张对照表，这是我在多个项目里反复调整后总结出来的，可以直接参考。

这里有个细节值得展开：给每个块加上“上下文前缀”。比如一个块本身只讲“时限是 7 个工作日”，但如果你在块前面加上“本文档章节：退款政策 > 时限”，检索和生成时模型就能知道这段话的归属。这个技巧叫上下文增强，实现成本很低，但效果提升明显。我在一个客服知识库项目里加了这个前缀后，答案准确率大概提升了七八个百分点。

2.3 切分环节的实操心得与避坑

说几个我实际踩过的坑。第一个坑是“无脑按字数切”。早期我图省事，直接用RecursiveCharacterTextSplitter按 1000 字切，结果表格被切得七零八落，一个表格的数据分散在三个块里，检索出来根本没法用。后来我改成先识别文档结构，表格单独处理，问题才解决。

第二个坑是“忽略元数据”。每个块除了文本内容，还应该带上来源、页码、章节、时间等元数据。这些元数据在检索时可以用于过滤，比如用户问“2024 年的政策”，你可以先用元数据过滤出 2024 年的文档再检索。没有元数据，你就只能靠语义相似度硬扛，效果差很多。

第三个坑是“重叠设置不当”。我见过有人把 overlap 设成 50%，觉得这样信息不会丢。结果向量库里全是重复内容，检索出来的五个块有三个是重复的，白白浪费了上下文窗口。重叠的目的是衔接边界，不是复制内容，10% 到 20% 足够了。

注意：切分没有万能参数，一定要拿真实数据做小批量测试。我的做法是准备 20 到 30 个典型问题，用不同的切分参数跑一遍，看召回率和答案质量，再定参数。

3. 检索优化：从向量召回走向混合检索

3.1 纯向量检索的局限在哪里

向量检索的核心是语义相似度，它擅长处理“意思相近但用词不同”的情况。比如用户问“怎么退钱”，文档里写的是“退款流程”，向量检索能匹配上，这是它的优势。但它也有明显的短板。

第一个短板是对专有名词、型号、编号不敏感。用户问“X200 的保修期”，向量检索可能把“X100 的保修期”也召回来，因为这两个句子在语义上几乎一样，向量距离很近。但用户要的是 X200，不是 X100。这种精确匹配的需求，向量检索经常翻车。

第二个短板是对否定和限定词不敏感。“支持的功能”和“不支持的功能”，向量可能认为很相似，但意思完全相反。第三个短板是长尾查询，一些生僻的表达，嵌入模型没见过，向量表示就不准。

这些短板决定了，光靠向量检索是不够的。生产环境里，我基本都会上混合检索。

3.2 混合检索的融合策略与参数

混合检索就是把向量检索和关键词检索（比如 BM25）结合起来，各取所长。向量负责语义，关键词负责精确匹配。两者结合，召回率通常能提升一大截。

融合的方式主要有两种。一种是加权求和，给两路结果各打一个分数，按权重加起来排序。另一种是倒数排名融合（RRF），不看具体分数，只看排名，把两路排名做倒数加权。RRF 的好处是不用归一化分数，因为向量相似度和 BM25 分数的量纲完全不同，直接加权很容易出问题。

# RRF 融合示例 def rrf_fusion(vector_results, bm25_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(bm25_results): scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: x[1], reverse=True)

这里的k是个平滑参数，一般取 60。它的作用是削弱排名靠前和靠后的差距，避免某一路结果完全主导。我实测下来，RRF 比加权求和更稳，尤其是在两路检索质量参差不齐的时候。

3.3 查询改写：让检索更懂用户

用户的问题往往很口语、很模糊，直接拿去检索效果不好。查询改写就是在检索前，先把用户问题“翻译”成更适合检索的形式。常见的手法有几种。

第一种是查询扩展，把一个问题拆成多个子问题，或者生成几个同义表达，分别检索再合并。比如用户问“这个功能怎么用”，可以扩展成“功能使用方法”“功能操作步骤”“功能配置说明”几个查询。第二种是查询重写，用大模型把口语化的问题改写成更规范的检索语句。第三种是 HyDE，先让模型“假装”生成一个答案，再用这个答案去检索。因为答案的表述通常比问题更接近文档，检索效果会更好。

这几种方法我都用过，效果最好的是查询重写加多路检索。但要注意，查询改写会引入额外的模型调用，增加延迟和成本。线上系统里，我会根据查询的复杂度决定是否触发改写，简单查询直接检索，复杂查询才走改写流程。

3.4 检索环节的实操经验

分享几个检索优化的实操经验。第一，top_k不要设太小。很多人为了省上下文，只取 3 个块，结果经常漏掉关键信息。我的做法是召回阶段取大一点，比如 20 个，然后用重排精筛到 5 个。召回要宽，精排要准，这是两回事。

第二，善用元数据过滤。如果知识库有时间、部门、类型等元数据，检索时先过滤再检索，能大幅提升准确率。比如用户问“销售部的报销标准”，先用元数据过滤出销售部文档，再在里面检索，比全库检索准得多。

第三，监控召回率。线上系统一定要记录每次检索的结果，定期人工抽查，看正确内容有没有被召回。召回率是 RAG 的生命线，召回不到，后面全是白搭。

4. 重排与上下文组织：把好钢用在刀刃上

4.1 重排模型为什么能提升精度

重排（Rerank）是 RAG 里性价比最高的优化手段之一。它的原理是：召回阶段用向量或混合检索快速捞出一批候选（比如 20 到 50 个），然后用一个更精细的模型对这批候选逐一打分，重新排序，取最相关的几个。

为什么重排有效？因为召回用的向量检索是“双塔”结构，问题和文档分别编码，最后算相似度，速度快但精度有限。重排用的是“交叉编码”结构，把问题和文档拼在一起送进模型，模型能同时看到两者的交互信息，判断更准。代价是慢，所以只能用在少量候选上。

我实测过一个场景，纯向量召回 top5 的准确率大概 60%，加上重排后能到 80% 以上。这个提升非常可观，而且重排模型可以选轻量级的，延迟增加在可接受范围内。

4.2 上下文窗口的分配与压缩

检索回来的内容怎么塞进提示词，也是门学问。上下文窗口是有限的，塞太多会稀释重点，塞太少又可能漏信息。我的原则是：优先放最相关的，其次放能提供背景的，最后放补充说明的。

如果检索回来的内容太多，可以做上下文压缩。一种做法是抽取式压缩，只保留和问题最相关的句子；另一种是生成式压缩，用模型把长文档浓缩成要点。抽取式更安全，不容易引入幻觉；生成式更简洁，但有信息丢失的风险。我一般优先用抽取式，只有在内容特别冗长时才用生成式。

还有一个技巧是“重排序 + 去重”。检索回来的块之间可能有大量重复内容，去重能腾出更多空间给有效信息。我见过一个案例，top5 里有三个块内容高度重叠，去重后实际有效信息只有一个块，白白浪费了窗口。

4.3 提示词设计的关键细节

提示词是 RAG 的最后一公里，写得好不好直接影响答案质量。我总结了几条原则。

第一，明确告诉模型“只根据给定材料回答”。这句话能显著降低幻觉。第二，告诉模型“如果材料里没有答案，就说不知道”，避免它硬编。第三，给出回答的格式要求，比如分点、引用来源。第四，把材料用清晰的分隔符包起来，让模型知道哪部分是资料、哪部分是问题。

你是一个严谨的问答助手。请只根据下面提供的资料回答问题。 如果资料中没有相关信息，请直接回答“资料中未提及”，不要编造。 资料： --- {context} --- 问题：{question}

这个模板看起来简单，但每一条都有用。我对比过加和不加“只根据资料”这句话的效果，幻觉率差别很明显。

提示：提示词里的资料顺序也有讲究。把最相关的资料放在最前面或最后面，模型更容易注意到。放在中间的内容容易被忽略，这是所谓的“中间遗忘”现象。

5. RAG 的评估：怎么证明你的系统变好了

5.1 评估的两个层面：检索和生成

RAG 评估要分开看检索和生成，因为两者的指标不一样，混在一起说不清楚问题出在哪。检索层面看的是召回率、准确率、MRR 这些指标，衡量的是“该找的有没有找到”。生成层面看的是答案的忠实度、相关性、完整性，衡量的是“找到之后有没有用好”。

分开评估的好处是定位问题快。如果检索召回率低，那问题在切分或检索策略；如果召回没问题但答案不对，那问题在提示词或模型。我见过很多人一上来就调提示词，结果发现根本是召回没做好，白费功夫。

5.2 常用评估指标与自动化方案

检索指标里，最核心的是召回率（Recall@K），也就是正确文档有没有出现在前 K 个结果里。其次是 MRR（平均倒数排名），衡量正确文档排得靠不靠前。生成指标里，忠实度（Faithfulness）最重要，衡量答案有没有脱离资料编造；答案相关性（Answer Relevancy）衡量答案有没有答非所问。

自动化评估可以用一些现成的框架，它们用大模型当裁判，对每个答案打分。虽然不如人工准，但胜在快、可批量。我的做法是：日常迭代用自动评估快速筛选，重要版本上线前做一轮人工抽检。

5.3 构建评估集的实操方法

评估集是评估的基础，没有评估集，一切优化都是拍脑袋。构建评估集的方法其实不复杂：从真实用户问题里抽样，人工标注每个问题的正确答案和对应的源文档。规模不用很大，100 到 200 条就能反映问题。

我建议评估集要覆盖几类问题：简单事实查询、多跳推理、需要归纳总结的、以及知识库里没有答案的（用来测幻觉）。最后一类特别重要，很多系统在“不知道”的时候会硬编，这类问题能暴露出来。

评估集要定期更新，因为知识库在变、用户问题也在变。我一般每个季度补充一批新问题，淘汰过时的。

6. 幻觉治理与线上排查实战

6.1 RAG 幻觉的几种来源

RAG 虽然能降低幻觉，但不能完全消除。幻觉的来源主要有几种。第一种是检索没召回到正确内容，模型只能靠自己的知识硬答。第二种是召回了相关内容，但模型理解错了，或者把不同块的信息错误拼接。第三种是资料本身有矛盾，模型不知道该信哪个。第四种是提示词没约束好，模型自由发挥。

定位幻觉来源，关键是看“答案有没有资料支撑”。如果答案里的信息在检索结果里找不到，那就是模型编的；如果能找到但拼错了，那是理解问题。分清楚来源，才能对症下药。

6.2 引用溯源与答案校验

治理幻觉的一个有效手段是引用溯源，也就是让模型在回答时标注每句话来自哪个资料块。这样用户能自己核实，系统也能自动检查引用是否真实存在。实现方式是在提示词里要求模型输出引用编号，然后在后处理阶段校验编号对应的内容是否真的支持该句话。

另一个手段是答案校验，用一个独立的模型或规则检查答案和资料是否一致。比如把答案和资料一起送给模型，问“这个答案是否完全由资料支持”。不一致的就打回重生成或降级处理。

6.3 线上问题排查速查表

线上 RAG 系统出问题，排查要有章法。我整理了一张速查表，基本覆盖了常见故障。

排查的核心思路是“分段定位”。把 RAG 链路拆成解析、切分、检索、重排、生成几段，逐段看输入输出，问题出在哪段一目了然。我习惯在每段都打日志，线上出问题直接看日志，比猜快得多。

6.4 几个真实踩坑案例

说两个我印象最深的坑。第一个是“切分把答案切没了”。有个用户问某个配置项的默认值，答案在文档里就一句话，结果被切分算法切成了两半，前半句在一个块，后半句在另一个块，检索只召回了一个块，模型给出的答案缺了一半。后来我调整了切分策略，保证句子完整性，问题解决。

第二个是“重排把正确答案排掉了”。有次上线重排后，发现某些查询的效果反而变差了。排查发现，重排模型对某些领域的术语不熟，把正确答案打了低分。解决办法是换了一个在该领域表现更好的重排模型，或者对重排结果做保底，保证召回的前几名不被完全挤掉。

这两个坑说明一个道理：任何优化都要用评估集验证，不能凭感觉。优化引入的新组件，本身也可能带来新问题。

7. 面试里怎么把这些讲出彩

7.1 回答原理题的框架

面试被问 RAG 原理，别一上来就背流程。我建议的框架是：先说它解决什么问题，再说它的核心链路，最后说每个环节的关键设计。这样回答有层次，面试官能看出你理解得深。

比如被问“RAG 是什么”，可以这样组织：大模型有知识截止、私有数据缺失、幻觉三个问题，RAG 通过外挂知识库来解决。链路分离线构建和在线响应两段，离线决定上限，在线决定体验。然后挑一两个环节展开，比如切分和检索，讲讲你的取舍。这样既全面又有深度。

7.2 回答优化题的思路

被问“怎么优化 RAG”，不要罗列一堆技术名词。正确的思路是先定位瓶颈，再选手段。可以说：我会先建评估集，测出是召回问题还是生成问题。召回问题就上混合检索、查询改写；生成问题就调提示词、加重排。每个优化都要有数据支撑，不能拍脑袋。

这种回答方式体现的是工程思维，比背名词强得多。面试官想招的是能解决问题的人，不是能背文档的人。

7.3 回答排查题的套路

被问“线上效果不好怎么办”，套路是分段定位。先看检索结果对不对，再看生成答案忠不忠实，逐段排除。可以举一个具体例子，比如“我之前遇到答案不全，排查发现是切分破坏了语义，调整切分后解决”。有例子、有过程、有结果，这样的回答最有说服力。

我个人在实际面试和带人过程中的体会是，RAG 这个方向，背概念只能应付初级问题，真正拉开差距的是对细节的理解和踩坑经验。你把切分、检索、重排、评估这几块里任意一块讲透，都比泛泛而谈整个流程要加分。最后再分享一个小技巧：面试前拿一个自己熟悉的领域，从零搭一个最小 RAG 系统，把每个环节都亲手调一遍，那些参数和坑你自然就记住了，面试时也讲得出来。