Coding-agent evals: pass@k and diff quality

Код — самый удобный домен для эвалов, потому что у ответа есть исполняемая проверка: тесты либо проходят, либо нет. Авторы HumanEval (Chen et al., 2021) показали, что текстовые метрики вроде BLEU не отличают верные решения от неверных — похожий на эталон код может быть сломан, а непохожий — корректен. Отсюда стандарт functional correctness: генерируем решения, запускаем тесты.

pass@k — вероятность, что хотя бы одно из k сгенерированных решений проходит все тесты. Наивная оценка «сгенерировать ровно k и посмотреть» имеет высокую дисперсию и смещение. Несмещённый эстиматор из HumanEval: генерируем n ≥ k решений на задачу, считаем c прошедших:

pass@k = E_задачи [ 1 − C(n−c, k) / C(n, k) ]

где C — биномиальный коэффициент: C(n−c, k)/C(n, k) — вероятность, что случайная выборка k решений из n не содержит ни одного прошедшего. Формулу считают численно устойчиво через произведение, не через факториалы.

Ориентиры из статьи: Codex-12B давал pass@1 = 28.8%, а при 100 сэмплах на задачу решалось 70.2% задач — повторное сэмплирование резко повышает шанс успеха, если есть автоматический способ выбрать верное решение. Практический вывод: pass@1 при низкой temperature — метрика продукта («какой ответ получит пользователь с первой попытки»), pass@k при высокой — метрика потенциала модели и верхняя граница для систем с автоперебором. Сравнивать модели можно только при одинаковых k, n и temperature.

HumanEval проверяет генерацию функции по докстрингу — это далеко от работы агента, который получает issue в живом репозитории. Этот разрыв закрывает SWE-bench (Jimenez et al., 2023): 2 294 задачи, собранные из реальных GitHub issue и PR двенадцати Python-проектов (django, sympy, scikit-learn и другие). Агент получает снапшот репозитория и текст issue, должен выдать патч. Проверка двухсторонняя: fail-to-pass тесты (падали до эталонного фикса, должны пройти после патча агента — задача решена) и pass-to-pass (проходили раньше и обязаны проходить после — ничего не сломано). Метрика — resolved rate: доля задач с полностью зелёной проверкой.

У оригинального набора нашлись дефекты: часть задач имела недоопределённые условия или тесты, завязанные на детали конкретного эталонного решения. Поэтому появился SWE-bench Verified — 500 задач, отфильтрованных профессиональными инженерами в сотрудничестве с OpenAI: из набора убраны некорректные и нерешаемые задачи. Для чтения лидербордов это важно: числа на Verified систематически выше и честнее, чем на полном наборе.

Ловушки интерпретации. Контаминация: популярные репозитории почти наверняка были в обучающих данных моделей, и рост метрики может отражать память, а не способность. Оверфит экосистемы: инструменты и скаффолды тюнятся под особенности бенчмарка. И главное — репрезентативность: SWE-bench — это Python-опенсорс определённой эпохи; его resolved rate не обещает такой же на вашем legacy-монолите. Лидерборды сравнивают модели между собой; для решения «пускать ли агента в наш репозиторий» нужен harness на ваших задачах.

Task completion бинарен, но между «тесты прошли» и «этот патч можно мержить» — дистанция. Агент может пройти проверку плохим способом: захардкодить ожидаемое значение, отредактировать сами тесты, навалить 800 строк там, где нужно 10, продублировать существующую функцию вместо переиспользования. Поэтому поверх resolved rate нужен слой метрик качества диффа:

• Неприкосновенность тестов: правки тестовых файлов запрещены конфигом раннера или как минимум фиксируются отдельным флагом и обнуляют зачёт задачи.
• Размер и локальность: изменённые строки и число затронутых файлов против эталонного патча; дифф в разы больше эталона — сигнал на ревью.
• Статические проверки: lint и typecheck после применения патча — код может проходить тесты и не проходить стандарты репозитория.
• Judge-ревью диффа по бинарной рубрике: «патч минимален, следует стилю модуля, не дублирует существующий код, не содержит мёртвых веток и захардкоженных ответов». Judge здесь дополняет тесты, а не заменяет: корректность уже доказана исполнением, judge оценивает сопровождаемость.
• Экономика: шаги агента, токены, доллары и минуты на задачу. Агент, решающий на 5% больше задач за втрое большую стоимость, — не всегда лучший выбор.

Сводить это в один балл не нужно: полезнее таблица «resolved rate / med. размер диффа / доля патчей без замечаний judge / $ на задачу» — по ней видно, чем именно один агент лучше другого.

Самый честный бенчмарк для вашей команды делается из вашей же истории git. Реальный багфикс-коммит — готовая задача формата SWE-bench: откатите код до состояния перед фиксом, оставьте тест, который этот фикс проверяет (или напишите его по мотивам инцидента), сформулируйте issue-текст из сообщения коммита и тикета. Получается задача с гарантированным fail-to-pass тестом и эталонным патчем для сравнения размеров диффа. 10–20 таких задач достаточно, чтобы осмысленно сравнить двух агентов или две модели на своём коде.

Контур прогона:

для каждой задачи:
  checkout base-коммита → поднять окружение (контейнер, зафиксированные зависимости)
  запустить агента с текстом задачи (лимиты: шаги, токены, wall-clock)
  применить дифф → прогнать fail-to-pass и pass-to-pass тесты
  lint + typecheck → judge-ревью диффа → записать метрики
отчёт: resolved rate, med. размер диффа, доля чистых ревью, $/задачу, p50 время

Технические требования: полная изоляция (контейнер на задачу — агент не должен видеть эталонный фикс в git-истории, обрежьте её), детерминированное окружение (lock-файлы зависимостей), таймауты на каждый этап и запрет сети, если задача её не требует. Флейки тестов окружения убивают доверие к harness быстрее всего — прогоните каждую задачу без агента дважды и выбросите нестабильные.

Этот harness — прямой предшественник капстоуна: те же компоненты (задачи, раннер, проверки, отчёт) мы соберём в общий контур и проверим подсаженными регрессиями.