企业官网建设流程全解析

别人看到你的数据不同，体现在每个样本的生成方式上——好的蒸馏数据不是把论文题目灌进去就能跑出来的，而是需要一整套“师生互动剧本”：先由教师针对你的目标场景生成一批高质量答复，再由你手工/规则筛选，最后用模型自己生成的样本回炉。这批数据既要有覆盖面，又不能全是高频任务。我习惯把一个任务的样本分成三块：三分之一是教师直接从公开Benchmark里挑的高分答案，三分之一是用不同Role Prompt让教师围绕同一知识点重新组织语言，剩下三分之一故意在教师输出后拼接错误上下文，用来考验学生模型在干扰下的稳定性。很多团队只保留教师答得漂亮的样本，结果学生模型永远学不会“不完美输入下如何挣扎”的应对策略。

比较意外的是，蒸馏的收益对于“知识密集型”任务非常明显，但让“推理密集型”任务真正受益的关键是提示模板，而不是样本数量。你要教师用链式思考把整个分析过程写出来，再让学生去学这个思考轨迹，而不是只学最终结论。这也是很多人所谓“蒸馏失败”最常见的根源——你让学生从一段只有“是/否”的标签里学习推理，怎么可能学得出推理能力？所以我在准备训练数据时，会强制把教师的完整推导过程保留下来，哪怕是重复率极高的简单问题也不删。过程越长，学生学到的内部思维协作就越深。

3.2 三种常见的蒸馏损失配置

数据准备好之后，剩下的核心动作就是“让学生的输出分布靠近老师的输出分布”。经典的蒸馏损失通常包含两路：一路是用teacher softmax概率做KL散度对齐，另一路是直接用真实标签做交叉熵兜底。代码写出来大概是这样：

import torch import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, T=4.0, alpha=0.7): # 软化老师与学生输出 student_soft = F.log_softmax(student_logits / T, dim=-1) teacher_soft = F.softmax(teacher_logits / T, dim=-1) kl_loss = F.kl_div(student_soft, teacher_soft, reduction="batchmean") * (T * T) # 硬标签交叉熵 ce_loss = F.cross_entropy(student_logits, labels) return alpha * kl_loss + (1 - alpha) * ce_loss

这里温度T是个很有讲究的数字。T越小，softmax就越接近one-hot，学生基本只看到教师的最终答案；T越大，分布的尾巴越平，学生能看到教师在错误答案之间微妙的犹豫程度。对于一般任务，T=4左右比较实用；但对于代码生成这类正确答案基本唯一的场景，T=2甚至更低的温度反而更好，因为你在乎的是确信的答案边界，而不是想让学生学会无意义的犹豫。

另一种更与现代LLM工作流匹配的蒸馏方式，是让教师模型对同一组问题生成多个候选回复，再让学生模型在这些候选回复间做对比学习。这种做法本质上把教师当成一个分布采样器，输出的多样性本身就是训练信号。实测里，多候选蒸馏对指令跟随能力的提升非常显著，特别是对Prompt变化敏感的用户场景，学生模型会从不同措辞里学会泛化，而不是死记一个表面句式。

至于蒸馏和微调在配置上的差别，对比起来会非常直观：

3.3 训练参数里的软硬取舍

蒸馏训练中另一个常见的坑是“软目标比例alpha”的选择。很多人一开始总喜欢把alpha设成0.9，觉得向教师学得越多越好。实际训练时，1.0的纯KL反而容易导致学生模型丢失对真实世界的常识判断——教师也会犯错，特别是教师本身在长尾知识上是“自信地胡说”。我通常先跑一轮小实验，alpha从0.5起步，观察学生模型在硬性问答指标上的衰减速度，再逐步提高软目标比例。如果某个领域你自己的标注数据本来就稀缺，alpha高一些没关系；但要是你有几千条高质量人工标注，那硬标签交叉熵的权重要适当拉高。

还要注意一点：你的验证指标和蒸馏损失很可能不是同一个东西。你真正关心的是下游任务的准确率或用户满意度，但训练时用的是KL散度。这两个目标并不完全一致，所以训练中最常见的结果是KL一直在降，但任务指标早就停止提升了。遇到这种情况，别无脑加训，先检查是否是温度偏高导致模型过度平滑，把不同T、不同alpha的小批量实验跑一遍对比，往往比你增加一倍训练步数更有效。

4. 蒸馏和微调的边界感：什么时候这是同一件事，什么时候它们是两种活儿

蒸馏和微调在工程上的边界越来越模糊，但在讨论争议时，大家容易把这两者混为一谈。事实是，微调是“在已有模型基础上，用特定语料继续训练”，蒸馏则是“以另一个模型为主要监督信号来训练新模型”。它们的目标方向不同：微调更接近于“给你装备新工具”，蒸馏更接近于“请一位老师言传身教”。所以一个更准确的说法是：你可以在蒸馏出来的学生模型上再做微调，也可以在微调过程中加入教师分布约束，那不是非此即彼的关系。

从工作场景来看，如果你的任务是让通用模型学会某个垂直领域的术语和格式，直接微调就够了。因为你需要的是知识注入，而不是换一种答题风格。比如做工业质检描述，模型只要学会“划痕深度0.3mm属于缺陷品”的表达和判定标准，直接微调几万条标注数据效果就非常好。但如果你想在10B的模型上复刻一个100B模型那种“有逼格”的回答方式，比如能分步骤思考、遇到无法回答的问题能得体拒绝，微调是办不到的——你应该用包含教师对复杂问题完整作答记录的语料去做蒸馏。

还有一种很多人忽略的场景：间接蒸馏。也就是你不直接拿教师的回答当目标，而是拿一堆由教师生成的数据做清洗、改写，再标注训练学生。这是实际工程里用得最多的手法，因为它能把教师的“生物形态”洗掉一些，让学生更像一个独立个体。著名的“用AI蒸馏一本书”就是这么个流程——先把一本书的目录拆成章节，让教师模型基于每章节生成大量问答，然后再用规则过滤掉重复、矛盾、超出原书范围的内容，最后拿这些问答去训练小模型。这本质上是蒸馏，但它已经被包装成“合成数据微调”。这也解释了为什么名单争议出来之后，各家可以义正辞严地说“我们没有直接复制权重，我们用的是自研语料”。

可是从模型行为的角度看，间接蒸馏反而更“伤”学生。因为数据经过多轮改写后，学生的知识边界会崩得非常厉害——它可能把一个错误的事实学得非常坚定，因为那份改写后的数据细节太逼真了。我见过有人在蒸馏医疗问答时，跳过人工审核直接训练，结果模型把教师幻觉里“某某药可用于某某疾病”当成金科玉律，输出确定得让人害怕。所以请记住：蒸馏会放大教师的盲区，微调则至少能让你的标注人员把住最后一道关。

实践中我的选型经验是：如果预算允许，尽量走“先蒸馏后微调”的两段式——先用教师数据训练出一个能力结构完整的学生，再用自有的高质量标注把核心业务场景校准一遍。前者解决“会不会”，后者解决“对不对”。很多团队想一步到位，直接混合两种数据训练，结果模型既没有完全继承教师风格，又丢失了部分自有知识，反而要返工。

5. 嫌疑模型的“指纹”：如何识别一个模型大概率蒸馏过

聊完技术，再回到名单事件本身。圈内人对名单还有一个非常关心的问题：这些“蒸馏嫌疑”到底是怎么被看出来的？虽然我们没有内部代码和训练日志，但社区通常靠三类证据来推断一个模型是否经过蒸馏。这三类证据不是百分百实锤，却足够引起注意。

5.1 输出概率的尖峰与怪癖

第一类证据藏在模型输出概率的特征里。一个真正从头训练的模型，它对自己输出的置信度通常是“常态分布”的——有些问题很确定，有些问题很犹豫，整体概率不会全体压在某个奇怪的位置。但蒸馏出来的模型往往在两类问题上会暴露痕迹：当问题与教师模型的高频训练主题重合时，学生模型会非常明显地表现出“极度确信”的尖峰分布，而且答案的结构和转折词风格几乎和教师一致；遇到教师也拿不准的冷门问题时，学生的输出概率又混乱得像随机噪声，因为整个知识分布都是从教师那里复制来的，教师没把握的地方传到学生手上就成了稀烂的一团。

这就导致了一个有趣的现象：蒸馏模型在某个领域内的答案质量非常稳定，一旦跨界到教师不熟悉的领域，立刻原形毕露。所以做模型评测时，不要只跑那些公开Benchmark——那些题目往往早就被教师模型见过无数遍，学生模型跟着占便宜。你要自己构造一批教师训练分布之外的冷门题，看模型还能不能保持水准。这招说白了就是“考试时给同桌作弊，遇到没复习过的综合题就会露馅”。

第二种概率怪癖是答案模板的过度固化。教师模型经过指令对齐后，往往形成一套固定的开头句式、递进指词和总结套路。学生蒸馏时为了降低Loss，会把这种风格放大成一个更刻板的模板。比如教师可能有时说“首先”，有时说“第一步”，而学生在所有回答里都机械地用同一个词。这不是模型风格稳定，这是学习数据里风格多样性不足的典型信号。你可以拿几百条输出做一次高频词汇统计，如果连接词和引导语的重复率超过某个阈值，蒸馏嫌疑就很高。

5.2 长尾能力的消失与创造力的坍缩

第二类证据没那么玄学，直接看能力分布。蒸馏最容易被牺牲掉的就是长尾能力。一个大模型从头训练时会接触到天文数字的语料，知识结构是千姿百态的；蒸馏数据却只覆盖了你喂给教师的那些Prompt空间。所以学生模型的学习广度完全取决于数据构建者的策划能力。如果你让教师扮演“某个领域的专家”，教师输出的样本通常会聚焦在几个高频问题上，而真正冷门但同样合理的问题，教师回答得少，学生也就从未见过。最后模型给人的感觉就是：它很懂，但只懂你问它的那几类问题。

这在业界有一个非常直观的表现：同一个模型，在通用榜单上的分数高得惊人，但你拿一些非主流问题去问，比如“明清时期江南的民间契约格式有哪些变体”或者“一部冷门电影的叙事结构分析”，它可能瞬间退化成一个只会堆砌术语的空壳。因为教师模型自己也不是万能的，学生模型把教师的这种局限性原封不动地继承了下来。用行话讲，这叫“能力坍缩”。

第三类证据是直接的文本重复。蒸馏的另一个常见副作用是，学生会把训练数据中的高频段落背下来，并在不同问题的回答里反复输出同一段内容。这不是像抄袭，而是真的一字不差。我在实际排查模型时，会特意把同一模型的几百条输出做两两相似度比较，如果发现大量片段完全一致的输出——特别是那些逻辑通畅、措辞优美但与当前问题关系不大的长句——几乎可以断定模型从某种教师输出语料里学到了“缝合”习惯。

5.3 社区里的“测谎”法，到底靠不靠谱

网上还有一种更业余的测法：用某个模型生成的回答去问另一个模型，让后者判断“这是不是你的输出”，或者用困惑度去比较。说实话，这些方法只能用于辅助，根本谈不上证据。因为先不说开源模型的权重本身就是公开的，很多团队的基座模型本来就是同一个开源检查点，所谓“输出风格一致”只是正常亲缘关系。真正的社区测谎手段多半是找下毒样本——在教师训练数据里埋一批特殊指令，让教师给出特定回答，如果学生模型也能复现，就能反向证明它用的是同一批数据训练。

这类测试在近期风波中确实被大量使用了，而且效果还很惊人，因为一些被怀疑的模型没有完全清洗掉教师数据中的特殊标记痕迹。但从技术角度说，这只能证明“训练数据里包含了教师的生成文本”，不能证明“模型是偷偷蒸馏来的”。这个界限必须划清楚，否则一顶帽子扣下来，谁也受不了。

6. 当我也把自己的模型蒸馏了一遍：一些不吐不快的现实经验

写了这么多理论，最后想聊点更个人化的东西。作为一个从2023年就开始拿大模型输出回训小模型的实践者，这几年的经历让我对蒸馏这件事又爱又怕。爱的是它确实解决了“小团队没有算力堆数据”的难题，怕的是它留下的隐患往往要等到上线后才会集中爆发。

第一个非常现实的体会是：蒸馏不是一锤子买卖，它是一个持续迭代过程。你蒸馏出来的学生模型上线后，用户反馈会暴露它的大量短板，你再拿着这些短板去问教师，教师补数据，再训练。循环往复，你才能保持一个还不错的状态。很多公司被点名的模型之所以看起来“和某知名闭源模型高度相似”，本质上是因为他们只做了第一轮蒸馏就匆忙发布，没有追加打磨。但凡多迭代几轮，模型风格早就被自家业务数据冲淡了，也不会留下那么多刺眼的模板痕迹。

第二个体会更难说出口：越省力的方案，越经不起放大镜观察。蒸馏的最快路径确实是拿教师的一批高质量输出堆在一起做监督训练。可这些高质量输出通常来自同一种Prompt模式，最后的模型就像“一株嫁接在他人审美上的盆景”——远看很美，近看全是问题。我自己后来改用了“老师带学生，学生再教学生”的多轮流程：先蒸馏第一版学生，再拿第一版学生重新生成一批数据，和教师数据按比例混合训练第二版。这样做出来的模型，虽然部分能力弱于教师，但风格上更自然、回答的上下文连贯性更扎实。虽然过程中需要多烧两倍算力，但至少面对“这模型是抄的吧”的质疑时，你能拿出一个属于自己的中间检查点。

最后一个建议给所有正在做或准备做蒸馏的团队。无论你是出于隐私合规还是团队自尊心，都别让你的蒸馏流程变成一个黑箱。我在自己项目的README里会明确写上“教师模型是什么”“合成数据怎么生成”“过滤规则是什么”。不是因为我想公开商业机密，而是因为只有把过程记录下来，未来出了问题你才能回溯到具体哪一步引入了教师的幻觉或偏见。这个习惯在我处理一次医疗问答模型的严重误答时，直接帮我省下了两周的排查时间。更有意思的是，当圈内散播“某某模型可疑”的消息时，那些能公开交代训练过程的团队往往最不容易被点名，因为他们的研发链路上有足够多的人工痕迹和检查节点，别人一眼就能看出来这不是套壳。

风波总会过去，蒸馏作为一项技术也不会因为某次争议就从工具库里消失。它太高效、太省钱了，任何做模型的人都抗拒不了这种性价比。但正因为如此，我们才更要把蒸馏当成一个需要反复权衡的工程方案来对待——而不是一个可以用一行命令换来的“捷径”。技术在进步，至于你是靠实力还是靠“借力”走到今天，最终都会在模型的一举一动里留下痕迹。