3 modèles clés pour créer un RAG multimodal : un guide complet
Les grands modèles de langage (LLM) sont très appréciés pour leur polyvalence, car nous pouvons les utiliser dans de nombreuses applications d’IA, telles que les chatbots personnalisés, le résumé de documents, les questions-réponses sur des documents, la classification de documents, et bien plus encore.
Cependant, l’un des principaux problèmes lors de l’utilisation des LLM est le risque d’hallucination. L’hallucination désigne un phénomène dans lequel les LLM produisent des réponses très convaincantes, mais fausses, à nos requêtes. Il est assez difficile de repérer les hallucinations des LLM, surtout si nous leur posons des questions sur des sujets que nous ne connaissons pas vraiment.
Parmi de nombreuses autres méthodes, la génération augmentée par récupération (RAG) est une approche qui peut nous aider à atténuer le risque d’hallucinations des LLM. Dans sa mise en œuvre initiale, la RAG était plus couramment utilisée uniquement pour les entrées textuelles. Avec les progrès des technologies d’IA, nous pouvons désormais utiliser la RAG avec différentes modalités de données, telles que les images, l’audio, les vidéos, etc., ce que nous appelons RAG multimodale.
Dans cet article, nous allons aborder différentes approches de mise en œuvre de la RAG multimodale dans nos applications d’IA. Avant d’entrer dans le détail de la RAG multimodale, récapitulons d’abord les fondamentaux de la RAG.
Les fondamentaux de la RAG
La RAG est une approche novatrice qui aide à atténuer le risque d’hallucination des LLM en fournissant un contexte pertinent à une requête utilisateur dans le prompt. Avant de répondre à une requête utilisateur, le LLM peut utiliser ce contexte pertinent comme base de sa réponse, ce qui permet d’obtenir des réponses plus contextualisées.
Comme son nom l’indique, la RAG comporte trois composants principaux : la récupération, l’augmentation et la génération.
Récupération : Dans ce composant, le contexte le plus pertinent pour une requête utilisateur est récupéré. Ce composant comporte deux étapes : la récupération de candidats et le reranking. À l’étape de récupération de candidats, les top-n contextes les plus prometteurs sont récupérés. En revanche, à l’étape de reranking, ces contextes sont classés ou triés selon des métriques de similarité, telles que la similarité cosinus ou la distance euclidienne.
Augmentation : Dans ce composant, les contextes les plus prometteurs sont intégrés à la requête utilisateur d’origine afin de former un prompt final cohérent. Ce prompt final servira ensuite d’entrée à notre LLM.
Génération : Dans ce composant, le LLM génère la réponse à partir du prompt d’entrée, qui contient les contextes prometteurs permettant de répondre à la requête de l’utilisateur. La réponse est ensuite renvoyée à l’utilisateur.
Figure : Le workflow complet de la RAG.
Cependant, nous devons mettre en place quelques éléments avant d’implémenter la RAG dans notre application.
Par exemple, nous avons besoin d’un système de stockage efficace et évolutif pour stocker tous les contextes possibles avant de pouvoir les récupérer. Comme les contextes généralement utiles pour la RAG sont des données non structurées (texte, image, etc.), les bases de données vectorielles sont les systèmes de stockage les plus couramment utilisés dans les applications de RAG.
Dans une base de données vectorielle, nous stockons généralement la représentation d’embedding des contextes plutôt que les contextes bruts. Grâce aux embeddings, nous pouvons effectuer des recherches de similarité afin de trouver les contextes les plus prometteurs pour une requête donnée. Par conséquent, nous avons également besoin d’un modèle de deep learning (modèle d’embedding) pour transformer nos contextes bruts en embeddings.
Embedding de mots similaires dans un espace vectoriel bidimensionnel.
Le workflow du pipeline RAG depuis le début est donc le suivant :
Transformer les contextes bruts en embeddings à l’aide d’un modèle d’embedding.
Stocker et indexer ces embeddings dans une base de données vectorielle.
Pour toute requête donnée, transformer la requête en embedding en utilisant le même modèle d’embedding que celui utilisé pour les contextes bruts.
Effectuer une recherche de similarité entre l’embedding de la requête et les embeddings des contextes dans la base de données vectorielle.
Récupérer les top-n contextes les plus pertinents et intégrer ces contextes avec la requête originale dans un prompt cohérent en entrée pour notre LLM.
Le LLM génère une réponse à la requête en utilisant les contextes pertinents fournis afin de donner un résultat plus précis.
Les fondamentaux du RAG multimodal
La mise en œuvre du RAG dont nous avons discuté dans la section précédente s’avère vraiment utile pour atténuer le risque d’hallucination des LLM et améliorer la qualité globale des réponses des LLM. Cependant, lorsque nous parlons des contextes dans le RAG, nous faisons normalement référence au contexte sous forme de texte. Dans le même temps, nous savons que dans les applications réelles, nous pouvons vouloir fournir d’autres modalités comme contextes au lieu du simple texte.
Disons que nous voulons utiliser une collection de documents comme contextes pour une application de chatbot interne. Comme nous le savons déjà, un document se compose généralement non seulement de texte, mais aussi d’images, de graphiques et de tableaux, qui contiennent beaucoup d’informations utiles pour répondre aux requêtes des utilisateurs. Avec le RAG basé sur le texte, nous ne pouvons pas stocker comme contextes les informations contenues dans ces images, graphiques et tableaux.
Le RAG multimodal est la solution à ce problème, car avec cette méthode de RAG, nous pouvons stocker tous les contextes provenant de différentes sources d’information, améliorant ainsi également la précision globale des réponses des LLM.
Figure : pipeline RAG multimodal.
Grâce à l’apparition et à l’essor de l’embedding multimodal ainsi que des LLM multimodaux, il nous est désormais possible de mettre en œuvre le RAG multimodal. L’idée du RAG multimodal est exactement la même que celle du RAG habituel, mais nous sommes désormais capables de stocker des embeddings issus de différentes modalités de données, telles que des images, de l’audio et des vidéos. Cependant, nous devons nous assurer d’utiliser des modèles d’embedding multimodaux ainsi que des LLM multimodaux si nous voulons mettre en œuvre le RAG multimodal.
En général, nous pouvons mettre en œuvre le RAG multimodal de différentes manières. Plus précisément, il existe trois schémas différents dont nous parlerons en détail dans cet article :
Ancrer toutes les modalités dans une modalité principale.
Intégrer toutes les modalités dans le même espace vectoriel.
Une récupération hybride avec accès aux images brutes.
Discutons de ces schémas un par un.
Schéma 1 : Ancrer toutes les modalités dans une modalité principale (du multimédia au texte)
Le premier schéma consiste à transformer toutes les modalités en une seule modalité principale. Bien que vous puissiez choisir n’importe quelle modalité comme modalité principale, le texte est le plus couramment utilisé dans le RAG multimodal. Par conséquent, nous allons utiliser le texte comme modalité principale tout au long de cette section.
Pour transformer différentes modalités en texte, l’astuce consiste à utiliser un LLM multimodal pour générer un résumé textuel de nos données. Par exemple, disons que nous avons un document qui contient un ensemble de textes et une image. Puisque le texte est notre modalité principale, nous n’avons rien à faire avec le texte du document. Dans le même temps, nous pouvons utiliser un Vision Language Model (VLM) comme LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc., qui accepte à la fois des images et du texte comme entrées pour générer un résumé textuel de notre image.
Une fois que nous avons le résumé textuel de notre image, nous pouvons transformer ce texte, ainsi que d’autres textes du document, en embeddings à l’aide d’un modèle d’embedding basé sur le texte. Il existe de nombreux modèles d’embedding basés sur le texte parmi lesquels nous pouvons choisir, tels que ceux de SentenceTransformers, OpenAI, VoyageAI, etc. Les embeddings de ces textes sont ensuite stockés et indexés dans une base de données vectorielle.
Figure : workflow du Pattern 1.
Maintenant, pour toute requête donnée, nous pouvons la transformer en embedding à l’aide du même modèle d’embedding basé sur le texte que celui utilisé précédemment. Après cela, nous pouvons effectuer une recherche de similarité pour trouver les contextes les plus pertinents, puis utiliser les contextes textuels dans le cadre du prompt pour nos LLM textuels ou multimodaux.
Si vous souhaitez en savoir plus sur les détails d’implémentation de ce pattern, nous avons un article dédié qui vous guidera à travers les étapes pour construire un RAG multimodal avec ce pattern.
Ce pattern serait idéal à utiliser si vous n’avez pas besoin d’accéder aux données brutes non textuelles dans votre cas d’utilisation. Votre application peut accepter des images en entrée, mais la sortie est toujours textuelle. Par exemple, vous pourriez construire une application dotée de la fonctionnalité permettant d’expliquer le contenu d’images dans un document interne.
Cependant, nous continuons de nous appuyer sur des contextes textuels avec ce pattern, tout comme le système RAG habituel. Dans les applications réelles, nous pourrions vouloir utiliser des images ou d’autres modalités comme contextes. Parlons donc du deuxième pattern.
Pattern 2 : intégrer toutes les modalités dans le même espace vectoriel
Le deuxième pattern consiste à transformer des données de toutes les modalités en embeddings dans le même espace vectoriel. Le secret derrière cette approche est l’implémentation de modèles d’embedding multimodaux tels que CLIP et ALIGN. Prenons CLIP comme exemple.
CLIP est un modèle développé par OpenAI qui prend à la fois du texte et une image comme paire d’entrées, et a été entraîné à déterminer la similarité entre le texte et l’image. Par conséquent, CLIP donnera un score de similarité élevé si le texte correspond à l’image, et inversement.
Figure : embeddings de données avec différentes modalités avec CLIP dans un espace vectoriel tridimensionnel.
Comme vous pouvez le voir ci-dessus, supposons que nous ayons une phrase « A smiling dog » et une image d’un chien souriant. CLIP transformera d’abord à la fois le texte et l’image en embeddings de dimensions similaires, et si nous vérifions l’espace vectoriel, les deux embeddings seront probablement placés près l’un de l’autre.
Puisque nous disposons d’un modèle d’embedding multimodal, la première étape de ce pattern consiste à transformer nos données de différentes modalités en embeddings avec ce modèle d’embedding multimodal. Ensuite, nous stockons et indexons ces embeddings dans une base de données vectorielle comme Milvus ou Zilliz Cloud. Une fois que nous avons une requête utilisateur, nous la transformons à l’aide du même modèle d’embedding multimodal, puis nous pouvons effectuer une recherche de similarité pour trouver les contextes les plus pertinents.
Figure : workflow du Pattern 2.
Les contextes récupérés lors de l’application de ce modèle peuvent être des données présentant diverses modalités, telles que l’image et le texte. Par conséquent, nous devons utiliser un LLM multimodal pour prendre ces contextes en compte et générer la réponse finale. Si nos données se composent d’images et de texte, nous pouvons utiliser un Vision Language Model (VLM) comme LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc.
Si vous souhaitez en savoir plus sur les détails d’implémentation de ce modèle, nous avons un article dédié qui vous guidera à travers les étapes pour créer un RAG multimodal avec ce modèle. Cependant, gardez à l’esprit que dans cet article, les images brutes ne sont pas directement stockées dans la base de données vectorielle, mais plutôt stockées en mémoire locale.
Le principal avantage de ce modèle est sa polyvalence et sa simplicité. L’implémentation d’un modèle d’embedding multimodal signifie que nous n’avons pas besoin d’une étape supplémentaire pour convertir le contenu de toutes les modalités en une modalité principale comme nous l’avons fait dans le premier modèle. De plus, les contextes récupérés après la recherche de similarité peuvent être des données de n’importe quelles modalités au lieu d’une seule modalité particulière.
Cependant, puisque nous pouvons utiliser n’importe quelles modalités de données comme contextes pertinents pour notre LLM multimodal, nous devons également stocker les données brutes lors de l’implémentation de ce modèle. Le problème est que la taille mémoire des données non textuelles telles que les images est importante, et les stocker directement dans une base de données vectorielle peut entraîner une utilisation inefficace des ressources. Cela finira également par conduire à des temps de requête plus lents et à des coûts de stockage plus élevés.
Par conséquent, nous recommandons d’utiliser ce modèle si vous devez utiliser des données avec différentes modalités comme contextes, mais que la scalabilité n’est pas une préoccupation pour votre cas d’utilisation.
Modèle 3 : Une récupération hybride avec accès aux images brutes.
Si vous devez utiliser des données avec diverses modalités comme contextes, et que la scalabilité est également une préoccupation, alors vous pouvez implémenter ce modèle. L’idée principale de ce modèle est la séparation des responsabilités : nous utilisons une base de données vectorielle pour effectuer des recherches de similarité rapides et efficaces afin de trouver des contextes pertinents, et nous utilisons des systèmes de stockage d’objets dédiés comme AWS S3 ou Google Cloud Storage pour stocker les données brutes.
Lors de l’implémentation de ce modèle, nous devons effectuer deux étapes différentes. Premièrement, nous stockons les données brutes réelles dans un système de stockage d’objets dédié comme AWS S3 ou Google Cloud Storage. Deuxièmement, nous stockons les métadonnées de nos données brutes dans la base de données vectorielle, telles que l’URL de notre image qui réside dans le système de stockage d’objets dédié.
Figure : flux de travail du modèle 3.
Puisque nous utilisons un système distinct pour stocker nos données brutes, la manière dont nous effectuons le RAG est presque similaire au premier modèle. Disons que le texte est notre modalité principale. La première chose que nous devrons faire est d’utiliser un LLM multimodal pour générer des résumés textuels de nos données brutes. Ensuite, nous pouvons utiliser un modèle d’embedding basé sur le texte pour transformer les résumés textuels en embeddings. Nous stockons ensuite les embeddings ainsi que les métadonnées de nos données brutes (URL des données brutes dans le système de stockage dédié) dans une base de données vectorielle.
Pour toute requête donnée, nous utilisons le même LLM multimodal pour générer un résumé textuel, puis nous transformons le résumé de la requête en embedding en utilisant le même modèle d’embedding basé sur le texte. Ensuite, nous pouvons effectuer une recherche de similarité et récupérer le résumé textuel ainsi que l’URL des contextes pertinents. Enfin, nous pouvons transmettre les données brutes à un LLM multimodal via l’URL récupérée.
Encore une fois, vous pouvez vous référer à cet article qui vous guidera à travers les étapes pour créer un RAG multimodal avec ce modèle. Cependant, gardez à l’esprit que dans l’article, les images brutes ne sont pas stockées dans un système de stockage typique prêt pour la production comme AWS ou GCP, mais plutôt en mémoire locale.
Parmi les trois options, ce modèle est le plus évolutif grâce à la séparation du stockage des données brutes. Comme nous le savons peut-être déjà, les bases de données vectorielles sont optimisées pour interroger des données non structurées, et non pour stocker et servir de grands objets binaires comme des images. En fait, la récupération d’objets binaires depuis des bases de données vectorielles est souvent plus lente que leur récupération depuis un système de stockage d’objets dédié.
Par conséquent, nous vous recommandons d’utiliser ce modèle si vous souhaitez utiliser des données de diverses modalités comme contextes et si l’évolutivité est une préoccupation majeure pour votre cas d’utilisation.
Comment la base de données vectorielle Milvus prend en charge le RAG multimodal
Comme mentionné dans les sections précédentes, les bases de données vectorielles jouent un rôle crucial dans l’application de la génération augmentée par récupération (RAG). Milvus est une base de données vectorielle qui serait parfaite pour une utilisation dans votre système RAG ou d’autres applications d’IA grâce à ses fonctionnalités avancées.
Milvus propose des méthodes d’indexation allant des plus simples à des méthodes plus avancées telles que IVFFLAT, HNSW et SCANN, ce qui nous permet de stocker d’immenses collections de données de manière rapide et efficace. La mise en œuvre de ces méthodes d’indexation avancées accélère également le processus de recherche de similarité afin de trouver des contextes pertinents dans une implémentation RAG.
Intégration facile de Milvus avec des outils populaires pour le RAG multimodal.
Milvus offre également une intégration facile avec tous les composants RAG dont nous avons discuté dans la section précédente, tels que les modèles d’embedding, les LLM et les outils d’orchestration. En ce qui concerne les modèles d’embedding, vous pouvez utiliser directement des options populaires d’OpenAI, Cohere, SentenceTransformers, HuggingFace, VoyageAI et d’autres avec le SDK Python de Milvus appelé pymilvus. Vous pouvez installer pymilvus avec une simple commande pip :
pip install -U pymilvus
Maintenant, supposons que vous souhaitiez utiliser le modèle d’embedding de SentenceTransformers, vous pouvez le faire facilement avec pymilvus comme suit :
pip install "pymilvus[model]"
from pymilvus import model
sentence_transformer_ef = model.dense.SentenceTransformerEmbeddingFunction(
model_name='all-MiniLM-L6-v2', # Specify the model name
device='cpu' # Specify the device to use, e.g., 'cpu' or 'cuda:0'
)
doc = [
"Artificial intelligence was founded as an academic discipline in 1956."]
doc_embedding = sentence_transformer_ef.encode_documents(doc)
Vous pouvez en apprendre davantage sur les différents types de modèles d’embedding pris en charge par Pymilvus sur cette page d’intégration.
En ce qui concerne les LLM et les outils d’orchestration, Milvus peut être intégré facilement à des frameworks populaires comme vLLM, Ollama, Gemini, LlamaIndex et Langchain. Si vous souhaitez en savoir plus sur l’intégration de Milvus avec tous ces outils, nous avons une collection de tutoriels que vous pouvez consulter sur cette page. Nous avons également un tutoriel simple dans lequel vous pouvez apprendre à créer un RAG multimodal simple avec Milvus sur cette page de documentation.
Conclusion
Le RAG multimodal représente une avancée significative dans l’utilisation de diverses modalités de données pour améliorer la précision des réponses des LLM. Nous avons discuté de trois modèles clés pour implémenter le RAG multimodal dans cet article : ancrer toutes les modalités dans une modalité principale, les intégrer dans un espace vectoriel unifié, ou employer une récupération hybride avec accès aux données brutes. Le choix d’un modèle approprié dépend des besoins spécifiques de votre application d’IA.
Grâce à ses méthodes d’indexation avancées et à son intégration facile avec les modèles d’embedding, les LLM et les outils d’orchestration, la base de données vectorielle Milvus offre un système adapté à la mise en œuvre de systèmes RAG multimodaux. À mesure que les applications d’IA gagnent en portée et en complexité, l’utilisation d’un système de base de données vectorielle évolutif comme Milvus devient de plus en plus cruciale.
Continuer à lire
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.