Как Amazon оценивает AI-агентов: практический фреймворк для production-систем

Почему ваш AI-агент проваливается в продакшене?

Вы построили AI-агента. Он блестяще проходит демо. Клиенты в восторге. Инвесторы кивают. А потом вы запускаете его в продакшен, и система разваливается через неделю.

Знакомо? Amazon сталкивался с этим тысячи раз. Пока остальные обсуждают точность LLM, Amazon уже три года оценивает не модели, а системы. Разница колоссальная.

Сдвиг парадигмы: от оценки моделей к оценке систем

В 2023 году все говорили про accuracy, perplexity, F1-score. В 2026 году в Amazon говорят про Task Success Rate, Tool Selection Accuracy и Multi-step Reasoning Efficiency.

Вот что изменилось:

• Раньше: оценивали, правильно ли модель отвечает на вопрос
• Сейчас: оценивают, правильно ли система выполняет задачу
• Раньше: тестировали на статических датасетах
• Сейчас: тестируют в динамических симуляциях
• Раньше: фокусировались на single-turn диалогах
• Сейчас: фокусируются на multi-turn workflow

Фреймворк Amazon Agent Evaluation Framework (AAEF)

Amazon не публикует этот фреймворк открыто. Но по кусочкам из их статей, патентов и выступлений можно собрать пазл. Вот как они оценивают агентов в 2026 году.

1 Task Success Rate (TSR) — главная метрика

Забудьте про точность ответов. Amazon измеряет процент успешно выполненных задач. И нет, это не одно действие.

Пример задачи для агента поддержки:

1. Получить запрос пользователя "Не могу войти в аккаунт"
2. Запросить email пользователя
3. Проверить аккаунт в базе данных
4. Определить причину проблемы (заблокирован, неверный пароль, 2FA)
5. Предложить решение
6. Убедиться, что проблема решена

Агент выполнил все 6 шагов правильно? Отлично. Провалился на шаге 4? TSR = 0.

2 Tool Selection Accuracy (TSA)

Агент умеет использовать 15 инструментов. Как часто он выбирает правильный?

Кажется просто. Но нет. Проблема в контексте. Инструмент "поиск в базе данных" может быть правильным в 90% случаев, но в 10% нужно использовать "поиск в логах". Amazon оценивает не просто процент правильных выборов, а процент правильных выборов в контексте.

3 Multi-step Reasoning Efficiency (MRE)

Самый болезненный показатель. Агент решает задачу в 5 шагов. Но мог бы решить в 3. Или в 7, но с лучшим результатом.

Amazon измеряет:

• Количество шагов до решения
• Оптимальность последовательности шагов
• Способность перепланировать при ошибке

Вот где суб-агенты показывают свою ценность. Главный агент делегирует специализированные задачи, сокращая общее количество шагов.

Практический план: как внедрить AAEF в вашем проекте

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

Шаг 1: Определите TSR для вашего домена

Не копируйте метрики Amazon. Определите, что значит "успех" для вашего агента.

Пример для агента аналитика:

# Конфигурация оценки TSR
class TaskSuccessEvaluator:
    def __init__(self):
        self.task_definitions = {
            "analyze_sales_trends": {
                "required_steps": [
                    "extract_sales_data",
                    "calculate_monthly_growth",
                    "identify_top_products",
                    "generate_insights"
                ],
                "success_threshold": 0.8  # 80% шагов выполнены правильно
            },
            "forecast_next_quarter": {
                "required_steps": [
                    "get_historical_data",
                    "apply_forecast_model",
                    "calculate_confidence_intervals",
                    "format_report"
                ],
                "success_threshold": 0.9
            }
        }
    
    def evaluate(self, agent_output, task_type):
        task = self.task_definitions[task_type]
        completed_steps = self._extract_completed_steps(agent_output)
        
        # Проверяем, выполнены ли обязательные шаги
        success = True
        for required in task["required_steps"]:
            if required not in completed_steps:
                success = False
                break
                
        return {
            "success": success,
            "completed_steps": len(completed_steps),
            "required_steps": len(task["required_steps"]),
            "score": len(completed_steps) / len(task["required_steps"])
        }

Шаг 2: Постройте симуляцию окружения

Тестировать агента на реальных пользователях — дорого и опасно. Amazon строит симуляции.

Для агента поддержки:

• Симулятор пользователя: генерирует реалистичные запросы
• Симулятор базы данных: возвращает контролируемые данные
• Симулятор внешних API: эмулирует задержки и ошибки

В статье про оркестрацию агентов мы обсуждали сложности координации. Симуляции помогают выявить проблемы до продакшена.

Шаг 3: Внедрите автоматическую оценку TSA

Каждый вызов инструмента должен логироваться и оцениваться.

# Декоратор для оценки выбора инструментов
def tool_selection_monitor(func):
    def wrapper(self, tool_name, *args, **kwargs):
        # Записываем контекст выбора
        context = {
            "user_query": self.current_query,
            "conversation_history": self.history[-3:],
            "available_tools": list(self.tools.keys()),
            "selected_tool": tool_name
        }
        
        # Выполняем инструмент
        result = func(self, tool_name, *args, **kwargs)
        
        # Оцениваем, был ли выбор правильным
        expected_tool = self._get_expected_tool(context)
        correct = (tool_name == expected_tool)
        
        # Логируем для анализа
        self._log_tool_selection({
            "context": context,
            "selected": tool_name,
            "expected": expected_tool,
            "correct": correct,
            "result_success": result["success"] if isinstance(result, dict) else True
        })
        
        return result
    return wrapper

Нюансы, которые никто не рассказывает

1. Проклятие компетентности

Чем лучше агент, тем сложнее его оценить. Агент-новидок делает очевидные ошибки. Агент-эксперт делает тонкие ошибки, которые выявляются только в 1% случаев.

Amazon решает это через adversarial testing. Специальные агенты-тестировщики пытаются сломать основного агента.

2. Дрейф производительности

Агент сегодня работает с TSR 92%. Через месяц — 87%. Почему?

• Изменения в данных
• Обновления моделей (актуальный GPT-5-Turbo на 18.02.2026 ведёт себя иначе, чем GPT-5)
• Изменения во внешних API
• Новые edge cases

Нужен continuous evaluation, а не разовые тесты.

3. Стоимость оценки

Оценивать каждого агента вручную — банкротство. Amazon автоматизирует 94% оценки. Но оставшиеся 6% — самые важные.

Инструменты, которые использует Amazon (но не афиширует)

1. AgentBench — внутренний фреймворк для бенчмаркинга агентов. Не путать с академическими аналогами. Этот работает с реальными продакшен-нагрузками.

2. ToolNet Simulator — симулятор для тестирования выбора инструментов. Эмулирует задержки, ошибки, неожиданные ответы.

3. Multi-Agent Evaluation Suite — для оценки систем с несколькими агентами. Измеряет координацию, делегирование, разрешение конфликтов.

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

Чего ждать в 2027 году?

Тренды, которые Amazon тестирует сейчас:

• Self-improving agents — агенты, которые сами улучшают свою оценку
• Cross-domain evaluation — один фреймворк для оценки агентов в разных доменах
• Real-time adaptation scoring — оценка способности адаптироваться к изменяющимся условиям в реальном времени

Самое важное: Amazon уже не спрашивает "Насколько точна ваша модель?". Они спрашивают "Насколько надежна ваша система в выполнении бизнес-задач?".

Ваш агент может использовать самую продвинутую модель 2026 года. Но если он неправильно выбирает инструменты в 40% случаев — это не агент. Это дорогая игрушка.

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