Isoler les étages — savoir qui a bougé

Le score global ne suffit pas à agir

Ton line_f1 global chute de 0,80 à 0,74 après un changement. Coupable : la lecture ? le matching ? Un chiffre unique ne le dit pas. Un harness mûr propose donc des mesures d'isolation qui répondent à « qui a bougé ».

Mesure 1 — le matching seul

On nourrit le matcher avec les lignes parfaites du gold (extraction idéale), et on mesure uniquement sa capacité à choisir le bon SKU. En comparant à la mesure de bout en bout, par soustraction :

• si le bout-en-bout est mauvais mais le matching-seul est bon → le problème est dans la lecture ;
• si le matching-seul est déjà mauvais → le problème est dans l'appariement.

Point crucial : on réinitialise l'état d'apprentissage entre chaque fichier (cf. contamination silencieuse) pour une mesure pure du matcher, pas du matcher-plus-son-historique.

Mesure 2 — le moteur de lecture en A/B

Pour isoler la lecture, on fait un banc d'essai A/B du moteur d'OCR/vision : on envoie chaque document brut à un autre moteur (par ex. un modèle vision généraliste), avec le même contrat (même prompt système, même schéma de sortie), et on le score sur les mêmes golds et les mêmes métriques. La différence de line_f1/recall mesure alors uniquement moteur A vs moteur B, tout le reste étant identique.

C'est poussé comme un run à part (vision:<modèle>) dans le même dataset → comparaison directe, côte à côte, avec la prod. Le match@1 y est nul et c'est attendu : ce banc ne teste pas le matching.

Isoler un étage = fixer tout le reste et ne faire varier qu'une chose. C'est la méthode expérimentale, appliquée à un pipeline.

Ce que ça t'offre

Une table de décision : tu sais où investir. Inutile de peaufiner le matcher si 60 % des pertes viennent d'un OCR qui rate des colonnes. L'isolation transforme « le score a bougé » en « change le moteur de lecture, garde le matcher ».