Garantir la qualité du matching

Le principe : la confiance est graduée, jamais binaire

La recherche hybride (leçon précédente) produit des candidats scorés — mais que fait-on du score ? Le pipeline le transforme en décision à trois issues via deux seuils :

fast match  : score ≥ 0.85  → matched (voie rapide, SQL pur)
              sinon         → deep match (réécritures Haiku + rerank Cohere)
deep match  : score ≥ 0.6   → matched
              candidat < 0.6 → needs_review   (l'humain tranchera)
              aucun candidat → not_found

Le point de design essentiel : le système ne force jamais un match douteux. Une ligne needs_review conserve son best_match ET ses alternatives (top-4) — l'UI présente le doute au lieu de le cacher. Chaque ligne persiste aussi match_confidence et matched_by (history|fast|deep|direct) : la provenance de chaque décision est auditable.

À noter (honnêteté du rétro-engineering) : ces seuils sont aujourd'hui globaux et codés en dur — le ScoringConfig porte un commentaire « later read from tenant config ». Un grossiste en visserie et un distributeur pharma n'ont sans doute pas la même tolérance au faux positif.

Le cache d'apprentissage : product_match_history

La source la plus prioritaire du pipeline n'est ni le SQL ni le LLM — c'est la mémoire :

• à la fin de chaque pipeline, le node match_history upsert chaque ligne résolue : clé = nom produit normalisé (accents retirés, minuscules, espaces réduits — « Câble RJ45 Cat6 » ≡ « cable rj45 cat6 »), valeur = variant matché + usage_count incrémenté ;
• au pipeline suivant, une phase 0 consulte ce cache en batch AVANT tout matching : hit → matched_by="history", statut matched, fast et deep entièrement court-circuités (zéro LLM, zéro rerank) ;
• le tout scoppé par tenant automatiquement — c'est une table sous RLS comme les autres (leçon 2 !). Subtilité : le prix n'est PAS caché — il est rechargé du catalogue courant à chaque hit (un prix figé dans un cache serait un bug métier).

Un client B2B recommande souvent les mêmes produits avec les mêmes libellés : ce cache transforme le 2ᵉ import en opération quasi gratuite et déterministe.

Le feedback utilisateur : product_match_feedback

Quand l'utilisateur corrige un match dans l'UI (PATCH .../lines/{id}), le système capture le signal : le candidat choisi est flaggé was_overridden_by_user, son rang d'origine enregistré. Et à chaque deep match, un snapshot du top-K (avec les 5 sous-scores de chaque candidat) est persisté avec was_selected. Cette table est un dataset d'entraînement en construction : elle contient exactement ce qu'il faut pour, un jour, entraîner un reranker maison — features (sous-scores) + label (le choix humain).

Nuance découverte au rétro-engineering : les corrections humaines vont dans PMF mais ne sont pas réinjectées dans le cache history — corriger un match ne « répare » pas encore la mémoire. La boucle d'apprentissage temps réel n'est fermée qu'à moitié.

Les garde-fous en amont : ne pas matcher du faux

La qualité du matching commence avant le matching — si le structurer hallucine une ligne, tout l'aval travaille sur du vent :

1. grounding par contrat : le prompt d'extraction interdit d'inventer un SKU, impose raw_text (le texte source exact) sur chaque ligne — chaque sortie est traçable vers sa source ;
2. validator : lignes sans nom, quantité ≤ 0 ou non numérique → éliminées ; un validation_score global déclenche l'erreur bloquante si tout est invalide ;
3. critique LLM : les lignes suspectes (score faible, nom trop court/long) passent devant Haiku qui détecte les artefacts classiques (un sous-total pris pour un produit, un doublon) — aujourd'hui en télémétrie seule, la boucle de re-extraction n'est pas câblée ;
4. brand veto & golden match : les deux règles dures du scoring — jamais de faux positif inter-marques, jamais de doute sur un SKU exact ;
5. anti-pollution : le pipeline live ne crée jamais de produit au catalogue (allow_auto_create=False) — un email mal lu ne peut pas inventer un variant.

Les chantiers ouverts (et comment l'histoire s'est écrite)

Au moment du rétro-engineering initial, trois manques étaient visibles — tu as les concepts pour les nommer :

• l'éval offline : des golden sets dormaient dans samples/ sans harness pour les rejouer… ce manque a depuis été comblé — un harness d'éval complet a été construit (corpus de cas durs, scorecard, runs Langfuse), et il a immédiatement fait progresser le matcher. C'est toute la leçon suivante, la plus instructive du module ;
• pas de métriques agrégées en prod : le taux de correction utilisateur (LE capteur de qualité) est calculable en SQL dans PMF, mais aucun compteur/dashboard ne le suit en continu — le « monitoring étage 4 » du cours ML, toujours à construire ;
• seuils non tenant-isés et boucle history↔feedback ouverte : l'éval a d'ailleurs prouvé le danger de cette boucle (le cache apprend les erreurs d'un premier import raté et les re-sert). Premier correctif mergé depuis : un trust gate — le cache ne mémorise et ne re-sert que les matchs confiants. La réforme complète (write-on-validation + invalidation) reste au backlog.

La morale d'étape : la mécanique de qualité au fil de l'eau (seuils, revue, mémoire, garde-fous) était solide ; dès que la mesure systématique est arrivée, elle a trouvé en quelques jours ce que des mois d'usage n'avaient pas prouvé.