Souvent incroyablement bien informés sur un large éventail de sujets, les grands modèles de langage (LLM) sont toutefois limités aux seules données sur lesquelles ils ont été entraînés. Par conséquent, les clients qui souhaitent alimenter leurs LLM d’informations privées ou propriétaires ne peuvent pas utiliser des modèles « prêts à l'emploi » pour répondre à des questions, générer leur correspondance, etc.
La génération augmentée par récupération (RAG) est une approche architecturale qui permet aux modèles de fondation de produire des sorties factuellement correctes pour des sujets spécialisés ou propriétaires non inclus dans les données d’entraînement du modèle. En enrichissant les questions et les prompts des utilisateurs avec des données pertinentes récupérées à partir de sources externes, la RAG fournit au modèle des faits et des détails « nouveaux » pour générer sa réponse.
Architecture conceptuelle
Schémas d’architecture d’IA générative
- Génération augmentée de récupération
- Discussion avec un agent conversationnel
- Recherche générative
- Raisonnement, connaissances et langage modulaires
- Synthèse de documents
- Modernisation et génération de code
- Génération de code pour Ansible
- Génération de code pour Z
- Développement de logiciels augmenté par l’IA avec des agents
Le schéma RAG, présenté ci-dessous, comporte deux parties : l’incorporation des données pendant la phase de développement, et les prompts utilisateur (ou l’affichage des résultats de recherche) pendant l’exécution.
Un ingénieur en IA prépare les données client (manuels de procédures, documentation des produits, tickets d’incident, etc.) pendant la phase de prétraitement des données. Les données client sont transformées et/ou enrichies pour s’adapter à l’augmentation du modèle. Il peut s’agir d’une simple conversion au format souhaité (par exemple, convertir les documents PDF en texte), ou de transformations plus poussées telles que la traduction des structures de tables complexes en instructions de type « si... alors... ». L’enrichissement peut consister à développer les abréviations courantes, à ajouter des métadonnées comme les informations sur les devises, ou d’autres éléments pour améliorer la pertinence des résultats de recherche.
On utilise un modèle de plongement pour convertir les données sources en vecteurs qui représentent les mots dans les données client. Les plongements facilitent l’application du machine learning sur des entrées volumineuses telles que des vecteurs épars représentant des mots. Les plongements sont stockés sous forme de passages (appelés chunks) de données client, un peu comme des sous-sections ou des paragraphes, afin de faciliter la recherche d’informations.
Les plongements générés sont stockés dans une base de données vectorielle. Toute source de données prenant en charge des requêtes « floues » renvoyant des résultats en fonction de leur pertinence probable, par exemple Watson Discovery, peut être utilisée dans l’architecture RAG. L’approche la plus courante consiste toutefois à employer une base de données vectorielle comme Milvus, FAISS ou Chroma.
Le système est maintenant prêt à être exploité par l’utilisateur final.
Les utilisateurs finaux interagissent avec une application dotée de l’IA générative et saisissent une requête.
L’application d’IA générative reçoit la requête et effectue une recherche dans la base de données vectorielle pour obtenir les éléments d’information qui correspondent le mieux à la requête de l’utilisateur (nous appelons cela « top K »). Par exemple, si la requête de l’utilisateur est « Quelle est le plafond journalier de retrait pour le compte MaxSavers », la recherche peut renvoyer des passages tels que « Le compte MaxSavers est… », « Les plafonds journaliers de retrait sont… » et « …plafonds du compte… ».
Les meilleurs passages sont envoyés au LLM, accompagnés d’un prompt adapté à l’application en question.
À l’instar d’un humain, le LLM formule une réponse en fonction de la requête utilisateur, du prompt et des informations contextuelles, qui est ensuite présentée à l’utilisateur final.
Le mappage du portefeuille de produits watsonx au modèle RAG est illustré dans le diagramme ci-dessus.
Watson Discovery met en œuvre les fonctions de prétraitement, de génération de plongements, de stockage et de recherche de pertinence du modèle. Pour certains types de solutions, Watson Discovery peut également servir d’application d’IA générative front-end pour les utilisateurs. Bien plus qu’une simple base de données vectorielle, Watson Discovery offre des fonctionnalités TAL enrichies et prêts à l’emploi telles que l’extraction d’entités, l’analyse des sentiments et des émotions, l’extraction de mots-clés, la classification, l’étiquetage des concepts et plus encore.
Pour les solutions de chat, watsonx Assistant fournit l’interface utilisateur et des capacités conversationnelles telles que la mémorisation du sujet des requêtes précédentes. Par exemple, si l’utilisateur lui demande : « Parle-moi du Toast-o-matic », puis « Combien ça coûte ? », watsonx Assistant sait que « ça » dans la dernière requête fait référence au grille-pain mentionné dans la première.
Enfin, watsonx.ai propose une sélection de grands modèles de langage dans un environnement d’hébergement cloud. Avec watsonx.ai, les clients peuvent facilement entraîner, valider, régler et déployer modèles de fondation, IA générative et fonctionnalités de machine learning, et créer des applications d’IA en peu de temps, avec moins de données.
Certains clients n’ont pas accès à watsonx.ai dans leur région, ou peuvent être dans l’impossibilité d’utiliser la solution watsonx.ai SaaS pour des raisons de sécurité ou d’exigencesréglementaires. Nous leur proposons watsonx.ai sous la forme d’un ensemble de services conteneurisés qui peuvent être déployés sur Red Hat Openshift dans leur propre centre de données, ou dans un cloud privé virtuel (VPC) sur l’infrastructure d’un fournisseur de service cloud.
La majorité des LLM sont entraînés sur des textes rédigés principalement en anglais, avec un faible pourcentage dans d’autres langues, souvent d’Europe occidentale. Pour les applications nécessitant une prise en charge multilingue ou localisée, vous pouvez mettre en œuvre une étape de traduction avant et après requête pour traduire les entrées dans la langue « de base » des documents pré-traités (par exemple, l’anglais), et traduire les sorties du modèle dans la langue cible (par exemple, l’espagnol). Cette approche est illustrée dans le diagramme ci-dessous.
Cette approche modifie le schéma RAG de base comme suit (en mettant de côté les étapes de génération des représentations vectorielles) :
Un utilisateur saisit une requête dans une langue différente de la langue dominante de la documentation prétraitée. Il peut s’agir, par exemple, d’une requête en espagnol sur une base documentaire principalement en anglais.
L’application d’IA générative demande à un grand modèle de langage de traduire la requête de l’utilisateur dans la langue de la base documentaire. Dans notre exemple, de l’espagnol vers l’anglais.
La requête traduite permet de récupérer les K premiers passages d’informations les plus pertinents pour la requête de l’utilisateur.
La requête traduite et le contexte récupéré sont envoyés au LLM pour générer une réponse.
L’application d’IA générative utilise à nouveau un grand modèle de langage pour traduire la réponse générée dans la langue cible de l’utilisateur. Dans notre exemple, de l’anglais vers l’espagnol.
La réponse traduite en espagnol est présentée à l’utilisateur final.
L’expérience montre que selon le contexte et le type de requêtes envoyées, cette approche permet d’obtenir une précision d’au moins 80 % pour les résultats dans une langue autre que celle de base. Les modèles multilingues émergents, entraînés en plusieurs langues aux pourcentages plus élevés, devraient atteindre un niveau de précision supérieur.
Cas d’utilisation
La RAG est une solution adaptée à tout scénario professionnel qui exige que l’utilisateur consulte un nombre important de ressources documentaires et de règles métier pour fournir des réponses fiables. Il s’agit également d’une solution fiable pour intégrer aux chatbots basés sur des LLM des connaissances propriétaires ou spécialisées et prévenir les hallucinations.
Voici quelques exemples d’utilisation :
Souscription des contrats d’assurance et gestion des sinistres. La RAG propose de nombreuses applications pour le secteur de l’assurance. Les souscripteurs et les courtiers doivent avoir une connaissance approfondie des conditions de centaines de produits d’assurance, soit des milliers de pages de documentation. De la même manière, les gestionnaires de sinistres peuvent être tenus d’avoir une connaissance approfondie de cette même documentation, ainsi que des contrats comportant des exclusions et des conditions supplémentaires pour chaque client. Le schéma d’architecture RAG peut servir d’épine dorsale à l’architecture des solutions pour permettre aux souscripteurs, aux courtiers et aux gestionnaires de sinistres de facilement interroger la documentation liée aux produits et aux contrats, de mieux répondre aux demandes des clients et d’améliorer l’efficacité des processus.
Aide aux agents des centre d’appels. Les agents des centres d’appels doivent bien connaître des centaines de produits et de services, les problèmes courants liés à ces derniers, ainsi que les solutions correspondantes. Le schéma RAG est une base solide pour créer des solutions permettant aux agents de trouver rapidement la réponse aux demandes des clients.
Chatbots client. La RAG est une approche très efficace pour créer des chatbots chargés de répondre aux questions des clients. Associer les capacités de langage naturel des grands modèles de langage à celles de réponse adaptée à chaque entreprise de la RAG permet d’offrir aux clients une expérience conversationnelle convaincante. Notez que la RAG propose uniquement la fonction de question-réponse, sans capacités « transactionnelles », qui consistent à interagir avec les systèmes de l’entreprise pour extraire des informations ou mettre à jour les données. Des composants supplémentaires doivent y être ajoutés pour détecter l’intention de l’utilisateur et interagir avec les systèmes de l’entreprise.
Support/service d’assistance. Tout comme les agents des centres d’appels, les équipes chargées de l’exploitation informatique et du support doivent bien connaître la configuration des systèmes complexes déployés, les problèmes courants, ou rencontrés antérieurement, ainsi que les solutions correspondantes. Le schéma RAG est une base solide pour créer des solutions permettant aux équipes de support de trouver rapidement réponse aux problèmes signalés ou observés.
Décisions et considérations relatives à l’architecture
Le choix du modèle dépend de nombreux facteurs.
La licence du modèle peut restreindre son utilisation. Par exemple, elle peut interdire son utilisation dans le cadre d’une application commerciale.
Le jeu de données utilisé pour entraîner le modèle affecte directement la performance de ce dernier sur une tâche donnée. Le risque que le modèle génère des réponses absurdes, offensantes ou tout simplement indésirables en dépend également. De la même manière, les modèles entraînés sur des données privées ou protégées par le droit d’auteur peuvent engager la responsabilité des utilisateurs. IBM assure une transparence totale des données d’entraînement et une indemnisation en cas de réclamation portant sur ses modèles.
La taille du modèle, le nombre de paramètres utilisés pour son entraînement et la taille de sa fenêtre contextuelle (la longueur des passages de texte qu’il peut accepter) affectent sa performance, ses besoins en ressources et son débit. Bien qu’il soit tentant de suivre le principe « plus c’est grand, mieux c’est » et de choisir un modèle à 20 milliards de paramètres, les besoins en ressources et l’amélioration (éventuelle) en termes de précision ne le justifient pas nécessairement. Selon plusieurs études récentes, les modèles plus petits peuvent s’avérer nettement plus performants que les grands dans le cas de certaines solutions.
Tout réglage fin appliqué aux modèles peut affecter leur adéquation à une tâche donnée. Par exemple, IBM propose deux versions du modèle Granite : l’une adaptée aux applications de chat générales, et une autre conçue pour suivre des instructions.
Autres aspects à prendre en compte pour bien choisir votre modèle :
Sélection des paramètres du modèle, comme sa température, pour concilier génération de textes semblables à ceux rédigé par un humain et réponses factuelles. Définir la température du modèle sur une valeur élevée entraîne la production de réponses cohérentes, mais potentiellement sans intérêt ou trop lacunaires, tandis que le réglage sur une valeur faible permet des réponses plus variées, dont la longueur et le contenu seront toutefois plus imprévisibles.
Sélection et mise en œuvre des garde-fous dans le modèle pour éviter les résultats inefficaces ou offensants.
Le choix du modèle dépend de l’application, du type de données et des exigences linguistiques. Il peut s’avérer nécessaire d’étendre les modèles de plongement pour encoder et rechercher avec précision des termes ou des acronymes spécifiques au secteur ou au client.
Les bases de données vectorielles ne sont pas la seule option disponible pour mettre en œuvre le magasin de données d’intégration. Watson Discovery propose des outils et des fonctionnalités supplémentaires pour améliorer la performance et la précision des solutions RAG. En outre, certaines bases de données « traditionnelles » permettent un stockage et une recherche vectoriels, et/ou une recherche de similarités pour prendre en charge les solutions RAG.
Il existe également de nombreuses options pour les bases de données vectorielles. Si les bases de données en mémoire simples, qui sont intégrées directement dans les applications d’IA générative, offrent une excellente performance d’exécution, elles peuvent s’avérer difficiles à adapter aux grands jeux de données et présenter des défis opérationnels importants pour rester à jour ou pour s’adapter aux configurations multiserveurs. Les bases de données qui reposent une architecture centralisée de type serveur sont plus faciles à exploiter et à faire évoluer, mais elles peuvent ne pas répondre aux besoins de performance de la solution en question.
Plusieurs méthodes permettent d’intégrer le modèle de récupération et de génération. Récupérer les K premiers passages pour compléter la requête de l’utilisateur est une option simple et pratique, qui peut toutefois manquer de subtilité pour répondre aux questions complexes. Une simple recherche par mot-clé peut également donner des résultats satisfaisants.
Les solutions plus complexes s’appuient sur un LLM pour générer plusieurs requêtes à partir de la requête initiale de l’utilisateur, afin de récupérer un plus grand ensemble de passages. Une logique supplémentaire peut être ajoutée pour trier et sélectionner les passages récupérés les plus pertinents.
Pré-traiter les données avant de les introduire dans le système RAG est essentiel pour s’assurer que le format des données d’entrée est adapté au modèle. Les méthodes simples consistent à diviser les données d’entrée en segments (« chunks ») de taille fixe avec des chevauchements (par exemple, les 10 derniers caractères d’un segment constituent les 10 premiers caractères du segment suivant). On risque toutefois de passer à côté des nuances présentes dans les données d’entrée.
Un prétraitement plus avancé consiste à manipuler le texte d’entrée pour supprimer les fins de mot courantes (par exemple, « stopper », « stoppant » et « stoppé » deviennent « stop »), ou encore à supprimer les mots « vides », non informatifs, comme « le », « comme », « est », etc.). Ces solutions peuvent considérablement améliorer la pertinence des informations récupérées, mais compliquent l’incorporation des données et l’utilisation des prompts par l’utilisateur.
Des techniques encore plus avancées peuvent être appliquées aux phrases entières, afin de conserver le plus possible le sens du texte.
Évaluer la performance d’un système RAG peut s’avérer difficile, étant donné la nature complexe de la tâche. Parmi les indicateurs d’évaluation courants, citons la perplexité, la fluidité, la pertinence et la cohérence, sans oublier les indicateurs BLU et ROUGE. Il est important de choisir des indicateurs qui correspondent aux objectifs de la tâche et aux résultats souhaités.
La RAG exige du texte brut, et le choix des méthodes de conversion affecte considérablement la qualité des données. Par exemple, la manière dont les tableaux, les images et autres éléments de métadonnées sont gérés lors de la conversion des fichiers PDF.
Pour générer une réponse semblable à celle d’un humain, les LLM exigent des ressources informatiques considérables, et l’opération prend souvent plusieurs secondes. Le délai dépend de la taille du modèle, de la complexité de la requête utilisateur et de la quantité d’informations augmentées transmises au modèle. Pour les solutions qui doivent servir un nombre important d’utilisateurs ou proposer un temps de réponse rapide, il peut s’avérer nécessaire de mettre en œuvre un mécanisme de mise en cache des réponses aux requêtes fréquentes.
Intégrer des informations propriétaires, potentiellement confidentielles et potentiellement personnelles dans les prompts des LLM est essentiel et nécessaire au schéma RAG. Les entreprises qui se tournent vers les plateformes de modèles hébergés se doivent de prendre connaissance des politiques mises en œuvre par les fournisseurs pour encadrer, par exemple, la conservation et l’utilisation des données de prompt (le fournisseur enregistre-t-il les données de prompt et les utilise-t-il pour le entraîner à nouveau les modèle ?), des contrôles mis en place pour empêcher les données de prompt de « fuiter » vers d’autres utilisateurs, etc. Les entreprises doivent comparer toutes ces mesures à leurs propres politiques et contrôles de sécurité de l’information.
Si la transmission de certaines informations propriétaires est inévitable, les entreprises peuvent limiter leur exposition en incluant lors du traitement uniquement des références document ou URL aux informations les plus sensibles. Par exemple, au lieu d’intégrer la table des réductions de prix dans vos données RAG, vous pouvez inclure dans le contenu uniquement la description de la table et une référence ou un lien vers un document interne ou un site Web.
Si le protocole de sécurité de la couche de transport (TLS) sur les communications interzones peut suffire pour répondre aux exigences en matière de sécurité des données, les architectes ont tout intérêt à renforcer la protection en ajoutant des composants pour chiffrer et déchiffrer les prompts et les réponses avant de les transmettre hors de la zone.
Le type de connexion entre les zones de déploiement a une incidence sur plusieurs exigences non fonctionnelles. Si l’utilisation d’une connexion VPN (réseau privé virtuel) sur l’Internet public est une option peu coûteuse, elle peut ne pas répondre entièrement aux préoccupations en matière de sécurité, ni aux exigences en matière de temps de réponse ou de débit. Si une connexion de type réseau privé à l’environnement d’hébergement du modèle sera beaucoup plus coûteuse, elle offrira un niveau de sécurité nettement supérieur et permettra aux architectes de contrôler la latence et la bande passante du réseau.
Vous pouvez utiliser les modèles de fondation proposés par IBM watsonx.ai pour appliquer le modèle de génération augmentée par récupération et générer des sorties factuelles et précises, ancrées dans une base de connaissances.
L’architecture d’IA générative d’IBM est celle proposée par IBM IT Architect Assistant (IIAA), un outil de développement et de gestion des architectures. IIAA permet aux architectes d’élaborer et de personnaliser l’architecture pour créer leurs propres solutions d’IA génératives.