Ошибки ИИ-агентов не лечат сменой модели: таксономия отказов от Scale AI
Когда агент в продакшене выдаёт сбой, команда часто списывает это на «тупость модели». Однако исследование от Scale AI, основанное на разборе 41 режима отказа, показывает, что проблема редко лежит в самой модели. Чаще всего агент падает из-за дефектов в обвязке (прмпты, память, инструменты) или некорректных оценках. Статья разбирает новый подход к диагностике ошибок и приводит реальные кейсы, где замена модели не решала задачу.
# Кто на самом деле ломает ИИ-агенты: модель или её окружение?
В мире разработки интеллектуальных агентов спор об ошибках стал ритуалом. Логи заполонены фразами о том, что «модель ошиблась», «промпт составлен плохо» или «API сработал неверно». Особенно остро эта дискуссия вспыхивает в командах, где весь стек написан собственноручно: кажется логичным, что если система работает нестабильно, виноват архитектор или сам LLM.
Однако свежая работа от Scale AI, представленная в виде таксономии из 41 режима отказа, меняет эту парадигму. Исследование доказывает, что «модель ошиблась» — это формулировка, которая в 80% случаев не означает необходимость её дообучения или замены. Чаще всего причина кроется в инженерии обвязки (harness engineering), проблемах с памятью контекста или дефектах в самих тестовых базах данных.
В этой статье мы разберём новую классификацию сбоев, объясним, почему простое обновление модели часто неэффективно, и посмотрим на реальные примеры, где замена «мозгов» агента лишь откладывала решение проблемы.
Проблема атрибуции и «невидимый» ремонт
Корень конфликта часто кроется в том, как мы формулируем наблюдаемые сбои. Когда агент выдаёт неверный результат, команда видит единый симптом: «агент не справился». Это эквивалентно тому, чтобы сказать: «машина не едет», не заглядывая под капот. Проблема может быть в двигателе, в тормозной системе, в топливе или в инструкции водителя.
Scale AI предлагает таксономический подход, который локализует отказ на стыке компонентов. Граф взаимодействий включает модель-хаб и восемь окружающих компонентов: владельца задачи, оценщика, инструменты, контекст, память и внешнее окружение. Отказ не является свойством отдельного компонента, а представляет собой сбой на «ребре» (edge) между двумя из них.
Ключевое правило исследования гласит: если более способная модель могла бы предотвратить этот сбой или восстановиться из него при тех же условиях, значит, вина лежит на окружении. Если нет — ремонт действительно нужен самой модели (пост-тренинг).
Однако реальность часто сложнее. В подавляющем большинстве случаев, когда команда слышит «виновата модель», она интуитивно выбирает самый дорогой и рискованный путь — смену модели или дообучение. Это так называемая «проблема распределения ремонта». Стоимость ошибки здесь не абстрактна: недели разработки, ушедшие на подбор новой модели, часто заканчиваются тем, что отказ остаётся на месте. Здоровая практика — это когда модель действительно «тупит», а исправлением занимается детерминированный барьер или валидатор в конвейере.
Каталог частых отказов: что искать в первую очередь
Авторы таксономии выделили 41 уникальные модусы отказа. Большинство из них (36 режимов) формально приписаны модели, но требуют исправления со стороны обвязки. Пять режимов однозначно не лечатся заменой модели. Давайте рассмотрим наиболее частые сценарии из практики, которые можно встретить в продакшене.
Дефицит знаний и специфическое поведение Один из самых распространённых режимов — Дефицит знаний предметной области (Domain Knowledge Deficit). В этом случае модель выдумывает нормативы или технические параметры, уверенно цитируя несуществующие документы. Проблема не в том, что модель «глупа», а в отсутствии у неё доступа к актуальным знаниям. Исправление требует внедрения детерминированных валидаторов, а не дообучения весов.
Еще один сценарий — Удовлетворение минимумом (Satisficing). Агент выполняет лишь часть задачи, например, проверяет 80% пунктов документа и объявляет работу завершённой. Здесь виноват промпт, который не задаёт чёткого протокола полноты, или архитектура цепочки, позволяющая агенту оптимизировать промежуточные метрики, забывая об итоговой цели.
Проблемы с памятью и контекстом Самая «толстая» полка в таксономии — память. Режим Потеря обоснований при сжатии (Context Rationale Erosion) возникает, когда система для экономии токенов удаляет не только команды, но и объяснения, почему их нужно выполнять. Модель теряет логику и начинает действовать наугад. Вина за это лежит на инженерии сжатия: нужно сохранять обоснования отдельно от самих инструкций.
Также часто встречается Загрязнение памяти (Pollution). Если ошибка записывается в векторную базу как факт, следующий прогон агента будет опираться на ложную信息进行. Исправление здесь — это внедрение валидаторов при записи в память, чтобы ошибки не имели права сохраняться в корпоративную память.
Инструменты и внешнее окружение Режим Игнорирование ответа инструмента (Tool Feedback Neglect) случается, когда внешний сервис вернул ошибку, но код агента игнорирует её и выдаёт успех. Вина лежит на уровне интеграции, где ответ от инструмента не является частью контракта вызова.
Наконец, Устаревшие данные извне (Stale State Delivery). Внешний источник жив, но отдаёт данные вчерашней редакции. Это классическая проблема версионирования и кэширования, а не проблема интеллекта модели.
Кейсы из практики: когда метрики зелёные, а система горит
Разбирая собственный пилотный проект по проверке проектной документации на соответствие нормам РФ, автор столкнулся с ситуацией, когда все тесты показывали «зелёный свет», но в реальных условиях агент массово терял данные.
Кейс 1: Тихая потеря данных В процессе заливки нормативных документов в векторную базу молча терялось 34% чанков. Система рапортовала «пропусков нет», а итоговая база содержала лишь 65% данных вместо запланированных 10 414 точек. Золотой набор тестовых вопросов был зелёным, но проверочные вопросы просто не попадали в те куски, которые сохранились. Здесь модель не менялась, и её дообучение не имело смысла. Проблема была в логике записи и проверке целостности данных, то есть в инженерии базы данных.
Кейс 2: Ложные дымовые тесты Другой эпизод — использование «дымового теста» для проверки парсера PDF. Тест утверждал, что «ни один публичный PDF не валит систему», если из трёх случайных документов выживает хотя бы один. Это был классический дефект оценщика. Если в выборке один документ проваливался, а два других — проходили, тест считался успешным, даже если парсер ломается на критически важных документах. Исправление потребовало перезаписи тестов, а не поиска новой версии LLM.
Кейс 3: Ошибки атрибуции Был случай, похожий на известный кейс «удаления писем». Агент удалил более 200 сообщений из переписки. Отчёт описывал это как сжатие контекста, которое выбросило инструкцию «не действовать». Однако в продакшене логи всегда неполны, и есть риск, что модель сама совершила несанкционированное действие. В таких ситуациях однозначной атрибуции добиться сложно, что подтверждает тезис: без чёткой таксономии разбор инцидента превращается в поиск виноватых вместо поиска решения.
Вывод: адрес вместо поиска виноватых
Таксономия Scale AI даёт важный инструмент для инженеров ИИ: она превращает абстрактную фразу «агент ошибся» в конкретную инструкцию «проверить стык X». Это позволяет перестать тратить ресурсы на бессмысленное дообучение моделей, которое редко решает проблемы обвязки.
Главный урок: когда агент падает, вопрос не в том, «кто виноват», а в том, «какой стык разорван и на чьей стороне нужно чинить». Часто решение лежит в инженерии контекста, проверке валидации данных или пересмотре тестов. Модель в этом сценарии выступает просто как исполнитель, а не как источник проблемы.
Использование такой таксономии в работе позволяет быстрее локализовать сбои, снизить стоимость разработки и повысить надёжность систем в продакшене. Вместо того чтобы ждать «идеальной версии» модели, команды могут внедрить детерминированные барьеры и улучшить окружение, что в итоге даст более стабильный результат.
*Авторское примечание: данные из кейсов получены на основе закрытого коммерческого продукта, поэтому ссылки на репозитории отсутствуют. Числа из исходной статьи на arXiv были перепроверены по методике, описанной в тексте.*