加州大学伯克利分校追问：你的AI是站在谁的"肩膀"上建起来的？

这项由加州大学伯克利分校与艾伦人工智能研究所联合开展的研究，以预印本形式于2026年6月发布，论文编号为arXiv:2606.12385。研究团队开发了一个名为ModSleuth的自动化系统，专门用于追踪大型语言模型背后那张错综复杂、几乎无人知晓的"家谱"。

现代的人工智能模型早已不是"从零生长"的纯粹产物。它们在训练过程中大量依赖其他AI模型来生成数据、筛选内容、评判质量和指导决策。这条"依赖链"层层嵌套，像俄罗斯套娃一样深不见底，而且几乎没有任何一份文档能完整地把这张关系网说清楚。普通用户看到的是一个漂亮的AI产品，却不知道它背后藏着多少"幕后功臣"，其中一些依赖甚至连开发者自己都没意识到。

ModSleuth的出现，正是为了揭开这层遮蔽。研究团队将这套系统应用于四款拥有大量公开文档的AI模型——Olmo 3、Nemotron 3 Super、DR Tulu和SmolLM3——最终追溯出超过一千条经过核实的依赖关系，构建出迄今为止最详尽的大型语言模型依赖图谱。这张图谱揭示了许多令人担忧的现象：潜在的许可证冲突悄悄传递、训练数据与评测基准之间存在暗中勾连、对外宣称使用的工具和实际训练时用的工具之间存在出入，还有一些依赖关系的记录本身就自相矛盾。

更值得关注的是，研究团队在与部分模型的原始开发者交流后发现，某些依赖关系连开发者本人都不知道——这说明问题不仅来自疏忽，更来自整个行业在文档记录和审计机制上的结构性缺陷。

---

一、被遗忘的"幕后黑手"：现代AI到底依赖什么

要理解这项研究想解决的问题，可以用一个建筑工程的比喻来思考。你走进一栋高楼，看到的是光鲜亮丽的大堂和整洁的电梯。但这栋楼能竖立起来，是因为用了某种品牌的钢筋、某种产地的混凝土、某家工厂生产的螺栓。如果其中一批螺栓其实是用了不符合规定的材料制成的，这个问题会一路传递到整栋建筑，但没有人能从外表上看出来。

现代大型语言模型的训练过程，正是这样一个复杂的"建筑工程"。以往，训练一个语言模型的流程相对简单：收集大量人类写的文字，用它来预训练模型，再用人工标注的数据做后续调整。但现在，这个流程已经变得极其复杂，其中充斥着各种"上游模型"的影子。

举几个具体的例子来说明这种依赖有多普遍：一个模型可能使用另一个AI来做光学字符识别，把扫描的学术论文转化成可用的文本；可能请一个"老师模型"生成大量合成训练数据，填充自己的训练集；可能用一个"过滤器模型"来筛选哪些内容质量足够高、值得进入训练；可能用一个"评判模型"在强化学习阶段决定哪些回答更好、给予更高分数；还可能基于另一个模型事先生成的"偏好对"来做偏好学习，让自己的回答风格更符合人类期待。

每一个环节都引入了至少一个外部模型作为依赖。而这些依赖又是递归的——那个"过滤器模型"本身也是用某些数据训练的，而那些数据又可能是另一个模型生成的……依赖链可以延伸很长，研究团队在实际分析中发现最深能达到八层。

问题在于，这些依赖关系散落在技术报告、模型卡（Hugging Face上的模型说明页）、代码仓库和数据集卡片等各种文档里，没有人统一记录和整理，也没有一套标准的格式来描述这些关系。如果你想了解某个模型依赖了哪些上游资源，你需要自己去翻遍它的所有公开资料，然后再对每一个上游资源重复同样的过程。研究团队在开发ModSleuth之前，曾尝试让人类专家手动追踪单个模型的依赖关系，结果发现哪怕是作者自己，花费了大量时间后仍然无法产出一份足够完整的依赖图谱。

---

二、给AI开具"成分表"：ModSleuth是怎么工作的

ModSleuth的工作思路，可以类比成一个拿着放大镜的档案员，专门去翻查一栋建筑的全套施工记录。它的任务不是"猜"这栋楼用了什么材料，而是从已有的公开文件里，把所有明确提到或隐含的材料来源梳理出来，建立一张有出处可查的关系图。

在动工之前，研究团队首先需要解决两个根本性的问题，而这两个问题才是整件事真正困难的地方——不是技术上的信息提取，而是语义和表示上的挑战。

第一个问题是：什么算"依赖"？这个界定出乎意料地复杂。有些依赖很直接，比如一个模型是在另一个模型的基础上微调出来的，或者训练数据是由另一个模型生成的。但有些依赖就模糊得多：如果一个评估模型只是用来在开发过程中比较不同版本的效果，它算不算依赖？如果研究者受到某篇论文的方法启发，借鉴了其中的某种做法，这算不算？如果某个工具只是用在数据预处理的边角环节，没有直接影响模型的最终权重，这算不算？

研究团队的处理方式是把依赖分成两大类。"直接依赖"指的是实质性地影响了模型权重或训练数据的上游资源，包括用于初始化的基础模型、生成训练数据的模型、做OCR的工具、过滤数据的分类器等。这类依赖还有一个关键特点：它是递归传递的——过滤器模型所使用的训练数据，也算作被过滤的那个下游模型的直接依赖。"间接依赖"则指那些没有直接进入训练，但实质性地影响了开发决策的资源，比如用于比较效果的评估模型、提供方法论启发的参考工作等。而那些仅仅是"提到了某项工作"或"和某个模型做了比较"的引用，则不算在依赖图里。

第二个问题是：同一个东西在不同地方有不同的叫法，怎么认出来？一篇论文可能写"Olmo 3 32B"，而代码仓库里的配置文件里写的是"Olmo-3-32B-Think"，Hugging Face上的版本号又写作"Olmo-3-1125-32B"，这三个名字指的是同一个东西，但也可能不是完全一样的版本。数据集的情况更加复杂：公开文档里可能提到某个数据集的内部名称，或者它的某个子集、某个衍生版本，而这些名称和公开发布的数据集标识符之间的对应关系，需要跨越多个平台才能确认。

为了解决这个问题，研究团队设计了一套"身份格"机制：每个被识别出来的资源，都用一组描述性标签来表示，比如"模型家族：Olmo 3，参数规模：32B，训练阶段：Think"。这个格子有高有低，越往下越具体，越往上越笼统。依赖关系可以挂在最精确的可确认层级上，不强迫系统在证据不足时做出虚假的精确判断。

在实际运行流程上，ModSleuth分三个主要阶段推进。第一阶段是收集素材，也就是把目标模型的所有公开文档——技术报告、模型卡、数据集卡、代码仓库、发布博客——都抓取回来，按照主题整理成批次，便于后续处理长文档。第二阶段是识别实体，从每个文档批次里把提到的所有模型和数据集的名字识别出来，记录原始说法，同时对照身份格进行规范化，标注可能的歧义和冲突。第三阶段是构建依赖关系，重新阅读每个文档批次，对照已经规范化的实体列表，提取具体的依赖关系，每条关系都要有原文出处作为证据。当多个文档对同一关系有不同描述时，系统会尝试合并，如果发现真正的冲突，则标记出来等待人工确认。

完成对目标模型的分析后，ModSleuth会对发现的每一个上游资源重复同样的过程，这样一级一级向上追溯，直到追不到更多公开文档为止。这种递归扩展，才是它能挖出普通人不可能手动发现的深层依赖的关键所在。

在底层技术实现上，ModSleuth使用了Anthropic公司的Claude Code作为智能代理，负责实际阅读和理解文档的工作。研究团队的贡献在于整个框架的设计——如何分解任务、如何管理身份解析、如何验证证据、如何递归扩展——而不是简单地丢给一个AI模型一个大问题然后等答案。

---

三、成绩单：追出了多少依赖关系

研究团队把ModSleuth和几个竞争对手放在一起做了比较，包括OpenAI的GPT-5.5 Pro、GPT-5.4 Pro、ChatGPT Deep Research，以及一个用Claude Code单次提示直接问的基线版本（不包含ModSleuth的多阶段流程设计）。

比较的标准是：每个系统追出了多少条经过独立验证的依赖关系。每条候选关系都会被Claude Sonnet 4.6（配备网络搜索）拿着原始证据去核实，只有能被验证的关系才算数。

结果的差距相当明显。所有单次提示的基线系统表现大致相近，追出的验证依赖关系在171到314条之间，其中GPT-5.5 Pro是最高的314条。ModSleuth在最保守的"仅统计直接与目标模型相关的依赖"这个口径下，追出了484条，比最强基线高出54%。在"统计追溯过程中发现的、与目标模型存在前向可达关系的所有依赖"这个更宽泛的口径下，ModSleuth追出了1060条，超过最强基线的三倍。如果进一步算上整个递归图谱中前向可及的所有依赖，数量达到了1654条。

增益最大的是Olmo 3和Nemotron 3 Super这两个模型，因为它们的训练流程涉及大量中间数据集、生成模型、过滤器和后训练资源，依赖链最为复杂。DR Tulu和SmolLM3相对较浅，各系统在这两个模型上的差距也相应较小。

从宏观数字来看，整个分析合并了四个目标模型的追溯图谱，最终得到一张包含2526个资源节点（1443个数据集、1083个模型）、9112条依赖边、36187条证据锚点的大型依赖图谱。不过，这9112条边中有7458条并不在任何一个目标模型的前向可达范围内，它们是追溯过程中顺带记录的兄弟节点、平行家族资源等，并不计入对应目标的依赖统计。

---

四、打开潘多拉的盒子：依赖图谱揭示了什么

收集到这张依赖图谱之后，研究团队用它做了一件很有意思的事：把各种审计问题转化成对图谱的查询，就像在数据库里搜索一样，然后看看结果能揭示哪些从单个文档里完全看不到的现象。

**数据来源的构成**

在全部验证通过的依赖关系中，直接依赖（实质影响模型权重或训练数据）占了72%，间接依赖（影响开发决策但不进入训练）占28%。值得注意的是，在直接依赖中，通过"数据操作"发挥影响的上游模型——包括生成、过滤、改写、嵌入和去污染——占到了21.2%，而通过直接权重继承（比如从某个基础模型微调）发挥影响的只有1.7%。换句话说，现代AI模型的大多数上游模型依赖，不是通过"继承权重"这种显眼的方式传递的，而是通过悄悄影响训练数据来起作用的。

**内外部依赖的比例**

研究团队还统计了每个目标模型的依赖中，有多少来自开发团队自己的组织（比如Olmo 3来自Ai2研究所，Nemotron 3来自英伟达），有多少来自外部。结果显示，所有四个目标模型中，外部依赖都占到了75%到82%。以Olmo 3为例，它依赖的外部模型达到90个，相比之下内部模型只有13个；外部数据集272个，内部106个。在外部依赖中，来自OpenAI和Qwen（阿里巴巴通义系列）的资源是被依赖最多的，在所有四个目标模型中均如此。

**DR Tulu的隐秘依赖：Claude的影子**

DR Tulu的论文里明确说明，它的训练数据是由OpenAI的模型生成的。但ModSleuth追踪到，论文附录里还提到，训练数据中有一部分来自Ai2的ScholarQA系统生成的轨迹数据。顺着ScholarQA的代码仓库往下看，研究团队发现，ScholarQA的默认生成器使用的是Anthropic的Claude Sonnet 3.7。这就形成了一条在DR Tulu的主文档里完全不可见的依赖链：Claude Sonnet 3.7生成了ScholarQA的输出，ScholarQA的输出被用来构建DR Tulu的训练数据。

**Olmo 3的代码数据里藏着Qwen**

Olmo 3的RL-Zero系列模型，是在Dolci RL-Zero数据集上训练的。追溯Dolci RL-Zero的构建过程，会发现它用到了早期的Olmo 3检查点和代码方向的数据构建流程。再往上追，在Olmo 3的预训练数据处理阶段，Qwen2.5-Coder-32B-Instruct被用来改写代码类数据。这个依赖关系在Olmo 3 RL-Zero系列的任何下游模型卡里都没有被提及。

**评测基准和训练数据的悄悄重叠**

研究团队发现了一种广泛存在、却很少被正视的现象：同一个评测基准，既出现在某个模型的训练侧，又出现在它的评测侧。

Olmo 3在训练用于强化学习的"指令跟随"任务时，从IFEval这个基准数据集里采样了约束条件；而IFEval同时也是Olmo 3对外报告的评测指标之一。GSM8K（一个数学题数据集）在Olmo 2的预训练数据混合中直接出现，同时也是Olmo 2和Olmo 3都报告评测结果的基准。

更系统性的统计显示，在所有被分析的模型中，多个著名基准同时出现在"训练侧"和"评测侧"：GSM8K有25条评测边和43条训练边，MMLU有39条评测边和14条训练边，GPQA有45条评测边和9条训练边，MATH有31条评测边和30条训练边，IFEval有27条评测边和18条训练边，SWE-bench Verified有2条评测边和10条训练边。

这类重叠并不一定意味着有人故意作弊，但它是一种结构性风险：评测的意义在于测量模型在"没见过的题目"上的表现，而当训练集里混入了与测试集有亲缘关系的内容，这个评测就不那么纯粹了。而这种重叠关系，仅从任何一个单独的文档里是看不出来的。

Nemotron系列内部的矛盾则更为直接。Nemotron-3-Super在RL训练阶段使用了基于SWE-Bench-Verified派生出来的数据，然后把SWE-Bench-Verified作为头部评测基准对外汇报。而同属Nemotron家族的Nemotron-Cascade却恰恰相反：它明确把源自SWE-Bench-Verified所包含的代码仓库的SFT样本从训练集里排除掉，就是为了保证评测的干净。同一个数据集，在同一家公司的两个产品里，一个用来训练，另一个用来排污。这个矛盾从外部完全无法察觉，只有通过图谱才能呈现出来。

**许可证通过依赖链悄悄传递：SmolLM3的案例**

SmolLM3（HuggingFace出品的一个小型语言模型）的模型卡里列出了FineMath作为预训练数据来源。FineMath是一个数学方向的网络文本数据集，它的卡片说明了它使用了一个分类器来筛选数学相关内容。但这个分类器是怎么训练出来的？ModSleuth追踪到，finemath-classifier是用Llama-3-70B-Instruct（Meta的Llama 3系列）打出的"教育价值分"来训练的。

这就形成了一条链：Llama-3-70B-Instruct的输出 → finemath-classifier的训练数据 → FineMath的筛选结果 → SmolLM3的预训练数据。而Llama 3的社区许可协议里有一条："你不得使用Llama材料的输出或结果来改善任何其他大型语言模型（Meta Llama 3或其衍生产品除外）。"那么，用Llama生成的注释训练出来的分类器，所筛选出来的数据，用于训练SmolLM3——这算不算违反了这条许可证条款？这是一个真实存在的法律解释问题，而这整条依赖链在SmolLM3自己的文档里根本没有提及。

**谁在背后充当"判官"**

在强化学习阶段，训练过程需要一个"评判者"来决定哪些模型回答更好，从而给予奖励信号。这个评判者的偏好，会实质性地塑造最终模型的行为风格。ModSleuth追踪到，Qwen3-32B被用作Olmo 3 RL训练中针对开放性问答的评判者，而且在没有可验证标准答案的情况下直接作出判断。也就是说，Qwen3-32B的品味，在一定程度上决定了哪些Olmo 3的RL训练样本被保留、被奖励。

Nemotron-3-Super用于RLHF（基于人类反馈的强化学习）的生成式奖励模型，其基础模型是Qwen3-235B-A22B-Thinking-2507。要了解这条依赖链，需要同时读Nemotron的技术报告、这个奖励模型的模型卡，以及它所使用的偏好数据集的卡片，才能把完整的链条拼出来：Qwen3奠基 → 生成式奖励模型 → Nemotron-3-Super的RLHF训练。

在所有被分析的模型中，承担生成器、过滤器、改写器和评判者角色最多的上游模型集中在少数几个家族：Qwen2.5-32B-Instruct被使用了70次，DeepSeek-R1被使用了43次，Llama-3.3-70B-Instruct被使用了36次，Qwen3-32B被使用了33次，GPT-4.1被使用了32次。整个行业的合成数据构建，高度集中在这几个上游模型身上。

**代码里才有真相**

研究团队还发现，论文和模型卡里的描述往往过于粗略，真正精确的依赖信息藏在训练脚本、YAML配置文件和数据处理代码里。Nemotron的训练数据混合配置文件里有占位符行，需要运行一个单独的fill_placeholders.py脚本才能填入DAPO-Math和Skywork-OR1的实际内容，配置文件本身并不完整。SmolLM2的模型卡指向SmolTalk数据集，SmolTalk的说明宽泛地描述了"摘要、改写、Magpie风格指令数据"等成分，但代码里才写清楚：摘要分支加载的是CNN DailyMail，通过Qwen2.5-72B-Instruct处理；Magpie-Ultra分支用Llama-3.1-405B-Instruct生成指令，然后用Llama-3.1-8B-Instruct过滤。Olmo 3的DPO训练脚本也是如此：论文里对DPO数据的描述很笼统，但32B-Instruct的训练脚本里的文件名里直接编码了上游生成器的名字，包括GPT-3.5和GPT-4o的偏好对来源。

**被记录下来的良好实践**

当然，依赖图谱不只是揭示问题，它也把一些良好的开发实践清晰呈现出来。Ai2团队在构建Olmo 3的预训练数据时，对三个数据集采取了"换老师"的策略：CraneMath在实现SwallowMath的数学数据改写方法时，把原方案里的Llama换成了Qwen3；CraneCode在实现SwallowCode风格的代码改写时，用Qwen2.5-Coder-32B-Instruct替换了Llama；MegaMath在复现MegaMath方法论时同样换用了Qwen3。这样做是为了绕开Llama许可证条款的限制，使用许可更宽松的上游模型。

Olmo 3在使用包含Llama-Nemotron后训练数据的训练混合时，专门过滤掉了其中被Llama模型处理过的样本，只保留DeepSeek和Qwen系列处理的部分。Nemotron-Cascade则在数据集卡里详细记录了去污染的操作定义：凡是源代码仓库出现在SWE-Bench-Verified中的SFT样本，一律在SFT之前剔除，而不是仅仅做文本级别的重叠检查。这些信息散落在各自的文档里，只有通过依赖图谱，才能把它们作为一种系统性的实践模式识别出来。

---

五、这些发现意味着什么，我们能做什么

说到底，这项研究的核心信息并不复杂：一个AI模型到底站在谁的"肩膀"上，这件事现在几乎没有任何系统性的机制去弄清楚和记录清楚。这不是哪家公司特别懒惰或特别不诚实，而是整个行业的发展速度远远超过了配套的文档和审计机制。

依赖链的混乱带来的不只是学术上的不雅观，它有实际后果。许可证风险可以在多跳传递后以意想不到的方式冒出来，被污染的数据可以通过训练链传递到完全没预料到的地方，用于评测的模型可能和被评测的模型共享了过多的"上游亲缘关系"，让评测结果变得不那么客观。

研究团队自己也承认，ModSleuth目前只能追踪有明确公开文档的依赖，那些没有写出来的、proprietary的、或者内部流程中用到的上游资源，仍然是一个无法触及的盲区。他们追出来的，是真实依赖关系的一个下界，而非全貌。同时，整个系统的验证流程仍然依赖Claude Code，这意味着同一家公司的产品参与了追踪和验证两个环节，存在潜在的系统性偏差。

从更大的视角看，这项研究提出了一个行业层面的诉求：现有的"模型卡"格式太平了，它假设一个模型的依赖关系是浅层的、静态的，可以用几个字段填清楚。但现代AI的开发流程已经是一个多层递归的依赖网络，需要一套能显式表示依赖结构、依据和角色语义的新型文档规范，才能让透明度从口号变成可执行的现实。

这张依赖图谱，以及构建它的工具和方法，已经由研究团队公开发布。ModSleuth的代码和相应的依赖图谱数据，让社区可以在这个基础上继续扩展、修正、探索——毕竟，了解一个AI是怎么来的，是评估和使用它的第一步。对这一课题感兴趣的读者，可以通过arXiv论文编号2606.12385查找完整原文。

---

Q&A

Q1：ModSleuth追踪的是什么类型的依赖关系？

A：ModSleuth追踪的是大型语言模型在开发过程中对其他模型和数据集的各种依赖关系，包括直接依赖（比如用某个模型生成训练数据、用某个分类器过滤数据、从某个模型初始化权重）和间接依赖（比如用某个模型做性能评测从而影响开发决策）。它只追踪公开文档中有记录的依赖，因此得到的是真实依赖关系的下界。

Q2：SmolLM3和Llama许可证的问题严重吗？

A：这是一个开放的法律解释问题，目前没有定论。依赖链是：Llama-3-70B-Instruct打出教育价值评分，这些评分被用来训练finemath-classifier，该分类器筛选出FineMath数据集，FineMath再进入SmolLM3的预训练。Llama 3的社区许可证规定不得用其输出来改善其他语言模型，但"分类器训练注释"算不算"输出"、"改善"的具体含义如何界定，尚无官方解答。这条多跳路径在SmolLM3自己的文档里完全没有提及。

Q3：为什么同一个评测基准会同时出现在训练数据和评测结果里？

A：这种现象大多不是故意的，而是在复杂多阶段的训练流程中自然产生的结构性问题。一个基准的训练集可能被用来构建训练数据，而其测试集仍被用于评测；或者基准相关的合成数据被加入训练，而原始基准仍用于衡量最终性能。这类重叠从任何单一文档中都无法察觉，只有通过跨文档的依赖图谱追踪才能发现。