Agenti AI

Agenti AI

Cosa sono gli agenti?
“Agente” può essere definito in diversi modi. Alcuni definiscono gli agenti come sistemi completamente autonomi che operano in modo indipendente per periodi prolungati, utilizzando vari strumenti per portare a termine attività complesse. Altri usano il termine per descrivere implementazioni più prescrittive che seguono flussi di lavoro predefiniti. In realtà, è preferibile categorizzare tutte queste varianti come sistemi agentici , ma tracciamo un’importante distinzione architettonica tra flussi di lavoro e agenti :

• I flussi di lavoro sono sistemi in cui LLM e strumenti vengono orchestrati attraverso percorsi di codice predefiniti.
• Gli agenti , d’altro canto, sono sistemi in cui gli LLM dirigono dinamicamente i propri processi e l’utilizzo degli strumenti, mantenendo il controllo sul modo in cui portano a termine i compiti.

Di seguito, esploreremo in dettaglio entrambi i tipi di sistemi agentici. Nell’Appendice 1 (“Agenti in pratica”), descriviamo due domini in cui alcune aziende hanno trovato un valore particolare nell’utilizzo di questi tipi di sistemi.

Quando usare gli agenti e quando non usarli
Quando si creano applicazioni con LLM, consigliamo di trovare la soluzione più semplice possibile e di aumentare la complessità solo quando necessario. Ciò potrebbe significare non creare affatto sistemi agentici. I sistemi agentici spesso barattano latenza e costi per migliori prestazioni delle attività e dovresti considerare quando questo compromesso ha senso.

Quando è giustificata una maggiore complessità, i flussi di lavoro offrono prevedibilità e coerenza per attività ben definite, mentre gli agenti sono l’opzione migliore quando sono necessari flessibilità e processo decisionale basato su modelli su larga scala. Per molte applicazioni, tuttavia, l’ottimizzazione di singole chiamate LLM con recupero ed esempi contestualizzati è solitamente sufficiente.

Quando e come utilizzare i framework
Esistono molti framework che semplificano l’implementazione dei sistemi agenti, tra cui:

• LangGraph di LangChain;
• Framework dell’agente AI di Amazon Bedrock ;
• Rivet, un generatore di flussi di lavoro LLM GUI drag and drop;
• Vellum, un altro strumento GUI per creare e testare flussi di lavoro complessi.

Questi framework migliorano l’avvio semplificando le attività standard di basso livello come la chiamata di LLM, la definizione e l’analisi di strumenti e il concatenamento delle chiamate. Tuttavia, spesso creano livelli di astrazione aggiuntivi che possono oscurare i prompt e le risposte sottostanti, rendendoli più difficili da eseguire il debug. Possono anche rendere allettante l’aggiunta di complessità quando una configurazione più semplice sarebbe sufficiente.

Suggeriamo agli sviluppatori di iniziare a usare direttamente le API LLM: molti pattern possono essere implementati in poche righe di codice. Se usi un framework, assicurati di comprendere il codice sottostante. Le ipotesi errate su cosa c’è sotto il cofano sono una fonte comune di errore dei clienti.

Elementi costitutivi, flussi di lavoro e agenti
In questa sezione esploreremo i pattern comuni per i sistemi agentici che abbiamo visto in produzione. Inizieremo con il nostro elemento costitutivo fondamentale, l’LLM aumentato, e aumenteremo progressivamente la complessità, dai semplici flussi di lavoro compositivi agli agenti autonomi.

Elemento costitutivo: LLM aumentato
Il componente di base dei sistemi agentici è un LLM potenziato con potenziamenti quali recupero, strumenti e memoria. I nostri modelli attuali possono utilizzare attivamente queste capacità, generando le proprie query di ricerca, selezionando strumenti appropriati e determinando quali informazioni conservare.

Consigliamo di concentrarsi su due aspetti chiave dell’implementazione: adattare queste capacità al tuo caso d’uso specifico e garantire che forniscano un’interfaccia semplice e ben documentata per il tuo LLM. Sebbene esistano molti modi per implementare queste integrazioni, un approccio è tramite il nostro Model Context Protocol rilasciato di recente , che consente agli sviluppatori di integrarsi con un ecosistema crescente di strumenti di terze parti con una semplice implementazione client .

Nel resto di questo articolo, daremo per scontato che ogni chiamata LLM abbia accesso a queste funzionalità avanzate.

Flusso di lavoro: concatenamento di prompt
Il concatenamento dei prompt scompone un’attività in una sequenza di passaggi, in cui ogni chiamata LLM elabora l’output di quella precedente. È possibile aggiungere controlli programmatici (vedere “gate” nel diagramma sottostante) su qualsiasi passaggio intermedio per garantire che il processo sia ancora in carreggiata.

Quando usare questo flusso di lavoro: Questo flusso di lavoro è ideale per situazioni in cui l’attività può essere facilmente e pulitamente scomposta in sottoattività fisse. L’obiettivo principale è di bilanciare la latenza con una maggiore accuratezza, rendendo ogni chiamata LLM un’attività più semplice.

Esempi in cui il concatenamento dei prompt è utile:

• Generare testi di marketing e tradurli in un’altra lingua.
• Scrivere lo schema di un documento, verificare che lo schema soddisfi determinati criteri, quindi scrivere il documento sulla base dello schema.

Flusso di lavoro: routing
Il routing classifica un input e lo indirizza a un’attività di follow-up specializzata. Questo flusso di lavoro consente la separazione delle preoccupazioni e la creazione di prompt più specializzati. Senza questo flusso di lavoro, l’ottimizzazione per un tipo di input può danneggiare le prestazioni su altri input.

Quando utilizzare questo flusso di lavoro: il routing funziona bene per attività complesse in cui sono presenti categorie distinte che è meglio gestire separatamente e in cui la classificazione può essere gestita in modo accurato, tramite un LLM o un modello/algoritmo di classificazione più tradizionale.

Esempi in cui il routing è utile:

• Indirizzare diversi tipi di richieste di assistenza clienti (domande generali, richieste di rimborso, supporto tecnico) verso diversi processi, richieste e strumenti a valle.
• Instradamento delle domande semplici/comuni verso modelli più piccoli come Claude 3.5 Haiku e delle domande difficili/insolite verso modelli più completi come Claude 3.5 Sonnet per ottimizzare costi e velocità.

Flusso di lavoro: parallelizzazione
Gli LLM possono talvolta lavorare simultaneamente su un’attività e avere i loro output aggregati a livello di programmazione. Questo flusso di lavoro, parallelizzazione, si manifesta in due varianti chiave:

• Sezionamento : suddivisione di un’attività in sottoattività indipendenti eseguite in parallelo.
• Votazione: eseguire la stessa attività più volte per ottenere risultati diversi.

Quando usare questo flusso di lavoro: la parallelizzazione è efficace quando le sottoattività divise possono essere parallelizzate per velocità o quando sono necessarie più prospettive o tentativi per risultati con maggiore affidabilità. Per attività complesse con più considerazioni, gli LLM in genere funzionano meglio quando ogni considerazione è gestita da una chiamata LLM separata, consentendo un’attenzione focalizzata su ogni aspetto specifico.

Esempi in cui la parallelizzazione è utile:

Sezionamento :

• Implementazione di guardrail in cui un’istanza del modello elabora le query degli utenti mentre un’altra le esamina per contenuti o richieste inappropriati. Questo tende a funzionare meglio rispetto all’avere la stessa chiamata LLM che gestisce sia i guardrail che la risposta principale.
• Automazione delle valutazioni per la valutazione delle prestazioni LLM, in cui ogni chiamata LLM valuta un aspetto diverso delle prestazioni del modello su un determinato prompt.

Votazione :

• Revisione di un pezzo di codice per individuare eventuali vulnerabilità, in cui diversi prompt esaminano e segnalano il codice se rilevano un problema.
• Valutare se un dato contenuto è inappropriato, con più richieste che valutano diversi aspetti o richiedono diverse soglie di voto per bilanciare falsi positivi e falsi negativi.

Flusso di lavoro: orchestrator-workers
Nel flusso di lavoro orchestrator-workers, un LLM centrale suddivide dinamicamente le attività, le delega ai LLM dei workers e ne sintetizza i risultati.

Quando usare questo flusso di lavoro: questo flusso di lavoro è adatto per attività complesse in cui non è possibile prevedere le sottoattività necessarie (nella codifica, ad esempio, il numero di file che devono essere modificati e la natura della modifica in ogni file dipendono probabilmente dall’attività). Sebbene sia topograficamente simile, la differenza fondamentale rispetto alla parallelizzazione è la sua flessibilità: le sottoattività non sono predefinite, ma determinate dall’orchestratore in base all’input specifico.

Esempio in cui orchestrator-workers è utile:

• Prodotti di codifica che apportano ogni volta modifiche complesse a più file.
• Attività di ricerca che implicano la raccolta e l’analisi di informazioni provenienti da più fonti per individuare possibili informazioni rilevanti.

Flusso di lavoro: evaluator-optimizer
Nel flusso di lavoro evaluator-optimizer , una chiamata LLM genera una risposta mentre un’altra fornisce valutazione e feedback in un ciclo.

Quando usare questo flusso di lavoro: questo flusso di lavoro è particolarmente efficace quando abbiamo chiari criteri di valutazione e quando la rifinitura iterativa fornisce un valore misurabile. I due segnali di buona corrispondenza sono, in primo luogo, che le risposte LLM possono essere dimostrabilmente migliorate quando un essere umano articola il proprio feedback; e in secondo luogo, che l’LLM può fornire tale feedback. Ciò è analogo al processo di scrittura iterativa che uno scrittore umano potrebbe seguire quando produce un documento rifinito.

Esempi in cui evaluator-optimizer è utile:

• Traduzione letteraria in cui sono presenti sfumature che il traduttore LLM potrebbe non cogliere inizialmente, ma in cui un valutatore LLM può fornire utili critiche.
• Attività di ricerca complesse che richiedono più cicli di ricerca e analisi per raccogliere informazioni esaustive, durante le quali il valutatore decide se sono necessarie ulteriori ricerche.

Agenti AI
Gli agenti stanno emergendo nella produzione man mano che gli LLM maturano in capacità chiave: comprendere input complessi, impegnarsi nel ragionamento e nella pianificazione, usare gli strumenti in modo affidabile e recuperare dagli errori. Gli agenti iniziano il loro lavoro con un comando da parte dell’utente umano o con una discussione interattiva con lui. Una volta che il compito è chiaro, gli agenti pianificano e operano in modo indipendente, potenzialmente tornando all’uomo per ulteriori informazioni o giudizi. Durante l’esecuzione, è fondamentale per gli agenti ottenere “verità di base” dall’ambiente a ogni passaggio (come i risultati delle chiamate degli strumenti o l’esecuzione del codice) per valutarne i progressi. Gli agenti possono quindi fermarsi per il feedback umano ai checkpoint o quando incontrano dei blocchi. Il compito spesso termina al completamento, ma è anche comune includere condizioni di arresto (come un numero massimo di iterazioni) per mantenere il controllo.

Gli agenti possono gestire attività sofisticate, ma la loro implementazione è spesso semplice. In genere sono solo LLM che utilizzano strumenti basati sul feedback ambientale in un ciclo. È quindi fondamentale progettare set di strumenti e la loro documentazione in modo chiaro e ponderato. Approfondiamo le best practice per lo sviluppo di strumenti nell’Appendice 2 (“Prompt Engineering your Tools”).

Quando usare gli agenti: gli agenti possono essere usati per problemi aperti in cui è difficile o impossibile prevedere il numero di passaggi richiesti e in cui non è possibile codificare un percorso fisso. L’LLM funzionerà potenzialmente per molti turni e devi avere un certo livello di fiducia nel suo processo decisionale. L’autonomia degli agenti li rende ideali per scalare le attività in ambienti affidabili.

La natura autonoma degli agenti comporta costi più elevati e il potenziale per errori composti. Raccomandiamo test approfonditi in ambienti sandbox, insieme alle protezioni appropriate.

Combinare e personalizzare questi modelli
Questi elementi costitutivi non sono prescrittivi. Sono modelli comuni che gli sviluppatori possono modellare e combinare per adattarsi a diversi casi d’uso. La chiave del successo, come per qualsiasi funzionalità LLM, è misurare le prestazioni e iterare sulle implementazioni. Per ripetere: dovresti considerare di aggiungere complessità solo quando ciò migliora in modo dimostrabile i risultati.

Riepilogo
Il successo nello spazio LLM non consiste nel costruire il sistema più sofisticato. Si tratta di costruire il sistema giusto per le tue esigenze. Inizia con semplici prompt, ottimizzali con una valutazione completa e aggiungi sistemi agentici multi-step solo quando le soluzioni più semplici non sono sufficienti.

Quando implementiamo gli agenti, cerchiamo di seguire tre principi fondamentali:

• Mantieni la semplicità nel design del tuo agente.
• Dare priorità alla trasparenza mostrando esplicitamente i passaggi di pianificazione dell’agente.
• Progetta con cura la tua interfaccia agente-computer (ACI) attraverso una documentazione e dei test approfonditi degli strumenti .

I framework possono aiutarti a iniziare rapidamente, ma non esitare a ridurre i livelli di astrazione e a costruire con componenti di base mentre passi alla produzione. Seguendo questi principi, puoi creare agenti che non sono solo potenti, ma anche affidabili, manutenibili e di cui si fidano i loro utenti.

Appendice 1: Agenti nella pratica
Troviamo due applicazioni particolarmente promettenti per gli agenti AI che dimostrano il valore pratico dei pattern discussi sopra. Entrambe le applicazioni illustrano come gli agenti aggiungano il massimo valore per le attività che richiedono sia conversazione che azione, hanno chiari criteri di successo, abilitano cicli di feedback e integrano una supervisione umana significativa.

A. Assistenza clienti
Il supporto clienti combina le interfacce familiari dei chatbot con capacità migliorate tramite l’integrazione degli strumenti. Questa è una scelta naturale per gli agenti più aperti perché:

• Le interazioni di supporto seguono naturalmente il flusso di una conversazione, pur richiedendo l’accesso a informazioni e azioni esterne;
• È possibile integrare strumenti per estrarre dati sui clienti, cronologia degli ordini e articoli della knowledge base;
• Azioni come l’emissione di rimborsi o l’aggiornamento dei biglietti possono essere gestite a livello di programmazione;
• Il successo può essere misurato chiaramente attraverso risoluzioni definite dall’utente.

Diverse aziende hanno dimostrato la fattibilità di questo approccio attraverso modelli di prezzo basati sull’utilizzo, che addebitano solo le risoluzioni positive, dimostrando fiducia nell’efficacia dei propri agenti.

B. Agenti di codifica
Lo spazio di sviluppo software ha mostrato un potenziale notevole per le funzionalità LLM, con capacità che si evolvono dal completamento del codice alla risoluzione autonoma dei problemi. Gli agenti sono particolarmente efficaci perché:

• Le soluzioni del codice sono verificabili tramite test automatizzati;
• Gli agenti possono ripetere le soluzioni utilizzando i risultati dei test come feedback;
• Lo spazio del problema è ben definito e strutturato; e
• La qualità dell’output può essere misurata oggettivamente.

Appendice 2: Progetta rapidamente i tuoi strumenti
Indipendentemente dal sistema agentico che stai costruendo, gli strumenti saranno probabilmente una parte importante del tuo agente. Gli strumenti consentono a Claude di interagire con servizi e API esterni specificandone la struttura e la definizione esatte nella nostra API. Quando Claude risponde, includerà un blocco di utilizzo dello strumento nella risposta API se intende invocare uno strumento. Le definizioni e le specifiche dello strumento dovrebbero ricevere la stessa attenzione di prompt engineering dei tuoi prompt complessivi. In questa breve appendice, descriviamo come prompt engineering dei tuoi strumenti.

Spesso ci sono diversi modi per specificare la stessa azione. Ad esempio, puoi specificare una modifica di file scrivendo un diff o riscrivendo l’intero file. Per un output strutturato, puoi restituire il codice all’interno di markdown o all’interno di JSON. Nell’ingegneria del software, differenze come queste sono cosmetiche e possono essere convertite senza perdita di dati dall’uno all’altro. Tuttavia, alcuni formati sono molto più difficili da scrivere per un LLM rispetto ad altri. Scrivere un diff richiede di sapere quante righe stanno cambiando nell’intestazione del chunk prima che il nuovo codice venga scritto. Scrivere codice all’interno di JSON (rispetto a markdown) richiede un escape extra di nuove righe e virgolette.

I nostri suggerimenti per decidere i formati degli strumenti sono i seguenti:

• Date al modello abbastanza token per “pensare” prima che si metta con le spalle al muro.
• Mantenere il formato il più possibile simile a quello che il modello ha visto ricorrere naturalmente nel testo su Internet.
• Assicuratevi che non ci siano “sovraccarichi” di formattazione, come dover tenere un conteggio accurato di migliaia di righe di codice o dover eseguire l’escape delle stringhe nel codice che scrivete.

Una regola empirica è pensare a quanto impegno viene dedicato alle interfacce uomo-computer (HCI) e pianificare di investire altrettanti sforzi nella creazione di buone interfacce agente -computer (ACI). Ecco alcune idee su come farlo:

• Mettiti nei panni del modello. È ovvio come usare questo strumento, in base alla descrizione e ai parametri, o dovresti pensarci attentamente? Se è così, allora probabilmente è vero anche per il modello. Una buona definizione dello strumento spesso include esempi di utilizzo, casi limite, requisiti del formato di input e chiari confini da altri strumenti.
• Come puoi modificare i nomi o le descrizioni dei parametri per rendere le cose più ovvie? Immagina di scrivere una grande docstring per uno sviluppatore junior del tuo team. Questo è particolarmente importante quando si usano molti strumenti simili.
• Prova il modo in cui il modello utilizza i tuoi strumenti: esegui molti input di esempio nel nostro workbench per vedere quali errori commette il modello e ripeti.
• Usa il Poka-yoke per i tuoi strumenti. Cambia gli argomenti in modo che sia più difficile commettere errori.

(fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura dell’AI Generativa consapevole accompagnando le aziende nella formazione del proprio team. Trovate l’offerta formativa di riferimento sul nostro sito a questo LINK.

INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)