1. 为什么RAG成了面试里的“必答题”
这两年只要简历上写了“大模型应用”“知识库问答”“智能客服”这类关键词，面试官几乎一定会往RAG方向追问。原因不复杂：微调成本高、周期长，而RAG（Retrieval-Augmented Generation，检索增强生成）能用相对低的代价把私有知识接进模型，还能缓解幻觉、支持知识更新。企业落地时，RAG往往是第一个真正跑起来的方案，所以面试官问的不是“你听没听过”，而是“你到底做没做过、踩没踩过坑”。
我面过也被人面过，发现一个规律：初级候选人能说清“先检索再生成”，中级能讲出向量库和切分策略，高级则能把召回率、重排、评估、成本这几件事串起来讲。标题里说的“6连问”，其实就是面试官从原理到优化的一条追问链。这篇文章我按真实面试的节奏，把这6个问题拆开讲透，每个问题都给出“面试官想听什么”“你怎么答”“背后的原理和坑”。不管你是准备面试，还是正在搭自己的RAG系统，都能直接拿去用。
先给一个整体认知：RAG的本质是“用检索结果约束生成”，它把大模型从“凭记忆答题”变成“开卷考试”。开卷考试考得好不好，取决于三件事——书找得对不对（检索）、书页给得全不全（上下文组织）、答题人会不会抄（生成）。面试的6连问，基本都围绕这三件事展开。
2. 第一问：RAG的基本流程和它到底解决了什么问题
2.1 一句话讲清RAG的完整链路
面试官问“讲讲RAG流程”，很多人背的是“文档切分、向量化、检索、拼接、生成”。这个答案没错，但太像背课文。我一般会这样答：离线阶段把私有文档做清洗、切分成块（chunk），用嵌入模型编码成向量存进向量库；在线阶段把用户问题也编码成向量，去库里做相似度检索，取回Top-K个块，按一定策略拼进Prompt，最后交给大模型生成答案。如果要做得好，中间还要加重排（rerank）、查询改写、上下文压缩这些环节。
这里有个容易被忽略的点：离线阶段和在线阶段的嵌入模型必须是同一个。我见过有人离线用A模型建库，在线用B模型编码query，结果检索出来的东西驴唇不对马嘴，排查了半天才发现是模型不一致。这个坑在面试里讲出来，面试官会觉得你是真做过。
2.2 RAG解决的三个核心痛点
第一是知识时效性。模型训练有截止日期，企业内部制度、产品价格、最新政策这些它根本不知道，RAG把最新文档喂进去就行，不用重新训练。第二是幻觉。模型在不知道答案时会一本正经地胡说，RAG给它真实材料，让它“有据可依”，幻觉率能明显下降。第三是数据隐私与成本。私有数据不用拿去微调，放在自己的向量库里，生成时只把相关片段送进模型，既可控又便宜。
但要注意，RAG不是万能药。如果检索没召回正确内容，模型照样会编；如果召回了矛盾内容，模型可能被带偏。所以面试时如果你只夸RAG好，反而显得没深度。我通常会补一句：“RAG降低幻觉的前提是检索质量过关，检索这一环才是真正的瓶颈。”
2.3 和微调的区别，面试官为什么爱问
这个问题几乎必问。我的答法是：微调改的是模型参数，适合教模型“说话风格”“任务格式”“领域语言习惯”；RAG改的是输入上下文，适合让模型“知道具体事实”。两者不是替代关系，实际项目里经常一起用——微调让模型更懂业务表达，RAG让它拿到最新事实。
举个生活化的类比：微调像是送一个人去培训，让他学会某个行业的说话方式；RAG像是给他配了一个随时能查的资料库。培训完他说话像行家了，但具体数字还得查资料。面试官听到这个类比，基本就知道你理解到位了。
3. 第二问：文档切分和向量化，细节里全是坑
3.1 chunk切分策略怎么选
切分是RAG里最不起眼但最影响效果的一步。切太大，一个块里混了好几个主题，检索时噪声多；切太小，语义不完整，模型拿到半句话没法用。常见做法有固定长度切分、按标点/段落切分、递归切分、按语义切分。
我实际项目里的经验是：优先按文档结构切，再按长度兜底。比如Markdown按标题层级切，PDF按段落切，代码按函数切。如果文档没有明显结构，用递归字符切分（RecursiveCharacterTextSplitter这类思路），分隔符优先级设为“段落→句子→逗号”，尽量在语义边界断开。chunk大小一般设在300到800个token之间，overlap设10%到20%，防止关键信息正好被切断。
注意：overlap不是越大越好。overlap太大，检索结果里全是重复内容，浪费上下文窗口，还容易让模型重复输出。我一般从10%起步，根据评估结果微调。
3.2 嵌入模型怎么选，别只看排行榜
嵌入模型决定了“语义相似”判得准不准。选型时我会看几个维度：中文效果、维度大小、推理速度、是否支持长文本、部署成本。中文场景下，很多开源嵌入模型表现不错，但要注意有些模型对长文本会截断，超过最大长度直接丢内容。
这里有个实操坑：嵌入模型的训练目标和你的检索目标可能不一致。有些模型擅长句子相似度，但你的场景是“问题找答案”，问题和答案的表述差异很大，纯语义相似未必召得回。这种情况可以考虑用带指令的嵌入模型，或者用“问题-答案对”做微调。面试时能提到“检索任务和语义相似任务不完全等价”，是个加分项。
3.3 向量库选型的取舍
向量库这块，面试官常问“你用的什么，为什么”。我的思路是分场景：数据量小、想快速验证，用内存型或轻量库就够；数据量大、要持久化、要过滤，就上专业向量数据库；如果已经有关系型数据库，也可以用它自带的向量扩展，减少运维成本。
选型时重点看：是否支持元数据过滤（比如按部门、时间过滤）、是否支持混合检索（向量+关键词）、召回性能、水平扩展能力。我踩过的坑是：早期只存了向量没存元数据，后来想按权限过滤，发现根本没法做，只能重建库。所以建库时一定要把元数据字段设计好，哪怕当时用不上。
4. 第三问：检索策略，为什么你的召回总是不准
4.1 纯向量检索的天然缺陷
向量检索擅长语义匹配，但对精确匹配很弱。比如用户问“工单编号TK-2024-001的处理进度”，向量检索可能召回一堆“工单处理流程”的文档，却漏掉那条具体记录。因为编号这种token，嵌入后语义信息很弱。
解决办法是混合检索：向量检索负责语义召回，关键词检索（BM25这类）负责精确召回，两路结果融合。融合常用RRF（Reciprocal Rank Fusion，倒数排名融合），它不依赖分数归一化，直接把两路排名做加权，简单又稳。我实测下来，混合检索在含专有名词、编号、缩写的场景里，召回率提升非常明显。
4.2 查询改写：用户问得烂，你得帮他问好
真实用户的问题往往很短、有错别字、指代不清。比如“那个报销的咋弄”，直接拿去检索效果很差。查询改写有几个常用手段：一是指代消解，结合多轮对话把“那个”补全；二是查询扩展，用大模型把问题改写成多个相关查询，分别检索再合并；三是HyDE，让模型先“假装”生成一个答案，再用这个答案去检索，因为答案和文档的表述更接近。
HyDE这个思路挺巧妙，面试时提出来很加分。它的逻辑是：用户问题短，文档长，两者在向量空间里距离远；但生成的假答案也是长文本，和真文档距离近，更容易召回。当然代价是多一次模型调用，延迟会增加。
4.3 重排：把真正相关的顶上来
检索取Top-K，K通常设得比较大（比如20到50），因为向量相似度高不代表真的相关。这时候加一个重排模型（rerank），对候选做精细打分，取Top-N（比如3到5）送进生成。重排模型通常是交叉编码器，把query和文档拼在一起打分，精度比向量点积高，但速度慢，所以只用在候选集上。
我的经验是：重排是性价比最高的优化之一。很多团队检索效果差，不是嵌入模型不行，而是没做重排，把一堆“看起来像”的文档直接喂给了模型。加个重排，答案准确率经常能涨一截。面试时如果能把“召回用双塔、精排用交叉”这个分工讲清楚，说明你懂检索系统的经典架构。
5. 第四问：上下文怎么组织，别把模型撑死
5.1 上下文窗口不是越大越好
现在模型上下文动辄几十万token，很多人就觉得“那我全塞进去”。实际上，塞太多有三个问题：一是贵，token是要花钱的；二是慢，长上下文推理延迟高；三是**“迷失在中间”**，模型对超长上下文中间部分的信息利用率会下降，关键内容放中间容易被忽略。
所以上下文组织要讲究。我一般把最相关的块放前面，因为模型对开头和结尾的信息更敏感。如果块之间有逻辑顺序（比如步骤、时间线），就按顺序排。如果块之间无关，就按相关性排。别小看这个顺序，实测对答案质量有影响。
5.2 上下文压缩和去重
检索回来的块经常有重复内容，尤其是overlap设大了，或者多个块来自同一段落。重复内容既浪费窗口又可能让模型重复输出。做法是：先做去重（按内容相似度或块ID），再做压缩。压缩可以用模型对每个块做摘要，只保留和问题相关的句子；也可以用句子级相关性打分，把不相关的句子删掉。
这里有个取舍：压缩会引入额外模型调用，增加延迟和成本，还可能丢信息。我的建议是，如果上下文没超窗口、成本可接受，优先保证信息完整，别过度压缩。只有在窗口紧张或成本敏感时才上压缩。
5.3 Prompt模板的设计细节
Prompt模板看着简单，其实很影响效果。一个稳的模板通常包含：角色设定、任务说明、上下文标记、问题、输出格式要求、以及“如果上下文没有答案就明说”的约束。最后这条特别重要，它能显著降低幻觉——告诉模型“不知道就说不知道”，比让它硬编要好得多。
我常用的结构是：先给一段系统指令，说明“你是基于给定资料回答的助手，只依据资料回答，资料没有就说无法回答”；然后用明确的分隔符把资料包起来，比如用XML标签或三引号；最后放问题。分隔符要清晰，避免模型把资料和问题混在一起。面试时能说出“用分隔符隔离上下文和问题”这种细节，说明你真写过Prompt。
6. 第五问：怎么评估RAG效果，别只会说“感觉还行”
6.1 评估要拆成检索和生成两部分
很多人评估RAG就是“找几个问题试试，看着还行”。这在面试里是减分项。专业做法是拆开评：检索阶段看召回率、命中率、MRR（平均倒数排名）、NDCG；生成阶段看答案正确性、忠实度（是否基于上下文）、相关性。
检索评估需要标注“每个问题对应的正确文档块”，然后看检索结果里有没有、排第几。生成评估可以用模型打分，也可以用人工。现在有一些开源评估框架，能自动算忠实度、答案相关性这些指标，省不少事。
6.2 忠实度和幻觉怎么量化
忠实度衡量的是“答案里的每句话是否都能在上下文里找到依据”。做法是把答案拆成句子，逐句判断是否被上下文支持。这个可以用模型来做，也可以用NLI（自然语言推理）模型判断“上下文能否推出这句话”。
幻觉的量化就是看忠实度低的比例。我实际项目里发现，加了“资料没有就说不知道”的约束后，幻觉率能降不少，但代价是有些本来能答的问题变成“无法回答”。所以要在“敢答”和“不乱答”之间找平衡，这个平衡点要靠评估数据来定，不能拍脑袋。
6.3 建立回归测试集
RAG系统改一个参数（比如chunk大小、Top-K、重排模型），效果可能变好也可能变差。没有回归测试集，你根本不知道改动是正优化还是负优化。我的做法是：从真实用户问题里采样，人工标注标准答案和对应文档，形成一个几十到几百条的测试集。每次改动跑一遍，看指标变化。
这个测试集不用一开始就很大，20到50条就能看出趋势。关键是要覆盖典型场景和边界情况：常见问题、长尾问题、需要多跳推理的问题、上下文里没有答案的问题。面试时提到“我维护了一个回归测试集”，面试官会觉得你有工程化思维。
7. 第六问：优化和落地，怎么把RAG做得又快又准
7.1 性能优化的几个抓手
RAG的延迟主要花在三块：检索、重排、生成。优化思路是分别下手。检索这块，可以用ANN（近似最近邻）索引加速，牺牲一点精度换速度；可以缓存高频query的检索结果；可以把嵌入模型量化或换更小的模型。重排这块，可以只对Top-K的前一部分做重排，或者用更轻量的重排模型。生成这块，可以流式输出让用户先看到内容，可以限制输出长度，可以用更小的生成模型处理简单问题。
我实际做过的优化里，缓存效果最直接。很多业务场景问题重复率高，把“query→检索结果”缓存起来，命中时直接跳过检索和重排，延迟能降一大半。当然缓存要考虑失效策略，文档更新后要能刷新。
7.2 成本控制：token就是钱
成本主要来自嵌入调用、模型生成、向量库存储。嵌入调用是一次性的（离线建库），但文档更新时要重新嵌入，量大也不便宜。生成是持续成本，每次问答都要调模型。控制生成成本的办法：减少送进模型的上下文长度（靠重排和压缩）、用更便宜的模型处理简单问题、设置输出长度上限。
有个容易被忽略的点：别把整个文档塞进上下文。我见过有人图省事，检索到文档后直接把整篇文档喂进去，token哗哗地烧。正确做法是只送相关块，块的大小也要控制。
7.3 上线后的持续迭代
RAG不是上线就完事，它需要持续迭代。迭代的输入来自两方面：一是用户反馈（点赞点踩、追问、转人工），二是评估指标。我会把用户点踩的问题收集起来，分析是检索没召回、还是生成没答好，然后针对性优化。如果是检索问题，看是切分不合理还是嵌入模型不行；如果是生成问题，看是Prompt没写好还是模型能力不够。
还有一个实践：记录每次问答的检索结果和生成答案，方便事后排查。用户说“答错了”，你能立刻回看当时召回了什么、模型看到了什么，定位问题快很多。这个日志在面试里提出来，说明你考虑过可观测性，是加分项。
8. 面试里那些容易被追问的边角问题
除了6连问，面试官还爱问一些边角但能区分水平的问题。比如“多轮对话怎么处理”，答案是：把历史对话做摘要或改写，把指代消解后的独立问题拿去检索，而不是把整段历史塞进去。再比如“文档更新了怎么办”，答案是：增量更新，只重新嵌入变化的文档，删掉旧向量，避免全量重建。
还有“权限控制怎么做”，答案是：在元数据里存权限标签，检索时按用户权限过滤，确保用户只能召回自己有权限看的文档。这个在企业场景里特别重要，答不上来会显得没落地经验。
最后说个心态问题：面试官问RAG，不是要你背标准答案，而是看你有没有真实做过、有没有思考过取舍。同一个问题，不同场景答案不同，你能说出“这取决于……，如果……我会……”，比背一个绝对答案强得多。我面人的时候，最怕听到“标准流程是……”，最喜欢听到“我遇到过……，后来发现……”。真实经验，永远比背诵值钱。
