Un tutoriel détaille la construction, en Python, d’un pipeline de génération augmentée par récupération (RAG) multimodal, capable de chercher et de raisonner à la fois sur le texte et sur les images extraits de documents complexes. Le principe vise les PDF qui mêlent prose, tableaux et graphiques, des formats où un RAG classique peine selon le texte.
- Le tutoriel présente un pipeline RAG multimodal en Python pour documents complexes.
- Il traite les images comme des éléments interrogeables, au même titre que le texte.
- GPT-4o décrit chaque image, et ces descriptions sont indexées dans Chroma avec le texte.
- Lors d’une requête, GPT-4o reçoit les textes et les images retrouvés pour répondre.
Le RAG consiste à retrouver des extraits d’un document pour les transmettre à un modèle de langage avant qu’il formule sa réponse. Appliqué à du texte seul, le procédé donne de bons résultats. En revanche, un découpage fondé uniquement sur le texte détruit la mise en forme des tableaux et laisse de côté les images, si bien que le système répond à partir d’une vision incomplète du document. Le pipeline décrit traite au contraire les images comme des objets interrogeables au même titre que le texte.
La réalisation s’appuie sur LangChain, sur la bibliothèque unstructured et sur l’API d’OpenAI. Le tutoriel décrit quatre étapes : analyser le document, résumer les images, stocker l’ensemble et interroger le système. Le paquet poppler-utils, dépendance système, est nécessaire à unstructured pour extraire les images des PDF.
Séparer le texte et les images
La fonction partition_pdf() d’unstructured lit le document et classe chaque élément par type : paragraphes, tableaux et images intégrées. Les images sont enregistrées dans un dossier dédié, tandis que les blocs de texte sont regroupés en fragments de 4 000 caractères au maximum, selon les titres. Une boucle sépare ensuite les fragments textuels des chemins d’accès aux images.
Une base vectorielle classique ne sait pas indexer directement une image. Chaque image est donc transmise à GPT-4o, avec la consigne « Describe this image in detail for use in a search system », afin d’obtenir une description détaillée qui sert de substitut interrogeable. Le tutoriel signale un coût à cette étape : chaque image déclenche un appel à l’API. Pour les documents contenant beaucoup de logos ou d’icônes, il suggère de filtrer les images les plus petites avant ce traitement.
Un stockage à deux niveaux
L’architecture repose sur un MultiVectorRetriever, qui gère deux espaces de stockage. Le premier, une base vectorielle Chroma, contient les fragments de texte et les descriptions d’images, transformés en vecteurs à l’aide du modèle d’embeddings text-embedding-3-small. Le second, un magasin de documents en mémoire, conserve le contenu brut. Chaque entrée est reliée à son équivalent par un identifiant unique. Une fois la recherche effectuée sur les descriptions, le système retrouve donc le fragment de texte ou le fichier image d’origine.
Lors d’une requête, la question est elle-même vectorisée et comparée aux éléments indexés. Les fragments de texte sont transmis tels quels, tandis que les images retrouvées sont ouvertes puis encodées en base64, un format de texte qui permet de les joindre à la requête. L’ensemble est envoyé à GPT-4o, qui produit une réponse fondée sur les deux types de contenus. Le tutoriel illustre la démarche par la question « What does the revenue chart show for Q3? », qui peut donc être reprise telle quelle comme exemple.
Pistes d’évolution
L’auteur mentionne plusieurs prolongements possibles : ajouter une étape de reclassement (re-ranking) pour améliorer la précision de la recherche, enregistrer la base Chroma sur disque pour un usage en production, ou explorer les modèles vision-langage comme ColPali, qui intègrent directement les pages de documents sous forme d’images et se passent ainsi de l’étape d’analyse.
