Pourquoi mon agent RAG ne répond pas à partir de la base de données ? Les 5 causes les plus fréquentes (FAQ)

Un agent RAG dans n8n est censé puiser ses réponses exclusivement dans la base de connaissances connectée, mais en pratique ce n'est souvent pas le cas : il ignore le vector store, invente du contenu ou affirme qu'une information n'est pas disponible alors qu'elle figure dans l'index. La cause n'est presque jamais le modèle de langage lui-même, mais la configuration entre l'indexation et l'interrogation : des embeddings mal alignés, un chunking défavorable, un filtre de retriever qui exclut trop ou trop peu, ou un system prompt qui n'impose pas clairement l'utilisation de l'outil. Cet article classe les cinq schémas d'erreur les plus fréquents issus des fils de discussion de la communauté n8n et de la documentation officielle, et indique à chaque fois la solution pratique. À jour en juillet 2026.

Causes liées à l'indexation et à l'interrogation

• Incompatibilité d'embeddings : Si les documents ont été traités lors de l'indexation avec un modèle d'embedding ou une dimension vectorielle différente de celle utilisée par la requête de recherche au moment de l'interrogation, la recherche par similarité ne renvoie plus de résultats exploitables, car les espaces vectoriels ne correspondent plus entre eux. Dans n8n, cela se produit typiquement lorsque le workflow d'insertion utilise un node d'embeddings différent de celui du workflow de récupération, par exemple OpenAI pour l'indexation et un modèle Ollama local pour l'interrogation. La solution : câbler fermement le même modèle d'embeddings dans les deux workflows et reconstruire entièrement l'index à chaque changement de modèle au lieu de simplement le compléter.
• Problèmes de chunking : Des chunks trop grands mélangent plusieurs sujets dans un seul vecteur et diluent la précision des résultats, tandis que des chunks trop petits déchirent le contexte, de sorte que la réponse reste sémantiquement proche mais incomplète sur le fond. Un bon point de départ se situe généralement entre 500 et 1 000 caractères avec un chevauchement notable, et le Recursive Character Text Splitter de n8n s'oriente sur les paragraphes et les titres, ce qui permet une séparation plus propre qu'une simple limite de caractères. La solution : faire varier la taille des chunks et le chevauchement à titre expérimental et vérifier la qualité des résultats sur de vraies questions d'utilisateurs, pas seulement sur des textes d'exemple.
• Filtre de retriever manquant ou incorrect : Les filtres de métadonnées dans le node vector store combinent par défaut plusieurs conditions avec un ET, de sorte qu'un filtre défini de manière trop restrictive, par exemple une combinaison de catégorie et de date, exclut tous les documents alors que du contenu correspondant existe dans l'index. Le forum n8n rapporte également que les filtres dynamiques sont moins fiables en mode outil de l'agent qu'en mode chaîne. La solution : supprimer d'abord entièrement la logique de filtrage pour vérifier la récupération de base, puis réintroduire progressivement les filtres.

Causes liées au prompt et à la connexion des outils

• L'agent n'utilise pas l'outil vector store : Les modèles de langage plus petits en particulier n'appellent pas l'outil de récupération de manière fiable si le system prompt n'impose pas explicitement son utilisation, et répondent alors aux questions à partir de leurs connaissances d'entraînement. Dans la communauté n8n, un system prompt explicite s'est révélé être une solution efficace : il impose l'utilisation de l'outil avant chaque réponse, n'autorise les réponses que sur la base des résultats de l'outil, et demande à l'agent de signaler ouvertement les lacunes de connaissance plutôt que d'improviser.
• La réponse de l'outil est rejetée par l'agent : Même lorsque le retriever fournit un résultat correct, l'agent peut ignorer la réponse si la sortie de l'outil est fortement structurée, par exemple avec de nombreux paragraphes et sauts de ligne provenant de plusieurs documents à la fois. Dans ces cas, le modèle répond que l'information n'est pas disponible bien que des résultats correspondants existent. La solution : réduire le nombre de documents renvoyés (top-K) et formater la sortie de l'outil dans le node retriever de manière plus compacte, afin que l'agent la reconnaisse clairement dans le contexte comme base de réponse.

Toute personne souhaitant non seulement réparer un tel pipeline mais le mettre en place proprement depuis le début trouvera dans le conseil en agents IA de NordFlux une approche fondée sur un prix fixe et la souveraineté des données allemande comme principe fondamental.

Questions fréquentes sur les agents RAG dans n8n

Pourquoi mon agent n8n ignore-t-il complètement le vector store ?

Le plus souvent, il manque une instruction claire dans le system prompt d'utiliser l'outil de récupération avant chaque réponse. Les modèles plus petits déduisent rarement ce comportement par eux-mêmes et se rabattent à la place sur leurs connaissances générales d'entraînement, même lorsqu'un outil approprié est connecté.

Comment reconnaître une incompatibilité d'embeddings ?

Un signe typique est que la recherche par similarité renvoie systématiquement des scores de correspondance faibles ou arbitraires, alors que le contenu recherché figure bel et bien dans l'index. Vérifiez si le workflow d'insertion et celui de récupération utilisent exactement le même node d'embeddings avec la même version de modèle, voir la documentation n8n sur les vector stores.

Quelle doit être la taille des chunks pour le RAG dans n8n ?

Un bon point de départ se situe généralement entre 500 et 1 000 caractères avec un léger chevauchement entre les chunks. La taille appropriée dépend toutefois de la structure des documents source et doit être ajustée à partir de véritables questions de test, et non selon une règle empirique fixe.

Dois-je réindexer après un changement de modèle d'embeddings ?

Oui. Comme différents modèles d'embedding produisent des espaces vectoriels différents, les anciens et les nouveaux vecteurs ne peuvent pas être recherchés ensemble de manière pertinente. Après un changement de modèle, l'index complet doit être reconstruit, comme le confirment également plusieurs fils de discussion de la communauté n8n pour des schémas d'erreur similaires.