GPT-6.1 Sol на COBOL: 86,6% против 5,4%, и только один из двух тестов можно перезапустить

19 октября 2026 года OpenAI опубликовала две оценки программирования для низкоресурсных языков, и главное число принадлежит GPT-6.1 Sol: 86,6% задач по миграции с COBOL прошли при низком уровне рассуждения против 5,4% у GPT-5.6 Sol при той же настройке; при повышении уровня этот показатель возрастает до 97,9%. Вторая оценка, MultiLangBench, — это история другой модели: GPT-6 Astra показала в среднем 87,4% на двадцати языках при максимальном уровне рассуждения, но именно она является более полезной половиной релиза, потому что OpenAI выложила свой испытательный стенд на GitHub под Apache-2.0, и вы можете запустить его сами уже сегодня днём. Оценка миграции с COBOL — та, что содержит 86,6%, — это другое дело: её тесты скрыты, критерием прохождения является побайтовое совпадение вывода с кейсами, которые никто за пределами OpenAI не видел, и ни одна третья сторона её не воспроизвела. Эта асимметрия — вся суть, и её стоит прямо изложить, прежде чем любое из этих чисел будет процитировано в бизнес-обосновании миграции. Документированные сбои ИИ и инциденты с агентами, стоящие за подобными релизами, собраны в архиве инцидентов ИИ OrcaRouter, где каждая запись содержит собственные источники, степень серьёзности, уровень уверенности и отметку о спорности.

Одну дату стоит запомнить. Сам GPT-6.1 Sol датируется 29 сентября 2026 г. — это не запуск, и ничто здесь не меняет веса модели, её цену или тарифную сетку. 19 октября произошло следующее: O​penAI опубликовала данные о том, на что способна модель в категории, которую ранее не документировала, и выпустила бенчмарк, который может повторно запустить любой желающий. Именно об этом событии и рассказывается в этом материале.

Что на самом деле было опубликовано и для чего нужна каждая половина

Эти две оценки отвечают на разные вопросы, и сама формулировка OpenAI их разделяет. MultiLangBench спрашивает, может ли модель создать что-то на языке, на котором никто не обучает: реализовать SQLite 3.40.1 с нуля на одном из двадцати языков программирования, а затем пройти набор тестов на соответствие требованиям к базе данных. Оценка миграции с COBOL спрашивает, может ли модель перенести что-то: перевести программы на COBOL в C++, Java, Kotlin, Python или Rust, точно сохраняя наблюдаемое поведение.

Первый — это тест минимального уровня возможностей. Второй — то, что действительно волнует предприятия, поскольку COBOL — не просто курьёз для бенчмарков: по давним оценкам IBM, на COBOL работают более 40% систем онлайн-банкинга и около 95% транзакций банкоматов, а код поддерживается рабочей силой, которая не восполняется.

• MultiLangBench, максимальные усилия — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra преодолела порог 83% в 19 из 20 языков; COBOL оказался её самым слабым местом — 72,1% против 10,9% у GPT-5.6 Sol, что говорит о том, что самый сложный язык в наборе по-прежнему тот, у которого самый старый инструментарий.

• Миграция COBOL, низкие трудозатраты — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, при оценке в 61% от стоимости API старой модели за оценочный прогон, или на 39% меньше.

• Миграция с COBOL, повышенная трудоёмкость — GPT-6.1 Sol 97,9%, что OpenAI описывает как близкое к насыщению.

• Детализация по языкам, которую OpenAI всё же опубликовала — Fortran: 83,5% у Astra против 21,4% у GPT-5.6 Sol; Visual Basic: 89,4% против 27,5%; OCaml: 85,8% против 25,6%; GPT-6 Luna — 17,1% по COBOL, 31,4% по Fortran, 34,1% по OCaml и 41,6% по Visual Basic.

• Стоимость одного образца на MultiLangBench — примерно $0.77 для GPT-6 Luna против $3.48 для GPT-5.6 Sol, примерно на 78% ниже; именно это число делает самую слабую модель в таблице интересной для конвейера генерации сборок.

Оценка, которую можно запустить повторно: что на самом деле требует MultiLangBench

Репозиторий — github.com/openai/MultiLangBench, лицензия Apache-2.0, и читать тестовую обвязку информативнее, чем читать таблицу лидеров. Задача достаточно конкретна, чтобы модель не могла её заблефовать: создать исполняемый файл, который принимает путь к базе данных в качестве аргумента командной строки, читает SQL-запрос из stdin и ведёт себя как SQLite 3.40.1. Тесты взяты из собственного TCL-набора тестов SQLite — всего около 51 000 тестов, из которых примерно 24 000 были преобразованы в тройки, используемые обвязкой: исходная база данных, пользовательский запрос и проверочный запрос. Имена тестов — это SHA-256-хэши этих компонентов, поэтому набор нельзя запомнить по именам.

Сложность заключается именно в правилах, и каждое из них закрывает путь к упрощению:

• Нет доступа в интернет, и нигде в окружении нет SQLite. Тестовый стенд требует сначала убрать все следы SQLite. Модель не может запустить настоящий движок через командную оболочку и не может загрузить реализацию.

• Проверка выполняется на реальной SQLite 3.40.1. Ваша реализация изменяет базу данных; тестовый стенд извлекает её и проверяет с помощью настоящего продукта. Приблизительное поведение не пройдёт проверку.

• Шестьдесят секунд на тест, а ответ не на том языке оценивается в ноль. Смешивание языков приводит к провалу, а тестовый стенд отмечает, что для проверки того, на каком языке вы на самом деле писали, может использоваться другая модель. Это последнее правило существует потому, что очевидная уловка — написать на Python и обернуть её — первое, что пробует способная модель.

• Быстрый прогон — это 272 теста, а не 24 000. В README рекомендуется запускать только тесты, имена которых начинаются с 00, 01 или 02, если вы хотите получить сопоставимое число. Именно это стоит учитывать, прежде чем сравнивать свой результат с OpenAI: полный прогон всего набора и быстрый прогон — это не одно и то же измерение, и в README об этом сказано.

Это настоящий, проверяемый бенчмарк. Он также говорит вам кое-что, о чём не сообщали в прессе: заголовочные 87,4% были измерены на наборе тестов, который вы можете применить к собственной модели, — и это достаточно редкий случай, чтобы загрузка того стоила.

Оценка, которую невозможно повторить, и почему это не обязательно скандал

Оценка миграции COBOL разработана O​penAI, проводится O​penAI и оценивается O​penAI, а её тестовые случаи не опубликованы. Порог прохождения сформулирован точно — миграция засчитывается, только если каждый скрытый тест даёт побайтово идентичный наблюдаемый вывод — и именно эта точность делает результат непроверяемым извне: 86,6% — это измерение O​penAI на собственных скрытых случаях O​penAI. Только одну из двух оценок в релизе читатель может воспроизвести.

Отказ от публикации тестов миграции не является неоправданным. Предположительно, корпус составлен из реальных legacy-программ, и его публикация может привести к утечке клиентского кода или предоставить будущим моделям обучающий набор. Побайтовое совпадение — также по-настоящему консервативный критерий, более строгий, чем большинство оценок вендоров: он не поощряет перевод, который лишь близок к оригиналу.

Но именно с этим критерием и начинаются практические проблемы, и собственные оговорки OpenAI указывают на это. Результаты миграции по-прежнему требуют экспертной проверки и тестирования на соответствие бизнес-правилам и системным зависимостям перед вводом в промышленную эксплуатацию. А побайтовое совпадение труднодостижимо именно там, где сложен COBOL: язык усекает и округляет арифметику с фиксированной точкой не так, как большинство целевых языков, поэтому перевод может выглядеть правильным, проходить набор тестов, проверяющих «достаточную близость», и всё же сдвигать баланс на цент. Скрытый набор тестов, требующий точного равенства, справляется с этим; ваш собственный процесс проверки тоже должен с этим справляться, потому что оценка модели — это не утверждение о ваших программах.

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

Что 86,6% и 97,9% должны изменить в решении

Честная интерпретация уже, чем заголовки, и полезнее их. Базовая модель с 5,4% — это не модель, которая работает наполовину; это модель, которая почти никогда не выдаёт перевод с сохранением поведения, поэтому старшее поколение никогда не было кандидатом для этой работы. GPT-6.1 Sol с 86,6% находится в диапазоне, где экономика меняется на противоположную: инструмент, который готовит большую часть перевода и оставляет проверку рецензенту, — это другой продукт по сравнению с тем, который не выдаёт ничего пригодного.

К цифре 97,9% при более высоком уровне усилий стоит относиться скептически — не потому, что она неверна, а потому, что она достигла насыщения. Как только бенчмарк приближается к своему потолку, он перестаёт различать модели и начинает измерять сам набор тестов, и OpenAI прямо это признаёт. Для планирования считайте 86,6% при низком уровне усилий дешёвой рабочей точкой, а 97,9% — потолком того, что может показать эта оценка, а не обещанием точности для вашей кодовой базы.

Есть также перекрёстная проверка, которую стоит провести, и она противоречит ажиотажу. В тесте сборки COBOL остался самым слабым языком GPT-6 Astra с показателем 72,1%, хотя в целом Astra — более сильная модель со средним результатом 87,4%. Этот язык сложен в обоих направлениях. Модель, которая хорошо выполняет миграцию с COBOL в скрытом eval, не становится от этого хорошей в COBOL; она хороша в паттерне, который выбирает eval.

Ещё одна вещь, произошедшая на этой неделе: утверждение о трассировке рассуждений

Широко разошедшийся пост от 21 октября утверждал, что трассы рассуждений GPT-6.1 Sol «полностью читаемы, беспокоиться не о чем». Ничто в публикации O​penAI от 19 октября и ничто на странице документации самой модели не подтверждает, что это изменение в том, что возвращает API. Руководство O​penAI по рассуждениям прямо указывает, что необработанные токены рассуждений не раскрываются — элементы рассуждений остаются непрозрачными — и что запросить можно сводку рассуждений с помощью summary параметра, при этом зашифрованное содержимое рассуждений воспроизводится между ходами. GPT-6.1 Sol поддерживает форму all_turns такого воспроизведения. Канал сводок — это не читаемая трасса, и именно так, принимая одно за другое, делают заявление о безопасности по скриншоту.

То, что можно измерить, лежит рядом и представляет больший интерес для любого, кто проводит аудит агента. Оценка Sonar от 9 октября для GPT-6.1 Sol, проведенная в сравнении с GPT-6 Sol при среднем уровне усилий на 4 444 Java-задачах, показала, что количество токенов рассуждений снизилось на 51,4% — с 2,64 млн до 1,28 млн, — тогда как доля рассуждений в выводе упала с 41,8% до 19,5%, объем вывода вырос, а доля успешных функциональных проверок улучшилась с 83,09% до 85,29%. В том же прогоне плотность уязвимостей снизилась на 32,4%, но количество находок, связанных с надежностью критической серьезности, выросло с 21 до 46, причем крупнейшей категорией стали ошибки конкурентности — 196 находок. Это компромисс, на который рецензент может отреагировать. «Трассы читаемы» — нет, потому что возвращаются не трассы.

Для проекта миграции это имеет конкретное значение в одном отношении: ваш аудиторский след — это дифф и вывод тестов, а не повествование модели. Планируйте ресурсы на проверку соответственно — вывод Sonar о том, что на 39,4% больше сгенерированного кода дало в общей сложности 12 982 находки против 9 859, — это то, как выглядят затраты, скрывающиеся за оценкой в бенчмарке.

Самостоятельно запускать обе ветви

Практическая проблема такого сравнения заключается в том, что базовый вариант и новый вариант — это обычно два договора, два ключа и два отдельных порядка выставления счетов, а это создаёт достаточно препятствий, чтобы никто не запускал базовый вариант. Обе модели находятся в нашем каталоге через один ключ: openai/gpt-6.1-sol и openai/gpt-5.6-sol, по прайс-листовым ценам O​penAI с наценкой 0%, то есть те же $2.00 за вход и $10.00 за выход на миллион токенов, которые вы заплатили бы вендору, при этом кэшированный вход — $0.10, запись в кэш — $2.50, а тариф для объёма свыше 272K передаётся без наценки по $4.00, $0.20, $5.00 и $15.00. Изменение тарифов вендора вступает здесь в силу в день публикации, а не на следующем пересмотре контракта.

Именно такая сквозная передача делает бенчмарк в тот же день дешёвым в проведении: направьте быстрый набор MultiLangBench на обе модели, заплатите по прайс-листу за каждую — и получите цифру, относящуюся к вашему собственному инструментарию, а не к OpenAI. Автоматическое переключение при сбое — вторая половина аргумента: если новая модель деградирует во время прогона или на маршруте срабатывает ограничение частоты запросов, запрос не падает вместе с ней, и именно это позволяет поставить непроверенную модель перед конвейером миграции, пока у вас нет собственных подтверждений.

Инфраструктура MultiLangBench общедоступна, а кейсы миграции COBOL — нет, поэтому единственная честная проверка 86,6% — та, которую вы построите сами: возьмите выборку из нескольких сотен собственных программ на COBOL, переведите их и сравните вывод побайтово с исходным поведением. Это неделя работы, и она стоит больше, чем таблица поставщика.

Что посмотреть дальше

Три обстоятельства изменили бы эту картину, и ни одно из них ещё не произошло. Если бы OpenAI опубликовала кейсы миграции с COBOL или независимая лаборатория повторила их прогон, вендорская цифра превратилась бы в результат измерения. Если бы третья сторона воспроизвела таблицу MultiLangBench по языкам, мы узнали бы, является ли показатель COBOL 72,1% свойством языка или самого набора тестов. А независимые результаты модели в бенчмарках — Artificial Analysis сейчас присваивает GPT-6.1 Sol значение 52 по Intelligence Index и ставит её на двенадцатое место среди 214 моделей, при 55,2 выходных токена в секунду и $0,72 за задачу индекса — это проверка, которая вообще не зависит от собственных оценок OpenAI.

А до тех пор полезное резюме будет коротким. GPT-6.1 Sol — это модель от 29 сентября, возможности которой по работе с устаревшим кодом были задокументированы 19 октября: в одном тесте, который вы можете запустить, и одном, который не можете. Запускаемый тест говорит, что новое поколение относится к другому классу на низкоресурсных языках. Незапускаемый говорит, что миграция COBOL теперь заслуживает пилотного проекта. Только ваша собственная кодовая база может превратить любой из этих результатов в решение.