💻 computer science

TraceCompiler: Skill-Guided Mining and Compilation of LLM Agent Traces into Mostly Deterministic Workflows

Questo articolo introduce TraceCompiler, un sistema guidato dalle abilità che estrae tracce rumorose di agenti LLM per compilarle in workflow prevalentemente deterministici ed eseguibili attraverso l'inferenza rigorosa delle dipendenze tra gli strumenti tramite evidenze verificabili, riducendo così significativamente le chiamate API a runtime pur mantenendo un'alta precisione nel recupero delle dipendenze.

Autori originali: Salma El Yadouni (EPFL), Guanyi Li (Binome Technologies)

Pubblicato 2026-08-05

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Salma El Yadouni (EPFL), Guanyi Li (Binome Technologies)

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 insegnare a un maggiordomo robotico, molto intelligente ma un po' sbadato, come preparare il tuo panino preferito. Gli mostri il processo una volta: prende il pane, poi il formaggio, poi il coltello, poi di nuovo il coltello perché se l'è dimenticato, poi di nuovo il formaggio per controllare l'etichetta e infine il pane. Ottiene il suo panino, ma il percorso che ha seguito è stato un zigzag disordinato di tentativi, ricontrolli e vagabondaggi per la cucina. Ora, immagina di chiedere al robot di fare lo stesso panino cento volte. Se lo lasci semplicemente "imparare" facendolo ogni volta, pagherà il prezzo di quel zigzag disordinato ogni singola volta, sprecando energia e tempo a riscoprire passaggi che già conosce. Questo è esattamente ciò che accade con i moderni agenti IA che utilizzano strumenti (come controllare un calendario o inviare un messaggio). Sono brillanti nel capire le cose sul momento, ma sono pessimi nel ricordare i propri percorsi efficienti, rileggendo istruzioni e riprovando tentativi falliti per ogni nuova richiesta. La grande domanda in questo angolo dell'informatica è: possiamo prendere quei "diari" disordinati e ripetitivi di ciò che ha fatto l'IA, pulirli e trasformarli in una ricetta rigida ed efficiente che l'IA possa seguire senza dover pensare così tanto ogni volta? Questa è la differenza tra un robot che deve capire come camminare ogni mattina e uno che ha una memoria muscolare pre-programmata per camminare.

Entra in scena TraceCompiler, un nuovo sistema progettato per essere lo "chef" capace di trasformare quei disordinati diari robotici in ricette pulite ed eseguibili. I ricercatori dietro questo lavoro si sono resi conto che, mentre gli agenti IA sono bravi nell'esplorare, sono terribili nel ricordare i propri percorsi efficienti. TraceCompiler agisce come un detective e un editor combinati. Esamina centinaia di tentativi rumorosi per eseguire lo stesso compito (come chiedere soldi su Venmo o aggiungere una canzone a una playlist) e cerca di capire quali passaggi fossero effettivamente necessari e quali fossero invece solo l'IA che inciampava.

La magia centrale di TraceCompiler è una regola rigorosa sulla "causa e l'effetto". In un registro disordinato, due azioni possono accadere una dopo l'altra solo per coincidenza, come il robot che prende il pane e poi il formaggio. TraceCompiler si rifiuta di assumere che il pane abbia causato il prendere il formaggio. Al contrario, esige una prova: "Il formaggio aveva davvero bisogno di una specifica informazione che solo il passaggio del prendere il pane ha prodotto?". Se la risposta è no, il legame viene tagliato. Se la risposta è sì, e nessun altro passaggio poteva fornire quell'informazione, il legame viene mantenuto. Ciò consente al sistema di eliminare il "rumore" — i tentativi, le ricerche accidentali e i controlli ridondanti — lasciando dietro di sé un flusso di lavoro snellito.

I risultati sono impressionanti ma presentano importanti avvertenza. Quando testato su un dataset di compiti relativi ai viaggi, il sistema ha identificato correttamente i collegamenti necessari tra i passaggi con una precisione del 93% e un richiamo del 94%. Si tratta di un salto enorme rispetto ai metodi più semplici che guardano solo cosa accade dopo in linea (che hanno ottenuto circa il 71%) o ai metodi che contano solo quanto spesso i passaggi appaiono insieme. In un test specifico riguardante un compito di richiesta di denaro su Venmo, il sistema è riuscito a restringere un processo disordinato che richiedeva 34 chiamate API a soli 11 passaggi essenziali. È una riduzione massiccia del lavoro!

Tuttalmente, l'articolo è molto attento a non sostenere che si tratti di una soluzione magica e perfetta. Il sistema non è solo una "scatola nera" che funziona sempre; è un editor cauto. Ad esempio, nel tentativo di compilare un workflow per aggiungere canzoni a una playlist, il sistema si è scontrato con un muro. Si è reso conto che i log dell'IA non mostravano chiaramente se le canzoni venissero aggiunte o rimosse, e poiché queste sono azioni opposte e irreversibili, il sistema si è rifiutato di compilare. Ha scelto di fermarsi e dire: "Non ne sono sicuro, quindi non indovinerò", piuttosto che rischiare un errore che potrebbe cancellare la musica di un utente. Questo "rifiuto di compilare" è in realtà una caratteristica, non un difetto, dimostrando che il sistema dà priorità alla sicurezza rispetto alla velocità.

Inoltre, i ricercatori ammettono che, sebbene i workflow compilati siano efficienti, non hanno misurato quanto tempo o denaro sia costato creare tali workflow in primo luogo. È come dire: "Questa nuova auto consuma poca benzina", senza però dire quanto è costato costruire il motore. Hanno anche scoperto che, sebbene il sistema funzioni bene con dati sintetici (esempi generati dal computer), esso dipende fortemente dalla capacità dell'IA di individuare schemi e non può ancora gestire perfettamente ogni tipo di log disordinato.

In definitiva, TraceCompiler dimostra che possiamo trasformare il comportamento caotico e ripetitivo degli agenti IA in programmi deterministici e puliti, ma solo se siamo disposti a essere rigorosi su cosa costituisce una "prova". È un passo verso un'IA che non deve solo "capire come fare" ogni volta, ma che può effettivamente imparare a seguire un percorso affidabile ed efficiente — a patto che si possa provare che quel percorso sia sicuro e necessario.

Riassunto Tecnico: TraceCompiler

Definizione del Problema

Gli agenti di modelli linguistici (LLM) che utilizzano strumenti spesso riscoprono procedure che hanno già eseguito, incorrendo in costi significativi in termini di utilizzo di token e latenza. Un singolo intento ricorrente (ad es., richiedere un pagamento o elencare i biglietti) scatena spesso una traccia che contiene un mix di struttura riutilizzabile (strumenti necessari, vere dipendenze di dati, configurazione stabile) e storia di esecuzione accidentale (tentativi di riproposizione, lookup dello schema, ordine stilistico e risoluzione ripetuta di fatti).

Gli approcci attuali, come la sintesi delle tracce in guida testuale, richiedono comunque che l'LLM reinterpreti la procedura durante l'esecuzione. Il tradizionale processo di discovery è insufficiente perché l'ordine degli eventi osservati non implica una dipendenza; chiamate consecutive possono derivare da operazioni indipendenti, tentativi falliti o flusso di dati. Inoltre, i log distribuiti soffrono spesso di osservabilità parziale, registrando gli argomenti ma non gli output degli strumenti, rendendo impossibile verificare le dipendenze accoppiando gli output dei produttori agli input dei consumatori.

La sfida centrale è compilare tracce di agenti rumorose e parzialmente osservabili in workflow eseguibili e prevalentemente deterministici, dove le decisioni supportate da prove vengono rimosse dalla responsabilità del modello durante l'esecuzione, lasciando solo le scelte genuinamente aperte all'LLM.

Metodologia

TraceCompiler è un sistema guidato dalle skill che estrae cluster di tracce rumorose e le compila in workflow tipizzati. La pipeline consiste nelle seguenti fasi:

1. Scoperta dell'Intento e Clustering

Le conversazioni vengono incorporate come documenti che combinano la richiesta iniziale con il ragionamento intercalato e le chiamate agli strumenti. L'agglomerazione tramite soglia (distanza coseno, linkage medio) raggruppa le tracie in cluster di intento. Il sistema privilegia un sotto-raggruppamento conservativo per evitare di contaminare intenti distinti. Pre-passaggi idempotenti rilevano e separano le conversazioni che mescolano intenti non correlati.

2. Normalizzazione e Denoising Comportamentale

Le tracce grezze vengono normalizzate in un vocabolario canonico app.action. Le azioni sono etichettate come:

Essenziali: Necessarie per il compito.
Recupero/Esplorazione/Ridondanti: Conservate per l'analisi ma potenzialmente rimovibili.
Dead Output: Azioni i cui output non sono mai consumati a valle (ad es., lookup dello schema).
Retry vs. Variazione: Il sistema distingue tra rumore (jittering degli argomenti che converge verso un successo) e fan-out genuino (argomenti sistematicamente distinti, ad es., ricerche per singola canzone). I loop di paginazione vengono rilevati tramite contatori letterali.

3. Verifica della Dipendenza a Livello di Argomento

Questa è l'innovazione principale. Un arco $a \to b$ viene ammesso come dipendenza hard solo se:

Un valore nell'argomento di $b$ è tracciabile all'output di $a$ .
Esclusione: Ogni origine alternativa per quel valore è esclusa (utterance dell'utente, contesto statico, default degli strumenti e output di tutte le altre chiamate precedenti).

Se esiste un'origine alternativa plausibile (ad es., due produttori compatibili per tipo), l'arco viene declassato a sospetto e non impone alcun vincolo di ordinamento. Ciò impedisce al compilatore di inferire false dipendenze basate solo sulla vicinanza.

4. Classificazione della Provenienza e Contesto Statico

I binding vengono classificati in:

Costante: Stabile attraverso le tracce (risolto al momento della build).
User Input: Risolto a runtime.
Copy Edge: Un valore provato originare da uno specifico produttore.
Transform: Trasformazioni deterministiche.
LLM/Dynamic: Binding semantici genuini che richiedono la risoluzione del modello a runtime.

Il compilatore è specificato per eseguire l'iniezione di contesto statico limitata allo scope, risolvendo i valori stabili al momento della build e vietando agli strumenti di scoperta di ricerca per tali valori a runtime. Tuttavia, questa funzione non è stata esercitata nei risultati riportati; nessuno dei casi di studio riporta un valore iniettato, e l'elemento di design rimane in attesa di evidenza. Se un effetto collaterale irreversibile è sotto-determinato (ad es., la direzione di una mutazione è ambigua), il compilatore si astiene ed emette nessun grafo eseguibile, scalando la richiesta.

5. Compilazione e Runtime

L'analisi viene compilata in una definizione eseguibile (DAG) con nodi tipizzati (TOOL, TRANSFORM, DECISION, LLM, HUMAN). Il router di runtime instrada le richieste ai workflow compilati se corrispondono a una soglia di somiglianza conservativa; le richieste non corrispondenti ricadono nel general agent.

Il motore del compilatore (v1) è implementato come una versione di skill dell'LLM — un pacchetto di istruzioni caricato da un agente — piuttosto che un modello addestrato. Ciò consente l'audit avversariale e la revisione rapida senza riaddestramento.

Contributi Chiave

Formulazione: Inquadrare il riutilizzo ricorrente delle tracce degli agenti come un problema di compilazione su struttura del workflow, provenienza dei parametri e residui di decisioni dell'LLM sotto osservabilità parziale.
Pipeline: Una pipeline completa non supervisionata per la scoperta dell'intento, il denoising comportamentale, la verifica della dipendenza, la classificazione della provenienza e la generazione di workflow eseguibili.
Regola di Dipendenza: Una regola formale e conservativa di dipendenza a livello di argomento che ammette archi solo tramite l'esclusione di origini alternative. Introduce espliciti tuple di evidenza e una relazione "sospetta" per i casi ambigui.
Valutazione: Valutazione contro due verità di base (T1 e AppWorld) che non condividono meccanismi, confrontandoli con baseline basate sull'ordine e sulla ricorrenza.
Case Studies: Dimostrazione di una compilazione riuscita (richiesta di denaro Venmo) e del rifiuto di compilare (Spotify/Todoist) quando gli effetti collaterali irreversibili sono sotto-determinati.

Risultati

Accuratezza della Dipendenza

Corpus T1 (Training Split): La regola meccanizzata ha ottenuto una precisione di 0,928 e un richiamo di 0,943 su 15.775 archi def–use. Questo supera significativamente le baseline basate sull'adiacenza (F1 0,711) e le misure di directly-follows basate sulla soglia di frequenza (F1 0,712).
- Caveat: Gli studi di ablazione rivelano che su questo specifico corpus la prova di esclusione è quasi vacua perché ogni relazione ha almeno un produttore candidato. Di conseguenza, l'accuratezza riportata si basa pesantemente sulla ricenza (selezionando il sopravvissuto più recente) tra i candidati sopravvissuti piuttosto che sul test di esclusione completo. La disciplina di esclusione è esercitata dalla skill dell'LLM, non dalla regola meccanizzata, a causa dei limiti del corpus.
Esecuzione Blind Skill: Su un subset di 250 archi di T1, la skill dell'LLM ha raggiunto 0,992 di precisione/richiamo in un singolo run.
AppWorld: Contro un riferimento basato su replay (che recupera i valori mascherati), la regola ha ottenuto una precisione di 0,993 su 563 archi di token. Questo funge da controllo di auto-coerenza piuttosto che da validazione indipendente, poiché la costruzione del riferimento condivide lo stesso assunto (preferire i token della stessa applicazione) della regola testata. Inoltre, questo limite riguarda solo l'attribuzione del session-token e non valida il recupero di flussi di identificatori non-token.

Compilazione e Esecuzione del Workflow

Intento Venmo: Ha compilato 34 chiamate API osservate (inclusi retry e lookup dello schema) in 11 chiamate a runtime. Il workflow ha superato 15 di 21 test di stato su istanze trattenute. I 6 fallimenti sono avvenuti perché il ramo specifico richiesto per l'istanza trattenuta non era mai stato osservato nel set di addestramento, causando l'escalation invece dell'azione.
Intento Spotify/Todoist: Il compilatore ha correttamente rifiutato di compilare questo intento perché la direzione della mutazione (aggiunta vs rimozione) era sotto-determinata dalle tracce, rappresentando un effetto collaterale irreversibile.
Riduzione delle Chiamate: Attraverso 56 scenari AppWorld, la frazione mediana di chiamate rimovibili (scoperta dello schema e ripetizioni identiche per byte) era del 51,4%.

Scoperta dell'Intento

Su T1, il clustering ha raggiunto una purezza di 0,930 sui dialoghi coperti ma un basso Adjusted Rand Index (0,235) rispetto alle etichette di riferimento. Ciò indica che il sistema scopre una partizione più fine rispetto alle etichette di riferimento (suddividendo i domini in task a livello di template) piuttosto che una classificazione errata.

Significato e Rivendicazioni

Il paper afferma che l'adiacenza osservata non implica una dipendenza. Imponendo una disciplina di evidenza che richiede l'esclusione di origini alternative, TraceCompiler può compilare tracce rumorose in workflow deterministici che riducono le chiamate agli strumenti e le invocazioni dell'LLM a runtime.

Sicurezza: Il sistema privilegia la sicurezza rispetto alla completezza. Si astiene dal compilare workflow in cui le azioni irreversibili sono sotto-determinate, evitando l'esecuzione di procedure speculative e insicure.
Efficienza: Sebbene il paper misuri la riduzione delle chiamate (ad es., da 34 a 11 chiamate), esso non rivendica esplicitamente un'efficienza netta perché i costi di compilazione offline non sono misurati. La premessa economica è che un modello capace può ammortizzare il costo dell'analisi su esecuzioni ripetute.
Limitazioni: Gli autori riconoscono che l'attuale valutazione si basa su dati sintetici o generati da simulatori. La disciplina di "esclusione" è esercitata dalla skill dell'LLM ma non completamente dalla regola meccanizzata a causa dei limiti del corpus. Il sistema attualmente manca di meccanismi di versionamento e invalidazione del workflow per il drift delle API.

Il lavoro stabilisce che le tracce osservate vincolano le affermazioni sulla necessità in modo altrettanto stretto di quanto vincolino le affermazioni sulla dipendenza, e che gli strumenti utilizzati per testare i workflow compilati (harness di esecuzione) sono essi stessi procedure di inferenza che richiedono validazione.