Dix bugs de récupération silencieux dans les systèmes RAG en production, et comment chacun d’eux est corrigé.
Du taille des blocs et de l’overlap à la recherche hybride, RRF, le reranking, le choix des embeddings et les évaluations CI : dix erreurs de récupération à l’origine de réponses RAG incorrectes et leurs corrections.
Un chatbot de support a un jour expliqué, dans une prose charmante, la mauvaise politique de remboursement. Le système avait retrouvé un paragraphe utilisant le mot « remboursement » quatre fois. Il était thématiquement pertinent et décrivait une gamme de produits déscontinuée. Le LLM a fait ce qui lui avait été demandé, à savoir répondre avec assurance en se basant sur le contexte fourni. Personne ne lui avait dit que ce contexte était erroné.
C’est ainsi que se produisent la plupart des échecs liés aux systèmes RAG qui aboutissent à des sessions de débogage. Une équipe passe deux semaines à changer de modèle, à réécrire les instructions du système et à ajouter en gras « répondre uniquement à partir du contexte », mais le taux d’hallucinations ne diminue presque pas. Le problème n’a jamais résidé dans la génération de texte. Le modèle a raisonné correctement à partir de preuves qui étaient déjà fausses dès son arrivée.
Dix erreurs spécifiques détériorent la qualité de la récupération dans les systèmes RAG en production. Elles apparaissent généralement dans une séquence fixe : d’abord les erreurs de segmentation, car elles interviennent avant tout le reste, puis la conception de la récupération, ensuite le choix du réclassement et des embeddings, et enfin le manque de mesures qui permet à toutes ces erreurs de passer inaperçues. Chaque section ci-dessous explique pourquoi l’erreur se produit, quel en est le coût, ce qui doit être modifié, et lorsque les études sont contradictoires, ces contradictions sont rapportées ouvertement.
Pourquoi c’est la récupération qui fait échouer RAG
Les rapports des professionnels sur le RAG en production en 2026 aboutissent toujours au même diagnostic : la plupart des réponses incorrectes sont imputables à l’étape de récupération des données. Les documents erronés reviennent, ou les bons documents échappent à la détection, ou ils se trouvent trop bas dans le classement pour être utilisés. Une estimation courante est d’environ 70 % ou plus. Ce chiffre varie en fonction du rapport et du domaine, ce qui en fait seulement une indication approximative, mais des sources indépendantes concordent sur l’orientation générale. Lorsqu’un système RAG commet une erreur, l’explication la plus probable est que le LLM n’a jamais été présenté aux preuves appropriées ; par conséquent, la première étape consiste à examiner ce que le moteur de récupération a retourné avant d’éditer la demande.
Ces dix erreurs se répartissent en quatre groupes selon le flux de travail. Les points 1 à 4 affectent ce qui est stocké dans le stockage vectoriel. Les points 5 à 7 concernent l’architecture de récupération. Les points 8 et 9 relèvent de l’étape de classement et d’incorporation. Le point 10 concerne le fait que rien de tout cela n’est mesuré.
Terminologie utilisée ci-dessous
- Chunking désigne la division des documents sources en passages avant l’indexation. Les modèles d’incorporation et les fenêtres de contexte fonctionnent mieux avec des unités courtes et ciblées que sur des fichiers entiers.
- Récupération dense (recherche vectorielle) place les requêtes et les chunks dans un même espace d’incorporation et retourne les voisins les plus proches. Elle est efficace pour les paraphrases mais moins performante pour les chaînes de caractères littérales.
- Récupération sparse comme BM25 classe les chunks en fonction des mots en commun avec la requête, en donnant plus de poids aux mots rares. Les codes, noms et jargons correspondent bien, tandis que les synonymes ne le font pas.
- Recherche hybride exécute simultanément les deux méthodes de récupération et fusionne les deux listes classées, le plus souvent à l’aide de la Fusion de rangs réciproques (RRF). La RRF utilise les positions de rang plutôt que les scores bruts, ce qui permet de résoudre le problème de l’incomparabilité des valeurs BM25 et des similarités cosinus.
- Reranking réévalue une courte liste de candidats, généralement de 20 à 100 éléments, à l’aide d’un encodeur croisé qui analyse conjointement la requête et le passage au lieu de les encoder séparément. Le résultat est un classement bien plus précis avant que les k éléments les plus pertinents ne soient transmis au LLM.
Quatre erreurs dans le découpage
1. Préférer un découpage de taille fixe par défaut sans jamais tester d’autres méthodes
Les tutoriels commencent généralement par diviser chaque document en fenêtres de 500 tokens, indépendamment du contenu. Cette méthode prend cinq minutes, fonctionne suffisamment bien pour une démonstration, et les équipes l’adoptent sans la revoir ensuite.
Les études divergent à ce sujet, et le dire est plus utile que de feindre un consensus. Plusieurs comparaisons menées en 2026 privilégient la segmentation fixe ou récursive des tokens par rapport au chunking sémantique. Dans une grande étude comparative de nombreuses stratégies, la segmentation récursive en 512 tokens s’est avérée la plus efficace, en partie parce que le chunking sémantique produisait en moyenne des fragments de seulement 43 tokens, trop petits pour conserver le contexte. D’autres études dans d’autres domaines indiquent le contraire : une évaluation révisée par des pairs du système d’aide à la décision clinique a rapporté une précision de 87 % pour le chunking adaptatif aligné sur le sujet, contre 50 % pour une approche fixe de base (p = 0,001). Une troisième comparaison a montré qu’une taille fixe bien ajustée pouvait égaler ou surpasser la segmentation sémantique sur des ensembles de données réels, ce qui correspond aux passages de 100 mots utilisés dans l’article original sur RAG.
Aucune stratégie ne fonctionne partout. Tout le monde s’accorde sur le fait que l’erreur réside non pas dans le choix d’une segmentation de taille fixe, mais dans le choix d’une stratégie quelconque sans évaluer d’alternative sur le corpus réel.
La réponse pratique consiste à mesurer plutôt qu’à théoriser. Rassemblez de 20 à 50 paires de questions et de réponses représentatives, indexez le même corpus selon deux ou trois stratégies candidates, et comparez le taux de rappel@5 ainsi que la précision contextuelle. Les contenus dotés d’une structure intégrée, tels que les documents API, les documents juridiques et les rapports financiers, obtiennent généralement de meilleurs résultats lorsqu’ils sont d’abord segmentés en fonction de cette structure, puisque ces unités étaient déjà cohérentes :
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Une taille de bloc unique pour chaque type de document
Une taille est choisie une fois, dès le début, sur la base d’une règle empirique, puis appliquée à une collection mixte. Les références API, les documents de politique longs et les transcriptions de conversations reçoivent tous la même taille de bloc.
Les blocs trop grands affaiblissent le signal de pertinence. Un bloc de 2 000 tokens couvrant cinq sujets produit un vecteur qui est une moyenne floue de ces cinq sujets et ne correspond bien à aucun d’eux. Les blocs trop petits font perdre le contexte nécessaire au lecteur, comme une signature de fonction sans ses notes de paramètres ou une clause sans la section qu’elle modifie.
La taille doit correspondre à la densité du contenu. La documentation technique comporte généralement entre 256 et 512 tokens, ce qui permet de concentrer l’attention sur un seul concept. Les textes narratifs ou réglementaires nécessitent généralement entre 1 024 et 2 048 tokens pour conserver le contexte environnant. Il s’agit de points de départ à valider, car le chiffre idéal dépend du modèle d’embedding ainsi que de la manière dont les utilisateurs formulent leurs questions.
3. L’oubli de l’overlap
L’overlap est défini une fois puis oublié, ou ignoré car il serait censé consommer inutilement de l’espace de stockage. Sans lui, une phrase qui dépasse la limite d’un chunk est divisée en deux. Un chunk se termine par l’introduction et le suivant commence par la conclusion, et aucun des deux ne peut être récupéré en tant que pensée complète. C’est une raison courante et entièrement évitable pour les plaintes selon lesquelles la réponse se trouve quelque part mais que le modèle ne parvient pas à la trouver.
Un chevauchement de 10 à 20 % de la taille du bloc constitue une valeur par défaut raisonnable : 50 à 100 tokens pour un bloc de 500 tokens, ce qui est peu coûteux par rapport aux erreurs qu’il permet d’éviter. Plus n’est pas toujours mieux. Un chevauchement beaucoup plus élevé entraîne principalement une augmentation de l’espace de stockage et du bruit informatique ; de plus, une analyse systématique menée en 2026 à l’aide de SPLADE n’a révélé aucun avantage mesurable lié au chevauchement dans ce contexte. C’est le ensemble idéal qui doit trancher, et non la valeur par défaut.
4. Ignorer la structure propre du document
Considérer chaque fichier comme un bloc unique est plus simple, que ce soit une référence API en Markdown, un contrat comportant des clauses numérotées ou un rapport financier riche en tableaux ; cependant, une segmentation sans tenir compte de la structure entraîne fréquemment le détachement d’un en-tête de sa section correspondante ou d’une table du paragraphe qui la décrit. La conséquence typique est une description de fonction séparée de sa liste de paramètres, de sorte qu’une question concernant cette fonction ne donne qu’une réponse incomplète.
La solution consiste d’abord à diviser le texte en fonction de sa structure, c’est-à-dire en fonction des en-têtes, des sections, des listes et des tableaux, et à n’utiliser la segmentation basée sur la taille que dans les sections qui restent trop volumineuses. Vers le milieu de 2026, la plupart des pipelines de segmentation en production sont hybrides pour cette raison : structure en premier, segmentation sémantique dans les longs segments non structurés, taille fixe en dernier recours, sans méthode unique imposée à un corpus mixte.
Trois erreurs dans l’architecture de récupération
5. Utiliser uniquement la recherche vectorielle
Les modèles de base préfèrent par défaut la recherche vectorielle. Il s’agit d’une seule appel API, et elle donne d’excellents résultats dans une démonstration où les requêtes de test sont des paraphrases conversationnelles, ce pour quoi les embeddings denses sont particulièrement efficaces.
Le trafic réel diffère du trafic de démonstration. Les utilisateurs saisissent des codes de produits, des chaînes d’erreurs, des noms de variables, des numéros de tickets et des noms propres, qui sont des tokens littéraux courts. Les modèles denses entraînés pour regrouper le sens ont tendance à les confondre avec des éléments apparentés mais incorrects. Les benchmarks montrent régulièrement cet écart : une configuration hybride optimisée a surpassé chacune des méthodes utilisées séparément dans un test de classement pour le e-commerce, et un benchmark pratique a montré que la méthode de rappel@10 basée uniquement sur des vecteurs était inférieure à une configuration hybride correctement intégrée, principalement en raison de l’omission d’identifiants exacts. Les chiffres varient selon les corpus, mais la tendance reste la même partout où elle a été testée. Lorsque les requêtes combinent des styles conversationnels et des recherches par correspondance exacte, ce qui est presque toujours le cas, la méthode hybride l’emporte.
La modification consiste à ajouter un index BM25 ou SPLADE à côté de l’index vectoriel. Weaviate, Elasticsearch, OpenSearch, Qdrant et Milvus prennent désormais en charge des requêtes hybrides natives, et tant LangChain que LlamaIndex fournissent des récupérateurs de fusion qui les encapsulent :
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Fusion par moyenne pondérée, et non par RRF
Après avoir ajouté BM25, la démarche intuitive consiste à normaliser les deux listes de scores dans la plage de 0 à 1 et à les combiner avec des poids. Cela semble raisonnable dans un tableur. Cependant, les scores BM25 et les similarités cosinus proviennent de distributions sans limite et de formes différentes, et la normalisation min-max est fragile. Un document atypique qui répète un terme de requête des dizaines de fois peut faire chuter tous les autres scores BM25 vers zéro après normalisation, déformant ainsi le classement fusionné de manière difficile à détecter sans recherche approfondie.
La fusion de rangs réciproques évite ce problème en utilisant la position de rang de chaque document dans chaque liste et en ignorant complètement les scores. C’est pourquoi le RRF, et non la moyenne pondérée, est la méthode par défaut dans pratiquement toutes les implémentations hybrides utilisées en pratique, comme mentionné dans les documents techniques de 2026. La formule standard attribue à chaque document la somme de 1 / (k + rang) pour toutes les listes dans lesquelles il apparaît, avec k=60 comme valeur par défaut courante qui atténue l’influence de tout rang extrême.
7. Un k par étape
Le top-k est généralement une constante globale réutilisée lors de la récupération en première étape, lors de la fusion des résultats et pour le prompt final. Lorsque la première étape ne récupère que le nombre limité de fragments que le prompt peut contenir, la capacité de rappel est déjà compromise avant même que le réordonneur ne puisse corriger quoi que ce soit : un fragment classé 14e par la recherche vectorielle n’atteint jamais le prompt. L’erreur inverse consiste à fournir des centaines de candidats à un réordonneur sans effectuer de tri ultérieur, ce qui coûte du temps et de l’argent et remplit le prompt de matériel de faible qualité. L’attention du LLM se dégrade sous cette charge (effet « lost-in-the-middle »), annulant ainsi silencieusement les avantages apportés par le réordonnement.
Pensez plutôt à k comme à un entonnoir. Utilisez un ensemble large au premier stade, d’environ 20 à 100 candidats, afin que le réclassificateur ait la possibilité de corriger les erreurs d’ordre précoces, puis réduisez le nombre à un petit ensemble final de roughly 3 à 8 éléments pour le prompt. Ajustez k pour chaque étape séparément en fonction de l’ensemble d’évaluation, car une seule valeur ne peut servir à ces deux fins.
Deux erreurs dans le classement et les embeddings
8. Omettre le réclassement
Le réclassement ajoute une appel réseau ou une étape d’inférence, ce qui entraîne des délais supplémentaires et, pour les services hébergés, des frais supplémentaires. Sous pression de délai, c’est la première chose à être supprimée, et l’ordre du premier stade est considéré comme définitif.
La recherche vectorielle en première étape repose sur des bi-encodeurs, qui compressent un texte en un vecteur fixe avant même qu’une requête n’existe. C’est ce qui en fait des outils rapides à grande échelle, mais cela limite leur précision, car l’interaction fine entre une requête donnée et un texte donné est perdue. Les cross-encodeurs la restituent en lisant les deux en même temps. Des rapports indépendants de 2026 décrivent le réclassement par cross-encodeur comme l’amélioration la plus efficace à ajouter à un pipeline disposant déjà d’une capacité de récupération de base satisfaisante : des gains de plusieurs points en précision ou en NDCG sont courants, et des résultats de vingt points sont atteints sur des ensembles de données lexicalement difficiles, tout cela avec un temps supplémentaire inférieur à 200 ms pour des tailles de pool raisonnables. Un client de conseil attribue à ce réclassement une amélioration de 23 points en précision sur un projet, ce qui dépasse les effets de tout changement d’embedding ou de taille de chunk. Une fois que la recherche hybride fonctionne, c’est la prochaine étape à essayer.
La modification consiste à insérer une étape de réclassement entre la fusion et le prompt final. Pour l’hébergement propre sans frais par appel, bge-reranker-v2-m3 est un encodeur croisé ouvert populaire offrant une bonne couverture multilingue. L’API Rerank de Cohere constitue l’alternative gérée habituelle lorsque l’infrastructure GPU n’est pas souhaitée. Ces deux solutions s’intègrent toutes deux à LangChain et LlamaIndex :
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Un modèle d’incorporation général sur un corpus spécialisé
Le modèle d’incorporation fourni avec le framework est souvent appliqué directement à un corpus juridique, médical ou financier, justifié par quelques vérifications manuelles ponctuelles. Les modèles polyvalents apprennent à partir de textes provenant d’Internet et d’encyclopédies, ce qui les amène à moins bien distinguer le jargon spécialisé que les modèles entraînés sur des documents sectoriels. Ce défaut est particulièrement préjudiciable là où les enjeux sont les plus élevés. Dans les domaines réglementés, une erreur mineure, comme l’inclusion d’un passage sur la procédure standard au lieu de l’exception spécifique demandée, produit une réponse plausible mais fondamentalement fausse, ce qui est pire qu’une erreur évidente.
Avant de valider, exécutez au moins un module d’incorporation adapté ou affiné au domaine par rapport à la version par défaut générale sur l’ensemble de référence. Lorsque l’affinage d’un tel module n’est pas possible, un réclassificateur à codeur croisé entraîné sur un petit ensemble de requêtes de domaine étiquetées comble souvent la majeure partie du déficit plus rapidement et à moindre coût, car il corrige les erreurs de la première étape sans devoir réincorporer l’ensemble du corpus.
L’erreur qui cache les autres
10. Facturation en fonction des impressions
L’évaluation de l’infrastructure est perçue comme une charge supplémentaire par rapport au développement des fonctionnalités, et il semble suffisant de jeter un coup d’œil à quelques résultats lorsque la démonstration a l’air bonne. C’est de loin la source de coûts la plus importante, car elle masque les neuf autres problèmes. Les hallucinations basées sur un contexte récupéré, les documents corrigés dans le mauvais ordre, ainsi que les segments coupés au mauvais endroit ne peuvent pas être détectés de manière fiable en se contentant de lire les résultats, et au moment où les utilisateurs les signalent, ils sont déjà en production.
La solution consiste en un ensemble « doré » de 50 à 200 paires de questions-réponses représentatives, couvrant des cas limites tels que des formulations ambiguës, des questions nécessitant deux documents pour être résolues ou des reformulations malveillantes. Il faut évaluer cet ensemble à l’aide d’un panel standard divisé en deux parties : le système de récupération est jugé en fonction de la précision et du rappel contextuel, tandis que le générateur est évalué sur sa fidélité et le degré de pertinence de la réponse fournie. Deux frameworks dominent ce domaine, et les équipes les combinent souvent. Ragas est l’outil habituel pour explorer les métriques, et son générateur synthétique permet de créer un ensemble « doré » à partir du corpus afin qu’une personne puisse le affiner. DeepEval, basé sur pytest, constitue la méthode courante pour intégrer l’évaluation comme étape obligatoire dans les processus CI. Une répartition courante consiste à utiliser Ragas pour l’exploration et la génération de données, et DeepEval pour valider chaque demande de fusion de code :
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Intégrez une telle solution dans CI afin qu’un ajustement lié au découpage des données, un remplacement d’éléments intégrés ou une mise à jour de la base de connaissances qui détériore les résultats de recherche empêche la compilation avant que cela ne gâche la journée d’un client.
Comment les erreurs varient selon l’environnement
- Recherche interne d’entreprise et Q&A sur les documents, le cas le plus courant, dépend fortement d’une recherche hybride. Le personnel colle des numéros de tickets, des codes de politique et des SKU aux côtés de questions en langage courant, mais la recherche basée uniquement sur du texte dense rate systématiquement la partie littérale des questions.
- Bots de support destinés aux clients tirent le plus grand profit du réclassement des résultats. Une réponse fluide mais erronée se transforme alors en ticket ou en perte de compte, au lieu d’un simple haussement d’épaules de la part d’un collègue.
- Les industries réglementées (finance, santé, droit) exigent des embeddings adaptés au domaine ou des outils de réclassement, ainsi qu’une évaluation stricte, car une récupération imparfaite expose à des problèmes de conformité et de responsabilité juridique.
- Les produits grand public à fort trafic fonctionnent dans des limites de latence très strictes pour la fusion des résultats et leur réclassement. L’objectif est d’atteindre la meilleure précision possible tout en restant dans un budget de récupération inférieur à 200 ms, ce qui favorise l’utilisation de petits encodeurs croisés ou de outils de réclassement gérés localement sur GPU plutôt que des modèles de très grande taille.
- Les assistants de codage et les plateformes d’outils pour développeurs représentent un cas plus récent en pleine expansion, où le découpage en blocs tenant compte de la structure est plus important que dans le texte narratif. Le code et les références API sont fortement structurés, et un découpage négligent détruit précisément cette structure qui permettait de les rechercher.
Choisir la prochaine étape
Pendant la phase pré-lancement, ou alors que l’on teste encore si RAG est même viable, une recherche basée uniquement sur des vecteurs constitue un bon point de départ : elle se met en place le plus rapidement et permet de répondre à la question relative à l’architecture en l’espace d’une journée. Une fois que des requêtes réelles des utilisateurs existent, il faut analyser les journaux pour identifier des motifs de correspondance exacte tels que des codes de produit, des identifiants de ticket et des valeurs de configuration. Si de tels éléments apparaissent, il convient d’ajouter d’abord BM25 combiné à RRF, car les sources indiquent systématiquement que c’est l’amélioration la plus significative en termes de récupération des données, de loin. La réclassification suit ensuite, lorsque la recherche hybride fonctionne et que l’objectif est la précision plutôt que le simple taux de récupération. Cette méthode est peu coûteuse par rapport aux résultats obtenus et ne nécessite pas de reconstruction de l’index. SPLADE ou des embeddings adaptés au domaine devraient être réservés aux équipes disposant d’un processus d’évaluation mature, qui a déjà démontré que la combinaison de recherche hybride et de réclassification laisse un déficit, car ils exigent plus d’efforts et de maintenance et sont difficiles à justifier en l’absence de métriques de référence.
Le nombre d’employés et le budget changent la réponse. Avec deux ingénieurs, une API de réclassement gérée (Cohere est généralement le choix privilégié) est plus avantageuse que d’exécuter un encodeur croisé en interne : avec un trafic modéré, les frais restent faibles par rapport aux heures consommées par les serveurs GPU. Lorsque du personnel dédié aux MLOps et des GPU sont déjà disponibles, ou que le trafic est suffisamment important pour que la facturation par requête devienne un poste important, il est plus judicieux d’héberger un modèle open source comme bge-reranker-v2-m3.
Le coût d’un bon pipeline
RAG n’est pas une solution parfaite. Sa principale force réside dans son ancrage : les réponses peuvent citer des sources récupérées au lieu de s’appuyer uniquement sur ce que le modèle a mémorisé, et la base de connaissances peut être mise à jour sans réentraînement. Cependant, cette mécanique supplémentaire représente un vrai fardeau opérationnel. Il faut maintenir en synchronisation deux index, un outil de réclassification pour détecter les écarts, un processus d’évaluation à considérer comme un élément essentiel, ainsi qu’un système de segmentation qui doit être réexaminé lorsque la composition des documents change.
RAG ne supprime pas non plus les hallucinations. Il réduit les inventions dues à un manque de connaissances, mais ne traite pas le cas où le LLM interprète ou applique incorrectement un contexte qui lui a été fourni correctement. Des métriques de fidélité existent parce que « ancré dans un contexte récupéré » et « correct » sont des propriétés distinctes, et un processus mature mesure les deux.
Prêt pour la production
- Évaluation en temps réel. Exécuter les tests Ragas et DeepEval pour chaque modification de prompt, de système de récupération ou de base de connaissances, plutôt que de les vérifier une seule fois au lancement.
- Synchronisation de l’index. Mettre à jour les index BM25 et vectoriels ensemble ou selon le même calendrier. Lorsqu’un index obsolète coexiste avec des embeddings récents, la récupération des données dévie de manière difficile à détecter.
- Observabilité. Enregistrer les fragments récupérés pour chaque requête, et non seulement la réponse finale. Cela permet de déterminer si une mauvaise réponse provient de la récupération des données ou de leur génération, sans avoir à spéculer.
- Credenciaux. Conserver les clés API de réclassement et d’embedding en dehors du répertoire de code et les faire tourner via le gestionnaire normal des secrets.
La leçon principale
Regardez ce que le système de récupération a retourné avant de modifier la requête ou le modèle. Neuf des dix erreurs (fragmentation insuffisante, absence de recherche hybride, fusion naïve, pools de candidats de taille inadaptée, omission du réclassement, modèle d’incorporation non vérifié) sont des problèmes de récupération pour lesquels il existe des solutions. La dixième erreur, l’absence d’évaluation, est la raison pour laquelle les neuf autres passent si souvent inaperçues.
Aucune de ces solutions n’exige une équipe de recherche. Ajouter BM25 à côté d’un stockage vectoriel existant, remplacer le mélange des scores par RRF ou supprimer une étape de réclassement entre la fusion et la génération relève davantage d’un travail d’ingénierie qu’à une refonte, et chacune de ces approches bénéficie d’un soutien cohérent dans des sources indépendantes, même lorsque les chiffres diffèrent. Un point de départ pratique : récupérez deux semaines de requêtes réelles des utilisateurs, comptez combien contiennent des identifiants exacts que la recherche vectorielle flouterait, puis créez un ensemble de référence de 50 requêtes à partir des échecs déjà disponibles. Cela semble moins complexe qu’il n’y paraît, et cela permet de déterminer quelles sont les dix erreurs les plus coûteuses.
Lectures complémentaires
- Déboguer les échecs silencieux du RAG : récupération, segmentation en blocs, filtres et évaluations — Les réponses générées par RAG peuvent sembler correctes tout en étant fausses. Un guide conçu pour les développeurs Python afin de tracer la récupération des données, la segmentation en blocs, les filtres de métadonnées, les évaluations, les recherches hybrides et les mécanismes de contextualisation.
- RAG hybride pour les textes juridiques : segmentation en blocs, BM25, BGE et réclassement — Un pipeline RAG pour la recherche juridique basé sur la Constitution de l’Inde : segmentation en blocs hiérarchiques, récupération des données via BM25 et BGE, fusion des classements, réclassement à l’aide d’un encodeur croisé et expansion des requêtes, testé sur des benchmarks.