AWS показывает, как проверять ИИ-агентов в 3 режимах: от отладки до продакшена

Клиент попросил вернуть деньги за заказ и объяснить, как отключить подписку. Агент оформил возврат, вежливо попрощался и забыл про подписку. По скорости ответа всё хорошо, по тону тоже. Для клиента задача осталась незакрытой. В новом материале AWS разбирает, как находить такие провалы через Amazon Bedrock AgentCore Evaluations: проверять отдельные действия агента и результат всего разговора, а затем использовать эти проверки перед релизом и на реальном трафике.

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

Сначала определите, что считается выполненной работой

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

Вернёмся к возврату. Здесь полезны три независимые проверки. GoalSuccessRate оценивает достижение цели за всю сессию. ConversationCompleteness из DeepEval помогает заметить забытый вопрос про подписку. PIILeakage проверяет, не раскрыл ли агент персональные данные. Успешный возврат сам по себе ничего не говорит о двух остальных результатах.

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

Один набор проверок для трёх режимов

В AgentCore доступны встроенные оценщики AWS, управляемые проверки из DeepEval и AutoEval, а также пользовательские варианты. Встроенные покрывают качество ответов, выполнение задач, работу с инструментами и другие поведения. В управляемом режиме сторонних проверок сервис размещает код, выбирает модель-оценщика и выполняет запросы на своей инфраструктуре. Пользовательские варианты позволяют менять модель, инструкции и критерии оценки.

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

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

Объединять проверки стоит, когда им нужны одни и те же данные и одна модель. Если для одного критерия требуется эталонный ответ, а другой можно оценить по живому диалогу, их удобнее оставить отдельно.

Где заканчивается польза автоматической оценки

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

Отдельное ограничение — сама модель-оценщик. Её балл нужно сверять с тем, что команда считает успехом. Для возврата денег полезно сопоставить оценку диалога с фактическим результатом операции в системе заказов. Хорошее объяснение модели ещё не подтверждает, что деньги действительно вернулись.

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