做 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 管住“它知道什么”，微调管住“它怎么说话”，前面再加一层查询改写，后面再做一层回答合规校验，整个系统才算完整。这个组合方式不一定适合所有团队，但对于知识密集型、交互频繁、对输出质量有要求的场景，值得认真考虑。
