💻 computer science

Theory Under Construction: Orchestrating Language Models for Research Software Where the Specification Evolves

Questo articolo introduce Comet-H, un automa di prompt iterativo che orchestra lo sviluppo accoppiato di codice, teoria e documentazione per prevenire allucinazioni e desincronizzazione nel software di ricerca, dimostrandone l'efficacia attraverso uno strumento di analisi statica in Python che supera significativamente le linee di base su un benchmark di 90 casi.

Autori originali: Halley Young, Nikolaj Björner

Pubblicato 2026-05-01

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Halley Young, Nikolaj Björner

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di voler costruire un nuovo tipo di automobile, ma non disponi di un progetto definitivo. Invece, hai un team di ingegneri incredibilmente talentuosi e dal pensiero rapido (l'IA) che possono disegnare parti, costruire motori e scrivere il manuale del proprietario tutto in una volta.

Il problema è che questi ingegneri sono inclini a due errori specifici:

La trappola del "Fingi finché non ci riesci": Potrebbero scrivere nel manuale: "Questa auto raggiunge i 320 km/h", prima di aver effettivamente costruito il motore per dimostrarlo. Poi, il prossimo ingegnere legge questa affermazione, presume che sia vera e costruisce un telaio progettato per i 320 km/h. Se il motore non può effettivamente farlo, l'intero progetto è costruito su una menzogna.
La trappola della "Perdita nella traduzione": L'ingegnere che ha progettato il motore potrebbe cambiare idea su come funziona, ma la persona che scrive il manuale non lo sa. Ora il manuale descrive un vecchio motore, il progetto ne mostra uno nuovo e l'auto effettiva sulla catena di montaggio è qualcosa di completamente diverso. Tutti stanno divergendo.

Questo articolo, "Orchestrating Language Models for Research Software Where the Specification Evolves", introduce un nuovo sistema chiamato Comet-H per risolvere questi problemi. Tratta la ricerca non come una linea retta, ma come una danza in cui la musica, i passi e i ballerini devono adattarsi costantemente l'uno all'altro.

L'idea centrale: un "Direttore d'orchestra" per l'IA

Invece di chiedere semplicemente all'IA di "scrivere codice", gli autori hanno costruito un Direttore d'orchestra (un controllore) che gestisce l'intera orchestra. Questo Direttore non si limita a dire all'IA cosa fare; controlla costantemente lo "spazio di lavoro" (il codice, la teoria matematica, i benchmark e l'articolo) per vedere cosa manca o non è sincronizzato.

Ecco come funziona Comet-H, utilizzando semplici analogie:

1. La "Lista di cose da fare che svanisce" (Decadimento dell'obbligo)

Immagina di scrivere un libro. Hai un post-it che dice: "Devo verificare i fatti di questo capitolo".

Vecchio modo: Se dimentichi di controllarlo, il post-it rimane lì per sempre, ingombrando la tua scrivania, oppure lo ignori e vai avanti.
Modo Comet-H: Il post-it ha una emivita. Ogni volta che compie un passo avanti nel progetto, il post-it diventa leggermente più sbiadito. Se non lo affronti presto, svanisce. Ma se è molto recente, brilla di rosso acceso.
Perché è importante: Questo costringe l'IA a occuparsi dei lavori incompiuti (come "dimostra questa affermazione") mentre sono ancora freschi. Se l'IA cerca di ignorare il debito, il "bagliore" diventa più intenso e il Direttore costringe l'IA a fermarsi e risolverlo prima di procedere.

2. Il "Controllo della realtà" (Grounding reattivo)

Ogni volta che l'IA modifica la "faccia pubblica" del progetto (come il file README o l'articolo di ricerca), Comet-H preme il Pulsante di Pausa.

La regola: Non puoi cambiare la storia senza verificare i fatti.
Il processo: Se l'IA scrive: "Il nostro strumento è 10 volte più veloce", il sistema si ferma immediatamente e dice: "Ok, mostrami i risultati della gara". Costringe l'IA a eseguire il codice e generare un "registro di fondazione" (una ricevuta leggibile dalla macchina) che provi l'affermazione.
Il risultato: Questo blocca la trappola del "Fingi finché non ci riesci". Una menzogna può sopravvivere solo per un passo prima di essere scoperta e corretta.

3. Il "Passo sicuro" (Vincoli di adiacenza)

A volte, un'IA si entusiasma e vuole saltare dal "costruire una bicicletta" al "costruire una navicella spaziale".

La regola: Comet-H consente solo mosse adiacenti. L'IA può compiere un piccolo passo avanti (ad esempio, "aggiungi una marcia alla bicicletta"), ma non può saltare a un universo completamente diverso.
Perché è importante: Questo mantiene il progetto radicato. Se l'IA vuole cambiare la teoria di base, deve farlo in modo che sia ancora collegato a ciò che è stato costruito ieri. Questo impedisce al team di divergere così tanto da dimenticare cosa stavano cercando di costruire originariamente.

I Risultati: il caso di studio "a3"

Gli autori hanno testato questo sistema costruendo un portafoglio di 46 diversi progetti di software di ricerca. La star dello spettacolo è uno strumento chiamato a3, un programma progettato per trovare bug nel codice Python.

La sfida: Di solito, gli strumenti per la ricerca di bug sono come vicini rumorosi; urlano "BUG!" per tutto, anche quando va tutto bene. Questo crea molti falsi allarmi.
L'approccio Comet-H: Il sistema non ha solo costruito lo strumento; ha evoluto la teoria alla sua base. Ha iniziato con un'idea semplice, ha realizzato che era troppo difficile da calcolare e il Direttore ha permesso al team di virare verso un nuovo approccio matematico (utilizzando "certificati di sicurezza") che effettivamente funzionava.
L'esito: Lo strumento finale era incredibilmente accurato. Ha catturato bug reali (alta precisione) senza urlare per cose che non erano rotte. Ha ottenuto un punteggio di 0,768 su una scala di test, mentre il prossimo miglior strumento ha ottenuto solo 0,364.

Cosa abbiamo imparato sul comportamento dell'IA

Osservando l'IA lavorare su questi 46 progetti, gli autori hanno notato alcuni schemi interessanti:

La "squadra di pulizia" è reale: All'inizio, l'IA è impegnata a costruire nuove funzionalità. Ma man mano che il progetto si avvicina alla fine, l'IA passa la maggior parte del suo tempo a verificare e correggere. È come un cantiere edile che passa l'ultima settimana del progetto solo a controllare che la pittura sia asciutta e che le porte si aprano, invece di costruire nuovi muri.
L'onestà emerge: Quando è costretta a provare le proprie affermazioni, l'IA diventa sorprendentemente onesta. Invece di nascondere i fallimenti, ha iniziato a dichiarare esplicitamente: "Non possiamo ancora risolvere questo tipo specifico di problema". Il sistema non ha programmato questa onestà; è emersa perché il "Controllo della realtà" ha reso troppo difficile mentire.
Auto-organizzazione: Nel tempo, l'IA ha iniziato a organizzare il proprio codice in strutture più pulite e logiche, anche se nessuno le ha detto esplicitamente di farlo.

Il quadro generale

L'articolo sostiene che costruire software di ricerca è diverso dal correggere un errore di battitura in un documento. È un processo di co-evoluzione. La teoria, il codice, i test e la storia devono crescere insieme.

Se chiedi semplicemente a un'IA di "scrivere un articolo e codice", probabilmente divergerà, allucinerà e perderà la sincronizzazione. Ma se le dai un Direttore d'orchestra che controlla costantemente lo spartito, impone controlli di realtà e garantisce che i passi rimangano collegati, puoi costruire strumenti di ricerca complessi e affidabili che funzionano davvero.

In sintesi: Comet-H è un sistema che impedisce all'IA di fantasticare e la costringe a mantenere le sue promesse, assicurando che la storia che racconta corrisponda al codice che scrive.

1. Enunciato del Problema: La Sfida della Co-Evoluzione

Il documento affronta un divario critico nello sviluppo automatizzato di software per la ricerca: il problema della co-evoluzione. A differenza delle attività standard di ingegneria del software in cui la specifica è fissa, il software di ricerca coinvolge una specifica che è in costruzione. La tesi matematica, il codice eseguibile, le superfici di benchmark e le affermazioni pubbliche devono maturare insieme.

Gli attuali agenti basati su Modelli Linguistici (LM) falliscono in questo regime a causa di due modalità di fallimento specifiche:

Accumulo di Allucinazioni: Affermazioni non supportate o dati fabbricati introdotti in un passaggio (ad esempio, in una bozza di articolo) vengono trattati come verità fondamentale nei passaggi successivi, propagando errori attraverso il ciclo di sviluppo.
Desincronizzazione: Il codice, la teoria o il modello del mondo interno dell'LM divergono. Ad esempio, il codice può essere ottimizzato per una specifica obsoleta, oppure la rappresentazione interna dell'LM del repository diventa obsoleta man mano che i file si accumulano, portando a incoerenza globale anche se esiste una coerenza a coppie.

I framework esistenti (ad esempio, SWE-agent, AI Scientist) presuppongono compiti fissi o frame di valutazione fissi, rendendoli inadatti alla ricerca in cui l'obiettivo stesso evolve.

2. Metodologia: Comet-H

Gli autori propongono Comet-H, un automa di prompt iterativo progettato per orchestrare l'evoluzione accoppiata di teoria, codice, prove e affermazioni.

Architettura Principale

Comet-H opera come una Macchina a Stati di Co-Evoluzione che gestisce uno spazio di lavoro $W$ composto da sei componenti:

$T$ (Teoria): La tesi matematica modificabile.
$R$ (Repository): L'implementazione del codice.
$P$ (Proiezione Pubblica): L'articolo e il README.
$E$ (Prove): Benchmark e registri di fondazione.
$U$ (Ipotesi di Utilità): Il "perché" del software.
$Q$ (Obblighi Aperti): Una coda di affermazioni non verificate o attività in sospeso.

Meccanismi Chiave

Trigger di Fondazione Reattivi:
- Qualsiasi modifica agli artefatti rivolti al pubblico ( $P$ : articolo/README) attiva immediatamente una Creazione di Fondazione seguita da un Audit Scettico.
- Questo costringe il sistema a verificare le affermazioni contro il codice eseguibile e i benchmark prima che possano propagarsi, limitando la propagazione delle allucinazioni a un singolo passaggio.
Vincoli di Adiacenza:
- Il controllore impedisce al sistema di divergere arbitrariamente. Qualsiasi espansione o pivot deve essere "adiacente" allo stato corrente (raggiungibile in un singolo passaggio concettuale) e deve rafforzare i benchmark o la teoria esistenti. Questo impedisce al modello di saltare a problemi non correlati privi di superfici di valutazione.
Selezione del Prompt come Bandit Contestuale:
- Il controllore seleziona il prossimo prompt da un alfabeto fisso di 17 famiglie di prompt (ad esempio, Ideazione, Generazione di Semi, Rafforzamento dell'Articolo, Audit Scettico).
- Punteggio: Uno scorer lineare trasparente e impostato a mano calcola un punteggio basato su un vettore di caratteristiche dei deficit dello spazio di lavoro (ad esempio, "bassa copertura dei test", "affermazioni non verificate").
- Decadimento dell'Obbligo: Il lavoro di follow-up incompiuto è memorizzato in un vettore di obblighi $o_t$ che decade esponenzialmente (emivita di 8 passaggi). Ciò garantisce che il controllore si concentri su debiti recenti e ad alta priorità senza essere sopraffatto da una storia obsoleta, mimando strategie di bandit non stazionari.
Fasi del Ciclo di Sviluppo:
- Seme: Seleziona una domanda di ricerca differenziata e un nucleo formale.
- Iterazione Reattiva: Genera codice/articoli, quindi li indurisce iterativamente in base alla superficie più debole (ad esempio, se i benchmark sono deboli, esegue Rafforzamento del Benchmark).
- Coda: Una sequenza fissa di passaggi di audit e rifinitura per garantire che l'output finale sia fondato, indipendentemente dal budget rimanente.

3. Contributi Chiave

Definizione delle Modalità di Fallimento della Co-Evoluzione: Il documento identifica formalmente l'accumulo di allucinazioni e la desincronizzazione come le cause principali di fallimento nella ricerca automatizzata, distinte dagli errori di codifica standard.
Macchina a Stati di Co-Evoluzione: Un framework formale (Definizione 4.1) che tratta la teoria come una variabile di stato modificabile e impone la sincronizzazione tra artefatti attraverso una modalità di controllo finita e una memoria di obblighi in decadimento.
Orchestrazione Trasparente: Un nuovo design del controllore che accoppia uno scorer lineare impostato a mano con un registro sfocato del lavoro incompiuto. Questo evita politiche apprese (scatole nere) a favore di un processo decisionale verificabile e interpretabile.
Portafoglio Empirico: La creazione di 46 repository di software per la ricerca in oltre 12 domini, dimostrando la scalabilità dell'approccio.

4. Risultati e Caso di Studio (a3)

Gli autori forniscono un'analisi approfondita di a3, uno strumento di analisi statica Python sviluppato interamente all'interno del ciclo Comet-H.

Prestazioni: Su un benchmark di 90 casi, a3 ha ottenuto un punteggio F1 di 0,768, superando significativamente il miglior baseline successivo di 0,364.
Guadagni Monotoni: Gli studi di ablazione hanno mostrato che ogni livello aggiunto di accoppiamento teoria/pratica (ad esempio, analisi interprocedurale, esecuzione simbolica dinamica) ha migliorato le prestazioni senza degradazione.
Evoluzione della Teoria: Il sistema ha revisionato con successo la sua teoria sottostante due volte durante lo sviluppo (passando da una formulazione basata sulla "distanza dal confine" a "certificati di sicurezza" e integrando risolutori SMT) senza rompere la base di codice, dimostrando la capacità del controllore di gestire pivot delle specifiche.
Osservazioni Comportamentali:
- Dominio dell'Audit: Nelle fasi successive dello sviluppo, la maggior parte dei commit era dedicata alla fondazione, all'audit e alla riparazione delle affermazioni piuttosto che all'aggiunta di funzionalità.
- Fallimento Visibile: Il sistema ha imparato a segnalare apertamente i limiti (ad esempio, verdetto "UNKNOWN" per casi ricorsivi) piuttosto che nasconderli, un comportamento guidato dal prompt Audit Scettico.
- Auto-Organizzazione: Su orizzonti temporali lunghi, l'LM ha riorganizzato naturalmente il codice in strutture più composizionali (ad esempio, convertendo in sottomoduli) senza prompt espliciti.

5. Significato

Questo documento sposta il paradigma degli agenti di ricerca AI dal completamento di compiti (risolvere un problema fisso) alla gestione dello stato (mantenere l'integrità di un sistema in co-evoluzione).

Governance sulla Generazione: Sostiene che la parte più difficile dell'automazione della ricerca non è generare codice, ma garantire che la tesi matematica, il codice e le affermazioni rimangano sincronizzati.
Nuove Metriche di Valutazione: Suggerisce che le future valutazioni degli agenti di ricerca dovrebbero misurare la stabilità, la recuperabilità dalla deriva e la latenza di riparazione dell'integrità, piuttosto che solo i punteggi finali dei benchmark.
Impatto Pratico: Dimostrando che gli LM possono gestire l'intero ciclo di vita del software di ricerca, inclusa la revisione della teoria e l'audit rigoroso, Comet-H fornisce un progetto per la costruzione di sistemi di scoperta scientifica autonomi e affidabili.

In sintesi, Comet-H dimostra che trattando la ricerca come un processo co-evolutivo con meccanismi espliciti per la fondazione, l'audit e la deriva limitata, gli LM possono navigare con successo il percorso complesso e non lineare della creazione di nuovo software per la ricerca.