🤖 AI

Goedel-Architect: Streamlining Formal Theorem Proving with Blueprint Generation and Refinement

Goedel-Architect è un framework agentico per la dimostrazione di teoremi in Lean 4 che utilizza una strategia di generazione e raffinamento di blueprint per raggiungere prestazioni allo stato dell'arte su benchmark matematici impegnativi come MiniF2F, Putnam e IMO con costi significativamente inferiori rispetto alle pipeline esistenti.

Autori originali: Jui-Hui Chung, Ziyang Cai, Zihao Li, Qishuo Yin, Rohit Agarwal, Simon Park, Rodrigo Porto, Narutatsu Ri, Ziran Yang, Shange Tang, Xingyu Dang, Hongzhou Lin, Mengdi Wang, Danqi Chen, Chi Jin, Liam H Fo

Pubblicato 2026-06-05

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Jui-Hui Chung, Ziyang Cai, Zihao Li, Qishuo Yin, Rohit Agarwal, Simon Park, Rodrigo Porto, Narutatsu Ri, Ziran Yang, Shange Tang, Xingyu Dang, Hongzhou Lin, Mengdi Wang, Danqi Chen, Chi Jin, Liam H Fowl, Sanjeev Arora

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 cercare di costruire un castello enorme e intricato fatto di mattoncini LEGO. Hai un progetto, ma non è un disegno; è un elenco di istruzioni che dice: "Per costruire la torre, devi prima fare una fondazione, poi un muro, poi una finestra".

Il problema è che, se provi a costruire l'intera torre in un unico salto gigante, potresti rimanere bloccato, o potresti renderti conto a metà dell'altezza che la fondazione è stata costruita male.

Goedel-Architect è un nuovo, intelligente team di robot progettato per costruire questi "castelli" matematici (formali) in un linguaggio chiamato Lean 4. Invece di cercare di costruire l'intera torre tutta in una volta, utilizza una strategia chiamata Generazione e Raffinamento del Progetto (Blueprint Generation and Refinement).

Ecco come funziona, suddiviso in semplici passaggi:

1. Il Progetto (Il Piano Maestro)

Prima che il robot inizi a costruire, disegna un Progetto (Blueprint).

Cos'è? Immaginalo come una mappa delle dipendenze. Elenca ogni singolo piccolo passaggio (chiamato "lemma") necessario per dimostrare il grande problema matematico.
Come funziona: Disegna delle frecce che mostrano quali passaggi dipendono da altri. Per esempio: "Non puoi costruire il tetto finché le mura non sono state completate".
Il colpo di scena: A volte, se il problema matematico è molto difficile, al robot viene fornito un Progetto in Linguaggio Naturale. Questo è come un matematico umano che dà al robot uno schizzo grossolano o una storia su come risolvere il problema. Il robot usa questa storia per disegnare un progetto migliore e più accurato fin dall'inizio.

2. La Squadra di Costruzione (Dimostrazione in Parallelo)

Una volta che il progetto è pronto, il robot non costruisce un passaggio alla volta. Invia una squadra intera di costruttori specializzati (un "dimostratore Lean") per lavorare su tutti i piccoli passaggi contemporaneamente.

Ogni costruttore guarda solo il proprio passaggio specifico e i passaggi che ha il permesso di utilizzare (le sue "dipendenze").
Cercano di costruire la loro parte. Se ci riescono, rendono quella parte del progetto Verde.
Se falliscono, la rendono Blu (bloccati) o Rosso (rotto).

3. Il Ciclo di Riparazione (Raffinamento)

È qui che Goedel-Architect è diverso dagli altri robot.

Il Vecchio Metodo: Molti altri sistemi di IA cercano di risolvere un problema, rimangono bloccati e poi provano a scomporre quel singolo pezzo bloccato in pezzi sempre più piccoli, ripetutamente. È come cercare di riparare un muro rotto semplicemente martellando più forte sullo stesso punto. Spesso questo porta a un vicolo cieco.
Il Metodo Goedel: Se un costruttore rimane bloccato, l'intera squadra si ferma e guarda l'intero progetto.
- Diagnosi: Il robot si chiede: "Perché questo è fallito?"
  - Caso A (Rosso): "Oh, questo passaggio è in realtà falso!" (Il progetto aveva un'idea errata). Il robot corregge l'enunciato.
  - Caso B (Blu): "Questo passaggio è vero, ma è troppo difficile da costruire in questo momento". Il robot scompone questo grande passaggio in due o tre passaggi ausiliari più piccoli e facili.
- Revisione: Il robot riscrive il progetto con questi nuovi passaggi più piccoli e invia nuovamente la squadra.
- Efficienza: Fondamentalmente, qualsiasi parte del castello che è già stata costruita con successo (Verde) rimane Verde. Il robot non butta via il buon lavoro; corregge solo le parti rotte e aggiunge nuovi passaggi ausiliari.

Perché è una cosa importante?

L'articolo sostiene che questo approccio sia un "cambio di gioco" per due ragioni principali:

È incredibilmente intelligente e accurato:
- In un test standard di problemi di matematica della scuola superiore (MiniF2F), ne ha risolti il 99,2%. Con un piccolo aiuto da una storia in linguaggio naturale (Natural Language), ne ha risolti il 100%.
- Nei problemi più difficili di livello universitario (PutnamBench), ne ha risolti il 75,6% da solo, e l'88,8% con un piccolo aiuto.
- Ha persino risolto problemi provenienti da competizioni recentissime e super difficili (come IMO 2025 e Putnam 2025) che nessun altro robot open-source ha risolto in precedenza.
È incredibilmente economico:
- Altri robot di alto livello che risolvono questi problemi spesso utilizzano modelli "black box" che costano migliaia di dollari per essere eseguiti.
- Goedel-Architect utilizza un cervello open-source più economico (DeepSeek-V4-Flash).
- Il Costo: Per risolvere l'intero test PutnamBench, Goedel-Architect è costato circa 294 dollari. Il prossimo miglior concorrente open-source è costato circa 163.000 dollari. Si tratta di un risparmio di 500 volte.

In sintesi

Goedel-Architect è come un maestro architetto che non si limita a cercare di piantare un chiodo; disegna una mappa, invia una squadra a costruire in parallelo e, quando qualcosa si rompe, ridisegna l'intera mappa per correggere la logica, mantenendo le parti buone e cambiando solo ciò che è necessario. Dimostra che non serve l'IA più costosa e segreta per risolvere i problemi matematici più difficili; basta un modo più intelligente di organizzare il lavoro.

Riepilogo Tecnico: Goedel-Architect

Definizione del Problema

Il documento affronta la sfida della dimostrazione formale di teoremi in Lean 4, con l'obiettivo specifico di colmare il divario tra i sistemi proprietari ad alte prestazioni e le pipeline open-source accessibili. Mentre i sistemi di IA all'avanguardia hanno dimostrato significative capacità matematiche (ad esempio, medaglie d'oro all'IMO, risoluzione di problemi aperti di Erdős), la verifica di queste dimostrazioni richiede una formalizzazione rigorosa. Le attuali soluzioni a pesi aperti (open-weight) faticano spesso con benchmark difficili come PutnamBench (punteggio <15%), mentre i sistemi ad alte prestazioni si affidano a modelli non rilasciati o a costose API proprietarie (che costano migliaia di dollari per l'esecuzione di un benchmark). La difficoltà principale risiede nel decomporre efficientemente teoremi complessi in lemmi dimostrabili senza rimanere intrappolati in vicoli ciechi ricorsivi o incorrendo in costi computazionali proibitivi.

Metodologia

Goedel-Architect è un framework agentico centrato sulla generazione e il raffinamento di blueprint. A differenza degli approcci che si basano sulla decomposizione ricorsiva top-down o sulla generazione di una dimostrazione singola (single-shot), questo sistema opera su un grafo di dipendenze globale.

1. Generazione del Blueprint

Il processo inizia con la generazione di un blueprint, definito come un grafo di dipendenza di definizioni e lemmi formalmente enunciati che costruiscono il teorema target.

Struttura: Il teorema target è l'unico "sink" (pozzo) del grafo. Ogni nodo rappresenta una definizione o un lemma, e gli archi rappresentano le dipendenze dichiarate (ovvero quali lemmi la dimostrazione è autorizzata a utilizzare).
Input: La formulazione formale del teorema funge sempre da seme per la generazione. Opzionalmente, per problemi difficili, una dimostrazione in linguaggio naturale (generata da un modello più forte o fornita come soluzione) può fungere da guida strutturale.
Validazione: Il generatore itera contro il compilatore Lean per garantire che il file emesso sia sintatticamente corretto, che tutti i nodi siano ben tipizzati e che il grafo sia aciclico e connesso.

2. Dimostrazione Parallela dei Teoremi

Una volta generato il blueprint iniziale ( $G_0$ ), il sistema assegna ogni nodo lemma a un dimostratore Lean dotato di strumenti in parallelo.

Contesto: Il dimostratore di un particolare lemma vede solo il lemma stesso e le sue dipendenze dichiarate (disponibili come fatti), non l'intero grafo.
Strumenti: Il dimostratore utilizza il compilatore Lean per il controllo dei tipi e un servizio di recupero di Mathlib per la ricerca dei lemmi.
Diagnosi: Se un lemma fallisce, il dimostratore restituisce una diagnosi strutturata. Questa include:
- Negazione: Se il dimostratore trova un controesempio, registra una dimostrazione della negazione dell'enunciato.
- Analisi del Gap: Se il lemma non è dimostrato ma si ritiene sia vero, il dimostratore identifica il punto in cui la catena di dimostrazione si interrompe.

3. Raffinamento del Blueprint

Se alcuni lemmi rimangono non dimostrati, un modello di raffinamento riscrive il blueprint globale ( $G_{k+1}$ ) basandosi sui segnali di fallimento.

Strategie: Il raffinamento include la decomposizione di lemmi difficili in lemmi ausiliari, la riconfigurazione delle dipendenze per concedere l'accesso ai risultati necessari, o la modifica/rimozione di enunciati che il dimostratore ha provato essere falsi.
Preservazione: I lemmi dimostrati con successo nelle iterazioni precedenti sono preservati (nodi verdi) con le loro firme intatte, garantendo che lo sforzo computazionale non venga disperso.
Iterazione: Il blueprint rivisto viene nuovamente dimostrato in parallelo. Questo ciclo continua finché tutti i nodi non sono risolti o finché il budget di iterazione non viene esaurito.

Contributi Chiave

Architettura Centrata sul Blueprint: Il documento introduce un approccio basato su un grafo di dipendenza globale che contrasta con la decomposizione ricorsiva. Ciò consente tentativi di dimostrazione paralleli di condividere il contesto e permette al raffinamento di agire sull'intera strategia simultaneamente anziché localmente.
Stato dell'Arte a Pesi Aperti (Open-Weight): Il sistema raggiunge prestazioni state-of-the-art utilizzando il backbone open-weight DeepSeek-V4-Flash (284B-A13B), evitando la necessità di modelli non rilasciati o frontiere proprietarie.
Efficienza dei Costi: La pipeline è significativamente più conveniente rispetto alle altre pipeline ad alte prestazioni. Il documento riporta un costo per problema di circa $0,44, che è fino a 500 volte inferiore rispetto ad altre pipeline open-source e ordini di grandezza più economico rispetto alle alternative proprietarie.
Semina in Linguaggio Naturale (Natural-Language Seeding): Il framework dimostra che le dimostrazioni opzionali in linguaggio naturale possono fungere da scaffold strutturali efficaci per il blueprint iniziale, particolarmente per problemi con strutture non locali (es. somme cicliche, catene di divisibilità), aiutando ad ancorare la strategia per il ciclo di raffinamento.

Risultati Sperimentali

Il sistema è stato valutato su cinque benchmark: MiniF2F-test, PutnamBench, IMO 2025, Putnam 2025 e USAMO 2026.

MiniF2F-test: Ha raggiunto il 99,2% di pass@1 (242/244 problemi) senza guida in linguaggio naturale. Con l'opzionale semina in linguaggio naturale, ha risolto tutti i 244 problemi (100%), stabilendo un nuovo record per i sistemi a pesi aperti.
PutnamBench: Ha raggiunto il 75,6% di pass@1 (508/672 problemi), superando la pipeline Hilbert (70,0% a pass@1840) e AxProverBase (54,7% a pass@1). Con la guida in linguaggio naturale (pass@4), il tasso di risoluzione è salito all'88,8% (597/672).
IMO 2025: Ha risolto 4/6 problemi.
Putnam 2025: Ha risolto 11/12 problemi.
USAMO 2026: Ha risolto 3/6 problemi (un benchmark privo di contaminazione, poiché i problemi sono successivi alla data di cutoff dell'addestramento del modello).

Analisi dei Costi: Su PutnamBench, Goedel-Architect ha risolto l'intero set di 672 problemi per $294 in costi API. Al contrario, la migliore pipeline open successiva (Hilbert) ha riportato una spesa di circa $163k–$ 170k per una singola esecuzione, evidenziando un enorme divario di efficienza.

Significato e Rivendicazioni

Gli autori affermano che Goedel-Architect stabilisce una nuova frontiera di Pareto per la dimostrazione formale di teoremi. Dimostra che prestazioni di alto livello (che rivaleggiano con i massicci sistemi proprietari come AlphaProof o sistemi che utilizzano Claude Opus 4.5) possono essere ottenute con un backbone a pesi aperti altamente efficiente e un design di pipeline innovativo.

Il documento sottolinea che la combinazione del grafo di dipendenza globale (che permette un raffinamento olistico) e dei modelli a pesi aperti (DeepSeek-V4-Flash) è il motore chiave di questo successo. Il sistema chiude efficacementamente il divario tra l'accessibilità accademica e le prestazioni di frontiera, rendendo la dimostrazione formale di alto livello fattibile a una frazione del costo precedente. Gli autori osservano che, sebbene la guida in linguaggio naturale aumenti significativamente le prestazioni sui problemi più difficili, il nucleo della pipeline rimane robusto ed efficace anche senza di essa sui benchmark standard.