Почему «зелёный» дашборд не гарантирует качество AI-агента
Дашборд горит зелёным. Все латентности в пределах SLA, процент успешных завершений держится на уровне 99,5%, ошибки сервера отсутствуют. Техническая команда спокойна. Бизнес получает поток жалоб от пользователей: агент поддержки врёт в ответах, агент бронирования подтверждает несуществующие слоты, агент аналитики рисует отчёты с вымышленными цифрами. Знакомая картина для тех, кто уже запустил AI-агентов в продакшен.
Этот разрыв между техническими метриками и реальным качеством работы - следствие фундаментального ограничения классического мониторинга. Инфраструктурные ошибки - сетевые таймауты, исключения в коде, отказы внешних API - детектируются мгновенно. Они оставляют чёткий след: стектрейс, HTTP-статус 500, превышение порога latency. Логические ошибки агента не оставляют такого следа. Агент успешно завершает цепочку вызовов, возвращает результат - и этот результат неверен. Система мониторинга фиксирует успех. Пользователь фиксирует провал.
Этот класс дефектов называется поведенческими сбоями (behavioral failures). Они не ломают пайплайн выполнения, не выбрасывают исключений, не нарушают контракты API. Они нарушают ожидания пользователя и бизнес-логику. Традиционные метрики - latency, error rate, throughput - не коррелируют с удовлетворённостью пользователей, когда речь идёт об AI-агентах. Агент может отвечать за 200 миллисекунд и при этом систематически галлюцинировать данные.
Проблема обостряется тем, что AI-агенты - это недетерминированные системы. Один и тот же промпт может дать разные результаты на разных вызовах. Ошибка может проявляться только в 5% сессий, но для этих 5% пользователей агент полностью бесполезен. Стандартный мониторинг, построенный на агрегации метрик, размазывает эти 5% по общему потоку и прячет проблему.
Анатомия поведенческого сбоя: что ломается на самом деле
Поведенческие сбои не монолитны. Они распадаются на три основные категории, каждая со своей механикой возникновения и своими последствиями для бизнеса. Разберём их на конкретных примерах из продакшена.
Галлюцинации: когда агент выдаёт желаемое за действительное
Агент технической поддержки получает запрос: «Как настроить интеграцию с Salesforce через ваш коннектор?» В базе знаний компании нет статьи про Salesforce-коннектор - продукт не поддерживает такую интеграцию. Корректный ответ: «Прямая интеграция с Salesforce отсутствует, доступны альтернативные сценарии через API». Вместо этого агент генерирует пошаговую инструкцию из пяти пунктов с несуществующими названиями эндпоинтов и вымышленными параметрами аутентификации. Пользователь тратит два часа, пытаясь воспроизвести инструкцию, находит несуществующие настройки и эскалирует проблему с формулировкой «ваш продукт сломан».
Стандартные метрики точности не помогают. Агент не сомневается в ответе - он выдаёт его с высокой уверенностью. Фактическая корректность ответа не измеряется ни одной инфраструктурной метрикой. Галлюцинация выглядит как успешный вызов: агент получил запрос, обратился к базе знаний, сгенерировал ответ, вернул пользователю. Цепочка завершена без ошибок.
Отловить галлюцинации можно только через анализ полного контекста диалога и сопоставление ответа агента с фактическим содержимым источников, на которые он ссылается. Без такого анализа вы будете узнавать о проблеме из тикетов второй линии поддержки - с задержкой в дни или недели.
Пропуск шагов: когда агент «забывает» важное действие
Агент бронирования переговорных комнат получает задачу: «Забронируй переговорную на вторник, 10:00-11:00, 6 участников, нужен проектор». Ожидаемая последовательность: проверить доступность комнат с проектором на заданный слот → выбрать подходящую → подтвердить бронирование → отправить приглашения участникам. Фактическая последовательность: агент сразу подтверждает бронирование первой попавшейся комнаты, не проверив её доступность и наличие проектора. Система бронирования возвращает ошибку «конфликт расписания», но агент уже сообщил пользователю об успехе.
Такие сбои часто вызваны нечёткими инструкциями в системном промпте или неправильной интерпретацией контекста. Агент «решает», что шаг проверки опционален, потому что в похожих сценариях он обходился без него. Проблема усугубляется тем, что пропуск шага не всегда приводит к немедленной ошибке - иногда результат выглядит корректным, но содержит скрытую некорректность, которая всплывёт позже.
Неверный выбор инструмента: когда агент «стреляет из пушки по воробьям»
Агент для анализа данных получает запрос: «Сколько пользователей зарегистрировалось вчера?» Корректный путь - сгенерировать SQL-запрос к базе данных и выполнить его. Вместо этого агент вызывает LLM для генерации ответа, передавая в контекст всю историю регистраций за месяц. Запрос, который должен стоить доли цента и выполняться 50 миллисекунд, превращается в вызов стоимостью 15 центов и длительностью 3 секунды. Ответ при этом может быть верным, но экономика агента разрушается на масштабе тысяч запросов.
Этот тип сбоя особенно коварен. Агент не ошибается с точки зрения результата - он ошибается с точки зрения процесса. Метрики качества показывают 100% точности, а финансовая модель агента уходит в минус. Мы разбирали эту проблему в статье про экономику AI-агентов: агент, прошедший все метрики качества, может быть отключен финансовым директором из-за стоимости успешного решения.
Общая черта всех трёх категорий: агент не генерирует явных ошибок. Инфраструктурный мониторинг молчит. Пользователь страдает.
Как Amazon Bedrock AgentCore видит невидимое: анализ трейсов без сигналов ошибок
Решение проблемы поведенческих сбоев требует смены парадигмы мониторинга. Вместо отслеживания сигналов ошибок нужно анализировать полные журналы выполнения агента - трейсы. Именно на этом принципе построен Amazon Bedrock AgentCore.
Трейс агента - это не просто лог запросов и ответов. Это детальная запись всей цепочки рассуждений: какие инструменты были вызваны, с какими параметрами, в каком порядке, какие промежуточные результаты получены, как агент интерпретировал эти результаты перед следующим шагом. Трейс содержит достаточно информации, чтобы восстановить логику принятия решений и сравнить её с ожидаемой.
AgentCore анализирует трейсы без опоры на сигналы ошибок. Система не ищет стектрейсы и эксепшены - она ищет отклонения от нормального паттерна поведения. Нормальный паттерн не задаётся вручную. Он выводится статистически из исторических данных: как обычно выглядит успешная сессия бронирования, какие шаги и в каком порядке выполняет агент, какие параметры передаёт в API.
Кластеризация паттернов отказов: группировка проблем по сути
Когда AgentCore обнаруживает аномалию в трейсе, он не просто регистрирует инцидент. Он группирует схожие аномалии в кластеры. Все сессии, где агент пропустил шаг проверки доступности перед бронированием, попадут в один кластер. Все сессии, где агент вызвал не тот API для получения данных о пользователе - в другой.
Кластеризация решает проблему «шума» в мониторинге. Вместо тысяч разрозненных алертов команда получает несколько осмысленных групп проблем. Каждый кластер - это кандидат на root cause analysis. Система фактически говорит: «Вот паттерн аномального поведения, он повторяется в 340 сессиях за последнюю неделю, все случаи выглядят похоже - агент использует метод POST вместо GET при запросе статуса заказа».
Такой подход радикально сокращает время от обнаружения проблемы до её диагностики. Команда не разбирает каждый инцидент по отдельности - она анализирует кластер и находит общую причину. Это особенно важно для недетерминированных систем, где один и тот же баг может проявляться по-разному в разных сессиях.
Ранжирование проблем: приоритизация по доле затронутых сессий
Обнаружить проблему мало. Нужно понять, какую проблему чинить первой. AgentCore использует метрику «доля затронутых сессий» - процент пользовательских сессий, в которых проявился данный сбой, от общего числа сессий за период.
Этот подход отличается от традиционной приоритизации по частоте ошибок. Частая ошибка может затрагивать 0,1% сессий и быть косметической. Редкая ошибка может затрагивать 20% сессий и делать агента бесполезным для пятой части пользователей. Доля затронутых сессий фокусирует команду на проблемах с наибольшим бизнес-влиянием.
Пример ранжирования: кластер «галлюцинации в сценарии onboarding» затрагивает 23% сессий новых пользователей. Кластер «пропуск проверки доступности» - 8% сессий бронирования. Кластер «неверный выбор инструмента» - 3% аналитических запросов. Приоритет очевиден: сначала чиним onboarding, потом бронирование, потом аналитику. Ресурсы команды распределяются туда, где они дадут максимальный эффект для пользователей.
Такой подход перекликается с идеей из нашего разбора побочного продукта AI-агента: реальная ценность часто обнаруживается не там, где вы её запланировали. AgentCore помогает увидеть, где агент создаёт ценность, а где - разрушает её.
От инсайтов к действию: как приоритизировать исправления на основе данных о сбоях
Данные о поведенческих сбоях бесполезны без процесса их конвертации в исправления. Предлагаем фреймворк из пяти шагов, который можно внедрить в существующий цикл разработки агента.
Шаг 1: Сбор данных. Включите полное логирование трейсов для всех сессий агента. Трейс должен содержать: последовательность вызовов инструментов с параметрами, промежуточные результаты, финальный ответ, идентификатор сессии, временные метки. Без этого шага все последующие невозможны.
Шаг 2: Кластеризация. Сгруппируйте аномальные сессии по схожим паттернам. На старте это можно делать вручную, анализируя выборку трейсов. При масштабировании потребуется автоматизация - либо через AgentCore, либо через собственные скрипты на основе эмбеддингов трейсов и алгоритмов кластеризации.
Шаг 3: Ранжирование. Для каждого кластера вычислите долю затронутых сессий. Отсортируйте кластеры по убыванию этой доли. Топ-3 кластера - ваш бэклог на ближайший спринт.
Шаг 4: Root cause analysis. Для каждого приоритетного кластера проведите анализ корневой причины. Типичные причины: нечёткий промпт, отсутствие валидации промежуточных результатов, неправильный выбор инструмента в оркестраторе, неполный контекст, передаваемый агенту.
Шаг 5: Исправление и верификация. Внесите изменение - перепишите промпт, добавьте проверочный шаг, уточните описание инструментов. Разверните изменение на canary-группе пользователей. Сравните долю затронутых сессий до и после. Если метрика упала - раскатывайте на всех пользователей.
Конкретный пример: кластер «галлюцинации в сценарии onboarding» затрагивает 23% сессий. Root cause analysis показывает, что агент не проверяет наличие информации в базе знаний перед генерацией ответа. Исправление: добавляем в промпт инструкцию «Если информация не найдена в базе знаний, честно сообщи об этом пользователю и предложи альтернативные каналы получения помощи». После внедрения доля затронутых сессий падает до 4%. Оставшиеся 4% - другой кластер, требующий отдельного анализа.
Процесс итеративен. После исправления топ-проблемы вы переходите к следующей в рейтинге. Качество агента растёт не от добавления новых фич, а от систематического устранения поведенческих сбоев. Подробнее о метриках качества агентов мы писали в разборе IssueBench от LangChain - синтетического бенчмарка для оценки агентов-диагностов.
Ограничения подхода и что делать, если AgentCore недоступен
Amazon Bedrock AgentCore - проприетарное решение, привязанное к экосистеме AWS. Если ваш стек построен на других облаках или on-premise, прямого доступа к этому инструменту у вас нет. Однако принципы анализа трейсов универсальны и воспроизводимы.
Первый принцип: логируйте всё. Трейс агента - это не роскошь, а обязательный компонент продакшен-системы. Без трейсов вы слепы. На практике это означает, что каждый вызов агента должен оставлять структурированный журнал: идентификатор сессии, временная метка, тип действия (вызов инструмента, генерация ответа, проверка условия), входные параметры, выходные данные, идентификатор используемого инструмента.
Второй принцип: анализируйте паттерны, а не инциденты. Не ждите явных ошибок. Ищите отклонения от нормы. Норму можно определить статистически: для каждого типа сессий вычислите типичную последовательность шагов, типичные параметры вызовов, типичную длительность. Всё, что выбивается за пределы нормы - кандидат на проверку.
Третий принцип: приоритизируйте по влиянию на пользователей. Доля затронутых сессий - универсальная метрика, не зависящая от конкретного инструмента. Считайте её для каждого выявленного паттерна аномалий.
Для практической реализации можно использовать open-source инструменты. LangSmith от LangChain предоставляет средства трассировки и анализа. Phoenix (Arize) специализируется на наблюдаемости LLM-приложений и включает кластеризацию аномалий. Оба инструмента требуют настройки, но дают фундамент для построения системы обнаружения поведенческих сбоев без привязки к конкретному облаку.
Ключевое ограничение любого подхода - качество трейсов. Если трейс не содержит информации о промежуточных шагах рассуждения агента, анализ поведенческих сбоев невозможен. Инструмент не решит проблему, созданную архитектурным решением не логировать внутреннее состояние агента. Внедрение мониторинга поведенческих сбоев начинается не с выбора инструмента, а с проектирования агента таким образом, чтобы его поведение было наблюдаемым.
Глубинная проблема здесь та же, что и в случае с кодовыми агентами: скорость генерации результата не должна подменять собой качество и понимание процесса. Агент, работающий как чёрный ящик, неизбежно накапливает скрытые дефекты, которые однажды станут видимыми - через пользовательские жалобы и отток клиентов.