Qu’est-ce que la Retrieval-Augmented Generation (RAG) ? Un guide en français simple pour les dirigeants

Si vous avez assisté à un pitch d’un fournisseur d’AI au cours de l’année écoulée, vous avez presque certainement entendu le terme RAG. Il est utilisé comme raccourci pour « de l’AI qui connaît les informations de notre entreprise », ce qui est à peu près juste, mais occulte ce qui se passe réellement et pourquoi cela compte pour ce que vous devez attendre du système.

Voici RAG expliqué sans jargon, à l’intention de la personne qui doit décider de financer le projet, pas de celle qui doit le construire.

Le problème que RAG résout

Un grand modèle de langage est entraîné sur une énorme quantité de texte général, mais il ne connaît pas les politiques de votre entreprise, votre catalogue de produits, vos contrats ni les tickets de support de la semaine dernière. On ne peut pas non plus lui faire confiance pour dire « je ne sais pas » — laissé à lui-même, un modèle interrogé sur quelque chose en dehors de son entraînement a tendance à produire une réponse fluide et convaincante, qui peut tout simplement être fausse. Dans un outil interne ou un produit destiné aux clients, c’est un vrai problème.

Réentraîner un modèle sur les documents privés de votre entreprise à chaque changement est lent, coûteux et peu pratique pour des informations qui évoluent tous les jours. RAG résout cela autrement : au lieu d’essayer d’intégrer les connaissances de votre entreprise dans le modèle lui-même, il récupère les informations pertinentes au moment où quelqu’un pose une question, puis transmet ces informations au modèle comme contexte pour sa réponse.

Comment cela fonctionne réellement, en termes simples

Voyez cela comme un processus en deux étapes qui se produit à chaque nouvelle question.

Étape 1 : récupération

Le système parcourt les documents de votre entreprise — politiques, documentation produit, anciens tickets de support, contrats, quelle que soit la source pertinente — pour trouver les éléments de contenu les plus susceptibles de répondre à la question. Cette recherche n’est généralement pas une simple correspondance de mots-clés ; elle utilise en général des « embeddings », une manière de représenter le texte afin que le système puisse trouver un contenu qui veut dire la même chose même s’il n’emploie pas les mêmes mots.

Étape 2 : génération

Les éléments de contenu récupérés sont transmis au modèle de langage avec la question d’origine, et le modèle est invité à répondre en s’appuyant sur ces informations précises. Comme le modèle répond à partir d’un contenu qui vient de lui être fourni plutôt que de sa mémoire, la réponse peut être fondée sur vos documents réels et actuels — et, lorsqu’il est bien conçu, le système peut citer exactement le document utilisé.

C’est toute l’idée : chercher d’abord, puis répondre à partir de ce qui a été trouvé, plutôt que de demander au modèle de répondre uniquement de mémoire.

Pourquoi cela compte plus qu’on pourrait le croire

L’avantage pratique, c’est que les systèmes RAG peuvent rester à jour sans réentraînement. Ajoutez un nouveau document de politique, et la prochaine question à son sujet pourra recevoir une réponse correcte, car la récupération trouvera le nouveau document comme elle en trouve n’importe quel autre. Inutile d’attendre une mise à jour du modèle.

Le deuxième avantage, c’est la confiance. Un système RAG bien conçu peut afficher ses sources — « cette réponse s’appuie sur la section 4.2 de la politique de remboursement » — ce qui permet à un humain de vérifier la réponse au lieu de la croire sur parole. Cette traçabilité fait souvent la différence entre un outil auquel les gens se fient réellement et un outil qu’ils cessent discrètement d’utiliser après une seule erreur.

Ce que RAG n’est pas

RAG n’est pas une garantie contre les mauvaises réponses. Si l’étape de récupération trouve le mauvais document, ou si aucun document pertinent n’existe, le modèle peut tout de même produire une réponse convaincante mais incorrecte, à moins que le système ne soit spécialement conçu pour reconnaître quand il n’a pas assez d’informations et le dire. C’est la qualité de la récupération, pas seulement celle du modèle, qui détermine si le système est fiable.

RAG n’est pas non plus la même chose que le fine-tuning. Le fine-tuning ajuste le modèle lui-même à partir d’exemples d’entraînement, ce qui est utile pour lui apprendre un style cohérent, un format ou un comportement précis pour une tâche donnée. RAG donne au modèle accès à des faits actuels et spécifiques au moment de la réponse. De nombreux systèmes de production utilisent les deux pour des objectifs différents, mais ils répondent à des problèmes distincts et ne sont pas interchangeables.

Enfin, RAG n’est pas simplement « recherche plus chatbot ». Cette formule sous-estime ce dont un système de production a besoin : une récupération tenant compte des permissions pour que chacun ne voie que les documents auxquels il a droit, des évaluations pour savoir à quelle fréquence les réponses sont réellement correctes, et une supervision pour que quelqu’un soit alerté lorsqu’une source de données cesse de se mettre à jour.

À quoi ressemble le “bon” en pratique

Un système RAG de niveau production, tel que nous les concevons dans notre travail RAG et systèmes de connaissance d’entreprise, comprend généralement quelques éléments qu’un proof-of-concept laisse de côté : des contrôles d’accès pour que la récupération respecte les droits de chacun, des citations pour que chaque réponse renvoie à une source réelle, un moyen de mesurer si les réponses sont réellement correctes à partir d’un ensemble réaliste de questions tests, et une supervision pour qu’une connexion de données défaillante soit détectée avant que les utilisateurs ne remarquent des réponses obsolètes.

Rien de tout cela n’apparaît dans une démonstration de cinq minutes, ce qui explique précisément pourquoi tant de pilotes RAG semblent impressionnants puis peinent dès qu’ils sont confrontés à un usage réel et à de vrais cas limites.

Questions utiles à poser à un fournisseur ou à une équipe qui propose RAG

Quelques questions suffisent souvent à distinguer une proposition sérieuse d’un simple habillage de chatbot : que se passe-t-il lorsque le système ne trouve pas de bonne réponse — l’indique-t-il, ou invente-t-il ? Comment mesurerez-vous si les réponses sont réellement exactes, et par rapport à quel jeu de test ? Comment le système gère-t-il des documents qui se contredisent ? Et qui est chargé de repérer lorsqu’une source de données cesse de se synchroniser ?

Si ces questions reçoivent des réponses vagues, considérez-le comme un signal sur le degré réel de maturité de la proposition pour la production.

Un exemple simple de ce à quoi cela ressemble

Imaginez qu’un employé demande à un assistant interne : « Quelle est notre politique concernant les indemnités pour le matériel de télétravail ? » Sans RAG, le modèle dirait soit qu’il ne sait pas, soit, pire, générerait une réponse plausible en se basant sur une connaissance générique de la façon dont les entreprises gèrent habituellement ces indemnités — ce qui peut ne pas correspondre du tout à votre politique réelle.

Avec RAG, le système recherche d’abord dans les documents de politique RH de l’entreprise, trouve la page précise consacrée aux indemnités, transmet ce texte au modèle, puis lui demande de répondre en s’appuyant uniquement sur ce contenu. La réponse peut alors indiquer exactement de quel document de politique et de quelle section elle provient, afin qu’un employé — ou qu’un responsable RH vérifiant le travail du système — puisse le confirmer en quelques secondes. Mettez la politique à jour le trimestre prochain, et la réponse suivante reflétera automatiquement la modification, car la recherche s’appuie sur le document actuel plutôt que sur un modèle entraîné plusieurs mois plus tôt.

Où RAG s’inscrit dans une stratégie AI plus large

RAG est généralement le bon point de départ lorsque le principal enjeu consiste à donner à AI accès aux informations propres à votre organisation, qui évoluent en continu — documentation interne, historique client, bibliothèques de politiques, spécifications produit. Il est moins adapté aux problèmes qui relèvent surtout d’un formatage cohérent ou d’un comportement spécifique à une tâche, où le fine-tuning ou une conception soignée des prompts ont tendance à compter davantage.

Dans la plupart des déploiements réels, on combine les approches : RAG pour ancrer les réponses dans des faits à jour, des garde-fous clairs pour définir ce que le système peut et ne peut pas faire, et une validation humaine pour tout ce qui comporte de vraies conséquences.

Commencer

Le premier pas le plus utile n’est généralement pas un vaste brief du type « construisez-nous un système RAG ». Il s’agit plutôt de choisir un cas d’usage étroit mais à forte valeur — un seul service, un seul ensemble de documents, un seul type de question clair — et de prouver la qualité de la recherche sur ce périmètre avant d’élargir. Cette approche met en lumière très tôt les véritables moteurs de coût et de complexité, au lieu de les découvrir après un déploiement à l’échelle de l’entreprise.

Si vous évaluez un projet RAG et souhaitez un second avis sur le périmètre avant d’engager un budget, le Planificateur de projet ASTACKRA est un moyen rapide de décrire vos sources de données et d’obtenir une lecture cadrée de ce qu’exigerait réellement une version prête pour la production.