Proxy-Pointer RAG : Réponses multimodales sans embeddings

Proxy-Pointer RAG : Des réponses multimodales sans embeddings multimodaux

Modèle de Langage Large

Proxy-Pointer RAG : Réponses multimodales sans embeddings multimodaux

Une image vaut mille mots. Pourtant, très peu de chatbots d'entreprise peuvent renvoyer de manière fiable des images ancrées dans leurs documents sources.

La raison en est que, bien que cela constituerait une amélioration significative par rapport à une expérience utilisateur uniquement textuelle, il est difficile de le faire de manière fiable et cohérente. Cependant, il existe de nombreux cas d'utilisation où cela serait inestimable. Des clients de projets immobiliers aux techniciens de service interrogeant sur les derniers paramètres de machine, les utilisateurs préféreraient voir les images de propriétés ciblées et les tableaux de maintenance comme partie intégrante de la réponse. Au lieu de cela, le mieux que nous puissions faire est de fournir une réponse avec des liens vers les documents sources (brochures, vidéos, manuels) et des pages web.

Dans cet article, je vais présenter un pipeline Proxy-Pointer RAG multimodal open-source, qui peut réaliser cela, principalement parce qu'il considère un document comme un arbre hiérarchique de blocs sémantiques, plutôt que comme un ensemble de mots à déchiqueter aveuglément en morceaux pour répondre à une requête.

Difficultés des réponses multimodales

Pourquoi la réponse multimodale est-elle un problème difficile à résoudre ? Quelles sont les techniques actuelles qui peuvent être appliquées ?

Lorsque nous pensons à RAG multimodal, cela signifie presque toujours que vous pouvez rechercher dans la base de connaissances en utilisant des images ainsi qu'une requête textuelle. Il est rare que ce soit l'inverse. Pour comprendre les raisons, examinons les approches possibles généralement utilisées :

• Légendage d'image : Exécuter un modèle OCR/Vision sur les images, transformer l'image en un paragraphe de texte et l'indexer dans un morceau avec d'autres textes. Ce n'est pas idéal, car le découpage en fenêtres glissantes peut entraîner une séparation de la légende de l'image à travers les morceaux.

Le problème central est un désalignement entre les unités de récupération et les unités sémantiques. Le RAG traditionnel récupère des morceaux arbitraires, tandis que le sens — et surtout les images — appartient à des sections cohérentes d'un document.

Lorsque qu'un morceau est récupéré, le LLM peut ne voir qu'une légende partielle (par exemple, pour la Figure 5), rendant difficile la détermination de la pertinence de l'image par rapport à ce morceau ou à un autre adjacent qui n'a pas été récupéré. De plus, le synthétiseur reçoit souvent plusieurs morceaux de différents documents sans contexte partagé, pouvant contenir plusieurs légendes d'images non liées. Cela complique la tâche du LLM pour décider de manière fiable quelles images, le cas échéant, sont pertinentes pour la requête de l'utilisateur.

• Embedding multimodal : Une autre approche consiste à intégrer à la fois des images et du texte dans un espace vectoriel partagé à l'aide d'un modèle multimodal. Bien que cela permette la récupération inter-modale, cela introduit un défi différent. Les embeddings multimodaux optimisent la similarité, pas l'ancrage. Des artefacts visuellement ou structurellement similaires — tels que des tableaux financiers de différentes entreprises — peuvent apparaître presque identiques dans l'espace vectoriel, même lorsque seul l'un est pertinent pour la requête.

Sans le contexte de la structure du document, le système récupère des candidats basés sur la similarité mais ne peut pas déterminer avec confiance quelle image appartient réellement à la réponse. Par conséquent, le LLM est contraint de choisir entre plusieurs visuels plausibles mais potentiellement incorrects — il est souvent plus sûr de ne rien montrer plutôt que de risquer de montrer le mauvais.

Architecture Proxy-Pointer

Le Proxy-Pointer résout cela en remplaçant le découpage basé sur le texte par un découpage basé sur un arbre. Nous ne découpons pas par nombre de caractères ; nous découpons par Limites Sectionnelles. Si une section contient 3 paragraphes et 2 images, aucun des morceaux ne dépasse et ne déborde dans la section suivante. Le LLM peut considérer chaque section comme une unité sémantique entièrement indépendante et peut juger des images qui s'y trouvent avec confiance.

J'ai construit un chatbot multimodal sur 5 articles de recherche en IA (tous sous licence CC-BY). Il s'agit de CLIP, Nemobot, GaLore, VectorFusion et VectorPainter. Pour l'extraction de PDF, l'API Adobe PDF Extract a été utilisée. Comme on peut s'y attendre, les articles contiennent un texte dense ainsi qu'un total de 270 images (figures, tableaux, formules) entre eux, qui ont pu être extraites par Adobe. Le modèle d'embedding utilisé est gemini-embedding-001 (avec des dimensions réduites à 1536 par rapport au 3072 par défaut, ce qui rend la recherche plus rapide et réduit l'utilisation de la mémoire). C'est un modèle d'embedding uniquement textuel. Aucun modèle d'embedding multimodal n'est utilisé. Pour tous les usages du LLM (filtre de bruit, re-ranker, synthétiseur et filtre visuel final), gemini-3.1-flash-lite-preview est utilisé. L'index vectoriel utilisé est FAISS.

Pipeline de récupération multimodale

Pour la sortie multimodale, nous modifions les étapes du pipeline avec le principe suivant : les images (figures, tableaux, formules, clips vidéo, etc.) peuvent être extraites en tant que fichiers artefacts (.jpg, .png, .svg, .mp4, etc.) et stockées aux côtés du contenu du document. Cela est assez simple si le document source est une page web ou un XML. Pour les PDF, bien que ce ne soit pas parfait, un extracteur tel que l'API Adobe PDF Extract, utilisé ici, peut extraire les tableaux et figures en tant qu'artefacts.

Dans le document extrait lui-même, qui dans notre cas est un markdown, chaque figure est présente sous forme de chemin relatif, par exemple ; ![](figures/fileoutpart11.png) dans le texte, ce qui pointe vers le nom de fichier réel.

De plus, inspiré par le puzzle Tangram qui forme différents objets à l'aide d'un ensemble d'éléments de base, nous reformulons la tâche de synthèse comme un réarrangement d'un ensemble de traits extraits de l'image de référence.

Voici le pipeline d'indexation :

• Arbre Squelette : Comme auparavant, nous analysons les titres Markdown en un arbre hiérarchique avec du python pur. Seulement maintenant, un tableau de figures est imbriqué dans chaque nœud, notant chaque figure trouvée dans ce nœud (section) avec son chemin. Le chemin est utilisé pour récupérer le fichier image pour l'affichage.

Les 4 étapes suivantes restent essentiellement les mêmes qu'auparavant :

• Injection de Breadcrumb : Préfixer le chemin structurel complet à chaque morceau avant l'embedding.

• Découpage Guidé par la Structure : Diviser le texte à l'intérieur des limites de section, jamais à travers elles.

• Filtrage de Bruit : Supprimer les sections distrayantes (table des matières, glossaire, résumés exécutifs, références) de l'index à l'aide d'un LLM.

• Contexte Basé sur les Pointeurs : Utiliser les morceaux récupérés comme pointeurs pour charger la section complète et intacte du document (qui contient maintenant des chemins d'image dans le texte) pour le synthétiseur.

Le pipeline de récupération mis à jour pour la récupération multimodale est le suivant :

• Étape 1 (Rappel Large) : FAISS renvoie les 200 meilleurs morceaux par similarité d'embedding. Ceux-ci sont dédupliqués par (doc_id, node_id) pour garantir que nous examinons des sections de documents uniques, résultant en une liste restreinte des 50 meilleurs nœuds candidats.

• Étape 2 (Re-Ranking Structurel Sensible aux Ancres) : Le re-ranker reçoit maintenant le chemin complet de breadcrumb + un extrait sémantique (150 caractères) pour chacun des 50 candidats.

• Étape 3 (Synthèse et Sélection d'Image Sensible au Contexte) : Le Synthétiseur LLM examine les 5 sections finales et forme la réponse textuelle. De plus, il prend la décision visuelle sur les images trouvées pour déterminer lesquelles doivent être affichées.

Le pipeline ci-dessus est capable de fournir 95% de précision pour les récupérations d'images sur le benchmark de 20 questions que j'ai créé, jugé par Claude. Les résultats complets sont disponibles dans le dépôt. Si vous souhaitez affiner encore plus les résultats, l'étape suivante est un filtre visuel optionnel.

• Étape 4 (Filtre Visuel — optionnel) : Pour des raffinements supplémentaires des images sélectionnées, une étape de sélection visuelle optionnelle peut être activée dans config.py. Ici, le LLM est invité à voir réellement les 6 images.