1. 为什么RAG成了面试的“必考题”如果你最近一年面过AI应用岗不管是做大模型应用开发、算法工程还是AI产品经理大概率会被问到RAG。原因很直接大模型本身的知识有截止日期企业内部文档又不可能全部拿去重新训练RAGRetrieval-Augmented Generation检索增强生成就成了让模型“开卷考试”的最实用方案。它不改变模型参数而是在生成之前先检索一批相关资料塞进上下文让模型基于这些资料回答。我面过也面过别人发现一个规律很多人能把RAG流程背出来——文档切块、向量化、检索、拼prompt、生成但一旦追问“切块大小怎么定”“召回不准怎么办”“检索和生成谁背锅”就开始含糊。这篇文章我打算把RAG面试里最常被连环追问的六个方向拆开讲透从原理到优化每个问题都给出我自己的理解和实操经验。适合准备面试的开发者、正在搭RAG系统的工程师以及想搞清楚RAG到底难在哪的产品同学。先给一个整体认知RAG的难点从来不是“能不能跑通”而是“跑通之后效果不好你知不知道问题出在哪个环节”。面试官真正想考的是你有没有一套定位和优化的方法论。2. 第一问RAG的基本链路到底在解决什么问题2.1 把RAG拆成两个阶段来看很多人一上来就背“检索增强生成”但面试官更想听你把链路拆清楚。我习惯把它分成离线索引阶段和在线查询阶段。离线索引阶段做三件事文档解析、切块chunking、向量化入库。文档解析要把PDF、Word、HTML这些格式统一转成纯文本这一步的坑最多表格、页眉页脚、多栏排版经常被解析得乱七八糟。切块是把长文本切成适合检索的小段。向量化是用embedding模型把每段文本转成一个高维向量存进向量数据库。在线查询阶段做四件事把用户问题向量化、在向量库里做相似度检索、把召回的内容和问题拼成prompt、交给大模型生成答案。有些系统还会加一步重排序rerank放在检索之后、生成之前。面试时如果只答“检索然后生成”基本会被判定为没做过。把离线和在线分开讲立刻显得你理解系统的全貌。2.2 为什么是“检索增强”而不是“微调”这是高频追问。我的回答逻辑是微调改变的是模型的“内在知识”成本高、更新慢而且容易灾难性遗忘RAG改变的是模型的“输入上下文”知识更新只需要更新文档库成本低、可追溯。企业场景里文档每天都在变用微调去追这个变化不现实。但要注意RAG和微调不是对立的。如果任务是让模型学会一种特定的回答风格或输出格式微调更合适如果是让模型回答特定知识库里的问题RAG更合适。实际项目里两者经常结合先微调让模型学会“基于给定资料回答”再用RAG喂资料。2.3 一个容易被忽略的前提检索质量决定上限我经常跟团队里新人说一句话RAG的效果上限由检索决定生成模型只是把检索到的东西组织成话。如果检索阶段没把正确资料捞出来再强的生成模型也只能瞎编或者拒答。所以面试里凡是问到优化优先谈检索侧的优化而不是一上来就说换更大的模型。3. 第二问文档切块到底怎么切才合理3.1 切块大小没有标准答案但有判断依据“chunk size设多少”是RAG面试的经典问题。我的经验是没有万能值取决于文档类型和问题类型。常见起点是256到512个token但这只是起点。判断依据有三条。第一看问题的粒度。如果用户问的是“某条款的具体规定”需要小chunk保证精度如果问的是“某事件的整体经过”需要大chunk保证上下文完整。第二看embedding模型的最佳输入长度。很多模型在512token左右表现最好超过之后语义会被稀释。第三看生成阶段能塞多少上下文。chunk太大召回几个就撑爆上下文窗口。我一般会做一组对比实验同一批问题分别用256、512、1024的chunk跑一遍看召回率和最终答案质量。实测下来技术文档512比较稳法律合同256更准叙事类内容1024反而更好。3.2 重叠overlap不是越大越好切块时通常会让相邻块有重叠防止一句话被切断导致语义丢失。常见做法是重叠10%到20%。但我踩过一个坑重叠设太大检索时会召回一堆高度相似的块浪费上下文还干扰生成。后来我把重叠控制在50到100个token效果反而更干净。3.3 比固定切块更好的几种策略固定长度切块最省事但经常把语义切碎。我在项目里试过几种改进方案按语义切块用句子边界、段落边界切保证每块语义完整。可以用简单的规则按句号、换行也可以用模型判断语义转折点。按结构切块Markdown按标题层级切代码按函数切HTML按标签切。这种切法保留了文档的天然结构检索时命中率明显更高。父子块small-to-big检索时用小chunk保证精度但送给生成模型时把它所在的父级大块一起带上兼顾精度和上下文。这个策略我在实际项目里用得最多效果提升明显。面试时如果能说出“小chunk检索、大chunk生成”这个思路基本能证明你真正调过系统而不是只看过流程图。4. 第三问向量检索召回不准问题出在哪4.1 先分清是“没召回”还是“召回错了”召回不准分两种。一种是正确资料根本没被检索出来叫召回失败另一种是正确资料在里面但排得太靠后叫排序问题。这两种的解法完全不同面试时先做这个区分会显得你思路清晰。召回失败常见原因embedding模型和领域不匹配、切块把关键信息切碎了、query和文档的表述差异太大比如用户说“报销流程”文档写“费用核销指引”。排序问题常见原因相似度算法单一、没有重排序、噪声块太多。4.2 混合检索向量加关键词纯向量检索对语义相似但字面不同的情况好但对专有名词、编号、代码这类精确匹配反而弱。我的做法是向量检索加BM25关键词检索两路结果融合。融合算法常用RRFReciprocal Rank Fusion它不依赖分数归一化直接按排名融合实现简单还稳。实测下来混合检索在技术文档和客服知识库场景里召回率比纯向量能提升一截。代价是要维护两套索引查询延迟也会增加需要权衡。4.3 重排序Rerank是性价比最高的优化检索召回一批候选比如top 50再用一个交叉编码器cross-encoder对每个候选和query做精细打分重新排序取top 5。这一步能显著提升送入生成模型的资料质量。我一般把rerank当作RAG优化的第一优先级因为它改动小、收益大。embedding模型是双塔结构query和文档分开编码快但粗cross-encoder把query和文档拼在一起编码慢但准。用粗排召回、精排重排是工业界的标准做法。4.4 查询改写让用户的问题更好检索用户的问题往往口语化、有指代、缺上下文。直接拿去做检索效果差。常见改写手段指代消解把“它”“这个”替换成具体对象需要结合对话历史。查询扩展用大模型把原问题改写成多个相关查询分别检索再合并。HyDE让模型先“幻想”一个答案再用这个答案去检索。因为答案和文档的表述风格更接近检索效果有时更好。这几种我在项目里都用过HyDE在冷启动、文档表述和问题表述差异大时特别有用但会增加一次模型调用延迟要算进去。5. 第四问检索做好了生成还是胡编怎么办5.1 先确认是不是“检索背锅”生成胡编第一反应不该是怪模型而是回去看检索到的资料里到底有没有答案。我见过太多情况是检索没召回正确内容模型只能硬编。所以排查顺序永远是先看召回内容再看prompt最后才怀疑模型。5.2 Prompt里的约束怎么写才有效让模型“基于以下资料回答”这句话太弱了。我一般会加几条硬约束明确要求“只使用提供的资料回答资料中没有的信息不要编造”。要求“如果资料不足以回答直接说不知道”。要求“回答时标注依据来自哪段资料”。但光靠prompt约束不够模型该编还是编。更可靠的做法是让模型输出引用然后做后置校验如果答案里的关键信息在召回资料里找不到对应就标记为可疑或触发兜底。5.3 用“不知道”兜底比硬答更重要企业场景里答错比不答代价大得多。我在系统里加了一个置信度判断如果检索到的资料和query的相似度都低于某个阈值直接返回“暂时没有找到相关信息”而不是让模型硬答。这个阈值需要根据业务容忍度调宁可多拒答几次也别放错误答案出去。5.4 上下文塞太多反而变差有个反直觉的现象召回资料塞得越多生成质量不一定越好。噪声多了模型会被干扰还可能“迷失在中间”lost in the middle——只关注开头和结尾的资料中间的被忽略。所以召回数量要控制配合rerank取最相关的几条通常3到5条就够。6. 第五问RAG系统怎么评估不能只靠感觉6.1 检索和生成要分开评RAG评估最大的误区是只看最终答案好不好。答案不好你根本不知道是检索的锅还是生成的锅。所以要拆成两块评。检索侧指标召回率正确资料有没有被召回、命中率top k里有没有正确资料、MRR正确资料的排名。生成侧指标忠实度答案是否忠于资料、相关性答案是否切题、完整性。6.2 没有标注数据怎么办真实项目里往往没有现成的标注。我的做法是先用大模型自动生成一批“问题-答案-依据”三元组作为评测集人工抽检修正。然后用这套集子跑评估。虽然自动生成的集子有噪声但用来做版本对比足够了——你不需要绝对分数只需要知道新版本比旧版本好还是差。6.3 用LLM当裁判的注意事项用大模型给答案打分LLM-as-a-judge现在很流行但有几个坑模型有位置偏好倾向给靠前的答案高分、有长度偏好倾向给长答案高分。我的应对是打分时交换答案顺序取平均控制答案长度相近并且用明确的评分标准而不是让模型自由发挥。评估这件事面试时能说出“检索生成分开评”和“用LLM当裁判的偏差”基本就超过大多数候选人了。7. 第六问线上RAG系统的性能与成本怎么平衡7.1 延迟都花在哪了一个RAG请求的延迟大致分四块query向量化、向量检索、rerank、生成。生成通常是大头尤其是长答案。检索和rerank相对快但如果候选集大、rerank模型重也会拖慢。优化延迟的常见手段向量检索用近似最近邻ANN索引而不是暴力搜索rerank只对top候选做生成用流式输出让用户先看到部分内容。我一般会先测出各阶段耗时占比再决定优化哪块而不是盲目换模型。7.2 成本控制的实际做法成本主要来自embedding调用、向量库存储、rerank调用、生成token。几个实用做法缓存高频问题直接缓存答案命中就不走全链路。分级检索先用便宜的检索召回再用贵的rerank精排别一上来就全用重模型。控制上下文长度召回资料精简生成token自然少。embedding批处理离线索引时批量调用比逐条便宜也快。7.3 一个我踩过的坑索引更新文档库是动态的新增、修改、删除都要同步到向量库。我早期没设计好更新机制导致检索到已删除的旧文档答案过时。后来改成给每个块打上文档ID和版本号更新时按文档ID批量替换删除时同步清理。这块在面试里如果主动提到会显得你有工程落地经验而不是只搭过demo。8. 面试里那些“送分”和“送命”的细节8.1 主动说出权衡比背标准答案加分RAG没有银弹每个选择都是权衡。面试时如果你能说“我选512的chunk是因为……但代价是……”比直接报一个数字强得多。面试官想招的是能做决策的人不是背参数的人。8.2 别把RAG说成万能有人一被问就吹RAG能解决所有知识问题。实际上RAG对结构化数据查询、多跳推理、需要全局统计的问题都不擅长。承认边界反而显得你理解深。比如问“一共有多少条记录”这种RAG不如直接查数据库。8.3 准备一个你真正调过的案例面试最怕空谈。准备一个你实际做过的RAG项目能说清楚原始效果多少、问题出在哪、你做了什么优化、优化后提升多少。哪怕数据不精确有具体的排查过程就足够有说服力。我自己面人时最看重的就是候选人能不能讲出一个“从坏到好”的完整故事。最后分享一个我自己的习惯每次做完一个RAG项目我都会把“哪个环节最容易出问题、当时怎么定位的”记下来。攒多了你会发现RAG的坑其实就那么几类面试时随手就能举出例子。这比临时背八股文管用得多。