OpenAI сообщила об улучшении ИИ для COBOL, Fortran и Visual Basic
19 октября OpenAI рассказала об оценках моделей для языков программирования, которые представлены в обучающих данных слабее, чем Python или JavaScript. Компания описала MultiLangBench для создания совместимой с SQLite базы данных на 20 языках и отдельную оценку миграции программ COBOL с сохранением поведения. В опубликованных результатах заявлены улучшения у моделей GPT-6 Astra, GPT-6 Luna и GPT-6.1 Sol. Это результаты внутренней оценки OpenAI, а не независимое подтверждение качества для любой корпоративной системы.
Что изменилось
Проблема старых систем и редких языков
OpenAI связывает работу с тем, что COBOL, Fortran и Visual Basic поддерживают важные старые системы, но объем доступного кода и документации для них меньше, чем для популярных современных языков. В таких проектах правила предметной области могут быть известны только из исходников, а документация и авторы давно недоступны. Модель может помочь разобраться в структуре и подготовить изменения, однако она не знает автоматически всех эксплуатационных допущений, включая форматы файлов, округление, порядок транзакций и исторические исключения. Эти свойства следует обнаружить и записать до переписывания кода.
Два теста для разных задач
Первый тест MultiLangBench проверяет, способна ли модель построить с нуля движок базы данных с совместимостью SQLite на 20 языках. Второй оценивает миграцию существующей программы COBOL на другой язык при сохранении поведения. Различие существенно: генерация нового компонента и перенос устоявшейся логики требуют разной проверки. Проход тестов по спецификации не означает, что система прошла нагрузочную проверку, проверку безопасности или тестирование на закрытом коде заказчика. Полезно рассматривать такие оценки как ориентир для выбора модели и составления собственного контрольного набора.
Опубликованные показатели принадлежат оценке компании
По данным OpenAI, GPT-6 Astra получила 87,4% среднего прохождения тестов MultiLangBench на 20 языках против 26,8% у GPT-5.6 Sol. Для GPT-6 Luna указано 40,3% и приблизительно на 78% меньшая расчетная стоимость API. В тесте миграции COBOL компания сообщает о 86,6% точности для GPT-6.1 Sol при низком уровне рассуждения против 5,4% у GPT-5.6 Sol, а при более высоком уровне рассуждения - 97,9%. Эти числа следует цитировать с условиями и авторством оценки, а не переносить на любую кодовую базу.
Что проверить перед применением
Для пилота выберите небольшой модуль, исходное поведение которого можно зафиксировать тестами и эталонными данными. Сравните не только компиляцию, но и результаты на граничных значениях, точность денежных расчетов, форматирование, обработку ошибок и производительность. Сверьте новую реализацию по журналам и специалистом, который знает бизнес-правила старой системы. Не передавайте закрытые исходники в сервис, пока не проверены условия доступа и хранения. Если задача состоит в миграции, сохраните исходную и новую версии, отчет о различиях и список ручных решений для аудита.
Почему сохранение поведения важнее перевода синтаксиса
Программа может выглядеть устаревшей, но содержать неочевидную логику, накопленную после инцидентов и изменений законодательства. Автоматическая замена конструкций не показывает, почему возникло исключение. Команда должна отделить подтвержденное требование от случайного побочного поведения, которое нельзя менять без согласования. Зафиксируйте контракты входа и выхода, зависимости от пакетных процессов и порядок восстановления после сбоя. Только после этого стоит принимать предложения модели и включать их в ветку изменений. Критичные системы требуют обычного ревью, тестирования и плана отката независимо от заявленного процента точности.
Применимость к устаревшему коду проверяют по контрактам
До пилота составьте список внешних контрактов модуля: формат входного файла, результат пакетной обработки, правила округления, порядок фиксации транзакций и ожидаемые сообщения об ошибке. Если тестов мало, восстановите несколько эталонных случаев из журналов и подтвержденных бизнес-правил. Сравнивайте оригинальную программу и новую версию на одинаковых данных, включая границы диапазонов и редкие исключения. Разницу сначала объясняет инженер, а не модель. Такая проверка помогает понять, является ли отличие исправлением известного дефекта или нежелательным изменением поведения, которое повлияет на пользователей.
Оценку стоит читать как сигнал для инженерной проверки
MultiLangBench и миграционная оценка отвечают на отдельные исследовательские вопросы. Они полезны тем, что делают работу на менее распространенных языках измеримой, но не охватывают все компиляторы, библиотеки, версии среды и соглашения конкретного работодателя. Перед сравнением моделей уточните, совпадает ли версия и режим с опубликованной оценкой. Затем отберите характерные фрагменты своей системы и оцените весь цикл: анализ, предложенное изменение, объяснение, проверку и откат. Решение о внедрении должно учитывать общую стоимость ревью и тестирования, а не только цену генерации кода.
План миграции должен включать обратимость
Разделите перенос на небольшие модули и заранее укажите точки, в которых можно вернуться к прежней реализации. Поддерживайте параллельный прогон на одной и той же выборке, сравнивайте выходы и храните журнал расхождений. Сначала переводите некритичный участок с ясными контрактами; центральные расчетные или платежные компоненты оставьте на поздний этап. Зафиксируйте владельца архитектурного решения, критерии остановки и процедуру перехода после успешной проверки. Даже высокий результат на языковом тесте не снимает обязанность команды доказать корректность изменения в реальной среде.
Что это дает пользователю
Результаты показывают, какие классы задач OpenAI включила в оценку.
Внутренний тест можно использовать как повод составить собственный набор проверок.
Для миграции особенно важны фиксация исходного поведения и аудит изменений.
Что нужно учитывать
Методика и результаты опубликованы самой OpenAI.
Оценка не гарантирует успех на закрытой или иной кодовой базе.
Проценты нельзя трактовать как вероятность безошибочной работы в production.
Коротко
Публикация от 19 октября описывает прогресс в кодировании на языках с меньшим количеством обучающих данных и приводит измерения на двух тестах. Для компаний практический вывод - проверять модели на собственных эталонных программах и сохранять инженера ответственным за миграцию.