Когда ИИ-агент ошибается молча: 6 отказов, которые не видно по ответу

ИИ-агент — не чат-бот. Чат-бот генерирует текст. Агент совершает действия: читает документ, решает, какие инструменты вызвать, выполняет многошаговый рабочий процесс и выдает результат, на основании которого без дополнительной проверки действуют системы-потребители — а иногда и люди.

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

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

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

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

Чтобы валидировать агентную ИИ-систему, сначала нужно понять, как именно она может дать сбой. В этом эссе представлена таксономия из шести режимов отказа, которые вместе охватывают все пространство некорректного поведения агента. Для каждого режима нужна своя стратегия тестирования и свой механизм обнаружения. Если смешивать их и сводить любой сбой к формуле «модель ошиблась», тестирование будет ловить поверхностные ошибки, но пропускать структурные.

Два типа отказов: исполнение и рассуждение

Сбои агентных систем естественным образом делятся на две категории в зависимости от того, на каком этапе рабочего цикла агента они возникают.

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

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

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

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

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

Но для тестирования это различие принципиально. Ошибки исполнения требуют анализа трассы выполнения: что именно агент сделал? Ошибки рассуждения требуют верификации результата: что именно агент утверждает?

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

Шесть режимов отказа

Каждый режим отказа мы проиллюстрируем на примере сценария оценки модельного риска. В нем агенту поручено проанализировать портфель из двенадцати моделей машинного обучения (MDL-001–MDL-012), которые банк использует для кредитного скоринга, выявления мошенничества и мониторинга соблюдения требований. Исходный документ содержит структурированные таблицы с метаданными моделей, метриками качества, рейтингами риска, зависимостями и регуляторными требованиями.

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

FM-1: Фактическая галлюцинация

Категория: ошибка рассуждения

Определение: агент утверждает факт, которого нет в исходных материалах, либо факт, который им противоречит.

Пример:

Вопрос: Какой AUC на тестовой выборке у MDL-001?

Эталонные данные (ground truth): 0.8412 — из таблицы 3.1 документа «Оценка модельного риска».

Ответ агента: 0.8934

Агент не выдумал это число на пустом месте. 0.8934 — AUC на обучающей выборке для MDL-001; это значение есть в другом месте того же документа. Агент извлек существующее значение из исходных материалов, но приписал его неверному контексту. Вместо тестовой метрики он выдал метрику на обучающей выборке.

Это наиболее коварный вид галлюцинации: почти правильный ответ. Число настоящее, оно взято из реального документа и относится к нужной модели, но к неправильной выборке, на которой измерялась метрика. Бегло просмотрев результат, человек может принять его за верный. Наивная система оценки, которая проверяет только одно — «есть ли это число в документе?», — тоже сочтет ответ правильным. Ошибку обнаружит только оценка, которая проверяет полный триплет: (MDL-001, has_test_auc, 0.8412).

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

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

FM-2: Некорректное использование инструментов

Категория: ошибка исполнения

Определение: агент вызывает не тот инструмент, передает неверные аргументы или запускает инструменты в неправильном порядке.

Пример:

Запрос: Передай замечание о справедливости модели MDL-001 на экспертную проверку.

Ожидаемый вызов инструмента: submit_escalation(model=”MDL-001″, finding=”fairness”, priority=”high”)

Фактические вызовы инструментов: data_lookup(query=”MDL-001 fairness”), risk_check(model=”MDL-001″)

Агента попросили совершить действие — эскалировать замечание, — но вместо этого он извлек информацию. Он нашел данные и проверил риск. Финальный текст может даже выглядеть вполне убедительно: например, агент подготовит сводку по метрикам справедливости и статусу риска MDL-001. Но эскалация так и не произойдет. Человек, запросивший ее, получит отчет вместо нужного действия.

Почему это важно на практике: некорректное использование инструментов — тот режим отказа, который отличает агентов от языковых моделей. Языковая модель способна лишь генерировать текст, поэтому пространство ее ошибок ограничено тем, что она говорит. Агент может совершать действия, а значит, его ошибки связаны и с тем, что он делает. В банковском контексте вызов data_lookup вместо submit_escalation означает, что замечание по комплаенсу остается без эскалации. Агент формально выполнил внешний запрос: сделал что-то, связанное с MDL-001 и справедливостью модели, — но не достиг фактической операционной цели. Замечание так и не передали на эскалацию.

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

FM-3: Нарушение корпоративной политики

Категория: ошибка исполнения

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

Пример:

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

Вызванные инструменты: data_lookup, risk_check [blocked], submit_escalation

В рабочей системе с правилами управления и контроля автоматическая эскалация без одобрения человека нарушает политику «требуется проверка руководителем». Инфраструктура отработала штатно — инструмент успешно выполнился. А правила управления и контроля не сработали.

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

Нарушения корпоративных политик особенно опасны, потому что в момент совершения они часто остаются незаметными. В логах системы будет успешный вызов инструмента. Результат выглядит корректно. Нарушение всплывает лишь через месяцы во время аудита, когда проверяющий спрашивает: «Кто одобрил эту эскалацию?» — и не находит ни одной записи о согласовании человеком.

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

FM-4: Непоследовательное многошаговое рассуждение

Категория: ошибка рассуждения

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

Пример:

Вопрос: Если MDL-009 даст сбой, какая зависимая модель будет затронута в кредитном скоринге?

Эталонные данные: MDL-001 — согласно таблице зависимостей, MDL-009 представляет собой модель вероятности дефолта, которая входит в конвейер кредитного скоринга MDL-001.

Ответ агента: | MDL-009 | PD-Logistic | Вероятность дефолта | Средний | Операционный… |

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

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

Эмпирические данные выглядят показательно. В тестах на бенчмарке из 520 структурированных вопросов передовая языковая модель набрала 0% на многошаговых задачах на перенос информации при оценке по точному совпадению. Даже после калиброванной повторной оценки, допускающей расхождения из-за перефразирования, результат вырос лишь до 50%. Сбои многошагового рассуждения — не случайные промахи, а системное ограничение.

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

FM-5: Нарушение калибровки уверенности

Категория: ошибка рассуждения

Определение: агент выражает такую степень уверенности, которая не соответствует фактической точности его ответов.

Пример:

Три вопроса, на которые агент ответил, оценив собственную уверенность:

1. Вопрос: Какой AUC на тестовой выборке у MDL-001?
   Ответ: 0.8934 [Уверенность: 8/10] — НЕВЕРНО (правильный ответ: 0.8412)

2. Вопрос: Какой тип модели у MDL-002?
   Ответ: Выявление мошенничества [Уверенность: 8/10] — ВЕРНО

3. Вопрос: Сколько моделей имеют высокий рейтинг риска?
   Ответ: Высокий [Уверенность: 8/10] — НЕВЕРНО (нужно было назвать количество, а не уровень риска)

Агент оценивает свою уверенность в 8/10 для каждого ответа — независимо от того, верен он или нет.

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

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

Почему это сложно обнаружить: метрики точности не выявляют нарушения калибровки. Модель, которая дает верный ответ в 70% случаев и каждый раз заявляет уверенность 70%, в среднем идеально откалибрована, но бесполезна на уровне отдельных предсказаний. Чтобы выявить нарушение калибровки, нужно сопоставлять заявленную уверенность с фактической точностью для каждого предсказания — обычно с помощью диаграмм калибровки (reliability diagrams), ожидаемой ошибки калибровки (Expected Calibration Error, ECE) и максимальной ошибки калибровки (Maximum Calibration Error, MCE). Для этого нужны достаточно большие тестовые наборы, чтобы корректно заполнить интервалы значений уверенности.

FM-6: Повреждение состояния между ходами диалога

Категория: ошибка исполнения

Определение: при многоходовом взаимодействии память или внутреннее состояние агента деградирует, из-за чего он забывает, путает или противоречит информации из предыдущих ходов.

Пример:

• Ход 1 (ввод факта): «Срок завершения проекта — 15 июня 2026 года».

• Ходы 2–4: три не связанных друг с другом вопроса о качестве моделей.

• Ход 5 (воспроизведение): «Когда истекает срок завершения проекта?»

• Ответ агента: «Не найдено релевантной записи в памяти по запросу: “Когда истекает срок завершения проекта?”»

Агенту сообщили факт, затем отвлекли тремя репликами и попросили его воспроизвести. Он не справился. Конкретный механизм зависит от реализации. Система памяти на основе ключевых слов может дать сбой, потому что «срок завершения проекта» с пробелом не совпадает с сохраненным ключом project_deadline с подчеркиванием. Система на основе контекстного окна может не сработать, потому что ранний ход сжали или вытеснили из контекста. Система на основе LLM может потерпеть неудачу, потому что внимание сместилось на более свежие отвлекающие ходы диалога.

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

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

Почему это сложно обнаружить: тестирование в рамках одного хода не выявляет повреждение состояния. В изоляции агент может корректно отвечать на каждый отдельный вопрос. Ошибка проявляется только в многоходовых последовательностях, где ранняя информация должна сохраняться. Для тестирования нужен протокол «ввод факта — задержка — воспроизведение» (teach-delay-recall): агенту сообщают факт, между этим и проверкой вставляют отвлекающие ходы, а затем проверяют, способен ли он вспомнить информацию. На проявление сбоя влияют длительность задержки, характер отвлекающих реплик и сходство между введенными фактами и формулировками вопросов для проверки.

Почему шесть, а не три и не двенадцать

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

Почему не меньше? Если свести все к трем режимам — например, «неверные факты», «неверные действия» и «неверная уверенность», — мы потеряем различия, важные для исправления проблем. Фактическая галлюцинация (FM-1) и непоследовательность в многошаговом рассуждении (FM-4) обе относятся к «неверным фактам», но у них совершенно разные первопричины и для них нужны разные тесты. Галлюцинации требуют проверки по эталонным данным для отдельных фактов. Сбои многошагового рассуждения требуют тестирования согласованности цепочки рассуждений по связанным фактам. Набор тестов, созданный для одного случая, пропустит другой.

Почему не больше? Можно перечислить десятки подрежимов: ошибки в соседней ячейке, нарушения пороговых значений на единицу, извлечение данных из неверного столбца, несовпадение форматов. Но это частные случаи шести режимов, а не самостоятельные типы отказов. Ошибка в соседней ячейке — это фактическая галлюцинация (FM-1), при которой геометрическое расстояние между правильным и выданным значением невелико. Извлечение данных из неверного столбца — тоже галлюцинация, но с конкретной структурной причиной. Выделение таких случаев в отдельные режимы не изменит того, что должен делать конвейер тестирования.

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

Трилемма оценки

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

Современные методы оценки сталкиваются с трилеммой.

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

Методы LLM-судьи (LLM-as-judge) повышают полноту, позволяя языковой модели оценивать эквивалентность ответов, но создают собственный режим отказа. В тестах на бенчмарке LLM-судья с доступом к опорному документу принимал неверные ответы в 80% случаев. LLM видит правдоподобный контекст рядом с поврежденной сущностью, попадает под эффект якоря и объявляет ответ правильным.

Экспертная проверка точна и всестороння, но плохо масштабируется и вносит задержки, несовместимые с конвейерами непрерывной интеграции (CI).

Эта трилемма — не просто академическая проблема. На бенчмарке из 520 структурированных финансовых вопросов оценка по точному совпадению дала передовой языковой модели точность 23,8%. Калиброванная повторная оценка, допускающая различия из-за перефразирования, повысила результат до 63,8%. То есть метод оценки отбрасывал 40% правильных ответов модели — не из-за ошибок самой модели. Но повторная оценка несет и противоположный риск: слишком снисходительный оценщик примет ответ «достаточно близкий к правильному» в предметной области, где близость недостаточна.

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

Подведем итоги

Агентный ИИ создает режимы отказа, которых нет у традиционных языковых моделей. Когда ИИ-система способна совершать действия — вызывать инструменты, запускать рабочие процессы, принимать решения, которым доверяют системы-потребители, — пространство ошибок расширяется от «неверного текста» до «некорректного поведения». Чтобы валидировать такие системы, прежде всего нужно понимать, как именно они дают сбой.

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

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

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

• 21 июля в 20:00. «Разработка ИИ-приложений с Claude Code». Записаться

• 22 июля в 20:00. «Что надо знать про работу LLM моделей». Записаться

• 23 июля в 20:00. «Когнитивные архитектуры: ReAct, Reflection и RAG». Записаться

Больше бесплатных уроков июля смотрите в дайджесте.