Les défauts silencieux des intégrations : pourquoi votre IA se trompe
Les données textuelles non structurées ont récemment proliféré, allant de la documentation technique et de la littérature scientifique aux publications sur les réseaux sociaux et aux évaluations clients. Les entreprises de divers secteurs réalisent de plus en plus que ces textes offrent des informations précieuses, mais leur obtention, leur organisation et leur exploitation sont complexes.
La richesse sémantique du langage humain n'est pas capturée par les techniques conventionnelles de traitement de texte par mots-clés, qui se sont révélées insuffisantes. Par exemple, une recherche sur « problèmes de voiture » peut ne pas renvoyer d'articles pertinents concernant des « problèmes automobiles », et un avis produit mentionnant un « écran bloqué » peut passer inaperçu lors de l'examen des plaintes de clients concernant des « pannes système ».
L'intégration de texte, une nouvelle technique permettant de convertir les mots et les phrases en vecteurs numériques capturant leur sens, a été développée et utilisée en réponse à cette contrainte fondamentale. Les grandes entreprises technologiques ont investi des milliards dans la création de modèles d'intégration toujours plus avancés ; les intégrations d'OpenAI, RoBERTa de Meta, BERT de Google et une multitude d'alternatives open source sont désormais des éléments essentiels des systèmes de traitement du langage naturel (TALN) contemporains.
Cependant, malgré leur utilisation intensive, nous ne comprenons toujours pas pleinement le fonctionnement de ces modèles d'intégration en pratique. Ce manque de compréhension a entraîné :
- Des erreurs de mise en œuvre coûteuses se produisent lorsque les systèmes ne répondent pas aux besoins de l’entreprise.
- Expérience utilisateur médiocre lorsque le contenu pertinent est ignoré par les systèmes de recherche ou de recommandation. Différences de performances selon les groupes démographiques, les catégories de contenu et les langues des utilisateurs.
- Utilisation inefficace des ressources par les organisations qui emploient des modèles trop complexes
Pertinence et applicabilité à l'industrie
De nombreux secteurs d’activité différents peuvent bénéficier directement de cette analyse :
Commerce de détail et commerce électronique :
- Amélioration de la recherche de produits pour prendre en charge les demandes multilingues, les synonymes et les fautes d'orthographe.
- Améliorer les systèmes de recommandation pour identifier des produits comparables avec des descriptions différentes.
- Développer des outils d’analyse des avis plus sophistiqués, conscients des subtilités des sentiments.
Soins médicaux :
- Permettre à la terminologie médicale d'être mise en correspondance avec les variations de notation dans les systèmes de recherche de documents cliniques.
- Quel que soit le niveau d’études, améliorer le traitement linguistique du patient pour la description des symptômes.
- Améliorer la recherche de littérature médicale en faisant mieux correspondre les concepts à travers les variables technologiques
Finance:
- Améliorer la surveillance de la conformité en cas d’infraction aux politiques, quelle que soit leur formulation.
- Améliorer la détection des fraudes grâce à l’identification de modèles douteux dans les variations linguistiques.
- Améliorer le service client en comprenant mieux les différents types de demandes des consommateurs
Déterminer si votre modèle d'intégration produit des résultats similaires : cette analyse aide les organisations à prendre de meilleures décisions concernant le choix du modèle, les besoins en prétraitement et les stratégies d'amélioration possibles, en offrant une méthode systématique pour comprendre le comportement d'intégration. Cette approche permet de créer des systèmes de traitement du langage plus efficaces, plus fiables et plus équitables.
Que sont les incorporations de texte ?
Pour les non-initiés, les intégrations de texte convertissent les mots ou les phrases en vecteurs numériques – essentiellement de longues listes de nombres, des vecteurs denses aux multiples dimensions. Ces vecteurs sont positionnés dans un espace à haute dimension où la similarité sémantique est représentée par la proximité. En termes plus simples, les éléments ayant des significations similaires devraient être proches les uns des autres dans cet espace. Ces intégrations sont à la base de pratiquement tout en TAL moderne :
Lorsque vous effectuez une recherche sur Google, il comprend que vous vouliez dire « hôtels à New York » même si vous avez tapé « endroits où séjourner à New York ».
Lorsque votre client de messagerie suggère des réponses
Lorsqu'un système de recommandation de contenu identifie les articles susceptibles de vous plaire
Cette capacité alimente de nombreuses applications :
- Moteurs de recherche sémantique
- Systèmes de recommandation de contenu
- Identification de l'intention du chatbot
- Organisation et regroupement des documents
- Systèmes de classification de textes et de réponse aux questions
L'efficacité de ces applications dépend en grande partie de la capacité du modèle d'intégration à gérer les différentes variantes de texte et les occurrences linguistiques. Un modèle trop sensible aux petites variations de formatage aurait des difficultés à traiter les requêtes de recherche réelles, tandis qu'un modèle traitant les expressions « J'adore ce produit » et « Je déteste ce produit » comme quasi identiques serait inefficace pour l'analyse des sentiments.
Pourquoi j'ai commencé à étudier les modèles d'intégration
Je n'oublierai jamais le jour où je recherchais des modèles d'intégration pour l'un de mes clients à partir de documents d'exemple. J'ai essayé de chercher « ordinateurs portables sans écran tactile », et j'ai obtenu une réponse concernant les ordinateurs portables à écran tactile dans l'index vectoriel. Notre modèle d'intégration avait complètement raté la négation.
Ce moment m'a marqué. Si le modèle ne comprenait pas un « sans » basique, que lui manquait-il d'autre ? Cet épisode m'a mené sur une voie inattendue. Je devais comprendre la gravité du problème. Certes, les tests de notre modèle d'intégration semblaient impressionnants, mais comment se comportait-il avec le langage courant et confus que nos utilisateurs tapaient quotidiennement ? Que se passait-il lorsque des mots étaient mal orthographiés, des phrases incomplètes ou que des émojis étaient utilisés ?
Après deux années d'expérimentation avec différents modèles d'intégration dans différentes applications grâce à RAG Experiment Accelerator ( https://github.com/microsoft/rag-experiment-accelerator ), j'ai développé une méthode systématique pour évaluer la façon dont ces modèles gèrent différents types de variations de phrases. Ce que j'ai découvert m'a effrayé.
Il ne s'agissait pas de bugs aléatoires, mais de failles profondes et systématiques, ancrées dans la façon dont ces modèles perçoivent le langage. Et personne n'en parlait. Je partage ces conclusions car j'ai vu trop d'équipes perdre des mois à mettre en œuvre des systèmes sophistiqués basés sur l'intégration, pour découvrir trop tard qu'ils se trompaient de manière inattendue.
Ce problème n'est pas seulement académique. Les conséquences d'une mauvaise compréhension du comportement d'intégration sont graves : un collègue d'une grande entreprise du secteur de la santé m'a confié que son système de recherche d'informations médicales manquait de documents cliniques pertinents, car son modèle d'intégration ne gérait pas correctement les abréviations et les variations de terminologie médicale. Dans le secteur de la santé, ce type d'erreur peut affecter les décisions thérapeutiques.
Dans une société de services financiers, le système de surveillance de la conformité a manqué des violations de politique, car son modèle d'intégration ne reconnaissait pas que les phrases à la voix passive (« des fonds ont été transférés ») signifiaient la même chose que la voix active (« quelqu'un a transféré des fonds »). J'ai vu des entreprises de e-commerce perdre des millions de dollars à cause de l'incapacité de leur système de recherche de produits à prendre en compte les fautes de frappe et les raccourcis linguistiques courants utilisés par les acheteurs.
Mon approche de test
J'ai développé un cadre de test qui examine la façon dont les modèles d'intégration réagissent à différentes catégories de variations de texte. En utilisant la similarité cosinus comme métrique (où 1,0 signifie une signification identique et 0,0 signifie une absence totale de lien), j'ai exécuté des centaines de cas de test. Je vais détailler mes résultats, en me concentrant sur les différents modèles, dont MSMarco DistilBERT, l'intégration de texte OpenAI et bien d'autres. J'ai observé des tendances similaires pour la plupart des intégrations basées sur des transformateurs.
Impossible de distinguer les majuscules des minuscules (du tout)
Celui-ci m'a choqué. Les modèles d'intégration considèrent « Apple a annoncé de nouveaux produits » et « Apple a annoncé de nouveaux produits » comme étant exactement la même chose : un score de similarité parfait de 1,0. Aucune différence.
J'ai rencontré ce problème avec un système de catalogue de produits. La recherche ne faisait pas la différence entre la marque « Apple » et le fruit « pomme ». Les clients recherchant des produits Apple obtenaient des recettes de tarte aux pommes. Pensez-vous que vos clients seront satisfaits des résultats ? Je suis sûr que je ne les apprécierai pas.
Pourquoi est-ce important ? Pensez à tous les cas où la casse change de sens : « Polonais » vs « polonais », « mars » vs « mars », « facture » vs « facture ». Pour les textes juridiques ou médicaux, ces distinctions peuvent être cruciales. Nous travaillons essentiellement avec des modèles partiellement aveugles à une dimension entière du langage écrit. Il existe un moyen de résoudre ce type de problèmes, et nous les aborderons plus tard. Examinons plus en détail les problèmes liés aux représentations vectorielles continues. Notez que cela peut être avantageux si ces différences n'affectent pas le cas traité.
Les chiffres pourraient aussi bien être inventés
Celui-ci m'a également stupéfait. Les modèles d'intégration considèrent que « l'investissement a rapporté 2 % par an » et « l'investissement a rapporté 20 % par an » sont identiques, avec un score de similarité extrêmement élevé de 0,97. Il n'y a aucune différence notable entre les deux scénarios.
J'ai rencontré ce problème avec un système de recherche de documents financiers. L'algorithme ne faisait pas la différence entre « frais de gestion : 0,2 % » et « frais de gestion : 2,0 % ». Les investisseurs à la recherche de fonds à faibles frais se voyaient alors recommander des options onéreuses. Pensez-vous que votre compte de retraite serait satisfait de cette erreur ? Je suis sûr que je n'aimerais pas voir mon épargne engloutie par les frais.
Pensez à tous les cas où les valeurs numériques représentent des instructions de dosage critiques, des tolérances techniques, des rendements financiers et des échéances contractuelles. Pour les textes d'investissement ou médicaux, ces distinctions peuvent être déterminantes. Nous travaillons essentiellement avec des modèles qui ne maîtrisent pas les chiffres, malgré la gestion de textes contenant des quantités importantes.
Le problème du « non » est effrayant
Celui-ci est vraiment dangereux. Ajouter « not » à une phrase – en renversant littéralement le sens – n'affecte pratiquement pas les scores de similarité. Nous avons régulièrement observé des scores supérieurs à 0,95 pour des phrases totalement opposées. « Le traitement a amélioré les résultats des patients » contre « Le traitement n'a pas amélioré les résultats des patients » → similarité de 0,96. Lorsque j'ai montré cela à un médecin qui utilisait notre moteur de recherche médicale, il a été horrifié. Il était tellement horrifié qu'il s'est éloigné physiquement de l'ordinateur. Et il avait raison.
Nous construisions un système que les médecins utiliseraient pour trouver des protocoles de traitement. Une erreur peut entraîner la mort. La négation n'est pas un cas limite : elle est fondamentale au langage humain. Si votre système de recherche, de recommandation ou d'analyse ne parvient pas à distinguer « efficace » de « inefficace » ou « sûr » de « dangereux », vous construisez de dangereuses machines à hallucinations.
Dans le domaine de la santé , cela pourrait signifier recommander des traitements nocifs. Dans les documents juridiques , cela pourrait complètement inverser les obligations contractuelles. En modération de contenu , vous pourriez manquer la différence entre « la violence est acceptable » et « la violence n'est jamais acceptable ».
Les espaces n'ont pas d'importance (jusqu'à ce qu'ils en aient vraiment)
Espaces superflus, tabulations, formatage étrange… les modèles s'en moquent. La similarité reste supérieure à 0,995. Mais supprimer tous les espaces ? La similarité chute soudainement à 0,82. J'ai rencontré ce problème en travaillant sur du contenu extrait et dont l'espacement était irrégulier en raison d'un code HTML de mauvaise qualité. Nous avons développé ce magnifique système de recherche pour une bibliothèque numérique contenant des milliers de documents extraits. La moitié des requêtes n'ont rien donné d'utile en raison d'un espacement incohérent. Les bibliothécaires étaient prêts à abandonner le projet.
Cette particularité devient dévastatrice lorsqu'il s'agit de contenu généré par les utilisateurs, de documents OCR ou de langues qui n'utilisent pas les espaces comme l'anglais (comme le thaï ou le chinois). Cela implique également que ces modèles peinent à gérer les hashtags, les URL et les codes produits, des éléments que les utilisateurs recherchent quotidiennement.
Les références sont difficiles
Les modèles intégrés perçoivent « La voiture est à gauche de l'arbre » et « La voiture est à droite de l'arbre » comme quasiment identiques, avec un score de similarité incroyablement élevé de 0,98. Bien que décrivant des perspectives opposées, les modèles intégrés les perçoivent comme quasiment identiques. Pensez-vous que les responsables d'entrepôt seront ravis que les robots livrent des colis aux mauvaises stations ? Je peux vous assurer que je serais submergé de frustration.
Pensez à tous les cas où la perspective et les cadres de référence sont essentiels : directions de navigation, relations spatiales, positionnement relatif dans les procédures médicales et descriptions juridiques des scènes d'accident. Ces distinctions ne sont pas anodines : elles modifient complètement le sens selon la perspective. Nous travaillons avec des modèles incapables de déterminer si l'on décrit quelque chose de face ou de derrière.
Les contrefactuels sont complètement inversés
Celui-ci m'a fait rire, puis pleurer. Les modèles intégrateurs considèrent que « Si la demande augmente, les prix augmenteront » et « Si la demande augmente, les prix baisseront » sont pratiquement identiques – avec un score de similarité surprenant de 0,95 . Malgré cela, ils décrivent des scénarios économiques totalement différents !
J'ai rencontré ce problème en créant un système d'analyse pour des articles de recherche économique. L'algorithme ne parvenait pas à distinguer des relations causales opposées. Les économistes recherchant des articles sur les hausses de prix lors de pics de demande obtenaient des résultats sur les baisses de prix lors de récessions. Pensez-vous que les analystes financiers qui prennent des décisions d'investissement de plusieurs millions de dollars apprécieraient d'obtenir des informations exactement à rebours ? Je suis sûr que je ne voudrais pas que mon fonds de retraite soit géré de cette façon.
Pensez à nouveau à tous les cas où le raisonnement contrefactuel est essentiel : projections économiques, relations de cause à effet médicales, hypothèses juridiques et analyse des défaillances techniques. Ne pas pouvoir distinguer « si X, alors Y » de « si non X, alors non Y » revient à méconnaître fondamentalement la relation causale. En réalité, nous travaillons avec des modèles incapables de saisir la logique conditionnelle de base, malgré la gestion d'un texte riche en hypothèses et en prédictions.
Plages et valeurs exactes
Celui-ci m'a laissé sans voix. Les modèles d'intégration considèrent que « Le produit coûte entre 50 et 100 $ » et « Le produit coûte exactement 101 $ » sont pratiquement identiques : un score de similarité ahurissant de 0,98 . L'un est dans une fourchette, l'autre en dehors, mais le modèle le remarque à peine !
J'ai découvert cela en créant un comparateur de prix pour un client e-commerce. La recherche ne faisait pas la distinction entre les fourchettes de prix et les prix exacts, même lorsque le prix exact était hors de la fourchette spécifiée. Les acheteurs avec un budget strict de 100 $ recherchant des produits « à moins de 100 $ » se voyaient toujours proposer des articles à 120 $ ou 150 $. Pensez-vous que les clients avec un budget fixe apprécient de voir des produits qu'ils ne peuvent explicitement pas se permettre ? Je suis sûr que je ne voudrais pas perdre de temps à chercher des articles que je ne peux pas acheter.
Pensez à tous les cas où la distinction entre plages et valeurs exactes est cruciale : décisions de prix, plages de dosage des médicaments, délais légaux, tolérances de sécurité et critères de performance. Si votre modèle considère « au moins 25 jours » et « exactement 20 jours » comme identiques, vous perdez un sens critique. Nous travaillons avec des modèles incapables de faire la distinction entre flexibilité et précision, malgré la gestion du texte ; cette distinction influence les décisions.
La vérité et les résultats
Voici la comparaison entre msmarco-distilbert-base-tas-b, all-mpnet-base-v2 et open-ai-text-embedding-3-large, et vous remarquerez qu'il n'y a pas de différence significative entre la sortie de ces modèles.
Score d'intégration msmarco-distilbert-base-tas-b dans différents cas de test
score d'intégration all-mpnet-base-v2 dans différents cas de test
openai-text-embedding-3-large score d'intégration dans différents cas de test
Comment travailler avec les incorporations
Les intégrations sont incroyablement utiles malgré ces problèmes. Je ne dis pas de ne pas les utiliser, mais de les utiliser en toute connaissance de cause. Voici mes conseils éprouvés après des dizaines de projets et d'innombrables échecs :
Testez votre modèle sur des modèles de langage utilisateur réels avant le déploiement. Pas de benchmarks académiques, pas de cas de test épurés : utilisez des exemples concrets de la façon dont vos utilisateurs communiquent. Nous avons développé une boîte à outils de « test de stress linguistique » qui simule des variations courantes comme les négations, les fautes de frappe et les différences numériques. Chaque système que nous testons présente des failles dans certains domaines ; la question est de savoir si ces points sont pertinents pour votre application spécifique.
Créez des garde-fous pour contourner les angles morts critiques. Chaque application a ses propres exigences en matière de sécurité. Pour la santé, il s'agit généralement de négation et de précision des entités. Pour la finance, il s'agit de chiffres et de relations temporelles. Pour le juridique, il s'agit de conditions et d'obligations. Identifiez les éléments absolument infaillibles dans votre domaine et mettez en œuvre des mesures de protection spécifiques.
Combinez différentes techniques au lieu de miser uniquement sur les intégrations. Nos systèmes les plus performants combinent la recherche basée sur l'intégration avec la vérification des mots-clés, des contrôles de règles explicites et des classificateurs spécialisés pour les distinctions critiques. Cette redondance n'est pas inefficace ; elle est essentielle.
Soyez transparent avec les utilisateurs sur ce que le système peut et ne peut pas faire de manière fiable. Nous avons ajouté des scores de confiance qui signalent explicitement lorsqu'un résultat peut impliquer une négation, une comparaison numérique ou d'autres faiblesses potentielles. Les utilisateurs apprécient cette honnêteté et cela renforce la confiance dans le système.
Voici la leçon la plus importante que j'ai apprise : ces modèles ne comprennent pas le langage comme les humains, mais des modèles statistiques. Lorsque j'ai cessé de m'attendre à une compréhension humaine et que j'ai commencé à les considérer comme des outils sophistiqués de recherche de modèles, avec des angles morts spécifiques, mes systèmes se sont améliorés. Beaucoup mieux.
Les angles morts que j'ai décrits ne sont pas près de disparaître : ils sont intégrés au fonctionnement de ces modèles. Mais si vous savez qu'ils existent, vous pouvez les contourner. Et parfois, reconnaître une limite est le premier pas vers sa résolution.
Remarque : j’ai découvert de nombreux autres cas de ce type au cours d’expériences, et je les aborderai dans mon prochain article avec des exemples de code.
Le prochain article de la suite paraîtra bientôt. Restez connectés !
