Construire un RAG avec n8n : les connaissances de l'entreprise en chatbot, étape par étape

Retrieval-Augmented Generation (RAG) relie un modèle de langage aux documents propres de l'entreprise, afin qu'un chatbot fournisse des réponses basées sur des connaissances internes réelles plutôt que sur les seules connaissances générales issues de l'entraînement du modèle. Dans n8n, vous construisez en pratique un système RAG sous la forme de deux workflows distincts : le premier workflow charge les documents, les découpe en sections de texte, les convertit en vecteurs via un modèle d'embedding et les stocke dans un nœud Vector Store. Le second workflow relie ce Vector Store via un nœud AI Agent en tant qu'outil consultable, de sorte que le chatbot recherche lui-même les passages de texte pertinents à chaque requête et les intègre dans sa réponse. État : juillet 2026.

De quels éléments un workflow RAG dans n8n a-t-il besoin ?

Selon la documentation de n8n, un workflow RAG dans n8n se compose de quatre éléments interconnectés : Document Loader, Text Splitter, Embeddings et Vector Store avec Retriever. Le Document Loader récupère les données sources externes, par exemple depuis un fichier, un webhook ou une requête de base de données. Le Text Splitter découpe les documents longs en sections plus petites, appelées chunks, afin que le modèle d'embedding puisse les traiter de manière pertinente. Les Embeddings convertissent le texte en vecteurs, c'est-à-dire en représentations numériques du sens, sachant que n8n, selon la documentation, ne prend en charge que les embeddings de texte. Enfin, le Retriever récupère, pour une requête donnée, les vecteurs correspondants dans la base de données et les retraduit en texte exploitable. Les détails de ces composants sont décrits dans la documentation officielle à l'adresse Store and search data with vectors.

Comment construire le premier workflow pour charger des documents dans le Vector Store ?

Pour l'ingestion, vous ajoutez un nœud Vector Store avec l'opération "Insert Documents", vous connectez un modèle d'embedding et vous ajoutez un nœud Default Data Loader pour le découpage en chunks.

• Taille des chunks : La documentation de n8n recommande des sections de 200 à 500 tokens pour une recherche fine, complétées par un certain chevauchement entre les chunks afin de ne pas perdre le contexte aux limites.
• Choix du splitter : Vous avez le choix entre le Character Text Splitter, qui découpe selon la longueur des caractères, le Token Text Splitter, qui découpe selon le nombre de tokens, et le Recursive Character Text Splitter, que n8n recommande pour la plupart des cas d'usage car il s'appuie sur les structures Markdown, HTML ou de code.
• Métadonnées : Il est possible d'enrichir les chunks avec des informations supplémentaires telles que la source, le type de document ou la date, ce qui facilite le filtrage ultérieur.
• Clear Store : Une option du mode insertion permettant de vider le stockage existant avant de le remplir à nouveau.

Pour des tests rapides, le nœud Simple Vector Store (In-Memory) convient, car il conserve les vecteurs directement dans la mémoire de travail de n8n. Selon la documentation officielle du nœud ce nœud est explicitement destiné uniquement au développement.

Comment rendre le Vector Store consultable pour un chatbot IA ?

Pour la récupération, vous connectez le même nœud Vector Store en mode "Retrieve Documents (As Tool for AI Agent)" à un nœud AI Agent, qui déclenche alors lui-même la recherche lorsqu'il en a besoin pour une réponse. Dans ce mode, vous configurez le Name et la Description de l'outil afin que l'agent comprenne quand y accéder, ainsi qu'une limite pour le nombre de chunks renvoyés et, en option, "Include Metadata" pour fournir les références des sources. Selon la documentation, il est important d'utiliser le même modèle d'embedding pour l'interrogation que pour l'insertion des données, sinon les espaces vectoriels ne correspondent pas et la recherche donne de mauvais résultats. Il existe aussi la requête directe via l'opération "Get Many", où vous définissez vous-même une requête de recherche fixe au lieu de la laisser à l'agent. Le déroulement exact est décrit dans Retrieve relevant context décrit. Celles et ceux qui ne souhaitent pas maintenir eux-mêmes cette configuration trouveront, dans le service Agents IA de NordFlux, une mise en œuvre à prix fixe et avec souveraineté des données allemande.

Quelles sont les limites du RAG avec n8n ?

Le RAG n'est pas une solution miracle : la qualité des réponses dépend directement de la structure des documents sources, et le Simple Vector Store intégré à n8n est, selon la documentation, explicitement destiné uniquement au développement, car les données sont perdues lors d'un redémarrage et, selon la documentation, sont visibles pour tous les utilisateurs à l'échelle de l'instance, indépendamment des autorisations du workflow concerné. Pour une utilisation en production, vous avez donc besoin d'un Vector Store externe persistant, pour lequel n8n propose ses propres nœuds, par exemple pour PGVector ou Azure AI Search. Des documents sources mal structurés, comme des PDF scannés sans véritable couche de texte ou de grands tableaux confus, entraînent un découpage inadapté des chunks et donc des réponses imprécises ou incomplètes du chatbot. Des données sources propres et bien structurées sont souvent plus importantes pour la qualité des résultats que le choix d'un modèle d'embedding plus grand.

Questions fréquentes sur le RAG avec n8n

Quelle est la différence entre le Vector Store en tant qu'outil et la requête directe via Get Many ?

Avec "Get Many", vous soumettez au Vector Store une requête de recherche fixe et prédéfinie, tandis que le mode "Retrieve Documents (As Tool for AI Agent)" laisse la décision à l'agent. L'agent vérifie lui-même, à partir du Name et de la Description de l'outil, si et quand une recherche dans le Vector Store est pertinente pour la question actuelle de l'utilisateur. Cela rend la configuration plus flexible pour un chatbot qui doit aussi répondre à des questions générales sans lien avec les documents.

Quel modèle d'embedding choisir pour un chatbot de connaissances d'entreprise ?

Selon la documentation de n8n, les modèles d'embedding plus petits sont plus rapides et moins coûteux et conviennent aux documents généraux, tandis que les modèles plus grands offrent une meilleure compréhension sémantique pour des sujets spécialisés complexes. Dans tous les cas, il est essentiel d'utiliser le même modèle lors de l'insertion des données et lors de l'interrogation ultérieure, car des modèles différents génèrent des espaces vectoriels différents.

Peut-on utiliser le Simple Vector Store de n8n en production ?

Non, selon la documentation de n8n, le nœud Simple Vector Store (In-Memory) est explicitement destiné uniquement au développement, car les données sont perdues lors d'un redémarrage de l'instance et, selon la documentation, sont visibles pour tous les utilisateurs à l'échelle de l'instance. Pour un chatbot de connaissances d'entreprise utilisé en production, vous avez besoin d'un Vector Store persistant et hébergé en externe.

Quelle doit être la taille des sections de texte pour la recherche ?

Pour une recherche fine, la documentation de n8n recommande des tailles de chunks comprises entre 200 et 500 tokens, combinées à un certain chevauchement entre les sections voisines afin de ne pas perdre de contexte aux limites des chunks. Comme stratégie de splitter, n8n propose le Recursive Character Text Splitter pour la plupart des cas d'usage, car il s'appuie sur la structure naturelle du document plutôt que de découper arbitrairement selon le nombre de caractères.