Pourquoi l'IA échoue sur les rapports d'expertise complexes ?

À retenir

• Un modèle entraîné sur des factures est un comparateur de gabarits qui s'ignore : sur le benchmark VRDU de Google, le micro-F1 sur des modèles de document inédits chute de 13 à 17 points par rapport aux performances multi-gabarits à 200 documents d'entraînement, alors qu'un rapport d'expertise n'a, par nature, aucun gabarit.
• Les benchmarks de tickets de caisse flattent tout le monde. Les meilleurs scores atteignent 96-97% sur CORD et SROIE, mais chutent à environ 45% sur les formulaires publicitaires de VRDU avec 200 échantillons d'entraînement.
• La difficulté d'un dossier sinistre ne tient pas à l'OCR, mais à la hiérarchie et au raisonnement : VRDU relève un écart de 60 à 70 points entre entités hiérarchiques et entités plates, quelle que soit la taille du jeu d'entraînement.
• Construisez votre schéma autour de zones de preuve (evidence spans) et de recoupement au niveau du document, pas autour de 8 champs plats, et évaluez par type de champ plutôt qu'avec une moyenne unique.

Pourquoi un modèle d'extraction entraîné sur des factures échoue-t-il sur un rapport d'expertise ?

Parce que l'extraction de factures est une tâche clé-valeur bornée sur une mise en page quasi fixe, tandis qu'un rapport d'expertise (rapport d'expert automobile, devis de réparation, évaluation médicale) est un récit multi-pages où la réponse est une phrase, une conclusion ou un chiffre noyé dans la prose. Le modèle a appris des priors spatiaux (« le total est en bas à droite, près d'un symbole monétaire ») qui n'existent pas dans un rapport de 14 pages. Et il a appris un schéma de 8 à 20 champs plats, alors qu'un dossier sinistre exige de la causalité, des dates de survenance, des exclusions et des parts de responsabilité.

Les benchmarks publics montrent à quel point cette distribution d'entraînement est étroite. SROIE, le benchmark le plus cité dans les articles sur l'extraction, compte 1 000 tickets de caisse scannés avec quatre champs clés : société, date, adresse et total. CORD rassemble des images de tickets de commerces et de restaurants avec 30 entités regroupées en Menu, Menu annulé, Sous-total et Total. Un modèle calibré sur cette distribution n'a jamais eu à juger si un dommage décrit est couvert ou non.

Un benchmark construit sur 400 tickets de restaurant ne permet pas de prédire le comportement d'un modèle sur un rapport d'expert de 14 pages.

L'échec est rarement spectaculaire. Le modèle renvoie un JSON valide, des chiffres plausibles et des scores de confiance qui semblent corrects. C'est précisément pour cela que les équipes sinistres découvrent les erreurs trois semaines plus tard, dans les calculs de provisions.

Quelle est l'ampleur de la baisse quand la mise en page change ?

Les baisses mesurées vont d'environ 9 points de F1 à plus de 25, selon la part du score initial du benchmark qui reposait sur la mémorisation des mises en page. Une étude a rééchantillonné les jeux FUNSD et SROIE pour supprimer la redondance d'information entre entraînement et test : le F1 moyen est passé de 94,34 à 85,60, et le meilleur score de 96,55 à 89,38. Les modèles texte seul ont le plus souffert : BERT, AlBERT et RoBERTa ont perdu en moyenne 10,5 points de F1, contre 7,5 pour les modèles multimodaux.

La généralisation aux gabarits raconte la même histoire, sans détour. Dans la tâche d'apprentissage sur gabarits inédits (Unseen Template Learning) de VRDU, les documents d'entraînement et de test proviennent d'ensembles de gabarits disjoints, ce qui constitue le cadre le plus exigeant puisque les nouveaux gabarits peuvent différer sensiblement. La nouveauté du modèle n'a pas rimé avec robustesse : LayoutLMv3 s'est le plus dégradé sur les gabarits inédits, passant de 89,77 à 62,58 de micro-F1, derrière LayoutLMv2 à chaque taille de jeu d'entraînement. Si un écart de 27 points apparaît entre deux variantes d'un même formulaire d'immatriculation, on peut s'attendre à un écart plus important encore entre une facture et un rapport d'expertise.

Qu'est-ce qui distingue réellement une facture d'un dossier sinistre ?

La différence est structurelle, pas cosmétique : cardinalité des champs, nombre de pages, localisation des preuves et niveau d'inférence requis entre le texte et la valeur cible.

La hiérarchie est le véritable facteur bloquant. Lignes de facture, dommages répétés, parties lésées multiples : ce sont des entités imbriquées, et VRDU note qu'aucun modèle existant ne prend en compte le type d'entité hiérarchique, une heuristique de regroupement lui étant substituée. Un dossier sinistre est quasi entièrement constitué d'entités imbriquées.

Les benchmarks multi-pages et multi-domaines sont-ils un meilleur proxy ?

Oui, et les résultats sont édifiants. DUDE a été conçu comme un benchmark DocVQA à grande échelle, multi-pages, multi-domaines et multi-sectoriel, et ses auteurs constatent que les performances en zero-shot et après fine-tuning des modèles de pointe restent très en deçà des résultats humains, en partie à cause du besoin d'une modélisation plus holistique du langage, de la vision et de mises en page richement structurées. Le jeu de données inclut délibérément des tableaux, graphiques, figures, listes, cases à cocher et tampons, ce qui correspond grosso modo au contenu d'un vrai dossier sinistre.

DUDE identifie aussi le bon cadrage du problème : une reconnaissance multi-domaines à longue traîne (long-tailed), avec déséquilibre des classes, distributions de labels divergentes selon les domaines et possible décalage de domaine entre entraînement et test. C'est exactement à quoi ressemble un portefeuille de sinistres. Les sinistres bris de glace arrivent par milliers ; les rapports d'affaissement de terrain ou de malfaçon arrivent par dizaines, avec les conséquences financières les plus lourdes. Tout modèle entraîné sur votre volumétrie de masse sous-performera sur les documents qui pèsent réellement sur les provisions.

Que faire à la place d'un fine-tuning plus poussé ?

Il faut changer la définition de la tâche avant de changer de modèle. Trois leviers rapportent davantage qu'un nouveau tour de fine-tuning.

1. Découper le pipeline en trois étapes : extraction brute (parse), localisation, décision. La qualité de l'extraction peut être mesurée indépendamment du raisonnement. LandingAI a démontré l'utilité de cette séparation en évaluant la fidélité de l'extraction plutôt que le VLM lui-même : 5 286 bonnes réponses sur 5 331 questions DocVQA (99,16%), traitées par un LLM à partir du seul texte extrait, sans accès à l'image pendant l'étape de question-réponse. Que votre extracteur repose sur l'OCR ou sur un modèle vision-langage change les modes d'échec hérités, ce qui est précisément l'arbitrage traité dans OCR vs VLM pour l'extraction de documents.

2. Exiger une zone de preuve pour chaque champ. Un champ sans page, sans zone de délimitation (bounding box) ni phrase citée ne peut pas être validé par un relecteur humain en moins d'une minute, et ne sera donc jamais relu. L'ancrage sur la source rend aussi les dérives silencieuses visibles.

3. Évaluer par type de champ, pas en moyenne globale. Dates, montants, conclusions en texte libre et tableaux imbriqués échouent différemment. Une moyenne unique à 94% peut masquer un score de 45% sur les lignes de détail, ce qui résume en une phrase la leçon de VRDU. Sygnet publie une checklist pour évaluer la précision d'extraction, qui détaille le scoring au niveau des champs et les plans d'échantillonnage.

Mesurez vos propres documents sur vos propres champs, car aucun benchmark public ne contient de rapport d'expertise.

Combien de documents faut-il pour constituer son propre jeu d'évaluation ?

Prévoyez 150 à 300 documents annotés par type de document, stratifiés par nature de sinistre, et non par échantillonnage aléatoire simple. VRDU a utilisé 300 documents dans son jeu de test pour chaque tâche, et ses découpages few-shot ont été calibrés à 10, 50, 100 et 200 instances d'entraînement précisément pour limiter la forte variance induite par l'échantillonnage de différents documents d'entraînement. Cette variance explique pourquoi de petits pilotes internes produisent des taux de précision radicalement différents d'une semaine à l'autre.

L'arithmétique compte autant que l'échantillonnage. La précision par champ se compose : à 98% de précision par champ sur huit champs, environ 85% des documents ressortent sans erreur, ce qui relève du calcul plutôt que de la mesure. Passez à un schéma sinistre de 30 champs, et la précision par champ doit être bien plus élevée pour obtenir un taux de réussite document par document acceptable. Décidez en amont quels champs sont bloquants (montant de la provision, date du sinistre, part de responsabilité) et lesquels tolèrent une relecture, puis fixez des seuils par champ. Pour les schémas de champs spécifiques aux sinistres, Sygnet documente son approche du traitement des sinistres d'assurance et de l'extraction de rapports médicaux, qui présente la même difficulté liée au document narratif.

Notez aussi que les chiffres publiés par les éditeurs ne sont guère utiles : une étude a montré qu'aucun des trois grands modèles cloud d'extraction de factures ne publie de taux de précision dans sa documentation. Votre propre jeu de test stratifié est le seul chiffre que vous pourrez défendre face à un actuaire.

FAQ

Un LLM généraliste peut-il remplacer un modèle de facture fine-tuné sur des documents sinistres ?

Souvent oui pour les champs narratifs, avec certaines réserves. L'extraction par prompt, sans fine-tuning, atteint déjà un F1 de 80,9 sur CORD et de 83,9 sur SROIE, en retrait par rapport aux modèles spécialisés sur les tickets de caisse, mais bien plus transposable à des mises en page inédites. Pour les dossiers sinistres, cette portabilité compte davantage que les derniers points de score sur un benchmark de tickets de caisse. Conservez dans tous les cas l'ancrage sur la source et des seuils par champ.

Le fine-tuning sur des rapports d'expertise en vaut-il la peine ?

Seulement une fois que vous disposez d'un jeu d'évaluation annoté et que vous savez quels champs échouent. Le fine-tuning aide sur les sous-formats récurrents (le formulaire d'estimation standard d'un assureur, les devis de réparation d'un réseau), mais apporte peu sur la prose libre. Les résultats few-shot de VRDU montrent un écart de plus de 15 points entre 10 et 50 échantillons d'entraînement, un écart qui persiste sur toutes les tâches et les trois modèles testés : ce sont les 50 premiers exemples qui rapportent le plus.

Faut-il construire ou acheter sa solution d'extraction pour les sinistres ?

Construisez si votre répertoire de documents est étroit, stable, et vos champs plats. Achetez si vous êtes confronté à des types de documents à longue traîne avec des champs imbriqués, car c'est précisément là que les modèles internes se dégradent le plus vite et où le coût de maintenance, bien plus que la précision initiale, devient déterminant. Les arbitrages sont détaillés dans build vs buy pour l'IDP.