知识蒸馏是模型压缩里最常用的手段之一：用一个大模型的预测结果去训练一个小模型，让它在参数量小很多的情况下逼近大模型的效果。但在实际项目中，很多人把蒸馏当成一个损失函数问题来做，反复调温度系数、改 KL 散度权重，效果却总是不稳定。原因往往不在蒸馏本身，而在数据。原始训练集如果类别不平衡、样本量不足或者噪声比例偏高，教师模型的输出也会继承这些问题，学生模型学到的东西自然受限。PROOF-Gen 的思路正好从这里切入：在进入蒸馏训练之前，先构造一批面向教师模型的优化数据，用这批数据去提升学生模型的学习质量。
这篇文章会围绕 PROOF-Gen 梳理一整套可落地的知识蒸馏数据流程：从数据诊断、生成候选样本、样本过滤，到联合训练和验证对比。读者可以是正在做模型压缩的算法工程师，也可以是刚接触蒸馏但想把效果跑明白的研究生。看完之后，你应该能搭建一个最小可运行的数据蒸馏链路，并且在效果没提升时，知道该从哪个环节排查。
1. 先理解蒸馏效果为什么卡在数据上
1.1 蒸馏不只是把教师输出当作标签
知识蒸馏的经典做法是让学生模型同时学习两个目标：一个是真实标签的硬损失，另一个是教师模型输出软标签的软损失。软标签指的是教师模型在某个输入上输出的概率分布，它比真实标签多了一层信息：哪些类别和当前类别相似，模型对哪些类别不确定。
一个典型蒸馏损失可以用下面的 PyTorch 片段表示：
import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, alpha=0.7, T=3.0): hard_loss = F.cross_entropy(student_logits, labels) soft_loss = F.kl_div( F.log_softmax(student_logits / T, dim=-1), F.softmax(teacher_logits / T, dim=-1), reduction="batchmean" ) * (T * T) return alpha * hard_loss + (1 - alpha) * soft_loss这里T是温度系数，它会把概率分布重新拉平。T越大，软标签里类别间的关系越明显；T越小，软标签越接近 one-hot。T * T是修正因子，因为 logits 被T缩放后，回传梯度也变小了，需要补回来。
不过要注意，这个公式隐含了一个前提：教师模型给出的软标签是可靠的。如果数据本身有问题，教师模型就会在部分样本上给出一套偏差很大的分布。此时，软标签不是知识，而是噪声来源。
1.2 原始训练集在蒸馏阶段会暴露三类典型问题
很多项目在蒸馏前没有重新检查过原始数据，直接拿训练集和教师模型开始训练，于是问题被带到了下游。常见情况如下：
| 数据问题 | 表现 | 对蒸馏的影响 |
|---|---|---|
| 类别不平衡 | 少数类别样本数量少 | 教师模型在少数类上学得差，软标签偏向多数类 |
| 样本量不足 | 训练曲线抖动明显，验证集波动 | 教师模型拟合不稳定，学生模型学到的是较高方差预测 |
| 标签噪声 | 部分样本标注错误 | 软标签与硬标签冲突，学生模型在噪声样本上反复震荡 |
这些现象在普通训练中也会影响精度，但在蒸馏里影响更大。因为学生模型不仅要学硬标签，还要学教师对样本的不确定性判断。当教师模型本身就因为数据偏差而判断错误时，学生模型会把错误判断当成知识来拟合。
所以，PROOF-Gen 的第一步不是急着写蒸馏代码，而是先回答一个问题：当前数据是否值得让教师模型去传授知识。
2. PROOF-Gen 的定位：把数据生成变成蒸馏前的独立阶段
2.1 从原始数据到优化数据的完整链路
PROOF-Gen 可以理解为一套面向知识蒸馏的数据工作流。它不把数据增强和样本生成当作附属操作，而是把它们独立成蒸馏之前的一个工序。整个流程可以拆成四步：
- 数据诊断：统计类别分布、教师模型置信度、困难样本比例，定位数据薄弱点。
- 候选样本生成：在原始样本基础上加入扰动、混入语义变化，然后交给教师模型输出软标签。
- 样本过滤：根据置信度、学生模型预测差异等指标，剔除低价值候选样本。
- 数据合并与重标注：把筛选后的生成样本与原始样本按比例合并，作为学生模型的训练集。
这个流程的核心不是“生成越多越好”，而是通过生成方式来打补丁。教师模型在哪些样本上表现得不够好，就针对这些区域补充数据，让软标签分布更可信。
2.2 与普通数据增强和生成式数据增强的区别
很多团队已经用普通数据增强做过蒸馏，比如随机裁剪、翻转、颜色扰动。这类方法简单，但不会改变原始数据分布的形状，只能让样本在同一分布内更丰富。生成模型增强则是利用 GAN 或扩散模型产生新样本，能覆盖分布外区域，但训练生成模型本身成本很高。
用表格对比：
| 方法 | 目标 | 数据来源 | 是否依赖教师模型 | 适用场景 |
|---|---|---|---|---|
| 普通数据增强 | 保持语义的扰动 | 原始样本自身变换 | 否 | 样本量足够，需要提升稳定性 |
| 生成模型增强 | 扩充分布外样本 | 生成模型无条件或条件生成 | 通常否 | 原始样本严重不足 |
| PROOF-Gen 类数据生成 | 修正教师模型暴露出的盲区 | 原始样本变换 + 教师模型反馈 | 是 | 蒸馏前需要提升软标签质量 |
PROOF-Gen 区别于前两者的关键点，是教师模型会参与数据选择。它生成的不是直接给学生训练的原始图像，而是“样本 + 教师软标签”组合。教师模型在这个流程里，既是被学习对象，也是数据质量的评估器。
3. 环境准备：用最小项目跑通 PROOF-Gen 流程
3.1 依赖选型和版本建议
本文示例基于 PyTorch。之所以选 PyTorch，是因为它写自定义训练循环和蒸馏损失比较直接，社区资料也多，方便复现。
| 依赖 | 用途 | 参考版本 |
|---|---|---|
| Python | 运行环境 | 3.8 及以上 |
| PyTorch | 模型定义与训练 | 建议 1.10 以上，实验前以官方稳定版为准 |
| TorchVision | 数据集与视觉模型 | 与 PyTorch 版本对应 |
| NumPy | 数据统计与处理 | 1.21 及以上 |
| scikit-learn | 评估指标与抽样 | 1.0 及以上 |
| tqdm | 训练进度展示 | 任意较新版本 |
具体版本要根据你的环境确认，尤其要注意 PyTorch 和 TorchVision 的匹配关系，否则加载 CIFAR-10 时可能报版本不一致错误。
3.2 项目结构先定清楚
把数据生成、过滤、训练分开写，比把所有逻辑堆在一个文件里更容易排查。推荐结构如下：
proof_gen_demo/ ├── data/ # 原始数据集缓存 ├── output/ # 模型权重、日志、样本池 ├── scripts/ │ ├── diagnose.py # 数据诊断 │ ├── generate.py # 生成候选样本 │ ├── filter.py # 过滤样本 │ └── train_teacher.py # 训练教师模型 ├── proof_gen/ │ ├── dataset.py # 数据集与样本池 │ ├── distill.py # 蒸馏损失与训练循环 │ └── evaluate.py # 精度和分布指标评估 └── requirements.txtscripts下的脚本负责跑了就能出结果的任务，proof_gen包负责可复用的核心逻辑。这样在你替换成业务数据时，只需要改数据加载和模型结构，不需要重写流程。
3.3 先用 CIFAR-10 这类数据验证流程
学习阶段建议先用 CIFAR-10 而不是业务数据。原因是它类别均衡、数据量小、可视化方便，硬标签准确率和软标签分布都能快速验证。如果链路在小数据集上跑不通，换到复杂业务数据会更难排查。
加载方式：
import torchvision.transforms as T from torchvision.datasets import CIFAR10 transform = T.Compose([ T.ToTensor(), T.Normalize((0.4914, 0.4822, 0.4465), (0.2470, 0.2435, 0.2616)), ]) train_ds = CIFAR10(root="./data", train=True, download=True, transform=transform) test_ds = CIFAR10(root="./data", train=False, download=True, transform=transform)这里的均值和标准差来自 CIFAR-10 数据集统计，换到自己的数据后不能直接复制，要先重新计算。否则图像归一化范围不对，生成样本的扰动幅度也会失真。
4. 核心实现：先诊断，再生成，最后过滤
4.1 数据诊断脚本：先量化再决策
不要凭感觉判断数据差在哪。一个简单诊断脚本可以输出类别分布和教师模型置信度，帮助确定生成参数。
示意代码：
from collections import Counter import numpy as np def diagnose(dataset, model=None, device="cpu"): labels = [sample[1] for sample in dataset] counter = Counter(labels) total = len(labels) print("总样本数:", total) for cls in sorted(counter.keys()): print(f"类别 {cls}: {counter[cls]} 样本, 占比 {counter[cls] / total:.4f}") if model is not None: model.eval() confidences = [] # 这里需要按 batch 遍历数据，收集教师模型预测置信度 # 示意逻辑：conf = softmax(logits).max() print("教师模型平均置信度:", np.mean(confidences)) print("低置信度样本占比:", np.mean(np.array(confidences) < 0.5))如果某个类别的样本少，或者教师模型在某个类别上的置信度明显偏低，那么生成阶段就要提高该类别的扰动和混合比例。诊断的价值在于，让后续参数不是拍脑袋选的。
4.2 基于教师模型生成候选样本
生成阶段不使用生成模型，而是对真实样本做受控变换，然后让教师模型输出软标签。这种方式成本低，且不会引入过多分布外样本。
这里给出一个示意结构：
import torch import torch.nn.functional as F def generate_candidates(model, dataset, T=3.0, noise_scale=0.05, mix_prob=0.5): model.eval() candidates = [] for img, label in dataset: # 方式一：添加高斯噪声 noisy_img = img + torch.randn_like(img) * noise_scale noisy_img = torch.clamp(noisy_img, 0.0, 1.0) # 方式二：按概率与随机样本做 mixup if torch.rand(1).item() < mix_prob: other_idx = torch.randint(0, len(dataset), (1,)).item() other_img, _ = dataset[other_idx] lam = torch.rand(1).item() noisy_img = lam * noisy_img + (1 - lam) * other_img with torch.no_grad(): logits = model(noisy_img.unsqueeze(0)) probs = F.softmax(logits / T, dim=-1) candidates.append((noisy_img, label, probs)) return candidates这段代码的目的是说明思想，不是最终可直接上生产的版本。实际项目中要注意三点：
- 数据归一化范围必须一致。如果训练时像素被归一化到 0 到 1，生成阶段也必须在同样范围内操作。
- 固定随机种子，否则每次生成结果不稳定。
- 对 batch 做循环，而不是单样本循环，否则生成速度太慢。
4.3 样本过滤：高质量不等于高置信度
生成完候选样本后，不能直接把所有样本加入训练集。需要按规则过滤，过滤本身决定了生成数据的价值。
常见过滤规则有：
- 保留教师置信度落在中间区间的样本。
- 保留学生模型当前预测与教师模型预测差异较大的样本。
- 剔除教师置信度极低的样本，因为大概率是噪声。
示意代码：
def filter_samples(candidates, lower=0.4, upper=0.95): kept = [] for img, label, probs in candidates: conf = probs.max().item() if lower <= conf <= upper: kept.append((img, label, probs)) return kept为什么要过滤高置信度样本？因为教师模型对过于熟悉的样本输出非常确定，这类样本提供的新信息很少。真正能帮助学生模型改进的，往往是位于教师决策边界附近的样本。低置信度样本也未必有用，通常要优先丢弃。
4.4 合并数据时要注意比例
合并原始数据和生成数据时，不建议一次性把生成数据全部加入。经验做法是从少量开始，比如先按 1:1 混合，再根据验证集变化调整。
| 数据构成 | 特点 | 适用情况 |
|---|---|---|
| 原始数据 | 分布真实，但可能有偏差 | 必须保留 |
| 原始数据 + 低比例生成数据 | 稳定性较好，提升温和 | 初次实验建议 |
| 生成数据占比过高 | 学生模型会被教师重复预测主导 | 验证集掉点时需要降低比例 |
生成数据比例的调整，本身就是蒸馏实验的一部分，应当记录在实验日志里。
5. 蒸馏训练与结果验证
5.1 训练策略选择
在 PROOF-Gen 链路里，建议至少跑三组实验：
- 教师模型基线：原始数据训练，代表蒸馏上限参考。
- 学生模型基线：原始数据训练，代表不蒸馏的下限。
- 学生模型 + PROOF-Gen 数据：完整流程。
训练循环可以使用统一的蒸馏损失函数：
def train_one_epoch(student, teacher, loader, optimizer, alpha=0.7, T=3.0): student.train() teacher.eval() total_loss = 0.0 for images, labels in loader: images = images.to(device) labels = labels.to(device) optimizer.zero_grad() student_logits = student(images) with torch.no_grad(): teacher_logits = teacher(images) loss = distill_loss(student_logits, teacher_logits, labels, alpha=alpha, T=T) loss.backward() optimizer.step() total_loss += loss.item() return total_loss / len(loader)这里教师模型必须处于eval模式，并且用torch.no_grad()包裹，避免更新教师参数。学生模型则正常反向传播。很多第一次写蒸馏的人会把教师模型也设成train模式，导致训练结果不稳定。
5.2 日志要记录软损失和硬损失
只看总 loss 不够，因为总 loss 可能掩盖软损失不下降的问题。建议每条 epoch 记录这几个指标：
epoch=5 loss=1.023 hard=0.642 soft=0.381 acc=0.781 teacher_conf=0.832其中hard代表硬标签交叉熵损失，soft代表软标签 KL 损失。如果整体准确率在涨但软损失一直不降，说明学生模型可能只靠真实标签学习，没有真正从教师模型里获取知识。
5.3 基线对比表要提前留好
最终对比表可以这样设计：
| 实验 | 数据 | 验证集准确率 | 说明 |
|---|---|---|---|
| 教师模型 | 原始数据 | 待填写 | 蒸馏上限参考 |
| 学生模型 | 原始数据 | 待填写 | 不蒸馏的基线 |
| 学生模型 | 原始数据 + 普通增强 | 待填写 | 区分数据增强影响 |
| 学生模型 | 原始数据 + PROOF-Gen 数据 | 待填写 | 本文完整流程 |
建议自己跑完再填写数字，不要照搬网上结果。不同模型结构、初始化方式和数据变换，会让结果存在明显波动。
6. 常见问题排查：效果没提升时按这条链路找
6.1 加了生成数据反而掉点
| 现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 验证集准确率低于只用原始数据 | 生成样本噪声太大 | 可视化生成样本，检查是否超出合法像素范围 | 调低噪声幅度，或统一归一化范围 |
| 生成数据覆盖了错误类别分布 | 过滤阈值不合适 | 统计过滤后样本的类别比例 | 调整置信度上下限，或按类别分别设置 |
| 教师模型过拟合原始数据 | 教师模型训练集指标远高于验证集 | 对比教师模型训练集和验证集准确率 | 对教师模型做更强的正则化或早停 |
掉点不一定意味着 PROOF-Gen 无效，可能只是某个生成参数过强。建议每次只调整一个参数，不要同时改噪声、过滤阈值和混合比例。
6.2 软标签损失不下降
如果总损失下降，但soft部分基本不变，说明学生模型没有从软标签中学到东西。常见原因包括：
- 温度
T太小，软标签接近 one-hot，KL 损失缺乏梯度信息。 alpha太大，软损失在总损失中权重过低。- 教师模型在部分样本上预测分布过于尖锐，即使提高温度也没有明显软化效果。
可以打印教师模型软标签分布的熵。如果熵很小，说明教师模型本身已经很自信，软标签信息有限，此时应该检查教师模型是否过拟合，或者是否需要重训教师模型。
6.3 训练不稳定或出现 NaN
NaN出现时先按顺序排查：
- 输入数据里是否有 NaN。生成样本时如果加入过大噪声，可能出现非法数值。
- 温度
T是否导致 logits 除以 0 或接近 0。 - 学习率是否过大。
一个简单做法是在 loss.backward 前检查 loss 是否为有限值：
if not torch.isfinite(loss): print("loss 出现 NaN，停止本轮训练") break这种保护在调试时很有用，能快速定位是生成数据问题还是优化器问题。
6.4 生产环境还要检查数据来源和合规性
生成数据本质上是对原始数据的变换和再利用，需要注意两点：一是原始数据来源是否允许生成派生数据，二是生成样本不能包含可识别的个人信息。在业务数据上做蒸馏之前，应该先完成数据脱敏，再检查生成样本是否会泄露敏感内容。这个问题与模型效果无关，但影响上线决策。
7. 最佳实践与下一步扩展
7.1 可复用的数据工作流检查清单
每次跑 PROOF-Gen 实验，建议留好以下记录：
- 数据版本：原始数据来自哪个目录，是否做过清洗。
- 随机种子：生成、过滤、训练是否统一固定。
- 生成参数：噪声幅度、mixup 概率、温度系数。
- 过滤阈值：置信度上下限、保留样本数。
- 基线对比：教师模型、学生基线的准确率和关键损失。
这些记录能保证一次实验结束后，你能还原出数据为什么变好或变差。
7.2 从离线蒸馏到生成反馈闭环
在实际数据科学项目里，从点击归因到预算优化通常是一个持续闭环：采集数据、归因分析、训练模型、评估效果，再把新的反馈数据回流到模型。蒸馏数据生成也可以设计成同样的闭环。PROOF-Gen 在第一次运行时可以是离线流程，但后续每次学生模型上线后，都可以把预测置信度较低的样本收集起来，重新进入生成和过滤流程。
这意味着在架构上，数据生成不能只写成一次性脚本，最好把样本池、过滤结果和评估指标都外部化存储。这样，后续迭代就可以复用历史样本，而不是每次从头生成。
7.3 生产环境扩展方向
小数据集跑通后，进入生产环境还需要考虑四件事：
- 使用样本库缓存，避免每次训练重新生成候选样本。
- 将生成任务拆成独立分布式任务，保存到对象存储或特征平台。
- 加入模型版本管理和数据版本管理，方便回滚。
- 上线前检查学生模型在长尾类别和敏感样本上的表现，不只关注整体准确率。
如果项目涉及大量文本或语音数据，生成策略要从图像扰动换成对应模态的增强方法，但诊断、过滤、合并的基本逻辑可以保留。
蒸馏优化的第一步不是调参数，而是把数据过程透明化。先用一张小数据集把 PROOF-Gen 的生成、过滤、训练、验证链路跑通，再回到自己的业务数据里观察教师模型在哪些样本上不稳定。只要数据版本、生成参数和评估基线都留得清楚，后续调整就是有针对性的，而不是凭感觉。对于刚接触蒸馏的读者，建议从教师模型输出的软标签分布入手，这批 soft label 本身就是整个蒸馏流程里最值得利用的信息。
