用图数据库追溯AI模型许可证：Pedigree工具解析

模型微调背后的许可证盲区

微调一个开源模型看起来只是技术活，但许可证的约束会顺着模型谱系一路传递。Meta 的 Llama 3.2 许可证要求使用者提供声明、制定可接受使用政策并遵守命名规则，而一个基于它微调出的模型，其模型卡片上可能只写了 MIT——两页内容并排看才能发现缺口。这种信息断层在真实的 AI 供应链中普遍存在，链条往往还不止两层。

一篇题为《Don't Trust the Label》的预印本专门讨论了 AI 供应链中许可证如何被“洗白”，作者指出目前没有工具能自动审计整条链上的许可证。现有扫描器大多一次只看一个模型，这正是 Pedigree 试图填补的空白。

许可证义务的“传染性”（license propagation）是理解这一问题的关键。开源模型许可证通常不是简单的授权声明，而是一组义务的集合：Llama 3.2 社区许可证要求下游分发者保留归属声明、在模型名称中体现“Llama”并附带“Built with Llama”标识、制定可接受使用政策，且对超过 7 亿月活用户的使用者设有额外许可要求。当有人微调该模型并再分发时，这些义务理论上应随衍生作品继续传递。但许可证字段本身只是一个字符串，Hub 不会自动校验子模型是否真正履行了父许可证的义务，也不会强制继承。因此“MIT”标签可能只是发布者自行填写的结果，与模型实际应承担的义务无关。这种字段与义务的脱节，正是供应链许可证“洗白”能够发生的结构性原因。

Pedigree 的工作机制

输入一个形如 org/name 的模型 ID 后，Pedigree 会读取 Hugging Face Hub 上的公开元数据——许可证、基础模型、声明的训练数据集——写入 FalkorDB 图数据库。接着沿谱系向上遍历，把每个子模型声明的许可证与父模型许可证所要求的义务逐项比对。

每个标记都会展示它走过的路径，并链接回原始页面，方便人工复核。作者强调，标记只意味着“值得看一眼”，不构成法律意见。这种克制是必要的：自动化工具能做的只是把隐藏的缺口摊开，判断仍需人来完成。

缺数据不等于没问题

工具在设计上有一条明确原则：任何缺失或无法读取的信息都计为风险，绝不算通过。一个在读取失败时保持沉默的工具，恰恰在它知道得最少的时候显得最干净。首次实测中，一个小型聊天模型列出的四个训练数据集里，cerebras/SlimPajama-627B 在浏览器中返回 404，Pedigree 将其标记为“无法获取”，并声明其上所有内容无法验证；另一个数据集的许可证写作“other”，工具同样如实报告而非当作合格。

Hugging Face Hub 元数据中的 base_model 字段是谱系追溯的起点，但它并不可靠。该字段由模型发布者手动填写，可以指向任意模型 ID，也可以留空；即便填写了，也只表示“声称基于此模型”，Hub 不做验证。Pedigree 依赖这一声明向上遍历，意味着如果中间某一层发布者遗漏或虚报了基础模型，整条谱系就会断裂，工具只能看到声明范围内的部分。同样，datasets 字段和 license 字段也都是自报信息。理解这一点很重要：Pedigree 审计的是声明的谱系，而非事实上的训练来源；它能暴露声明层面的矛盾，却无法证明模型真实的训练血统。

抽样数据揭示了什么

作者统计了下载量最高的 60 个 Llama-3.2-1B 微调模型：48 个声明的许可证带有与父模型相同的义务，6 个声明了 Apache-2.0 或 MIT，3 个的许可证无法评估，3 个干脆没有声明。

那 6 个模型没有被点名——每个都只是供人核查的线索，标记本身不说明任何意图。样本按下载量选取、并非随机，因此不能代表整个 Hub 的状况。这组数字的意义不在于指控，而在于说明“许可证字段与父模型义务脱节”是可以被系统性观测到的现象。

图数据库为何是合适的选择

在 Pedigree 的数据模型里，模型、数据集、许可证、义务都是节点；边记录谁衍生自谁、谁在什么数据上训练、哪份许可证携带哪些义务。一个标记本质上是一条 Cypher 查询：沿谱系向上最多六层，寻找父许可证携带而子许可证缺失的义务。

图结构在这里不只是存储选择，它直接构成了标记的解释——走过的路径就是呈现给读者的证据。没有图，标记就只是一句没有依据的断言。

每次用户保存决定时，系统会生成独立的私有图，并存储当时谱系的快照。日后复查时取新快照对比，就能精确指出哪份许可证在哪一环发生了变化。重新检查某个模型时，旧的父链接会先被删除——模型卡片会变，图不应保留发布者已经移除的关系。

Cypher 是 Neo4j 提出的图查询语言，FalkorDB 兼容其语法。它用模式匹配表达“沿关系走”：例如 MATCH (child:Model)-[:DERIVED_FROM*1..6]->(parent:Model) 表示从子模型出发，沿 DERIVED_FROM 边向上最多走六跳找到祖先模型，再匹配各自的许可证与义务节点，找出父有而子无的义务。相比在关系型数据库中反复做递归 JOIN，图查询把“路径”本身作为一等结果返回，路径上的每个节点和边都可以直接取出展示。这正是 Pedigree 能把标记与可阅读的证据链绑定的技术基础：标记不是布尔判断，而是一条查询命中的具体路径。

踩过的坑与未验证的边界

部署过程并不顺利。Docker 起初报引擎未运行，解决后又拒绝拉取 FalkorDB 镜像，提示 TLS 协议版本不支持；而用 curl 直连 Docker 服务器一切正常。关闭 WSL 并登出 Docker 后拉取才成功。环境方面，作者机器上装有 Python 3.15 和 3.12，选择了 3.12，因为 3.15 太新、部分包可能没有对应构建——不过作者坦承并未实际测试 3.15 是否会失败。

更重要的边界在于：目前只有 Llama 3 和 Llama 3.2 的规则与许可证文本做过比对，其他许可证对应的规则标记为未验证，相关标记只是线索。Hub 只知道发布者声明了什么，而声明可能缺失也可能有误。

隐私设计上，Pedigree 只读取公开元数据，不要求个人信息，没有账户体系；浏览器保存一个随机 ID，评审记录存在该 ID 下的私有图中，Forget 按钮可删除整张图，仓库中不存放任何令牌。

“未验证规则”的含义需要精确理解。Pedigree 的比对逻辑依赖一份人工整理的映射：某份许可证文本对应哪些具体义务。作者只对 Llama 3 和 Llama 3.2 的许可证文本逐条比对过，形成了可信的义务清单；对其他许可证（如 Apache-2.0、MIT、各种“other”自定义条款），工具要么没有完整规则，要么规则未经文本核验。此时产生的标记只说明“子模型声明的许可证与父模型义务之间存在某种不一致”，但不保证该判断准确——可能漏报，也可能因规则不全而误报。因此这类标记的定位是“线索”而非“结论”，把它当作法律判断依据是不成立的。

定位与局限

与严肃的学术工作相比，Pedigree 是个小工具。《Don't Trust the Label》（arXiv 2607.20300）描述了 AI 供应链中的许可证问题，《AI Supply Chain Galaxy》（arXiv 2606.16292）是面向许可证合规的可视化分析系统。Pedigree 的增量在于：每个标记都附带一条可阅读的路径，以及一个能保存决定并观察变化的去处。

值得留意的是作者的坦诚——工具由 AI 助手参与编写了大部分代码的初稿，但数据库搭建、每一条命令的执行、对实时 Hugging Face 数据的测试以及取舍决定，都由作者本人完成。这种披露本身，也是当前 AI 辅助开发项目值得参考的实践。

代码已开源于 GitHub（triixdev/Pedigree）。对于需要处理模型合规的团队，它更像一个起点：把谱系中的许可证缺口变得可见，然后交由人来判断。