Implementazione di Agentic RAG usando Claude 3.5 Sonnet, LlamaIndex e Milvus
Man mano che i sistemi di IA continuano a evolversi rapidamente, affidarsi esclusivamente ai large language models (LLM) non è più sufficiente per soddisfare le diverse esigenze delle industrie di oggi. Queste sfide crescenti richiedono lo sviluppo di architetture più complesse in grado di risolvere i problemi in modo più efficiente ed efficace.
All’Unstructured Data Meetup ospitato da Zilliz, Bill Zhang, Director of Engineering presso Zilliz, ha introdotto il concetto di Compound AI Systems, presentato nel blog Berkeley AI Research (BAIR). Questo approccio modulare integra più componenti per gestire varie attività invece di affidarsi a un singolo modello di IA, offrendo risultati più personalizzati ed efficienti. Puoi guardare la presentazione di Bill sul canale Zilliz YouTube.
In questo blog, riepilogheremo i punti chiave di Bill, inclusa l’evoluzione delle architetture delle app LLM, i concetti di Retrieval Augmented Generation (RAG) e Agentic RAG, e le loro sfide e benefici. Ti guideremo anche nella creazione di un Agentic RAG usando Claude 3.4 Sonnet, LlamaIndex e il database vettoriale Milvus.
Lo sviluppo dell’architettura delle applicazioni LLM
Gli LLM fanno parte del panorama dell’IA da oltre un decennio, ma l’emergere di foundation models disponibili pubblicamente, in particolare ChatGPT di OpenAI, negli ultimi tre anni ha accelerato significativamente lo sviluppo delle applicazioni LLM, favorendone la rapida espansione. All’Unstructured Data Meetup, Bill ha riassunto i componenti chiave delle attuali architetture di IA e il loro sviluppo.
Figura 1- Evoluzione del sistema LLM .png
Figura 1: Evoluzione del sistema LLM
Affidarsi esclusivamente alla conoscenza pre-addestrata degli LLM
Il modo più semplice per usare un LLM è fare affidamento sulla sua conoscenza “propria” per rispondere alla tua query. Tuttavia, questo metodo ha una limitazione: gli LLM non possono coprire tutti gli argomenti o casi d’uso, il che può portare a risposte inaccurate o “allucinate”. Un modo per affrontare questo problema è usare più LLM, ciascuno adattato a diversi tipi di domande, ma questo metodo renderebbe il sistema eccessivamente complesso e difficile da scalare.
Compound AI systems: aggiungere componenti extra alla tua pipeline LLM
Quindi, come possiamo risolvere questo problema? La soluzione risiede nei Compound AI systems. Aggiungere componenti extra alla pipeline LLM può migliorare le prestazioni del sistema. Un esempio comune è la Retrieval Augmented Generation (RAG). La RAG introduce una "knowledge base" o un "contesto," tipicamente archiviato in un database vettoriale come Milvus o Zilliz Cloud (il Milvus gestito), dove informazioni specifiche vengono salvate per ricerche di similarità. Puoi accedere a informazioni personalizzate per il tuo caso d’uso inserendo la tua conoscenza nel sistema RAG. La RAG sfrutta la potenza dell’LLM combinata con un prompt su misura composto dalla query dell’utente e dal contesto recuperato dal database vettoriale, producendo risposte più accurate e pertinenti.
Agenti
Quindi, dobbiamo implementare più moduli? Dipende dal caso d'uso specifico. Tuttavia, come gli LLM, anche RAG ha dei limiti, poiché si basa sul modello specifico. Per esempio, cosa succede se la tua query implica l'esecuzione di un'attività di confronto, ma il tuo modello è stato addestrato per la sintesi? Come si possono gestire efficacemente diversi tipi di domande? È qui che entra in pratica un modulo aggiuntivo: Agents. Gli agenti AI sono sistemi complessi che aggiungono passaggi “simili a quelli umani” nella pipeline, come il ragionamento, gli strumenti utilizzati o la pianificazione. Approfondiamo prima le basi di RAG per comprendere i vantaggi degli agenti.
Retrieval Augmented Generation (RAG)
Come menzionato sopra, i sistemi RAG migliorano l'output degli LLM incorporando un database vettoriale come base di conoscenza. I passaggi di base per costruire un sistema RAG possono essere riassunti come segue:
Chunking: Suddividere i documenti in parti più piccole per migliorare la pertinenza del contenuto recuperato dal database vettoriale usando la ricerca semantica, una caratteristica fondamentale dei database vettoriali come Zilliz Cloud e Milvus.
Embedding: Vettorializzare (creare rappresentazioni numeriche di) i chunk che verranno ingeriti nel database vettoriale.
Prompt: Istruzioni fornite all'LLM per cercare nel database vettoriale in base alla query al fine di ottenere la risposta
Query: La domanda fornita all'LLM
Questi passaggi si basano principalmente sulla similarità. Il modello cerca i chunk più simili nel database e genera la risposta più accurata sulla base di ciò.
Figura 2- Passaggi di base di RAG .png
Figura 2: Passaggi di base di RAG
Tuttavia, una ricerca di similarità semantica non è una soluzione magica. Anche la risposta risultante sarà insufficiente se i chunk più simili non sono abbastanza accurati. Bill ha esplorato alcune delle debolezze dei sistemi RAG, in particolare nei casi d'uso in cui gli LLM potrebbero non funzionare in modo ottimale, inclusi sintesi, confronto e domande in più parti.
Tuttavia, il problema di RAG, ovvero la sua mancanza di capacità di ragionamento e l'incapacità di recuperare accuratamente i documenti richiesti, può essere affrontato efficacemente con l'introduzione degli Agents. Queste entità svolgono un ruolo cruciale nell'intero processo, offrendo una potenziale soluzione alle sfide poste da RAG.
Agentic RAG
Ora che comprendiamo i limiti degli LLM e di RAG, possiamo esplorare più a fondo i vantaggi degli agenti. Nel diagramma seguente, gli agenti LLM contengono diversi componenti che interagiscono tra loro in un processo iterativo. Ora non si tratta solo di similarità, ma anche di pianificazione, ragionamento, uso di strumenti e memorizzazione.
Figura 3- Agenti LLM .png
Figura 3: Agenti LLM
Sebbene esistano diverse architetture e framework agentici, uno dei più popolari è ReAct (Reasoning/Acting). ReAct prevede diversi passaggi: pianificazione/ragionamento, azione (uso di strumenti), osservazione/valutazione e generazione della risposta. Bill ha evidenziato questi passaggi come parte di un processo iterativo.
Nella fase di osservazione/valutazione, se il modello non trova la risposta, continuerà a cercare alternative tornando alla fase di ragionamento o persino richiedendo un prompt aggiuntivo all'utente.
Figura 4- Framework ReAct.png
Figura 4: Framework ReAct (Fonte)
Quindi, come possiamo usare questi agenti in una pipeline RAG? Il bello è che possono essere implementati in tutti i passaggi della pipeline, che si tratti di routing/pianificazione nella pipeline RAG a valle o di chiamata di strumenti. Anche la knowledge base può essere considerata uno strumento o un framework ReAct.
Figure 5- How An Agentic RAG works .png
Figura 5: Come funziona un Agentic RAG
Durante il talk, Bill ha spiegato cinque possibili implementazioni agentiche all’interno di una pipeline RAG:
Routing: La query dell’utente viene reindirizzata a una knowledge base specifica pertinente alla query.
- Esempio: Se l’utente chiede raccomandazioni per tipi specifici di libri, la query può essere instradata alla knowledge base, che contiene informazioni su quei tipi di libri.
Query Planning: La query viene suddivisa in sotto-query, con ciascuna sotto-query indirizzata alla pipeline RAG pertinente.
- Esempio: Se vuoi conoscere i risultati finanziari di un’azienda negli ultimi tre anni, l’agente crea sotto-query per ciascun anno e indirizza ciascuna alla knowledge base appropriata.
Tool Use: Un LLM interagisce con un’API esterna o uno strumento, determinando i parametri necessari per l’interazione.
- Esempio: Se un utente richiede le previsioni del tempo, l’LLM chiama un’API meteo, determina parametri come località e data, ed elabora la risposta dell’API per fornire la risposta.
ReAct: Un processo iterativo che incorpora ragionamento e azione, inclusi passaggi di pianificazione, uso di strumenti e osservazione.
- Esempio: Per generare un itinerario di viaggio dettagliato, il sistema ragiona sulle esigenze dell’utente, utilizza API per raccogliere informazioni su attrazioni, ristorazione e alloggio, osserva i risultati per verificarne accuratezza e pertinenza, quindi fornisce un piano di viaggio completo.
Dynamic Query Planning: L’agente esegue più attività o sotto-query in parallelo anziché in sequenza e aggrega i risultati
Esempio: Se vuoi confrontare i risultati finanziari di due aziende e calcolare la differenza in una metrica specifica, l’agente elabora i dati per entrambe le aziende in parallelo e poi combina i risultati per fornire il confronto. LLMCompiler è un esempio di framework che consente un’orchestrazione efficiente ed efficace delle chiamate di funzione parallele.
Figure 6- LLM Compiler.png
Figura 6: LLM Compiler (Fonte)
Quindi, gli agenti aggiungono un livello aggiuntivo alla pipeline RAG, potenziando e migliorando l’efficienza complessiva del processo. Tuttavia, proprio come gli LLM e RAG come sistemi autonomi, anche gli agenti presentano alcune sfide, come il controllo dei loro passaggi interni e la loro personalizzazione per ottenere i migliori risultati per casi d’uso specifici.
Mostriamo ora una semplice pipeline agentica usando il database vettoriale Milvus.
RAG agentico usando Claude 3.5 Sonnet, LlamaIndex e Milvus
Il seguente notebook è un esempio di pipeline Agentic RAG costruita con LlamaIndex come framework agentico, Milvus come database vettoriale e Claude 3.5 Sonnet come LLM. In questa sezione, ti guiderò nella costruzione di questo RAG agentico.
Puoi anche consultare il codice completo in questo notebook.
Passaggio 1: Caricamento dei dati
Usiamo le pagine FAQ della Documentazione Milvus 2.4.x come conoscenza privata nel nostro RAG, che è una buona fonte di dati per una semplice pipeline RAG.
!pip install -qq llama-index pymilvus llama-index-vector-stores-milvus llama-index-llms-anthropic
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q /content/milvus_docs_2.4.x_en.zip -d /content/milvus_docs
from llama_index.core import SimpleDirectoryReader
# load documents
documents = SimpleDirectoryReader(
input_files=["/content/milvus_docs/en/faq/operational_faq.md"]
).load_data()
print("Document ID:", documents[0].doc_id)
Passaggio 2: Variabili ambientali
Dobbiamo importare due API KEYS: Anthropic e OpenAI.
import os
from google.colab import userdata
os.environ["ANTHROPIC_API_KEY"] = userdata.get('ANTHROPIC_API_KEY')
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Passaggio 3: Indicizzazione dei dati
Viene creato un indice dei documenti utilizzando il database vettoriale Milvus. Questa sarà la nostra knowledge base. Poiché OpenAI è il modello di embedding predefinito in LlamaIndex (può essere modificato), dobbiamo definire le stesse dimensioni (dim = 1536) in MilvusVectorStore. Inoltre, dopo aver eseguito il codice seguente verrà creato un database locale, che conterrà la nostra knowledge base.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
Passaggio 4: Motore di query semplice
Testiamo prima il motore di query senza un agente. È basato su Claude 3.5 Sonnet e cerca contenuti pertinenti all'interno del nostro indice.
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
res = query_engine.query("What is the maximum vector dimension supported in Milvus?")
print(res)
"""
Output:
Milvus supports vectors with up to 32,768 dimensions by default. However, if you need to work with vectors of even higher dimensionality, you have the option to increase the value of the 'Proxy.maxDimension' parameter. This allows Milvus to accommodate vectors with dimensions exceeding the default limit.
"""
Passaggio 5: Motore di query agentico
Ora aggiungiamo QueryEngineTool, che fungerà da strumento wrapper per il motore di query, che verrà utilizzato dall'agente.
from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool, ToolMetadata
from llama_index.llms.anthropic import Anthropic
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
query_engine_tool = QueryEngineTool(
query_engine=query_engine,
metadata=ToolMetadata(
name="knowledge_base",
description=(
"Provides information about Milvus FAQ."
"Use a detailed plain text question as input to the tool."
),
),
)
Passaggio 6: Creazione dell'agente AI
L'agente utilizzato in questo caso è il FunctionCallingAgentWorker di LlamaIndex, che impiega la riflessione critica sulla risposta alla query utilizzando lo strumento del motore di query per generare una risposta migliorata.
from llama_index.core.agent import FunctionCallingAgentWorker
agent_worker = FunctionCallingAgentWorker.from_tools(
[query_engine_tool], llm=llm, verbose=True
)
agent = agent_worker.as_agent()
response = agent.chat("What is the maximum vector dimension supported in Milvus?")
print(str(response))
"""
Output:
Added user message to memory: What is the maximum vector dimension supported in Milvus?
=== LLM Response ===
To answer your question about the maximum vector dimension supported in Milvus, I'll need to consult the Milvus FAQ knowledge base. Let me do that for you.
=== Calling Function ===
Calling function: knowledge_base with args: {"input": "What is the maximum vector dimension supported in Milvus?"}
=== Output della funzione ===
Milvus supporta vettori con un massimo di 32.768 dimensioni per impostazione predefinita. Tuttavia, se devi lavorare con vettori di dimensionalità ancora più elevata, hai la possibilità di aumentare il valore del parametro 'Proxy.maxDimension'. Questo consente a Milvus di gestire vettori con dimensioni superiori al limite predefinito.
=== Risposta LLM ===
In base alle informazioni provenienti dalla knowledge base delle FAQ di Milvus, posso fornirti la seguente risposta:
La dimensione vettoriale massima supportata in Milvus è 32.768 per impostazione predefinita. Ciò significa che, già pronto all’uso, Milvus può gestire vettori con un massimo di 32.768 dimensioni, il che è adatto alla maggior parte delle applicazioni.
Tuttavia, è importante notare che Milvus offre flessibilità per i casi in cui potresti dover lavorare con vettori di dimensionalità ancora più elevata. Se il tuo caso d’uso richiede vettori con dimensioni superiori a 32.768, hai la possibilità di aumentare questo limite. Questo può essere fatto regolando il parametro 'Proxy.maxDimension' nella configurazione di Milvus.
Quindi, per riassumere:
1. Dimensione massima predefinita: 32.768
2. Può essere aumentata: Sì, modificando il parametro 'Proxy.maxDimension'
Questa flessibilità consente a Milvus di gestire un’ampia gamma di casi d’uso, dalle tipiche applicazioni di machine learning e AI a scenari più specializzati che potrebbero richiedere vettori di dimensionalità estremamente elevata.
In base alle informazioni provenienti dalla knowledge base delle FAQ di Milvus, posso fornirti la seguente risposta:
La dimensione vettoriale massima supportata in Milvus è 32.768 per impostazione predefinita. Ciò significa che, già pronto all’uso, Milvus può gestire vettori con un massimo di 32.768 dimensioni, il che è adatto alla maggior parte delle applicazioni.
Tuttavia, è importante notare che Milvus offre flessibilità per i casi in cui potresti dover lavorare con vettori di dimensionalità ancora più elevata. Se il tuo caso d’uso richiede vettori con dimensioni superiori a 32.768, hai la possibilità di aumentare questo limite. Questo può essere fatto regolando il parametro 'Proxy.maxDimension' nella configurazione di Milvus.
Quindi, per riassumere:
1. Dimensione massima predefinita: 32.768
2. Può essere aumentata: Sì, modificando il parametro 'Proxy.maxDimension'
Questa flessibilità consente a Milvus di gestire un’ampia gamma di casi d’uso, dalle tipiche applicazioni di machine learning e AI a scenari più specializzati che potrebbero richiedere vettori di dimensionalità estremamente elevata.
"""
L’output dell’agente fornisce una risposta più dettagliata, includendo la fonte delle informazioni, il ragionamento alla base della risposta e alcuni suggerimenti aggiuntivi relativi all’argomento. Questo ci aiuta a comprendere meglio la risposta fornita dal modello LLM.
L’architettura Agentic RAG
L’architettura completa dell’agentic RAG che abbiamo appena costruito è come mostrato di seguito.
L’architettura agentic RAG costruita con Milvus, LlamaIndex e Cluade 3.5 Sonnet.png
Figura 7: L’architettura agentic RAG costruita con Milvus, LlamaIndex e Cluade 3.5 Sonnet
Conclusione
Nel suo intervento, Bill Zhang ha esplorato il panorama in evoluzione dei sistemi LLM, evidenziando il passaggio da modelli standalone ad architetture più complesse che incorporano RAG e agenti. Ogni componente—LLM, RAG e agenti—ha punti di forza e di debolezza. Il concetto di Compound AI consente la creazione di sistemi modulari progettati per affrontare vari colli di bottiglia, migliorando così l’efficienza complessiva della pipeline.
Sebbene i risultati di questi sistemi avanzati siano promettenti e le implementazioni pronte per la produzione stiano diventando più comuni, permangono diverse sfide, in particolare nella gestione e personalizzazione del comportamento degli agenti all’interno di questi sistemi. La messa a punto di questi componenti affinché funzionino in modo efficiente in casi d’uso specifici è un’area di sviluppo continua.
Ulteriori risorse su GenAI, VectorDB e ML
Continua a leggere
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.