1. 从一档播客聊起datagenproc 到底在讨论什么Nathan Lambert 和 Epoch AI 坐下来录了一期播客主题是决定前沿 AI 未来的开放问题。这个组合本身就值得琢磨——Nathan Lambert 长期在开源模型和 RLHF 方向做一线工作Epoch AI 则是专注 AI 趋势量化研究的机构一个偏工程实践一个偏宏观测算两边凑到一起聊的必然不是某个模型又刷了多少分这种表层话题而是那些真正卡住整个领域往前走的结构性问题。这期播客里被反复提及的一个关键词是datagenproc也就是 data generation process数据生成过程。这个词听起来很学术但拆开看非常朴素当模型训练越来越依赖合成数据、依赖模型自己生成的数据来喂自己时这批数据是怎么造出来的、造得干不干净、有没有系统性偏差就直接决定了下一代模型的天花板。Epoch AI 一贯的风格是把这类问题量化——比如合成数据占比到多少会开始出现模型崩溃model collapse数据过滤的阈值怎么设才不至于把长尾能力一起砍掉。Nathan Lambert 则更关心工程上怎么落地比如在 post-training 阶段怎么配比真实数据和合成数据。另一个绕不开的词是RSI即 recursive self-improvement递归自我改进。这是前沿 AI 讨论里最敏感也最核心的开放问题之一模型能不能参与到改进下一代模型的过程中从而形成一个加速循环。播客里对这个问题的态度是谨慎的——不是说做不到而是说能做到什么程度和哪些环节其实卡住了需要拆开看。数据生成、评测、训练策略调整每个环节能不能交给模型自己答案是不一样的。还有蒸馏distillation这条线。热词里知识蒸馏模型蒸馏运动蒸馏skill蒸馏扎堆出现说明这个词已经从学术圈下沉到了工程实践甚至内容创作领域。播客语境下的蒸馏更多是指用大模型的能力去指导小模型或者用强模型生成的数据去训练弱模型——这本身就是 datagenproc 的一个具体分支。把这几条线串起来看这期播客其实在讨论一个闭环数据怎么造datagenproc→ 造出来的数据怎么用蒸馏→ 用完之后模型能不能自己接着造RSI。我写这篇东西不是要复述播客内容——那没意义录音就在那儿。我想做的是把这几个概念背后的工程逻辑拆开结合我自己在模型训练和数据管线上的实操经验讲清楚这些开放问题为什么开放卡点具体在哪以及如果你真的在做相关的工作哪些坑是绕不过去的。适合做模型训练、数据工程、AI 应用开发的读者也适合想搞明白前沿 AI 到底在纠结什么的技术管理者。2. datagenproc合成数据管线的真实工程复杂度2.1 为什么数据生成过程突然成了核心议题几年前大家聊训练重点在模型结构、参数量、算力规模。数据虽然重要但更多是有多少 token这种量的讨论。现在风向变了因为高质量真实数据的存量正在见底。公开互联网上能爬的、质量过关的文本基本被主流模型扫过一遍了。再往上堆边际收益急剧下降。于是合成数据从补充手段变成了主力手段。但这里有个反直觉的点合成数据不是免费的。它的成本不在生成而在筛选和验证。你让一个大模型生成一百万条指令数据可能只有几万条是真正可用的剩下的要么太简单、要么有事实错误、要么风格单一。datagenproc 这个词之所以重要就是因为它把生成这件事从一次性动作变成了一个需要设计的过程——输入什么种子、用什么 prompt 模板、怎么去重、怎么过滤、怎么保证多样性每一步都影响最终数据集的分布。Epoch AI 在这方面的研究思路很值得借鉴他们倾向于把数据生成过程建模成一个可测量的 pipeline每个环节都有明确的输入输出和质量指标。这比我们用了合成数据这种模糊表述要靠谱得多。2.2 一条可落地的合成数据管线长什么样我把自己实际跑过的一条指令数据合成管线拆开讲你可以对照自己的场景调整。整条链路大致是种子收集 → 种子扩增 → 批量生成 → 质量过滤 → 多样性去重 → 人工抽检 → 配比混合。种子收集阶段关键是种子的信息密度。我一般从三个来源拿种子真实业务日志里脱敏后的 query、公开高质量数据集里的样本、以及人工手写的少量锚点样本。锚点样本不用多几十条就够但必须覆盖你希望模型学会的所有任务类型。这一步的意图是给后续扩增定一个风格基准——如果种子本身质量参差后面生成再多也是垃圾进垃圾出。种子扩增是很多人忽略的一步。直接拿种子去批量生成会导致生成结果高度同质化。我的做法是先让模型对每个种子做任务改写——同一个意图换三种不同的表述方式、换不同的约束条件、换不同的输出格式要求。这样一条种子能裂变成多条且天然带来多样性。这里有个参数要调改写温度temperature建议设在 0.7 到 0.9 之间太低改不动太高会跑偏原意。批量生成阶段prompt 模板的设计是核心。我踩过的坑是一开始用很详细的 system prompt 去约束模型结果生成的数据风格极其统一模型学完之后只会一种腔调。后来改成约束输出格式放开表达风格多样性明显改善。具体来说格式约束比如必须输出 JSON、必须有 reasoning 字段要严格但语言风格、举例方式、详略程度要留出空间。质量过滤是最耗工程的一步。纯靠规则过滤比如长度、关键词黑名单会漏掉大量语义层面的问题。我的组合方案是规则过滤先砍掉明显不合格的太短、重复、含敏感词然后用一个小的 reward model 或者一个强模型做打分按分数分档。这里要注意不要用同一个模型既生成又打分否则它会系统性高估自己的输出。用一个不同来源的模型做裁判哪怕弱一点也比自评自判强。多样性去重不能只做字面去重。语义去重更关键——用 embedding 做聚类每个簇里只保留少量代表样本。我一般把相似度阈值设在 0.85 到 0.9 之间具体看任务。阈值太低会误删有用的变体太高则去重不彻底。人工抽检这一步不能省。哪怕只抽 200 条也能发现系统性问题。我习惯按分数分档各抽一部分重点看高分档里有没有看起来漂亮但事实错误的样本——这类样本对模型伤害最大因为它教模型自信地胡说。配比混合是最后一步也是 datagenproc 里最需要经验的地方。合成数据和真实数据的比例没有万能公式我的经验是任务越接近真实分布真实数据占比越高任务越需要特定格式或推理链合成数据占比可以高一些。一般从 1:1 起步根据验证集表现调整。2.3 合成数据占比过高会怎样模型崩溃的工程表现模型崩溃model collapse这个词在播客里被提到但很多人只知道概念不知道它在工程上长什么样。我实际遇到过几次表现很有特征输出多样性塌缩模型对同一类问题的回答越来越像翻来覆去就那几个句式。长尾能力丢失训练集里少见的任务类型模型直接不会了或者用主流任务的模式硬套。错误累积放大合成数据里的小偏差经过几轮迭代后被放大成系统性错误。困惑度异常在验证集上 loss 看着还行但在分布外数据上表现断崖式下跌。Epoch AI 的研究倾向于给出一个临界比例但我的实操感受是临界点不是固定的它取决于你的过滤强度和多样性维护做得好不好。过滤做得狠、多样性维护得好合成数据占比可以推到 70% 以上还不崩反之30% 就开始出问题。所以与其记一个数字不如把精力放在管线的质量控制上。3. 蒸馏从知识蒸馏到skill蒸馏的工程分野3.1 蒸馏的三种形态别混为一谈热词里知识蒸馏模型蒸馏运动蒸馏skill蒸馏混在一起其实它们说的不是一回事。我在工程里把蒸馏分成三类每类的做法和适用场景差别很大。第一类是 logits 蒸馏也就是经典的知识蒸馏。学生模型去拟合教师模型的输出概率分布而不只是硬标签。这种做法需要能拿到教师模型的 logits通常要求你有教师模型的访问权限。优点是信息量大——软标签里包含了哪些错误选项比较接近正确答案这种暗知识。缺点是工程上麻烦要处理 logits 对齐、温度参数调节而且教师模型和学生模型容量差距太大时效果会打折。第二类是数据蒸馏也就是用教师模型生成的数据去训练学生模型。这是目前最主流、最容易落地的做法本质上就是 datagenproc 的一个应用。你不需要访问教师模型的内部只需要它的输出。缺点是信息损失大——你只拿到了采样结果没拿到分布信息。但对于大多数应用场景这已经够用了。第三类是 skill 蒸馏这个词最近很火指的是把某种特定能力比如代码生成、数学推理、工具调用从强模型迁移到弱模型或专用模型上。它和普通数据蒸馏的区别在于针对性不是泛泛地学而是聚焦某个技能维度用专门构造的数据去训练。运动蒸馏、skill蒸馏这些说法本质都是这个思路在不同领域的叫法。3.2 数据蒸馏的实操怎么构造教得会的数据数据蒸馏听起来简单——拿强模型的输出训练弱模型嘛。但实际做下来直接拿原始输出训练效果往往一般。问题出在数据的教学性上。强模型的输出是给用户看的不是给模型学的。它可能省略推理步骤、可能用很高级的表达、可能默认读者有背景知识。这些对训练学生模型都不友好。我的做法是对教师输出做二次加工补全推理链让教师模型在输出答案前显式写出推理过程。这一步可以用 prompt 引导比如要求先分析再作答。控制难度梯度把同一类任务按难度分层学生模型从易到难学。直接上难题学生学不会还容易过拟合。增加负例对比不只给正确答案也给接近但错误的答案并说明为什么错。这对提升学生模型的判别能力很关键。统一输出格式学生模型的输出格式必须严格统一否则训练时 loss 会震荡。这里有个参数值得说教师模型的选择不一定要选最强的。我试过用超大模型蒸馏小模型效果反而不如用一个中等规模但风格更平实的模型。原因是超大模型的输出太聪明学生模型够不着学了个四不像。选教师模型的标准应该是比学生强一档但风格可模仿。3.3 蒸馏的常见误区与验证方法我见过最多的误区是只看最终指标不看中间过程。蒸馏完之后跑个 benchmark分数涨了就以为成了。但实际部署时问题一堆模型在边缘 case 上崩、输出格式偶尔跑偏、对某些输入异常敏感。我的验证方法是分三层验证层级验证内容通过标准格式层输出是否符合预期结构99% 以上样本格式正确能力层目标任务指标是否达标达到或接近教师模型的 90%鲁棒层边缘 case、对抗输入表现无明显崩溃错误可解释格式层用自动化脚本跑能力层用标准评测集鲁棒层需要人工构造测试用例。三层都过了才算蒸馏成功。只过前两层就上线迟早出问题。另一个误区是忽视学生模型的容量上限。蒸馏不是万能的学生模型容量不够再好的数据也学不进去。我一般会先做一个小实验用少量数据训练看学生模型能不能拟合。如果连小数据集都过拟合不了说明容量不够得换模型或者加参数。4. RSI递归自我改进到底卡在哪4.1 RSI 的诱惑与现实的差距RSIrecursive self-improvement是前沿 AI 讨论里最有想象力也最容易被过度解读的概念。它的核心设想是模型能参与到改进下一代模型的过程中从而形成一个正反馈循环能力提升越来越快。播客里对这个问题的讨论很克制我认为这是对的。因为把 RSI 拆解到工程层面你会发现每个环节的可自动化程度差别巨大。数据生成环节模型已经能深度参与了——这就是 datagenproc 和蒸馏在做的事。评测环节模型也能部分参与比如用模型做裁判LLM-as-judge。但训练策略调整、架构设计、超参搜索这些环节目前还是高度依赖人的判断。模型可以给建议但拍板的是人。所以现实中的 RSI 更像是一个半自动循环模型负责生成和筛选数据人负责设定目标和验证方向。完全无人干预的 RSI目前还停留在设想阶段。4.2 哪些环节已经可以交给模型哪些还不行我把 RSI 涉及的环节按可自动化程度排了个序这个排序基于我自己的实践观察不一定适用于所有场景但大方向应该差不多。高度可自动化数据生成、数据过滤、初步评测、格式检查、去重。这些环节规则明确、反馈及时模型做得比人快也比人稳。部分可自动化评测标准设计、难度分层、数据配比调整。模型能给出建议但需要人审核。比如让模型提议一个数据配比方案然后人根据验证集结果决定采不采纳。低度可自动化训练目标设定、架构选择、失败原因诊断。这些需要全局判断和领域知识模型目前还替代不了。尤其是失败诊断——模型能告诉你loss 不降了但为什么降不了往往需要人去翻数据、查梯度、做消融实验。几乎不可自动化决定要不要继续这个方向。这是战略判断涉及资源分配、风险评估、价值取舍不是技术问题。这个排序的实践意义是如果你想搭一个半自动的训练循环从高度可自动化的环节入手逐步往上游推。一上来就想全自动大概率会卡在诊断环节然后整个循环停摆。4.3 搭一个半自动循环的最小可行方案如果你想实际动手试试 RSI 的思路我建议从一个最小闭环开始。不要贪大先把一个环节跑通。我的最小方案是这样的选一个明确的任务比如某类代码生成准备一批种子数据让模型生成扩增数据用一个固定的评测脚本打分根据分数自动筛选然后用筛选后的数据微调一个小模型再评测。整个循环里人只在两个点介入设定评测标准、审核最终结果。这个循环跑一轮大概需要几个小时到一天取决于数据量和模型大小。跑通之后你可以逐步把审核最终结果也部分自动化——比如设定一个阈值分数超过阈值就自动进入下一轮低于阈值才需要人看。这里的关键经验是循环的稳定性比单轮效果更重要。我一开始追求单轮提升最大化结果循环跑几轮就崩了——因为某一轮的数据偏差被放大后面全歪了。后来改成每轮只求小幅稳定提升加严格的分布监控循环反而能持续跑下去。分布监控具体就是每轮结束后对比新数据和原始数据的分布差异差异超过阈值就报警。5. 这几个开放问题之间的隐藏联系5.1 datagenproc、蒸馏、RSI 其实是一个闭环单独看这三个概念容易觉得它们是三个独立的研究方向。但放到一起看它们构成一个闭环datagenproc 决定了数据从哪来蒸馏决定了能力怎么迁移RSI 决定了这个循环能不能自己转起来。这个闭环里任何一个环节出问题整个循环都会退化。datagenproc 做得不好数据质量差蒸馏出来的学生模型就弱蒸馏做得不好能力迁移效率低RSI 循环的每一轮收益就小RSI 循环设计得不好偏差累积几轮之后模型就崩了。所以播客里把这些放在一起讨论是有道理的——它们不是三个问题是一个问题的三个面。5.2 为什么开放问题短期内不会有标准答案这些问题之所以开放不是因为没人研究而是因为答案高度依赖具体场景。合成数据占比多少合适取决于你的任务、你的过滤能力、你的验证手段。蒸馏用哪种方式取决于你能不能拿到教师 logits、你的算力预算、你的部署约束。RSI 能推到什么程度取决于你的容错空间和监控能力。Epoch AI 的研究价值在于给出趋势和边界Nathan Lambert 的实践价值在于给出可操作的方案。但具体到你的项目还是得自己试。我自己的经验是任何关于数据配比、蒸馏策略、循环设计的建议都只能作为起点不能作为终点。跑起来看结果调参数这才是正路。5.3 给实际做项目的人几条硬建议最后分享几条我在实际项目里总结的硬建议都是踩过坑换来的。第一数据管线的可观测性比管线本身更重要。我早期搭管线只关心产出多少条数据不关心数据分布怎么变。结果模型训练出问题回头查数据发现某一批数据的分布和之前完全不同但没有任何记录。后来我强制要求每个环节都输出统计报告——长度分布、任务类型分布、去重率、过滤率全部留档。出问题时能快速定位是哪一批数据的问题。第二蒸馏不要一步到位。想用最强模型直接蒸馏出一个小模型往往效果不如强模型→中等模型→小模型的渐进式蒸馏。中间那一步的作用是翻译——把强模型的表达翻译成小模型能理解的形式。第三RSI 循环一定要有刹车。我见过有人搭了个自动循环跑了一晚上第二天发现模型完全崩了因为中间某一轮的数据出了系统性问题循环自己没法发现。我的做法是每轮结束后强制人工看一眼关键指标或者设一个自动熔断——指标异常就停。第四别迷信任何单一指标。benchmark 分数、loss、困惑度都只是参考。真正靠谱的验证是拿模型去跑真实任务看它在实际场景里的表现。我习惯在每轮训练后用一批固定的真实 case 做回归测试这批 case 不参与训练只用于验证。回归测试过了才认为这一轮是成功的。第五记录每一次实验的完整配置。数据配比、蒸馏方式、超参、随机种子全部记下来。不是为了写论文是为了复现。我吃过亏——某次实验效果特别好但配置没记全想复现的时候怎么都调不回去。从那以后我强制要求所有实验都有配置文件且配置文件进版本控制。这几个问题短期内不会有定论但工程上的最佳实践会慢慢沉淀下来。与其等标准答案不如自己动手跑起来在过程中积累自己的判断。毕竟前沿 AI 的前沿两个字本身就意味着没有现成的路可走。