On a tous vécu ça. Vous posez une question à ChatGPT sur un process interne ou éléments techniques propre à votre entreprise ou client, et il vous sort une réponse générique qui n'a rien à voir avec votre entreprise. Ou pire : il invente carrément un élément qui n'existe pas. "Selon votre politique RH..." mais il n'a jamais lu votre politique RH.
Le souci, c'est que ces modèles sont figés. Ils ont été entraînés sur des données jusqu'à une certaine date, point barre. Votre documentation Notion, vos contrats, votre wiki Confluence ? Ils n'en savent rien.
C'est là que le RAG entre en jeu. Derrière cet acronyme se cache une idée toute simple : donner à l'IA accès à vos vrais documents avant qu'elle réponde. Et ça change tout.
Le RAG, c'est quoi exactement ?
RAG, pour Retrieval-Augmented Generation signifie en français : "génération augmentée par la récupération". Le terme vient d'un dossier de recherche de Meta AI publié en 2020, et depuis, c'est devenu LA méthode pour rendre les IA plus fiables en entreprise par rapport à des données internes.
Le principe est assez intuitif, imaginez que vous ayez un assistant très doué pour formuler des réponses (dans notre cas c'est notre modèle d'intelligence artificielle générative), mais qui ne connaît pas vos dossiers. Vous lui adjoignez un documentaliste qui, à chaque question, va fouiller dans vos archives pour lui sortir les passages pertinents. L'assistant peut alors répondre en s'appuyant sur du concret.
Dans la pratique, ce fonctionnement peut se transcrire en 4 étapes :
- Le système transforme la question en requête de recherche
- Il va chercher tous les documents les plus pertinents dans votre base
- Il colle ces extraits de documents dans le prompt envoyé au modèle pour lui fournir un contexte riche
- Le modèle génère sa réponse en s'appuyant dessus
Le fonctionnement parait plutôt simple, mais fonctionne très bien, grâce à la nature contextuelle des LLM.
Pourquoi ne pas juste réentraîner le modèle ?
Cette question est légitime. Si on veut que l'IA connaisse nos données, pourquoi ne pas faire du "fine-tuning", c'est-à-dire réentraîner le modèle dessus ?
En un seul mot : coût. On parle de grosses dépenses en matière de matériel pour réentrainer le modèle. Il faut des GPUs, du temps de calcul, des compétences pointues. Et surtout : à chaque fois que vos documents changent, il faut tout recommencer. Votre politique de congés a été mise à jour ? Hop, on relance un entraînement.
Avec le RAG, c'est beaucoup plus souple. Vos docs changent ? Vous mettez à jour la base, et c'est réglé. Pas besoin de toucher au modèle. Beaucoup moins cher, plus simple et plus rapide.
Un autre avantage important du RAG est la traçabilité. Le modèle peut vous dire "j'ai trouvé ça dans tel document, page 12". Avec le fine-tuning, c'est une boîte noire. Le modèle a une base de connaissances, mais impossible de savoir d'où ça vient.
Comment ça fonctionne ?
Un système RAG se construit en deux temps : Il y a tout d'abord une phase de préparation des documents (l'indexation), ensuite on peut répondre aux questions (l'inférence).
Charger les documents
Première étape : ingérer vos documents : PDF, Word, pages web, Markdown, CSV... Les frameworks comme LangChain proposent des loaders pour quasiment tous les formats. Vous pointez vers vos fichiers et LangChain s'occupe d'extraire correctement le contenu.
Découper en morceaux
Là, ça devient intéressant. On ne peut pas nourrir un PDF de 200 pages au modèle. Sa fenêtre de contexte est limitée, et en plus ce serait inefficace. La solution est de découper les documents en petits morceaux qu'on appelle des "chunks".
La taille des chunks est un des éléments clé géré par le RAG. Trop petits, ils perdent le contexte ("Le client peut..." peut quoi ?). Trop grands, on dilue l'information pertinente dans du bruit. En général, ils font 500 à 1000 caractères avec un chevauchement de 100-200 caractères entre les chunks pour ne pas couper en plein milieu d'une idée.
Transformer en vecteurs
C'est là que la magie opère. Chaque chunk est converti en "vecteur" : une série de nombres qui représente le sens du texte. L'idée, c'est que deux phrases qui parlent de la même chose auront des vecteurs proches, même si elles utilisent des mots différents.
"Comment poser des congés" et "procédure pour demander des vacances" vont donner des vecteurs similaires.
Pour faire cette conversion, on utilise des modèles d'embedding. Les plus courants : text-embedding-3 d'OpenAI, Mistral Embed, ou d'autre modèle open source comme Sentence Transformers si vous souhaitez tout garder en local.
Stocker dans une base vectorielle
Pour le stockage de ces vecteurs, il existe des solutions de bases de données vectorielles. Elles sont optimisées pour un type de requête bien précis : "trouve-moi les vecteurs les plus proches de celui-ci".
Les options les plus connues sont :
- pgvector si vous êtes déjà sur PostgreSQL (extension à activer)
- ChromaDB si vous souhaitez une solution légère pour prototyper
- Pinecone si vous voulez du cloud managé
- Milvus pour les gros volumes
La recherche
Quand un utilisateur pose une question, on la transforme aussi en vecteur. Puis on cherche dans la base les chunks dont les vecteurs sont les plus proches. En général, on récupère les 3 à 5 meilleurs résultats.
La génération
Dernière étape : on envoie tout ça au LLM. Le prompt ressemble à quelque chose comme :
Utilise le contexte ci-dessous pour répondre à la question. Si l'information n'est pas dans le contexte, dis-le clairement.
Contexte : [les chunks récupérés]
Question : [la question de l'utilisateur]
Et le modèle fait son travail.
Quelle est la cible des RAG ?
Le RAG est utilisé par un grands nombre d'entreprise, et ça quotidiennement.
DoorDash l'utilise pour son support aux livreurs. Quand un livreur signale un problème, le système va chercher dans la base de connaissances les articles pertinents et les cas similaires déjà résolus. Résultat : des réponses plus précises, moins de temps perdu.
Shopify a créé "Sidekick", un assistant pour les marchands. Il peut répondre sur les stocks, les commandes, les stats de vente parce qu'il a accès aux vraies données de la boutique.
Morgan Stanley l'a déployé pour ses conseillers financiers. Ils peuvent interroger des milliers de rapports de recherche en langage naturel. "Quelles sont les perspectives pour le secteur tech en Asie ?" Et le système va chercher dans les analyses récentes.
Côté interne, les cas d'usage RH sont légion. Les assistants qui répondent aux questions sur les congés, les notes de frais, les process d'onboarding... Le RAG fait gagner énormément de temps aux équipes.
Les limites
Le RAG n'est pas magique. Il y a des cas où ça coince.
Le chunking peut mal se faire. Si vos documents sont mal découpés, le système va récupérer des bouts incomplets ou hors sujet. Il arrive que la réponse à une question soit coupée en deux chunks différents, et le système n'en récupérait qu'un seul. Résultat : une réponse imprécise et/ou partielle.
Le raisonnement multi-documents, c'est dur. Si la réponse nécessite de croiser des infos de plusieurs sources, un RAG classique peut être en difficulté. Il récupère des passages indépendants, il ne "comprend" pas les liens entre eux. Des approches comme GraphRAG essaient de résoudre ça en utilisant des graphes de connaissances, mais c'est plus complexe à mettre en place.
Les hallucinations n'ont pas disparu. Moins fréquentes qu'avec un LLM brut, certes. Mais le modèle peut toujours mal interpréter le contexte ou extrapoler au-delà de ce qui est écrit. Des techniques comme CRAG (Corrective RAG) ajoutent une couche de vérification, mais ça complique l'architecture.
RAG et MCP, c'est quoi la différence ?
Si vous avez lu notre article sur le MCP, vous vous demandez peut-être comment ça s'articule.
Le RAG est une technique (enrichir le contexte avec des documents), le MCP est un protocole (standardiser la connexion entre l'IA et des outils externes).
Les deux sont complémentaires. Un serveur MCP peut très bien exposer une fonctionnalité de recherche RAG. L'utilisateur pose une question, le MCP déclenche la recherche dans la base vectorielle, récupère le contexte, et le transmet au modèle. Chacun son rôle.
Pour conclure
Le RAG a vraiment démocratisé l'IA d'entreprise. Avant, pour avoir un chatbot qui connaisse vos données, il fallait des mois de développement et un budget conséquent. Maintenant, avec les bons outils, vous pouvez monter un prototype en quelques jours.
Est-ce que c'est parfait ? Non. Le chunking reste complexe, les hallucinations existent toujours, et les cas complexes nécessitent des architectures plus sophistiquées. Mais pour 80% des besoins (FAQ interne, support client, recherche documentaire) ça fait le job.
La suite logique, c'est de combiner RAG et agents autonomes. Des systèmes qui ne se contentent pas de répondre, mais qui peuvent agir : créer un ticket, mettre à jour un document, déclencher un workflow.