Génération augmentée par la récupération

La génération augmentée par la récupération est un modèle qui récupère des informations pertinentes provenant de sources en dehors des paramètres appris par le modèle et les fournit comme contexte avant que le modèle ne génère une réponse [1].

RAG est une méthode permettant à une IA de répondre en utilisant des informations externes récupérées au moment de la génération, qu'elles aient ou non été présentes dans les données d'entraînement du modèle. Au lieu de demander au modèle de répondre à partir de ses paramètres appris et du prompt seul, le système recherche d'abord dans un magasin de documents, récupère les passages pertinents, les ajoute au prompt ou au contexte, puis demande au modèle de répondre à partir de ceux-ci.

Cela peut rendre les systèmes d'IA plus utiles pour les politiques d'entreprise, la documentation produit, les bases de connaissances de support, les notes de recherche et les procédures internes. Cela peut également réduire certains risques d'« hallucination » en ancrant les réponses dans le matériel fourni. Cela ne garantit pas la correction. Le système peut récupérer la mauvaise section, manquer le bon document, utiliser du contenu obsolète, exposer des données que l'utilisateur ne devrait pas voir, ou être manipulé par des instructions cachées dans les documents récupérés.

De nombreuses tâches utiles en IA dépendent d'informations qui n'étaient pas présentes dans les données d'entraînement du modèle ou qui changent souvent. Une politique de support change. Un manuel scolaire est mis à jour. Un produit a une nouvelle étape de configuration. Un modèle de contrat a des exceptions locales. RAG offre aux développeurs un moyen pratique de connecter un modèle à des connaissances sélectionnées sans avoir à réentraîner le modèle à chaque fois.

L'article RAG original de Lewis et ses collègues a combiné la récupération et la génération pour les tâches NLP intensives en connaissances, présentant l'architecture comme un modèle de recherche plutôt qu'une garantie de vérité [1]. Les recommandations des fournisseurs comme AWS sont utiles pour les choix d'implémentation pratiques, tels que les options de récupération et les compromis d'architecture, mais elles doivent être traitées comme des directives d'implémentation, et non comme l'autorité neutre unique pour le concept [2].

Pour les organisations, RAG est attrayant car la source de connaissance peut être gérée séparément du modèle. Une équipe peut mettre à jour les documents, supprimer les pages obsolètes, améliorer le découpage et changer les autorisations sans entraîner un nouveau modèle de base. Cela rend RAG pratique, mais cela signifie aussi que la qualité de la réponse dépend du travail ordinaire de gestion de l'information : des documents propres, une propriété claire, des politiques à jour et une récupération testée.

Un système RAG de base comporte trois parties. La première est la récupération. Le système prend la question de l'utilisateur et recherche des documents ou des enregistrements structurés, souvent à l'aide de recherches par mots-clés, d'encodages vectoriels, de filtres de métadonnées, de requêtes structurées ou d'une combinaison de méthodes. La deuxième est l'augmentation, souvent mieux décrite comme l'assemblage du contexte. Le système ajoute le matériel récupéré à la requête du modèle, généralement avec des instructions sur la manière de l'utiliser. La troisième est la génération. Le modèle de langage écrit une réponse en utilisant la question de l'utilisateur, les instructions et le contexte récupéré.

Une réponse RAG peut inclure des références ou des étiquettes de source, mais la provenance n'est utile que si elle est précise. Une référence peut pointer vers un document récupéré mais qui ne soutient pas la phrase exacte. Un passage peut être pertinent pour le sujet mais pas pour la revendication. Un modèle peut également mélanger du texte récupéré avec du langage non soutenu. C'est pourquoi la vérification des sources reste partie intégrante du workflow.

RAG soulève également des questions de sécurité et de gouvernance. Le NIST traite les systèmes d'IA générative comme des systèmes gérés en matière de risques tout au long de leur cycle de vie, et non comme des appels isolés de modèles [3]. Le Top 10 de l'OWASP pour 2025 des applications LLM et d'IA générative met en évidence des risques tels que la divulgation d'informations sensibles, l'agence excessive, les faiblesses des vecteurs et des empreintes, et la désinformation [4]. Son guide sur l'injection de prompt décrit également des attaques indirectes où des instructions malveillantes sont cachées dans du contenu externe que le système d'IA traite [5]. Les documents récupérés sont un endroit où ce risque peut apparaître.

Un développeur devrait tester chaque partie séparément. Les tests de récupération vérifient si les bons passages sont trouvés. Les tests de fondation vérifient si la réponse reste dans ces passages. Les tests de citation vérifient si chaque marqueur de source soutient la phrase à côté de laquelle il apparaît. Les tests de permission vérifient si l'utilisateur était autorisé à récupérer le matériel en premier lieu. Les tests de bout en bout vérifient si l'ensemble du système gère les questions réelles des utilisateurs et les cas d'échec.

Imaginons un assistant de support client pour une entreprise de logiciels. Un client demande : « Puis-je obtenir un remboursement après 45 jours si le produit n’a jamais été activé ? » Le système RAG transforme la question en recherche, récupère des extraits de la politique de remboursement et du guide de dépannage d'activation, puis ajoute ces passages au contexte du modèle.

Le modèle génère ensuite une réponse : « La politique dit que les remboursements sont normalement disponibles dans les 30 jours, mais une activation ratée peut être soumise à un examen. Demandez au client l'erreur d'activation et l'ID de commande. » Une bonne interface afficherait les passages de la politique utilisés pour cette réponse. Un travailleur de support humain devrait toujours vérifier que la politique récupérée est à jour, que le compte client a la bonne date d'achat, et que la réponse ne révèle pas des notes internes.

La plus grande erreur est de penser que RAG élimine les hallucinations. RAG peut réduire certains risques car le modèle dispose de contexte pertinent à exploiter. Il peut également rendre les échecs plus faciles à inspecter car les utilisateurs peuvent consulter les passages récupérés. Mais le système peut tout de même échouer avant la génération, pendant la génération ou après la génération.

Une autre idée fausse est qu'un lien source signifie que la réponse est prouvée. La source récupérée doit réellement soutenir l'affirmation. Si la réponse dit "les remboursements sont autorisés après 45 jours", mais que la source dit "les remboursements sont normalement autorisés dans les 30 jours", la citation n'est pas suffisante.

La défaillance de récupération est le premier risque majeur. Le système peut récupérer une page populaire mais non pertinente, manquer une exception rare ou choisir un fragment qui manque le contexte nécessaire. Les documents obsolètes ou absents constituent un autre risque. Une recherche parfaite sur une politique obsolète produit toujours un fondement obsolète.

Le contrôle d'accès est également central. Un système RAG ne doit pas récupérer des documents de salaire, des dossiers clients, des notes juridiques ou des procédures de sécurité internes pour des utilisateurs qui n'ont pas le droit de les voir. L'injection de commandes dans les documents récupérés est un risque séparé : un document malveillant ou compromis peut contenir des instructions qui tentent de remplacer la tâche du système, de faire fuir des données ou de modifier la réponse. Le RAG a besoin d'une hygiène des documents, de permissions, de surveillance et de revue humaine pour les utilisations à haut risque.

Une autre limitation est l'évaluation. Un démo peut sembler solide avec quelques questions sélectionnées, tandis que le système réel échoue sur des cas limites, des synonymes, des documents longs, des politiques contradictoires ou des informations manquantes. Un système RAG utile a besoin d'exemples de bonnes réponses, de mauvaises récupérations, de cas sans réponse, de documents obsolètes et de limites de permissions. Les équipes devraient également décider comment le produit se comporte lorsqu les résultats de récupération sont faibles, contradictoires ou absents : répondre avec de l'incertitude, poser une question suivante, orienter vers une personne ou refuser de répondre sur la base de preuves faibles.

Avant de faire confiance à une réponse RAG, demandez : Les bons documents ont-ils été récupérés ? Sont-ils à jour ? La réponse est-elle limitée à ce que les sources soutiennent ? Les citations sont-elles associées aux affirmations exactes qu'elles soutiennent ? Un document récupéré pourrait-il contenir des instructions hostiles ? L'utilisateur a-t-il le droit de voir chaque source récupérée ? Que se passe-t-il si la récupération ne trouve rien ?

Pour les brouillons à faible enjeu, une réponse RAG peut être un bon point de départ. Pour les décisions sur les politiques, la sécurité, les clients, les affaires, les finances, la médecine ou l'emploi, exigez une revue des sources et un propriétaire d'approbation clair. RAG réduit certains risques en rapprochant les preuves du modèle, mais ne remplace pas la vérification. Les bons systèmes rendent l'incertitude visible au lieu de la cacher pendant l'utilisation et la revue réelle.