Potenziare gli assistenti intelligenti basati su RAG utilizzando l’estrazione di entità, le query SQL e gli agenti con Amazon Bedrock.

Potenziare gli assistenti intelligenti basati su RAG con l'estrazione di entità, le query SQL e gli agenti con Amazon Bedrock.

La conversational AI ha fatto molti progressi negli ultimi anni grazie allo sviluppo rapido dell’intelligenza artificiale generativa, soprattutto grazie al miglioramento delle performance dei grandi modelli di linguaggio (LLM) introdotte dalle tecniche di formazione come il fine-tuning dell’istruzioni e il reinforcement learning dal feedback umano. Quando vengono sollecitati correttamente, questi modelli possono sostenere conversazioni coerenti senza bisogno di dati di addestramento specifici per compiti. Tuttavia, non riescono a generalizzare bene alle domande specifiche dell’azienda perché, per generare una risposta, si basano sui dati pubblici a cui sono stati esposti durante la fase di pre-training. Questi dati spesso mancano delle conoscenze specializzate contenute nei documenti interni disponibili nelle aziende moderne, che sono tipicamente necessarie per ottenere risposte accurate in settori come la ricerca farmaceutica, l’indagine finanziaria e il supporto clienti.

Per creare assistenti IA in grado di sostenere discussioni basate sulle conoscenze specializzate interne all’azienda, è necessario collegare questi potenti ma generici LLM ad archivi di conoscenza interni che contengono i documenti. Questo metodo di arricchire il contesto di generazione del LLM con informazioni provenienti dalle fonti di dati interne dell’azienda è chiamato Retrieval Augmented Generation (RAG) e produce assistenti specifici per determinati settori e più affidabili, come mostrato in Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Un altro motivo per la popolarità di RAG è la facilità di implementazione e l’esistenza di soluzioni di ricerca di vettori mature, come quelle offerte da Amazon Kendra (vedi Amazon Kendra launches Retrieval API) e Amazon OpenSearch Service (vedi k-Nearest Neighbor (k-NN) search in Amazon OpenSearch Service), tra gli altri.

Tuttavia, il popolare modello di progettazione RAG con ricerca semantica non può rispondere a tutti i tipi di domande possibili sui documenti. Questo è particolarmente vero per le domande che richiedono un ragionamento analitico su più documenti. Ad esempio, immagina di dover pianificare la strategia dell’anno prossimo per una società di investimenti. Un passo essenziale sarebbe analizzare e confrontare i risultati finanziari e i potenziali rischi delle aziende candidate. Questo compito comporta la risoluzione di domande che richiedono ragionamenti analitici. Ad esempio, la query “Dammi le prime 5 aziende con il fatturato più alto degli ultimi 2 anni e identifica i loro principali rischi” richiede più passaggi di ragionamento, alcuni dei quali possono utilizzare la ricerca semantica, mentre altri richiedono capacità analitiche.

In questo post, mostriamo come progettare un assistente documentale intelligente in grado di rispondere a domande di ragionamento analitico e a più passaggi in tre parti. Nella Parte 1, rivediamo il modello di progettazione RAG e le sue limitazioni sulle domande analitiche. Successivamente ti introduciamo a un’architettura più versatile che supera queste limitazioni. Nella Parte 2, approfondiamo la pipeline di estrazione delle entità utilizzata per preparare i dati strutturati, che è un ingrediente chiave per la risposta alle domande analitiche. Nella Parte 3, ti illustreremo come utilizzare gli LLM di Amazon Bedrock per interrogare quei dati e creare un agente LLM che migliora RAG con capacità analitiche, consentendoti di creare assistenti documentali intelligenti in grado di rispondere a complesse domande specifiche del settore su più documenti.

Parte 1: Limitazioni di RAG e panoramica della soluzione

In questa sezione, rivediamo il modello di progettazione RAG e discutiamo delle limitazioni sulle domande analitiche. Presentiamo anche un’architettura più versatile che supera queste limitazioni.

Panoramica di RAG

Le soluzioni RAG sono ispirate all’apprendimento delle rappresentazioni e alle idee di ricerca semantica che sono state gradualmente adottate nei problemi di ranking (ad esempio, raccomandazione e ricerca) e nelle attività di elaborazione del linguaggio naturale (NLP) dal 2010.

L’approccio popolare usato oggi è composto da tre passaggi:

Un lavoro di elaborazione batch offline acquisisce i documenti da una base di conoscenza in ingresso, li suddivide in frammenti, crea una rappresentazione per ogni frammento che rappresenta la sua semantica utilizzando un modello di rappresentazione pre-addestrato, come i modelli di rappresentazione di Amazon Titan, e utilizza queste rappresentazioni come input per creare un indice di ricerca semantica.
Quando viene posta una nuova domanda in tempo reale, la domanda viene convertita in una rappresentazione, che viene utilizzata per cercare ed estrarre i frammenti di documenti più simili utilizzando una metrica di similarità, come la similarità coseno, e un algoritmo di nearest neighbors approssimativo. La precisione della ricerca può essere migliorata anche con un filtraggio dei metadati.
Un prompt viene costruito dalla concatenazione di un messaggio di sistema con un contesto che è costituito dai frammenti di documenti rilevanti estratti nel passaggio 2 e dalla domanda stessa. Questo prompt viene quindi presentato a un modello LLM per generare la risposta finale alla domanda dal contesto.

Con il giusto modello di incorporamento sottostante, in grado di produrre rappresentazioni semantiche accurate dei frammenti del documento di input e delle domande di input, e un modulo di ricerca semantica efficiente, questa soluzione è in grado di rispondere a domande che richiedono il recupero di informazioni esistenti in un database di documenti. Ad esempio, se hai un servizio o un prodotto, potresti iniziare indicizzando la sezione FAQ o la documentazione ad esso associata e avere un’intelligenza artificiale conversazionale iniziale personalizzata sulla base della tua offerta specifica.

Limitazioni del RAG basato sulla ricerca semantica

Anche se il RAG è un componente essenziale negli assistenti AI specifici del dominio moderni e un punto di partenza sensibile per la costruzione di un’IA conversazionale basata su una base di conoscenza specializzata, non può rispondere a domande che richiedono di scansionare, confrontare e ragionare su tutti i documenti nella tua base di conoscenza contemporaneamente, soprattutto quando l’aumento è basato esclusivamente sulla ricerca semantica.

Per comprendere queste limitazioni, consideriamo nuovamente l’esempio relativo alla decisione su dove investire sulla base dei report finanziari. Se dovessimo utilizzare il RAG per interagire con questi report, potremmo fare domande come “Quali sono i rischi affrontati dall’azienda X nel 2022” o “Qual è il reddito netto dell’azienda Y nel 2022?” Per ciascuna di queste domande, il vettore di incorporamento corrispondente, che codifica il significato semantico della domanda, viene utilizzato per recuperare i frammenti di documenti K più simili semanticamente disponibili nell’indice di ricerca. Questo viene tipicamente realizzato mediante l’impiego di una soluzione di vicini più prossimi approssimata come FAISS, NMSLIB, pgvector o altri, che cercano di trovare un equilibrio tra velocità di recupero e richiamo per ottenere prestazioni in tempo reale mantenendo un’accuratezza soddisfacente.

Tuttavia, l’approccio precedente non può rispondere in modo accurato a domande analitiche su tutti i documenti, come “Quali sono le prime 5 aziende con il maggior reddito netto nel 2022?”

Ciò è dovuto al fatto che la ricerca semantica tenta di trovare i K frammenti di documenti più simili alla domanda di input. Tuttavia, poiché nessuno dei documenti contiene riepiloghi completi dei ricavi, verranno restituiti frammenti di documenti che contengono semplicemente menzioni di “reddito netto” e eventualmente “2022”, senza soddisfare la condizione essenziale di focalizzarsi sulle aziende con il maggior reddito. Se presentiamo questi risultati di recupero a un modello di linguaggio generativo come contesto per rispondere alla domanda di input, potrebbe formulare una risposta fuorviante o rifiutarsi di rispondere perché manca l’informazione corretta necessaria.

Queste limitazioni sono dovute alla progettazione perché la ricerca semantica non effettua una scansione accurata di tutti i vettori di incorporamento per trovare documenti rilevanti. Invece, utilizza metodi approssimati di vicini più prossimi per mantenere una velocità di recupero ragionevole. Una strategia chiave per l’efficienza in questi metodi è la suddivisione dello spazio di incorporamento in gruppi durante l’indicizzazione. Ciò consente di identificare rapidamente quali gruppi possono contenere incorporamenti rilevanti durante il recupero, senza la necessità di confronti a due a due. Inoltre, anche le tecniche tradizionali di vicini più prossimi come KNN, che scansionano tutti i documenti, calcolano solo metriche di distanza di base e non sono adatte per i confronti complessi necessari per il ragionamento analitico. Pertanto, il RAG con ricerca semantica non è adatto a rispondere a domande che comportano ragionamento analitico su tutti i documenti.

Per superare queste limitazioni, proponiamo una soluzione che combina il RAG con metadati ed estrazione di entità, interrogazione SQL e agenti LLM, come descritto nelle sezioni seguenti.

Superare le limitazioni del RAG con metadati, SQL e agenti LLM

Esaminiamo più approfonditamente una domanda in cui il RAG fallisce, in modo da poter risalire al ragionamento necessario per rispondere in modo efficace. Questa analisi dovrebbe indicarci l’approccio corretto che potrebbe integrare il RAG nella soluzione complessiva.

Consideriamo la domanda: “Quali sono le prime 5 aziende con il maggior reddito nel 2022?”

Per poter rispondere a questa domanda, dovremmo:

Identificare il reddito per ogni azienda.
Filtrare per mantenere i ricavi del 2022 per ciascuna di esse.
Ordinare i ricavi in ordine decrescente.
Estrarre i primi 5 ricavi insieme ai nomi delle aziende.

Tipicamente, queste operazioni analitiche vengono eseguite su dati strutturati, utilizzando strumenti come pandas o motori SQL. Se avessimo accesso a una tabella SQL contenente le colonne azienda, reddito e anno, potremmo facilmente rispondere alla nostra domanda eseguendo una query SQL simile all’esempio seguente:

SELECT azienda, reddito FROM nome_tabella WHERE anno = 2022 ORDER BY reddito DESC LIMIT 5;

Memorizzare metadati strutturati in una tabella SQL che contiene informazioni sulle entità rilevanti consente di rispondere a molti tipi di domande analitiche scrivendo la query SQL corretta. Ecco perché completiamo il RAG nella nostra soluzione con un modulo di interrogazione SQL in tempo reale su una tabella SQL, popolata da metadati estratti in un processo offline.

Ma come possiamo implementare e integrare questo approccio in un’intelligenza artificiale conversazionale basata su LLM?

Ci sono tre passaggi per poter aggiungere un ragionamento analitico SQL:

Estrazione dei metadati – Estrarre i metadati dai documenti non strutturati in una tabella SQL
Testo in SQL – Formulare query SQL da domande di input in modo accurato utilizzando un LLM
Selezione degli strumenti – Identificare se una domanda deve essere risposta utilizzando RAG o una query SQL

Per implementare questi passaggi, prima riconosciamo che l’estrazione delle informazioni dai documenti non strutturati è un compito tradizionale di NLP per il quale i LLM mostrano il potenziale per raggiungere alta precisione attraverso l’apprendimento zero-shot o few-shot. In secondo luogo, la capacità di questi modelli di generare query SQL da linguaggio naturale è stata dimostrata da anni, come visto nella versione del 2020 di Amazon QuickSight Q. Infine, la selezione automatica dello strumento giusto per una domanda specifica migliora l’esperienza dell’utente e consente di rispondere a domande complesse attraverso un ragionamento a più passi. Per implementare questa funzionalità, approfondiamo gli agenti LLM in una sezione successiva.

In sintesi, la soluzione che proponiamo è composta dai seguenti componenti principali:

Ricerca semantica per arricchire il contesto di generazione
Estrazione strutturata dei metadati e interrogazione con SQL
Un agente in grado di utilizzare gli strumenti giusti per rispondere a una domanda

Panoramica della soluzione

Il diagramma seguente rappresenta un’architettura semplificata della soluzione. Ti aiuta a identificare e comprendere il ruolo dei componenti principali e come interagiscono per implementare l’intera funzionalità dell’assistente LLM. La numerazione segue l’ordine delle operazioni durante l’implementazione di questa soluzione.

Nella pratica, abbiamo implementato questa soluzione come descritto nell’architettura dettagliata seguente.

Per questa architettura, proponiamo un’implementazione su GitHub, con componenti debolmente accoppiati in cui il backend (5), le pipeline di dati (1, 2, 3) e il frontend (4) possono evolvere separatamente. Questo per semplificare la collaborazione tra competenze durante la personalizzazione e il miglioramento della soluzione per la produzione.

Deploy della soluzione

Per installare questa soluzione nel tuo account AWS, completa i seguenti passaggi:

Clona il repository su GitHub.
Installa il backend AWS Cloud Development Kit (AWS CDK) app:
1. Apri la cartella backend.
2. Esegui npm install per installare le dipendenze.
3. Se non hai mai usato l’AWS CDK nell’account e nella regione corrente, esegui il bootstrapping con npx cdk bootstrap.
4. Esegui npx cdk deploy per distribuire lo stack.
Opzionalmente, esegui l’streamlit-ui come segue:
1. Raccomandiamo di clonare questo repository in un ambiente Amazon SageMaker Studio. Per ulteriori informazioni, consulta Onboard to Amazon SageMaker Domain using Quick setup.
2. All’interno della cartella frontend/streamlit-ui, esegui bash run-streamlit-ui.sh.
3. Scegli il link con il seguente formato per aprire la demo: https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/.
Infine, puoi eseguire il pipeline di Amazon SageMaker definito nel notebook data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb per elaborare i documenti in formato PDF di input e preparare la tabella SQL e l’indice di ricerca semantica utilizzati dall’assistente LLM.

Nel resto di questo post, ci concentriamo sull’illustrazione dei componenti più importanti e delle scelte di design, per ispirarti nella progettazione del tuo assistente AI su una base di conoscenza interna. Assumiamo che i componenti 1 e 4 siano facili da capire, e ci focalizziamo sui componenti principali 2, 3 e 5.

Parte 2: Pipeline di estrazione delle entità

In questa sezione, approfondiamo la pipeline di estrazione delle entità utilizzata per preparare dati strutturati, che sono un elemento chiave per la risposta alle domande analitiche.

Estrazione del testo

I documenti sono tipicamente memorizzati nel formato PDF o come immagini acquisite. Possono essere costituiti da layout di paragrafi semplici o tabelle complesse e possono contenere testo digitale o scritto a mano. Per estrarre correttamente le informazioni, dobbiamo trasformare questi documenti grezzi in testo normale, preservando la loro struttura originale. Puoi utilizzare Amazon Textract, un servizio di apprendimento automatico (ML) che fornisce API mature per l’estrazione di testo, tabelle e moduli da input digitali e scritti a mano.

Nel componente 2, estraiamo testo e tabelle come segue:

Per ogni documento, chiamiamo Amazon Textract per estrarre il testo e le tabelle.
Utilizziamo lo script Python seguente per ricreare le tabelle come pandas DataFrames. Python script.
Consolidiamo i risultati in un singolo documento e inseriamo le tabelle come markdown.

Questo processo è illustrato dal diagramma di flusso seguente e dimostrato concretamente in notebooks/03-pdf-document-processing.ipynb.

Estrazione delle entità e interrogazione utilizzando LLM

Per rispondere in modo efficace alle domande analitiche, è necessario estrarre metadati ed entità rilevanti dalla base di conoscenza del documento in un formato dati strutturato accessibile. Suggeriamo di utilizzare SQL per archiviare queste informazioni e recuperare risposte grazie alla sua popolarità, facilità d’uso e scalabilità. Questa scelta beneficia anche dalla capacità dei modelli linguistici provati di generare query SQL da linguaggio naturale.

In questa sezione, approfondiamo i seguenti componenti che consentono domande analitiche:

Un processo batch che estrae dati strutturati da dati non strutturati utilizzando LLM.
Un modulo in tempo reale che converte domande in linguaggio naturale in query SQL e recupera risultati da un database SQL.

Puoi estrarre i metadati rilevanti per supportare domande analitiche come segue:

Definisci uno schema JSON per le informazioni che devi estrarre, che contiene una descrizione di ogni campo e il suo tipo di dati e include esempi dei valori attesi.
Per ogni documento, richiedi a un LLM lo schema JSON e chiedi di estrarre con precisione i dati rilevanti.
Quando la lunghezza del documento è superiore alla lunghezza del contesto e per ridurre il costo di estrazione con LLM, puoi utilizzare la ricerca semantica per recuperare e presentare i frammenti di documenti rilevanti all’LLM durante l’estrazione.
Analizza l’output JSON e convalida l’estrazione LLM.
Opzionalmente, esegui il backup dei risultati su Amazon S3 come file CSV.
Carica nel database SQL per interrogazioni successive.

Questo processo è gestito dall’architettura seguente, in cui i documenti in formato testo vengono caricati con uno script Python che viene eseguito in un lavoro di Elaborazione di Amazon SageMaker per eseguire l’estrazione.

Per ogni gruppo di entità, costruiamo dinamicamente una richiesta che include una chiara descrizione del compito di estrazione delle informazioni e include uno schema JSON che definisce l’output atteso e include i frammenti di documento rilevanti come contesto. Aggiungiamo anche alcuni esempi di input e output corretto per migliorare le prestazioni di estrazione con apprendimento a pochi esempi. Questo è dimostrato in notebooks/05-entities-extraction-to-structured-metadata.ipynb.

Parte 3: Costruire un assistente documentale diligente con Amazon Bedrock

In questa sezione, dimostriamo come utilizzare gli LLM di Amazon Bedrock per interrogare i dati e costruire un agente LLM che potenzi RAG con capacità analitiche, consentendo di creare assistenti documentali intelligenti in grado di rispondere a domande complesse specifiche del dominio su più documenti. Si può fare riferimento alla funzione Lambda su GitHub per l’implementazione concreta dell’agente e degli strumenti descritti in questa parte.

Formulare query SQL e rispondere a domande analitiche

Ora che abbiamo un archivio di metadati strutturato con le entità rilevanti estratte e caricate in un database SQL che possiamo interrogare, la domanda che rimane è come generare la giusta query SQL dalle domande in linguaggio naturale di input?

Gli LLM moderni sono bravi a generare SQL. Ad esempio, se richiedi all’LLM Anthropic Claude tramite Amazon Bedrock di generare una query SQL, vedrai risposte plausibili. Tuttavia, è necessario attenersi a alcune regole quando si scrive il prompt per ottenere query SQL più accurate. Queste regole sono particolarmente importanti per le query complesse al fine di ridurrei errori di allucinazione e di sintassi:

Descrivere accuratamente il compito all’interno del prompt
Includere lo schema delle tabelle SQL all’interno del prompt, descrivendo ogni colonna della tabella e specificandone il tipo di dati
Dire esplicitamente all’LLM di utilizzare solo nomi di colonne esistenti e tipi di dati
Aggiungere alcune righe delle tabelle SQL

Puoi anche postprocessare la query SQL generata utilizzando un linter come sqlfluff per correggere la formattazione, o un parser come sqlglot per rilevare errori di sintassi e ottimizzare la query. Inoltre, se le prestazioni non soddisfano i requisiti, è possibile fornire alcuni esempi all’interno del prompt per guidare il modello con il few-shot learning verso la generazione di query SQL più accurate.

Da un punto di vista implementativo, utilizziamo una funzione AWS Lambda per orchestrare il seguente processo:

Chiamare un modello Anthropic Claude in Amazon Bedrock con la domanda in input per ottenere la query SQL corrispondente. Qui, utilizziamo la classe SQLDatabase di LangChain per aggiungere descrizioni dello schema delle tabelle SQL pertinenti e utilizzamo un prompt personalizzato.
Analizzare, convalidare ed eseguire la query SQL sul database Amazon Aurora compatibile con PostgreSQL.

L’architettura di questa parte della soluzione è evidenziata nel seguente diagramma.

Considerazioni di sicurezza per prevenire gli attacchi di SQL injection

Quando abilitiamo l’assistente AI ad interrogare un database SQL, dobbiamo assicurarci che ciò non introduca vulnerabilità di sicurezza. Per fare ciò, proponiamo le seguenti misure di sicurezza per prevenire gli attacchi di SQL injection:

Applicare le autorizzazioni IAM con privilegi minimi – Limitare i privilegi della funzione Lambda che esegue le query SQL utilizzando una policy IAM (Identity and Access Management) e un ruolo che seguono il principio del privilegio minimo. In questo caso, concediamo solo accesso in modalità lettura.
Limitare l’accesso ai dati – Fornire solo l’accesso al minimo indispensabile di tabelle e colonne per prevenire attacchi di divulgazione di informazioni.
Aggiungere uno strato di moderazione – Introdurre uno strato di moderazione che rileva i tentativi di iniezione di prompt in fase iniziale e impedisce loro di propagarsi al resto del sistema. Può assumere la forma di filtri basati su regole, confronto di similarità con un database di esempi noti di iniezioni di prompt o un classificatore di machine learning.

Ricerca semantica per potenziare il contesto di generazione

La soluzione che proponiamo utilizza RAG con la ricerca semantica nel componente 3. È possibile implementare questo modulo utilizzando knowledge base per Amazon Bedrock. Inoltre, ci sono diverse altre opzioni per implementare RAG, come ad esempio l’API di recupero di Amazon Kendra, il database vettoriale Amazon OpenSearch e Amazon Aurora PostgreSQL con pgvector, tra gli altri. Il pacchetto open source aws-genai-llm-chatbot mostra come utilizzare molte di queste opzioni di ricerca vettoriale per implementare un chatbot alimentato da LLM.

In questa soluzione, poiché abbiamo bisogno sia di interrogazioni SQL che di ricerca vettoriale, abbiamo deciso di utilizzare Amazon Aurora PostgreSQL con l’estensione pgvector, che supporta entrambe le funzionalità. Pertanto, implementiamo il componente RAG di ricerca semantica con l’architettura seguente.

Il processo di risposta alle domande utilizzando l’architettura precedente viene effettuato in due fasi principali.

Innanzitutto, un processo batch offline, eseguito come lavoro di elaborazione SageMaker, crea l’indice di ricerca semantica come segue:

O periodicamente, o al ricevimento di nuovi documenti, viene eseguito un lavoro SageMaker.
Vengono caricati i documenti di testo da Amazon S3 e suddivisi in chunk sovrapposti.
Per ogni chunk, viene utilizzato un modello di inserimento di Amazon Titan per generare un vettore di inserimento.
Viene utilizzata la classe PGVector di LangChain per acquisire i vettori di inserimento, con i loro chunk di documenti e metadati, in Amazon Aurora PostgreSQL e creare un indice di ricerca semantica su tutti i vettori di inserimento.

In secondo luogo, in tempo reale e per ciascuna nuova domanda, costruiamo una risposta nel seguente modo:

La domanda viene ricevuta dall’orchestratore che viene eseguito su una funzione Lambda.
L’orchestratore inserisce la domanda con lo stesso modello di inserimento.
Recupera i chunk di documenti più rilevanti (top-K) dall’indice di ricerca semantica PostgreSQL. Facoltativamente, utilizza il filtraggio dei metadati per migliorare la precisione.
Questi chunk vengono inseriti dinamicamente in un prompt LLM insieme alla domanda di input.
Il prompt viene presentato ad Anthropic Claude su Amazon Bedrock, per istruirlo a rispondere alla domanda di input sulla base del contesto disponibile.
Infine, la risposta generata viene inviata all’orchestratore.

Un agente capace di utilizzare strumenti per ragionare e agire

Fino ad ora in questo post, abbiamo discusso del trattamento separato delle domande che richiedono sia RAG che ragionamento analitico. Tuttavia, molte domande del mondo reale richiedono entrambe le capacità, a volte in più passaggi di ragionamento, al fine di arrivare a una risposta finale. Per supportare queste domande più complesse, dobbiamo introdurre il concetto di un agente.

Gli agenti LLM, come gli agenti per Amazon Bedrock, sono emersi di recente come una soluzione promettente in grado di utilizzare gli LLM per ragionare e adattarsi utilizzando il contesto attuale e per scegliere azioni appropriate da un elenco di opzioni, il che rappresenta un quadro generale di risoluzione dei problemi. Come discusso in Agenti autonomi basati su LLM, ci sono diverse strategie di prompting e pattern di progettazione per gli agenti LLM che supportano un ragionamento complesso.

Uno di questi pattern di progettazione è Reason and Act (ReAct), introdotto in ReAct: Synergizing Reasoning and Acting in Language Models. In ReAct, l’agente prende in input un obiettivo che può essere una domanda, identifica le informazioni mancanti per rispondere ad essa e propone in modo iterativo lo strumento giusto per raccogliere informazioni in base alle descrizioni degli strumenti disponibili. Dopo aver ricevuto la risposta da uno strumento specifico, l’LLM valuta nuovamente se ha tutte le informazioni necessarie per rispondere completamente alla domanda. Se non è così, effettua un altro passaggio di ragionamento e utilizza lo stesso o un altro strumento per raccogliere ulteriori informazioni, fino a quando una risposta finale non è pronta o viene raggiunto un limite.

Il seguente diagramma a sequenza spiega come funziona un agente ReAct per rispondere alla domanda “Dammi le prime 5 aziende con il maggior fatturato degli ultimi 2 anni e identifica i rischi associati alla prima”.

I dettagli dell’implementazione di questo approccio in Python sono descritti in Custom LLM Agent. Nella nostra soluzione, l’agente e gli strumenti sono implementati con l’architettura parziale evidenziata di seguito.

Per rispondere a una domanda di input, utilizziamo i servizi AWS come segue:

Un utente inserisce la domanda attraverso un’interfaccia utente, che chiama un’API su Amazon API Gateway.
API Gateway invia la domanda a una funzione Lambda che implementa l’esecutore dell’agente.
L’agente chiama LLM con un prompt che contiene una descrizione degli strumenti disponibili, il formato di istruzione ReAct e la domanda di input, quindi analizza l’azione successiva da completare.
L’azione contiene quale strumento chiamare e qual è l’input dell’azione.
Se lo strumento da usare è SQL, l’esecutore dell’agente chiama SQLQA per convertire la domanda in SQL ed eseguirla. Quindi aggiunge il risultato al prompt e chiama nuovamente LLM per vedere se può rispondere alla domanda originale o se sono necessarie ulteriori azioni.
Allo stesso modo, se lo strumento da usare è la ricerca semantica, quindi l’input dell’azione viene analizzato e utilizzato per recuperare dall’indice di ricerca semantica di PostgreSQL. Aggiunge i risultati al prompt e controlla se LLM è in grado di rispondere o ha bisogno di un’altra azione.
Dopo che tutte le informazioni per rispondere a una domanda sono disponibili, l’agente LLM formula una risposta finale e la invia all’utente.

Puoi estendere l’agente con ulteriori strumenti. Nell’implementazione disponibile su GitHub, dimostriamo come puoi aggiungere un motore di ricerca e una calcolatrice come strumenti extra al motore SQL e agli strumenti di ricerca semantica sopra citati. Per memorizzare la cronologia della conversazione in corso, utilizziamo una tabella Amazon DynamoDB.

Dalla nostra esperienza finora, abbiamo visto che i seguenti sono elementi chiave per un agente di successo:

LLM sottostante in grado di ragionare con il formato ReAct
Una descrizione chiara degli strumenti disponibili, quando usarli e una descrizione dei loro argomenti di input con, eventualmente, un esempio di input e output attesi
Un’outline chiara del formato ReAct che LLM deve seguire
Gli strumenti giusti per risolvere la domanda aziendale resi disponibili all’agente LLM
Analisi corretta delle risposte degli agenti LLM in quanto ragionano

Per ottimizzare i costi, consigliamo di memorizzare nella cache le domande più comuni con le relative risposte e aggiornare questa cache periodicamente per ridurre le chiamate al LLM sottostante. Ad esempio, puoi creare un indice di ricerca semantica con le domande più comuni come spiegato in precedenza e confrontare la nuova domanda dell’utente con l’indice prima di chiamare il LLM. Per esplorare altre opzioni di caching, fare riferimento alle integrazioni di caching LLM.

Supporto ad altri formati come video, immagini, audio e file 3D

Puoi applicare la stessa soluzione a vari tipi di informazioni, come immagini, video, audio e file di progettazione 3D come file CAD o mesh. Ciò comporta l’utilizzo di tecniche di apprendimento automatico consolidate per descrivere il contenuto del file in testo, che può quindi essere inglobato nella soluzione esplorata in precedenza. Questo approccio consente di svolgere conversazioni di Q&A su questi diversi tipi di dati. Ad esempio, puoi ampliare il tuo database di documenti creando descrizioni testuali di immagini, video o contenuti audio. Puoi anche migliorare la tabella dei metadati identificando proprietà attraverso la classificazione o il rilevamento degli oggetti all’interno di questi formati. Dopo che questi dati estratti vengono indicizzati nel negozio di metadati o nell’indice di ricerca semantica per i documenti, l’architettura complessiva del sistema proposto rimane largamente coerente.

Conclusion

In questo post abbiamo mostrato come l’utilizzo di LLM con il pattern di progettazione RAG sia necessario per la creazione di un assistente AI specifico per un determinato dominio, ma non sia sufficiente per raggiungere il livello di affidabilità richiesto per generare valore commerciale. Per questo motivo, abbiamo proposto di estendere il popolare pattern di progettazione RAG con i concetti di agenti e strumenti, dove la flessibilità degli strumenti ci consente di utilizzare sia tecniche tradizionali di NLP che le moderne capacità di LLM per consentire a un assistente AI di avere più opzioni per cercare informazioni e assistere gli utenti nella risoluzione efficiente dei problemi aziendali.

La soluzione dimostra il processo di progettazione verso un assistente LLM in grado di rispondere a vari tipi di domande di recupero, ragionamento analitico e ragionamento multi-step su tutte le basi di conoscenza. Abbiamo anche sottolineato l’importanza di pensare all’indietro dai tipi di domande e compiti che ci si aspetta che il vostro assistente LLM aiuti gli utenti. In questo caso, il percorso di progettazione ci ha portato a un’architettura con tre componenti: ricerca semantica, estrazione di metadati e interrogazione SQL, agente LLM e strumenti, che riteniamo siano sufficientemente generici e flessibili per molteplici casi d’uso. Crediamo anche che, prendendo ispirazione da questa soluzione e approfondendo le esigenze dei vostri utenti, sarete in grado di estendere ulteriormente questa soluzione verso ciò che funziona meglio per voi.

Amazon Bedrock,Amazon SageMaker,Amazon Textract,Generative AI,Technical How-to

Come Q4 Inc. ha utilizzato Amazon Bedrock, RAG e SQLDatabaseChain per affrontare le sfide dei dati numerici e strutturati nella creazione del loro chatbot Q&A

Il Pixel 8 Pro, il primo smartphone con intelligenza artificiale integrata, ora è dotato di Gemini Nano, e ci sono in arrivo ulteriori aggiornamenti di intelligenza artificiale per la gamma di Pixel.