Oublier sans prévenir : peut-on compter sur l'IA pour restituer des insights research ?

On s’est récemment interrogé sur le fait d’utiliser les IA pour incarner des utilisateurs, des clients (panels synthétiques). On passe au cran d’après : on s’interroge sur la capacité qu’a l’IA à interpréter, à incarner des insights utilisateurs. La question qu’on se pose, c’est quelle est la meilleure approche technique pour que l’IA utilise des insights utilisateurs pour répondre à des questions. Le fantasme derrière, c’est toujours le même : parler à des utilisateurs en leur absence.

Et la question technique, c’est quelle est la meilleure façon de faire. Est-ce qu’il vaut mieux donner seulement des extraits bien fléchés ? C’est ce qu’on appelle le RAG : avant chaque réponse, un programme cherche dans les entretiens les extraits qui ressemblent le plus à la question posée, et l’IA ne reçoit que ces extraits. Quelles approches de RAG sont les plus efficaces ? Et d’ailleurs, est-ce qu’on a besoin d’un RAG ? Pour cette comparaison, on a utilisé des entretiens inventés, ce qui permet de connaître la bonne réponse à chaque question. Nos propres données, anonymisées, font l’objet d’un second article.

Les résultats, c’est qu’évidemment, si on donne peu d’extraits, même bien fléchés, l’IA rate beaucoup (25 points sur 53 avec 6 extraits), et plus on donne d’extraits, plus elle progresse. Le problème, c’est que ces oublis ne sont pas documentés. Grosso modo, on a une réponse parfaitement formulée, qui utilise les mots de l’utilisateur, mais qui contient des omissions dont on n’est pas tenu informé, et qui se répètent. Si on donne les entretiens en entier au lieu des extraits, il y a très peu d’erreurs (2 sur 53), et on n’a observé aucune hallucination.

Comment on a monté le banc d’essai

Les données dont on disposait, c’étaient trois utilisateurs fictifs d’un service en ligne, avec dix entretiens chacun, soit environ 14 000 tokens par utilisateur (un token est l’unité de texte que le modèle lit et qu’on lui facture). Pour interroger ce corpus, on avait 30 questions, découpées en 77 points précis. Pour 53 d’entre eux, on connaissait la bonne réponse, et même la phrase d’entretien qui la prouvait. Les 24 autres étaient des pièges : soit le sujet, plausible, était absent des entretiens, soit il concernait un autre utilisateur, parce qu’on se posait aussi la question de la bonne attribution à l’utilisateur.

On a testé des modèles d’Anthropic, en montant en taille : d’abord Haiku, puis Sonnet, puis Opus, les trois en version 5.5. Chaque question a été posée cinq fois, pour mesurer la répétabilité. En bout de chaîne, un juge, une autre IA (Sonnet), notait les réponses sans avoir la bonne réponse. Pour vérifier ce juge, on lui a glissé 48 inventions : il en a repéré 46.

Les tests statistiques

Avec 53 points, un écart de quelques unités peut venir du hasard. Pour chaque taux, on donne donc un intervalle à 95 %, calculé par la méthode exacte de Clopper-Pearson : en fait, c’est simplement l’ensemble des taux encore compatibles avec ce qu’on a observé. Pour comparer deux façons de faire posées sur les mêmes points, on utilise un test de McNemar exact, qui ne regarde que les points justes d’un côté et faux de l’autre, et donne une valeur p, la probabilité d’observer un écart au moins aussi grand si les deux façons de faire se valaient. Et comme on fait cinq comparaisons de ce genre, on serre le seuil à 0,01 (correction de Bonferroni) pour ne pas trouver un écart par chance.

Si l’IA a l’info, elle s’en sert, sinon elle ne la devine pas

Certains de nos résultats semblent enfoncer une porte ouverte, d’autres un petit peu moins. Si on fournit peu d’extraits, même bien fléchés, l’IA produit clairement beaucoup plus d’erreurs : 25 points ratés sur 53 avec 6 extraits, 18 avec 12, 7 avec 24. Si on charge tout dans la fenêtre de contexte du modèle, c’est encore mieux, 2 sur 53, mais encore une fois, parce qu’il n’y a pas tant d’informations que ça.

Ce sont des statistiques inférentielles : on mesure un écart, et on vérifie qu’il ne vient pas du hasard. Avec 6 ou 12 extraits, la différence avec les entretiens en entier est significative. Avec 24, elle ne l’est pas : on ne peut pas dire que ça fait moins bien, ni que ça fait mieux. À partir d’un tiers du corpus, on ne distingue donc plus les deux.

La porte ouverte, c’est la cause : si l’IA a l’info, elle sait l’utiliser, et si elle ne l’a pas, elle ne devine pas qu’elle ne l’a pas. Avec 6 extraits, quand l’information fait partie des extraits, l’IA répond juste 28 fois sur 29, et quand elle n’y est pas, elle ne la trouve jamais, 24 fois sur 24 (on avait d’abord compté 4 réponses justes sans la bonne phrase : l’information était en fait dans un autre extrait). La recherche ne lui donne pas le bon morceau, donc évidemment, l’IA se trompe. Le cas le moins évident, c’est celui d’un de nos utilisateurs fictifs qui dit, au début de ses entretiens, qu’une fonction n’existe pas, puis la découvre dans ses derniers entretiens. La recherche n’a ramené que les premiers, et l’IA a répondu avec l’avis qu’il avait au départ. Avec des extraits, on peut donc perdre le fil d’un entretien à l’autre. Avec les entretiens en entier, l’IA lit toute l’histoire. Et une consigne plus stricte ou un modèle plus gros ne produisent pas de meilleurs résultats démontrables.

Se tromper, ici, veut dire oublier : aucune réponse n’affirme le contraire d’un entretien, et sur nos 24 pièges l’IA n’a rien inventé. Elle ne va pas non plus dire, pour chaque question, « je te réponds ça, mais je ne sais pas s’il n’y a pas d’autres choses dans mon corpus ». On a donc une réponse parfaitement formulée, qui utilise les mots de l’utilisateur, mais avec des omissions dont on n’est pas tenu informé, et qui se répètent. Avec 6 extraits, sur les 24 points ratés qui attendaient un détail précis (le 25e vérifiait seulement que l’IA s’abstient), l’IA prévient qu’il lui manque quelque chose dans 13 cas, et rien dans la réponse ne signale le manque dans 11 cas sur 24. Pour 17 des 24, le même oubli revient aux 5 essais.

Ce qui est moins évident, c’est l’écart avec les réglages courants : par défaut, LangChain et LlamaIndex, deux bibliothèques qui servent à monter un RAG, donnent respectivement 4 et 2 extraits au modèle, moins que notre plus petit essai. On ne l’a pas testé, mais à 6 extraits on ratait déjà près d’un point sur deux.

Et on a un corpus qui n’a pas une taille dingue : les dix entretiens d’un utilisateur représentent environ 10 % du seuil où Anthropic résume le contexte par défaut (150 000 tokens). Il faut quand même ajouter que donner les entretiens en entier n’est possible que sur un corpus de taille réduite. Si le corpus est énorme, on retombe sur le phénomène de l’aiguille dans une botte de foin (retrouver une information isolée dans un très long texte), que les fiches des modèles de pointe ne documentent plus guère : Anthropic a cessé de le publier, OpenAI et Google n’en gardent qu’une version plus dure. Et Anthropic recommande la compaction (le modèle résume ce qu’il a lu pour faire de la place) au-delà de 150 000 tokens, en reconnaissant qu’elle fait perdre du contexte : au-delà d’une certaine quantité d’informations chargées dans la fenêtre de contexte, il y a de la perte de données, de qualité, de précision. On ne l’a pas mesuré, mais c’est évident : si c’est la meilleure solution, ce n’est pas une solution qui répond à tous les problèmes non plus.

Le juge se trompe-t-il ?

On a noté les réponses avec un juge, et du coup le juge devait passer le même examen. On lui en a fait passer trois.

On a d’abord regardé sa stabilité. Sur 154 jugements répétés 3 fois, aucun n’a changé.

On a ensuite regardé sa capacité à repérer des inventions. Comme en test logiciel, on fabrique exprès des réponses fausses, et on compte celles que le juge attrape. Un agent d’IA neuf, c’est-à-dire qui n’avait pas vu nos données (Opus), a fabriqué 48 réponses qui affirment volontairement un fait faux, à quatre niveaux de finesse, de l’invention flagrante à une seule phrase fausse noyée dans une abstention honnête, plus 12 réponses saines.

Le juge a détecté 46 inventions sur 48, les deux ratées étant au niveau le plus fin, et il n’a accusé aucune des 12 réponses saines. La borne basse de son taux de détection est à 85,7 %, en traitant les 48 inventions comme indépendantes alors qu’elles vont par quatre sur un même piège. Les deux ratées sont des fausses règles de produit glissées dans une réponse qui s’abstient.

Enfin, on a regardé sa justesse tout court, et là le juge aussi se trompe. Sur une question qui vérifiait si la réponse empruntait un mot propre à un autre utilisateur, le juge répondait « oui » alors qu’aucune réponse n’employait ce mot : elles en employaient toutes un voisin. Relancé trois fois sur les cinq mêmes réponses, il a dit « oui » 8 fois sur 15, avec un verdict qui change d’un lancement à l’autre. On pense qu’il a confondu les deux mots, mais il ne s’explique pas. Une version corrigée de sa consigne ramène ce nombre à 0 sur 15.

À quoi ça peut servir ?

La première conclusion, c’est que les éditeurs ont cessé de publier le test simple de l’aiguille dans une botte de foin, signe que ce test simple ne pose plus de difficulté aux modèles, même si le risque demeure sur un très gros corpus. Sur un petit corpus comme le nôtre, le modèle s’en sort très bien. Si le corpus est petit, clairement, il faut le donner en entier. Sur un gros corpus, le RAG est sans doute nécessaire, mais ce n’est pas la panacée non plus. C’est un terme qui a été très à la mode ces derniers temps, il y a des effets de mode, mais quand on mesure, le RAG ne donne pas forcément des résultats de bonne qualité : avec 6 extraits, l’IA rate près d’un point sur deux.

Le deuxième point, c’est qu’il faut s’intéresser à des règles liées, vraisemblablement proportionnelles, à la taille du corpus (combien d’extraits donner pour quelle taille de corpus), parce que si on ne donne pas une info à une IA, elle ne peut pas deviner que l’info existe ailleurs. On ne peut pas partir du principe qu’une solution technique est la bonne parce qu’elle est très plébiscitée. Sur des sujets de research, où les quantités de données peuvent être importantes, voire très importantes, il est sans doute raisonnable de garder un regard critique sur cette approche, pour s’assurer que le LLM traite bien l’exhaustivité du contenu. Sinon, on interagit avec une version partielle de notre matière research, et on ne peut s’en rendre compte qu’un peu par hasard, quand le LLM ne répond pas quelque chose dont on était sûr qu’il devrait le faire.

Du coup, ça plaide pour une citation systématique des sources utilisées, et c’est autant valable ici que pour tout autre sujet où on laisse un LLM aller chercher de l’information, la ramener, voire la synthétiser.

Les limites de cette étude

On ne sait rien d’une IA nourrie de vrais entretiens, ni de questions ouvertes, car nos 77 points sont fermés, ni d’un corpus de plusieurs centaines d’entretiens. Nos chiffres sur le RAG dépendent en plus d’un choix de découpage, un extrait étant ici une question de l’intervieweur avec la réponse qui suit. Chacun de nos trois utilisateurs est une seule personne fictive, interrogée dix fois, alors que dans un projet réel on interroge des personnes différentes qui ne disent pas toutes la même chose : c’est l’objet du second article. Et tout repose sur peu de regards, parce qu’un seul auteur a écrit les bonnes réponses, qu’un seul juge a noté toutes les réponses, que ce juge est l’un des trois modèles testés, qui viennent tous du même éditeur, et que le programme qui vérifie nos bonnes réponses a lui-même laissé passer, avant correction, 9 des 39 défauts qu’on y avait glissés exprès.

L’illustration de cet article a été générée par IA (voir notre déclaration d’usage de l’IA).