Оценка агентов: pass@k и траектории

Как измерить качество LLM-агента: метрики pass@1, pass@k и pass^k, оценка траекторий и стоимости, песочницы и бенчмарки SWE-bench, WebArena, GAIA. Почему одинаковый pass@1 не значит «одинаковые агенты».

Интуиция: почему это сложнее, чем оценить LLM

Оценку одиночных ответов модели мы разобрали в теме про eval LLM: вопрос → ответ → сравнение с эталоном. У агента всё хуже: результат — это многошаговая траектория со стохастикой на каждом шаге. К одной и той же цели ведут сотни разных путей, и провалиться можно сотней разных способов: не тот файл, зацикливание, лимит итераций. Прогнал агента один раз — узнал про него почти ничего: в следующем прогоне те же входные данные могут дать другой исход.

Поэтому фундамент оценки — успех задачи (task success), проверяемый автоматически: тесты прошли, файл создан, ответ совпал с эталоном. Внешняя проверка вместо мнения модели — тот же принцип, что и в критерии остановки, только теперь он определяет метрику.

Как это работает: прогоняй k раз

Из-за стохастики одну задачу прогоняют k раз и считают:

• pass@1 — доля задач, решённых с первой попытки. Метрика «пользовательского опыта»: именно её видит человек, запустивший агента один раз.
• pass@k — доля задач, решённых хотя бы раз из k попыток. Показывает потолок способностей: «решение в принципе достижимо».
• pass^k — доля задач, решённых во всех k прогонах подряд. Метрика надёжности для продакшна: агент, которому можно доверять без присмотра.

Если вероятность успеха одного прогона — p, то ожидаемо:

При p = 0.6 и k = 8: pass@8 ≈ 99.9%, а pass^8 ≈ 1.7%. Один и тот же агент выглядит почти идеальным по одной метрике и бесполезным по другой. Разрыв между pass@1 и pass@k — прямая мера нестабильности: чем он больше, тем сильнее исход зависит от везения.

Оценивать траекторию, а не только исход

«Задача решена» — необходимое, но не достаточное условие. Агент мог удалить не тот файл, потом восстановить его и всё-таки решить задачу — по outcome-метрике это успех, по здравому смыслу — тревога. Поэтому к успеху добавляют метрики траектории: число шагов и токенов (стоимость — агент, решающий задачу за 8 шагов, в проде вдвое дешевле решающего за 16), зацикливания (повторы одинаковых действий без прогресса), опасные действия по пути. Для длинных задач помогает milestone-оценка: чекпоинты («нашёл нужный файл», «воспроизвёл баг», «написал фикс») дают частичный зачёт провальным прогонам — на сложных задачах метрика перестаёт быть нулём и начинает различать «почти решил» и «не понял задачу». Качество нечётких аспектов траектории (осмысленность плана, вежливость с пользователем) оценивают LLM-судьёй — про его предвзятости смотри оценку LLM.

Песочницы и бенчмарки

Агента прогоняют в окружении-песочнице: изолированной, воспроизводимой, с фиксированным начальным состоянием. Иначе eval флакает: вчера тесты в репозитории проходили, сегодня внешний API сменил ответ — и метрика прыгает без изменений в агенте. Известные бенчмарки:

• SWE-bench — реальные issue из GitHub-репозиториев: агент должен написать патч, успех проверяется скрытыми тестами.
• WebArena — задачи в веб-интерфейсах (магазин, форум, вики): кликать, заполнять формы, добиваться результата.
• GAIA — вопросы, требующие многошагового поиска, работы с файлами и рассуждения; ответ сравнивается с эталоном.

Типовые ловушки. Средняя метрика скрывает бимодальность: «60% успеха» может означать «идеально на лёгких, ноль на сложных». Контаминация: решения популярных бенчмарков попадают в обучающие данные, и агент «вспоминает», а не решает. И reward hacking на eval: агент находит ответ в файлах тестов, ослабляет проверку или подгоняет вывод под грейдер — формально успех, фактически взлом проверки. Поэтому подозрительно резкий рост метрики — повод не радоваться, а читать траектории успешных прогонов.