Qu'est-ce que la génération augmentée de récupération (RAG) ?

La génération augmentée de récupération fournit des données contextuelles et actualisées pour les rendre utiles.

Cette technique comble leurs lacunes en leur donnant accès à des données contextuelles et à jour. Les mises en œuvre de la RAG, parfois appelées modèles RAG, fonctionnent en combinant un LLM pré-entraîné avec un système de récupération d'informations facilement accessibles. Ce dernier est chargé de trouver des informations pertinentes dans une bibliothèque de connaissances, telle qu'une base de données. Les modèles RAG permettent au LLM de générer une réponse plus précise avec un contexte à jour et pertinent pour la tâche à accomplir.

Ils se sont révélés efficaces pour de nombreuses tâches qui nécessitent de solides connaissances, telles que :

• les tâches de génération de langage, comme répondre à des questions de manière exhaustive et éclairée, ou générer différents formats de texte créatifs, comme des poèmes, des scripts, des morceaux de musique, des e-mails, des lettres, etc.
• Les tâches de TAL, comme résumer des conversations, des enregistrements audio et des appels vidéo ;
• les tâches qui nécessitent une classification, telles que la cybersécurité et la conformité, ou des capacités de raisonnement comme la gestion d'entreprise.

Elle peut également être utilisée pour permettre à une application générative alimentée par l'IA d'observer un état d'arrière-plan et d'adapter ses générations en conséquence. Il peut s'agir, par exemple, d’écrire du code basé sur le code écrit par un utilisateur. Parmi les autres exemples, citons :

• le contexte de l'application. Supposons que vous créiez un assistant Excel alimenté par l'IA. Il serait utile qu'il connaisse le nom de vos feuilles, le nom du fichier, les plages de cellules sélectionnées, etc. La RAG introduira ces « informations sur l'activité de base » dans le prompt afin que le LLM puisse adapter son aide à votre feuille.
• les données personnelles (par exemple, un chatbot d'assistance aux représentants). Supposons que vous créez un robot d'assistance à la clientèle. Il peut s'appuyer sur les conversations précédentes et l'historique du CRM pour ce client spécifique afin d'adapter la conversation (pas seulement l'accueil, mais aussi la personnalisation des options, etc.) Sans cet historique, le LLM ne sera pas en mesure d'effectuer efficacement la personnalisation ou de résoudre les problèmes existants ;
• les chiffres bruts, indicateurs, données tabulaires (par exemple, CSV, Parquet, JSON, etc.). La RAG ne se limite pas au contexte textuel, elle s'appuie également sur des informations quantitatives. Un chatbot de business intelligence (BI) ferait certainement de la RAG sur des données tabulaires brutes ;
• les autres types de données multimodales tels que les images, les vidéos et l'audio. De nombreux modèles, tels que DALL-E 2, peuvent exploiter le texte pour créer ou augmenter des images. À l’inverse, ils peuvent synthétiser des images ou des vidéos en langage naturel. Grâce au contexte de certaines images ou de certains facteurs de forme, la RAG peut rendre les applications d'IA générative plus puissantes lorsqu'il s'agit de créer des ressources marketing ou de générer des résumés et des traductions à partir de vidéos qui contiennent des informations très spécifiques et très contextuelles.

Elle est également utile pour les données qui ne peuvent pas être incorporées en tant que données d'entraînement.

• les données très volatiles/sensibles au temps : les données telles que les actualités boursières deviennent rapidement obsolètes. Par conséquent, il est plus logique d'améliorer le LLM avec les informations les plus récentes, idéalement à chaque demande pendant le temps d'inférence, plutôt que d'essayer de réentraîner les LLM avec ce corpus.
• les données sensibles : la plupart des LLM les plus performants (tels que GPT d'OpenAI ou Claude d'Anthropic) sont payants et appartiennent à ces sociétés. L'utilisation d'informations personnelles et sensibles dans les données de formation pour affiner ces LLMS peut entraîner des fuites de données privées et est potentiellement dangereuse. Ainsi, RAG est parfois la seule option sûre.

Principaux cas d'utilisation de RAG.

Compte tenu de ce qui précède, voici les cas d'utilisation les plus appropriés de la RAG :

• la réponse aux questions sur toute connaissance extrinsèque du domaine telle que la documentation spécifique à l'entreprise et les bases de connaissances, les systèmes opérationnels en direct, les systèmes de back-office, etc. Par définition, l'utilisation de LLM avec toute donnée en dehors de leur champ de connaissances nécessite de la RAG. En outre, les questions et les réponses portent sur un contexte très sensible au temps et qui évolue rapidement : les données qui deviennent rapidement obsolètes sont impossibles à intégrer dans les LLM via un affinage ;
• pour réduire les hallucinations et augmenter la précision : de manière générale, la RAG peut améliorer la précision même pour répondre à des questions sur des informations contenues dans le corpus de formation du LLM. Cela s'explique par le fait qu'elle transforme les réponses aux questions en un « quiz à livre ouvert », ce qui est plus facile qu'une réponse à une question non délimitée ;
• la personnalisation est un cas d'utilisation canonique pour la RAG. Dans ce cas, l'invite est complétée par les données de l'utilisateur. Toutes les données PII peuvent éventuellement être nettoyées avant d'être insérées dans l'invite ;
• fournir des réponses contextuelles (dans Co-Pilots). Comme le montre Github Copilot, les générations de LLM peuvent être plus pertinentes lorsqu'elles sont basées sur l'état de l'application (le document actuel, les métadonnées générales du projet, l'URL ou la page actuellement visitée, etc.) ;
• toute application d'IA générative qui fonctionne avec des contextes très spécifiques à un domaine. Il s’agit par exemple de la santé, des services financiers, de la recherche juridique et des sciences et de l’ingénierie. Dans ces domaines, les données d'entraînement sont souvent rares et le RAG est donc essentielle pour créer des applications d'IA générative utiles.

Pourquoi la génération augmentée de récupération ? Quelles sont les alternatives à la RAG dans le cadre de la création d'applications d'IA générative ?

Il existe un certain nombre d'alternatives à la RAG pour créer des applications d'IA générative. Voici quelques-unes des alternatives les plus populaires :

• entraîner son propre LLM : bien qu'il puisse être justifié d'entraîner son propre LLM, il sera probablement beaucoup trop coûteux et long de créer un modèle compétitif avec les nombreux modèles commerciaux (GPT d'OpenAI) et open source (LLaMa de Meta) disponibles ;
• affinage d'un LLM existant : cette technique consiste à réentraîner un LLM pré-entraîné sur un ensemble de données plus petit de données spécifiques à une tâche. L'affinage peut être efficace pour améliorer les performances d'un LLM sur une tâche spécifique, mais il peut également s'avérer coûteux et chronophage. Ce processus est continu : à mesure que de nouvelles données sont disponibles, le modèle doit être à nouveau affiné. Si votre application d'IA générative exige l'accès à des données opérationnelles en direct, l'affinage ne sera pas adapté.

Pourquoi privilégier la génération augmentée de récupération à l'affinage d'un LLM ?

• L'affinage est une autre solution visant à utiliser les LLM avec des « données personnalisées », mais contrairement à la génération augmentée de récupération, qui revient à donner à un LLM un quiz à livre ouvert, l'affinage revient à lui donner des souvenirs entièrement nouveaux ou à lui faire subir une lobotomie. Cette méthode permet d'adapter le modèle afin de modifier ses performances, son comportement, son profil de coût, etc. Ce processus est très chronophage et demande de nombreuses ressources. Il n'est généralement pas viable pour fonder les LLM sur un contexte spécifique, et est particulièrement inadapté aux données opérationnelles en temps réel de votre entreprise.

Les fondamentaux d'une architecture RAG

Une architecture de base de génération augmentée de récupération se compose de trois éléments principaux :

• un LLM pré-entraîné : le LLM est responsable de la génération de texte, d'images, d'audio et de vidéo ;
• la recherche vectorielle (ou recherche sémantique) : le système de récupération est chargé de trouver des informations pertinentes à partir d'une base de connaissances externe au LLM. Il existe de nombreuses bases de données générales ou bases de données vectorielles à usage unique qui permettent de stocker les vector embeddings et d'exécuter des requêtes de recherche approximative du plus proche voisin sur celles-ci. La recherche vectorielle est essentielle pour pouvoir améliorer avec précision les connaissances exclusives fournies à un LLM à usage général ;
• vector embeddings : parfois simplement appelés « vecteurs » ou « intégrations », il s'agit essentiellement des représentations numériques capturant la sémantique ou la signification sous-jacente d'une donnée. En règle générale, il s'agit d'un tableau de valeurs flottantes, où chaque valeur flottante représente une dimension unique des représentations numériques ;
• orchestration : le mécanisme de fusion est chargé de combiner la sortie du LLM avec les informations du système de récupération pour générer le résultat final.

Le schéma suivant montre une architecture RAG de base avec le même exemple de vente au détail que précédemment :

Pour pallier ce manque de contexte spécifique au domaine, la génération augmentée de récupération est effectuée comme suit :

• nous récupérons les descriptions de produits les plus pertinentes dans une base de données (souvent une base de données dotée de la recherche vectorielle) qui contient le dernier catalogue de produits ;
• ensuite, nous insérons (augmentons) ces descriptions dans l'invite du LLM ;
• enfin, nous demandons au LLM de « référencer » ces informations de produits à jour en répondant à la question.

Trois éléments à prendre en compte à partir de ce qui précède :

• la génération augmentée de récupération est une technique purement basée sur le temps d'inférence (le recyclage n'est pas nécessaire). Les étapes 1 à 3 ci-dessus se déroulent toutes dans le temps de l'inférence. Aucune modification du modèle n'est nécessaire (par exemple, la modification des poids du modèle) ;
• la génération augmentée de récupération est particulièrement adaptée aux personnalisations en temps réel des générations LLM. Comme il n'y a pas de réentraînement et que tout se fait par apprentissage en contexte, l'inférence basée sur la RAG est rapide (latence inférieure à 100 ms) et particulièrement adaptée à une utilisation dans des applications opérationnelles en temps réel ;
• la génération augmentée de récupération rend les générations LLM plus précises et plus utiles. Chaque fois que le contexte change, le LLM génère une réponse différente. Ainsi, la RAG fait en sorte que les LLM dépendent du contexte récupéré.

Simplifier la RAG mais faire en sorte qu'elle soit suffisamment élaborée pour fonctionner de manière fiable à grande échelle

Pour obtenir une architecture RAG performante et peu complexe, il faut d'abord choisir les bons systèmes. Lorsque vous choisissez des systèmes ou des technologies pour la mise en œuvre d'un système RAG, vous devez choisir un système ou des systèmes qui répondent aux objectifs suivants :

• la prise en charge de nouvelles exigences en matière de données vectorielles sans augmenter considérablement l'étendue, le coût et la complexité de vos activités informatiques ;
• s'assurer que les expériences d'IA générative développées ont accès à des données en direct avec une latence minimale ;
• avoir la flexibilité nécessaire pour répondre aux nouvelles exigences en matière de données et d'applications et permettre aux équipes de développement de rester agiles ;
• doter les équipes de développement des outils nécessaires pour qu’elles puissent intégrer l’ensemble de l’écosystème de l’IA à leurs données, et non l’inverse.

Il peut s'agir de bases de données vectorielles à usage unique ou de bases de données documentaires et relationnelles dotées de capacités vectorielles natives, en passant par les entrepôts de données et les lakehouses. Toutefois, les bases de données vectorielles à usage unique entraîneront immédiatement une prolifération et une complexité accrues. Les entrepôts de données et les lakehouses sont intrinsèquement conçus pour des requêtes analytiques de longue durée sur des données historiques, par opposition aux exigences élevées en matière de volume, de faible latence et de données récentes des applications d'IA générative alimentées par la RAG. En outre, les relational databases comportent des schémas rigides qui limitent la possibilité d'ajouter de nouvelles données et des exigences concernant l'application. Il ne reste plus que les bases de données documentaires dotées de capacités vectorielles natives ou intégrées. À ce titre, MongoDB repose sur un modèle documentaire flexible et dispose de fonctionnalités de recherche vectorielle natives. C'est donc une base de données vectorielles pour la RAG en plus d'être la base de données leader du secteur pour toute application moderne.

Faire passer les LLM au niveau supérieur avec des capacités supplémentaires dans votre mise en œuvre de la RAG

Outre les composants de base, il existe un certain nombre de fonctionnalités supplémentaires qui peuvent être ajoutées à un projet de mise en œuvre de la RAG pour améliorer la puissance des LLM. En voici quelques-unes  :

• la multimodalité : les modèles RAG multimodaux peuvent générer des textes basés sur des données textuelles et non textuelles, telles que des images, des vidéos et des sons. Le fait que ces données multimodales soient stockées avec les données opérationnelles en temps réel facilite la conception et la gestion de la mise en œuvre de la RAG ;
• la définition de filtres supplémentaires dans la requête de recherche vectorielle : la possibilité d'ajouter des filtres de recherche par mot-clé, de recherche géospatiale, de point et d'intervalle sur la même requête vectorielle peut renforcer la précision et la rapidité du contexte fourni au LLM ;
• la spécificité du domaine : les modèles RAG propres à un domaine peuvent être entraînés sur des données provenant d'un domaine particulier, comme les soins de santé ou la finance. Cela permet au modèle RAG de générer un texte plus précis et plus pertinent pour ce domaine.

Garantir la sécurité, la performance, la fiabilité et l'évolutivité de votre application alimentée par l'IA générative lorsqu'elle sera disponible mondialement

Il y a un certain nombre de choses à faire pour s'assurer qu'une application alimentée par l'IA générative qui repose sur la RAG est sûre, performante, fiable et évolutive lorsqu'elle est lancée à l'échelle mondiale. Voici quelques exemples :

• utiliser une plateforme sécurisée dotée de capacités de gouvernance des données adéquates : la gouvernance des données est un terme générique qui englobe toutes vos initiatives visant à garantir la sécurité, la confidentialité, l'exactitude, la disponibilité et l'utilisation des données. Elle comprend les processus, les politiques, les mesures, la technologie, les outils et les contrôles relatifs au cycle de vie des données. La plateforme doit donc être sécurisée par défaut, disposer d'un chiffrement de bout en bout et avoir atteint les niveaux de conformité les plus élevés ;
• utiliser une plateforme basée sur le cloud : outre les caractéristiques de sécurité et d'évolutivité qu'offrent les plateformes basées sur le cloud, les principaux fournisseurs de ce secteur sont ceux qui innovent le plus en matière d'infrastructure d'IA. Le choix d'une plateforme agnostique permet aux équipes de tirer parti des innovations en matière d'IA, où elles se trouvent ;
• utiliser une plateforme capable d'isoler l'infrastructure des charges de travail vectorielles de l'infrastructure des autres bases de données : les charges de travail OLTP ordinaires et les charges de travail vectorielles ne doivent pas partager l'infrastructure afin que les deux charges de travail puissent s'exécuter sur du matériel optimisé pour chacune d'entre elles, et qu'elles ne soient pas en concurrence pour les resources tout en étant en mesure d'utiliser les mêmes données ;
• utiliser une plateforme qui a fait ses preuves à grande échelle : c'est une chose pour un fournisseur de dire qu'il peut s'adapter, mais peut-il témoigner de ses réussites à l'échelle internationale ? A-t-il une tolérance aux pannes critiques et une capacité à évoluer horizontalement, et peut-il le prouver avec des témoignages de clients ?

En suivant ces conseils, il est possible de créer des applications alimentées par l'IA générative avec des architectures RAG sécurisées, performantes, fiables et évolutives.

Avec l'introduction d'Atlas Vector Search, la developer data platform de MongoDB fournit aux équipes une base de données vectorielles qui permet de construire des architectures RAG sophistiquées et performantes qui peuvent fonctionner à grande échelle. Tout cela en maintenant les plus hauts niveaux de sécurité et d'agnosticisme dans le cloud, et surtout, sans rendre les processus plus complexes et ajouter de frais inutiles.