企业官网建设流程全解析

• 数据集
• NLP
• 机器学习

你是否想给一个已发布的大数据集"加料"，却又怕一动就毁掉已有的 250 多万行训练数据？开源数据集 tasksource-jev-typed-decisions 最近就完成了一次教科书级的操作：把 WebInstruct 的 mc（多选）和 binary（二分类）数据以独立分片的形式追加进已有数据集，而所有旧分片一个字节都没动。本文带你完整复盘这次增量扩展的做法、原理和可复用的经验。

1. 先搞懂两个概念：数据集分片与增量扩展

🧩 在 Hugging Face 这类数据平台上，数据集通常不是一整个大文件，而是切成很多parquet 分片（shard），比如：

• 训练集：data/train-00000-of-00005.parquet~train-00004-of-00005.parquet
• 验证集与测试集各 1 个分片
• full配置（全量 2.5M+ 行）则用full/train-00000-of-00013.parquet等 13 个分片

增量扩展（incremental addition），指在不重构、不重排旧数据的前提下，把新来源的数据"贴"上去。它和"推倒重跑全量构建"是两回事：后者会打乱所有行的顺序与分片编号，所有用户都要重新下载；前者则像给书架加一层新书，旧书一本不动。

💡 对新手来说，判断一个仓库是否值得长期依赖，一个重要信号就是：它敢不敢把每一次增量都做成"只加不改"。

2. 为什么不能直接修改旧分片？

直接改写旧 parquet 文件看似省事，但会踩三个坑：

tasksource 项目的选择是第三种思路：新增数据一律写入独立的新分片，旧分片原样保留，并用校验和（sha256）证明它们没被动过。这正是 Hugging Face 数据分片机制天然支持的模式——配置（config）的data_files指向通配模式data/train-*，新增一个匹配该模式的文件，加载器就会自动把它并入同一个 split。

3. 案例背景：WebInstruct 的 mc 与 binary 数据要进来了

这次追加的数据来自上游tasksource/webinstruct，锁定了具体 revision05e8b528d68c628c1af682d47bdb53f85535876a（锁定版本意味着：以后上游怎么改，这次追加都可复现）。只取了两个配置：

• mc：多选（multiple choice）题
• binary：是/否二分类题

数据最终去向是两个配置：default（约 100 万行精选混合）与full（全部构建行，250 万+）。两边的追加内容完全一致，验证集则明确不动。

📌 本次追加的所有账目都记录在 webinstruct-addition.json 中，这是复盘最值得读的"案卷"。

4. 追加流程拆解：6 步完成 28562 行增量

第 1 步：锁定来源版本

源数据集和父数据集各自固定到 commit 级别的 revision（见 webinstruct-addition.json 顶部的source_revision与parent_revision）。这是"可复现"的地基。

第 2 步：统一 schema，做确定性变换

tasksource 的每一行都是一个"决策（decision）"：state（文本）+question（要判断什么）+options+target。WebInstruct 的行要先被改写成这个统一格式，变换规则在 webinstruct-addition.json 的transformations字段里逐条写明了：

• 原始 prompt 转为state；源数据的 train/test 划分原样保留，不新造验证集；
• mc 行保留全部选项，套用标准的确定性 Jev 选项重排（per-row permutation），gold 标签同步重映射成 one-hottarget；
• 位置敏感的选项（如"A 和 B 都对"）保持原顺序；结尾的 "all/none of the above" 选项由标准 Jev 工具归一化；
• binary 题使用显式的no/false与yes/true两个选项，配合 one-hot target；
• 只保留"直接行（direct rows）"，带稳定的源行 group ID 和基于内容哈希的example_id；
• 不包含任何"修复后"或"未过滤"的样例——宁可少，不可脏。

第 3 步：按既有契约做过滤，并留下"排除清单"

mc 数据中有47 行因为"选项文本为空或重复"违反了 Jev 选择契约（choice contract）而被剔除。关键在于：这 47 行不是静默丢弃，而是逐条记录了 ID 和原因（webinstruct-addition.json 的excluded列表，如webinstruct-mc-df907c7ba0:train:239294）。

🔍 这是很多项目做不到的：排除的每一行都可追溯、可申诉、可复核。

第 4 步：写入独立新分片

新数据没有混进任何旧文件，而是生成了独立分片，例如：

• data/train-webinstruct-05e8b528d68c.parquet
• data/test-webinstruct-05e8b528d68c.parquet
• full/train-webinstruct-05e8b528d68c.parquet
• full/test-webinstruct-05e8b528d68c.parquet

文件名里的05e8b528d68c就是源数据集 revision 的前 12 位，一眼看出这批分片的血统。由于文件名匹配data/train-*通配模式，load_dataset会自动把它们并入对应 split——配置代码一行都不用改。

第 5 步：精确记账

webinstruct-addition.json 给出的最终账目：

同时还记录了每个新分片的字节数与 sha256，以及全部 21 个"必须保持原样"的旧分片清单（preserved_parquets），逐一带哈希值。

第 6 步：验证"旧物未动、新物正确"

验证环节回答了增量发布最关键的三个问题：

1. 旧分片还在吗？—— 校验现有 parquet 分片全部保留；
2. 新分片完整吗？—— 新写入的 6 个分片逐一核对 sha256；
3. 各配置行数对得上吗？—— 追加后default/train为 1,031,657 行、full/train为 2,529,342 行、validation保持 15,550 行不变、filtered-full保持 1,305,072 行不受影响。

5. 这套方法的可复用要点

把这次复盘提炼成清单，适用于任何"已发布数据集要扩数据"的场景：

• ✅只追加，不改写：新数据进新分片，旧分片字节级不变，用哈希证明；
• ✅锁定双端版本：父数据集 revision + 源数据集 revision，写进 manifest；
• ✅变换规则显式化：每一条 prompt→state、选项重排、标签归一化的规则都写在账本里；
• ✅排除项留痕：被过滤的每一行都有 ID 和原因，而不是一个"过滤掉了 N 行"的总数；
• ✅验证集不动：评测基准的稳定性优先于数据量增长；
• ✅混合策略不改：新增行不会触发已有 mixture 重采样，训练配方保持稳定；
• ✅同批双配置：default和full得到相同的新增内容，避免两个配置数据漂移。

这个模式在仓库里不是孤例。同一批"增量批"（addition batch）还有几份可对照的账本，每份都带manifest.json（计数、sha256、父 revision）：

• additions/167c5ad6fb79/ —— WebLINX / WebSRC 等浏览器任务批次，含 verification.json（验证"91 个既有分片全部保留"）与 rows.json（逐行溯源）
• additions/2d27d40ae2fe/manifest.json —— SEntFiN、WANDS、SciRepEval 批次
• additions/b3e70284a0c4/manifest.json —— 法律、生物医学与结构化文本批次
• additions/aebc640a1ba7/manifest.json 与 additions/b221677e3faf/manifest.json —— 对话证据类与立场/论辩类批次

对照阅读这些 manifest，你会发现同一套"分片追加 + 哈希锁定 + 排除留痕"的模板被反复执行——这正是一个数据集能持续生长而不腐坏的核心机制。

6. 小结

这次 WebInstruct mc/binary 追加用 28,562 行新数据证明了一件事：数据集增量扩展不必以"破坏旧分片"为代价。锁定版本、独立分片、显式变换清单、逐行排除账本、哈希验证五件套齐上，老用户零重下载，新用户直接受益，审计者处处可查。如果你也在维护一个公开数据集，这套 webinstruct-addition.json 式的"增量账本"值得直接抄作业。

• 数据集
• NLP
• 机器学习