微调还是别调：微调 / RAG / 提示词工程三岔口决策指南

效果上不去的时候，vibe coder 的第一反应往往是："微调一个模型吧。"

听起来很硬核，做起来也很"充实"：准备数据、租卡、跑训练、看 loss 曲线下降，多有搞大模型的仪式感。但残酷的真相是——90% 喊着要微调的场景，用 RAG 或提示词工程更便宜、更快、效果还更好。微调不是效果药，它是一次性价很高的手术：做对了脱胎换骨，做错了浪费两周时间和几百美元，模型还变傻了。

这篇文章给你的是一张决策表，不是微调教程。读完你能回答三个问题：这个问题到底值不值得微调？如果值得，数据要准备到什么程度？调完怎么证明没调坏？

先把三者的分工一句话说死，后面所有判断都从这句长出来：

• 提示词工程：教模型"这次怎么做"——零训练成本，改一行字立刻生效，天花板是模型本身的能力。
• RAG：给模型"查资料的能力"——知识外置，可更新，回答带出处，代价是多一次检索延迟。
• 微调：改模型"默认的行为习惯"——把某种格式、风格、领域行为压进权重，知识更新靠重新训练。

记住这句：微调改变的是行为，不是知识；RAG 解决的是知识，不是行为。分不清这句，后面全错。

一、三岔口决策树：先看任务类型

决策的第一分叉永远是任务类型，不是数据量。按这个顺序问自己：

第 1 问：你要解决的是"知识问题"还是"行为问题"？

• 模型答错了你们公司的产品价格、报错码含义、私有 API 参数——这是知识问题。知识会变（价格会调、文档会更新），微调是把"易变的东西"焊进"难变的地方"，属于方向性错误。走 RAG。
• 模型能答对，但格式总不对（JSON 字段顺序乱、客服话术不像你们品牌、代码注释风格不统一）——这是行为问题。行为稳定、要内化成"肌肉记忆"，这是微调的主场。
• 两者都要？先 RAG 解决知识，再看行为问题是否值得一次微调（见第七部分"组合拳"）。

第 2 问：提示词工程真的到头了吗？

在谈微调之前，先诚实地做完这三件事：写了 5 版以上的 system prompt 并做过 A/B 对比；试过 few-shot（3-8 个高质量示例）；试过把任务拆小（一个大 prompt 拆成 3 步 pipeline）。如果这三件没做完，你缺的不是微调，是提示词的基本功。我见过太多"微调后提升 3%"的案例，事后发现是第一版 prompt 写得太烂。

第 3 问：延迟和成本的账怎么算？

RAG 的代价在推理时：每次请求多一次向量检索（几十到几百毫秒）+ 更长的 context（更多的输入 token 钱）。微调的代价在训练时：一次几十到几百美元，之后推理延迟和 token 成本与基座模型持平（甚至更低——因为你可以用更小的模型达到大模型的行为效果）。

所以这条经验法则很实在：调用量越大，微调越划算（训练成本被摊薄）；调用量小、知识更新快，RAG 完胜。

/media/content-media/a56f3ccd-38fe-490f-a5d3-6edb6bc228d5/2026/10/6fb26569-3a10-4d40-a694-7014df054425.jpg

上图是微调的本质：训练时用更多数据、更多算力、更多参数，把某种能力"压进"基座模型。注意箭头方向——训练是一次性的，推理时不再有这部分成本。这就是"调用量越大越划算"的物理基础。

二、数据量门槛表：多少条样本才值得调

微调最常见的死法是数据不够还硬调。下面这张表是社区反复验证的量级经验（以 7B~70B 开源模型 LoRA 微调为基准）：

样本量	结论	理由
< 100 条	别调，用 few-shot prompt	模型会直接背下这 100 条，泛化能力不升反降，还可能灾难性遗忘原有能力
100 ~ 500 条	大概率别调；先试 RAG + 强 prompt	这个量级调出来的效果，好的 prompt + 示例基本能打平，成本是零
500 ~ 2,000 条	可调可不调，看任务类型	行为类任务（格式/风格）可以调；知识类任务依然走 RAG
2,000 ~ 10,000 条	微调甜点区	LoRA 在这个区间性价比最高，行为改变明显且稳定
> 10,000 条	值得认真调，考虑全量微调	数据够了，瓶颈变成算力和调参耐心；但先问一句：1 万条高质量标注哪来的？

注意最后一行的灵魂拷问。微调的成本大头不是 GPU，是数据。1 万条"高质量"样本意味着：清洗、去重、人工抽检、配负样本——solo 团队干这个通常要 2~4 周。租卡的钱反而是小头。凡是跟你说"微调很便宜"的人，八成没算数据标注的人力账。

数据准备 checklist（动手前逐项打勾）：

• 样本覆盖了真实输入的分布吗？还是只覆盖了你手头好找的那几类？（分布偏了，调完线上就崩）
• 有负样本吗？比如"用户问了不在业务范围内的问题，模型应该拒绝"——没有负样本，模型会学会"有问必答"，开始一本正经地胡说八道。
• 做过 10% 人工抽检吗？AI 生成的训练数据里混进 5% 的错误样本，效果提升直接归零。
• 留了验证集吗？训练集和验证集按时间或来源切分，不能随机混切（否则验证集泄漏，loss 好看但上线拉胯）。
• 数据里有 PII（手机号、邮箱）吗？有的话先脱敏——微调会把训练数据"记住"，这是隐私事故的种子。

三、成本公式：训练 + 推理 + 维护，三笔账一起算

只算训练费的人，都会在第三个月被账单教育。完整的公式是：

总成本 = 训练成本 × 训练次数 + （单次推理成本差 × 调用量） + 维护成本

• 训练成本：LoRA 调 7B 模型，单卡 A100/H100 跑几小时到十几小时，按云厂商按量价约 30~150 美元/次。但注意是"× 训练次数"——调参 3~5 轮是常态，第一次就成的属于欧皇。
• 单次推理成本差：微调本身不增加推理成本，但它让你能用更小的模型达到大模型的效果（比如用微调后的 7B 代替 70B），这时每次调用能省 5~10 倍 token 钱。调用量越大，这笔越赚。
• 维护成本（最容易被忽略）：基座模型升级了（Llama 3 → Llama 4），你的微调权重作废，重调一遍；业务变了（话术更新），重调一遍。微调是一次性手术，但业务是活的——每次业务大变都是一次"复诊费"。

对比 RAG 的账：没有训练费，但每次请求多付检索延迟 + 更长的输入 token；知识更新 = 更新向量库，分钟级生效，零训练费。所以：知识高频变、调用量中等 → RAG；行为稳定要内化、调用量大 → 微调。这句话值 500 美元。

/media/content-media/a56f3ccd-38fe-490f-a5d3-6edb6bc228d5/2026/10/525ea923-6e29-47fb-bf23-025781900c23.jpg

上图是 AWS 官方博客里的 RAG 架构：检索 → 增强 → 生成。注意它的代价全部发生在推理时——每次请求都要走一遍这个 pipeline。这也是 RAG 和微调成本结构完全不同的直观体现。

四、LoRA vs 全量微调：solo 团队只看这一张表

	LoRA（推荐）	全量微调
动了多少参数	只训练低秩适配器（通常 <1% 参数）	全部参数
显存需求（7B 模型）	单卡 24GB 可跑（如 4090）	至少 4×80GB 起步
训练成本	几十美元/次	几百到几千美元/次
灾难性遗忘风险	低（基座权重冻结）	高，数据配比不对直接变傻
多任务复用	一个基座 + N 个 LoRA 适配器，按需切换	每个任务一个完整模型副本，存储和部署都是负担
什么时候选它	95% 的 solo 场景	预训练领域偏移极大（如从通用模型转到古汉语/分子式），且你有 10 万+ 样本和预算

一句话：除非你能清楚说出"为什么 LoRA 不够"，否则永远选 LoRA。全量微调是实验室和巨头的玩具，solo 团队碰它，烧钱速度会超过你的融资速度——而你还没有融资。

五、eval 门禁线：调完必须过的回归集

微调最大的隐形杀手不是"没调好"，而是"调好了 A，调坏了 B，自己还不知道"。没有 eval 就上线，等于闭眼开车。

门禁线做法（抄走即用）：

1. 动手前，先攒 200 条回归测试：100 条目标任务（你想让模型变好的）、50 条通用能力（数学、常识、指令遵循——防灾难性遗忘）、50 条负样本（应该拒绝/应该说不知道的）。
2. 基座模型先跑一遍，记录基线分数。
3. 微调后重跑，门禁规则：目标任务提升 ≥10%，通用能力下降 ≤3%，负样本通过率不下降。任何一条不满足，打回重调。
4. 回归集永不进训练集。泄漏一次，这套门禁就废了。

评估方式上，200 条这个量级别省那点钱：人工抽检 50 条 + LLM-as-judge 跑全量，judge 的 prompt 要写清楚评分标准（别只写"你觉得哪个好"，要写"按以下 4 条标准打分"）。纯人工太贵，纯自动不放心，混合是最优解。

还有一句难听但真实的话：如果基座模型换代（比如新出了强 30% 的版本），先重测基线再决定要不要继续微调。很多人微调了三个月，发现新基座零样本就超过了自己的微调版——那三个月，约等于给旧模型办了一场昂贵的葬礼。

六、组合拳：什么时候 "RAG + 微调" 才划算

RAG 和微调不是二选一，它们解决的是正交问题，所以组合拳是常态，但顺序有讲究：

1. 先 RAG，后微调。RAG 一周能上线，微调按月计。先用 RAG 验证"这个问题有没有价值解决"，有价值再投入微调固化行为。
2. 组合拳的经典配方：RAG 管知识，微调管"怎么用检索到的知识"。比如客服场景：RAG 召回产品文档，微调让模型学会"引用文档条款编号、按公司话术组织回答、遇到召回为空时主动说不知道"。后者是行为，前者是知识，各归其位。
3. 不划算的组合：知识更新极快（每天变）+ 还要微调——你会陷入"每周重调"的地狱。这时正确姿势是 RAG + 强 prompt，把微调的钱省下来买更好的 embedding 模型。

/media/content-media/a56f3ccd-38fe-490f-a5d3-6edb6bc228d5/2026/10/11f9b807-edda-49f1-88ec-cb78cf235df9.png

上图是 RAG 的标准工作流：文档切分 → 向量化 → 检索 → 增强生成。当你决定打组合拳时，微调的目标就是让模型更擅长"消费"这个流程吐出来的检索结果——而不是让模型去背文档本身。

七、"别微调"反模式清单

最后，把最常见的几种"调了也白调"钉死在这里。命中任何一条，立刻停手：

• 用微调记事实：把"产品价格表""API 参数"塞进权重。价格一变，模型还在背旧价，还不如 RAG 查表准。这是头号反模式。
• 用微调追新知识：指望微调让模型知道上周的新闻。知识截止日期是基座模型的属性，微调 1 万条新闻也追不上互联网。
• 数据不够硬调：200 条样本调 70B 模型，loss 降得很漂亮，上线一问三不知——因为它背下了你的 200 条，忘掉了全世界。
• prompt 能解决的非要调：格式问题先试"输出 JSON schema + 3 个示例"，90% 的格式问题到这步就死了，不需要动权重。
• 不做 eval 就上线：调完感觉"好像变好了"就发布。感觉是最贵的测试方法。
• 指望微调改"智商"：微调改的是行为习惯，不是推理能力。一个在数学上只有 60 分的基座，微调后数学还是 60 分，只是"用你的格式"考 60 分。

八、实战推演：三个真实场景走一遍决策树

光看表不过瘾，拿三个 vibe coder 最常遇到的场景实战推演一遍：

场景 A：给自家 SaaS 做智能客服，回答产品使用问题。
第 1 问：知识还是行为？产品文档、价格、报错码——全是知识，且每周更新。结论：RAG。向量库接产品文档，更新文档 = 重新索引，分钟级生效。再补一个行为层：如果希望客服按公司话术组织语言，等 RAG 跑顺、调用量起来后，再考虑一次 LoRA 固化话术风格——这就是第六部分的组合拳顺序。

场景 B：代码生成工具，要求输出符合公司内部的注释规范和目录约定。
第 1 问：行为问题（格式/风格），规范稳定、半年一变。第 2 问：prompt 到头了吗？先试 system prompt + 5 个示例，大概率解决 80%。第 3 问：如果 prompt 解决后仍有 20% 的格式漂移，且你攒下了 3000+ 条"输入需求 → 规范代码"的真实样本，调用量每天上万次——结论：LoRA 微调，甜点区，一次训练摊到每次调用几乎不要钱。

场景 C：想让模型记住 500 个客户的私有业务规则并准确回答。
第 1 问：知识问题。500 条样本——看第二部分的表，<500 条硬调等于让模型背电话本，还会忘掉通用能力。结论：RAG + 强 prompt，别碰微调。把 500 条规则结构化进检索库，prompt 里写清楚"只根据检索结果回答，检索不到就说不知道"。这 500 条要是每天变，微调更是灾难。

你发现规律了吗？决策树的前两问能杀掉 80% 的"想微调"冲动，剩下的 20% 才是微调的真正领地。微调不是被否定了，是被放回了它该待的位置：最后手段，而非第一反应。

一句话决策

把这篇 7000 字压缩成一句话：先问"这是知识还是行为"，知识走 RAG、行为先 prompt；prompt 到头了、数据过 2000 条、调用量够大，再谈微调；调了必须过 eval 门禁，否则等于没调。

微调不是效果药，是手术。手术的价值在于"非做不可"，而不是"做了显得厉害"。下次再有人跟你说"我们微调了一个模型"，你可以问他三个问题：数据多少条？eval 门禁是什么？为什么不用 RAG？答不上来——那这场手术，大概率是白挨了一刀。