RAG agentique avec n8n : quand l'agent décide lui-même comment chercher

Le RAG classique dans n8n suit un pipeline rigide : la question part telle quelle dans une recherche vectorielle, les passages les plus proches sont injectés dans le prompt, le modèle répond. Ce schéma échoue dès que la question demande de croiser plusieurs documents, que la formulation de l'utilisateur ne ressemble pas au vocabulaire du corpus, ou que la réponse se trouve dans une base plutôt qu'une autre. Le RAG agentique inverse la logique : vous donnez à un node AI Agent un ou plusieurs Vector Store Tools, et c'est le modèle qui décide s'il cherche, combien de fois, et avec quelles requêtes. Ce guide montre comment le configurer dans n8n, quand cela vaut le surcoût, et comment éviter le piège des boucles de recherche infinies.

RAG pipeline vs RAG agentique : ce qui change vraiment

Le RAG « pipeline » descend directement de l'architecture décrite par Patrick Lewis et ses co-auteurs dans Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020) : une recherche, un contexte, une génération. Dans n8n, c'est le pattern retrieve → stuff → answer détaillé dans notre guide du RAG avec Supabase : la recherche s'exécute systématiquement, avec la question brute.

Le RAG agentique s'appuie sur le schéma réflexion-action popularisé par Shunyu Yao et ses co-auteurs dans ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 2023) : le modèle alterne raisonnement et appels d'outils, observe les résultats, et décide de la suite. Concrètement :

• Recherche optionnelle : si le message est du bavardage (« merci, c'est clair »), l'agent répond sans interroger la base.
• Requêtes reformulées : l'agent traduit « ça plante quand j'exporte » en « erreur export PDF timeout », plus proche du vocabulaire de votre documentation.
• Recherches multiples : pour comparer les garanties des produits A et B, l'agent lance deux recherches ciblées au lieu d'une requête moyenne qui ne remonte bien ni l'un ni l'autre.
• Routage entre index : avec plusieurs outils, l'agent choisit la base pertinente au lieu de tout chercher partout.

Akari Asai et ses co-auteurs ont formalisé cette récupération « à la demande » dans Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (ICLR 2024) : un modèle qui décide lui-même quand récupérer surpasse le RAG systématique en question-réponse et en vérification factuelle.

Configurer l'AI Agent avec un Vector Store Tool

La mise en place repose sur trois briques : un node AI Agent (voir notre guide complet du node AI Agent), un vector store déjà alimenté, et l'outil qui les relie.

1. Préparez votre vector store : Supabase/pgvector, Pinecone ou Qdrant — voir notre comparatif Qdrant vs pgvector. L'ingestion (chunking, embeddings, insertion) est identique au RAG classique.
2. Ajoutez un node AI Agent avec son Chat Model (et une mémoire si l'usage est conversationnel).
3. Attachez le vector store comme outil sur le connecteur Tool de l'agent : soit via le sous-node Vector Store Question Answer Tool (un vector store plus un modèle qui synthétise les passages), soit via le node vector store lui-même en mode « Retrieve Documents (As Tool for AI Agent) », qui renvoie les passages bruts.
4. Reliez le même modèle d'embeddings qu'à l'ingestion — une divergence ici rend la recherche silencieusement inutilisable.
5. Réglez la limite de résultats (top K) : 4 à 6 passages suffisent généralement, l'agent pouvant relancer une recherche au besoin.

La description de l'outil : le paramètre le plus important

L'agent ne « voit » pas votre base documentaire : il ne voit que le nom et la description de l'outil, et décide sur cette seule base de l'utiliser ou non — exactement comme pour les outils personnalisés de l'AI Agent. Une description vague (« recherche des documents ») produit un agent qui interroge la base au hasard ou pas du tout. Une bonne description précise le contenu, le périmètre et le format attendu de la requête :

Nom : base_support
Description : Recherche dans la documentation technique du produit
Flowkit : guides d'installation, messages d'erreur, procédures de
dépannage, notes de version. Utilise cet outil pour toute question
technique sur le fonctionnement du produit. Formule la requête avec
des mots-clés techniques précis, pas la question brute de
l'utilisateur. Ne contient NI tarifs NI conditions contractuelles.

Le « ne contient pas » évite que l'agent s'obstine sur le mauvais index.

Multi-index : un outil par base documentaire

Plutôt qu'un index unique où fiches produits, CGV et tickets support se polluent mutuellement à la recherche, créez un vector store (ou une collection) par domaine et attachez un outil par domaine : base_produits (caractéristiques, compatibilités), base_juridique (CGV, contrats, mentions RGPD), base_support (documentation technique, dépannage).

Face à « puis-je résilier si le module X n'est pas compatible avec mon installation ? », l'agent interroge base_produits, puis base_juridique, et croise les deux réponses — là où un index unique aurait remonté un mélange médiocre des deux sujets. Ce routage par description est plus simple à maintenir qu'un filtrage par métadonnées sur index unique quand les domaines sont vraiment disjoints, et les deux approches se combinent bien.

Exemple de workflow complet

Un assistant support interne interrogeable depuis Slack ou un widget de chat :

1. Chat Trigger (ou Webhook) reçoit la question.
2. AI Agent avec un prompt système du type : « Tu es l'assistant support de [entreprise]. Réponds uniquement à partir des documents récupérés via tes outils, en citant tes sources. Si deux recherches ne suffisent pas, réponds que tu ne sais pas. »
3. Trois Vector Store Tools (produits, juridique, support), chacun avec sa description délimitée.
4. Mémoire (Window Buffer Memory ou équivalent) pour le suivi conversationnel.
5. En sortie, un node de mise en forme puis l'envoi vers Slack ou la réponse au webhook.

Les données d'exécution montrent chaque cycle (réflexion, appel d'outil avec la requête reformulée, observation) — une trace lisible précieuse pour le débogage, là où un pipeline reste muet.

Le piège : les boucles de recherche infinies

Un agent mal cadré peut relancer indéfiniment des variantes de la même recherche quand le corpus ne contient pas la réponse — chaque itération étant un appel LLM facturé. Trois garde-fous :

• Max Iterations : dans les options du node AI Agent, plafonnez le nombre de cycles (3 à 5 suffisent pour la plupart des assistants).
• Consigne d'abandon explicite dans le prompt système : « après deux recherches sans résultat pertinent, réponds que l'information n'est pas disponible ». Sans cette porte de sortie, le modèle préfère chercher encore plutôt qu'avouer qu'il ne sait pas.
• Suivi des coûts : loggez le nombre d'appels et de tokens par exécution pour repérer les questions qui font déraper l'agent.

Quand ça vaut le coût — et quand rester en RAG classique

Le RAG agentique n'est pas un remplacement, c'est un cran au-dessus qui se paie. Choisissez l'agentique quand les questions sont multi-hop (croiser plusieurs documents ou plusieurs bases), quand le corpus est hétérogène (le routage par outil bat l'index unique) ou quand les formulations utilisateur sont éloignées du corpus (la reformulation récupère ce qu'une recherche brute manque).

Restez en RAG pipeline quand :

• les questions sont simples et le corpus homogène : une FAQ produit n'a pas besoin d'un agent ;
• la latence compte : chaque itération ajoute un aller-retour LLM ; un pipeline répond en un appel ;
• le déterminisme compte : un pipeline fait toujours la même chose, ce qui simplifie les tests et l'évaluation de la qualité du RAG ; un agent peut varier d'une exécution à l'autre ;
• le budget est serré : deux à quatre appels LLM par question au lieu d'un.

Avant de passer à l'agentique, vérifiez aussi que le problème n'est pas la recherche elle-même : la recherche hybride et le reranking corrigent souvent le tir à coût bien moindre.

En résumé

Le RAG agentique remplace la recherche fixe du pipeline par une décision du modèle : chercher ou non, reformuler, répéter, router entre plusieurs index. Dans n8n, tout tient dans le trio AI Agent + Vector Store Tool(s) + descriptions d'outils soignées — la description étant le vrai levier de qualité. Plafonnez les itérations, donnez une consigne d'abandon, et réservez cette architecture aux questions multi-hop et aux corpus hétérogènes : pour le reste, le pipeline classique reste plus rapide, moins cher et plus prévisible. Pour partir d'une base déjà assemblée, le Pack Assistant RAG (119 €) fournit un socle directement extensible vers le multi-index agentique.