大部分 AI 产品的真正壁垒,是后训练。
真心推荐所有的 AI 创业者,都看看 Fireworks CEO 的对谈播客。Fireworks 这家公司,我觉得大概率会成为 OpenAI 之后,硅谷最炙手可热的创业公司之一。
周末两天,我一边 Vibe Coding,一边看他们 CEO Lin Qiao 的观点,收获非常大。尤其是她对 AI 应用怎么建立壁垒,以及为什么过了 PMF 以后要开始做后训练的思考,值得仔细咀嚼。
下面是我不成体系的手工笔记。
1、AI 应用一旦过了 PMF,都应该认真考虑下是否要做自己的专用模型。这绝对不是什么异想天开的事情。
因为 Anthropic、OpenAI 的模型实在是太贵了,调用量越大,反而可能亏的越多。
之前传统 SaaS 产品找到 PMF 以后,新增一个用户的边际成本很低。然后随着用户越来越多,研发这些固定成本被摊薄,毛利通常会越来越好。
但 AI 产品不一样。它不会出现边际成本递减的情况。每一个用户都会实实在在的消耗 Token,而这些 Token 真的都是钱啊。大家记得吧,去年 Cursor 就是那样,虽然收入一直在增长,但与此同时模型成本也在一起增长。
最后产品是你做的,用户是你找的,但赚到的钱又通过 API 费用交给了模型公司。
2、基于开源模型后训练的专用模型,可以大幅降低 AI 产品真正的任务成本。
因为一个针对具体任务做过后训练的模型,效果可以做到和最强的通用模型差不多,甚至更好,但推理成本可以下降 5 到 10 倍。
最近硅谷法律 AI 独角兽 Harvey 就做了一个很好的 Case。他们和 Fireworks 基于 Kimi K3 后训练出了 Tenet 这个专有模型,在法律类任务上,它的表现要比前沿模型好很多,而且运行成本不到前沿模型的四分之一。
很有意思的一点是,他们直接把效率放进了 Reward。完成同样任务的情况下,训练会更偏好 Token 消耗更少、工具调用更有效的轨迹。
所以后训练优化的已经不只是模型能力,还可以直接优化每完成一个任务到的成本。这直接决定一个 AI 产品能否产生规模化的利润。
3、当然,成本只是一部分考虑。更重要是,产品过了 PMF 之后,会产生大量的数据,而这些数据都是用户在真实任务里的选择和反馈,非常宝贵。和互联网上的公开数据完全不一样。
如果模型一直是别人的,这些数据的价值其实很难完全发挥出来。
你当然可以拿它们继续优化 Prompt、做 RAG、迭代产品,但更进一步,其实是得把这些反馈重新训练进模型。这样模型下一次再碰到类似任务的时候,就能知道什么样的结果更好。
4、一个基本的判断是,智能最终来自数据。今天基础模型能够训练的数据主要来自公开互联网和人工标注,只占全世界数据的一小部分。
真正大量的数据,还是在企业自己的应用和业务系统里。
比如一家法律公司的案件研究数据,或者一家医疗公司的医生搜索数据,都是非常宝贵的 Know How 数据。
所以,Fireworks 认为,AI 的未来绝对不会只剩下几个通用大模型,而是可能出现数百万个专用模型。任何一个规模大一些的 AI 应用,都会有自己的模型。
5、当然,这些公司不会从头开始训练模型,而是在开源模型的基础上进行后训练。后训练会越来越重要,好的 AI 应用公司,一定会有一支优秀的后训练团队。
因为 AI 时代,应用越来越容易复制。过去一个新产品可能需要几十个工程师、几个月才能做出来,现在几个人用几周时间就能做出一个可用版本。
应用层的实现门槛快速降低以后,公司真正独特的东西会越来越集中到自己的数据、产品判断和对用户的理解上。
后训练其实就是把这些东西写进模型里。
6、不过也不建议一开始就做后训练。
产品没过 PMF 之前,直接调用最强的通用模型,用 Prompt 和 Few-shot 把产品跑起来。这个阶段最重要的,是先验证用户到底有没有这个痛点。
如果必须接一些行业 Know How,就用 RAG,简单粗暴,把需要的数据临时塞进 Context 里。
等产品过了 PMF,开始积累大量真实用户数据,就可以做 SFT。比如你已经知道什么样的回答用户会接受,就可以把这些高质量样本拿来继续训练模型。
SFT 更适合解决这种有比较明确标准答案的问题。你希望模型以后遇到类似任务时,输出格式更稳定,行为更符合产品要求,少犯一些重复性的错误。
但再往后,很多问题其实没有标准答案。
比如两份医疗研究报告都没有明显错误,但医生就是更喜欢其中一份。两段代码都能运行,但程序员明显觉得其中一种写法更好。
这时候光靠告诉模型正确答案就不够了,因为这里根本没有唯一的正确答案。你需要告诉模型,在两个都能用的结果里,我们更喜欢哪一个。
DPO、KTO 这类 Preference Tuning 其实就是在把用户长期表现出来的偏好,训练进模型。
再往后,如果模型已经能完成任务,但在复杂任务里的成功率还不够高,就可以开始考虑 RL。
像 Coding Agent 这类任务,中间往往要连续做很多步决策。模型可能已经会写代码、会搜索资料,但它不一定知道最佳的路径。
这种任务很难提前准备大量完整的标准答案,因为真正影响结果的,是模型在整个过程中动态的选择和推理。
RL 更适合解决这类问题。先让模型自己不断尝试,再根据最后的任务结果给出 Reward。
成功的路径得到更高分,失败或者低效的路径得到更低分,模型慢慢学会哪些决策更容易把任务做成。
所以通常是先用 SFT 让模型具备基本能力,再用 RL 去提升复杂任务里的决策和执行能力。
最后还有蒸馏。比如一个很大的模型已经能很好地完成某个任务,就可以让它产生数据,再把这些能力训练到更小的模型上。
最后在这个具体任务上,可能用一个小很多的模型,也能达到接近的效果,但推理成本会低很多。
7、所以这几个东西其实对应的是不同阶段的问题。Prompt 和 RAG 解决怎么先把产品做出来,SFT 和 Preference Tuning 开始把真实用户数据写进模型,RL 再往上提升复杂任务的能力,蒸馏则把已经验证过的能力尽量做得更便宜。
林乔对 SFT 和 RL 的解释很容易理解。SFT 有点像给模型一本教材,把正确答案直接告诉它,让它学习这些答案。RL 更像让模型自己做题。
模型先尝试一种方案,然后去真实产品或者模拟环境里执行,根据结果拿到一个从 0 到 1 的 Reward。如果分数很差,就退回来尝试另一条路径,不断探索,直到找到高分方案。
8、RL 真正难的地方,不是训练算法,而是 Reward 到底怎么定义。Reward 可以直接理解成代码。先把一个好结果拆成多个评分维度,再按照公司的标准组合这些分数。
比如做招聘 Agent,可以分别评价候选人的能力、行动速度、韧性,再给这些指标不同权重。不同公司的权重和标准都不一样,这些细微差异最后就会变成模型里的产品判断。
9、Reward 设计不好,模型还会钻空子。比如要求一个 Coding 模型尽可能减少编译错误。模型最后找到的最佳方案,是一行代码都不生成。
这样确实没有任何编译错误,分数也很好,但完全没有完成真正的任务。RL 里的 Reward Hacking 很常见,所以模拟环境和评分标准必须尽量接近真正想解决的问题。
10、做后训练的时候,数据质量远比数据数量重要。单纯把大量数据扔进去,并不一定能得到好模型。
最有资格判断训练数据好不好的人,往往是产品团队,因为他们最了解用户到底需要什么。这也会让过去相对分开的产品团队和模型团队越来越融合。
11、Eval 也是一样。早期大家经常靠人看几个 Case,觉得这个答案好不好,这种方式可以启动,但最后必须把这种主观判断变成一套可以反复执行的 Eval。
Eval 可以类比成传统软件开发里的单元测试和集成测试。人的感觉需要逐步被拆成明确指标,否则模型每训练一次,都不知道究竟变好了还是变差了。
12、模型做完后训练也远远没有结束。最终还是要放进真实产品里做 A/B Test,看用户体验和产品指标到底有没有提升。
而且模型从训练环境切到线上推理环境以后,效果甚至可能变差。因为两边用的计算库、数值精度和推理优化方式不完全一样,同一个模型最后跑出来的结果也可能出现偏差。
所以 Fireworks 会特别强调训练和推理的一致性,尽量让模型上线以后,和训练时保持完全一样的表现。他们把这件事叫 Zero KLDE,目标就是避免模型明明训练得很好,一部署到线上,能力反而掉下来。
13、还有一点我很认同,以后比较模型成本,不能只看每百万 Token 多少钱。假如 A 模型每个 Token 的价格便宜一半,但完成同一个任务需要输出两倍 Token,那两者真实成本其实一样。
更合理的指标应该是每个任务的 Token Economics,也就是完成同一件事情到底花多少钱。
链接给大家分享下:
-
www.youtube.com-
www.youtube.com-
www.youtube.com