一、本次成果

1）使用优化后的脚本进行模型全规模训练

2）发现并解决了训练数据加载的稳定性问题

3）group_by_length 的尝试与回退

4）加入早停机制

二、全规模训练

全规模训练是应用数据集中的所有训练集数据进行训练并在验证集上验证，成效良好

训练集数据(音频）共两万条以上，保证模型的准确性

3轮总耗时1小时10分，时间较长，若须快速获得模型可降低训练轮次或进行中规模训练

训练结果取第一轮以及3轮后最终在验证集上的指标，如下：

{'eval_loss': 0.02347954548895359, 'eval_accuracy': 0.998389953308646, 'eval_f1': 0.9991028568991387, 'eval_precision_spoof': 0.9992373261551817, 'eval_recall_spoof': 0.998968424829521, 'eval_f1_spoof': 0.9991028568991387, 'eval_precision_bonafide': 0.9909945184021178, 'eval_recall_bonafide': 0.9933281004705677, 'eval_f1_bonafide': 0.9921599367791099, 'eval_cm_tp': 22273, 'eval_cm_tn': 2531, 'eval_cm_fp': 17, 'eval_cm_fn': 23, 'eval_pred_spoof_count': 22290, 'eval_pred_bonafide_count': 2554, 'eval_true_spoof_count': 22296, 'eval_true_bonafide_count': 2548, 'eval_decision_threshold': 0.5, 'eval_runtime': 391.2099, 'eval_samples_per_second': 63.506, 'eval_steps_per_second': 7.939, 'epoch': 1.0}

final train result: TrainOutput(global_step=9519, training_loss=0.04454359405558029, metrics={'train_runtime': 4947.733, 'train_samples_per_second': 15.389, 'train_steps_per_second': 1.924, 'total_flos': 2.749328578004501e+18, 'train_loss': 0.04454359405558029, 'epoch': 3.0})
final eval metrics: {'eval_loss': 0.008619075641036034, 'eval_accuracy': 0.9994364836580261, 'eval_f1': 0.9996860277574118, 'eval_precision_spoof': 0.9997308692921414, 'eval_recall_spoof': 0.9996411912450215, 'eval_f1_spoof': 0.9996860277574118, 'eval_precision_bonafide': 0.9968627450976483, 'eval_recall_bonafide': 0.9976452119305347, 'eval_f1_bonafide': 0.9972538245290321, 'eval_cm_tp': 22288, 'eval_cm_tn': 2542, 'eval_cm_fp': 6, 'eval_cm_fn': 8, 'eval_pred_spoof_count': 22294, 'eval_pred_bonafide_count': 2550, 'eval_true_spoof_count': 22296, 'eval_true_bonafide_count': 2548, 'eval_decision_threshold': 0.5, 'eval_runtime': 383.675, 'eval_samples_per_second': 64.753, 'eval_steps_per_second': 8.095, 'epoch': 3.0}

三、训练数据加载的稳定性问题

在跑全规模训练时，我遇到过一次比较典型的数据加载报错。
一开始 num_workers 设得比较大，在 Windows 环境下更容易出现 worker 子进程出错。

后来我测试后发现：

• num_workers=8 会报错
• num_workers=2 可以正常运行

这是因为在 Windows 上跑大规模语音数据时，DataLoader 多进程更容易出这种问题，尤其是：

• 音频长度不一致
• batch 里需要 padding
• worker 多了以后，内存碎片/临时数组开销变大
• Windows 的多进程本来就比 Linux 更不稳定

所以最后我把训练命令里的 num_workers 调整为 2，兼顾了稳定性和效率。

这也提醒我，语音训练中数据加载参数并不是越大越好，实际还要看：

• 操作系统
• 数据规模
• 音频长度分布
• 内存情况

四、group_by_length 的尝试与回退

我尝试开启了 group_by_length=True，希望通过按音频长度分组来减少 padding、提升训练效率。

group_by_length 的作用是：

• 把长度相近的样本放进同一个 batch
• 减少 padding
• 提高训练效率
• 节省显存

但在我的项目里出现了问题：

由于我当前使用的是自定义的 Dataset，而 Trainer 的长度分组机制更偏向 Hugging Face 默认的数据格式，所以开启后出现了兼容性报错。

最终我把它关闭，回到了：

• group_by_length=False

这是一个比较务实的选择，对于当前这个项目，稳定性比这个优化更重要。

---

五、早停机制的加入

为了避免训练在验证集不再提升后继续浪费时间，我给训练脚本加入了早停机制：

• EarlyStoppingCallback
• 可配置 early_stopping_patience（在验证集上不再提高的次数）
• 可配置 early_stopping_threshold

这样一来，如果验证指标连续多次没有提升，训练就会自动停止。

这对全规模训练尤其有用，因为全规模训练耗时更长，早停可以：

• 节省时间
• 避免无效 epoch
• 减少过拟合

---

六、总结

本次进行优化后的全规模训练，并发现和解决了过多线程同时运行时的不稳定性。同时尝试对训练脚本进行试错和再优化，使训练模型更具效率与精准。接下来我会不断优化并更新音频检测模型，供给项目组使用。