RELEASE года: как читать SWE-bench и не перепутать код-агента с презентацией

RELEASE года: как читать SWE-bench и не перепутать код-агента с презентацией

SWE-bench — это не «поставили задачу, модель что-то ответила», а проверка на реальных багфиксах из GitHub-репозиториев. Там важен не красивый текст, а способность найти нужные файлы, понять контекст, изменить код и не сломать соседние тесты. Для model_comparison это почти идеальный стресс-тест: болтовня быстро заканчивается, остаётся инженерная дисциплина.

Если смотреть на метрики, не залипай только в общий score. Сильная модель может хорошо чинить короткие патчи, но разваливаться на длинном контексте, а другая — наоборот. Для evals полезно отдельно смотреть:
• успешность на локализации бага;
• качество финального патча;
• число лишних правок;
• поведение в многошаговом плане.

Главная ловушка — сравнивать агентов по «умности», а не по пайплайну. В SWE-bench результат часто делает не один llm, а связка: поиск по репозиторию, планирование, редактирование, запуск тестов, повторная попытка. Поэтому один и тот же базовый модельный мозг в разных обвязках выглядит то как MVP года, то как цирк с автокоммитами.

Если вы строите ai_tools или внутренний код-агент, проверяйте не только победы на бенчмарке, но и типы фейлов: застревание в одном файле, галлюцинации API, сломанные импорты, бесполезные массовые правки. Именно это потом вылезает в проде, а не в красивой таблице.

SWE-bench хорошо отрезвляет: тут быстро видно, где реальный потенциал, а где маркетинг под релиз года. Может, конечно, ни хуя не взлетит — но как тест на инженерную адекватность это один из самых честных benchmarks.