我们的模型基于哪些模型？审计现代LLM中的隐形依赖

TL;DR ModSleuth 用智能体递归重建 LLM 训练中的隐藏依赖链，从公开碎片中溯源验证 1,060 条依赖，揭示多跳许可关联与训练-评估耦合的隐形风险。

问题

问题背景：当前大语言模型（LLM）的训练管线深度依赖上游模型，用于数据生成、语料过滤、输出评判等，形成递归的依赖链，但依赖关系分散在模型卡片、论文、代码库等异构公开文档中，缺乏整体可见性，给合规审计、模型选择与信任带来严重隐患。

现有方法局限：现有依赖追踪主要依赖人工梳理或简单规则抽取，难以应对以下技术局限：

• 依赖定义模糊：何谓“依赖”？是直接使用模型权重、受其生成数据训练，还是间接通过经其处理的数据集？缺乏统一概念导致图谱边界不清。
• 实体解析困难：同一上游模型在不同文档中以不同名称、版本、仓库引用，无标准化标识符，难以唯一解析，造成大量遗漏或错误链接。
• 间接依赖盲区：递归依赖（如模型 A 依赖 B，而 B 又依赖 C）通常仅记录在各自独立发布物中，人工无法高效追溯多跳路径，导致许可证义务传递、训练-评估数据耦合等深层问题不易发现。

为什么这个问题难/重要：技术上，挑战在于将非结构化的自然语言叙述、代码配置与模型仓库信息融合，并在缺乏唯一标识符的情况下完成实体对齐与关系验证。业界对此关注度迅速上升，因为：

• 许可证合规风险：模型依赖上游数据及模型，其许可证条款可能通过多跳路径强制传递，例如使用 CC BY-NC 数据训练的模型可能侵犯商业使用限制，而开发者未必知情。
• 训练-评估污染：若依赖模型参与测试集构造或过滤，可能导致评测基准泄漏，损害模型性能评估的公正性。
• 版本漂移与现实差距：发布的模型卡片常与训练时实际使用的依赖版本不一致，造成可复现性危机与调试困难。

因此，自动化、可验证的依赖图重建成为保障 LLM 供应链透明性的关键需求。

行业类比：如同软件工程中软件物料清单（SBOM） 已成为安全治理的基础，LLM 生态系统急需一种模型依赖物料清单来自动化追踪递归依赖，确保 AI 开发者的合规与信任。

核心洞察

• 核心范式转移：构建 LLM 依赖图的主要难点已从信息提取转向定义“什么是依赖”以及跨异构文档协调实体身份。传统审计工具聚焦于从单一 artifact 中抽取提及关系，但 ModSleuth 的实践表明，不同模型卡、技术报告、代码仓库对同一上游模型使用完全不同的名称、版本或缩写，且文档常把间接依赖包装为直接引用。因此，系统必须引入操作中心（operation-centered）的依赖建模，区分审核训练、数据生成、评估评判等不同管道角色，并通过来源验证（source-grounded evidence）解决引用歧义，否则恢复出的依赖图将包含大量虚假连接或遗漏关键传递性义务。
• 多跳依赖网络暴露了人工审计几乎无法捕捉的隐性风险：许可证义务传播、训练评估耦合、以及“模型中介选择”机制。ModSleuth 递归展开发现，一个目标模型可能通过数据过滤依赖某奖励模型，而该奖励模型又基于另一专有模型做偏好标注，形成跨 3 层以上的许可证传染路径；同时，评估基准的构建常复用训练指令微调模型，导致 train-test 泄露隐患隐蔽于间接依赖中。这种可见性直接帮助合规团队预判 GPL-like 条款的传染范围，并指导模型发布者清理评估数据来源，其工程价值远超静态文档审计。

方法

输入与目标

ModSleuth 以目标 LLM 的公开发布制品（论文、模型卡、数据表、博客、代码仓库等）为输入，目的是自动构建该模型的全量依赖图——即哪些上游模型、数据集、代码工具被直接或间接用于其训练、评估、数据构造等环节。

核心三阶段

1. 源收集 (Source Gathering)： 系统首先从指定起点出发，自动抓取与目标模型相关的公开文档和代码资源，形成初始证据库。

2. 实体发现与解析 (Entity Discovery & Resolution)： 这是系统区别于传统信息抽取的关键模块。它不仅从文本中识别出依赖项名称，更要解决制品身份冲突——同一模型在不同文档中可能以不同名称、版本或仓库路径出现。ModSleuth 通过跨文档对齐与版本规范化，将指代同一实体的多种表述统一为规范的 Artifact Identity，为后续关系构建提供可靠节点。

3. 依赖构建与调和 (Dependency Construction & Reconciliation)： 系统基于操作中心的关系类型（如 is_trained_on、is_evaluated_by、generates_data_for）来建立有向边，明确表示依赖的性质。对于多源文档中出现的矛盾描述，ModSleuth 采用证据加权策略进行调和，并记录源级证据 (source-grounded evidence)，确保每条依赖边均可追溯至原始引用语句。

递归扩展与输出

上述三阶段并非一次性执行：每发现一个上游依赖实体，系统会将其作为新的起点递归展开（如数据集 B 引用模型 A，而模型 A 又依赖数据集 C），从而恢复多层间接依赖。最终输出为有向依赖图，节点是唯一标识的制品，边带有关系类型、证据片段及许可证信息等元数据。

与同类方法的差异

传统监督抽取专注于预定义槽位填充，而 ModSleuth 将挑战转向依赖语义的形式化定义与跨异构文档的制品身份对齐，并通过 agentic 递归机制补全隐藏的多跳依赖，首次在 LLM 生态审计中实现了可验证的大规模图重构。

实验

实验设计

ModSleuth 在四个公开文物丰富的 LLM 发布（涵盖不同组织、规模与训练范式）上进行评估，系统从模型卡、论文、代码仓库等公共文物中递归重建依赖图。任务形式化为三个阶段：源收集（抓取官方声明、技术报告、仓库）、实体发现与解决（识别模型、数据集、工具，并跨名称 / 版本 / 仓库统一身份）、依赖构建与调和（根据操作中心关系连接实体，区分直接与间接依赖）。依赖类型覆盖数据生成、语料过滤、输出评判、决策指导等流水线角色。人工验证所有恢复依赖的源证据。

关键发现

系统成功恢复 1,060 个源验证依赖，构建出包含多跳路径的完整依赖图。图谱揭示：(1) 多跳上游模型：最终模型常依赖未经文档化的二层、三层上游模型，形成隐蔽供应链；(2) 训练-评估耦合：训练数据与评测基准出现非预期的交叉污染；(3) 许可证义务传播：依赖链中的许可证要求会沿多跳传导，带来合规风险；(4) 发布文物不一致：模型发布所用的工件与训练时实际使用的工件存在显著差异，模型卡与代码配置所体现的信息经常矛盾。

对比解读

与传统人工审计（仅能追踪显式直接依赖）相比，ModSleuth 的自动化 agent 首次实现了递归、跨文物的依赖证实，突破文档碎片化与身份歧义瓶颈。在没有同类自动化 baseline 的情况下，其核心价值体现在深度：传统方法即使辅助脚本也难梳理三层以上间接依赖，而 ModSleuth 通过操作中心关系建模与文物身份解析，可达 4-6 跳依赖深度，揭示出上游模型、数据加工步骤、代码级来源等隐藏风险。这为 AI 供应链透明化提供了可复用的基座工具，后续其他依赖审计系统可直接将其作为基准。

行业影响

落地场景

当企业基于开源 LLM（如 Llama 3、Qwen2）构建下游产品或微调定制模型时，常面临隐藏依赖风险：预训练数据可能由其他闭源模型生成，评估基准与训练数据耦合导致数据泄露，许可证义务沿多跳传递。ModSleuth 提供自动化依赖审计，适用于：

• 模型发布前的合规审查：在发布模型、权重或 API 前，扫描所有上游依赖，识别 GPL/CC 等许可证冲突。
• 企业采购模型的第三方审计：金融机构、政府客户需要对供应商模型进行供应链透明化检查，避免合规黑箱。
• AI 平台的内容溯源：内容生成平台（如社交媒体、新闻）需要追溯训练数据来源，防止版权纠纷。

商业价值

直接降低合规成本：手工审计一个 LLM 的依赖链需数周甚至数月，ModSleuth 的自动图构建可将时间压缩至小时级，减少人工律师和工程师投入。避免许可证违规赔偿：多级依赖可能隐藏 copyleft 许可证，提前发现可避免商业发布后被追责。提升模型可解释性与市场信任：在欧美市场，AI 审计日志已成为企业客户招标的必备项，提供可验证的依赖图能增强竞标优势。

与现有工作流的接口

ModSleuth 可集成进 MLOps 流水线中，作为模型注册前的门禁步骤：

1. 在 CI/CD 中增加一个检查节点，输入目标模型的公开 artifact（模型卡、论文、代码仓库），输出依赖图 JSON。
2. 与 SBOM（Software Bill of Materials）工具（如 SPDX）对接，将依赖关系映射为许可证兼容矩阵，自动产生合规报告。
3. 与企业内部的模型目录（如 MLflow Model Registry）集成，将依赖图作为模型元数据存储，便于持续监控上游变更风险。

具体案例：

• 金融领域的风控模型：某银行基于开源金融 LLM 构建信贷评估助手。在上线前用 ModSleuth 扫描发现其微调数据由某未公开模型合成，且该上游模型使用了 GPL 组件，于是及时替换数据生成管线，避免许可证传染。
• 电商平台的推荐模型：某电商平台计划开源其多模态推荐模型，以吸引开发者生态。通过 ModSleuth 自动审计，发现训练时使用的图文匹配模型存在非商业许可限制，团队据此清理依赖并重新训练，顺利开源并建立技术信誉。

局限

• **依赖文档的不完整性**：ModSleuth 仅从公开 artifacts 中提取依赖信息，无法捕获未公开或故意隐藏的依赖关系（如内部训练工具、非开源数据预处理脚本），导致依赖图可能遗漏关键路径。同时，模型卡片、论文等文档常存在模糊表述或版本不一致，间接依赖的重建高度依赖文档质量，单个文档的错误可能沿依赖链传播，产生级联错位。
• **信息抽取与实体解析的准确性**：系统使用 LLM 进行实体发现、链接和依赖推理，虽结合了验证步骤，但 LLM 固有的幻觉和敏感度可能导致遗漏或错误关联。特别是跨不同仓库、不同命名惯例的 artifact 身份解析仍需人工核对，复杂隐式依赖（如通过基准评测间接依赖上游模型）可能被忽视。
• **依赖定义的局限性**：ModSleuth 依赖预定义的操作中心关系（如生成、过滤、评估）来刻画依赖，这未必涵盖所有相关的管道交互（如超参搜索、数据平衡策略）。此外，依赖图的“间接依赖”边界界定带有主观性，不同审计需求可能需要不同的抽象粒度，当前形式化无法完全适配动态变化的 LLM 开发生态系统。