AWS выпустила UAEF: один набор из 36 метрик для агентов на любом фреймворке

Вы собрали агента на LangGraph, он работает, метрики настроены. Потом команда решает перейти на Strands или вынести часть логики в AgentCore, и выясняется, что скоринг, хранилище результатов и отчёты заточены под формат трейсов старого фреймворка. Оценку приходится строить заново, а простой вопрос «стал ли агент лучше после смены промпта?» остаётся без ответа.

AWS предлагает разорвать эту связку. UAEF (Universal Agent Evaluation Framework) — открытый проект под лицензией Apache 2.0 (репозиторий awslabs/uaef). Он отделяет «как фреймворк записал запуск агента» от «как мы оцениваем качество». По данным AWS, им уже пользовались 12 организаций из телекома, здравоохранения и финансов.

Как это устроено

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

Дальше конвейер работает так:

1. Адаптер читает нативный след выполнения (сообщения, вызовы инструментов, передачи между агентами) и превращает его в единый формат AgentTrace. Трейс можно подсунуть готовый, из логов или Langfuse. Либо UAEF сам вызовет агента по ARN или HTTP-эндпоинту на каждом входе датасета.
2. Трейс проверяется на персональные данные (почты, телефоны, номера карт) до сохранения.
3. Движок считает метрики. Их 36, они разложены по 7 измерениям: вызов инструментов, качество ответа, ответственный ИИ, производительность, многошаговый диалог, координация нескольких агентов и рассуждения.
4. Результат записывается как эксперимент: метаданные в DynamoDB, полные результаты вместе с обоснованиями судьи в S3.

Главная идея в порядке действий: сначала нормализация, потом оценка. Поэтому агента на одном фреймворке можно честно сравнить с агентом на другом по одной шкале. Каждая метрика возвращает число от 0 до 1, где 1 — лучшее значение.

Детерминированные метрики и LLM-судья

Метрики бывают двух типов. Детерминированные считаются прямо из трейса и эталона и воспроизводятся один в один. Остальные работают через LLM-as-a-judge: модель на Amazon Bedrock оценивает то, что трудно формализовать, например релевантность или безопасность. Можно добавлять свои метрики и подключать RAGAS и DeepEval.

Авторы отдельно описывают защиту судьи. Ответ агента попадает в промпт судьи, а значит, это недоверенный ввод. Иначе агент, способный влиять на судью, мог бы влиять на собственные оценки. Критерии отправляются отдельно от контента, контент экранируется, а судья обязан процитировать дословный фрагмент оценённого текста. Если цитаты в тексте нет, оценка отбрасывается. При этом AWS честно предупреждает: оценки судьи — это сигнал для разработки, а не механизм безопасности. Для защиты в рантайме нужны Bedrock Guardrails.

Сравнение версий и регрессии

Это самая практичная часть. Для каждой общей метрики двух запусков UAEF считает абсолютное и процентное изменение и помечает её как регрессию, улучшение или без изменений. Порог по умолчанию — 5%. Тяжесть регрессии делится на три уровня: лёгкая (5–10%), умеренная (10–20%) и тяжёлая (больше 20%). Регрессии группируются по измерениям.

Представим, что вы поправили системный промпт. Сравнение может показать, что качество ответа не изменилось, а точность выбора инструментов упала на 12%, то есть умеренная регрессия. Без разреза по измерениям вы увидели бы только средний балл, который почти не сдвинулся.

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

Отчёты работают на трёх уровнях: сводка результатов в веб-интерфейсе, статистический отчёт и LLM-инсайты. Статистический отчёт считается только по баллам, без LLM, с доверительными интервалами и выбросами, поэтому на одних данных он всегда одинаков. Инсайты, то есть гипотезы о причинах и приоритеты правок, генерирует модель на Bedrock через Python-библиотеку.

Что с этим делать

Первое: не включайте все 36 метрик подряд. AWS в плейбуке советует идти от сценария. RAG-ассистенту нужны релевантность, точность и faithfulness из RAGAS, а агенту с инструментами выбор и порядок вызовов и качество параметров. Лишние метрики стоят времени и вызовов Bedrock.

Второе: UAEF можно встроить в CI/CD через Python-библиотеку, а для менее технических коллег есть развёртываемый сервис с low-code интерфейсом. Движок в обоих случаях один и тот же.

Ограничения тоже очевидны. Инструмент плотно завязан на AWS: судья работает на Bedrock, а хранилище — это DynamoDB и S3. Порог в 5% на маленьком датасете легко принять за шум, поэтому смотрите на доверительные интервалы в отчёте. И не путайте оценку качества с защитой: для безопасности нужны отдельные ограждения.

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