Recherche hybride et reranking pour les chatbots IA : de meilleurs résultats RAG

Les chatbots de sites web échouent rarement parce qu'une base de connaissances ne contient aucune information. Plus souvent, l'étape de retrieval ne trouve pas le passage qui correspond à la question et au contexte concret. Les visiteurs utilisent des noms de produits, des messages d'erreur et des numéros d'articles, mais s'expriment tout aussi librement : « Pourquoi le chatbot affiche-t-il le mauvais tarif ? » ou « Puis-je encore modifier une commande déjà expédiée ? » Pour ce mélange, ni la simple recherche par mots-clés ni la simple recherche vectorielle ne suffisent comme réponse globale. La recherche hybride combine ces deux signaux afin qu'un chatbot RAG obtienne des sources plus fiables dans son contexte de réponse.

La recherche par mots-clés et la recherche vectorielle répondent à des besoins différents

La recherche par mots-clés est performante lorsque les mots doivent apparaître exactement. Cela s'applique aux numéros de commande, aux désignations de produits, aux messages d'erreur concrets, aux noms de contrats ou à une version telle que « 2.4 ». Elle peut montrer de manière compréhensible pourquoi un document correspond : le mot cherché se trouve dans le titre, dans un en-tête ou dans le passage. Sa faiblesse apparaît avec le langage quotidien, les synonymes et les formulations incomplètes. La question d'un visiteur concernant une « copie de facture » ne trouvera pas nécessairement une page qui parle uniquement de « télécharger le reçu ».

La recherche vectorielle comble cette lacune. Elle représente la question et le contenu sous forme de proximité sémantique et peut ainsi trouver des demandes similaires, bien que les mêmes termes soient absents. Cela aide pour les questions de support formulées naturellement, les variantes multilingues et les différentes désignations pour une même procédure. Cependant, la proximité sémantique seule n'est pas un passe-droit : un passage peut être similaire au sujet, mais concerner une autre version du produit, un autre marché ou une règle expirée. C'est précisément pourquoi la vérification du contexte relève du pipeline de retrieval et ne doit pas être déléguée au modèle linguistique uniquement.

Pourquoi la recherche hybride est un excellent point de départ

Microsoft décrit la recherche hybride comme une requête conjointe comprenant une partie texte intégral et une partie vectorielle. Les deux requêtes s'exécutent en parallèle, puis leurs listes de résultats sont fusionnées. C'est attrayant pour les sites web d'entreprise, car les termes exacts sont préservés tout en rendant accessibles des contenus connexes et bien formulés. Un chatbot n'a pas besoin de faire choisir aux visiteurs entre une recherche « technique » et une recherche « sémantique ». La sélection s'effectue en arrière-plan et peut être vérifiée pour toutes les questions avec le même processus de qualité.

La recherche hybride améliore l'ensemble des candidats ; elle ne crée pas de vérité absolue. Le chatbot ne doit utiliser que des contenus autorisés pour la situation concrète. Les pages web publiques, les brouillons internes et les données clients protégées ne doivent pas se retrouver dans un contexte commun non contrôlé. Tout aussi important est un comportement clair lorsqu'aucune source adéquate n'est disponible : une demande de précision, un lien vers la page de contact ou un Human Handoff sont plus sûrs qu'une supposition formulée de manière fluide.

Comprendre RRF : fusionner des classements

Les scores de la recherche en texte intégral et de la recherche vectorielle ont des significations et des échelles différentes. Les additionner directement ou inventer une valeur limite fixe conduit souvent à des résultats instables. La Reciprocal Rank Fusion, ou RRF, travaille donc avec la position d'un document dans chaque classement. Un document qui apparaît en haut des deux listes reçoit un signal combiné fort. Un document qui n'est visible que dans une seule liste peut également être pris en compte, mais sans évincer automatiquement tout le reste.

RRF n'est pas une valeur par défaut magique ni une formule de remplacement pour les tests métiers. Le nombre de candidats issus de chaque recherche qui parviennent à la fusion, les filtres qui s'appliquent au préalable et le moment où un résultat est considéré comme exploitable dépendent du contenu et du risque. Pour des questions courantes sur les produits, une fenêtre réduite et ciblée peut être judicieuse. Pour des instructions complexes ou des diagnostics d'erreurs, davantage de candidats peuvent être nécessaires. L'essentiel est de comparer les modifications par rapport à un jeu de test avec de vraies questions au lieu de reprendre un paramètre universel tiré d'un exemple.

Le reranking sémantique comme seconde étape ciblée

Après une bonne présélection, un reranker peut évaluer à nouveau l'ensemble restreint de candidats par rapport à la question globale. Microsoft définit le classement sémantique comme un classement secondaire au-dessus d'une liste de résultats déjà classée au préalable. Amazon Bedrock décrit le reranking de manière similaire comme une évaluation des documents textuels quant à leur pertinence par rapport à la requête. Cette seconde étape convient aux questions comportant plusieurs conditions : par exemple, si un changement de tarif est possible après l'envoi d'une commande et pour un type de contrat spécifique.

Le reranking doit être délimité de manière consciente. Il génère une latence supplémentaire et peut, selon le service, être payant. Ne fournissez donc pas l'ensemble de la base de connaissances à un reranker, mais uniquement le groupe restreint déjà filtré et fusionné. Définissez un budget temporel et une solution de repli. Si le budget est dépassé, le chatbot peut par exemple afficher la liste de sources la plus fiable, demander une précision ou passer la main à une équipe de support. Un reranker ne répare pas des contenus obsolètes, manquants ou non autorisés.

Les filtres de métadonnées protègent le contexte

Les métadonnées décident souvent plus fortement de la qualité de la réponse qu'une option de modèle supplémentaire. Maintenez pour chaque source au moins la langue, le produit ou le service, la version, le marché, le public cible et la validité, dans la mesure où ces informations sont pertinentes pour l'utilisation. Un filtre sur l'organisation ou la zone d'autorisation appropriée doit s'appliquer avant la restitution. Sur un site web public, un chatbot ne peut récupérer que des contenus publics ; pour un espace connecté, des autorisations vérifiables s'appliquent en complément.

Le temps est également une question de métadonnées. Les listes de prix, les conditions de livraison et les guides doivent porter une date de mise à jour claire ou un statut de validité contrôlé. Si la source n'est plus digne de confiance, elle doit être retirée de l'index ou placée dans un parcours de vérification séparé. Les filtres doivent refléter des exigences compréhensibles pour les visiteurs et non manipuler secrètement l'ordre de classement. Documentez donc quels filtres s'appliquent à quelle catégorie de questions et comment une équipe vérifie les modifications.

Un pipeline concret de la requête au contexte

1. Normaliser la question : Identifiez la langue et le contexte évident sans stocker ou modifier inutilement des données personnelles.
2. Vérifier l'accès et les métadonnées : Déterminez avant le retrieval quelles sources sont autorisées pour le produit, le marché, le rôle et la période de validité.
3. Extraire en parallèle : Exécutez la recherche texte intégral et la recherche vectorielle sur le même ensemble de sources autorisées.
4. Fusionner les classements : Combinez les listes avec RRF et conservez les signaux d'origine par candidat pour le débogage.
5. Reranker de manière limitée : Exécutez l'évaluation de pertinence uniquement sur le petit groupe restreint et mesurez la latence.
6. Sécuriser le contexte : Vérifiez les doublons, le statut des sources et une longueur appropriée avant d'envoyer les passages au modèle de réponse.
7. Répondre avec des limites : Citez les sources, signalez l'incertitude et utilisez si nécessaire un transfert sécurisé.

Exemple pratique : statut d'expédition et changement de tarif

Supposons qu'un visiteur demande : « Puis-je encore changer de tarif alors que le colis est déjà en route ? » La recherche par mots-clés peut trouver une page sur « changer de tarif » et un article de support contenant « colis en route ». La recherche vectorielle trouve un guide décrivant la procédure comme une modification après expédition. RRF remonte les documents qui combinent ces deux aspects. Un reranker peut ensuite vérifier si le passage pertinent contient réellement la combinaison du tarif et de l'expédition.

Avant de répondre, vous filtrez selon le marché concerné, la gamme de produits et le statut de validité actuel. Si les sources sont contradictoires ou si des détails requis manquent, le chatbot ne doit pas tirer de conclusions à partir de cas similaires. Il peut indiquer de manière transparente quelle condition reste ouverte et diriger le visiteur vers un moyen de contact adapté et vérifié. La conversation reste ainsi utile sans inventer un engagement non étayé.

Cas sans résultat et débogage des scores

Un résultat vide est souvent le signal d'un manque de connaissances, et non d'une recherche défaillante. Distinguez donc au moins quatre cas : il n'y a pas de source autorisée, il existe des sources mais aucun résultat suffisamment pertinent, la question est ambiguë ou une erreur technique empêche le retrieval. Chaque cas nécessite une réaction propre et compréhensible. « Je ne trouve pas de réponse fiable dans les informations autorisées à ce sujet » est plus honnête qu'une phrase générique sans étape suivante.

Pour le débogage, les scores finaux seuls ne suffisent pas. Pour chaque question de test, les équipes doivent pouvoir voir quels filtres ont été appliqués, quels documents provenaient de la recherche par mots-clés et vectorielle, comment ils ont été fusionnés et si le reranking a modifié l'ordre. Ne conservez que les données nécessaires à la qualité, préparées de manière sobre. Recherchez des schémas : manque-t-il certains synonymes ? Une ancienne source masque-t-elle du contenu récent ? Une locale déroge-t-elle à la logique des métadonnées ? Seule la cause concrète permet de décider si le chunking, les métadonnées, la gestion des sources ou le ranking doivent être modifiés.

Jeu de test, métriques et budget de coût

Un petit Golden Set comprenant 30 à 50 questions réalistes constitue un bon départ. Associez à chaque question les sources attendues, les sources non autorisées et la réaction souhaitée en cas de connaissances manquantes. Mesurez séparément si une bonne source figure parmi les candidats, si elle est classée suffisamment haut et si la réponse finale n'utilise que des informations étayées. Ajoutez délibérément des fautes de frappe, des termes exacts, des formulations naturelles, du multilinguisme et des cas négatifs critiques.

Ne modifiez qu'une seule variable par session de test : un filtre, le nombre de candidats, la profondeur de reranking ou la structure des chunks. Notez également le temps de réponse et le nombre d'appels externes aux modèles. Un score de pertinence plus élevé peut être inutilisable si la réponse arrive trop tard ou si les coûts pour les questions standard fréquentes augmentent. Définissez donc un budget de latence et de coût par catégorie de questions. Des réponses standard rapides et bien documentées ainsi que des transferts prudents ont souvent plus de valeur pour de nombreux sites web qu'un classement d'une complexité maximale.

Erreurs typiques lors de la mise en œuvre

• Comparer directement les scores bruts de mots-clés et vectoriels alors que leurs échelles diffèrent.
• Indexer des brouillons, d'anciennes listes de prix ou des contenus protégés sans filtres de statut et d'autorisation.
• Appliquer le reranking à un trop grand nombre de candidats et perdre ainsi le contrôle de la latence et des coûts.
• Considérer une démonstration réussie sur quelques bonnes questions comme une preuve de qualité suffisante.
• Générer une réponse plausible en l'absence de source au lieu de prévoir l'incertitude, une demande de précision ou un transfert.
• Ne pas versionner les modifications apportées aux sources, au chunking et au ranking, ce qui rend toute explication ultérieure impossible.

Check-list de déploiement

• Définir les sources autorisées et les limites d'accès avant l'indexation.
• Renseigner les métadonnées pour la langue, le produit, la version, le marché et la validité.
• Lancer la recherche par texte intégral et la recherche vectorielle en parallèle, puis les fusionner via RRF.
• Utiliser le reranking uniquement pour un nombre restreint de candidats autorisés.
• Évaluer les liens de sources, les réponses sans résultat et le Human Handoff dans le jeu de test.
• Mesurer la latence, les coûts et les erreurs de réponse critiques à chaque modification.

Conclusion

La recherche hybride est un point de départ solide pour les chatbots de sites web confrontés à des formulations variées. La recherche par mots-clés préserve les signaux exacts, la recherche vectorielle couvre les intentions similaires, RRF combine leurs classements et un reranker ciblé permet d'affiner la sélection finale. Toutefois, le gain de qualité durable provient de sources bien entretenues, de métadonnées adaptées, de tests rigoureux et d'une logique de réponse qui reconnaît ses limites. Le retrieval devient ainsi vérifiable plutôt que simplement impressionnant sur le plan technique.

Sources et références complémentaires

• Microsoft Learn: Recherche hybride
• Microsoft Learn: Pertinence et RRF en recherche hybride
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking pour chatbots IA
• ChatReact: Mesurer la qualité des réponses avec un Golden Set
• ChatReact: Maintenir la base de connaissances à jour