做 AI 应用落地的人大概率都卡在同一个选择题上手里的模型回答问题不准到底是该给它外挂一个“知识库”还是直接把它“再教育”一遍这两个方向的代表方案就是 RAG 和模型微调。RAG 全称 Retrieval-Augmented Generation检索增强生成简单说就是在模型回答之前先从外部数据库里捞一段相关内容塞进上下文让它照着说模型微调则是拿一批标注好的数据继续训练原有模型把新的知识、风格和能力固化进参数里。两者解决的问题有重叠但底层逻辑完全不一样。我这两年陆续做过几个知识问答类的项目从最开始的“闭眼微调”到后来“RAG 优先、微调兜底”中间踩过不少坑。这篇文章不打算做太多理论搬运重点把两者在真实项目里的区别、选型思路和实操经验讲透希望能帮正在纠结的人少走弯路。1. 先搞清楚两件事的定位RAG 是外挂微调是重塑在对比之前得先建立一个基本共识RAG 和微调并不是同一层级的东西。RAG 更像一种“系统架构方案”它依赖检索组件、向量数据库、排序逻辑和生成模型共同工作而微调是“模型训练手段”它直接修改模型内部的权重。一个改的是外部流程一个改的是内部参数。这个定位上的差异决定了后续几乎所有选择。1.1 两者的起点不一样RAG 的起点是“模型不会的知识我可以临时喂给它”。比如某个企业内部有几千份制度文件模型预训练时根本没见过这些内容你不想重新训练模型也不想让模型凭空“记住”这些文件那就每次提问时先从文件库里检索出最相关的几段拼到提示词里让模型基于这些材料回答。微调的起点则是“模型的能力短板我想让它内化掉”。比如模型输出格式总是不稳定或者回答风格过于书面化你希望它变成一个“永远用活泼语气回复”的客服助手这种能力不是靠临时塞一段文字能解决的而是要让模型在大量样例中学习到这种模式最终固化在参数里。一个常见的误解是“微调可以让模型学到新知识”。严格来说微调也能让模型“记住”一些新事实但它的成本远高于 RAG而且存在灾难性遗忘的风险。对大多数动态更新的业务知识用微调去记住是得不偿失的。1.2 两者的知识来源不一样RAG 的知识来自外部载体可以是向量数据库、关系型数据库、对象存储里的文档、甚至搜索引擎结果。只要在回答前能被检索到并放进上下文都算 RAG 的范畴。这意味着知识的更新非常灵活——文档改了一版把新文档重新切片入库下一次查询就能用到最新内容。微调的知识来源则只能是“训练数据”。你需要把知识整理成问答对、指令对或者其他格式的样本喂给模型做监督学习。一旦训练完成知识就冻结在模型参数里。如果业务知识变了你得重新准备数据、重新训练、重新评估、重新发布整个周期以天甚至周计算。我做过一个模拟项目 X产品的帮助文档每周更新两次。用 RAG 方案时每次更新只需跑一次文档入库脚本十分钟搞定但当时为了对比我硬是尝试把同一批文档微调进一个小模型光整理训练数据就花了三天而且新文档出来后旧模型立刻过时。这个例子很能说明问题知识变动频率越高的场景RAG 的维护优势越明显。1.3 两者的行为表现不一样RAG 的行为特征是“上下文敏感”。模型是否引用检索到的内容取决于检索结果的质量、提示词的写法、上下文窗口的长度。你给的材料太杂模型可能答非所问材料顺序不对模型可能忽略关键信息材料里有矛盾说法模型甚至会自己挑一个“看起来更合理”的。这种方案的可控性来自检索链路而不是模型本身。微调的行为特征是“风格固化、知识稳定”。训练完成后模型在任何对话里都会稳定地表现出训练数据中的模式。比如你训练它“先复述用户问题、再给结论、最后列依据”它基本都会照做。但缺陷也很明显它一旦学会了某种错误回答你要花同样甚至更大的成本去纠正而不是像 RAG 那样直接删掉一段错误文档就能解决。用生活化类比来说RAG 是把资料放在手边的“开卷考试”模型可以翻阅资料再作答微调是让模型“背熟某些考点的闭卷考试”。开卷考试的优势在于资料可以随时换劣势在于模型不一定找得到、也不一定照资料写闭卷考试的优势是稳定、快速劣势是你得花时间背而且背错了很难改。2. 从技术原理推导差异藏在检索、上下文与参数之间很多人把 RAG 和微调放在一起比较却说不清它们各自的技术路径。这一节把两条推理链路拆开来看许多选择问题其实从原理上就已经有了答案。2.1 RAG 的推理链路一个典型的 RAG 流程包含四段将用户问题输入先做查询改写或意图识别有时还要拆解成多个子查询。用嵌入模型把改写后的查询转成向量在向量数据库中做近似最近邻搜索召回 Top-K 候选片段。对召回结果做重排序如果有排序模型的话把最相关的片段筛选出来并按逻辑顺序拼进提示词。将完整提示词交给大模型生成最终回答。这条链路里模型本身没有变化。你换一个更强大的基座模型RAG 效果往往会跟着提升检索质量差再强的模型也无济于事。所以做 RAG 项目大部分精力都在“喂”的阶段文档切片、清洗、嵌入模型选型、向量库调优、召回测试。这里有一个关键点值得强调RAG 的效果是“检索结果 模型能力 提示词结构”三者的联立。同一个知识库用不同的嵌入模型召回命中率能差出一大截同样的检索结果提示词里是“请严格依据材料回答不要自行发挥”还是“请根据以下内容回答”输出质量差别也很明显。这意味着 RAG 有大量可调空间但也意味着它的问题排查面更广。2.2 微调的推理链路微调的推理链路看起来更简单用户问题输入模型模型基于内部参数直接生成回答。训练阶段的关键是对基座模型施加监督信号让它在特定分布的数据上拟合。常用方法包括全量微调和参数高效微调后者只训练一小部分参数比如低秩适配那一类做法训练成本低很多效果在多数指令类任务上也够用。从原理上说微调改变的并不是“模型记住了什么精确句子”而是“模型在什么输入下倾向产生什么输出”。训练数据里的问答对本质上是给模型划定了输入输出空间的一个局部先验。模型学到的可能是规则、风格、知识边界也可能只是数据里的表层模式这取决于数据规模、质量和训练策略。正是这个原因微调的效果评估需要非常小心。我自己见过不少项目训练集上的指标很好看一上线就崩。原因往往是训练数据的分布和真实用户提问的分布不一致模型在训练阶段见过的“问题写法”太单一到了线上遇到同义表达就抓瞎。这说明微调不是简单把数据喂进去就行数据设计决定了模型泛化能力的天花板。2.3 为什么会出现“检索到了但模型不照做”的情况这是 RAG 项目里最常遇到的问题也最能体现 RAG 和微调的边界。明明向量库里已经命中了正确答案模型却还是给出了自己的臆测。原因一般有三种第一提示词没有明确给模型设定“引用材料”的约束。很多基座模型默认倾向于依赖自己的知识生成如果你不说“只依据材料回答”它会把检索内容和自己的记忆混在一起。第二上下文中材料太多或太杂。比如你把 8 个片段都塞了进去正确答案混在第 7 个片段里模型在长上下文里的注意力容易被前面的内容带走尤其当前面几个片段内容更“顺眼”时。第三模型本身的能力不足。小参数模型的指令跟随能力弱即使明确要求它引用材料它也可能做不到。这种情况下单纯调 RAG 链路是无解的要么换更强的基座模型要么考虑用微调强化它的指令跟随能力。理解这一点很重要RAG 能解决“知识达不到”的问题但解决不了“模型能力不达标”的问题而微调恰好能在“能力不达标”这个方向上发力。两者不是替代关系更多是互补关系。3. 选 RAG 还是微调9 个关键问题帮你做决定不少团队在立项时纠结“到底选哪个”其实没有统一答案。我习惯用一个问题清单来帮助判断下面的内容可以当成决策工具。3.1 适合优先选 RAG 的场景如果你的情况符合下面任意一条优先考虑 RAG知识更新频率高比如规章制度、产品文档、活动规则每周甚至每天都有变化。知识来自大量非结构化文档无法简单用几千条样例覆盖。要求回答可溯源用户想看“这句话出自哪份文档”RAG 可以直接返回引用来源微调做不到。模型基座已经选定预算不足以承担训练和评估周期。冷启动时间紧今天拿到文档明天就想上线。我印象很深的一个例子是某企业的内部 IT 支持机器人。他们的知识库里有几百篇运维手册问题五花八门而且手册每隔一段时间就更新。用了 RAG 之后新增一篇手册只需要走一遍切片入库用户第二天就能问到相关内容。这种场景如果走微调光是跟进文档更新的训练节奏就够团队崩溃。3.2 适合优先选微调的场景反过来下面这些情况更适合微调模型输出格式要求非常固定比如必须输出 JSON、必须遵守某种复杂指令模板。业务有自己的表达风格比如客服要温暖、技术社区要专业、教育产品要耐心这些风格很难靠提示词稳定维持。任务的输入输出模式相对稳定可以用几千到几万条高质量样例覆盖绝大多数情况。推理性能要求高RAG 的检索环节可能造成额外延迟微调后的模型一次推断就能给出结果。数据隐私要求严格不想在推理链路里多一个向量检索组件希望所有逻辑都在模型内部完成。一个典型例子是内容安全分类器。输入一段用户内容输出一个分类标签类别固定、判断规则稳定。这种任务很难说 RAG 有什么优势反而是微调一个小模型推理快、可控性强、离线评估也方便。3.3 两者组合的常见做法真实项目里最健康的姿势通常是先 RAG、后微调必要时两条链路并行。我常用的组合方式是RAG 负责“知识供给”微调负责“表达与指令服从”。比如一个医疗健康问答项目先让微调后的模型掌握统一的回答结构和安全话术再在推理时挂上 RAG检索最新的健康指南和药品说明。这样即使检索结果不理想模型也会按照安全话术回应而不是随口编造。反过来如果只做微调而不接 RAG知识更新慢只做 RAG 而不微调回答风格和格式又难控制。还有一个被低估的方案微调一个“查询改写器”。在 RAG 链路的最前面加一个小模型把用户的模糊提问改写成适合检索的精确查询能显著提升召回率。这个组件不需要很大用几百条改写样例微调一个小参数模型就够用成本低收益却很明显。4. 成本和效果的多维度对比算清六笔账决策的时候不能只看“效果好不好”更要看“代价值不值”。这一节我做了一个比较全面的成本对照每一项都来自实际项目中的体会。4.1 数据准备成本RAG 的数据准备主要是清洗文档、设计切片逻辑、确认检索单元。文档质量参差不齐时切片策略很关键切太长召回粒度粗模型容易被无关信息干扰切太短上下文割裂关键信息经常丢。做一套相对稳定的切片和清洗流程一个熟练的工程师几天内可以完成。难点在“持续维护”上因为文档会不断新增和变更。微调的数据准备成本通常更高。你需要产出高质量的训练样本这意味着要对原始文档进行语义理解、提取问答对、编写标准答案、考虑边界情况、做数据增强。一个中等规模的数据集往往要投入人力和专家时间。我见过很多项目因为数据质量不足训练结果始终达不到预期最后只能重新回到 RAG 方案。从单位成本看微调的“一次性数据投入”远高于 RAG 的“持续性数据投入”。如果数据总量不大且几乎不变微调的成本可以接受如果数据持续增长微调的数据成本会越滚越大。4.2 GPU 与基础设施成本微调需要至少一次训练过程。全量微调大模型需要多卡并行费用相当可观即便采用参数高效微调也需要准备训练环境、调试超参数、做多次实验。训练过程本身消耗的 GPU 时数是 RAG 方案完全不需要承担的。RAG 的基础设施成本主要在向量数据库的存储与查询、嵌入模型的推理资源、重排序模型的推理资源。如果并发不高这些服务甚至可以跑在低配 CPU 上如果并发高需要为检索链路的每个环节单独扩容。但总体来说RAG 的基础设施成本是“运行时”成本可以按需伸缩微调的成本是“发生即巨额”的成本不管最后有没有上线训练费用都花出去了。我还建议把持续评估的人力和算力也计入成本。微调方案每次模型更新都要重新跑一遍评测集RAG 方案每次知识库更新也要重跑一遍召回评测两者都有“校验成本”只是微调的校验周期更长、返工代价更大。4.3 维护与迭代成本这是差距最明显的一项。RAG 的知识更新是按小时计的新文档进来清洗、切片、嵌入、入库整个流程可以用脚本串起来。文档召回错了直接调切片或重排序逻辑不用碰模型。微调的迭代周期是按天甚至按周计的。新知识要变成训练样本训练样本要经过质检和格式转换训练要跑效果要对比还要防止灾难性遗忘。哪怕是参数高效微调一轮完整迭代也很少能在一天内完成。从团队角度说RAG 更像“软件工程”需要检索系统、数据管线、评测脚本的持续打磨微调更像“建模工程”需要数据标注、训练实验、模型评估的长期投入。两种维护模式对团队技能的要求不一样选择时也要考虑团队现有能力。4.4 效果评价方式RAG 的效果可以拆开来看检索质量用召回率、命中率衡量生成质量看回答准确性、忠实度、引用正确率。你可以对每个环节单独做评测定位问题非常迅速。微调的效果则要看整体行为是否符合预期通常用一组覆盖典型场景的评测集来打准召率、格式合规率、风格一致性。问题定位更难“答错了”可能是数据覆盖不足、可能是训练超参不对、也可能是基座模型本身能力不足需要反复实验才能定位。我建议任何项目上线前都准备至少一份“金标准评测集”里面包含典型提问和理想回答。RAG 项目测评测集要同时记录“检索命中了什么”和“最终答了什么”这样才能区分是检索问题还是生成问题。微调项目的评测集要按功能模块分层比如基础问答层、格式执行层、安全规范层每一层单独给分。5. 实操中常见的坑与排查思路最后聊聊实际操作中容易踩的坑。这些内容大多来自我和同行交流时的经验汇总按 RAG 侧和微调侧分开列方便对照排查。5.1 RAG 侧的问题第一个坑文档切片长度一刀切。几百篇不同格式的文档用同一个固定切片大小结果有的片段全是标题有的片段把完整表格拦腰截断。建议先分析文档结构再决定切片策略。规则类文档按条目切长文按段落切表格至少保留表头和上下文。第二个坑不检查召回结果。很多人只盯着最终回答看回答错了就怀疑模型。实际上先看一眼召回的前 5 条里有没有正确答案能快速定位问题。我习惯在开发环境里把召回结果直接打印出来排查效率极高。如果召回结果里根本没有正确答案那就别折腾提示词和模型了先去调嵌入模型、重排序、切片方案。第三个坑提示词里材料塞太多。上下文越长模型越可能“迷失在中间”。实践里我往往只保留重排序后的前 3 到 5 个片段长度控制在上下文窗口的一半以内剩下空间留给指令和用户问题。不要以为材料给得越多越安全冗余信息反而会稀释答案质量。第四个坑忽略查询改写。用户问题往往是“上次那个文档里的规定是什么”直接拿这句话去向量库检索效果通常不好。简单做一个查询改写去掉指代词、补充实体全称召回率能提升不少。这个环节用规则就能解决一部分不需要一上来就上大模型。5.2 微调侧的问题第一个坑训练样本风格太单一。如果所有训练样本都长一个样模型只会“背答案”换个写法就崩。做训练数据时要有意识地加入表达变体、错误的输入、边缘场景。宁可数量少一点也要保证覆盖度。第二个坑忽视基座模型能力天花板。一个小参数模型再怎么微调也很难学会复杂推理。选基座时先做几个不训练的预实验看看它在目标任务上的基础表现如果差得太远换更大规模的基座往往比堆更多训练数据更有效。第三个坑过度训练导致遗忘。参数高效微调也有遗忘风险尤其是训练轮数多、学习率偏大的时候。我一般会在训练过程中保留多个 checkpoint并在每个 checkpoint 上跑一遍通用能力评测集一旦发现通用指标掉得厉害立即回退。第四个坑微调和数据标注脱节。标注人员不知道模型最终要什么格式标出来的答案千奇百怪。最好在标注规范里给出正例和反例并且跑一个基线模型让标注人员参考输出格式这样标注质量会稳定很多。5.3 混合方案的实施顺序如果决定走 RAG 加微调的混合路线我的建议是先做 RAG 基线再考虑微调优化。理由是 RAG 基线搭建快能快速暴露领域数据里的问题帮助你理解真实用户提问长什么样。拿到这些真实问题之后再做微调数据设计数据质量会高得多。反过来先微调再上 RAG 的缺点是微调阶段缺失真实检索场景模型可能在“没有上下文”的情况下表现很好一接上 RAG面对长长短短的检索片段反而不知道如何取舍。微调的样本设计如果能包含“带噪声的检索片段”模型会更适应混合场景。我个人实际使用中的一个体会是别把 RAG 和微调当成互斥的路线它们分别解决的是知识获取能力和行为规范能力。一个成熟的 AI 应用往往需要两条腿走路。RAG 管住“它知道什么”微调管住“它怎么说话”前面再加一层查询改写后面再做一层回答合规校验整个系统才算完整。这个组合方式不一定适合所有团队但对于知识密集型、交互频繁、对输出质量有要求的场景值得认真考虑。