OpenAI GPT-6 Sol: Оценка

По сравнению с 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. Плотность сложности и «запахов» кода (code smells) указана на 1000 строк кода (kLOC). Плотность ошибок и уязвимостей, а также все разбивки по категориям указаны на миллион строк (mLOC).

Два термина, которые стоит определить в первую очередь:

• Цикломатическая сложность: подсчитывает количество независимых путей через функцию.
• Когнитивная сложность: метрика SonarQube, которая придает больший вес вложенной и сильно разветвленной логике, отражая то, насколько сложно человеку читать код.

Ни одна из них не говорит о том, работает ли код. Обе помогают определить, сколько логики придется осмыслить рецензентам и тестировщикам.

Как GPT-6 Sol и GPT-6 Astra соотносятся по ключевым метрикам?

Метрика

GPT-6 Astra

GPT-6 Sol

Строк кода (всего)

656 445

480 125

Плотность комментариев (% от LOC)

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

BLOCKER (Блокирующая)

CRITICAL (Критическая)

MAJOR (Значительная)

229

300

MINOR (Незначительная)

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

BLOCKER (Блокирующая)

CRITICAL (Критическая)

142

198

MAJOR (Значительная)

MINOR (Незначительная)

Плотность блокирующих уязвимостей составляет 2 на млн строк кода (mLOC) по сравнению с 3 ранее, и это самый низкий показатель, который мы фиксировали для этого семейства моделей. К этим цифрам стоит относиться с осторожностью, поскольку абсолютные значения крайне малы: одна блокирующая уязвимость в коде Sol и две в Astra. Оба варианта показывают очень хорошие результаты на верхнем уровне критичности, и при таком масштабе одна находка меняет показатель сразу на целый пункт.

Все показатели ниже уровня блокирующих уязвимостей выросли. Критические уязвимости увеличились на 39% до 198 на млн строк кода, значительные — более чем вдвое, а незначительные — на 167%. Критические уязвимости остаются доминирующей категорией, составляя 69% от плотности безопасности против 80% у Astra.

Категория уязвимости

GPT-6 Astra

GPT-6 Sol

Неверная конфигурация криптографии

106

Небезопасная обработка системных ресурсов

Инъекционные атаки

Неадекватная обработка ошибок (ввод-вывод)

Пропуски проверки сертификатов

Неверная конфигурация криптографии является крупнейшей категорией в обоих вариантах, и ее показатель вырос на 39%, в то время как количество находок осталось примерно на прежнем уровне. То же самое произошло с небезопасной обработкой системных ресурсов: рост показателя на 39% при схожем количестве находок. Эти две категории оставались стабильными в абсолютном выражении и выглядят как рост только потому, что модель улучшилась в других областях.

Реальный рост наблюдается в категории инъекционных атак — с 10 до 18 находок, и в неадекватной обработке ошибок — с 3 до 8. Обе категории являются небольшими.

Неверная конфигурация криптографии и небезопасная обработка системных ресурсов вместе составляют 191 из 284 на млн строк кода, то есть две трети поверхности безопасности сосредоточены в двух категориях. Это было верно для каждой модели в данном семействе, и это ответ на вопрос, на что в первую очередь должен быть направлен конвейер проверки. Неверная конфигурация криптографии охватывает слабые алгоритмы, небезопасные размеры ключей и генераторы случайных чисел, используемые ненадлежащим образом.

Насколько поддерживаемым является код, созданный GPT-6 Sol?

Плотность запахов кода (code smells) составляет 19,62 на тыс. строк кода (kLOC) по сравнению с 18,47. Рост на 6,2%.

В абсолютном выражении количество запахов кода существенно снизилось: с 12 123 до 9 420 находок, что на 22,3% меньше.

Серьезность поддерживаемости на млн строк кода

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

Regex / шаблоны / форматирование строк

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. Regex и форматирование строк — с 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, то есть почти удвоил бюджет на рассуждения, производя при этом немного меньше вывода. Общее количество токенов все равно оказалось на 4,3% ниже для Sol (7,63 млн против 7,97 млн), потому что рост рассуждений в абсолютном выражении меньше, чем сокращение кода.

Больше размышлений, меньше написания. Это разумное описание того, что разделяет эти два варианта.

Каковы самые большие риски использования кода, созданного GPT-6 Sol, в производстве?

Sol — более лаконичный из двух вариантов GPT-6, и он создает меньше работы в целом. Он также жертвует частью корректности и чистоты на строку, чтобы достичь этого. Три области, на которые стоит направить усилия по проверке.

Безопасность на первом месте, и это единственная область, где оба метода оценки согласны. Плотность уязвимостей выросла на 60%, а абсолютное количество — на 17% при сокращении объема кода на 27%. Неверная конфигурация криптографии и небезопасная обработка системных ресурсов составляют две трети этой поверхности, и обе хорошо покрываются автоматизированным анализом. Блокирующие находки очень редки в обоих вариантах (2 на млн строк кода для Sol), поэтому речь идет о критическом уровне, а не о самом серьезном.

В сумме эти два фактора примерно компенсируют друг друга, но состав смещается в сторону наиболее значимого уровня. Если в вашем шлюзе качества блокирующие находки имеют больший вес, чем критические, это смещение будет заметно.

Разрыв в корректности — третий фактор. 83,09% против 85,85% означает, что примерно одно из шести решений не проходит тесты, а не одно из семи. На 544 задачах с поддержкой тестов это разница примерно в 15 решений. Имеет ли это значение, зависит от того, насколько вы полагаетесь на процент прохождения тестов по сравнению с тем, насколько вы цените меньшую поверхность для проверки.

Параллелизм — это хорошая новость. Он по-прежнему остается крупнейшей категорией ошибок в обоих вариантах, и Sol улучшает показатели по обоим критериям: снижение на 12% по частоте и на 36% по количеству обнаруженных проблем.

Три основных вывода:

• Sol — это лаконичный вариант. На 26,9% меньше кода, чем в Astra для тех же задач, на 23,6% меньше функций и на 21,8% меньше выявленных проблем в целом. Как ошибки, так и «запахи кода» сократились в абсолютном выражении.
• Безопасность — исключение. Уязвимости выросли как по плотности, так и по количеству, что делает их единственным типом проблем, где меньший объем кода не привел к уменьшению объема исправлений. Количество критических проблем остается очень низким — 2 на миллион строк кода (mLOC).
• Эти варианты — выбор, а не рейтинг. Astra подходит для более высокого процента успешных проверок и более чистого профиля кода на строку. Sol — для меньшей поверхности проверки и меньшего количества проблем, которые нужно проработать. Выбирайте в зависимости от того, что является вашим «узким местом»: глубина проверки или объем проверяемого кода.

Полные результаты оценки GPT-6 Sol, наряду со всеми другими моделями, которые мы измеряли, представлены в таблице лидеров Sonar LLM.