BM25 vs Embeddings vs Rerankers : stack de recherche en 2026
Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.
Un bon stack de recherche fonctionne comme un entonnoir. Les méthodes peu coûteuses constituent d’abord un vaste ensemble de candidats ; les méthodes plus coûteuses affinent ensuite un ensemble beaucoup plus restreint. Les problèmes commencent souvent lorsque les équipes remplacent la recherche textuelle exacte par des embeddings, au lieu de combiner les deux.
Commencez par les filtres et BM25, une méthode performante de classement textuel exact. Ajoutez la recherche dense pour trouver des correspondances sémantiques, puis fusionnez les deux listes de résultats avec Reciprocal Rank Fusion (RRF) ou une méthode similaire. Effectuez le reranking de la shortlist avec un cross-encoder. N’utilisez un LLM que pour un très petit ensemble final, lorsque le gain de qualité justifie la latence et le coût supplémentaires.
Dernière vérification : 2026-08-10. Le stack est évalué selon le recall, le gain de classement, la conformité aux politiques, la latence p95 et le coût sur de vrais segments de requêtes, et non selon un nombre universel de candidats.
Stack recommandé
| Étape | Valeur par défaut | Rôle |
|---|---|---|
| Filtrage | Filtres structurés | Appliquer les contraintes de tenant, d’autorisations, de produit, de langue, de période et de disponibilité. |
| Recherche lexicale | BM25 | Noms exacts, IDs, codes d’erreur, termes juridiques et tokens à haute précision. |
| Recherche dense | Embeddings | Synonymes, paraphrases, intention approximative et recall sémantique. |
| Fusion | Reciprocal Rank Fusion ou composition pondérée de retrievers | Fusionner les candidats sparse et denses sans supposer que leurs scores sont comparables. |
| Reranking | Cross-encoder | Réordonner une shortlist dont la latence est maîtrisée, en exploitant l’interaction entre la requête et le document. |
| Précision finale | LLM reranker ou modèle de réponse | Résoudre les cas de pertinence nuancés uniquement lorsque la liste est réduite. |
| Évaluation | Recall@k, nDCG, MRR, labels de clics, labels humains | Vérifier que chaque étape améliore la précédente. |
Valeurs par défaut selon le cas d’usage
| Surface produit | Bon choix par défaut | Pourquoi |
|---|---|---|
| Recherche documentaire | BM25 plus embeddings plus cross-encoder | Les noms exacts d’API et les questions sémantiques comptent tous les deux. |
| RAG | Recherche hybride plus reranker plus vérification des citations | L’absence de preuves est généralement plus grave qu’une génération lente. |
| Recherche produit | Filtres lexicaux plus recherche hybride plus signaux métier | La disponibilité, le prix, la popularité et les facettes exactes comptent. |
| Recherche de support | Recherche hybride plus fraîcheur et métadonnées des tickets | La formulation similaire et les politiques actuelles comptent toutes les deux. |
| Base de connaissances interne | Référence BM25, puis recherche dense à partir des query logs | Commencez par une base mesurable avant d’ajouter le coût des modèles. |
| Recherche juridique ou de conformité | Référence lexicale plus filtres stricts, puis expansion sémantique prudente | Les faux positifs comme les faux négatifs peuvent avoir un coût élevé. |
Pourquoi BM25 a toujours sa place dans le stack
Les embeddings trouvent des textes de sens similaire, mais ne remplacent pas systématiquement la recherche exacte. Les codes d’erreur, noms de fonctions, SKU produits, expressions juridiques et noms de personnes véhiculent souvent l’intention par leur orthographe exacte. BM25 reste une base solide, car il favorise les termes effectivement saisis par l’utilisateur.
La recherche dense augmente le recall lorsque les utilisateurs ne connaissent pas le vocabulaire exact. Le choix ne se résume pas à BM25 ou aux embeddings. Utilisez BM25 pour le recall lexical, les embeddings pour le recall sémantique, et la fusion pour les combiner.
Quand ajouter un reranker
Ajoutez un cross-encoder lorsque des documents pertinents entrent dans l’ensemble de candidats, mais sont insuffisamment bien classés. Déterminez le nombre de candidats à partir des mesures de recall et de latence ; un top 50 constitue une expérience utile, pas un seuil universel.
N’ajoutez pas de LLM reranker avant un cross-encoder, sauf si l’ensemble de candidats est minuscule. Le jugement de pertinence doit également être suffisamment subtil pour justifier le coût. Le reranking par LLM peut être utile, mais il est plus coûteux et plus lent. Comparez ses résultats à ceux d’un reranker moins coûteux.
Séquence d’évaluation
- Annotez de vraies requêtes couvrant les intentions, langues, autorisations et coûts d’échec importants. Commencez modestement, puis élargissez jusqu’à ce que les segments et l’incertitude permettent de prendre une décision.
- Mesurez BM25 seul.
- Ajoutez la recherche dense et mesurez le delta de recall.
- Ajoutez la fusion et mesurez nDCG et Recall@k.
- Ajoutez le reranking par cross-encoder et mesurez Precision@1 et nDCG.
- Ajoutez le reranking par LLM uniquement s’il améliore la qualité après prise en compte du coût et de la latence.
- Surveillez les métriques de production : taux de résultats nuls, taux de reformulation, taux de clics, corrections des réponses, latence p95 et coût.
Pour aller plus loin
- Search Ranking Stack propose un guide complet de mise en œuvre.
- RAG Evaluation Metrics explique l’évaluation de la recherche et des citations.