Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
В LLM-агентах можно отделить заявленный «когнитивный» модуль от кода, который действительно меняет результат системы. В работе Shenyang Institute of Technology 18 из 25 проверенных модулей не влияли на рабочий результат; препринт не рецензирован, а числа получили сами авторы. До оценки качества агента команде стоит проверить путь значения от модуля до ответа или управляющего решения.
Как проследить модуль от названия до результата
Аудит начинается не с тестового задания для всего агента, а с кода отдельного модуля. Для каждого компонента проверяют четыре вещи: что он вычисляет, соответствует ли вычисление заявленному механизму, доходит ли результат до рабочего выхода и какие побочные эффекты возникают по пути.
Первый вопрос отделяет алгоритм от константы, таблицы правил или случайного значения. Например, модуль с названием causal reasoning может выглядеть как причинный анализ, но фактически выбирать направление связи по знаку корреляции и возвращать пустой результат при попытке смоделировать вмешательство.
Второй шаг — пройти по цепочке вызовов. Импорт файла и успешное выполнение функции ещё ничего не доказывают: вызывающий код может выбросить результат, заменить его константой или записать только в журнал. Авторы считали значение полезным лишь тогда, когда оно меняло управление системой либо содержимое ответа.
Статическую проверку дополнили вмешательствами в код выбранных 11 модулей. Критерии успеха зафиксировали до запуска экспериментов, чтобы не подгонять объяснение под результат. Затем исследователи меняли входы, отключали связи и проверяли, реагирует ли выход так, как требует заявленный механизм.
Два дефектных компонента также исправили. Это служило контрольной проверкой самого аудита: если после восстановления связи модуль начинал влиять на задачу, проблема заключалась в реализации, а не в принципиальной невозможности проверить механизм.
Вызванный код может оставаться бесполезным
Аудит выявил не только обычный мёртвый код. Некоторые компоненты импортировались, запускались и тратили ресурсы, но их значения не попадали в ответ. Поэтому профилировщик или тест на выполнение мог показать исправную работу, хотя поведение агента не менялось.
Авторы выделили три характерные схемы. В первой компонент подключён, но его никто не вызывает. Во второй функция выполняется, однако вызывающий код игнорирует результат. В третьей модуль получает управление, но не читает содержательные входы и потому одинаково реагирует на разные данные.
Встречались и менее очевидные последствия. Код «голографической памяти» переустанавливал общий генератор случайных чисел процесса. Из-за этого модуль мог менять случайный выбор в других частях системы, хотя собственное вычисление не приносило заявленной пользы.
Ремонт показал, что проверка на достижение выхода находит практически значимые дефекты. После исправления связей доля успешных задач планировщика выросла с 0,028 до 1,000, а ошибка контроллера состояния сократилась на 52%. Значит, часть неработающих механизмов можно восстановить без замены всей архитектуры.
Что меняется в планах разработки агента
Работа не даёт основания считать все архитектуры с названиями из когнитивной науки фиктивными. Основную систему проверили целиком, а во второй архитектуре глубоко исследовали только ядро IIT-ϕ, которое оценивает интеграцию состояния. Там обнаружился настоящий алгоритм, но рабочий путь не подключал проверку значимости из-за пропущенной связи.
Граница результатов проходит на уровне двух конкретных систем. Это не статистическая оценка рынка и не сравнение моделей, языков или сред выполнения. Статические вердикты первоначально составляли LLM-агенты без отдельной проверки согласия между аудиторами, однако для каждого вывода сохранили строки кода, а выбранные модули проверили вмешательствами.
Для продуктовой команды такая работа меняет прежде всего порядок приёмки архитектуры. До общего бенчмарка стоит потребовать для каждого заявленного модуля цепочку вызовов, путь вычисленного значения к выходу и тест, где изменение входа предсказуемо меняет результат. Название каталога, импорт и запись в журнал не должны считаться подтверждением функции.
Этот порядок помогает разделить разные решения. Если реальный алгоритм отключён одной связью, его можно починить и проверить повторно. Если модуль возвращает константу или переименованную эвристику, команде придётся либо реализовать обещанный механизм, либо убрать заявление из документации.
Аудит также стоит проводить до нагрузочных тестов и настройки запросов к LLM. Иначе команда может оптимизировать скорость и стоимость компонента, который выполняется на каждом запросе, но не влияет на ответ. Общая метрика агента такой дефект скрывает: хороший результат способен обеспечить базовый LLM, пока архитектурная надстройка остаётся декоративной.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
