Аудит невидимых зависимостей LLM: как ModSleuth раскрывает рекурсивную родословную ИИ

Аудит невидимых зависимостей LLM: как ModSleuth раскрывает рекурсивную родословную ИИ

В 2023 году исследователи из Allen Institute for AI запустили OLMo — полностью открытую языковую модель с прозрачным пайплайном обучения. Казалось бы, прозрачность достигнута: веса, код, датасеты, логи — всё выложено публично. Но когда авторы новой работы попытались проследить, на чём конкретно построен OLMo 3, они обнаружили рекурсивный лабиринт из OCR-систем, моделей переписывания, пайплайнов предпочтений и синтетических датасетов — каждый из которых сам зависел от десятков других артефактов. Полная картина ускользала даже от создателей модели. Эта проблема не уникальна для OLMo. Она системная.

Что такое невидимые зависимости в LLM

Современные языковые модели обучаются не на сырых человеческих текстах, а на продуктах других моделей. Синтетические данные генерируются GPT-4, Claude или Qwen. Корпуса фильтруются классификаторами, обученными на размеченных выборках. Предпочтения формируются через judge-модели. Даже решения об архитектуре и гиперпараметрах часто принимаются на основе оценок других систем. Эти зависимости рекурсивны: модель A использует данные от модели B, которая сама обучалась на выходах модели C, и так далее.

Проблема в том, что эта структура фрагментирована. Информация о зависимостях разбросана по техническим отчётам, model cards, репозиториям и датасетам — каждый в своём формате, с непоследовательной номенклатурой и версионированием. Сложность и глубина рекурсии давно превысили человеческие возможности к ручному отслеживанию. Даже эксперты, потратившие часы на аудит одной модели, не смогли построить исчерпывающий граф зависимостей.

Авторы работы формализуют задачу как построение evidence-grounded dependency graph — графа зависимостей над артефактами моделей и датасетов, где каждое ребро подкреплено цитируемым доказательством из публичных источников. Узлы — это модели и датасеты, рёбра — отношения влияния, а каждое ребро снабжено якорем к исходному документу.

Как работает ModSleuth

ModSleuth — это агентная система, которая восстанавливает граф зависимостей исключительно из публичных артефактов релиза. Интересно, что извлечение информации уже не является главным узким местом: современные агентные системы вроде Claude Code способны навигацию и синтез сложной технической документации. Настоящие сложности — семантические и репрезентационные.

Первая проблема — определение самой зависимости. В современных пайплайнах LLM существует множество неоднозначных артефактов: reward-модели, judge-модели, фильтрующие классификаторы, синтетические датасеты. Их влияние варьируется от прямого вхождения в веса целевой модели до косвенного формирования решений об обучении. ModSleuth вводит явную семантику ролей: trained_on, generated_by, filtered_by, transformed_by, embedded_by, decontaminated_against, composed_from для прямых зависимостей и used_for_evaluation, used_for_ablation, inspired_by для косвенных.

Вторая проблема — канонизация идентичностей. Один и тот же артефакт может называться по-разному в разных источниках: allenai/OLMo-2 в репозитории, OLMo 2 в техническом отчёте, OLMo-2-1124 в model card. ModSleuth разрешает эти идентичности через кросс-ссылочный анализ и объединяет в единый граф.

Система работает поэтапно: рекурсивное обнаружение артефактов, извлечение отношений, канонизация, привязка доказательств и валидация. Результат — единый объединённый граф, который поддерживает аудит-запросы в стиле SQL или graph query.

Цифры, которые меняют восприятие

Авторы протестировали ModSleuth на четырёх публично документированных релизах: OLMo 3 (Ai2), Nemotron 3 Super (NVIDIA), DR Tulu (Ai2) и SmolLM3 (HuggingFace). Результаты впечатляют.

ModSleuth восстановил 2526 узлов-артефактов, 9112 рёбер зависимостей и 36187 якорей доказательств. Из узлов 1443 — датасеты, 1083 — модели. При этом многие зависимости моделей входят не через наследование весов, а через сгенерированные, отфильтрованные или переписанные данные.

Проверенные рёбра доминируют прямыми зависимостями — 1191 ребро (72%), то есть артефакты, которые материально влияют на веса или обучающие данные целевой модели. Косвенные зависимости — 463 ребра (28%) — формируют разработку через оценку, абляцию, заимствование методологии.

Но самый неожиданный вывод — распределение внутренних и внешних зависимостей. 75–82% проверенных рёбер исходят извне организации-разработчика. OLMo 3 от Ai2 использует 90 внешних моделей против 13 внутренних. OpenAI и Qwen оказались наиболее востребованными внешними организациями во всех четырёх исследованных релизах. Даже компании с репутацией открытости зависят от закрытых поставщиков на большинстве этапов пайплайна.

Ещё один контринтуитивный факт: upstream-модели чаще влияют на downstream-системы через операции с данными, чем через прямое наследование весов. Генерация, фильтрация, трансформация, эмбеддинг и деконтаминация дают 350 проверенных рёбер (21,2%), тогда как прямое checkpoint-lineage — всего 28 рёбер (1,7%). Модели передают знания не через копирование параметров, а через обработку данных.

Почему ручной аудит больше не работает

Авторы попытались построить небольшие графы зависимостей вручную — и быстро поняли, что это невозможно. Даже для одной модели эксперты потратили многие часы на прослеживание зависимостей, но так и не смогли создать сколько-нибудь исчерпывающую картину. Причина не в лени или недостатке квалификации, а в экспоненциальном росте сложности.

Возьмём OLMo 3. Чтобы понять, на чём он построен, нужно изучить технический отчёт, model card, репозиторий с кодом и опубликованные датасеты. В отчёте упоминаются OCR-системы для обработки входных документов — но какие именно модели использовались для OCR? В model card указаны синтетические данные — но какая модель их генерировала и на чём она сама обучалась? В коде фигурируют пайплайны предпочтений — но reward-модель взята из внутнего репозитория или загружена с HuggingFace? Каждый ответ порождает три новых вопроса, и рекурсия уходит на глубину, которую человек не способен удержать в рабочей памяти.

К тому же источники противоречат друг другу. Технический отчёт называет датасет одним именем, model card — другим, а код ссылается на третье. Без автоматической канонизации невозможно понять, что это один и тот же артефакт. Анализ, ограниченный только статьями, model cards или кодом по отдельности, пропускает большинство зависимостей — потому что каждый тип источника фиксирует лишь фрагмент полной картины.

Почему это важнее, чем кажется

Графовое представление превращает аудит-вопросы из ручного поиска по документам в исполняемые запросы. Можно спросить: «Какие лицензионно-рискованные многошаговые пути ведут к этой модели?» или «Какие артефакты одновременно участвуют в обучении и оценке, создавая конфликт интересов?» Структурированные запросы находят паттерны, невидимые при чтении отдельных источников.

Авторы обнаружили несколько классов проблем. Лицензионные многошаговые пути: модель может формально соответствовать open-source лицензии, но зависеть от артефактов с коммерческими ограничениями на втором или третьем уровне рекурсии. Структурная связь обучения и оценки: когда один и тот же артефакт используется и для тренировки, и для бенчмаркинга, это создаёт неявный data leakage. Несоответствие между опубликованными и реально использованными артефактами: model card декларирует один набор данных, а граф показывает другой. Непоследовательность документации: одно и то же отношение описано по-разному в разных источниках, что затрудняет верификацию.

Эти проблемы не академические. Они влияют на юридическую чистоту моделей, на достоверность бенчмарков, на возможность регуляторного аудита. Европейский AI Act требует документирования обучающих данных. Но если половина «обучающих данных» — это синтетические тексты, сгенерированные другими моделями, документация должна включать и их родословную. Иначе compliance превращается в формальность.

Что это значит для бизнеса и разработчиков

Для инженеров, выбирающих модели для production, эти выводы меняют подход к due diligence. Раньше достаточно было проверить лицензию самой модели и качество на бенчмарках. Теперь нужно задавать вопросы о втором и третьем уровне зависимостей: на чём обучалась модель, которая генерировала обучающие данные? Какие фильтры применялись и кто их создал? Используется ли один и тот же датасет для тренировки и для оценки?

Для юристов и compliance-офицеров ситуация ещё сложнее. Лицензия Apache 2.0 на веса модели не гарантирует, что все данные в пайплайне имели совместимые лицензии. Если синтетические данные сгенерированы коммерческой моделью, а её terms of service запрещают использование выходов для обучения конкурирующих систем, вся цепочка может быть под вопросом. ModSleuth позволяет выявлять такие риски до того, как они превратятся в судебные иски.

Для исследователей в области безопасности ИИ рекурсивный аудит открывает новый инструментарий. Вместо того чтобы проверять alignment конечной модели в вакууме, можно проследить, какие компоненты пайплайна влияют на каждый аспект поведения. Это позволяет локализовать проблемы: если модель демонстрирует неожиданные bias или failure modes, аудит зависимостей покажет, на каком этапе они были введены — в генерации данных, в фильтрации, в оценке предпочтений или в самой архитектуре.

Сравнение с базовыми подходами

Авторы сравнили ModSleuth с четырьмя базовыми подходами: GPT-5.5 Pro, GPT-5.4 Pro, Claude Code с одним промптом и ChatGPT Deep Research. Разница колоссальна.

GPT-5.5 Pro восстановил 314 проверенных рёбер суммарно по четырём моделям. GPT-5.4 Pro — 283. Однопромптовый Claude Code — 275. ChatGPT Deep Research — 171. ModSleuth в режиме unbounded — 1060 рёбер, более чем в три раза больше лучшего базового подхода. Даже в консервативном режиме depth-1 (только прямые зависимости целевой модели) ModSleuth показывает 484 ребра — на 54% больше, чем GPT-5.5 Pro.

Ключевое отличие не в качестве извлечения информации — современные LLM и агенты справляются с чтением документации. Разница в структурированном подходе: декомпозиция на этапы, явная семантика зависимостей, канонизация идентичностей и рекурсивное построение графа. Без этой архитектуры даже самые мощные модели теряются в фрагментации.

Часто задаваемые вопросы

Почему компании не раскрывают зависимости сами?

Часто потому, что и сами не знают полной картины. Рекурсивные зависимости распределены между командами, проектами и даже организациями. Model card пишет одна команда, код выкладывает другая, датасеты публикует третья. Никто не владеет полным графом. К тому же некоторые зависимости коммерчески чувствительны: признание, что open-source модель обучена на синтетических данных GPT-4, может вызвать вопросы у сообщества.

Может ли ModSleuth работать с закрытыми моделями?

Нет — система опирается исключительно на публичные артефакты. Для закрытых моделей вроде GPT-5.5 или Claude Opus 4.7 публичная документация слишком разрежена, чтобы построить полный граф. Это создаёт асимметрию: open-source модели подвергаются более строгому аудиту, чем закрытые, хотя последние могут иметь не менее сложные зависимости.

Как это связано с безопасностью ИИ?

Прямо. Если модель прошла safety-фильтрацию, но фильтр сам обучен на данных от непроверенного источника — гарантии безопасности размываются. Рекурсивный аудит позволяет отслеживать, какие компоненты пайплайна влияют на alignment, и проверять их происхождение. Это особенно важно для критических применений: медицинских диагностических систем, юридических ассистентов, финансовых аналитиков.

Итог

Эпоха «одной модели, одного датасета, одной команды» закончилась. Современные LLM — это экосистемы из тысяч взаимозависимых артефактов, и большинство этих зависимостей остаются невидимыми даже для создателей. ModSleuth показывает, что проблема решаема: с правильной архитектурой агентной системы, явной семантикой зависимостей и графовым представлением можно восстановить тысячи проверенных связей из фрагментированной публичной документации.

Но технология — только полдела. Вторая половина — культурная. Сообщество должно перейти от плоской документации к структурированному раскрытию зависимостей. Model cards, technical reports и dataset documentation должны явно представлять не только состав обучающих данных, но и их рекурсивную родословную. Без этого прозрачность ИИ останется призрачной — красивой на словах, но непроверяемой на практике.

← Все записи