🤖 AI

Self-Modifying Lean Proof Agents with Verifier-Grounded Benchmark Coevolution

Questo articolo introduce un agente di prova Lean auto-modificante che coevolve con un benchmark a soglia di padronanza per raggiungere un tasso di risoluzione del 45,1% su test non visti, superando significativamente i propri corrispettivi seed e a benchmark fisso garantendo che tutti gli auto-miglioramenti rimangano radicati nella verifica affidabile di Lean.

Autori originali: Yuqing Li, Zeguan Wu, Yu Gan, Junyu Liu

Pubblicato 2026-07-21

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Yuqing Li, Zeguan Wu, Yu Gan, Junyu Liu

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

Immaginate un mondo in cui i computer non si limitino a seguire ordini, ma possano effettivamente imparare a correggere i propri errori, riscrivere le proprie istruzioni e diventare più intelligenti nel tempo. Questo è il regno degli "agenti auto-evolutivi", un ramo dell'intelligenza artificiale in cui il software cerca di migliorare se stesso modificando il proprio codice. Di solito, queste creature digitali vengono testate su un insieme fisso di enigmi, come uno studente che affronta lo stesso esame di matematica ripetutamente finché non impara a memoria le risposte. Ma cosa succederebbe se il test stesso potesse diventare più difficile ogni volta che lo studente migliora? Questa è l'idea della "coevoluzione", dove l'apprendista e la sfida crescono insieme, spingendosi a vicenda verso nuove vette. In l'angolo specifico della matematica noto come verifica formale, esiste un arbitro severo chiamato "Lean" che controlla se una dimostrazione è corretta al 100%. La grande domanda che i ricercatori si sono posti è: un agente informatico può capire da solo il modo migliore per risolvere queste dimostrazioni matematiche, senza che un insegnante umano ne progetti la strategia?

Questo articolo racconta la storia di un team di ricercatori che ha costruito un "agente di dimostrazione" digitale che cerca di rispondere a questa domanda. Inveve di fornire all'agente una guida perfetta e scritta a mano su come risolvere i problemi matematici, hanno lasciato che l'agente riscrivesse il proprio flusso di lavoro, i propri strumenti e persino il modo in cui organizza i propri pensieri. Per mantenere le cose giuste e oneste, hanno abbinato questo agente auto-migliorante a un "benchmark in coevoluzione". Pensate a un videogioco che adatta automaticamente la sua difficoltà: non appena l'agente padroneggia un livello, il gioco sostituisce quei livelli facili con versioni più difficili, assicurandosi che l'agente non si annoi o rimanga bloccato. I ricercatori hanno scoperto che questo approccio ha funzionato sorprendentemente bene. Alla fine di 15 generazioni di evoluzione, il loro agente auto-istruito riusciva a risolvere il 45,1% di un insieme di difficili problemi matematici mai visti prima, un salto enorme rispetto al 12,7% che riusciva a risolvere all'inizio. Tuttavia, il documento suggerisce anche che, sebbene l'agente sia diventato molto bravo, non è diventato un genio perfetto; è imparato principalmente a essere molto bravo a correggere i propri errori piuttosto che a inventare modi completamente nuovi e complessi per scomporre i problemi.

La storia del bot matematico che si auto-edita

Immaginate di avere un robot che vuole risolvere una gigantesca pila di dimostrazioni matematiche. Di solito, un programmatore umano scriverebbe un manuale rigido per il robot: "Prima, fai questo. Poi, se vedi un errore, fai quello". Ma in questo esperimento, i ricercatori hanno deciso di lasciare che il robot scrivesse il proprio manuale. Hanno creato un sistema in cui il "cervello" del robot (il suo codice, i suoi strumenti e la sua strategia) era completamente modificabile. Il robot poteva provare a riscrivere le proprie istruzioni per vedere se poteva risolvere i problemi più velocemente o con maggiore precisione.

Ma c'era un problema. Se il robot poteva riscrivere il proprio codice, poteva anche mentire e dire: "L'ho risolto!", quando in realtà non l'aveva fatto. Per impedire ciò, i ricercatori hanno costruito un "runtime fidato" — un arbitro severo e immutabile che non dorme mai. Questo arbitro, alimentato da un sistema chiamato Lean, agisce come l'ultimo giudice. Qualunque cosa il robot faccia cambiare nel proprio codice, l'arbitro controlla la dimostrazione finale. Se la dimostrazione non regge sotto il microscopio dell'arbitro, non conta. Questo assicura che il robot non possa imbrogliare; deve effettivamente fare la matematica per ottenere un punto.

Il gioco che diventa più difficile

La parte più eccitante di questo esperimento è come hanno testato il robot. Nella maggior parte degli esperimenti di IA, il robot si esercita su una lista fissa di problemi. Se il robot diventa troppo bravo, impara semplicemente le risposte a memoria, e il test smette di essere utile. I ricercatori in questo articolo volevano evitare questo. Hanno impostato un "benchmark in coevoluzione", che è come un videogioco che diventa più difficile ogni volta che superi un livello.

Ecco come funzionava:

Il Campione: In ogni round, il robot con le prestazioni migliori (il "campione") decide come sarà il round successivo.
L'Aggiornamento: Se il campione risolve troppi problemi facili, il sistema ritira quei problemi facili e li sostituisce con problemi più difficili presi da un pool più ampio di sfide.
Il Segnatore del punteggio: Per garantire che i punteggi rimangano equi man mano che il gioco diventa più difficile, hanno usato un trucco matematico speciale chiamato "ricalibrazione a singolo ancoraggio". Immaginate se correste una gara su una pista che improvvisamente diventa più ripida; correreste più lentamente, ma sareste comunque dei grandi corridori. Questo sistema ha regolato i punteggi in modo che ottenere una "medaglia d'oro" su una pista difficile valesse quanto ottenerne una su una pista facile.

Questa configurazione significava che il robot veniva sempre spinto appena oltre la sua zona di comfort, costringendolo a imparare nuovi trucchi invece di limitarsi a memorizzare quelli vecchi.

Cosa ha imparato realmente il robot

Dopo aver eseguito questo esperimento per 15 generazioni, i risultati sono stati affascinanti. Il robot è partito risolvendo solo circa il 12,7% dei problemi. Alla 15ª generazione, la versione migliore del robot riusciva a risolvere il 45,1% dei problemi di un nuovo test mai visto prima. È un miglioramento enorme, che dimostra che lasciare che il robot riscrivesse se stesso ha davvero aiutato a renderlo più intelligente.

Tuttavia, i ricercatori hanno scoperto qualcosa di interessante su come il robot è diventato più intelligente. Si aspettavano che il robot dovesse alla fine elaborare una strategia complessa, passo dopo passo, in cui scompone un grande problema in pezzi piccoli e gestibili (come un grande architetto che progetta il piano di un edificio un piano alla volta). Inveve, i robot vincitori sono diventati principalmente esperti di riparazione.

Pensate a questo: il robot ha imparato a scrivere un'intera dimostrazione rapidamente, poi controllare se ci fossero errori e poi correggere le parti specifiche che si erano rotte. Non ha necessariamente pianificato l'intero edificio da zero; ha solo imparato a essere molto bravo a tappare le crepe. I ricercatori hanno scoperto che, sebbene il robot avesse tentato di costruire piani complessi e passo dopo passo, questi piani spesso cadevano a pezzi o erano troppo rischiosi. La strategia più semplice di "prova, controlla, correggi" era più affidabile e ha vinto la competizione.

Il robot ha anche inventato alcuni strumenti astuti per aiutarsi. Ad esempio, ha imparato a ricontrollare i nomi dei termini matematici che usava per assicurarsi di non inventare parole false (un errore comune chiamato "allucinazione"). Ha costruito piccole liste di controllo e strumenti di ricerca per garantire che ogni parte della sua dimostrazione fosse reale e valida prima di sottoporla.

Il verdetto

Quindi, il robot è diventato un genio della matematica? Non proprio. Sebbene sia migliorato drasticamente, non riesce ancora a risolvere il 99% dei problemi come fanno i migliori robot progettati da umani. I ricercatori suggeriscono che il robot è ancora bloccato in una "modalità riparazione" piuttosto che in una "modalità pianificazione". È molto bravo a correggere gli errori, ma non ha ancora capito come costruire una struttura profonda e perfetta partendo dal basso.

Questo esperimento dimostra che gli agenti auto-evolutivi possono imparare a usare meglio i propri strumenti e possono diventare molto più intelligenti quando le sfide crescono insieme a loro. Ma suggerisce anche che c'è un limite a quanto un robot può insegnare a se stesso senza un essere umano che lo guidi verso strategie più complesse. Il robot ha dimostuto di poter evolversi, ma il viaggio per diventare un vero maestro della matematica è ancora un lavoro in corso.

Riepilogo Tecnico: Agenti di Dimostrazione Lean Auto-Modificanti con Coevoluzione del Benchmark Basata sul Verificatore

Definizione del Problema

Progettare framework agentici efficaci per la dimostrazione di teoremi basata su Lean affronta una duplice sfida: migliorare la capacità di sintesi grezza del provatore e ottimizzare il workflow di dimostrazione circostante. Mentre il lavoro recente si è concentrato sulla costruzione di modelli specializzati più forti o di tattiche, una prospettiva complementare sostiene che il collo di bottiglia risieda nell'interazione dell'agente con l'ambiente Lean — specificamente, in come esso decompone gli obblighi, utilizza il feedback del compilatore, diagnostica i fallimenti e mantiene un contesto di dimostrazione strutturato.

Gli attuali sistemi di agenti auto-evolutivi (es. Darwin Gölder Machine, Hyperagents) ottimizzano tipicamente gli agenti contro benchmark fissi forniti esternamente. Questo approccio è inadatto alla matematica formale perché:

Segnale di Selezione: Se il benchmark è troppo difficile (es. problemi di livello competitivo), la maggior parte delle valutazioni fallisce, non fornendo alcun gradiente per l'evoluzione. Se è troppo facile, l'agente raggiunge rapidamente la saturazione.
Rigidità del Workflow: La maggior parte degli agenti si affida a workflow progettati a mano. Resta da capire se un agente possa evolvere il proprio workflow di dimostrazione, i propri strumenti e la propria rappresentazione del contesto senza intervento umano.
Radicamento (Grounding): Un agente capace di riscrivere se stesso non può essere fidato nel riportare il proprio successo; è necessario un verificatore fisso e affidabile per arbitrare la correttezza.

Metodologia

Gli autori propongono un sistema in cui un agente di dimostrazione Lean auto-evolutivo coevolve con un benchmark auto-indurente, entrambi radicati in un verificatore Lean fisso e affidabile.

1. Architettura del Sistema

Runtime Affidabile vs. Workspace Mutabile: Il sistema separa un runtime fisso e affidabile (che gestisce la verifica Lean, la valutazione e la gestione del benchmark) da uno workspace completamente mutabile. L'agente può riscrivere il proprio workflow di dimostrazione, i propri prompt e i propri strumenti all'interno di questo workspace.
Validità del Codice vs. Successo della Dimostrazione: Gli agenti mutati sono sottoposti a un "test di fumo" a livello di codice per garantire che siano eseguibili, ma un teorema è considerato "risolto" solo se la dimostrazione generata viene verificata nuovamente sotto uno snapshot affidabile di Lean.
Contratto Basato sul Verificatore: Ogni tentativo di risoluzione deve emettere un contesto di dimostrazione leggibile dalle macchine. Sebbene la rappresentazione di questo contesto (grafo, albero, tabella) sia libera di evolvere, la sua validità (groundedness) è imposta. Il runtime sanitizza i certificati, rifiuta sorry/admit e verifica indipendentemente le affermazioni.

2. Meccanismo di Benchmark in Coevoluzione

Invece di un benchmark fisso, il sistema impiega un curriculum guidato dal campione e con soglia di padronanza (mastery-throttled):

Pool di Task: I problemi sono stratificati in tre livelli di difficoltà (L1: lemmi a singola tattica; L2: miniF2F; L3: PutnamBench).
Regola di Aggiornamento: Alla fine di ogni generazione, se il "campione" (l'agente con il punteggio più alto) supera una soglia di risoluzione ( $\gamma=0.30$ $γ = 0.30$ ), il benchmark si aggiorna.
- I task risolti da tutti gli agenti vengono ritirati.
- Se la padronanza del campione su un livello specifico supera una soglia ( $\tau=0.70$ ), i task ritirati sono sostituiti da task più difficili del livello successivo; altrimenti, sono sostituiti lateralmente con nuovi task della stessa difficoltà.
- L'aggiornamento predilige i domini in cui la popolazione di agenti ha accumulato fallimenti.
Ricalibrazione a Singolo Ancora: Per mantenere la comparabilità dei punteggi man mano che la difficoltà aumenta, il campione viene rivalutato sul nuovo benchmark. Un coefficiente di difficoltà ( $c$ ) viene aggiornato moltiplicativamente per normalizzare i punteggi attraverso le generazioni ( $q = r \times c$ ).

3. Interfaccia di Evoluzione

Selezione dei Genitori: Gli agenti sono selezionati da un archivio in base a un punteggio normalizzato per difficoltà, scontato dal numero di figli che hanno già prodotto per prevenire la dominanza della linea di discendenza.
Auto-Modifica: Gli agenti riscrivono il proprio codice, inclusa la logica del workflow (es. loop di riparazione, strategie di decomposizione) e gli strumenti (es. controllori di lemmi).

Contributi Chiave

Agente di Dimostrazione Lean Auto-Evolutivo: Gli autori presentano un agente auto-evolutivo a livello di codice dove il workflow di dimostrazione e gli strumenti sono mutabili, ma il successo della dimostrazione rimane strettamente ancorato alla verifica Lean.
Coevoluzione del Benchmark: Introducono un benchmark auto-indurante guidato dal campione che evolve insieme all'agente. Questo evita la saturazione dei benchmark facili fissi e la scarsità dei benchmark difficili fissi, utilizzando aggiornamenti a soglia di padronanza e ricalibrazione a singolo ancora.
Contesti di Dimostrazione Senza Rappresentazione Specifica ma Radicati: Il sistema impone un contratto in cui gli agenti possono evolvere il formato del loro contesto di dimostrazione (es. da log piatti a grafi strutturati), ma la validità delle affermazioni risolte è rigorosamente imposta dal runtime affidabile.

Risultati Sperimentali

Il sistema è stato valutato su 15 generazioni attive, confrontando la traiettoria di coevoluzione rispetto a un baseline a benchmark fisso.

Performance su Test Indipendente (Held-Out):
- Agente Seed: Tasso di risoluzione del 12,7% sul test split di miniF2F tenuto da parte.
- Baseline a Benchmark Fisso: Il miglior agente ha raggiunto il 32,0%.
- Agente in Coevoluzione: Il miglior agente (c144, Generazione 15) ha raggiunto il 45,1% sul test indipendente.
Indurimento del Benchmark: Il coefficiente di difficoltà è salito da 1,00 a 3,17 in 15 generazioni, indicando che il benchmark ha aumentato con successo la complessità man mano che l'agente migliorava.
Evoluzione del Workflow:
- Dominanza Centrata sulla Riparazione: Il workflow vincente è rimasto principalmente "centrato sulla riparazione" (genera dimostrazione $\to$ controlla errori Lean $\to$ ripara) piuttosto che "centrato sulla decomposizione" (pianifica sottogiochi $\to$ dimostra $\to$ assembla).
- Evoluzione degli Strumenti: Gli agenti hanno evoluto con successo strumenti per prevenire allucinazioni di nomi Lean (es. sonde #check, ricerca sorgente, cache di lemmi verificati).
- Tentativi di Decomposizione: Diversi agenti hanno tentato workflow basati sulla decomposizione (es. c26, c44, c141). Sebbene questi agenti abbiano evoluto una reale verifica a livello di nodo per i sotto-lemmi autosufficienti, queste strategie sono state spesso scartate dalla selezione perché la fase di assemblaggio introduceva nuovi punti di fallimento (parsing JSON, mismatch di contesto) che riducevano il tasso finale di risoluzione rispetto ai loop di riparazione compatti.
Contesto di Dimostrazione: I contesti di dimostrazione sono diventati ispezionabili ma raramente si sono evoluti in grafi di dipendenza profondi e verificati. Gli agenti tendevano a costruire il contesto a ritroso dal prodotto finale piuttosto che pianificare un grafo in anticipo.

Significato e Rivendicazioni

Il paper afferma che la coevoluzione del benchmark può migliorare i workflow di dimostrazione Lean tramite l'auto-evoluzione ancorata al verificatore.

Fattibilità dell'Auto-Miglioramento: I risultati dimostrano che un agente può migliorare il proprio workflow matematico e i propri strumenti riscrivendo esclusivamente il proprio codice, a patto che un verificatore fisso e affidabile arbitri il successo.
Importanza della Coevoluzione: Lo studio di ablazione mostra che un benchmark fisso porta alla stagnazione evolutiva una volta che l'agente padroneggia un sottoinsieme di task. Il benchmark in coevoluzione mantiene un segnale di selezione informativo aumentando continuamente la difficoltà.
Limitazioni e Direzioni Future: Gli autori sono modesti riguardo allo stato attuale. Il workflow vincente è ancora centrato sulla riparazione e il sistema non ha ancora evoluto un grafo di contesto di dimostrazione profondo e duraturo (DAG) che rivaleggi con agenti progettati a mano come Goedel-Architect (che raggiunge il 99,2% su miniF2F-test). Gli autori suggeriscono che potrebbero essere necessari run più lunghi, popolazioni più ampie o ricompense mirate specificamente alla decomposizione verificata per far evolvere workflow più complessi e orientati alla decomposizione.

Il lavoro stabilisce le fondamenta per agenti capaci di adattare le proprie strutture di ragionamento in domini formali, mantenendo fissa la logica di verifica mentre si permette l'evoluzione del "come" della costruzione della dimostrazione.