原创 孔某人 2025-02-10 17:44 北京
RFT as a Service
RFT as a Service有望成为第一种通用Agent构建平台。
0、背景知识
本节为还不熟悉相关信息的读者介绍一些背景知识。
RFT是OpenAI在2024.12月发布的针对o1系列推理模型的强化学习微调功能，截至目前为止OpenAI仍未官方发布。
由于DeepSeek R1的大热和其GRPO训练方式的广为认知，目前已经有了一些开源框架库在复现该训练方式。所以虽然OpenAI官方还没有发布该功能，但基本可以参照GRPO和目前的开源实现作为RFT方案的参考实现。
RFT相对于过去LLM的SFT/传统微调方案来说，有几个差异：
原生更匹配推理模型，或推理期计算范式
不需要准备高质量的完整参考回答，要求变为准备高质量的回答结果验证方案。
RFT（以及LLM post-training阶段的RL）可以发现一些方案构建者也未曾设想到的思考路径来实现目标。
RFT探索出的路径更符合原始LLM的“思考习惯”，相对于外部构建的SFT参考回答来说学习难度更低。
GRPO相对于传统的PPO RLHF方案：不再需要value model或Process Reward Model（PRM），方案更简单，也由此降低了reward hacking的影响。
目前RFT和post-training阶段的RL的成功案例有：
OpenAI的o系列模型
OpenAI的Deep Research功能（第一版由o3模型再进行RFT）
DeepSeek R1模型
其有用性已经不用怀疑，实际上这应该算过去半年中LLM方面最有价值的已经被验证的新技术方案。
相关阅读：Reinforcement Fine-Tuning—12 Days of OpenAI: Day 2 中文全文
1、RFTaaS平台
1.1、为什么需要RFTaaS平台
首先OpenAI已经宣布RFTaaS平台功能了，回顾历史，单就这一点就足够支撑去开发这个功能。不过本节还是正经讨论下为什么我们需要RFTaaS平台，而不是需要RFT的人自己搞。
首先一个问题是，FTaaS平台的需求较少，虽然到目前各家都已经实现了该功能，虽然我手头没有数据，但我估计国内云平台该功能的使用量并不大。RFTaaS是否会重蹈该覆辙呢？
FTaaS的不成功在我看来有几个原因：
各家云平台的FTaaS的上线太晚，等需求方都自己搞定了之后各家才姗姗来迟。
SFT的技术门槛并不算高，无论是方案还是算力，大部分技术团队可以自己搞定，特别是对于私有化部署需求的团队来说。
适合SFT的数据准备本身是更大的卡点，这方面FTaaS平台也没有更大的帮助，平台的用户方也没有低成本的办法。
FTaaS平台可能由于想要留住用户的考虑，如果微调的是开源模型，SFT后无法下载参数，这进一步排除了一些希望独立部署的用户。现在国内大部分FTaaS上支持的开源模型都很少了，一般都是仅供微调自家开源和闭源模型。
而现在对于RFT来说：
由于各方面原因目前用户对于RL、RFT类方案尝试意愿度很高，而现在还没有完全托管的平台可用。
RFT对于用户的数据要求降低了，只需要提供合适的reward方案就可以，这相对于SFT扩大了用户范围。
RFT的高上限和构建更通用方案的能力很吸引尚未实现PMF的领域的人。
RFT类方案由于新的rollout环节，需要的算力比SFT大很多。对于不是持续训练的场景有了更大的算力成本分摊压力，而这方面是云平台的优势。
RFT方案仍然依赖推理期计算，也就是会产生较长的response（包含思考过程），在context长度方面相对于SFT有更大的要求，也就意味着更大的显存和更多的算力。
RFT在以解决一些困难或领域知识缺少较多的问题时，对模型的能力和规模有一定要求，更强的模型的RFT效果会显著提升，这也对算力和显存的需求更大。
相对于SFT时代，在RFT方面，云平台相对于小团队自己搞有着更多的优势，特别是在算力分摊方面。
1.2、RFTaaS的功能设计
一直以来，云平台上产品的功能设计都是短板，不过对于RFT来说，已经有了尚可接受的参考设计：HuggingFace TRL库的GRPO的接口设计作为baseline版本。未来还可以参考OpenAI的RFT的功能设计，不过得说OpenAI在开发者平台的功能设计方面也不算很优秀。
本质上来讲，这个接口逻辑上只有：训练的模型、训练超参数、prompt数据集、reward 方案这几个，再配上模型训练中常见的指标监控系统等就基本可用了。
当然*FTaaS类平台的价值也很依赖于它是否足够开放，是否能够接入其他家的开源模型，以及在reward function中是否可以使用其他家的LLM。以及微调的开源模型参数是否可以下载。一些FTaaS平台的功能未必有多差，但它的不开放极大的限制了该功能的价值，毕竟做个第一梯队的LLM是更难的事情。不开放的FTaaS平台基本上是把用户推给了OpenAI、Qwen等第一梯队的模型厂。
RFT不同于SFT，它并不是仅依赖固定的SFT数据集，本质上它依赖reward和tool或环境等来自动生成FT数据。所以它对于tool和reward的部署支持需求显著高于SFT。一个RFT平台支持reward function和tools的云端部署应该是基本操作，而且应该是serverless的。reward function和tools也很有可能会需要通过网络访问外部。
当然如果RFTaaS平台能够集成常用的tools和reward function模式的话，会降低用户的使用成本。以及tools会成为增加用户粘性的特性之一，如果用户自己开发tools的成本较高，那么它更可能直接在该平台上直接部署该模型进行推理，以直接使用平台提供的tools。我更提倡这种通过吸引而不是“限制用户能使用的模型和阻拦用户下载微调参数”的方式来增加平台的用户粘性。
对于reward function来说，“足够有用”是决定RFTaaS平台价值的关键之一。在不同场景下reward的方式各种各样：可能是一个固定的标准答案；可能是一个复杂的json，需要custom函数来验证；甚至可能需要用一个最强的LLM模型来做语义验证。OpenAI已经支持了几种reward方式，但大多只集中于能简单实现以及能完美实现的方式。“我不好实现一个复杂json的验证，那么我就只做一个json schema验证”、“我不好做一个基于LLM的语义验证，那么我就不做这个功能”。平台是可以不做，但这实际上也就是排除了这部分用户。
平台的优势和价值在于尽量解决它的客户不好解决的问题。部署一个serverless的reward function麻烦？但这就是云平台该做的。靠外部LLM和prompt进行语义验证容易出现reward hacking？那就应该做一个reward function的结果评估和验证UI，让用户更方便地评估当前这不完美的reward的实现是否已经成为了阻碍RFT效果的瓶颈，并让用户找到指导改进reward实现的case。
在新供应链诞生之际，能够更多以及更好的覆盖整个供应链中缺失部分的平台产品，能够最快的吸引用户到自己的平台上。
1.3、RFTaaS作为集成方案的一部分
很多LLM应用中，最终B客户是希望产品能够持续自动学习的，FTaaS其实有希望成为交付产品方案中的一部分，而不是一个临时的一次性调模型工具。
但在SFT时代，自动的构建SFT数据的成本较高，甚至在一些场景下很难自动实现。B客户大部分自己没法做SFT数据，只有项目开发团队才能做。但开发团队的人工成本太高，人工去满足这种后续效果提升需求在商业上不匹配，客户付费意愿低，实施成本高。
但在RFT时代，情况出现了变化。需要的内容是种子prompt和reward方案。种子prompt更接近于客户的业务中采样的数据，采集和过滤成本不算太高。reward 方案也是接近于一次性的，可以由开发团队构建，或者是由客户构建。在长期需要迭代时，也是客户持有的领域信息更多。而剩下的工作都是RFTaaS平台自动完成，最后新模型与上一版模型在客户数据上做下diff评估或者AB实验，就能决定是否切换。
RFT时代中，RFTaaS终于有希望直接成为集成方案的一部分了。B客户更可能直接对接这个系统进行后续维护，或者就保持第一版reward不动，只是根据第一版方案开发时接通的prompt更新流程来自动更新数据。
2、高Reward成本的场景
上一节的讨论基本还是在一个“传统”的*FTaaS平台的视角下讨论的，但RFTaaS平台的商业价值不仅限于此。
让我们考虑以下几种类型的reward方式：
根据response，把一个内容推送给C端用户，看用户是否点击、观看、点赞等……
根据response（或使用当前模型参数版本继续推理），去给一个潜在销售线索客户打电话
根据response去做了一个生化实验，观察结果
在这些场景下，确实有提升方案效果的需求。而且这些场景没法事先构建一个足够好的reward function，即使采用了o1模型来进行评判也仍然不行。我们只能通过直接与环境的交互来获取reward信号。
实际上在2023年10月的时候，我就被一个创业公司CEO问过这类问题，如何在电话销售的场景下实现“整体方案根据数据自动优化”？而直到今天，让我看到第一个比较可能的自动化实现方式，就是在整个业务流程上做全链路的RFT。当然这不仅限于让模型产生一次回答，而是要完整rollout到能获得业务reward信号的时候为止，这中间可能经过多轮用户对话。在这种场景下，从产生待评估response到最终获得reward信息可能需要1天甚至更长的时间。
在这类高价值和高延迟的Reward的场景中，实际上我们仍然可以全自动的做RFTaaS。当然这需要客户系统进行充分的适配，不过据我所知，客户很愿意适配。但在这种场景中，Reward本身成了延迟最大的环节，整体系统的设计思路与能够快速反应的reward的RFTaaS平台有着很大的不同。在平台来看，平台是断断续续的收到reward信号，或者从当前候选版本模型中rollout出了少量新的trace。
在这类场景下，平台计算的计算负载很低，对平台计算的延迟要求也很低。整个RFT task是很间歇性的被唤起，更新一点点梯度。与其说这是一个云上的长时间task，不如说这是一个有点类似于云数据库的有状态系统，只不过这个有状态系统具有自学习能力。
当然这个场景下不只是云服务的工程架构设计问题，对于需要reward的样本也需要精打细算。例如如果我们已经能够区分不同action的好坏，那么就可以进行更新了，而不是等它们都采样到了固定的数量。
我不知道有多少模型层、模型infra层、硬件层的读者能相信这类需求的市场价值足够大，但对于应用层的读者来说“理解我在说什么”应该并不难。
3、通用Agent构建与运行平台
在第2节中，RFT任务实际上已经不是一个系统构建阶段的过程了。它是一个长期存在，它是整个Agent系统的一部分，而且承担着Agent中最难学习的那部分知识的学习工作。即使不是第2节的场景，只要目标场景希望模型效果持续优化，那么它就能够成为系统中的一个长期存在。
这个视角在第1节中不太显然，但当读者理解第2节后，也许能够更加接受这个视角。在第1节中，我们还希望通过tools的开发成本来增加用户的粘性。但随着RFT能够适用的场景增加，RFT平台本身就会成为这些应用场景的一个核心，整个Agent都可以基于这个平台实现。就好像是数据库的功能太强，开发方为了省事干脆把很多业务逻辑都转移到数据库的存储过程中运行了，数据库本身就成了一个业务应用运行平台。
如果RFTaaS能够起到这样的价值，并且它有一个开放的心胸，能够满足客户的一些RFT之外的需求，那么最后它就会成为一个通用Agent的构建和运行平台。
既然我的标题说它有望成为第一种通用Agent平台，就代表我认为这之前的所有平台都不是。
A、结语
我目前判断这一轮机会前期还是给大厂云平台的，也就是目前FTaaS的这些团队。它们的资源禀赋与之最为接近，但很遗憾它们大多行动都很缓慢，很可能会又赶个晚集。不知道是否有哪个大老板能够看好这个方向，去推动它们及时去做和做好这件事。
某种意义上，这可能是第三方推理平台创业公司的一个机会。但根据我过去1年的观察，我觉得这些团队大概率不会在这上行动，资源不够、决断力也不够。
希望以此文能够推动这方面更快的发展。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 联系方式。
本文于2025.2.10首发于微信公众号和知乎，知乎链接：
https://zhuanlan.zhihu.com/p/22809424150
