RAG : donner une mémoire fiable à vos agents IA

Un LLM seul ne connaît que ses données d'entraînement. Il ne sait rien de vos produits, vos clients, vos procédures. Le RAG comble ce trou, à condition de le construire correctement.

Ce qu'est le RAG

RAG signifie Retrieval-Augmented Generation, génération augmentée par récupération. Au lieu de demander au modèle de répondre de mémoire, on récupère d'abord les documents pertinents dans votre base, puis on les fournit au modèle comme contexte. Le modèle répond à partir de faits réels, pas d'hallucinations.

Le pipeline en quatre étapes

1. Ingestion : vos documents (FAQ, docs produit, procédures) sont découpés en morceaux cohérents.
2. Vectorisation : chaque morceau est transformé en vecteur (embedding) qui capture son sens, puis stocké dans une base vectorielle.
3. Récupération : à chaque question, on cherche les morceaux les plus proches sémantiquement.
4. Génération : le modèle reçoit la question plus les morceaux récupérés et formule une réponse ancrée dans vos données.

Là où ça dérape

La plupart des RAG ratés échouent à l'étape du découpage. Des morceaux trop gros noient l'information ; trop petits, ils perdent le contexte. Le bon découpage suit la structure logique du document (par section, pas par nombre de caractères arbitraire).

L'autre piège : ne pas mesurer la qualité de récupération. Si les mauvais morceaux remontent, le modèle répond mal avec assurance. Testez la récupération séparément de la génération.

La sécurité d'un RAG

Un RAG récupère dans vos données internes. Sans contrôle, il peut faire remonter un document confidentiel à un utilisateur qui ne devrait pas le voir. Deux règles :

1. Contrôle d'accès au niveau document : la couche de récupération filtre selon les droits de l'utilisateur avant de fournir quoi que ce soit au modèle.
2. Pas de données sensibles inutiles dans l'index : si un document n'a pas à être interrogeable, il ne va pas dans la base vectorielle.

Les données personnelles méritent une attention particulière. Si l'index contient des renseignements sur des clients ou des employés, une demande de suppression doit aussi effacer les morceaux et vecteurs correspondants, pas seulement le document source. Au Québec, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée avant un projet de système d'information traitant des renseignements personnels, et avant de les communiquer hors du Québec, par exemple vers une API de modèle hébergée ailleurs. Le RGPD et la loi 09-08 au Maroc posent des exigences comparables sur la minimisation et les transferts.

Préparer les documents avant l'ingestion

La qualité d'un RAG se joue avant la première ligne de code. Une base documentaire désordonnée donne un agent désordonné.

1. Faire l'inventaire des sources : FAQ, procédures, fiches produit, conditions générales, tickets résolus.
2. Éliminer les doublons et les versions périmées : deux procédures contradictoires produisent des réponses contradictoires.
3. Désigner un propriétaire par source, chargé de la tenir à jour.
4. Structurer les documents avec des titres clairs : ce sont eux qui guident un bon découpage.
5. Ajouter des métadonnées utiles : date, produit, langue, niveau de confidentialité. Elles servent à filtrer la récupération et à appliquer les droits d'accès.

Mesurer avant de mettre en production

Un RAG se teste en deux couches, séparément.

La récupération. Constituez une liste de questions réelles et notez, pour chacune, le ou les documents qui contiennent la réponse. Vérifiez ensuite que ces documents figurent bien parmi les premiers résultats remontés. Si ce n'est pas le cas, le problème vient du découpage, des embeddings ou des métadonnées, pas du modèle.

La génération. Sur les mêmes questions, vérifiez que la réponse s'appuie uniquement sur les morceaux fournis, qu'elle cite ses sources et qu'elle reconnaît ne pas savoir quand l'information est absente. Une réponse juste mais inventée reste un échec : la prochaine sera fausse.

Relancez ce jeu de tests à chaque modification du découpage, du modèle ou du prompt. C'est le seul moyen de savoir si un changement améliore vraiment les choses.

L'effort de maintenance

Un RAG n'est pas un projet qu'on livre puis qu'on oublie. Il faut réindexer quand les documents changent, idéalement de façon automatique, surveiller les questions restées sans bonne réponse pour combler les lacunes, et revoir périodiquement les droits d'accès. Prévoyez quelques heures par mois pour ce suivi : c'est ce qui sépare un agent qui reste fiable d'un agent qui se dégrade en silence.

Quand utiliser un RAG plutôt qu'un fine-tuning

Le fine-tuning change le comportement du modèle ; le RAG change ce qu'il sait. Pour des connaissances qui évoluent (catalogue, procédures, prix), le RAG gagne : vous mettez à jour la base, pas le modèle. Le fine-tuning sert surtout à ajuster le ton ou un format de sortie spécifique.

Le résultat

Bien construit, un agent RAG répond avec les faits exacts de votre entreprise, cite ses sources, et reste à jour sans réentraînement. C'est la base de tout agent IA fiable en production.

En résumé

1. Le RAG fournit au modèle vos documents au moment de la question : il répond à partir de faits réels plutôt que de mémoire.
2. Le pipeline compte quatre étapes : ingestion, vectorisation, récupération, génération.
3. La plupart des échecs viennent du découpage et d'une récupération jamais mesurée : testez-la séparément de la génération.
4. Le contrôle d'accès au niveau document est indispensable, et les données personnelles de l'index relèvent de la Loi 25, du RGPD ou de la loi 09-08.
5. Pour des connaissances qui évoluent, le RAG est préférable au fine-tuning : on met à jour la base, pas le modèle.

Un audit gratuit de vos systèmes ?

30 minutes. On identifie vos vrais risques. Sans jargon, sans engagement.