Au-delà de Top-K : seuils de pertinence, recherche hybride et réclassement dans RAG
Découvrez pourquoi une base de données vectorielle associée à un LLM ne constitue pas un système RAG opérationnel, et comment le découpage en chunks, les seuils de similarité, la recherche hybride, le réclassement et l’évaluation comblent cette lacune.
La génération augmentée par la récupération d’informations est généralement présentée comme une méthode en trois étapes : trouver des documents liés à la question, les transmettre à un modèle de langage et le laisser rédiger la réponse. Le schéma est simple ; en faire une solution fiable, ce n’est pas le cas. Un pipeline qui relie directement une recherche par embedding à un LLM donnera des réponses assurées même avec un contexte limité, manquera les identifiants exacts et inventera des réponses lorsque la base de connaissances ne contient aucune information. C’est là que ce design naïf échoue, et c’est à quelles étapes – allant du découpage en segments tenant compte de la structure jusqu’à l’évaluation mesurable – il se transforme en une architecture de récupération d’informations fiable.
Le pipeline naïf et ses hypothèses cachées
La base de référence des tutoriels les plus courants est la suivante : diviser les documents en blocs, les intégrer, stocker les vecteurs, puis, au moment de la requête, intégrer la question, récupérer les top_k blocs les plus proches et les coller dans le prompt. Cette méthode fonctionne bien en démonstration, mais elle suppose implicitement que chaque bloc constitue une unité significative et que « le plus proche » signifie « pertinent ».
Blocage selon la structure du document
Prenons par exemple un manuel des employés. L’approche faible le divise en tronçons arbitraires de 1 000 caractères, ce qui entraîne parfois la séparation d’une politique en deux et le collage de la fin d’un sujet au début d’un autre. L’approche plus solide suit plutôt le plan propre au document, produisant des blocs tels que Travail à distance, Sécurité, Congés payés et Dépenses.
Une section autonome fournit au modèle d’incorporation suffisamment de contexte pour comprendre de quoi traite réellement le texte et comment ses affirmations sont liées entre elles. Les vecteurs obtenus sont plus propres, et la recherche sémantique renvoie davantage de résultats pertinents.
Top-K affiche les résultats les plus proches, pas ceux qui sont pertinents
De meilleures divisions en segments mènent directement à une nouvelle idée fausse. Définir top_k = 5 est souvent interprété comme « donnez-moi les cinq résultats pertinents ». En réalité, cela demande simplement les cinq résultats les plus proches, qu’ils soient pertinents ou non. Une distribution typique des scores pour une question sur le télétravail pourrait être :
Remote Work 0.62
Paid Time Off 0.36
Security 0.30
Expenses 0.28
Other Policy 0.24
La première réponse correspond probablement à ce dont a besoin l’utilisateur. Les quatre autres sont des correspondances faibles qui figurent sur la liste uniquement parce qu’il fallait remplir des places. Fournir les cinq résultats au modèle mélange des informations utiles avec du texte potentiellement utile mais peu lié et irrelevant. Le modèle doit alors séparer lui-même le signal du bruit, ce qui augmente les coûts de traitement et rend la réponse moins prévisible.
Les questions sans réponse nécessitent un traitement spécifique
Un cas particulièrement important concerne les questions que la base de connaissances ne peut tout simplement pas répondre, comme « Quel est le montant de la franchise de l’assurance maladie de l’entreprise ? » lorsque le manuel n’en parle jamais. La méthode Top-K renverra néanmoins cinq extraits, et un processus naïf traitera le plus proche comme preuve pour faire une estimation.
Le comportement approprié dans un environnement d’entreprise consiste à indiquer que les documents disponibles ne contiennent pas suffisamment d’informations. Un système bien conçu doit être capable de renvoyer quelque chose comme ceci :
No sufficiently relevant context was found.
Ajouter un filtre de pertinence entre la récupération et le modèle
Gérer à la fois les correspondances faibles et les questions sans réponse nécessite une étape supplémentaire. Le flux naïf est le suivant :
Vector Search
↓
Top-K
↓
LLM
Le flux amélioré traite Top-K comme une liste de candidats et insère un filtre avant le modèle :
Vector Search
↓
Top-K candidates
↓
Relevance Filter
↓
LLM
Le filtre le plus simple est un seuil de similarité. Les candidats atteignant ou dépassant ce seuil sont retenus :
score >= threshold
→ keep
et tout ce qui est en dessous est éliminé :
score < threshold
→ discard
Si aucun candidat n’est retenu, le système renvoie la réponse « pas de contexte pertinent » au lieu d’appeler le modèle avec des données brouillées.
Sélection du seuil à partir de mesures
Le seuil doit être déterminé à partir des données. Une petite expérience menée sur un ensemble de données de manuel d’entreprise a comparé le taux de rappel pour les requêtes répondables (« connues ») avec le taux de rejet pour celles qui ne peuvent pas être répondues (« inconnues »), en examinant plusieurs valeurs :
| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
| 0.20 | 100% | 0% |
| 0.25 | 100% | 0% |
| 0.30 | 100% | 50% |
| 0.35 | 100% | 50% |
| 0.40 | 100% | 50% |
| **0.45** | **100%** | **100%** |
| 0.50 | 100% | 100% |
| 0.55 | 100% | 100% |
Dans cet ensemble de données, 0,45 était le premier seuil qui permettait de conserver toutes les requêtes connues tout en rejetant celles inconnues, ce qui en faisait la meilleure valeur de séparation parmi celles testées. Ce chiffre n’est pas portable : les scores de similarité dépendent du modèle d’incorporation, du corpus, de la formulation des requêtes et de la configuration de récupération ; différents modèles distribuent leurs scores dans des plages très variées. Le taux de rejet, qui augmente par étapes de 50 %, indique également l’existence d’un très petit nombre de requêtes inconnues ; par conséquent, toute mise en œuvre réelle nécessite un ensemble plus important de données étiquetées avant de pouvoir se fier à ce seuil. Ce qui est transférable, c’est la méthode : mesurer le comportement de récupération pour les questions connues et inconnues, puis choisir le seuil en se basant sur des données concrètes et non sur l’intuition.
La récupération et le classement sont des tâches distinctes
Supposons que la récupération renvoie 20 candidats. Elle a accompli sa mission : elle a trouvé 20 extraits de texte qui semblent être liés. Une deuxième question reste : lesquels de ces 20 sont le meilleur contexte pour cette question en particulier ? C’est là la fonction du reclassement.
La récupération est optimisée pour le taux de rappel sur une grande collection, en réduisant quelque 10 000 éléments à un ensemble de candidats gérable :
10,000 chunks
↓
retrieval
↓
50 candidates
Le reclassement évalue ensuite plus attentivement cet petit ensemble, généralement à l’aide d’un modèle qui lit la question ainsi que chaque candidat ensemble, et conserve les meilleurs éléments :
50 candidates
↓
reranker
↓
5 strongest candidates
Le flux de travail ressemble maintenant à ceci :
Question
↓
Embedding
↓
Vector / Hybrid Search
↓
Candidate Set
↓
Reranking
↓
Best Context
↓
LLM
La recherche sémantique rate les termes exacts
Les embeddings excellent pour interpréter le sens, mais les données d’entreprise sont remplies de tokens dont la valeur réside dans leur orthographe exacte :
INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345
Un modèle d’incorporation peut comprendre qu’une requête concerne une erreur de connexion en classant le fragment contenant le code précis ERR_CONNECTION_RESET en dessous d’un paragraphe général sur les réseaux.
La récupération hybride combine ces deux signaux
La solution standard est la récupération hybride, qui exécute en même temps une recherche sémantique et une recherche lexicale :
Semantic Search
+
Keyword / Lexical Search
Les deux recherches sont effectuées pour la même question et leurs résultats sont fusionnés en un seul ensemble de candidats, souvent à l’aide d’une méthode de fusion qui combine les deux classements :
Question
│
┌─────────┴─────────┐
↓ ↓
Semantic Search Keyword Search
│ │
└─────────┬─────────┘
↓
Candidate Set
Le système prend en compte la similarité sémantique pour les questions paraphrasées et une correspondance exacte des termes pour les identifiants.
Le pipeline orienté vers la production
Avec chaque étape en place, le flux complet est :
Documents
↓
Semantic Chunking
↓
Embeddings
↓
Vector / Hybrid Retrieval
↓
Relevance Filtering
↓
Reranking
↓
LLM
↓
Answer + Sources
↓
Evaluation + Observability
Le modèle n’est plus directement situé derrière une base de données vectorielle. Une véritable architecture de récupération se trouve désormais entre l’utilisateur et le LLM. Pour en savoir plus sur l’étape de classement et sur les moments où sa latence est avantageuse, consultez notre article expliquant pourquoi le reranking doit justifier sa latence.
Une base de référence à créer en premier
Un bon moyen d’apprendre ces compromis est de développer progressivement. Une petite base de référence peut combiner Python, FastAPI, des embeddings d’OpenAI et des LLMs, ainsi que Pinecone en tant que stockage vectoriel, avec :
- un découpage en blocs tenant compte des titres et des métadonnées de ces blocs
- une récupération sémantique avec un paramètre
top_kconfigurable - un filtrage par similarité
- une attribution de source
- une évaluation de la récupération
Son flux est :
Question
↓
Embedding
↓
Pinecone Retrieval
↓
Top-K Candidates
↓
Similarity Threshold
↓
Relevant Context
↓
LLM
↓
Answer + Sources
La prochaine étape logique consiste à ajouter des méthodes de récupération hybrides et un réclassement, puis à les comparer avec cette référence en utilisant le même ensemble d’évaluation, afin que chaque amélioration soit mesurée plutôt que supposée.
Mesurer la fiabilité du système
« Le chatbot fonctionne-t-il ? » n’est pas une question utile. Décomposez-la en dimensions que vous pouvez mesurer :
- Qualité de la récupération : les informations correctes ont-elles été obtenues ?
- Qualité du classement : le contexte le plus utile se trouve-t-il en haut de la liste ?
- Fondement des réponses : la réponse est-elle étayée par le contexte récupéré ?
- Précision des citations : les sources citées confirment-elles les affirmations ?
- Gestion des requêtes inconnues : le système reconnaît-il lorsque la réponse n’existe pas dans la base de connaissances ?
L’objectif passe de « l’application peut-elle répondre aux questions ? » à « pouvons-nous mesurer si l’architecture de récupération est fiable ? »
Points clés
- RAG va au-delà de simplement donner à un LLM accès aux documents ; les décisions difficiles concernent ce qui doit être récupéré, en quoi on peut avoir confiance, ce qui doit être transmis et quand refuser.
top_kgarantit la quantité, non la pertinence, il faut donc filtrer les candidats à l’aide d’un seuil calibré sur ses propres données.- La recherche hybride permet de retrouver les identifiants exacts que les embeddings rendent flous, et le réclassement transforme un ensemble de candidats large en un contexte précis.
- La qualité des réponses est déterminée en grande partie avant même que le modèle ne voie un quelconque contexte : un meilleur contexte conduit à de meilleures réponses et à des systèmes plus fiables.
- Considérez le RAG de production comme un problème d’architecture comportant des étapes mesurables, et non comme une simple intégration de LLM.
Lectures complémentaires
- Recherche hybride RAG avec pgvector, BM25 et un rerankeur à encodeur croisé — Découvrez pourquoi la recherche vectorielle pure échoue avec les numéros de pièce et les codes d’erreur, ainsi que la manière de combiner pgvector, BM25 et le reranking dans LangChain pour une recherche RAG précise.
- Choix adapté des LLM : routage, recherche et évaluation indépendamment de la taille du modèle brut — Apprenez à choisir entre des modèles linguistiques petits et grands en fonction de la charge de travail, à mesurer le coût par tâche réussie, et à utiliser d’abord le routage, le RAG, le cache et la validation.
- Concevoir un pipeline RAG fondé sur la réalité : fragmentation, filtrage et diffusion — Une présentation détaillée des fondements d’un pipeline RAG ancré dans la réalité : fragmentation tenant compte de la structure, séparation sécurisée des tokens, filtrage en trois étapes pour la récupération des informations, réassemblage des éléments correspondants, conception de prompts et diffusion en temps réel.