Évaluer les parsers de tableaux pour factures : métriques et benchmarks

À retenir

• Un TEDS de 90 % sur un benchmark public ne dit rien de votre taux d'erreur sur une facture à double en-tête : la seule mesure qui compte est un jeu de test issu de vos propres PDF.
• Les métriques de structure (TEDS-S, GriTS-Top) et les métriques de contenu (TEDS, GriTS-Con) mesurent deux choses différentes, et un parser peut exceller sur l'une en échouant sur l'autre.
• Sur RD-TableBench, la meilleure similarité moyenne publiée était de 90,2 %, ce qui signifie qu'environ une cellule sur dix reste litigieuse sur les tableaux complexes : votre pipeline RAG doit être conçu pour ça.
• Les erreurs qui cassent le RAG ne sont pas les fautes de caractères, mais les décalages ligne/colonne : un montant rattaché au mauvais en-tête produit une réponse fausse et confiante.

Pourquoi les factures multi-colonnes cassent-elles un pipeline RAG ?

Parce que le RAG travaille sur du texte linéarisé, et qu'un tableau à en-têtes multi-niveaux perd son sens dès qu'on l'aplatit. Une facture fournisseur typique empile une colonne "Quantité", deux colonnes de prix (HT / remisé), un taux de TVA par ligne et parfois un sous-total intermédiaire par centre de coût. Si le parser fusionne deux colonnes ou décale une ligne de span, le chunk indexé contient toujours les bons chiffres, mais rattachés aux mauvais libellés. L'embedding reste plausible, la récupération fonctionne, et le modèle répond avec assurance un montant faux.

C'est précisément le type de tableau que les benchmarks récents ciblent. Les tableaux d'OmniDocBench comportent des structures imbriquées, des en-têtes multi-niveaux et des cellules fusionnées qui mettent sous pression la prédiction structurelle de chaque système. Côté données réelles, RD-TableBench couvre scans, écriture manuscrite, détection de langue et cellules fusionnées. Traduction opérationnelle : vos pires documents ne sont pas des exceptions, ce sont la catégorie que la littérature considère comme le cas difficile de référence.

Un chunk mal aligné ne provoque pas une erreur, il provoque une réponse fausse qui passe la revue humaine.

Quelles métriques utiliser pour évaluer un parser sur les tableaux ?

Trois familles, à mesurer séparément : structure, contenu, et exactitude au niveau champ métier. TEDS (Tree Edit Distance based Similarity) compare les représentations arborescentes HTML des tableaux, tandis que la distance d'édition normalisée mesure la transformation d'une chaîne en une autre. Dans OmniDocBench, TEDS combiné à la NED évalue à la fois la précision structurelle et la précision du contenu du tableau, et la variante TEDS-S isole la structure seule.

TEDS a un défaut connu : il mélange mise en forme et structure. D'où GriTS. GriTS (grid table similarity) évalue un tableau prédit directement sous sa forme naturelle de matrice, et unifie topologie des cellules, localisation des cellules et contenu des cellules dans un même cadre. Troisième approche, l'alignement de séquences : RD-TableBench utilise un scoring Needleman-Wunsch, qui crédite proportionnellement les tableaux partiellement corrects au lieu de les mettre à zéro.

Aucune de ces métriques ne vous dit si le total TTC est juste. Ajoutez donc un quatrième niveau : exactitude par champ sur les valeurs que votre système consomme réellement.

Les benchmarks publics suffisent-ils à choisir un parser ?

Non, mais ils cadrent vos attentes et éliminent rapidement les candidats faibles. Les écarts publiés sont larges : sur RD-TableBench, la similarité de tableau allait de 90,2 pour Reducto à 82,7 pour Azure, 80,9 pour Textract, 76,0 pour GPT-4o et 60,2 pour Unstructured. Trente points d'écart entre le premier et le dernier, sur une tâche où tous les fournisseurs annoncent une "extraction de tableaux".

Deuxième précaution : la provenance des annotations. PubTabNet et FinTabNet offrent de gros volumes, mais proviennent d'un corpus homogène avec des labels générés programmatiquement depuis les métadonnées de fichiers, alors que RD-TableBench repose sur 1 000 images de tableaux complexes annotées manuellement par des labelleurs de niveau doctorat. Troisième précaution : la contamination. Seule une partie du framework d'évaluation est publiée publiquement, afin d'éviter les fuites en données d'entraînement. Un score public excellent peut donc refléter une exposition partielle au jeu de test. Nous détaillons ces angles morts dans notre analyse des limites d'OmniDocBench pour les factures.

Comment construire un jeu de test interne représentatif ?

Visez 150 à 300 pages annotées, choisies par difficulté et non au hasard. Le tirage aléatoire sur-représente les factures simples, celles que tous les parsers réussissent, et noie le signal. Stratifiez plutôt par attributs de difficulté, exactement comme le fait la littérature : OmniDocBench annote 5 attributs de page, 3 attributs de texte et 6 attributs de tableau, ce qui permet de lire les scores par type de tableau plutôt qu'en moyenne.

Pour un corpus de factures, retenez au minimum ces strates : en-têtes sur deux niveaux, cellules fusionnées verticalement, tableaux à cheval sur deux pages, scans à 200 dpi et moins, documents photographiés de travers, multi-devises, factures avec lignes de remise négatives, et formats structurés type Factur-X dont la couche PDF contredit parfois le XML. Annotez en HTML avec les attributs rowspan / colspan, plus un dictionnaire de champs métier attendus. Les annotations de référence peuvent contenir à la fois LaTeX et HTML pour les tableaux, mais pour un usage interne le HTML seul suffit et se compare directement en TEDS.

Un jeu de test de 200 pages bien choisies vaut mieux que 10 000 pages tirées au hasard dans le flux entrant.

Comment tester le parser dans le contexte RAG, pas seulement en isolation ?

En mesurant la fin de chaîne : le taux de bonnes réponses sur des questions qui exigent le croisement ligne/colonne. Un score TEDS est une métrique de laboratoire. Ce qui vous intéresse est de savoir si "quel est le montant de TVA sur la ligne de prestation de janvier ?" renvoie la bonne valeur après chunking, embedding et génération.

Protocole minimal : générez 300 à 500 questions à réponse unique et vérifiable depuis vos annotations (une cellule = une réponse attendue), puis comparez deux à trois stratégies de linéarisation à parser constant. Le choix de la sérialisation change les résultats autant que le choix du modèle : HTML brut, Markdown, ou triplets explicites (ligne, en-tête, valeur). Mesurez ensuite le taux d'abstention. Un système qui refuse de répondre quand la structure est douteuse vaut mieux qu'un système confiant à 92 %, et ce compromis se règle avec des règles de validation arithmétiques : somme des lignes = total HT, TVA recalculée par taux, total TTC cohérent. Ces contrôles attrapent les décalages de colonne que n'attrape aucune métrique de similarité.

Quels critères non liés à la précision doivent entrer dans la décision ?

Le débit, le coût par page, la variance et le mode d'échec. La variance compte autant que la moyenne : un système qui rend d'excellents résultats sur les 60 % de documents où il ne plante pas se lit très différemment dans un benchmark qui sépare le taux d'échec du score de qualité. Exigez donc un rapport par strate, pas un chiffre global.

Le coût se lit par page et non par token, et les approches VLM restent plus chères et plus lentes que les pipelines OCR classiques sur du volume, arbitrage que nous décrivons dans notre comparaison OCR contre VLM. Ajoutez la question du lieu de traitement : pour des factures fournisseurs contenant des données personnelles, la résidence des données et la non-conservation sont des critères d'éligibilité, pas des options. Sygnet évalue les parsers sur ces trois axes conjointement (exactitude par strate, coût par page, périmètre de traitement) parce qu'un gain de 3 points de TEDS payé en latence multipliée par cinq ne passe jamais en production.

FAQ

Quel score TEDS viser avant de passer en production ?

Il n'existe pas de seuil universel, parce que TEDS dépend du corpus. Un point de comparaison utile : Nemotron-Parse obtient 86,2 de TEDS sur RD-TableBench et 82,68 sur OmniDocBench 1.0 en anglais. Sur vos propres factures, fixez le seuil à partir du coût d'une erreur : si une ligne mal alignée déclenche un rejet de paiement, visez plutôt une exactitude par champ supérieure à 99 % sur les montants, avec revue humaine sur le reste.

TEDS ou GriTS : laquelle choisir ?

Utilisez TEDS pour comparer vos résultats à la littérature, et GriTS pour diagnostiquer. GriTS sépare topologie, localisation et contenu des cellules dans un cadre unique, ce qui permet d'identifier si le parser se trompe de grille ou de texte. TEDS, lui, agrège tout et mélange mise en forme et structure. En pratique, beaucoup d'équipes rapportent TEDS et TEDS-S côte à côte, puis passent à GriTS quand elles doivent choisir entre deux modèles proches.

Combien de pages faut-il annoter pour un test fiable ?

Comptez 150 à 300 pages stratifiées, soit environ 2 000 à 5 000 cellules de référence. C'est assez pour détecter un écart de 3 à 5 points entre deux parsers sur les strates difficiles. Pour l'ordre de grandeur inverse, les benchmarks publics travaillent à une échelle bien supérieure : les résultats GriTS sont moyennés sur 44 381 tableaux du jeu de test PubTables-1M. Vous n'avez pas besoin de ce volume pour une décision d'achat, mais vous avez besoin de la stratification.