Agentic RAG dans n8n : pourquoi le RAG classique échoue souvent – et comment faire mieux

Beaucoup d’entreprises misent aujourd’hui sur des assistants IA censés répondre à des questions portant sur leurs propres documents – comptes rendus de réunion, tableaux d’indicateurs ou retours clients. Le procédé courant derrière cela s’appelle Retrieval Augmented Generation (RAG). Il est répandu, bien pris en charge et rapidement mis en œuvre dans des outils no-code comme n8n. Seulement voilà : dans la pratique, le RAG classique livre étonnamment souvent des réponses fausses ou incomplètes. Dans sa vidéo, Cole Medin montre d’où cela vient et comment un montage dit Agentic RAG contourne les faiblesses typiques. Nous en résumons sobrement les points essentiels.

Pourquoi le RAG classique déçoit dans la pratique

Le RAG fonctionne par recherche de similarité : la requête est comparée à des morceaux de texte stockés (« chunks »), et les plus pertinents sont transmis au modèle de langue. Le problème, c’est la sélection. Elle passe régulièrement à côté d’un contexte important.

Medin cite deux faiblesses concrètes :

• Aucune vue sur les documents entiers : le RAG ne mobilise que des extraits isolés. Qui veut analyser des tendances dans un tableau n’obtient peut-être qu’un quart des lignes – et donc un résultat faux.
• Pas de véritable analyse de données : des sommes ou des valeurs maximales sur un tableau ne se calculent pas de façon fiable avec une simple recherche textuelle.

S’y ajoute une contrariété pratique : lorsqu’on demande le compte rendu d’une date précise, le RAG remonte parfois le document du mauvais jour – alors même que la date figure dans le titre. Et relier différents documents entre eux pour établir un contexte plus large réussit rarement.

Ce que l’Agentic RAG fait différemment

L’idée de fond est simple : au lieu de ne donner à l’agent IA qu’un unique outil de recherche, il en reçoit plusieurs – et peut décider lui-même comment explorer la base de connaissances. Medin définit l’Agentic RAG ainsi :

L’Agentic RAG consiste à donner à l’agent la capacité de réfléchir à la manière dont il interroge la base de connaissances – au lieu de le clouer à un seul outil.

Concrètement, l’agent peut ainsi améliorer ses requêtes de recherche, choisir au besoin un autre outil et essayer plusieurs voies jusqu’à obtenir une réponse solide. Si la seule recherche RAG échoue, il n’est plus bloqué.

Les quatre outils de l’agent

Dans le workflow n8n, l’agent dispose des outils suivants :

• Recherche RAG – la recherche de similarité classique, dans sa version améliorée avec indication de la source.
• Lister les documents – l’agent récupère tous les documents avec leurs titres et leurs ID et réfléchit à ceux qui pourraient être pertinents.
• Récupérer le contenu d’un fichier – via l’ID du fichier, il obtient le texte complet d’un document donné (par exemple le compte rendu du 23 février, reconnaissable au titre).
• Requête SQL sur des tableaux – les fichiers CSV et Excel sont interrogés comme des tables SQL, afin de permettre sommes, maxima et évaluations similaires.

Dans le prompt système, l’agent est invité à commencer par le RAG et à ne se rabattre sur les autres outils que si la recherche ne donne pas ce qu’il faut. Une remarque importante tirée de la vidéo : demander explicitement à l’agent d’être honnête – c’est-à-dire de dire ouvertement lorsqu’aucune réponse n’a été trouvée – réduit sensiblement les hallucinations.

Comment les données tabulaires sont stockées

La partie techniquement la plus intéressante concerne les tableaux. Trois tables sont créées à cette fin dans Supabase :

• documents – contient les embeddings pour le RAG, les métadonnées et le contenu des différents chunks.
• document_metadata – stocke les informations de niveau supérieur : titres, URL pour les indications de source et – pour les tableaux – le schéma (c’est-à-dire les noms de colonnes).
• document_rows – conserve les lignes des tableaux. Les données proprement dites atterrissent dans une colonne JSONB flexible nommée row_data.

L’astuce : grâce à JSONB, on peut stocker des structures de colonnes quelconques sans devoir créer une table SQL propre à chaque fichier CSV ou Excel. L’agent lit d’abord le schéma dans les métadonnées, comprend les colonnes disponibles, puis formule une requête SQL sur row_data. Medin souligne expressément que ce montage est simplifié – le schéma ne dit par exemple rien des types de données, si bien qu’une somme sur une colonne comportant un symbole dollar peut échouer. Ce qui l’intéresse, c’est le concept, pas une mise en œuvre parfaite.

Le pipeline RAG : de Google Drive vers Supabase

Avant que l’agent puisse travailler, la base de connaissances doit être remplie. Le pipeline se déroule en plusieurs étapes :

• Déclencheur : un déclencheur Google Drive vérifie chaque minute la présence de fichiers nouveaux ou modifiés. Dropbox ou un déclencheur de fichier local fonctionnent aussi. Les fichiers supprimés ne sont toutefois pas détectés.
• Plusieurs fichiers à la fois : une boucle nouvellement ajoutée traite désormais aussi plusieurs fichiers arrivant dans le même intervalle de polling – une lacune connue de la version précédente.
• Supprimer les anciennes données : avant chaque import, les entrées existantes rattachées à l’ID du fichier concerné sont supprimées. Ainsi, aucun chunk obsolète ne subsiste lorsqu’un document a été raccourci.
• Extraire le contenu : un nœud Switch aiguille selon le type de fichier – PDF, Google Doc, texte ou tableau sont lus différemment. D’autres formats comme JSON ou HTML peuvent être ajoutés via des nœuds supplémentaires.
• Stocker les tableaux en double : les fichiers CSV sont d’une part préparés comme document texte pour le RAG, d’autre part enregistrés ligne par ligne dans document_rows pour les requêtes SQL.

Un écueil pratique lors de la mise en place : pour la connexion Postgres vers Supabase, il faut utiliser, selon la vidéo, le Transaction-Pooler (port 6543), et non la connexion directe. La documentation de n8n serait peu claire sur ce point.

Modèles utilisés

Pour les embeddings, c’est text-embedding-3 d’OpenAI qui est employé, et comme modèle de langue GPT-4o mini – choisi délibérément pour son coût faible et sa rapidité. Pour des cas plus exigeants, Medin recommande des modèles plus performants comme GPT-4o ou Claude Sonnet 4. Important : lors de l’insertion et lors de la récupération, le même modèle d’embedding avec le même nombre de dimensions doit être utilisé.

Trois exemples tirés de la vidéo

Medin montre comment l’agent choisit différents outils selon la question :

• Question sur un tableau : à « Quel mois avons-nous eu le plus de nouveaux clients ? », l’agent écrit une requête SQL et fournit le résultat correct (décembre, 129 nouveaux clients) – au lieu de s’en remettre à des chunks incomplets.
• Question purement RAG : à « Où pouvons-nous nous améliorer ? », la recherche de similarité trouve le document de retours clients, bien que le mot « amélioration » n’ait volontairement pas été utilisé.
• Récupération de fichier avec source : lors de la récupération d’un compte rendu de réunion complet, l’agent livre les action items et, sur demande, un lien cliquable vers la source.

Conclusion

L’article montre sobrement pourquoi un RAG naïf ne suffit pas pour beaucoup d’applications métier : il passe à côté du contexte et ne sait pas calculer sur des tableaux. L’approche agentique résout cela de façon pragmatique, en donnant à l’agent IA plusieurs outils et une marge de décision. Pour les décideurs de PME qui envisagent un assistant documentaire, c’est un enseignement important : la qualité ne tient pas au seul modèle, mais à l’architecture qui le porte. Qui reprend le montage n8n présenté devrait le considérer comme un point de départ – prompts, outils et modèle de données sont à adapter à ses propres données. La requête SQL sur les tableaux et le traitement des types de données offrent en particulier une marge d’amélioration.

Source : Cole Medin – « I Built the ULTIMATE n8n RAG AI Agent Template », https://www.youtube.com/watch?v=mQt1hOjBH9o