«Мониторинг оставался зелёным, а ответ — неверным»: AWS показала девять стадий оценки агентов, которые ловят тихую деградацию до продакшена

Что это за пост и о какой системе речь

Пост «Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore» вышел 16 октября 2026 года в блоге Amazon Web Services; авторы — Rui Li, Chandana Srinivas, Mihir Gadgil, Alok Singh и Madhu Samhitha Vangara.

Речь о внутренней системе команды AWS Sales, Marketing, and Global Services Operations, которая обслуживает полевые продажи AWS. Продавец задаёт вопрос на обычном языке в Amazon Quick, а за одним интерфейсом работают несколько специализированных агентов: Performance Insights отвечает за выручку и показатели в границах территории продавца, Customer Insights собирает портрет клиента по использованию продукта, истории обращений, статусу контракта и вовлечённости, Data Insights переводит вопрос в SQL по структурированным данным. Ответы ограничены территорией пользователя и правами его роли.

Ту же систему используют руководители — в том числе для еженедельных бизнес-обзоров, поэтому цифры в ответах должны быть верными. Контур построен на возможностях Amazon Bedrock AgentCore, а вместе с ним в нём участвуют Amazon Bedrock Guardrails, Amazon CloudWatch, Amazon S3 и Amazon Redshift.

Как агент ломается тихо

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

Перед запуском это подтвердилось на самом Customer Insights Agent, и AWS перечисляет четыре найденных случая: агент показал 410,08 доллара выручки клиента за три месяца как «410.08 Million»; выдал показатель Sales Revenue подписанным как Sales Revenue excluding Adjustments; предложил оценку Annual Recurring Revenue, которой в данных не было; и представил собственные расчёты как факты из источника.

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

Окно рассинхронизации: 78% против 38%

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

В одном предпродакшн-тесте только это окно снизило долю успешных прохождений с 78% до 38%. Именно под такие отказы и построены девять стадий, описанных в посте.

Девять стадий: что делает каждая

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

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

Четвёртая — ворота качества. Кандидат прогоняется через полный золотой набор вопросов по всем измерениям, и решение о выкатке становится количественным, а не «выглядит нормально». Инструменты при этом подменяются: заранее фиксируется версионированный набор уже проверенных ответов инструментов, и каждый вызов во время проверки получает ответ из этого набора, а не из живой системы, — поэтому агент проверяется на собственном рассуждении, а не на скорости и доступности инструментов. Сквозной прогон — 200 отложенных вопросов, которые оценивает LLM-судья по рубрике. Ворота закрываются автоматически по любому из трёх условий: агрегированный балл просел относительно предыдущего прогона кандидата; кандидат не обошёл текущую продакшн-базу; доля вопросов ниже порога превысила заданную. Так ловится случай, который скрывает среднее: модель улучшает средний балл, но тихо проваливает больше отдельных вопросов.

Пятая — канарейка: она работает в продакшене непрерывно, по живому трафику и синтетическим сценариям, и ловит то, что не запускал никакой код. Пакетная оценка идёт по двум расписаниям: окна по 30 минут и полный золотой набор раз в сутки на порогах ворот. Тридцать минут выбрали по опыту: 15 минут давали слишком много ложных тревог, а 60 минут позволяли пройти двум часам до регистрации реальной деградации. Одно нарушившее порог окно — сигнал для эксплуатации, а не инцидент: дежурного поднимают только после трёх подряд. Каждый прогон публикует в CloudWatch точность, долю галлюцинаций, обоснованность, задержку и стоимость.

Шестая — защита от злоупотреблений: Amazon Bedrock Guardrails применяются в двух точках каждого взаимодействия. На входе проверяются рамки запроса и инъекции в промпт, на выходе — что чувствительные данные не уходят не тому пользователю и что агент не был переведён в нарушение политики; проверки идут на 100% трафика синхронно, до ответа пользователю. Фильтры контента охватывают категории VIOLENCE, HATE, SEXUAL, MISCONDUCT и INSULTS, а защита промпта — категорию PROMPT_ATTACK с подтипами вроде JAILBREAK. Целевая задержка guardrail-проверок — p99 ниже 50 мс.

Седьмая — A/B-тест: после ворот AgentCore Gateway направляет часть живого трафика между текущим и кандидатным агентом, и кандидат должен победить или не проиграть по всем измерениям, прежде чем выкатываться полностью.

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

Девятая — петля улучшений: рекомендации по системному промпту и по описаниям инструментов строятся по реальным трассам и целевой метрике. Пример из поста: модель дословно воспроизводила суммы и названия клиентов из примеров в промпте, и после замены конкретных значений на плейсхолдеры вида $[AMOUNT] и [CUSTOMER_NAME] чистые галлюцинации упали с 138 до менее 52 на 10 000 ответов, а обоснованность выросла с 93% до 96%.

Что именно поймали на живых данных

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

Отдельный случай — иерархия: Customer Insights Agent и Data Insights Agent вернули разные, но по отдельности верные суммы выручки по одному клиенту — одну по материнскому аккаунту, другую по дочерней компании. Вопрос был в том, определит ли агент нужную рамку по смыслу запроса и роли спрашивающего, а не усреднит значения. Кандидат вернул сумму материнского уровня на вопрос про дочернюю компанию, и ворота зафиксировали расхождение: не неверное число, а верное число не в той рамке.

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

Ещё один случай закончился не алертом, а вопросом продавца: после изменения схемы во входном конвейере агент начал ссылаться на данные не того временного окна. Ночная история с точностью идентификации клиентов показывает масштаб реакции: 98% в 1:30, 81% в 2:00, 80% в 2:30, после чего дежурный инженер спросил у агента, что случилось с точностью между часом и тремя ночи, и получил сводку с указанием на поиск тикеров и сокращённые названия как источник сбоя.

Метрики по уровням: от точности до стоимости успешного ответа

Набор метрик определяется на первой стадии, проверяется на всех девяти и наблюдается в продакшене; он не статичен — по мере накопления опыта добавляются новые измерения.

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

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

Кроме качества измеряются безопасность (доля блокировок, доля нарушений на входе и выходе, задержка guardrail-проверок), производительность (задержки p50, p90 и p99 сквозные и по каждому агенту и инструменту, доля прогонов CI с нарушением порога), стоимость (стоимость запроса, стоимость успешного ответа как стоимость запроса, делённая на долю успеха, и среднее число вызовов инструментов) и эксплуатация: время до обнаружения и устранения с целью меньше четырёх часов, доля инцидентов, найденных оценкой, а не жалобой пользователя, с целью выше 95%, и доля ложных тревог.

Чего здесь нет

Это разбор одной внутренней системы и её контура оценки, а не сравнение платформ и не независимая проверка: все цифры взяты из собственного описания AWS. Часть проверок детерминированные — точность идентификации клиента, корректность SQL, точность маршрутизации, — а часть представляет собой оценку LLM-судьи по рубрике, и это разные по надёжности измерения.

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

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