GPT-1复现翻车实录：数据集陷阱与灾难性遗忘

训练翻车：损失曲线突然飙升

团队用BookCorpus加上自己收集的尼日利亚语料库（9ja-bookcorpus）合并训练，规模约1.1亿参数，试图尽可能复现GPT-1。头几千步一切正常：损失从接近11一路降到3.6左右。然后，在约500步之内，损失翻倍飙升回7以上，之后再也没降下来。整轮训练后期，损失曲线变成一条平线，一动不动。

这就是灾难性遗忘：模型在训练中途，非但没有巩固已学知识，反而把学过的内容丢掉了。

如果不太熟悉损失值的含义，可以这么理解：损失大致衡量模型对句子中下一个词的“惊讶程度”。损失高，说明模型猜得差，输出文本混乱、重复或跑题。损失低，模型猜测更精准，生成的文字更流畅。从11降到3.6，意味着模型明显学会了写正常句子。但损失突然飙升，不只是图表上的数字变化——模型的输出质量也确实退回了最初的混乱状态，且再没有恢复。

排查过程：谁搞砸了模型？

两个数据集合并，最直接的问题是：到底是哪个数据集搞砸了？原因是什么？团队查看了本地训练日志，列出几个嫌疑点：

a) 数据质量问题
b) 两个数据集没有充分混洗
c) 数据集之间存在某种冲突，或者某个数据集中隐藏着真正的脏数据

为了找到真正原因，他们做了消融实验——这个术语源自医学和科研，意思是故意移除或隔离系统中的某个部分，看它是否是导致问题的根源。一次只动一个变量，而不是瞎猜整体。

每次都用完整1.1亿参数模型跑会又慢又贵，所以团队将模型缩小到约3000万参数，架构不变，只是减少层数、注意力头数和嵌入维度。跑得更快更便宜。

但这带来了新麻烦：所有训练都跑在谷歌Colab（Google Colab）上，Colab会频繁崩溃——要么内存不足，要么连接中断导致整个会话丢失。第一次尝试单独隔离尼日利亚语料库时，还没开始就跑内存出错了。记住，这个过程里很多挫折都不是模型问题，而是基础设施在拖后腿。

正确隔离数据集之后，问题清楚了：根子在BookCorpus。缩小模型用合并数据重训，损失卡在3.9-4.0的狭窄区间，跑了数万步毫无改善。这次没有突然飙升，只是一条拒绝下降的平线——无论跑多久，模型输出质量都定格在一个水平上。团队用的那个BookCorpus版本确实有问题。

我的任务：调查BookCorpus并寻找替代

我加入后第一件事不是碰模型，而是仔细审视BookCorpus这个数据集本身：到底烂在哪里？有什么替代品可以替换或补充？

BookCorpus虽然催生了GPT-1，但已知问题不止我们遇到的这一个。一篇2021年的数据审计报告指出，它约7185本书中，超过2900本出现了不止一次（有的重复了5次），还有几十个空文件和数百本被截断的书。而且它本身就偏窄：未出版的小说为主，从Smashwords网站爬取（未经作者同意），风格偏向英语文学的一种类型。拿它作为模型的基础数据——尤其是想要理解尼日利亚语境的模型——本身就摇摇欲坠。再加上我们消融实验的发现，弃用它或至少大幅补充它的理由就更充分了。

我去寻找能真正替代它的数据集，找到了FineWeb-Edu——一个Hugging Face上的数据集，通过过滤Common Crawl网页数据，只保留教育质量高的内容。背后的团队用LLM（LLaMA3-70B-Instruct）给数十万网页的教育价值打分（0-5分），然后用这些分数训练一个分类器，再用分类器过滤整个网络数据集。把质量门槛设为3分（满分5分），丢掉了约92%的原始数据，保留1.3万亿token，刻意偏向中小学水平写作，所以不只是偏向技术文章。

不是说我们已经用上了它——迁移到这么大的数据量计算量不小。但我认为这是未来的方向：基础数据应该来自有目的的质量过滤，而不是因为从网上爬取未出版小说很容易。

下一步

目前有两件事在清单上。第一，用同样严格的标准审查9ja-bookcorpus（它目前只有约1300万token，连缩小版3000万参数的模型都不够）。来自“Chinchilla”缩放定律（DeepMind在GPT-1之后发布）的经验法则是：高效训练时，总训练token数大约是参数量的20倍。对3000万参数的模型，大约需要6亿token——离我们还有很远。

第二，实际测试一下：用更干净的数据替换BookCorpus，是否真的能修复模型。

第三，我们准备迁移出谷歌Colab。因为内存崩溃或断连导致训练跑废的事情，一次两次可以，特别是一个run要跑好几个小时。下一轮训练我们计划用RunPod——这样训练就不会因为浏览器标签页关了而前功尽弃。

这些就是Part 2的内容。