Recherche Visuelle & Analyse Différée: Optimiser les Coûts IA

Après avoir mené mes recherches sur le sujet.

À retenir

• Analyzing every page upfront is the main cost driver in most document AI budgets, with a corpus of 1 million pages costing $10,000 for Azure Layout before indexing, and 4 to 6 times more with Textract Forms and Tables.
• Visual search with ColPali/ColQwen2 replaces this ingestion cost with GPU time, reducing processing from 7.22 s/page to 0.39 s/page, or about 108 GPU-hours per million pages instead of 2,000.
• The trade-off for visual search is storage, as a full ColPali index requires about 250 GB per million pages, making quantification mandatory.
• Parse-on-retrieval inverts the economic equation for infrequently queried corpuses, costing $80 per million pages at a 2% query rate with Mistral OCR 4, compared to $4,000 for upfront analysis.

À retenir

• Analyser chaque page en amont représente le principal poste de dépense dans la plupart des budgets d'IA documentaire : au tarif Layout d'Azure (10 $ pour 1 000 pages), un corpus de 1 million de pages coûte 10 000 $ avant même d'indexer le premier vecteur, et 4 à 6 fois plus si l'on passe par Textract Forms and Tables.
• La recherche visuelle avec ColPali/ColQwen2 remplace cette facture d'ingestion par du temps GPU : 0,39 s/page contre 7,22 s/page pour un pipeline layout + OCR + captioning, soit environ 108 heures-GPU par million de pages au lieu d'environ 2 000.
• La contrepartie, c'est le stockage : un index ColPali complet nécessite environ 250 Go par million de pages (85 Go en version poolée), ce qui rend la quantification obligatoire, et non optionnelle.
• L'analyse différée (parse-on-retrieval) inverse l'équation économique lorsque seule une petite fraction du corpus est effectivement interrogée : à un taux de sollicitation de 2 % et avec Mistral OCR 4 à 4 $ pour 1 000 pages, l'extraction différée coûte 80 $ par million de pages au lieu de 4 000 $.

Faut-il arrêter d'analyser chaque page ?

Oui, pour les corpus orientés recherche documentaire dont la majorité des pages ne seront jamais lues, mais non pour tout ce qui alimente un flux transactionnel. La règle qui résiste à la modélisation des coûts est la suivante : si les champs extraits d'une page doivent être écrits dans un système de référence (lignes de facture, montants de sinistre, identifiants KYC), il faut l'analyser dès l'ingestion. Si la page n'existe que pour être retrouvable, il faut l'indexer visuellement et ne l'analyser qu'au moment de la restitution.

Ce sujet compte parce que les corpus sont fondamentalement asymétriques. Les estimations des analystes situent depuis longtemps la part des contenus non structurés entre 80 et 90 % des données d'entreprise, et une étude Splunk a montré que 55 % des données d'une organisation restent en moyenne « dormantes », collectées, stockées, jamais exploitées. Un pipeline qui effectue une analyse documentaire complète sur chaque page paie 100 % du coût d'extraction pour servir un schéma de requêtes qui ne touche qu'un pourcentage à un chiffre de l'archive. C'est exactement cet écart que la recherche visuelle exploite.

Qu'est-ce que la recherche visuelle (ColPali/ColQwen2) et pourquoi évite-t-elle l'analyse préalable ?

La recherche visuelle vectorise directement l'image d'une page rendue, sans OCR, sans détection de mise en page ni découpage textuel entre les deux. ColPali repose sur un encodeur visuel SigLIP-So400m qui produit 1 024 embeddings de patch par page (une grille de 32×32 sur une entrée 448×448), chacun projeté en 128 dimensions, et calcule la pertinence via MaxSim, en sommant la similarité maximale entre chaque token de la requête et l'ensemble des patches du document. Ce mécanisme d'interaction tardive, héritée de ColBERT, permet un appariement fin tout en restant exploitable à grande échelle.

ColQwen2 en est le successeur naturel : une extension de Qwen2-VL-2B plus précise que ColPali sur ViDoRe (+5 points de nDCG@5), sous licence permissive, et qui utilise 768 embeddings de patch au lieu de 1 024, réduisant à la fois le calcul et le stockage. Sur les benchmarks de qualité, ColPali a surpassé tous les autres systèmes évalués sur ViDoRe, y compris des références s'appuyant sur un modèle visuel propriétaire puissant (Claude Sonnet) pour légender chaque élément visuel. Point crucial : cette approche supprime le besoin de pipelines fragiles de reconnaissance de mise en page et d'OCR, en s'appuyant sur un seul modèle qui prend en compte à la fois le contenu textuel et visuel.

Que signifie concrètement l'analyse différée (parse-on-retrieval) ?

L'analyse différée signifie que l'index visuel répond à la question « quelle page ? », et que seules les pages retournées sont ensuite envoyées à un parseur ou à un modèle vision-langage pour l'extraction structurée. Un flux typique : rendu des pages → vectorisation avec ColQwen2 → stockage des multi-vecteurs → au moment de la requête, récupération des k pages les plus pertinentes via MaxSim → analyse de ces k pages en markdown/JSON → génération de la réponse avec citations renvoyant à l'image de la page.

Deux propriétés rendent cette approche viable. D'abord, la latence de recherche n'est pas le point de blocage : l'encodage d'une requête avec le modèle de langage de ColPali prend environ 30 ms, et l'opération d'interaction tardive ajoute environ 1 ms par tranche de 1 000 pages dans le corpus. Ensuite, analyser k pages plutôt que N pages fait passer l'étape coûteuse d'un coût fixe en capital à un coût marginal qui évolue avec l'usage réel. Le revers de la médaille : la première réponse porte désormais la latence d'analyse en direct, d'où l'importance d'un cache agressif, une page analysée une fois ne devrait jamais l'être une seconde. Supprimer le découpage au moment de l'ingestion élimine aussi tout un pan de travail de calibration, puisque l'unité de recherche devient simplement la page.

Combien coûtent réellement 1 million de pages selon chaque stratégie ?

Voici le modèle, pour 1 000 000 de pages, sur la base des tarifs publics affichés. Le calcul du calcul d'indexation part de la mesure de 0,39 s/page du papier ColPali sur une NVIDIA L4 (≈108 heures-GPU par million de pages), tarifée avec un coût GPU cité en référence ; à considérer comme un ordre de grandeur, pas comme un devis.

L'écart entre la première et la dernière ligne représente environ deux ordres de grandeur. À noter également qu'Azure n'offre presque aucun levier de coût sur le parcours « tout analyser » : le Read en batch est à 1,50 $/1k, le Layout en batch à 10 $, l'extraction personnalisée en batch à 30 $, il n'existe pas de remise batch, contrairement à Gemini et Mistral qui divisent par deux le coût d'inférence en batch. Pour comparer ces chiffres à vos propres volumes et taux d'erreur, Sygnet publie un calculateur de ROI sur l'économie du traitement par document.

Où part réellement l'argent dans un pipeline d'analyse exhaustive ?

Dans le prétraitement, pas dans la vectorisation. Les auteurs de ColPali ont mesuré la répartition par page : détection de mise en page 0,81 s, OCR 2,67 s, captioning 3,71 s, encodage de page 0,03 s, soit 7,22 s au total, contre 0,39 s pour ColPali de bout en bout. Des tests indépendants aboutissent à la même conclusion sous un autre angle : pour les pipelines PDF/image utilisant des outils d'OCR, la conversion de format représente en moyenne 98,2 % de la durée d'indexation, avec un taux d'utilisation GPU moyen d'environ 10 %.

C'est là l'enseignement structurel. Dans une architecture RAG centrée sur le texte, on paie, en frais d'API, en heures-GPU et en temps réel, essentiellement pour convertir des pixels en chaînes de caractères, avant de jeter la mise en page qu'on vient de payer pour détecter. Les pipelines fondés sur l'OCR échouent sur les documents d'entreprise réels parce qu'ils écartent les relations spatiales entre tableaux, graphiques et texte ; un rapport financier multi-colonnes perd la majeure partie de son information une fois aplati en simple chaîne de texte.

Quels sont les coûts cachés de la recherche visuelle ?

Le stockage et la granularité, et les deux sont quantifiables. Le stockage multi-vecteurs coûte 10 à 100 fois plus qu'un index à vecteur unique dense, car on conserve un vecteur par token ; à 10 millions de pages, l'écart entre un index à vecteur unique et un index de type ColPali se compte en dizaines de Go contre plusieurs To, avant même la réplication et les frais d'indexation. La compression est un chantier bien balisé : la quantification int8 réduit le stockage d'un facteur 4, Vespa stocke les vecteurs en int8 avec compression binaire pour une réduction de 32 fois par rapport au float, et la troncature de type Matryoshka de 1024 à 256 dimensions coûte généralement moins de 2 % de rappel tout en réduisant le stockage d'un facteur quatre.

Le second coût est architectural : la recherche de la famille ColPali s'effectue au niveau de la page. ViDoRe mesure le NDCG@5 pour la recherche au niveau page, et la recherche au niveau des régions reste largement inexplorée. On obtient « cette page est pertinente », mais ni bounding box, ni champ validé, ni score de confiance permettant un routage. Pour tout ce qui relève de l'extraction de tableaux ou d'une traçabilité auditable au niveau des champs, une étape d'analyse reste nécessaire, la seule question est à quel moment.

Dans quels cas l'ingestion complète par VLM reste-t-elle le bon choix ?

Lorsque le taux de sollicitation est élevé, que la sortie doit être structurée, ou que le flux est transactionnel. Le point d'équilibre se calcule arithmétiquement : l'analyse différée l'emporte tant que (pages récupérées × prix d'analyse à la demande) < (toutes les pages × prix d'analyse en batch). Avec Mistral OCR 4 à 4 $/1 000 pages en standard et 2 $/1 000 en batch, ce point d'équilibre se situe à un taux de sollicitation de 50 %. Au-delà, il vaut mieux tout analyser dès l'ingestion et profiter de la remise batch.

Trois autres cas imposent une ingestion complète, indépendamment du calcul : (1) les flux réglementés où chaque page doit être classée et conservée sous forme extraite ; (2) le traitement automatisé de bout en bout (straight-through processing), où les champs sont écrits directement dans un ERP ou un système de gestion des sinistres sans intervention humaine ; (3) les corpus où les mêmes pages sont consultées en permanence, les analyses mises en cache s'amortissent instantanément. L'article de Sygnet sur OCR vs VLM détaille précisément où chaque classe de moteur atteint ses limites. En pratique, la plupart des entreprises adoptent un modèle hybride : extraction complète sur les 5 % transactionnels (factures, sinistres, dossiers d'entrée en relation), index visuel plus analyse différée sur les 95 % archivistiques.

FAQ

ColPali est-il moins coûteux que l'OCR à grande échelle ?

À l'ingestion, oui, nettement. En supprimant la détection de mise en page, l'OCR et le captioning, l'indexation par page passe de 7,22 s à 0,39 s sur le même matériel NVIDIA L4, soit une réduction de calcul d'environ 18 fois, et une analyse indépendante réalisée sur le cloud GPU affirme que l'auto-hébergement de ColQwen2.5 pour l'indexation revient 37 fois moins cher par page qu'Azure Document Intelligence. Mais on paie ensuite en stockage de l'index, environ 250 Go par million de pages non poolées, donc le coût total de possession dépend surtout de la facture de base de données vectorielle, pas uniquement des heures-GPU.

De combien de stockage un index ColQwen2 a-t-il besoin par million de pages ?

Environ 190 Go en précision 16 bits. ColQwen2 découpe chaque page en 768 tokens de 128 dimensions ; stockés en flottant 16 bits, un document de 50 pages consomme 9,6 Mo, soit environ 192 Ko par page. La quantification int8 ramène ce chiffre à près de 48 Go, et la compression binaire utilisée par Vespa réduit l'empreinte d'un facteur 32 par rapport au flottant, pour atteindre environ 6 Go par million de pages, au prix d'une perte de rappel modeste.

L'analyse différée nuit-elle à la qualité des réponses ?

Pas pour la précision de la recherche, et elle peut même améliorer la qualité de l'extraction. La recherche visuelle trouve la bonne page sans passer par un point de défaillance lié à l'OCR, le modèle lit la page comme le ferait un humain, sans étape d'OCR susceptible d'échouer ni de détection de mise en page confondant un résumé multi-colonnes avec un encadré latéral. Le risque de qualité se déplace vers l'étape d'analyse, qui s'exécute désormais sur bien moins de pages et peut donc recourir à un modèle plus coûteux et plus précis, qu'on ne pourrait pas se permettre sur l'ensemble du corpus.

Quelle taille de corpus justifie la recherche visuelle ?

En dessous de quelques milliers de pages, cela ne fait guère de différence. Sous les 1 000 pages, l'usage mémoire se compte en mégaoctets et l'indexation se termine en quelques minutes ; le choix doit alors privilégier la qualité de recherche et l'infrastructure disponible plutôt que l'efficacité. L'économie devient déterminante entre plusieurs centaines de milliers et plusieurs millions de pages, là où la taille de l'index décide si l'ensemble tient sur un seul nœud ou nécessite un stockage distribué, et là où une décision d'ingestion à 10 $/1 000 pages se transforme en engagement à cinq ou six chiffres.