Un corpus, plusieurs représentations

Ce que les corpus industriels nous ont appris sur la manière de concevoir les représentations documentaires dans notre pipeline RAG.

Lorsqu'on construit un pipeline RAG, il est assez naturel de considérer qu'un document suit une chaîne de traitements relativement linéaire : un parser extrait le contenu d'un PDF, le convertit en Markdown, puis ce texte est découpé en chunks, transformé en embeddings et finalement utilisé pour construire le contexte envoyé au modèle.

Autrement dit, un même artefact traverse l'ensemble du pipeline. Cette manière de faire est simple et fonctionne très bien dans beaucoup de situations. Nous avons d'ailleurs commencé avec cette architecture, comme beaucoup d'autres systèmes RAG.

En pratique, cette vision fonctionne surtout lorsque l'information est essentiellement textuelle. Or, les corpus que nous manipulons chez Ask for the Moon sont rarement dans ce cas. Les documents industriels comme les normes, les notices techniques ou les dossiers d’ingénierie contiennent du texte, mais aussi des tableaux, des graphiques, des plans, des pictogrammes, des abaques, etc.

Et surtout, tous ces éléments ne jouent pas le même rôle. Certains portent directement l'information recherchée, tandis que d'autres servent plutôt à illustrer ou contextualiser un propos.

Dans ce contexte, il devient difficile de considérer qu'une représentation unique puisse convenir à toutes les étapes du pipeline.

‍

Préserver l'information importante

Ce constat fait rapidement apparaître une nouvelle question : que faut-il réellement préserver de chaque élément d’un document ?

Pour nous, ce questionnement est apparu progressivement, au fil des retours de nos utilisateurs. Un tableau mal interprété, un plan illisible, ou encore un graphique difficile à exploiter par le LLM nous ont fait réaliser qu’il fallait surtout comprendre quelle information chaque élément portait réellement, afin de déterminer ce qui devait être préservé ou non au sein du pipeline.

Pour aider à raisonner sur ces différents éléments, on peut par exemple se poser les questions suivantes :

‍

En pratique, cela peut par exemple conduire aux représentations suivantes :

‍

¹ La légende générée par le moteur d'OCR est généralement intégrée au texte du document (par exemple : « Pictogramme indiquant un risque électrique »). Elle ne constitue généralement pas un élément particulièrement pertinent pour le retrieval, mais bénéficie « gratuitement » de l'indexation du chunk auquel elle appartient.

² Selon le contexte. Par exemple, un pictogramme ou une photographie peuvent être intrinsèquement porteurs de sens, mais ce n'est pas systématique.

Ce tableau reste volontairement simplificateur. Une photographie annotée d'un équipement dans une usine, par exemple, ne doit pas forcément être traitée comme une photographie illustrative de salariés en train de discuter entre eux. Cela montre au passage à quel point une catégorisation pertinente des contenus devient importante.

Cette approche conduit cependant à une nouvelle question : si chaque élément peut donner lieu à plusieurs représentations, pourquoi ne pas toutes les produire systématiquement ?

‍

Toutes les représentations ont un coût

D'abord, parce que chaque représentation supplémentaire indexée devient un candidat potentiel lors du retrieval. Or, un moteur de recherche vectorielle ne renvoie généralement qu'un nombre limité de résultats. Décrire des logos, des pictogrammes ou des éléments purement décoratifs augmente donc le risque d'écarter des contenus réellement pertinents.

Ensuite, générer automatiquement une description pour chaque image d'un document peut rapidement devenir très coûteux, alors qu’une grande partie d'entre elles n'apporte aucune information utile. On risque donc d’augmenter le temps de traitement, le coût d'inférence, ainsi que la quantité de bruit dans les données, sans bénéfice réel pour le RAG.

Enfin, les modèles multimodaux imposent généralement une limite sur le nombre d'images qu'ils peuvent traiter efficacement. Au-delà d'un certain nombre, celles-ci sont souvent dégradées en résolution, voire ignorées. Là encore, il est clairement préférable de réserver ce budget aux éléments dont l'information visuelle est réellement importante.

Ainsi, chaque représentation consomme une ressource. L'enjeu n'est donc pas d'en produire le plus possible, mais uniquement celles dont on a réellement besoin, au bon moment.

Une conséquence sur l'architecture

Si l'on applique par exemple cette réflexion à un tableau, plusieurs représentations deviennent naturellement nécessaires.

Pour le retrieval, nous générons une description enrichie à partir du tableau et de son contexte dans le document. Son objectif n'est pas d'être fidèle au tableau original, mais de fournir au moteur de recherche vectorielle le signal sémantique dont il a besoin, notamment les concepts et le vocabulaire qui seraient susceptibles d'apparaître dans une requête utilisateur.

Une fois le tableau retrouvé, cette représentation n'a plus beaucoup d'intérêt. Le LLM reçoit alors d'autres artefacts : le tableau en Markdown pour raisonner sur les valeurs, ainsi que son image, qui permet de mieux conserver certains éléments (comme les cellules fusionnées, les annotations, les couleurs, etc.).

Cette séparation entre les représentations du retrieval et celles de la génération modifie naturellement l'architecture du pipeline : le moteur de recherche vectorielle ne renvoie plus directement le contexte envoyé au LLM, mais plutôt un identifiant d'élément documentaire, qui nous permet ensuite de récupérer les représentations adaptées à chaque usage.

Description générée
        │
        ▼
   Embedding
        │
        ▼
 Vector Search
        │
        ▼
  Identifiant
        │
        ▼
Bibliothèque d'artefacts
    ├── Markdown
    ├── Image
    ├── Métadonnées
    └── ...

Le retrieval n'a donc plus pour rôle de construire le contexte envoyé au modèle. Il sert avant tout à identifier les éléments documentaires pertinents, et les représentations adaptées à la génération sont ensuite résolues dans un second temps.

Conclusion

Cette approche rend naturellement l'ingestion plus longue et coûteuse qu'une simple chaîne « OCR → chunking → embeddings », et c'est un compromis que nous assumons. En effet, cette manière de concevoir notre pipeline s'est révélée particulièrement utile sur les corpus industriels de nos clients, où l'information est rarement uniquement textuelle. Elle nous a permis d'améliorer la qualité du retrieval, et de fournir au LLM l’information la plus ciblée et pertinente possible. Au final, cela se traduit par des réponses plus précises, y compris sur des documents particulièrement complexes.

‍