数据管线

数据管线负责把原始数据转换为可训练、可评测、可追溯的数据集。它不是简单的下载和清洗脚本，而是一组有版本、有质量门禁、有血缘记录的离线与在线处理步骤。数据管线的目标是让每个训练样本都能回答三个问题：来自哪里、经过了什么处理、为什么进入当前数据集。

快速开始¶

先为每个数据源建立不可变的 manifest，再按下面的顺序处理：

数据源登记
    -> 抓取与解析
    -> 规范化与质量过滤
    -> 去重与污染检查
    -> 隐私、版权与安全检查
    -> 混合采样与切分
    -> Tokenizer 编码与打包
    -> 分片、打乱与加载
    -> 评测、发布与血缘记录

最小可复现流程不应直接覆盖原始文件。保留原始快照，为每个中间结果记录输入版本、处理代码版本、配置、样本数量和内容哈希；训练配置只引用最终数据集版本，不引用会变化的「latest」。

数据源与 manifest¶

数据源可以是网页、书籍、代码、对话、领域文档或人工标注数据。登记数据源时至少记录来源地址、抓取时间、许可证、允许用途、语言或领域、原始文件哈希和处理责任人。对于会持续更新的数据源，还要记录 revision 或快照标识，避免同一个名称在不同时间解析出不同内容。

一个简化的 manifest 如下：

dataset: domain-corpus
version: 2026-08-18
sources:
  - name: public-docs
    revision: "commit-or-snapshot-id"
    license: CC-BY-4.0
    sha256: "..."
processing:
  code_revision: "pipeline-commit-id"
  config_revision: "config-version"
  tokenizer: "tokenizer-revision"
output:
  format: parquet
  shards: 128
  sample_count: 0

manifest 是数据发布的入口，不应把密钥、个人联系方式或未脱敏的原始内容写入其中。大文件的详细清单可以单独存储，但 manifest 必须能定位到它。

解析与规范化¶

不同来源先统一为内部记录格式，例如 document_id、source_id、text、language、timestamp、license 和 metadata。解析阶段要区分正文、标题、代码、表格、导航和模板内容，不能把网页菜单或重复页脚当成训练语料。

规范化包括 Unicode 归一化、空白和换行处理、语言识别、编码转换、HTML 或 Markdown 结构解析，以及异常字符处理。规范化规则必须可配置；过度清洗会删除代码缩进、数学公式、表格结构和少数语言信息。对同一来源应保留规则前后的计数，便于解释样本数量变化。

质量过滤¶

质量过滤通常由多层规则组成：

不要用单一困惑度阈值替代质量判断。过滤前后应按来源、语言、领域和长度分组统计保留率；如果某个小语种或专业领域的保留率异常低，应先检查规则偏差，再决定是否调整阈值。

去重与数据污染¶

去重至少分为三层：完全相同的文本使用哈希去重；近似重复文本使用 MinHash、SimHash 或 shingling 等方法；语义重复则根据任务成本选择向量相似度或人工抽样。去重键应保留来源和样本 ID，不能只留下最终文本，否则无法解释哪一条记录被删除。

训练集、验证集和测试集必须在去重后切分，避免同一文档的不同片段跨集合泄漏。对公开评测集、基准答案和测试代码建立污染清单，在训练前做精确匹配、近似匹配和时间切分检查。污染检查的结果应进入发布报告，即使结果是「未发现匹配」。

混合、采样与切分¶

多来源数据需要定义混合策略。最简单的是按样本数比例采样；当某个大语料会压制高价值领域时，可以使用上限、温度采样、领域权重或分阶段 curriculum。配置中应同时记录原始比例和实际采样比例，因为过采样会改变有效训练分布。

切分时优先按文档、用户、时间或来源分组，而不是随机切分单条文本。这样可以减少同一作者、同一会话或同一版本文档泄漏到验证集。验证集应尽量保持稳定，测试集则需要限制访问并记录评测版本。

Tokenizer、打包与分片¶

训练前使用固定版本的 Tokenizer 编码，并记录词表、特殊 token、截断长度和添加的分隔符。对对话数据明确 system、user、assistant 和 tool 消息的边界；对代码、表格和多模态占位符保留必要结构。Tokenizer 变更会改变 token 数量、样本长度分布和训练成本，因此不能只修改名称而不重新发布数据版本。

将 token 序列打包为固定或近似固定长度的样本时，要明确是否跨文档拼接、是否插入 EOS，以及 loss mask 如何处理 padding、提示词和无监督目标。打包后的样本应能反向定位到原始 document_id，至少在审计抽样时能够恢复来源。

数据分片应兼顾顺序读取、并行加载和断点恢复。大规模训练通常把分片清单、样本数量和内容哈希写入发布 manifest，训练进程再按照 rank、worker 和 epoch 做确定性分配。存储布局可参考 数据集存储；如果涉及模型权重与数据下载，还应固定 Hugging Face 的 revision。

质量门禁与发布¶

发布前至少检查以下指标：样本数和 token 数、各来源保留率、语言和领域分布、长度分布、重复率、污染匹配数、隐私与版权处理结果，以及随机抽样的可读性。每项指标都应和上一版本比较，异常变化必须有原因记录。

发布采用不可变版本。建议把原始快照、中间产物、最终分片、manifest、处理日志和评估报告分开保存；新版本通过新目录或新对象前缀发布，完成全部校验后再更新指针。训练作业只读取固定版本，这样失败重跑和结果对比才有意义。

案例：领域继续预训练数据¶

假设要为一个基础模型构建法律领域语料。先登记公开法规、判决书和经过授权的内部文档，分别保存来源和许可证；解析时保留条款编号、标题层级和引用关系；随后进行脱敏、重复文档合并、跨版本时间切分，并把法规正文与解释性材料设置不同采样权重。

发布前抽样检查条款是否被截断、引用是否跨分片丢失、个人信息是否残留，并将最终 token 数与训练预算对齐。若后续补充新版本法规，不覆盖旧数据，而是发布新 manifest，记录新增、删除和变更的文档 ID。这样训练结果出现变化时，可以判断变化来自数据内容、采样策略还是训练代码。

相关主题¶

• 模型架构
• 模型训练
• 模型评估
• 数据集存储