Vous voulez apprendre Warhammer 40K ? Construisez ce chatbot avec des vecteurs et RAG sur du matériel de base

Lors de la création d'une application d'IA générative qui doit appeler plusieurs fois un grand modèle de langage (LLM) pour accomplir une tâche, un problème courant est que les requêtes répétées au LLM peuvent être à la fois coûteuses et imprévisibles. Les grands modèles tels que GPT-3.5/4 sont incroyablement gourmands en ressources pour entraîner et exécuter l'inférence ; cela se reflète dans les frais de l'API ainsi que dans les interruptions occasionnelles du service. ChatGPT a été initialement publié en tant qu'aperçu de recherche et n'était pas destiné à être utilisé pour des applications de production. Cependant, son utilité dans un large éventail d’applications est incontestable, c’est pourquoi l’intérêt pour les LLM a explosé.

Depuis la création de ChatGPT, les utilisateurs recherchent des moyens de contourner le manque de confidentialité et l'incapacité de contrôler la disponibilité ou les paramètres d'inférence lors de l'utilisation de GPT. Cela a conduit à la popularité de modèles publics gratuits tels que Meta's Llama 2 et plus tard à la création de versions quantifiées et à paramètres inférieurs de Llama pouvant fonctionner sur du matériel grand public. Ces modèles publics sont capables de fournir une grande partie des mêmes fonctionnalités que GPT pour une puissance de calcul bien moindre, mais au prix de moins de paramètres et de sorties détaillées.

Si votre application ne dépend pas nécessairement du traitement de contextes excessivement volumineux ou de la production de sorties détaillées, héberger votre propre inférence sur les instances que vous contrôlez peut être une option plus rentable. Et lorsqu’il s’agit d’applications réelles de génération augmentée par récupération (RAG), les différences de coûts peuvent devenir encore plus importantes.

Je vais démontrer une méthode simple permettant de combiner des magasins de vecteurs, une recherche lexicale et une ingénierie d'invite pour effectuer un RAG précis sur du matériel de base. Grâce à cette méthode, vous pouvez à la fois réduire la complexité de grands volumes d’informations et rendre l’exécution d’applications d’IA générative plus précise, efficace et rentable à grande échelle. En utilisant RAG sur des banques d'informations spécifiques, vous pouvez éliminer les hallucinations et créer des agents efficaces et compétents à partir de n'importe quelle source sans avoir à payer pour des API tierces.

Pour commencer, vous aurez besoin d'une instance DataStax Enterprise 7 ou de DataStax Astra DB pour stocker les vecteurs et les données textuelles, ainsi que d'un LLM et d'un modèle de transformateur de phrases pour générer des réponses et encoder vos données avec des vecteurs. En fonction de la complexité de vos données ou des invites de l'utilisateur, vous pouvez également envisager de combiner cela avec une base de données DataStax Enterprise 6.8 capable d'effectuer des recherches Solr pour faire correspondre des plages de données plus larges, ce que j'ai utilisé dans cet exemple. DataStax travaille continuellement sur des améliorations pour permettre toutes ces opérations avec une seule base de données, mais pour l'instant, j'utilise deux bases de données.

Résoudre les hallucinations

Quel que soit le LLM que vous choisissez, ils souffrent tous encore d' hallucinations . Pour l’instant, cette limitation doit être résolue en fournissant des informations véridiques dans le contexte d’invites au LLM, également connu sous le nom de RAG. La méthode par laquelle vous localisez vos informations et les transformez en invites dépend entièrement de votre modèle de données, mais vous pouvez trouver des informations plus pertinentes de manière plus efficace en utilisant des bases de données vectorielles.

Supposons, par exemple, que vous disposiez d'une collection de livres électroniques sur un sujet que vous aimeriez explorer, comme comment jouer à Warhammer 40,000 . Dans des circonstances normales, il faudrait des années pour lire la littérature à l’appui et acquérir suffisamment d’expérience de jeu pour atteindre un niveau expert.

Une question ciblée telle que : « Que pouvez-vous me dire sur Morvenn Vahl de l'Adepta Sororitas ? il serait préférable de répondre à cette question par un joueur vétéran ou par tout employé d'un magasin Warhammer. Bien que ChatGPT puisse répondre à de nombreuses questions sur le jeu, il ne dispose malheureusement d'aucune donnée d'entraînement couvrant ce personnage particulier :

Comparez cela à un LLM de paramètre Llama 2 13B hébergé sur un poste de travail grand public avec une carte graphique Nvidia RTX A4000. De même, le modèle peut démontrer une connaissance de base de l'univers de Warhammer, mais en raison du réglage, le modèle ne se soucie pas que le personnage ne soit pas trouvé et fournit à la place une hallucination au mieux :

Si vous souhaitez créer un chatbot capable d'aider à la fois les nouveaux arrivants et les vétérans à jouer à Warhammer 40,000, alors ces résultats sont inacceptables. Pour être un guide de jeu efficace, le chatbot doit connaître les règles du jeu, les règles de chaque unité, quelques éléments de l'histoire, ainsi qu'un peu de stratégie et de commentaires. Heureusement, toutes ces informations sur les règles de la 10e édition sont disponibles gratuitement sur Games Workshop et sur les sites Web de fans, et tout ce que vous avez à faire est de les rendre consultables sur votre application chatbot.

Comparez cela au même modèle 13B Llama, où avec RAG, il est demandé de comparer quelques sources sur Morvenn Vahl et de concevoir une réponse pertinente basée sur l'invite de l'utilisateur. Cette fois, le chatbot a accès à une base de données de recherche et à une base de données vectorielles regroupant toutes les informations publiques sur la façon de jouer à Warhammer 40,000, 10e édition :

Quelle différence! Non seulement il trouve des informations pertinentes sur ce personnage de niche, mais il maintient également ses résultats en phase avec le contexte de la façon de jouer au jeu avec les règles de la 10e édition.

Le plus difficile dans tout cela est d'effectuer une recherche efficace pour trouver les pages pertinentes à alimenter dans le LLM. C’est là que les bases de données vectorielles peuvent s’avérer particulièrement utiles.

Application de vecteurs

Dans cet exemple, nous utiliserons DSE 7 et DSE 6.8 exécutés dans des instances Docker pour satisfaire aux exigences de base de données de l'application chatbot, qui doit être capable de comparer des vecteurs et d'effectuer des recherches lexicales. DSE 7 et Astra DB ont introduit la possibilité de stocker des vecteurs et d'effectuer des recherches de vecteurs, ainsi que le filtrage par correspondance de texte. Nous n'avons besoin de rechercher que quelques dizaines de livres pour cet exemple, donc exécuter des instances DSE dans Docker sera suffisant pour la plupart du matériel grand public.

L'utilisation de vecteurs dans vos bases de données vous aidera à trouver des documents similaires à une requête donnée, ou ils pourront être utilisés pour comparer les résultats extraits d'une autre recherche. Cela peut vous aider à surmonter les limites de la recherche lexicale et à améliorer l’efficacité des modèles de données.

Par exemple, quelque chose comme les PDF de livres électroniques peut bénéficier d'être encodés avec des transformateurs de phrases comme miniLM , et les vecteurs peuvent être utilisés pour effectuer une comparaison de similarité entre une requête et une source donnée. Dans ce cas, un modèle de transformateur de phrase est utilisé pour créer des intégrations du texte d'une page dans un livre électronique, ce qui peut vous permettre de comparer avec l'invite de l'utilisateur pour déterminer si un résultat est pertinent pour la requête. Les pages pertinentes doivent contenir une ou plusieurs instances de termes similaires à la requête de l'utilisateur et donner lieu à de meilleurs scores de similarité du point de vue du modèle.

Cela dit, il est préférable d’appliquer les vecteurs en complément d’un modèle de recherche lexical existant. Si vous effectuez une recherche uniquement par vecteurs, vous risquez de récupérer de manière inattendue des documents sans rapport et de les fournir comme contexte là où ils ne s'appliquent pas.

Dans cet exemple, la requête « Que pouvez-vous me dire sur Morvenn Vahl de l'Adepta Sororitas ? » peut être transformé par un LLM en un ensemble de termes de recherche simples :

Morvenn, Vahl, Adepta, Sororitas

La première étape pour trouver des documents pertinents serait de rechercher des documents contenant ces termes de base. Cela peut être fait en filtrant d'abord les correspondances de texte dans la base de données pour trouver des mots-clés dans le texte de la page correspondant à une telle requête. La raison de l'utilisation d'un LLM pour générer des mots-clés est de fournir un plus large éventail de mots-clés possibles à rechercher, car il tente souvent d'ajouter davantage de mots-clés liés mais ne figurant pas dans le texte de l'invite d'origine. Soyez toutefois prudent, car les LLM peuvent également générer des caractères spéciaux et des séquences impaires que vous devrez nettoyer.

Une fois que vous avez au moins un résultat, vous pouvez vectoriser la requête de l'utilisateur et la comparer aux vecteurs de la recherche lexicale, créant ainsi des scores indiquant la pertinence de chaque résultat. Cela vous permet de vérifier l'exactitude des résultats de la recherche par rapport à la requête et de définir un seuil de rejet des résultats sans rapport lorsqu'il s'agit de présenter enfin vos résultats au LLM.

Dans ce cas, la première étape doit correspondre aux pages qui montrent spécifiquement la fiche de Morvenn Vahl ou les mécanismes de jeu, car celles-ci décrivent l'unité du personnage en termes de façon dont il joue dans le jeu. Si la page atteint un certain seuil de pertinence pour la requête de l'utilisateur, déterminé par l'application, elle est alors résumée et placée dans une liste de résultats.

Enfin, les résultats de la recherche peuvent être compilés dans une liste et renvoyés au LLM, où il est demandé d'utiliser les contextes les plus pertinents pour répondre à la requête initiale. Voici une visualisation du flux :

Comme vous pouvez le constater, le LLM est appelé assez fréquemment pour ce flux. Le LLM est chargé de transformer l'invite utilisateur en mots-clés, de résumer les résultats applicables et de choisir le contexte qui répond le mieux à une requête. Chaque source à vérifier ajoute un autre appel LLM, ce qui peut être assez coûteux lors des requêtes vers GPT. Mais si vous disposez déjà des informations dont vous avez besoin et que vous souhaitez simplement les résumer ou les transformer, vous n'aurez peut-être pas besoin d'utiliser un modèle aussi volumineux. En fait, passer à des modèles plus petits peut offrir de nombreux avantages.

En utilisant un LLM plus petit, vous pouvez réduire le coût de calcul de chaque requête, ce qui peut entraîner des économies significatives au fil du temps. Cela peut également entraîner des temps de réponse plus rapides pour vos utilisateurs, ce qui peut améliorer leur expérience globale. Dans cet exemple, où RAG est effectué à l'aide d'un petit LLM et de petites bases de données, toutes hébergées sur la même instance GPU, il faut environ 30 secondes pour récupérer 15 sources, en analyser la pertinence et fournir une réponse finale. Et plus les invites (sources) sont courtes, plus les résultats peuvent être renvoyés rapidement.

De plus, cette méthode permet une sécurité et une évolutivité accrues. Grâce à une ingénierie rapide et à un pipeline d'appels au LLM, vous contrôlez totalement la manière dont les données sont accédées et ce que les utilisateurs obtiendront dans leurs réponses. En termes d'utilisation des ressources, l'exemple de modèle de paramètres 13B ne consomme qu'un peu plus de 8 Go de VRAM et fournit toujours des réponses pertinentes. En fonction des besoins, cela montre le potentiel même d'exécuter RAG sur une myriade d'autres plates-formes, telles que les postes de travail des utilisateurs et les appareils mobiles.

Contrôler la sortie

Une ingénierie rapide est essentielle pour que RAG fasse exactement ce que vous voulez. Vous contrôlez la manière dont le chatbot interprète les données et le contexte dans lequel il doit réfléchir. Dans cet exemple, nous voulons nous assurer que le chatbot sait que nous recherchons spécifiquement des informations sur Warhammer, afin que nous puissions d'abord lui demander de fournir un contexte de soutien à la requête de l'utilisateur :

Requête : « <requête utilisateur> »

Donnez-moi une liste minimale de mots-clés Warhammer 40K, séparés par des virgules, pour un moteur de recherche. Répondez avec uniquement la requête. N'utilisez pas d'émojis ou de caractères spéciaux.

Répondre:

Warhammer 40,000 regorge de termes et de noms qui pourraient apparaître dans d'autres cultures populaires sans rapport, il est donc important de définir le contexte du RAG dès la toute première requête. Ce contexte doit être quelque chose que vous pouvez sélectionner ou modifier si votre application couvre plusieurs contextes, par exemple si vous devez couvrir plusieurs éditions des règles du jeu Warhammer ou les combiner avec les livres d'histoire officiels.

Notez que la requête de l'utilisateur est toujours encapsulée avec des guillemets pour cette expérience. Cela aide le LLM à faire la distinction entre la requête à laquelle il tente de répondre directement et les instructions d'ingénierie d'invite distinctes, auxquelles il ne doit pas répondre directement. La partie question/réponse de l'invite peut être ajustée pour s'adapter à un contexte particulier, mais surtout, tout ce que vous devez pouvoir faire est d'informer le LLM à quoi il doit et ne doit pas répondre directement et comment répondre.

Dans ce cas, on peut supposer que le LLM possède une connaissance générale de l'univers du jeu puisque la série est raisonnablement populaire et que les informations générales sont disponibles gratuitement. Le résultat de cette première requête permet de générer des mots-clés à utiliser dans la recherche lexicale sans que nous ayons à créer une aide-mémoire dans notre application.

Les comparaisons lexicales et vectorielles peuvent ensuite être effectuées en arrière-plan, et une liste de résultats est compilée pour examen par le LLM. Étant donné que l'invite d'origine de l'utilisateur ne reçoit jamais de réponse directe par inférence dès la première étape, le LLM transforme uniquement ce qui est trouvé dans une recherche et peut facilement être empêché de répondre aux requêtes en dehors de ses garde-fous ou de sa base de connaissances.

Si la recherche donne des résultats pertinents :

Requête : « <requête utilisateur> »

Examinez ces résultats de recherche et utilisez-les pour répondre à la requête.

Résultat 1

Résultat 2

etc.

Répondre:

S'il n'y a aucun résultat pertinent lors de la recherche :

Requête : « <requête utilisateur> »
Dites-moi poliment que vous avez cherché mais que vous n'avez pas trouvé de réponse à votre requête. Répondez plutôt au meilleur de vos connaissances.

Répondre:

Pour plus de sécurité, vous pouvez rejeter ou rediriger complètement la demande lorsqu'elle ne peut pas être servie.

Requête : « <requête utilisateur> »

Dites-moi poliment que vous avez cherché mais que vous n'avez pas trouvé de réponse à votre requête. Demandez-moi plutôt de contacter l’équipe de support client pour obtenir de l’aide.

Répondre:

Vous pouvez même allonger les sorties en demandant plus de détails. Tant que vous pouvez adapter votre matériel source dans la fenêtre contextuelle, le LLM peut le transformer pour vous.

Requête : « <requête utilisateur> »

Examinez ces résultats de recherche et utilisez-les pour répondre à la requête. Soyez le plus détaillé possible et citez les sources.

Résultat 1

Résultat 2

etc.

Répondre:

Limites

Le LLM a une fenêtre contextuelle limitée et ne parviendra pas à traiter des pages de texte exceptionnellement volumineuses. Pensez à imposer des limites à la taille des lignes afin que vos données soient plus gérables et plus faciles à traiter pour le LLM. Par exemple, couper les pages en morceaux d'environ 1 000 caractères semble bien fonctionner et essayez d'éviter de fournir plus de quatre ou cinq réponses détaillées dans l'invite.

Le LLM n'a aucun souvenir d'une conversation en dehors de ce que vous pouvez insérer dans la fenêtre contextuelle. Il est possible de créer un stockage permanent de données de conversation, mais il n'est pas possible pour un LLM d'insérer des conversations excessivement volumineuses ou un contexte détaillé dans une invite ; il y a une limite supérieure à ce qu’il peut transformer. Cela signifie que quoi qu'il en soit, à un moment donné, vous remarquerez que le LLM semble « oublier » certains détails même lorsqu'ils sont fournis à titre contextuel ; il s'agit simplement d'une limitation inhérente à l'outil. Il est préférable de s'en servir uniquement pour de courtes conversations et de se concentrer sur la transformation de petites quantités de texte à la fois afin de minimiser les hallucinations.

Le caractère aléatoire dans le LLM peut être un problème. Des tests et des réglages seront nécessaires pour déterminer quelles invites fonctionnent le mieux pour votre ensemble de données et pour trouver quel modèle fonctionne le mieux pour votre cas d'utilisation. Lors de mes tests avec un modèle de paramètres 13B, il y avait beaucoup d'imprévisibilité quant aux mots-clés de recherche générés à partir de la première invite, d'autant plus que la longueur de l'invite augmentait. Pour de meilleurs résultats, respectez des invites plus courtes.

Conclusion

En résumé, tirer parti de RAG en combinant des modèles de recherche vectorielle et lexicale permet de trouver et de trier plus efficacement les résultats pertinents et de générer des sorties d'agents beaucoup moins sujettes aux hallucinations. Plus le contexte de recherche est petit, plus les réponses sont précises et exactes. La construction de votre propre pipeline personnalisé d'appels LLM offre beaucoup plus de flexibilité dans l'ajustement des réponses en fonction du niveau de précision et des garde-fous souhaités.

Bien qu'il ne puisse pas traiter des quantités de données excessivement importantes dans une fenêtre de contexte limitée, il offre la possibilité de créer des assistants efficaces sur des bases de connaissances limitées, ainsi que d'exécuter davantage d'agents simultanés sur le même matériel ou sur un matériel moindre qu'auparavant. Cela pourrait ouvrir davantage de possibilités aux assistants virtuels pour des applications telles que les jeux sur table ou même couvrir des sujets plus complexes destinés aux gouvernements, aux cabinets juridiques et comptables, à la recherche scientifique, à l'énergie, etc.

Si vous êtes prêt à commencer à créer, vous pouvez essayer Astra DB gratuitement . Créez votre base de données et commencez à charger vos sources RAG dès aujourd'hui, sans aucune expérience requise en matière d'exploitation du cloud ou des bases de données.

Par Mario Charnell-Delgado, DataStax

Également publié ici .