RAG, ou retrieval-augmented generation (génération augmentée par récupération), est un modèle qui extrait des documents pertinents depuis un store externe et les transmet à un modèle de langage en tant que contexte avant qu'il génère une réponse. Le modèle répond à partir de ce qu'il récupère, et pas uniquement de ce qu'il a appris lors de l'entraînement.
Pourquoi ce modèle existe
Les modèles de langage ont une date limite de connaissance fixe et n'ont aucune conscience des données privées. Un modèle entraîné sur des textes publics ne peut pas répondre à des questions sur votre documentation interne, les événements récents ou les données propriétaires, sauf si ces informations lui sont fournies au moment de l'inférence. RAG est la méthode standard pour les lui fournir.
L'alternative, le fine-tuning, intègre les connaissances dans les poids du modèle. Cette méthode est coûteuse, lente à mettre à jour et peu adaptée aux informations qui changent fréquemment. RAG maintient le store de connaissances et le modèle séparés, ce qui permet de mettre à jour les documents sans toucher au modèle.
Comment ça fonctionne
À un niveau général, un pipeline RAG comporte trois étapes :
- L'indexation. Les documents sources sont découpés en fragments, convertis en embeddings vectoriels et stockés dans une base de données vectorielle. Des métadonnées sont souvent stockées aux côtés des vecteurs pour faciliter le filtrage.
- La récupération. Lorsqu'une requête arrive, elle est également convertie en embedding. Le système recherche dans le store vectoriel les fragments dont les embeddings sont proches de l'embedding de la requête, généralement par similarité cosinus ou produit scalaire. Certains pipelines ajoutent une étape de reranking pour améliorer la précision.
- La génération. Les fragments récupérés sont insérés dans le prompt en tant que contexte. Le modèle de langage lit à la fois la requête et le texte récupéré, puis génère une réponse ancrée dans ce matériau.
On parle parfois de la fenêtre de contexte comme d'une surface de travail : vous alimentez la fenêtre de contexte du modèle avec des faits récupérés plutôt que de vous appuyer sur sa mémoire paramétrique.
Ce qui peut mal tourner
RAG ne garantit pas automatiquement la précision. Plusieurs modes d'échec sont courants.
Échecs de récupération. Si le fragment pertinent n'est pas récupéré, le modèle hallucine ou indique qu'il ne sait pas. La taille des fragments, le choix du modèle d'embedding et la formulation de la requête influencent tous le rappel.
Empoisonnement du contexte. Du texte récupéré qui est obsolète, contradictoire ou hors sujet peut induire le modèle en erreur, même lorsque l'étape de récupération réussit techniquement.
Injection de prompt. Du contenu malveillant intégré dans un document récupéré peut tenter de rediriger le comportement du modèle. Il s'agit d'un risque réel lorsque le corpus de documents n'est pas entièrement maîtrisé. Voir qu'est-ce que l'injection de prompt pour plus de détails.
Erreurs d'attribution. Les modèles mélangent parfois le contenu récupéré avec les connaissances issues de l'entraînement de manière difficile à retracer. Rattacher les affirmations aux fragments sources est une bonne pratique, mais elle nécessite une conception délibérée du pipeline.
La place de RAG dans une architecture plus large
RAG est souvent l'un des composants d'une architecture plus large. Un serveur MCP peut exposer la récupération comme un outil qu'un agent appelle dynamiquement, plutôt que de récupérer à chaque requête. Les environnements de codage agentique utilisent parfois RAG pour intégrer le contexte d'une base de code qui dépasse ce qui tient dans un seul prompt.
L'évaluation est importante ici. Un pipeline RAG doit être testé selon la qualité de la récupération, la fidélité des réponses et la pertinence des réponses, en tant que trois préoccupations distinctes. Un indicateur agrégé unique masque le composant défaillant. Voir qu'est-ce qu'un eval pour la façon dont la conception de l'évaluation s'applique.
Ce que nous évaluons
Les ingénieurs qui travaillent avec des pipelines RAG doivent raisonner clairement sur l'origine d'une défaillance : l'étape de récupération, le contexte transmis au modèle, ou l'utilisation que le modèle fait de ce qui lui est fourni. Notre processus de sélection évalue cela directement. Dans l'évaluation AI-native, les candidats sont notés sur la vérification des sorties IA et le débogage accéléré par l'IA, deux critères qui révèlent si quelqu'un comprend l'ensemble du pipeline ou le traite comme une boîte noire. L'approche complète est décrite sur how we vet.
Réponses courtes
Quelle est la différence entre RAG et le fine-tuning ?
Le fine-tuning intègre les connaissances dans les poids du modèle et nécessite un réentraînement pour les mettre à jour. RAG récupère les connaissances au moment de l'inférence depuis un store externe, ce qui facilite leur mise à jour et le rend plus adapté aux informations privées ou qui changent fréquemment.
RAG élimine-t-il les hallucinations ?
Non. RAG réduit les hallucinations en ancrant les réponses dans le texte récupéré, mais le modèle peut toujours mal interpréter, mélanger ou ignorer ce texte. Les échecs de récupération privent également le modèle du contexte dont il a besoin, ce qui peut produire des réponses confiantes mais incorrectes.
Quel type de base de données RAG utilise-t-il ?
La plupart des pipelines RAG utilisent une base de données vectorielle pour stocker et rechercher des embeddings de documents par similarité. Certaines implémentations ajoutent des stores de métadonnées relationnelles ou une recherche par mots-clés en complément de la recherche vectorielle pour améliorer la précision de la récupération.
