freebird2913

起点只有 8,705 条#

训练走的是 MiniMind 那套代码，这也是后面格式和 tokenizer 都得迁就它的原因。本来以为得从头建目录、写脚本，翻开 training_data/ 才发现里面已经有个采集脚本 collect_training_data.py，还有份来自单个仓库的早期数据 gpt_load_code.jsonl，8,705 条。所以真正要做的，是把这个能跑通的小脚本扩成一条撑得住大规模采集的管道。

动手前给自己划了几条线。仓库代码一行都不执行——采集器只读 Git 对象，不 checkout、不装依赖、不跑构建脚本，我可不想在自己机器上跑一百多个陌生仓库的 setup.py。依赖能少就少，Python 标准库加 Git 就够，爬虫框架和 GitHub API 都不要，省得操心限流和 token。另外两条更硬：每条样本都要能倒查到仓库、commit、文件路径和分块编号，缺一个不算合格；输出直接是 MiniMind PretrainDataset 要的 {"text": "..."}，不做二次转换。

这后两条基本把产物定死了：一份训练文件，一份溯源侧车。

80 万条是怎么堆出来的#

数据按语言拆开存，哪门语言不对劲可以单独查、单独补、单独调采样比例。训练用的是跨数据集去重后的单文件版本。

打包后的训练入口：

上表加起来是 803,008，这里却只有 802,952。差的 56 条不是算错，是合并阶段抓出来的跨文件重复，后面细说。

采集器只读 Git 对象#

主干逻辑不复杂：

1
浅拉取指定 commit（git fetch --depth=1）
2
  → git ls-tree 列出所有 blob
3
  → 按扩展名、目录与生成文件规则过滤
4
  → git cat-file --batch 批量读取内容
5
  → UTF-8 解码（拒绝二进制）
6
  → 按行边界切为不超过 2048 字符的块
7
  → 基于内容 SHA-256 去重
8
  → 写入 {"text": ...} 与溯源侧车

复杂的地方在三个细节。

一是用 git cat-file --batch，别逐文件 git show。一个仓库几千个候选文件，每个起一次 git show，进程创建和 Git 初始化的开销很快压过真正的读取。我第一次拿大仓库试的时候，进度条几乎不动、CPU 却也不忙，盯着看了一会儿才反应过来时间花在哪了。--batch 是批量协议：往同一个 Git 进程里连续写 blob 标识、连续读回内容，整个仓库压缩成一个子进程。

二是分块尽量切在行边界。每块上限 2,048 字符，按字符位置硬截最省事，但会把语句、字符串字面量、注释拦腰切断。代码的可读性全靠换行，所以优先在行边界切。函数中间被切开是免不了的，至少行内结构还在，样本看起来还像段真实的代码。

三是按内容哈希去重，路径不算身份。示例、vendor、模板、拷贝出来的代码，同一份东西出现在不同路径下太常见了。每个分块算一遍 SHA-256 当去重键，路径、仓库、commit 留在侧车里当来源信息。

七个坑#

按踩到的顺序写。

1
DEFAULT_EXTENSIONS = {
2
    '.py', '.js', '.ts', '.java', '.c', '.cpp', '.go', '.rs',
3
    # 没有 .md
4
}

1
python train_pretrain.py `
2
  --data_path "../../training_data/coding/data/*_code.jsonl"

1
code_pretrain.jsonl

1
def metadata_path(output):
2
    return output.with_suffix('.meta.jsonl')

1
def metadata_path(output, meta_dir=None):
2
    if meta_dir is None:
3
        return output.with_suffix('.meta.jsonl')
4
    return Path(meta_dir) / f'{output.stem}.meta.jsonl'

写完不等于写对#

采集器打印”成功写入 5,000 条”，只证明它写了文件。JSON 合不合法、哈希对不对、文本重没重复、末行截没截断、来源字段全不全，一概不知。

所以每轮采完我单独跑一个校验脚本，而且刻意不复用采集器的内部逻辑——同一个 bug 既当生产者又当质检员，出事太容易了。

15 份数据集都过了。然后在打包阶段再做一次跨数据集全局去重，JavaScript、Java、C/C++、C#、Go、Rust、PHP、Kotlin、Swift 和学习资料之间一共撞了 56 条。56 条，占 0.007%，小得可以假装没看见。但文件内去重和数据集级去重是两回事——直接 cat 拼起来，它们就一声不响地进了训练集。

2048 是怎么量出来的#

采集器管的是字符数（--max-chars 2048），训练管的是 token 数（--max_seq_len）。两者之间没有固定汇率，语言之间差别还很大。

我用 MiniMind 的 ByteLevel BPE tokenizer（词表 6,400）把每份数据集的分布量了一遍。为了不额外装依赖，编码流程用纯 Python 写，15 份数据集各随机抽 700 条做 encode → decode 往返，结果是 0 处不一致。

数字摊开，想装没看见都难。C# 密度最高，2.66 个字符换 1 个 token；Go 最低，只有 1.87——同样 2,048 个字符，C# 里约 770 token，Go 里要 1,095。768 那列最惨，代码数据集的截断率全落在 35% 到 88% 之间，照抄通用文本示例里的长度，等于亲手扔掉大段上下文。2048 那列全是 0.0%，只有 Markdown 是 4.1%，散文密度低、篇幅长，倒也符合直觉。

所以合适的最大长度没法从示例参数里继承，只能拿 tokenizer 和真实数据一起量。

目录、训练、复现#

训练数据、侧车、许可证按职责分开：

1
training_data/
2
├── coding/
3
│   ├── data/          # 15 份分语言数据 + 1 份全量打包文件
4
│   ├── meta/          # 15 份溯源侧车 + 1 份打包清单
5
│   └── licenses/      # 按仓库去重后的许可证全文
6
├── chat_data/         # CodeX / ZCode 导出的对话 SFT 数据
7
├── officals/          # 官方示例预训练数据
8
└── scripts/           # 采集器、导出器与测试

推荐用单文件训练，这样跨数据集去重才是有效的：

1
python train_pretrain.py `
2
  --data_path "../../training_data/coding/data/code_pretrain.jsonl" `
3
  --max_seq_len 2048

也可以按语言分开加载：

1
python train_pretrain.py `
2
  --data_path "../../training_data/coding/data/*_code.jsonl" `
3
  --max_seq_len 2048

提醒一句：首次加载时 HuggingFace datasets 会在缓存目录生成 Arrow 缓存，大概要额外留 1.5–2 GB 磁盘。

想自己跑一遍的话，采 TypeScript 仓库、侧车写进独立目录：

1
python training_data/scripts/collect_training_data.py `
2
  --repo vuejs/core --repo nestjs/nest `
3
  --extensions .ts,.tsx --max-samples 10000 `
4
  --output training_data/coding/data/ts_code.jsonl `
5
  --meta-dir training_data/coding/meta --append

测试：

1
cd training_data
2
python -m unittest discover -s scripts/tests -v

全部参数 python scripts/collect_training_data.py --help。仓库清单、每份数据集的统计、许可证为空的说明，都在 training_data/scripts/README.md 里。

一些零碎#

跑完这轮，有几件事确实记住了，随手记下。

最费人的从来不是采集，是解释异常：meta 为什么 648 MB、许可证为什么空着、数据看着完整却追加不了、某门语言为什么老被截断。没有独立验证的采集，本质上是产出了一个还没被信任的文件。

默认参数也最会装没事。--max-samples 的全局语义、扩展名白名单里没有 .md、示例里的 max_seq_len 768，三个默认值捅了三类篓子。管道这东西，读实现和读测试，比读使用文档靠谱。

许可证那课我交了三次学费：一个字段是每样本属性还是每仓库属性，动手前先想想它的基数。8,705 条时多几 MB 无所谓，到 803,008 条就是几个 GB。

还有一条有点反直觉：--meta-dir 的修复里，“漏传会明确失败”和”传对能跑通”一样要测。数据工程里最危险的 bug 很少崩，它们只是安静地写出错的东西。

从 8,705 条到 803,008 条，翻了九十二倍。至于那七个坑——它们的价值大概是让我下次别再踩。也可能只是换个姿势再踩一次。