Проблема метрики Pass/Fail
Стандартный бенчмарк SWE-bench оценивает только финальный результат: прошли ли тесты или нет. Однако этот подход игнорирует процесс. Агент может решить задачу за 5 шагов, а может — за 11, сделав лишние правки в ненужных файлах, запустив тесты повторно без изменений и внеся «мусор» в финальный патч. Оба сценария считаются успешными, но второй требует больше токенов, времени и усилий для ревью кода.
Методология: симуляция без API
Автор исследования провел 50 000 симуляций (24 000 в рамках комплаенс-свипа, 14 400 для проверки правил и 12 000 на тестовой выборке). Вместо использования реальных моделей (Claude, Codex), которые требуют ключей API и создают шум от различий в окружении, автор использовал seeded Python policy. Это позволило изолировать влияние правил работы агента (harness) на эффективность, используя реальные репозитории и тесты, но симулируя только принятие решений.
Профили поведения агентов
Эксперимент тестировал четыре профиля агентов с разными вероятностями ошибок. Вот как они распределяют действия:
| Профиль | Ошибка в правке | Повтор команды | Откат (Revert) | Ранний выход | Лишняя правка после успеха |
|---|---|---|---|---|---|
| careful | 0.05 | 0.05 | 0.02 | 0.03 | 0.05 |
| normal | 0.15 | 0.15 | 0.08 | 0.08 | 0.15 |
| sloppy | 0.30 | 0.30 | 0.20 | 0.18 | 0.30 |
| loop_prone | 0.10 | 0.55 | 0.15 | 0.05 | 0.40 |
Что считается «потерянной» работой?
Не каждое падение теста — это отходы. Автор определяет потерянными только те действия, которые не приближают к решению:
- Повтор одних и тех же команд без изменений в коде.
- Правки файлов, не связанных с падающими тестами.
- Правки, которые не меняют состояние или были отменены позже.
- Запуск тестов на уже пройденных случаях.
В примере из статьи агент исправил баг за 4 хода, но продолжил работу до 11-го хода, сделав 6 лишних изменений в 3 файлах, хотя эталонное решение занимало всего 2 строки в одном файле.
Вывод: нужен новый стандарт оценки
Результаты показывают, что метрика Pass/Fail скрывает реальную стоимость работы AI-агентов. Внедрение правил планирования (plan_benefit) и контроля комплаенса (compliance) может значительно снизить количество лишних итераций. Для индустрии это означает необходимость перехода от оценки «решил/не решил» к оценке «эффективность процесса», учитывающей размер финального диффа и количество потраченных токенов на путь к решению.
Источник: Towards Data Science ↗