RSI、中美模型差距与蒸馏技术：从对谈到工程实践的系统梳理

1. 这场对谈为什么值得反复听Nathan Lambert 和 Epoch AI 的 JS Denain 坐下来聊 RSI、中美模型差距和蒸馏影响这个组合本身就很有意思。Nathan 在开源模型圈子里摸爬滚打多年做过 RLHF 相关的研究也在 Allen AI 参与过 OLMo 系列模型的训练JS Denain 在 Epoch AI 做算力和趋势分析擅长用数据说话。两个人一个偏工程实践一个偏宏观趋势碰在一起聊出来的东西比单纯看论文或者刷推文要实在得多。我前后把这场对谈听了三遍第一遍是通勤路上泛听第二遍是拿着笔记本逐段暂停第三遍是挑了几个关键段落反复回放。之所以这么较真是因为里面涉及的几个话题——RSI 到底靠不靠谱、中美模型差距是在拉大还是缩小、蒸馏对模型生态的长期影响——恰好是我最近半年在项目里反复思考的问题。我在做模型微调和部署方案选型的时候经常要判断“现在这个时间点自研还是用开源”“蒸馏出来的小模型能不能扛住生产环境”“国内模型和海外模型的真实差距到底在哪”。这些问题没有标准答案但这场对谈提供了不少有价值的思考框架。这篇文章不是对谈的文字实录而是我基于对谈内容结合自己在模型训练和部署中的实际经验做的一次系统性梳理。我会把 RSI 的核心逻辑拆开讲清楚把中美模型差距的数据和体感对齐把蒸馏这件事从技术原理到实际影响都过一遍。如果你也在做 AI 相关的工程或产品决策或者单纯想搞清楚这几个热词背后的真实含义这篇内容应该能帮你省下不少自己摸索的时间。2. RSI 到底是什么为什么大家都在聊2.1 RSI 的基本概念与常见误解RSI 是 Recursive Self-Improvement 的缩写中文一般叫“递归自我改进”。这个词听起来很科幻但它的核心逻辑其实不复杂一个系统能够利用自身的输出来改进自身而且这个改进过程可以循环进行每一轮改进后的系统都比上一轮更强从而形成加速效应。我刚开始接触这个概念的时候第一反应是“这不就是模型自己训练自己吗”。后来发现这个理解太粗糙了。RSI 的关键不在于“自己训练自己”这个动作而在于改进的闭环是否真的能持续加速。Nathan 在对谈里提到一个很重要的点当前的大模型确实可以在某些环节辅助自身的改进比如用模型生成训练数据、用模型做代码审查、用模型优化训练超参但这些环节目前还是需要人类来设定目标、验证结果、决定方向。真正的 RSI 意味着系统能够自主完成“发现问题—提出改进方案—验证改进效果—决定是否采纳”这个完整循环而且每一轮循环的效率要高于上一轮。这里有一个常见的误解需要澄清很多人把“模型能写代码”等同于“模型能自我改进”。实际上模型写代码只是 RSI 的一个必要不充分条件。一个模型能写出训练脚本不代表它能判断这个脚本的训练效果是否真的比之前好也不代表它能自主决定下一步该往哪个方向优化。RSI 的门槛在于自主决策和自主验证而不是单纯的代码生成能力。2.2 当前 RSI 的真实进展与瓶颈JS Denain 在对谈里给了一个比较冷静的判断目前我们看到的更多是“AI 辅助 AI 研究”而不是真正的 RSI。这个区分很重要。AI 辅助 AI 研究是指人类研究员用 AI 工具来加速自己的研究工作比如用模型来筛选论文、生成实验代码、分析实验结果。这个环节确实在加速而且加速效果很明显。但 RSI 是指 AI 系统自己主导研究过程人类只负责提供算力和数据这个阶段还远远没有到来。我在实际项目里也有类似的体感。我们用模型来生成微调数据的时候确实能节省大量人工标注成本但生成的数据质量参差不齐需要人工筛选和修正。我们用模型来优化推理参数的时候模型能给出一些建议但最终决定用哪组参数还是得靠人在验证集上跑一遍。这些环节里模型是加速器但不是决策者。Nathan 提到一个很有意思的观察RSI 的瓶颈可能不在模型能力本身而在验证环节。一个模型可以快速生成一百个改进方案但验证这一百个方案哪个真的有效需要的时间和算力可能比生成方案本身还要多。这就导致 RSI 的循环速度受限于验证速度而不是生成速度。这个观察对我很有启发因为我们在做模型迭代的时候也经常遇到类似问题生成候选方案很快但评估方案效果很慢最后整个迭代周期还是被评估环节卡住。2.3 RSI 对模型研发流程的潜在影响如果 RSI 真的实现最直接的影响是模型研发的迭代周期会大幅缩短。现在一个大模型的训练周期动辄几个月从数据准备到训练到评估到调优中间有大量人工介入的环节。RSI 实现后这些环节可能被压缩到几天甚至几小时。这意味着模型能力的提升速度会从线性变成指数级。但我觉得更值得关注的是 RSI 对研发组织形态的影响。如果模型能自主完成大部分研发工作那么 AI 实验室的核心竞争力可能从“有多少优秀研究员”变成“有多少算力和数据”。这个转变对行业格局的影响会非常深远。Nathan 在对谈里也提到了这一点他认为如果 RSI 真的实现当前很多 AI 公司的商业模式和竞争壁垒都需要重新思考。不过从目前的情况看RSI 还处于非常早期的阶段。我们在项目里用 AI 辅助研发更多是把它当作一个效率工具而不是一个自主决策者。这个定位在短期内应该不会改变。3. 中美模型差距的真实图景3.1 从 benchmark 数据看差距变化中美模型差距这个话题网上讨论很多但很多讨论要么过于情绪化要么只盯着几个 benchmark 分数。JS Denain 在对谈里给了一个比较系统的分析框架我觉得很有参考价值。他把差距拆成几个维度基础模型能力、训练效率、推理成本、生态成熟度。从基础模型能力看海外头部模型和国内头部模型的差距在缩小。以 MMLU、GSM8K 这些常规 benchmark 为例国内头部模型在两三年前可能落后十几分现在很多榜单上差距已经缩小到几分以内。但这个缩小有多少是真实能力提升有多少是 benchmark 过拟合需要仔细分辨。我在实际使用中的体感是在通用问答和文本生成任务上国内头部模型和海外头部模型的差距确实不大但在复杂推理、代码生成、多步规划这些任务上差距还是比较明显。从训练效率看差距可能比 benchmark 分数显示的更大。海外头部实验室在训练框架、数据配比、超参调优上的积累更深同样的算力预算下他们能训练出更强的模型。这个差距不容易从公开数据里看出来但在实际训练中体感很明显。我们之前尝试复现一些海外模型的训练方案发现同样的数据量和算力预算训练出来的模型效果就是差一截后来发现差距主要在数据清洗和配比这些细节上。3.2 算力约束下的工程应对策略算力约束是国内模型研发必须面对的现实。在这个约束下国内团队发展出了一些很有特色的工程策略。比如在模型架构上国内团队更倾向于用 MoE 架构来提升参数效率用更激进的量化方案来降低推理成本用更精细的数据筛选来弥补数据量的不足。我在项目里也用过类似的策略。我们做本地部署的时候显存预算是硬约束所以必须在模型大小和推理质量之间做取舍。我们的做法是先用大模型生成高质量的训练数据然后蒸馏到小模型上再对小模型做量化。这个流程能在有限显存下跑出可用的效果但每一步都有信息损失最终效果和直接用大模型还是有差距。Nathan 在对谈里提到一个观点算力约束不一定是坏事它可能逼出更高效的工程方案。这个观点我部分认同。国内团队在推理优化、模型压缩、数据效率上的很多做法确实比海外团队更激进也更有创意。但另一方面算力约束也限制了探索空间很多需要大算力才能验证的想法国内团队可能根本没机会尝试。3.3 生态差距与追赶路径除了模型本身生态差距也是一个重要维度。海外有更成熟的工具链、更活跃的开源社区、更完善的数据和评估体系。国内在这些方面也在快速追赶但差距还是存在的。我在选型的时候经常遇到一个问题海外的一些工具和框架文档更全、社区更活跃、遇到问题更容易找到解决方案。国内的一些工具虽然功能不差但文档和社区支持相对薄弱遇到问题需要自己啃源码。这个差距在项目初期可能不明显但在项目进入深水区之后会显著影响开发效率。追赶路径方面我觉得国内团队有几个优势可以利用。一是应用场景丰富国内有大量独特的应用场景可以反哺模型迭代。二是工程能力强国内团队在把模型落地到实际产品上的能力很强。三是数据资源丰富虽然高质量数据仍然稀缺但场景数据的多样性是优势。这些优势能不能转化为模型能力的提升取决于团队能不能把场景反馈有效地整合到训练流程里。4. 蒸馏技术的真实影响与实操细节4.1 蒸馏的基本原理与常见方案蒸馏这个词最近出现频率很高但很多人对它的理解还停留在“大模型教小模型”这个层面。实际上蒸馏的技术细节比这个复杂得多。知识蒸馏的核心思想是让一个小模型学生模型去模仿一个大模型教师模型的输出分布而不仅仅是模仿硬标签。我刚开始做蒸馏的时候以为只要用教师模型的输出作为学生模型的训练目标就行了。后来发现效果并不好因为教师模型的输出分布里有很多“暗知识”比如它对某些错误答案的置信度虽然低但也不是零这些信息如果直接用来训练学生模型可能学不到重点。后来我们改用温度参数来平滑输出分布让学生模型更容易学到教师模型的相对偏好效果才上来。常见的蒸馏方案有几种logit 蒸馏、特征蒸馏、关系蒸馏。logit 蒸馏是最常用的就是让学生模型去拟合教师模型的输出概率分布。特征蒸馏是让学生模型的中间层特征去逼近教师模型的中间层特征这个在视觉任务里用得比较多。关系蒸馏是让学生模型学习样本之间的关系这个在推荐系统里比较常见。4.2 蒸馏在小模型部署中的实际效果我们在项目里用蒸馏主要是为了把大模型的能力迁移到小模型上以便在有限显存下部署。实际效果怎么说呢有惊喜也有失望。惊喜的是在文本分类、意图识别、简单问答这些任务上蒸馏后的小模型能达到教师模型 90% 以上的效果但参数量只有教师模型的十分之一甚至更少。这个性价比很高在很多对延迟和成本敏感的场景里完全够用。失望的是在复杂推理、多步规划、代码生成这些任务上蒸馏的效果损失比较明显。我们试过用 GPT-4 级别的模型蒸馏一个 7B 的小模型来做代码生成结果小模型在简单函数生成上还行但遇到需要多步推理的题目就经常出错。后来分析发现教师模型在推理过程中有一些“隐式步骤”这些步骤在输出分布里体现得不明显学生模型很难学到。Nathan 在对谈里也提到了类似的观点蒸馏能传递的是“结果”但很难传递“过程”。教师模型在推理时可能走了很多步但最终只输出一个答案学生模型看到的是答案看不到推理过程自然学不到推理能力。这个观察和我们的实际经验很吻合。4.3 蒸馏对模型生态的长期影响蒸馏对模型生态的影响是一个值得认真思考的问题。短期看蒸馏让小模型的能力快速提升降低了模型部署的门槛这对整个行业是好事。但长期看蒸馏可能带来一些负面影响。第一个影响是模型同质化。如果大家都用少数几个大模型来蒸馏小模型那么小模型的能力分布会趋同多样性会下降。这对需要多样化模型能力的应用场景是不利的。第二个影响是创新动力。如果蒸馏就能获得不错的效果那么从头训练小模型的动力就会下降。长期看这可能导致小模型架构和训练方法的创新放缓。第三个影响是评估难度。蒸馏出来的模型在 benchmark 上可能表现不错但实际能力边界可能和教师模型差异很大。如果评估体系不能准确反映这种差异就可能导致模型选型失误。我在项目里的做法是蒸馏模型和原生训练的小模型都会保留根据任务特点选择使用。对于需要快速迭代、对成本敏感的任务用蒸馏模型对于需要深度推理、对质量要求高的任务用原生训练的小模型或者直接调用大模型 API。这个策略不一定最优但至少能平衡成本和效果。5. 从对谈延伸出的实操建议5.1 模型选型的决策框架基于这场对谈的内容和我自己的项目经验我整理了一个模型选型的决策框架。这个框架不是要给出标准答案而是提供一个思考路径。第一步是明确任务类型。如果是通用问答、文本生成、简单分类蒸馏后的小模型或者国内头部模型完全够用。如果是复杂推理、代码生成、多步规划建议用海外头部模型或者国内头部模型的大参数版本。第二步是评估成本约束。如果显存和延迟是硬约束优先考虑蒸馏模型或者量化模型。如果成本不是主要问题优先考虑效果。第三步是考虑数据隐私和合规要求。如果数据不能出本地必须用本地部署的模型。如果能接受 API 调用可以用云端模型。第四步是留出迭代空间。模型选型不是一次性的随着业务变化和模型迭代选型也需要调整。建议在架构设计上留出切换模型的灵活性。5.2 蒸馏实操中的避坑清单蒸馏实操中有几个坑我踩过这里列出来供参考。第一个坑是温度参数设置不当。温度太高学生模型学到的分布太平滑区分度不够温度太低学生模型学到的分布太尖锐泛化能力差。我们的经验是温度设在 2 到 5 之间比较合适具体值需要在验证集上调。第二个坑是教师模型选择不当。不是越大的教师模型越好。如果教师模型和学生模型的架构差异太大蒸馏效果可能反而不好。我们试过用 70B 的模型蒸馏 1B 的模型效果不如用 13B 的模型蒸馏 1B 的模型。第三个坑是训练数据配比。蒸馏数据要和原始训练数据混合使用纯蒸馏数据训练出来的模型容易过拟合教师模型的偏好。我们的配比是蒸馏数据占 30% 到 50%其余用原始数据。第四个坑是评估不充分。蒸馏模型在训练集上的表现可能很好但在分布外数据上可能很差。评估的时候一定要留出分布外测试集。5.3 对 RSI 和模型差距的理性预期最后说一下我对 RSI 和中美模型差距的理性预期。RSI 方面我认为短期内三到五年不会实现真正的递归自我改进。我们看到的更多是 AI 辅助研发的加速而不是 AI 自主研发。这个判断基于两个观察一是验证环节的瓶颈还没有突破二是自主决策的可靠性还不够。但这不意味着 RSI 不重要相反它应该被当作一个长期方向来关注和投入。中美模型差距方面我认为差距在缩小但缩小的速度在放缓。基础模型能力的差距可能在未来两三年内缩小到可接受的范围但生态差距和工程效率差距可能需要更长时间来追赶。对于做应用的人来说与其纠结差距有多大不如关注在给定约束下怎么做出最好的产品。这场对谈给我的最大启发是技术讨论要区分“事实”和“叙事”。RSI 和中美模型差距都是容易被叙事裹挟的话题但真正做决策的时候还是要回到具体的数据和实际的体感上来。我在项目里做选型的时候从来不看 benchmark 排名而是自己跑一遍实际任务看效果、看成本、看稳定性。这个习惯帮我避免了很多坑也推荐给你。