ModSleuth: Tracing the Invisible Dependencies Behind Open-Source LLMs

Forum topic · ✨步子哥 · 2026-06-11

Summary

Researchers from UC Berkeley and the Allen Institute for AI present ModSleuth, an agentic system that audits the hidden dependency chains behind modern large language models. Because LLM training pipelines rely on other models for data generation, filtering, evaluation, and reward modeling, every open model may sit atop a recursive, poorly documented dependency graph scattered across papers, GitHub repos, and HuggingFace model cards. ModSleuth works in three stages: clue collection from public sources, entity discovery and disambiguation across inconsistent references, and operation-centered dependency graph construction, then recursively expands upstream. Audits of OLMo 2, Amber, Phi-1.5, and OpenELM recovered 1,060 source-code-verified dependencies, revealing multi-hop license obligations, train-evaluation contamination, documentation drift, and model-mediated data selection. The authors argue AI needs an SBOM-like standard for models and that automated auditing is essential as manual tracing is no longer feasible.

When you download an open-source LLM, you think you know where it came from. The model card says: fine-tuned from Llama, trained on open datasets. Looks crystal clear.

But if you keep asking: How was that dataset built? What model was used to filter it? What was the filtering model itself trained on? Does that base model's training data have copyright issues? — a few layers in, you'll find the dependency chain nests like Russian dolls, with each layer's documentation scattered in a different place.

Researchers at UC Berkeley and the Allen Institute for AI call this problem "invisible dependencies" and built an agentic system called ModSleuth to trace them.

The Core Problem: Dependency Graphs Are Fragmented

Modern LLM training pipelines aren't a straight line — they're a complex graph:

Data generation: GPT-4 generates training data
Data filtering: another model screens for high-quality samples
Evaluation: a third model acts as judge
Alignment: DPO/RLHF, where the reward model is yet another independent model

Every step can introduce new model dependencies, and these dependencies are scattered across papers, GitHub repos, HuggingFace model cards, and technical reports. Worse, the documents often contradict each other — the model card says Llama-2, the code actually uses Llama-2-chat; the technical report cites dataset v1, but v2 was actually used.

Human tracing has fallen behind, because the recursive depth and heterogeneity far exceed what manual audits can handle.

How ModSleuth Works: A Three-Tier Detective

ModSleuth is designed like an automated detective team, in three phases:

Phase 1: Clue collection. Given a target model (e.g., OLMo 2), ModSleuth gathers relevant documents from all public sources — papers, model cards, GitHub repos, HuggingFace pages. It doesn't just search; it uses LLMs to understand document content and extract dependency-relevant information.

Phase 2: Entity discovery and disambiguation. This is the hardest part. "Llama-2", "Llama 2", "llama2", "meta-llama/Llama-2-7b" may be the same model, or different versions. ModSleuth must resolve these references across documents, deciding whether they point to the same artifact. That requires understanding version numbers, repo paths, release dates, and other context.

Phase 3: Dependency construction and reconciliation. All evidence is aggregated into a dependency graph. The key innovation is an operation-centered representation: instead of simply saying "A depends on B", it says "A's data-filtering operation used B". This fine-grained representation distinguishes different types of dependency relations.

ModSleuth then recursively expands — repeating the process for every discovered upstream dependency until the graph converges.

What Did It Find? 1,060 Source-Verified Dependencies

ModSleuth audited four public LLMs (OLMo 2, Amber, Phi-1.5, OpenELM) and recovered 1,060 dependency edges backed by source-code evidence. Key findings:

Multi-hop license obligations. Model A used data generated by model B, which was fine-tuned from model C, which has a non-commercial license. Model A is then effectively bound by C's license — but this three-hop relationship is entirely invisible in A's documentation.

Train-evaluation coupling. Some models have hidden dependencies between training data and evaluation benchmarks — models or data used in evaluation indirectly contributed to building the training data, so evaluation results may be contaminated.

Release vs. reality mismatches. The model version claimed in documentation differs from what the code actually uses. This "documentation drift" is common in fast-iterating projects but rarely noticed.

Model-mediated data selection. Training data wasn't hand-picked but filtered by another model. This means the selection process embeds the filtering model's preferences and biases — yet you'd never tell from the final dataset's description.

Why This Matters

Transparency is not a luxury. As the LLM ecosystem grows more complex, "who does my model depend on?" becomes increasingly important — for license compliance, safety evaluation, and bias provenance. ModSleuth demonstrates that manual tracing is no longer realistic; automated auditing is necessary.

The software supply chain analogy. This closely mirrors supply-chain security in software engineering: your app depends on a library, which depends on another library, nested layer by layer. The software industry has developed standards like SBOM (Software Bill of Materials); the AI model world needs a similar "MBOM" (Model Bill of Materials).

The auditor itself needs auditing. ModSleuth uses LLMs to do the auditing, but LLMs have dependencies too — an interesting meta-problem. The authors note, however, that every dependency ModSleuth reports is backed by source-code evidence, not LLM hallucination, which provides verifiability.

Limitations

ModSleuth can only trace dependencies recorded in public documents. If a model used undisclosed internal models (common in commercial models), ModSleuth cannot know. Entity disambiguation also has residual errors — identical names across documents may point to different artifacts.

But as a first step, ModSleuth reveals an overlooked reality: the dependency graphs of modern LLMs are far more complex than we assume, and current transparency practices fall far short.

---

Paper: https://arxiv.org/abs/2606.12385 Code: https://github.com/cal-data-audit/modsleuth Demo: https://modsleuth.cal-data-audit.org Institutions: UC Berkeley, Allen Institute for AI