我们团队最近在招做检索增强方向的工程师我负责技术面。面了十几位候选人简历里几乎人人都写“熟悉 RAGRetrieval-Augmented Generation检索增强生成”可真往细了问能从头到尾把原理讲透、把优化路径讲清楚的人大致也就三分之一。很多人能背出“先检索、再拼接、后生成”这个三步走可一旦问到为什么切分参数要这样设、重排在链路上到底起了什么作用、上线之后又该怎么量化评估就开始含糊了。这篇文章把我面试时最高频的6 个连续问题整理了出来按一条实际项目的推进顺序串起来讲先讲清楚 RAG 到底在解决什么问题再拆一条查询从进入到产出的完整链路接着依次深入检索质量、重排序、生成端设计最后落到生产环境里的评估与持续优化。不管你是正在准备面试、打算系统梳理 RAG 知识点还是已经在做项目、想找优化思路都可以对着这套问题自查一遍。1. 第一问模型知识库里什么都有为什么还要外接一个检索器RAG 面试的第一个问题通常不是“RAG 是什么”而是“RAG 解决了什么问题”。这个切入点最能区分候选人是在背概念还是真的理解大模型应用的痛点。1.1 幻觉、时效性和可溯源性三个绕不开的坎先看一个最日常的场景。你问一个通用大模型“你们产品里批量导出的快捷键是什么”它可能会一本正经地给你编一个组合键说完还特别自信。这其实就是大模型的“幻觉”问题——它的参数里存储了大量从训练语料中学到的模式但底层运行机制是“根据上文预测下一个 token”而不是“去资料库查答案”。所以当问题超出它的可靠记忆范围时它就会用概率推断去补全一个听起来合理的答案。除了幻觉还有时效性。大模型的参数知识截止于训练数据采集的那一天之后发生的事情它一概不知。你今天刚更新了产品手册模型不会自动同步除非重新做一次训练或微调。对很多业务场景来说这种“知识冻结”是致命的。第三个问题是最容易被忽略的可溯源性。你说模型的答案来自某个报告可它引用错了、甚至引用了不存在的内容你怎么追责纯靠参数生成的答案没有“来源”这个概念出了问题很难定位。针对这三个痛点RAG 给的方案是不把知识硬塞进模型参数里而是在生成前先去外部知识库检索相关资料再把资料拼进上下文让模型基于这些真实资料作答。打个不太恰当比喻这就像你身边有一位知识面很广但记性随缘的老同事你更放心的做法不是让他凭记忆回答而是让他先翻开操作手册再告诉你结论。在 RAG 出现之前业界也不是没有尝试过微调方案——把资料喂给模型训练让它“记住”。这个方向确实能解决一部分问题但代价非常大。1.2 RAG 和微调的边界不是二选一而是看分工很多人面试时会把 RAG 和微调对立起来认为“现在有了 RAG微调已经过时了”这个说法其实不够准确。两者的本质差异在于纬度不同对比维度微调RAG知识更新速度慢每次更新都要重新训练周期以天/周计快换索引、换文档即刻生效周期以分钟计训练成本高需要算力和精心构造的数据集低不需要改模型权重只做向量化建库可解释性差答案来源难以追踪好可以定位到具体被检索到的片段幻觉治理弱模型仍可能凭记忆发挥强生成被限定在检索资料范围内私有知识支持需要单独准备训练语料直接建立索引即可擅长场景输出格式控制、语气风格、特定任务行为对齐事实性知识问答、实时资料查询、私有文档问答更准确的理解是RAG 解决的是“知识来源与时效”问题微调解决的是“能力与表达方式”问题。比如你想让模型统一用 JSON 格式输出、学会某种工具调用的流程这适合微调但产品文档里的具体参数、最新政策条款这类事实性内容直接用 RAG 挂在外部更高效。提示面试里答这道题不要只抛结论最好补一句“RAG 解决的不是模型智商问题而是知识范围、更新频率和事实可溯源问题”这会明显区别于只会背定义的人。2. 第二问一条查询从进门到出门RAG 内部到底干了哪些活如果说第一问考的是动机第二问考的就是全景图。这个话题回答得越结构化越说明你真正跑过完整流程。2.1 线下建库与线上查询两条链路缺一不可RAG 不只是一条“查询→检索→生成”的直线它实际上由两条相对独立、但都必须打通的链路组成。链路一线下索引构建离线这步决定了知识库的“底子”文档加载从 PDF、Word、Markdown、HTML、数据库等来源获取原始材料。格式解析与清洗不同文档格式的解析差异极大。PDF 要处理表格、页眉页脚扫描件可能还需要 OCR表格内容容易被切碎网页要去掉导航和脚本噪声。每一类文档都要单独写清洗规则。切分Chunking按一定策略把长文档切成小块。这一步直接决定后续检索粒度的粗细。向量化用嵌入模型把每块文本转成向量。向量入库把向量和原始文本以及元数据一起写入向量数据库建立索引。链路二线上查询服务在线用户发起一次查询时查询预处理改写、扩展、抽取关键词或者判断是否需要走多轮对话补全。查询向量化用同一个嵌入模型把 query 转成向量。相似性检索在向量库里做最近邻搜索取 top K 候选。重排序可选但强烈推荐对检索回来的候选片段做一次更精细的打分和筛选。构造 Prompt把筛选后的片段作为上下文注入提示词再加上指令和对话历史。生成大模型阅读上下文生成最终回答并在必要处引用来源片段编号。流程本身不复杂但工程化之后到处都是细节。举个最常见的坑很多人只做“文本 → 向量 → 入库”这样的最小闭环完全不采集文档的元数据信息等到需要按业务线隔离、按更新时间过滤时就只能重新清洗数据、重建索引。2.2 元数据与过滤条件向量相似度只是第一层筛选“向量检索”这个名字容易让人产生一个误解以为只要算相似度就够了。实际上生产级的 RAG 系统几乎一定会叠加多层过滤条件。比如文档要按权限隔离A 租户的用户不能检索到 B 租户的资料某些答案需要限定时间范围去年发布的旧版操作说明不该出现在“最新流程”问答里文档有来源渠道有些知识只面向特定业务线开放。这些需求如果不在建库时把来源、部门、权限级别、发布时间等字段作为元数据存进向量库上线后就是一个灾难。我有一个项目就是因为前期没做权限字段的过滤导致内部人员测试时检索到了另一条业务线的资料虽然标题相似度确实高但内容完全不对口最后花了两周重建索引才解决。提示讲全链路的时候建议顺便提一句“RAG 的检索结果不是靠余弦相似度一锤定音而是‘相似度得分 元数据过滤 重排序’三层筛选的结果”这句话很容易体现工程经验。3. 第三问检索质量上不去卡点往往不在向量库里很多做 RAG 的新人最早遇到的困惑是我用了一个不错的向量库也写了标准的检索代码为什么召回结果总是不尽如人意于是开始怀疑向量数据库选型不行。以我的经验80% 的检索质量问题出在向量库之前和之后而不是向量库本身。3.1 切分策略chunk 的粒度决定了召回的上限检索训练里有一个基本矛盾chunk 切得越小召回越精准但可能丢失上下文逻辑切得越大上下文越完整但噪声也跟着变大而且很容易超过嵌入模型和生成模型的长度上限。常见的切分策略大概有四种切分策略基本思路适用场景典型问题固定长度切分按字符或 token 数等长切开快速原型验证会把句子、段落从中截断语义碎片化滑动窗口重叠切分相邻 chunk 之间保留部分重叠需要平衡粒度与语义连续性的通用场景重叠比例和窗口大小需要调参递归/结构化切分按段落、标题、列表等层级逐级切分文档本身有清晰结构的场景对文档解析质量要求高语义切分按句子向量相似度变化点断开主题变化明显的长文档计算量大切分边界不稳定在中文场景里我比较推荐的做法是以语义单元为主、配合参数化控制优先按句号、问号、段落边界切分再限制每个 chunk 的 token 窗口。举个例子如果嵌入模型支持 512 token 的上限chunk 目标长度设在 300500 token 之间比较稳妥overlap 控制在 10%20%避免关键句正好落在切缝附近而被截断。这里要给一个基础概念补充token 和字的数量不是一回事。一个中文字在常见分词器里大约对应 0.61.5 个 token同一个“500 token”在不同模型里对应的实际文本长度是不同的。所以做参数设计时要以你实际选用的嵌入模型为准不要照搬别人的字符数。3.2 嵌入模型的影响比向量库大得多我见过不少团队花大量精力调研向量数据库的特性、对比性能却忽略了一个更本质的问题文本向量是谁生成的嵌入模型的质量直接决定了“语义相似”能不能被正确表达。选择嵌入模型时有几个实际经验可以参考开源中文向量模型与调优版模型的差异很明显。通用模型可能在通用领域的相似度上有不错表现但换到法律、医疗、金融这种垂直领域同一个模型的表现可能明显下降。如果预算允许优先选在目标领域语料上做过微调的版本。注意模型对长文本的支持上限。有的模型单次最多只能编码 512 token你非要往里塞 2000 token 的 chunk长出来的部分会被静默截断实际索引的只有前半段。query 和文档的编码模式最好一致。很多嵌入模型对检索侧和待检索侧有不同的输入模板比如会给查询加“查询问题”的前缀。你建库时用了 document 模板查询时也一定要用配套的 query 模板否则效果会打折。向量维度和检索精度不是简单的正相关。高维度向量能表达更细的语义但内存消耗和检索延迟都会上升需要按实际数据量权衡。3.3 混合检索词面匹配与语义匹配是互补关系再往下聊就绕不开混合检索。纯向量检索擅长语义相似和同义改写但在人名、编号、型号、精确术语这类场景下反而不如传统的关键词检索。这两个方向不是互斥的而是互补的。你可以把“BM25 关键词检索 向量检索”的结果做一个融合典型的融合方式有两种加权合并两路结果各自打分按权重线性加权再统一排序。互惠排名融合RRF不直接比较两边的分数而是按各自排名取倒数派生分再做合并。这个方法的好处是不需要统一两路分数的量纲实际项目中挺常用。这里也解释一下 BM25 是什么方便新手理解BM25 是一种经典的关键词匹配打分算法核心思路是“词在文档里出现得越频繁、文档越短、词越稀有得分越高”。它和 vector 相似度走的是完全不同的逻辑所以很适合做互补。注意检索优化有一个公认的经验——先诊断“哪类 query 召回差”再决定要不要上混合检索。不要一上来就把关键词检索、多路召回、rerank 全部加上否则系统复杂度上去了你反而很难判断每一层到底贡献了多少。4. 第四问召回集里混进了噪声怎么用重排序兜底检索之后理想状态是拿回来的片段全都相关但现实中召回结果往往掺杂着不少“看起来沾边、实际没多大用”的内容。这时候重排序就该上场了。4.1 从“召回”到“精排”两阶段漏斗的核心思路把召回和重排分开本质上是在把两个互相冲突的目标解耦。可以把它类比成招聘流程向量召回是 HR 海选简历标准是简历里包含关键技能关键词宁多勿漏重排序则是业务面试官精面标准是候选人能不能真正胜任这份工作宁缺毋滥。向量检索阶段为了召回率通常会放宽阈值把 top 20 甚至 top 50 的候选都捞回来但大模型的上下文窗口是有限的你把 50 个片段全塞进去不仅可能超长而且模型的注意力会被大量无关信息搅乱回答质量直线下降。所以需要一个“精排”环节把候选压缩到 top 35。重排序模型和嵌入模型的核心区别在于嵌入模型是把 query 和文档分别编码成向量再用余弦相似度衡量这种方式检索效率高但损失了文本间细粒度的交互信息重排序模型则会把 query 和文档拼接在一起做全词交互编码打分更准但计算成本也更高。在实际项目中我对重排序的基本建议是召回阶段用向量检索取 top 20 候选保证信息不遗漏。重排阶段用交叉编码器对 20 个候选重新打分取 top 35 进入生成阶段。如果 latency 紧张可以考虑先用粗排过滤到 top 10再做一次精细重排把耗时控制在可接受范围内。4.2 重排时的几个工程坑阈值、截断与延迟重排序不是简单的“多加一步”这层如果处理不好反而会引入新问题。重排分数不能直接用向量相似度来对比。两者的分数量纲完全不一样向量检索的余弦相似度普遍在 0.70.9 之间重排模型给出的可能是一个 logit 分数甚至可能是负数。很多调参经验走到这里就崩了。要不要设阈值过滤我的经验是重排后如果 top 结果分数明显低于训练阶段的平均水平宁可不返回也不要硬塞给大模型。否则生成阶段的“忠实度”指标会很难看。重排序模型通常比嵌入模型重很多。它一次要处理 query 和候选文档的拼接如果一次来了 20 个候选就需要 20 次前向计算延迟显著上升。线上系统里往往需要做缓存策略、并发调控甚至把重排模型专门部署成独立服务避免拖垮主链路。注意输入长度限制。重排模型同样有最大 token 限制如果候选片段特别长会被截断。所以做重排前最好先按长度做一次粗筛把过长或明显不相关的片段先去掉再交给重排模型。提示面试时如果被问到“检索回来的都能用吗”直接回答“不能需要重排”只会显得背了模板。更好的答法是把“召回率高但精度低”这个矛盾讲清楚再引出重排是为了在生成前做一次性价比最高的精选。5. 第五问生成端怎么设计才能让模型“引用资料”而不是“自由发挥”检索链路做完了任务还没结束。你会发现同一个检索结果不同 prompt 下生成的答案质量差异很大。生成端的设计本质上是在约束模型“必须基于资料说话”。5.1 Prompt 设计把检索结果“焊”进回答里先说一个原理大模型没有天然的“引用意识”它在对话中更倾向于“生成一个流畅合理的回答”而不是“严格执行某段资料”。所以你必须通过 prompt 进行强约束。一个在生产环境里被我反复验证过的模板大致长这样请根据以下资料回答问题。资料内容用context标签包裹。 context [1] 根据产品手册批量导出功能位于设置 - 数据管理 - 导出 支持CSV和Excel两种格式单次最多导出5万条记录。 [2] 如果记录数超过5万条系统会自动拆分为多个文件并通过 站内消息通知用户下载。 /context 要求 1. 只依据资料内容回答不要使用资料之外的常识或记忆 2. 如果资料中没有相关信息明确回答“资料中未包含该信息” 3. 回答时在引用处标注来源编号形如[1] 4. 保持简洁先给出结论再补充细节。 问题批量导出的上限是多少超过上限会怎样这个模板的核心在于三条约束限定资料范围、允许拒绝回答、强制来源标注。真实项目里模型偶尔还是会“忍不住”想用自己的记忆补充几句解决办法是在生成参数上做配合比如把温度调低一些减少随机发挥的空间。这里要注意信息来源标注不只是为了让答案好看它能大幅提升可排查性——当用户反馈答案有误时你能直接定位到是检索到的资料有误还是生成逻辑出了问题。这是 RAG 系统在生产环境中必须具备的可观测能力。5.2 微调和 RAG 不是二选一而是可以组合成多层方案上一节讲过 RAG 和微调的宏观区分这里补充一个落地级的判断规则。我在实际项目中是这样取舍的适合微调希望模型固定以某种格式输出、想改变它的语气风格、需要它按特定方式调用工具。这些属于“行为对齐”微调效果稳定RAG 则很难控制。适合 RAG事实性知识、最新资讯、企业内部资料、需要追溯来源的内容。这些属于“知识注入”RAG 改动成本低、可实时更新。组合玩法先用微调让模型学会“当我给出资料时你要严格引用”再用 RAG 动态提供资料。这样责任分离各自发挥各自的长处。有经验的人还会注意一个细节微调数据的构建方式对 RAG 也有影响。如果在微调阶段就加入“资料引用”的示例模型会把“看资料再答”内化成一种行为习惯这对 RAG 生成端的鲁棒性有非常明显的帮助。6. 第六问从 Demo 到生产RAG 优化到底在优化什么这可能是区分“跑过 Demo”和“做过产品”最关键的一道题。一个检索增强系统能在 demo 里跑通和能稳定服务于线上业务中间隔着一整套评估和迭代体系。6.1 评估优先没有评测集一切优化都是空谈很多团队的现状是凭感觉调参。今天觉得 chun大小调到 400 效果好了明天又觉得 600 更好但从来没有人定义过“效果更好”到底是什么意思。没有量化指标优化就是一团乱麻。在生产环境里我建议至少建立三层的评估体系评测集构建从真实业务里抽取 100300 条典型问题覆盖高频问题、边界问题、语义近似问题、文档缺失问题。每条标注好标准答案和支撑文档来源。分环节指标单独测检索质量命中率、召回准确率、上下文相关性单独测生成质量答案正确性、忠实度、完整性。不要把两段混在一起看否则有问题时你根本不知道是哪段的责任。线上回归每次修改切分参数、更换嵌入模型或调整 prompt 之后都要跑一遍评测集做对比记录哪些类型的 query 变好了、哪些变差了。具体到指标可以关注几个业界常用的口径忠实度衡量答案是否严格基于检索资料有没有凭空捏造答案相关性衡量回答是否切题上下文相关性衡量检索回来的片段与查询有多少关联。忠实度这一项特别值得盯它直接对应着 RAG 最初要解决的幻觉问题。6.2 检索结果的补救手段查询改写与多轮迭代评测集建立之后你会发现在某些 query 上检索环节就是不合格。此时不要直接调 embedding 模型成本太高一般先尝试更轻量的补救手段。查询改写把用户的口语化 query 改写成更利于检索的表达。比如用户问“上次说的那个功能在哪”改写模块会先补全指代再进入检索。HyDE 思路先用大模型针对 query 生成一个“伪答案”再用这个伪答案去检索利用“问题与答案表达更接近”的特性提高召回率。这个思路在文档表述和用户表述差异较大时很有效代价是多一次生成调用延迟会高。多轮迭代式检索第一轮检索后如果模型判断信息不足可以依据已有信息扩展 query 再次检索直到收集到足够的信息再作答。这种做法能缓解复杂问题一次检索不全的问题但要注意控制迭代轮数别让延迟失控。CRAG / 自反思类思路对检索回来的片段先做一轮质量判断如果判断为相关度低就触发额外检索或直接生成“资料不足”的回答如果判断为存在矛盾还需要后续的处理策略。这些看起来很高大上的方案本质都是围绕“query ↔ 文档”匹配不足的问题在做针对性修补。我的建议是先把基础检索和切分调到稳定再上这些进阶手段否则你只是在用复杂度掩盖上游没解决的根因。6.3 可观测性把每次查询变成可复盘的数据最后想强调一个常被忽略的环节——日志与可观测性。RAG 线上链路较长问题可能是文档解析出来的、嵌入模型编码坏的、重排阈值切掉的、prompt 没约束住的、大模型本身答偏的。你不把中间环节的数据记录下来就只能黑盒排查。我在项目里通常会给每个请求打上这样的日志原始 query、改写后的 query召回的 top 20 候选及其分数重排后最终送入 prompt 的 top 3 片段及分数模型生成的原始答案不做截断端到端的延迟拆分检索耗时、重排耗时、生成耗时。有了这些日志bad case 复盘就变成了一件很具体的事定位到某一环节后再去调整对应模块并且可以在评测集上验证调整是否真的有效。这套机制积累久了你会慢慢总结出自己知识库特有的“常见病”比如“PDF 表格切碎导致遗漏”“查型号必须走关键词”“跨语种同义词检索必须改写”。最后再分享一点实际运行的体会我见过太多团队把 90% 的精力花在尝试各种时髦技巧上真正上线后反而被最基础的文档解析问题反复折磨。RAG 的优化顺序永远是先把数据质量做扎实、把评估机制建立起来再谈策略升级。如果你只能做一件事那我建议你先去把你的评测集建好并且让每次修改都能在评测集上留下可对比的痕迹。有了这条底后面无论换模型、调参数还是加路由你都走在对的路上。