Progettare workflow AI super efficienti, serve (ovviamente) un altro strumento automatico

Un paper Harvard SEAS descrive un problema che chi ha costruito sistemi multi-agente conosce bene: in ogni fase del flusso di lavoro viene scelto un modello, spesso senza verifica della reale complessità del task. Il paper, “Orla: A Library for Serving LLM-Based Multi-Agent Systems“, è firmato da Rana Shahout, Hayder Tirmazi, Minlan Yu e Michael Mitzenmacher.

Un orchestratore sopra l’orchestrazione

Orla osserva ogni passaggio di un workflow AI e assegna il modello più efficiente in base a costo, latenza e qualità richiesta. Non tutte le fasi di un compito complesso hanno la stessa difficoltà: una classificazione semplice non ha bisogno dello stesso motore che serve per generare codice o ragionare su problemi matematici articolati.

Il problema che Orla prova a risolvere è concreto e diffuso: la maggior parte dei team, di fronte all’incertezza su quale modello serva in una fase del flusso, sceglie per eccesso di sicurezza. Si punta quasi sempre al modello più potente disponibile, anche per compiti banali come classificare un testo o estrarre un campo da un documento, perché il costo di un errore sembra più alto del costo dell’inferenza stessa. Il risultato è una bolletta di calcolo gonfiata da richieste che un modello dieci volte più piccolo avrebbe gestito con lo stesso esito.

Il progetto ha ricevuto un premio Slingshot dal Laude Institute, il fondo che finanzia infrastrutture AI di base considerate di interesse pubblico. Il codice è open source, licenza MIT, pubblicato su GitHub.

I numeri di Orla: meno tempo, meno costi, accuratezza quasi intatta

I benchmark del paper sono verificabili, non stime vendor. Su Hendrycks MATH, un test di ragionamento matematico a catena logica, Orla riduce la latenza media da 140,9 a 40,9 secondi: 3,45 volte più veloce, mantenendo l’accuratezza all’88% del baseline.

Il meccanismo instrada i problemi di difficoltà 1-4 su un modello piccolo (Qwen3-4B) e riserva il livello 5 al modello grande (Qwen3-32B). Su GSM8K, un set di 1.319 problemi matematici, la riduzione dei costi raggiunge il 41% con una perdita di accuratezza sotto i 2 punti percentuali.

L’architettura si regge su tre componenti: uno Stage Router che funge da proxy OpenAI-compatibile, un modulo di Telemetry che logga costo e latenza, un Runtime Mapper che rimappa i modelli sui dati. Le modifiche passano prima da uno shadow-testing, un doppio binario che verifica il cambiamento prima di applicarlo in produzione.

Orla si integra con LangGraph, SGLang, vLLM, Ollama e qualsiasi endpoint OpenAI-compatibile. Gli autori lo descrivono come “drop-in”: si inserisce nel workflow senza riscrivere il codice.

Il limite strutturale: Orla serve a chi ha già il problema

Qui si vede il limite di Orla. Risparmia risorse instradando le chiamate al modello giusto, ma presuppone un’infrastruttura multi-agente già complessa. Chi non ha quell’infrastruttura, non ha nemmeno il problema che Orla risolve.

I dati italiani lo confermano: il 16% delle imprese con più di dieci addetti usa AI, l’adozione strutturata si ferma all’8,2%. Per la maggioranza il tema non è scegliere tra dieci modelli, è tenere in piedi un solo modello su un solo compito.

Il quadro internazionale non è molto diverso. Le survey di settore stimano che solo una minoranza delle aziende enterprise abbia superato la fase pilota su sistemi multi-agente in produzione: la maggior parte resta ferma a un singolo assistente collegato a un solo flusso di lavoro. Orla nasce per un problema che esiste già, ma in una nicchia ristretta di organizzazioni. Il paper stesso lo lascia intuire: i benchmark sono costruiti su carichi di lavoro con decine di richieste al minuto, un volume che solo chi ha già scalato l’adozione AI genera davvero ogni giorno.

Orla rimane uno strumento di ricerca: nessuna disponibilità commerciale, nessun supporto enterprise, integrazione da configurare manualmente. Chi ha un team ML dedicato può sperimentare il framework, chi non lo ha aspetta: non ha ancora raggiunto la scala dove il routing diventa utile.

Il divario di competenze si aggiunge a quello tecnico. Configurare Stage Router, Telemetry e Runtime Mapper richiede persone che leggano metriche di latenza e costo per token, e che intervengano quando il sistema propone routing sbagliato. Competenze che oggi si trovano quasi solo nei team oltre la fase pilota, gli stessi che avrebbero i mezzi per costruire un router interno su misura.

Le aziende che buttano soldi instradando ogni richiesta sul modello più costoso, senza valutare la complessità reale, hanno un problema di spreco anche a un solo modello. La lezione di Orla: instradare in base alla difficoltà effettiva, rimane valida in versione artigianale.

Un router basato su regole, senza machine learning, cattura una parte del risparmio: separare richieste semplici (classificazione, estrazione, riformulazione) da quelle complesse (ragionamento multi-step, generazione di codice) e assegnarle a modelli di taglia diversa è alla portata di due o tre sviluppatori, non serve un laboratorio. È la versione a basso budget della stessa idea, meno precisa ma già capace di tagliare significativamente i costi.

Chi vuole evitare lo spreco senza aspettare un router intelligente può partire da un controllo più semplice: misurare quanto costa ogni chiamata al modello grande, e chiedersi se una versione più piccola avrebbe dato lo stesso risultato. È un esercizio manuale, richiede qualche ora di analisi sui log già disponibili, e non serve installare nessuna libreria nuova. Per un’azienda con un solo processo automatizzato, questo controllo vale più di qualunque orchestratore sofisticato: il problema da risolvere per primo è capire dove va il budget, non ottimizzarne la distribuzione tra modelli che nemmeno si usano ancora in parallelo.

Orla è un ulteriore strato, non il primo ordine

L’orchestrazione multi-agente non nasce con Orla. Tom’s Hardware l’ha già inquadrato come problema di architettura software, e come questione di orchestrazione da affrontare oltre il modello singolo. Orla è un ulteriore strato sopra strati già esistenti.

I sistemi multi-agente spesso falliscono sui dati prima ancora di arrivare al routing, e la maggior parte dei progetti enterprise fatica a uscire dalla fase pilota. In questo contesto, ottimizzare il routing tra modelli è un problema per chi ha già superato gli ostacoli precedenti.

La ricerca è solida: paper passato per revisione paritaria all’ACM Conference on AI and Agentic Systems, codice ispezionabile, benchmark riproducibili. Quello che manca dal comunicato è la consapevolezza di quanto ristretto sia il pubblico che può davvero beneficiarne oggi.

L’industria AI genera continuamente nuovi livelli infrastrutturali per gestire la complessità del precedente. Come nel cloud: prima Kubernetes, poi strumenti per gestire Kubernetes, poi piattaforme che promettono di semplificare quegli stessi strumenti. Chi vende il livello N+1 guadagna, indipendentemente dal valore reale che arriva all’utente finale.

Le PMI che guardano agli agenti AI per crescita restano a un piano diverso. La distanza tra chi ha risorse per sperimentare l’ennesimo strato e chi fatica ancora con l’AI di base rischia di allargarsi, mentre la ricerca produce soluzioni per problemi che solo una minoranza ha già raggiunto.

Qui sta il paradosso. Le poche aziende che hanno un’infrastruttura multi-agente abbastanza grande da giustificare Orla hanno già superato la fase in cui la maggioranza delle PMI si trova: singolo modello, singolo compito, nessun bisogno di routing. Orla non è per il mercato largo, è per chi è già nel segmento più ristretto e attrezzato.

Il paper Harvard è uno specchio fedele dell’adozione enterprise reale: non nel vasto numero di aziende che sperimentano un chatbot, ma in poche organizzazioni che gestiscono decine di agenti in produzione. Per tutti gli altri, il problema rimane a monte: far funzionare un solo modello su un solo processo senza sprecare budget prima ancora di raggiungere il punto dove Orla diventerebbe utile.