Décrivez le problème/l’erreur/la question
Je suis en train de construire un flux de travail IA qui utilise un Vector Store Receiver connecté à PGVector. La plupart du temps, il récupère le bon document, mais occasionnellement un document moins pertinent est classé plus haut que celui que j’attendais réellement. J’ai déjà confirmé que les documents sont correctement incorporés et que le même modèle d’incorporation est utilisé pour l’indexation et l’interrogation. Y a-t-il quelque chose à examiner pour améliorer la qualité de la récupération ?
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre flux de travail
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
- Version n8n : 1.123.x
- Base de données (défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
Hé @Oluwanifemi, en attendant une réponse, voici quelques ressources qui pourraient vous aider :
Ressources suggérées
Automatiquement mises en correspondance avec votre question.
Docs :
Forum :
@merarisosa, @jabbson - vous avez déjà aidé à résoudre des problèmes similaires, pourriez-vous jeter un œil ?
Suggéré automatiquement par le bot communautaire de n8n. C’est un essai - veuillez partager vos commentaires ici.
Salut @Oluwanifemi
Si un document moins pertinent se classe plus haut, c’est souvent parce que le message central du document pertinent a été « dilué » par le texte environnant dans son chunk, ou que le chunk était trop petit pour fournir suffisamment de contexte.
- Ajustez la taille et le chevauchement des chunks : Dans votre nœud Text Splitter, expérimentez avec la taille des chunks. Si les chunks sont trop grands (par exemple, >1000 tokens), ils contiennent plusieurs sujets, ce qui rend le vecteur une « moyenne » de concepts non liés. S’ils sont trop petits (<200 tokens), ils manquent de contexte. Essayez une taille entre 400–800 tokens avec un chevauchement de 10–20 %.
- Ajoutez du contexte aux chunks : Si vous divisez de gros fichiers PDF ou markdown, ajoutez en préfixe le titre du document ou l’en-tête de section à chaque chunk avant d’incorporer. Vous pouvez le faire en utilisant un nœud Edit Fields (Set) ou un nœud Code juste avant Vector Store Receiver. Cela force le modèle d’incorporation à ancrer le vecteur au contexte du document/de la section spécifique.
Les bases de données vectorielles calculent la distance entre les points à l’aide de formules mathématiques. Si la métrique ne correspond pas à la façon dont votre modèle d’incorporation spécifique a été entraîné, les classements seront faussés.
- Vérifiez le nœud PGVector : Dans votre configuration de Vector Store Tool / nœud PGVector, assurez-vous que la métrique de similarité est définie sur Cosine Distance (ou Cosine Similarity). La plupart des modèles d’incorporation modernes (comme
text-embedding-3-* d’OpenAI, Cohere et Mistral) sont optimisés pour la similarité cosinus. Si elle est définie sur L2 (euclidienne) ou Inner Product, cela peut faire que les documents non pertinents obtiennent un score plus élevé.
Ça vous aide ?
Il vaut la peine de vérifier quel type d’index se trouve sur votre colonne PGVector. S’il s’agit de ivfflat ou hnsw, cela signifie que vous effectuez une véritable recherche des voisins les plus proches approximatifs. Si vous utilisez les paramètres par défaut, « approximatif » peut finir par signifier que la correspondance réelle la plus proche est manquée et non simplement déprioritisée.
Pour ivfflat, vérifiez votre nombre de listes et augmentez les « probes » au moment de la requête. Plus de probes se rapproche d’une recherche exacte, mais même un nombre de probes plus élevé n’est pas garanti comme équivalent. Pour hnsw, vérifiez « ef_search ». C’est quelque chose de rapide à éliminer avant d’essayer de réclasser votre recherche, surtout parce que cela pourrait être un simple changement SQL sur une ligne.
Salut @Oluwanifemi
Le nœud du magasin vectoriel a des modes insertion, récupération et recherche, mais pas de remplacement ou suppression, donc chaque exécution de votre flux de travail d’ingestion ajoute une copie nouvelle de chaque fragment au lieu de mettre à jour les lignes déjà présentes. Les anciennes copies quasi identiques entrent alors en concurrence avec le fragment actuel et peuvent occuper les meilleurs emplacements du récupérateur, ce qui apparaît exactement comme un mauvais document qui gagne occasionnellement. Comptez les lignes et comparez avec ce qu’un seul passage d’ingestion devrait produire :
SELECT count(*) FROM your_table;
Si le résultat est un multiple de ce que vous attendez, videz la table, indexez une fois, puis supprimez les lignes d’une source avant de la réindexer à partir de là.
Plus d’informations sur la configuration RAG plus large ici :
https://axshul.site/n8n/guide/vector-stores-and-rag/
Si vous avez déjà exclu une incompatibilité de modèle d’embedding, je regarderais comment les documents sont fragmentés. Beaucoup de problèmes de récupération proviennent de fragments contenant plusieurs sujets, ce qui rend l’embedding moins ciblé
Une autre chose à vérifier est si vos documents contiennent beaucoup de formulations répétées ou de modèles. Si chaque enregistrement commence par les mêmes paragraphes, les embeddings finissent par être plus proches les uns des autres que prévu, ce qui rend plus difficile pour PGVector de classer la meilleure correspondance
Enfin, ne vous fiez pas trop au score de similarité lui-même. Comparez plutôt les 5 meilleurs résultats. Si le bon document apparaît systématiquement près du début mais pas en premier, c’est généralement un problème de qualité des données plutôt qu’un problème avec PGVector
Salut @Oluwanifemi
Ce n’est pas un bug. C’est le comportement normal de la recherche vectorielle en une seule étape : la similarité cosinus mesure la similarité thématique, pas la pertinence. Quand deux chunks sont à une distance cosinus de ~0,03, lequel se classe en premier est essentiellement du bruit. Le fait que vos embeddings soient corrects n’empêche pas cela.
Solution (5 minutes, native dans n8n depuis 1.98) :
- Sur votre nœud PGVector Vector Store, réglez Limit sur
20 (la valeur par défaut est 4).
- Options → Ajouter une option → Rerank Results → activez.
- Un connecteur Reranker apparaît en bas du nœud — attachez un sous-nœud Reranker Cohere, modèle
rerank-v3.5.
- Laissez le Vector Store Retriever et le câblage de la chaîne tels quels.
Pourquoi ça fonctionne : votre modèle d’embedding a encodé les documents sans jamais voir la requête. Le reranker est un cross-encoder — il lit la requête et le chunk ensemble et évalue la pertinence réelle. Trop lent pour l’ensemble du corpus, idéal sur 20 candidats.
Réglez Limit comme un nombre simple, pas une expression — n8n#14151 ignore silencieusement les expressions là et revient par défaut à 4.