⚛️ high-energy experiments

Articulating Assumptions in AI-Generated Scientific Analyses through Task Decomposition

Questo articolo introduce un framework multi-agente che utilizza la decomposizione dei compiti e la differenziazione semantica basata sulla quantità per migliorare la trasparenza, la riproducibilità e l'affidabilità delle analisi scientifiche generate da LLM, identificando e risolvendo esplicitamente le ambiguità nelle istruzioni dell'utente e nelle assunzioni di implementazione.

Autori originali: Ahmed Hammad, Mihoko Nojiri

Pubblicato 2026-07-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Ahmed Hammad, Mihoko Nojiri

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 essere un maestro architetto che vuole costruire una macchina molto specifica e complessa. Descrivi la tua visione a una squadra di brillanti ma leggermente caotici costruttori di robot (i modelli AI). Dici: "Costruitemi una macchina che selezioni le biglie rosse da quelle blu, ma solo se sono lucide e più grandi di un acino d'uva".

I robot iniziano a costruire. Potrebbero costruire qualcosa che funziona, ma potrebbero anche aver selezionato tutte le biglie prima di controllare le dimensioni, o potrebbero aver pensato che "lucido" significasse "riflettere la luce" invece di "levigato". La macchina funziona, ma tu non sai esattamente quali regole abbiano usato per prendere le loro decisioni. Nella scienza, questo è pericoloso perché se le regole sono sbagliate, i risultati sono inutili, anche se la macchina non si guasta.

Questo articolo introduce un nuovo modo per gestire questi costruttori robot affinché costruiscano esattamente ciò che intendevi, utilizzando un sistema chiamato "Decomposizione dei Compiti" (Task Decomposition). Invece di un singolo robot che cerca di fare tutto da solo, il lavoro viene suddiviso in una squadra di agenti specializzati, ognuno con un compito specifico.

Ecco come funziona il sistema, utilizzando analogie semplici:

1. L'Oracolo della "Ascia d'Oro" (Il Clarificatore)

Prima ancora che i robot tocchino uno strumento, un agente speciale chiamato Oracolo (dal nome della favola del boscaiolo e dell'ascia d'oro) esamina le tue istruzioni.

Il Problema: Le tue istruzioni potrebbero essere vaghe. "Seleziona le biglie rosse" potrebbe significare "seleziona quelle rosse da un mucchio" o "seleziona le rosse dall'intera scatola".
La Soluzione: L'Oracolo agisce come un editor severo. Individua le parti vaghe e ti chiede: "Intendevi le biglie rosse dall'intera scatola o solo quelle rosse?". Ti offre due opzioni (l'"Ascia d'Oro" e l'"Ascia d'Argento") in modo che tu possa scegliere quella corretta prima che la costruzione inizi. Questo evita che i robot tirino a indovinare.

2. Il Selezionatore di Aiutanti (Il Bibliotecario)

Una volta che le istruzioni sono chiare, un Selezionatore di Aiutanti agisce come un bibliotecario.

Il Problema: Se chiedi a un piccolo robot di costruire una macchina complessa partendo da zero, potrebbe dimenticare come si fabbrica un ingranaggio specifico o inventarne uno strano e rotto.
La Soluzione: Il bibliotecario consulta un catalogo di strumenti pre-fatti e perfetti (aiutanti) che i robot sanno già usare. Sceglie gli strumenti esatti necessari per il tuo lavoro e li consegna al costruttore. Questo è fondamentale perché permette anche a robot più piccoli e meno costosi (come modelli da 14 miliardi di parametri) di svolgere il lavoro di modelli molto più grandi e costosi. Non devono inventare la ruota; devono solo usare la ruota perfetta fornita loro.

3. Il Costruttore (Il Generatore di Codice)

Ora, il Costruttore riceve le istruzioni chiare e gli strumenti specifici. Scrive il codice (il progetto) per la macchina. Poiché ha gli strumenti giusti e regole chiare, è meno propenso a commettere errori.

4. Il Tracciatore (Il Detective)

Una volta che la macchina è stata costruita e avviata, interviene un agente Tracciatore. Non si limita a controllare se la macchina funziona; esegue l'ingegneria inversa della macchina per vedere esattamente come funziona.

L'Analogia: Immagina che la macchina sia una scatola nera. Il Tracciatore la apre e disegna una mappa che mostra: "Per ottenere il risultato finale, la macchina ha preso le biglie rosse, ha controllato la loro dimensione, poi ha controllato la loro lucentezza".
Perché è importante: Traduce il codice complesso in linguaggio semplice, creando una "specifica" di ciò che è stato effettivamente costruito.

5. Il Critico (L'Ispettore della Qualità)

Infine, il Critico confronta "Ciò che hai chiesto" (le tue istruzioni originali) con "Ciò che è stato effettivamente costruito" (la mappa del Tracciatore).

Il Compito: Il Critico cerca discrepanze. "Hai chiesto biglie lucide, ma la macchina ha controllato biglie levigate". Oppure "Volevi selezionare l'intera scatola, ma la macchina ha selezionato solo lo strato superiore".
L'Output: Produce un rapporto che evidenzia queste differenze, le assunzioni nascoste o gli errori. Non dice solo "Passato" o "Fallito"; spiega perché il risultato potrebbe essere diverso da quello che intendevi.

Perché questo è importante

L'articolo ha testato questo sistema su problemi di fisica complessi (come l'analisi delle collisioni di particelle al Large Hadron Collider). Hanno scoperto che:

Piccoli robot possono fare grandi lavori: Scomponendo il compito e fornendo loro gli strumenti giusti, anche i modelli AI più piccoli possono ora svolgere lavori che prima richiedevano modelli enormi e costosi.
Niente più "Scatole Nere": Puoi vedere esattamente quali assunzioni ha fatto l'IA. Se l'IA ha ipotizzato una regola, il Critico lo segnala.
Riproducibilità: Poiché ogni passaggio è registrato (dalle domande dell'Oracolo al rapporto del Critico), altri scienziati possono esaminare la "scia di carta" e capire esattamente come è stato derivato il risultato.

In breve, questo articolo propone un flusso di lavoro basato sul lavoro di squadra dove un'IA non si limita a "indovinare" come scrivere codice scientifico. Invece, chiarisce le regole, utilizza strumenti approvati, costruisce il codice e poi lascia che un detective e un ispettore verifichino che il prodotto finale corrisponda all'intento scientifico originale. Ciò rende la scienza generata dall'IA trasparente, affidabile e comprensibile.

Sintesi Tecnica: Articolare le Assunzioni nelle Analisi Scientifiche Generate dall'IA attraverso la Decomposizione dei Task

Definizione del Problema

L'integrazione dei Large Language Models (LLM) nel calcolo scientifico offre il potenziale per automatizzare la generazione di codice di analisi eseguibile a partire da specifiche in linguaggio naturale. Tuttavia, questa capacità introduce rischi significativi riguardanti la comprensibilità e la riproducibilità dei risultati scientifici. Esistono due fonti primarie di incertezza:

Ambiguità della Specifica: Le richieste in linguaggio naturale spesso mancano delle definizioni procedurali rigorose richieste per il calcolo, lasciando critici aspetti (ad esempio, criteri di selezione degli oggetti, unità di aggregazione, regole di derivazione) aperti all'interpretazione.
Variabilità Stocastica: Gli LLM possono produrre codice differente, incompleto o semanticamente errato per prompt identici.

Di conseguenza, anche se il codice generato viene eseguito senza errori, potrebbe non riflettere la fisica intesa dal ricercatore. L'"eseguibilità" del codice non garantisce che le assunzioni sottostanti, le definizioni degli oggetti o i percorsi computazionali siano espliciti o corretti. Ciò è particolarmente critico nella fisica delle alte energie (HEP), dove i risultati dipendono da definizioni precise di collezioni di particelle, osservabili composti e tagli di selezione.

Metodologia: Un Framework Multi-Agente

Gli autori propongono un framework multi-agente che decompone il workflow di analisi scientifica in fasi distinte e verificabili. Invece di fare affidamento su un singolo prompt per generare il codice, il sistema orchestra agenti specializzati per gestire la generazione del codice, l'esecuzione, il tracciamento e la critica. Il workflow è progettato per essere indipendente dal dominio, con la conoscenza specifica del dominio racchiusa in pacchetti intercambiabili.

Il workflow centrale consiste nelle seguenti fasi:

Inizializzazione del Dominio: Un pacchetto di dominio (ad esempio, per i dati di LHC Olympics) fornisce un profilo di generazione, un registro di helper, politiche di selezione e contesti di critica. Questo separa la logica di orchestrazione generale dalle risorse specifiche del dominio.
Selezione degli Helper: Un agente dedicato analizza la "task card" dell'utente e un registro di funzioni helper predefinite (ad esempio, ricostruzione cinematica, selezione di oggetti) per identificare le utility più rilevanti. Questo passaggio vincola la successiva generazione del codice, impedendo al modello di inventare funzioni o utilizzare impropriamente gli strumenti del dominio.
Generazione del Codice: Un agente genera uno script Python utilizzando la task card arricchita (richiesta originale + helper selezionati) e il profilo di generazione del dominio.
Esecuzione e Riparazione Iterativa: Il codice generato viene eseguito in un sandbox. Se si verificano errori, un agente Fixer tenta di patchare il codice basandosi sulle diagnosi di runtime. Se le riparazioni falliscono, un agente Regenerator produce una nuova implementazione.
Tracciamento dell'Implementazione: Una volta ottenuto il codice eseguibile, un agente Tracer ricostruisce una "specifica come implementata". Esso estrae frammenti di codice corrispondenti a ogni elemento della task card, mappandoli a definizioni di variabili, catene di dipendenze e riferimenti alle righe sorgente. Ciò crea una rappresentazione strutturata di ciò che il codice effettivamente fa, indipendentemente dal testo grezzo del codice sorgente.
Critica Post-Generazione: Un agente di Critica confronta la task card originale con la specifica ricostruita. Identifica discrepanze, requisiti mancanti, assunzioni nascoste o violazioni semantiche (ad esempio, il calcolo di un osservabile composto direttamente dalle particelle grezze invece che da un oggetto ricostruito).
Rilevamento dell'Ambiguità (Golden Axe Oracle): Prima della generazione del codice, un modulo Oracle ispeziona l'input in linguaggio naturale dell'utente per individuare ambiguità ad alto rischio. Identifica frasi che potrebbero portare a molteplici implementazioni valide (ad esempio, "jet leader" rispetto a "jet leader dopo i tagli") e propone domande di chiarimento all'utente, offrendo interpretazioni "Golden" (raccomandate) e "Silver" (alternative).

Contributi Chiave

1. Decomposizione del Task per Modelli Piccoli

Un risultato centrale è che la decomposizione del compito di generazione permette a modelli LLM sostanzialmente più piccoli di eseguire complessi workflow scientifici. Mentre gli approcci precedenti (ad esempio, CoLLM) richiedevano modelli con circa 70B di parametri per ottenere risultati affidabili, questo framework consente a modelli anche di soli 14B di parametri (ad esempio, Qwen2.5-14B, Qwen3-14B) di completare con successo l'intero pipeline. L'Helper Selector è fondamentale in questo senso, poiché guida il generatore iniettando le utility di dominio rilevanti, riducendo il carico cognitivo sul modello.

2. Ricostruzione Semantica e Tracciamento

L'introduzione del modulo Tracer affronta la natura "black box" del codice generato. Ricostruendo la specifica di implementazione dal codice, il framework rende esplicite le definizioni delle collezioni selezionate, delle selezioni di eventi e delle quantità composte. Ciò consente un confronto semantico tra l'intento dell'utente e il comportamento del codice, piuttosto che un semplice controllo sintattico superficiale.

3. Risoluzione Esplicita dell'Ambiguità

Il modulo Golden Axe Oracle sposta l'onere della risoluzione dell'ambiguità dall'LLM al ricercatore umano. Rilevando le frasi ambigue prima della generazione del codice e presentando interpretazioni alternative, il sistema impedisce al modello di compiere silenziosamente assunzioni errate.

4. Adattabilità Modulare del Dominio

Il framework è progettato con un'interfaccia fissa per gli asset di dominio. Sebbene l'implementazione attuale si concentri sulla fisica delle alte energie (specificamente il formato LHC Olympics), l'architettura consente l'adattamento ad altri domini scientifici sostituendo il pacchetto di dominio (profilo di generazione, registro degli helper, contesto di critica) senza alterare la logica di orchestrazione principale.

Risultati e Validazione

Il framework è stato validato su cinque analisi rappresentative della fisica dei collider (ad esempio, $W^+W^-$ , $t\bar{t}$ , $H \to \gamma\gamma$ ) utilizzando il formato eventi di LHC Olympics.

Stabilità della Selezione degli Helper: L'Helper Selector ha migliorato significativamente la stabilità. Mentre i modelli da 70B mostravano un'alta coerenza, anche i modelli da 14B hanno raggiunto una selezione degli helper affidabile quando guidati dal registro, laddove i precedenti approcci a singolo agente fallivano con modelli di questa dimensione.
Qualità del Codice e Fedeltà Semantica:
- Il codice generato da modelli da 14B era spesso "parzialmente riuscito", implementando la logica di selezione principale ma fallendo su osservabili composti complessi (ad esempio, calcolare $\Delta\phi$ tra un sistema di dijet rispetto ai singoli jet).
- La fase di Critica ha identificato con successo queste discrepanze semantiche, come l'applicazione errata dei veto sui b-jet (applicati ai jet grezzi invece che ai jet selezionati) o l'ordine errato del riempimento degli istogrammi.
Rilevamento dell'Ambiguità:
- I modelli più grandi (72B) hanno rilevato più ambiguità (28/30 possibili) rispetto ai modelli più piccoli (il modello da 14B ne ha rilevate 13/30).
- L'introduzione di Oracle-templated (oraclet), che restringe la ricerca di ambiguità a categorie specifiche (Ambito della Collezione, Oggetto Multi-parte, Tempistica dell'Output), ha migliorato significativamente le prestazioni dei modelli più piccoli (modelli da 7B hanno rilevato 27/30 ambiguità utili con l'approccio templated).
Raffinamento della Task Card: Lo studio ha dimostrato che definire esplicitamente la costruzione di oggetti composti all'interno della task card (invece di fare affidamento su convenzioni implicite del modello) ha drasticamente migliorato la stabilità e la coerenza della generazione tra esecuzioni ripetute.

Significato e Rivendicazioni

Il paper sostiene che la riproducibilità e la trasparenza nella scienza generata dall'IA richiedono più del semplice codice eseguibile; richiedono un conto esplicito delle assunzioni e dei percorsi computazionali utilizzati.

Cambio di Paradigma: Il lavoro si allontana dal trattare la generazione di codice come un singolo step di inferenza verso un processo strutturato con molteplici punti di ispezione.
Accessibilità: Abilitando l'uso di modelli da 14B, il framework rende l'analisi scientifica assistita da IA avanzata accessibile su risorse di calcolo locali, riducendo la dipendenza dall'accesso costoso ad API di massicci modelli proprietari.
Human-in-the-Loop: Il framework non mira a una piena autonomia. Al contrario, posiziona l'LLM come uno strumento che genera candidati, mentre gli agenti Tracer e Critique, insieme all'Oracle, facilitano l'ispezione e la verifica umana. Gli artefatti intermedi (liste di helper, specifiche ricostruite, report di critica) fungono da record di provenienza, permettendo ai ricercatori di auditare esattamente come un risultato sia stato derivato.

In conclusione, gli autori sostengono che questo approccio multi-agente modulare migliora l'affidabilità delle analisi scientifiche generate da LLM rendendo esplicite le assunzioni implicite e consentendo l'uso di modelli più piccoli e accessibili senza sacrificare il rigore richiesto dalla scoperta scientifica.