Document - Vérité terrain de l’IA au-delà de l’OCR : ordre de lecture, tableaux, champs et relations entre pages

Les systèmes d’IA documentaire vont au-delà de l’OCR : ils doivent extraire la structure et les relations qui rendent une page exploitable. Pour les équipes qui construisent des jeux de données d’entraînement pour l’IA, un modèle peut transcrire correctement chaque mot et malgré tout échouer à répondre aux exigences du flux de travail pour lequel il a été conçu.

Une facture peut contenir le bon montant mais l’associer à la mauvaise ligne de facture. Un rapport à deux colonnes peut contenir chaque phrase tout en assemblant les colonnes dans le mauvais ordre. Un tableau peut conserver la valeur de chaque cellule mais placer une valeur sous le mauvais en-tête. Il s’agit d’erreurs de compréhension de documents que le taux d’erreur de caractères ou le taux d’erreur de mots ne suffit pas, à lui seul, à détecter.

C’est pourquoi la vérité terrain pour l’IA documentaire doit aller au-delà du texte vérifié. Si l’application dépend de l’ordre de lecture, de la topologie des tableaux, des relations entre champs ou de la continuité entre les pages, le jeu de données de référence doit contenir des étiquettes pour ces relations afin que chaque relation puisse être évaluée séparément.

La distinction ne tient pas au fait que l’OCR moderne se limite au texte brut. Les systèmes actuels tels que Google Cloud Document AI peuvent renvoyer du texte OCR, des coordonnées et des signaux de mise en page. Une distinction plus utile est celle entre la précision de reconnaissance de texte et la précision structurelle : une métrique de transcription peut indiquer si les mots ont été reconnus, mais pas si les relations documentaires nécessaires à la tâche ont été reconstruites correctement.

La vérité terrain de Document AI désigne des données de référence vérifiées utilisées pour entraîner ou évaluer des systèmes qui convertissent des documents en informations structurées. Selon la tâche, elle peut inclure le texte OCR et les régions de mise en page, l’ordre de lecture, la structure de tableau, les champs nommés, les relations clé-valeur, les classes de documents, les limites de page et les liens entre pages.

La vérité terrain doit correspondre à la sortie évaluée. Si un modèle est censé reconstituer la hiérarchie d’un tableau, associer un champ à sa valeur ou joindre un tableau à cheval sur un saut de page, une transcription vérifiée est nécessaire mais pas suffisante. L’ensemble d’évaluation doit enregistrer la relation elle-même.

C’est aussi pourquoi l’expression « précision de l’OCR » exige de la prudence. Le taux d’erreur sur les caractères (CER) et le taux d’erreur sur les mots (WER) mesurent le texte reconnu par rapport à une transcription de référence. Ils sont utiles pour la qualité de l’OCR, mais ils ne permettent pas de savoir si un montant correctement reconnu a été affecté au bon champ ou si des blocs correctement reconnus ont été placés dans la bonne séquence.

L’ordre de lecture semble trivial dans une lettre à une seule colonne. Il devient un problème d’annotation à part entière dès qu’une page contient deux colonnes, une barre latérale, une citation en exergue, une note de bas de page, une légende flottante ou un formulaire avec plusieurs groupes alignés.

Les données de référence ont donc besoin d’une unité d’ordonnancement explicite. Un projet peut ordonner des blocs, des régions, des lignes ou une autre unité de mise en page, mais la règle doit être fixée avant le début de l’annotation de production. Sinon, deux relecteurs attentifs peuvent être en désaccord tout en croyant tous deux suivre « l’ordre de lecture naturel ».

Des recherches récentes traitent l’ordre de lecture comme une tâche mesurable plutôt que comme un sous-produit informel de la détection de mise en page. LaTeX2Layout, publié à AAAI 2026, reconstruit à la fois les régions de mise en page et l’ordre de lecture à partir des traces du compilateur et évalue la concordance des séquences à l’aide du tau de Kendall, séparément de l’ancrage des éléments. ROOR annote également l’ordre de lecture sous forme de relations d’ordonnancement explicites plutôt que de supposer que les boîtes de régions impliquent une séquence.

La même tendance apparaît dans des benchmarks plus récents de documents visuellement riches. MosaicDoc, également publié à AAAI 2026, combine des annotations d’OCR, d’ordre de lecture, de localisation et de réponse aux questions sur documents, sur des mises en page complexes de journaux et de magazines. La leçon utile n’est pas un score de benchmark particulier : localiser les bonnes régions et ordonner ces régions sont deux capacités différentes, donc un jeu d’évaluation ne devrait pas les traiter comme interchangeables.

Si la séquence compte pour la tâche en aval, elle a besoin de ses propres étiquettes de référence.

L’extraction de tableaux présente au moins deux modes de défaillance distincts. Un modèle peut mal lire le texte à l’intérieur d’une cellule, ou lire correctement le texte tout en affectant la cellule à la mauvaise ligne, à la mauvaise colonne ou à la mauvaise hiérarchie visuelle d’en-tête. Un seul indicateur agrégé de précision rend ces défaillances difficiles à diagnostiquer.

La similarité fondée sur la distance d’édition d’arbre (TEDS), introduite avec PubTabNet, compare une représentation prédite du tableau à la référence sous forme d’arbre. Les variantes purement structurelles, couramment désignées sous les noms TEDS-Struct ou TEDS-S, ignorent le texte des cellules afin que les erreurs de transcription ne dominent pas le score structurel. Les benchmarks d’extraction de tableaux de 2026 rapportent encore les scores TEDS et TEDS-S séparément, précisément pour cette raison.

Cette séparation est utile sur le plan opérationnel. Si les performances baissent après un changement de modèle, une équipe doit savoir si la régression provient de l’OCR, d’une cellule fusionnée non détectée, d’une frontière de colonne décalée ou d’une relation en-tête-corps incorrecte. Ces problèmes nécessitent des corrections différentes.

Le domaine du jeu de données compte aussi. PubTabNet a été construit à partir de tableaux d’articles scientifiques, tandis que FinTabNet a été créé à partir de documents financiers. Un modèle qui traite bien une population donnée peut avoir du mal lorsque la grammaire de mise en page change, en particulier pour les en-têtes imbriqués, les sous-totaux, les cellules fusionnées et le formatage financier dense.

Supposons qu’un formulaire contienne trois occurrences de l’étiquette « Date » : la date de facture, la date d’échéance et la date de livraison. Un modèle peut localiser chaque étiquette et chaque valeur de date, transcrire correctement les six segments, et pourtant échouer s’il les associe de manière incorrecte.

C’est pourquoi l’extraction de champs nécessite souvent des étiquettes de relation plutôt que de simples boîtes englobantes. Le jeu de données original FUNSD rend cette distinction explicite : il étiquette des entités sémantiques telles que les questions et les réponses et enregistre séparément les liens entre ces entités. L’annotation indique non seulement « ce texte existe ici » mais aussi « ces deux éléments vont ensemble ».

La partie difficile consiste à définir l’unité qui peut être liée. Une adresse sur plusieurs lignes peut être une seule valeur, plusieurs lignes ou un ensemble de champs imbriqués. Un schéma vague permet à chaque annotateur de faire un choix différent, ce qui transforme les désaccords en bruit dans la vérité terrain.

Ce risque n’est pas théorique. Des chercheurs ayant réexaminé FUNSD ont documenté des étiquettes incohérentes et révisé le jeu de données pour la détection clé-valeur. Les travaux de réétiquetage ultérieurs ont continué de mettre en évidence des incohérences de granularité et de liaison. La leçon pratique est simple : définissez les limites des entités et les règles de liaison à l’aide d’exemples difficiles avant qu’une grande équipe d’annotation ne commence.

Le préétiquetage assisté par modèle peut réduire le travail répétitif. Un modèle peut proposer des boîtes englobantes, des champs, des tableaux ou des liens, et un relecteur peut les corriger. Mais la proposition doit rester une proposition : les relecteurs doivent être formés à rechercher des erreurs structurelles d’apparence plausible plutôt qu’à supposer qu’une sortie de modèle confiante constitue déjà la vérité terrain.

Un lien manquant n’est pas le même défaut qu’un champ manquant. L’étiquette et la valeur peuvent toutes deux être présentes et parfaitement transcrites alors que la relation entre elles est erronée.

Une page n'est pas toujours la bonne unité d'évaluation. Un tableau peut commencer à la page 4 et se poursuivre à la page 5. Un lot numérisé peut contenir trois factures à la suite parce qu'elles sont arrivées sous la forme d'un seul PDF. Une référence dans le corps du texte peut renvoyer à une annexe située plusieurs pages plus loin. Un titre de section peut établir une hiérarchie qui se poursuit au fil des sauts de page.

Ces relations nécessitent des libellés au niveau du document si l'application en dépend. Voici des exemples utiles :

• Continuation de tableau  -  si deux fragments appartiennent au même tableau logique et comment la continuation doit être raccordée.

• Limites de document  -  où un document logique se termine et où le suivant commence dans un scan ou dans un lot combiné.

• Références croisées  -  à quelle figure, quel tableau, quelle section ou quelle note une référence renvoie réellement.

• Structure hiérarchique  -  comment les titres, sous-titres et sections du corps s'imbriquent dans l'ensemble du document.

Il est plus difficile d'annoter cela de manière cohérente que de dessiner des cadres sur des pages isolées. Les relecteurs ont besoin de suffisamment de contexte pour comprendre le document entier, et le travail est moins facile à répartir entre plusieurs personnes sans perdre la continuité.

Les benchmarks publics reflètent de plus en plus cette réalité. DUDE a été conçu autour de documents visuellement riches, multipages et multidomaines, tandis que VRDU met l'accent sur les schémas riches, les modèles complexes, les champs répétés et imbriqués, ainsi que sur la diversité de mise en page dans les documents professionnels. Pour un jeu de données de production, l'objectif n'est pas d'imiter un benchmark en particulier. Il s'agit de déterminer de quelles relations entre pages l'application réelle dépend et d'étiqueter ces relations délibérément.

Des métriques distinctes ne relèvent pas de la simple intendance académique. Elles rendent les défaillances diagnostiquables.

Imaginez qu’un système d’extraction de champs se dégrade après une mise à jour du modèle. Si le seul résultat est « 92 % de précision », ce chiffre n’indique pas à l’équipe où chercher. La régression peut provenir de la reconnaissance de texte, de l’ordre de lecture, de la structure des tableaux, de la liaison des champs, des limites de document ou de plusieurs de ces éléments à la fois.

Un jeu d’évaluation utile maintient ces signaux suffisamment distincts pour permettre d’enquêter. Cela ne signifie pas que chaque projet ait besoin d’une douzaine de métriques de tableau de bord. Cela signifie que la métrique rapportée doit correspondre à l’affirmation faite. Si l’objectif est la transcription, rapportez une métrique de transcription. Si l’objectif est la structure de tableau, rapportez une métrique de structure. Si l’objectif est l’extraction clé-valeur, définissez comment la détection d’entités et leur liaison sont toutes deux évaluées.

Si deux erreurs exigent des corrections différentes, elles devraient normalement rester distinguables dans l’évaluation. Un score récapitulatif peut encore être utile, mais il ne devrait pas remplacer les mesures par composante nécessaires pour diagnostiquer ce qui a changé.

Une métrique de qualité sans sa méthode de mesure ne constitue pas une preuve. « 95 % de précision » ne devient utile que lorsque le lecteur sait ce qui a été compté comme correct, quelles étiquettes de référence ont été utilisées et comment les cas ambigus ont été résolus.

Les mêmes mots peuvent créer un problème de compréhension du document très différent lorsque la mise en page change. Cela fait de la variation contrôlée de la conception un moyen utile de vérifier si un modèle a appris la structure du document ou seulement des gabarits familiers.

Une expérience pratique consiste à garder le contenu constant et à modifier une variable de mise en page à la fois :

• texte sur une seule colonne plutôt que sur deux colonnes ;
• une valeur de champ placée à côté de son libellé plutôt qu’alignée à l’écart ;
• un en-tête de tableau simple plutôt que des en-têtes fusionnés ou imbriqués ;
• une légende directement sous une image plutôt qu’un encadré flottant ;
• un tableau conservé sur une seule page plutôt que le même tableau qui se poursuit sur une deuxième page.

Faites passer les variantes dans le même pipeline OCR/IA documentaire et évaluez séparément la transcription et la structure. Si les mots restent corrects alors que l’ordre de lecture, la topologie du tableau ou les liens de champs se dégradent, le test a isolé un problème de généralisation de la mise en page plutôt qu’un problème d’OCR.

Pour une publication axée sur le design, il s’agit d’un angle de gain d’information plus crédible qu’une autre liste générique des avantages de l’IA documentaire. Cela transforme la conception de pages en une variable contrôlée qui peut être mesurée. Ne publiez pas de résultats chiffrés à moins que l’expérience ne soit réellement menée et que sa méthodologie ne soit documentée.

Un projet n’a pas besoin de toutes les couches par défaut. Il a besoin des couches qui correspondent à de véritables décisions en aval. Un système de classification de documents n’a peut-être pas besoin d’étiquettes de tableaux au niveau des cellules. Un système d’automatisation de factures en a probablement besoin. L’objectif n’est pas une densité d’annotation maximale ; il est de disposer de suffisamment de données de référence pour évaluer les tâches qui importent vraiment.

Les erreurs coûteuses surviennent généralement avant que le premier lot de production ne soit étiqueté. Un pipeline viable se présente comme suit :
1. Définissez d'abord le schéma. Décidez de ce qui constitue un champ, un tableau, une unité d'ordre de lecture et une limite de document. Incluez des exemples difficiles plutôt que uniquement des pages idéales.

2. Lancez un lot pilote. Utilisez un échantillon réduit mais varié pour repérer les désaccords concernant les lignes directrices avant qu'ils ne se propagent sur des milliers de pages.

3. Mesurez les désaccords là où l'ambiguïté compte. Toutes les étiquettes ne nécessitent pas de statistique formelle d'accord inter-annotateurs, mais des désaccords récurrents devraient déclencher une modification des lignes directrices ou une règle d'arbitrage plutôt qu'une moyenne silencieuse.
4. Utilisez le pré-étiquetage assisté par modèle de manière sélective. L'automatisation est utile pour les propositions répétitives, tandis que l'attention humaine doit se concentrer sur les relations et les cas limites qu'il est coûteux de mal traiter.
5. Évaluez le contenu et la structure séparément. Gardez la transcription, la topologie des tableaux, la liaison d'entités et les relations inter-pages suffisamment distinctes pour diagnostiquer les régressions.
6. Versionnez le schéma et préservez la provenance. Une équipe doit pouvoir déterminer quelle version des lignes directrices a produit une étiquette, comment elle a été revue et pourquoi une exception a été acceptée.

Le plus petit schéma utile vaut mieux qu'un schéma élaboré que personne ne peut appliquer de manière cohérente. Ne définissez que les étiquettes qui répondent à de vraies questions de modèle ou de produit, puis rendez ces étiquettes reproductibles.

Si vous souscrivez une licence, commandez ou approuvez un jeu de données de documents, posez des questions qui mettent au jour la structure qui sous-tend le chiffre de précision mis en avant :
• Quelle est l'unité d'annotation pour l'ordre de lecture : mots, lignes, blocs ou régions ?
• La structure des tableaux et le texte des cellules sont-ils évalués séparément ?
• Les relations clé-valeur sont-elles explicitement étiquetées ou déduites de la proximité ?
• Comment les champs répétés, imbriqués et multilignes sont-ils traités ?
• Les étiquettes de continuation et de limite de document sont-elles disponibles sur l'ensemble des pages ?
• Quels cas ambigus sont documentés dans les directives d'annotation ?
• Y a-t-il eu un projet pilote et un processus d'arbitrage en cas de désaccord entre réviseurs ?
• La version du jeu de données peut-elle être rattachée à une version de schéma et à un lot de production ?
• Quelles métriques sont rapportées, et qu'est-ce qui est exactement considéré comme une prédiction correcte ?

Ces questions révèlent souvent davantage sur l'adéquation d'un jeu de données qu'un seul chiffre de précision agrégé.

Si vous en êtes encore au stade antérieur de la recherche de sources, le guide de DesignWizard pour trouver des jeux de données professionnels pour des projets d'apprentissage automatique couvre plus largement la découverte et l'approvisionnement en jeux de données. Cet article intervient une étape plus tard, lorsqu'il s'agit de savoir ce que les étiquettes de référence elles-mêmes doivent contenir.

Pour les équipes qui commandent des données documentaires, la page de Wavebreak Media sur les jeux de données de documents pour l'entraînement de l'IA couvre les jeux de données de documents sous licence et personnalisés pour l'OCR, la compréhension de la mise en page, l'extraction de champs, les tableaux et les métadonnées structurées. Pour les projets commerciaux, ses conseils sur les licences de jeux de données d'IA couvrent également les droits d'utilisation, la provenance, les autorisations de diffusion et la documentation justificative. Un projet d'IA documentaire doit néanmoins définir son propre schéma structurel et ses critères d'acceptation plutôt que de supposer que le mot « annoté » couvre les relations dont il a besoin.

Qu'est-ce que la vérité terrain en IA documentaire ?

La vérité terrain de l'IA documentaire est constituée de données de référence vérifiées utilisées pour entraîner ou évaluer des systèmes qui interprètent des documents. Selon la tâche, elle peut inclure la transcription, l'ordre de lecture, la structure des tableaux, les relations entre champs, les limites de document et les liens inter-pages.

Quelle est la différence entre la précision de l'OCR et celle de l'IA documentaire ?

Les métriques OCR telles que le CER et le WER mesurent si le texte a été reconnu correctement. L'évaluation de l'IA documentaire peut aussi devoir mesurer si les régions ont été ordonnées correctement, si les tableaux ont été reconstruits correctement, si les champs ont été liés aux bonnes valeurs et si les relations entre les pages ont été préservées.

De quelles annotations un jeu de données d'IA documentaire a-t-il besoin ?

Uniquement les annotations exigées par la tâche en aval. Un extracteur de formulaires peut avoir besoin de liens clé-valeur et de règles pour les champs répétés ; un système de tableaux peut avoir besoin d'annotations de lignes, de colonnes, de fusions et d'en-têtes ; un flux de travail multipage peut avoir besoin de limites de document et d'étiquettes de continuation.

Comment évaluer l'ordre de lecture dans un document ?

Définissez d'abord l'unité à ordonner, comme des blocs ou des régions, puis comparez la séquence prédite à une séquence de référence. Les benchmarks de recherche utilisent des mesures de classement telles que le tau de Kendall, mais la métrique appropriée dépend de l'annotation et de la tâche.

Comment mesurer séparément la précision de la structure des tableaux et celle de l'OCR ?

Des métriques telles que TEDS-Struct ou TEDS-S comparent la structure des tableaux en excluant le texte des cellules. Cela permet d'évaluer les erreurs structurelles, telles qu'une mauvaise appartenance à une ligne ou à une colonne ou des fusions manquées, séparément des erreurs de transcription.

Un jeu de données OCR existant peut-il être réutilisé pour l'évaluation de l'IA documentaire ?

Parfois, mais généralement uniquement pour les couches qu'il annote déjà. Si l'application dépend de l'ordre de lecture, de la structure des tableaux, des liens entre champs ou des relations inter-pages, ces annotations peuvent devoir être ajoutées avant que le jeu de données puisse évaluer la tâche complète.

Comment évaluer les systèmes d'IA documentaire multipages ?

Utilisez des références au niveau du document pour les relations qui traversent les limites de page : continuation de tableau, limites de document, sections hiérarchiques et références croisées. La précision par page seule ne peut pas montrer si ces relations ont été préservées.

Que doit vérifier un acheteur avant de commander une annotation documentaire ?

Demandez quelles relations sont explicitement annotées, comment les cas difficiles sont définis, comment les relecteurs résolvent les désaccords, quel processus d'assurance qualité est utilisé et ce que mesure réellement chaque métrique rapportée.

L’erreur d’IA documentaire la plus facile à mesurer est le caractère erroné. Bon nombre des défaillances coûteuses se produisent une fois que les caractères sont corrects.

Une cellule de tableau se trouve sous le mauvais en-tête. Une valeur est liée à la mauvaise étiquette. Deux colonnes sont lues dans le mauvais ordre. La suite d’un tableau est traitée comme un nouveau tableau parce que le jeu d’évaluation n’a jamais consigné le fait que les pages allaient ensemble.

Une vérité terrain de qualité rend ces relations visibles. La précision du texte vous indique ce qui a été reconnu ; la vérité terrain structurelle vous indique si la sortie a été organisée de la manière exigée par la tâche.

C’est la ligne de démarcation utile pour l’évaluation : si une décision en aval dépend d’une relation, la spécification du jeu de données doit indiquer comment cette relation est représentée, examinée et notée.