Оценка Агентов и Бенчмаркинг SWE-bench

1. Обзор концепции и системная проблема

Наибольшая угроза при разработке агентских систем в 2026 году — это так называемая «деградация поведения» (Behavioral Regression):

• Вы изменяете одно предложение в системном промпте, чтобы агент лучше форматировал Markdown, но неожиданно он перестает вызывать инструмент чтения файлов.
• Вы переходите с модели версии v1.2 на v1.3, и агент начинает делать вдвое больше ошибочных shell-команд.
• Без автоматизированных тестов агентские проекты превращаются в «шаманство», где разработчики тестируют качество системы двумя-тремя ручными запросами в чате.

Agent Evals — это инженерная дисциплина, которая переносит классические принципы TDD и CI/CD в мир недетерминированных языковых агентов. Она позволяет количественно измерять успешность (Pass Rate), стоимость в токенах (Cost per Task) и время выполнения (Latency).

2. Архитектурная таксономия и ментальная модель

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMY OF AGENT EVALUATION                │
├─────────────────────────────────────────────────────────────┤
│ 1. State-Based Evals (Конечное состояние среды):            │
│    • Unit / Integration Tests Pass (pytest, vitest == 0)    │
│    • File System Diff Verification (созданы ли необходимые)  │
├─────────────────────────────────────────────────────────────┤
│ 2. Trajectory-Based Evals (Оценка траектории мыслей):       │
│    • Tool Call Accuracy (вызван ли правильный инструмент)    │
│    • Step Efficiency (за сколько шагов достигнута цель)      │
│    • Redundant Action Penalty (штрафы за повторы)           │
├─────────────────────────────────────────────────────────────┤
│ 3. LLM-as-a-Judge Evals (Семантическая проверка судьей):     │
│    • Response Tone & Adherence to Style Guides              │
│    • Completeness & Safety Compliance                       │
├─────────────────────────────────────────────────────────────┤
│ 4. Resource & Economic Evals:                               │
│    • Token Burn Rate per Resolved Issue                     │
│    • Wall-Clock Execution Time                              │
└─────────────────────────────────────────────────────────────┘

3. Технический пайплайн и внутренняя механика

Типичный фреймворк оценки агентов (например, Inspect AI, Braintrust или собственный Docker Harness) работает по следующему циклу:

1. Test Environment Reset: Запуск изолированного Docker-контейнера с начальным коммитом кодовой базы, где проблема еще присутствует.
2. Task Provisioning: Агенту отправляется только описание бага (issue.md).
3. Agent Trajectory Recording: Агент выполняет команды, читает файлы и делает правки. Все шаги записываются в формате OpenTelemetry / JSONL (траектория действий).
4. Harness Evaluation:
   • Оркестратор забирает сгенерированный git diff.
   • Запускаются скрытые верификационные тесты (Fail-to-Pass тесты).
   • Фиксируется статус: RESOLVED, FAILED, TIMEOUT или OUT_OF_BUDGET.
5. Metric Aggregation: Вычисляется общий процент решенных задач (Resolve Rate) для релиза агента.

4. Практические инженерные сценарии в продакшене

01. CI/CD гейт для обновления агентских промптов

Перед слиянием изменений в файл .cursorrules или системный промпт в репозитории запускается GitHub Action с 30 синтетическими тестами. Если агент решает менее 90% задач, пулл-реквест автоматически блокируется.

02. Выбор провайдера моделей по критерию ROI

Команда оценивает: стоит ли платить за топовую модель $15 за миллион токенов, или достаточно новой открытой модели за $0.50? Запуск эвалов на собственных 100 задачах показывает точные цифры: топовая модель решает 78% задач, дешевая — 74%, но обходится в 20 раз дешевле.

5. Подводные камни, типовые ошибки и безопасность

• Contamination (Загрязнение обучающей выборки): Публичные бенчмарки (например, базовый HumanEval) попадают в обучающие данные свежих моделей, из-за чего модель "помнит" правильный ответ, но не умеет рассуждать. Используйте только собственные закрытые эваллы или SWE-bench Verified с постоянно обновляемыми задачами.
• Flaky Evals (Нестабильные тесты): Недетерминированность температуры модели может давать 80% успеха в одном прогоне и 65% в другом. Необходимо делать как минимум 3–5 прогонов на каждую задачу (метрика Pass@k).
• Слепая доверие к LLM-as-a-Judge: Использование другой модели для оценки кода часто страдает от предвзятости в пользу длинных или красивых ответов. Предпочитайте детерминированные компиляторы и тесты.

6. Стратегический вывод для инженера 2026 года

Без системы непрерывной оценки (Agent Evals) создание автономных систем — это движение вслепую. Инженер нового поколения тратит 70% времени не на написание промптов, а на проектирование исчерпывающих наборов тестов, которые позволяют безопасно модифицировать и масштабировать агентские архитектуры.