企业官网建设流程全解析

1. 从一场对谈说起：RSI、模型差距与蒸馏到底在聊什么

Nathan Lambert 和 Epoch AI 的 JS Denain 坐下来聊 RSI、中美模型差距和蒸馏影响，这个组合本身就很有意思。Nathan 是 Allen AI 出身、长期做开源模型和后训练研究的从业者，Epoch AI 则是专门做 AI 趋势量化分析的机构，两边视角一个偏工程实践、一个偏数据趋势，碰在一起基本不会停留在“模型又变强了”这种层面。我第一时间关注这场对谈，是因为它把三个平时被分开讨论的话题串成了一条线：RSI（Recursive 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 中美模型差距的多维拆解：别用一个数字概括

“中美模型差距”这个说法最大的问题是它暗示了一个单一维度的差距。实际拆开看，至少有这么几个维度：

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 在模型趋势分析上的方法论值得单独讲，因为它提供了一套可复用的量化框架。他们的核心做法是：

1. 建立能力代理指标：把“模型能力”拆成可测量的维度，比如推理、代码、数学、多语言理解等。
2. 追踪训练算力：用训练 FLOPs 作为模型规模的代理，追踪顶尖模型的算力投入趋势。
3. 标准化评估：尽量用统一的评估协议，减少不同团队自报数据的偏差。
4. 趋势外推：基于历史趋势做短期预测，而不是做长期断言。

这套方法的优势是透明、可复现。局限也很明显：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）和蒸馏经常配合使用：先蒸馏出一个结构更小的模型，再做量化。

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, temperature=2.0, alpha=0.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, reduction='batchmean') * (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 质量和数据质量占了问题原因的七成以上。很多人跳过 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 预测错误的样本，把这些样本的正确答案（人工核对过的）也加入训练集。这个技巧成本不高，但效果比较稳。