蒸馏、合成数据和 RSI，是怎么连到一起的？
整理这期节目时，我原本以为重点会是蒸馏。顺着对谈往下看，问题慢慢变成了：训练越来越方便以后，模型研究员到底还在研究什么？
42章经对谈 Evolvent AI 联合创始人孟繁青，发布于 2026 年 8 月 8 日。下面是我基于节目内容和公开资料做的整理，不是逐字稿。
模型怎么变强，越来越取决于一套实验循环：找到它不会的东西，想办法造出合适的数据，训一版，再看它到底学会了没有。
整理这期时，我最想弄清的是那个有点敏感的问题：国内模型到底有多依赖蒸馏？这段对谈没有在「蒸还是不蒸」上纠缠太久。孟繁青把问题往前推了一步。模型厂的训练平台已经很成熟，提交数据、发起训练、拿回 checkpoint，逐渐像调用内部服务。既然如此，研究员每天最花心思的工作是什么？他的答案很朴素：做数据。
这篇沿着“下一轮训练数据从哪里来”展开。蒸馏可以提供教师模型的回答或轨迹，合成数据还涉及出题、筛选和反馈，RSI 则进一步尝试自动安排改进与验证。三者有交集，不能当成模型团队必然依次经历的三个阶段。
我为什么把这三个词画在一条线上
蒸馏
先找一个更强的老师，借它的回答和轨迹教目标模型。
合成数据
开始自己出题，还要管难度、轨迹、反馈和答案是否可信。
RSI
再把出题、训练、考试和复盘交给系统自己安排。
这张图用于说明本文的讨论关系：蒸馏可以产生合成数据，RSI 可以使用这些数据，但它们没有固定的先后顺序。
蒸馏最直接。一个更强的模型已经会做某件事，就让目标模型学习它给出的答案、推理轨迹或工具操作过程。这当然也会产生合成数据，但合成数据的范围更大。团队还得决定出什么题、出多难、哪些轨迹该扔掉，以及一批数据训完会不会让模型在别的任务上变笨。
在这里讨论的数据中心场景中，RSI 还要分析上一轮失败、提出数据策略、训练候选模型，再根据评估决定下一步。能生成样本只完成了其中一环，策略选择和版本保留仍可能失败。
后训练的人，怎么每天都在做数据
孟繁青在节目里描述了模型厂内部的一种工作方式：SFT、推理和评估都有现成平台。研究员提交请求，远端服务完成训练，最后把结果交回来。找 GPU、配环境、拉训练仓库这些事情，已经由基础设施团队消化掉了。
按他的描述，基础设施团队承担了训练执行的许多工作，研究员仍要决定模型缺少什么、该用哪批数据，以及怎样检查迁移效果。一批样本看起来合理，训练后也可能没有收益；这部分判断仍需要实验。
给一道题，核对一个答案
数学题和早期代码题比较适合这样测。模型像坐在考场里，答完以后看对错。
给一套工具，看事情有没有办成
Agent 要操作 Notion、终端或代码仓库。评估器得检查中间状态，还要防着模型钻规则的空子。
做 Agent Benchmark 往往需要软件环境、可恢复状态和验证器，这些组件也能用于实际产品。不过，测试环境可以控制的条件比真实业务更多，不能因为搭好了 Benchmark 就认定产品已经可用。
训练平台把重复执行工作封装以后，数据选择和实验设计的比重会更显眼。这个变化来自受访者描述的工作环境，不能覆盖每家团队的分工。
国内模型的优势，可能不在我们以为的地方
这一段和我原先想的刚好相反。通常的说法是，国内团队工程能力强，所以更擅长 Post-training；预训练则吃算法人才和算力，海外优势更大。孟繁青的观察刚好倒过来。他觉得国内模型最有特色的地方，恰恰是算力紧张逼出来的预训练架构创新。后训练这边，海外公司开始得早，数据和经验多积累了几个月，时间差反而更难抹平。
这是受访者的行业观察，公开信息还不足以把它证明成一条普遍规律。不过它让我意识到，大家说「追赶模型」时，经常把几件速度完全不同的事混在一起。我按自己的理解拆了个表：
| 竞争层 | 核心问题 | 追赶方式 | 难复制之处 |
|---|---|---|---|
| 算力 | 能跑多大规模、多少实验 | 资本投入与资源调度 | 供给、集群稳定性、长期预算 |
| 架构 | 每单位算力能换来多少能力 | 论文、开源与人才流动 | 规模化验证和工程细节 |
| 数据 | 模型应该学习什么 | 蒸馏、合成、采集与标注 | 失败经验、课程设计、质量判断 |
| 组织 | 能否把新认知快速变成新版本 | 流程调整与团队协作 | 决策速度、反馈链路、隐性知识 |
那蒸馏到底算什么
孟繁青把它叫作加速手段，我基本同意。强模型已经会的东西，可以很快变成后训练材料，数据冷启动会省事很多。但一个团队仍然得有自己的基础模型，知道该测什么，也要有办法判断迁移过来的能力是真是假。
我更想继续查的是，团队能否用自己的模型、环境和反馈持续生成并验证数据。教师模型可以帮助启动训练，但仅凭使用了蒸馏，判断不了团队是否具备独立迭代能力。
RSIBench-Data 测到的改进与回退
RSI 这个词很容易把人带到「模型无限自我进化」的想象里。把它落到这期节目讨论的数据场景，其实就是下面这几步：
循环能执行，不代表每一轮都有收益。研究 Agent 可能误判失败原因，生成与任务不匹配的数据；也可能曾经得到更好的候选版本，却在最后提交了较差的结果。下面的实验把这两类问题分开观察。
Evolvent AI 公开的 RSIBench-Data 论文专门测这件事。实验固定基础模型、训练服务、评估环境和预算，只让研究 Agent 改数据策略。这样才能看清：进步到底来自 Agent 的研究判断，还是碰巧换了训练配置和评估条件。
这两个比例分别涉及找到改进和保留改进。它们提示，评估研究 Agent 时，除了看运行中出现过的最好分数，还要看最终提交的版本和选择过程。
我最后留下的判断
训练服务化可以减少环境准备和执行成本，数据策略仍需要通过训练与评估检验。本期讨论对我有用的部分，是把“做数据”展开成出题、生成轨迹、筛选、训练和复测，而不只理解为清洗文本。
Agent Benchmark 也要记录中间状态和副作用。模拟环境越接近任务，能检查的问题越多，但真实组织中的权限、沟通和临时变化仍要另测。
蒸馏的价值需要放进这套流程中评估：教师提供了什么，目标模型学到了多少，哪些能力没有迁移，以及后续是否还依赖同一教师。公开信息目前不足以计算各家模型的蒸馏贡献比例。
RSI 在这组实验中已经能找到部分有效的数据改进，稳定选择和保留结果仍有问题。比较方法时，应把最终提交效果、过程最好结果和实验预算一起报告。
有几处我还没完全被说服
「预训练学知识，后训练搬分布」说得太整齐了
这个说法适合解释大方向，拿来划能力来源就有点勉强。持续预训练、中期训练、长上下文扩展和大规模 RL 已经搅在一起，基础能力很难只记到某一个阶段头上。
在模拟环境里做对，进公司后未必也能做对
环境越复杂，验证器越容易漏掉没有写进规则的要求。Agent 能操作一个模拟 Notion，当然比答选择题更接近工作，但真实组织还有权限、沟通和各种临时变化。Benchmark 永远只测出了被写下来的那一部分。
没人能算清蒸馏到底贡献了多少
各家的训练数据、教师调用和内部评估都不透明。「蒸馏只是加速器」是孟繁青的判断，我觉得有道理，却没法从公开资料算出一个占比。现阶段最多能说，它很重要，但它代替不了预训练、架构和自己的数据积累。
节目时间轴
如果只想听重点，可以沿着下面四段进入原节目：
- 后训练与模型竞争。从模型厂到创业公司，Post-training、Benchmark 与数据工作的变化。
- RSI。Self-Evolving、AI for AI 与 Auto-Research 的关系，以及闭环为何很难转起来。
- 数据。模型对数据需求的几轮变化，外采价值，以及合成数据与蒸馏的区别。
- 展望。AI4S、模型公司的组织形态、蒸馏对国内追赶的意义与 Evolvent AI 的方向。