Qu’est-ce que le RAG ? Comment fonctionne la génération augmentée par récupération
- Rédigé par
- Jack Limebear
- Publié
- Dernière mise à jour
ÉcouterÉcouter cet article
Les modèles IA génèrent des réponses à partir de ce qu’ils ont appris durant leur entraînement. Ils ne connaissent donc pas automatiquement les politiques, les produits ou les autres informations d’une entreprise créés après cet entraînement. Le RAG (Retrieval-Augmented Generation) résout ce problème en récupérant des informations externes pertinentes et en les transmettant au modèle avant sa réponse.
Le RAG ancre les réponses d’une IA dans les documents réels de l’entreprise. Un agent de support client qui utilise le RAG peut consulter la politique de retour ou les spécifications produit à jour avant de répondre, ce qui réduit le risque d’hallucination.
Ce guide explique ce que signifie le RAG en IA, comment récupération et génération fonctionnent ensemble, et en quoi le RAG diffère d’un LLM seul. Nous aborderons aussi les limites du RAG, les applications d’IA générative où il est le plus utile, ainsi que la manière dont il permet la récupération de connaissances dans les agents IA.
En résumé
- Le RAG associe un système de récupération à un modèle génératif afin que celui-ci puisse exploiter des informations au-delà de ses données d’entraînement.
- Les connaissances récupérées par le RAG sont externes au modèle ; elles peuvent donc être mises à jour sans nouvel entraînement.
- ElevenAgents utilise automatiquement le RAG lorsqu’une base de connaissances est trop volumineuse pour tenir directement dans le contexte du modèle. Les réponses restent ainsi rapides et précises, même avec des bases de connaissances étendues et complexes.
Qu’est-ce que le RAG en IA ?
RAG est une architecture système conçue autour d’un LLM pour lui fournir des informations externes, comme des directives de marque, des manuels produit, des articles de base de connaissances ou des bases de données internes. L’IA peut ainsi exploiter des informations propres à l’entreprise, afin que ses réponses reflètent les politiques actuelles, les connaissances privées et les détails de l’entreprise sur lesquels le modèle n’a jamais été entraîné.
Un LLM ne peut également prendre en compte qu’une quantité limitée d’informations à la fois, appelée fenêtre de contexte. Une grande base de connaissances organisationnelle peut rapidement dépasser cette limite. Le RAG conserve donc les informations hors du LLM et ne récupère que les passages nécessaires à la question en cours.
Le nom décrit le cheminement de l’information dans le système :
- Récupération : recherche dans des sources connectées, telles que des documents de politique, des journaux du centre d’aide ou des fichiers d’inventaire, le contenu correspondant à la demande de l’utilisateur.
- Augmentation : ajoute les passages récupérés les plus pertinents au contexte du prompt.
- Génération : exploite la demande de l’utilisateur et le contexte récupéré pour produire la réponse.
Le RAG favorise également l’ancrage factuel, qui consiste à relier une réponse d’IA à des informations sources précises, en fournissant au LLM des éléments pertinents lors de la génération d’une réponse. Par exemple, si un client pose une question sur une politique de garantie, le système RAG récupère les conditions pertinentes dans la documentation de l’entreprise et les transmet au LLM afin qu’il puisse y répondre.
Comment fonctionne la génération augmentée par récupération ?
Un système RAG prépare les connaissances externes pour la recherche, récupère les informations les plus pertinentes pour la question d’un utilisateur et les fournit au LLM comme contexte avant qu’il ne génère une réponse.
Les implémentations du RAG varient en complexité. Le RAG de base repose sur un processus simple de récupération et de génération, tandis que des approches plus avancées peuvent ajouter la réécriture de requêtes, le filtrage, le reranking ou d’autres techniques de récupération.
Le processus RAG suit généralement cinq étapes :
- Préparer les connaissances : les documents sont divisés en passages plus courts (un processus appelé « chunking »), convertis en représentations mathématiques appelées embeddings, puis stockés dans un index interrogeable ou une base de données vectorielle.
- Traiter la requête : le système interprète la question de l’utilisateur et, dans les systèmes RAG plus avancés, la réécrit ou l’affine avant la recherche.
- Récupérer les passages pertinents : le système de récupération recherche dans la base de connaissances indexée les segments de texte qui correspondent le mieux à la demande.
- Ajouter du contexte à la requête du modèle : les passages sélectionnés sont envoyés au LLM avec la question de l’utilisateur, les instructions pertinentes et l’historique de conversation.
- Générer la réponse : le LLM produit une réponse en utilisant les éléments récupérés dans son contexte.
De nombreux systèmes RAG déclenchent sélectivement la récupération en tant qu’outil externe. ElevenAgents permet aux équipes d’activer le RAG pour une base de connaissances directement dans les paramètres de l’agent. Le système utilise ensuite la réécriture de requêtes pour transformer les échanges précédents et les références vagues en une requête de recherche précise et autonome lors des suivis conversationnels.
Pour assurer des réponses rapides, ElevenLabs a également développé une architecture de mise en concurrence des modèles, qui envoie chaque requête à plusieurs modèles de réécriture en parallèle et utilise la première réponse valide. Cette approche a réduit de moitié la latence médiane du RAG, de 326 ms à 155 ms. La récupération reste ainsi suffisamment rapide pour préserver la fluidité naturelle d’une conversation, même lorsqu’elle est déclenchée par une grande base de connaissances.
Quelle est la différence entre les LLM et les modèles RAG ?
Un LLM est un modèle qui comprend et génère du langage. Le RAG est une architecture autour du LLM qui récupère des informations externes lorsque l’application en a besoin.
Voici ce qui change lorsqu’un LLM est associé au RAG :
Fonctionnalité | LLM seul | LLM utilisé avec le RAG |
Connaissances | Données d’entraînement et contexte actuel | Données d’entraînement, contexte actuel et informations d’entreprise récupérées, telles que des politiques, des documents produit ou du contenu de base de connaissances |
Mises à jour | Les nouvelles informations doivent être fournies dans le contexte ou par des mises à jour du modèle | Les connaissances externes peuvent être mises à jour indépendamment du modèle |
Informations privées | Indisponibles si elles ne sont pas fournies | Peuvent être récupérées depuis des sources privées approuvées |
Récupération | Ne fait pas partie du modèle de base | Ajoutée par le système RAG qui entoure le modèle |
L’expression « modèle RAG » est parfois utilisée comme raccourci pour désigner un LLM employé dans un système RAG. Par exemple, une entreprise peut affirmer utiliser un « modèle RAG » pour le support client alors que la configuration réelle repose sur un LLM qui récupère le contenu pertinent du centre d’aide ou des politiques avant de générer une réponse.
Limites des modèles RAG dans les applications réelles
Le RAG améliore l’accès aux connaissances métier pertinentes stockées hors du LLM, mais la récupération introduit ses propres limites et ne garantit pas une réponse correcte. Les principales limites concernent ce que le système récupère, ce qu’il envoie au modèle et la manière dont celui-ci répond :
- Qualité de la récupération : si le système manque le passage le plus pertinent, le LLM part d’un contexte incomplet ou faible. Des requêtes mal formulées, des correspondances sémantiques faibles ou une formulation ambiguë peuvent orienter la récupération dans la mauvaise direction.
- Qualité des sources : des documents obsolètes, contradictoires ou incomplets peuvent produire des réponses peu fiables.
- Sélection du contexte : de mauvais choix de chunking ou de récupération peuvent supprimer des détails nécessaires ou introduire des informations sans rapport.
- Latence supplémentaire : la récupération et le traitement des requêtes interviennent avant la génération, ce qui peut ralentir les réponses dans les applications en temps réel.
- Erreurs de génération : le LLM peut encore mal interpréter les informations récupérées ou introduire des affirmations non étayées.
Le RAG peut réduire le risque d’hallucination, mais ne l’élimine pas complètement. Des résultats précis dépendent toujours de sources bien maintenues, d’une récupération efficace et de contrôles sur la réponse finale.
Le RAG en IA générative : cas d’usage pratiques et avantages
Le RAG est particulièrement utile lorsqu’une application d’IA a besoin d’informations qui évoluent fréquemment, appartiennent à l’organisation ou sont trop volumineuses pour être incluses dans chaque requête au modèle.
Voici les cas où le RAG fait le plus de différence :
Suivre les informations fréquemment mises à jour
Le RAG aide les équipes à maintenir les réponses de l’IA alignées sur les détails produit, tarifs, politiques et inventaires actuels. Les équipes peuvent mettre à jour les informations sources indépendamment, et le RAG récupère la version pertinente lorsqu’une question est posée. Par exemple, un agent de qualification de prospects peut consulter les derniers tarifs ou détails des forfaits lorsqu’il qualifie un appel entrant.
Exploiter des connaissances privées ou spécialisées
Certaines connaissances sont privées ou spécialisées plutôt que publiques, comme les politiques internes, la documentation technique ou le contenu d’assistance destiné à une équipe spécifique. Le RAG permet à un agent de récupérer directement ces sources, au lieu de s’appuyer uniquement sur les informations publiques ou intégrées au modèle.
Par exemple, un agent interne de centre d’aide informatique ou RH peut récupérer des informations dans une base de connaissances dédiée aux RH pour répondre aux questions sur les avantages sociaux des employés, plutôt que de rechercher une documentation publique qui ne contient pas ces informations.
Rechercher dans de grandes bases de connaissances
Le RAG est utile lorsqu’une entreprise possède bien plus de documentation qu’un LLM ne peut prendre en compte dans une seule requête. Il ne récupère que les passages pertinents pour la question en cours, au lieu d’envoyer toute la collection au modèle. Dans un contexte commercial, un assistant technique peut rechercher dans des manuels produit les exigences pertinentes pendant un appel.
Commencez avec ElevenAgents pour des solutions RAG avancées
ElevenAgents permet aux équipes de créer des agents vocaux et de chat IA qui utilisent le RAG avec des sources de connaissances connectées, depuis la plateforme web no-code ou via l’API pour intégrer directement des agents à leurs propres produits.
Pour les agents compatibles avec le RAG, les équipes peuvent ajouter des documents, des URL ou du texte à une base de connaissances et ne récupérer que les informations pertinentes pour chaque requête.
ElevenLabs a également optimisé la récupération pour les conversations en temps réel, réduisant la latence médiane du RAG de 326 ms à 155 ms dans son architecture ElevenAgents. Les équipes qui développent avec ElevenAgents bénéficient de ces capacités de récupération prêtes à l’emploi, qu’elles configurent un agent dans le Dashboard ou s’appuient sur l’API.
Commencer à créer avec ElevenAgents ou contacter notre équipe pour définir la configuration adaptée à votre application.
