Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

通俗地讲,RFT 是什么
什么时候该用 RFT,而不是提示词调优
自定义评分器能帮上什么忙
RFT 的五步循环
真正有效的数据准备
训练与上线阶段的评估纪律
一份务实的决策清单
官方链接

通俗地讲,RFT 是什么

OpenAI 的强化微调(reinforcement fine-tuning,简称 RFT)通过一个可编程评分器(grader)所定义的反馈信号来调整推理模型。目标不只是让模型的表现听起来更好,而是要把它推向某个特定领域内的专家级水平。

这让 RFT 与单纯的提示词调优区分开来。提示词方面的工作可以改进指令遵循、语气或格式,而当任务有明确的成功条件、并且可以针对一个可重复的信号来训练模型时,RFT 会更有效。

目前的公开文档说 RFT 在 o 系列推理模型上受支持,指南中点名了 o4-mini 和 o4-mini-2025-04-16。OpenAI 在 2025 年 10 月 6 日发布的 AgentKit 上线文章中也提到,RFT 在 o4-mini 上已经正式可用(GA),GPT-5 处于私有测试(private beta)阶段,自定义评分器处于测试(beta)阶段。

什么时候该用 RFT,而不是提示词调优

当问题主要在于表达清晰度、风格,或是一次小幅度的行为调整时,先用提示词调优。而当模型必须在一项难以用提示词说清楚、但容易打分的任务上变得更好时,再考虑用 RFT。

以下情况下,RFT 是不错的选择:

任务本身没有歧义
成功标准具体且稳定
领域专家能就「什么是好答案」达成一致
你需要在一个范围较窄的工作流中获得更好的推理能力
失败的代价足够高,值得为更强的训练信号付出搭建成本

这正是 RFT 适合政策审查、安全分析、法律条文选取、结构化决策支持等工作流的原因 — 在这些场景里,答案可以用一套严格的评分标准来判定。

提示词调优在塑造语气和指令方面仍然很有价值。而当提示词的改动不再带来持久的收益、你需要模型把这种行为真正内化下来时,RFT 就成了更好的选择。

自定义评分器能帮上什么忙

自定义评分器是 RFT 的核心,它们把你的业务规则转化为训练信号。

对产品团队来说,这意味着你可以把产品中真正重要的东西编码进去:

模型是否选择了正确的行动
是否遵守了政策
是否产出了正确的结构化输出
是否避免了没有依据的断言
是否留在预期的范围之内

对平台团队来说,评分器是评估与训练之间的契约。一个好的评分器会迫使团队在训练开始之前就定义好「什么算成功」,从而让整个循环保持诚实;它也让回归测试更有用,因为同一套评分标准可以在不同实验和不同检查点之间复用。

实用的判断规则很简单:如果人类专家能够可靠地判断输出结果,并且任务可以表达为一个明确的分数,那它通常就是自定义评分器的好候选。

RFT 的五步循环

公开文档把 RFT 描述为一个五步循环:

实现一个评分器,为模型的每条响应打出数值化的奖励(reward)。
上传提示词数据集,并划出一个验证集(validation split)。
启动微调任务。
监控并评估各个检查点(checkpoint),必要时修改数据或评分器。
通过标准 API 部署训练出的模型。

这个循环之所以重要,是因为 RFT 不是一次性的训练任务。你实际上是在搭建一套测量系统,再用这套测量系统去塑造模型。如果评分器本身不够可靠,模型就会学到错误的教训;如果数据集范围过窄,模型就可能过拟合到一个错误的模式上。

真正有效的数据准备

大多数 RFT 项目的成败,取决于数据质量,而不是训练命令本身。

从贴近真实生产使用场景的任务开始。既要包含简单的例子,也要包含边界情况和真正困难的案例。再加入一些模型应该拒绝回答、应该要求更多信息、或者应该遵循某项政策而不是靠猜测的场景。

一个实用的数据集通常需要:

来自真实用户或真实工作流的有代表性的提示词
干净的训练集与验证集划分
覆盖边界情况的样本,而不只是理想路径(happy path)
专家能够一致套用的稳定标注规则
足够的多样性,避免模型只学到一种脆弱的模式

如果任务使用结构化输出,就要把 schema 明确写清楚,并直接对这个结构进行评估。如果任务以文本为主,就要确保评分器不会为了文笔的润色而牺牲正确性。

训练与上线阶段的评估纪律

只有当团队把评估当作产品流程的一部分,而不是事后补充时,RFT 才能真正带来回报。

在训练开始之前,先定义好在验证集上「成功」意味着什么,以及在生产环境中「失败」会是什么样子。训练过程中,要检查各个检查点,而不是只等最终结果。训练结束后,再对一批有代表性的提示词单独做一轮复核,检查是否存在过拟合、reward hacking(奖励破解),或者行为漂移。

最有用的上线保护措施包括:

让验证集与训练数据保持分离
与「只用提示词」的基线做对比
把成本、延迟和质量放在一起追踪
在边界情况和拒绝回答的情况下也做测试,而不只是理想路径
对影响面大的部署保留人工复核关口

这对产品团队尤其重要,因为分数的提升仍然可能掩盖了更差的用户体验。一个在评分器上「获胜」、却让工作流变得更慢、更有风险或更不清晰的模型,算不上真正的改进。

一份务实的决策清单

在启动一个 RFT 项目之前,可以用这份清单自问一遍:

我们能不能把任务描述得足够清楚,让评分器可以对其打分?
专家们是否就「正确的回答长什么样」达成了一致?
这项任务是否重要到值得为数据准备和训练投入额外开销?
提示词调优是不是已经接近极限了?
我们是否有足够有代表性的数据来划分训练集与验证集?
我们能不能监控各个检查点,并与基线做对比?
如果模型在边界情况上出现回退,我们是否愿意为上线设置门槛?

如果这些问题大多数的答案都是「是」,那么 RFT 大概率值得一试。如果任务仍然模糊、宽泛,或者主要还是措辞层面的问题,提示词调优通常是更省成本的选择。