RAG en IA : c’est quoi, et comment le construire avec n8n

Le RAG (Retrieval-Augmented Generation, ou génération augmentée par récupération) permet à une IA de répondre avec vos documents : elle repère d’abord les extraits utiles dans une base, puis construit sa réponse avec eux. Pour votre client, c’est un assistant qui répond aux questions de ses employés à partir de ses procédures internes, et qui donne le lien du document source. Voici le résumé de la masterclass de 1 h 30, technique par technique, du RAG classique au graph RAG, avec les changements depuis octobre 2025 et les cas où vous pouvez vous en passer.

1:31:37

RAG en IA : la définition, mot par mot

Le RAG dont il est question ici vient de l’intelligence artificielle (en anglais, « rag » désigne aussi un chiffon, et un morceau de ragtime). Le terme est né dans un article de recherche publié en 2020 par Patrick Lewis et ses coauteurs.

Le RAG est la mémoire à long terme d’un agent IA. Un agent, c’est un prompt, un modèle de langage pour raisonner, une mémoire courte (la conversation en cours) et des outils. Je l’ai détaillé dans l’article sur l’agent IA. Le RAG s’ajoute à cet ensemble : c’est la base de connaissances dans laquelle l’agent va chercher ce qu’il ne sait pas.

Les trois mots du sigle décrivent ce qui se passe quand quelqu’un pose une question :

1. Retrieval (récupération) : la question est transformée en nombres, puis la base renvoie les morceaux de texte les plus proches de cette question.
2. Augmented (augmentée) : ces morceaux sont ajoutés à la question et au prompt de l’agent.
3. Generation (génération) : le modèle de langage rédige la réponse avec tout cela sous les yeux.

Comment fonctionne un RAG : on l’alimente, puis on l’interroge

Un RAG a toujours deux parties. L’alimentation range les documents dans la base. L’utilisation va les y chercher.

Pour l’alimenter, on découpe chaque document en petits morceaux. Chaque morceau passe dans un modèle d’embedding, qui le transforme en une liste de nombres : un vecteur. Les vecteurs sont rangés dans une base de données vectorielle.

Un modèle d’embedding est un modèle à part, conçu pour cet usage : on ne discute pas avec lui, il place les textes de sens proche à des endroits proches. Sur un schéma en trois dimensions, « chien » et « chat » sont voisins. « Apple » est près de « Google » quand on parle de la marque, et près de « orange » et « mangue » quand on parle du fruit. Une vraie base a bien plus de trois dimensions : 1 536 par morceau avec le modèle text-embedding-3-small d’OpenAI, celui de la vidéo.

À l’utilisation, la question passe dans le même modèle d’embedding, et la base renvoie les morceaux dont les vecteurs sont les plus proches. Retenez une règle : le même modèle d’embedding partout, à l’alimentation comme à la question. Sinon, les nombres ne se comparent plus.

Quand utiliser un RAG, et quand vous en passer

Anthropic, l’éditeur de Claude, l’a écrit en septembre 2024 : si votre base de connaissances fait moins de 200 000 tokens, soit environ 500 pages, mettez-la directement dans le prompt, sans RAG. Le cache du prompt évite de payer le plein tarif à chaque appel : la partie qui ne change pas est gardée par le fournisseur et facturée beaucoup moins cher.

J’insiste dans la vidéo sur une condition : que la base ne dépasse jamais ce seuil. Une base qui grossit chaque mois finira dans un RAG de toute façon.

Depuis, les fenêtres de contexte ont grandi. En octobre 2026, les quatre modèles Claude actuels lisent 1 million de tokens, environ 555 000 mots selon Anthropic, et GPT-5.5 en lit 1 050 000. Le RAG reste pourtant utile dans quatre cas :

• La base dépasse ce que le modèle lit. Le Drive d’une PME dépasse vite le millier de pages, et il grossit.
• Le volume de questions coûte cher. Avec Claude Sonnet 5.5, envoyer une base d’un million de tokens coûte 2 $ par question, 0,10 $ quand elle est en cache. Pour 3 000 questions par mois, cela fait au moins 300 $ rien qu’en entrée. Un RAG qui envoie 4 morceaux et la question, environ 2 000 tokens par appel, revient à 12 $.
• Les droits comptent. Tout le monde n’a pas à lire les documents RH. Dans un RAG, chaque morceau porte l’identifiant de son document, et vous filtrez ce que chaque agent a le droit de chercher.
• La qualité baisse avec la longueur. En juillet 2025, l’étude « Context Rot » de Chroma a testé 18 modèles : leurs performances baissent quand l’entrée s’allonge, même sur des tâches très simples.

La règle tient toujours, avec un seuil plus haut. Une base stable de quelques centaines de pages, consultée par une petite équipe, va dans le prompt avec le cache. Une base qui grossit, des droits par service ou des milliers de questions par mois : faites un RAG.

Technique 1 : le RAG classique avec n8n et Supabase

La première version est celle que l’on trouve partout. Je ne la construis pas en direct : je montre chaque brique, je la configure et je la teste. Les deux workflows tournent dans n8n.

L’agent qui interroge la base

Côté utilisation, quatre briques :

• un déclencheur de chat, relié à un nœud AI Agent ;
• le modèle : GPT-4o mini au tournage ;
• la mémoire : Postgres Chat Memory, dans la même base Supabase que le RAG ;
• le RAG : le nœud Supabase Vector Store, branché comme outil de l’agent, réglé pour rendre 4 morceaux avec leurs métadonnées.

Plus vous demandez de morceaux, plus le prompt envoyé au modèle s’allonge, et plus vous consommez de tokens.

Pour le test, le prompt système interdit à l’agent de répondre de mémoire :

Vous êtes un assistant personnel qui aide à répondre aux questions en utilisant une base de documents. Vous devez systématiquement consulter la base de connaissance RAG pour toute question, même si vous pensez connaître la réponse. Ne vous fiez jamais à votre mémoire interne pour fournir des informations. Utilisez exclusivement les documents de la base de documents pour répondre aux questions de l’utilisateur.

La base vectorielle dans Supabase

Supabase est une base Postgres classique, à laquelle l’extension pgvector ajoute les vecteurs, et cela fonctionne très bien. Pinecone et d’autres font le même travail, et n8n a un nœud pour plus d’une dizaine de bases vectorielles.

Le plan gratuit suffit pour commencer : 500 Mo de base et 2 projets actifs. Un projet sans activité pendant une semaine est mis en pause, pas supprimé : on le relance depuis le tableau de bord. Choisissez la région Europe à la création.

La documentation de n8n renvoie vers le script SQL du guide LangChain de Supabase. Collez le premier bloc dans le SQL Editor : il active pgvector, crée la table documents (identifiant, contenu, métadonnées, et une colonne embedding de 1 536 nombres) et la fonction de recherche match_documents. Côté n8n, l’accès demande l’URL du projet et sa clé secrète. Pour la mémoire Postgres, prenez les identifiants du pooler en mode transaction, sur le port 6543 : n8n crée lui-même sa table d’historique au premier message.

Premier test, base vide : « Comment s’appelle mon entreprise ? » L’agent consulte la mémoire, puis la base, et répond qu’il ne trouve pas.

L’alimentation depuis Google Drive, mise à jour comprise

Les documents de test sont quatre procédures internes d’une entreprise fictive, Technosphère Solution, rédigées par Claude : ressources humaines, finances, formation. Le workflow d’alimentation :

1. Deux déclencheurs Google Drive surveillent le dossier RAG toutes les minutes : l’un pour un fichier créé, l’autre pour un fichier modifié.
2. Une boucle (Loop Over Items, lot de 1) traite les fichiers un par un.
3. Un If ne laisse passer que les Google Docs, d’après le type MIME. Pour des PDF, des CSV ou des Google Sheets, remplacez-le par un Switch, avec un traitement par type.
4. Un Edit Fields crée le champ id_fichier : l’identifiant du Google Doc, la longue chaîne visible dans son URL.
5. Un nœud Supabase supprime de la base tous les morceaux dont la métadonnée id_fichier vaut cet identifiant. Activez Always Output Data pour que le workflow continue quand il n’y a rien à supprimer, puis un Limit à 1 pour qu’il ne reparte pas une fois par morceau supprimé.
6. Google Drive télécharge le document au format HTML, Extract from File en sort le texte, et le nœud Markdown le convertit : titres, gras et tableaux restent lisibles par un modèle de langage.
7. Supabase Vector Store, en Insert Documents, range le tout. L’embedding : text-embedding-3-small. Le Default Data Loader ajoute la métadonnée id_fichier, et le Recursive Character Text Splitter coupe tous les 1 000 caractères.

La procédure financière donne 33 morceaux. L’étape 5 est celle que la plupart des tutoriels oublient : un document vit. Je passe sa version de 2.8 à 2.9, le workflow repart, les 33 anciens morceaux disparaissent et les nouveaux prennent les numéros 34 à 66. Sans cette suppression, la base garderait les deux versions, et l’agent mélangerait l’ancienne règle et la nouvelle.

Même question qu’au début : l’agent répond « Technosphère Solution », une information qu’il ne pouvait trouver que dans les documents, et l’on voit les 4 morceaux qu’il a récupérés.

Technique 2 : le chunking intelligent, par section

Le défaut de la première version se voit dans Supabase. Le premier morceau se termine par le titre « Table des matières », et la table elle-même commence le morceau suivant, sans son titre. Le modèle reçoit une liste dont il ne sait pas ce qu’elle est.

Avec 4 documents, cela ne change aucune réponse. Sur des milliers de documents, ces coupures font des erreurs.

La correction : un nœud Code, écrit par Claude, qui coupe au niveau des titres du Markdown et garde chaque section entière, en morceaux de 400 à 1 000 caractères. Le même document donne 49 morceaux, qui commencent presque tous par un titre de section. C’est la seule modification du workflow.

Les méthodes de découpage, leurs réglages et un code prêt à coller sont dans l’article sur le chunking.

Technique 3 : le RAG contextuel d’Anthropic

La troisième version vient du billet « Contextual Retrieval » publié par Anthropic en septembre 2024. Seule l’alimentation change.

Pour chaque morceau, un modèle de langage reçoit le morceau et le document complet, et rédige deux ou trois phrases qui situent le morceau dans le document. Anthropic compte 50 à 100 tokens par contexte. Ce contexte est collé devant le morceau avant l’embedding.

J’ai repris le prompt d’Anthropic, traduit en français :

<document>
{{ document complet }}
</document>
Voici le fragment que nous souhaitons situer dans le contexte du document complet :
<chunk>
{{ morceau }}
</chunk>
Veuillez fournir un contexte court et succinct pour situer ce fragment dans le document global, afin d’améliorer sa récupération lors des recherches. Répondez uniquement avec le contexte succinct, sans rien d’autre.

Dans n8n, une boucle envoie chaque morceau au modèle, puis un Edit Fields colle le contexte et le contenu avant l’insertion. J’ai aussi porté la taille des morceaux de 1 000 à 1 400 caractères, pour laisser la place au contexte. Les 49 morceaux de la procédure financière ressortent avec une phrase en tête, par exemple : « Document de procédure financière interne de Technosphère Solution, section préliminaire présentant la table des matières des processus financiers de l’entreprise. »

Le coût reste bas : le document complet est le même à chaque appel, il passe dans le cache. Anthropic l’estimait à 1,02 $ par million de tokens de documents, une seule fois, à l’alimentation.

Reste à lire correctement les chiffres d’Anthropic. Ils mesurent la part des questions dont le bon morceau n’est pas dans les 20 premiers renvoyés par la base, ce qui est différent du taux de mauvaises réponses :

Le workflow de la vidéo n’a pas de recherche par mots-clés (BM25). Le « 98,1 % de précision » annoncé au début de la vidéo correspond au meilleur cas d’Anthropic, pas à une mesure de ce workflow. Sur 4 documents, la démonstration ne peut pas montrer d’écart : je le dis dans la vidéo, et je m’appuie sur les tests d’Anthropic.

Technique 4 : donner le document entier à l’agent

Jusqu’ici, l’agent n’a qu’une vue des documents : les 4 morceaux que la base lui renvoie. Pour une question qui porte sur tout un document, c’est trop peu. La quatrième version lui donne des outils pour voir l’information autrement : c’est ce qu’on appelle le RAG agentique.

• Une nouvelle table Supabase, fichier_metadata, garde l’identifiant, le titre et l’URL de chaque document.
• Le workflow d’alimentation la remplit juste après la suppression des anciens morceaux, en mode insérer ou mettre à jour : l’identifiant du Google Doc sert de clé.
• L’agent reçoit deux outils Postgres. « Lister les documents » lit cette table. « Lire un document » recolle tous les morceaux d’un document dans l’ordre.

À « Comment faire pour les notes de frais ? », l’agent se contente du RAG. À « Cite-moi ta source », il liste les documents et répond avec le titre de la procédure financière et son lien. Pour un client, c’est souvent ce qui fait accepter l’outil : le salarié vérifie la réponse en un clic.

Technique 5 : le rerank avec Cohere

Le rerank remet de l’ordre dans les morceaux trouvés. La base en renvoie une vingtaine, un modèle de rerank les classe selon leur pertinence pour la question, et seuls les 4 premiers vont à l’agent. Anthropic a retenu 20 morceaux comme le meilleur réglage de ses tests, avec le reranker de Cohere.

Dans n8n :

1. Dans le nœud Supabase Vector Store, activez Rerank Results et montez la limite à 20.
2. Branchez le nœud Reranker Cohere, le seul reranker de n8n aujourd’hui. Modèle : rerank-v3.5, celui par défaut. Top N : 4 (le nœud propose 3 par défaut).
3. Créez un compte sur cohere.com et une clé d’API. La clé d’essai est gratuite et suffit pour tester ; pour la production, il faut une clé de production.

Cohere a sorti depuis les modèles rerank-v4.0 et rerank-v5.0, qui lisent 32 000 tokens ; la v5.0 couvre plus de 100 langues, dont le français. Le nœud de n8n ne propose encore que rerank-v3.5, rerank-english-v3.0 et rerank-multilingual-v3.0.

Technique 6 : le graph RAG, hors du no-code

La dernière technique relie les informations entre elles, un peu comme des neurones. Zep l’a construite avec Graphiti, sa bibliothèque open source : chaque relation entre deux faits porte une date de début et une date de fin de validité. Le graphe sait ce qui était vrai avant, et ce qui l’est maintenant.

Pour le brancher sur n8n, il faut un serveur. Graphiti demande Python 3.10 ou plus et une base de graphes (Neo4j ou FalkorDB). Son serveur MCP, qui le relie à vos outils, est livré comme implémentation de référence, sans authentification, et ses auteurs le déconseillent en production. Cela sort du no-code. Pour la plupart des PME, la technique 5 suffit.

Ce qui a changé depuis le tournage

La vidéo date du 19 octobre 2025. Vérifié en octobre 2026 :

• Les modèles lisent 1 million de tokens : la règle « RAG ou tout dans le prompt » a changé de seuil, et le détail est plus haut.
• Claude 3.5 Haiku, qui rédige les contextes dans la vidéo (via OpenRouter), a été retiré de l’API en février 2026. Anthropic recommande Claude Haiku 4.5 à sa place, et Claude Haiku 5.5 est sorti depuis.
• GPT-4o mini, le modèle de l’agent, quitte l’API d’OpenAI le 14 janvier 2027 : prenez un modèle récent dès maintenant.
• text-embedding-3-small est toujours là, à 0,02 $ le million de tokens. Indexer 500 pages coûte moins d’un centime.
• Le plan gratuit de Supabase n’a pas bougé, et Cohere reste le seul reranker de n8n.

Le reste de la masterclass tient : les deux parties d’un RAG, la suppression des anciens morceaux, le découpage par section, le contexte, le rerank.