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

Для команд, поддерживающих старые корпоративные системы, полезная часть новости — не только заявленные проценты, но и два разных типа проверки. Один оценивает создание программ с нуля на разных языках; другой проверяет, сохраняет ли перенос COBOL-кода наблюдаемое поведение. Эти задачи требуют разных тестов и по-разному связаны с риском при внедрении.
Два теста — две инженерные задачи
В MultiLangBench модель должна создать совместимый с SQLite движок, который принимает запросы и изменяет файл базы данных. OpenAI сообщает средний процент пройденных тестов по 20 языкам: GPT‑6 Astra набрала 87,4% при максимальном уровне рассуждений, а GPT‑5.6 Sol — 26,8%. Для каждой реализации результат проверяется по ожидаемому содержимому базы; оцениваются также длительность работы и стоимость API.
Компания выложила MultiLangBench на GitHub, включая тестовую инфраструктуру. В опубликованном репозитории описаны тесты, созданные на основе набора SQLite TCL Tests, и правила проверки результата. Это даёт разработчикам возможность посмотреть, какие именно операции входят в оценку, а затем воспроизвести её для своей модельной конфигурации.
Для миграции COBOL проверяется другая способность: переписать существующую программу на C++, Java, Kotlin, Python или Rust и сохранить её поведение на скрытых тестах. OpenAI сообщает точность 86,6% для GPT‑6.1 Sol при низком уровне рассуждений против 5,4% у GPT‑5.6 Sol в том же режиме. При более высоком уровне рассуждений показатель GPT‑6.1 Sol достигает 97,9% на этой оценке.
Почему перенос требует проверки бизнес-правил
В описании OpenAI подчёркивает, что совместимость зависит от семантики исходного языка. Например, фиксированная арифметика COBOL отбрасывает лишние десятичные разряды, если округление не задано явно. Если новая реализация округляет их иначе, программа может успешно запускаться и при этом выдавать другие финансовые результаты.
Поэтому критерий миграционного теста — совпадение выходов на проверяемых случаях, а практический критерий команды должен включать собственные правила расчётов, формат данных и зависимости системы. Полезный первый шаг — выбрать модуль с понятным входом и выходом, зафиксировать эталонные результаты на реальных крайних случаях и прогнать параллельно исходную и переписанную версии.
Что результаты дают командам
Цифры OpenAI относятся к опубликованным наборам и настройкам рассуждений. MultiLangBench оценивает создание SQLite-совместимой реализации, а COBOL-набор — сохранение поведения при переносе; показатели описывают эти конкретные проверки. Командам они дают ориентир для отбора моделей и основу для собственного воспроизводимого сравнения, а не готовую оценку совместимости с любой производственной системой.
Практический вывод прост: тестировать модели стоит на своём коде и собственных контрольных случаях, а стоимость считать вместе с успешностью выполнения. Для модернизации COBOL особенно важны проверки округления, пропущенных записей и других правил, которые закреплены в поведении старой программы. Новые результаты делают такую проверку доступнее; ответственность за подтверждение эквивалентности остаётся частью инженерного процесса.