Mise en œuvre d’un RAG agentique avec Claude 3.5 Sonnet, LlamaIndex et Milvus
Alors que les systèmes d’IA continuent d’évoluer rapidement, s’appuyer uniquement sur les grands modèles de langage (LLMs) ne suffit plus à répondre aux besoins variés des industries actuelles. Ces défis croissants nécessitent le développement d’architectures plus complexes capables de résoudre les problèmes de manière plus efficace et efficiente.
Lors du Unstructured Data Meetup organisé par Zilliz, Bill Zhang, Director of Engineering chez Zilliz, a présenté le concept de Compound AI Systems, qui a été mis en avant dans le blog Berkeley AI Research (BAIR). Cette approche modulaire intègre plusieurs composants pour gérer diverses tâches plutôt que de s’appuyer sur un seul modèle d’IA, offrant des résultats plus adaptés et plus efficaces. Vous pouvez regarder la présentation de Bill sur la chaîne Zilliz YouTube.
Dans cet article de blog, nous récapitulerons les points clés de Bill, notamment l’évolution des architectures d’applications LLM, les concepts de génération augmentée par récupération (RAG) et d’Agentic RAG, ainsi que leurs défis et avantages. Nous vous guiderons également dans la création d’un Agentic RAG à l’aide de Claude 3.4 Sonnet, LlamaIndex et de la base de données vectorielle Milvus.
Le développement de l’architecture des applications LLM
Les LLM font partie du paysage de l’IA depuis plus d’une décennie, mais l’émergence de modèles de fondation accessibles au public, en particulier ChatGPT d’OpenAI, au cours des trois dernières années, a considérablement accéléré le développement des applications LLM, favorisant leur expansion rapide. Lors du Unstructured Data Meetup, Bill a résumé les composants clés des architectures d’IA actuelles et leur développement.
Figure 1- LLM System Evolution .png
Figure 1 : Évolution du système LLM
S’appuyer uniquement sur les connaissances pré-entraînées des LLM
La façon la plus simple d’utiliser un LLM consiste à s’appuyer sur ses « propres » connaissances pour répondre à votre requête. Cependant, cette méthode présente une limite : les LLM ne peuvent pas couvrir tous les sujets ni tous les cas d’utilisation, ce qui peut entraîner des réponses inexactes ou « hallucinées ». Une façon de résoudre ce problème consiste à utiliser plusieurs LLM, chacun adapté à différents types de questions, mais cette méthode rendrait le système trop complexe et difficile à faire évoluer.
Compound AI systems : ajouter des composants supplémentaires à votre pipeline LLM
Alors, comment pouvons-nous résoudre ce problème ? La solution réside dans les Compound AI systems. L’ajout de composants supplémentaires au pipeline LLM peut améliorer les performances du système. Un exemple courant est la génération augmentée par récupération (RAG). La RAG introduit une « base de connaissances » ou un « contexte », généralement stocké dans une base de données vectorielle comme Milvus ou Zilliz Cloud (le Milvus géré), où des informations spécifiques sont enregistrées pour les recherches de similarité. Vous pouvez accéder à des informations personnalisées pour votre cas d’utilisation en alimentant le système RAG avec vos connaissances. La RAG exploite la puissance du LLM combinée à une invite adaptée composée de la requête utilisateur et du contexte récupéré depuis la base de données vectorielle, produisant des réponses plus précises et pertinentes.
Agents
Alors, devons-nous implémenter davantage de modules ? Cela dépend du cas d’utilisation spécifique. Cependant, comme les LLM, le RAG a également des limites, car il repose sur le modèle spécifique. Par exemple, que se passe-t-il si votre requête implique d’effectuer une tâche de comparaison, mais que votre modèle a été entraîné pour la synthèse ? Comment différents types de questions peuvent-ils être gérés efficacement ? C’est là qu’un module supplémentaire entre en pratique : Agents. Les agents d’IA sont des systèmes complexes qui ajoutent des étapes « semblables à celles des humains » dans le pipeline, comme le raisonnement, les outils utilisés ou la planification. Examinons d’abord les bases du RAG afin de comprendre les avantages des agents.
Génération augmentée par récupération (RAG)
Comme mentionné ci-dessus, les systèmes RAG améliorent la sortie des LLM en intégrant une base de données vectorielle comme base de connaissances. Les étapes de base de la création d’un système RAG peuvent être résumées comme suit :
Découpage : Diviser les documents en morceaux plus petits afin d’améliorer la pertinence du contenu récupéré depuis la base de données vectorielle à l’aide de la recherche sémantique, une caractéristique essentielle des bases de données vectorielles telles que Zilliz Cloud et Milvus.
Embedding : Vectoriser (créer des représentations numériques de) les morceaux qui seront ingérés dans la base de données vectorielle.
Prompt : Instructions données au LLM pour rechercher dans la base de données vectorielle en fonction de la requête afin d’obtenir la réponse
Requête : La question donnée au LLM
Ces étapes reposent principalement sur la similarité. Le modèle recherche les morceaux les plus similaires dans la base de données et génère la réponse la plus précise sur cette base.
Figure 2- Basic steps of RAG .png
Figure 2 : Étapes de base du RAG
Cependant, une recherche de similarité sémantique n’est pas une solution magique. La réponse obtenue sera également insuffisante si les morceaux les plus similaires ne sont pas assez précis. Bill a exploré certaines des faiblesses des systèmes RAG, en particulier dans les cas d’utilisation où les LLM peuvent ne pas fonctionner de manière optimale, notamment la synthèse, la comparaison et les questions en plusieurs parties.
Cependant, le problème du RAG, à savoir son manque de capacités de raisonnement et son incapacité à récupérer avec précision les documents requis, peut être efficacement traité par l’introduction d’Agents. Ces entités jouent un rôle crucial dans l’ensemble du processus, offrant une solution potentielle aux défis posés par le RAG.
RAG agentique
Maintenant que nous comprenons les limites des LLM et du RAG, nous pouvons explorer plus en profondeur les avantages des agents. Dans le diagramme ci-dessous, les agents LLM contiennent plusieurs composants qui interagissent les uns avec les autres dans un processus itératif. Désormais, il ne s’agit plus seulement de similarité, mais aussi de planification, de raisonnement, d’utilisation d’outils et de mémorisation.
Figure 3- LLM Agents .png
Figure 3 : Agents LLM
Bien qu’il existe plusieurs architectures et frameworks agentiques, l’un des plus populaires est ReAct (Reasoning/Acting). ReAct implique plusieurs étapes : planification/raisonnement, action (utilisation d’outils), observation/évaluation et génération de réponse. Bill a présenté ces étapes comme faisant partie d’un processus itératif.
Lors de l’étape d’observation/évaluation, si le modèle ne trouve pas la réponse, il continuera à chercher des alternatives en revenant à l’étape de raisonnement, voire en demandant un prompt supplémentaire à l’utilisateur.
Figure 4- ReAct Framework.png
Figure 4 : Framework ReAct (Source)
Alors, comment pouvons-nous utiliser ces agents dans un pipeline RAG ? Le point positif est qu’ils peuvent être implémentés à toutes les étapes du pipeline, qu’il s’agisse du routage/de la planification vers le pipeline RAG en aval ou de l’appel d’outils. Même la base de connaissances peut être considérée comme un outil ou un framework ReAct.
Figure 5- How An Agentic RAG works .png
Figure 5 : Fonctionnement d’un RAG agentique
Pendant la présentation, Bill a expliqué cinq implémentations agentiques possibles au sein d’un pipeline RAG :
Routage : La requête de l’utilisateur est redirigée vers une base de connaissances spécifique pertinente pour la requête.
- Exemple : Si l’utilisateur demande des recommandations pour des types de livres spécifiques, la requête peut être routée vers la base de connaissances, qui contient des informations sur ces types de livres.
Planification de requête : La requête est divisée en sous-requêtes, chaque sous-requête étant dirigée vers le pipeline RAG pertinent.
- Exemple : Si vous souhaitez connaître les résultats financiers d’une entreprise au cours des trois dernières années, l’agent crée des sous-requêtes pour chaque année et dirige chacune vers la base de connaissances appropriée.
Utilisation d’outils : Un LLM interagit avec une API ou un outil externe, en déterminant les paramètres nécessaires à l’interaction.
- Exemple : Si un utilisateur demande des prévisions météorologiques, le LLM appelle une API météo, détermine des paramètres comme le lieu et la date, puis traite la réponse de l’API pour fournir la réponse.
ReAct : Un processus itératif intégrant le raisonnement et l’action, incluant des étapes de planification, d’utilisation d’outils et d’observation.
- Exemple : Pour générer un itinéraire de voyage détaillé, le système raisonne sur les besoins de l’utilisateur, utilise des API pour recueillir des informations sur les attractions, les restaurants et l’hébergement, observe les résultats pour en vérifier l’exactitude et la pertinence, puis fournit un plan de voyage complet.
Planification dynamique de requêtes : L’agent exécute plusieurs tâches ou sous-requêtes en parallèle plutôt que séquentiellement et agrège les résultats
Exemple : Si vous souhaitez comparer les résultats financiers de deux entreprises et calculer la différence pour une métrique spécifique, l’agent traite les données des deux entreprises en parallèle, puis combine les résultats afin de fournir la comparaison. LLMCompiler est un exemple de framework qui permet une orchestration efficace et efficiente de l’appel de fonctions en parallèle.
Figure 6- LLM Compiler.png
Figure 6 : LLM Compiler (Source)
Ainsi, les agents ajoutent une couche supplémentaire au pipeline RAG, renforçant et améliorant l’efficacité globale du processus. Cependant, tout comme les LLM et le RAG en tant que systèmes autonomes, les agents présentent également certains défis, comme le contrôle de leurs étapes internes et leur personnalisation afin d’obtenir les meilleurs résultats pour des cas d’usage spécifiques.
Présentons maintenant un pipeline agentique simple utilisant la base de données vectorielle Milvus.
RAG agentique avec Claude 3.5 Sonnet, LlamaIndex et Milvus
Le notebook suivant est un exemple de pipeline RAG agentique construit avec LlamaIndex comme framework agentique, Milvus comme base de données vectorielle, et Claude 3.5 Sonnet comme LLM. Dans cette section, je vais vous expliquer comment construire ce RAG agentique.
Vous pouvez également consulter le code complet dans ce notebook.
Étape 1 : Chargement des données
Nous utilisons les pages FAQ de la documentation Milvus 2.4.x comme connaissance privée dans notre RAG, ce qui constitue une bonne source de données pour un pipeline RAG simple.
!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)
Étape 2 : Variables d’environnement
Nous devons importer deux CLÉS API : Anthropic et 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')
Étape 3 : Indexation des données
Un index des documents est créé à l’aide de la base de données vectorielle Milvus. Ce sera notre base de connaissances. Comme OpenAI est le modèle d’embedding par défaut dans LlamaIndex (il peut être modifié), nous devons définir les mêmes dimensions (dim = 1536) dans le MilvusVectorStore. De plus, une base de données locale sera créée après l’exécution du code suivant, qui contiendra notre base de connaissances.
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)
Étape 4 : Moteur de requête simple
Commençons par tester le moteur de requête sans agent. Il est alimenté par Claude 3.5 Sonnet et recherche le contenu pertinent dans notre index.
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.
"""
Étape 5 : Moteur de requête agentique
Maintenant, nous ajoutons le QueryEngineTool, qui servira d’outil enveloppe pour le moteur de requête, lequel sera utilisé par l’agent.
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."
),
),
)
Étape 6 : Création de l’agent IA
L’agent utilisé dans ce cas est le FunctionCallingAgentWorker de LlamaIndex, qui emploie la réflexion critique sur la réponse à la requête en utilisant l’outil du moteur de requête pour générer une réponse améliorée.
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?"}
=== Sortie de fonction ===
Milvus prend en charge par défaut les vecteurs comportant jusqu’à 32 768 dimensions. Cependant, si vous devez travailler avec des vecteurs d’une dimensionnalité encore plus élevée, vous avez la possibilité d’augmenter la valeur du paramètre 'Proxy.maxDimension'. Cela permet à Milvus de prendre en charge des vecteurs dont les dimensions dépassent la limite par défaut.
=== Réponse du LLM ===
Sur la base des informations issues de la base de connaissances FAQ de Milvus, je peux vous fournir la réponse suivante :
La dimension vectorielle maximale prise en charge dans Milvus est de 32 768 par défaut. Cela signifie que, prêt à l’emploi, Milvus peut gérer des vecteurs comportant jusqu’à 32 768 dimensions, ce qui convient à la plupart des applications.
Cependant, il est important de noter que Milvus offre de la flexibilité pour les cas où vous pourriez devoir travailler avec des vecteurs de dimension encore plus élevée. Si votre cas d’utilisation nécessite des vecteurs dont les dimensions dépassent 32 768, vous avez la possibilité d’augmenter cette limite. Cela peut être fait en ajustant le paramètre 'Proxy.maxDimension' dans la configuration de Milvus.
Donc, pour résumer :
1. Dimension maximale par défaut : 32 768
2. Peut être augmentée : Oui, en modifiant le paramètre 'Proxy.maxDimension'
Cette flexibilité permet à Milvus de prendre en charge un large éventail de cas d’utilisation, des applications typiques de machine learning et d’IA aux scénarios plus spécialisés qui pourraient nécessiter des vecteurs de très haute dimension.
Sur la base des informations issues de la base de connaissances FAQ de Milvus, je peux vous fournir la réponse suivante :
La dimension vectorielle maximale prise en charge dans Milvus est de 32 768 par défaut. Cela signifie que, prêt à l’emploi, Milvus peut gérer des vecteurs comportant jusqu’à 32 768 dimensions, ce qui convient à la plupart des applications.
Cependant, il est important de noter que Milvus offre de la flexibilité pour les cas où vous pourriez devoir travailler avec des vecteurs de dimension encore plus élevée. Si votre cas d’utilisation nécessite des vecteurs dont les dimensions dépassent 32 768, vous avez la possibilité d’augmenter cette limite. Cela peut être fait en ajustant le paramètre 'Proxy.maxDimension' dans la configuration de Milvus.
Donc, pour résumer :
1. Dimension maximale par défaut : 32 768
2. Peut être augmentée : Oui, en modifiant le paramètre 'Proxy.maxDimension'
Cette flexibilité permet à Milvus de prendre en charge un large éventail de cas d’utilisation, des applications typiques de machine learning et d’IA aux scénarios plus spécialisés qui pourraient nécessiter des vecteurs de très haute dimension.
"""
La sortie de l’agent fournit une réponse plus détaillée, incluant la source de l’information, le raisonnement derrière la réponse et quelques suggestions supplémentaires liées au sujet. Cela nous aide à mieux comprendre la réponse donnée par le modèle LLM.
L’architecture RAG agentique
L’architecture complète du RAG agentique que nous venons de construire ressemble à ce qui suit.
L’architecture RAG agentique construite avec Milvus, LlamaIndex et Cluade 3.5 Sonnet.png
Figure 7 : L’architecture RAG agentique construite avec Milvus, LlamaIndex et Cluade 3.5 Sonnet
Conclusion
Dans sa présentation, Bill Zhang a exploré le paysage en évolution des systèmes LLM, en mettant en évidence le passage de modèles autonomes à des architectures plus complexes qui intègrent le RAG et des agents. Chaque composant — LLM, RAG et agents — possède des forces et des faiblesses. Le concept de Compound AI permet de créer des systèmes modulaires conçus pour traiter divers goulets d’étranglement, améliorant ainsi l’efficacité globale du pipeline.
Bien que les résultats de ces systèmes avancés soient prometteurs et que les implémentations prêtes pour la production deviennent plus courantes, plusieurs défis subsistent, en particulier dans la gestion et la personnalisation du comportement des agents au sein de ces systèmes. Le réglage fin de ces composants afin qu’ils fonctionnent efficacement dans des cas d’utilisation spécifiques est un domaine de développement continu.
Ressources supplémentaires sur GenAI, VectorDB et ML
Continuer à lire
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.