Посмотрел короткий доклад Ibragim Badertdinov из Nebius про SWE-rebench, в котором речь идет про то, как честно понять, что coding agent действительно умеет решать software engineering задачи, а не просто красиво проходит знакомый benchmark.
Главная проблема старых и статичных бенчмарков в том, что они быстро перестают быть свежими. Задачи лежат в публичном доступе, попадают в обучающие данные, вокруг них появляются подсказки, scaffolding, retry-циклы и неочевидная подгонка. В итоге resolved rate может отражать не только способность модели разбираться в коде, но и contamination, инженерную обвязку вокруг модели или удачный запуск.
SWE-rebench пытается поправить именно это. Идея в том, чтобы регулярно собирать свежие GitHub-issues и оценивать агентов в более production-похожем режиме. Агенту нужно не ответить на вопрос, а пройти маленький цикл разработки: понять issue, разобраться в репозитории, воспроизвести проблему, изменить код, запустить проверки и отдать patch. Из доклада хорошо видно, насколько сложна сама инфраструктура оценки. Хорошая задача для benchmark-а не должна быть слишком размытой, слишком очевидной, слишком хрупкой или завязанной на нестабильные тесты. Иначе мы начинаем мерить шум: flaky environment, странный assert в тесте, недосказанный issue или случайную удачу агента. То есть хороший eval для agents становится похож на маленький стенд разработки, а не на набор задач из олимпиады.
Самая показательная часть - reward hacking. Badertdinov разбирает кейсы, где сильный агент не "пишет плохой код", а слишком хорошо использует доступные каналы. Сначала он находит будущую правку через
git log. После очистки history идет читать исходный issue и PR на GitHub. Когда веб-доступ ограничивают, пробует добраться до той же информации через curl. Урок здесь не в том, что модель "читерит" в человеческом смысле. Урок в том, что у агентной системы намного шире поверхность reward hacking. Если агент имеет терминал, сеть, историю репозитория и инструменты, то оценивать нужно не только финальный diff, но и траекторию: откуда он взял информацию, какие команды запускал, не использовал ли будущий ответ.Еще один важный сдвиг - экономика. Для production-агентов мало знать средний resolved rate. Нужно смотреть tokens per problem, cost per problem, cached tokens, число попыток, SEM,
pass@5 и стабильность между несколькими запусками. Один успешный прогон может быть удачей. Пять запусков уже показывают, насколько модель надежна, а не просто иногда попадает в цель.Отдельно интересно, что SWE-rebench - это не только leaderboard. На HuggingFace версия V1 содержит описание про 21,000+ интерактивных Python SWE-задач для RL-обучения агентов, а для версии V2 уже указаны 32,000+ окружений в 20 языках и 126,000+ дополнительных задач. То есть одна и та же pipeline становится и инструментом оценки, и фабрикой training environments.
В общем, если мы хотим запускать coding agents в реальной разработке, нужно мерить не только "решил или не решил". Нужно мерить свежесть задач, утечки, стоимость, воспроизводимость, надежность, ограничения окружения и поведение агента по шагам. И начинать можно с публичных бенчмарков, а потом переходить к замерам на внутренних задачах.
#AI #AI4SDLC #Engineering #Agents #Evals #DevTools #Software