Как понять, что сломало ИИ-агента: модель или обвязка

Когда ИИ-агент ошибается, спор обычно быстро сводится к удобной версии: виновата модель, промпт или API. Новая работа Scale AI предлагает более практичный подход — искать не «кто плохой», а конкретный стык, где произошёл сбой, и чинить именно его.

Почему «агент сломался» — слишком общий диагноз

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

Для обычной команды это полезно тем, что экономит время и деньги. Если сразу идти в дообучение, можно неделями лечить не ту причину и так и не исправить ошибку. Поэтому вопрос стоит ставить иначе: на каком именно стыке компонентов возникла проблема и какая сторона отвечает за ремонт.

Что показала практика: зелёные тесты не спасают

Автор приводит три случая из собственного проекта, где метрики были зелёными, а агент всё равно ломался. При загрузке нормативного корпуса в векторную базу молча пропадало 34% чанков: в хранилище осталось 6861 точка из 10 414, но логи показывали, что всё прошло нормально, а проверочные вопросы просто не попадали в потерянные фрагменты.

Во втором случае состязательный аудит выявил 14 дефектов, и половина из них скрывалась в самих оценочных тестах. Третий пример ещё нагляднее: smoke test на PDF был написан через any(), поэтому если выжил хотя бы один документ из трёх, тест считался успешным. Модель при этом не меняли и не дообучали — исправлять пришлось загрузку, конвейер и сами тесты.

Для бизнеса и команд разработки это важный сигнал: зелёные метрики не гарантируют, что система действительно работает. Особенно если агент участвует в отчётах, экспертизе или других задачах, где ошибка может стоить репутации и денег.

Каталог отказов помогает быстро искать виновника

Авторы статьи Scale AI собрали таксономию из 41 режима отказа: 36 отнесли к стороне модели, а 5 — к окружающим компонентам. Вся схема построена вокруг взаимодействий между девятью компонентами: моделью, владельцем, оценщиком, третьей стороной, а также обвязкой — контекстом, памятью и инструментами — и внешним и локальным окружением.

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

Что можно взять себе уже сейчас

Если у вас есть ИИ-сервис или агент, начните с простого: разделяйте сбои по месту возникновения, а не по общему ощущению «что-то сломалось». Смотрите на логи загрузки, тесты, память, инструменты и окружение отдельно — так быстрее станет понятно, где именно нужен ремонт.

Это особенно полезно для предпринимателей, маркетологов и офисных команд, которые запускают ИИ в рабочие процессы. Такой подход помогает не тратить бюджет на лишнее дообучение, быстрее находить реальные причины ошибок и увереннее использовать ИИ там, где цена сбоя высока.