Agentic AI

Un sistema di agentic AI è composto dai seguenti componenti:

• Un componente di Orchestrazione degli agenti gestisce e coordina le azioni di un insieme di agenti. Il componente di orchestrazione degli agenti può utilizzare un LLM per suddividere e generare dinamicamente workflow per risolvere attività complesse, oppure può utilizzare esclusivamente workflow definiti staticamente utilizzando tecnologie come Business Process Modelling Notation (BPMN), Business Process Execution Language (BPEL), o altre tecnologie di workflow.
  
  
• Uno o più agenti, parti di software in grado di autodeterminare ed eseguire azioni per raggiungere obiettivi specifici. Gli agenti utilizzano in genere un LLM per generare dinamicamente piani per completare le attività. Gli agenti possono anche avvalersi di strumenti per interagire con sistemi esterni, come ad esempio un'API di un'applicazione aziendale, per ricercare archivi di conoscenza, come ad esempio una query di Wikipedia, o per effettuare calcoli, come le operazioni matematiche, che non possono essere eseguite in modo accurato o efficace utilizzando un solo LLM.
  
  
• Infine, gli strumenti interagiscono con fonti e sistemi aziendali ed esterni per recuperare informazioni e aggiornare i sistemi di registrazione.

Gli agenti hanno una propria architettura concettuale, illustrata nella figura sottostante.

Gli agenti sono costituiti dai seguenti componenti principali:

• Il componente Input è una o più fonti di input che inducono l'agente ad agire. Di solito si tratta di una query in linguaggio naturale o di un'attività da parte di un utente, ma potrebbe anche essere un evento di sistema, come la creazione di un file, un messaggio su una coda Kafka o una chiamata API strutturata.
  
  
• La componente esecuzione coordina le attività dell'agente per svolgere il compito richiesto. Comunemente, il primo compito eseguito dal componente esecuzione consiste (i) nel mobilitare un elenco degli strumenti e delle risorse disponibili per l'agente, e (ii) invocare il componente pianificazione e riflessione per generare un piano di attività per svolgere il compito. Il componente esecuzione esegue quindi il piano generato, richiamando strumenti e risorse necessari per raccogliere informazioni o modificare l'ambiente esterno dell'agente; e può periodicamente richiamare nuovamente il componente pianificazione e riflessione per adattare il piano di attività in base a risposte/errori dello strumento.
  
  
• Il componente pianificazione e riflessione, comunemente un LLM, consente all'agente di creare piani d'azione passo dopo passo per svolgere un'attività in risposta ai suoi input e di riflettere sui risultati delle azioni e di adattare i propri piani in risposta.
  
  
• Il componente Integrazione degli strumenti consente all'agente di utilizzare gli "strumenti" per chiamare le API e accedere alle risorse per completare le azioni e raccogliere informazioni per contribuire al completamento dell'attività complessiva.
  
  
• Il componente memoria gestisce il contesto a breve termine all'interno dell'attività, così come la conoscenza a lungo termine che consente all'agente sia di mantenere il contesto tra le invocazioni di attività (ad esempio, "Annulla l'ultimo ordine di acquisto"), sia di fornire una base per l'analisi delle azioni passate e l'ottimizzazione delle azioni future.
  

Componenti aggiuntivi, non mostrati nella figura, possono essere aggiunti per fornire la gestione operativa degli agenti, il monitoraggio delle prestazioni e i controlli di sicurezza come la propagazione delle identità e la prevenzione delle fughe di dati.

Il diagramma seguente illustra il flusso di controllo e di informazioni attraverso l'architettura concettuale.

1. Un utente invia una query a un'applicazione di AI generativa (ad esempio, un chatbot o un'interfaccia di query all'interno di un'applicazione aziendale)
   
   
2. L'applicazione di AI generativa passa la query dell'utente all'Agent Orchestrator sotto forma di query non elaborata, ad esempio l'applicazione AI è un'interfaccia di chat o l'attivazione di un workflow predefinito, ad esempio l'avvio di una richiesta di acquisto. Per la procedura dettagliata si presumerà una query non elaborata.
   
   
3. Il router utilizza un LLM ottimizzato per suddividere la query dell'utente in una serie di azioni, o passaggi, necessari per arrivare a una risposta. Ad esempio, per rispondere alla domanda "Qual è la temperatura attuale a Winnipeg, Manitoba, Canada?" Come si confronta con la media storica di questo periodo dell'anno?" L'LLM potrebbe rispondere con il seguente elenco concettuale di azioni:
   
   
   • Cerca la temperatura attuale di Winnipeg usando l'agente Meteo
   • Cerca la data attuale usando l'agente Calendario
   • Cerca la temperatura media a Winnipeg in questa data usando l'agente Ricerca
   • Trova la differenza tra la temperatura attuale e la media storica utilizzando l'agente Calculator
   • Formula una risposta in linguaggio naturale utilizzando l'agente Linguaggio
     
     
4. L'orchestratore poi invoca l'agente appropriato per ogni azione nella lista. Continuando con l'esempio del passaggio 3:
   
   
   • L'orchestratore invoca l'agente Meteo per recuperare l'attuale temperatura di Winnipeg, -1 °C.
   • L'orchestratore invoca l'agente Calendario per ottenere la data attuale, il 9 novembre 2023.
   • L'orchestratore utilizza l'agente Ricerca per trovare la temperatura normale a Winnipeg il 9 novembre, 1,4 °C.
   • L'Orchestrator richiama l'agente Calculator per trovare la differenza tra le due temperature, -1 - 1,4 = -2,4
   • L'Orchestrator utilizza l'agente Language per formulare una risposta alla domanda iniziale utilizzando i dati raccolti
      
5. Quando un agente viene invocato, può, come l'orchestratore, usare un LLM per pianificare le sue azioni. Continuando con l'esempio, l'agente Meteo riceverebbe la richiesta "Qual è la temperatura attuale a Winnipeg?", per la quale genererebbe il seguente piano:
   
   
   • Cerca in quale paese si trova Winnipeg
   • Consulta l'autorevole servizio meteorologico nazionale per il paese di Winnipeg
   • Usa l'API Meteo per interrogare il servizio meteorologico sulla temperatura attuale a Winnipeg.
   • L'agente poi cercherebbe il Paese in cui si trova Winnipeg (Canada) usando un LLM o un servizio esterno, userebbe quel valore per consultare il servizio meteorologico nazionale del Canada (Environment Canada) e userebbe l'API Meteo per ottenere la temperatura attuale di Winnipeg.
      
6. La risposta finale viene poi inviata all'applicazione di AI generativa; nel nostro esempio: "La temperatura attuale a Winnipeg è di -1 °C. Si tratta di 2,4 °C in meno rispetto alla norma storica di 1,4
   °C".
   
   
7. La risposta formulata viene restituita all'utente.

Il diagramma sopra illustra la mappatura dei prodotti IBM verso l'architettura di agentic AI.

Watsonx Orchestrate è una soluzione di agentic AI "tutto in uno" che combina:

• pubblicazione e gestione di strumenti (chiamate skill in watsonx Orchestrate);
• composizione delle competenze in processi complessi e a più fasi utilizzando workflow dichiarativi;
• agenti specifici di dominio precostituiti per aree di business orizzontali come risorse umane e acquisti.

Watsonx.ai Agent Builder è uno strumento low-code/no-code che consente agli sviluppatori di creare agenti e definire e gestire strumenti utilizzando flussi precostituiti.

Strategia di orchestrazione

L'orchestrazione degli agenti può essere implementata con diversi approcci. Un approccio di orchestrazione centralizzata utilizza un singolo componente master di orchestrazione per gestire le azioni di tutti gli altri agenti nel sistema. Avere un unico punto di configurazione e gestione rende il sistema complessivo semplice da gestire e controllare, facile da diagnosticare. L'aspetto negativo è che un singolo punto di controllo può diventare un collo di bottiglia e portare a problemi di scalabilità con l'aumento dei volumi delle richieste e/o del numero di agenti.

Un approccio di orchestrazione decentralizzata implementa una coda di attività da cui gli agenti prelevano le attività e pubblicano i risultati, instradando tra loro le attività composte da più parti; in modo simile a un sistema blackboard. Le soluzioni di orchestrazione decentralizzate sono estremamente robuste e tolleranti ai guasti, ma sono difficili da progettare e risolvere man mano che i sistemi diventano più grandi con maggiori funzionalità.

Infine, un approccio di orchestrazione gerarchica combina elementi degli approcci centralizzati e decentralizzati. Nell'orchestrazione gerarchica, un orchestratore master viene utilizzato per coordinare le azioni di agenti di alto livello che a loro volta possono evocare altri agenti per completare compiti complessi. In questo modo si conserva gran parte della facilità di gestione e di controllo di un approccio centralizzato, ma si riduce la possibilità che il componente di controllo centrale diventi un collo di bottiglia in presenza di elevati volumi di richieste e/o di un gran numero di agenti.

Granularità dell'agente

La granularità di un agente AI si riferisce alla complessità dei compiti che l'agente può svolgere. Un agente ad alta granularità può essere in grado di svolgere molti compiti o un piccolo numero di compiti con un alto livello di dettaglio, mentre un agente a bassa granularità può essere in grado di svolgere solo un piccolo numero o anche solo un singolo compito con un livello di dettaglio ridotto. Per rendere più chiaro questo concetto, consideriamo un agente del servizio clienti. Un agente a bassa granularità può essere in grado di rispondere solo a semplici domande su un prodotto (ad esempio, "È disponibile in nero?"), mentre un agente ad alta granularità può essere in grado di controllare gli inventari locali e organizzare la consegna del prodotto a casa del cliente.

I progettisti di soluzioni agentiche devono decidere quanto rendere granulari i singoli agenti all'interno del sistema, ad esempio se avere un numero ridotto di agenti ad alta granularità oppure un numero maggiore di agenti a bassa granularità. Le ampie funzionalità dell'agente ad alta granularità comportano un maggiore fabbisogno di risorse informatiche e tempi di completamento delle attività più lunghi. Sebbene meno capaci, il focus ristretto degli agenti a bassa granularità significa che richiedono meno risorse di calcolo e generalmente completano le attività molto più velocemente.

Sebbene il livello di granularità "giusto" non sia ancora noto, le prime esperienze suggeriscono la creazione di agenti a bassa granularità allineati a processi aziendali mirati, ad esempio Purchase_Order_Processing_Agent, produce un buon equilibrio tra requisiti di risorse, velocità di elaborazione e complessità della soluzione. Gli agenti a bassa granularità possono quindi essere incorporati in workflow statici, oppure invocati da agenti ad alta granularità come parte di un processo più ampio.

Workflow statici e dinamici a confronto

I progettisti di soluzioni di agentic AI devono trovare un equilibrio tra agenti che seguono processi e workflow predefiniti e statici, e workflow generati dinamicamente in risposta ai prompt degli utenti. Sebbene non esista una risposta giusta o sbagliata, si consiglia agli architetti di tenere in considerazione le seguenti raccomandazioni e considerazioni:

• I workflow statici dovrebbero essere utilizzati per i processi aziendali costituiti da più passaggi complessi che attraversano domini di conoscenza (ad esempio, legali e contabili) o che sono soggetti a supervisione normativa. L'uso di workflow statici in questi casi offre agli architetti diversi benefici:

  • I workflow statici sono (relativamente) semplici da strumentare, monitorare e ispezionare e possono essere utilizzati come prova di conformità normativa. I workflow generati dinamicamente sono più difficili da monitorare durante l'esecuzione e le singole esecuzioni di processo devono essere ricostruite a partire dai singoli log degli agenti. I workflow dinamici hanno anche il potenziale di variare la sequenza delle attività, complicando ulteriormente l'audit e il monitoraggio della conformità.
    
    
  • Avere "passaggi di consegne" ben definiti tra le diverse aree di competenza garantisce una chiara separazione delle responsabilità e rende più semplice assicurare che le informazioni trasferite siano complete e corrette. Sebbene lo stesso possa essere ottenuto con un workflow generato dinamicamente, richiede maggiore attenzione nella progettazione e nell'implementazione
    
    
• I workflow dinamici devono essere utilizzati per attività o funzioni "single step" che vengono eseguite ravvicinate nel tempo e che non attraversano domini di conoscenza, e la cui esecuzione non è soggetta a supervisione o controlli normativi.