Construire un système RAG multimodal avec Elasticsearch : L'histoire de Gotham City

Elasticsearch dispose d'intégrations natives avec les outils et fournisseurs d'IA générative leaders du secteur. Consultez nos webinars sur le dépassement des bases de RAG ou sur la création d'applications prêtes à l'emploi avec la Base vectorielle Elastic.

Pour élaborer les meilleures solutions de recherche pour votre cas d'utilisation, commencez un essai gratuit d'Elastic Cloud ou essayez Elastic sur votre machine locale dès maintenant.

Dans ce blog, vous apprendrez à construire un pipeline RAG (Retrieval-Augmented Generation) multimodal à l'aide d'Elasticsearch. Nous verrons comment exploiter ImageBind pour générer des embeddings pour différents types de données, notamment le texte, les images, l'audio et les cartes de profondeur. Vous découvrirez également comment stocker et récupérer efficacement ces embeddings dans Elasticsearch à l'aide de dense_vector et de k-NN search. Enfin, nous intégrerons un modèle de langage étendu (LLM) pour analyser les preuves extraites et générer un rapport final complet.

Comment fonctionne la canalisation multimodale RAG ?

1. Collecte d'indices → Images, sons, textes et cartes de profondeur provenant de la scène de crime de Gotham.
2. Génération d'embeddings → Chaque fichier est converti en vecteur à l'aide du modèle multimodal ImageBind.
3. Indexation dans Elasticsearch → Les vecteurs sont stockés pour une récupération efficace.
4. Recherche par similarité → Étant donné un nouvel indice, les vecteurs les plus similaires sont récupérés.
5. Le LLM analyse les preuves → Un modèle GPT-4 synthétise la réponse et identifie le suspect !

Technologies utilisées

• ImageBind → Génère des encastrements unifiés pour différentes modalités.
• Elasticsearch → Permet une recherche vectorielle rapide et efficace.
• LLM (GPT-4, OpenAI) → Analyse les preuves et produit un rapport final.

À qui s'adresse ce blog ?

• Utilisateurs d'Elastic intéressés par la recherche vectorielle multimodale.
• Les développeurs qui cherchent à comprendre le RAG multimodal dans la pratique.
• Toute personne à la recherche de solutions évolutives pour l'analyse de données provenant de sources multiples.

Conditions préalables à la mise en place d'un RAG multimodal : mise en place de l'environnement

Pour résoudre les crimes de Gotham City, vous devez mettre en place votre environnement technologique. Suivez ce guide étape par étape :

1. Exigences techniques

2. Mise en place du projet

Tout le matériel d'enquête est disponible sur GitHub, et nous utiliserons Jupyter Notebook (Google Colab) pour cette expérience interactive de résolution de crimes. Suivez les étapes suivantes pour commencer :

Configuration avec Jupyter Notebook (Google Colab)

1. Accéder à l'ordinateur portable

• Ouvrez notre carnet Google Colab prêt à l'emploi : RAG multimodal avec Elasticsearch.
• Ce carnet contient tout le code et les explications dont vous avez besoin pour suivre le cours.

2. Cloner le référentiel

3. Installer les dépendances

4. Configurer les informations d'identification

Note : Le modèle ImageBind (~2GB) sera téléchargé automatiquement lors de la première exécution.

Maintenant que tout est prêt, plongeons dans les détails et résolvons le crime !

Introduction : Le crime à Gotham City

Par une nuit pluvieuse à Gotham City, un crime choquant secoue la ville. Le commissaire Gordon a besoin de votre aide pour élucider ce mystère. Les indices sont dispersés dans différents formats : images floues, sons mystérieux, textes cryptés et même cartes de profondeur. Êtes-vous prêt à utiliser la technologie d'IA la plus avancée pour résoudre l'affaire ?

Dans ce blog, vous serez guidé pas à pas dans la construction d'un système RAG (Retrieval-Augmented Generation) multimodal qui unifie différents types de données(images, audio, textes et cartes de profondeur) dans un espace de recherche unique. Nous utiliserons ImageBind pour générer des encastrements multimodaux, Elasticsearch pour stocker et récupérer ces encastrements, et un Grand Modèle de Langage (LLM) pour analyser les preuves et générer un rapport final.

Principes fondamentaux : Architecture multimodale RAG

Qu'est-ce qu'un RAG multimodal ?

L'essor du multimodal RAG (Retrieval-Augmented Generation) révolutionne la façon dont nous interagissons avec les modèles d'IA. Traditionnellement, les systèmes RAG travaillent exclusivement avec du texte, récupérant les informations pertinentes dans des bases de données avant de générer des réponses. Toutefois, le monde ne se limite pas au texte : les images, les vidéos et les sons sont également porteurs de connaissances précieuses. C'est pourquoi les architectures multimodales gagnent en importance, permettant aux systèmes d'IA de combiner des informations provenant de différents formats pour obtenir des réponses plus riches et plus précises.

Trois approches principales pour le RAG multimodal

Trois stratégies sont couramment utilisées pour mettre en œuvre un RAG multimodal. Chaque approche présente ses propres avantages et limites, en fonction du cas d'utilisation :

1. Espace vectoriel partagé

Les données provenant de différentes modalités sont mises en correspondance dans un espace vectoriel commun à l'aide de modèles multimodaux tels qu'ImageBind. Cela permet aux requêtes textuelles de récupérer des images, des vidéos et des fichiers audio sans conversion explicite de format.

Avantages :

• Permet la recherche multimodale sans nécessiter de conversion de format explicite.
• Il assure une intégration fluide entre les différentes modalités, permettant une recherche directe dans le texte, l'image, l'audio et la vidéo.
• Évolutif pour divers types de données, ce qui le rend utile pour les applications de recherche à grande échelle.

Inconvénients :

• La formation nécessite de grands ensembles de données multimodales, qui ne sont pas toujours disponibles.
• L'espace d'intégration partagé peut introduire une dérive sémantique, lorsque les relations entre les modalités ne sont pas parfaitement préservées.
• Les biais dans les modèles multimodaux peuvent avoir un impact sur la précision de la recherche, en fonction de la distribution de l'ensemble des données.

2. Une seule modalité ancrée

Toutes les modalités sont converties dans un format unique, généralement du texte, avant d'être extraites. Par exemple, les images sont décrites par des légendes générées automatiquement, et le son est transcrit en texte.

Avantages :

• Simplifie la recherche, car tout est converti en une représentation textuelle uniforme.
• Fonctionne bien avec les moteurs de recherche textuels existants, ce qui élimine la nécessité d'une infrastructure multimodale spécialisée.
• Peut améliorer l'interprétabilité puisque les résultats obtenus sont dans un format lisible par l'homme.

Inconvénients :

• Perte d'informations: Certains détails (par exemple, les relations spatiales dans les images, la tonalité dans le son) peuvent ne pas être entièrement pris en compte dans les descriptions textuelles.
• Dépend de la qualité du sous-titrage/de la transcription: Les erreurs dans les annotations automatiques peuvent réduire l'efficacité de la recherche.
• Elle n'est pas optimale pour les requêtes purement visuelles ou auditives, car le processus de conversion risque de supprimer le contexte essentiel.

3. Récupération séparée

Maintient des modèles distincts pour chaque modalité. Le système effectue des recherches distinctes pour chaque type de données et fusionne ensuite les résultats.

Avantages :

• Permet une optimisation personnalisée par modalité, améliorant la précision de la recherche pour chaque type de données.
• Moins de dépendance à l'égard de modèles multimodaux complexes, ce qui facilite l'intégration des systèmes de recherche existants.
• Permet de contrôler finement le classement et le reclassement, les résultats provenant de différentes modalités pouvant être combinés de manière dynamique.

Inconvénients :

• Nécessite la fusion des résultats, ce qui rend le processus de recherche et de classement plus complexe.
• Peut générer des réponses incohérentes si différentes modalités renvoient des informations contradictoires.
• Coût de calcul plus élevé car des recherches indépendantes sont effectuées pour chaque modalité, ce qui augmente le temps de traitement.

Notre choix : Espace vectoriel partagé avec ImageBind

Parmi ces approches, nous avons choisi l'espace vectoriel partagé, une stratégie qui s'aligne parfaitement avec le besoin de recherches multimodales efficaces. Notre implémentation est basée sur ImageBind, un modèle capable de représenter plusieurs modalités(texte, image, audio et vidéo) dans un espace vectoriel commun. Cela nous permet de

• Effectuer des recherches multimodales entre différents formats de médias sans avoir à tout convertir en texte.
• Utiliser des encastrements très expressifs pour capturer les relations entre les différentes modalités.
• Garantir l'évolutivité et l'efficacité, en stockant des encastrements optimisés pour une recherche rapide dans Elasticsearch.

En adoptant cette approche, nous avons construit un pipeline de recherche multimodale robuste, dans lequel une requête textuelle peut directement récupérer des images ou du son sans prétraitement supplémentaire. Cette méthode permet d'élargir les applications pratiques, de la recherche intelligente dans les grands référentiels aux systèmes de recommandation multimodaux avancés.

La figure suivante illustre le flux de données dans le pipeline RAG multimodal, en mettant en évidence le processus d'indexation, d'extraction et de génération de réponses sur la base de données multimodales :

Comment fonctionne l'espace d'intégration ?

Traditionnellement, les enchâssements de texte proviennent de modèles de langage (par exemple, BERT, GPT). Aujourd'hui, avec des modèles multimodaux natifs comme ImageBind de Meta AI, nous disposons d'une colonne vertébrale qui génère des vecteurs pour de multiples modalités :

• Le texte: Les phrases et les paragraphes sont transformés en vecteurs de même dimension.
• Images (vision): Les pixels sont placés dans le même espace dimensionnel que celui utilisé pour le texte.
• Audio: Les signaux sonores sont convertis en enregistrements comparables à des images et à du texte.
• Cartes de profondeur: Les données relatives à la profondeur sont traitées et donnent lieu à des vecteurs.

Ainsi, tout indice(texte, image, son, profondeur) peut être comparé à un autre en utilisant des mesures de similarité vectorielle comme la similarité cosinusoïdale. Si un échantillon audio de rires et une image du visage d'un suspect sont "proches" dans cet espace, nous pouvons en déduire une certaine corrélation (par exemple, la même identité).

Étape 1 - Collecte d'indices sur la scène de crime

Avant d'analyser les preuves, il faut les collecter. Le crime commis à Gotham a laissé des traces qui peuvent être cachées dans des images, des sons, des textes et même des données de profondeur. Organisons ces indices pour qu'ils alimentent notre système.

Qu'avons-nous ?

Le commissaire Gordon nous a envoyé les fichiers suivants, qui contiennent des preuves recueillies sur la scène de crime selon quatre modalités différentes :

Description de la piste et modalité

a) Images (2 photos)

• crime_scene1.jpg, crime_scene2.jpg → Photos prises sur la scène de crime. Montre des traces suspectes sur le sol.
• suspect_spotted.jpg → Image d'une caméra de sécurité montrant une silhouette s'enfuyant de la scène.

b) Audio (1 enregistrement)

• joker_laugh.wav → Un microphone situé à proximité de la scène de crime a capté un rire sinistre.

c) Texte (1 message)

• Riddle.txt, note2.txt → Des notes mystérieuses ont été trouvées sur place, peut-être laissées par le criminel.

d) Profondeur (1 carte de profondeur)

• depth_suspect.png → Une caméra de sécurité équipée d'un capteur de profondeur a filmé un suspect dans une ruelle voisine.
• jdancing-depth.png → Une caméra de sécurité équipée d'un capteur de profondeur a filmé un suspect descendant la station de métro.

Ces éléments de preuve se présentent sous des formes différentes et ne peuvent être analysés directement de la même manière. Nous devons les transformer en encastrements, c'est-à-dire en vecteurs numériques qui permettront d'effectuer des comparaisons intermodales.

Organisation des dossiers

Avant de commencer le traitement, nous devons nous assurer que tous les indices sont correctement organisés dans le répertoire data/ afin que le pipeline fonctionne correctement.

Structure de répertoire attendue :

Code pour vérifier l'organisation de l'indice

Avant de poursuivre, vérifions que tous les fichiers nécessaires se trouvent au bon endroit.

Exécution du fichier

Résultat attendu (si tous les fichiers sont corrects) :

Résultat attendu (si un fichier est manquant) :

Ce script permet d'éviter les erreurs avant de commencer à générer des embeddings et à les indexer dans Elasticsearch.

Étape 2 - Organiser les preuves

Générer des embeddings avec ImageBind

Pour unifier les indices, nous devons les transformer en représentations vectorielles (embeddings) qui capturent la signification de chaque modalité. Nous utiliserons ImageBind, un modèle de Meta AI qui génère des embeddings pour différents types de données(images, audio, texte et cartes de profondeur) dans un espace vectoriel partagé.

Comment fonctionne ImageBind ?

Pour comparer différents types de preuves(images, audio, texte et cartes de profondeur), nous devons les transformer en vecteurs numériques à l'aide d'ImageBind. Ce modèle permet de convertir n'importe quel type d'entrée dans le même format d'intégration, ce qui permet d'effectuer des recherches intermodales entre les différentes modalités.

Vous trouverez ci-dessous un code optimisé (src/embedding_generator.py) permettant de générer des embeddings pour tout type d'entrée en utilisant les processeurs appropriés pour chaque modalité :

Un tenseur est une structure de données fondamentale dans l'apprentissage automatique et l'apprentissage profond, en particulier lorsque l'on travaille avec des modèles comme ImageBind. Dans notre contexte :

Le tenseur représente les données d'entrée (image, son ou texte) converties dans un format mathématique que le modèle peut traiter. En particulier :

• Pour les images: Le tenseur représente l'image sous la forme d'une matrice multidimensionnelle de valeurs numériques (pixels organisés par hauteur, largeur et canaux de couleur).
• Pour l'audio: Le tenseur représente les ondes sonores comme une séquence d'amplitudes dans le temps.
• Pour le texte: Le tenseur représente les mots ou les tokens sous forme de vecteurs numériques.

Test de la génération d'encastrement :

Testons notre génération d'intégration avec le code suivant. Sauvegardez-le dans 02-stage/test_embedding_generation.py et exécutez-le avec cette commande :

Résultat attendu :

L'image a été transformée en un vecteur à 1024 dimensions.

Étape 3 - Stockage et recherche dans Elasticsearch

À présent que nous avons généré les encastrements pour les éléments de preuve, nous devons les stocker dans une base de données vectorielle afin de permettre des recherches efficaces. Pour ce faire, nous utiliserons Elasticsearch, qui prend en charge les vecteurs denses (dense_vector) et permet d'effectuer des recherches par similarité.

Cette étape consiste en deux processus principaux :

• Indexation des encastrements → Stockage des vecteurs générés dans Elasticsearch.
• Recherche de similarité → Récupère les documents les plus similaires à un nouvel élément de preuve.

Indexer les preuves dans Elasticsearch

Chaque élément de preuve traité par ImageBind (image, son, texte ou profondeur) est converti en un vecteur à 1024 dimensions. Nous devons stocker ces vecteurs dans Elasticsearch pour permettre des recherches ultérieures.

Le code suivant (src/elastic_manager.py) crée un index dans Elasticsearch et configure le mapping pour stocker les embeddings.

Exécution de l'indexation

Maintenant, indexons un élément de preuve pour tester le processus.

Résultat attendu dans Elasticsearch (résumé du document indexé) :

Pour indexer toutes les preuves multimodales, veuillez exécuter la commande Python suivante :

Les preuves sont désormais stockées dans Elasticsearch et prêtes à être récupérées en cas de besoin.

Vérification du processus d'indexation

Après avoir exécuté le script d'indexation, vérifions si toutes nos preuves ont été correctement stockées dans Elasticsearch. Vous pouvez utiliser les outils de développement de Kibana pour exécuter des requêtes de vérification :

1. Vérifiez d'abord si l'index a été créé :

2. Ensuite, vérifiez le nombre de documents par modalité :

3. Enfin, examiner la structure du document indexé :

Résultats attendus :

• Un index nommé `multimodal_content` devrait exister.
• Environ 7 documents répartis entre différentes modalités (vision, audio, texte, profondeur).
• Chaque document doit contenir les champs suivants : embedding, modality, description, metadata et content_path.

Cette étape de vérification permet de s'assurer que notre base de données d'éléments de preuve est correctement constituée avant de procéder aux recherches de similitudes.

Recherche de preuves similaires dans Elasticsearch

Maintenant que les preuves ont été indexées, nous pouvons effectuer des recherches pour trouver les enregistrements les plus similaires à un nouvel indice. Cette recherche utilise la similarité vectorielle pour renvoyer les enregistrements les plus proches dans l'espace d'intégration.

Le code suivant effectue cette recherche.

Tester la recherche - Utiliser l'audio comme requête pour des résultats multimodaux

Testons maintenant la recherche de preuves à l'aide d'un fichier audio suspect. Nous devons générer de la même manière un encapsulage pour le fichier et rechercher des encapsulages similaires :

Résultats attendus dans le terminal :

Nous pouvons maintenant analyser les éléments de preuve retrouvés et déterminer leur pertinence dans le cadre de l'affaire.

Au-delà de l'audio - Explorer les recherches multimodales

Inverser les rôles : Toute modalité peut être une question ""

Dans notre système RAG multimodal, chaque modalité est une requête de recherche potentielle. Dépassons l'exemple de l'audio et explorons comment d'autres types de données peuvent déclencher des enquêtes.

1. Recherche par texte (déchiffrer la note du criminel)

Scénario : Vous avez trouvé un message texte crypté et vous souhaitez trouver des preuves connexes.

Résultats attendus :

2. Recherche d'images (suivi de la scène de crime suspecte)

Scénario : Une nouvelle scène de crime (crime_scene2.jpg) doit être comparée à d'autres éléments de preuve.

Sortie :

3. Recherche d'une carte de profondeur (poursuite 3D)

Scénario : Une carte de profondeur jdancing-depth.png() révèle les motifs d'évasion de l' image.

Sortie

Pourquoi cela est-il important ?

Chaque modalité révèle des connexions uniques:

• Texte → Modèles linguistiques du suspect.
• Images → Reconnaissance de lieux et d'objets.
• Profondeur → reconstruction dela scène en 3D.

Nous disposons désormais d'une base de données de preuves structurée dans Elasticsearch, qui nous permet de stocker et d'extraire efficacement des preuves multimodales.

Résumé de ce que nous avons fait :

• Stockage d'encastrements multimodaux dans Elasticsearch.
• Effectuer des recherches de similitudes, trouver des preuves liées à de nouveaux indices.
• Test de la recherche à l'aide d'un fichier audio suspect, afin de s'assurer que le système fonctionne correctement.

Prochaine étape : Nous utiliserons un LLM (Large Language Model) pour analyser les données extraites et produire un rapport final.

Étape 4 - Faire le lien avec le LLM

Maintenant que les preuves ont été indexées dans Elasticsearch et peuvent être retrouvées par similarité, nous avons besoin d'un LLM (Large Language Model) pour les analyser et générer un rapport final à envoyer au commissaire Gordon. Le LLM sera chargé d'identifier des modèles, de relier des indices et de suggérer un suspect possible sur la base des éléments de preuve récupérés.

Pour cette tâche, nous utiliserons le GPT-4 Turbo, en formulant une demande détaillée afin que le modèle puisse interpréter les résultats de manière efficace.

Intégration du LLM

Pour intégrer le LLM dans notre système, nous avons créé la classe LLMAnalyzer (src/llm_analyzer.py), qui reçoit les preuves extraites d'Elasticsearch et génère un rapport médico-légal en utilisant ces preuves comme contexte d'invite.

Réglage de la température dans l'analyse LLM :

Pour notre système d'analyse criminelle, nous utilisons une température modérée de 0,5. Ce cadre équilibré a été choisi pour les raisons suivantes :

• Il s'agit d'une solution intermédiaire entre les résultats déterministes (trop rigides) et les résultats hautement aléatoires ;
• À 0,5, le modèle conserve une structure suffisante pour fournir des conclusions médico-légales logiques et justifiables ;
• Ce paramètre permet au modèle d'identifier des modèles et d'établir des connexions tout en restant dans des paramètres raisonnables d'analyse médico-légale ;
• Il permet de concilier le besoin de résultats cohérents et fiables avec la capacité de générer des analyses perspicaces.

Cette température modérée permet de garantir que notre analyse médico-légale est à la fois fiable et perspicace, en évitant les conclusions trop rigides et trop spéculatives.

Effectuer l'analyse des données probantes

Maintenant que nous avons l'intégration LLM, nous avons besoin d'un script qui relie tous les composants du système. Ce script va :

• Rechercher des preuves similaires dans Elasticsearch.
• Analyser les preuves récupérées à l'aide du LLM pour produire un rapport final.

Code : Script d'analyse des preuves

Résultats attendus du LLM

Conclusion : Affaire résolue

Après avoir recueilli et analysé tous les indices, le système RAG multimodal a identifié un suspect : Le Joker.

En combinant des images, du son, du texte et des cartes de profondeur dans un espace vectoriel partagé à l'aide d'ImageBind, le système a pu détecter des connexions qu'il aurait été impossible d'identifier manuellement. Elasticsearch a permis d'effectuer des recherches rapides et efficaces, tandis que le LLM a synthétisé les données dans un rapport clair et concluant.

Cependant, le véritable pouvoir de ce système va au-delà de Gotham City. L'architecture multimodale RAG ouvre la voie à de nombreuses applications dans le monde réel:

• Surveillance urbaine : Identification des suspects à partir d'images, de sons et de données de capteurs.
• L'analyse médico-légale : Corrélation d'éléments de preuve provenant de sources multiples pour résoudre des crimes complexes.
• Recommandation multimédia : Création de systèmes de recommandation qui comprennent les contextes multimodaux (par exemple, suggestion de musique sur la base d'images ou de textes).
• Tendances des médias sociaux : Détection des sujets en vogue dans différents formats de données.

Maintenant que vous avez appris à construire un système RAG multimodal, pourquoi ne pas le tester avec vos propres indices?

Partagez vos découvertes avec nous et aidez la communauté à progresser dans le domaine de l'IA multimodale!

Remerciements particuliers

Je tiens à remercier Adrian Cole pour sa précieuse contribution et son examen au cours du processus de définition de l'architecture de déploiement de ce code.

Références

• Construire un système de recherche d'images multimodales en utilisant la recherche KNN et les encastrements CLIP
• Recherche par k-Nearest Neighbor (kNN)
• Documentation officielle de PyTorch sur les tenseurs
• ImageBind : une nouvelle façon de "relier" l'IA à travers les sens

Questions fréquentes