По сравнению с GPT-6 Astra, модель GPT-6 Sol пишет на 27% меньше кода и выдает в общей сложности на 22% меньше замечаний, при этом показатель успешного прохождения тестов ниже на 2,76 пункта, а количество замечаний на строку кода выше.
Релиз GPT-6 Astra стал тем этапом, когда корректность и объем кода улучшились одновременно. У Astra выше процент успешных прохождений и ниже плотность проблем, в то время как Sol генерирует значительно меньше кода и в целом меньше замечаний.
Мы прогнали Sol через систему оценки LLM от Sonar, используя тот же Java-бенчмарк, который применяем для каждой модели, и сравнив результаты с тем же запуском Astra, который мы опубликовали ранее в этом месяце.
Как оценивалась GPT-6 Sol?
Модель: GPT-6 Sol, средний уровень рассуждений
Базовая модель: GPT-6 Astra, средний уровень рассуждений
Язык: Java
Бенчмарк: тот же Java-бенчмарк, который мы используем для каждой модели, охватывающий HumanEval, MBPP и ComplexCodeEval. Оба запуска включают 4444 задачи. Все они анализируются на предмет качества кода и безопасности, откуда и берутся все приведенные ниже показатели плотности. 544 задачи включают исполняемые тесты, и процент успешных прохождений рассчитывается только по ним.
Анализатор: систематический анализ кода SonarQube. Плотность сложности и «запахов» кода указана на 1000 строк кода (kLOC). Плотность ошибок и уязвимостей, а также все разбивки по категориям указаны на миллион строк (mLOC).
Два термина, которые стоит определить в первую очередь:
- Цикломатическая сложность: подсчитывает количество независимых путей через функцию.
- Когнитивная сложность: метрика SonarQube, которая придает больший вес вложенной и сильно разветвленной логике, отражая то, насколько сложно человеку читать код.
Ни одна из них не говорит о том, работает ли код. Обе помогают определить, какой объем логики придется осмыслить рецензентам и тестировщикам.
Как GPT-6 Sol и GPT-6 Astra соотносятся по ключевым метрикам?
Метрика
GPT-6 Astra
GPT-6 Sol
Строк кода (всего)
656 445
480 125
Плотность комментариев (% от строк кода)
4,2%
1,3%
Цикломатическая сложность на kLOC
220,93
225,56
Когнитивная сложность на kLOC
163,38
167,38
Плотность ошибок на mLOC
558
629
Плотность уязвимостей на mLOC
178
285
Плотность «запахов» кода на kLOC
18,47
19,62
Общая плотность проблем на kLOC
19,20
20,53
Функциональные навыки (процент успешных прохождений)
85,85%
83,09%
Пропущенные завершения
0,09%
0,09%
Каков процент успешных функциональных прохождений GPT-6 Sol?
83,09% по 544 задачам с тестами против 85,85% у Astra. Это на 2,76 пункта ниже.
Для контекста: GPT-5.6 Sol прошла 81,99%, а GPT-5.5 до нее — 78,66%. Таким образом, GPT-6 Sol все еще находится выше предыдущего поколения, но чуть ниже своей «сестры».
Количество пропущенных завершений идентично в обоих запусках и составляет 0,09% — это 4 задачи из 4444, по которым не было получено пригодного кода. Оба варианта доводят начатое до конца.
Примерно одно из шести решений в подмножестве с тестами не проходит их, против одного из семи у Astra. Это самое явное различие между двумя вариантами, и это число, которое нужно сопоставить со всем тем, что Sol делает хорошо ниже.
Сколько кода генерирует GPT-6 Sol по сравнению с Astra?
Sol сгенерировала 480 125 строк в рамках бенчмарка. Astra сгенерировала 656 445. Это на 26,9% меньше кода для тех же 4444 задач.
Для этого она использовала 50 077 функций, что меньше, чем 65 513 (сокращение на 23,6%). Если рассчитать это на функцию, получится 9,6 строки против 10,0 у Astra, так что функции стали немного меньше. Это меньше кода при примерно той же гранулярности, а не та же работа, упакованная в более плотные единицы.
Количество строк комментариев сократилось гораздо сильнее, чем количество кода. Плотность комментариев составляет 1,3% от вывода против 4,2%, что в абсолютном выражении составляет 6 219 строк комментариев против 28 824 у Astra. Sol возвращается к диапазону, в котором находились варианты GPT-5.6 (1,5% и 0,9%).
Для любого, кто будет поддерживать этот код в будущем, встроенного контекста значительно меньше, чем предоставляла Astra.
Генерирует ли GPT-6 Sol более сложный код, чем Astra?
Обе меры сложности немного выросли, причем почти на одну и ту же величину.
Цикломатическая сложность составляет 225,56 на kLOC против 220,93 (рост на 2,1%). Когнитивная сложность составляет 167,38 на kLOC против 163,38 (рост на 2,4%).
При таком объеме ни одно из этих изменений само по себе не является значимым. Важно направление в сочетании с объемом. Sol распределяет чуть более плотную логику на 27% меньшее количество строк, поэтому общее количество ветвлений и вложений в выводе существенно сократилось, даже несмотря на то, что показатели на строку немного выросли.
Какова плотность ошибок GPT-6 Sol по сравнению с GPT-6 Astra?
Плотность ошибок составляет 629 на mLOC против 558. Рост на 12,8%.
Серьезность надежности на mLOC
GPT-6 Astra
GPT-6 Sol
БЛОКИРУЮЩАЯ
КРИТИЧЕСКАЯ
ВЫСОКАЯ
229
300
НИЗКАЯ
222
229
Два уровня серьезности поменялись местами. Количество блокирующих ошибок выросло на 51%, с 37 до 56 на mLOC. Критические ошибки упали на 37%, с 70 до 44. Высокие выросли на 31%, а низкие практически не изменились.
Astra концентрировала свои серьезные замечания на критическом уровне. Sol переносит больше из них на блокирующий уровень, который с наибольшей вероятностью попадет в продакшн. Это стоит учитывать, даже если в сумме они примерно компенсируют друг друга.
В абсолютном выражении картина более благоприятная, так как кода на 27% меньше. Sol произвела 302 ошибки в рамках бенчмарка против 366 у Astra, то есть на 17,5% меньше ошибок в целом, несмотря на более высокий показатель на строку.
Категория ошибки
GPT-6 Astra/mLOC
GPT-6 Sol/mLOC
Параллелизм / многопоточность
276
242
Производительность / структура
112
Утечки ресурсов / потоков
Безопасность типов / приведения
Null / значения данных
Обработка исключений
Шаблоны / регулярные выражения
Нарушение контракта API
Ошибка потока управления
Структура данных
Без категории
Итого
559
629
Параллелизм и многопоточность по-прежнему являются крупнейшей категорией ошибок в обоих вариантах, и именно здесь наблюдается улучшение. Sol снижает этот показатель на 12% (с 276 до 242 на mLOC) и на 36% в абсолютном выражении (со 181 замечания до 116).
Обработка исключений также улучшилась: снижение на 51% по частоте и с 44 до 16 замечаний.
Большинство других категорий выросли по частоте. Ошибки с Null и значениями данных выросли более чем вдвое, поток управления — более чем вдвое, безопасность типов — на 79%, утечки ресурсов — на 71%. Однако посмотрите на количество замечаний рядом с ними. Утечки ресурсов выросли с 25 до 31, а безопасность типов — с 19 до 25, так что это скромные абсолютные изменения на небольших базах, усиленные меньшим знаменателем.
Замечания по параллелизму остаются самыми «дорогими» независимо от улучшений. Их трудно воспроизвести, они зависят от среды выполнения и проявляются как периодические сбои, а не как чистые ошибки. Категории, которые их отмечают, узкие и специфичные: double-checked locking, блокировка, не освобождаемая на каждом пути выхода из метода, синхронизация по полю, которое переназначается, инкремент счетчика на volatile-поле и вызовы wait или notify без удержания блокировки. Они появляются в настройках синглтонов и кэшей, пулах соединений и воркеров, общих счетчиках, а также очередях производителей и потребителей.
Какие уязвимости безопасности генерирует GPT-6 Sol в коде?
Это единственная область, где написание меньшего количества кода не привело к меньшему количеству замечаний.
Плотность уязвимостей составляет 285 на mLOC против 178. Рост на 60%. И в отличие от ошибок и «запахов» кода, абсолютное количество тоже выросло — со 117 до 137, что на 17,1% больше при 27% меньшем объеме кода.
Серьезность безопасности на mLOC
GPT-6 Astra
GPT-6 Sol
БЛОКИРУЮЩАЯ
КРИТИЧЕСКАЯ
142
198
ВЫСОКАЯ
НИЗКАЯ
Плотность блокирующих уязвимостей составляет 2 на mLOC, что ниже 3, и это самый низкий показатель, который мы когда-либо регистрировали для этого семейства. Относитесь к этим показателям с осторожностью, потому что базовые числа крошечные: одна блокирующая уязвимость в выводе Sol и две в Astra. Оба варианта очень чисты на вершине шкалы серьезности, и на этой шкале одно обнаружение сдвигает показатель на целый пункт.
Все, что ниже блокирующего уровня, выросло. Критические уязвимости выросли на 39% до 198 на mLOC, серьезные более чем удвоились, а незначительные выросли на 167%. Критические уязвимости остаются доминирующим уровнем, составляя 69% плотности безопасности, против 80% для Astra.
Категория уязвимостей
GPT-6 Astra
GPT-6 Sol
Неправильная конфигурация криптографии
106
Небезопасная обработка системных ресурсов
Атака внедрением
Неадекватная обработка ошибок (ввод/вывод)
Пропуски проверки сертификатов
Неправильная конфигурация криптографии является крупнейшей категорией в обоих вариантах, и ее показатель вырос на 39%, в то время как количество оставалось примерно постоянным. Небезопасная обработка системных ресурсов показала то же самое: 39% по показателю и аналогичное количество обнаружений. Эти две категории оставались стабильными в абсолютном выражении и выглядят как увеличение только потому, что модель улучшилась в других областях.
Истинные увеличения — это атаки внедрением, с 10 до 18 обнаружений, и неадекватная обработка ошибок, с 3 до 8. Обе категории невелики.
Неправильная конфигурация криптографии и небезопасная обработка системных ресурсов вместе составляют 191 из 284 на mLOC, так что две трети поверхности безопасности приходятся на две категории. Это было верно для каждой модели в этом семействе, и это ответ на вопрос, куда в первую очередь должен быть направлен конвейер. Неправильная конфигурация криптографии охватывает слабые алгоритмы, небезопасные размеры ключей и генераторы случайных чисел, используемые ненадлежащим образом.
Насколько поддерживаем код, сгенерированный GPT-6 Sol?
Плотность «запахов кода» составляет 19,62 на kLOC, по сравнению с 18,47. Увеличение на 6,2%.
В абсолютном выражении количество «запахов» существенно снизилось, с 12 123 до 9 420 обнаружений, что на 22,3% меньше.
Серьезность поддерживаемости на mLOC
GPT-6 Astra
GPT-6 Sol
БЛОКИРУЮЩИЙ
КРИТИЧЕСКИЙ
2 990
3 235
СЕРЬЕЗНЫЙ
8 595
10 308
НЕЗНАЧИТЕЛЬНЫЙ
6 101
5 261
ИНФО
722
764
Обнаружения блокирующих проблем поддерживаемости снизились на 12%. Незначительные снизились на 14%. Серьезные выросли на 20% и несут основную часть увеличения плотности.
Категория «запахов кода»
GPT-6 Astra/mLOC
GPT-6 Sol/mLOC
Тип параметра коллекции / обобщений
7 987
8 619
Лучшие практики проектирования / фреймворков
2 616
2 587
Когнитивная вычислительная сложность
1 999
2 406
Регулярные выражения / шаблоны / формат строк
2 096
1 941
Присваивание / поле / видимость области действия
1 368
1 323
Мертвый / неиспользуемый / избыточный код
871
948
Управляющая / условная логика
801
846
Именование / стиль / документация
455
487
Устаревание / устаревший API
171
296
Структура / архитектура
Без категории
102
165
Всего
18 468
19 620
Это таблица, где два столбца рассказывают самую ясную историю. Количество обнаружений в каждой категории снизилось, за исключением использования устаревшего API, которое выросло со 112 до 142. Коллекции и обобщения снизились с 5 243 до 4 138 обнаружений. Дизайн и фреймворки снизились с 1 717 до 1 242. Регулярные выражения и форматирование строк снизились с 1 376 до 932.
По показателю большинство тех же категорий выросли, потому что знаменатель сокращался быстрее, чем количество обнаружений. Это честное прочтение профиля поддерживаемости Sol: всего меньше, распределено по меньшему объему кода, поэтому показатель на строку увеличивается, в то время как объем работы уменьшается.
Коллекции и обобщения по-прежнему являются крупнейшей категорией «запахов» с большим отрывом в обоих вариантах. Это «сырые» типы там, где должны быть параметризованные обобщения, и обработка коллекций, которая обходит типобезопасность. В Java они несут реальные издержки. «Сырые» типы обходят проверки обобщенных типов и производят непроверенные предупреждения, они усложняют рефакторинг и откладывают обнаружение небезопасного кода до времени выполнения, тогда как правильно типизированная реализация обнаружила бы его во время компиляции.
Использование устаревшего API — это то, за чем стоит следить: рост на 73% по показателю и увеличение по количеству.
Как объем кода GPT-6 Sol влияет на общее количество обнаружений?
Общее количество обнаружений
GPT-6 Astra
GPT-6 Sol
Ошибки
366
302
Уязвимости
117
137
«Запахи кода»
12 123
9 420
Все проблемы
12 606
9 859
Общее количество обнаружений снизилось на 21,8%. Ошибки снизились на 17,5%, а «запахи кода» — на 22,3%. Уязвимости выросли на 17,1%.
Все показатели плотности пошли в другом направлении. Плотность ошибок выросла на 12,8%, плотность уязвимостей — на 60%, плотность «запахов кода» — на 6,2%, общая плотность проблем — на 6,9%.
Таким образом, два показателя указывают в противоположных направлениях по трем из четырех пунктов, и разрыв между ними составляет 27% сокращения объема. Плотность показывает, насколько чист код на каждую написанную строку. Абсолютные значения показывают, сколько работы существует. Для команды, оценивающей объем работы по проверке, Sol производит меньше работы: 480 000 строк вместо 656 000, и 9 859 обнаружений вместо 12 606. Для команды, сравнивающей, насколько тщательно нужно читать каждую строку, Astra является более чистым результатом.
Уязвимости — это исключение, на котором стоит остановиться, потому что это единственная категория, по которой оба показателя совпадают. Sol произвел больше уязвимостей в абсолютном выражении при меньшем объеме кода. Это не эффект знаменателя, и это самый ясный аргумент в пользу Astra между двумя вариантами.
Как GPT-6 Sol и GPT-6 Astra сравниваются по использованию токенов?
Входные токены были идентичны в обоих запусках и составляли 1 322 069, что и следовало ожидать от моделей, использующих один и тот же токенизатор.
Выходные токены снизились на 5,1%, с 6,65 миллиона для Astra до 6,30 миллиона для Sol. В сравнении с уменьшением объема кода на 26,9% это означает, что Sol потратил больше токенов на строку вывода, чем Astra.
Токены рассуждений — это то, где два варианта расходятся. Sol использовал 2,64 миллиона против 1,36 миллиона у Astra, таким образом, он почти удвоил свой бюджет рассуждений, производя при этом немного меньше вывода. Общее количество токенов для Sol все равно оказалось на 4,3% ниже, составив 7,63 миллиона против 7,97 миллиона, потому что увеличение рассуждений в абсолютном выражении меньше, чем сокращение кода.
Больше размышлений, меньше написания. Это разумное описание того, что отличает эти два варианта.
Каковы самые большие риски использования кода, сгенерированного GPT-6 Sol, в продакшене?
Sol является более лаконичным из двух вариантов GPT-6 и в целом производит меньше работы. Он также жертвует некоторой корректностью и чистотой кода на строку, чтобы достичь этого. Три области, куда следует направить усилия по проверке.
Безопасность — это первое, и это единственное место, где два показателя совпадают. Плотность уязвимостей выросла на 60%, а абсолютное количество — на 17% при уменьшении объема кода на 27%. Неправильная конфигурация криптографии и небезопасная обработка системных ресурсов составляют две трети этой поверхности, и обе хорошо покрываются автоматическим анализом. Блокирующие обнаружения очень низки в обоих вариантах, составляя 2 на mLOC для Sol, так что речь идет о критическом уровне, а не о самом серьезном.
В целом эти два показателя примерно компенсируют друг друга, но соотношение смещается в сторону уровня с наибольшим воздействием. Если ваш шлюз качества придает блокирующим обнаружениям больший вес, чем критическим, это смещение проявится.
Разрыв в корректности — третий. 83,09% против 85,85% означает, что примерно одно из шести решений не проходит тесты, а не одно из семи. Для 544 задач, поддерживаемых тестами, это разница примерно в 15 решений. Важность этого зависит от того, насколько вы полагаетесь на процент успешных прохождений тестов по сравнению с тем, насколько вы цените меньшую поверхность для проверки.
Конкурентность – хорошая новость. Это остаётся крупнейшей категорией ошибок в обоих вариантах, и Sol улучшает её по обоим показателям, снижая на 12% по частоте и на 36% по количеству обнаружений.
Три вывода:
- Sol – лаконичный вариант. 26,9% меньше кода, чем у Astra для тех же задач, 23,6% меньше функций и на 21,8% меньше обнаружений в сумме. Ошибки и запахи кода снизились в абсолютных цифрах.
- Безопасность – исключение. Уязвимости выросли как по плотности, так и по количеству, что делает их единственным типом обнаружений, где меньше кода не означает меньше работы. Обнаружения блокирующего уровня остаются очень низкими – 2 на миллион строк кода.
- Варианты – это выбор, а не рейтинг. Astra для более высокого коэффициента прохождения и более чистого профиля на строку. Sol для меньшей поверхности обзора и меньшего количества обнаружений, которые нужно обработать. Выбирайте в зависимости от того, является ли узким местом глубина обзора или объём обзора.
Полные результаты оценки GPT-6 Sol, а также всех остальных моделей, которые мы измеряли, находятся на таблице лидеров Sonar LLM.
