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 系统里几个关键组件面试官几乎一定会问选型理由。我整理了一个常见的对照表你可以根据自己的项目经验调整组件常见选项选型考量我的经验文档解析通用解析库、专用解析服务格式兼容性、表格和图片处理能力表格多的文档一定要用支持结构化的解析方案否则切片后表格语义全丢Embedding 模型开源模型、商业 API维度、语言支持、推理成本、领域适配中文场景优先选在中文语料上训练过的模型通用多语言模型在中文短查询上经常翻车向量数据库内存型、持久化型、分布式数据量、查询延迟、过滤条件支持百万级以下用内存型足够上千万再考虑分布式别一上来就过度设计重排模型交叉编码器、LLM 重排精度提升幅度、延迟增加交叉编码器性价比最高LLM 重排适合对精度要求极高的场景生成模型不同参数规模的模型上下文长度、指令遵循能力、成本上下文长度比参数规模更重要塞不下检索结果再强也没用这张表里的每一行你都要能说出“我为什么选 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 系统线上效果不好排查思路一定要系统化不能东一榔头西一棒子。我的习惯是按链路顺序逐段检查查询理解有没有问题、检索召回有没有漏、重排排序有没有错、生成有没有胡编。具体做法是建一个评估集包含一批典型问题和标准答案。然后对每个环节单独评估检索阶段看召回率标准答案所在的文档块有没有被召回重排阶段看排序质量最相关的块有没有排在前列生成阶段看答案准确率和幻觉率。这样就能快速定位瓶颈在哪个环节。环节评估指标常见问题排查手段查询理解意图识别准确率查询改写错误、关键词提取遗漏人工检查查询改写结果检索召回率、MRR切片不合理、Embedding 不适配检查标准答案块是否被召回重排NDCG、排序准确率重排模型领域不匹配对比重排前后排序变化生成准确率、幻觉率Prompt 设计差、上下文过长检查生成答案与资料的一致性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 模型、重排模型、向量库层出不穷。保持学习习惯多动手试比背八股文有用得多。我到现在还保持着每周跑一两个新模型、试一两个新工具的习惯很多优化思路都是在折腾中冒出来的。