Correction des LLM : génération augmentée de récupération

Nous nous moquons tous de la façon dont les grands modèles de langage se trompent, mais uniquement parce que nous souhaitons vraiment que les LLM fassent les choses correctement. La génération augmentée par récupération (RAG) est un moyen de fournir potentiellement des résultats plus fiables.

Comme Internet, l’intelligence artificielle finira par tout affecter. Je pense qu’il est assez clair, par exemple, qu’il y aura deux types d’organisations dans notre avenir : celles qui utilisent l’IA et celles qui vont mourir. Mais même cela n’est bien sûr vrai que pour les organisations qui disposent des outils nécessaires pour fonctionner de manière fiable. IA générative utilisant de grands modèles de langage est un bon exemple des problèmes et des solutions disponibles avec les outils d’IA.

Le problème

Le problème le plus connu dans l’utilisation de solutions textuelles génératives est celui des « hallucinations », où une réponse générée comprend à la fois du matériel sur lequel vous pouvez compter et du matériel qui est… disons simplement, moins fiable.

Mon exemple préféré vient de Wikipédia où un chatbot, recevant une URL contenant plusieurs mots anglais (« technologie », « chatgpt-prompts-to-avoid-content-filters »), a généré un résumé de cette page, sauf qu’il n’y avait aucune page à l’URL. Ce n’était pas important que la page n’existe pas, car de toute façon, le chatbot ne disposait pas d’une connexion Internet pour rechercher la page.

Critiquez autant que vous voulez la réponse de ce chatbot, mais ce chatbot a un avenir en tant que consultant (ou en tant que rédacteur technique). En fait, pour moi, ce qui est intéressant dans la réponse, c’est la façon dont humain c’est le cas : plutôt que d’admettre son ignorance, le chatbot a deviné la bonne réponse.

Mais il s’avère que nous nous soucions beaucoup de la fiabilité des réponses que nous obtenons des solutions d’IA. Si nous voulions des réponses parfois peu fiables, nous sauterions le artificiel intelligence et optez pour une véritable intelligence en embauchant un consultant qui pourrait nous dire quand leurs réponses n’étaient que des conjectures. Les outils de langage génératif ne font pas cela (du moins, pas encore – voir ci-dessous).

Les problèmes de l’IA ne se limitent cependant pas à simplement « inventer des choses ». Les réponses peuvent également être hors sujet ou absurdes. Encore une fois, ce n’est pas inhabituel : j’ai écrit un article il y a quelques mois sur la production des résumés de documents en intégrant le PDF Telerik et des outils de traitement de documents avec Azure Language Services. Parmi les trois exemples que j’ai utilisés dans cet article, il y avait un résumé de document que je pensais être correct et un résumé qui, selon moi, pourrait être amélioré. Cependant, dans le résumé du troisième document, les services linguistiques ont révélé qu’ils ne pouvaient pas faire la distinction entre le sujet de mon message (« le code pour travailler avec Azure Language Services ») et les sujets des exemples de documents que j’ai utilisés. Le résultat était plutôt moche.

Pourtant, c’est un succès, un échec et un intermédiaire. En termes de baseball, cela représente un pourcentage de base de 0,500 alors qu’actuellement, un bon pourcentage de base est considéré (vérification rapide à l’aide d’un chatbot) d’environ 0,360. À mon avis, cela signifie que même si vous pouvez utiliser l’IA pour créer des solutions qui auraient pu être trop coûteuses auparavant, ces solutions nécessiteront une certaine supervision.

J’appellerais toujours cela un progrès, mais si nous voulons des solutions plus fiables, nous devons comprendre pourquoi nos solutions d’IA produisent actuellement des résultats peu fiables.

Comment ça marche (et pourquoi ça échoue)

La technologie actuelle pour générer du texte à l’aide de l’IA est celle des grands modèles de langage (LLM). Les LLM absorbent un énorme corpus de divers types de documents (texte, audio, vidéo, images) en entrée et sont ensuite formés pour répondre à de nouvelles requêtes en utilisant des modèles découverts dans ce corpus. Mais comme les LLM sont basés sur des modèles (plutôt que sur des connaissances), ils génèrent uniquement des réponses qui regarder comme la bonne réponse. Comme le démontrent mes exemples précédents, cela s’avère ne pas être totalement fiable.

Un autre problème important est que les LLM sont intrinsèquement obsolètes – un problème appelé « latence ». Parce que les LLM ont besoin de temps pour construire leur corpus de documents, ingérer ces documents puis être formés sur ce corpus, ils sont inévitablement guidés par le passé (un peu comme les dictionnaires, qui vous indiquent comment les mots étaient utilisés dans le passé mais pas comment ces mots étaient utilisés dans le passé). les mots sont utilisés en ce moment). Un LLM orienté services dans un domaine en évolution rapide n’est peut-être pas hallucinant mais pourrait facilement donner des réponses dépassées.

Les solutions

Il existe au moins deux manières possibles d’améliorer la fiabilité, et j’aime beaucoup l’une d’elles.

Affiner les LLM avec des modèles petits (ou ciblés)

Une solution consiste à « affiner » les LLM pour utiliser des documents provenant d’un « domaine problématique » particulier. Étant donné que votre solution ne trouvera désormais que le contenu pertinent pour le domaine problématique, les modèles découverts seront basés sur des informations réelles pour ce domaine problématique. L’incidence des hallucinations devrait être réduite et la fiabilité améliorée.

Cependant, même si ces modèles plus ciblés sont parfois appelés «petits modèles de langage», ils ont généralement encore besoin d’une collection de documents assez importante pour générer des réponses cohérentes. Il serait peut-être préférable de les considérer comme des modèles linguistiques « thématiques » plutôt que « petits ». Sans surprise, les ressources nécessaires au traitement de tous ces documents restent élevées, tout comme la formation de ces LLM. Et bien entendu, la latence reste un problème.

Et le temps/coût/effort de construction d’un corpus est un problème car les LLM « à usage général » existants sont a) disponibles dès maintenant et b) vraiment bon marché. Il n’est pas clair que les améliorations de fiabilité résultant de la création de modèles « affinés » justifieront les coûts par rapport aux LLM « à usage général » existants.

Génération augmentée de récupération (RAG)

L’autre solution, plus prometteuse, est la génération augmentée par récupération (RAG). Avec RAG, les applications construites sur un LLM accèdent automatiquement aux sources de données thématiques pour récupérer des informations liées à l’interaction. Cette récupération peut concerner des données spécifiques à un domaine (la liste de produits ou les manuels de service de votre entreprise) ou simplement des données plus récentes (des sondages en cours dans les campagnes électorales). Les informations supplémentaires sont intégrées dans la réponse du LLM pour enrichir la réponse avec des données actuelles spécifiques au domaine.

À titre d’exemple de ce à quoi cela pourrait ressembler, il y a environ deux jours, j’ai cliqué sur un lien généré par l’IA pour accéder à des informations sur un groupe de rock que j’aime (L’avertissementsi vous êtes intéressé). Le lien m’a amené à une page contenant une discussion sur le style du groupe qui, même si elle n’était pas particulièrement perspicace, n’était pas fausse.

Mais ensuite, la page énumérait (prétendument) les albums du groupe, et aucun des albums répertoriés n’était un album du groupe. Ajoutant l’insulte à l’injure, la réponse générée a également erroné les noms des membres du groupe (ce qui, étant donné que les membres sont tous sœurs et partagent un même soir hier soir, était une erreur assez impressionnante).

Heureusement, je me méfiais de la fiabilité de l’information : je connaissais le nom du dernier album du groupe, qui ne figurait pas sur la liste. J’ai donc fait ce que toute personne rationnelle ferait et j’ai consulté une source fiable : le entrée pour le groupe sur AllMusic.comce qui m’a donné la bonne information.

Où ce chatbot d’origine a-t-il obtenu ses informations ? Je n’ai aucun moyen de le savoir. Mais si ma requête initiale avait été traitée à l’aide d’AllMusic, comme je l’ai fait et comme un RAG pourrait le faire, la liste des albums du groupe (et des noms des membres du groupe) aurait été plus précise. Utiliser une source basée sur les connaissances, plutôt que de compter uniquement sur la correspondance de modèles, peut empêcher un LLM de fournir une réponse à moins qu’il n’y ait des informations à l’appui provenant de la source de données thématique (c’est-à-dire pas d’« hallucinations »).

Mais il y a un autre avantage : les systèmes RAG sophistiqués peuvent également inclure des références aux sources de données thématiques, fournissant ainsi des citations que les utilisateurs peuvent examiner et vérifier. Cela permet aux utilisateurs de filtrer les réponses absurdes ou hors sujet (si elles se produisent) en vérifiant si cette partie de la réponse contient une citation. À tout le moins, dans mon exemple, l’absence de lien vers une source fiable (l’entrée AllMusic du groupe) aurait signalé l’information comme potentiellement peu fiable.

Problèmes de RAG

Mais bien sûr, aucune solution n’est parfaite et RAG a également des problèmes. Comprendre ces problèmes nécessite d’examiner comment RAG est intégré au traitement d’une requête.

Toutes les solutions LLM commencent par le traitement du langage naturel (c’est-à-dire tokeniser la requête, générer des synonymes, reconnaître et nommer des entités, etc.). La sortie de ce processus est ensuite convertie en vecteur. Un vecteur est un ensemble de nombres qui reflètent la manière dont les mots sont utilisés dans une phrase et quelles sont les relations entre ces mots. RAG utilise ce vecteur pour récupérer des données à partir d’une base de données de vecteurs thématiques, sur la base des similitudes entre le vecteur de requête et les vecteurs de vos données thématiques (par exemple, en reconnaissant la relation entre « Les grands danois sont de très gros chiens » et « Quels sont certains gros chiens ? »).

Ce qui nous amène au premier problème : vos données thématiques doivent également être converties en vecteurs (« vector embedding ») avant de pouvoir être intégrées dans une solution LLM.

Et cela conduit également au deuxième problème : la requête dans votre base de données thématique renverra de nombreux vecteurs correspondants. Les vecteurs de données thématiques correspondants doivent être classés et les résultats les mieux classés doivent être prioritaires pour générer la réponse.

Ce classement varie d’une source de données thématiques à l’autre. En répondant à une question « Comment puis-je réparer cet appareil cassé ? » interrogez, par exemple, les données pertinentes pour un appareil particulier et les symptômes de la panne sont prioritaires. En revanche, dans un système de détection d’intrusion, la priorité serait donnée aux données sur les anomalies et les activités qui correspondent à celles de la base de connaissances MITRE ATT&CK. Cette diversité signifie qu’obtenir un classement fiable pour une source de données thématique particulière impliquera une certaine formation.

Cette formation n’est peut-être pas difficile, cependant : elle pourrait simplement consister à demander à des êtres humains de classer les réponses initiales du LLM + RAG et de demander au LLM de faire davantage de tout ce qu’il a fait qui a généré des réponses de niveau supérieur et moins de tout ce qui a abouti à des résultats de niveau inférieur. . De plus, la formation est probablement un coût ponctuel/initial plutôt qu’une dépense continue (même si, encore une fois, une supervision est requise et les résultats de toute solution doivent être examinés à intervalles réguliers pour déterminer si une formation/recyclage supplémentaire est nécessaire).

Troisièmement : la latence reste un problème. Cependant, comme la quantité d’informations spécifiques au domaine est d’un ordre de grandeur inférieure à celle requise pour les modèles volumineux ou affinés, la régénération de la base de données vectorielles peut se produire plus fréquemment, réduisant ainsi l’écart de latence. Il s’agit toutefois d’un coût permanent.

Encore un problème : l’évolutivité, cette fois en termes de nombreuses sources de données thématiques que vous pouvez inclure dans une solution RAG. Même si, en théorie, vous pouvez structurer un RAG pour inclure davantage de sources de données thématiques, à mesure que vos sources de données se diversifient, vous vous retrouvez avec le problème initial : vous disposez d’un système de correspondance de modèles à usage général plutôt que d’un système qui exploite des connaissances spécialisées. . En conséquence, à moins que la solution ne dispose d’un moyen de choisir la « bonne » source de données thématiques pour toute requête, la fiabilité des réponses de la solution diminuera (bien que la présence/l’absence de citations aidera à signaler les réponses peu fiables).

Nous savons tous que la fiabilité compte. Si vous avez lu jusqu’ici, c’est uniquement parce que vous pensiez qu’il s’agissait d’un article fiable, par exemple. RAG, bien que payant, offre un moyen de créer des solutions plus fiables que les implémentations purement LLM en évoluant vers une approche basée sur la connaissance au lieu d’une simple correspondance de modèles – ou, à tout le moins, en donnant aux utilisateurs un moyen rapide d’évaluer la fiabilité de toute réponse.

Pourtant, si j’étais vous, même dans une solution RAG, je garderais un œil sur les résultats que vous obtenez : les outils sont encore jeunes et, comme toute nouvelle recrue, auront besoin d’être encadrés.

Et, pour mémoire, en voici quelques-uns images d’audience de The Warning (les sœurs Villarreal – Ale, Pau et Dany), en tournée dans ma ville.