BM25 vs RAG : pourquoi la recherche par mots-clés et la recherche sémantique donnent des réponses différentes

BM25 reste le mécanisme fondamental de recherche dans Elasticsearch et Lucene, mais il a une limitation rigide : il comprend les mots, pas le sens. Face à cela, RAG avec embeddings vectoriels résout un problème différent—il trouve des fragments pertinents même quand la requête et le document n'ont pas de correspondance exacte dans la formulation.

Comment Fonctionne BM25

BM25 classe les documents selon trois signaux principaux : combien de fois les termes de la requête apparaissent dans le texte, à quel point ces termes sont rares dans toute la collection et si le document est trop long comparé à la moyenne. Ces facteurs se combinent en un score final que le système utilise pour trier les résultats. Cette approche a été la base de la recherche classique pendant des décennies car elle est rapide, compréhensible et ne nécessite pas un modèle séparé pour interpréter le sens de la requête.

Le mécanisme de saturation de la fréquence de terme est particulièrement important. Si un mot apparaît cinq fois, cela augmente généralement notablement la pertinence ; s'il apparaît cinquante fois, le gain change à peine le tableau. Le paramètre k1 contrôle la rapidité avec laquelle cette saturation se déclenche, et le paramètre b contrôle à quel point les documents longs sont pénalisés. La couche IDF (fréquence inverse de document) amplifie les mots rares et affaiblit les mots courants. Mais l'inconvénient fondamental de BM25 ne disparaît avec aucun réglage : l'algorithme voit le texte comme un ensemble de jetons et ne distingue pas le contexte, l'ordre des mots ou le sens.

Où RAG Gagne

La recherche vectorielle, qui se situe généralement à l'intérieur d'un pipeline RAG, fonctionne différemment. Le système transforme à la fois les documents et la requête elle-même en vecteurs numériques denses via un modèle d'embedding, puis les compare par similarité cosinus. Dans l'exemple de l'article, on utilise le modèle text-embedding-3-small d'OpenAI avec une dimensionnalité de 1536. Cela permet à une requête sur « trouver du contenu similaire sans correspondance exacte de mots » de renvoyer du texte pertinent même si les mots nécessaires n'apparaissent pas du tout dans le document.

«

Aucune des approches n'est meilleure en tout : elles échouent dans des directions opposées. »

C'est là qu'émerge un compromis pratique. BM25 peut être configuré localement : tokenisation, index, arithmétique—et la recherche est prête. La récupération vectorielle nécessite des appels API au stade de l'indexation et de la requête, plus le stockage des embeddings eux-mêmes. Pour un petit ensemble, c'est trivial, mais avec des centaines de milliers ou des millions de chunks, ce schéma devient une décision d'infrastructure et financière. Cependant, elle gère mieux les synonymes, les paraphrases et les requêtes où l'utilisateur exprime le sens plutôt que les mots clés exacts.

Pratique et Compromis

L'article construit sa comparaison sur une démo Python simple avec 12 chunks de texte couvrant BM25, TF-IDF, RAG, transformers, Django, PostgreSQL et autres sujets. Pour BM25, on utilise la bibliothèque rank_bm25, et pour les embeddings, l'API OpenAI et le calcul standard de similarité cosinus. La même requête est ensuite exécutée via les deux récupérateurs pour voir quels fragments arrivent en tête. Cela montre clairement : les systèmes répondent à une question mais arrivent au résultat via des signaux complètement différents.

• BM25 cherche les mots exacts de la requête et explique facilement pourquoi un document est classé plus haut.
• La recherche vectorielle cherche le sens et capte mieux les synonymes et les paraphrases.
• BM25 ne nécessite pas de GPU, de modèles ou d'appels externes.
• Les embeddings nécessitent un index séparé, des appels de modèle et de l'espace pour stocker les vecteurs.
• La recherche hybride combine les deux approches et est devenue la norme pour la production.

La conclusion de l'article est assez pragmatique : discuter de ce qui est « mieux » n'a pas de sens en dehors du contexte de la tâche. Si vous avez besoin d'une recherche rapide, bon marché et transparente par mots clés explicites, BM25 reste très fort. Si la correspondance sémantique et la résilience aux différentes formulations importent davantage, la récupération dense gagne. C'est pourquoi dans les systèmes RAG réels aujourd'hui, les deux sorties sont de plus en plus combinées en premier, puis les candidats sont transmis au LLM pour une réponse.

Ce Que Cela Signifie

Pour les équipes construisant une recherche sur une base de connaissances, une FAQ, des PDFs ou des wikis internes, c'est une bonne orientation sans magie inutile. BM25 n'est pas devenu obsolète, et RAG ne remplace pas la recherche classique. Au contraire, les systèmes les plus fiables aujourd'hui sont construits à partir des deux couches : l'une fournit la précision des mots clés, l'autre fournit la compréhension sémantique et la résilience aux paraphrases.