微调通常是过早的：先穷尽评估、提示与检索三层

当 AI 功能「差一点就成」时，总有人提出：我们该微调了吧。听起来很认真，像是向前推进。但多数情况下，这是错误的下一步。

大多数伸手去拿微调的团队，缺的并不是权重。他们缺的是上下文、提示词、检索，或者最常见的是——缺少一套评估。微调昂贵、难以回退，而且很容易因为错误的理由启动。先把更便宜的层次穷尽，只有当可测量的残差缺口证明模型本身是瓶颈时，再考虑微调。

rss source: Fine-Tuning Is Usually Premature

一个诱人的叙事

微调兜售的是一个干净的故事：拿你的数据，教模型你的领域，然后上线更聪明的产品。厂商把按钮做得很简单，博客把收益写得像理所当然，利益相关者听到「定制模型」就点头。

这个故事跳过了几件事：

微调并不能可靠地注入私有或变化中的知识，检索可以。
微调不能替代缺失的评估标准，评估可以。
微调会把你锁进一个训练循环：数据准备、回归测试、基础模型更新后重新训练，以及每个季度都要支付的维护税。

如果你还不能在一个固定评估集上给基础模型打分，那你还没准备好微调。你只是在用 GPU 猜。

**RAG（Retrieval-Augmented Generation，检索增强生成）**是一类在推理时先从外部知识源（向量库、文档库、工单系统、实时 API 等）检索相关片段，再把这些片段拼接进提示词交给模型生成的架构模式。它与微调的关键差别在于：知识存放在外部而非模型参数里，因此更新文档就等于更新知识，可以做到分钟级时效；每条回答都能追溯到具体来源，便于引用与审计；访问控制可以按用户身份在检索层过滤。相比之下，微调把知识烘焙进权重，更新需要重新准备数据、重新训练、重新回归，天然更重且不可审计。当缺口是「模型不知道我们最新的政策」时，这属于检索问题而非权重问题。

先诊断缺口，再选工具

要问的是：今天的模型和任务之间，到底缺什么？

知识缺口。 模型缺少你的文档、工单、政策或近期事实。这是检索的问题（RAG、对实时系统的工具调用），不是权重的问题。把事实教进参数里，无法替代引用、时效性和访问控制。

行为 / 格式缺口。 语气不对、JSON 不规范、步骤不一致。这通常是提示词问题：更清晰的系统指令、少样本示例、结构化输出、重新追问的验证器。许多「我们需要微调」的工单，在针对评估工具进行两周严格的提示工程后就消失了。

能力缺口。 即使有完美的上下文和认真的提示努力，仍然存在可测量的失败——大规模下的模式合规、狭窄的分类体系、需要更小的专用模型来满足延迟/成本。这才是微调能获得一席之地的地方。

能力缺口是真实存在的。但它们比路线图幻灯片所暗示的要罕见得多。用数字来确认，而不是靠感觉。

真正有效的顺序

生产团队反复使用的一个实用序列：

建立黄金评估集 — 50–200 条真实输入，附带预期输出或清晰的评分标准。给它版本控制，跑一个基线。
改进提示词 — 角色、约束、示例、结构化输出。重新打分。
修复上下文 — 更好的检索、工具调用、稳定前缀的缓存。把检索和生成分开测量（oracle-context 测试很有帮助：如果完美的片段能修复答案，就别再怪模型）。
只有在这之后才考虑微调 — 当残差缺口是形式、顽固的指令遵循，或大规模下的单位经济性，并且你有数百到数千条干净的标签。

组合胜过对立。提示词始终在场。检索注入知识。微调是在特定、可测量的失败模式下的一种可选优化——通常是在更小、更便宜的模型上。

其他来源也明确说过同样的话：按缺口选择，而不是按流行语选择；在微调之前穷尽上下文工程；当你其实有检索问题时，停止微调。OpenAI 自己的指南也推动同样的纪律：在把微调当作默认升级之前，先投资于评估和提示词。

oracle-context 测试是一种常用于定位 RAG 系统故障边界的诊断方法：在推理时不再使用检索器返回的片段，而是直接把「理论上最理想」的上下文（即已经人工确认为正确答案所需的那几段文本）硬塞给模型。如果在这种「作弊」条件下模型能给出正确输出，说明瓶颈在检索环节——切片策略、嵌入质量、召回排序、过滤条件或访问控制出了问题；反之，如果连完美上下文都无法修复答案，问题才可能落在模型本身的推理或格式遵循能力上。这个测试的价值在于把「检索失败」与「合成失败」彻底解耦，避免团队在没定位清楚根因时盲目升级到微调，白白承担训练与维护成本。

微调真正被合理使用的时候

我信任的绿灯：

你已经针对固定评估集跑了认真的提示 + 检索战役，分数已经趋于平稳
你能用一句话说出残差失败（例如「40 个专有条款标签」、「p99 下的严格模式」、「该 QPS 下 Haiku 级成本」）
你有足够多干净、有标签的示例（狭窄任务大约 500+ 条；质量胜过嘈杂的数量）
你会回归测试安全性和广泛能力，而不只是目标指标
当数据或基础模型漂移时，你有负责重新训练的人

一个有数千条律师标注示例和可测量基线的法律条款分类器，是合理的微调。而「我们的聊天机器人应该听起来更像我们」，在下午花了一小时提示词之后，不是。

人们低估的成本

微调不只是训练账单：

错误诊断税 — 在检索或提示词本可以缩小差距时，花数周准备数据
遗忘和安全漂移 — 行为在训练分布之外发生变化；每次运行都需要广泛的评估
过时 — 知识形态的微调会腐烂；基础模型升级会强制返工
相对于提示词的不可逆性 — 回滚系统提示词是一个 diff；回滚权重变化是一个流程

如果你的团队无法在生产日志中区分检索失败和合成失败，就不要再增加一个活动部件。

**灾难性遗忘（catastrophic forgetting）**指的是模型在针对性微调后，虽然目标任务表现上升，却在训练分布之外的通用能力上出现退化：原来能顺畅处理的多语言、代码、长链推理或安全拒答，可能因为权重被新数据拉扯而变差。这在小数据集和高学习率下尤为明显。它与「安全漂移」往往同时发生——对齐行为、拒答边界、语气约束都可能被目标任务的梯度覆盖。因此微调的评估不能只看目标指标，还需要一套覆盖通用能力与安全红线的回归集，每次训练都跑一遍，否则上线后才发现模型在其他场景「变笨」或「变得更容易被诱导」，回滚成本会远高于一次系统提示词的 diff。

一份决策清单

在把「微调」放上路线图之前：

我们有版本化的评估和基线分数吗？
我们是否已经针对该评估在提示词和结构化输出上花了真实周期？
如果知识缺失，我们是否证明了检索（包括 oracle-context 测试）？
我们能否在不使用「更聪明」这个词的情况下陈述残差缺口？
我们有标签、负责人和回归计划吗？

如果任何一个答案是否定的，微调就是过早的。

结论：手术刀，不是徽章

微调是针对已确认残差缺口的手术刀——不是证明你的 AI 团队「认真」的徽章。

不要从权重开始。从测量、上下文和提示词开始。当数字仍然说模型是瓶颈时，再调——最好是一个更小的专用模型，并且对维护睁大眼睛。

你的护城河不是定制的检查点，而是评估集、反馈循环，以及让每个变更都可证伪的、无聊的运营纪律。