OpenAI, accuratezza del 97,9% nella valutazione della migrazione da COBOL: netto miglioramento nel supporto ai linguaggi legacy

Il 19 ottobre (ora locale), la statunitense OpenAI ha annunciato un netto miglioramento nelle capacità di sviluppo e migrazione dei suoi modelli più recenti per linguaggi di programmazione come COBOL, Fortran e Visual Basic, per i quali esistono pochi codici e documenti utilizzabili dall’AI per l’addestramento. Per misurare i progressi, ha predisposto due valutazioni proprietarie. In quella sulla migrazione di programmi COBOL verso altri linguaggi, il modello ha raggiunto un’accuratezza del 97,9% con un livello di ragionamento più elevato.

Il peso dei vecchi linguaggi, prima ancora dei numeri

COBOL è un linguaggio nato nel 1959. Qualcuno potrebbe chiedersi con sorpresa se una tecnologia così datata sia ancora in uso, ma viene tuttora utilizzata ampiamente nei sistemi di istituti finanziari e amministrazioni pubbliche. Secondo OpenAI, COBOL è alla base di oltre il 40% dei sistemi di online banking, dell’80% delle transazioni con carta di credito effettuate di persona e del 95% delle operazioni agli sportelli automatici.

Anche Fortran, incluso nella valutazione, viene utilizzato nelle previsioni meteorologiche e nelle analisi di sicurezza dei reattori nucleari. Rispetto a Python e JavaScript, la quantità di codice e documentazione da cui l’AI può apprendere è limitata. Eppure questi linguaggi sostengono le fondamenta della società: una situazione un po’ paradossale.

Secondo quanto riferito, l’iniziativa è nata dalle segnalazioni di sviluppatori e clienti aziendali, secondo cui i modelli di programmazione faticavano a lavorare con questi linguaggi. È importante notare che il punto di partenza sono state le difficoltà incontrate sul campo.

Nella valutazione della migrazione non basta che il programma «funzioni»

Colpisce soprattutto il rigore della seconda valutazione. Consiste nel trasferire un programma COBOL in C++, Java, Kotlin, Python o Rust e verificare che mantenga lo stesso comportamento dell’originale: per essere considerato riuscito, l’output deve corrispondere perfettamente, byte per byte. Inoltre, la valutazione si basa su test non pubblici e il risultato viene conteggiato come positivo solo se tutti vengono superati.

Un esempio rende bene l’idea. Nell’aritmetica a virgola fissa di COBOL, le cifre decimali eccedenti vengono troncate, a meno che non si specifichi esplicitamente un arrotondamento. Cosa succederebbe se il programma migrato, per abitudine, arrotondasse invece per eccesso o per difetto? Potrebbero cambiare soltanto i risultati dei calcoli sugli importi, senza che venisse segnalato alcun errore.

Basta immaginare calcoli bancari o assicurativi in cui uno yen di differenza si accumula su milioni di operazioni per capire il senso di questa valutazione. Più che sostituire un linguaggio con un altro, si tratta di trasferire in un linguaggio diverso, mantenendolo identico, il «comportamento» di codice in cui sono incorporate implicitamente regole operative consolidate da anni.

Come interpretare il 97,9%

Riepiloghiamo i risultati. Nella valutazione della migrazione, «GPT-6.1 Sol» ha raggiunto un’accuratezza dell’86,6% con un livello di ragionamento basso. «GPT-5.6 Sol», nelle stesse condizioni, si è fermato al 5,4%: una differenza considerevole. Il costo dell’API sarebbe pari al 61% di quello di GPT-5.6 Sol. Aumentando il livello di ragionamento, l’accuratezza è salita al 97,9%.

L’altra valutazione, «MultiLangBench», ha caratteristiche diverse. L’obiettivo è creare da zero un motore di database compatibile con SQLite in ciascuno di 20 linguaggi di programmazione. «GPT-6 Astra», con il livello di ragionamento al massimo, ha raggiunto una percentuale media di test superati dell’87,4% nei 20 linguaggi, in crescita rispetto al 26,8% di GPT-5.6 Sol.

Per evitare confusioni, riepiloghiamo in una tabella le differenze tra le due valutazioni.

【Confronto tra le valutazioni】
・Valutazione della migrazione: trasferimento di COBOL in uno dei 5 linguaggi e verifica della corrispondenza dell’output byte per byte. GPT-6.1 Sol raggiunge l’86,6% con un livello di ragionamento basso e il 97,9% con un livello più alto.
・MultiLangBench: creazione di un motore di database compatibile con SQLite in 20 linguaggi. La percentuale media di test superati da GPT-6 Astra è dell’87,4%.

COBOL resta il linguaggio più difficile

In MultiLangBench, 19 dei 20 linguaggi hanno superato l’83%. COBOL si è fermato al 72,1%: un netto miglioramento rispetto al 10,9% di GPT-5.6 Sol, ma resta il linguaggio più difficile.

Anche il modello a basso costo «GPT-6 Luna» ha superato GPT-5.6 Sol, con una media del 40,3%. Il costo API stimato per campione è di 0,77 dollari, circa il 78% in meno rispetto ai 3,48 dollari di GPT-5.6 Sol. L’ambiente di valutazione e la suite di test saranno pubblicati su GitHub.

I progressi dell’AI e lo stato attuale del rinnovamento dei sistemi legacy

Non è la prima volta che si tenta di usare l’AI per migrare COBOL. Nel 2023 IBM ha presentato «watsonx Code Assistant for Z», uno strumento che converte COBOL in Java usando l’AI generativa. Lo scorso febbraio, la statunitense Anthropic ha illustrato in un post sul blog come Claude Code possa aiutare a modernizzare COBOL. Il mercato ha considerato la notizia un fattore rilevante e le azioni IBM hanno registrato il calo percentuale giornaliero più marcato da circa 25 anni. È un segno dell’attenzione riservata a questo settore: un solo post sul blog può scuotere il mercato azionario.

C’è anche un contesto sociale da considerare. Nel 2020, durante la pandemia di COVID-19, le richieste si sono riversate sui sistemi di sussidi di disoccupazione basati su COBOL gestiti dai governi dei singoli Stati americani. Forse ricordate che la carenza di tecnici in grado di intervenire divenne un problema. La possibilità che l’AI entri in settori dove manca personale non riguarda soltanto la tecnologia: è una questione che incide sulla sostenibilità della pubblica amministrazione e del sistema finanziario.

Usarla senza affidarle tutto

Nonostante i numeri elevati, OpenAI stessa afferma che, per applicare il sistema al software in produzione, restano necessari la revisione di esperti e test basati sulle regole operative e sulle dipendenze del sistema. Anche se vengono superati i test che verificano la corrispondenza byte per byte, nei sistemi reali restano casi eccezionali non contemplati dai test di valutazione e collegamenti con altri sistemi.

Ritengo più realistico considerare il ruolo dell’IA non come una «magia che sostituisce tutto in blocco», bensì come quello di un subappaltatore che porta avanti la migrazione in modo da renderla facile da verificare. Quando la documentazione delle specifiche del sistema di partenza è andata perduta, la capacità di progettare verifiche che accertino la riproduzione del comportamento originale avrà più valore della velocità di conversione. Il dato del 97,9% indica che, dando per scontato che siano gli esseri umani a farsi carico delle verifiche, le possibilità di avviare una migrazione si sono ampliate enormemente.