Blog
Créer un RAG avec la base de données vectorielle Milvus auto-déployée et Snowpark Container Services

Créer un RAG avec la base de données vectorielle Milvus auto-déployée et Snowpark Container Services

Jun 28, 202415 min read

Jiang Chen, Head of Ecosystem & AI Platform chez Zilliz, a récemment expliqué comment intégrer Milvus de manière fluide avec Snowflake lors d’une intervention au Unstructured Data Meetup. Plus précisément, il a exploré comment construire un système de Retrieval Augmented Generation (RAG) avec la base de données vectorielle Milvus et son intégration avec l’écosystème Snowflake à l’aide du Snowpark Container Service (SPCS).

< Regardez l’intervention de Jiang Chen sur Youtube >

Cet article récapitulera les points clés de Jiang et couvrira trois sujets importants.

Tout d’abord, nous discuterons de l’utilisation de Milvus pour la recherche vectorielle, une étape essentielle pour construire un système RAG. Ensuite, nous verrons comment intégrer Milvus dans Snowflake avec SPCS. Enfin, nous aborderons également le futur paysage du RAG. Avant d’approfondir ces sujets, explorons comment l’IA a transformé la recherche d’informations.

Comment l’IA révolutionne le processus de recherche d’informations

Les progrès et la popularité de l’IA ont rapidement transformé l’ensemble du paysage de la recherche d’informations. Avant l’essor de l’IA, la recherche d’informations reposait fortement sur des modèles statistiques et des méthodes de correspondance par mots-clés comme le balisage. Par exemple, le propriétaire d’une boutique en ligne devait saisir manuellement des tags pour chaque produit dans des catégories prédéfinies. S’il dispose d’un immense catalogue de produits, ce processus ne serait pas pratique.

De même, en tant que clients, nous devions saisir les tags appropriés pour obtenir le produit exact que nous souhaitons. Le problème est que, si nous saisissons un tag qui n’est pas exact mais dont le sens est similaire au produit que nous voulons, la recherche d’informations via la méthode de balisage ne parviendra pas à nous fournir les produits appropriés. En d’autres termes, la méthode de balisage ne tient pas compte du sens sémantique d’une requête.

L’IA révolutionne notre utilisation des données non structurées L’IA révolutionne notre utilisation des données non structurées

L’apparition des modèles d’embedding a complètement transformé la manière dont nous récupérons les informations. La plupart des modèles d’embedding utilisent la célèbre architecture Transformer comme colonne vertébrale. Le modèle Transformer s’appuie sur plusieurs blocs encodeur-décodeur, chacun contenant une couche d’attention spécialisée. Cette couche permet au modèle de percevoir le sens sémantique de chaque token d’entrée par rapport à l’ensemble de la séquence d’entrée, ce qui rend les modèles d’embedding capables d’inférer le sens sémantique des mots d’entrée.

Architecture Transformer

Architecture Transformer

Les modèles d’embedding transforment les requêtes, les images ou les descriptions textuelles en leurs représentations numériques appelées embeddings vectoriels. Un embedding vectoriel porte une signification riche sur le plan sémantique de l’entrée qu’il représente, et nous pouvons comparer la similarité entre deux embeddings vectoriels via la similarité cosinus ou la distance cosinus. Si la similarité est élevée, alors deux embeddings vectoriels ont un sens similaire, et inversement.

Textes bruts vers embeddings vectoriels.png

Textes bruts vers embeddings vectoriels

Grâce à ces caractéristiques puissantes, les modèles d’embedding rendent la mise en œuvre du concept de recherche d’informations beaucoup plus facile et plus flexible.

Génération augmentée par récupération (RAG)

Les progrès rapides des modèles d’embedding et l’essor des grands modèles de langage (LLMs) ont conduit à l’émergence de RAG, une méthode de recherche d’informations très sophistiquée. RAG est conçu pour améliorer la qualité des réponses d’un LLM en fournissant au LLM un contexte pertinent issu d’une base de connaissances interne en plus de la requête. Le LLM utilisera ensuite le contexte fourni pour répondre à la requête.

Architecture RAG

Dans une application RAG, nous utilisons les modèles d’embedding que nous avons choisis pour transformer nos données et notre requête d’entrée en embeddings. Ensuite, nous calculons la similarité entre l’embedding de notre requête et les embeddings de nos propres données. Les données les plus similaires à notre requête seront ensuite transmises à un LLM comme contexte, avec notre requête. Au final, notre LLM peut générer une réponse à la requête en fonction du contexte fourni. De cette façon, nous pouvons améliorer la précision des réponses d’un LLM sans avoir besoin de l’affiner.

Intégrer la base de données vectorielle Milvus et Snowflake avec Snowpark Container Service

Milvus est une base de données vectorielle open source qui vous permet de stocker une quantité massive d’embeddings vectoriels utiles pour les applications RAG et d’effectuer des recherches vectorielles dessus en une fraction de seconde. Il existe plusieurs options pour installer et utiliser Milvus :

Milvus Lite: Une version légère de Milvus adaptée au prototypage rapide. Milvus Lite ne nécessite pas de serveur ; vous pouvez l’exécuter sur votre propre appareil. Le processus d’installation est aussi simple que l’utilisation d’une commande pip install.

!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")

Milvus dans Docker: Si vous souhaitez utiliser votre base de données vectorielle Milvus en production et que vous ne disposez que d’une petite quantité de données, vous pouvez l’exécuter comme un conteneur Docker. Le processus est également simple, car il vous suffit d’exécuter ces commandes dans votre ligne de commande :

# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh

# Start the Docker container
$ bash standalone_embed.sh start

# In your Python IDE
from pymilvus import MilvusClient

client = MilvusClient(
uri="<http://milvus:19530>",
)

Milvus dans Kubernetes: Cette option convient si vous avez des quantités massives de données ou si vos applications RAG comptent un très grand nombre d’utilisateurs. Vous pouvez stocker jusqu’à 100 milliards de vecteurs avec Kubernetes. Le processus d’installation avec Kubernetes est un peu plus compliqué que celui de Milvus Lite et Docker. Par conséquent, consultez la documentation d’installation pour obtenir des informations détaillées.

Milvus offre une intégration transparente avec des boîtes à outils d’IA populaires telles que OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex et Snowflake. Ces intégrations facilitent la création de vos propres systèmes RAG ou d’autres applications GenAI. Cette section vous montrera comment exécuter Milvus au sein de l’écosystème Snowflake.

Milvus offre une intégration transparente avec toutes les boîtes à outils d’IA populaires

Milvus offre une intégration transparente avec toutes les boîtes à outils d’IA populaires

Snowflake est une plateforme d’entreposage de données qui vous permet de stocker, traiter et analyser les données de manière efficace et fiable. Avec l’introduction de Snowpark Container Service (SPCS), vous pouvez désormais exécuter des applications conteneurisées dans l’environnement Snowflake. Ainsi, votre application peut interagir avec les données stockées dans Snowflake, ce qui vous permet de créer un large éventail d’applications, y compris un système RAG.

Dans cette section, nous allons d’abord créer une application avec Milvus qui effectue une recherche vectorielle. Ensuite, nous conteneuriserons l’application à l’aide de Docker et exécuterons le conteneur dans Snowflake avec SPCS.

Pour commencer, créons une application Milvus afin d’effectuer une recherche vectorielle avec Jupyter Notebook. Si vous souhaitez suivre les étapes, consultez ce dépôt pour le notebook complet et le script permettant de créer le modèle d’embedding.

from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode

# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)

# init model
model = model.Onnx()

# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)

print("Collection Created!")

Dans le code ci-dessus, nous avons créé une collection appelée “quick_demo” dans une base de données vectorielle Milvus et chargé le modèle pour transformer les textes en embeddings. Nous utiliserons ALBERT comme modèle d’embedding, qui mappe un texte d’entrée vers un embedding vectoriel à 768 dimensions.

Ensuite, insérez des données textuelles dans notre collection “quick_demo”.

# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]

# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})

res = client.insert(
collection_name="quick_demo",
data=data
)

Dans le code ci-dessus, nous transformons nos textes d’entrée en embeddings avec ALBERT et les stockons dans la collection avec leurs ID et leurs textes bruts.

Maintenant, si nous avons une requête telle que “Qui a commencé la recherche en IA ?” et que nous souhaitons obtenir le contexte pertinent susceptible de contenir la réponse pertinente à notre requête, nous pouvons effectuer facilement une recherche vectorielle avec Milvus comme suit :

# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)

res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)

print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""

Et voilà pour notre application Milvus.

À ce stade, nous avons un Jupyter Notebook pour effectuer une recherche vectorielle avec Milvus. Supposons que nous voulions conteneuriser ce notebook pour l’exécuter au sein de l’écosystème Snowflake. La première chose que nous devons faire est de configurer le rôle et les privilèges pour créer et exécuter le service fourni par Snowflake.

Tout d’abord, téléchargez SnowSQL en suivant les instructions de la page de documentation Installer SnowSQL. Ensuite, exécutez la commande suivante dans le terminal :

snowsql -a ${instance_name} -u ${user_name}

où le format de ${instance_name} est ${org_name}-${acct_name}, et vous pouvez trouver des informations sur ces deux champs dans votre compte Snowflake. Nous pouvons maintenant configurer le rôle et les privilèges avec les commandes suivantes dans le shell SnowSQL :

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
  TYPE=oauth
  OAUTH_CLIENT=snowservices_ingress
  ENABLED=true;
  
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;

USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;

USE ROLE USERADMIN;
CREATE USER milvus_user
  PASSWORD='milvususerok'
  DEFAULT_ROLE = MILVUS_ROLE
  DEFAULT_SECONDARY_ROLES = ('ALL')
  MUST_CHANGE_PASSWORD = FALSE;
  
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;

Comme Snowflake est une plateforme d’entrepôt de données, nous interagissons avec tous les objets dans Snowflake au moyen d’une commande semblable à une requête SQL, comme vous pouvez le voir ci-dessus. Ensuite, nous pouvons créer l’entrepôt de données et la base de données dans Snowflake avec les commandes suivantes :

USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;

USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');

--GRANT ROLE PRIVILEGES--

USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;

--CONFIGURE ACL--

USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');

CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;

GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;

Pour exécuter une application conteneurisée dans Snowflake, nous devons construire l’image Docker de notre application sur notre machine locale. Dans ce projet, nous devons construire deux images Docker différentes : l’une pour instancier la base de données vectorielle Milvus et l’autre pour exécuter le fichier notebook que nous avons créé ci-dessus.

Cependant, nous avons besoin d’un Dockerfile pour construire une image Docker. Pour simplifier les choses, clonez le dépôt suivant. Vous trouverez dans ce dépôt tous les fichiers nécessaires pour construire les deux images dont nous avons besoin. Après avoir cloné le dépôt, vous pouvez construire les deux images Docker avec les commandes suivantes dans votre terminal local :

cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter

Ensuite, nous pouvons ajouter des balises appropriées aux deux images nouvellement construites avec les commandes suivantes :

docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}

docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

Enfin, nous pouvons pousser les images vers SPCS avec les commandes suivantes :

docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

Maintenant que nous avons poussé les images vers SPCS, la seule chose que nous devons faire est de créer deux services de calcul, un pour chaque image, comme vous pouvez le voir dans les commandes suivantes à l’intérieur du shell SnowSQL :

USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_S
  AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_S
  AUTO_RESUME = true;

Dans le repo que nous avons cloné précédemment se trouve un dossier appelé « specs ». Dans ce dossier se trouvent deux fichiers YAML, un pour chaque image. Ouvrez chaque fichier YAML et modifiez ${org_name}-${acct_name} dans le champ image en fonction de votre propre compte Snowflake.

Ensuite, à l’aide de SnowSQL, téléversez les fichiers YAML modifiés avec les commandes suivantes :

PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;

Et enfin, nous pouvons créer les services pour les deux images comme suit :

USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;

CREATE SERVICE MILVUS
  IN COMPUTE POOL MILVUS_COMPUTE_POOL 
  FROM @YAML_STAGE
  SPEC='milvus.yaml'
  MIN_INSTANCES=1
  MAX_INSTANCES=1;

CREATE SERVICE JUPYTER
  IN COMPUTE POOL JUPYTER_COMPUTE_POOL 
  FROM @YAML_STAGE
  SPEC='jupyter.yaml'
  MIN_INSTANCES=1
  MAX_INSTANCES=1;

Maintenant, si vous tapez la commande SHOW SERVICE, vous devriez voir la sortie suivante :

SHOW SERVICES;

+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name    | database_name | schema_name | owner    | compute_pool         | dns_name                                               | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO   | PUBLIC      | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ...... 
| MILVUS  | MILVUS_DEMO   | PUBLIC      | SYSADMIN | MILVUS_COMPUTE_POOL  | milvus.public.milvus-demo.snowflakecomputing.internal  | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------

Nous sommes maintenant prêts à exécuter la base de données vectorielle Milvus et à tester notre notebook dans Snowflake. Tout d’abord, accordez au rôle que nous avons créé précédemment l’autorisation d’accéder à l’application conteneurisée.

USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;

Ensuite, vérifiez l’endpoint du conteneur de notre notebook dans Snowflake avec la commande suivante :

USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;

Endpoint Jupyter, tel qu’affiché dans ingress_url

Endpoint Jupyter, tel qu’affiché dans ingress_url

Si tout fonctionne correctement, vous pouvez voir une colonne appelée « ingress_url » en sortie. Ouvrez votre navigateur, copiez-collez cet « ingress_url », et vous devriez voir Jupyter démarrer. Vous pouvez ensuite ouvrir le fichier notebook à l’intérieur du conteneur et exécuter chaque cellule du notebook normalement.

Le futur paysage de RAG

RAG est une technique très populaire de nos jours. Cependant, son application actuelle est loin d’être parfaite. Selon Jiang Chen, voici plusieurs prédictions concernant l’utilisation future et l’amélioration des applications RAG.

Évaluation continue et observabilité

Construire RAG est devenu plus facile grâce à la disponibilité de diverses plateformes ou bibliothèques qui simplifient et abstraient le processus de développement RAG. Par exemple, nous pouvons construire un prototype RAG en quelques minutes avec l’aide de trois plateformes différentes : Milvus, LangChain et OpenAI.

Cependant, nous sommes souvent confrontés à des défis lorsque nous faisons passer une application alimentée par RAG du prototype à la production. En production, nos systèmes RAG doivent gérer des millions, voire des milliards de documents, ce qui rend crucial le suivi continu de la qualité des réponses générées par notre LLM

Évaluation continue du système RAG

Avant de mettre en œuvre des améliorations pour renforcer la qualité de notre RAG, il est important d’établir une approche systématique pour l’évaluer et l’améliorer en continu.

Certains éléments clés de cette approche systématique incluent :

Construire une infrastructure d’amélioration dédiée : Dans cette infrastructure, nous pouvons mettre en œuvre diverses méthodes pour améliorer la qualité de RAG, puis comparer leurs réponses via des tests A/B.
Planifier un cycle de publication : Une fois que nous trouvons une approche qui améliore la qualité de RAG selon notre cas d’utilisation, nous devons planifier comment la publier et l’intégrer dans notre système afin de remplacer l’ancienne sans interrompre l’expérience utilisateur.
Mettre en œuvre un système d’observabilité : Nous devons également construire un système pour observer les performances de notre RAG en production et déterminer son efficacité. Si les performances ne sont pas satisfaisantes, nous pouvons explorer et mettre en œuvre des améliorations grâce à l’infrastructure d’amélioration dédiée.

RAG multimodal

Jusqu’à présent, nous avons principalement utilisé RAG dans le traitement du langage naturel. Cela signifie que nous utilisons du texte comme prompt ou requête, et que les réponses de notre LLM sont également sous forme de texte.

Cependant, le paysage du RAG pourrait changer à l’avenir avec l’introduction du RAG multimodal. Le RAG multimodal est possible grâce à l’essor des modèles d’embedding multimodaux ces dernières années. Au cours des dernières années, la recherche a conclu que les Transformers peuvent traiter le langage naturel comme entrées ainsi que d’autres modalités, telles que les images et les sons.

Les modèles Vision Transformers (ViT) et DETR ont démontré que les Transformers peuvent être utilisés comme de puissants modèles de classification d’images et de détection d’objets. En s’appuyant sur ViT, OpenAI a introduit un modèle multimodal appelé CLIP, qui peut calculer la similarité entre deux entrées de modalités différentes : le texte et l’image.

Les capacités multimodales montrées par ces modèles basés sur les Transformers peuvent servir de fondation aux futures applications RAG multimodales. Dans ce système, nous pouvons utiliser une combinaison de texte et d’image comme requête, et le LLM générera une image basée sur nos requêtes multimodales.

À titre d’exemple, supposons que nous souhaitions que notre LLM génère une image qui ressemble étroitement à une image de requête fournie. Nous pouvons enrichir notre image de requête avec une description textuelle afin d’affiner davantage le type d’images que nous voulons que notre LLM génère, comme vous pouvez le voir dans la visualisation ci-dessous :

Application RAG multimodale, combinaison de requêtes texte et image

Dans la visualisation ci-dessus, nous avons demandé à nos modèles d’embedding de renvoyer des images ressemblant à l’image en haut à gauche, et nous avons ajouté un prompt textuel, tel que "une image d’une montagne pendant l’heure dorée," à côté de l’image en haut à gauche. Les résultats sont les trois autres images générées sur la base de la requête multimodale.

Cette approche multimodale du RAG ouvre de nouvelles possibilités pour une récupération et une génération d’informations plus intuitives et expressives, en combinant les forces des modalités textuelle et visuelle.

Un bon RAG provient de bonnes données

La qualité de notre système RAG dépend fortement de la qualité des données que nous avons dans notre base de données. Par conséquent, lorsque la réponse générée par notre RAG n’est pas optimale, nous ne devons pas conclure hâtivement que le modèle doit être amélioré. Tout d’abord, nous devons toujours vérifier la qualité de nos données.

Comme vous le savez peut-être déjà, la qualité des réponses de RAG dépend des contextes transmis avec la requête. Si notre LLM ne peut pas trouver de réponses appropriées à la requête à partir des contextes fournis, il n’est alors pas surprenant que la qualité des réponses générées par notre système RAG soit médiocre.

Par conséquent, avant de choisir d’améliorer les modèles d’embedding et le LLM dans notre système RAG, nous devons toujours poser les questions suivantes :

Avons-nous les bonnes données dans notre base de données ?
Avons-nous collecté toutes les données disponibles à partir des sources de données dans notre base de données ?
Avons-nous mis en œuvre le bon processus de nettoyage des données avant de transmettre les données aux modèles d’embedding ?
Avons-nous mis en œuvre l’approche de segmentation appropriée pour nos données ?
Avons-nous mis en œuvre les bonnes méthodes de prétraitement des données (par exemple, analyse de PDF, analyse OCR) pour nos données ?

Résoudre les problèmes liés aux données est une première étape cruciale pour optimiser les performances d’une application alimentée par RAG. Ce n’est qu’après avoir vérifié la qualité des données que nous devrions envisager d’affiner les modèles d’embedding, le LLM ou d’autres composants du système RAG.

Agents : routage des requêtes avec des sous-requêtes

Actuellement, un système RAG courant récupère les contextes pertinents pour une requête donnée à partir de textes et d’embeddings enregistrés dans une base de données interne. Cependant, cette approche pourrait évoluer, car le contexte pourrait être récupéré à partir de bases de données internes et de sources externes, telles que des recherches web.

Visualisation des agents pour le routage des requêtes

La recherche dans ce domaine est encore en cours, mais l’ajout d’un soi-disant « agent » au sein d’un système RAG pourrait aider à déterminer la source de contexte appropriée pour une requête donnée.

Par exemple, pour une requête comme « Qui a lancé la recherche en IA ? », l’agent peut décider si RAG est nécessaire ou non pour répondre à cette question. Si ce n’est pas le cas, le système peut laisser le LLM générer directement une réponse à la requête sans aucun contexte supplémentaire.

Si RAG est jugé nécessaire, l’agent doit déterminer la source du contexte, qu’il s’agisse d’une base de données interne ou d’une source externe. Une autre approche consiste pour l’agent à agréger les informations provenant de diverses sources en un seul contexte résumé pouvant être utilisé par le LLM pour générer une réponse appropriée.

Conclusion

Les performances puissantes des LLM pour générer des réponses textuelles semblables à celles d’un humain ont changé tout le paysage de la recherche d’informations. L’introduction de RAG vise à améliorer la précision des réponses des LLM en leur fournissant des contextes pertinents pour une requête donnée. Ces contextes sont généralement stockés sous forme d’embeddings, qui doivent être stockés dans une base de données vectorielle comme Milvus.

En tant que base de données vectorielle open source dotée de capacités avancées de recherche vectorielle, Milvus offre une intégration transparente avec des boîtes à outils d’IA populaires, telles que Snowflake. Avec le Snowpark Container Service (SPCS) de Snowflake, les utilisateurs peuvent désormais exécuter Milvus au sein de l’écosystème Snowflake, ce qui leur permet d’interagir facilement avec Milvus en utilisant les données stockées dans Snowflake.

Mis à jour le Jul 13, 2026

Ruben Winastwan

Continuer à lire

Optimizing Embedding Model Selection with TDA Clustering: A Strategic Guide for Vector Databases

Discover how Topological Data Analysis (TDA) reveals hidden embedding model weaknesses and helps optimize vector database performance.

Vector Databases vs. Key-Value Databases

Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.

Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights

Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.