L'hallucination héritée

Chapitre 4 — L'hallucination héritée

C'est peut-être l'histoire la plus instructive de toute l'enquête, car elle aborde un thème que les tutoriels ignorent et qui, en réalité, cause plus de dommages que tous les autres réunis : la qualité des données en entrée.

Une entreprise américaine de vélos — appelons-la ainsi par respect — disposait d'une énorme archive photographique, des milliers d'images de produits, d'événements, de clients à vélo, de voyages promotionnels. C'était le patrimoine visuel de l'entreprise, accumulé en quinze ans de campagnes. À un moment de clairvoyance, quelqu'un avait utilisé un service de tagging automatique pour ajouter, à chaque photo, une liste d'"objets présents" : "vélo, casque, route, montagne, personne". Des métadonnées utiles, en théorie, pour la future recherche visuelle. Archivées à côté des photos, oubliées pendant des années, puis récupérées et ingérées dans le nouveau RAG de l'entreprise avec la conviction naturelle que "plus de métadonnées, c'est mieux".

Après l'ingestion, la recherche d'images donnait des résultats surréalistes. Vous cherchiez "bici in città" et il vous affichait une photo d'un lac. Vous cherchiez "modello donna con casco" et il vous affichait une voiture ancienne. Vous cherchiez "montagna" et il vous affichait indistinctement n'importe quoi — un échantillon aléatoire de l'ensemble des archives, comme si le système avait tiré au sort. L'équipe a d'abord pointé du doigt le modèle d'embedding visuel. Puis le reranker (voir chapitre précédent, pour comprendre pourquoi cette piste était particulièrement séduisante). Puis la qualité des descriptions générées par l'IA.

L'enquête réelle, menée cette fois avec une query SQL directe à la base de données, a révélé quelque chose de grotesque. Sur 3997 photos du catalogue, toutes, mais bien toutes, avaient la même liste d'objets. Une liste de dix-neuf éléments — "voiture, moto, lac, mer, montagne, vélo, casque, route, ville, personne..." — qui n'avait aucun rapport avec le contenu de la photo individuelle. Elle avait été importée, il y a des années, depuis un autre site web, comme ensemble de tags génériques pour remplir un champ obligatoire du CMS. Personne, dans l'entreprise, ne s'en souvenait plus. Les photos étaient passées de système en système en traînant avec elles ces étiquettes fantômes, plausibles à suffire pour ne pas éveiller les soupçons, suffisamment toxiques pour corrompre toute recherche basée sur elles. Le moteur de recherche, diligent, les utilisait comme symptôme de contenu. Et renvoyait n'importe quelle photo pour n'importe quelle requête, avec un certain degré d'hallucination garanti par la loi de la nature.

Le point crucial, celui qui fait mal quand on le comprend, c'est que dans un RAG, les données "bruyantes" ne font pas de bruit audible. Elles ne ralentissent pas le système, ne génèrent pas d'erreurs, n'allument pas de voyants. Elles se limitent à éroder silencieusement la qualité des résultats. Et quand le modèle linguistique en aval reçoit cinq documents dont quatre sont hors sujet, il ne vous dit pas "ceux-ci n'ont rien à voir, posez-moi autre chose" : il construit diligemment une réponse qui les mélange, et la réponse sonne toujours plausible. Toujours. L'hallucination finale — cette réponse inventée dont on se plaint — ne naît pas du modèle, comme le raconte le récit dominant. Elle naît en amont, des données. Le modèle n'est que celui qui l'emballe dans une phrase grammaticalement impeccable. Mais la faute est ailleurs, plus en arrière, dans ce que vous avez donné à manger au système des mois avant de lui demander quoi que ce soit.

Cette observation a des conséquences pratiques qui coûtent de l'argent. Le premier travail de ceux qui construisent un RAG d'entreprise sérieux, avant d'écrire une seule ligne de code, est de faire l'autopsie de leurs données. D'où elles proviennent. Qui les a touchées. Quels champs sont observés et lesquels sont des vestiges fossiles de systèmes précédents. Quels métadonnées ont du sens aujourd'hui et lesquels en avaient en 2017 et personne ne s'est jamais donné la peine de les nettoyer. C'est un travail peu glamour, très archivistique, complètement absent des tutoriels, souvent perçu comme "non technique" et donc snobé par les équipes de développement. Mais sans cette hygiène initiale, toute architecture géniale que vous mettez en place ne devient qu'un amplificateur très puissant de déchets très anciens.

Dans le cas de l'entreprise américaine, la solution a été brutale et juste : vider le champ "objets", reconstruire les métadonnées à partir de zéro avec un modèle de vision moderne appliqué à chaque photo, et suivre, cette fois, quand et comment chaque métadonnée a été produite. Travail fastidieux. Résultat : la recherche a enfin commencé à fonctionner. Non pas parce qu'ils avaient changé de modèle. Parce qu'ils avaient fait le ménage dans le débarras.