È importante valutare attentamente come e dove vengono prese le decisioni nel proprio sistema agentico.
Delegare più decisioni a un LLM consente al sistema di adattarsi potenzialmente a più attività, ma può comportare costi in termini di velocità, affidabilità e robustezza.
Ove possibile, cercate di trasferire dal LLM al codice software esplicito la maggior parte del processo decisionale. Ciò vale soprattutto per i flussi di lavoro ad alto rischio e/o in produzione.
Quando si progetta un sistema agentico basato su LLM, una delle decisioni più importanti riguarda la quota del processo decisionale affidata a un modello LLM rispetto a quella gestita da software esplicito.
Per comprendere meglio questa scelta, possiamo immaginarla come uno spettro tra i seguenti approcci:
Le architetture basate su router definiscono esplicitamente nel codice l'ordine e la logica, garantendo verificabilità, prevedibilità e robustezza per attività circoscritte a un ambito specifico (sono dette anche «agenti di workflow»).
Gli agenti orchestratori si affidano ai modelli linguistici di grandi dimensioni (LLM) per decidere dinamicamente i flussi delle attività tramite prompt in linguaggio naturale. Sono ideali per interazioni aperte, in cui una logica predefinita è insufficiente o impossibile.
Per i flussi di lavoro ad alto rischio e in produzione, in genere consigliamo di ricorrere maggiormente a funzionalità basate su router, riservando gli orchestratori alle applicazioni che richiedono conversazioni flessibili e di carattere generale.
Architetture basate su router
I sistemi agentici basati su router:
Definiscono esplicitamente il flusso decisionale tramite codice o software e usano un LLM per stabilire quale percorso debba seguire il software.
Sono più simili ai sistemi software tradizionali, poiché prevedono percorsi chiari e prevedibili che producono risultati più coerenti.
Sono ideali per attività che possono essere definite in modo rigoroso.
Di seguito è riportato un semplice esempio di agente chatbot per la prenotazione di voli che adotta l'«approccio router». Sebbene il LLM ci aiuti a classificare l'intento della domanda tra tre opzioni possibili, è il software ad associare tale intento a una risposta testuale predefinita. Poiché il LLM è soggetto a vincoli molto rigidi, l'utente riscontrerà un comportamento più coerente.
Architetture con orchestratore
A differenza dei sistemi basati su router, i sistemi agentici con orchestratore:
Definiscono i flussi logici tramite prompt in linguaggio naturale anziché tramite software. Nota: rispetto a un linguaggio di programmazione, il linguaggio naturale è intrinsecamente ambiguo e flessibile, caratteristiche che possono essere sia positive sia negative, come vedremo più avanti. Consideriamo questo approccio come «intenzione anziché istruzione».
Possono offrire più opzioni di elaborazione, lasciando al LLM la scelta dell'ordine e del metodo di esecuzione.
Possono creare dinamicamente nuovi percorsi logici difficili da definire esplicitamente nel software.
Questa ambiguità può produrre risultati incoerenti, ma quando tutto funziona l'esperienza può sembrare «magica».
L'esempio seguente applica un approccio con orchestratore allo stesso semplice problema relativo a una compagnia aerea. Anziché lasciare che sia il software a decidere quale risposta sia appropriata, il processo decisionale viene delegato al livello LLM. In questo caso abbiamo un sistema multiagente in cui un agente orchestratore «principale» valuta la richiesta dell'utente e la passa a un agente progettato appositamente per modificare i voli, che infine fornisce la risposta all'utente.
In questo esempio, il livello LLM svolge le funzioni di classificatore, router e autore della risposta. Nell'esempio con router, svolgeva soltanto la funzione di classificatore, mentre il software gestiva tutto il resto.
Ove possibile, consigliamo di adottare approcci basati su router, che offrono i seguenti vantaggi:
Velocità ed efficienza: i calcoli locali sono più veloci rispetto agli orchestratori che dipendono da API esterne. Inoltre, elaborare la logica «IF/ELSE» in Python è molto meno costoso che pagare un fornitore di LLM per eseguirla su un modello da 400 miliardi di parametri.
Verificabilità e prevedibilità: il debug, i test e la manutenzione sono molto più semplici grazie a pratiche software consolidate.
Trasparenza e affidabilità: una minore variabilità del comportamento semplifica la risoluzione dei problemi. Una quota maggiore del flusso applicativo è inoltre espressa in software trasparente e sottoposto a controllo di versione, anziché nei pesi opachi e non interpretabili di un LLM.
Gli svantaggi degli approcci basati su router sono la rigidità, la scarsa flessibilità e la difficoltà nell'affrontare problemi più aperti. Un chatbot che fornisce sempre le stesse identiche risposte potrebbe risultare noioso o statico agli utenti.
Le architetture con orchestratore offrono funzionalità avanzate:
Pianificazione: possono pianificare dinamicamente le risposte.
Selezione degli strumenti/passaggio a un agente: selezionano gli strumenti appropriati o delegano le attività agli agenti.
Combinazione iterativa dei risultati: elaborano e ricombinano creativamente i risultati in modo iterativo.
Determinazione del completamento: stabiliscono quando sono state raccolte informazioni sufficienti per finalizzare una risposta.
Framework come Pydantic-AI o Agents SDK di OpenAI rendono l'orchestrazione semplice e rapida da implementare. Questo li rende ideali per demo o proof of concept.
Gli svantaggi di questo approccio sono i seguenti:
Non vi è alcuna garanzia che le fasi di pianificazione del LLM e le azioni successive siano corrette o appropriate. Il sistema basato su router presenta lo stesso problema, ma essendo più vincolato ha un comportamento più prevedibile.
Per attività semplici e ben definite, è improbabile che siano necessarie tutte le funzionalità di un sistema multiagente. Ad esempio, nel nostro caso dell'agente per compagnie aeree, probabilmente esiste solo un numero limitato di richieste che un utente desidera rivolgere a un sistema di assistenza aerea.
Poiché il LLM contiene una parte maggiore della logica, è molto più esposto ai tentativi di aggiramento delle protezioni o di sfruttamento da parte di malintenzionati.
Ast trae il processo decisionale trasferendolo nel LLM e rende quindi più difficile comprendere il sistema, anche se strumenti di monitoraggio come Langfuse o Braintrust possono essere parzialmente utili.
Nota per il lettore: sebbene le capacità dei modelli stiano evolvendo rapidamente, è improbabile che quanto segue cambi nel prossimo futuro.
Definite l'ambito del problema.
Riuscite a rappresentare facilmente in un diagramma la logica decisionale desiderata?
La vostra applicazione non può tollerare errori o comportamenti imprevisti?
Rispondere «sì» a una delle due domande suggerisce che le funzionalità basate su router siano più adatte.
Ove possibile, consigliamo di adottare approcci basati su router finché lo consentono. Come principio generale, se una parte del sistema può essere espressa nel codice, esprimetela nel codice: non ricorrete eccessivamente ai LLM quando non sono necessari.
Quando si raggiungono i limiti di questi approcci, alcuni vantaggi degli orchestratori per problemi aperti possono essere riprodotti in modo controllato. Ad esempio:
Selezione degli strumenti/passaggio a un agente: facilmente implementabile tramite diramazioni condizionali o classificatori LLM.
Determinazione del completamento: semplici classificatori LLM possono verificare che una risposta sia completa prima di restituirla all'utente.
La «pianificazione» e la «combinazione iterativa dei risultati» sono però indubbiamente molto più difficili da realizzare in un sistema rigido basato su router. Quando un'attività richiede queste funzionalità, in base alla valutazione di un classificatore LLM o di un'altra logica, suggeriamo quindi di creare nel sistema una diramazione con orchestratore soggetta a meno vincoli.
La scelta tra architetture basate su router e architetture con orchestratore dovrebbe riflettere la chiarezza, la complessità e lo stile di interazione dell'applicazione. Gli approcci basati su router offrono attualmente affidabilità, efficienza e facilità di test per attività ben definite. Gli orchestratori offrono maggiore flessibilità per interazioni conversazionali più ampie.
Con la continua evoluzione dei LLM, l'equilibrio tra questi approcci potrebbe cambiare. Per i carichi di lavoro in produzione preferiamo architetture basate su router o ibride, riservando gli orchestratori ai problemi aperti che richiedono interazioni dinamiche e simili a quelle umane.