1. 为什么RAG成了面试里的“必答题”如果你最近一年在找算法岗或者大模型应用岗大概率会发现一个现象面试官不再只问Transformer八股了而是会突然抛出一句——“你做过RAG吗聊聊你的理解。”这不是跟风而是因为RAG已经从“论文里的概念”变成了“工程里必须落地的模块”。我面过也面过别人发现很多候选人对RAG的理解停留在“检索拼接生成”这三步但面试官真正想听的是你有没有踩过坑、有没有优化过、有没有想过为什么这么设计。RAG全称Retrieval-Augmented Generation检索增强生成。它的核心逻辑很朴素大模型本身的知识有截止日期也有幻觉那就在回答问题之前先去外部知识库里把相关材料找出来塞进上下文让模型基于材料回答。听起来简单但真正做起来从文档切分到向量检索再到重排序每一步都有大量细节决定最终效果。面试里的“6连问”通常不是六个独立问题而是一条链原理是什么、怎么切分、怎么检索、怎么重排、怎么生成、怎么评估。这条链上任何一个环节答得含糊面试官就能判断你只是“跑过demo”还是“真正调过系统”。这篇文章我打算把这条链拆开结合我自己在多个项目里实际调优的经验把每个环节的“为什么”和“怎么做”讲透。不管你是准备面试还是正在搭建自己的RAG系统这些内容都能直接拿去用。我不会只给你一个流程图而是会告诉你为什么朴素RAG经常效果不好、为什么切分策略比模型选择还重要、为什么重排序能救回一半的召回损失。这些才是面试官真正想听的“干货”。2. 第一问RAG到底解决了大模型的哪些硬伤2.1 知识截止与幻觉两个必须分开看的问题很多人把RAG的价值笼统概括为“让模型知道更多”这个说法太糙了。大模型有两个独立的硬伤RAG对它们的解决程度完全不同。第一个是知识截止。模型训练数据有截止日期之后发生的事情它不知道。这个问题RAG解决得很直接把新信息放进外部知识库检索出来塞进上下文就行。但这里有个隐藏坑——如果检索出来的材料和模型内部知识冲突模型倾向于相信谁实测下来如果材料在上下文中位置靠前且表述明确模型会优先采信材料但如果材料模糊或者位置靠后模型很可能回到自己的旧知识。所以RAG不是“加了检索就万事大吉”上下文的位置和表述方式同样关键。第二个是幻觉。模型会编造不存在的事实这个问题RAG只能缓解不能根治。因为幻觉的来源不只是知识缺失还有模型对自身不确定性的错误估计。你给它材料它可能仍然编造尤其是当材料里没有直接答案时。我见过一个案例问一个关于某内部流程的问题知识库里只有部分相关文档模型没有说“材料不足”而是把几个文档的片段拼接成了一个看似合理但完全错误的答案。所以RAG系统里必须加一道“拒答”机制当检索置信度低于阈值时让模型明确说“根据现有资料无法回答”而不是硬编。2.2 朴素RAG的流水线为什么经常跑不通朴素RAG的流程是文档切分→向量化→存入向量库→查询向量化→相似度检索→拼接上下文→生成。这条流水线在demo里跑得通一到真实场景就崩原因通常出在三个地方。第一切分粒度与语义完整性冲突。按固定长度切比如512个token一刀切很容易把一个完整段落切成两半检索出来的片段缺少上下文模型看不懂。按段落切又可能一段太长向量化后语义被稀释检索精度下降。第二向量相似度不等于语义相关性。用户问“如何申请报销”文档里写的是“费用审批流程”字面不相似但语义相关纯向量检索可能漏掉。反过来有些文档字面相似但答非所问也会被召回来。第三上下文窗口的浪费。检索回来一堆片段全塞进去其中可能只有一两段真正有用其余都是噪声。模型在噪声里找答案准确率会明显下降。所以RAG的优化本质上是在“召回率”和“精度”之间找平衡而朴素RAG两头都不占。面试里如果被问到“RAG有什么缺点”不要只说“检索不准”要具体到切分、向量语义、上下文噪声这三个层面面试官会立刻知道你真正调过。3. 第二问文档切分策略怎么选才不踩坑3.1 固定长度、语义切分与递归切分的适用场景切分是RAG的第一道关也是最能体现经验的地方。常见的策略有三种我分别说一下适用场景和坑。固定长度切分最简单按token数或字符数一刀切通常加一个重叠窗口overlap来缓解语义断裂。比如每512个token切一段相邻段重叠128个token。这个策略适合结构松散、段落边界不明显的文档比如聊天记录、日志。但它的坑在于重叠窗口会增加存储和检索成本而且如果文档本身有清晰的章节结构固定切分反而破坏了结构信息。语义切分是先用模型判断句子之间的语义相似度在相似度骤降的地方切一刀。这个策略适合长篇文章、技术文档能保证每段语义完整。但它的坑是计算成本高而且对短文档不划算。另外语义切分的阈值很难调阈值太高切得太碎太低又切不开。递归切分是我最常用的折中方案。它按层级来先按大标题切如果某段还是太长再按小标题切再长就按段落切最后才按固定长度切。这样既保留了文档的层级结构又控制了每段的长度。LangChain里的RecursiveCharacterTextSplitter就是干这个的你可以指定分隔符优先级比如先按“\n\n”切再按“\n”切最后按“。”切。3.2 切分长度与重叠窗口的参数计算切分长度设多少不是拍脑袋决定的。它取决于两个因素嵌入模型的最大输入长度和生成模型的上下文窗口。假设你用的嵌入模型最大输入是512个token那切分长度就不能超过512否则会被截断。但实际建议设在256到384之间因为太长的文本向量化后语义会被平均掉检索精度反而下降。重叠窗口一般设切分长度的10%到20%比如切分384重叠64。生成模型的上下文窗口决定了你能塞多少段。假设窗口是8K token系统提示词占500用户问题占100留给检索材料的空间大约是7400。如果每段384 token理论上能塞19段。但实际不要塞满因为模型在长上下文里对中间位置的信息注意力会下降这就是著名的“lost in the middle”现象。我的经验是塞5到8段把最相关的放在最前面和最后面中间放次相关的。切分策略适用场景优点坑点固定长度日志、聊天记录实现简单、速度快破坏语义完整性语义切分长篇文章、技术文档语义完整计算成本高、阈值难调递归切分结构化文档保留层级、长度可控需要设计分隔符优先级切分不是一次性的要跟着检索效果反复调。我一般会先跑一轮评估看召回的材料里有多少是“断头断尾”的再决定要不要调整切分参数。4. 第三问向量检索的精度瓶颈在哪里4.1 嵌入模型选型不是越大越好嵌入模型负责把文本转成向量它的质量直接决定检索的上限。很多人一上来就选最大的模型觉得维度越高越好其实不一定。选嵌入模型要看三个指标检索精度、推理速度、维度成本。精度可以用MTEB榜单参考但榜单分数高不代表你的场景就好。比如你处理的是法律文书通用模型可能不如在法律语料上微调过的小模型。速度方面如果知识库有百万级文档嵌入模型的推理速度直接影响索引构建时间。维度成本则关系到向量库的存储和检索延迟768维和1536维的存储差一倍检索速度也差不少。我的建议是先用一个中等规模的通用模型跑基线比如BGE-base或者GTE-base看召回效果。如果精度不够再考虑换大模型或者微调。微调嵌入模型需要构造正负样本对成本不低但效果提升往往很明显尤其是垂直领域。4.2 相似度度量与索引类型的选择逻辑向量检索的核心是相似度计算常见的有余弦相似度、点积、欧氏距离。余弦相似度最常用因为它对向量长度不敏感只看向量方向。点积和余弦的区别在于是否归一化如果向量已经归一化两者等价。索引类型决定了检索速度和召回率的平衡。Flat索引是暴力检索召回率100%但速度慢适合小知识库几万条以内。IVF索引把向量聚类检索时只查最近的几个簇速度快但可能漏掉边界上的向量。HNSW是基于图的索引检索速度快且召回率高是目前最常用的但内存占用大。选择逻辑很简单知识库小于10万条用Flat或HNSW大于10万条用IVF或HNSW加量化。如果内存紧张可以考虑PQ量化但会损失精度。4.3 混合检索为什么纯向量不够纯向量检索有个致命问题它对关键词精确匹配不敏感。比如用户问“错误码E502怎么解决”向量检索可能召回一堆关于“错误处理”的文档但就是漏掉那个专门讲E502的。这时候需要混合检索把向量检索和关键词检索比如BM25的结果融合。融合策略有两种加权求和和倒数排名融合RRF。加权求和需要调权重RRF更简单它只看排名不看分数把两个检索结果的排名做倒数相加。实测下来RRF在多数场景下更稳因为它不需要归一化分数避免了不同检索器分数尺度不一致的问题。混合检索的坑在于如果两个检索器召回的结果高度重叠融合后提升不明显如果完全不重叠融合后噪声会变多。所以通常还要加一个重排序模型来精排。5. 第四问重排序为什么能救回一半的召回损失5.1 交叉编码器与双编码器的本质区别重排序的核心是换一种更精细的相关性计算方式。检索阶段用的双编码器bi-encoder是把查询和文档分别编码成向量然后算相似度。这种方式快但查询和文档之间没有交互细粒度的语义匹配会丢失。重排序用的交叉编码器cross-encoder是把查询和文档拼在一起输入模型让模型直接输出相关性分数。因为有了交互它能捕捉到更细的语义关系比如否定、条件、指代。代价是慢因为每个查询-文档对都要过一次模型没法预计算。所以标准流程是检索阶段用双编码器召回Top 50到100重排序阶段用交叉编码器精排取Top 5到10送给生成模型。这样既保证了速度又提升了精度。5.2 重排序模型的选型与延迟权衡重排序模型的选择要看延迟预算。如果系统要求端到端响应在2秒内重排序的耗时必须控制在200毫秒以内。这时候可以用小一点的交叉编码器比如MiniLM级别的或者用蒸馏过的模型。如果延迟不敏感可以用大模型做重排序甚至用生成模型来打分。我试过用7B的模型做重排序精度确实高但单次推理要几百毫秒Top 50排下来要十几秒完全不实用。所以重排序模型的选择本质上是在精度和延迟之间找平衡点。另一个坑是重排序模型也需要和你的领域匹配。通用重排序模型在垂直领域可能不如微调过的小模型。如果领域数据多可以考虑用领域数据微调一个交叉编码器效果提升很明显。5.3 重排序的输入构造与截断策略重排序模型的输入是“查询文档”但文档可能很长超过模型的最大输入长度。这时候需要截断。截断策略有两种头截断和尾截断。头截断保留文档开头尾截断保留结尾。哪个更好取决于你的文档结构。如果关键信息通常在开头用头截断如果在结尾用尾截断。更精细的做法是先用检索阶段的高分片段作为重排序的输入而不是整个文档。因为检索阶段已经定位到了相关片段重排序只需要在这个片段上做精细判断。这样既避免了截断信息丢失又减少了输入长度。重排序不是万能的。如果检索阶段Top 50里根本没有相关文档重排序也救不回来。所以召回率和精度要分开优化先保证召回再提精度。6. 第五问生成阶段怎么让模型“说人话”6.1 上下文拼接的顺序与格式设计检索和重排序之后你手里有一堆相关片段怎么把它们拼成上下文送给模型直接决定生成质量。顺序上我试过三种按相关性降序、按文档原始顺序、两头强中间弱。实测下来两头强中间弱效果最好因为模型对开头和结尾的注意力最强。具体做法是把最相关的两段放开头和结尾次相关的放中间。格式上每段前面加一个来源标记比如“【文档1】”段与段之间用分隔符隔开。这样模型能区分不同来源也方便你在生成结果里做引用。另外在系统提示词里要明确告诉模型“只根据以下材料回答如果材料中没有答案就说不知道。”这句话能显著降低幻觉率。6.2 提示词模板里的防幻觉设计防幻觉的提示词设计有几个关键点。第一明确边界告诉模型只能使用提供的材料不能使用内部知识。第二要求引用让模型在回答里标注信息来源比如“根据文档1”。第三允许拒答明确说“如果材料不足以回答请直接说无法回答”。第四禁止推测告诉模型不要根据材料做推断只做直接陈述。我见过一个反例提示词里写“请根据材料回答”模型就以为可以自由发挥结果把材料里的片段重新组合成了一个错误答案。后来改成“只允许逐字引用材料中的原句来回答”幻觉率立刻降下来了。当然这样回答会不够流畅所以需要在流畅性和准确性之间找平衡。6.3 生成参数的温度与长度控制生成阶段的参数也会影响RAG效果。温度建议设低0.1到0.3之间因为RAG需要的是准确复述不是创意写作。温度高了模型容易自由发挥增加幻觉。最大长度要限制避免模型长篇大论。通常答案长度不会超过材料总长度设一个合理上限就行。另外重复惩罚可以适当调高防止模型反复说同一句话。但不要调太高否则会导致语句不通顺。这些参数没有固定值需要在你的场景里跑评估来调。7. 第六问RAG系统怎么评估和持续优化7.1 检索评估召回率、MRR与NDCG评估RAG要分两段检索质量和生成质量。检索质量的核心指标是召回率即相关文档有多少被召回了。如果召回率低后面再怎么优化都没用。计算召回率需要标注数据即每个查询对应哪些文档是相关的。标注成本高但可以用大模型辅助标注再人工抽检。除了召回率还有MRR平均倒数排名和NDCG归一化折损累计增益。MRR看第一个相关文档的排名NDCG看整个排序的质量。这两个指标比重排序更关注排序质量适合评估重排序模型的效果。7.2 生成评估忠实度、答案相关性与幻觉率生成质量的核心是忠实度即答案是否完全基于提供的材料没有编造。评估忠实度可以用大模型做裁判让一个模型判断答案里的每个陈述是否能在材料里找到依据。这个方法成本低但裁判模型本身也可能出错所以需要人工抽检校准。答案相关性是另一个指标看答案是否直接回答了问题。有时候答案忠实于材料但答非所问比如问“怎么申请”答“申请条件是什么”。这个指标可以用人工评估也可以用模型评估。幻觉率是最关键的指标计算方式是在答案里找出所有无法在材料中验证的陈述除以总陈述数。这个指标直接反映RAG系统的可靠性。7.3 用A/B测试驱动迭代的实操方法评估不是为了打分是为了驱动迭代。我的做法是每次改动一个变量跑一轮评估看指标变化。比如这周只改切分长度下周只改重排序模型这样能清楚知道每个改动的影响。A/B测试在RAG里比较难做因为用户查询分布不均匀。我的经验是构造一个固定的评估集包含各种类型的查询每次改动都在这个评估集上跑。评估集要覆盖简单事实查询、多跳推理、否定查询、模糊查询等场景。这样指标才有可比性。另外线上反馈也很重要。可以在答案旁边加一个“有用/没用”的按钮收集用户反馈。但要注意用户点“没用”不一定是因为答案错可能是答案不完整或者格式不好。所以线上反馈要结合人工分析不能只看数字。评估维度核心指标评估方法迭代优先级检索质量召回率、MRR标注数据模型辅助最高重排序质量NDCG标注数据高生成质量忠实度、幻觉率模型裁判人工抽检最高用户体验有用率、点击率线上反馈中8. 面试里怎么把6连问答出“经验感”面试官问RAG不是想听你背定义而是想判断你有没有真正调过系统。所以回答的时候不要只给结论要给“我试过什么、发现什么、怎么改的”。比如问“切分怎么选”不要只说“用递归切分”要说“我试过固定切分发现召回的材料经常断头断尾后来换成递归切分按标题层级切召回质量明显提升但切分长度从512降到384之后检索精度又涨了一截”。这样面试官就知道你真正跑过评估。再比如问“重排序有用吗”不要只说“有用”要说“我试过不加重排序Top 5里经常只有2到3个相关加了交叉编码器重排序之后Top 5里相关文档能到4个以上但延迟从200毫秒涨到了500毫秒后来换了个蒸馏过的小模型延迟回到300毫秒精度只掉了不到一个点”。这种带数据的回答比任何理论都有说服力。还有一个技巧主动提坑。面试官如果问“RAG有什么坑”你可以说“最大的坑是检索和生成之间的信息损失。检索阶段召回的相关文档在拼接上下文时可能因为截断或者顺序问题被模型忽略了。我遇到过检索Top 1的文档在生成时完全没被用上后来发现是因为它被放在了上下文中间模型注意力不够。把最相关的放两头之后这个问题就解决了”。这种细节只有真正调过系统的人才知道。最后如果面试官问“你怎么评估RAG”不要只说“用召回率和准确率”要说“我分两段评估检索段看召回率和MRR生成段看忠实度和幻觉率。评估集是我自己构造的覆盖了简单查询、多跳查询和否定查询。每次改动只动一个变量跑一轮评估看指标变化。线上还会收集用户反馈但反馈要结合人工分析不能只看数字”。这样回答面试官基本就能判断你是有实战经验的。RAG这个方向理论不难难的是工程细节。面试里的6连问本质上是在考你有没有把这些细节串起来。希望这篇内容能帮你把这条链理清楚不管是面试还是实际项目都能直接用上。