Recherche hybride et reranking : diagnostiquer le passage introuvable avant le LLM

La procédure existe, son titre apparaît dans le stockage et le chatbot répond pourtant avec une règle générale. L’équipe allonge le prompt, ajoute une consigne de citation et obtient une phrase plus convaincante. Le passage qui précise la reprise sélective n’a toujours pas été remis au modèle. Le problème se trouve dans la récupération ; améliorer la formulation peut seulement rendre son absence plus difficile à voir.

En pratique, une recherche RAG se diagnostique par la présence du passage nécessaire à chaque étage, avant la réponse finale. Recherche lexicale, vecteurs, fusion et reranking ne résolvent pas les mêmes pertes. Un chatbot RAG relié aux sources de l’entreprise doit conserver les traces qui permettent de distinguer document non indexé, document exclu et document disponible mais mal classé.

Nous comparons six variantes sur des documents fictifs : BM25 réellement exécuté dans SQLite, cosinus sur des vecteurs manuscrits, fusion RRF et reclassement par règle. Aucun embedding ou reranker appris n’est utilisé, et aucun LLM ne produit de réponse. Dans une IA documentaire sur mesure, la question sur une référence produit doit permettre de suivre le passage attendu depuis la sélection des sources jusqu’au contexte final. Ce banc montre où le passage se perd ; il ne mesure pas une qualité sémantique de fournisseur.

Pour qui vérifier les passages avant de changer le prompt

Reconnaître une réponse privée de sa condition décisive

Le diagnostic concerne une équipe qui interroge procédures, notices ou documentation technique et sait identifier la pièce attendue pour une question. La réponse peut citer un document de la bonne famille tout en omettant l’exception qui commande l’action. Une preuve générale sur la synchronisation des tarifs ne suffit pas pour décider si l’on peut relancer le lot entier ou seulement ses lignes refusées.

Le métier doit définir cette condition avant de juger la recherche. Le passage utile n’est pas nécessairement le document dont le titre ressemble le plus à la question. Il peut être une sous-section, une note de version ou une procédure applicable à un seul canal. L’évaluation doit donc conserver référence et contenu attendu, plutôt qu’un verdict vague de « réponse pertinente » impossible à rapprocher aux résultats du moteur.

Choisir les questions qui éprouvent réellement le rappel

Une famille utilise des références exactes, une autre des formulations métier différentes du vocabulaire documentaire, une troisième des conditions composées. Les attentes peuvent exiger plusieurs passages ou une non-réponse lorsque la pièce n’existe pas. Ces familles doivent être examinées séparément. Une réussite sur les codes produit ne démontre pas la couverture des paraphrases ; une bonne paraphrase ne prouve pas la conservation d’une référence presque identique.

Si le problème est une procédure contradictoire ou un droit absent, changer le moteur n’établira pas l’applicabilité. Résolvez d’abord la frontière du corpus et l’attente autorisée. La recherche ne doit pas contourner un refus légitime pour améliorer son rappel. Le service peut répondre que l’information n’est pas disponible dans le périmètre consultable, avec une voie de clarification conçue par le propriétaire métier.

Localiser la perte dans les étages de récupération

Conserver des candidats identifiables à chaque frontière

La chaîne distingue source originale, extraction indexée, corpus admissible, résultats de chaque branche, fusion, candidats de reclassement et passages finalement transmis. Le contrat de trace relie requête, identité imposée, versions et identifiants de candidats. La responsabilité de diagnostic dépend de l’étage défaillant : ingestion, politique d’accès, recherche ou sélection. Le seuil de fenêtre est enregistré, car une pièce peut disparaître sans qu’aucun service ne renvoie d’erreur.

Pour une question en échec, recherchez d’abord l’identifiant du passage attendu dans chaque liste. Présent dans l’index mais absent après filtre : examiner son admissibilité. Présent dans une branche mais absent de la fusion retenue : examiner fenêtre et combinaison. Présent après fusion mais absent du contexte final : examiner reclassement, déduplication et limites de sélection. Cette lecture évite d’attribuer au LLM un document qu’il n’a jamais reçu.

Séparer une correction de corpus d’une correction de classement

Si la condition de reprise a été perdue à l’extraction, aucun score ne la reconstruit comme preuve interne. Si elle figure dans un autre fragment, la recette doit vérifier si la récupération remet les deux pièces ensemble. Si elle est indexée et admissible mais classée trop loin, le problème peut se situer dans les champs, l’analyse de la requête ou la taille de candidats. Ces causes demandent des corrections différentes.

Un premier signal faible est la citation qui ouvre toujours le début d’une procédure, alors que l’opérateur cherche ensuite manuellement la section applicable. Un autre est la référence presque correcte : même famille, autre version ou code voisin. Les deux peuvent produire des réponses fluides. Enregistrez les identifiants et passages effectifs afin de comprendre quelle pièce a remplacé celle attendue.

Établir le passage attendu et son admissibilité

Lire les six pièces du corpus synthétique

Notre question est : « Comment reprendre les tarifs de REF27-ALPHA en relançant uniquement les lignes refusées ? » Le passage D01 est attendu parce qu’il contient cette reprise sélective. Les six documents et leurs métadonnées ont été écrits pour le banc. D04 est une ancienne version inactive ; D06 appartient à B. Seuls D01, D02, D03 et D05 entrent dans les deux branches pour le contexte fictif A.

D01 contient exactement : « REF27-ALPHA. Reprise après erreur de synchronisation des tarifs : contrôler la révision du lot, corriger le mapping puis relancer uniquement les lignes refusées. » Cette phrase fictive sert de preuve attendue. Elle ne décrit aucun logiciel réel ni procédure client. Les listes sont rapprochées à cet identifiant ; un résultat général D02 ne remplace pas automatiquement cette attente.

Appliquer le périmètre aux deux branches

Le contrôleur choisit les documents actifs de A avant de construire l’index FTS5 et la liste vectorielle. D04 et D06 ne peuvent donc contribuer aux rangs ou à la fusion. Ce filtrage est un mécanisme local de la fixture, avec un contexte fixé ; il ne prouve pas une authentification ou un contrôle de droits complet. L’intégration réelle doit vérifier le comportement du moteur et les métadonnées qu’elle utilise.

Un filtre appliqué après une fenêtre courte peut également réduire fortement le nombre de candidats autorisés. Selon le moteur et son mode de recherche, ce comportement doit être observé plutôt que supposé. La trace distingue donc candidat non autorisé, candidat autorisé non retrouvé et candidat supprimé par une règle de version. On ne résout pas un manque de rappel en relâchant silencieusement ces frontières.

Tester la référence exacte avec une recherche lexicale

Inspecter champs, analyseur et expression recherchée

La recherche lexicale réelle utilise SQLite 3.51.2, FTS5 et l’analyseur unicode61. L’identifiant du document est non indexé ; seul son corps est recherché. L’expression est "REF27-ALPHA" OR reprise OR tarifs. La référence entre guillemets exprime une phrase analysée ; ce n’est pas une égalité de champ brut. Les tirets, accents et références doivent donc être éprouvés avec le comportement de l’analyseur retenu.

La documentation SQLite FTS5 sur BM25 décrit la fonction de classement et sa convention de scores, où les valeurs les plus basses sont meilleures. Le banc trie par BM25 croissant, puis identifiant pour départager. Ce sens est propre à l’interface utilisée ; recopier un seuil positif depuis un autre moteur sans vérifier sa convention rendrait le diagnostic incohérent.

Rapprocher le résultat au passage attendu

La liste lexicale complète est D01, D02, D05, D03. D01 arrive premier, avec un score BM25 d’environ −0,765765 ; les autres valeurs sont proches de zéro dans ce petit corpus. Cela vérifie le classement de cette expression et de ces pièces. Ce résultat n’est pas une mesure de pertinence sur une base documentaire réelle, et la magnitude de ce score ne devient pas une probabilité de réponse correcte.

En production, vérifiez d’abord que le code et la condition sont dans les champs effectivement recherchés. Un PDF peut afficher une référence que l’extraction a coupée ou placée dans un champ non consulté. Comparez ensuite requête originale et requête transformée : supprimer les codes lors d’une reformulation peut retirer le meilleur signal lexical. Le prompt de génération n’a aucune prise sur une référence perdue avant la recherche.

Lire le rang vectoriel sans en faire une probabilité

Calculer un exemple volontairement réduit

Nos vecteurs à deux dimensions sont manuscrits : D01 vaut [1 ; 0,8], D02 [1 ; 0,05], D03 [1 ; 0,10] et D05 [1 ; 0,15]. La requête vaut [1 ; 0]. Le contrôleur calcule le cosinus ; aucun modèle d’embedding n’a transformé la question ou les documents. Ces coordonnées sont choisies pour rendre une perte de rappel observable, sans prétendre représenter leur sens linguistique.

La liste devient D02, D03, D05, D01, avec des cosinus d’environ 0,998752 ; 0,995037 ; 0,988936 ; 0,780869. Une fenêtre de trois candidats exclut donc le passage attendu D01. Dans cet exemple concret, la première place D02 et son score élevé ne fournissent pas la condition « relancer uniquement les lignes refusées ». Le score exprime seulement la proximité géométrique des coordonnées fournies.

Distinguer représentation, recherche et budget de candidats

Dans une intégration réelle, un passage peut être mal représenté, associé à la mauvaise version d’embedding ou non retrouvé par une recherche approximative. Une fenêtre trop courte constitue encore une autre cause. Enregistrez modèle et préparation des entrées, index utilisé, filtres et paramètres de récupération. Comparer une recherche exhaustive à une recherche approximative peut aider à distinguer qualité de représentation et comportement de l’index.

Augmenter la fenêtre fournit davantage de candidats mais peut ajouter coût, latence et bruit. Le seuil doit être choisi sur des questions annotées et un budget d’exécution connu. Une taille qui suffit aux codes exacts peut échouer aux demandes composées ; une grande fenêtre ne recrée pas le passage non indexé. Le choix se justifie par la couverture des pièces nécessaires, avec les cas où une réponse doit rester impossible.

Fusionner les rangs et contrôler les fenêtres

Combiner les positions sans additionner des scores incompatibles

La documentation Azure AI Search sur RRF décrit une fusion par rangs : chaque liste contribue avec une valeur de la forme 1 / (constante + rang). Notre banc utilise la constante 60 et des poids égaux, sur les trois premiers candidats de chaque branche. C’est une configuration locale. Le paramètre de constante ne se confond pas avec le nombre de voisins ou la taille finale de réponse.

D02 reçoit 1/62 de la branche lexicale et 1/61 de la vectorielle. D05 reçoit deux contributions de rang 3, soit 2/63. D01 reçoit seulement 1/61, car il est absent de la fenêtre vectorielle. D03 reçoit 1/62 de la seule fenêtre vectorielle. La fusion calculée ordonne D02, D05, D01, D03 ; D01 est disponible au troisième rang, mais ne devient pas automatiquement le premier résultat.

Identifier la fenêtre qui retire une pièce encore récupérable

La documentation Elasticsearch RRF explicite le rôle d’une fenêtre de rangs dans la fusion. Les paramètres et interfaces diffèrent selon les moteurs ; notre banc n’exécute ni Elasticsearch ni Azure. Il distingue fenêtre de chaque branche, liste fusionnée et nombre de candidats transmis au reclassement, afin que ces limites ne soient pas résumées par un seul « top k » ambigu.

Dans notre variante, conserver trois candidats fusionnés garde D01. N’en conserver que deux le retire : D02 et D05 occupent ces places. Un reclassement ultérieur ne verra plus la procédure de reprise sélective. La correction utile porte alors sur cette frontière ou sur le classement précédent, pas sur une consigne demandant au générateur de « chercher davantage » alors qu’aucun outil supplémentaire ne lui est fourni.

Reclasser les candidats réellement disponibles

Vérifier ce que le reclassement reçoit et peut changer

Un reranker compare requête et candidats pour proposer un nouvel ordre ; il ne constitue pas automatiquement une nouvelle recherche dans le corpus. La présentation Microsoft du classement sémantique décrit ce reclassement sur des résultats déjà disponibles et ses limites. Il faut donc examiner la liste d’entrée avant son score de sortie. Un passage absent ne peut pas être promu par une opération qui ne le consulte jamais.

Notre reclassement est volontairement une règle, sans modèle appris : un point si le corps contient REF27-ALPHA et un point s’il contient exactement « relancer uniquement les lignes refusées ». Les égalités conservent l’ordre des candidats. Cette règle très spécifique sert à vérifier le trajet du passage et la différence entre présence et rang. Elle ne mesure aucune compréhension sémantique ou capacité à retrouver des paraphrases.

Ne pas confondre rang de preuve et qualité de réponse

Sur D02, D05, D01, la règle place D01 premier avec deux points ; les deux autres restent à zéro. Sur D02, D03, D05, elle ne récupère rien : aucun candidat ne possède les deux éléments. Ce deuxième cas concret démontre pourquoi une étape de classement doit être évaluée avec son périmètre réel. Le succès sur une liste contenant déjà la preuve ne corrige pas une autre liste qui l’a perdue.

Un reranker réel demande sa propre recette : questions, passages attendus, versions et budget de candidats constants. Examinez les inversions utiles et défavorables, le contenu réellement envoyé et les éventuelles troncatures. Un meilleur rang peut réduire la difficulté de génération sans garantir que la réponse cite la bonne condition. Récupération, reclassement et vérification du texte final gardent des évaluations distinctes.

Six variantes exécutées sur les mêmes documents fictifs

Comparer les listes finales et le rang attendu

Les variantes utilisent la même question et la même admissibilité, sauf R27-F qui retire explicitement D01 de l’index admissible. Les listes de candidats et sorties sont calculées et archivées. Les vecteurs restent manuscrits et le reclassement reste la règle textuelle décrite. Les résultats ci-dessous ne représentent pas six configurations de modèles ni des mesures de précision obtenues sur un benchmark réel.

R27-C montre une récupération possible sans première place ; R27-D montre le changement de rang lorsqu’une règle peut examiner la preuve. R27-B et R27-E échouent avant ce changement, par des fenêtres différentes. R27-F échoue encore plus tôt : les deux branches n’ont plus de D01. Le diagnostic doit conserver cette différence, car élargir la fenêtre ne réindexera pas un passage absent.

Lire une trace courte de la frontière hybride

{
  "case": "R27-D",
  "candidates": ["D02", "D05", "D01"],
  "final": ["D01", "D02", "D05"],
  "expected_rank": 1
}

Cette trace est un extrait des résultats calculés. Les rangs lexicaux, cosinus et fractions RRF restent disponibles dans le rapport du banc ; D04 et D06 sont absents de toutes ces listes. Aucun texte de réponse n’a été généré. La présence de D01 prouve seulement que la procédure fictive peut être remise à l’étape suivante dans cette variante, sans démontrer que celle-ci l’interprétera ou la citera correctement.

Le contrôle utilise un petit corpus sans recherche approximative, réseau ou moteur distribué. Il n’établit donc ni débit, ni latence réelle, ni robustesse d’un embedding ou reranker commercial. Une recette d’intégration doit reproduire la collecte des traces avec le moteur choisi, ses paramètres et son corpus. Le résultat utile est une cause de perte identifiée, avec une correction vérifiable au bon étage.

Mesurer rappel, rang utile et coût de recherche

Séparer disponibilité de preuve et ordre de présentation

Sur un jeu annoté, mesurez si le passage nécessaire entre dans les candidats à la profondeur retenue, puis à quel rang il apparaît. Si une question exige plusieurs pièces, vérifiez aussi leur couverture conjointe. Une métrique de premier passage pertinent peut sembler favorable alors qu’une condition manque. Les identifiants et critères d’applicabilité doivent rester inspectables derrière les moyennes.

Notre question unique ne permet pas d’estimer un taux général de rappel. Les variantes prouvent des parcours de cette fixture, sans représenter leur fréquence future. Pour un vrai jeu, segmentez codes, paraphrases, conditions composées et non-réponses ; gardez les cas de référence voisine ou de version exclue. Le classement doit aider à retrouver la preuve autorisée, pas seulement augmenter le nombre de fragments rendus.

Chiffrer le coût du rappel supplémentaire

Une fenêtre plus large peut augmenter recherches, volume retourné, appels de reranker et taille du contexte. La latence de chaque étage et le coût complet par question utile doivent être suivis séparément. Une amélioration de rang qui multiplie les pièces inutiles peut déplacer la charge vers le gestionnaire. Le budget prévoit également les questions sans résultat, dont la recherche et les reprises ont tout de même consommé des ressources.

Le contrat d’exécution fixe délai, taille de candidats et repli en cas de panne du reclassement. Le responsable produit décide si une recherche sans reranker peut afficher des résultats comme documents à consulter, ou doit suspendre la génération. La trace indique ce mode dégradé. Revenir à une liste brute n’autorise pas à présenter une réponse comme vérifiée si la preuve attendue n’a pas été retrouvée.

Erreurs fréquentes qui masquent le document absent

Interpréter des scores hors de leur convention

BM25, cosinus, RRF et score de reranker ne partagent pas nécessairement unité ou échelle. Dans notre banc, BM25 se trie en ordre croissant, le cosinus en ordre décroissant et RRF combine des rangs. Leur addition directe ne représente pas une probabilité de vérité. Une calibration éventuelle appartient au moteur et au jeu de recette, avec ses changements de corpus et de paramètres.

La confusion de fenêtres est tout aussi fréquente : voisins demandés, candidats réellement retrouvés, résultats fusionnés, entrées du reranker et passages finaux peuvent avoir des tailles différentes. Conservez leurs noms et leurs compteurs dans les traces. Une valeur « trois » à la réponse finale ne prouve pas que chaque branche a recherché trois pièces ni que trois pièces autorisées étaient disponibles au reclassement.

Corriger la génération alors que la preuve a disparu avant elle

Changer le prompt peut améliorer l’abstention quand la source manque, mais ne répare pas l’extraction ou le rappel. Le signal trompeur est une réponse qui connaît la règle de façon générale et produit une référence plausible. La recette doit vérifier que cette référence existe, est autorisée et soutient la condition. Une phrase correcte par hasard ne constitue pas une preuve de recherche réussie.

Paradoxalement, une recherche hybride peut retrouver le passage attendu tout en le repoussant derrière deux résultats généraux, comme R27-C. Le diagnostic n’est donc pas « hybride bon, vectoriel mauvais ». Il examine le rang et la sélection pour une attente déterminée. La combinaison n’apporte une amélioration utile que si les preuves nécessaires survivent jusqu’à l’usage, avec leurs conditions et leur périmètre.

Plan d’action pour corriger le premier étage défaillant

Partir d’une question et d’une preuve annotées

Choisissez une demande en échec pour laquelle le métier peut désigner la pièce et la condition attendues. Le propriétaire documentaire confirme version et applicabilité ; l’équipe d’intégration retrouve le contenu extrait et les métadonnées. L’équipe de recherche collecte listes et paramètres. Avant de tester plusieurs moteurs, il faut pouvoir dire exactement où le passage existe et à quelle frontière il cesse d’être disponible.

1. Vérifier source, extraction et passage indexé. Comparer identifiant, contenu et version ; corriger la perte de condition ou le champ absent avant d’ajuster les scores.
2. Contrôler admissibilité et filtres avec le contexte serveur. Tester ancienne version et pièce étrangère ; distinguer exclusion légitime et erreur de métadonnées sans relâcher les droits pour gagner du rappel.
3. Comparer les branches sur la même question. Conserver expression lexicale, vecteur ou version d’embedding, profondeur et liste de candidats ; repérer référence perdue, représentation inadaptée ou fenêtre trop courte.
4. Rapprocher rangs de fusion, fenêtre retenue et entrée du reranker. Réduire puis élargir une seule limite pour identifier son effet ; vérifier que le passage attendu reste présent avant de juger son nouveau score.
5. Évaluer la sélection finale et son budget sur les familles du jeu. Mesurer couverture des conditions, rang utile et non-réponses, puis seulement tester la génération et les citations à partir des pièces réellement transmises.

Le livrable est une trace de perte et une correction ciblée, avec comparaison avant/après. Il doit contenir aussi les questions qui régressent, les coûts et les cas non résolus. Un meilleur exemple isolé ne suffit pas pour ouvrir le service. Les paramètres retenus restent rattachés au corpus, aux familles de questions et à une version de configuration que l’équipe peut rétablir.

Organiser la reprise et la surveillance de la recherche

La responsabilité de monitoring distingue rejet d’ingestion, refus de droits, absence de candidat et panne technique. La traçabilité conserve entrée, listes et sortie avec les limites de collecte adaptées aux documents. Le runbook explique repli sans reranker, suspension et retour à une configuration vérifiée. Les permissions ne doivent jamais dépendre d’un résumé de requête ou d’une demande du modèle.

Une nouvelle ingestion, un analyseur modifié ou un changement de représentation déclenche une recette de récupération avant ouverture. Les attentes sont revues seulement si les sources applicables changent, avec leur propriétaire. Le service garde ainsi deux révisions distinctes : celle du savoir autorisé et celle de la recherche qui tente de le retrouver. Une amélioration technique ne réécrit pas silencieusement la preuve métier attendue.

Guides complémentaires sur corpus, découpage et index

Préserver les conditions et l’applicabilité des passages

Le RAG documentaire avec corpus, accès et preuve définit les frontières de réponse et la source autorisée. Ce socle reste nécessaire avant une optimisation du rappel. Retrouver très haut une procédure exclue n’est pas une amélioration du service ; c’est une violation du périmètre qu’il devait respecter.

La comparaison de découpages sur des preuves constantes examine les conditions conservées dans les fragments. Elle complète le diagnostic lorsque la recherche retrouve une moitié de règle ou impose d’assembler plusieurs pièces. La fusion de rangs ne restitue pas une condition qui n’a jamais été extraite ou indexée.

Distinguer conflit documentaire et intégration d’index

Le traitement des procédures RAG contradictoires aide à définir l’applicabilité quand plusieurs sources semblent répondre. Un classement récent ou élevé ne suffit pas pour arbitrer une contradiction métier. Le propriétaire doit expliquer la règle ou la non-réponse que la recette de récupération cherchera ensuite à couvrir.

L’intégration Pinecone avec index, namespaces et ingestion traite la projection technique et ses identités. Elle complète la chaîne lorsque les pièces attendues ne rejoignent pas l’index ou portent une mauvaise portée. La recette de recherche doit partir d’une projection rapprochée aux sources, indépendamment du moteur finalement retenu.

Conclusion : fournir une preuve avant de générer une réponse

Une réponse RAG dépend de passages effectivement récupérés et applicables. Le diagnostic suit source, extraction, filtres, branches, fusion et sélection avant d’examiner la réponse générée. Chaque étage peut retirer la pièce nécessaire sans panne visible. Les traces d’identifiants et de fenêtres permettent de corriger cette cause au lieu de demander au modèle de compenser une preuve absente.

Les six variantes fictives vérifient cette frontière : D01 apparaît au troisième rang après fusion, passe premier avec notre règle et disparaît si la fenêtre finale est réduite à deux. Une règle ne le récupère ni dans la liste vectorielle courte ni lorsqu’il est retiré de l’index. Ces résultats utilisent BM25, cosinus calculés et vecteurs manuscrits ; ils ne mesurent aucun embedding, reranker appris ou qualité de réponse LLM.

La conception d’un RAG documentaire vérifiable relie ces listes aux questions de vos équipes. Le passage attendu, ses conditions et sa portée deviennent les points de contrôle de la recherche. Les technologies se comparent sur cette recette, avec leur budget et leurs limites, sans transformer un score élevé en certificat de vérité.

Dawap accompagne le diagnostic d’une recherche documentaire IA sur mesure à partir d’une question dont le propriétaire métier connaît le passage attendu. Nous conservons les listes avant et après chaque sélection pour identifier la première étape qui l’écarte. La comparaison fait ensuite varier une fenêtre ou une règle de classement à sources constantes, avant d’évaluer la réponse du modèle sur le contexte effectivement transmis.