Vérifier des fiches produit sans vérité de référence

Une extraction qui ne dit pas quand elle se trompe

Nricher enrichit les catalogues de sites marchands. À partir du titre et de la description d'un produit, une chaîne le catégorise, extrait ses attributs (couleur, dimensions, matière, poids…) avec des expressions régulières, normalise les valeurs et produit une fiche structurée. Cette extraction est déterministe et facile à inspecter, mais elle ne donne aucun score de confiance.

Le contrôle se fait donc à la main : un account manager relit un échantillon de 1 000 produits, ce qui lui prend un à deux jours. Et la difficulté est réelle. Sur un canapé convertible, l'extraction lit « 140 × 190 » : ce sont les dimensions du matelas. Elle lit un poids de 32 kg : c'est la densité de la mousse. Le catalogue du client, de son côté, contient aussi des erreurs.

Il ne s'agit donc pas de comparer une prédiction à une vérité, mais d'arbitrer entre deux sources douteuses.

Construire une vérité sans rien annoter

• Quand le catalogue et l'extraction concordent après normalisation, je considère la valeur comme correcte.
• Ce jeu ne contient alors que des accords. J'injecte des erreurs dans 20 % des lignes en remplaçant la valeur par une autre valeur réelle du même attribut : une erreur trop grossière n'apprendrait rien. La graine est fixe, tout est reproductible.
• J'ajoute un cas « information absente » en retirant l'information du texte sur environ 10 % des lignes de chaque attribut.

Le banc d'essai réunit 4 catalogues de production, 35 attributs et 30 919 lignes. Un point de repère : 73,3 % des valeurs sont déjà justes sans rien faire. Toute méthode doit faire mieux que ça.

L'inférence textuelle, phrase par phrase

La valeur à vérifier devient une hypothèse, par exemple « la hauteur est 84 ». Le modèle mDeBERTa-v3, multilingue car les catalogues sont en français, la confronte à chaque phrase de la description et renvoie trois probabilités : implication, contradiction ou neutralité. Les descriptions sont découpées en phrases (21 en médiane), car ces modèles se dégradent sur les textes longs, et je garde le maximum : une seule phrase qui soutient la valeur suffit.

Au meilleur seuil (0,70 sur l'implication), cette règle atteint 0,808 d'exactitude équilibrée et 0,919 de précision.

En analysant les attributs un par un, j'ai trouvé ce qui les rend difficiles à vérifier. Ce n'est pas le nombre de valeurs possibles, c'est la négation : les attributs qui s'expriment par une phrase négative (« non déhoussable ») plafonnent entre 0,437 et 0,854 d'AUC, les autres atteignent 0,968 à 0,997.

Un modèle tabulaire qu'on n'entraîne pas

TabPFN est pré-entraîné sur des millions de jeux de données synthétiques, puis gelé. On ne l'entraîne pas : il reçoit les exemples étiquetés dans son contexte et prédit en un seul passage. Assez léger pour des milliers d'exécutions sur un ordinateur portable, sans GPU, environ 4 secondes chacune. Ne lisant pas le texte, il reçoit une description encodée par BGE-M3 puis réduite à 50 composantes par ACP, avec ou sans les scores d'inférence ; un modèle par attribut.

L'ablation appariée (test de Wilcoxon) tranche : retirer les 4 scores d'inférence coûte 8,9 points, retirer les 50 composantes d'embedding n'en coûte que 1,9. Quatre nombres calculés face à la valeur à vérifier valent plus que cinquante composantes calculées à l'aveugle : c'est l'orientation de la représentation du texte, pas sa richesse, qui décide. Au passage, l'écart-type entre attributs passe de 0,128 à 0,079 : le modèle est meilleur et plus régulier.

TabSTAR permettait de tester l'inverse : un modèle pré-entraîné sur 350 jeux de données réels, avec un encodeur de texte entraînable, qui lit la description brute. Seul, il fait moins bien que la règle d'inférence (0,742). Avec les scores, il gagne 15,6 points (0,898) mais reste derrière TabPFN, pour un temps environ 28 fois plus long (116 s par exécution, sur GPU).

Un seul réglage : le seuil

L'architecture que j'ai proposée se branche sur la chaîne existante sans la modifier :

1. Titre et description du produitchaîne existante : catégorisation, extraction par règles, normalisation
2. Le catalogue du client et l'extraction sont-ils d'accord ?
   Oui → la ligne rejoint le corpus d'entraînement. Le système se nourrit de son propre flux, sans annotation.

   Non → la ligne part en vérification.
3. Vérificationscores d'inférence (mDeBERTa-v3) + description encodée (BGE-M3, ACP) + code de la valeur candidate → TabPFN → probabilité que la valeur soit juste
4. La probabilité dépasse-t-elle le seuil ?
   Oui → la valeur part directement dans la fiche produit.

   Non → relecture par un data developer.

Le seuil se déplace sans rien réentraîner. Réglé pour 99 % de précision, il valide automatiquement 68 % des valeurs : la relecture humaine ne porte plus que sur un tiers du volume, et ce tiers est choisi, pas tiré au hasard.

Ce que ce système ne voit pas

• La référence vient d'un accord entre deux sources. Si le catalogue et l'extraction partagent le même biais, il passe inaperçu. Il faudrait annoter un échantillon indépendamment du texte.
• Les erreurs sont injectées, pas observées. La mauvaise attribution d'une valeur, l'erreur la plus fréquente en production, n'est pas reproduite. La prochaine étape est de valider sur de vraies erreurs.
• Détecter une absence n'est pas vérifier. Sans valeur candidate, il n'y a pas d'hypothèse, donc pas de score : sur le cas « information absente », l'exactitude plafonne à 0,57. Ce cas mérite une tâche à part.