Как построить систему оценки AI-агентов: от точности ответов до анализа пути исполнения

Почему ваша система оценки AI-агентов — это просто красивые цифры

Вы запускаете агента. Он решает задачу. Вы смотрите на метрику точности — 87%. Отличный результат, можно показывать инвесторам. Но через неделю в продакшене агент начинает вести себя как первоклассник на экзамене по высшей математике — тупит, ошибается, делает странные вещи.

Проблема в том, что большинство команд оценивают AI-агентов так же, как классические ML-модели. Измерили accuracy, F1-score, запустили A/B-тест — готово. Но агент — это не модель. Это сложная система с состоянием, инструментами, цепочками рассуждений, внешними зависимостями.

Вспомните нашу статью про production-ready агентов. Там мы говорили о ReAct, инструментах, планировании. Теперь представьте: как оценить, насколько хорошо агент использует эти инструменты? Как измерить качество его reasoning chain?

От vibe engineering к инженерной дисциплине

Vibe engineering — это когда вы настраиваете промпты методом научного тыка. «Добавим вот эту фразу, посмотрим, станет ли лучше». Иногда работает. Чаще — нет. Особенно когда система становится сложной.

Нужен системный подход. Как в статье про AI-агентов как сотрудников. Вы же не нанимаете людей без собеседования, тестовых заданий, периода испытательного срока. Почему с агентами должно быть иначе?

1 Создаем датасет use cases — не просто примеры, а сценарии с ловушками

Первая ошибка — собирать датасет из простых примеров. «Напиши функцию сложения двух чисел». «Найди информацию о компании X». Это бесполезно.

Настоящий датасет для оценки агентов должен содержать:

• Краевые случаи — что происходит, когда инструмент возвращает ошибку?
• Многозадачные сценарии — нужно выполнить A, потом B, причем B зависит от результата A
• Конфликтующие инструкции — «сделай быстро, но качественно» (классика)
• Неполные данные — что делает агент, когда информации недостаточно?
• Временные зависимости — задача, которая меняется со временем

# Пример структуры датасета use case
{
  "id": "uc_001",
  "description": "Анализ финансового отчета с пропущенными данными",
  "input": {
    "task": "Рассчитай квартальный рост выручки компании по приложенному отчету",
    "documents": ["financial_report_q1.pdf", "financial_report_q2.pdf"],
    "constraints": ["В отчете Q2 отсутствует раздел 'Операционные расходы'"]
  },
  "expected_behavior": [
    "Агент запрашивает недостающие данные",
    "Агент отмечает в ответе, какие расчеты приблизительные",
    "Агент не выдает точных цифр для показателей с пропусками"
  ],
  "evaluation_criteria": {
    "correctness": 0.4,
    "safety": 0.3,
    "completeness": 0.2,
    "efficiency": 0.1
  },
  "tools_required": ["pdf_parser", "calculator", "data_validator"],
  "difficulty": "hard",
  "max_steps": 15
}

Собирайте минимум 50 таких use cases для старта. Лучше 100. И да, это ручная работа. Автоматизировать создание качественных тестовых сценариев пока невозможно.

2 Мультиметрическая система оценки — смотрите не только на результат

Accuracy — 87%. И что это значит? Ничего. Нужно разбивать оценку на компоненты:

3 Анализ пути исполнения — смотрите, КАК агент думает

Конечный результат правильный. Отлично. А как агент к нему пришел? Вот пример плохого execution path:

{
  "steps": [
    {"action": "search_web", "query": "как решить задачу про финансы"},
    {"action": "ask_human", "question": "Что такое квартальный отчет?"},
    {"action": "search_web", "query": "финансовые формулы"},
    {"action": "calculate", "formula": "выручка - расходы"},
    {"action": "search_web", "query": "проверить расчет"}
  ],
  "total_steps": 5,
  "redundant_actions": 3,
  "external_dependencies": 2
}

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

Создайте систему анализа execution path:

class ExecutionPathAnalyzer:
    def __init__(self, agent_trace):
        self.trace = agent_trace
    
    def detect_loops(self):
        """Обнаруживает циклическое поведение"""
        # Агент вызывает один инструмент 3+ раза с одинаковыми параметрами
        pass
    
    def measure_tool_switching(self):
        """Измеряет частоту переключения между инструментами"""
        # Частые переключения = плохое планирование
        pass
    
    def identify_bottlenecks(self):
        """Находит узкие места в выполнении"""
        # Где агент проводит больше всего времени?
        # Какие инструменты чаще всего fail?
        pass
    
    def compare_with_optimal(self, optimal_path):
        """Сравнивает с оптимальным путем"""
        # Расхождение в шагах, инструментах, последовательности
        pass

4 Гиперпараметрический поиск — но не тот, о котором вы подумали

В классическом ML гиперпараметры — learning rate, batch size. В агентах — совсем другое:

• Temperature — не только для генерации, но и для planning
• Max steps — когда агент должен остановиться?
• Tool timeout — сколько ждать ответа от инструмента?
• Retry policy — как реагировать на ошибки инструментов?
• Context window usage — сколько истории сохранять?

Проблема в том, что эти параметры зависят друг от друга. И от конкретной задачи. И от модели. И от фазы луны (шучу, но иногда кажется, что так).

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

def hyperparameter_search(agent_class, test_suite, param_grid):
    """Поиск оптимальных гиперпараметров для агента"""
    best_score = -1
    best_params = None
    
    for params in generate_param_combinations(param_grid):
        agent = agent_class(**params)
        scores = []
        
        for test_case in test_suite:
            result = agent.run(test_case["input"])
            score = evaluate_result(result, test_case["expected"])
            scores.append(score)
        
        avg_score = np.mean(scores)
        
        # Учитываем не только точность, но и стоимость/время
        cost = calculate_execution_cost(agent.execution_log)
        time = calculate_execution_time(agent.execution_log)
        
        adjusted_score = avg_score * 0.7 - cost * 0.2 - time * 0.1
        
        if adjusted_score > best_score:
            best_score = adjusted_score
            best_params = params
    
    return best_params, best_score

5 Абляционные исследования — что на самом деле важно в вашем агенте

Абляционное исследование (ablation study) — это когда вы по очереди убираете компоненты системы и смотрите, что происходит. Для агентов это критически важно.

Пример: у вас агент с такими компонентами:

1. Planner — разбивает задачу на подзадачи
2. Critic — проверяет результаты каждого шага
3. Memory — хранит контекст
4. Tool selector — выбирает инструменты

Проводите эксперименты:

Такие исследования показывают, на что тратить время при оптимизации. Может оказаться, что сложный компонент, над которым вы бились месяц, дает прирост всего в 3%. Или наоборот — простой хак улучшает результаты на 20%.

Интеграция в CI/CD — оценка не раз в квартал, а на каждый коммит

Самая большая ошибка — делать оценку раз в месяц/квартал. К тому времени уже накопились изменения, непонятно, что сломалось и когда.

Интегрируйте систему оценки в CI/CD:

# .github/workflows/agent-evaluation.yml
name: Agent Evaluation

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  evaluate-agent:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Run Core Tests
      run: |
        python run_evaluation.py \
          --test-suite core_tests.json \
          --agent-config agent_config.yaml \
          --output results_core.json
      env:
        OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
    
    - name: Run Performance Tests
      run: |
        python run_performance.py \
          --scenarios performance_scenarios.json \
          --concurrency 5 \
          --duration 300 \
          --output results_perf.json
    
    - name: Check Regression
      run: |
        python check_regression.py \
          --current results_core.json \
          --baseline baseline_results.json \
          --threshold 0.05
      
    - name: Upload Results
      uses: actions/upload-artifact@v3
      with:
        name: evaluation-results
        path: results_*.json
    
    - name: Fail on Critical Regression
      if: failure()
      run: |
        echo "Critical regression detected. Blocking merge."
        exit 1

Что должно запускаться на каждый коммит:

• Быстрые smoke-тесты — 10-15 ключевых use cases (5-10 минут)
• Регрессионные проверки — сравнение с baseline
• Стоимостные проверки — не выросла ли стоимость выполнения

Полную оценку (100+ use cases) запускайте раз в день или при изменении критических компонентов.

Мультиагентные системы — оценка становится в 10 раз сложнее

Один агент — сложно. Несколько агентов, которые взаимодействуют друг с другом — совсем другая история. Вспомните статью про фреймворки оркестрации. Там мы говорили о коммуникации между агентами.

Для мультиагентных систем добавляются новые метрики:

Создавайте тестовые сценарии специально для мультиагентного взаимодействия:

{
  "scenario": "Разработка микросервиса командой из 3 агентов",
  "agents": [
    {"role": "архитектор", "tools": ["diagram_generator", "tech_stack_selector"]},
    {"role": "разработчик", "tools": ["code_generator", "test_writer"]},
    {"role": "тестировщик", "tools": ["test_runner", "bug_reporter"]}
  ],
  "success_criteria": [
    "Все агенты завершили свои задачи",
    "Нет deadlock или livelock",
    "Общее время < 30 минут",
    "Количество конфликтов < 2"
  ],
  "failure_modes": [
    "Архитектор и разработчик спорят о технологическом стеке",
    "Тестировщик начинает работу до готовности кода",
    "Агенты дублируют работу друг друга"
  ]
}

Чего не хватает в этой картине? Людей.

Автоматическая оценка — это хорошо. Но недостаточно. Нужны люди в цикле. Особенно для сложных, субъективных аспектов.

Создайте процесс human-in-the-loop оценки:

1. Еженедельный review — эксперты просматривают 5-10 самых сложных/интересных кейсов
2. Adversarial testing — специальная команда пытается сломать агента
3. Пользовательские тесты — реальные пользователи выполняют задачи с агентом
4. Экспертная оценка качества reasoning — насколько логичен ход мысли агента

И да, это дорого. Но дешевле, чем выпустить в продакшен кривого агента, который накосячит на миллионы.

Что будет дальше? Эволюция систем оценки

Сейчас мы оцениваем агентов постфактум. Запустили — получили результат — оценили. В будущем системы оценки будут работать в реальном времени.

Представьте агента, который:

• Сам оценивает уверенность в своих действиях
• Определяет, когда нужно запросить помощь у человека
• Адаптирует свою стратегию на основе прошлых оценок
• Предсказывает, какие действия приведут к низкой оценке, и избегает их

Это уже не просто оценка. Это мета-когнитивная способность. Агент, который умеет оценивать себя — это следующий шаг эволюции.

Пока же начните с основ. Создайте датасет use cases. Разработайте мультиметрическую систему. Интегрируйте в CI/CD. И помните: оценка агентов — это не разовое мероприятие. Это непрерывный процесс, который должен стать частью ДНК вашей разработки.

И последний совет: не пытайтесь создать идеальную систему оценки с первого раза. Начните с простого. Измеряйте что-то. Даже если метрики неидеальны. Лучше неидеальная система оценки, чем никакой. Потому что без оценки вы летите вслепую. А вслепую можно лететь только до первого столба.