先说结论：这俩多数时候不是竞争关系
“该微调还是上 RAG”是 LLM 应用落地里被问得最凶的问题，但它一开始就问歪了：RAG（Retrieval-Augmented Generation，检索增强生成）改的是模型”知道什么”，微调（fine-tuning）改的是模型”怎么说话”。一个是外挂知识库，一个是改行为习惯，把两者当同类竞争，选型表就永远填不对。本文给一张四维决策表、两份”做不到清单”、微调三种形态的门槛、组合拳场景与一棵决策树，收尾把边界也讲透。站内已有两篇打底：《RAG 从演示到能用》讲检索链路里切分、召回、重排的成败细节，《本地大模型部署》讲自托管模型；本文只管”什么时候轮到微调”这一个决策。另一个常见误区是把问题问成”微调是不是比 RAG 高级”——两者没有高低，只有匹配不匹配，方向用错了的高级手段，比便宜的朴素手段又贵又差。
四维决策表
| 维度 | RAG | 微调（LoRA/QLoRA） |
|---|---|---|
| 成本结构 | 固定成本在检索链路（切分、向量库、重排）；边际成本是每次请求多出检索与更长的输入 token | 固定成本在训练（数据清洗、标注、GPU 时）；边际成本几乎为零，推理时不再携带长上下文 |
| 时效性 | 分钟级：文档入库即生效，删了即撤回 | 改知识=重训：周级起步，训练窗口之外的世界一无所知 |
| 可解释与可撤销 | 可溯源（引用命中段落）、可审计（查日志）、可按文档甚至按用户粒度收回 | 黑盒：权重里分不清哪条知识来自哪份数据；撤销某条知识的唯一办法是回滚旧权重 |
| 适配的数据性质 | 事实与知识：文档、价格、库存、政策条文 | 行为与风格：输出格式、语气、术语习惯、拒答倾向 |
读懂这张表的方式不是逐行打分，而是先问你要注入的东西是”知识”还是”行为”——这一问基本就分流了八九成场景。剩下拿不准的，看下面两份清单。
成本这一维值得再拆一层，因为它是唯一随用量变化的维度。RAG 的账单跟着调用量线性走：每次请求都多一次检索、多一大段被塞进上下文的文档 token，用得越多越贵，但链路搭好后迭代的边际成本几乎为零。微调相反：训练那一次很贵（数据清洗是最大头，GPU 时是第二大头），训完之后每次推理反而比 RAG 便宜——不用检索、不用背着两千 token 的规范文档。所以量级判断可以简化成一句话：用量小、迭代频繁，RAG 的固定成本低优势大；用量大、输出模式稳定，微调的边际成本低优势才慢慢回本。回本点在哪没有通用数字，它取决于你的文档规模与请求量级，只能自己拿 token 账单算。
时效性这一维也常有反直觉的用法：有团队为了”让模型记住新政策”去微调，结果训完政策又改了。这里有个判断式：知识变更频率高于你的训练频率时，微调在数学上就不成立——每次变更都要重走一遍数据准备与训练流程，而 RAG 侧只是换个文档。把”多久更新一次”这个问题问在选型之前，能省掉一批注定返工的项目。
RAG 做不到的：微调的真正地盘
这些需求检索帮不上忙，因为它们要的不是”模型知道更多”，而是”模型稳定地以某种方式输出”：
- 风格与人设：客服要克制友善、营销文案要带节奏——提示词能撑一阵，但长对话里风格漂移，微调后的行为是权重级的，稳定得多；
- 严格的格式遵循：要求每次输出都命中某个 JSON Schema、固定字段顺序、零多余文字。提示词的遵循率随字段数与输出长度下降是普遍体验——最爱出事的是批量处理的第二条记录：第一条规规矩矩，第二条带了句寒暄，第三条字段顺序乱了，下游解析直接崩。格式微调是这类需求的标准解；
- 领域术语的稳定输出：行业黑话、内部编码、双关回避——模型预训练里没见过或见过太少的词，靠检索塞进上下文也只能”看着抄”，术语层的行为要靠训练固化。语料全是内部行话的企业，几乎必然撞上这条；
- 上下文经济的刚需场景：每请求都往 prompt 里塞两千 token 的规范文档，token 成本与延迟月月烧钱；微调把规范”焊”进权重，推理输入只剩问题本身。
什么时候该从提示词挪到微调？看三个信号，满足两个就值得认真评估：格式/风格的坏例占比压不到可接受水位（提示词改一轮、测一轮仍不行）；规范文档常驻上下文导致 token 账单成为显著成本项；响应延迟里大头是长输入的处理时间。三个信号一个都没有的话，你不在微调的目标客户名单里。
微调做不到的：RAG 的地盘
反过来，这些需求微调从原理上就不可靠，而且失败方式很隐蔽——不是报错，是自信地胡说：
- 知识时效：模型权重定格在训练完成那一刻。价格、库存、政策这种天级甚至小时级变动的信息，只有外挂库能跟；
- 溯源：微调模型说出一个数字，你无法回答”这来自哪份文件”。合规场景（金融、医疗、法务）要的是”这句话为什么可以这么说”的完整证据链，权重给不出其中任何一环，这只有 RAG 给得了；
- 知识注入的可靠性：这是被研究反复验证的一条——《Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs》（arXiv 2312.05934）的结论是 RAG 在知识注入上显著更可靠，且事实在预训练语料里出现得越少（越冷门），微调失败率越高。社区实践同向：LoRA/QLoRA 这类参数高效微调几乎新增不了知识，越冷的知识越是如此。指望微调”背下”你的私有文档，是这条路线上最贵的弯路；
- 权限粒度：不同用户能看不同文档，RAG 在检索层按身份过滤即可；微调把数据熔进权重，”这个客户不该知道这条”无法在权重层面表达。
把这条展开成反模式点名：把微调当知识注入手段。症状三连——训练后模型对新知识答得含糊（学成了语气没学进事实）、文档更新后要重训、出了错没法定位是哪份数据教坏的。同级别的另一个反模式：RAG 效果差，就想着”上微调补一补”。检索质量不行（切分不当、召回不准、没重排）导致的答非所问，微调一个字都救不了，先按RAG 那篇的三个成败点修链路。还有个更靠前的反模式：没穷尽提示词就上微调——一行 system prompt 加几个少样本示例能解决的需求（见《提示词工程》），微调是拿最贵的基础设施解决最便宜的问题。
微调的三种形态：全量、LoRA、QLoRA
决定微调之后还有一层选型，门槛差异巨大：
| 形态 | 做法 | 门槛与代价 | 适合 |
|---|---|---|---|
| 全量微调 | 更新模型全部权重 | 成本最高，多数应用团队不碰 | 有专属训练基建的大厂场景 |
| LoRA | 冻结原权重，训练一小片低秩适配层 | 消费级到单卡级 GPU 可训，产物是轻量适配权重 | 行为微调的默认起点 |
| QLoRA | LoRA 基础上再量化底座 | 显存与存储需求显著更低，训练更慢 | 显存紧张的自托管环境 |
一组公开口径的注脚：Google 文档给出的对比是 LoRA 训练速度比 QLoRA 快约 66%、成本最多便宜 40%；Red Hat 的口径是 QLoRA 以量化换来了显著更低的存储与硬件门槛。方向一致：资源宽裕选 LoRA，卡紧选 QLoRA。选形态的顺序建议：从 LoRA 起步验证行为收益，硬件撑不住再降级到 QLoRA；全量微调在应用层公司几乎没有出场机会。对自托管部署侧的连带影响（量化权重与推理框架的搭配）在本地大模型部署那篇展开。数据准备侧一句实话：样本质量比数量重要，清洗与标注占项目工作量的大头，这一条在各家工程实践里高度一致。
组合拳：什么时候两个都要
真实的生产系统常常两个都要，因为要同时改”知道什么”和”怎么说话”：
| 场景 | 微调负责 | RAG 负责 |
|---|---|---|
| 企业客服 | 语气、话术规范、拒答边界 | 订单状态、退换政策、库存事实 |
| 法务/医疗助手 | 术语体系、文书格式 | 最新法规与指南原文，逐条引用出处 |
| 结构化抽取（发票、简历） | 目标 Schema 的稳定输出 | 通常不需要——知识面不在此处 |
| 领域问答（运维知识库） | 排障思路与提问习惯 | 版本相关的具体参数与坑，随版本更新 |
组合的架构顺序是”底座模型 → LoRA 权重管行为 → 检索层管知识”，两层互不越界。预算有限时先保知识层：行为可以拿提示词兜底，知识错误是直接输出给用户的事故。上线顺序上有一条工程纪律：先把 RAG 跑稳，再谈微调。理由很实际：RAG 改文档即生效、随时可回滚，是低风险的迭代面；微调每次动都是行为级变更，没有评测护栏就是在裸奔。顺序反了的典型结局是两套行为打架：微调固化了旧话术，RAG 又带来新事实，冲突时模型忽左忽右，排查时两边的负责人互相甩锅。护栏长这样：微调前后跑同一套基准，格式遵循率、风格评分、知识问答准确率三个数摆出来对比，坏例单独归档复盘。评测体系怎么搭见《LLM 评测怎么做》；成本侧的持续优化（哪些请求该降级到小模型、哪些 prompt 该瘦身）是另一条线，站内《LLM 成本优化》专门讲。
三个决策走一遍
抽象表看完了，拿三个典型场景把决策链走一遍。
场景一，电商客服。知识面是商品信息与售后政策，天天在变；同时话术要统一、拒答边界要稳。决策：RAG 做主干（文档入库、引用出处、按用户权限过滤），话术先靠 system prompt 顶着，格式坏例率连续压不住再立项微调。话术统一的另一个动机是合规：客服对用户承诺了兑现不了的东西，比答不上来贵得多。头一个月的排期里根本没有微调这两个字。
场景二，合同要素抽取。输出必须严格命中固定的 JSON Schema，抽取对象是几套一年改一次的合同模板。决策：LoRA 格式微调，不上 RAG——这里没有”要查的文档”，只有”要守的格式”，检索层既贵又无用。知识面窄而稳定，恰好落在微调的舒适区。
场景三，医院预问诊助手。问法要贴医学语境（行为），指南与用药知识必须最新且可引用（知识）。决策：组合拳，但 RAG 先行——指南引用出错是安全事故，先把知识层做成可溯源的；术语层微调放第二批，上线前必须过整套评测基准。
三个场景的共性可以提走：先问知识还是行为，再问变更频率与用量，最后问评测和兜底谁负责——答案自然会落到决策树的某一层。
立项前的自查清单
| 问题 | 答不上来意味着 |
|---|---|
| 有没有一份可复现的评测集 | 没有就不能微调：改了行为也无法证明没改坏 |
| 坏例能不能归因（提示词/检索/模型行为） | 归因不到行为层的坏例，微调治不了 |
| 底座模型半年内会不会换 | 会换的话，把权重作废的迁移成本写进立项书 |
| 谁来长期维护训练数据与权重版本 | 没有维护者的微调资产，大概率烂尾成一次性行为补丁 |
这四个问题任何一个答不上来，项目都该停在 RAG 阶段——不是微调不好，是你还没到能安全使用它的组织成熟度。
决策树收尾
把前面四个维度、两份清单压成一棵树，任何场景从根走一遍，两分钟就能落到叶子：
你要改的是"知道什么"（事实/文档/价格/库存/政策）吗
├─ 是 → RAG。要溯源、要天级更新、要按权限收回的，只有 RAG 能做
└─ 否，要改的是"怎么说话"（风格/格式/术语/倾向）
├─ 提示词 + 少样本示例能压住 → 不动模型（最便宜，先穷尽它）
├─ 压不住，或示例塞不进上下文、token 成本扛不住 → 微调（LoRA 起步，显存紧选 QLoRA）
└─ 两类需求都有 → 组合拳：LoRA 管行为 + RAG 管知识，RAG 先行、微调跟进树上第一层分叉就是全文核心：知识与行为分开问。这棵树还有一个隐含前提：你手里已经有一份能跑的评测集——没有它，”压不住””效果差”都只是感觉，选型就退化成迷信。顺带回应一个常被拿来终结讨论的问题——”上下文窗口都这么长了，RAG 会不会被淘汰”。长上下文解决了”塞得下”，没解决另外四件事：塞得下不等于塞得起（成本随长度线性涨）、长文档中段的注意力衰减是公认现象、按用户隔离的权限控制、以及可引用的出处。这四条恰好都是 RAG 的主场，所以至少在可见的工程周期里，这棵树的形状不变。
边界与诚实结论
最后三句实话。其一，微调不是护城河：底座模型一升级，你的 LoRA 权重大概率作废，而提示词与 RAG 链路几乎原样迁移——把不可迁移的投入压到最低，是选型的隐藏维度。其二，微调的真实成本被普遍低估：数据清洗与标注占整个项目的大头，训练只是最后一步。给不同规模团队的默认答案：三人以下小组，RAG 加提示词就是全部武器库，微调不在菜单上；有专人负责数据与评测的中型团队，行为微调按需求触发；训练基建齐备才轮到全量微调。其三，本文不引用自家实测数字（未做受控对比，不编数），文中结论来自公开研究与厂商文档口径；”你的场景里微调值不值”这个问题，只能靠你自己那套可复现的评测来回答——这也正是评测那篇存在的意义。
版本与事实核实：本文涉及的研究结论（arXiv 2312.05934，RAG 在知识注入上更可靠、事实越冷门微调失败率越高）、LoRA/QLoRA 工程现状与公开对比口径（Google 文档、Red Hat）均为撰写时公开资料核对；文中不含具体模型版本依赖，各微调与推理工具的当前版本以官方文档为准。