你的微调投资，正在被推理模型悄悄蒸发

2026 · 从什么该微调到什么还值得微调一家做合同审查的团队花了两个月微调出一个专用模型测试集指标比 GPT-4 高了整整 20 个百分点。他们很满意。然后 o3 出来了。他们几乎没做任何改动就把请求路由到 o3——没有微调没有特殊提示词就裸跑。结果o3 的表现比他们花两个月做的微调模型还好 20 个百分点。两个月的工程投入在推理模型面前蒸发了。这件事让我开始重新审视一个本以为搞清楚了的问题微调到底该用在哪 不是 2023 年的答案是 2026 年的答案。先搞懂这两件事的本质区别提示词工程和微调经常被放在一起比较但它们其实解决的是完全不同层面的问题。打个比方提示词工程像是给一个人布置任务前的交代——“你今天负责客服回答要简洁不超过 100 字语气友好”。这个人自身的能力没有变变的是他当下接受的指令和约束。微调则更像是送这个人去参加专项培训——培训结束后他处理某类问题的方式从根子上变了不需要你每次都反复交代他已经形成了本能反应。这个区别决定了它们的适用边界•提示词工程激活模型已有的能力改变它当前的行为倾向推理时生效不改变权重•微调向模型注入新的知识或行为模式持久改变权重代价是时间和数据所以如果一个模型会做但不做那是提示词的问题。如果模型根本不知道那才是微调的领域。问题是推理模型的出现把很多以前根本不知道的事情变成了会做但需要点拨。推理模型做了什么它内置了一个草稿本在 GPT-4 时代模型回答问题的方式有点像一个快速但仓促的人——它直接告诉你答案中间没有停下来想一想。对于简单的格式转换、文本改写这没问题。但遇到需要多步推理、逻辑链条较长的任务它很容易在某个中间步骤犯错而你根本看不到错在哪。推理模型o3、DeepSeek-R1、Qwen3的不同之处在于它们在给你最终答案之前会先在内部经历一个完整的打草稿过程。这个过程不对外暴露或者可以看到 reasoning_content但它确实发生了——模型在自己和自己辩论检查逻辑纠正错误。就像你让一个人估算1 到 100 所有奇数的和有人会直接脱口而出一个数很可能错有人会拿出纸笔列出步骤再告诉你答案。后者更慢但更可靠。推理模型就是那个会主动拿出纸笔的人。这个机制的后果是很多以前必须通过微调才能提升准确率的复杂推理任务换上推理模型 好的提示词就够了。数据说话法律合同条款提取这个任务2024 年 GPT-4 微调 vs GPT-4 提示词差距约 15-25 个百分点F1。到 o3提示词方案反超了 2024 年的微调模型 10-20 个百分点。那两个月的微调工作被一个模型升级抹平了。那微调的地盘剩下哪些微调没有死但它的管辖领域确实在收缩。剩下的地盘可以分成三类① 私有知识内化模型确实不知道的东西推理模型再强它也不知道你们公司内部的业务逻辑、专有术语、私有代码库。这里有个关键区分• 知识是结构化的、可检索的比如 5000 个 SKU 的规格参数→ 用 RAG不用微调。RAG 就像给模型配了一个随时可查的参考手册知识变了直接更新手册不用重新培训。• 知识是分散的、有大量隐性约定的比如内部代码风格规范没法写成一页文档说清楚→ 微调。这时候微调就像让模型浸泡在你的代码环境里慢慢培养出对你们风格的语感这是 RAG 做不到的。② 私有 DSL模型对你的语言没有感觉如果你需要模型将自然语言转换成公司内部的查询语言或配置 DSL这类问题提示词和推理模型都很难根治——因为这个语言压根不在训练数据里模型只能靠猜。这就好比让一个只学过中文和英文的翻译官帮你翻译一门自创的暗语。不管他多聪明没有专项训练就是不行。判断方法用最强提示词 10 条 few-shot 在 30-50 个测试样本上跑一遍。准确率 80% 且错误模式是语法理解偏差不是规则遗忘→ 必须微调。③ 推理成本压缩蒸馏是 2026 年最值钱的微调用法这是最容易被忽视的一块。推理模型很强但 token 消耗是普通模型的 5-10 倍——因为它要打草稿。对于大量重复性、规律性强的任务让 o3 来处理就像每天用豪华轿车接送孩子上学性价比极差。更聪明的做法是先用推理模型批量生成高质量的思考过程 答案配对然后用这些数据蒸馏一个轻量小模型。这个小模型学会了怎么想能在特定任务上以 1/10 的成本复现大模型 80% 的准确率。# 用推理模型生成训练数据蒸馏策略 from openai import OpenAI import json client OpenAI() def generate_training_sample(user_input: str, task_description: str) - dict: 用 o3 生成带推理链的高质量样本 response client.chat.completions.create( modelo3, messages[ {role: system, content: task_description}, {role: user, content: user_input} ], ) thinking response.choices[0].message.reasoning_content answer response.choices[0].message.content return { messages: [ {role: system, content: task_description}, {role: user, content: user_input}, # 把推理链一起塞进训练数据让小模型学会怎么想 {role: assistant, content: f\n{thinking}\n\n\n{answer}} ] } # 生成 200-500 条这样的样本后用 Qwen2.5-7B 这类小模型微调 # 目标小模型复现大模型 80% 准确率推理成本降低 90%这个策略有个好的类比o3 相当于一个顶级厨师你不可能在每个分店都请一个。但你可以让他把所有菜谱和操作手法录下来然后用这套材料培训普通厨师——培训完的厨师做不了满汉全席但烤鸡腿做得和顶级厨师一模一样而且成本低得多。Agent 场景最容易踩错的判断很多团队在做 LLM Agent 时遇到工具调用不稳定第一反应是提示词没写好。这个反应有时候对但很多时候错。区分方法看错误属于哪类•工具选择错该搜索用了计算器→ 提示词问题工具描述写清楚加几个示例就好•参数格式错字段类型不对→ 用 Structured Output 强制约束输出 schema基本能消灭•参数语义错格式对但值不对→ 往往是工具 schema 设计问题不是模型问题•任务分解策略错调用了一堆工具但没解决问题→ 推理能力问题换推理模型前三类都不需要微调。但有一个真正值得微调的 Agent 场景有明确 reward 信号的业务环境。比如自动化客服、代码自动修复这类场景——你能明确判断一次任务执行是成功还是失败。这时候可以用 DPO 方式收集成功轨迹和失败轨迹训练一个专门的策略模型让它学会在你的业务环境里做最优决策。# Agent DPO 微调用成功/失败轨迹训练策略模型 from trl import DPOTrainer, DPOConfig dpo_config DPOConfig( output_dir./agent-dpo, num_train_epochs2, per_device_train_batch_size2, learning_rate5e-7, # 比普通微调小很多防止过拟合 beta0.1, # KL 惩罚系数偏离原始模型的代价 loss_typesigmoid, ) trainer DPOTrainer( modelmodel, ref_modelref_model, # 原始模型作为锚点保持不动 argsdpo_config, train_datasetdataset, # 包含 prompt/chosen(成功)/rejected(失败) 三列 ) trainer.train()这个方向在 2026 年还在快速发展是最有价值也最难做对的微调应用场景。一张可以直接用的判断表不废话给一个决策流程• 用的是推理模型→先裸跑提示词大部分你以为需要微调的任务推理模型直接搞定• 问题是格式/结构输出→Structured Output不需要微调• 私有知识结构化可检索→RAG比微调便宜灵活• 私有 DSL / 隐性业务规范→30-50 样本测试 80% 准确率 → 微调• 海量重复任务推理成本是瓶颈→知识蒸馏用推理模型生成数据微调小模型• Agent 场景有明确 reward 信号→DPO 微调策略模型真正该问的问题回到最开始那个故事。那个团队的两个月没有浪费——他们弄清楚了合同审查任务的评估方法、测试集构建方式、关键指标定义。这些东西当推理模型来了让他们能在三天内确认o3 直接好用而不是花两个月再来一遍。微调的边界在收窄但工程判断力的价值在上升。真正该问的不是用提示词还是微调而是我的基础模型有没有这个任务的存量能力有多少用什么方式激活最便宜2026 年的工程现实推理模型把很多必须微调变成了提示词就够RAG 覆盖了大量知识注入需求微调真正有价值的领地越来越聚焦——私有 DSL、成本蒸馏、Agent RL。聚焦就是好事。与其把微调用在所有地方不如把它用在真正值得的地方。如果这篇文章对你有帮助欢迎转发给在做 LLM 工程的同学。