OpenAI повідомила про суттєвий стрибок у здатності своїх моделей працювати зі старими мовами програмування та переносити наявні програми на сучасні платформи. За даними Interesting Engineering, одна з нових моделей досягла 97,9% точності у тесті з міграції легасі‑програм.
Такі покращення можуть допомогти компаніям оновлювати критично важливе програмне забезпечення, яке працює десятиліттями. Банки та фінансові установи досі покладаються на старий код, де будь-яка помилка під час переписування може змінити розрахунки або бізнес‑правила.
Чому старий код такий важливий
COBOL залишається глибоко вбудованим у фінансову інфраструктуру. За оцінками IBM, він забезпечує понад 40% онлайн‑банкінгу, 80% офлайн‑транзакцій за кредитними картками та 95% операцій банкоматів. Fortran і далі широко використовується в наукових обчисленнях, зокрема в прогнозуванні погоди та аналізі безпеки ядерних реакторів.
На відміну від популярних мов на кшталт Python чи JavaScript, для COBOL і Fortran існує менше навчальних матеріалів. OpenAI зазначає, що розробники та корпоративні клієнти раніше скаржилися на ненадійну роботу кодових моделей із цими мовами. Документація часто неповна, а ключові бізнес‑правила можуть бути зафіксовані лише в оригінальному коді.
Це створює ризики під час міграції: переписана програма може запускатися без помилок, але давати інші результати. Наприклад, COBOL за замовчуванням може відкидати зайві десяткові знаки, якщо явно не вказати округлення. Зміна такої поведінки здатна вплинути на фінансові розрахунки.
Оцінка точності міграції COBOL
Щоб виміряти прогрес, OpenAI використовує власний тест міграції COBOL. Він перевіряє, чи можуть моделі перекласти наявні програми на C++, Java, Kotlin, Python або Rust без зміни їхньої поведінки.
Модель GPT‑6.1 Sol на «низькому рівні міркування» досягла 86,6% точності, тоді як попередня GPT‑5.6 Sol показувала лише 5,4%. Одночасно OpenAI повідомляє про 39% зниження вартості API у такому режимі.
На вищому рівні міркування GPT‑6.1 Sol вийшла на 97,9% точності. Для зарахування результату перекладені програми мають пройти всі приховані тести, включно з перевірками, які порівнюють їхні вихідні дані з оригінальними програмами.
Водночас ці показники відображають лише результати на внутрішньому наборі тестів OpenAI і не гарантують повністю безпомилкову міграцію в реальних умовах. Розробникам усе одно потрібно перевіряти переписані застосунки на реальних навантаженнях і з урахуванням неформалізованих залежностей.
Робота одразу з 20 мовами
Окремо OpenAI протестувала моделі на бенчмарку MultiLangBench, який оцінює здатність побудувати сумісний із SQLite рушій бази даних на 20 мовах програмування.
Модель GPT‑6 Astra досягла середнього показника проходження тестів 87,4%, тоді як GPT‑5.6 Sol мала лише 26,8%. Astra покращила результати в кожній із мов. Зокрема, для Fortran точність зросла з 21,4% до 83,5%, а для Visual Basic — з 27,5% до 89,4%.
COBOL залишився найскладнішою мовою, але й тут Astra підняла результат із 10,9% до 72,1%. Це свідчить про прогрес, хоча до стабільної роботи з цією мовою ще далеко.
Модель GPT‑6 Luna показала нижчий середній показник — 40,3%, зате виявилася значно дешевшою. За оцінкою OpenAI, середня вартість API для Luna становила близько 0,77 долара за вибірку проти 3,48 долара для GPT‑5.6 Sol, тобто приблизно на 78% менше.
Що це означає для модернізації ПЗ
Результати вказують на посилення підтримки старих систем, від яких залежать банки, урядові структури та бізнес. Потужніші моделі можуть прискорити аналіз і переписування коду, зменшити витрати та дати змогу командам частіше експериментувати з варіантами міграції.
Водночас бенчмарки показують і обмеження. Результати Astra суттєво відрізняються між мовами, а COBOL досі залишається найбільшим викликом. Навіть за високих показників точності командам потрібно ретельно валідувати модернізовані системи, перш ніж довіряти їм критично важливі операції.
Таким чином, нові моделі OpenAI демонструють обнадійливий прогрес у роботі з легасі‑кодом, але повна безпека й відповідність бізнес‑логіці, як і раніше, залежать від уважної перевірки з боку інженерів.