- Pour extraire des informations de documents complexes, les approches traditionnelles basées sur l’OCR et le parsing ne préservent pas correctement le sens
- Morphik met en œuvre une méthode de visual document embedding fondée sur le modèle ColPali, capable de comprendre directement les tableaux, les graphiques et le contexte de mise en page
- Par rapport aux pipelines existants, cette approche est nettement supérieure en précision et en préservation de l’information, avec jusqu’à 95,56 % de précision dans les benchmarks
- En outre, l’introduction de MUVERA et Turbopuffer a permis des gains de vitesse dans la recherche documentaire à grande échelle
- À l’avenir, l’objectif est d’automatiser concrètement le travail documentaire avec le raisonnement multi-documents, l’intégration aux workflows et une interprétation de niveau expert
Les limites du parsing de documents complexes et les difficultés du RAG
- Lorsqu’on cherche à extraire des informations de documents PDF complexes mêlant graphiques, schémas et tableaux, les pipelines OCR et parsing perdent souvent les informations recherchées
- Les limites des pipelines traditionnels apparaissent clairement dans des cas réels comme les tableaux imbriqués, les schémas essentiels, les documents techniques très annotés, voire les manuels sans texte
- Étapes d’un pipeline traditionnel :
- Application d’un OCR au PDF (avec risque de mauvaise lecture des chiffres ou des caractères)
- Tentative de distinguer tableaux et schémas via un modèle de détection de mise en page (avec un taux d’échec élevé)
- Reconstruction de l’ordre de lecture (au risque de perdre le flux visuel)
- Reconnaissance des légendes de figures (avec perte fréquente de nuances)
- Découpage du texte en chunks (des informations liées peuvent être séparées)
- Création d’embeddings vectoriels et stockage dans une vector DB (avec perte de la position et du contexte)
- Exemple : même un tableau simple peut voir
1,000 lu comme l,0O0, ou le tableau séparé de son en-tête, empêchant de calculer correctement le total
- Les cas réels de perte d’information sont fréquents, par exemple une légende de graphique interprétée comme du texte principal ou des pourcentages dispersés au mauvais endroit
Une nouvelle approche : passer à la compréhension visuelle des documents
- L’équipe de Morphik a trouvé un point de bascule en se demandant : « Et si l’on comprenait les documents comme des objets visuels, à la manière des humains ? »
- Grâce aux recherches récentes (ColPali) et aux progrès des Vision Language Models (VLM), il devient possible d’embedder directement des images pour préserver tout le contexte documentaire et les informations visuelles, sans parsing ni OCR
- Chaque page du document est traitée comme une image haute résolution, puis découpée au niveau des patches afin de générer des embeddings intégrant à la fois les informations visuelles et textuelles
- Le Vision Transformer SigLIP-So400m génère les embeddings des patches visuels, tandis que le modèle de langage PaliGemma-3B comprend la structure du document
- Pour une requête (« évolution du chiffre d’affaires au T3 », par exemple), un mode de recherche en late interaction permet d’extraire précisément les informations pertinentes, y compris les indices visuels comme le texte, les graphiques, les tableaux et les couleurs
- La position dans le document, la mise en page, les couleurs, les variations de graphique et toutes les autres informations visuelles sont conservées — d’une manière proche de la vision globale qu’a un humain sur un document
Comparaison entre le parsing traditionnel et l’approche ColPali
- Dans un pipeline classique fondé sur le parsing, l’information se perd à chaque étape, et les embeddings texte/image étant séparés, il devient impossible d’interpréter les relations spatiales dans le document
- À l’inverse, l’approche ColPali intègre toutes les informations dans un unique espace d’embedding visuel, ce qui préserve le sens global et le contexte du document
- Dans des benchmarks réels (centrés sur des documents financiers, avec jeux de données publics), Morphik (basé sur ColPali) a atteint jusqu’à 95,56 % de précision (contre 72 % pour LangChain + OpenAI text-embedding, et seulement 13,33 % pour la recherche de fichiers OpenAI)
- Dans le benchmark ViDoRe, l’approche visuelle a obtenu une performance supérieure de plus de 14 points de pourcentage en nDCG@5 par rapport aux méthodes traditionnelles de parsing
Optimisation des performances et usage en conditions réelles
- Le défaut de l’approche initiale était une baisse de vitesse due à la charge de calcul, car sa structure nécessitait une recherche vectorielle pour chaque patch, ce qui la rendait inadaptée à des dizaines de millions de requêtes par seconde
- En s’appuyant sur l’article MUVERA, l’équipe a introduit une méthode remplaçant la recherche multi-vecteurs par une recherche à vecteur unique (encodage à dimension fixe)
- Combinée à la vector DB spécialisée Turbopuffer, cette approche a permis de faire passer la latence des requêtes de 3 à 4 secondes à environ 30 ms
- Il devient ainsi possible de rechercher dans des millions de documents à une vitesse largement supérieure à celle du parsing textuel classique
Cas d’usage et API simple à utiliser
- Prise en charge d’une recherche très précise sur différents types de documents, sans perte de structure visuelle ni d’information
- Documents financiers où tableaux et graphiques complexes sont essentiels
- Manuels techniques centrés sur des schémas
- Extraction d’informations fondée sur la mise en page dans les factures et reçus
- Compréhension des visuels et données chiffrées dans les articles de recherche
- Reconnaissance de relations fondée sur la mise en page dans les dossiers médicaux
- L’API repose sur une structure très simple : on charge un document puis on pose une question en langage naturel, avec la prise en charge de requêtes comme « montre-moi tous les contrats comportant une clause d’amende supérieure à 10 000 dollars »
Orientation future : intelligence multi-documents et compréhension plus profonde
- Intelligence multi-documents : développement en cours de fonctionnalités de référence croisée et de suivi d’information entre plusieurs documents
- Au-delà de la recherche dans un document unique, prise en charge du suivi des relations et du raisonnement entre plusieurs documents (par exemple : clause contractuelle → document réglementaire → manuel d’exécution)
- Système de compréhension agentique : au-delà du simple question-réponse sur un document, automatisation du raisonnement logique entre chunks comme l’extraction de clauses → la vérification dans d’autres documents → le contrôle croisé des détails
- Intégration aux workflows : amélioration d’une intelligence documentaire adaptée aux processus métier, comme la comparaison de conditions entre plusieurs contrats ou le suivi de l’historique des décisions techniques
Limites et objectifs à venir
- L’approche actuelle n’atteint pas encore le niveau d’interprétation experte et de jugement contextuel
- Des aspects comme l’interprétation approfondie d’un expert financier restent encore techniquement insuffisants, et des développements supplémentaires sont nécessaires pour répondre aux exigences enterprise en matière de fiabilité et de quantification de l’incertitude
- La combinaison de la compréhension visuelle avec des graphes de connaissances métier, le raisonnement causal et la fourniture d’indicateurs de fiabilité constituent les principaux chantiers à venir
Conclusion
- Les documents doivent être traités comme des objets de connaissance visuels, et au-delà des limites du parsing, la compréhension documentaire fondée sur l’image constitue une meilleure solution dans un environnement RAG
- Morphik veut proposer un nouveau standard pour l’extraction d’information documentaire, avec pour objectif l’automatisation de workflows documentaires complexes et leur application concrète en entreprise
- Une présentation détaillée des fonctionnalités est disponible sur morphik.ai
1 commentaires
Commentaire sur Hacker News
Il y a plusieurs problèmes fondamentaux que les gens devraient absolument connaître
Les LLM sont généralement préentraînés sur environ 4k tokens de texte, puis étendus à de longues fenêtres de contexte (passer de 4000 à 4001 est facile, mais c’est impossible avec les images car la tokenisation fonctionne différemment)
Résultat, on sort de la distribution, et les hallucinations deviennent graves dès qu’on traite plus de deux ou trois images
Un PDF en résolution 1536×2048 consomme 3 à 5 fois plus de tokens que du texte, ce qui augmente le coût d’inférence et ralentit les réponses
Si on baisse la résolution, l’image devient floue
Les images sont lourdes par nature, donc le simple fait de télécharger les images nécessaires ajoute de la latence à chaque requête
Sur de petits benchmarks, cela fonctionne naturellement mieux qu’un simple chunking de texte pour des documents financiers riches en graphiques et en tableaux
Personnellement, j’aimerais comparer avec quelque chose comme Gemini en lui permettant d’annoter les images via OCR
Une approche end-to-end basée sur l’image a du sens dans des cas particuliers (brevets, diagrammes d’architecture, etc.), mais c’est vraiment une solution de dernier recours
Le problème, c’est que les LLM ont tendance à inventer un texte plausible dans les zones qu’ils ne parviennent pas à lire, ce qui peut empirer le résultat
Par exemple, GPT4.1 fonctionnait parfaitement sur une capture d’écran de taille 1296×179, mais en la réduisant à 50 % pour obtenir 650×84, il a renvoyé "A PNG at 512x 2048 is 3.5k more tokens" à la place de "Pdf's at 1536 × 2048 use 3 to 5X more tokens"
La majeure partie est correcte, mais il faut faire attention à ce genre de détails subtils qui changent
Une propriété intéressante de la famille gemma3 est que l’augmentation de la taille de l’image en entrée n’accroît pas les besoins en mémoire de traitement
C’est parce que l’encodeur de deuxième étape compresse en tokens de taille fixe
En pratique, c’est très utile
Mais cela obligerait l’ensemble des documents traités à passer par un gros VLM
Cela peut devenir beaucoup trop coûteux et trop lent
Il y a clairement un arbitrage ici
Dans la plupart des cas, la méthode actuelle était la plus efficace
On voit des cas où tout est envoyé dans un LLM, mais selon la situation, ce n’est pas forcément adapté
Tout n’a pas besoin d’être traité par un LLM
Je pense que cela pourrait s’étendre en une idée qui change le pipeline RAG
Pour chaque résultat RAG, on pourrait utiliser une étape de traitement par le modèle pour extraire depuis l’image les informations directement liées à la requête utilisateur, puis agréger ces résultats (texte) comme entrée de la génération finale
Cela permettrait de contourner les limites de tokens sur plusieurs images et de paralléliser la compréhension visuelle
Mes collègues et moi avons essayé une implémentation de ce type il y a 6 mois pour une agence gouvernementale française
Nous l’avons publiée en open source ici : https://github.com/jolibrain/colette
Ce n’est pas notre activité principale et le projet est un peu laissé à l’abandon, mais avec un peu de tuning, cela fonctionne plutôt efficacement
Le vrai intérêt, c’est qu’on peut rendre tout le pipeline entièrement différentiable et fine-tuner viz rag pour le spécialiser sur un dataset donné
On peut aussi personnaliser le modèle de layout pour une compréhension documentaire très fine
Dans les cas ordinaires, le principal obstacle est le besoin d’un jeu d’évaluation de haute qualité (comme toujours)
Nous avons mené plusieurs études de benchmark OCR vs image + LLM généraliste : https://getomni.ai/blog/ocr-benchmark
Le plus gros problème des approches d’extraction directe depuis l’image, ce sont les documents multipages
Sur une seule page, le direct image était légèrement meilleur (OCR=>LLM vs Image=LLM), mais au-delà de 5 images, la précision chute fortement par rapport à une approche OCR-first
En réalité, le rappel long contexte en texte est déjà un problème difficile, même si les LLM sont optimisés pour cela, alors que le rappel long contexte sur images reste encore très insuffisant
Ajouter une petite couche de transformation LLM directement sur l’image est aussi assez efficace (c’est-à-dire, au lieu de faire de l’OCR direct, envoyer 5 images à la fois à un petit modèle de vision pour n’en extraire que les points les plus importants du document)
En ce moment, nous étudions aussi des modifications du cache ou des attention maps des LLM pour mieux faire fonctionner de plus gros lots d’images
Des approches comme la sliding window ou l’infinite retrieval semblent prometteuses
C’est une intuition personnelle, mais vu l’accélération des progrès des modèles multimodaux, je pense que le long contexte image ne sera bientôt plus un gros problème
Ce billet de blog soulève de bons points sur l’utilisation de modèles de vision pour la retrieval, mais je voudrais signaler quelques problèmes
Le parsing de documents consiste à transformer un document en texte structuré comme du Markdown/JSON (ou, pour l’extraction, un output conforme à un schéma)
Le RAG n’est qu’un de ces usages parmi d’autres
ColPali est excellent pour la retrieval, mais il n’est pas utilisable pour du pur parsing de documents (du moins pas nativement)
L’auteur mentionne surtout des benchmarks de retrieval visuelle
Cela fonctionne souvent mieux que l’OCR standard, mais
a. il reste des problèmes de précision sur la longue traîne
b. on perd les métadonnées comme les confidence scores, bounding boxes, etc.
c. le pipeline de capture d’écran lui-même demande aussi des efforts si on veut le rendre sophistiqué
Les tokens image sont beaucoup plus puissants, mais les tokens texte coûtent beaucoup moins cher à stocker, ce qui permet d’interroger le document entier lors de la retrieval (et pas seulement des chunks)
(Pour référence : je suis le CEO de llamaindex et j’ai travaillé à la fois sur le parsing et la retrieval avec LlamaCloud ; c’est juste un point de vue général)
L’an dernier, j’ai passé pas mal de temps à construire un système d’analyse de documents de brevets
Les brevets contiennent toutes sortes de contenus, comme des diagrammes abstraits, des formules chimiques et des équations, donc préparer les données pour les LLM est vraiment délicat
La méthode la plus simple que j’ai trouvée consistait à convertir chaque page comme si on la “photographiait”, puis à demander au LLM de générer un JSON décrivant son contenu avec des métadonnées (numéro de page, nombre d’éléments visuels, etc.)
Pour les images complexes, on peut simplement demander au modèle de les décrire
Cela permet ensuite d’embedder facilement le JSON dans le vector store souhaité
Il est difficile d’évaluer l’efficacité coût/résultat, mais cette méthode est plus simple et plus efficace que celle proposée par l’auteur
Par exemple, même si le modèle extrait correctement la plupart des couples x, y dans un graphique, si l’utilisateur interroge une valeur x/y précise, il peut passer à côté
Si on montre directement l’image au moment de l’inférence, l’approche est plus efficace car le modèle peut répondre exactement à ce que demande l’utilisateur
Le seul véritable obstacle ici est la qualité de la retrieval, et c’est un problème relativement limité
Autrement dit, si on transmet bien le bon contexte, le LLM peut gérer le reste
Sinon, le nombre de problèmes à traiter explose vite : OCR, parsing, description d’images, etc.
Mais cela montre aussi que l’opportunité des LLM se concentre sur la reclassification et le retraitement d’une valeur existante (comme les documents de brevets)
Dans les années 90-2000, les éditeurs logiciels ont réussi en transformant des documents papier existants en bases de données
Créer dès le départ de nouveaux jeux de données réellement précieux demande toujours énormément d’investissement et d’efforts
D’après mon expérience, cette approche n’est pas terrible
Selon la police, il peut être difficile de distinguer le o et le 0
Convertir un document (doc/xls/pdf/html) en image fait perdre ce type d’information discriminante
Pour des numéros de série, même un humain peut parfois ne pas réussir à faire la différence à l’œil
Donc, pour les PDF, il est assez raisonnable d’extraire en rendant l’image
Pour les autres formats, il vaut mieux parser directement le document
Cela dit, en pratique, pour concevoir la mise en page d’une page, montrer la véritable image au modèle est bien plus efficace pour le débogage que de ne lui donner que le code
Les problèmes du type 1 vs I ou 0 vs O existent réellement, mais j’ai souvent constaté qu’avec des documents riches en diagrammes et en graphiques, le traitement uniquement par image était bien plus simple
(Il y a peut-être un biais de sélection)
J’ai essayé pendant plusieurs minutes de copier un planning dans Gemini puis de l’interroger, mais même en HTML cela ne marchait pas correctement
Au final, j’ai pris une capture d’écran, masqué les parties inutiles avec des rectangles noirs, envoyé l’image, et cela a très bien fonctionné
Je suis curieux, car il me semble que le multimodal RAG résout déjà ce problème
J’obtiens des résultats d’analyse d’image assez satisfaisants avec Flash 2.5, Sonnet 3.7, etc.
J’ai même l’impression d’obtenir de meilleures réponses avec des images qu’avec du texte
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Mais les multivecteurs à l’état brut (la base du multimodal RAG) sont très difficiles à manipuler au départ, et le calcul de similarité est extrêmement coûteux, ce qui complique fortement le passage à l’échelle
Il faut de la quantification, une conversion en vecteur unique (encodage à dimension fixe), des optimisations d’indexation, etc.
C’est exactement ce que nous faisons chez Morphik
J’ai moi aussi essayé de scanner toutes mes factures d’un coup en extrayant simplement les pièces jointes de ma boîte mail, puis en exécutant un script qui les envoie une par une pour extraire “facture : oui/non”, ainsi que chaque poste, le nom du fournisseur, la date, le numéro de facture, etc.
Au final, le taux de lecture était bon, et même si cela a pris plus de 3 heures d’appels LLM, c’était automatisé donc cela ne me dérangeait pas
Ensuite, j’ai aussi demandé au LLM de faire la correspondance avec les relevés bancaires, et seules quelques factures non envoyées en pièce jointe ont manqué
En revanche, l’appariement facture-relevé a été assez médiocre de la part du LLM (s’il y avait seulement quelques dollars d’écart, il répondait quand même que c’était ce relevé)
Donc il semble qu’un comptable reste nécessaire pour l’instant
Je n’avais pas vraiment estimé le coût, et j’utilisais un modèle peu cher comme Claude 3.7
Je comprends pourquoi ColPali paraît intuitif et puissant, mais le traitement documentaire conserve quand même certains avantages