TL;DR
- Un RAG n'apprend pas vos documents, il contextualise la réponse d'un LLM à partir d'eux.
- Il fonctionne selon un principe de structuration de corpus documentaire, indexation de celui-ci et enrichissement du LLM.
- Il est inadapté pour répondre à des questions nécessitant la mise en oeuvre de processus logiques.
- La gestion des données est l'élément clef permettant à un RAG d'être performant.
- Tout au long de son cycle de vie, un RAG nécessite une évaluation permanente.
- La confidentialité et la souveraineté des données sont des facteurs clef qui influencent les choix d'architecture.
- L'intelligence artificielle est très consommatrice de ressources, une mise en place rationnelle est à privilégier.
De quoi parle-t-on réellement ?
Le fonctionnement du Retrieval-Augmented Generation (RAG) se retrouve simplement dans son nom. Il s'agit, en Français, d'une génération de réponse par intelligence artificielle (IA) suite à un enrichissement contextuel.
De manière générale, un Large Language Model (LLM) est un modèle de langage qui génère une réponse à une instruction donnée. Le RAG est une technique consistant à identifier les documents les plus pertinents dans une base de données documentaire afin d'enrichir le contexte du LLM et aider le modèle à générer des réponses plus précises et pertinentes.
Le RAG ne consiste pas à entraîner un modèle de langage, mais à l'assister afin de lui permettre de remplir son objectif de façon plus fiable.
Imaginons que le LLM soit un étudiant lors d'un examen. De base (sans RAG), l'étudiant répond aux questions de l'examen en fonction des connaissances qu'il a mémorisées. Admettons maintenant que l'étudiant ait accès à ses notes pendant l'examen (avec RAG), il a maintenant la possibilité d'apporter une réponse plus précise et pertinente. Cette analogie permet aussi d'apercevoir les composantes essentielles de l'efficacité du RAG : qu'y a-t-il dans les notes ? Comment sont-elles structurées et indexées pour être récupérables ? De quelle manière vont-elles enrichir la réponse ?
Comment ça fonctionne concrètement ?
Du chapitre précédent, nous pouvons déduire les composants essentiels du RAG.
corpus documentaire : dans un premier temps, l'ensemble de la documentation disponible est inventorié et structuré. Dans un second temps, les documents (ou segments de documents) sont vectorisés et indexés dans une base de données vectorielle.
récupération : lorsqu'une requête est soumise, celle-ci est vectorisée et comparée aux vecteurs des documents indexés afin d'identifier les plus proches voisins par comparaison mathématique des vecteurs.
enrichissement : les documents ainsi identifiés sont récupérés et vont servir à enrichir le contexte de la requête envoyée au LLM. Le prompt est aussi affiné afin de donner des instructions précises au LLM sur la manière d'utiliser ces documents ainsi que sur l'utilisation, ou non, de ses autres connaissances.
Ces trois étapes sont les étapes essentielles du RAG. Elles sont elles-mêmes subdivisées en étapes plus précises, mais représentent fidèlement les processus macros derrière le fonctionnement d'un tel système.
Dans quels cas peut-il être déployé ?
Afin que sa mise en place soit pertinente, le déploiement d'un RAG dépend de la préexistence de différents éléments. Certains de ces éléments sont fondamentaux, d'autres sont plus accessoires.
- La nécessité d'une réponse spécifique : le RAG n'a absolument aucune utilité si une réponse générique non adossée à des sources internes spécifiques est suffisante. Il faut que l'intérêt d'une réponse spécifique soit prépondérant pour justifier son déploiement.
- Un corpus volumineux : ce n'est pas une nécessité absolue, mais le RAG prend tout son sens lorsque la masse de documents est importante et que personne ne peut raisonnablement la parcourir à la main.
- L'accessibilité : si les documents ne sont pas accessibles, le RAG ne peut pas les utiliser et sa mise en place ne sera soit pas possible, soit l'accessibilité aux documents doit être traitée au préalable.
- Des questions formulées en langage naturel : par opposition à une recherche par mots-clefs, le RAG est capable de répondre à des questions imprévisibles, même si l'utilisateur ne connaît pas le vocabulaire exact des documents. Pour une recherche par mots-clefs ou via une nomenclature, le RAG perd de son utilité.
- Des recherches non logiques : ce point est prépondérant dans l'échec ou le succès d'un RAG. Il mérite une attention particulière et fait l'objet du chapitre suivant.
- Une tolérance à l'imperfection : c'est le lot commun de toute utilisation d'un LLM, mais il est bon de le rappeler. Les réponses ne seront pas nécessairement toujours parfaites et l'être humain reste au cœur de leur évaluation. Une réponse incomplète, mais sourcée, reste utile, et l'utilisateur conserve son libre arbitre concernant son appréciation et sa capacité à étoffer la réponse à partir des sources. Le RAG doit être perçu et utilisé comme un outil servant à assister un expert et non à le remplacer.
Si un cas d'utilisation se rapproche de l'une ou plusieurs de ces situations, alors le RAG peut être une solution intéressante à déployer. Si ce n'est pas le cas, il est préférable de se tourner vers des solutions différentes, parfois bien plus simples ou pertinentes à mettre en place.
Les limites des recherches logiques
Ce point est crucial pour le succès d'un projet RAG. Il n'a aucune incidence sur le déploiement technique, mais s'avère déterminant dans l'adéquation de l'outil produit au cas d'utilisation souhaité par l'entreprise commanditaire. Il conditionne à lui seul la pertinence de sa mise en place.
Le plus simple pour expliciter le concept est d'analyser des questions types qu'un utilisateur pourrait poser dans le cadre de besoins métiers :
- "En se basant sur les contrats des 6 derniers mois, quel est le chiffre d'affaires total ?"
- "Quelles sont les modalités de prise en charge des congés maternité d'après nos derniers accords RH ?"
- "Quels sont les clients qui ont le plus gros encours ?"
- "Une machine ne démarre pas et l'afficheur indique l'erreur XBC-596, quelle est la cause de ce problème ?"
- "Quel est le référentiel de sécurité incendie le plus récent ?"
- "Dans notre rapport d'activité 2025, quel est le montant de notre passif ?"
- "Extrais-moi la liste des clients qui ont le plus gros encours."
Ce n'est pas forcément évident à déterminer de prime abord, mais un système RAG seul ne pourra pas répondre de façon satisfaisante aux questions 1, 3, 5 et 7. Ces questions nécessitent un traitement des données (la 1 calcule, la 3 et la 5 comparent et la 7 extrait une liste exhaustive). Il y a, dans ces cas, des opérations de traitement des données logiques qui ne peuvent être effectuées par un système RAG.
Le vrai défi se trouve dans la gestion des données
Le modèle de langage, la base vectorielle et le modèle d'embedding (modèle de vectorisation) sont des briques interchangeables, qui seront remplacées plusieurs fois au cours de la vie du projet au fur et à mesure des évolutions technologiques. Le corpus documentaire, lui, est l'actif durable et crucial.
C'est sur cette partie que l'essentiel du travail de mise en place se concentre. Afin de parvenir à un corpus documentaire satisfaisant, plusieurs opérations de traitement des données sont nécessaires afin de les rendre exploitables au sein d'un système RAG.
- L'identification : les documents doivent être identifiés de façon unique, exhaustive et persistante.
- La structuration : les documents doivent être structurés de façon cohérente et homogène.
- Le découpage : un passage trop court perd son contexte, un passage trop long dilue l'information. La bonne granularité de découpage dépend de la structure des documents.
- Les métadonnées : date, auteur, version. Les métadonnées permettent d'étendre les capacités du RAG en lui permettant de prioriser les documents les plus pertinents en fonction de critères définis.
- Les droits d'accès : la vérification des droits d'accès d'un collaborateur sur les documents indexés permet de garantir que seuls les documents autorisés peuvent être récupérés et transmis au contexte du LLM.
- La mise à jour : chaque création, modification ou suppression de document doit être répercutée dans l'index, automatiquement et de façon à toujours disposer d'une base documentaire exacte.
Sans un corpus documentaire de qualité et à jour, le RAG ne peut pas être efficace.
Évaluation, évaluation et évaluation
Je répète ce mot clef trois fois, car l'évaluation est un processus essentiel tout au long du cycle de vie d'un projet RAG. Elle intervient en pré-projet, en validation continue et en cours d'exploitation.
Évaluation pré-projet : pourquoi lancer un projet RAG si celui-ci n'est pas adapté à l'usage qui en sera fait par les équipes internes ? C'est pour répondre à cette question de pertinence qu'un audit de pré-projet est nécessaire. L'idée sous-jacente est d'amener les équipes à réfléchir aux questions qu'elles souhaitent soumettre à l'assistant afin d'évaluer si celui-ci est théoriquement en mesure d'apporter des réponses pertinentes ou si le déploiement d'un RAG n'est pas la solution adaptée aux besoins des équipes.
Évaluation continue : lors du développement du projet, l'adéquation technique du RAG est évaluée à travers trois métriques, la qualité du contexte (Context Precision et Context Recall), la fiabilité de la réponse (Faithfulness) et la pertinence de la réponse (Answer Relevance). En gros : est-ce que le système utilise les bons documents, les utilise sans halluciner et apporte une réponse pertinente ? Cette évaluation doit se faire en continu à chaque modification du système et s'appuie sur un jeu de données de référence (Gold Dataset).
Évaluation d'exploitation : une fois le RAG déployé, il est important de continuer à évaluer sa performance au fil du temps. L'objectif est de détecter rapidement les problèmes techniques (coupure de service) et les problèmes de fiabilité (réponses inexactes) tout en monitorant la structure de coûts. Cette évaluation s'appuie à la fois sur des systèmes de monitoring et sur des métriques, mais aussi par la mise en place de fonctionnalités de collecte de retours des utilisateurs.
Souveraineté, confidentialité et efficience énergétique : des points souvent négligés
Lorsqu'une entreprise est soumise au RGPD, à la LPD, manipule des informations stratégiques sensibles, a un engagement écologique ou a simplement des convictions sur ces sujets, ce point est crucial et doit être pris en compte dès le début du projet, car il va conditionner les choix d'architecture.
En effet, certains modèles et hébergements sont exploités par des plateformes qui ne respectent pas les normes de confidentialité et de souveraineté Européennes ou qui sont soumises à des réglementations litigieuses comme le CLOUD Act. Si vos données doivent conserver un caractère privé, il est important de faire les choix adéquats.
Concernant l'aspect énergétique, il est de notoriété publique que les technologies d'intelligence artificielle sont souvent très consommatrices d'énergie et ont un impact environnemental important. Pour autant, leur utilisation dans un cadre approprié est devenue nécessaire pour un nombre croissant d'entreprises. Une approche responsable consiste ici à opter pour des modèles d'intelligence artificielle dimensionnés en cohérence avec les besoins, à optimiser l'architecture technique et à privilégier des services d'hébergement écoresponsables.
En pratique : avant de lancer un projet RAG, quatre questions suffisent à écarter la plupart des fausses bonnes idées. Dispose-t-on d'un corpus documentaire accessible ? Les réponses aux questions peuvent-elles être apportées sans nécessiter d'es 'opérations logiques ? Les réponses peuvent-elles être imparfaites si elles sont sourcées ? Est-il possible d'évaluer la qualité du système ? Quatre « oui » font un bon candidat. Un seul « non » désigne le chantier à mener en premier.