Retrieval Augmented Generation (RAG) aide les grands modèles de langage (LLM) à produire des réponses plus précises et fidèles en récupérant activement des informations de sources externes avant de générer une réponse. Il fonde les sorties sur les données actuelles, réduisant ainsi les hallucinations dues à la connaissance interne du modèle. Bien que le RAG améliore la fiabilité, des erreurs peuvent encore se produire si le modèle interprète mal les informations extraites, rencontre des contextes contradictoires ou néglige des détails importants.
Pour les applications d'entreprise, les LLM doivent comprendre le contexte commercial, y compris les feuilles de route des produits, l'historique des clients et les politiques internes. RAG fait le lien entre les connaissances générales du modèle et les données organisationnelles exclusives afin de fournir des informations factuelles et spécifiques au contexte. Pour protéger les informations sensibles, le pipeline d'extraction doit être sécurisé par des contrôles d'identité vérifiables, de sorte que seuls les utilisateurs autorisés ou les agents d'IA puissent accéder aux données de l'entreprise.
Fonctionnement de la génération augmentée par récupération (RAG)
Les systèmes RAG interrogent des sources de connaissances externes, telles que des bases de données internes ou des entrepôts de données vectorielles, afin de fournir un contexte factuel pour les résultats de la gestion du cycle de vie. Les documents sont transformés en encastrements denses ou épars, ce qui permet une recherche sémantique et une extraction hybride combinant l'évaluation de la pertinence et les correspondances exactes. Les informations pertinentes les mieux classées sont introduites dans la fenêtre contextuelle du modèle, ce qui réduit la tendance du LLM à confabuler tout en soutenant les cas d'usage de l'entreprise qui requièrent des données précises et privées.
À un niveau élevé, le RAG se déroule en deux étapes. Tout d'abord, il permet d'ancrer les résultats du LLM dans le contexte factuel actuel, en réduisant les limites de la coupure des connaissances et en permettant un accès sécurisé et en temps réel aux données propriétaires de l'entreprise.
Phase 1 : définitions de base et recherche
Lorsqu'un utilisateur introduit une question, le système RAG recherche d'abord des sources de données externes. Les bases de données vectorielles servent généralement de couche de stockage, abritant des représentations mathématiques de documents appelées "embeddings". L'indexation multidimensionnelle permet au système de rechercher une signification sémantique ou d'utiliser une recherche hybride, combinant la pertinence sémantique et la correspondance exacte des mots-clés. L'évaluation de la similarité identifie les morceaux d'information ou les enregistrements évalués par des métriques de similarité telles que la similarité en cosinus, le produit intérieur ou la distance euclidienne. Il les classe afin d'identifier les candidats les mieux notés et les plus pertinents par rapport à la requête.
Les sources de récupération incluent :
- Documentation interne et wikis contenant les procédures essentielles de l'entreprise
- Les tickets de support client qui montrent comment les problèmes techniques ont été résolus dans le passé
- Données en temps réel provenant d'API, y compris les standards émergents tels que le protocole de contexte de modèle (MCP) ou les appels de fonctions dynamiques à des bases de données en temps réel
- Manuels techniques et spécifications des produits indexés pour la recherche sémantique
Phase 2 : le processus d'augmentation
Les informations récupérées sont reclassées pour donner la priorité aux extraits de code les plus importants avant d'être ajoutées à l'invite en tant qu'entrée contextuelle. L'invite augmentée est ensuite transmise au LLM dans sa fenêtre de contexte. Le modèle génère une réponse basée à la fois sur ses données d'apprentissage et sur le contexte récupéré. En se référant au matériel source pendant la génération, les réponses sont plus fondées, ce qui rend RAG adapté aux cas d'usage critiques où les suppositions probabilistes ne sont pas acceptables.
L’écart émergent des autorisations
La sécurité devient critique lors de l'étape de récupération. Les agents d'IA accèdent souvent à des sources de données contenant des informations sensibles sur les clients ou des données commerciales exclusives. Les implémentations traditionnelles de RAG négligent souvent une question cruciale : Comment confirmer que l'agent ne récupère que les données que l'utilisateur demandeur est autorisé à voir ?
L'autorisation à granularité fine (FGA) comble ces lacunes en matière de contrôle, entraînant une adoption accrue des systèmes RAG d'entreprise. Différents utilisateurs peuvent poser des questions similaires mais nécessiter l'accès à des ensembles de données différents. Si un employé junior pose une question sur la rémunération des cadres et que le système RAG récupère une feuille de calcul confidentielle, cela entraîne une grave exposition de données. En l'absence de contrôles d'autorisation dynamiques adéquats, les systèmes RAG risquent de divulguer des données sensibles. Les fuites de données à grande échelle peuvent se produire via l'injection indirecte de messages (IPI), un terme émergent souvent regroupé avec les attaques générales par injection de messages, où des instructions malveillantes sont intégrées dans les documents récupérés ou d'autres formes de manipulation non autorisée du contexte.
Le défi majeur que représente le RAG en matière de sécurité
En déployant les RAG, les organisations introduisent une nouvelle catégorie d'identité non humaine : l'agent d'IA. Ces agents agissent au nom des utilisateurs ou fonctionnent de manière autonome pour traiter les informations. Les agents d'IA posent des problèmes de sécurité que les systèmes traditionnels de gestion de l'identité n'ont pas été conçus pour gérer à grande échelle. Les organisations passent de la gestion de l'accès humain à la gestion de l'accès des travailleurs numériques et des services qui leur sont associés.
Le problème de l'identité de l'agent
Les agents d’IA ne s’intègrent pas aisément aux frameworks d’identité hérités. Ce ne sont pas des utilisateurs humains avec des mots de passe, mais ils sont également plus complexes que les intégrations API traditionnelles. Les agents peuvent prendre des décisions autonomes, opérer sur plusieurs systèmes, exécuter des tâches en continu et traiter des données sensibles telles que les informations personnelles et la propriété intellectuelle.
Les clés API à longue durée de vie ou les comptes de service statiques introduisent un risque car ils accordent un accès large et permanent. Si un agent subit une compromission, les attaquants peuvent se déplacer latéralement et exfiltrer des données sans restriction. Les architectures modernes atténuent ce risque en utilisant des tokens éphémères et la fédération des identités de charge de travail (WIF), fournissant un accès vérifiable et de courte durée sans secrets partagés.
Le problème de l'IA fantôme
Sans contrôles d'identité solides, les organisations risquent l'IA fantôme, qui apparaît lorsque des agents d'IA sont créés et déployés sans visibilité centralisée ni supervision de la sécurité. Les développeurs peuvent facilement créer des pipelines RAG en dehors des environnements approuvés, parfois en les connectant directement aux sources de données de production. L'IA fantôme augmente le risque organisationnel en créant des surfaces d'attaque cachées et en contournant les protocoles de prévention des pertes de données.
Sécuriser RAG : les fondements de l'identité
La sécurité des RAG ne doit pas être négligée. Les organisations ont besoin d'une approche sécurisée dès la conception, où l'identité sert de plan de contrôle pour l'accès à l'IA. Chaque agent et chaque demande de données doivent être authentifiés et autorisés.
1. Sécurisation de l'accès aux données pour les agents grâce à une autorisation centralisée d'accès inter-applications
Les agents d'IA ont besoin d'une authentification solide de machine à machine (M2M). Les modèles d'autorisation M2M centralisent les décisions d'accès par le biais d'une couche de contrôle d'identité partagée. L'application centralisée des politiques fonctionne avec des magasins de vecteurs fragmentés et des API héritées.
Les stratégies clés sont les suivantes :
- Zéro privilège permanent (ZSP) : Un modèle d'accès juste à temps (JIT) qui accorde des autorisations uniquement pour la durée d'une tâche, puis les révoque immédiatement après. JIT minimise le rayon d'action d'un agent compromis et aide à prévenir l'élévation des privilèges.
- Limites d’accès ciblées : Les agents sont limités aux seules ressources nécessaires à leur fonction actuelle, appliquant ainsi le principe du moindre privilège (PoLP) au niveau de l’API et des lignes de données.
- Autorisation déléguée : En utilisant l'autorisation "on-behalf-of", le système propage les identités pour restreindre l'accès aux données à l'intersection des autorisations de l'agent et de l'utilisateur. Cette double contrainte permet d'éviter efficacement les attaques de type "député confus".
2. Audit et traçabilité
Les actions de l’agent doivent pouvoir être retracées jusqu’à un être humain ou un système initiateur. La traçabilité repose sur des journaux d’audit détaillés qui indiquent quel utilisateur a lancé une action et quelles sources de données ont été consultées lors de la recherche. Dans les secteurs réglementés, des pistes d'audit détaillées facilitent la mise en conformité et les enquêtes sur les incidents. Les organisations ont de plus en plus besoin de pouvoir prouver quels vecteurs spécifiques "morceaux de contexte" l'IA a utilisés pour générer sa réponse afin de maintenir une chaîne de contrôle de l'information.
3. L’humain dans la boucle pour des actions à haute importance
Toutes les actions d’un agent ne doivent pas être exécutées automatiquement. Pour les opérations impliquant des données sensibles ou un impact financier, les systèmes RAG bénéficient d’étapes explicites d’approbation humaine, mises en œuvre par des flux de travail d’autorisation asynchrones ou progressifs. L’agent interrompt l’exécution jusqu’à ce qu’un réviseur humain autorise l’action, afin que les humains conservent le contrôle des décisions risquées.
Le rôle de l’autorisation à granularité fine (FGA)
Pour sécuriser le RAG à grande échelle, les organisations vont souvent au-delà du contrôle d’accès basé sur les rôles (RBAC) à granularité grossière. FGA permet de prendre des décisions d’accès au niveau de l’objet ou de la relation, ce qui est particulièrement important lorsque les bases de données vectorielles indexent des données provenant de plusieurs sources avec des autorisations différentes des systèmes sources.
Pourquoi l'AGF est-elle une bonne pratique émergente pour le GCR ?
Lors de la récupération, le système RAG peut interroger un service d'autorisation en temps réel afin de déterminer si un utilisateur est autorisé à accéder à un fragment de document spécifique. Le contenu non autorisé est exclu de l'ensemble des candidats avant qu'il n'entre dans la fenêtre de contexte du modèle. Les requêtes d'autorisation en temps réel garantissent que les documents récupérés respectent les contrôles des accès existants au moment de la requête, plutôt que de s'appuyer sur un filtrage statique.
L'autorisation en temps réel est prise en charge :
- ReBAC : Octroi d'un accès en fonction de la possession d'un fichier par un utilisateur ou de son appartenance à une équipe de projet spécifique définie dans un graphe orienté d'autorisations.
- Permissions dynamiques : résillier l'accès instantanément sans avoir à réembarquer ou à réindexer l'ensemble de la base de données vectorielles.
- Granularité : Protéger les données au niveau du paragraphe ou de l'enregistrement plutôt que de verrouiller des fichiers entiers, ce qui maximise l'utilité du LLM tout en préservant l'intégrité des limites des données.
Plan de contrôle d'identité unifié
Les projets RAG peuvent rencontrer des difficultés en production en raison de la complexité de la gouvernance des données plutôt que de la performance du modèle. Les organisations qui accordent la priorité à l'identité dès le premier jour peuvent évoluer plus facilement. La gestion de l'identité des agents sur plusieurs plateformes déconnectées augmente le risque opérationnel. Un plan de contrôle unifié de l'identité centralise la visibilité, simplifie l'application des politiques et réduit le besoin d'une logique d'autorisation personnalisée. En traitant les agents d'IA comme des identités de premier ordre, les organisations peuvent faire évoluer RAG sans introduire de voies d'accès persistantes et sur-privilégiées, et permettre la non-répudiation de toutes les transactions effectuées par les agents.
Foire aux questions (FAQ)
Quelle est la différence entre le RAG et le réglage fin ?
Le RAG tire des informations externes au moment de l'interrogation afin de fonder les réponses sur les données actuelles. Le réglage fin permet de réentraîner le modèle sur des ensembles de données spécifiques afin d'ajuster les poids internes et le comportement. Le système RAG est idéal pour les connaissances qui évoluent fréquemment et pour maintenir des limites strictes d'accès aux données que le réglage fin ne peut pas imposer.
Qu'est-ce qu'une base de données vectorielle dans RAG ?
Une base de données vectorielle stocke les données sous forme de plongements mathématiques qui capturent la signification sémantique. Dans un système RAG, les documents sont convertis en vecteurs. Lorsqu'une requête est soumise, le système trouve les vecteurs les plus proches en utilisant des métriques de similarité, telles que la similarité cosinus. La pertinence marginale maximale (MMR) est une technique de reclassement et de diversité, et non une métrique de similarité primaire. Le MMR confirme ensuite l'exactitude et la diversité contextuelle, donnant au LLM un ensemble de preuves représentatif et non redondant. Il en résulte une recherche axée sur l'intention qui surpasse la recherche traditionnelle par mots-clés.
Comment le RAG réduit-il les hallucinations chez les LLM ?
RAG réduit les hallucinations paramétriques en fournissant au modèle un contexte récupéré. Le modèle fonde sa réponse sur des données factuelles plutôt que sur des modèles probabilistes appris. Vous pouvez demander au système de privilégier le contexte retrouvé et indiquer si l'information n'est pas disponible, en faisant passer le modèle d'une tâche générative à une tâche discriminative utilisant les preuves fournies.
Quels sont les principaux défis de sécurité liés à RAG ?
Le principal défi consiste à contrôler l'accès lors de l'étape de récupération. Les agents d'IA peuvent interroger des données sensibles, c'est pourquoi les contrôles d'autorisation sont essentiels. Parmi les autres risques, citons les agents Shadow IA non gérés et l'utilisation de clés API non sécurisées et à longue durée de vie. La mise en œuvre de contrôles des accès précis et d'un audit continu permet d'atténuer ces risques tout en protégeant contre les attaques par injection rapide ciblant la logique d'extraction.
Le système RAG peut-il fonctionner avec des données structurées ?
Oui, RAG peut fonctionner avec du texte non structuré et des données structurées. Dans un RAG structuré (souvent appelé « Text-to-SQL » ou « Table-RAG », dénomination alternative ; non standardisée), le système peut utiliser la cartographie sémantique pour générer une requête SQL afin d'extraire des enregistrements spécifiques d'un data warehouse. Les résultats des requêtes sont convertis en langage naturel pour être traités par le LLM ; cependant, cela nécessite des requêtes paramétrées et des couches de validation supplémentaires afin d'empêcher l'exfiltration de données non autorisées ou les injections SQL. L'injection SQL est un risque lié à la génération de requêtes non sécurisées et n'est pas inhérente à la RAG.
Déployer l'IA sécurisée avec l'identité
Le passage de RAG à la production implique plus qu'une simple ingénierie des invites. Il s’agit de traiter l’identité comme un contrôle de sécurité fondamental. Les garde-fous doivent être appliqués par le biais de l’authentification, de l’autorisation et de la journalisation des audits.
La plateforme Okta fournit une couche d'identité unifiée pour aider les organisations à construire des agents d'IA sécurisés dès leur conception. En régissant les identités humaines et non humaines par le biais d'un plan de contrôle unique, les organisations obtiennent la visibilité et le contrôle nécessaires pour prévenir les fuites de données, gérer l'IA fantôme et libérer toute la valeur commerciale de la RAG.
