Pourquoi la structure des tableaux compte plus que la précision de l’OCR pour le RAG local

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

L’OCR local peut alimenter un système RAG fondé sur des tableaux, mais c’est la structure du tableau — et non la seule précision des caractères — qui détermine si un nombre récupéré conserve le sens du document original.

Un pipeline peut reconnaître correctement chaque valeur visible et produire malgré tout une réponse erronée après avoir aplati un tableau. Si « 2026 », « 412 $ » et « Ménage A » survivent à l’OCR, mais que leurs relations entre lignes et colonnes disparaissent, le modèle de langage reçoit des jetons exacts associés aux mauvais éléments de preuve.

L’OCR reconnaît les symboles, tandis que la compréhension des tableaux reconstitue les relations

L’OCR classique indique quels caractères apparaissent et, approximativement, où ils se trouvent. Un analyseur de tableaux doit accomplir une tâche plus complexe : identifier les limites du tableau, déduire les lignes et les colonnes, attribuer les en-têtes, résoudre les cellules fusionnées, conserver l’ordre de lecture et préserver les coordonnées qui relient chaque valeur à la page.

Le système de reconnaissance de tableaux Split, Embed and Merge sépare explicitement la détection de la grille du tableau de la fusion des cellules et utilise des caractéristiques visuelles et textuelles pour reconstituer les structures complexes. Sa structure de tableau fondée sur la division et la fusion montre pourquoi la reconnaissance des caractères et la récupération des relations entre lignes, colonnes et cellules sont deux problèmes différents ; l’article rapporte un score F1 de 97,11 % sur SciTSR pour sa tâche de structuration des tableaux.

Cette distinction devient particulièrement importante pour les factures, les relevés de services publics, les emplois du temps scolaires, les tableaux de médicaments et les états financiers, où un même nombre peut apparaître sur plusieurs lignes. Le traitement local évite que la page quitte le domicile, mais la localité ne rend pas pour autant une représentation aplatie sûre sur le plan sémantique.

Les en-têtes et les cellules étendues portent le sens que le système RAG doit récupérer

Une unité indexée utile doit répondre non seulement à la question « quelle valeur a été trouvée ? », mais aussi à « à quel libellé de ligne, en-tête de colonne, unité et section cette valeur appartient-elle ? ». Les en-têtes à plusieurs niveaux et les cellules fusionnées créent des relations héritées qui disparaissent lorsqu’un analyseur convertit la page en une seule ligne de texte.

Un article publié en 2026 dans PMLR sur la correction de la mise en page des tableaux a fait état d’une meilleure extraction structurée et de meilleures réponses aux questions en aval après une correction explicite de la mise en page et une conversion en représentations de type Markdown/HTML. Il s’agit d’un indicateur plus pertinent pour la qualité du RAG que la simple précision des caractères OCR, car il évalue si la structure reste exploitable pour répondre aux questions.

L’article connexe de ZimaSpace sur les relations entre les éléments des tableaux OCR présente les formes courantes d’échec. La distinction mise en avant ici dans AI Hub est architecturale : la structure du tableau doit devenir un élément de preuve indexé à part entière, et non un sous-produit accessoire de l’OCR.

Traiter un tableau comme un texte courant lors du découpage peut compromettre une extraction correcte

Même un tableau correctement reconstitué peut échouer par la suite si le découpage sépare une valeur de ses en-têtes ou dissocie un en-tête répété des lignes qu’il régit. Un système RAG adapté aux tableaux a souvent besoin de groupes de lignes, de la propagation des en-têtes, d’identifiants de tableau stables, de coordonnées sur la page et d’une représentation pouvant être récupérée comme un seul objet logique.

Les travaux T2-RAGBench de 2026 évaluent le RAG sur des textes et des tableaux, plutôt que de traiter les tableaux comme du texte courant. L’existence d’un benchmark dédié aux textes et aux tableaux reflète le problème sous-jacent : la qualité de la récupération dépend de la préservation des éléments de preuve structurés lors de l’ingestion et de la construction du contexte, et pas seulement de l’extraction des mots d’une page.

Ne créez pas de petits embeddings limités aux cellules sans contexte partagé, à moins que la couche de récupération puisse reconstituer le chemin des en-têtes de manière déterministe. Une cellule contenant « 18,4 » est rarement utile seule. L’index doit pouvoir renvoyer la valeur avec suffisamment de structure environnante pour établir ce que mesure 18,4, pour qui et sur quelle période.

Validez la fidélité structurelle avec des questions, et pas uniquement avec le pourcentage OCR

Constituez un jeu de tests à partir des tableaux les plus difficiles du foyer : en-têtes fusionnés, relevés sur plusieurs pages, numérisations orientées, lignes de grille peu visibles, unités répétées et lignes contenant des nombres similaires. Évaluez séparément la précision du texte des cellules, l’attribution des en-têtes, la correspondance entre lignes et colonnes et l’exactitude des réponses finales, afin qu’un score OCR élevé ne puisse pas masquer une défaillance structurelle.

Une analyse pratique des échecs d’extraction des cellules fusionnées montre comment les cellules fusionnées et les en-têtes à plusieurs niveaux peuvent rompre les associations entre lignes et colonnes en aval, même lorsque le texte visible est correctement reconnu. Ce sont précisément les erreurs qu’un test RAG local doit révéler avant l’indexation de milliers de documents du foyer.

Ne considérez le pipeline comme prêt que lorsque les réponses récupérées peuvent être rattachées au bon tableau, à la bonne page, à la bonne ligne, à la bonne colonne et au bon chemin d’en-têtes. Si le modèle doit deviner quel libellé correspond à une valeur, améliorez la reconstitution du tableau ou récupérez l’image de la page pour une vérification multimodale, plutôt que d’accepter un score de précision OCR trompeusement élevé.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.