Мониторинг AI-агентов: метрики, ошибки и реакция на сбои

Почему доступный AI-агент может работать неправильно

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

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

В документации Google Cloud по наблюдаемости агентов отдельно рассматриваются взаимодействия с моделью и использование инструментов, включая задержки, ошибки и расход токенов. Это полезная основа технического наблюдения. Конкретный бизнес-результат, например подтверждённую запись в CRM, компании всё равно нужно определить и проверить в собственной интеграции.

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

Какие метрики выбрать для первого рабочего отчёта

Начните с небольшого набора показателей, связанных с решениями. Для каждого показателя укажите формулу, источник, период и владельца. «Качество агента» слишком расплывчато; «доля проверенных ответов без критической ошибки» понятнее, если определены выборка и признаки ошибки. Если данные собираются только по части потока, отчёт должен явно показывать это ограничение.

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

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

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

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

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

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

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

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

Как настроить уведомления, на которые будут реагировать

Уведомление должно содержать понятный симптом, масштаб, время начала и следующее действие. «Агент сломан» бесполезно. «Растёт число неподтверждённых записей в CRM; новые операции временно остановлены; проверьте доступ интеграции» уже помогает дежурному. Не включайте в общий канал исходные сообщения клиентов или секреты: для расследования используйте защищённую ссылку на событие.

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

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

Порядок действий при сбое AI-агента

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

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

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

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

Как находить тихое ухудшение качества

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

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

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

Минимальный план внедрения мониторинга

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

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

Мониторинг AI-агентов не устраняет все ошибки, но позволяет замечать их раньше и ограничивать последствия. Начните с подтверждённого результата, понятной ответственности и нескольких значимых сигналов. Такая основа полезнее большого количества технических графиков, по которым невозможно решить, что именно должна сделать команда.