{"notes":[{"id":"retrieval-augmented-generation/bm25-wins-at-scale","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"BM25 Wins at Scale","subtitle":"Rendons sa grandeur à BM25","author":"Z. Yuan","paperDate":"2026-07-29","publishedOn":"2026-09-10","paperTitle":"BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms","paperUrl":"https://arxiv.org/abs/2607.26497","bibliography":{"title":"BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms","authors":["Pengyu Wang","Benfeng Xu","Shaohan Wang","Mingxuan Du","Xin Zeng","Huarui Wu","Lei Zhang","Licheng Zhang"],"url":"https://arxiv.org/abs/2607.26497","pdfUrl":"https://arxiv.org/pdf/2607.26497v3","codeUrl":null,"preprint":{"id":"2607.26497","submittedOn":"2026-07-29","url":"https://arxiv.org/abs/2607.26497"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationbm25winsatscale2026,\n  title = {{BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms}},\n  author = {Pengyu Wang and Benfeng Xu and Shaohan Wang and Mingxuan Du and Xin Zeng and Huarui Wu and Lei Zhang and Licheng Zhang},\n  year = {2026},\n  eprint = {2607.26497},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2607.26497}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/bm25-wins-at-scale.faa6780c7835.bib"},"thumbnail":{"src":"/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png","width":700,"height":550},"locale":"fr","path":"/content/papers/fr/retrieval-augmented-generation/bm25-wins-at-scale.b0652c457329.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"la-base-dune-entreprise-fictive","text":"La base d'une entreprise fictive","depth":3},{"id":"le-socle--1-144-documents-fixes","text":"Le socle : 1 144 documents fixes","depth":3},{"id":"28-bases-emboîtées","text":"28 bases emboîtées","depth":3},{"id":"sept-pipelines-quatre-familles","text":"Sept pipelines, quatre familles","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"résultat-principal--un-croisement-vers-dix-millions-de-tokens","text":"Résultat principal : un croisement vers dix millions de tokens","depth":3},{"id":"coût--lagent-cherche-de-plus-en-plus-cher","text":"Coût : l'agent cherche de plus en plus cher","depth":3},{"id":"le-rag-par-graphe-bute-sur-la-construction","text":"Le RAG par graphe bute sur la construction","depth":3},{"id":"pourquoi-lagent-perd-il--trouver-avant-de-raisonner","text":"Pourquoi l'agent perd-il ? Trouver avant de raisonner","depth":3},{"id":"doù-vient-lavantage-de-bm25-","text":"D'où vient l'avantage de BM25 ?","depth":3},{"id":"ce-quil-faut-garder-en-tête","text":"Ce qu'il faut garder en tête","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"En 2026, le RAG se divise déjà en plusieurs écoles.\n\nLa **recherche lexicale** classe par mots-clés avec des méthodes comme BM25. La **recherche dense** compare des vecteurs de texte. Le **RAG par graphe** demande à un LLM d'extraire les entités et relations de chaque passage pendant l'indexation pour construire un graphe de connaissances. Enfin, certains laissent un **agent** parcourir une arborescence avec `ls`, `grep` et des lectures de fichiers, comme un agent de programmation, jusqu'à trouver la réponse.\n\nChaque école présente de beaux résultats. Mais ceux-ci proviennent généralement de **jeux d'évaluation différents**, et d'**une seule taille de corpus**.\n\nUne base d'entreprise, elle, continue de grandir : quelques dizaines de milliers de documents aujourd'hui, peut-être plusieurs centaines de milliers l'an prochain.\n\nCette prépublication de l'Université des sciences et technologies de Chine, de Metastone et du Centre de recherche en technologies de l'information de l'Académie des sciences agricoles et forestières de Pékin pose une question pratique : **quelle forme de RAG tient encore quand les données continuent de croître ?**\n\nDéposé sur arXiv le 29 juillet 2026, l'article portait d'abord le titre « Which RAG Paradigm Wins at Scale? », avant de prendre son titre actuel. Cette note suit la v3 du 31 juillet 2026.\n\n\n> [!TIP]\n> \n> **Qu'est-ce que BM25 ?**\n> \n> BM25 est une méthode de classement par mots-clés devenue mature dans les années 1990. Les moteurs de recherche et des outils comme Elasticsearch l'utilisent encore parmi leurs modes de classement par défaut.\n> \n> Son score repose principalement sur trois éléments :\n> \n> 1. **La fréquence du terme recherché.** Plus il apparaît, plus le score monte, mais avec saturation. Cent occurrences ne valent pas dix fois dix occurrences.\n> 2. **La rareté du terme.** « the » apparaît partout et apporte peu. « ticket-4821 », présent dans quelques documents seulement, fournit une correspondance beaucoup plus informative.\n> 3. **La longueur du document.** Un long document a naturellement plus de chances de contenir les termes ; le score est donc ajusté en fonction de sa longueur.\n> \n> Aucun entraînement ni GPU n'est nécessaire : un index inversé suffit.\n\n\n## Définir le problème\n\nLes auteurs définissent précisément le passage à l'échelle : **garder les questions fixes, augmenter uniquement la base et observer l'évolution de chaque méthode.**\n\nCela impose trois contraintes :\n\n1. **Fixer questions et réponses.** Sinon, une variation de score peut venir aussi bien du volume de données que de la difficulté des questions.\n2. **Fixer les distracteurs.** Les documents conçus pour induire en erreur doivent être présents dès le départ, au lieu d'apparaître progressivement avec le volume.\n3. **Fixer les autres conditions.** Modèle de réponse, notation et comptabilisation des coûts doivent être identiques pour toutes les méthodes.\n\n## Résoudre le problème\n\n### La base d'une entreprise fictive\n\nEnterpriseRAG-Bench simule une entreprise de services d'inférence LLM. Il contient 511 957 documents, soit 600,8 millions de tokens, issus de neuf types de sources : wiki, fils de discussion, tickets, courriels, transcriptions de réunions, fiches CRM, revues de code, entre autres.\n\nSes 500 questions couvrent dix catégories, de la recherche élémentaire à la synthèse exhaustive, à la résolution d'informations contradictoires et aux questions de haut niveau. Chaque question possède une réponse de référence, des documents associés — 722 au total — et une liste des faits atomiques attendus.\n\nLe corpus contient déjà 7,7 % de documents bruités : mauvaise source ou mauvais chemin, quasi-doublons devenus obsolètes. Bref, des fichiers comme on en rencontre dans une vraie entreprise.\n\n### Le socle : 1 144 documents fixes\n\nLes auteurs construisent d'abord une base minimale, le **socle**, ou *bedrock* :\n\n$$\n\\underbrace{722}_{\\text{documents de référence}}+\\underbrace{326}_{\\text{pièges}}+\\underbrace{99}_{\\text{leurres}}+\\underbrace{2}_{\\text{pages de présentation}}-\\underbrace{5}_{\\text{doublons}}=1{,}144\n$$\n\nLes **pièges**, ou *traps*, sont essentiels. Ils parlent du même sujet que les documents de référence, mais donnent une version, une date ou une décision incorrecte : une ancienne spécification du même projet, par exemple. Les auteurs prennent les dix premiers résultats BM25 du corpus complet, puis dix résultats obtenus en reclassant par recherche dense les 200 premiers de BM25. Un LLM sélectionne ensuite les documents portant sur le bon sujet, mais contenant les mauvais faits.\n\nLes **leurres**, ou *lures*, servent aux questions sans réponse : ce sont des documents très proches du sujet, mais dont on a vérifié qu'ils ne permettent pas de répondre. Le modèle ne peut donc pas réussir simplement parce qu'il n'a rien trouvé.\n\nTous ces distracteurs sont présents dès la base minimale et restent ensuite inchangés.\n\n### 28 bases emboîtées\n\nLes documents restants sont placés dans un ordre fixe. À partir du socle, chaque niveau ajoute des documents pour multiplier approximativement leur nombre par 1,25 :\n\n$$\nn_{t+1}\\approx1.25\\,n_t\n$$\n\nOn passe ainsi de 1 144 à 511 959 documents en 28 niveaux, soit environ un facteur 450. En tokens, cela représente 1,7 million à 601 millions.\n\nL'emboîtement est strict : chaque niveau contient entièrement le précédent, ce que les auteurs vérifient par sommes de contrôle des fichiers. Du premier au vingt-huitième niveau, le seul changement est l'ajout de documents de fond sans rapport.\n\nL'échantillonnage est stratifié par source et par proportion de bruit pour conserver, à chaque niveau, une composition proche du corpus complet.\n\n### Sept pipelines, quatre familles\n\n| Famille | Méthode | Fonctionnement |\n| --- | --- | --- |\n| Lexicale | BM25 | Index inversé, sans LLM |\n| Dense | DenseRAG | Embedding de chaque bloc et comparaison de similarité |\n| Graphe | HippoRAG 2 | Extraction de triplets, graphe et recherche par Personalized PageRank |\n| Graphe | MS-GraphRAG | Graphe d'entités et rapports de communautés hiérarchiques, recherche locale |\n| Graphe | LightRAG | Index à deux niveaux, entités et relations, mode hybride |\n| Graphe | LinearRAG | Graphe de cooccurrences construit avec une reconnaissance légère d'entités, sans LLM génératif |\n| Agent | File-System Agent | Sans index ; parcours, recherche et lecture dans l'arborescence brute |\n\n*D'après la section 4.1 de l'article.*\n\nFile-System Agent reprend l'interface d'un agent de programmation, avec au plus 80 appels LLM par question.\n\nLes autres conditions sont uniformisées autant que possible :\n\n- **Modèle de réponse** : Qwen3.6-27B pour tous, température 0. File-System Agent utilise aussi ce modèle pour choisir son action suivante.\n- **Embeddings** : Qwen3-Embedding-0.6B pour tous.\n- **Profondeur de recherche** : les cinq premiers blocs pour les méthodes concernées. BM25, DenseRAG et HippoRAG 2 utilisent le même découpage.\n- **Coûts** : chaque appel LLM est intercepté, avec ses tokens attribués soit à l'indexation, soit aux réponses.\n- **Évaluation** : protocole officiel du benchmark. L'indicateur principal, le **combined score**, mesure l'exhaustivité factuelle après franchissement d'un seuil de correction. Chaque question est exécutée une seule fois ; les intervalles de confiance viennent d'un bootstrap sur les questions.\n\nUne nouvelle notation par un juge indépendant produit 96,2 % d'accord. Une notation binaire, plus simple, conserve aussi le classement des méthodes aux neuf niveaux communs.\n\n## Discussion\n\n### Résultat principal : un croisement vers dix millions de tokens\n\n[![Évolution du combined score officiel avec la taille du corpus, avec intervalles de confiance à 95 % ; BM25 et File-System Agent se croisent vers dix millions de tokens](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)\n\n*Figure 3 de l'article, extraite de la [**page 6 du PDF v3**](https://arxiv.org/pdf/2607.26497v3#page=6). L'abscisse logarithmique indique les tokens du corpus ; l'ordonnée, le combined score officiel. Les bandes représentent les intervalles de confiance à 95 %. Les courbes des graphes s'arrêtent au dernier niveau dont l'index a pu être construit.*\n\nL'axe horizontal représente donc le volume de tokens sur une échelle logarithmique, et l'axe vertical le score.\n\nRegardons les deux courbes du haut. À gauche, File-System Agent, en cyan, dépasse légèrement BM25, en brun : 77,4 contre 74,7 au socle. Mais les intervalles de confiance à 95 %, respectivement 73,9–80,8 et 71,4–77,9, se chevauchent ; les résultats ne permettent pas de les départager statistiquement.\n\nEn allant vers la droite, les courbes se croisent autour de $10^7$, soit dix millions de tokens. BM25 mène ensuite à tous les niveaux communs, avec un écart croissant.\n\nSur le corpus complet, à droite :\n\n| Méthode | 1 144 documents, socle | 21 614 documents | 131 876 documents | 511 959 documents, complet |\n| --- | ---: | ---: | ---: | ---: |\n| BM25 | 74,7 | 64,9 | 55,2 | **50,5** |\n| File-System Agent | **77,4** | 62,6 | 50,9 | 30,7 |\n| DenseRAG | 58,1 | 44,2 | 36,0 | 29,9 |\n| HippoRAG 2 | 66,2 | 53,8 | 41,0 | — |\n| LinearRAG | 46,2 | 34,3 | 29,8 | — |\n| MS-GraphRAG | 45,9 | — | — | — |\n| LightRAG | 48,0 | — | — | — |\n\n*D'après la Table 1. Les colonnes donnent le nombre de documents de chaque niveau. « — » indique un index non construit ou une évaluation non réalisée à ce niveau.*\n\nBM25 termine à 50,5, File-System Agent à 30,7 et DenseRAG à 29,9 : presque 20 points d'écart.\n\nLa recherche dense reste sous BM25 du début à la fin. Plus de la moitié des méthodes par graphe n'atteignent même pas le corpus complet.\n\n### Coût : l'agent cherche de plus en plus cher\n\nLes pipelines à une recherche suivie d'une réponse, comme BM25, DenseRAG et HippoRAG 2, gardent un coût par question presque constant avec la taille : environ 5 000 à 6 000 tokens, principalement le prompt du modèle de réponse.\n\nFile-System Agent suit une autre trajectoire. Dès le socle, il consomme 226K tokens par question, 39 fois BM25. À 21 614 documents, il passe à 343K, soit environ 60 fois plus.\n\nLe nombre médian d'appels LLM passe de cinq à huit à 42 587 documents. La proportion de questions épuisant les 80 appels reste sous 7 % jusqu'à 42 587 documents, monte à 15 % à 131 876, puis à 31 % sur le corpus complet.\n\nLes auteurs soulignent que l'exactitude baisse aussi parmi les questions qui n'épuisent pas ce budget. Un budget trop faible ne suffit donc pas à expliquer la chute.\n\nCalculons le total pour les 500 questions au socle. À 5,8K tokens chacune, BM25 consomme 2,9 millions de tokens pour 74,7 points. À 226K chacune, File-System Agent en consomme environ 113 millions pour 77,4 points. Près de 40 fois plus de tokens achètent 2,7 points, toujours dans la zone de chevauchement des intervalles de confiance.\n\n### Le RAG par graphe bute sur la construction\n\nPour les méthodes par graphe, le gros du coût vient de l'indexation : faire lire les passages au LLM pour en extraire entités et relations.\n\nLes auteurs ajustent $C(x)=a\\,x^{b}$ au nombre de tokens de construction selon la taille du corpus, puis extrapolent jusqu'au corpus complet :\n\n| Méthode | Exposant $b$ | Extrapolation au corpus complet | Temps estimé sur une machine |\n| --- | ---: | ---: | ---: |\n| HippoRAG 2 | 1,01 | Environ 2,9 milliards de tokens | Environ 3 jours |\n| MS-GraphRAG | 0,92 | Environ 7,9 milliards de tokens | Environ 50 jours |\n| LightRAG | 1,36 | Environ 102 milliards de tokens | Environ 4 ans |\n\n*D'après la Table 2 de l'article.*\n\nL'exposant de LightRAG dépasse 1 : le coût par document augmente avec le volume. Les auteurs l'attribuent aux réécritures et fusions répétées d'entités. Dès 2 826 documents, sa construction dépasse les ressources dont ils disposent.\n\nMême lorsque l'index est constructible, les résultats restent modestes. Sur environ 155 millions de tokens de corpus, HippoRAG 2 utilise 724 millions de tokens pour indexer et obtient 41,0 points, environ 15 de moins que BM25 au même niveau.\n\nLes auteurs identifient trois difficultés sur ce corpus. L'extraction introduit du bruit : les 32 000 entités du socle contiennent de nombreux fragments incomplets. La proximité dans le graphe favorise des contenus sémantiquement liés mais factuellement faux, précisément visés par les documents pièges. Enfin, HippoRAG 2 retire le texte des prédicats extraits, perdant ainsi la sémantique des relations.\n\n### Pourquoi l'agent perd-il ? Trouver avant de raisonner\n\nVoici l'expérience de contrôle la plus importante de l'article.\n\nFile-System Agent échoue-t-il à trouver les informations, ou à les exploiter une fois trouvées ?\n\nSur 150 questions fixes, les auteurs comparent le socle et le corpus complet. Une nouvelle référence, **Agent+BM25**, conserve modèle, harness, budget de 80 appels et juge. Seuls les outils changent : recherche classée par BM25 et lecture de blocs remplacent le parcours de l'arborescence brute. La première recherche doit utiliser la question originale.\n\n| Méthode | Socle | Complet | Rappel des documents | Appels | Tokens |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Native BM25 | 81,3 | 54,8 | 65,6 | 1,00 | 5,8K |\n| File-System | 87,1 | 36,9 | 36,8 | 36,12 | 895K |\n| Agent+BM25 | **90,1** | **69,4** | **72,4** | 5,79 | 101K |\n\n*D'après la Table 4 : 150 questions fixes, renotées dans la même campagne. Les deux premières colonnes sont les combined scores des deux niveaux. Le rappel des documents, les appels et les tokens par question concernent tous le corpus complet.*\n\nLa réponse est claire : **la difficulté se situe dans la recherche des preuves**.\n\nSur le corpus complet, File-System Agent retrouve au moins un document de référence pour seulement 39,0 % des questions, contre 71,6 % pour BM25.\n\nLes auteurs examinent aussi les questions où chaque méthode a trouvé au moins un document de référence. File-System Agent y obtient 85,9, contre 73,8 pour BM25. Cela suggère que l'agent sait bien raisonner et synthétiser une fois les documents trouvés. Les deux scores portent toutefois sur les sous-ensembles réussis propres à chaque méthode, donc sur des questions différentes : ils restent descriptifs et ne permettent pas de comparaison directe de supériorité.\n\nEn ne changeant que les outils de recherche, Agent+BM25 atteint 69,4 sur le corpus complet : 32,5 points au-dessus de File-System Agent et 14,6 au-dessus de Native BM25. La proportion de questions avec au moins un document de référence monte à 78,0 %, tandis que les tokens par question passent de 895K à 101K, environ un neuvième du coût initial.\n\nLes auteurs concluent que **le raisonnement de l'agent est plus utile après un classement global des résultats que comme substitut à ce classement**. À mesure que l'arborescence grandit, une exploration branche par branche atteint plus difficilement les zones pertinentes.\n\n\n> [!NOTE]\n> \n> **Le harness compte aussi**\n> \n> Sur les 150 questions du socle, les auteurs comparent aussi trois harness lisant les fichiers bruts : 86,3 pour le leur, 82,3 pour Pi-Agent et seulement 43,9 pour Codex. Native BM25 obtient 82,1, selon la Table 5.\n> \n> Avec le même modèle, le même corpus et le même juge, le choix du harness produit plus de 40 points d'écart. Le contrôle Agent+BM25 précédent utilise la meilleure des trois variantes, celle des auteurs.\n\n\n### D'où vient l'avantage de BM25 ?\n\nLes auteurs reconnaissent que ce corpus favorise BM25. Les questions d'entreprise contiennent souvent des repères lexicaux exacts : noms de projets, numéros de tickets, noms de personnes. Les pièges, eux, sont sémantiquement proches mais factuellement faux ; les correspondances exactes y résistent mieux.\n\nIls réalisent donc deux contrôles :\n\n- **Reformuler les questions** pour réduire le recoupement lexical. Au socle, BM25 descend à 63,9, File-System Agent obtient 73,3 et DenseRAG 51,8. L'avantage de l'agent sur une petite base devient plus net, mais BM25 reste devant les recherches dense et par graphe.\n- **Récupérer dix blocs** au lieu de cinq. BM25 atteint 83,0 et DenseRAG 70,0 : l'écart demeure.\n\n### Ce qu'il faut garder en tête\n\n1. **Un seul benchmark.** EnterpriseRAG-Bench est un corpus d'entreprise simulé. Ses repères lexicaux et ses pièges influencent la comparaison entre recherche lexicale et sémantique.\n2. **Un petit modèle d'embedding.** Tous les embeddings viennent de Qwen3-Embedding-0.6B. L'article ne teste pas l'effet d'un modèle plus grand sur DenseRAG.\n3. **Pas de recherche hybride évaluée.** Les pipelines représentent chacun leur famille, sans fusion BM25-dense ni reranker après BM25, pourtant courants. Agent+BM25 s'en approche le plus.\n4. **Un modèle de réponse et une exécution par question.** L'incertitude vient du rééchantillonnage des questions, sans mesure de variation entre exécutions.\n5. **Code et données.** L'annexe décrit les éléments complémentaires et leurs correspondances, mais le texte de la v3 ne fournit aucun emplacement public de téléchargement.\n\n## Conclusion\n\nL'article construit 28 bases emboîtées couvrant un facteur d'environ 450, en fixant les questions, les références et les pièges. Seuls les documents de fond se multiplient. Dans ce cadre :\n\n1. **Le gagnant change avec la taille.** File-System Agent mène légèrement sur les petites bases. Après environ dix millions de tokens, BM25 le dépasse à tous les niveaux communs, avec presque 20 points d'écart sur le corpus complet.\n2. **BM25 reste économique et stable.** Environ 5,8K tokens par question, sans indexation par LLM : il occupe solidement le côté économique du compromis entre coût et qualité.\n3. **L'agent peine à trouver les preuves.** Remplacer l'arborescence par une recherche BM25 fait passer le même agent de 36,9 à 69,4 sur le corpus complet, pour un neuvième des tokens.\n4. **Les graphes butent sur la construction.** LightRAG demanderait environ quatre ans sur une machine selon l'extrapolation. Même HippoRAG 2, constructible à certaines tailles, reste sous BM25.\n\nLa recommandation des auteurs pour les corpus d'entreprise est directe : **BM25 par défaut ; Agent+BM25 lorsque la question demande de synthétiser plusieurs sources**. Entre cent mille et un million de documents, un index construit par LLM est difficile à justifier, sauf si sa construction reste presque linéaire et si les questions portent principalement sur les relations.\n\nQuand les données grossissent, une méthode vieille de trente ans revient au premier plan. Cette fois, elle ouvre la voie à l'agent.\n","imageSizes":{"/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png":{"width":700,"height":550}}}