La génération augmentée de récupération, qu'est-ce que c'est ?

Copier l'URL

La génération augmentée de récupération ou RAG (Retrieval-Augmented Generation) est une méthode qui permet d'obtenir de meilleures réponses de la part d'une application d'IA générative grâce à l'association de ressources externes à un grand modèle de langage (LLM).

Découvrir Red Hat AI

La RAG permet de compléter les données que contient un LLM avec une sélection de sources de connaissances externes, comme des référentiels de données, des corpus et de la documentation. Ces ressources sont segmentées, indexées dans une base de données vectorielle, puis utilisées comme référence pour produire des réponses plus précises.

Dans le cadre de la RAG, le LLM va récupérer des informations spécifiques en temps réel dans les sources de vérité sélectionnées. Cette méthode permet de proposer une expérience personnalisée sans les dépenses liées à l'entraînement et au réglage fin du modèle, avec à la clé de nombreuses économies. Elle permet aussi d'économiser les ressources, dans la mesure où le LLM interrogé fournira uniquement les informations les plus pertinentes (plutôt que de longs documents).

En savoir plus sur l'IA générative

Ressources Red Hat

Les LLM s'appuient sur des techniques d'apprentissage automatique (AA) et de traitement du langage naturel (TLN) pour comprendre et générer du langage humain. S'ils peuvent être précieux pour la communication et le traitement de données, ils présentent toutefois quelques inconvénients :

  • Les LLM sont entraînés avec des données disponibles publiquement, mais qui n'incluent pas forcément les informations spécifiques souhaitées (par exemple, un ensemble de données interne d'une entreprise).
  • Les connaissances des LLM sont limitées par une date, ce qui implique que les informations avec lesquelles ils ont été entraînés peuvent ne pas être à jour. Par conséquent, ce contenu source peut devenir obsolète et perdre sa pertinence.
  • Les LLM cherchent à plaire, ce qui signifie qu'ils peuvent parfois présenter des informations fausses ou qui ne sont plus valides. C'est le phénomène des « hallucinations ».

La mise en œuvre d'une architecture RAG dans un système de questions-réponses reposant sur un LLM permet d'établir un moyen de communication entre un LLM et la sélection de sources de connaissances supplémentaires. Le LLM est capable de croiser les références et de compléter ses connaissances internes de manière à générer une sortie plus fiable et précise pour l'utilisateur à l'origine de la requête.

En savoir plus sur les grands modèles de langage

L'architecture RAG intègre des mécanismes de récupération qui peuvent exploiter des sources de données supplémentaires sortant du cadre de l'entraînement général d'un LLM. L'utilisation d'un ensemble de faits externes et vérifiables pour alimenter un LLM dans le cadre de la RAG permet d'atteindre plusieurs objectifs avantageux :

Précision
La RAG fournit à un LLM des sources à citer afin que les utilisateurs puissent vérifier les déclarations. Il est également possible de concevoir une architecture RAG qui donne la réponse « Je ne sais pas » lorsque les connaissances du LLM sont insuffisantes. Avec la RAG, un LLM est globalement moins susceptible de partager des informations incorrectes ou trompeuses, ce qui peut renforcer la confiance des utilisateurs.

Rentabilité
Les opérations de réentraînement et de réglage fin des LLM sont coûteuses et chronophages, tout comme la création d'un modèle de fondation (pour concevoir un chatbot par exemple) à partir d'informations propres à un domaine. Grâce à la RAG, un utilisateur peut introduire de nouvelles données dans un LLM ainsi que remplacer ou mettre à jour des sources d'informations en important simplement un document ou un fichier.

La RAG peut également réduire les coûts d'inférence. Les requêtes de LLM coûtent cher, car elles nécessitent plus de matériel en interne ou augmentent les dépenses liées à l'utilisation d'un service externe par le biais d'une interface de programmation d'application (API). Au lieu d'envoyer l'intégralité d'un document de référence à un LLM en une fois, la RAG permet de transmettre uniquement les parties les plus pertinentes, ce qui réduit la taille des requêtes et améliore l'efficacité.

Contrôle de l'équipe de développement
Par rapport aux méthodes de réglage fin traditionnelles, la RAG est un moyen plus simple et accessible de recueillir des avis, de résoudre les problèmes et de corriger les applications. Pour les équipes de développement, le principal avantage de l'architecture RAG est qu'elle permet de tirer parti d'un flux d'informations propres à un domaine et à jour.

Souveraineté et confidentialité des données
L'utilisation d'informations confidentielles pour effectuer le réglage fin d'un LLM a toujours présenté un risque, car ces outils peuvent révéler des informations issues de leurs données d'entraînement. La RAG offre une solution à ces problèmes de confidentialité. Elle permet de conserver sur site les données sensibles, qui sont tout de même utilisées pour fournir des informations à un LLM local ou un LLM externe de confiance. L'architecture RAG peut également être configurée de sorte à limiter la récupération d'informations sensibles à des niveaux d'autorisation spécifiques, c'est-à-dire que les utilisateurs ont accès à certaines informations selon leur niveau d'habilitation de sécurité. 

Les architectures RAG récupèrent les données d'une source externe, les transforment en contexte de LLM, puis génèrent une réponse qui repose sur des sources mixtes. Ce processus comprend trois grandes étapes : la préparation des données, la récupération et la génération.

Étape 1 : préparation des données (en vue de la récupération)

  • Recherche et chargement de documentation : il faut identifier les documents sources à ajouter et vérifier que le LLM comprend leur format (fichiers texte, tables de base de données, fichiers PDF, etc.). Quel que soit le format source, tous les documents doivent être convertis en fichiers texte avant leur intégration à la base de données vectorielle. C'est ce que l'on appelle le processus ETL (extraction, transformation et chargement), qui est utilisé pour nettoyer les données brutes et les organiser de façon à ce qu'elles soient prêtes pour le stockage, l'analyse et l'apprentissage automatique.
     
  • Transformation : afin de préparer les documents pour la récupération, le texte doit être découpé ou segmenté. Les documents mis à jour sont analysés et classés par segments selon des caractéristiques précises. Par exemple, un modèle aura plus de facilité à effectuer une recherche et à récupérer des informations dans les documents contenant des paragraphes plutôt que des tableaux et des figures.

    La segmentation peut reposer sur différents facteurs, tels que le sens, les phrases, les tokens, le formatage, les caractères HTML ou le type de code. De nombreux frameworks Open Source peuvent faciliter le processus d'ingestion de documents, notamment LlamaIndex et LangChain.
     

  • Plongement : les plongements utilisent un modèle d'apprentissage automatique spécialisé (modèle de plongement vectoriel) pour convertir des données en vecteurs numériques, ce qui permet ensuite d'effectuer des opérations mathématiques pour évaluer les similitudes et les différences entre certaines données. Grâce à la technique du plongement, il est possible de convertir du texte (ou des images) en vecteur qui capture le sens fondamental du contenu tout en écartant les détails qui ne sont pas pertinents. Le processus de plongement peut attribuer une valeur numérique (telle que [1,2, −0,9, 0,3]) à un segment de données et l'indexer dans un plus grand système appelé base de données vectorielle.

    Dans une base de données vectorielle, cette valeur numérique aide l'architecture RAG à indiquer les associations entre les segments de contenu et à organiser ces données pour optimiser la récupération. L'objectif de cette indexation est de structurer les vecteurs pour que les concepts similaires soient stockés avec des coordonnées adjacentes. Par exemple, les termes « café » et « thé » seraient positionnés à proximité l'un de l'autre. L'expression « boisson chaude » ne serait pas loin non plus. Les concepts qui n'ont aucun rapport, comme « téléphones portables » et « télévision », seraient plus éloignés. La distance ou la proximité entre deux points de vecteur aide le modèle à choisir les informations à récupérer et à inclure dans la sortie correspondant à la requête de l'utilisateur.
     

  • Stockage : les données combinées issues de plusieurs sources (les documents externes sélectionnés et le LLM) sont stockées dans un référentiel centralisé.
     

Étape 2 : récupération

  • Une fois que les données sont classées dans la base de données vectorielle, les algorithmes recherchent et récupèrent des extraits d'informations correspondant à l'entrée de la requête de l'utilisateur. Les frameworks comme LangChain prennent en charge divers algorithmes de récupération, qui reposent notamment sur les similitudes entre les données, telles que le sens, les métadonnées et les documents parents.

    Dans le contexte d'un client à domaine ouvert, les informations récupérées proviennent de documents indexés accessibles sur Internet via l'API d'une source d'informations. Dans le contexte d'une entreprise à domaine fermé, où les informations doivent rester confidentielles et être protégées des sources extérieures, la récupération via l'architecture RAG peut rester locale et garantir une meilleure sécurité.

    Enfin, les données récupérées sont injectées dans le prompt et envoyées au LLM pour traitement.
     

Étape 3 : génération

  • Sortie : une réponse est donnée à l'utilisateur. Si la méthode RAG fonctionne comme prévu, l'utilisateur obtiendra une réponse précise et basée sur les connaissances sources fournies.

Commencer à utiliser les frameworks d'IA avec les services de consulting Red Hat

Lors de la création d'un modèle d'apprentissage automatique, il est important de choisir des documents sources de qualité pour garantir celle des réponses données. Les systèmes qui produisent des résultats faussés ou biaisés représentent un problème de taille pour toute entreprise qui utilise l'IA. Pour limiter les biais dans les sorties, il est essentiel de vérifier que les documents sources sélectionnés ne contiennent pas d'informations biaisées, c'est-à-dire des contenus qui placent systématiquement les groupes de personnes privilégiées à leur avantage et les groupes de personnes défavorisées à leur désavantage.

Lors de la recherche des données pour l'architecture RAG, il faut s'assurer que celles qui sont ajoutées aux documents sources sont à jour et citées de manière exacte. De plus, des spécialistes humains doivent aider à évaluer les sorties et la qualité des résultats avant et même après le déploiement du modèle en production pour un public plus large.

Il est important de bien comprendre les différences entre les méthodes d'entraînement de données et l'architecture RAG pour savoir quelle ressource d'IA déployer selon les besoins, sachant qu'il est possible d'utiliser plusieurs méthodes. Voyons donc les principales méthodes d'utilisation des données, et leurs différences avec la RAG.

RAG et ingénierie de prompt
L'ingénierie de prompt est le moyen le plus élémentaire et le moins technique d'interagir avec un LLM. Cette méthode repose sur l'écriture d'un ensemble d'instructions qui permet à un modèle de générer une sortie spécifique lorsqu'un utilisateur envoie une requête. Par rapport à la RAG, l'ingénierie de prompt nécessite moins de données puisqu'elle utilise uniquement celles avec lesquelles le modèle a été préentraîné. Elle coûte moins cher, car elle utilise uniquement les outils et modèles existants. Elle est toutefois incapable de générer des sorties basées sur des informations à jour ou évolutives. En outre, la qualité des sorties dépend de la formulation du prompt. Les réponses peuvent donc être incohérentes.

L'ingénierie de prompt est à privilégier si l'entreprise recherche une méthode intuitive et rentable pour extraire des informations sur des sujets généraux sans avoir besoin de beaucoup de détails.

RAG et recherche sémantique
La sémantique correspond à l'étude du sens des mots. La recherche sémantique est une technique d'analyse de données qui prend en compte l'intention et le contexte d'une requête.

La recherche sémantique utilise le TLN et l'AA pour déchiffrer une requête et rechercher les données à utiliser afin de donner une réponse plus précise et pertinente qu'avec une simple correspondance de mots-clés. Autrement dit, la recherche sémantique réduit l'écart entre la requête saisie par un utilisateur et les données exploitées pour générer un résultat.

Par exemple, si la requête comprend l'expression « vacances de rêve », la recherche sémantique aiderait le modèle à comprendre qu'il est plus probable que la recherche porte sur des vacances « idéales ». Au lieu d'aborder les rêves, la réponse serait plus adaptée à l'intention et proposerait peut-être un forfait vacances pour un séjour à la mer.

La recherche sémantique est un élément de la RAG utilisé lors de l'étape de récupération dans la base de données vectorielle pour produire des résultats à la fois à jour et adaptés au contexte.

RAG et préentraînement
Le préentraînement correspond à la phase initiale de l'entraînement, au cours de laquelle un LLM développe une compréhension globale du langage en apprenant à partir d'un grand ensemble de données. À l'instar du cerveau humain qui crée des chemins neuronaux lorsque l'on apprend, le préentraînement développe un réseau neuronal au sein d'un LLM à mesure de son entraînement avec les données.

Le préentraînement d'un LLM est plus coûteux que la RAG. Il peut également prendre plus de temps et nécessiter davantage de ressources de calcul (des milliers de GPU). Le préentraînement est à privilégier si l'entreprise a accès à un ensemble de données qui est suffisamment volumineux pour avoir une incidence significative sur le modèle entraîné, et si elle souhaite que le LLM ait une compréhension fondamentale de certains sujets ou concepts.

RAG et réglage fin
L'architecture RAG définit les connaissances d'un LLM et le réglage fin détermine son comportement. Ce processus consiste à prendre un LLM préentraîné et à approfondir son entraînement avec un ensemble de données plus petit et ciblé. Il permet au modèle d'apprendre des schémas courants qui n'évoluent pas au cours du temps.

Si à première vue, la RAG et le réglage fin peuvent paraître similaires, ces méthodes présentent bien des différences. Par exemple, le réglage fin requiert un grand volume de données et une quantité considérable de ressources de calcul pour la création du modèle, tandis que la RAG peut récupérer des informations à partir d'un seul document et nécessite beaucoup moins de ressources de calcul. De plus, la RAG réduit efficacement les hallucinations, alors que l'utilisation du réglage fin d'un LLM pour limiter ce phénomène est un processus bien plus chronophage et compliqué.

Souvent, l'utilisation combinée du réglage fin et d'une architecture RAG est plus avantageuse. Le réglage fin s'avère toutefois plus intéressant si l'entreprise a déjà accès à une énorme quantité de données et de ressources, si ces données ont plutôt tendance à ne pas évoluer ou s'il s'agit d'une tâche spécialisée qui exige une analyse plus personnalisée pour laquelle le format question-réponse, caractéristique de la RAG, n'est pas adapté.

En savoir plus sur la RAG et le réglage fin

Les cas d'utilisation de l'architecture RAG sont nombreux. Voici certains des cas les plus courants.

  • Service clientèle : il est possible de programmer un chatbot de sorte à répondre aux demandes de la clientèle avec les informations issues d'un document spécifique pour ainsi réduire le temps de résolution et améliorer l'efficacité du système de service clientèle.

  • Génération d'informations : la RAG peut aider à extraire davantage d'informations des documents existants. L'utilisation d'une architecture RAG permet d'associer un LLM à des rapports annuels, des documents marketing, des commentaires sur les réseaux sociaux, des avis de la clientèle, des résultats d'étude, des documents de recherche ou tout autre support, pour ainsi obtenir des réponses qui favorisent une meilleure compréhension des ressources. La RAG permet d'accéder à des sources de données en direct, comme des fils d'actualité de réseau social, des sites web ou d'autres sources fréquemment mises à jour pour générer des réponses utiles en temps réel.

  • Systèmes d'information de santé : l'architecture RAG peut améliorer les systèmes qui fournissent des informations ou conseils en lien avec la santé. Avec la possibilité d'examiner des éléments tels que le dossier médical, les services de planification de rendez-vous et les dernières recommandations et avancées de la recherche médicale, la RAG facilite la mise en relation des patients avec une assistance et des services adaptés à leurs besoins.

Notre gamme de produits Red Hat® AI repose sur des solutions que nos clients utilisent déjà en toute confiance. C'est ce qui permet à nos produits de rester fiables, flexibles et évolutifs.

Elle offre les avantages suivants :

  • Rapidité d'adoption de l'IA et d'innovation
  • Simplification de la distribution de solutions d'IA
  • Possibilité de déploiement dans tous les environnements

Découvrir Red Hat AI 

Collaboration et contrôle dans le cadre du développement

Nos solutions d'IA permettent aux entreprises de mettre en œuvre une architecture RAG au sein de leur processus LLMOps en leur fournissant l'infrastructure sous-jacente pour les charges de travail.

Plateforme MLOps flexible et évolutive, la solution Red Hat® OpenShift® AI inclut notamment des outils de création, de déploiement et de gestion d'applications basées sur l'IA pour les équipes de développement. Elle fournit l'infrastructure sous-jacente pour prendre en charge une base de données vectorielle, créer des intégrations, interroger des LLM et utiliser les mécanismes de récupération nécessaires à la production de résultats.

Nos solutions pour l'IA proposent également des mécanismes d'alignement de modèles pour améliorer les LLM. Appelée InstructLab, cette solution met en œuvre une approche Open Source et communautaire pour améliorer les capacités des LLM.

Grâce à une collaboration continue et prise en charge, les entreprises peuvent personnaliser les applications de modèles d'IA de manière simple et rapide en fonction de leurs cas d'utilisation.

Découvrir Red Hat OpenShift AI

Créer une application RAG

Red Hat OpenShift AI est une plateforme qui sert à réaliser des projets de science des données et à servir des applications basées sur l'IA. Il est possible d'intégrer tous les outils nécessaires pour prendre en charge la génération augmentée de récupération (RAG), un moyen d'obtenir des réponses d'une IA basées sur des documents de référence spécifiques. L'association d'OpenShift AI et de NVIDIA AI Enterprise permet d'utiliser des grands modèles de langage (LLM) afin de trouver le modèle optimal pour chaque application.

Concevoir un pipeline pour les documents

Pour tirer parti de la RAG, il est nécessaire, dans un premier temps, d'ajouter des documents dans une base de données vectorielle. Dans notre exemple d'application, nous intégrons un ensemble de documents relatifs à des produits dans une base de données Redis. Puisque ces documents changent fréquemment, nous avons créé un pipeline pour ce processus que nous exécuterons régulièrement afin de nous assurer que l'IA dispose toujours des dernières versions des documents.

Parcourir le catalogue de LLM

NVIDIA AI Enterprise donne accès à un catalogue varié de LLM. Il est donc possible de tester plusieurs modèles et de sélectionner celui qui offre les meilleurs résultats. Les modèles sont hébergés dans le catalogue d'API de NVIDIA. Une fois le token API configuré, un modèle peut être déployé directement à partir d'OpenShift AI, en utilisant la plateforme de service de modèles NVIDIA NIM.

Choisir le modèle le plus adapté

Lors du test de différents LLM, les utilisateurs peuvent noter chaque réponse générée. Il est possible de configurer un tableau de bord de surveillance Grafana pour comparer les notes ainsi que la latence et le temps de réponse pour chaque modèle. Ensuite, ces données peuvent être utilisées pour choisir le meilleur LLM à utiliser en production.


 

An architecture diagram shows an application built using Red Hat OpenShift AI and NVIDIA AI Enterprise. Components include OpenShift GitOps for connecting to GitHub and handling DevOps interactions, Grafana for monitoring, OpenShift AI for data science, Redis as a vector database, and Quay as an image registry. These components all flow to the app frontend and backend. These components are built on Red Hat OpenShift AI, with an integration with ai.nvidia.com.

 

Télécharger le PDF

Hub

Le blog officiel de Red Hat

Découvrez les dernières informations concernant notre écosystème de clients, partenaires et communautés.

Tous les essais de produits Red Hat

Profitez de nos essais gratuits de produits Red Hat pour renforcer votre expérience pratique, préparer une certification ou évaluer l'adéquation d'un produit avec les besoins de votre entreprise.

En savoir plus

IA prédictive et IA générative

L'IA générative et l'IA prédictive ont différentes caractéristiques et utilisations. Dans un contexte d'évolution continue, il est important de savoir distinguer ces deux types d'IA pour mieux comprendre leurs capacités spécifiques.

L'IA agentique, qu'est-ce que c'est ?

L'IA agentique est un système logiciel conçu pour interagir avec les données et les outils d'une manière qui nécessite une intervention humaine minimale.

La famille de modèles Granite, qu'est-ce que c'est ?

La famille Granite regroupe des grands modèles de langage qui ont été créés par IBM pour les applications d'entreprise. Les modèles de fondation Granite peuvent prendre en charge les cas d'utilisation de l'intelligence artificielle générative qui reposent sur un langage spécifique et du code.

IA/ML : ressources recommandées