OpenAI опубликовала бенчмарк MultiLangBench и результаты второго, закрытого теста на перенос COBOL-программ на современные языки. Сухие цифры: GPT-6 Astra проходит 87,4% тестов MultiLangBench, GPT-5.6 Sol - 26,8%, COBOL остаётся самым сложным языком с результатом 72,1%. В закрытом тесте GPT-6.1 Sol даёт 86,6% при низком уровне рассуждений и 97,9% при повышенном, тогда как прошлое поколение моделей справляется с 5,4% заданий. Подробный разбор публикации и методики приводит Habr.
Смешивать эти числа нельзя, они про разное. MultiLangBench измеряет генерацию с нуля на незнакомом языке: модель пишет новый код без доступа к сети и без исходников SQLite. Закрытый тест измеряет перенос существующей COBOL-программы с требованием побайтового совпадения результата. Разные модели, разные задачи, разный смысл у процентов.
Отдельно OpenAI сообщила об улучшении работы своих моделей с устаревшими языками программирования и переносом программ на новые языки, назвав среди примеров COBOL, Fortran и Visual Basic (обзор заявления).
Что OpenAI опубликовала и какие цифры важно запомнить
Три модели, два теста: как не запутаться в названиях
В названиях легко потеряться, потому что в публикации фигурируют три модели и два разных замера. GPT-6 Astra - базовая линейка, на которой выстроены Sol и Luna, о чём мы писали в разборе выпуска GPT-6 Sol и Luna. Astra участвует в MultiLangBench, GPT-6.1 Sol - в закрытом тесте на перенос COBOL, GPT-5.6 Sol служит точкой отсчёта в обоих случаях.
| Модель | Тест | Результат |
|---|---|---|
| GPT-6 Astra | MultiLangBench, все 20 языков | 87,4% |
| GPT-5.6 Sol | MultiLangBench, все 20 языков | 26,8% |
| GPT-6 Astra | MultiLangBench, только COBOL | 72,1%, худший язык набора |
| GPT-6.1 Sol | Закрытый тест на перенос COBOL, низкий уровень рассуждений | 86,6% |
| GPT-6.1 Sol | Тот же тест, повышенный уровень рассуждений | 97,9% |
| Прошлое поколение моделей | Тот же тест, прежние настройки | 5,4% |
Читать таблицу стоит построчно, а не по диагонали. Разница между 26,8% и 87,4% относится к генерации кода с нуля, а разница между 5,4% и 97,9% - к переписыванию готовых программ. Это два разных навыка, и оба теста провела сама OpenAI.
Как устроен MultiLangBench: движок SQLite с нуля на 20 языках
Задача крупная по масштабу: модель должна с нуля написать движок базы данных, совместимый с SQLite 3.40.1, на одном из 20 языков. В наборе есть C, Python, COBOL, Fortran, Visual Basic, OCaml, Zig и Lean, язык математических доказательств. Интернета в окружении нет, все следы SQLite из него удалены, у модели остаётся только документация. Готовая программа получает файл базы и SQL-запрос, а содержимое базы после её работы проверяют настоящей SQLite.
Тесты взяты из собственного набора SQLite: из 51 тысячи OpenAI переделала 24 тысячи, а для оценки рекомендует 272. Эта деталь важна. 272 - рекомендованный набор для прогона, а не все 24 тысячи переработанных тестов, поэтому цифры MultiLangBench считаются по выборке, а не по полному корпусу.
Почему это сложнее, чем LeetCode-задачи
Совместимый движок означает большой связный проект: парсер SQL, хранилище, работа с транзакциями, типы данных, индексы и совместимый формат файла базы. Ошибка в одном слое ломает побайтовое содержимое базы, и тест падает целиком, даже если остальные 90% кода написаны верно.
Поэтому 87,4% у GPT-6 Astra - сильный результат для такой задачи. И поэтому же 72,1% на COBOL заметно ниже среднего: язык тянет вниз общий балл, хотя модель справляется с ним намного лучше, чем предыдущее поколение.
Почему COBOL, Fortran и Visual Basic исторически даются моделям хуже
Малоресурсность значит, что язык важный, но примеров для обучения мало. Модели учатся на открытом коде и обсуждениях, а открытого кода и документации на COBOL намного меньше, чем на Python или JavaScript: большая часть банковских программ никогда не покидала стен компаний. COBOL появился в 1959 году как язык для бизнес-расчётов и до сих пор работает в банках, страховых компаниях и госсекторе. Fortran в том же посте OpenAI назван языком прогнозов погоды и расчётов безопасности ядерных реакторов.
Историческая база была низкой. В апрельской статье о модели COBOL-Coder GPT-4o писала на COBOL компилируемый код в 41,8% случаев, а правильный с первой попытки - в 16,4%. Открытые CodeLlama, StarCoder2 и CodeGemma почти не выдавали программ, которые хотя бы компилируются, а перевод с Java на COBOL у универсальных моделей был близок к нулю. На этом фоне 72,1% у GPT-6 Astra выглядят серьёзным рывком, но это по-прежнему худший результат среди 20 языков бенчмарка.
Цифры IBM про COBOL: как их читать
OpenAI ссылается на оценки IBM: на COBOL держится больше 40% систем онлайн-банкинга, 80% оплат картой в магазинах и 95% операций в банкоматах. Оценка не очень прозрачная, поэтому цифры стоит воспринимать как порядок величины, а не как точную статистику. Методика подсчёта не раскрыта, независимого подтверждения этим процентам в доступных материалах нет.
Закрытый тест на перенос COBOL: что значит 97,9%
Второй тест устроен иначе. Модель получает работающую COBOL-программу и переписывает её на современный язык так, чтобы результат работы совпадал побайтово. Сравнивается не стиль кода и не структура файлов, а выход программы. Прошлое поколение моделей справлялось с 5,4% заданий, GPT-6.1 Sol при тех же настройках - с 86,6%, при повышенном уровне рассуждений - с 97,9%.
Набор задач закрыт. Снаружи нельзя ни посмотреть его состав, ни прогнать свою модель на тех же примерах, поэтому методику проверяет только сама OpenAI. Скачок с 5,4% до 97,9% выглядит впечатляюще, и он действительно большой, но измерен на внутреннем наборе разработчика.
Почему «повышенный уровень рассуждений» даёт +11 процентных пунктов
Разница между 86,6% и 97,9% - это цена режима «подумать дольше». Модель тратит больше вычислений и времени на каждую задачу, качество переноса растёт. Для практики это означает, что точность управляется настройкой: там, где важна каждая строка, можно включить длинное рассуждение и заплатить задержкой и токенами.
Конкретных цен и замеров времени в публикации нет, подставлять свои цифры не стоит. Известен только сам факт: прирост точности покупается вычислениями.
Перенос программы vs миграция системы: где заканчивается бенчмарк
Перенос отдельной программы - локальная задача с проверяемым результатом: есть вход, есть выход, есть побайтовое сравнение. Миграция системы собирается из десятков и сотен таких программ и добавляет то, чего в тесте нет: общие copybook'и, JCL, транзакционные среды, интеграции, регламентные задания, данные в VSAM и DB2.
Главное, что не проверяется в закрытом тесте, - бизнес-правила. Логика расчёта процентов, порядок проводок, обработка округлений часто нигде не задокументирована и живёт только в коде, который переписывают. Модель может выдать программу, идентичную на тестовом наборе, и всё равно ошибиться на граничных данных, которых в тестах не было. Побайтовое совпадение на выборке не гарантирует совпадения на реальном потоке операций.
Проверка бизнес-правил и корректности расчётов остаётся задачей людей: кто-то должен подтвердить, что правило начисления или проводки сохранило смысл, а не только форму вывода. Что именно измеряют бенчмарки переноса кода и чем они отличаются от привычных coding-тестов, разобрано в материале о Program-Bench, SRE-Bench и Code Migration.
Ограничения: вендорский бенчмарк, закрытый набор, нет сравнений с Claude и Gemini
Список ограничений короткий и жёсткий. Оба теста провела сама OpenAI. Сравнений с Claude и Gemini в опубликованных материалах нет. Набор для миграции COBOL закрыт. Независимых прогонов MultiLangBench пока не опубликовано. Значит, все проценты - это отчёт разработчика о собственной модели, а не внешняя проверка.
Контекст конкуренции объясняет, почему отчёт появился именно сейчас. В феврале Anthropic заявила, что Claude Code берёт на себя самую трудоёмкую часть модернизации COBOL: разбор и документирование старого кода. По версии Anthropic, компании смогут обновлять такие системы «за кварталы, а не за годы». В тот день акции IBM, чьи мейнфреймы десятилетиями обслуживают этот код, упали на 13,2%, сильнее всего с октября 2000 года. Рынок legacy-модернизации горячий, и вендорские проценты стоит читать с поправкой на коммерческий интерес.
Есть и общая проблема чтения бенчмарков: наборы задач, версии моделей и условия прогона меняются, поэтому цифры из разных отчётов плохо стыкуются между собой. Об этом мы подробно писали в разборе MiniCPM5-2B, где отдельно объясняется, почему сводные бенчмарки из разных лет сравнивать нельзя.
Что это значит на практике: как использовать результат, не обманываясь
Сценарии, где модели уже полезны команде с legacy-кодом: разбор и документирование старого COBOL-кода, черновик переноса отдельной программы, генерация тестовых кейсов по существующей логике, объяснение кода новым разработчикам. Во всех этих задачах человек остаётся тем, кто подтверждает смысл написанного.
Где без проверки человека нельзя: бизнес-правила, расчёты, граничные случаи, обработка ошибок, интеграции с внешними системами. Здесь 97,9% из отчёта не заменят собственного набора эталонных тестов.
Порядок действий для команды, которая рассматривает миграцию, выглядит так. Взять 10-20 программ, по которым есть чем сравнить результат, прогнать перенос через модель в двух режимах рассуждений, сравнить выход побайтово и разобрать каждое расхождение руками. Такой пилот даёт цифру для своего кода и своего набора данных. Решение о полной миграции зависит от состояния регрессионных тестов и критичности расчётов, а не от вендорского процента.
Итог: прогресс реальный, но проверять всё равно людям
Модели заметно продвинулись в генерации кода на старых языках и в переносе отдельных программ. 87,4% в MultiLangBench против 26,8% у предыдущего поколения и рост с 5,4% до 97,9% в закрытом тесте - это большой сдвиг за одно поколение. COBOL при этом остаётся самым сложным языком даже у GPT-6 Astra, с 72,1%. Оба замера сделаны самой OpenAI, набор для COBOL закрыт, независимых прогонов MultiLangBench нет.
Инструмент стал сильнее, ответственность за бизнес-правила и корректность расчётов остаётся на людях. Если планируете миграцию, начинайте с собственных эталонных тестов и пилота на ограниченном наборе программ, а не с процентов из вендорского отчёта.