RAG et évaluation

Playbook RAG multimodal : documents, images et tableaux

Un guide d'architecture orienté production pour analyser, indexer, retrouver, citer et évaluer du texte, des images et des tableaux dans un système RAG multimodal.

11 avril 20265 min de lectureRAG multimodalIA documentaire

Un PDF n'est pas une suite de paragraphes propres. Il peut contenir plusieurs colonnes, des captures, des diagrammes, des notes de bas de page, des en-têtes répétés et des tableaux dont le sens dépend des lignes et des colonnes. Tout aplatir en texte brut détruit les preuves avant même la recherche. Cet article est un guide d'architecture, pas l'affirmation que j'ai livré exactement la pile technique multimodale décrite ci-dessous. Il étend la discipline de preuve et de citation présentée dans mon étude publique sur le RAG Equity Research Agent à des documents dont le sens est réparti entre texte et éléments visuels.

Préserver la structure pendant l'ingestion

Le premier objectif n'est pas le découpage en segments, mais la construction d'un modèle documentaire fiable. Pour chaque élément extrait, il faut conserver :

l'identité du document, de la page et de la section ;
le type d'élément : paragraphe, titre, image, légende ou tableau ;
la boîte englobante et l'ordre de lecture lorsqu'ils sont disponibles ;
les relations entre figures, légendes et texte voisin ;
la structure des tableaux, y compris les en-têtes et cellules fusionnées ;
la version de la source et la date d'ingestion ;
les métadonnées de contrôle d'accès.

Les PDF natifs, pages scannées, images et documents bureautiques nécessitent des chemins d'extraction distincts. L'OCR doit être une solution de repli pour les contenus image, pas un remplacement automatique du texte embarqué. La confiance d'extraction et les avertissements de l'analyseur doivent rester dans les métadonnées afin que les pages faibles soient revues ou traitées avec prudence. Les en-têtes, pieds de page et éléments de navigation répétés doivent être retirés sans perdre les titres de section. Un analyseur sensible à la mise en page peut préserver l'ordre de lecture, mais il a toujours besoin de tests sur les familles de documents importantes pour le produit.

Créer une représentation par type de preuve

Une seule représentation répond rarement à toutes les requêtes. J'utilise des vues propres à chaque élément :

texte nettoyé pour la recherche sémantique ;
Markdown structuré ou JSON pour les tableaux ;
légendes ou descriptions générées pour les images et diagrammes ;
embeddings visuels facultatifs lorsque la requête dépend de l'apparence ;
résumés compacts de la section parente pour récupérer le contexte.

L'élément original reste la source de vérité. Les descriptions générées facilitent la recherche, mais ne constituent pas une preuve faisant autorité. Leur modèle et leur version de prompt doivent être stockés afin de pouvoir les régénérer et les évaluer. Les tableaux demandent une attention particulière. Sérialiser chaque ligne peut fonctionner pour une recherche simple, alors qu'une comparaison exige souvent les en-têtes, les unités et plusieurs lignes. Il faut conserver une représentation structurée et relier chaque segment sérialisé au tableau original et à sa page.

Retrouver les candidats en plusieurs étapes

Un pipeline de recherche multimodale gagne à être séquencé :

qualifier les types de preuves probablement nécessaires ;
appliquer les filtres de client, document, date et permission ;
récupérer des candidats depuis les index texte, tableau et image pertinents ;
fusionner et dédupliquer les résultats ;
reclasser les modalités avec une politique de pertinence commune ;
enrichir les éléments retenus avec leur section parente ou leur voisinage.

Le routage ne doit pas empêcher la récupération. Une question qui semble textuelle peut finalement dépendre d'un diagramme. Une solution de repli doit pouvoir élargir la recherche lorsque la confiance est faible ou que le premier passage ne fournit pas assez de preuves. La recherche hybride reste utile. Les identifiants exacts, codes produits et libellés de tableau favorisent souvent la recherche lexicale, tandis que les questions conceptuelles bénéficient des embeddings. La politique de classement doit préserver la diversité des sources lorsque plusieurs preuves indépendantes sont requises.

Le pipeline préserve l'identité de chaque élément de l'analyse à la recherche afin que la réponse puisse pointer vers la page, la figure ou le tableau original.

Générer avec des citations précises

La génération doit recevoir un paquet de preuves compact, pas tous les candidats accumulés. Chaque élément possède un identifiant de citation stable et assez de métadonnées pour afficher une référence utile. La politique de réponse doit demander au modèle de :

distinguer les preuves explicites des interprétations ;
citer la page et l'élément qui soutiennent chaque affirmation importante ;
préserver les unités, périodes et en-têtes de tableau ;
signaler un visuel illisible ou ambigu ;
ne pas répondre lorsque le paquet de preuves est insuffisant.

Pour les workflows sensibles, un post-traitement déterministe peut vérifier que les citations existent, correspondent à des éléments réellement récupérés et respectent les contrôles d'accès. Il ne prouve pas que la réponse est juste, mais élimine plusieurs classes d'échecs évitables.

Évaluer par modalité et couche d'échec

Un score unique de qualité de réponse ne suffit pas. Les cas de test doivent couvrir :

les documents natifs et scannés ;
les pages multi-colonnes et notes de bas de page ;
les graphiques avec légendes et unités ;
les tableaux avec en-têtes fusionnés ou cellules manquantes ;
les questions nécessitant du texte et un visuel ;
les preuves contradictoires entre plusieurs pages ;
les documents contenant des erreurs d'extraction ou d'OCR.

Il faut mesurer séparément la fidélité de l'extraction, le rappel des candidats, la qualité du reclassement, la validité des citations, la qualité de la réponse sourcée et la solution de repli. Lorsqu'une réponse échoue, l'équipe doit savoir si l'analyseur a perdu le contenu, le moteur de recherche l'a manqué, le système de reclassement l'a relégué ou le modèle a mal interprété une bonne preuve. Le blueprint RAG en production détaille la même taxonomie d'échecs pour les systèmes centrés sur le texte. Le multimodal ajoute des types de preuves, mais ne supprime pas la nécessité d'isoler chaque défaillance.

Prévoir le retraitement et l'exploitation

Les analyseurs, modèles OCR, descriptions et embeddings évolueront. La lignée doit permettre de retraiter uniquement la couche affectée plutôt que de reconstruire aveuglément tout le corpus. Des index versionnés ou des alias permettent de valider un nouveau pipeline avant de basculer le trafic. La supervision couvre les échecs d'ingestion, les avertissements de l'analyseur, la fraîcheur des index, la recherche par modalité, l'utilisation des citations, la latence et les causes de repli. Les documents bruts et les contenus extraits doivent partager la même politique d'accès, y compris pour les artefacts temporaires et les traces d'observabilité. Un déploiement pragmatique commence par une ou deux familles de documents représentatives et un vrai jeu de questions. On valide l'extraction manuellement, établit les références de recherche, ajoute la génération seulement lorsque la qualité des preuves est comprise, puis élargit les modalités et formats. Dans un RAG multimodal, la fiabilité de l'ingestion n'est pas un détail de prétraitement. Elle fonde toute la qualité de réponse.

Sources et références

Documentation LlamaIndexConcepts d'indexation et de recherche multimodales
Documentation UnstructuredParsing, partitionnement et extraction des éléments documentaires
Documentation FAISSFondamentaux de la recherche vectorielle et compromis d'indexation

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

11 avril 20265 min de lectureDonnées synthétiquesFine-tuning