Kronumos 2 Kairos: Cost-Bounded Automated Program Repair via Dual-Brain Cybernetic Sub-Cortex on SWE-bench Verified

La manutenzione del software è un'industria silenziosa e massiccia che consuma più del sessanta percento del budget globale dell'ingegneria. È il lavoro di trovare pezzi rotti in sistemi digitali complessi e di ripararli senza rompere le parti che funzionano ancora. Per decenni, questo è stato un compito umano, che richiedeva una profonda conoscenza di come i diversi file di codice comunichino tra loro. Recentemente, programmi informatici addestrati su enormi quantità di codice hanno iniziato a tentare questo lavoro autonomamente. Questi programmi, noti come modelli linguistici di grandi dimensioni, possono leggere la descrizione di un problema e suggerire una soluzione. Tuttavia, quando questi modelli cercano di riparare software del mondo reale, spesso incontrano difficoltà. Si perdono nell'enorme volume di informazioni, commettono errori di formattazione sottili che causano il rifiuto del loro lavoro da parte del computer e lo fanno a un costo finanziario elevato, richiedendo spesso costosa potenza di calcolo in cloud per ogni singolo tentativo.

Un nuovo studio introduce un approccio diverso a questo problema, uno che privilegia la precisione e l'efficienza dei costi rispetto alla forza bruta. I ricercatori hanno costruito un sistema chiamato Kronumos 2 Kairos, progettato per agire come uno strumento chirurgico piuttosto che come un motore di ricerca generico. Invece di lasciare che un modello informatico vaghi attraverso un codice sorgente, indovinando e controllando ripetutamente, questo sistema costringe il modello a concentrarsi su un compito molto specifico e ristretto. Accoppia un modello informatico open-source di medie dimensioni con un motore rigido basato su regole che agisce come un severo ispettore del controllo qualità. L'obiettivo era vedere se un modello più piccolo e meno costoso potesse riparare bug software reali se fosse protetto dalla sua tendenza a commettere errori superficiali e se fosse impedito a sprecare risorse in passaggi non necessari. I ricercatori hanno testato questo sistema su un benchmark di cinquecento problemi software del mondo reale, un insieme standard di sfide utilizzato per misurare la capacità dell'intelligenza artificiale di riparare il codice.

Il sistema opera dividendo il lavoro in due parti distinte. La prima parte è la "corteccia cognitiva", ovvero il modello informatico responsabile della comprensione del problema e della scrittura della correzione del codice. La seconda parte è la "sottocorteccia", un motore deterministico scritto in un linguaggio che garantisce un comportamento esatto e prevedibile. Questa sottocorteccia agisce come un filtro e un formatore. Prima ancora che il modello veda il problema, la sottocorteccia elimina migliaia di righe di rumore tecnico irrilevante che solitamente affollano i messaggi di errore. Rimuove informazioni sensibili come password e chiavi API per garantire la privacy. Successivamente, prende l'output del modello e lo controlla rispetto alle regole rigide su come debbano essere scritti i patch del codice. Se il modello commette un errore nei numeri di riga, nell'indentazione o nella formattazione della correzione, la sottocorteccia lo intercetta immediatamente. Corregge l'errore oppure rifiuta interamente il patch, assicurando che nessun codice rotto o malformato venga mai inviato per il test. Questo processo impedisce al sistema di sprecare tempo in tentativi destinati al fallimento a causa di semplici errori di formattazione.

I ricercatori hanno testato questo sistema contro i cinquecento problemi software del mondo reale. I risultati hanno mostrato che il sistema è riuscito a risolvere otto di questi bug. Sebbene otto su cinquecento possa sembrare un numero piccolo, la significatività risiede nel modo in cui il sistema ha raggiunto questo obiettivo. I ricercatori hanno utilizzato un modello con soli sette miliardi di parametri, che è significativamente più piccolo dei modelli massicci utilizzati dalle aziende commerciali che spesso costano migliaia di dollari per essere eseguiti. Utilizzando la loro architettura a doppio cervello, il sistema è riuscito a risolvere questi problemi con un costo marginale nullo per la potenza di calcolo utilizzata. La quantità media di dati elaborati dal sistema per ogni compito era di poco superiore a duemila token, una cifra che è il novantatré percento inferiore alle centinaia di migliaia di token tipicamente consumati da altri sistemi di riparazione automatizzata. Questa drastica riduzione dell'uso dei dati significa che il sistema è molto più efficiente e scalabile rispetto alle alternative attuali.

Una scoperta critica dello studio è stata l'importanza del motore di controllo qualità rigoroso. Quando i ricercatori hanno rimosso la capacità della sottocorteccia di correggere gli errori di formattazione dopo che il modello aveva scritto il codice, il numero di riparazioni riuscite è sceso da otto a sei. Ciò ha dimostrato che una parte significativa dei fallimenti del modello non era dovuta a una mancanza di comprensione, ma piuttosto a errori minori e correggibili nel modo in cui il codice veniva presentato. La sottocorteccia ha agito come una rete di sicurezza, intercettando questi errori e assicurando che le correzioni logiche trovate dal modello fossero effettivamente consegnate in un formato utilizzabile. Il sistema ha inoltre dimostrato di poter operare senza eseguire i test del software durante il processo di riparazione. Invece di provare la correzione e vedere se funziona, il sistema si è affidato alle sue regole interne per garantire che la correzione fosse strutturalmente solida prima di essere applicata.

Lo studio ha valutato il sistema attraverso quattro diversi ecosistemi software, inclusi progetti importanti come Django e Scikit-Learn. Le otto riparazioni riuscite coprivano una varietà di problemi, dal correggere un crash in uno strumento di migrazione del database al correggere un errore matematico in una libreria di analisi dei dati. In un caso, il sistema ha risolto un bug in cui un programma andava in crash se una specifica impostazione mancava; il modello ha identificato correttamente che il codice doveva controllare l'assenza di tale impostazione prima di provare a usarla. In un altro caso, ha risolto un problema in cui un programma cambiava accidentalmente dati che avrebbe dovuto lasciare invariati. I ricercatori hanno ispezionato manualmente ogni correzione riuscita per confermare che la logica fosse corretta e che la soluzione non fosse solo un colpo di fortuna.

I ricercatori riconoscono che il loro sistema non è una soluzione completa a tutti i bug del software. Il modello fatica ancora con problemi molto complessi che richiedono un ragionamento profondo attraverso molti file diversi o che coinvolgono concetti astratti oltre il suo addestramento. Tuttavia, lo studio stabilisce un nuovo punto di riferimento per ciò che è possibile con modelli open-source più piccoli. Dimostra che combinando un modello capace ma modesto con un sistema rigido basato su regole che impone standard severi, è possibile ottenere risultati affidabili senza i costi massicci associati ai sistemi allo stato dell'arte attuali. Il lavoro suggerisce che il futuro della riparazione automatizzata potrebbe non dipendere dal rendere i modelli infinitamente più grandi, ma dal costruire sistemi migliori per guidarli e intercettare i loro errori.

Questa ricerca fornisce un percorso chiaro per rendere la riparazione del software automatizzata accessibile ed economica. Dimostrando che un sistema può riparare bug reali con costo zero ed alta efficienza, lo studio sfida la nozione che solo i modelli più costosi e potenti possano svolgere questo lavoro. Il successo dell'approccio a doppio cervello evidenzia il valore del separare il compito creativo di scrivere codice dal compito meccanico di garantire che esso segua le regole. Mentre il campo della riparazione automatizzata continua a evolversi, questo lavoro offre un esempio pratico di come bilanciare l'intelligenza con la disciplina, assicurando che gli strumenti che costruiamo per riparare il nostro software siano essi stessi robusti, affidabili ed efficienti.