如何在不公开训练数据的前提下证明它的存在

是的，你可以在不公开数据集的情况下，证明一份私有数据集曾经存在。

做法很简洁：构建一份数据集清单，对其中的条目计算哈希，把这些哈希折叠成一个 Merkle 根，然后在 Cardano 上发布一份 Label 309 存在性证明（Proof of Existence）记录。数据集本身始终不会脱离你的掌控。日后，你可以精确地只披露一个文件、一行数据、一条清单条目，或一份包含证明，以表明它曾属于这份已承诺的快照——仅此而已。

这能证明你在某个时间点之前已经持有这份数据。但它本身并不能证明所有权、版权状态、授权同意或合法使用。这些都是另一类问题，需要另一类记录来佐证。

AI 团队为什么会需要这个？

训练数据已经成了董事会层面的议题。一家模型提供方可能需要向投资人、合作伙伴、客户、监管机构、审计方、授权方或诉讼方说明：它持有过哪些数据、何时持有、来源何处、如何处理，以及某个特定的模型版本是用哪些数据集训练出来的。

与此同时，公司往往无法公开数据集。其中可能包含授权内容、客户数据、个人数据、专有来源、内部标注、商业秘密、安全评估、检索语料、合成数据，或敏感的过滤规则。

存在性证明化解了这层张力。它让你既能对数据集的状态与时间线作出承诺，又无需向公众披露数据集本身。你发布的是一枚指纹，字节则留在原处。

你应该承诺什么：原始数据，还是清单？

承诺一份清单，而不是单纯的原始字节。

数据集清单以结构化、机器可读的方式描述快照。它可以记录：

数据集名称与快照 id
采集时间窗口
来源类别与权利元数据
按文件和按行的哈希
去重与过滤的版本
标注与预处理流水线的版本
使用它的模型或训练任务
留存策略与内部归属

清单无需向公众暴露任何敏感细节。它完全可以留在公司内部。对外的证明只承诺它的哈希，或承诺覆盖众多清单条目的一个 Merkle 根。目标很窄、也很持久：把数据集在某个已知时刻的状态作为证据冻结下来。

为什么用 Merkle 根，而不是一份文件一条记录？

数据集很大，为每个文件或每一行各发布一条记录无法扩展。Merkle 根解决了这个问题：它把一份有序的哈希列表承诺为单一的 32 字节值，并锚定在一笔交易中。

日后，要证明某一项被包含在内，你只需披露：

该项本身或它的哈希
相关的清单条目
一份 Merkle 包含证明
该 Label 309 交易引用

验证方会从那片叶子重新计算到根的路径，并确认该根是在某个特定的 Cardano 区块时间发布的。证明的体积随批处理规模的对数增长，因此即便有数百万片叶子，它依然很小。关键在于：构建树、检查证明都是纯粹的离线计算——在验证时，不需要服务器、不需要账户，也不需要你的任何配合。

这正是有选择地披露之所以可行的原因。你无需公开整份数据集，就能证明其中某一项确实属于这份已承诺的快照。

公众实际上能看到什么？

只有链上的那条证明记录。视你的发布方式而定，其中可以包含一个清单哈希、一个 Merkle 根、一个叶子数、交易时间、一份来自你公司或系统的可选签名，以及指向公开或加密辅助材料的可选内容寻址 URI（ar://、ipfs://）。

公众看不到数据集文件、完整的叶子列表、来源元数据、客户数据、授权细节、标注或内部备注。在某个具体问题迫使披露之前，这些都留在你的证据系统内部。

日后你会披露什么，又会在何时披露？

只披露问题所要求的内容。

某个文件是否在数据集里？ 披露该文件或它的哈希、对应的清单条目，以及一份包含证明。
某个来源类别是否被纳入？ 披露相关的清单部分，以及证明它属于这份已承诺快照的证据。
某个模型版本是否用了某个特定快照？ 披露那份把模型版本与数据集根关联起来的训练任务清单。
是否需要一次完整审计？ 在适当的保密流程下，披露整份清单与叶子列表。

链上的根证明了时间线。你内部的归档则决定了你能展示多少细节、以及向谁展示。如果辅助材料本身必须转交给第三方却又要保持私密，你可以以保密方式分享它，而不必将其公开。

这和 AI 监管有什么关系？

AI 监管正朝着更强的文档化与透明度义务发展。例如，欧盟《AI 法案》为通用人工智能模型设定了透明度与版权相关的规则，欧盟委员会也发布了训练内容公开摘要的模板——用委员会自己的话说，这是对外公开信息的一条最低基线。

一份私有数据集证明，并不等同于那份公开摘要。它无法取代监管报送、法律审查、同意管理或授权记录，而这一切在某个具体案件中是否有帮助，取决于你所在的司法辖区和你的法律顾问。

它能支撑的，是这些流程背后的证据层。如果一家公司日后需要说明它持有过什么、知道什么，或者某份公开摘要是基于哪个快照编制的，那么一份带时间戳的清单承诺，就是关于时间与完整性的、由第三方锚定的具体证据。

一份数据集证明到底证明了什么？

它证明：某个特定的数据集承诺，在某个公开的区块时间之前已经存在。视你所保存的证据而定，这可以帮助说明：

某个文件曾在某份数据集快照中
某份清单在争议发生之前就已存在
某个数据集版本在某次模型发布之前就已存在
某次训练任务引用了某个特定快照
某个来源类别在当时已被记录在案
某条预处理或过滤流水线已被记录下来

如果记录被签名——Label 309 支持可选的记录级签名——它还能表明某把公司密钥或系统密钥为这份承诺背书。签名从来不是必需的，因此一份未签名的承诺同样有效；签名只是额外增加了可归属的作者身份。

它不能证明什么？

这部分必须如实说清楚，因为这些空白很重要。

一份数据集证明并不能证明这些数据的使用是合法的。它无法证明你拥有这些数据、它们是经同意采集的，也无法证明它们的版权状态。它无法证明数据真的被用于训练——除非你的训练流水线和模型记录本身就与数据集快照绑定在一起。它也无法证明清单是完整的；只有你的流程与控制才能让完整性变得可信。

存在性证明是关于时间线与完整性的证据。它确立的是：确切的字节在某个公开时间之前已经存在。它对真伪、所有权、权利或合规性只字未提——那些需要额外的记录与法律分析。如果你想完整了解这条界线落在哪里，参见一份证明能证明与不能证明什么。

你应该如何设计这套工作流？

围绕你预期日后要回答的问题来设计，而不只是为了今天计算哈希。

一种可行的形态：

定义一种规范的数据集清单格式。
对每个数据集项或清单条目计算哈希。
为该快照构建一个 Merkle 根。
发布一条 Label 309 记录，如果你需要可归属的作者身份，就对它签名。
保存清单、叶子列表和包含证明所需的材料。
把模型训练任务回链到数据集根。
为法律或合规接收方封存敏感的证据材料包。
当数据集发生变化时，记录用于替换的新快照。

难点很少在密码学本身。难点在于判断：几个月甚至几年后有人来追问时，哪些证据才会真正有意义。

你应该多久承诺一次快照？

只要数据集发生了有实质意义的变化，就承诺一次——通常是在一次新的数据接入之后、一次训练任务之前、去重或过滤之后、标注之后、模型发布之前、某个治理检查点上，或者把数据集分享给合作伙伴之前。

承诺的节奏应当与你预期要回答的问题相匹配。一年只承诺一次，你可能就无法证明某个中间快照曾经存在；每发生一点微小变化就承诺一次，又会产生运营噪声。由于 Merkle 批处理让一个根就能代表整份快照——无论它覆盖多少文件，都只需一笔交易——每次承诺的成本基本保持不变。于是你可以按所需的证据来选择节奏，而不必受价格摆布。

封存存储在这里起什么作用？

有时候，仅仅计算哈希还不够——你想保存的是证据本身，而不只是它的一枚指纹。

封存 PoE 让你能做到这一点。对外的记录仍然像普通证明那样承诺明文哈希。敏感的载荷则被加密后存放在一个内容寻址 URI 处，内容加密密钥被封装给一个或多个接收方密钥。获授权的接收方日后可以解密它，并通过重新计算哈希，确认恢复出来的明文与链上承诺一致。

链上从不携带明文，也从不暴露接收方是谁；它只表明：在时间 T 作出了一份封存承诺。当丢失原始清单会削弱你的证明时，这一点尤为重要。只要你仍然持有文件，一条仅含哈希的记录就足以证明其存在。而一条封存记录可以连加密文件本身一起保存，让证据与承诺一同流转。

有一点局限值得直白地讲清楚：封存让内容对除选定密钥持有者之外的所有人保持私密，但它并不能让任何人匿名，接收方在解密之后也始终可以泄露明文。封存控制的是谁能读取，而不是他们读取之后会做什么。

这套流程应该由谁来主导？

数据集证明流程不应该是一段无人主导的工程脚本。它牵涉法律、安全、数据治理、合规与模型开发，而一套好的流程会把边界讲明白：谁可以创建快照、谁可以为承诺签名、清单存放在哪里、谁可以解密封存材料包、包含证明如何生成、模型任务如何与根关联、用于替换的快照如何处理，以及在审计或争议期间证据如何产出。

证明是密码学的事。治理是组织的事。两者你都需要。

简要版本

要在不公开训练数据的前提下证明它，请承诺快照，而不是数据集。构建一份清单，对其中的条目计算哈希，在一条 Label 309 记录中发布一个 Merkle 根，并保留叶子列表和包含证明。当丢失敏感辅助文件会削弱证明时，就把它们封存起来。然后只披露每个问题真正需要的那部分证据。

这就给了你一份持久的、由第三方锚定的证明，证明你此前的持有与时间。它本身并不能证明所有权、合法使用或合规性——而当你清楚地说明它在做什么、不在做什么时，它才最有用。