Même question, chiffres différents, mauvaise réponse
« Allouer 400 unités » et « allouer 1 000 unités » produisent des vecteurs presque identiques. Un cache qui ne s'appuie que sur la similarité servira à un responsable les chiffres d'un autre.
Même question, chiffres différents, mauvaise réponse. C’est ce qui s’est passé quand un cache d’approvisionnement a rapproché deux requêtes sur la seule similarité.
Pourquoi cela compte
Le cache est ce qui garde un système rapide : on range la réponse, on la ressert quand quelqu’un repose la même question. La méthode courante convertit chaque question en une empreinte numérique et vérifie à quel point une nouvelle empreinte ressemble à une empreinte rangée.
Voici où cela casse. « Allouer 400 unités au fournisseur A » et « allouer 1 000 unités au fournisseur A » produisent des empreintes quasi identiques. Le sens est le même. Les chiffres diffèrent. La bonne réponse change entièrement.
Quand des réponses en cache alimentent de vraies décisions d’achat, une correspondance erronée conduit un responsable des achats à valider une allocation fournisseur sur les chiffres de quelqu’un d’autre, et l’écart ressort à l’inventaire du trimestre suivant.
Pour le responsable qui signe cette allocation, un cache rapide et faux vaut moins qu’un système lent et juste.
Comment cela fonctionne
Le réglage par défaut des caches en production est la seule similarité cosinus, avec un seuil placé assez haut pour rassurer. Les gardes fondées sur les entités sont ce qui referme l’écart que ce seuil laisse ouvert. Dans un domaine où « 400 unités » et « 1 000 unités » se plongent presque au même endroit, monter le seuil ne suffit pas.
J’ai intégré ce correctif à un copilote ERP LangGraph pour la chaîne d’approvisionnement. Il applique deux couches de correspondance.
D’abord, une correspondance textuelle exacte. On hache la question, on la cherche. Même question, réponse rangée.
Ensuite, une correspondance sémantique avec garde. On compare les empreintes à 0,95 de similarité. Avant d’accepter, on vérifie que les deux questions contiennent les mêmes nombres et les mêmes codes d’entité. « 400 unités » contre « 1 000 unités » échoue à la garde. « Fournisseur A » contre « fournisseur B » échoue. Mêmes nombres, mêmes codes, formulation différente ? Là, c’est une vraie correspondance.
Certaines réponses ne sont jamais mises en cache : celles qui attendent l’approbation d’un responsable, parce qu’elles portent un identifiant de décision en cours, et celles produites pendant une indisponibilité du modèle.
Ce qui m’a surpris : la garde qui extrait les nombres et les identifiants a demandé plus de travail que la recherche par similarité. Le cache d’origine tenait en 24 lignes. La version de production en compte 201. Dans un domaine où une mauvaise réponse déplace de l’argent, j’ai réglé ce cache pour la justesse plutôt que pour le taux de succès, et j’ai testé la garde exactement là-dessus.
