Michael JohnsonПеренести програму 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 особливо важливо перевіряти округлення, пропущені записи та інші правила, закріплені в поведінці старої програми. Нові результати спрощують таку перевірку; відповідальність за підтвердження еквівалентності залишається частиною інженерного процесу.