一线研究员闭门讨论：蒸馏变难后下一步重点是什么

1.Astra 最明显的使用变化，是 agent 能在更多软件里把任务做完。虽然在 Astra 发布之前，agent 就已经能在 Obsidian、GitHub 中处理不少工作，但到了 Blender、游戏引擎、Excel 等相对复杂软件，最后几步常常还要人接手。Astra 的 Computer Use 能力提高后，agent 通过软件界面来执行任务操作也更顺畅了。

2.Computer Use 还让 agent 有机会使用没有给 agent 开放完整接口的软件。比如 LinkedIn 不一定愿意通过 API 开放全部信息，因为这可能影响自身平台的商业价值；企业内部的 Salesforce 等业务系统，往往需要专门集成才能相互交换信息，大量旧软件也很难逐一补上 CLI 或 API 接口。但有了 Computer Use 之后，只要人类用户能在界面上看到、操作，agent 就有机会完成同样的动作。

3.Astra 在 Computer Use 能力上的提升不是一蹴而就的，其实是 OpenAI 长期投入的结果。和国内不同，海外头部模型厂长期保留着较大的 GUI 团队，甚至相关投入规模仅次于 Coding；而国内部分团队则缩减 GUI 投入、转向 Coding。因此，新模型突然变得好用，可能是过去的投入积累终于反映到了产品体验上，不一定来自某个单独的技术突破。

4.但 Computer Use 能力的进步不代表模型的通用视觉理解有同等提升：

•软件和屏幕操作有相对规整的布局和明确按钮，即操作目标更明确，因此这类任务比一般的图像理解更容易让模型训练和验证；

•模型能操作软件界面，也不代表 agent 的操作已经足够稳定。一个例子是电商弹窗，弹窗的位置和样式经常变化，人通常知道去右上角找关闭按钮，模型却可能反复出错。

•一个应对方法是，人把经验写进 Prompt，或存入 Memory、由负责执行流程的 Harness 调用，可以减少部分错误。但经验怎样总结、何时调用，通常仍由人设计，换个界面就可能失效。因此，模型要适应没见过的界面，还需要自己从交互中总结经验，并判断什么时候适用。

5.模型能否积累经验，也会影响企业是否愿意为它改造系统。在考虑这个问题时，企业不仅会看 agent 执行任务的速度和资源消耗，也看 agent 每次完整任务时需要多少人工介入。假如经过 3-5 轮人工反馈，agent 就能减少重复错误，企业会更愿意投入资源来打通 agent 接口；假如同样的问题每次都要人处理，企业就很难判断为 agent 改造到底能带来多少回报。

6.长期来看，Computer Use 是否依然重要，仍存在分歧：

•购物、外卖等平台为了争取 agent 带来的订单，会逐步开放 CLI、API，AI Coding 也降低了系统改造成本。接口开放后，agent 可以直接调用软件服务，不需要再逐步点击界面。因此，agent 对 GUI 的依赖可能在过渡期达到高峰，随后下降。这类似人驾与自动驾驶混行时，交通更复杂；等车辆都改为自动驾驶，协调起来反而更简单。

•旧系统太多，新软件也不一定优先面向 AI。即使更多平台开放接口，agent 仍需要通过 Computer Use 操作那些无法直接调用的系统。

7.当 agent 能执行更多软件任务，下一个问题就是，AI 能否进一步参与模型研发？也就是 RSI。

8.今天 agent 参与模型研发的一个早期实践是：当模型厂每进入一个新领域（domain）时，往往都需要确定 Benchmark、找数据、搭环境、做训练。为了应对领域增多、人手有限的问题，有团队开始尝试让 agent 执行人类预先设计好的流程，接替部分 ML Engineer 的工作。

9.还有团队曾把模型研发的操作方法保存为共享 Skill，供同事和 agent 查用，当时还没有通过训练把这些经验写入模型参数，但这套共享系统在当时反而降低了研发效率。这背后的问题在于，模型分不清哪些记录适用于当前任务，因此有时 agent 会照搬同事处理另一项任务的方法，跑了很久才发现做的不是用户要的事。

但 Agent 执行固定的研发流程不等于 RSI

10.让 agent 执行固定的研发流程其实并没有在真正意义上实现 RSI，因为数据、workflow 和评价标准仍主要由人设计。

11.有厂商曾只给 code agent 提供算力，让它自己造数据，但没有看到模型能力在持续改进，甚至给模型加入联网搜索的能力后，问题还是没有解决。

12.如果要真正实现 RSI，agent 就要做到能够根据实验结果决定下一步改什么、哪些经验值得复用，并推进后续模型研发。如果要实现这个效果，模型就要能作出研发判断，需要能理解模型训练方法和相应的实验结果。

13.至于怎么才能做到 agent 自主推进实验，有观点表示，前沿大模型的 post-training 经验很少被公开，所以模型可能没有学过最新方法、也无法自主补充这方面的知识，因此模型最终可能仍需要人补充相关知识。

14.但较弱的模型能否通过自主探索补上相应知识，并进一步训练出更强的模型？在这一点上，不同的人有不同的看法：

•一种观点认为，知识不足会降低探索效率。比如棋类游戏有明确的规则和胜负，模型可以根据反馈调整，但“超越 GPT-6”存在大量可能的研发路径，模型未必知道该尝试哪一条。直接补充研发知识，可以帮助模型在有限的时间和资源内找到方向。

•按这种观点推演，较弱的模型即使增加尝试次数，也不一定能补上知识的缺口。一个假设是，前沿模型能找到某道数学题的证明路径，较弱模型可能尝试了一百万次仍找不到，因此再用这些失败轨迹训练，也不一定能让弱模型学到有效方法。

•另一种观点认为，模型当前的知识不等于模型的上限。RSI 本来就是要让模型通过探索获得新知识、改进研发方法，起点较弱并不意味着它无法训练出更强的模型。

15.对于“人提前拆解了模型需要达到的目标，算不算降低了 RSI 的要求”这个问题，今天也还没有共识。从本质上来看，把“超越某模型”改成“在几个 Benchmark 上超过它”，意味着人已经替模型作出了一部分判断。

•一种观点认为，现阶段可以先验证模型能不能自动找数据、完成训练，再逐步让它自己拆解更模糊的目标。

•另一种观点认为，拆解目标本来就应该由模型完成。人提前选好 Benchmark，相当于把自己的经验提前输入给模型，那么模型实际验证的其实是一个更容易的问题。

Kernel 优化可能是最适合先实现 RSI 的场景

16.Kernel 优化类任务可能是今天最适合先实现 RSI 的场景之一。Kernel 是 GPU 上执行计算的程序，优化的目标是在特定计算任务和输入规模下提高运行速度。

•这类任务的优势在于反馈直接：修改后的代码可以直接放到 GPU 上运行，看运行速度有没有提高，再根据测试结果继续优化。

•同时，模型厂清楚自己需要优化哪些计算任务，也有熟悉 GPU 编程的工程师，相关内部专家可以直接提供专业知识。

17.优化后的 Kernel 还需要接入实际训练系统，确认计算结果正确，并且能与别的模块配合，才能真正节省资源、加快实验。对于这一步到底有多难，目前的判断存在分歧。

•一种观点认为，针对确定模型的实际输入做优化，接入问题就比较可控。

•另一种观点更担心数值一致性、模块兼容，以及测试中没有覆盖到的 Corner Case。

18.更长期的设想是，给出模型结构和计算要求后，就能让 AI 直接生成 GPU 代码，减少对编译器和中间表示的依赖，也就是减少从高层描述到可执行代码的转换环节，甚至进一步为模型专门设计芯片。

19.简单来说，模型蒸馏就是采集教师模型的输出或推理过程，再用这些数据训练学生模型。但 Astra、Fable 5 有个明显趋势是 OpenAI、Anthropic 等开始在防蒸馏上做投入，因此今天市场都在关心，蒸馏到底有没有变难？

20.蒸馏在工程上的首要难点就是要稳定产出足够多的可用数据：

•偶尔采出一两条，与稳定生产一万条，对 Infra 和成本的要求不同，数据还原的正确率是 70% 还是 99%，也会影响最终有多少样本能用于训练。

•采集数据时，还要完整还原 CoT、排除异常内容。有些样本虽然给出了正确答案，CoT 却有问题，因此不能只检查最终答案。清洗这些数据也是蒸馏成本的一部分。

21.同一批教师数据，用来训练不同学生模型，得到的效果也可能不同。学生模型的规模和原有能力，以及团队的训练 Infra、人员和训练配方，都会影响最终的训练效果。

22.蒸馏还面临时效问题：即使最终能拿到教师数据，也不一定赶得上模型迭代。

•一种判断认为，只要教师模型一直提供 API，团队就总能找到办法继续蒸馏。

•另一种观点认为，未来找到蒸馏办法、稳定生产数据所需的周期可能明显变长，对模型研发来说，能否采到数据和能否及时拿到足够的数据，是两个同样重要的问题。

23.最近在中美都很明显的趋势是，专家提供的 human data 正在成为模型训练中越来越重要的数据来源，这些数据的价值就是帮助模型把工作做到用户愿意付费的程度。

•在很多垂直领域中，专业材料怎样组织、判断怎样呈现等大部分 know-how 都是从业者熟悉、却没有完整写在网上的惯例。

•还有些垂直领域的 Benchmark 往往只覆盖真实工作的前几步，没有涵盖后续流程。要训练模型完成整项工作，还需要有人定义任务、补齐 context，并明确什么结果算合格。

24.今天全球的模型厂都已经在招聘不同领域的专业人员来参与专业数据生产。随着训练 Pipeline 标准化，非 ML 背景的人也更容易参与造题和反馈，还可能帮助团队找到产品试用者。模型研发人员也可以进入行业现场，直接了解工作流程。

25.Anthropic 就会让不同专业背景的人使用内部模型，也会安排研发人员进入 JPMorgan 等投行体验工作，从而能更直观地了解工作流程，弄清楚模型究竟能在哪一步提供帮助。

26.拥有行业经验并不意味着就能直接生成数据，再熟悉工作的专家也是需要学习怎样拆任务、准备 context 和设计评估的。在一个业务案例中，熟悉数据生产流程的运营人员一周能做几十道题，而专家可能只能做几道，甚至暂时做不出合格题。

27.专家经验转成训练数据，还会遇到两个问题：专家能否说清判断依据，以及任务结果能否及时验证。

•有的人工作做得很好，却说不清为什么这样判断，因此直接让他们参与具体工作、记录过程，再结合结果检查，才更有机会辨别哪些经验有效。

•投资这类工作往往要等待很久才能看到结果，模型难以及时获得评价和训练信号。有一种判断是，随着 continual learning 更成熟，模型能够积累经验、利用长周期反馈，投资经验可能更容易用于训练。

28.总的来说，要把专业任务数据用于 RL，供应商需要一并提供任务、工作环境和评价方法，让模型反复尝试，并根据结果获得训练信号。一份完整 RL 数据应该至少包含以下四部分：

•Task：写清模型要完成什么任务；

•Context：提供所需的文件、数据或应用环境；

•Metric：规定怎样评价结果、计算分数；

•Reference Answer：提供一个可供模型参考、但不要求逐字匹配的结果。

29.除了数据要完整之外，“好的数据”还需要满足：数据的内容必须是正确的、客户的训练系统必须能用起来。内容有错，或文件超出系统的处理能力，都可能让真实任务无法直接进入训练。

30.模型厂需要结合模型能力、每个任务允许模型尝试的次数，以及训练方式选择数据，在任务难度与学习价值之间取得平衡。

•如果模型在每个任务可尝试的次数较少时，应选择偏简单、让模型更容易获得成功反馈的任务；如果模型可尝试的次数较多时，可适当提高难度。

•不同训练方式对数据的要求也不同：有的模型训练阶段可以使用较大规模的 Off-policy 数据；有的阶段更适合用当前模型自己生成的轨迹训练，并可以围绕较小的数据集反复尝试。

31.完成这些检查后，数据到底能带来多少训练收益，最终仍需要在目标模型上验证。模型厂可以先用小模型做小规模实验，再到大模型上验证。需要注意的是，即使供应商在开源模型上验证了数据有效，客户也不一定能复现，因为基础模型的能力、训练数据分布、算法和 Infra 都可能不同。

32.验证训练收益时，需要区分模型能否学会当前任务，以及学到的能力能否用于别的任务。

•在一些围绕原神、王者荣耀、围棋和斗地主的训练尝试中，任务需要 Reasoning，专家也能写出完整 CoT，但结果是，模型甚至连训练集本身的拟合都会不太稳定，也就是说，专业人员能把推理写清楚，不代表模型就能学会。

•还有一些训练经验显示，Coding 数据能提高模型在差异较大的任务上的表现，以及，让模型学会了完成包含多步有效交互的长任务后，也能提高它在部分短任务或不同类型任务上的表现。

33.虽然 benchmark 提分不一定改善用户体验，但有团队发现，当模型在足够多、覆盖足够广的 benchmark 上提高后，即使没有专门优化体验，用户的实际使用体验也变好了。

•一种解释是，这些 benchmark 包含大量指令遵循要求，比如正确解析 CSV、JSON，相关训练可能同时改善 Coding 和完成下游任务的能力，因此也会反映到使用体验上。

•有些 benchmark 还会迫使团队改进模型基础能力。比如在一个需要连续多步操作的 Long-horizon Task 测试中，有团队曾尝试针对这个测试做定向优化，但没有奏效，最后只能寻找更基础的模型改进方法。

34.最后，评估模型表现，还要看完成模型任务的成本。同一道题，不同模型的 Token 用量可能相差十倍甚至更多。但从训练优先级来看，团队往往会先让模型完成难题，再减少完成任务所需的 Token。

35.数据有训练价值，还不等于供应商能持续获得订单。模型厂首先要决定哪些数据自己做、哪些从外部采购。两者可以互补：内部团队通常更了解模型，外部采购则可以补充内部数据，验证能否带来额外收益。

36.其中，用户与模型交互后留下的记录，也就是模型厂得到的回流数据，是能否替代外部采购，要看任务数据分布和筛选成本，不能只看总量。

•如果用户主要用模型进行娱乐，回流记录里可能缺少金融、法律、医疗等领域的任务。外部定制采购可以补充现有用户还没有覆盖的场景。

•即使用户使用记录中有改进模型需要的任务，模型厂从海量交互中筛出有用的训练信号，有时也比直接定制数据更贵。

37.模型厂常把外购数据作为模型进入新领域的第一批样本，用来了解任务要求，再搭建自己的数据合成 Pipeline。关键专业知识仍需要外部补充时，团队就会继续采购。

•一种判断是，当模型厂把 Coding 能力追到 SOTA 模型的八九成后，可能就会寻找新的高价值任务。Coding、Kernel 专家往往就在厂内，金融、法律、医疗等专业知识却更多需要从外部获得，这也给数据供应商带来机会。

•蒸馏也会影响采购意愿。有明确的教师模型时，团队可以通过蒸馏追赶；当蒸馏收益下降、需要探索新方向时，供应商就更有机会提供新任务和数据。

38.外采还可以帮助模型厂应对需求波动。比如，模型在某个 Benchmark 暴露短板后，团队可能一周就要一万条数据。如果内部数据团队按峰值配人，平时容易闲置；按平均需求配人，又可能应付不了突发任务。而外部供应商可以跨客户调配人员，更灵活地安排产能。

39.自建和外采也有不同的数据质量约束。供应商的数据不达标，客户可以不验收、不付款；内部团队则主要依靠绩效和组织管理。一线观察是，在模型厂内部，模型能力提高后，功劳往往被归到 Researcher 名下，数据团队的贡献不容易单独衡量，数据岗位即使把数据做得更多、更好，也很可能没有即时奖励。

40.因此，对于数据供应商来说，要获得订单，首先需要先了解客户的训练目标。有的模型厂重视 Benchmark，有的更看重体验和商业价值，但客户通常不会一开始就开放完整模型信息。一种做法是先提供成品任务，让客户按类型和难度筛选，积累信任后，再围绕模型表现不好的任务（Bad Case）开发数据。

41.按一线观察，frontier labs 可能会在模型发布前 3-6 个月、部分方向甚至提前约十二个月提出数据需求，供应商需要提前准备，但做出的数据却不一定能卖很久：一旦模型能自行生成这类数据，采购需求就可能减少。

•这意味着，供应商需要提前找到能做任务的人，并用自己的现金流支撑 6-12 个月的预研，类似短剧押爆款，有需求变化的风险。

•但供应商也可以参考模型厂的能力目标和研发计划来安排预研，就算某批数据过期了，积累的专家、任务知识和生产流程，也能用于开发下一批数据。

42.在数据这个市场，供应商规模大，并不代表他们能在每个领域都做得最好，比如在海外，虽然 Surge AI、Mercor 已有很大的规模，但新团队仍可能凭借对某类任务的深入理解和合适的专家获得订单。

•一种设想是，小团队如果专注某类稀缺的专业任务，做出大客户需要的数据，大客户也可能花一千万美元直接买断团队一年的产量。

•模型厂也可能成为数据供应方，但算法人员不一定愿意把研究产出做成生意。

43.数据售价取决于任务难度、任务多样性、实际训练效果，以及是否独家出售。

•国内非独家采购其实比较常见，一批数据平均能复卖约二到三次，通过多次销售分摊成本。

•独家价格约为非独家的数倍，供应商需要管好独家数据，防止已售数据被复制、转卖。

44.未来，随着人们工作方式持续变化，也可能会带来新的数据需求。

•比如原来人们用 Excel 完成的任务，以后可能改用 HTML 或其他工具，SQL 数据库的使用方式也可能改变。假如模型不能自行适应这些变化，那就需要补充新的训练数据。

•供应商也在考虑改变数据来源。一种长期设想是数据供应商自己运营工作平台，让用户在使用 AI 时留下任务和反馈，再把这些记录转成 RL 数据。

45.企业已有的业务流程和工作记录，也可能被整理成 RL Environment，让模型在接近真实公司的环境里执行任务、获得评价。比如公司可以结合保存在钉钉/飞书里的记录和原员工的解释，来还原当时的任务背景、决策和业务问题，为搭建训练环境提供素材。模型通过这些数据训练得到的能力，还可以用于其他企业。

46.所以，数据供应商的业务领域还可能延伸到企业 AI 部署。比如一些企业客户可能需要 Private Model、私有数据和私有部署，因此数据供应商可以帮助这些客户梳理业务、判断哪些任务适合 AI，并完成工程部署。这类服务可以采用 FDE 模式，由工程人员深入客户业务，完成适配。供应商的客户范围也可能从二十来家基模厂，扩大到更多中大型企业。