基模能力越来越强,微调(RLHF、SFT)还有价值吗?
最近两年大模型的迭代速度快得让人恍惚几乎每隔几个月就会有新一代通用基座模型发布推理、知识、理解能力的边界一次次被拓宽。随之而来的一个讨论也越来越高频既然基模已经越来越强那我们花大力气做的 SFT、RLHF 这些微调工作会不会很快被新一代基模抹平还有必要继续投入吗不少团队都有过类似的尴尬辛辛苦苦攒了几千条数据、跑了几周训练出来的垂类模型新基模一发版人家零样本效果就和你微调后的效果差不多甚至更好。一时间 “微调无用论” 颇有市场。但在我看来微调从来没有失去价值只是它的核心价值正在发生迁移 —— 从过去的补能力转向了控行为、控偏好、控成本、控风险。搞清楚这个定位变化才能真正判断微调在你的业务里到底值不值得做。一、先把概念说透SFT、RLHF、DPO 到底在解决什么问题聊价值之前先跳出公式和论文用最朴素的逻辑理清楚这些常被提起的名词到底是什么、各自解决什么问题。很多争论本质上都是把手段和目标混为一谈。SFT教模型 “照着做”SFT监督微调的本质非常简单给模型看一批高质量的标准答案让它模仿这种回答方式。比如你想让模型处理退款咨询时先索要订单号再做判断而不是直接下结论你就准备一批对应格式的问答样本让模型学习这种行为模式。它解决的是「怎么做」的问题 —— 输出格式、业务流程、工具调用规范、统一话术这些都可以通过 SFT 让模型形成稳定的行为习惯。但很多人对 SFT 有一个典型误区把它当成知识库用把业务规则、产品说明一股脑塞进训练数据里。这其实是选错了场景。业务知识是动态变化的今天的 7 天退款规则明天可能改成 15 天训进模型里的知识更新成本极高还容易残留旧信息。这类动态知识天然更适合 RAG 或者工具查询来解决。一句话总结SFT 教模型「怎么答」不适合教模型「答什么」。RLHF教模型 “选更好的”如果说 SFT 是给标准答案那RLHF人类反馈强化学习就是给偏好判断。同一个问题可能有好几种都不算错的回答但业务场景里有更优的选择是先道歉还是先讲规则是更简洁还是更详尽遇到风险问题是直接拒答还是给出替代方案这些问题没有唯一正确解只有更符合业务偏好的解。RLHF 的典型流程是先让模型生成多个候选回答由人标注出优劣训练出奖励模型再通过强化学习让模型往人类偏好的方向对齐。它解决的不是 “对不对”而是 “好不好” 的偏好问题。RL只要有反馈就能优化RL强化学习是比 RLHF 更宽泛的概念它不一定需要人类反馈只要你能定义出明确的奖励规则就可以用 RL 来优化模型。比如代码生成任务能跑通单测就给高奖励编译报错就给低奖励比如 Agent 工具调用调对工具、参数合法就加分越权操作就重罚。和 RLHF 依赖人的主观判断不同RL 的核心是可验证的环境反馈——奖励越明确、越客观RL 的效果就越可控。PPO 与 DPO两种优化路径很多人会把 PPO、DPO 和上面的概念混为一谈其实它们是实现层面的方法而不是目标。PPO是一种经典的强化学习优化算法在 RLHF 里用来在提升奖励的同时约束模型不要偏离原模型太远避免为了刷奖励出现 “奖励黑客” 现象比如疯狂输出长文本、过度客套这类走形的问题。它的核心思想是 “可以优化但别一步迈太大”。而DPO直接偏好优化是近年流行的轻量方案它跳过了单独训练奖励模型和复杂的 PPO 流程直接用偏好对数据训练模型让模型自动偏向更优的回答。它的优势是工程实现简单、训练更稳定大大降低了偏好对齐的门槛。当然它也有边界极度依赖偏好数据的质量也没法替代真实环境里的多轮交互反馈。二、为什么很多垂类微调会被基模轻松抹平先说结论会被抹平的大多是低壁垒、低质量的微调。真正有深度的微调基模很难简单覆盖。容易被迭代掉的微调通常有这几个特征第一只补通用知识。如果你只是攒了几千条技术常识、行业基础问答去微调那被新基模抹平是必然的。通用知识本来就是基座模型的核心能力人家用更大的参数、更多的语料训练出来的效果天然就比你小范围微调的覆盖面更广。这类微调没有任何护城河本质是在补基模本来就会、只是还没那么熟的内容。第二只调风格没有量化评测。很多团队所谓的 “行业微调”最后只落得一个 “感觉回答更像业内人了” 的评价。没有测试集没有准确率、格式合规率、幻觉率这些硬指标全靠主观感受判断效果。这种微调本身就站不住脚基模一升级你甚至都没法证明自己的模型还有没有优势。第三数据质量低下。SFT 不是数据越多越好低质量的数据不仅没用还会污染模型。很多团队拿未经清洗的历史聊天记录直接训练里面混杂着错误话术、过时规则、客服的随意表达甚至用户隐私。这样训出来的模型效果不稳定是常态甚至可能比原基模还差。第四没有闭环的 RL 方案。RL 听起来高级但如果没有明确的奖励定义、没有环境反馈、没有线上监控它就只是个技术名词。很多人说要做 Agent 的 RL但连工具调用成功率、任务完成率怎么定义都说不清更不用说怎么避免奖励黑客、怎么监控策略退化了。这样的 RL本质是样子工程自然很容易被更强的基模替代。三、微调的真正破局点从补能力到控行为与控决策基模再强也不可能天然适配每一家的业务流程、品牌口径、成本要求和风险标准。这就是微调真正的价值空间。SFT 的核心价值稳定行为与降本提效SFT 的未来从来不是让模型知道更多而是让模型在固定场景里更稳定、更可控地输出。固化输出格式生产系统对结构化输出的要求是 “稳定”而不是 “大概能行”。字段不能缺、枚举不能乱、数值不能瞎填强基模靠 Prompt 也许能做到八九成但对于高并发的核心链路用 SFT 把输出格式焊死是更可靠的选择。固化业务流程很多业务不是简单的问答而是有严格的步骤。比如客服退款要先识别意图、再要订单号、再查状态、最后判断规则比如工单处理要按分类走不同的处理路径。这类标准化流程通过 SFT 可以让模型形成稳定的行为范式减少自由发挥带来的流程错误。统一行业话术与品牌口径金融、医疗、政务这类强监管场景措辞本身就是业务的一部分。同样是拒绝用户生硬的拒绝和引导式的表达风险和用户体验天差地别。这种品牌级、行业级的表达规范通用基模无法天然对齐正是 SFT 的用武之地。小模型降本这是非常现实的工程价值。大模型效果好但成本高、延迟高。对于工单分类、信息抽取、简单咨询这类固定场景完全可以用大模型生成高质量样本再 SFT 出一个小模型来承接大部分流量复杂问题再路由到大模型。不求超过最强基模但求够用的前提下把成本打下来这就是实打实的收益。RLHF 与 RL 的核心价值对齐偏好与优化决策如果说 SFT 解决的是 “稳不稳定”那 RLHF 和 RL 解决的就是 “好不好” 和 “会不会做决策”。RLHF对齐业务偏好大量业务问题没有唯一正确答案。用户投诉先安抚还是先讲规则什么程度的问题该转人工拒绝用户的时候把握什么分寸这些选择直接影响用户体验和业务风险却不是靠几条 Prompt 或者 SFT 示范就能完全覆盖的。通过偏好对齐让模型的整体输出风格和策略符合业务预期这是 RLHF 不可替代的价值。RL优化多步决策Agent 时代RL 的价值会越来越凸显。Agent 不是只说一句话而是要做一连串动作选工具、填参数、读结果、判断下一步、执行操作每一步都可能出错。如果你能定义出工具调用成功率、任务完成率、参数合法率这些可量化的指标就可以把它们变成奖励信号用 RL 持续优化模型的多步决策能力。这和基模的通用推理能力是两个维度的事情 —— 基模再聪明也不会天然知道你家的工具体系和任务路径该怎么选。当然RL 的前提是奖励清晰可验证。代码、数学、工具调用这类有客观对错的场景RL 的价值最高如果只是主观上 “觉得回答更好”那贸然上 RL 很容易训歪。尤其要注意的是对于退款、数据删除、对外通知这类高风险动作永远不要把安全寄托在模型训练上。RLHF 也好SFT 也好只能提升模型做出正确选择的概率工程层面的权限控制、二次确认、操作日志、回滚机制才是风险的最后一道防线。四、工程实践什么时候该用微调什么时候不该技术选型最忌讳手里拿着锤子看什么都是钉子。微调不是银弹在决定投入之前一定要先判断有没有更轻量的方案。我的判断逻辑很明确按优先级从低到高走先试 Prompt如果只是调整输出结构、语气、简单规则优先用 Prompt 解决。能靠指令约束稳定实现的需求就不要引入训练成本。毕竟训练意味着数据准备、版本管理、评测上线、回滚预案一整套工程链路成本远高于改几条 Prompt。知识问题优先 RAG只要核心是外部知识、动态信息比如产品文档、政策条款、库存价格一律优先考虑 RAG 或者工具查询。知识更新是常态把知识和模型解耦才是可维护的架构。行为不稳定再考虑 SFT当 Prompt 已经写得很长很复杂还是经常出现格式错乱、流程跳步、话术走样而且这个场景是高频固定场景再考虑上 SFT。有偏好对齐需求考虑 DPO/RLHF多个答案都正确但业务有明确的风格、策略偏好可以先从更轻量的 DPO 入手数据和场景复杂再考虑完整的 RLHF 链路。有可验证反馈才上 RL只有当任务有明确的、可自动化的奖励信号时才值得投入做 RL。否则很容易变成为了技术而技术的面子工程。反过来也有几类场景我不建议贸然做微调业务流程、规则还在频繁变动的阶段不要重仓微调不然改一次规则就要重训一次成本高到离谱。没有建立评测体系的不要盲目微调。没有量化指标你永远不知道是变好还是变坏全靠感觉的优化都是玄学。数据质量没保障的先治理数据再谈训练。脏数据训出来的不是垂类模型是垂类问题集合。五、怎么判断微调真的产生了价值判断微调有没有用不能靠 “感觉更流畅了”要靠完整的指标体系。一套合格的评估至少要覆盖这几个维度任务指标这是最核心的比如分类准确率、信息抽取 F1 值、JSON 格式合法率、工具调用成功率、任务完成率直接对应业务目标有没有达成。质量指标比如幻觉率、无证据回答占比、错误拒答率、人工接管率。很多时候表面上任务完成了但实际上模型在胡说八道这类风险必须监控。成本指标如果微调的目标是降本就要算清楚单次调用成本下降了多少小模型承接了多少流量大模型调用量减少了多少。效果差不多的前提下成本降一半就是硬价值。风险指标高风险业务尤其要关注比如越权操作率、错误放行率、投诉率、触发二次确认的比例。微调不能只追求体验好还要看风险有没有降低。最后回归测试是底线。每次模型迭代都要跑完整的回归集避免出现 “这个场景好了另一个场景崩了” 的情况。六、写在最后基模越来越强对整个行业来说当然是好事 —— 它把大量通用能力的门槛拉到了极低的水平让我们不用再从零开始补基础能力。但这并不意味着定制化优化就失去了意义。微调的定位变了它不再是弥补基模能力不足的补丁而是让通用模型适配具体业务的精细化工具。它解决的是基模天然解决不了的问题你的业务流程、你的品牌风格、你的成本约束、你的风险标准。技术选型从来不是追热点而是在合适的场景用合适的方案。知道什么时候该做微调更知道什么时候不该做这才是真正的工程判断力。互动话题你的业务里微调不可替代的核心价值是什么新基座变强后你会缩减微调投入还是换轻量化微调方案我是阿宇欢迎聊聊你的落地踩坑经历