Исследователи из Университета Сунь Ятсена и Alibaba Group представили SWE-CI - бенчмарк*, позволяющий оценить, насколько модель способна писать код, поддерживаемый в долгосрочной перспективе.
*Бенчмарк - стандартизированный тест или набор задач (датасет), используемый для объективной оценки и сравнения производительности, точности, скорости и возможностей моделей ИИ.
Для ленивых - кратко :)
Китайцы заставили ИИ поиграть в долгосрочное развитие кода - сделав ИИ-Архитектора, который выдает требования на естественном языке, и ИИ-программиста, который их исполняет. Ну что бы прям как вживую! 😏
А затем начали измерять, сколько работающих юнитов упадет после очередной итерации доработок.
15 из 18 моделей смогли не ухудшить код в 37% случаев и менее.
А если интересны подробности, читай дальше :)
Зачем?
Существующие бенчмарки направлены на оценку того, что ИИ генерирует работающий "в моменте" код. Но в условиях реальной разработки - код надо не просто написать, а еще развивать и поддерживать. Поэтому и решили создать бенчмарк, оценивающий насколько код ИИ работоспособен в долгосрочной перспективе.
Исходные данные
Исследователи прошлись по Python-репозиториям на Github, выбирая по критериям: активно поддерживается не менее трех лет, набрал более 500 звезд, содержит конфиги, зависимости и наборы юнит-тестов, распространяется под разрешительной лицензией (такие как MIT или Apache-2.0).
Затем, оставив только основную ветку, выделили такие кусочки истории, в которых зависимости кода неизменны. Начальная точка такого кусочка - "база" с которой стартовал ИИ, конечная - "эталон" к которому он должен был прийти.
После проверили корректность отработки тестов и выбрали топ-100 кусочков истории из 68 репозиториев, в которых присутствует более длинная история, большее число коммитов и у которых было значительное число изменений (сравнивали по запуску тестов). В среднем, кусочек истории состоял из 233 дней и 71 последовательного коммита + в каждом кусочке не менее 500 строк измененного кода (без учета тестов).
Как?
ИИ должен был превратить "базовую" кодовую базу в "эталонную", путем итераций разработки.
Для итераций использовалось 2 ИИ агента - Архитектор и Программист.
Тесты, релевантные эталонной базе, запускались на базовой версии. Архитектор должен был проанализировать ошибки упавших тестов и сформировать список требований Программисту, причем этот список требований формировался на естественном языке. Также допустимо было формулировать не более 5 требований за раз, поэтому Архитектор должен был выбирать наиболее критичные.
Программист реализовывал требования Архитектора.
Оценка "поддерживаемости" кода
Для оценки "поддерживаемости", т.е. корректности работы кода в будущем, сравнивалось, сколько юнит-тестов из исходного их количества выполнилось успешно после очередной итерации доработки кода.
При этом более поздним итерациям доработок давался больший "вес", чтобы как раз и выделить модели, чей код в будущем работал менее корректно.
Итог
См. график выше. По оси Y - модель, которую тестировали, по оси X - доля нулевых регрессий от всех итераций доработки (нулевая регрессия - ни один старый тест не сломался после доработки кода).
15 из 18 моделей показали результат ниже 37% - т.е. доля таких доработок, при котором тесты, что должны были работать, не сломаны, ниже 37%.
Однако 2 модели Claude показали очень неплохие результаты в 51 и 76 процентов.
Также попробовали варьировать метрику, дающую больший вес итерациям, и выяснили, что модели MiniMax, DeepSeek и GPT склонны к долгосрочным улучшениям, Kimi и GLM - к более быстрым, но менее поддерживаемым результатам. Qwen, Doubao и Claude оставались стабильными при разных значениях метрики.
Также внутри одного "семейства" более новые версии модели давали лучшие результаты.
- - - - - - -
Такие вот дела. Всё еще осторожнее с генерацией кода с ИИ - в долгосрок они пока умеют не очень :) Но совершенствуются!
Оригинал статьи можно скачать тут + переведенная от меня в первом комментарии. Осторожно, там немного математики :)
