ИИ-агенты редко дают сбой. Обычно они отказывают незаметно — и исследования объясняют почему

Агенты на основе больших языковых моделей уже отвечают на обращения в службу поддержки, запрашивают данные из баз и планируют поездки. Когда что-то идет не так, они обычно выдают уверенный ответ и код успешного выполнения. Растущий объем исследований объясняет, почему такие сбои трудно заметить и как инженерные команды учатся их измерять.

Сбой, который выглядит как успех

Традиционное программное обеспечение обычно дает сбои явно. Функция вызывает исключение, сервер возвращает код ошибки, а панель мониторинга загорается красным. ИИ-агент ведет себя иначе. Он работает циклически: языковая модель читает запрос, решает вызвать инструмент — например, поисковый API или базу данных, — читает результат и решает, что делать дальше. На каждом этапе что-то может пойти не так, хотя все сетевые запросы в цепочке завершаются успешно.

Рассмотрим типичный случай. Инструмент для проверки погоды дает сбой и возвращает текст «сервис недоступен» в остальном обычном ответе. Модель читает этот текст, вежливо извиняется или, что хуже, составляет правдоподобный прогноз на основе данных, на которых обучалась. Пользователь получает беглый и связный ответ. В журналах сервера запрос отмечен как успешный, а время отклика — как нормальное. Обычная система мониторинга никак не фиксирует, что что-то пошло не так.

Поставщики моделей описывают тот же пробел в собственной документации. В руководстве Google по Gemini API отмечается, что модель «сама не выполняет функцию». Она лишь предлагает имя функции и аргументы, а вызов выполняет приложение разработчика. Поэтому только приложение во всей системе видит фактический результат. В инженерном руководстве Anthropic по созданию агентов говорится о том, что агентам на каждом этапе нужны «фактические данные» из окружающей среды, например результаты работы инструментов, чтобы оценивать собственный прогресс. Если инструмент сообщает о сбое обычным текстом, эти фактические данные неверны, и агент никак не может это обнаружить.

Это не новая проблема, а лишь более выраженная версия старой. В 2015 году инженеры Google во главе с D. Sculley описали «скрытый технический долг» в системах машинного обучения. По их мнению, большая часть рисков, связанных с системой машинного обучения в промышленной эксплуатации, кроется за пределами кода модели — в зависимостях от данных, конфигурации и вспомогательном коде. Агенты добавляют к этому списку новый уровень. Запросы и описания инструментов — это конфигурация, способная изменить поведение системы без каких-либо изменений в ее коде.

Небольшие правки — большие последствия

Насколько сильно может повлиять небольшое изменение запроса? В статье, представленной на ICLR 2024, Melanie Sclar из University of Washington и ее коллеги изменили только формат запросов с примерами: разделители, интервалы и регистр букв. Смысл остался прежним. И все же точность выполнения той же задачи на LLaMA-2-13B различалась на величину до 76 пунктов. Повышенная чувствительность сохранялась и при использовании более крупных моделей, большего числа примеров и дообучения на инструкциях.

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

То же относится к описаниям инструментов, которые модель читает как часть запроса. В руководстве Anthropic говорится, что определения инструментов заслуживают «не меньшего внимания при разработке запросов», чем основной запрос. В нем описывается агент для программирования, который постоянно ошибался при работе с относительными путями к файлам. Когда инструмент изменили так, чтобы он требовал абсолютные пути, модель стала пользоваться им без ошибок. Сама модель не изменилась — изменилось только прочитанное ею описание.

Один успешный запуск мало что доказывает

Еще одно направление исследований посвящено стабильности результатов. В бенчмарке τ-bench, опубликованном Shunyu Yao и его коллегами из Sierra и представленном на ICLR 2025, моделируются диалоги со службой поддержки, в которых агент должен пользоваться инструментами и соблюдать бизнес-правила. Авторы предложили метрику pass^k: вероятность того, что агент правильно решит одну и ту же задачу во всех k попытках.

Результаты оказались неутешительными. Агент на GPT-4o справлялся примерно с 61% задач в розничной торговле с первой попытки. Когда ему требовалось восемь раз подряд успешно решить одну и ту же задачу, этот показатель снижался примерно до 25%. Демонстрация, которая сработала один раз, мало говорит о том, как система поведет себя при тысячном запуске.

Где дают сбой системы с несколькими агентами

Многие команды теперь объединяют в цепочку несколько агентов: один планирует, другой выполняет, а третий проверяет результат. В исследовании 2025 года, проведенном специалистами из UC Berkeley, — «Почему дают сбой системы на основе больших языковых моделей с несколькими агентами?» — проанализировано более 1 600 размеченных трасс выполнения в семи популярных системах с несколькими агентами. Авторы во главе с Mert Cemri разработали таксономию MAST, включающую 14 типов сбоев в трех группах: проблемы проектирования системы, несогласованность между агентами и проверка выполнения задач.

Главный вывод авторов состоит в том, что многие сбои связаны с проектированием системы, а не только с ограничениями базовой модели. Агенты игнорируют назначенные им роли, теряют нить разговора или объявляют задачу завершенной, не проверив результат. Такие сбои не оставляют сообщений об ошибках. Их можно обнаружить, только если кто-то способен прочитать, что именно сделал каждый агент. В материале Unite.AI о парадоксе нескольких агентов сделан сходный вывод с архитектурной точки зрения: добавление агентов может усилить раннюю ошибку, а не устранить ее.

Как сделать невидимое видимым

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

Несколько проектов с открытым исходным кодом, в том числе Langfuse, Arize Phoenix и AcruxCore, уже используют этот подход. Их исходный код открыт, поэтому команды могут проверить, как сохраняются трассировки, и запустить программное обеспечение на собственных серверах. Эти проекты записывают вызовы моделей и инструментов как спаны одной трассировки и позволяют командам присваивать им оценки качества. Выбор инструмента менее важен, чем один нюанс: в спане инструмента нужно фиксировать то, что он действительно вернул, а не только то, завершился ли сетевой запрос успешно. Иначе описанный выше сбой погодного инструмента останется незамеченным.

Опросы в отрасли показывают, что трассировка стала распространённой практикой, а тестирование отстаёт. В конце 2025 года LangChain провела опрос 1 340 специалистов для отчёта «Состояние инженерии агентных систем». Чаще всего препятствием для внедрения агентов в производство называли качество — об этом сообщили 32% респондентов. 89% организаций заявили, что в той или иной форме отслеживают работу своих агентов, а 62% подробно трассируют отдельные этапы и вызовы инструментов. Лишь 52,4% проводили офлайн-оценку на тестовых наборах, а 37,3% оценивали трафик в реальном времени. Большинство команд могут видеть, что делали их агенты. Но гораздо меньше команд проверяют, правильно ли они действовали.

Оценка ответов в больших масштабах

Трассировки показывают, что произошло. Но они не говорят, был ли ответ хорошим. Проверять вручную каждый диалог невозможно, поэтому команды всё чаще используют вторую модель для оценки — этот подход называют оценкой языковой моделью. В статье, представленной на NeurIPS 2023, Ляньминь Чжэн и его коллеги выяснили, что сильные модели, например GPT-4, совпадали с предпочтениями людей более чем в 80% случаев — примерно с той же частотой, с какой люди соглашались друг с другом.

В той же статье описаны слабые стороны этого метода. Модели-оценщики предпочитают ответ, показанный первым, отдают предпочтение более длинным ответам и могут благоволить тексту, написанному ими самими. Поэтому оценки таких моделей — лишь приблизительные. Они полезны при обработке больших объёмов данных, но их нужно проверять на небольшой выборке примеров, размеченных людьми, случайным образом меняя порядок ответов.

От практики к политике

Такая работа по измерению результатов становится также требованием в области управления. Национальный институт стандартов и технологий США опубликовал свою систему управления рисками ИИ в январе 2023 года. Одна из четырёх её основных функций — «Измерение» — предполагает, что организации должны количественно оценивать риски ИИ, отслеживать их и документировать изменения с течением времени. Для агента трассировки и оценки результатов служат доказательствами, которые требует эта функция.

Что команды могут сделать уже сейчас

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

Исследования указывают на несколько простых практик, многие из которых рекомендуют и крупные разработчики моделей. Практическое руководство OpenAI по созданию агентов советует командам «настроить тесты для определения исходного уровня производительности» до начала оптимизации, а также передавать управление человеку, если агент превышает установленное число неудачных попыток или сталкивается с действием высокого риска. Anthropic рекомендует проводить «тщательное тестирование в изолированных средах» до того, как агенты начнут действовать самостоятельно.

На практике это означает несколько конкретных шагов. Храните версии запросов и описаний инструментов в системе контроля версий, как и версии кода. Проверяйте каждое изменение запроса на одном и том же наборе данных и ожидайте получить диапазон результатов, а не одно число. Запускайте каждый тестовый сценарий несколько раз, поскольку один прогон не выявляет непостоянство результатов. Записывайте результаты работы инструментов в трассировках, чтобы сбой инструмента не оставался скрытым за кодом успешного выполнения. Считайте оценки автоматических моделей приблизительными и сверяйте их с оценками людей.

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