Connecter Pinecone à n8n pour un pipeline RAG sans serveur à gérer

Monter un pipeline RAG (Retrieval-Augmented Generation) avec n8n suppose presque toujours de stocker des embeddings quelque part. Le choix par défaut dans l'écosystème n8n penche vers pgvector ou Qdrant — deux options détaillées dans notre comparatif Qdrant ou pgvector pour votre RAG n8n — parce qu'elles s'auto-hébergent à côté de l'instance n8n. Mais une partie non négligeable des projets RAG n'a justement pas envie d'opérer une base de données supplémentaire : c'est exactement le créneau de Pinecone, une base vectorielle entièrement managée. L'article fondateur du RAG, Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020, voir sur Google Scholar), posait déjà le principe qui rend ce choix pertinent : la qualité d'un système RAG dépend directement de la pertinence de la recherche documentaire en amont du LLM, bien plus que du modèle génératif lui-même. Autant confier cette brique à un service dont c'est l'unique métier. Ce guide montre comment créer un index Pinecone, le connecter à n8n, y insérer des documents et l'interroger — de la console Pinecone jusqu'au premier appel réussi.

Pourquoi Pinecone plutôt que pgvector ou Qdrant

Les trois options font le même travail — stocker des vecteurs et retrouver les plus proches d'une requête — mais avec des compromis très différents :

• Zéro opération. Pas de conteneur à lancer, pas de sauvegarde à planifier, pas d'index HNSW à paramétrer à la main (voir notre guide HNSW ou IVFFlat pour pgvector pour mesurer ce que ça représente côté pgvector). Pinecone gère l'infrastructure, le scaling et la répartition des données en coulisses.
• Facturation à l'usage. Un plan gratuit (Starter) couvre largement un prototype ou un petit projet ; au-delà, le coût suit le volume de vecteurs stockés et de requêtes, sans serveur à dimensionner à l'avance.
• Des namespaces natifs. Chaque index se subdivise en namespaces isolés, un mécanisme particulièrement pratique pour séparer les documents de plusieurs clients ou projets sans multiplier les index — utile pour une agence qui reprend l'architecture du Pack Assistant RAG (119 €) pour plusieurs clients.
• La contrepartie. Vos vecteurs vivent hors de votre infrastructure, chez un tiers ; il n'y a pas de jointure SQL possible avec vos données métier, contrairement à pgvector ; et un projet déjà entièrement self-hosted (n8n, Postgres, Redis) ajoute ici sa seule dépendance cloud obligatoire.

Si la priorité est de garder toutes les données sur votre propre infrastructure, pgvector ou Qdrant self-hosted restent le bon choix, comme détaillé dans le guide RAG avec Supabase et n8n. Si la priorité est de démarrer vite sans administrer de base de données, Pinecone le permet en quelques minutes.

Étape 1 : créer l'index Pinecone

Dans la console Pinecone, créez un index en spécifiant deux paramètres critiques :

• La dimension, qui doit correspondre exactement au modèle d'embeddings utilisé en amont. Avec text-embedding-3-small d'OpenAI, la dimension par défaut est 1536 ; avec text-embedding-3-large, 3072 (réductible via le paramètre dimensions de l'API OpenAI si besoin).
• La métrique de similarité, le plus souvent cosine pour des embeddings de texte — c'est la métrique attendue par la majorité des modèles d'embeddings généralistes.

Un index serverless (le mode par défaut aujourd'hui chez Pinecone) suffit pour la quasi-totalité des projets n8n : pas de dimensionnement de pods à anticiper, le stockage et le débit s'ajustent automatiquement à l'usage.

Étape 2 : configurer les credentials dans n8n

Dans Pinecone, la clé s'obtient depuis API Keys dans la console — copiez-la telle quelle. Dans n8n, créez ensuite un credential Pinecone API : collez la clé, sans autre configuration réseau à fournir manuellement, n8n résout l'hôte de votre index automatiquement à la connexion.

Ce credential est ensuite disponible dans le node Pinecone Vector Store, celui qui sert aussi bien à l'insertion qu'à la recherche — un seul node, dont le comportement change selon le mode sélectionné dans son paramètre principal.

Étape 3 : insérer des documents

Pour l'ingestion, le node Pinecone Vector Store se configure en mode Insert Documents, en sélectionnant l'index créé à l'étape 1. Il se branche en aval de deux nodes qui font tout le travail de préparation :

1. Un Text Splitter (Recursive Character Text Splitter) qui découpe le document source en fragments exploitables — voir notre guide sur le chunking de documents RAG pour bien choisir la taille et le recouvrement des chunks.
2. Un node Embeddings OpenAI (ou tout autre fournisseur compatible) qui transforme chaque fragment en vecteur — le choix du modèle est détaillé dans notre guide de sélection d'un modèle d'embeddings.

En amont de ces deux nodes, un Default Data Loader reçoit le contenu binaire (PDF, texte) et les métadonnées à attacher à chaque chunk (nom de fichier, date, source) — ces métadonnées seront ensuite exploitables comme filtres à la recherche, sur le modèle décrit dans notre article sur le filtrage de métadonnées RAG. Pour isoler les documents d'un client ou d'un projet, indiquez un namespace dans les paramètres du node : chaque namespace se comporte comme un sous-index totalement étanche des autres.

Étape 4 : interroger l'index

Pour la recherche, deux modes du même node répondent à des besoins différents :

Mode	Usage
Retrieve Documents (As Tool for AI Agent)	Brancher l'index comme outil d'un node AI Agent, qui décide seul quand interroger la base documentaire dans une conversation
Retrieve Documents (As Vector Store for Chain/Tool)	Intégrer la recherche dans une chaîne de question-réponse structurée, sans agent autonome
Get Many	Récupérer directement les N documents les plus proches d'une requête textuelle, pour un traitement programmatique en aval

Pour un chatbot documentaire avec citations, comme celui du Pack Assistant RAG, le mode « As Tool for AI Agent » est le plus courant : l'agent reformule la question, interroge Pinecone, puis rédige une réponse en citant les passages retrouvés — la même logique que celle décrite dans le guide RAG Supabase, avec Pinecone à la place de pgvector.

Namespaces : le multi-tenant sans multiplier les index

C'est l'argument le plus concret en faveur de Pinecone pour une agence ou un consultant qui déploie le même pipeline RAG chez plusieurs clients : plutôt que de créer un index par client (et donc un jeu de credentials et de coûts distincts), un seul index Pinecone accueille un namespace par client. Le node Pinecone Vector Store accepte un namespace dynamique, calculable depuis une expression n8n (par exemple l'identifiant du client extrait du webhook d'ingestion) — de quoi réutiliser exactement le même workflow pour dix clients sans dupliquer la moindre logique.

Sécuriser la clé et suivre le coût

La clé API Pinecone donne un accès complet à l'index : elle doit rester dans les credentials n8n, jamais en clair dans un node Code ou une variable d'environnement partagée — les bonnes pratiques génériques de notre guide sur la sécurisation des credentials API s'appliquent telles quelles. Côté coût, la facturation Pinecone s'ajoute à celle des appels d'embeddings et de génération : notre guide sur le suivi du coût des appels IA montre comment journaliser ces montants dans le même pipeline, pour éviter la mauvaise surprise en fin de mois sur un corpus qui grossit vite.

Pour aller plus loin

Le Pack Assistant RAG (119 €) livre ses quatre workflows avec Supabase et pgvector par défaut — un choix pensé pour rester entièrement self-hosted et gratuit à démarrer. L'architecture (Text Splitter, Embeddings, node de stockage, agent de réponse) reste toutefois identique avec Pinecone : remplacer le node PGVector Vector Store par le node Pinecone Vector Store, recréer les credentials, relancer une ingestion complète, et le reste du pipeline fonctionne sans autre modification. Un choix à faire tôt dans le projet, mais jamais définitif.