Il prezzo elevato dei flussi di lavoro intelligenti
Gli assistenti AI moderni seguono spesso procedure a più passaggi — prenotare un volo, risolvere problemi software, gestire una richiesta di rimborso assicurativo.
L’approccio dominante, chiamato surface orchestration, avvolge un modello linguistico di grandi dimensioni (LLM) in un controller esterno che inietta prompt e instrada le decisioni a ogni turno.
Questo approccio funziona bene ma è costoso: a ogni passo viene chiamato un modello frontier e l’orchestrator aggiunge latenza e complessità.
Un team dell’Università di Melbourne pone una domanda provocatoria: e se potessimo compilare l’intero flusso di lavoro direttamente nei pesi di un modello piccolo, eliminando l’orchestrator a runtime?
Due architetture: Surface vs. Subterranean
La surface orchestration è come un GPS che ti dice costantemente dove svoltare.
Un programma esterno siede tra l’utente e il LLM, fornendo prompt per i nodi e decidendo il passo successivo in base all’output del modello.
La subterranean compilation ribalta la situazione.
L’orchestrator viene usato solo durante l’addestramento per generare dialoghi di esempio.
Al momento del deployment, l’utente parla direttamente con un piccolo modello fine‑tuned — l’agente subterranean — che segue la procedura a partire dai propri pesi, guidato da un system prompt minimo.
L’intuizione chiave del paper: la conoscenza procedurale può essere incorporata nei parametri, non reiniettata a ogni chiamata.
La pipeline di compilazione: dal flowchart ai pesi
La pipeline di compilazione si articola in quattro fasi.
In primo luogo, gli esperti definiscono il flusso di lavoro come un grafo orientato (flowchart) con nodi per i turni dell’agente e dell’utente, e archi che codificano le transizioni e le condizioni.
In secondo luogo, un modello frontier (Claude Sonnet 4.5) genera conversazioni sintetiche percorrendo tutti i percorsi aciclici validi attraverso il grafo.
In terzo luogo, un piccolo LLM open‑source viene fine‑tuned su questi dialoghi usando full‑parameter update — i metodi a basso rango come LoRA si sono mostrati inefficaci sui task procedurali.
Infine, il modello viene messo in produzione senza alcun orchestrator; riceve solo una breve istruzione come «Sei un utile assistente per la prenotazione di viaggi».
I dati di addestramento contengono solo dialoghi naturali, mai le annotazioni sottostanti del flowchart.
Procedure come grafi orientati
I flussi di lavoro sono formalizzati come grafi con nodi (turni agente/utente), archi (transizioni con condizioni opzionali), un nodo iniziale e nodi terminali per successo, abbandono o escalation.
Tre domini mettono alla prova la portata dell’approccio:
- Prenotazione viaggi (14 nodi, 86 percorsi unici, 4–17 turni)
- Supporto Zoom (14 nodi, 60 percorsi, codifica conoscenze specifiche del prodotto su UI e codici di errore)
- Rimborsi assicurativi (55 nodi, 2.381 percorsi, 9–39 turni, con cicli annidati e dipendenze tra fasi)
La complessità del grafo assicurativo dimostra che la compilazione può gestire flussi di lavoro aziendali reali, non semplici script lineari.
Valutazione rigorosa con utenti simulati
Tutti gli esperimenti utilizzano 200 scenari per condizione, generati da un simulatore utente dinamico (Claude Sonnet 4.5) che impersona clienti con personalità, budget e obiettivi diversi, senza vedere il flowchart.
Ogni conversazione viene valutata da un LLM‑as‑judge su cinque criteri (scala 1–5): Successo del compito, Accuratezza delle informazioni, Coerenza, Gestione elegante e Naturalezza.
La valutazione primaria utilizza Claude Sonnet 4.5; un controllo di robustezza ha rivalutato tutte le conversazioni con GPT‑4.1 usando la stessa griglia.
I confronti statistici si basano su test di Wilcoxon per dati appaiati o Mann–Whitney U con correzione di Holm–Bonferroni, oltre a d di Cohen e intervalli di confidenza bootstrap.
Prenotazione viaggi: un modello da 3B sfida il frontier
L’agente subterranean da 3B (Qwen 2.5 3B Instruct, fine‑tuned su 2.125 dialoghi sintetici) è stato confrontato con tre baseline.
| Confronto | Successo compito | Accuratezza informazioni | Coerenza | Gestione elegante | Naturalezza |
|---|---|---|---|---|---|
| vs. 3B orchestrator | +0.18*** | +0.05 (n.s.) | +0.22*** | +0.20*** | +0.17*** |
| vs. LangGraph (Claude 3.5) | paragonabile | 4.75 vs 4.21* | paragonabile | 4.07 vs 4.62*** | 4.12 vs 4.84*** |
| vs. in‑context Claude 3.5 | ~102% di accuratezza | — | — | ~82% di gestione elegante | ~82% di naturalezza |
Il modello piccolo batte la sua stessa taglia quando orchestrato e supera il modello frontier 70 volte più grande nell’accuratezza delle informazioni.
Resta indietro nella gestione elegante e nella naturalezza, ma il divario è modesto — e il costo è di due ordini di grandezza inferiore.
Supporto Zoom e la strada da percorrere
Portare il modello a 8B (Qwen3‑8B) nel dominio del supporto Zoom conferma la tendenza.
Con 8 esecuzioni di addestramento indipendenti e più dati, l’agente subterranean eguaglia o supera nuovamente l’orchestrator LangGraph in termini di successo del compito e accuratezza, funzionando a una frazione del costo.
Il dominio dei rimborsi assicurativi (55 nodi) spinge il metodo ancora oltre, dimostrando che anche procedure profondamente annidate possono essere internalizzate.
Questi risultati suggeriscono un futuro in cui flussi di lavoro agentici complessi vengano distribuiti su dispositivo o su larga scala, senza pagare la tassa di orchestrazione a ogni passo.
