Reranking dans un RAG n8n : pourquoi le top-k de la recherche vectorielle ne suffit pas

Un chatbot RAG branché sur Supabase pgvector répond parfois à côté alors que la bonne information est bel et bien dans la base documentaire — elle est juste sortie en position 8 ou 12 du match_documents, jamais injectée dans le prompt parce que seul le top 4 ou 5 est retenu. Le problème n'est pas le LLM, ni le découpage des documents : c'est que la recherche vectorielle, prise seule, n'est pas conçue pour classer finement des résultats déjà proches les uns des autres. Une étape de reranking entre la recherche et la génération corrige précisément ce point faible.

Le compromis que fait toute recherche vectorielle

Un embedding encode un texte en un vecteur unique, calculé une fois pour toutes, indépendamment de la question qui sera posée plus tard. C'est ce qui rend la recherche vectorielle rapide : comparer la question à des milliers de vecteurs pré-calculés ne coûte qu'une similarité cosinus par candidat. Mais cette rapidité a un prix — le modèle qui produit les embeddings, un bi-encoder, n'a jamais vu la question et le passage ensemble au moment de les encoder. Le papier qui a popularisé cette architecture, Sentence-BERT de Reimers et Gurevych (EMNLP 2019, voir sur Google Scholar), le formule clairement : c'est justement ce qui permet de réduire la recherche du meilleur candidat parmi des milliers de textes de plusieurs dizaines d'heures à quelques secondes — au prix d'une précision de classement moins fine qu'une comparaison directe question-par-question.

Résultat concret dans un pipeline RAG n8n : le top 20 retourné par match_documents contient presque toujours le bon passage, mais rarement en première position. Si le prompt n'en retient que les 4 ou 5 premiers résultats bruts, une partie des bonnes réponses est écartée avant même d'atteindre le LLM.

Le reranking : un second modèle, plus lent mais plus précis

Un reranker est un cross-encoder : contrairement au bi-encoder, il prend la question et chaque passage candidat ensemble en entrée, et calcule un score de pertinence spécifique à cette paire. Nogueira et Cho ont montré dès 2019 avec leur reranker BERT (« Passage Re-ranking with BERT » — Google Scholar) que cette approche améliore nettement le classement par rapport à une similarité vectorielle seule sur des benchmarks de recherche de passages comme MS MARCO — au prix d'un calcul par paire, donc impossible à appliquer à toute une base documentaire, mais parfaitement adapté à un petit lot de candidats déjà présélectionnés.

C'est exactement l'architecture à deux étages (two-stage retrieval) à reproduire dans n8n :

1. Recherche vectorielle large — récupérer 20 à 50 candidats avec match_documents plutôt que les 4-5 habituels, pour maximiser les chances que le bon passage soit dans le lot.
2. Reranking — un cross-encoder note chaque candidat par rapport à la question exacte posée.
3. Sélection finale — ne garder que les 3 à 5 meilleurs passages après reranking pour construire le prompt.

Implémentation concrète dans un workflow n8n

En reprenant le pipeline décrit dans notre guide RAG avec Supabase pgvector, l'ajout du reranking se glisse entre la recherche et la génération, sans toucher à l'ingestion ni au chunking :

1. Node Supabase / Postgres — appeler match_documents avec match_count: 25 (au lieu de 5) pour obtenir une large short-list de candidats.
2. Node HTTP Request — envoyer la question et les 25 passages à une API de reranking. Avec l'API Cohere Rerank par exemple, le corps de la requête est simplement {"query": "...", "documents": ["chunk 1", "chunk 2", ...], "top_n": 5}, qui renvoie directement les index triés par score de pertinence.
3. Node Code — reconstituer, à partir des index renvoyés, les chunks originaux avec leurs métadonnées (source, page), pour ne pas perdre les informations de citation utilisées dans le chatbot avec citations.
4. Node IA (chaîne LLM) — injecter uniquement ces 5 passages reclassés dans le prompt final, comme dans un pipeline RAG classique.

Pour un déploiement self-hosted sans dépendance à une API tierce, un modèle cross-encoder open source léger (ms-marco-MiniLM-L-6-v2 par exemple) peut tourner derrière une petite API Python appelée par le même node HTTP Request — le reste du workflow n8n ne change pas.

L'ordre des passages dans le prompt compte aussi

Reranker les passages ne sert pas qu'à choisir lesquels garder : l'ordre dans lequel ils sont ensuite injectés dans le prompt influence la qualité de la réponse. Un LLM exploite mieux l'information placée en début ou en fin de contexte que celle noyée au milieu — un phénomène documenté dans l'article « Lost in the Middle » de Liu et al. (TACL, voir sur Google Scholar). Concrètement dans le node Code qui construit le prompt : placer le passage le mieux noté par le reranker en tout premier (et éventuellement dupliquer son idée clé dans la consigne finale) plutôt que de laisser l'ordre brut de la base vectorielle, qui n'a aucune raison de correspondre à la pertinence réelle.

Coût et latence : quand ça vaut le coup

Reranker 20 à 50 candidats ajoute typiquement 200 à 500 ms par requête — négligeable face aux quelques secondes que prend déjà la génération de la réponse par le LLM, à condition de respecter les bonnes pratiques de rate limiting si le volume de requêtes est élevé. Côté coût, l'API Cohere Rerank facture au nombre de documents évalués plutôt qu'au token, ce qui reste marginal comparé au coût de génération d'une réponse complète par un LLM.

Le reranking n'est cependant pas toujours nécessaire. Sur une petite base documentaire homogène (quelques dizaines de pages bien découpées), la recherche vectorielle seule remonte déjà les bons passages en tête la plupart du temps — ajouter un étage supplémentaire n'apporte alors qu'une complexité de plus pour un gain marginal. Le reranking devient rentable à partir du moment où la base documentaire grossit, se diversifie (plusieurs types de documents, plusieurs sources), ou que les retours utilisateurs signalent des réponses « à côté » alors que l'information existe bien quelque part dans la base.

Pièges fréquents

• Reranker trop peu de candidats : passer de 5 à seulement 8-10 candidats en entrée du reranker ne change presque rien — l'intérêt vient de partir d'un lot large (20-50) pour vraiment donner une chance au bon passage d'être présent.
• Oublier de remonter les métadonnées : l'API de reranking renvoie des scores associés à des index ou à du texte brut ; si les métadonnées (source, page) ne sont pas correctement réassociées après reranking, les citations affichées à l'utilisateur deviennent fausses ou disparaissent.
• Reranker sur toute la base : appliquer un cross-encoder directement sur des milliers de documents au lieu d'un lot déjà présélectionné par recherche vectorielle ruine la latence — le reranking n'a de sens qu'en second étage, jamais en remplacement de la recherche vectorielle.
• Ignorer le seuil de score : un reranker attribue un score à chaque candidat, y compris aux mauvais ; sans seuil minimal, un passage clairement hors sujet peut quand même être injecté dans le prompt s'il n'y a pas assez de bons candidats disponibles.

Pour aller plus loin

Le Pack Assistant RAG (119 €) fournit les quatre workflows d'ingestion, de chat avec citations, de synchronisation Notion et d'API question-réponse déjà décrits dans nos guides sur pgvector et le choix d'index HNSW/IVFFlat — l'ajout d'un étage de reranking comme celui-ci s'intègre directement en aval du node de recherche vectorielle fourni, sans modifier le reste du pipeline. Si votre assistant documentaire répond parfois à côté malgré une base bien construite, c'est souvent la première amélioration à tester avant de revoir le chunking ou de changer de modèle d'embedding.