1. 为什么面试官揪着RAG不放：先把这个动机吃透我最近在系统梳理大模型方向的面试题，RAG（Retrieval-Augmented Generation，检索增强生成）几乎是每家必问的模块。尤其是做应用层项目的岗位，RAG的提问密度比微调还高。原因很直接：它是目前让大模型落地到私有知识场景里成本最低、见效最快的一套方案，而且这块的工程细节足够多，面试官一聊就能摸清你到底是调过接口还是真的从0到1搭过系统。面试考RAG，考点其实非常集中。抛开八股文式的概念背诵，真正拉开差距的永远是这三层：第一层是你有没有把RAG的pipeline（数据切分、向量化、召回、重排、生成）完整跑通过；第二层是当效果不好的时候，你能不能快速定位是哪个环节拖了后腿；第三层是当数据规模上来或业务复杂化之后，你有没有考虑过RAG的各种变形，比如GraphRAG、Agentic RAG这些进阶方案。我自己复盘了十几场面经之后一个很深的体会：面经准备最忌讳的是把每个概念背得滚瓜烂熟，但串不起一条完整的链路。面试官一旦从"你讲讲RAG"跳到"如果召回的结果全是无关内容你怎么办"，很多人就开始支支吾吾。所以这篇文章我的主线思路不是背知识点，而是站在"我做了一个RAG系统、现在效果不佳、我要怎么排查优化"的角度，把所有高频考点串起来。先说清楚一个根本问题：RAG到底解决了什么。大模型的训练数据是有截止时间的，而且公开互联网语料里根本不存在你公司的内部文档、你手里的私有协议、你刚调试出来的实验数据。你要让模型"知道"这些内容，摆在面前的无非三条路：继续预训练、微调、RAG。继续预训练的成本绝大多数团队想都不用想，微调能把知识"塞"进参数里但每次更新知识都要重新训练一轮，而且微调改不动模型对事实性内容的编造倾向。RAG的思路就完全不同了：它不试图改变模型的记忆，而是把知识放在外部，每次回答前先从知识库里检索出相关内容，把检索结果连同问题一起丢给模型生成答案。这就是RAG最核心的定位：给模型外挂一个可随时更新的动态记忆。面试官想听的就是你能不能用这个逻辑解释清楚，为什么一套"检索+拼接+生成"的机制能同时处理知识过时、幻觉、领域知识缺失这些大模型的老大难问题。2. 数据准备环节的高频追问：切分与向量化没那么简单RAG的第一道工序是把知识库文档切成合适的片段，然后向量化入库。这块看似人人在做，但面试题恰恰最爱从这里开始深挖。2.1 文档切分的"黄金尺寸"确实存在吗每个做过RAG的人大概率都被chunk size折磨过。面试官常常直接问："你切分的时候chunk大小怎么设的？"这个问题背后想考察的是你有没有真正理解切分长度和效果之间的微妙关系。咱们把逻辑拆开。切短了，比如128个token一段，检索回来的是精确的小片段，语义聚焦，但问题是它很容易丢失上下文，一个完整的观点被拦腰截断，生成的时候模型拿到的是"半句话"，答案自然容易断章取义。切长了，比如1024甚至2048个token，每段包含的信息量充足，上下文完整，但向量化之后语义容易被稀释——整段话的主要意思可能集中在某一小部分上，检索时计算相似度反而被无关内容干扰，召回精度下降。我在实际项目里常用的是512到768这个区间，同时配合一个参考维度：先看业务文档本身的结构。如果手里的资料本来就是按章节组织的、每章内部主题高度内聚，那优先按语义边界切而不是按固定长度硬切，比如用标题层级、段落边界做切分点。技术类文档、规章制度这些结构感强的文本，按固定长度切会非常吃亏。还有个细节很多人没注意：重叠（overlap）参数的设置。切分时让相邻两个片段之间保留一定重叠，能缓解"核心信息恰好落在边界被切断"的问题，但要控制幅度，一般50到100个token就够，过多重叠会让库里存在大量高度重复的向量，检索时会出现好几个片段都是同一段话的情况，白白占用量化后的存储空间，也影响检索结果的多样性。2.2 嵌入模型的选择逻辑向量化的核心是把文本变成向量，这一步的选型直接决定了检索"理解"语义的天花板。面试官一般不期待你报出一串模型名字，而是想听你怎么做选择、怎么评估。选择嵌入模型时我会按三个维度去聊。第一是领域匹配度，通用模型在通用语料上表现尚可，但拉到法律、医疗、代码这些垂直领域，领域内微调过的模型往往召回效果明显更好，选择前最好拿一批真实业务query做小规模召回测试对比。第二是语言支持，中文场景尤其要注意模型对中文的对齐能力，一个优秀的英文嵌入模型放到中文短文本检索上可能表现很普通。第三是向量维度与检索性能的平衡，维度越高的向量表达信息越丰富，但计算量和存储成本也随之上升，得结合知识库规模和线上QPS来权衡。我印象最深的是一次面试里追问："向量库你选的什么？怎么评估它适不适合你的场景？"这个问题的潜台词是：你有没有从性能、规模、过滤能力这些工程维度想过问题。比如业务里经常需要按文档来源、业务线、时间范围做过滤，那向量库对标量过滤的支持就很重要；知识库规模上到千万级，索引构建方式、内存占用、分片策略就都要纳入考量。准备面经的话，建议准备一套自己的"选型框架"故事：什么量级、什么并发、什么数据特点，我选了什么方案，为什么。提示：回答嵌入模型和向量库选型题时，最出彩的讲法不是报名字，而是把你的决策依据讲成"数据特点倒逼选型"的推理过程，面试官更想看到方法论。3. 召回、重排和检索优化：这里最容易暴露工程功底检索环节是RAG里信息密度最大的考点。一个朴素的RAG系统就是：query向量化、去向量库检索TopK、把结果塞给大模型。但实际效果往往在"朴素"两个字上翻车。3.1 混合检索为什么越来越标配向量检索擅长语义匹配，它能把"如何申请年假"和"请假流程是什么"关联起来，因为它捕捉的是语义相似性。但向量检索有一个天然痛点：对专有名词、编号、精确表述不敏感。假设用户问的是"PRD-2024-001号文档的审批状态"，这种字符串级别的精确匹配，向量检索的召回质量往往不如传统的BM25稀疏检索。这就是混合检索（Hybrid Search）的价值：向量召回负责语义泛化，关键词召回负责精确命中，最后把两路结果融合。面试里被问到"召回结果不理想你怎么优化"时，混合检索是最稳妥的第一步答案。我还建议往下补一句：融合时要考虑分数分布不一致的问题，向量相似度分数和BM25分数不在同一个量纲，不能简单相加，常见的做法是分别做归一化之后再加权融合，权重本身也可以根据业务调优。和混合检索经常一起出现的是多路召回。比如你做一个企业知识库问答，高质量命中的文档可能分布在不同的数据源里，员工手册里有一份、项目Wiki里有一份、旧版OA系统里也有一份，只检索向量库里"所有文档混合切分"的内容，很容易漏掉某个来源里的关键信息。按业务线、按文档类型拆分索引，每路独立召回，最后统一汇总，这种设计在知识库场景里很常用。3.2 重排（Rerank）是提升效果最被低估的一环很多人做RAG做到向量召回就结束了，然后抱怨效果不好。我可以直接说：不做重排，你的RAG效果上限会很惨。前一步召回阶段为了Recall（查全率），通常会把候选集拉宽，比如拿回50条甚至100条文本片段。但其中真正和问题强相关的可能只有三四条，如果直接把这几十条一股脑塞给大模型，上下文被大量无关内容污染，模型不仅答得差，还会被噪音信息带偏，编造出基于无关片段的内容，幻觉概率直线上升。重排就是负责在较大候选集里"优中选优"的环节：用更强的排序模型对候选片段重新打分，把真正相关的3到5条送到生成环节。它和召回的区别可以打个比方：召回像是从书架上把所有可能相关的书都拿下来，粗看封面快速筛选；重排则是坐下来一本本翻目录和摘要，挑出跟问题最相关的那几页。今年面试里几乎必问的一个衍生问题是"为什么不用重排模型直接做召回"，这个问题很有迷惑性。答法是：因为重排模型的推理成本远高于向量检索，向量检索可以用近似最近邻算法在毫秒级别扫过百万级向量，而重排模型是老老实实地逐条计算深度交互的语义匹配分数，两边效率和成本完全不在一个量级。实际架构就是"粗召回+精排"的分层漏斗，这个是信息检索领域沉淀下来的经典设计逻辑，单靠一层想做满两个目标基本不现实。3.3 query改写与意图纠偏：容易被忽视但面试爱问还有一个面试官特别喜欢拿出来考的点：用户的原始问题直接拿去检索，效果往往不好。为什么？因为口语化表达太模糊，指代词太多。用户问"它的续费价格是多少"，但这个"它"在上文指的是某款具体产品，单独拿这句话去检索，知识库根本不知道你要问什么。这个场景就需要一个前置环节：把用户的原始query做改写，补充指代信息、扩展同义表达、甚至拆解成多个子问题，再拿去检索。类似的思路还包括HyDE——先让大模型基于query生成一个假设性的回答，用这个回答的向量去检索。逻辑是：与query直接匹配的片段可能措辞不同，但假设性回答在语义空间里更接近真正的相关文档，能提升召回命中率，代价是多一次大模型调用，延迟会增加。面试时提到这些，还会连带着考察RAG迭代中的模块化思维：原始的"检索-生成"两端式结构太单薄，面对复杂query需要拆解、改写、多轮检索这些配套模块，这就是从Naive RAG走向Advanced RAG的自然路径。你不用刻意背这三个阶段的名词，但你的回答要让面试官觉得你不是只搭过一个demo，而是经历过"基础版不够用、再加模块优化"的完整迭代过程。4. 生成环节的幻觉把控：RAG能不能落地，看的就是这一关检索做完了，拿到TopK片段，剩下的工作就是把这些片段和用户的query组装成Prompt，交给大模型生成答案。这块的字面考点是Prompt怎么写，深层考点其实是幻觉治理。4.1 幻觉是检索增强要解决的头号问题，但增强本身也会制造幻觉先明确概念。幻觉指的是模型生成了与事实不符、或者根本没有依据的内容。RAG被寄予厚望，正是因为把真实文档片段塞进上下文之后，模型有了"参考材料"，理论上应该照着材料回答，不应该再凭空编造。但实际用下来你会发现，RAG系统照样出幻觉，原因经常比想象的复杂。一是检索噪音导致的幻觉。你召回的内容里混了一条完全不相关的片段，模型又"很聪明"地试图把这条片段也融入到回答里，结果就是牵强附会。所以治理幻觉的第一步往往不在生成侧，而在检索侧——减少无效内容进入上下文，靠的正是前面提到的重排与过滤。二是大模型"不忠实于上下文"造成的幻觉。模型即使看到了一堆参考资料，它长期养成的话痨习惯还是会让它忍不住补充一些上下文里没有的"常识"或"猜测"。这时候Prompt约束就有讲究了。我常用的做法是在系统提示里写死一条："只能依据提供的上下文回答，如果上下文不足以回答问题，直接说明信息不足，不要自行推测。"同时把回答限制在"基于材料、不提材料之外内容"的范围内。三是上下文截断造成的信息缺失。Retrieved的片段太多了，超长文本放不进上下文窗口，或者超出窗口后被截掉了结尾，关键依据还没送进去。所以设计Prompt模板时，我给每个片段编号，让模型在答案里标注引用了哪条片段，这对于定位"幻觉到底是哪来的"非常有帮助，属于排查工具里成本最低的一个。4.2 评估体系如何帮你定位"哪一环出了问题"聊到幻觉治理，几乎必然会引到下一个问题："你怎么知道你系统效果变好了？"如果你回答"我大概看几个问题测了一下"，面试官对你的印象分马上会降一档。RAG的评估体系是今年面试里上升速度最快的一个考点。我到目前用下来最顺手的思路是把评估拆成两块：检索质量和生成质量。检索质量看两个指标，一个是召回率（Recall），即相关片段有没有出现在你的召回结果里；一个是命中位置，即正确答案排在Top3还是掉到Top5开外了，这直接反映召回端加混合检索或重排之后有没有实质提升。生成质量则看回答对材料的使用是否充分，有没有出现"材料里有答案但模型没用上"的浪费情况，有没有回答内容过度发挥，把材料里根本不存在的信息讲得有鼻子有眼。这里有一个很多团队没做到的细节：要把生成答案和答案所依据的片段按句拆分，逐句判断它是不是被上下文支持的。比如答案里有五句话，四句有依据、一句是编的，整体打分会被平均掉，手工看一遍根本看不出问题。自动化的逐句归因评估在这个粒度上才能暴露出真实问题，每次改造之后跑一遍，看看幻觉句子的占比是上升还是下降，这个数值变化才是迭代效果的客观记录。注意：光看端到端问答效果好坏是无法区分问题出在哪个环节的。不把检索质量和生成质量拆开评估，你换了检索策略都不知道有没有生效，这是很多RAG项目迭代慢的根源。5. 面试加分项：RAG的进阶方向与工程落地经验聊完基础链路，面试水平高不高就看你能不能往上游走一层。近一年面试官对RAG进阶方案的提问密度明显增加，而且特别喜欢用"你了解GraphRAG吗""你的RAG系统如果知识库很大怎么办"这类开放问题来测试你的知识边界。5.1 GraphRAG：当文档之间的关系成为核心价值普通向量RAG有一个尴尬的场景：你问系统"我们公司今年几个核心产品的定位分别是什么变化"，这个问题的答案分散在多份文档里，而且需要理解产品与产品之间的衍生关系、先后关系。传统RAG把文档切成一块块独立的向量，片段之间没有任何关联，模型答这种"需要跨越文档做关系推理"的问题时经常顾此失彼。GraphRAG的思路是：对文档做实体抽取和关系抽取，构建一张知识图谱，把"文档片段"的组织方式升级成"实体-关系"的组织方式。回答问题时先在图上做遍历和推理，再结合原始片段生成答案。我的经验是用在知识体系强关联的场景很有效，比如产品文档体系、法规条文体系、研发Wiki等。代价也很实在：构建图谱需要消耗大量大模型调用做实体识别与关系提取，成本和时效都要评估好，知识更新频率高的场景图谱维护就很让人头疼。5.2 Agentic RAG和模块化趋势：面试时如何自然聊到最近面经里还有一个高频词是Agentic RAG。它解决的核心痛点是：真实场景的query常常不是一句就问完的——用户说"帮我对比一下A产品和B产品的定价策略，然后给我一个适合小团队的推荐"，这种query拆开就是多个子任务，前后存在依赖关系，单次检索根本搞不定。Agentic RAG的思路是让大模型作为Agent来自主规划：先拆解问题、决定需要哪几步、每一步选择不同的工具（向量检索、结构化数据库查询、网页搜索、代码计算），中间还可以根据上一步的结果决定下一步怎么走。相当于把原来的"先检索后生成"死板流程，改成一个有决策能力的工作流。面试中谈到这点时我会强调一个关键认知：Agentic RAG不等于"多轮对话"，它的核心是让模型拥有任务分解与工具调用的能力，每一步都由模型决策，而不是脚本写死的固定流程。另外一个容易被追问的进阶点是:微调与RAG如何配合。我在实战里的经验是：如果知识库内容频繁更新，靠RAG就够了；如果你希望模型在特定风格的输出上更稳定，比如客服场景固定话术、法律文书特定结构，那可以考虑用少量数据做微调，让模型更贴合任务格式。两者不是替代关系——RAG负责提供事实知识，微调负责约束输出风格和技能倾向，面试里能说出这层配合逻辑，比单纯背"RAG和微调的区别"要打动人多。5.3 工程落地中真正值得写进面经的踩坑经验最后分享几个我在实际搭RAG系统时积累的，几乎每次面试都会提到的经验。第一个是关于测试集的重要性：建RAG项目的第一周，先花时间把"评测问题集"搭起来，覆盖典型问题、边界问题、容易混淆的问题，没有它后面任何优化都说不清有没有效果。很多项目死在"凭感觉说效果好了一点"上。第二个是召回候选集的规模设计。候选集太小，重排环节形同虚设，太小就筛不出东西；候选集太大，重排延迟和成本扛不住。常规做法是先让召回端给到20到50条候选，重排后再保留3到5条进生成环节，这个比例兼顾了查全、精度和成本。第三个是Prompt模板里给模型留"不知道"的退路。我见过最典型的翻车是：材料里没有信息，模型靠着通用知识硬答，表面看答得挺流畅，实际跟材料毫无关系，这种"流畅的幻觉"在B端知识问答里非常致命。模板里明确给一条"基于材料无法回答"的出口，效果立竿见影。第四个经验点跟部署环境有关：遇到向量库服务化带来的性能瓶颈时，先排查Index构建参数和并发连接池配置，往往比换更贵的机器更解决问题。召回服务的P99延迟飙升，很多时候不是机器不够，而是索引参数没收敛好。面经写到这，我自己的感觉是：RAG这块只要把"数据准备—召回—精排—生成—评估"这条链路的相关技术原理都过一遍，再配上两三个踩坑案例，面试时基本就能做到有体系、有细节。下一轮我打算把Agent相关的准备笔记也整理出来，毕竟今年RAG题目聊到最后，十有八九都会拐到Agent上，提前把树状结构搭好总没坏处。
1. 为什么面试官揪着RAG不放：先把这个动机吃透我最近在系统梳理大模型方向的面试题，RAG（Retrieval-Augmented Generation，检索增强生成）几乎是每家必问的模块。尤其是做应用层项目的岗位，RAG的提问密度比微调还高。原因很直接：它是目前让大模型落地到私有知识场景里成本最低、见效最快的一套方案，而且这块的工程细节足够多，面试官一聊就能摸清你到底是调过接口还是真的从0到1搭过系统。面试考RAG，考点其实非常集中。抛开八股文式的概念背诵，真正拉开差距的永远是这三层：第一层是你有没有把RAG的pipeline（数据切分、向量化、召回、重排、生成）完整跑通过；第二层是当效果不好的时候，你能不能快速定位是哪个环节拖了后腿；第三层是当数据规模上来或业务复杂化之后，你有没有考虑过RAG的各种变形，比如GraphRAG、Agentic RAG这些进阶方案。我自己复盘了十几场面经之后一个很深的体会：面经准备最忌讳的是把每个概念背得滚瓜烂熟，但串不起一条完整的链路。面试官一旦从"你讲讲RAG"跳到"如果召回的结果全是无关内容你怎么办"，很多人就开始支支吾吾。所以这篇文章我的主线思路不是背知识点，而是站在"我做了一个RAG系统、现在效果不佳、我要怎么排查优化"的角度，把所有高频考点串起来。先说清楚一个根本问题：RAG到底解决了什么。大模型的训练数据是有截止时间的，而且公开互联网语料里根本不存在你公司的内部文档、你手里的私有协议、你刚调试出来的实验数据。你要让模型"知道"这些内容，摆在面前的无非三条路：继续预训练、微调、RAG。继续预训练的成本绝大多数团队想都不用想，微调能把知识"塞"进参数里但每次更新知识都要重新训练一轮，而且微调改不动模型对事实性内容的编造倾向。RAG的思路就完全不同了：它不试图改变模型的记忆，而是把知识放在外部，每次回答前先从知识库里检索出相关内容，把检索结果连同问题一起丢给模型生成答案。这就是RAG最核心的定位：给模型外挂一个可随时更新的动态记忆。面试官想听的就是你能不能用这个逻辑解释清楚，为什么一套"检索+拼接+生成"的机制能同时处理知识过时、幻觉、领域知识缺失这些大模型的老大难问题。2. 数据准备环节的高频追问：切分与向量化没那么简单RAG的第一道工序是把知识库文档切成合适的片段，然后向量化入库。这块看似人人在做，但面试题恰恰最爱从这里开始深挖。2.1 文档切分的"黄金尺寸"确实存在吗每个做过RAG的人大概率都被chunk size折磨过。面试官常常直接问："你切分的时候chunk大小怎么设的？"这个问题背后想考察的是你有没有真正理解切分长度和效果之间的微妙关系。咱们把逻辑拆开。切短了，比如128个token一段，检索回来的是精确的小片段，语义聚焦，但问题是它很容易丢失上下文，一个完整的观点被拦腰截断，生成的时候模型拿到的是"半句话"，答案自然容易断章取义。切长了，比如1024甚至2048个token，每段包含的信息量充足，上下文完整，但向量化之后语义容易被稀释——整段话的主要意思可能集中在某一小部分上，检索时计算相似度反而被无关内容干扰，召回精度下降。我在实际项目里常用的是512到768这个区间，同时配合一个参考维度：先看业务文档本身的结构。如果手里的资料本来就是按章节组织的、每章内部主题高度内聚，那优先按语义边界切而不是按固定长度硬切，比如用标题层级、段落边界做切分点。技术类文档、规章制度这些结构感强的文本，按固定长度切会非常吃亏。还有个细节很多人没注意：重叠（overlap）参数的设置。切分时让相邻两个片段之间保留一定重叠，能缓解"核心信息恰好落在边界被切断"的问题，但要控制幅度，一般50到100个token就够，过多重叠会让库里存在大量高度重复的向量，检索时会出现好几个片段都是同一段话的情况，白白占用量化后的存储空间，也影响检索结果的多样性。2.2 嵌入模型的选择逻辑向量化的核心是把文本变成向量，这一步的选型直接决定了检索"理解"语义的天花板。面试官一般不期待你报出一串模型名字，而是想听你怎么做选择、怎么评估。选择嵌入模型时我会按三个维度去聊。第一是领域匹配度，通用模型在通用语料上表现尚可，但拉到法律、医疗、代码这些垂直领域，领域内微调过的模型往往召回效果明显更好，选择前最好拿一批真实业务query做小规模召回测试对比。第二是语言支持，中文场景尤其要注意模型对中文的对齐能力，一个优秀的英文嵌入模型放到中文短文本检索上可能表现很普通。第三是向量维度与检索性能的平衡，维度越高的向量表达信息越丰富，但计算量和存储成本也随之上升，得结合知识库规模和线上QPS来权衡。我印象最深的是一次面试里追问："向量库你选的什么？怎么评估它适不适合你的场景？"这个问题的潜台词是：你有没有从性能、规模、过滤能力这些工程维度想过问题。比如业务里经常需要按文档来源、业务线、时间范围做过滤，那向量库对标量过滤的支持就很重要；知识库规模上到千万级，索引构建方式、内存占用、分片策略就都要纳入考量。准备面经的话，建议准备一套自己的"选型框架"故事：什么量级、什么并发、什么数据特点，我选了什么方案，为什么。提示：回答嵌入模型和向量库选型题时，最出彩的讲法不是报名字，而是把你的决策依据讲成"数据特点倒逼选型"的推理过程，面试官更想看到方法论。3. 召回、重排和检索优化：这里最容易暴露工程功底检索环节是RAG里信息密度最大的考点。一个朴素的RAG系统就是：query向量化、去向量库检索TopK、把结果塞给大模型。但实际效果往往在"朴素"两个字上翻车。3.1 混合检索为什么越来越标配向量检索擅长语义匹配，它能把"如何申请年假"和"请假流程是什么"关联起来，因为它捕捉的是语义相似性。但向量检索有一个天然痛点：对专有名词、编号、精确表述不敏感。假设用户问的是"PRD-2024-001号文档的审批状态"，这种字符串级别的精确匹配，向量检索的召回质量往往不如传统的BM25稀疏检索。这就是混合检索（Hybrid Search）的价值：向量召回负责语义泛化，关键词召回负责精确命中，最后把两路结果融合。面试里被问到"召回结果不理想你怎么优化"时，混合检索是最稳妥的第一步答案。我还建议往下补一句：融合时要考虑分数分布不一致的问题，向量相似度分数和BM25分数不在同一个量纲，不能简单相加，常见的做法是分别做归一化之后再加权融合，权重本身也可以根据业务调优。和混合检索经常一起出现的是多路召回。比如你做一个企业知识库问答，高质量命中的文档可能分布在不同的数据源里，员工手册里有一份、项目Wiki里有一份、旧版OA系统里也有一份，只检索向量库里"所有文档混合切分"的内容，很容易漏掉某个来源里的关键信息。按业务线、按文档类型拆分索引，每路独立召回，最后统一汇总，这种设计在知识库场景里很常用。3.2 重排（Rerank）是提升效果最被低估的一环很多人做RAG做到向量召回就结束了，然后抱怨效果不好。我可以直接说：不做重排，你的RAG效果上限会很惨。前一步召回阶段为了Recall（查全率），通常会把候选集拉宽，比如拿回50条甚至100条文本片段。但其中真正和问题强相关的可能只有三四条，如果直接把这几十条一股脑塞给大模型，上下文被大量无关内容污染，模型不仅答得差，还会被噪音信息带偏，编造出基于无关片段的内容，幻觉概率直线上升。重排就是负责在较大候选集里"优中选优"的环节：用更强的排序模型对候选片段重新打分，把真正相关的3到5条送到生成环节。它和召回的区别可以打个比方：召回像是从书架上把所有可能相关的书都拿下来，粗看封面快速筛选；重排则是坐下来一本本翻目录和摘要，挑出跟问题最相关的那几页。今年面试里几乎必问的一个衍生问题是"为什么不用重排模型直接做召回"，这个问题很有迷惑性。答法是：因为重排模型的推理成本远高于向量检索，向量检索可以用近似最近邻算法在毫秒级别扫过百万级向量，而重排模型是老老实实地逐条计算深度交互的语义匹配分数，两边效率和成本完全不在一个量级。实际架构就是"粗召回+精排"的分层漏斗，这个是信息检索领域沉淀下来的经典设计逻辑，单靠一层想做满两个目标基本不现实。3.3 query改写与意图纠偏：容易被忽视但面试爱问还有一个面试官特别喜欢拿出来考的点：用户的原始问题直接拿去检索，效果往往不好。为什么？因为口语化表达太模糊，指代词太多。用户问"它的续费价格是多少"，但这个"它"在上文指的是某款具体产品，单独拿这句话去检索，知识库根本不知道你要问什么。这个场景就需要一个前置环节：把用户的原始query做改写，补充指代信息、扩展同义表达、甚至拆解成多个子问题，再拿去检索。类似的思路还包括HyDE——先让大模型基于query生成一个假设性的回答，用这个回答的向量去检索。逻辑是：与query直接匹配的片段可能措辞不同，但假设性回答在语义空间里更接近真正的相关文档，能提升召回命中率，代价是多一次大模型调用，延迟会增加。面试时提到这些，还会连带着考察RAG迭代中的模块化思维：原始的"检索-生成"两端式结构太单薄，面对复杂query需要拆解、改写、多轮检索这些配套模块，这就是从Naive RAG走向Advanced RAG的自然路径。你不用刻意背这三个阶段的名词，但你的回答要让面试官觉得你不是只搭过一个demo，而是经历过"基础版不够用、再加模块优化"的完整迭代过程。4. 生成环节的幻觉把控：RAG能不能落地，看的就是这一关检索做完了，拿到TopK片段，剩下的工作就是把这些片段和用户的query组装成Prompt，交给大模型生成答案。这块的字面考点是Prompt怎么写，深层考点其实是幻觉治理。4.1 幻觉是检索增强要解决的头号问题，但增强本身也会制造幻觉先明确概念。幻觉指的是模型生成了与事实不符、或者根本没有依据的内容。RAG被寄予厚望，正是因为把真实文档片段塞进上下文之后，模型有了"参考材料"，理论上应该照着材料回答，不应该再凭空编造。但实际用下来你会发现，RAG系统照样出幻觉，原因经常比想象的复杂。一是检索噪音导致的幻觉。你召回的内容里混了一条完全不相关的片段，模型又"很聪明"地试图把这条片段也融入到回答里，结果就是牵强附会。所以治理幻觉的第一步往往不在生成侧，而在检索侧——减少无效内容进入上下文，靠的正是前面提到的重排与过滤。二是大模型"不忠实于上下文"造成的幻觉。模型即使看到了一堆参考资料，它长期养成的话痨习惯还是会让它忍不住补充一些上下文里没有的"常识"或"猜测"。这时候Prompt约束就有讲究了。我常用的做法是在系统提示里写死一条："只能依据提供的上下文回答，如果上下文不足以回答问题，直接说明信息不足，不要自行推测。"同时把回答限制在"基于材料、不提材料之外内容"的范围内。三是上下文截断造成的信息缺失。Retrieved的片段太多了，超长文本放不进上下文窗口，或者超出窗口后被截掉了结尾，关键依据还没送进去。所以设计Prompt模板时，我给每个片段编号，让模型在答案里标注引用了哪条片段，这对于定位"幻觉到底是哪来的"非常有帮助，属于排查工具里成本最低的一个。4.2 评估体系如何帮你定位"哪一环出了问题"聊到幻觉治理，几乎必然会引到下一个问题："你怎么知道你系统效果变好了？"如果你回答"我大概看几个问题测了一下"，面试官对你的印象分马上会降一档。RAG的评估体系是今年面试里上升速度最快的一个考点。我到目前用下来最顺手的思路是把评估拆成两块：检索质量和生成质量。检索质量看两个指标，一个是召回率（Recall），即相关片段有没有出现在你的召回结果里；一个是命中位置，即正确答案排在Top3还是掉到Top5开外了，这直接反映召回端加混合检索或重排之后有没有实质提升。生成质量则看回答对材料的使用是否充分，有没有出现"材料里有答案但模型没用上"的浪费情况，有没有回答内容过度发挥，把材料里根本不存在的信息讲得有鼻子有眼。这里有一个很多团队没做到的细节：要把生成答案和答案所依据的片段按句拆分，逐句判断它是不是被上下文支持的。比如答案里有五句话，四句有依据、一句是编的，整体打分会被平均掉，手工看一遍根本看不出问题。自动化的逐句归因评估在这个粒度上才能暴露出真实问题，每次改造之后跑一遍，看看幻觉句子的占比是上升还是下降，这个数值变化才是迭代效果的客观记录。注意：光看端到端问答效果好坏是无法区分问题出在哪个环节的。不把检索质量和生成质量拆开评估，你换了检索策略都不知道有没有生效，这是很多RAG项目迭代慢的根源。5. 面试加分项：RAG的进阶方向与工程落地经验聊完基础链路，面试水平高不高就看你能不能往上游走一层。近一年面试官对RAG进阶方案的提问密度明显增加，而且特别喜欢用"你了解GraphRAG吗""你的RAG系统如果知识库很大怎么办"这类开放问题来测试你的知识边界。5.1 GraphRAG：当文档之间的关系成为核心价值普通向量RAG有一个尴尬的场景：你问系统"我们公司今年几个核心产品的定位分别是什么变化"，这个问题的答案分散在多份文档里，而且需要理解产品与产品之间的衍生关系、先后关系。传统RAG把文档切成一块块独立的向量，片段之间没有任何关联，模型答这种"需要跨越文档做关系推理"的问题时经常顾此失彼。GraphRAG的思路是：对文档做实体抽取和关系抽取，构建一张知识图谱，把"文档片段"的组织方式升级成"实体-关系"的组织方式。回答问题时先在图上做遍历和推理，再结合原始片段生成答案。我的经验是用在知识体系强关联的场景很有效，比如产品文档体系、法规条文体系、研发Wiki等。代价也很实在：构建图谱需要消耗大量大模型调用做实体识别与关系提取，成本和时效都要评估好，知识更新频率高的场景图谱维护就很让人头疼。5.2 Agentic RAG和模块化趋势：面试时如何自然聊到最近面经里还有一个高频词是Agentic RAG。它解决的核心痛点是：真实场景的query常常不是一句就问完的——用户说"帮我对比一下A产品和B产品的定价策略，然后给我一个适合小团队的推荐"，这种query拆开就是多个子任务，前后存在依赖关系，单次检索根本搞不定。Agentic RAG的思路是让大模型作为Agent来自主规划：先拆解问题、决定需要哪几步、每一步选择不同的工具（向量检索、结构化数据库查询、网页搜索、代码计算），中间还可以根据上一步的结果决定下一步怎么走。相当于把原来的"先检索后生成"死板流程，改成一个有决策能力的工作流。面试中谈到这点时我会强调一个关键认知：Agentic RAG不等于"多轮对话"，它的核心是让模型拥有任务分解与工具调用的能力，每一步都由模型决策，而不是脚本写死的固定流程。另外一个容易被追问的进阶点是:微调与RAG如何配合。我在实战里的经验是：如果知识库内容频繁更新，靠RAG就够了；如果你希望模型在特定风格的输出上更稳定，比如客服场景固定话术、法律文书特定结构，那可以考虑用少量数据做微调，让模型更贴合任务格式。两者不是替代关系——RAG负责提供事实知识，微调负责约束输出风格和技能倾向，面试里能说出这层配合逻辑，比单纯背"RAG和微调的区别"要打动人多。5.3 工程落地中真正值得写进面经的踩坑经验最后分享几个我在实际搭RAG系统时积累的，几乎每次面试都会提到的经验。第一个是关于测试集的重要性：建RAG项目的第一周，先花时间把"评测问题集"搭起来，覆盖典型问题、边界问题、容易混淆的问题，没有它后面任何优化都说不清有没有效果。很多项目死在"凭感觉说效果好了一点"上。第二个是召回候选集的规模设计。候选集太小，重排环节形同虚设，太小就筛不出东西；候选集太大，重排延迟和成本扛不住。常规做法是先让召回端给到20到50条候选，重排后再保留3到5条进生成环节，这个比例兼顾了查全、精度和成本。第三个是Prompt模板里给模型留"不知道"的退路。我见过最典型的翻车是：材料里没有信息，模型靠着通用知识硬答，表面看答得挺流畅，实际跟材料毫无关系，这种"流畅的幻觉"在B端知识问答里非常致命。模板里明确给一条"基于材料无法回答"的出口，效果立竿见影。第四个经验点跟部署环境有关：遇到向量库服务化带来的性能瓶颈时，先排查Index构建参数和并发连接池配置，往往比换更贵的机器更解决问题。召回服务的P99延迟飙升，很多时候不是机器不够，而是索引参数没收敛好。面经写到这，我自己的感觉是：RAG这块只要把"数据准备—召回—精排—生成—评估"这条链路的相关技术原理都过一遍，再配上两三个踩坑案例，面试时基本就能做到有体系、有细节。下一轮我打算把Agent相关的准备笔记也整理出来，毕竟今年RAG题目聊到最后，十有八九都会拐到Agent上，提前把树状结构搭好总没坏处。