RSI、中美模型差距与知识蒸馏：大模型能力增长的动力与工程实践

1. 从一场对谈说起RSI、模型差距与蒸馏到底在聊什么Nathan Lambert 和 Epoch AI 的 JS Denain 坐下来聊 RSI、中美模型差距和蒸馏影响这个组合本身就很有意思。Nathan 是 Allen AI 出身、长期做开源模型和后训练研究的从业者Epoch AI 则是专门做 AI 趋势量化分析的机构两边视角一个偏工程实践、一个偏数据趋势碰在一起基本不会停留在“模型又变强了”这种层面。我第一时间关注这场对谈是因为它把三个平时被分开讨论的话题串成了一条线RSIRecursive Self-Improvement递归自我改进、中美模型差距、蒸馏Distillation。这三个词单独拎出来都能写一篇长文但放在一起其实是在问同一个问题——模型能力增长的动力到底来自哪里以及这种增长在不同地区、不同团队之间是怎么传导的。先把 RSI 说清楚。很多人一听“递归自我改进”就联想到科幻里的失控 AI实际在当下的工程语境里它指的是模型参与改进自身或改进下一代模型的过程。具体形式包括用模型生成训练数据、用模型做数据筛选和标注、用模型辅助写训练代码、用模型评估模型输出并反馈到后训练流程。Nathan 在多个场合都强调过一个观点现在所谓的 RSI 更多是“人在环路里的加速”而不是完全自主的闭环。模型能帮你把实验迭代速度提上去但方向判断、目标设定、失败归因这些还是人在做。这个区分很重要因为它直接决定了你对“模型能力会不会突然暴涨”这件事的判断。再说中美模型差距。这个话题容易被情绪带偏但从 Epoch AI 的数据视角看它其实是一个可以量化的问题顶尖模型的 benchmark 分数差距、训练算力差距、数据质量差距、开源生态活跃度差距这几个维度拆开看结论并不一致。有些维度差距在缩小有些维度差距在拉大还有些维度根本没法直接比较。JS Denain 在 Epoch 的工作里经常处理这类问题他们的方法论是把“能力”拆成可测量的代理指标然后看趋势线而不是看单点。蒸馏则是把前两个话题连起来的关键机制。知识蒸馏最早是 Hinton 那批人提出的模型压缩方法让一个小模型去模仿一个大模型的输出分布。但到了大模型时代蒸馏的含义被大大扩展了它可以是 API 输出蒸馏用强模型的输出训练弱模型、可以是运动蒸馏和skill 蒸馏这类针对特定能力的定向迁移、也可以是大模型蒸馏到端侧小模型的部署优化。蒸馏之所以和“差距”话题强相关是因为它提供了一条绕过算力壁垒的路径——你不需要从头训练一个顶级模型你可以用它的输出来训练自己的模型。这条路径的合法性和可持续性是这场对谈里绕不开的争议点。我写这篇东西是想把这场对谈涉及的几个核心概念拆开讲透同时补上从业者视角的实操细节。适合谁看如果你在做大模型后训练、数据工程、模型评估或者你只是想知道“蒸馏到底是不是抄”“中美差距到底怎么看”这类问题这篇应该能给你一些可参考的判断框架。下面我会按“整体思路拆解—核心概念解析—实操要点—常见问题”的顺序展开尽量把每个点讲到能落地。2. 整体思路拆解为什么这三个话题必须放在一起看2.1 RSI 的真实边界加速器而非自动驾驶理解 RSI 的第一步是把它从科幻叙事里拉出来。在当前的工程实践中RSI 的形态非常具体一个模型团队用模型来生成合成数据、用模型来做 reward modeling、用模型来写和调试训练脚本、用模型来做 ablation 实验的初步筛选。这些环节每一个都能节省人力但每一个也都需要人来做最终判断。Nathan Lambert 在开源模型社区的一个核心观察是后训练post-training环节的 RSI 程度远高于预训练环节。原因很直接——后训练的数据量小、迭代快、反馈信号明确模型能帮上忙的地方多。而预训练涉及的数据清洗、去重、配比、课程学习很多决策依赖的是对数据分布的直觉和长期经验模型目前还替代不了。这个区分对从业者很有用如果你想在团队里引入 RSI 相关的工具链从后训练和数据筛选切入ROI 会比从预训练切入高得多。还有一个容易被忽略的点RSI 的瓶颈往往不在模型能力而在评估能力。模型能生成大量候选方案但如果你没有可靠的评估手段生成再多也没法筛选。这也是为什么 Epoch AI 这类做评估和趋势分析的机构在 RSI 讨论里位置很重要——评估是 RSI 闭环里的关键卡点。2.2 中美模型差距的多维拆解别用一个数字概括“中美模型差距”这个说法最大的问题是它暗示了一个单一维度的差距。实际拆开看至少有这么几个维度维度观察方式差距趋势从业者普遍观察顶尖闭源模型能力综合 benchmark、人类偏好评估头部差距较小但迭代节奏有差异开源模型生态模型数量、下载量、微调社区活跃度开源侧差距相对更小训练算力集群规模、互联带宽、可用卡时算力侧差距是结构性因素数据质量与规模高质量语料、多语言覆盖、领域数据中文数据侧有独特优势工程与部署推理优化、端侧部署、成本控制部署侧差距在快速缩小JS Denain 在 Epoch 的分析里反复强调方法论看趋势线不看单点看多个指标不看单一 benchmark。这个原则对从业者同样适用。你在做技术选型时如果只盯着某个榜单的排名很容易做出误判。更靠谱的做法是看你自己场景下的实际表现——你的任务分布、你的延迟要求、你的成本预算这些才是决定性的。2.3 蒸馏为什么是连接点能力迁移的工程路径蒸馏之所以把 RSI 和差距话题连起来是因为它同时是 RSI 的工具和缩小差距的手段。作为 RSI 工具蒸馏让模型能把自己的能力“压缩”到更小的模型里加速迭代作为缩小差距的手段蒸馏让算力有限的团队能借助强模型的输出训练自己的模型。但蒸馏有一个核心争议用别人的模型输出训练自己的模型这算不算真正的能力建设这个问题没有简单答案。从工程角度看蒸馏确实能快速提升小模型在特定任务上的表现这是实打实的。但从长期能力积累看如果团队只做蒸馏不做底层训练对模型行为的理解深度是有限的。Nathan 在开源社区的立场偏向于蒸馏是合法且有用的工具但团队应该清楚自己在做什么不要把蒸馏出来的能力误认为是自己训练出来的能力。3. 核心概念解析RSI、差距、蒸馏的技术细节3.1 RSI 的工程实现从数据生成到评估闭环RSI 在工程上不是一个单一技术而是一组技术的组合。我把它拆成四个环节来讲每个环节都有具体的工具和方法。第一个环节是合成数据生成。这是目前 RSI 最成熟的应用。做法是用一个强模型teacher生成大量候选输出然后用某种筛选机制规则、reward model、人工抽检过滤出高质量样本用于训练目标模型student。这里的关键参数是生成温度和筛选阈值。温度太高输出多样性好但质量参差温度太低输出质量稳定但多样性不足。我的经验是对于数学和代码类任务温度设在 0.6-0.8 之间比较平衡对于创意写作类任务可以到 0.9-1.0。第二个环节是 reward modeling 的自动化。传统 RLHF 需要大量人工偏好标注成本高、周期长。RSI 的思路是用模型来辅助偏好判断先用少量人工标注训练一个 reward model然后用这个 reward model 去筛选模型输出再把筛选结果反馈到训练里。这个闭环能显著降低人工标注量但要注意 reward model 的分布偏移问题——如果 reward model 训练数据覆盖不够它会对某些类型的输出给出错误的高分。第三个环节是训练代码和实验的辅助。这个环节的 RSI 程度取决于任务复杂度。让模型写一个标准的训练循环、调一个学习率 schedule、加一个 gradient checkpointing这些都没问题。但让模型判断“这个 loss 曲线是不是过拟合了”“这个数据配比是不是有问题”目前还不可靠。我的做法是把模型当“高级 autocomplete”用它给建议我做决策。第四个环节是评估闭环。这是最容易被低估的环节。RSI 的效率取决于评估的速度和可靠性。如果你的评估需要跑一整天那 RSI 的迭代速度就被卡死了。实践中我会把评估分层快速评估用少量样本和自动化指标慢速评估用完整测试集和人工抽检。快速评估用于日常迭代慢速评估用于里程碑决策。注意RSI 闭环里最容易出问题的地方是“评估污染”。如果你用模型生成的评估数据来评估模型自己很容易得到虚高的分数。一定要保留一部分从未参与训练和筛选的 holdout 数据。3.2 模型差距的量化方法Epoch AI 的思路与局限Epoch AI 在模型趋势分析上的方法论值得单独讲因为它提供了一套可复用的量化框架。他们的核心做法是建立能力代理指标把“模型能力”拆成可测量的维度比如推理、代码、数学、多语言理解等。追踪训练算力用训练 FLOPs 作为模型规模的代理追踪顶尖模型的算力投入趋势。标准化评估尽量用统一的评估协议减少不同团队自报数据的偏差。趋势外推基于历史趋势做短期预测而不是做长期断言。这套方法的优势是透明、可复现。局限也很明显benchmark 本身有饱和问题当顶尖模型都接近满分时区分度就下降了训练算力的数据来源依赖团队披露不披露的就没法追踪能力代理指标和真实应用表现之间有 gap。对从业者的启示是不要迷信任何单一排名建立自己的评估集。你的业务场景是独特的公开 benchmark 只能作为参考。我通常会维护一个 200-500 条的内部评估集覆盖我的核心任务类型每次模型更新都跑一遍。这个评估集的维护成本不高但决策价值很大。3.3 蒸馏的技术谱系从 logit 蒸馏到 skill 蒸馏蒸馏这个词现在被用得很泛有必要把技术谱系理清楚。按蒸馏信号的类型分主要有这么几类Logit 蒸馏是最经典的形式student 模型学习 teacher 模型的完整输出分布soft labels而不是硬标签。优势是信息量大劣势是需要访问 teacher 的 logits很多 API 不提供。Sequence-level 蒸馏是只学 teacher 的最终输出序列用标准的交叉熵训练。这是目前 API 蒸馏的主流形式因为只需要输出文本。劣势是丢失了 teacher 的不确定性信息。Feature 蒸馏是让 student 的中间层表示逼近 teacher 的中间层表示。需要模型结构可访问主要用于白盒场景。Skill 蒸馏是近年比较热的说法指针对特定能力比如代码、数学推理做定向蒸馏。做法是构造特定任务的数据集用 teacher 生成高质量解答然后训练 student。运动蒸馏这个词在部分社区里被用来指代类似的概念强调“把某种能力动作迁移过来”。大模型蒸馏到端侧是部署场景的常见需求。这里的关键约束是显存和延迟。低显存运行模型时量化INT8、INT4和蒸馏经常配合使用先蒸馏出一个结构更小的模型再做量化。蒸馏类型需要的访问权限适用场景主要风险Logit 蒸馏白盒logits同架构压缩需要 teacher 配合Sequence 蒸馏黑盒仅输出API 蒸馏、跨架构信息损失Feature 蒸馏白盒中间层同架构、同 tokenizer结构约束强Skill 蒸馏黑盒定向能力迁移泛化性下降端侧蒸馏白盒/黑盒均可部署优化能力上限受限4. 实操要点把概念变成可执行的方案4.1 搭建一个最小可用的 RSI 数据闭环如果你想在团队里试水 RSI我建议从一个最小闭环开始不要一上来就搞大而全。具体步骤第一步选定一个窄任务。比如“把用户问题分类到 20 个意图标签”。任务越窄评估越容易闭环越容易跑通。第二步准备种子数据。人工标注 100-200 条高质量样本作为初始训练集和评估集。评估集要单独留出不参与训练。第三步训练初始模型。可以用开源基座模型做微调也可以用 API 模型做 few-shot。这一步的目标是有一个 baseline。第四步引入 teacher 生成候选。用更强的模型可以是 API 模型对未标注数据生成预测然后用规则或 reward model 筛选。第五步迭代。把筛选后的数据加入训练集重新训练在评估集上看提升。如果提升停滞检查是数据质量问题还是任务本身到了上限。这个闭环跑通一次你就能体会到 RSI 的实际节奏和瓶颈在哪里。我的经验是瓶颈通常出现在第三步到第四步之间——teacher 的生成质量和筛选机制的可靠性决定了整个闭环的效率。4.2 蒸馏实操数据构造、训练配置与评估蒸馏的实操细节很多我挑几个最关键的讲。数据构造方面teacher 输出的质量直接决定 student 的上限。我的做法是先用 teacher 在目标任务的验证集上跑一遍确认 teacher 在该任务上的表现确实显著优于 student baseline再开始大规模生成。如果 teacher 本身在这个任务上就不行蒸馏是白费功夫。生成时的 prompt 设计也很关键。对于推理类任务我会要求 teacher 输出完整的推理过程chain-of-thought而不只是最终答案。这样 student 学到的不只是答案还有推理模式。对于分类任务我会要求 teacher 输出置信度和简短理由方便后续筛选。训练配置方面蒸馏训练和普通微调的区别主要在损失函数。如果是 sequence-level 蒸馏损失函数和普通 SFT 一样只是数据来源不同。如果是 logit 蒸馏需要加一个 KL 散度项import torch import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, labels, temperature2.0, alpha0.7): # 硬标签损失 hard_loss F.cross_entropy(student_logits, labels) # 软标签损失KL 散度 soft_student F.log_softmax(student_logits / temperature, dim-1) soft_teacher F.softmax(teacher_logits / temperature, dim-1) soft_loss F.kl_div(soft_student, soft_teacher, reductionbatchmean) * (temperature ** 2) return alpha * soft_loss (1 - alpha) * hard_loss温度参数temperature控制软标签的平滑程度一般设在 2-5 之间。alpha控制软硬损失的权重数据量少时软损失权重要高一些。评估方面蒸馏模型最容易出现的问题是“在蒸馏任务上表现好在泛化任务上表现差”。所以评估集一定要包含两类一类是和蒸馏数据同分布的任务一类是相关但不同分布的任务。如果第二类任务上表现下降明显说明蒸馏导致了过拟合或能力窄化。提示蒸馏数据里如果包含大量格式化的输出比如固定的 JSON 结构student 可能会过度拟合格式而忽略内容。可以在训练数据里混入一定比例的多样化格式样本。4.3 模型差距的自我评估建立内部 benchmark与其纠结“中美差距到底多大”不如建立自己的评估体系。我的做法分三层第一层是通用能力评估。用公开 benchmark 的简化版比如 MMLU 的子集、HumanEval 的子集。这一层用于横向对比不同模型的基础能力。第二层是领域能力评估。针对你的业务领域构造 100-300 条评估样本。这一层是决策的主要依据。第三层是端到端评估。如果你的产品有完整的用户流程直接在这个流程上做 A/B 测试。这一层最接近真实价值但成本也最高。三层评估的频率不同第一层每次模型更新都跑第二层每周跑一次第三层在重大版本更新时跑。这个节奏能平衡评估成本和决策质量。4.4 低显存与端侧部署的蒸馏配合如果你要把模型部署到端侧或低显存环境蒸馏和量化的配合很关键。我的经验顺序是先蒸馏再量化。原因是量化会引入精度损失如果模型本身已经因为蒸馏而能力受限再量化可能直接不可用。具体做法先用 teacher 蒸馏出一个参数量适中的 student比如 1B-3B确认在目标任务上达标再做 INT8 或 INT4 量化。量化后一定要重新跑评估因为量化对不同层的影响不均匀有些任务可能掉点严重。如果显存极其有限可以考虑滑动窗口滤波模型这类轻量结构或者用TCN 模型结构替代部分 attention 层。这些结构在特定任务上能做到接近 transformer 的效果但参数量和计算量更小。5. 常见问题与排查技巧实录5.1 蒸馏效果不达预期怎么排查蒸馏做了但 student 没提升这是最常见的问题。排查顺序排查项检查方法常见原因Teacher 质量在验证集上跑 teacherteacher 在该任务上本身不强数据质量人工抽检 50 条生成数据有格式错误或幻觉数据量看 loss 曲线数据太少欠拟合训练配置对比 baseline 配置学习率、epoch 数不合适评估方法检查评估集分布评估集和训练集分布不一致能力窄化跑泛化评估过拟合到蒸馏任务我的经验是teacher 质量和数据质量占了问题原因的七成以上。很多人跳过 teacher 验证直接生成结果 teacher 本身在这个任务上就不行蒸馏自然无效。5.2 RSI 闭环跑不起来的典型卡点RSI 闭环跑不起来通常卡在三个地方卡点一是评估太慢。如果每次迭代要等一天才能看到评估结果迭代速度就上不去。解法是把评估分层快速评估用自动化指标和少量样本控制在 10 分钟内。卡点二是筛选机制不可靠。用 reward model 筛选但 reward model 本身有偏差筛出来的数据质量不稳定。解法是定期人工抽检筛选结果校准 reward model。卡点三是数据多样性不足。teacher 生成的输出风格单一student 学到的也是单一风格。解法是在 prompt 里加入多样性要求或者用多个 teacher 混合生成。5.3 关于“蒸馏是否可持续”的从业者视角这个问题在社区里争议很大我说说我的看法。从工程角度蒸馏是一个工具工具本身没有对错。用蒸馏快速提升小模型在特定任务上的表现这是合理的工程选择。但如果一个团队长期只做蒸馏不做底层训练和数据积累那它的能力上限是被 teacher 锁死的。我的建议是把蒸馏当作加速器而不是替代品。在项目早期用蒸馏快速拿到可用模型同时并行做自己的数据积累和训练能力建设。等到自己的数据量和训练经验上来了再逐步减少对蒸馏的依赖。这个过渡期可能是半年到一年取决于团队规模和任务复杂度。5.4 模型选型时的常见误判选模型时最容易犯的错是“看榜单选模型”。榜单上的排名和你的实际场景表现可能差很远。我踩过的坑包括榜单上排名很高的模型在我的中文长文本任务上表现一般榜单上不显眼的模型在我的代码补全任务上反而更稳。避免误判的方法是先明确你的核心任务和约束条件再选模型。约束条件包括延迟要求、成本预算、部署环境、数据隐私要求。把这些列清楚候选模型的范围就小很多了。然后在小范围里做实测用你自己的评估集。还有一个细节模型的版本更新很快今天测的结果下个月可能就变了。所以评估要定期重跑不能一次测完就长期依赖。5.5 数据合规与使用边界做蒸馏和 RSI 时数据来源的合规性是一个必须考虑的问题。用公开数据集、用自己积累的数据、用有明确授权的数据这些都没问题。用 API 输出做训练时要仔细看服务条款有些服务明确禁止用输出训练竞争模型。我的做法是在项目启动前就把数据来源和授权情况列一个清单每个来源标注可用范围。这个清单在团队协作时特别有用能避免后续的合规风险。6. 从对谈到落地我的一些实际体会Nathan Lambert 和 JS Denain 的这场对谈价值不在于给出了什么确定结论而在于把 RSI、模型差距、蒸馏这三个话题放在同一个框架里讨论。这个框架对从业者的启发是模型能力的增长不是单一因素驱动的而是训练、数据、评估、蒸馏、部署多个环节共同作用的结果。我在实际项目里的体会是与其追逐最新的模型或方法不如把基础环节做扎实。评估集建好了模型选型就不会太离谱数据质量把控住了蒸馏和微调的效果就有保障RSI 闭环跑通了迭代速度就上来了。这些基础工作不性感但决定了项目的下限。最后分享一个我在做蒸馏时的具体技巧在蒸馏数据里混入 5%-10% 的“困难样本”也就是 teacher 也容易出错的样本。这些样本能让 student 学到 teacher 的边界在哪里而不是盲目模仿。实测下来这个做法能提升 student 在分布外任务上的鲁棒性。具体操作是先用 teacher 在验证集上跑一遍挑出 teacher 预测错误的样本把这些样本的正确答案人工核对过的也加入训练集。这个技巧成本不高但效果比较稳。