Anatomie d'un pipeline faillible

Le cas fil rouge (générique et anonymisé)

Tout le cours s'appuie sur un pipeline réaliste mais entièrement générique : un système qui reçoit des bons de commande dans tous les formats du réel — PDF propre, PDF scanné, photo prise de travers, tableur, parfois manuscrit — et doit produire une commande structurée. Aucun nom d'entreprise, de client ou de produit réel n'apparaît : on invente des exemples plausibles (GOBELET 20cL, SACHET KRAFT 1kg).

Le pipeline fait deux choses dures et faillibles :

1. Extraction — lire le document et en sortir les bonnes lignes : produit, quantité, unité, prix. La difficulté : mise en page chaotique, colonnes fusionnées, double référencement, lignes ajoutées dans un commentaire libre, ratures.
2. Matching — relier chaque ligne extraite au bon SKU d'un catalogue de milliers de variantes. La difficulté : « gobelet 20 » peut désigner dix références qui ne diffèrent que par la matière ou le conditionnement.

Les deux reposent sur des LLM → les deux sont non déterministes → les deux doivent être évalués séparément (on verra pourquoi c'est crucial).

Les deux familles d'erreurs

Chaque étape a sa manière de mentir, et elles ne se soignent pas pareil :

Retiens la dissymétrie : rater une ligne et inventer une ligne sont deux fautes différentes. La seconde est souvent la pire (on facture un produit non commandé) et pourtant la plus discrète. Une bonne éval doit rendre l'invention visible et coûteuse — on y reviendra longuement.

Pourquoi séparer extraction et matching

Si tu ne mesures que le résultat de bout en bout et qu'il est mauvais, tu ne sais pas qui a fauté : la lecture ou l'appariement. Impossible d'agir. Un harness sérieux permet donc de mesurer chaque étage isolément (dernier module) — exactement comme tu profiles séparément la requête SQL et le rendu template quand une page est lente.