# Pourquoi TEDS ne mesure pas la qualité d'un parseur de tableaux

> Découvrez pourquoi le score TEDS, bien que populaire, ne reflète pas toujours la performance réelle des parseurs de tableaux pour les pipelines RAG et quelles métriques privilégier.

Published: 2026-10-15

Canonical: https://sygnet.ai/fr/blog/pourquoi-teds-ne-mesure-pas-la-qualite-dun-parseur-de-tableaux

---

## À retenir
- Les scores de structure de tableaux et la qualité de retrieval ne mesurent pas la même chose : dans un benchmark de 8 extracteurs locaux, la structure des tableaux (TEDS) et le hit@5 en retrieval se sont contredits, et cinq outils se sont retrouvés à moins de 0,04 point d'écart en hit@5.
- TEDS suppose qu'il n'existe qu'une seule sortie correcte, ce qui pénalise des rendus alternatifs pourtant valides : un tableau HTML sémantiquement riche a obtenu un TEDS de 0,34, alors que la précision du contenu des cellules sur ce même tableau atteignait 0,68.
- C'est l'ordre de lecture, et non la fidélité des tableaux, qui détermine généralement l'emplacement de vos coupures de chunks ; OmniDocBench le mesure d'ailleurs comme un indicateur à part, qui n'entre jamais dans le score global affiché.
- Évaluez les parseurs sur votre propre corpus avec des métriques au niveau des questions (hit@k, exactitude des réponses), et non sur un classement public construit à partir des documents d'autres entreprises.

## Pourquoi un parseur de tableaux bien classé peut-il nuire à la précision d'un RAG ?

Parce que la métrique qui l'a sacré (TEDS) récompense la reconstruction d'un arbre HTML, alors que votre pipeline RAG, lui, est jugé sur la capacité d'un retriever à retrouver les bons 800 tokens et d'un LLM à les lire correctement. Ces deux objectifs divergent plus souvent que les éditeurs ne veulent l'admettre. Un parseur peut produire un arbre `<table>` quasiment parfait, que votre découpeur en chunks va ensuite trancher en plein milieu, en détachant la ligne d'en-tête des lignes 14 à 40 et en laissant un chunk de chiffres bruts sans aucune sémantique exploitable.

Les preuves empiriques sont sans appel. Dans un benchmark ouvert portant sur 8 extracteurs PDF locaux et 27 documents, les auteurs ont mesuré le TEDS par rapport à des tableaux HTML annotés manuellement, en parallèle du hit@5 en retrieval sur 233 questions avec un embedder bge-large et un bge-reranker, et ont constaté que la structure des tableaux et le retrieval se contredisent. L'inversion de classement saute aux yeux dans leurs propres chiffres : Marker (sans OCR) atteint un TEDS de 0,82 sur les tableaux réels qu'il traite intégralement, mais seulement 0,50-0,52 en hit@5, tandis que Tesseract 5.5, avec des taux d'erreur de caractères bien pires (CER de 0,17-0,43), arrive en tête du retrieval avec 0,83.

> Un parseur qui gagne sur la structure des tableaux et perd sur l'ordre de lecture va livrer à votre découpeur des tableaux parfaits, mais placés au mauvais endroit.

## Que mesure exactement TEDS, et qu'est-ce qu'il ignore ?

TEDS mesure la distance d'édition entre un arbre de tableau prédit et un tableau HTML de référence unique, en combinant structure et contenu des cellules dans un seul score de similarité. Il capture la similarité structurelle en comparant des représentations arborescentes des tableaux HTML, et fusionne la précision spatiale des cellules (chaque cellule est-elle à la bonne position, avec ses relations intactes) avec le contenu des cellules, le tout dans un seul chiffre.

Ce qu'il ignore : tout ce qui se trouve hors du cadre du tableau. L'ordre de lecture sur la page, le fait qu'une note de bas de page soit restée rattachée à sa cellule, que la légende ait survécu, ou qu'un tableau sur plusieurs pages ait été recousu correctement ou dupliqué. OmniDocBench est explicite sur cette distinction. Il évalue quatre dimensions (la transcription de texte par distance d'édition normalisée, la reconnaissance de formules par CDM, la reconstruction de tableaux par TEDS et TEDS-S, et la récupération de l'ordre de lecture par distance d'édition sur les séquences de blocs), mais le score global ne fait la moyenne que du texte, du CDM des formules et du TEDS des tableaux. L'ordre de lecture est mesuré, puis exclu du score affiché. Si vous choisissez un parseur sur ce classement, vous avez optimisé trois critères et ignoré celui qui gouverne les coupures de chunks.

## Pourquoi les classements de benchmarks s'inversent-ils sur vos propres documents ?

Parce que les corpus publics ne sont pas votre corpus, et les performances des parseurs s'effondrent de façon inégale selon le type de document. Une étude portant sur plus de 800 documents et 7 parseurs de pointe a montré que les articles académiques dégradent systématiquement les résultats : GPT-5.1 chute de 84 % de similarité d'édition globale à 39 % sur les pages académiques (-45 points), LlamaParse passe de 78 % à 38 % (-40 points), et Claude Sonnet 4.5 de 78 % à 34 %. Un écart de 40 points selon la classe de document est plus important que n'importe quel écart entre les cinq meilleurs parseurs sur un classement agrégé.

Le taux d'échec compte tout autant que la performance maximale. Dans le benchmark à 27 documents, MinerU a échoué sur 9 documents sur 27 et Docling sur 8, tandis que PyMuPDF, pdfplumber et Tesseract n'ont échoué sur aucun. Un parseur affichant un TEDS de 0,90 sur les 70 % de pages qu'il traite, et ne renvoyant rien sur le reste, vous donne un index silencieusement incomplet, ce qui est le pire mode de défaillance en RAG : le système répond avec assurance à partir de ce qui a effectivement été indexé. Nos propres notes sur l'[évaluation de la précision d'extraction](https://sygnet.ai/checklists/extraction-accuracy-evaluation) partent de la couverture pour exactement cette raison.

## Quelle métrique devriez-vous réellement optimiser ?

Optimisez des métriques au niveau des questions sur vos propres documents : hit@k en retrieval, puis exactitude des réponses, les scores au niveau du parsing ne servant que de diagnostic. Le bon protocole expérimental consiste à ne faire varier qu'un seul composant à la fois. Les travaux dérivés de FinanceBench sur le question-réponse financier procèdent exactement ainsi : ils évaluent des pipelines RAG de bout en bout en faisant varier les parseurs, les stratégies de chunking et les LLM, à la fois sur FinanceBench et sur un jeu de questions-réponses dérivé de tableaux, en mesurant l'impact de chaque choix de composant sur la précision du retrieval et l'exactitude des réponses.

Deux substitutions pratiques aident. D'abord, remplacer la notation à référence unique par une notation sémantique : une comparaison de 2026 indique qu'une évaluation sémantique des tableaux par LLM atteint un coefficient de Pearson r=0,93 avec le jugement humain, contre r=0,68 pour le TEDS seul. Ensuite, utiliser des benchmarks de vérification factuelle plutôt que la distance de chaînes de caractères lorsque c'est possible. olmOCR-Bench vérifie des faits sans ambiguïté et vérifiables automatiquement sur chaque page, par exemple si une phrase précise apparaît exactement dans la sortie, car la distance d'édition peut pénaliser des variations valides ou manquer des erreurs sémantiques critiques.

| Métrique | Ce qu'elle récompense | Ce qu'elle manque pour le RAG | À utiliser pour |
|---|---|---|---|
| TEDS / TEDS-S | Structure arborescente du tableau + contenu des cellules par rapport à une référence unique | Ordre de lecture, légendes, tableaux multi-pages, rendus multiples valides | Comparer des moteurs de tableaux sur un corpus fixe |
| Distance d'édition normalisée (texte) | Fidélité de la transcription au niveau du caractère | La sémantique ; pénalise les variantes de mise en forme pourtant valides | Détecter des régressions OCR |
| Distance d'édition sur l'ordre de lecture | La bonne séquence de blocs | L'intérieur des tableaux | Prédire la qualité des coupures de chunks |
| Hit@k en retrieval | Le fait que le bon passage soit retrouvable | Les erreurs de génération en aval | Sélection du parseur et du découpeur |
| Exactitude des réponses | L'utilité de bout en bout | L'attribution de la responsabilité à un composant précis | Décisions go/no-go |
| Couverture / taux d'échec | Les pages effectivement traitées | La qualité de ce qui a été traité | Risque en production |

## Comment les choix de parseur se répercutent-ils en erreurs de chunking ?

La structure détermine les coupures de chunks, de sorte qu'une erreur structurelle devient, une étape plus loin, une erreur de retrieval. Un parseur peut exceller en extraction de texte à 80 % et échouer en récupération de structure à 40 %, et cet écart compte pour les pipelines RAG, où la structure du document détermine les coupures de chunks et la qualité du retrieval. La métrique d'ordre de lecture est ici l'indicateur avancé déterminant : une comparaison de 2026 affirme directement que l'ordre de lecture est la métrique qui gouverne le bon ou mauvais placement des coupures de chunks.

Une seconde défaillance, plus discrète : des modèles de mise en page qui classent un graphique comme une simple image. Le benchmark à 27 documents a montré que les outils d'analyse de mise en page classent les graphiques comme des images et en jettent le texte, Docling ne récupérant que 3 % des faits contenus dans les graphiques, contre 84 % pour EasyOCR et 65 % pour Tesseract. Rien dans un score TEDS ne vous avertira qu'un tiers de vos figures a silencieusement disparu. Si vos questions portent sur des annotations de graphiques, des libellés d'axes ou des légendes, un pipeline de mise en page affichant un TEDS élevé peut être le pire choix possible.

> Rien dans un score de structure de tableau ne vous dira qu'un tiers de vos figures a été classé comme de simples images et écarté.

## Dans quels cas un TEDS élevé est-il vraiment le bon objectif à viser ?

Quand vos requêtes se résolvent à l'intérieur de tableaux numériques denses et que votre découpeur est conçu pour respecter les tableaux. Les états financiers, les dépôts réglementaires et les grilles de résultats d'analyses récompensent réellement la fidélité structurelle, et l'écart entre parseurs sur ce type de documents est important : sur le corpus opendataloader-bench, Docling 2.110.0 obtient un TEDS de 0,93 contre 0,74 pour la CLI Nutrient standard, et la configuration hybride fait grimper le TEDS des tableaux de 0,489 à 0,928. Ce n'est pas du bruit statistique.

La condition, c'est que le tableau arrive intact jusqu'au LLM, avec les en-têtes répétés dans chaque chunk et la légende attachée. Si vous sérialisez chaque tableau comme une unité autonome, avec sa ligne d'en-tête et un court résumé en langage naturel placé devant, un parseur à 0,93 de TEDS bat un parseur à 0,74. Si vous découpez naïvement par nombre de tokens, cet avantage structurel s'évapore. Sygnet travaille sur des pipelines d'extraction de documents où cette distinction se manifeste constamment, et la [checklist d'ingestion de documents pour le RAG](https://sygnet.ai/checklists/rag-document-ingestion) couvre cette étape de sérialisation. La question du modèle de parsing lui-même (pipeline de mise en page ou modèle vision-langage) est traitée séparément dans [OCR vs VLM](https://sygnet.ai/ocr-vs-vlm).

## FAQ
### TEDS est-il une mauvaise métrique ?

Non, c'est une métrique précise pour une tâche étroite : reconstruire un tableau par rapport à un unique arbre de référence. Le problème, c'est de la traiter comme un indicateur de la qualité d'un RAG. Le CER et le TEDS supposent qu'il n'existe qu'une seule sortie correcte, ce qui pénalise les multiples représentations valides que produisent les parseurs génératifs et les VLM, et peut donc inverser les classements. Si on le rapporte aux côtés de l'ordre de lecture, de la couverture et du retrieval, il reste utile.

### Combien de documents faut-il pour un benchmark interne significatif ?

Moins que vous ne le pensez, à condition qu'ils soient stratifiés. L'étude portant sur 8 extracteurs s'est appuyée sur 27 documents allant de 1 à 487 pages et 233 questions, ce qui a suffi pour distinguer les parseurs selon leur taux d'échec et leur traitement des graphiques. Visez 20 à 40 documents couvrant chaque famille de mise en page que vous ingérez réellement (scans, PDF natifs, multi-colonnes, tableaux denses), plus 10 à 15 questions par famille avec des réponses connues.

### Quel chiffre faut-il présenter aux parties prenantes ?

L'exactitude des réponses sur votre propre jeu de questions, avec le hit@k en retrieval comme diagnostic sous-jacent. Les scores au niveau du parsing expliquent pourquoi un pipeline a échoué, ils ne prédisent pas s'il va échouer. Si le dossier métier nécessite un chiffrage, le [calculateur de ROI](https://sygnet.ai/roi-calculator) associe volume et taux d'erreur au temps de relecture en aval.