J’ai un workflow pour RAG, mais il ne fonctionne pas. Après avoir uploadé du texte dans la base de données Supabase (le workflow se termine avec succès), j’ai demandé au LLM quelque chose d’uploadé dans Supabase. Mais l’IA a donné une mauvaise réponse (elle m’a donné quelque chose comme : Je ne sais pas de quoi tu parles).
Quelqu’un sait-il comment corriger ce problème.
Mon workflow ici
@Quent problème classique du RAG : le téléchargement a fonctionné mais la recherche ne retourne rien, donc l’agent n’a pas de contexte et dit « Je ne sais pas. » Presque toujours l’une de ces deux causes :
-
Décalage du modèle d’embedding (la cause n°1). Le modèle avec lequel tu fais l’embedding lors de l’insertion doit être exactement le même que celui utilisé lors de la requête. Un modèle différent ou une dimension différente place les vecteurs dans un espace différent, si bien que la recherche de similarité retourne zéro résultat. Vérifie que les deux nœuds Embeddings utilisent le modèle identique.
-
Le Vector Store n’est pas relié à l’agent en tant que retrieveur, ou le Query Name n’est pas défini sur match_documents.
Si les deux s’alignent déjà, colle le workflow et je vais le vérifier, mais 9 fois sur 10 c’est le modèle d’embedding qui diffère entre l’insertion et la requête.
Je pense que j’ai configuré le LLM correctement. Et je pense que le problème vient exactement de Supabase parce que quand je regarde dans la base de données Supabase, je ne vois pas les embeddings téléchargés
@Quent cela réduit le champ : succès mais aucune ligne signifie qu’elles se retrouvent quelque part où tu ne cherches pas. Le point clé : le nœud Supabase Vector Store ignore le champ table-name et écrit toujours dans une table littéralement nommée documents (défaut connu). Donc vérifie spécifiquement la table documents, si tu as créé ou vérifies une table avec un nom différent, tes lignes sont dans documents.
Confirme aussi que la table documents a la structure quickstart (id, content, metadata, embedding vector(N)) avec la dimension correspondant à ton modèle d’embedding, si cette colonne manque rien ne persiste.
Si tu vois plutôt une erreur RLS/policy, bascule les identifiants sur ta clé service_role (elle contourne RLS). Mais vérifie d’abord la table documents, c’est généralement là qu’elles sont.
Non, il n’y a pas de table documents. J’ai vérifié les buckets dans le stockage mais je l’ai pas trouvée là, j’ai aussi vérifié les tables dans la db mais je l’ai pas trouvée
Mieux que quand j’ai téléchargé du texte dans Supabase, je ne vois jamais le nœud Supabase interagir avec le modèle intégré
@Quent c’est la cause. Le nœud Supabase Vector Store a besoin d’un sous-nœud Embeddings connecté à celui-ci, le petit port « Embeddings » sous le nœud. Si rien n’est branché à cet endroit, le nœud n’a pas de modèle pour convertir votre texte en vecteurs, donc l’insertion ne stocke rien d’utilisable, ce qui explique exactement pourquoi tu ne vois jamais le nœud interagir avec un modèle d’embedding.
Connecte un nœud Embeddings (Embeddings OpenAI, ou n’importe quel fournisseur) à ce port sur le nœud Vector Store, puis relance l’exécution, tu verras des lignes avec des embeddings apparaître dans la table documents. Un point à retenir pour plus tard : utilise exactement le même modèle d’embeddings du côté requête aussi, sinon la récupération ne correspondra pas.
Si vous ne voyez pas la table documents dans Supabase du tout, cela signifie que la table n’a jamais été créée - n8n ne la créera pas automatiquement pour vous. Allez dans Supabase > SQL Editor et exécutez ceci :
create extension if not exists vector;
create table documents (
id bigserial primary key,
content text,
metadata jsonb,
embedding vector(1536)
);
create index on documents using ivfflat (embedding vector_cosine_ops);
Remarque : changez 1536 pour qu’il corresponde à la dimension de votre modèle d’embedding (OpenAI text-embedding-3-small = 1536, text-embedding-3-large = 3072). Une fois que la table existe, réexécutez votre workflow de téléchargement et vous devriez voir des lignes apparaître dans la table documents sous Table Editor.
Maintenant je vois la table documents, mais je ne vois pas les lignes de cette table. Quand j’ai téléchargé du texte dans ma table workflow, cela n’a pas rempli ma table.
Salut @Quent, puisque la table existe mais n’a toujours zéro ligne, l’insertion elle-même échoue probablement en silence.
Vérifications rapides :
Clique sur le nœud Vector Store après une exécution et vérifie sa sortie réelle, une coche verte sur le workflow ne signifie pas toujours que ce nœud a vraiment écrit les données.
Confirme qu’il est réglé en mode « Insert » et non « Retrieve ».
Essaie la clé service_role au lieu de anon, RLS peut bloquer silencieusement les insertions sans erreur visible.
Si rien ne s’affiche, une capture d’écran de la sortie d’exécution réelle du nœud (pas seulement le canevas) aiderait à identifier le problème rapidement.
Je suis d’accord avec @achamm, les incompatibilités d’embedding sont de loin la #1 cause.
Deux points supplémentaires à vérifier si ses corrections ne résolvent pas le problème :
- Dimension de la colonne vector Supabase : quand vous avez créé la table, la colonne
embeddinga une taille fixe (par ex.vector(1536)). Si votre modèle d’embedding génère une taille différente, les insertions peuvent échouer silencieusement ou la recherche ne retourne rien. Exécutez\d documentsdans l’éditeur SQL de Supabase pour confirmer que la dimension correspond à votre modèle. - Chunking + top_k : si vos chunks sont trop volumineux (pages complètes) ou si votre
top_kest trop bas (comme 1), le retriever risque de récupérer un chunk qui ne contient pas vraiment la réponse. Commencez par des chunks d’environ 500 tokens et top_k = 4-5.
Partagez le workflow s’il ne fonctionne toujours pas après ça !
J’ai déjà résolu ce problème. Merci à vous tous