RAG面试必考六大方向：从检索增强生成原理到工程优化实战

1. RAG 面试为什么成了技术岗的“必考题”

这两年做算法岗、大模型应用岗的招聘，RAG 几乎是绕不开的话题。我参与过几轮团队内的技术面试，也帮朋友做过模拟面，发现一个很明显的趋势：前两年大家还在问“Transformer 的注意力机制怎么算”，现在面试官更倾向于问“你手头这个知识库问答系统，检索召回率上不去，你从哪几个环节排查”。这个转变背后其实是一个很朴素的逻辑——大模型本身的能力已经足够强了，真正拉开工程差距的地方，在于你怎么把外部知识准确、及时、低成本地喂给它。

RAG，全称 Retrieval-Augmented Generation，检索增强生成。拆开看就是三个动作：先把用户的问题拿去检索相关资料，再把检索到的资料和问题一起塞给大模型，最后让模型基于这些资料生成回答。听起来简单，但真正落地过的人都知道，这里面每一个环节都能踩出一堆坑。检索召回不准、切片切得稀碎、重排模型选错、上下文塞太满导致模型“失忆”、生成内容胡编乱造……这些问题在面试里被问到的频率极高，因为它们直接反映了一个人有没有真正做过端到端的系统。

这篇文章我打算围绕 RAG 面试里最常被追问的六个方向展开，从最基础的原理讲起，一路聊到工程优化和线上排查。每个方向我都会先讲清楚“面试官到底想考什么”，再讲“你应该怎么答”，最后补充一些我自己的实操经验和踩坑记录。不管你是准备跳槽的算法工程师，还是刚接触 RAG 想系统梳理一遍的开发者，这篇内容应该都能帮你把知识框架搭起来。我不会堆砌论文里的公式，而是尽量用工程视角把每个环节讲透，让你在面试里能说出“人话”，也能在实际项目里直接抄作业。

2. 第一问：RAG 的基本流程和核心组件到底怎么讲

2.1 面试官想听到的不是流程图，而是你对数据流的理解

很多人被问到“介绍一下 RAG 的流程”时，会背一段标准答案：文档加载、文本切片、向量化、存入向量库、检索、重排、生成。这个回答没错，但太像教科书了，面试官听完没有任何记忆点。我建议你在回答时，把重点放在“数据在每个阶段发生了什么变化”上，而不是单纯罗列组件名称。

你可以这样组织语言：原始文档进来之后，第一步是解析和清洗，把 PDF、Word、HTML 这些格式统一转成纯文本，同时去掉页眉页脚、导航栏、广告这些噪声。第二步是切片，把长文本切成适合检索和塞进上下文的小块，这里要权衡块大小和重叠长度。第三步是向量化，用 Embedding 模型把每个文本块映射成一个高维向量，存进向量数据库。第四步是检索，用户提问时同样把问题向量化，然后在向量库里做相似度搜索，召回 Top-K 个候选块。第五步是重排，用一个更精细的模型对候选块重新打分排序，挑出最相关的几个。第六步是生成，把问题和筛选后的文本块拼成 Prompt，交给大模型输出答案。

这个回答的好处是，你不仅说了“做了什么”，还暗示了“每一步都有取舍”。面试官接下来大概率会顺着某个环节往下追问，比如“切片大小你怎么定”“重排模型为什么需要”“Top-K 怎么选”，而这些正是展示你实战经验的地方。

2.2 核心组件的选型逻辑比组件本身更重要

RAG 系统里几个关键组件，面试官几乎一定会问选型理由。我整理了一个常见的对照表，你可以根据自己的项目经验调整：

这张表里的每一行，你都要能说出“我为什么选 A 不选 B”。比如向量数据库，如果你说“因为团队之前用过”，那面试官会觉得你没有独立思考；如果你说“我们的数据量在 50 万条左右，查询 QPS 峰值不到 10，内存型方案完全扛得住，而且运维成本低”，这就是一个有说服力的回答。

2.3 一个容易被忽略的点：离线索引和在线查询是两条链路

很多候选人在描述流程时，会把离线索引和在线查询混在一起讲，这是一个减分项。实际上，RAG 系统在工程上必须拆成两条独立的链路：离线链路负责文档解析、切片、向量化、入库，通常用批处理任务跑，关注的是吞吐和稳定性；在线链路负责查询向量化、检索、重排、生成，关注的是延迟和并发。

面试官如果问你“系统怎么部署”，你要能说清楚这两条链路的资源隔离和调度方式。比如离线任务可以放在夜间低峰期跑，用队列控制并发；在线服务要保证 P99 延迟在可接受范围内，检索和生成阶段可以分别做超时控制和降级策略。这种工程视角的回答，比单纯讲算法细节更能体现你的落地能力。

3. 第二问：文档切片策略，切多大切多小有讲究

3.1 切片不是越细越好，也不是越粗越好

切片是 RAG 里最容易被低估的环节。很多人觉得这就是个预处理步骤，随便按固定长度切一刀就完事了。但实际项目中，切片策略直接决定了检索的上限——如果切片切得不好，后面的重排和生成再强也救不回来。

我见过一个典型的反面案例：某团队做法律文书问答，把每份判决书按 500 字固定长度切片，结果一个完整的法律条款被切成了三段，检索时只召回了其中一段，模型拿到残缺的条款后给出了错误解释。后来改成按段落和条款结构切片，召回准确率直接提升了二十多个百分点。

切片的核心矛盾在于：块太小，语义不完整，检索时容易断章取义；块太大，噪声多，向量表示被稀释，检索精度下降，而且塞进上下文时占用大量 token。所以切片策略的本质是在“语义完整性”和“检索精度”之间找平衡。

3.2 固定长度切片、语义切片、结构化切片怎么选

常见的切片策略有三类，我分别说一下适用场景和注意事项。

固定长度切片是最简单的方案，按字符数或 token 数切，通常设置一个重叠窗口来缓解语义断裂。比如每块 512 个 token，相邻块重叠 50 到 100 个 token。这种方案实现简单，适合格式统一、结构规整的文档，比如新闻稿、博客文章。但它的缺点也很明显：遇到表格、代码块、多级标题时，很容易把完整结构切碎。

语义切片是先用模型判断句子之间的语义相似度，在语义转折处切分。比如相邻两句话的 Embedding 相似度低于某个阈值，就在那里断开。这种方案切出来的块语义更完整，但计算成本高，而且阈值不好定。我的经验是，对于技术文档、研究报告这类逻辑性强的材料，语义切片效果明显好于固定长度；但对于口语化、碎片化的内容，语义切片的优势就不大了。

结构化切片是效果最好但实现最复杂的方案。它依赖文档本身的结构信息，比如 Markdown 的标题层级、HTML 的标签树、PDF 的章节编号。按一级标题切大块，按二级标题切小块，表格和代码块单独处理。这种方案需要文档解析阶段保留结构信息，对解析器的要求比较高。如果你做的是企业知识库、产品手册这类结构清晰的文档，我强烈建议走结构化切片路线。

3.3 重叠窗口和元数据，两个不能省的细节

不管用哪种切片策略，有两个细节一定不能省。第一个是重叠窗口。相邻文本块之间保留一定重叠，是为了防止关键信息刚好落在切割边界上。重叠长度一般设为块大小的 10% 到 20%，太小起不到保护作用，太大则会造成检索结果冗余。我通常设 15% 左右，实测下来比较稳。

第二个是元数据。每个切片除了文本内容，还要带上来源文档、章节标题、页码、更新时间等元信息。这些元数据在检索阶段可以用来做过滤，比如只检索某个部门的最新文档；在生成阶段可以用来做引用标注，让用户知道答案是从哪来的。我见过很多项目前期不重视元数据，后期想加引用功能时发现数据已经入库了，只能重新跑一遍索引，非常痛苦。

提示：切片大小没有万能值。中文场景下，我一般从 300 到 500 字开始试，英文从 256 到 512 个 token 开始试，然后根据检索效果调整。别指望一次就定到最优。

4. 第三问：向量检索和关键词检索，到底该用哪个

4.1 向量检索擅长语义匹配，但有它的盲区

向量检索的原理是把文本映射到高维空间，语义相近的文本在空间里距离更近。它的优势是能处理同义词、近义词、换一种说法的情况。比如用户问“怎么退钱”，文档里写的是“退款流程”，向量检索能匹配上，关键词检索就未必。

但向量检索有几个明显的盲区。第一，它对精确匹配不敏感。用户搜一个产品型号“X200-Pro”，向量检索可能召回一堆“X200”“Pro”相关的文档，但就是漏掉精确包含这个型号的那一篇。第二，它对数值和专有名词的处理不稳定。比如“2024 年第三季度营收”，向量检索很难区分季度和年份的细微差别。第三，它的可解释性差。你很难跟用户解释“为什么这篇文档被召回了”，因为相似度分数是一个黑盒。

4.2 混合检索才是工程上的正解

在实际项目里，我基本不会只用向量检索或只用关键词检索，而是走混合检索路线。具体做法是：同时跑一路向量检索和一路关键词检索（比如 BM25 或全文索引），各自召回一批候选，然后用融合算法合并结果。

融合算法常见的有两种。一种是加权求和，给向量检索和关键词检索的分数各分配一个权重，比如 0.7 和 0.3，然后按加权总分排序。另一种是 Reciprocal Rank Fusion，简称 RRF，它不看具体分数，只看排名，把两路结果的排名做倒数求和。RRF 的好处是不需要调权重，对不同检索器的分数尺度不敏感，我一般优先用 RRF。

4.3 检索数量怎么定，Top-K 不是拍脑袋

检索阶段召回多少个候选块，这个参数直接影响后续重排和生成的效果。召回太少，可能漏掉关键信息；召回太多，重排压力大，而且容易引入噪声。

我的经验值是：向量检索和关键词检索各召回 20 到 50 个候选，融合后取 Top 30 到 Top 50 进入重排阶段，重排后取 Top 3 到 Top 5 塞进生成上下文。这个数字不是固定的，要根据文档总量、查询复杂度、延迟要求来调。如果文档总量只有几千块，召回 20 个就够；如果文档上百万，可能需要召回 100 个以上才能保证不漏。

还有一个技巧是动态调整 Top-K。对于简单的事实型查询，少召回几个就够；对于复杂的分析型查询，多召回一些。你可以用一个轻量分类器判断查询类型，或者直接用查询长度、关键词数量做启发式规则。这个优化在面试里提出来，会显得你对系统有精细化运营的思路。

5. 第四问：重排模型为什么必要，怎么选怎么用

5.1 检索和重排是两套不同的逻辑

很多人不理解为什么检索完了还要重排。简单说，检索阶段用的是双塔模型，问题和文档分别编码成向量，然后算相似度。这种方式的优点是快，可以提前把文档向量算好存起来，查询时只需要编码问题然后做向量搜索。但缺点是问题和文档之间没有交互，模型看不到两者的细粒度关系。

重排阶段用的是交叉编码器，把问题和文档拼在一起输入模型，模型能同时看到两边的每一个词，判断相关性更准。代价是慢，因为每对“问题-文档”都要单独跑一次模型推理，没法提前缓存。所以工程上的标准做法是：检索阶段用双塔快速召回一批候选，重排阶段用交叉编码器精细排序。这是一个典型的“粗筛加精排”架构，和推荐系统里的召回排序两阶段是一个思路。

5.2 重排模型的选型和性能权衡

重排模型的选择主要看三个维度：精度、延迟、成本。开源社区有几个常用的交叉编码器重排模型，参数规模从几千万到几亿不等。参数越大精度越高，但推理越慢。我的建议是先用中等规模的模型跑 baseline，如果精度不够再换大模型，同时用蒸馏或量化来压延迟。

如果你不想自己部署重排模型，也可以用商业 API，但要注意数据隐私和调用成本。对于日均查询量不大的场景，API 方案省事；对于高并发场景，自部署更可控。

还有一个取巧的方案是用大模型做重排。把问题和候选文档一起塞给大模型，让它输出相关性分数或直接排序。这种方案精度不错，但延迟和成本都很高，适合对精度要求极高、查询量不大的场景。我在一个内部知识库项目里试过，效果确实好，但每次查询要多花好几秒，后来还是换回了交叉编码器。

5.3 重排阶段的常见坑

重排阶段有几个坑我踩过，这里分享一下。第一个坑是候选数量太多导致延迟爆炸。交叉编码器的推理时间和候选数量成正比，如果你召回 100 个候选，每个都要跑一次模型，延迟可能直接飙到几秒。解决办法是控制进入重排的候选数量，或者在重排前先用轻量规则做一轮过滤。

第二个坑是重排模型和 Embedding 模型的领域不匹配。如果你的文档是医疗领域的，但重排模型是在通用语料上训练的，效果可能还不如不重排。这时候要么找领域内微调过的重排模型，要么自己标注一批数据做微调。

第三个坑是忽略重排分数的阈值。重排后不是所有候选都值得塞进上下文，如果最高分都很低，说明知识库里可能根本没有相关内容。这时候应该让模型直接回答“我不知道”，而不是硬塞一堆不相关的文档让它编。设置一个分数阈值，低于阈值的候选直接丢弃，这个细节在面试里提出来很加分。

6. 第五问：生成阶段怎么防止模型胡编乱造

6.1 Prompt 设计是生成质量的第一道防线

检索做得好，不代表生成就一定好。如果 Prompt 设计得不好，模型照样会忽略检索结果，按自己的记忆胡编。我在项目里总结了一个 Prompt 模板，效果比较稳定，你可以参考：

你是一个严谨的问答助手。请严格根据以下参考资料回答用户问题。 规则： 1. 如果参考资料中没有相关信息，直接回答“根据现有资料无法回答该问题”。 2. 不要编造参考资料中没有的事实、数字或引用。 3. 回答时尽量引用资料中的原文表述。 4. 如果资料之间存在矛盾，指出矛盾并说明不同来源的说法。 参考资料： {context} 用户问题：{question} 回答：

这个模板的关键在于：明确告诉模型“没有就说没有”，而不是让它自由发挥；要求引用原文，减少改写带来的信息失真；处理资料矛盾的情况，避免模型随机选一个。这些规则看起来简单，但能显著降低幻觉率。

6.2 上下文塞太满反而会降低效果

很多人觉得检索到的资料越多越好，恨不得把 Top 20 全塞进上下文。但实际测试下来，上下文太长会导致两个问题：一是模型注意力被稀释，关键信息淹没在大量文本里；二是超出模型有效上下文长度后，前面的内容会被截断或遗忘。

我的做法是：重排后只取 Top 3 到 Top 5，而且对每个块做长度限制，超长的块做截断或摘要。如果确实需要更多信息，宁可分多轮对话，也不要一次性塞太多。另外，把最相关的块放在上下文的最前面或最后面，中间放次要的，因为模型对首尾位置的注意力更强，这是有研究支持的。

6.3 引用标注和置信度输出，让答案可追溯

生成阶段还有一个重要功能是引用标注。让模型在回答时标注每个结论来自哪个资料块，比如“根据资料 1”或“根据文档 A 第 3 节”。这样做有两个好处：用户能验证答案的可靠性，出了问题也能追溯到具体文档。

实现方式有两种。一种是在 Prompt 里给每个资料块编号，要求模型引用编号；另一种是生成后再做一次对齐，用规则或模型判断每句话对应哪个资料块。第一种实现简单但依赖模型遵循指令的能力，第二种更可靠但多一步处理。我一般先用第一种，如果模型引用不准再上第二种。

置信度输出也是一个加分项。让模型在回答末尾输出一个置信度分数，或者用检索分数和重排分数综合计算一个置信度。低置信度的回答可以加一个提示，让用户谨慎参考。这个功能在面试里提出来，能体现你对用户体验的思考。

7. 第六问：线上效果不好，怎么系统排查

7.1 先定位问题出在哪个环节

RAG 系统线上效果不好，排查思路一定要系统化，不能东一榔头西一棒子。我的习惯是按链路顺序逐段检查：查询理解有没有问题、检索召回有没有漏、重排排序有没有错、生成有没有胡编。

具体做法是建一个评估集，包含一批典型问题和标准答案。然后对每个环节单独评估：检索阶段看召回率，标准答案所在的文档块有没有被召回；重排阶段看排序质量，最相关的块有没有排在前列；生成阶段看答案准确率和幻觉率。这样就能快速定位瓶颈在哪个环节。

7.2 几个高频问题的速查和处理

问题一：检索召回率低。先检查切片策略，看标准答案是不是被切碎了。如果切片没问题，再检查 Embedding 模型是否适配领域。中文短查询场景下，很多通用 Embedding 模型表现不佳，可以试试在领域语料上微调，或者换一个中文优化过的模型。还有一个容易被忽略的点是查询改写，用户的问题可能很口语化，直接拿去检索效果不好，可以先让模型把问题改写成更规范的检索式。

问题二：重排后相关文档反而排后面了。这通常是重排模型和 Embedding 模型不一致导致的。检查重排模型的训练数据是否和你的领域匹配，如果不匹配，要么换模型，要么自己标注数据微调。另外，重排模型的输入格式也很重要，有些模型要求特定的分隔符和指令前缀，用错了效果会差很多。

问题三：生成答案和资料矛盾。先检查 Prompt 是否明确要求“根据资料回答”。如果 Prompt 没问题，可能是上下文太长导致模型忽略了部分资料。试着减少上下文长度，或者把关键资料放在首尾位置。还有一种可能是模型本身的能力不足，换一个指令遵循能力更强的模型试试。

问题四：延迟太高。按链路拆解延迟：检索花了多少、重排花了多少、生成花了多少。检索延迟高通常是向量库索引没建好，或者候选数量太大；重排延迟高是候选太多或模型太大；生成延迟高是上下文太长或模型太大。针对性地优化，比如减少候选数量、用量化模型、做流式输出。

7.3 建立持续评估和反馈闭环

RAG 系统不是上线就完事了，需要持续运营。我建议做三件事：第一，记录每次查询的检索结果、重排分数、生成答案和用户反馈，存到日志里；第二，定期抽样人工评估，发现系统性问题；第三，把用户点踩或纠正的案例加入评估集，持续迭代。

还有一个实用技巧是 A/B 测试。每次调整切片策略、换 Embedding 模型、改 Prompt 模板，都先在小流量上跑一段时间，对比核心指标再全量。RAG 系统里很多优化是“看起来应该更好但实际不一定”，只有数据能说话。

注意：排查问题时不要同时改多个变量。一次只调一个环节，否则你无法判断效果变化是哪个改动带来的。这是我踩过好几次坑之后总结的血泪教训。

8. 面试里怎么把 RAG 讲出差异化

8.1 用项目故事代替知识点罗列

面试官一天要面好几个人，如果你只是罗列知识点，很难留下印象。我的建议是准备一两个完整的项目故事，把 RAG 的各个环节串起来讲。比如：“我们做的是一个内部技术文档问答系统，初期检索召回率只有 60%，我通过调整切片策略、引入混合检索、加交叉编码器重排，把召回率提到了 85%，生成准确率从 70% 提到了 90%。”然后面试官追问细节时，你再展开讲每个环节的具体做法。

这种讲法的好处是，你展示的不只是知识，还有发现问题、分析问题、解决问题的能力。面试官会觉得你真正做过项目，而不是背了一堆概念。

8.2 主动暴露权衡和取舍

RAG 系统里到处都是权衡：切片大小、召回数量、重排模型规模、上下文长度、延迟和精度的平衡。面试官很看重候选人有没有“权衡思维”。你可以在回答时主动说：“这里我选择了 A 方案，因为我们的场景更看重 X，虽然牺牲了 Y，但通过 Z 手段做了补偿。”这种表达方式会显得你思考得很深入。

比如聊到重排模型，你可以说：“我们一开始用了一个大参数的重排模型，精度确实好，但 P99 延迟到了 3 秒，用户体验很差。后来换了一个蒸馏过的小模型，精度只掉了两个点，但延迟降到了 500 毫秒以内。对于我们的场景来说，这个取舍是值得的。”

8.3 展示对边界和失败案例的认知

还有一个加分项是主动聊失败案例。比如：“我们试过用大模型做重排，效果确实好，但成本太高，日均查询量一上来就扛不住了，后来还是换回了交叉编码器。”或者：“我们一开始没做查询改写，用户问‘那个新功能怎么用’，检索完全找不到相关文档，后来加了查询改写才解决。”

能说出失败案例，说明你真的动手做过，而且有反思。面试官通常会对这种候选人更有好感，因为知道边界在哪里的人，比只知道最优方案的人更靠谱。

9. 一些实操中的零碎经验

9.1 评估集怎么建才有效

评估集是 RAG 优化的基础，但很多人建评估集的方式有问题。常见错误是只收集“好问题”，忽略了难例和边界情况。我的做法是：从线上日志里随机抽样一批真实查询，覆盖不同类型（事实型、分析型、对比型、否定型），然后人工标注标准答案和对应的文档块。评估集不用很大，100 到 200 条就够，但一定要有代表性。

另外，评估集要定期更新。用户的问题分布会变化，旧评估集可能不再反映真实情况。我一般每个月补充一批新查询，淘汰过时的案例。

9.2 向量库的索引参数别用默认值

向量数据库的索引参数对检索性能和精度影响很大。以常见的 HNSW 索引为例，有几个关键参数：M 控制图的连接数，efConstruction 控制建索引时的搜索范围，efSearch 控制查询时的搜索范围。默认值通常是通用场景的折中，不一定适合你的数据。

我的经验是：数据量小的时候，把 efSearch 调大一些，精度提升明显，延迟增加可接受；数据量大的时候，要在精度和延迟之间找平衡，可以通过小规模测试确定最优参数。别直接用默认值上线，这是很容易踩的坑。

9.3 缓存能省很多钱和时间

RAG 系统里有很多可以缓存的地方。Embedding 结果可以缓存，相同文本不用重复编码；检索结果可以缓存，相同查询不用重复检索；生成结果也可以缓存，高频问题直接返回。缓存策略要根据数据更新频率来定，更新频繁的数据缓存时间短一些，静态数据可以缓存久一些。

我在一个项目里加了查询缓存，命中率大概 30%，直接省了三分之一的模型调用成本。对于高频重复问题多的场景，缓存收益非常明显。

9.4 监控和告警不能少

线上系统一定要有监控。我关注的指标包括：查询量、P50/P99 延迟、检索召回率（抽样）、生成幻觉率（抽样）、用户反馈率、缓存命中率。这些指标异常时要有告警，比如延迟突然升高、召回率突然下降，可能是向量库出问题或者模型服务不稳定。

还有一个容易忽略的监控点是文档更新。如果知识库文档更新了但索引没更新，用户会拿到过时的答案。所以要监控索引更新任务的状态，确保新文档及时入库。

10. 最后聊几句个人体会

RAG 这个方向，入门容易精通难。原理半天就能讲清楚，但真正做好一个生产级系统，需要反复迭代和打磨。我自己的体会是，不要追求一步到位，先把基础链路跑通，然后根据评估数据逐个环节优化。每次只改一个变量，用数据验证效果，别凭感觉调参。

另外，RAG 不是万能的。有些问题适合用 RAG，比如知识库问答、文档检索；有些问题不适合，比如需要复杂推理的数学题、需要实时数据的场景。面试时如果被问到“RAG 的局限性”，你可以从这几个角度回答：检索质量依赖文档质量、上下文长度限制、无法处理需要多步推理的问题、对实时性支持有限。能清楚说出边界，比一味吹捧技术更有说服力。

这个领域变化很快，新的 Embedding 模型、重排模型、向量库层出不穷。保持学习习惯，多动手试，比背八股文有用得多。我到现在还保持着每周跑一两个新模型、试一两个新工具的习惯，很多优化思路都是在折腾中冒出来的。