Connecter Weaviate à n8n : la base vectorielle qui fait la recherche hybride sans SQL

La recherche hybride pour le RAG résout un vrai problème : la recherche vectorielle seule rate les requêtes qui contiennent une référence exacte, un code d'erreur ou un nom propre rare, parce qu'un modèle d'embedding encode du sens, pas des caractères. La solution que nous détaillons dans cet article-là repose sur Postgres/Supabase : une fonction SQL qui interroge en parallèle un index tsvector et pgvector, puis fusionne les deux listes avec Reciprocal Rank Fusion. Ça fonctionne très bien — mais ça s'écrit à la main. Weaviate propose la même idée sans écrire de SQL : son node natif dans n8n embarque une recherche hybride BM25 + vecteurs directement configurable dans l'interface, avec un paramètre alpha qui règle l'équilibre entre les deux moteurs. Voici comment le connecter et l'exploiter dans un pipeline RAG n8n.

Qu'est-ce que Weaviate, en une phrase

Weaviate est une base de données vectorielle open source, pensée dès le départ pour combiner recherche sémantique et recherche par mots-clés dans le même moteur, plutôt que comme une extension ajoutée après coup à une base relationnelle. Elle se déploie en conteneur Docker, expose une API HTTP (port 8080 par défaut) et une API gRPC plus performante pour les gros volumes (port 50051 par défaut), et propose une offre cloud managée pour qui préfère ne pas l'opérer soi-même.

n8n a ajouté un node Weaviate Vector Store dédié dans ses nodes LangChain, puis, dans une mise à jour du node fusionnée début janvier 2026, un vrai support de la recherche hybride natif — pas un contournement, une fonctionnalité du protocole de requête de Weaviate lui-même exposée directement dans l'interface n8n.

Le node Weaviate dans n8n : quatre usages

Comme les autres vector stores de n8n, le node Weaviate Vector Store fonctionne en plusieurs modes distincts, à choisir selon la position du node dans votre workflow :

• Insert Documents : ingère des documents (texte + métadonnées) avec leurs embeddings dans une collection Weaviate. Utilisé en fin de pipeline d'ingestion.
• Get Many : récupère un lot de documents, utile pour l'inspection ou la maintenance de la collection.
• Retrieve Documents (as Vector Store for Chain/Tool) : branché à une Question and Answer Chain pour aller chercher les passages pertinents avant de répondre.
• Retrieve Documents (as Tool for AI Agent) : branché directement sur le connecteur d'outils d'un AI Agent, pour que l'agent décide lui-même quand interroger la base documentaire.

C'est ce dernier mode — retrieval en tant qu'outil de l'agent — qui expose les réglages de recherche hybride.

Connexion : self-host Docker ou Weaviate Cloud

Les credentials Weaviate dans n8n distinguent la couche HTTP et la couche gRPC :

• HTTP : hôte (domaine ou IP de votre instance), port (8080 par défaut), et une bascule HTTPS.
• gRPC : hôte et port (50051 par défaut), utilisés par le client pour les opérations à plus haut débit.
• Clé API : requise dès que l'instance n'est pas ouverte sans authentification — systématique sur Weaviate Cloud, recommandé aussi en self-host dès que le conteneur est exposé au-delà de localhost.

Pour un self-host à côté d'une instance n8n existante, un docker-compose.yml minimal suffit : un service Weaviate avec un volume persistant pour les données, les ports 8080 et 50051 exposés sur le réseau interne partagé avec n8n, et la clé API activée via les variables d'environnement du conteneur (AUTHENTICATION_APIKEY_ENABLED, AUTHENTICATION_APIKEY_ALLOWED_KEYS). C'est la même logique de déploiement que pour Qdrant : un conteneur de plus à côté de votre VPS n8n, avec ses propres sauvegardes à planifier — Weaviate a son propre mécanisme de backup, distinct de pg_dump.

La recherche hybride native : le paramètre alpha

C'est le vrai différenciateur par rapport aux autres vector stores de n8n. Quand vous configurez le node en mode retrieval, plusieurs champs apparaissent pour activer et régler la recherche hybride :

• Requête hybride (hybridQuery) : le texte de la requête envoyé simultanément au moteur lexical (BM25) et au moteur vectoriel.
• Alpha : de 0 (recherche purement par mots-clés) à 1 (recherche purement vectorielle), avec 0,5 par défaut — un équilibre entre les deux.
• Type de fusion (fusionType) : la méthode de combinaison des deux classements (rank-based, à la manière de la Reciprocal Rank Fusion décrite dans notre article sur la recherche hybride, ou relative-score).
• Propriétés interrogées (queryProperties) : les champs texte sur lesquels porte la partie lexicale de la recherche, pour ne pas indexer en mots-clés des métadonnées non pertinentes.
• Distance vectorielle maximale et seuil de coupure automatique (maxVectorDistance, autoCutLimit) : pour écarter les résultats trop éloignés plutôt que de renvoyer un top-k fixe qui inclut du bruit.

Concrètement, un alpha à 0,3 privilégiera un chunk qui contient exactement la référence produit citée dans la question, même si son score sémantique est moyen — exactement le comportement que l'article sur la recherche hybride construit à la main avec une fonction SQL et du RRF. Ici, il se règle en un champ de formulaire.

Pourquoi ça compte : la recherche mono-signal a une limite documentée

Ce n'est pas un raffinement cosmétique. Une étude publiée aux actes de la 10ᵉ édition de l'International Conference on Communication and Information Processing (ACM, 2024), « Evaluating Sparse and Dense Retrieval in Retrieval-Augmented Generation Systems: A Study » de Wang, Dai, Ke et Zheng (voir sur Google Scholar), compare recherche dense et recherche parcimonieuse (type BM25) dans des pipelines RAG et montre que le choix du bon algorithme de récupération, adapté au type de requête et aux contraintes matérielles, influence directement la qualité des réponses générées en aval. Autrement dit : un seul moteur de recherche, aussi bon soit-il, ne couvre pas tous les profils de requêtes d'un usage réel — d'où l'intérêt de pouvoir combiner les deux sans reconstruire un pipeline de fusion à la main.

Weaviate, pgvector ou Qdrant : comment trancher

Les trois options ont un node natif dans n8n et se déploient en Docker. Le critère de choix n'est pas la performance brute — les trois tiennent largement la charge d'un projet RAG n8n typique — mais l'opération que vous voulez éviter de coder vous-même :

Priorité	Choix recommandé
Éviter un service de plus, tout garder dans Postgres/Supabase	pgvector
Recherche hybride prête à l'emploi, sans SQL de fusion à écrire	Weaviate
Filtrage de métadonnées complexe à très grande échelle	Qdrant

Aucun des trois n'est un mauvais choix : ce sont trois façons différentes de payer le même coût (un service à opérer, une fonction à écrire, ou un paramètre à régler) selon ce que votre projet privilégie.

Construire le pipeline complet

Une fois la connexion établie, le pipeline suit le schéma classique d'un RAG n8n : ingestion des documents source (PDF, pages web, exports Notion) via un workflow de chunking, génération des embeddings, insertion dans Weaviate via le node en mode Insert. Côté requête, un AI Agent avec le node Weaviate branché en outil, alpha réglé selon le profil de vos questions utilisateurs, répond en citant les passages retrouvés — le même schéma que celui détaillé dans notre guide RAG PDF, avec un moteur de recherche différent en coulisses.

Le Pack Assistant RAG (119 €) fournit ces quatre workflows prêts à importer — ingestion PDF, chatbot avec citations, synchronisation Notion, API /ask — configurables avec pgvector par défaut mais adaptables à Weaviate en changeant simplement le node de vector store et ses credentials. Pour qui démarre un projet où la recherche hybride est un besoin day one plutôt qu'une optimisation ajoutée plus tard, c'est le seul des trois moteurs qui l'offre sans construire soi-même la couche de fusion.