OriginBlame：面向AI训练数据集的记录级与令牌级数据溯源系统

# OriginBlame：针对AI训练数据集的记录级和标记级数据溯源
来源：https://arxiv.org/html/2607.13037

###### 摘要

当数据贡献者请求删除时，模型训练者面临一个实际缺口：反学习算法需要一个遗忘集，但没有任何工具能够定位哪些训练记录属于特定作者。现有溯源系统仅在文件或数据集级别操作，导致灾难性的过度删除。我们提出ob，一个记录级和标记级的数据溯源系统，通过数据处理流水线传播作者身份，并通过确定性查询将撤销请求解析为精确的遗忘集。在219,555个维基百科页面上的评估表明，记录级溯源消除了数据集级别的过度删除（从101倍降至1.3倍），而在维基数据上，集成带来的吞吐开销为1.3–4.0%（HuggingFace）和2.1–19.0%（Datatrove）。在1.7B模型上，基于溯源的遗忘集相比随机基线将反学习效果提升了42%。

# OriginBlame：针对AI训练数据集的记录级和标记级数据溯源

Haolin Xue
[email protected]

## 1 引言

当数据贡献者请求删除时，模型训练者必须识别并从训练集中移除该贡献者的数据。机器反学习方法如负偏好优化（NPO）[Zhang et al. (2024)](https://arxiv.org/html/2607.13037#bib.bib15) 和用于反学习的表示误导（RMU）[Li et al. (2024)](https://arxiv.org/html/2607.13037#bib.bib16) 可以在提供遗忘集后削弱特定数据的影响，但所有现有研究都假设这个遗忘集是已知的。实践中，训练数据集通过数据处理、分词和打包从数千个来源组装而成；当数据集到达训练者手中时，单个训练行与其原始贡献者之间的联系已经丢失。没有细粒度溯源，唯一的选项是灾难性的过度删除（丢弃整个数据集）或事后不精确的推断 [D’Angelo et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib5)。遗忘集的质量直接决定了反学习的效果。诸如 TOFU [Maini et al. (2024)](https://arxiv.org/html/2607.13037#bib.bib2) 和 MUSE [Shi et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib1) 的基准测试在合成策划的遗忘集上评估反学习算法，但如果没有一种机制能够在训练粒度上定位受影响的数据，这些结果无法转化为实际合规。图1 (https://arxiv.org/html/2607.13037#S1.F1) 说明了知道“遗忘谁”与知道“遗忘哪些数据”之间的差距。

![参见说明文字](图1：反学习流水线缺口。现有方法假设预定义的遗忘集，但定位受影响的数据仍未解决。OriginBlame 填补了这一缺口。)

如表1 (https://arxiv.org/html/2607.13037#S1.T1) 所示，数据版本控制工具（DVC [Iterative (2024)](https://arxiv.org/html/2607.13037#bib.bib10)，LakeFS [Treeverse (2024)](https://arxiv.org/html/2607.13037#bib.bib13)，Delta Lake [The Linux Foundation (2024)](https://arxiv.org/html/2607.13037#bib.bib14)）在文件或数据集级别操作。实验管理工具（MLflow [Databricks (2024)](https://arxiv.org/html/2607.13037#bib.bib11)，Weights & Biases [Weights & Biases (2024)](https://arxiv.org/html/2607.13037#bib.bib12)）跟踪元数据但不跟踪数据来源。诸如 yProv4ML [Padovani et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib6) 的溯源工具捕获数据集级别的关系，而 DLProv [Pina et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib8) 需要大量植入。没有任何工具提供带有作者归属的记录级溯源。OriginBlame (ob) 通过三层架构（图2 (https://arxiv.org/html/2607.13037#S4.F2)）并带有一个独立的标记索引层，跟踪哪些训练记录来自哪些源段以及哪些作者贡献了这些段。用户每个记录只需调用一次 `ob.track()` 即可集成。ob 在记录级和标记级都提供精确的遗忘集。我们强调，ob 并不发现作者身份；它*传播*作者身份。ob 适用于数据收集流水线，其中作者身份已由源环境确定——例如 MediaWiki 修订历史或 GitHub 提交——但这种归属在分词和打包过程中*丢失*。ob 跨这些转换保留溯源链，使得下游查询（例如，“查找来自作者 ai 的所有训练行”）成为可能，否则这些查询需要事后推断。

**表1：溯源工具比较**

本文做出三项贡献。首先，我们设计了一个三层内容寻址架构（作者 ← 段 ← 文档索引），无需 ML 或 GPU 依赖。其次，我们表明该架构通过确定性查询将作者撤销请求解析为精确的遗忘集，并证明记录级溯源消除了文件级工具所造成的数据集级别过度删除。第三，我们引入一个独立的标记索引层，在分词和打包过程中记录来源归属，将遗忘集生成扩展到标记粒度，而无需文档索引记录。

## 2 问题形式化

D’Angelo 等人 [D’Angelo et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib5) 形式化了遗忘集识别（ForSId）问题：给定训练集 D、模型 M_D、不想要集 D_u 和想要集 D_w，找到一个遗忘集 D_f ⊆ D，其移除能在最大程度上保持模型在 D_w 上的行为，同时改变其在 D_u 上的行为。ForSId 需要模型访问来计算每个样本的影响力（通过训练数据梯度）。更根本的是，它的输入是*行为*证据——其预测应该改变的样本——而不是元数据级别的查询，例如“遗忘作者 ai 的所有数据”。当作者 ai 发起撤回请求时，目标遗忘集是 F = { l ∈ D | author(l) = ai }。在没有模型访问的情况下精确计算 F 是 ob 解决的挑战。数据集级别溯源只能回答“作者 ai 的数据存在于 D 中”，迫使两个极端：删除整个数据集或不采取任何行动。行级别溯源通过回答“作者 ai 贡献了 n 行”来解决这个问题，从而实现有针对性的删除——正如我们在第5.2节 (https://arxiv.org/html/2607.13037#S5.SS2) 所示，记录级撤销相比数据集级方法减少了高达 101 倍的过度删除。

从这个缺口出发，我们推导出三个设计要求。
* **精度**：定位特定的数据行，而不是文件或数据集。
* **可验证性**：溯源必须是独立可审计的，而不仅仅是内部存储。
* **最小侵入性**：集成必须只需要几行代码——DLProv [Pina et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib8) 是一个警示性例子，尽管运行时开销低，但需要大量的脚本植入。

## 3 相关工作

如表1 (https://arxiv.org/html/2607.13037#S1.T1) 所示，现有溯源工具停留在文件或数据集粒度。Chen 等人 [Chen et al. (2026)](https://arxiv.org/html/2607.13037#bib.bib7) 提出了带有贡献分数的细粒度样本级可追溯性，跨越 ML 流水线，但侧重于训练阶段的数据使用审计，而不是作者身份归属。OriginBlame 与 DVC 和 HuggingFace Datasets 等工具共存：DVC 管理文件版本，而 ob 管理记录级作者溯源。

机器反学习研究同样假设遗忘集是已知的（表2 (https://arxiv.org/html/2607.13037#S3.T2)）。基准测试 TOFU [Maini et al. (2024)](https://arxiv.org/html/2607.13037#bib.bib2) 和 OpenUnlearning 使用预定义的遗忘集，而 MUSE [Shi et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib1) 在已知遗忘/保留拆分的真实语料上评估反学习。反学习方法如 NPO、RMU、GradAscent 以及精确反学习算法 [Muresanu et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib3) 直接接收遗忘集作为输入。ForSId [D’Angelo et al. (2025)](https://arxiv.org/html/2607.13037#bib.bib5)（§2）是唯一解决遗忘集识别的工作，但从事后通过模型访问进行操作。OriginBlame 在记录时捕获来源信息，无需模型访问。

**表2：机器反学习基准测试：遗忘集定位缺口**

这种定位补充了像 Attribute-to-Delete [Georgiev et al. (2024)](https://arxiv.org/html/2607.13037#bib.bib4) 等方法，这些方法使用数据模型模拟反学习，但仍需要遗忘集作为输入。IPFS 的内容寻址设计 [Trautwein et al. (2022)](https://arxiv.org/html/2607.13037#bib.bib9) 启发了 OriginBlame 的哈希链机制，但 IPFS 在块级别（256 KB 块）操作，而 OriginBlame 将粒度细化到行。OriginBlame 使用普通的 JSONL 而不是专门的文件系统。与针对代码编辑场景设计的 git-blame 相比，OriginBlame 针对生成数据场景：支持多源归属，其中单行可能融合多个作者的贡献，以及作者发起的撤销。

## 4 系统设计

### 4.1 架构概述

OriginBlame（缩写为 ob）将所有溯源元数据存储在与项目数据同目录的 `.ob/` 目录中。所有文件都是普通的 JSONL，没有配置文件或中央数据库。

**三层模型**。ob 采用分层存储架构。如图2 (https://arxiv.org/html/2607.13037#S4.F2) 所示，三个核心层通过内容寻址哈希以严格的父子关系链接：

* **作者层**（顶部）存储身份和撤销标签：`id`（`name+email` 的 SHA-256）、`name`、`email` 和 `revoked`（布尔值）。`revoked` 字段是撤销的唯一真实来源，在查询时惰性级联；`email` 用作 `revoke` 的查找键。
* **段层**（中间）存储文件级版权：`section_hash`（主键，`{path, authors, license, year}` 的 SHA-256）、`path`（源文件路径，按文件分组记录）、`authors`（作者 ID 列表）、`license`、`year` 和 `revoked`（布尔值）。
* **文档索引层**（底部）存储每个记录的溯源：`line_hash`（数据内容的 SHA-256）、`file`（输出数据文件）、`sources`（标识贡献源的段哈希列表）、`source_type`（来源指示器，例如 `"track"` 用于显式跟踪）和 `revoked`（布尔值）。唯一键是 `(line_hash, file, sources)`。

每个文档索引条目对应一个输出记录（数据文件中的一行），链接到其贡献段及其作者。文档索引记录不存储行号——`blame` 在查询时从数据文件计算哈希。

**存储**。所有核心文件通过主哈希的前两个十六进制字符分片到 256 个桶中：`document-index/00–/ff`、`sections/00–/ff`、`authors/00–/ff`。空桶不会创建。该设计支持 O(1) 查找——给定 `line_hash`，`blame` 直接读取 `document-index/{前两个十六进制字符}`，无需扫描无关桶。多进程安全通过无锁实现：每个进程写入隔离文件（`docidx.{pid}`、`lock.{pid}`），之后 `ob clean` 将它们合并到分片桶中。未合并的 pid 文件会阻止读操作，直到清理完成。`embeddings.{model}/` 目录存储每个模型的嵌入向量，分片到 256 个桶中，用于 `reconcile`（§4.4 (https://arxiv.org/html/2607.13037#S4.SS4)）；核心无需 ML 库或 GPU——嵌入由 `reconcile` 工具（§4.4 (https://arxiv.org/html/2607.13037#S4.SS4)）计算，而非用户。

**内容寻址哈希**。ob 通过将字典输入序列化为带有排序键的 JSON，然后应用 SHA-256 [National Institute of Standards and Technology (2015)](https://arxiv.org/html/2607.13037#bib.bib21) 进行哈希；字符串输入作为原始 UTF-8 字节进行哈希。不执行标准化。对于 k 位哈希空间中的 n 个记录，碰撞概率由生日近似 p ≈ n²/2^(k+1) 界定（Katz and Lindell, 2020 [Katz and Lindell (2020)](https://arxiv.org/html/2607.13037#bib.bib20)，定理 A.4）。在评估的最大规模（n=2.2×10⁵ 个记录，k=256）下，这产生 p < 10⁻⁶⁸——相对于任何实际故障模式来说可以忽略不计。

**设计原则**。ob 遵循两个核心原则。首先，*未记录的内容不存在*：ob 不进行事后推断，也不将无溯源内容标记为有溯源。其次，*单跳溯源*：系统仅跟踪从原始来源到最终输出的直接映射，不追踪中间处理阶段。删除原始数据文件不影响溯源或撤销。

![参见说明文字](图2：基于哈希分片的三层参考架构。)

### 4.2 核心工作流

OriginBlame 被设计为既是库又是 CLI 工具，具有 Rust 原生实现和可选的 Python 绑定。用户通过 `ob init` 初始化项目，创建 `.ob/` 目录；Python 初始化包装器还会为临时文件写入 `.gitignore`。一次性设置需要三个 CLI 调用和一个 Python API 调用：(1) `ob init`，(2) `ob author.add NAME EMAIL`，(3) `ob register.add --path PATH --authors AUTHOR --license LICENSE --year YEAR`，(4) `source.append(PATH)`（Python API）。集成到现有数据流水线只需在每个训练记录写入磁盘时添加一个 `track()` 调用——例如，在将记录写入输出文件之前立即插入 `track(record, file="data/train.jsonl")`。用户现有的流水线逻辑保持不变；ob 仅观察通过的数据。

**源管理**：`source.append(path)` 将路径解析为段记录并激活它们，注册与该路径关联的所有段。可选的 `section` 参数通过其哈希选择单个段。`source.pop()` 移除最近添加的源，或通过文件路径移除特定源。`with ob.sources(...):` 提供作用域跟踪。跟踪操作自动关联所有活动源——调用者无需显式传递源。

**ob.track() 工作流**：`track(data, file)` 库函数为单个数据条目记录溯源。来源归属要么从显式的 `source=` 参数（解析为注册段或段哈希列表的文件路径）解析，要么默认从源栈解析。如图3 (https://arxiv.org/html/2607.13037#S4.F3) 所示，它 (1) 计算 `data` 的 SHA-256 哈希（所有类型的 JSON 序列化），(2) 将活动源列表解析为段哈希，(3) 检查重复（幂等），(4) 通过 WAL（`lock.{pid} → docidx.{pid}`）写入进程隔离文件（Python API 中），Rust 原生实现直接写入分片桶。如果进程在锁被删除之前崩溃，剩余数据可通过 `ob clean` 恢复。可选的 `embedding` 参数（Python API）将每个记录的嵌入向量存储到文档索引记录旁边，以供后续 `reconcile` 使用（§4.4 (https://arxiv.org/html/2607.13037#S4.SS4)）。

![参见说明文字](图3：track() 工作流。哈希计算后，系统检查重复并在 WAL 保护下写入进程隔离的临时文件。)

**查询功能**：ob 提供两种正交的查询方法。`ob blame` 执行正向查询：给定文件路径和行号，它读取该行，计算 SHA-256 以获得 `line_hash`，查询 `document-index/{line_hash[:2]}`，并遍历溯源链：`line_hash → sources (段)`