Quel modèle d'embeddings choisir pour votre RAG n8n (Supabase pgvector) ?

Dans un pipeline RAG n8n, le choix du modèle d'embeddings est une décision structurante prise dès le premier workflow d'ingestion — et souvent par défaut, en gardant le modèle pré-rempli dans le node sans se poser de question. C'est pourtant lui qui détermine la qualité de la recherche vectorielle, la taille de l'index pgvector, le coût de chaque ingestion et la dimension de la colonne vector(n) déclarée dans Supabase. Et contrairement au prompt du LLM, qu'on ajuste en deux minutes, en changer plus tard impose de ré-indexer tout le corpus. Autant le choisir en connaissance de cause.

Rappel : le rôle des embeddings dans un pipeline RAG

Un embedding est la représentation numérique d'un texte : un modèle transforme une phrase ou un chunk de document en un vecteur de plusieurs centaines ou milliers de nombres, construit pour que deux textes proches par le sens produisent des vecteurs proches dans l'espace. C'est ce qui permet à la recherche vectorielle de retrouver « les passages qui parlent de la même chose » qu'une question, même sans mot-clé commun.

L'idée de produire des embeddings de phrases directement comparables entre eux a été popularisée par l'article fondateur Sentence-BERT de Reimers et Gurevych (EMNLP 2019, voir sur Google Scholar) : encoder chaque texte une seule fois en un vecteur réutilisable, ce qui rend la comparaison de milliers de candidats quasi instantanée. Tous les modèles d'embeddings modernes, propriétaires comme open source, descendent de cette approche.

Dans n8n, le modèle se règle dans le node Embeddings (Embeddings OpenAI, Embeddings Ollama, etc.), branché sur le node Vector Store. Et il intervient à deux endroits du pipeline décrit dans notre guide RAG avec Supabase pgvector :

• à l'ingestion : chaque chunk issu du découpage des documents est converti en vecteur puis inséré dans la table Supabase ;
• à la requête : la question de l'utilisateur est convertie en vecteur avec le même node, puis comparée aux vecteurs stockés via match_documents.

La règle d'or : même modèle à l'ingestion et à la recherche

C'est la contrainte non négociable du choix : le modèle utilisé pour indexer et le modèle utilisé pour chercher doivent être identiques. Chaque modèle projette les textes dans son propre espace vectoriel — un vecteur produit par text-embedding-3-small et un vecteur produit par un modèle Ollama n'ont mathématiquement rien à voir, même s'ils ont par hasard la même dimension. Comparer les deux donne des scores de similarité qui ressemblent à des scores… mais ne mesurent rien.

Deux conséquences pratiques :

• Changer de modèle = tout ré-indexer. Il faut repasser l'intégralité du corpus dans le workflow d'ingestion et recréer la colonne vector(n) si la dimension change. Sur un gros corpus, c'est du temps et de l'argent — d'où l'intérêt de tester avant de s'engager.
• Vérifier la cohérence entre workflows. Dans n8n, l'ingestion et le chat sont souvent deux workflows séparés, chacun avec son propre node Embeddings. Si quelqu'un modifie le modèle d'un côté sans toucher à l'autre, le RAG continue de « fonctionner » (aucune erreur) mais renvoie des passages sans rapport avec les questions. C'est un bug silencieux redoutable.

Les critères qui comptent vraiment

La qualité sur votre langue

C'est le critère le plus sous-estimé. Beaucoup de modèles d'embeddings sont entraînés majoritairement sur de l'anglais : sur un corpus en français, un modèle explicitement multilingue fait souvent une différence nette. Si votre documentation mélange français et anglais (cas fréquent : docs internes en français, documentation technique en anglais), le multilingue devient carrément indispensable — un bon modèle multilingue rapproche une question en français d'un passage en anglais qui y répond.

La dimension du vecteur

Chaque modèle produit des vecteurs d'une dimension fixe, et cette dimension a des effets très concrets côté Supabase :

• elle détermine la colonne vector(n) déclarée dans la table — 1536 pour text-embedding-3-small par défaut, par exemple ;
• elle conditionne la taille de la table et surtout de l'index pgvector : des vecteurs deux fois plus grands, c'est un index environ deux fois plus lourd, plus de RAM consommée et des recherches un peu plus lentes, quel que soit le type d'index choisi (HNSW ou IVFFlat).

Une dimension plus grande capture en théorie plus de nuances, mais sur un corpus de taille raisonnable, la différence de qualité entre un bon modèle « compact » et un modèle à très grande dimension est rarement le facteur limitant — le chunking et le reranking pèsent souvent davantage.

Le coût, la latence et l'hébergement

Les embeddings se facturent au million de tokens, à des tarifs bien inférieurs à ceux des LLM de génération — mais l'ingestion d'un gros corpus, ré-indexations comprises, finit par se voir sur la facture. La latence, elle, compte surtout côté requête : chaque question de l'utilisateur passe par un appel d'embedding avant la recherche.

Enfin, l'hébergement : une API cloud (OpenAI, Cohere, Mistral, Google) est simple et rapide à intégrer, mais chaque chunk de votre documentation transite par un serveur tiers. Pour des données sensibles, un modèle open source servi en local est la seule option réellement étanche.

Les grandes familles de modèles

Les embeddings OpenAI sont le choix par défaut dans l'écosystème n8n : text-embedding-3-small (1536 dimensions par défaut) couvre très bien la plupart des cas, y compris en français, et text-embedding-3-large monte en qualité pour les corpus exigeants. Particularité utile : ces modèles acceptent un paramètre dimensions qui permet de réduire la taille des vecteurs produits — pratique pour alléger l'index pgvector — à condition, règle d'or oblige, d'utiliser exactement la même dimension réduite à l'ingestion et à la requête.

Les alternatives propriétaires — Cohere (réputé pour son multilingue), Mistral (acteur européen, argument de localisation des données), Google — proposent toutes des API d'embeddings de bonne qualité. Le raccordement dans n8n se fait via le node Embeddings correspondant quand il existe, ou un node HTTP Request sinon.

Les modèles open source en local via Ollama : des modèles comme nomic-embed-text tournent sur votre propre machine, appelés depuis le node Embeddings Ollama. Deux arguments massifs : la confidentialité (aucune donnée ne sort de votre infrastructure) et le coût API nul — l'ingestion d'un corpus entier ne coûte que du temps machine. La contrepartie : c'est votre serveur qui encaisse la charge, et la qualité multilingue varie beaucoup d'un modèle à l'autre. Notre guide n8n + Ollama pour un LLM local sans clé API détaille la mise en place, qui vaut aussi pour les embeddings.

Comparer objectivement : MTEB, avec précaution

Pour comparer des dizaines de modèles sans les tester un par un, la référence publique est MTEB (Massive Text Embedding Benchmark), introduit par Muennighoff et ses coauteurs en 2022 (voir sur Google Scholar) : un banc d'essai qui évalue les modèles d'embeddings sur des dizaines de tâches (recherche, classification, clustering…) et dont le leaderboard public est régulièrement mis à jour avec les nouveaux modèles.

La mise en garde qui va avec : un bon score moyen MTEB ne garantit pas le meilleur résultat sur votre corpus. Le classement agrège des domaines et des langues qui ne sont pas les vôtres. La bonne méthode : utiliser MTEB pour présélectionner 2 ou 3 candidats crédibles (en filtrant sur les tâches de retrieval et les langues qui vous concernent), puis les départager sur un échantillon de vraies questions : indexez le même sous-ensemble de documents avec chaque modèle, posez 20 à 30 questions réelles, et comparez les passages remontés. Une heure de test évite des mois avec le mauvais modèle.

Côté n8n : les points de cohérence à verrouiller

Concrètement, dans un workflow comme notre ingestion de PDF vers Supabase pgvector, trois éléments doivent rester alignés en permanence :

1. Le node Embeddings du workflow d'ingestion — le modèle (et l'éventuel paramètre de dimension) qui produit les vecteurs stockés.
2. La colonne vector(n) de la table Supabase — sa dimension doit correspondre exactement à celle des vecteurs produits, faute de quoi pgvector rejette l'insertion. La création de cette table est couverte dans notre guide pour connecter n8n à Supabase.
3. Le node Embeddings du workflow de chat — même modèle, même dimension, sans exception.

Un réflexe simple : noter le nom du modèle dans les métadonnées de chaque chunk au moment de l'ingestion. Le jour où un doute survient (« cette table a été indexée avec quoi, déjà ? »), la réponse est dans la base.

Pour aller plus loin

Le choix du modèle d'embeddings est l'une des trois fondations d'un RAG qui répond juste, avec le chunking et la qualité du retrieval — si les passages remontés restent décevants malgré un bon modèle, l'étape suivante est souvent le reranking. Le Pack Assistant RAG (119 €) fournit les workflows d'ingestion, de chat avec citations, de synchronisation Notion et d'API question-réponse déjà câblés sur Supabase pgvector : le node Embeddings y est isolé et documenté, ce qui permet de tester plusieurs modèles sur votre propre corpus en changeant un seul paramètre — puis de ré-indexer proprement une fois le bon candidat identifié.