Modelli di progettazione dei sistemi agenti

La creazione di un sistema agente comporta l'orchestrazione di come le chiamate LLM, il recupero dati e le azioni esterne fluiscono insieme. È possibile considerare i modelli di progettazione per i sistemi agente in un continuum di complessità e autonomia: da catene deterministiche , attraverso sistemi a singolo agente che possono prendere decisioni dinamiche (e possono coinvolgere più chiamate LLM dietro le quinte), fino a architetture multi-agenti che coordinano più agenti specializzati.

Richiamo degli strumenti

Prima di approfondire i modelli di progettazione, è importante comprendere l'invocazione degli strumenti come funzionalità fondamentale che può essere utilizzata in qualsiasi sistema di agenti, da semplice a complesso. La chiamata agli strumenti è un meccanismo che consente a un sistema agente di interagire con funzioni esterne, origini dati o servizi. Questo può abilitare:

• Ricerche di dati in tempo reale, ad esempio query SQL, recuperi CRM, o recupero dell'indice vettoriale.
• Azioni come l'invio di un messaggio di posta elettronica o l'aggiornamento di un record.
• Logica o trasformazioni arbitrarie tramite funzioni o API Python.

La chiamata di strumenti fornisce quindi un potente meccanismo per rendere le VM "consapevoli" di dati esterni o API indipendentemente dal modello di progettazione scelto.

Per altre informazioni sugli strumenti dell'agente, vedere strumenti dell'agente di intelligenza artificiale.

Le sezioni seguenti illustrano tre modelli di progettazione dei sistemi agenti, ciascuno dei quali può sfruttare la chiamata di strumenti in gradi variabili.

Confrontare i modelli di progettazione delle app di intelligenza artificiale generativa

I modelli di progettazione delle app di intelligenza artificiale di generazione (agente) vengono presentati in ordine di complessità.

Modello di progettazione	Quando usare	Vantaggi	Contro
catena deterministica	Attività ben definite Pipeline statiche, ad esempio RAG di base Nessuna necessità di decisioni in tempo reale	Molto semplice Facile da controllare	Rigido Richiede modifiche al codice per adattarsi
sistema a agente singolo	Query da moderate a complesse nello stesso dominio Alcune decisioni dinamiche senza sovraccarico di più agenti specializzati.	Flessibile Più semplice di un sistema multi-agenti Buon "valore predefinito"	Meno prevedibile Deve proteggersi dalle chiamate ripetute o errate degli strumenti
sistema multi-agente	Domini di grandi dimensioni o interfunzionali; più agenti "esperti" ; logica distinta o contesti di conversazione; modelli di reflection avanzati.	Altamente modulare Scalabilità in domini di grandi dimensioni	Complesso da coordinare Più difficile da tracciare e debuggare

sistema a agente singolo

Un sistema a agente singolo offre un flusso coordinato di logica, spesso orchestrando più chiamate LLM, per gestire le richieste in ingresso. L'agente può:

1. Accetta richieste, come le query degli utenti, e ogni contesto pertinente, ad esempio la cronologia delle conversazioni.
2. Rifletti su come rispondere al meglio, decidere, se necessario, se chiamare strumenti per dati o azioni esterne.
3. Se necessario, chiamare ripetutamente un LLM (e/o gli stessi strumenti) finché non viene raggiunto un obiettivo o viene soddisfatta una determinata condizione (ad esempio, la ricezione di dati validi o la risoluzione di un errore).
4. Integrare gli output degli strumenti nella conversazione.
5. Restituire una risposta coesa come output.

In molti casi d'uso, un singolo round di ragionamento LLM (spesso con la chiamata di strumenti) è sufficiente. Tuttavia, gli agenti più avanzati possono scorrere più passaggi fino a quando non arrivano a un risultato desiderato.

Anche se c'è solo un agente, è comunque possibile avere più chiamate LLM e strumenti sotto le quinte (per pianificazione, generazione, verifica e così via), tutti gestiti da questo singolo flusso unificato.

Esempio di : Assistente supporto tecnico

• Se l'utente pone una domanda semplice ("Qual è la nostra politica di restituzione?"), l'agente può rispondere direttamente dalla conoscenza posseduta dall'LLM.
• Se l'utente desidera lo stato dell'ordine, l'agente chiama una funzione lookup_order(customer_id, order_id). Se tale strumento risponde con "numero di ordine non valido", l'agente può riprovare o richiedere all'utente l'ID corretto, continuando fino a quando non può fornire una risposta finale.

Quando usare:

• Si prevedono query utente diverse, ma ancora all'interno di un dominio coesivo o di un'area di prodotto.
• Alcune query o condizioni possono giustificare l'utilizzo di strumenti, ad esempio decidere quando recuperare i dati dei clienti.
• Si vuole una maggiore flessibilità rispetto a una catena deterministica, ma non richiedono agenti specializzati separati per attività diverse.

Vantaggi:

• L'agente può adattarsi a query nuove o impreviste scegliendo gli strumenti (se presenti) da chiamare.
• L'agente può scorrere le chiamate LLM ripetute o le chiamate degli strumenti per perfezionare i risultati, senza dover configurare completamente più agenti.
• Questo modello di progettazione è spesso il punto ideale per i casi d'uso aziendali: più semplice eseguire il debug rispetto alle configurazioni multi-agente, consentendo comunque la logica dinamica e l'autonomia limitata.

Considerazioni:

• Rispetto a una catena hard-coded, è necessario proteggersi da chiamate di strumenti non valide o ripetute. I cicli infiniti possono verificarsi in qualsiasi scenario di chiamata di strumenti, quindi impostare limiti di iterazione o timeout.
• Se l'applicazione si estende su sottodomini radicalmente diversi (finanza, devops, marketing e così via), un singolo agente può diventare difficile o sovraccarico con requisiti di funzionalità.
• È comunque necessario progettare con attenzione richieste e vincoli per mantenere l'agente incentrato e pertinente.

catena deterministica (passaggi predefiniti)

In questo modello, lo sviluppatore definisce quali componenti vengono chiamati, in quale ordine e con quali parametri. Non esiste alcun processo decisionale dinamico su quali strumenti chiamare o in quale ordine. Il sistema segue un flusso di lavoro predefinito per tutte le richieste, rendendolo estremamente prevedibile.

Comunemente chiamato "Catena", il flusso è essenzialmente una catena fissa di passaggi, ad esempio:

1. Recuperare sempre la richiesta dell'utente e recuperare da un indice vettoriale per il contesto pertinente.
2. Combinare tale contesto con la richiesta dell'utente in un prompt LLM finale.
3. Chiama il LLM e restituisci la risposta.

Esempio di : catena RAG di base

Una catena RAG deterministica può sempre:

1. Recuperare i risultati top-k da un indice vettoriale usando la richiesta di un utente in ingresso (recuperare).
2. Formattare sezioni recuperate in un modello di prompt (aggiungere elementi).
3. Inoltrare la richiesta aumentata all'LLM (genera).
4. Restituisci la risposta del LLM.

Quando usare:

• Per le attività ben definite con flussi di lavoro prevedibili.
• Quando la coerenza e il controllo sono le priorità principali.
• Quando si vuole ridurre al minimo la latenza evitando più chiamate LLM per decisioni di orchestrazione.

Vantaggi:

• Massima prevedibilità e verificabilità.
• Generalmente una latenza inferiore (meno invocazioni LLM per l'orchestrazione).
• Più facile da testare e convalidare.

Considerazioni:

• Flessibilità limitata per la gestione di richieste diverse o impreviste.
• Può diventare complesso e difficile da gestire man mano che i rami logici crescono.
• Può richiedere un refactoring significativo per supportare nuove funzionalità.

sistema multi-agente

Un sistema multi-agente prevede due o più agenti specializzati che scambiano messaggi e/o collaborano alle attività. Ogni agente ha competenze specifiche per dominio o attività, contesto e set di strumenti potenzialmente distinti. Un "coordinatore" separato, che potrebbe essere un altro LLM o un router basato su regole, indirizza le richieste all'agente appropriato o decide quando passare da un agente a un altro.

esempio : Assistente aziendale con agenti specializzati

• Agente di supporto clienti: gestisce consultazioni CRM, restituzioni e spedizioni.
• Analytics Agent: è incentrata sulle query SQL e sul riepilogo dei dati.
• supervisore/router: sceglie quale agente è migliore per una determinata query dell'utente o quando passare.

Ogni sub-agente può eseguire chiamate di strumenti all'interno del proprio dominio (ad esempio lookup_customer_account o run_sql_query) che spesso richiedono richieste univoche o cronologie delle conversazioni.

Quando usare:

• Sono presenti diverse aree problematiche o set di competenze, ad esempio un agente di codifica o un agente finanziario.
• Ogni agente deve accedere alla cronologia delle conversazioni o alle richieste specifiche del dominio.
• Ci sono così tanti strumenti che inserirli tutti nello schema di un solo agente è poco pratico; ogni agente può possedere un sottoinsieme.
• Si vuole implementare la riflessione, la critica o la collaborazione tra agenti specializzati.

Vantaggi:

• Questo approccio modulare significa che ogni agente può essere sviluppato o gestito da team separati, specializzati in un dominio ristretto.
• Può gestire flussi di lavoro aziendali complessi di grandi dimensioni che un singolo agente potrebbe faticare a gestire in modo coesivo.
• Facilita il ragionamento avanzato in più passaggi o multi-prospettiva, ad esempio un agente genera una risposta e un altro la verifica.

Considerazioni:

• Richiede una strategia per il routing tra agenti, oltre al sovraccarico per la registrazione, il tracciamento e il debug tra più endpoint.
• Se si dispone di molti sotto-agenti e strumenti, può diventare complicato decidere quale agente ha accesso a quali dati o API.
• Gli agenti possono rimbalzare le attività all'infinito tra di loro senza risoluzione, se non strettamente vincolate.
  • I rischi di cicli infiniti esistono anche nelle chiamate a strumenti con agente singolo, ma le configurazioni multi-agente aggiungono un ulteriore livello di complessità nel debugging.

Consigli pratici

Indipendentemente dal modello di progettazione selezionato, prendere in considerazione le procedure consigliate seguenti per lo sviluppo di sistemi agenti stabili e gestibili.

1. Iniziare semplice: Se è necessaria solo una catena semplice, una catena deterministica è veloce da compilare.
2. Aggiungere gradualmente complessità: Quando sono necessarie query più dinamiche o origini dati flessibili, passare a un sistema a agente singolo con chiamate di strumenti.
3. Go multi-agent: Solo se sono presenti domini o attività chiaramente distinti, più contesti di conversazione o un set di strumenti di grandi dimensioni troppo grande per la richiesta di un singolo agente.

Se il tuo caso d'uso inizia in piccolo - come una semplice catena RAG - inizia con una catena codificata manualmente. Man mano che i requisiti si evolvono, è possibile aggiungere logica di chiamata degli strumenti per il processo decisionale dinamico o anche segmentare le attività in più agenti specializzati. In pratica, molti sistemi agenti reali combinano modelli. Ad esempio, usare una catena principalmente deterministica, ma consentire a LLM di chiamare in modo dinamico determinate API in un singolo passaggio, se necessario.

Mosaic AI Agent Framework è indipendente da qualsiasi modello scelto, semplificando l'evoluzione dei modelli di progettazione man mano che l'applicazione cresce.

Linee guida per lo sviluppo

• Suggerimenti
  • Mantenere le richieste chiare e minime per evitare istruzioni contraddittorie, distraendo le informazioni e riducendo le allucinazioni.
  • Fornire solo gli strumenti e il contesto richiesti dall'agente, anziché un set non associato di API o contesto irrilevante di grandi dimensioni.
• registrazione & osservabilità
  • Implementare una registrazione dettagliata per ogni richiesta utente, ogni piano agente e ogni chiamata dello strumento. MLflow Tracing consente di acquisire log strutturati per il debug.
  • Archiviare i log in modo sicuro e tenere presente le informazioni personali nei dati della conversazione.
• aggiornamenti del modello & blocco delle versioni
  • I comportamenti LLM possono cambiare quando i provider aggiornano i modelli in background. Usare il blocco delle versioni e i test di regressione frequenti per garantire che la logica dell'agente rimanga affidabile e stabile.
  • Combinare MLflow con la Valutazione degli Agenti di Intelligenza Artificiale Mosaic offre un modo semplificato per il versionamento degli agenti e la valutazione regolare della qualità e delle prestazioni.

Linee guida per il test e l'iterazione

• Gestione degli errori & logica di fallback
  • Pianificare per i fallimenti degli strumenti o degli LLM. I timeout, le risposte in formato non valido o i risultati vuoti possono interrompere un flusso di lavoro. Includere strategie di ripetizione dei tentativi, logica di fallback o una catena di fallback più semplice quando le funzionalità avanzate hanno esito negativo.
• Ingegneria iterativa dei prompt
  • Prevedere di perfezionare le richieste e la logica della catena nel tempo. Versione di ogni modifica (usando Git e MLflow) in modo da poter eseguire il rollback o confrontare le prestazioni tra le versioni.
  • Prendere in considerazione framework come DSPy per ottimizzare a livello di codice i prompt e altri componenti all'interno del sistema agente.

Linee guida per la produzione

• latenza e l'ottimizzazione dei costi
  • Ogni chiamata LLM o strumento aggiuntiva aumenta l'utilizzo dei token e il tempo di risposta. Se possibile, combinare i passaggi o memorizzare nella cache query ripetute per mantenere gestibili le prestazioni e i costi.
• Sicurezza e Sandboxing
  • Se l'agente può aggiornare i record o eseguire il codice, isolare tali azioni in un ambiente sandbox o richiedere l'approvazione umana, se necessario. Questo è fondamentale negli ambienti aziendali o regolamentati per evitare danni imprevisti.
  • Databricks consiglia gli strumenti del catalogo Unity per l'esecuzione in modalità sandbox. Vedere Scegliere l'approccio dello strumento. Unity Catalog consente l'isolamento dell'esecuzione arbitraria del codice e impedisce agli attori malintenzionati di indurre l'agente a generare ed eseguire codice che interferisce o intercetta altre richieste.

Seguendo queste linee guida, è possibile attenuare molte delle modalità di errore più comuni, ad esempio chiamate errate degli strumenti, deviazione delle prestazioni LLM o picchi di costi imprevisti e creare sistemi agente più affidabili e scalabili.