{"notes":[{"id":"retrieval-augmented-generation/bm25-wins-at-scale","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"BM25 Wins at Scale","subtitle":"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":"ja","path":"/content/papers/ja/retrieval-augmented-generation/bm25-wins-at-scale.f2f8dfd8bbfd.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"架空の会社の知識ベース","text":"架空の会社の知識ベース","depth":3},{"id":"土台固定された1144件の文書","text":"土台：固定された1,144件の文書","depth":3},{"id":"入れ子になった28段階のデータベース","text":"入れ子になった28段階のデータベース","depth":3},{"id":"7つのパイプライン4つの流派","text":"7つのパイプライン、4つの流派","depth":3},{"id":"議論","text":"議論","depth":2},{"id":"主な結果1000万token付近で交差する","text":"主な結果：1,000万token付近で交差する","depth":3},{"id":"コストagentは探すほど高くつく","text":"コスト：agentは探すほど高くつく","depth":3},{"id":"グラフ型ragがぶつかる索引構築の壁","text":"グラフ型RAGがぶつかる索引構築の壁","depth":3},{"id":"なぜagentは負けるのか-推論の前にまず見つける","text":"なぜagentは負けるのか？ 推論の前に、まず見つける","depth":3},{"id":"bm25の強みはどこから来る","text":"BM25の強みはどこから来る？","depth":3},{"id":"読むときに押さえておきたいこと","text":"読むときに押さえておきたいこと","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"2026年までに、RAGはいくつもの流派に分かれました。\n\n**語彙検索**はBM25などでキーワードを順位付けし、**密なベクトルによる検索**は文章をベクトルに変換して類似度を比べます。**グラフ型RAG**は索引の構築時にLLMで文章中のエンティティと関係を抽出し、知識グラフを作ります。さらに、**agent**にcoding agentのようにファイルツリーを`ls`や`grep`で探させ、ファイルを読みながら答えへ進ませる方法もあります。\n\nどの流派にも、見栄えのよい論文の成績があります。ただ、その成績はたいてい**別々の評価セット**から得られ、しかも**ある特定のデータ量**で測られています。\n\n企業の知識ベースは、同じ大きさのままではありません。今日数万件の文書でも、来年には数十万件かもしれません。\n\n中国科学技術大学、Metastone、北京市農林科学院情報技術研究センターによるこのプレプリントは、実用的な問いに向き合います。**データ量が増え続けても、どのRAGなら持ちこたえられるのか？**\n\n論文は2026年7月29日にarXivへ初めて投稿され、当初の題名は『Which RAG Paradigm Wins at Scale?』でした。その後、現在の題名へ変更されています。この記事では2026年7月31日のv3を読みます。\n\n\n> [!TIP]\n> \n> **BM25とは？**\n> \n> BM25は1990年代には成熟していたキーワードの順位付け手法です。検索エンジンやElasticsearchなどでは、現在も標準の順位付け手法のひとつとして使われています。\n> \n> 文書の点数を付けるとき、大まかに次の3つを見ます。\n> \n> 1. **検索語が何回現れるか。**多いほど点数が上がりますが、次第に飽和します。同じ語が100回現れても、10回の場合の10倍にはなりません。\n> 2. **その語がどれほど珍しいか。**「the」はどこにでもあるので、ほとんど加点されません。「ticket-4821」は少数の文書にしか現れず、ヒットすると重みがあります。\n> 3. **文書がどれほど長いか。**長い文書はもともと検索語に当たりやすいため、長さで調整します。\n> \n> 学習もGPUも不要です。転置索引を作れば使えます。\n\n\n## 問題の定義\n\n著者はscalingを明確に定義しています。**問題は固定し、データベースだけを大きくして、各手法の性能がどう変わるかを見る。**\n\nこれを実現するには、3つの難所があります。\n\n1. **問題と答えを固定する。**問題が変わると、成績の変化がデータ量の増加によるものか、問題が難しくなったためかを区別できません。\n2. **妨害情報を固定する。**誤誘導用に設計した文書は、最初から入れておきます。データ量に合わせて後から追加すると、条件が変わってしまいます。\n3. **ほかの条件を固定する。**回答モデル、採点方式、コストの計算を、各手法でそろえます。\n\n## 問題の解決\n\n### 架空の会社の知識ベース\n\n著者が使うEnterpriseRAG-Benchは、LLM推論サービスを提供する架空の会社を模しています。文書は511,957件、計6億80万token。wiki、チャットのスレッド、チケット、メール、会議の書き起こし、CRM記録、code reviewなど、9種類の情報源から構成されます。\n\n問題は500問、10種類です。基本的な情報検索から、情報の網羅的な集約、矛盾する情報の処理、高水準の問いへの回答まで含まれます。各問に正解、対応する文書（計722件）、答えに含めるべき原子的な事実が付与されています。\n\nコーパス自体にも7.7%のノイズ文書があります。情報源やパスを間違えたもの、内容が古くなった近似重複など、実際の会社にもありそうなファイルです。\n\n### 土台：固定された1,144件の文書\n\nまず、著者は**土台**（bedrock）と呼ぶ最小のデータベースを作ります。\n\n$$\n\\underbrace{722}_{\\text{正解文書}}+\\underbrace{326}_{\\text{罠}}+\\underbrace{99}_{\\text{おとり}}+\\underbrace{2}_{\\text{会社概要ページ}}-\\underbrace{5}_{\\text{重複}}=1{,}144\n$$\n\n特に重要なのが**罠**（trap）です。正解文書と同じ話題を扱いながら、版、日付、決定事項が間違っています。同じプロジェクトの古い仕様書などが該当します。著者は全コーパスからBM25の上位10件を取り、さらにBM25の上位200件を密なベクトルによる検索で再順位付けして10件を取ります。最後にLLMが、「話題は同じだが事実が間違っている」文書を選びます。\n\n**おとり**（lure）は、答えが見つからない問題用です。問題にはよく似ていても、その問いには答えられないことを確認済みの文書です。これを入れることで、モデルが単に「何も見つからなかった」から正解することを防ぎます。\n\nこうした妨害文書は最小のデータベースからすべて入れ、後から変更しません。\n\n### 入れ子になった28段階のデータベース\n\n次に、残りの文書を固定した順序で並べ、土台から少しずつ追加します。段階がひとつ上がるごとに、文書数を1.25倍にします。\n\n$$\nn_{t+1}\\approx1.25\\,n_t\n$$\n\n1,144件から511,959件まで、28段階で約450倍に増えます。token数では170万から6億100万です。\n\nここでの「入れ子」は厳密です。各段階は前の段階を完全に含み、著者はファイルのチェックサムでも確認しています。したがって、第1段階から第28段階までの違いは、無関係な背景文書が追加されたことだけです。\n\n追加文書は情報源とノイズの比率によって層化抽出し、各段階の構成をコーパス全体に近づけています。\n\n### 7つのパイプライン、4つの流派\n\n| 流派 | 手法 | 仕組み |\n| --- | --- | --- |\n| 語彙 | BM25 | 転置索引。LLMは不要 |\n| 密なベクトル | DenseRAG | チャンクをembeddingに変換し、類似度を比較 |\n| グラフ | HippoRAG 2 | 三つ組を抽出してグラフを作り、Personalized PageRankで検索 |\n| グラフ | MS-GraphRAG | エンティティのグラフと階層的なコミュニティレポートを作り、local searchを使用 |\n| グラフ | LightRAG | エンティティと関係の2層索引を作り、hybridモードを使用 |\n| グラフ | LinearRAG | 軽量な固有表現認識で共起グラフを構築。生成LLMは呼ばない |\n| Agent | File-System Agent | 索引を作らず、生のファイルツリーで一覧表示、検索、読み取りを行う |\n\n*原論文§4.1に基づいて整理。*\n\nFile-System Agentはcoding agent型のインターフェースを使い、各問題で最大80回までLLMを呼び出せます。\n\nほかの条件も、できるだけそろえます。\n\n- **回答モデル**：すべてQwen3.6-27B、temperatureは0です。File-System Agentが次の行動を決めるときも、同じモデルを使います。\n- **embedding**：すべてQwen3-Embedding-0.6Bを共有します。\n- **検索深度**：検索深度を持つ手法は、上位5チャンクを取得します。BM25、DenseRAG、HippoRAG 2は同じ分割方法を使います。\n- **コスト計測**：すべてのLLM呼び出しを捕捉し、tokenを「索引の構築」と「質問への回答」に分けて記録します。\n- **採点**：評価セットの公式プロトコルを使います。主指標の**combined score**は、正確性の基準を通過したうえで、回答が事実をどれほど網羅しているかを測ります。各問は1回だけ実行し、信頼区間は問題を再抽出するbootstrapで推定します。\n\n別の独立した判定モデルでも採点し直したところ、判定の一致率は96.2%でした。より単純な正誤の二値評価に変えても、共通する9段階で各手法の順位は変わりませんでした。\n\n## 議論\n\n### 主な結果：1,000万token付近で交差する\n\n[![コーパスのtoken数に対する各手法の公式combined scoreと95%信頼区間。BM25とFile-System Agentは約1,000万tokenで交差](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)\n\n*原論文Figure 3。[**v3 PDFの6ページ目**](https://arxiv.org/pdf/2607.26497v3#page=6)より。横軸はコーパスのtoken数（対数）、縦軸は公式combined score、帯は95%信頼区間です。グラフ型手法の線は、構築できた最大の段階で止まっています。*\n\n横軸はコーパスのtoken数で、対数目盛です。縦軸は得点です。\n\n上の2本の線を見ます。左端では、シアンのFile-System Agentが茶色のBM25を少し上回ります。土台での点数は77.4と74.7。ただし、95%信頼区間はそれぞれ73.9〜80.8と71.4〜77.9で重なっており、統計的には優劣を区別できません。\n\n右へ進むと、2本は$10^7$、約1,000万token付近で交差します。それ以降、共通するすべての段階でBM25が先行し、差も広がります。\n\n右端の全コーパスまで進むと、こうなります。\n\n| 手法 | 1,144件（土台） | 21,614件 | 131,876件 | 511,959件（全件） |\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*原論文Table 1に基づいて整理。列は各段階の文書数です。「—」は、その段階で構築または評価ができなかったことを示します。*\n\n全コーパスではBM25が50.5、File-System Agentが30.7、DenseRAGが29.9です。差は20点近くあります。\n\n密なベクトルによる検索は、最初から最後までBM25を下回ります。グラフ型手法の多くは、全コーパスまでたどり着けません。\n\n### コスト：agentは探すほど高くつく\n\nBM25、DenseRAG、HippoRAG 2のように「一度検索してから回答する」パイプラインは、データ量が変わっても、各問の問い合わせコストはほぼ一定です。約5,000〜6,000tokenで、その大半は回答モデルへのプロンプトです。\n\nFile-System Agentは様子が違います。土台ですでに各問226K token、BM25の39倍を使います。文書が21,614件になると343K、約60倍へ増えます。\n\nLLM呼び出し回数の中央値も、5回から8回へ増えます（42,587件時）。80回の予算を使い切る割合は、42,587件までは7%未満ですが、131,876件で15%、全コーパスでは31%になります。\n\n著者は、予算を使い切らなかった問題だけを見ても、正答率が下がっていると指摘しています。性能低下には、予算不足以外の要因もあります。\n\n500問の総コストを計算してみましょう。BM25は各問5.8K token、500問で290万tokenを使い、74.7点。File-System Agentは各問226K、500問で約1億1,300万tokenを使い、77.4点です。40倍近いtokenを費やして得た差は2.7点で、信頼区間も重なっています。\n\n### グラフ型RAGがぶつかる索引構築の壁\n\nグラフ型手法では、主に索引の構築にコストがかかります。文章の各部分をLLMに読ませ、エンティティと関係を抽出するためです。\n\n著者は、構築token数とコーパスの大きさの関係を$C(x)=a\\,x^{b}$で近似し、全コーパスへ外挿しました。\n\n| 手法 | 指数$b$ | 全コーパスへの外挿 | 推定される1台での所要時間 |\n| --- | ---: | ---: | ---: |\n| HippoRAG 2 | 1.01 | 約29億token | 約3日 |\n| MS-GraphRAG | 0.92 | 約79億token | 約50日 |\n| LightRAG | 1.36 | 約1,020億token | 約4年 |\n\n*原論文Table 2に基づいて整理。*\n\nLightRAGの指数は1を超えます。データが増えるほど、1文書あたりの構築コストも増えるということです。著者は、エンティティの書き換えと統合を繰り返すことが原因だと考えています。文書が2,826件になった段階で、著者の利用可能な資源では完了できなくなりました。\n\n構築できた場合も、得点は振るいません。HippoRAG 2は約1億5,500万tokenのコーパスで、索引構築に7億2,400万tokenを使い、41.0点でした。同じ段階のBM25より約15点低い値です。\n\n著者は、このコーパスでグラフ型手法が不利になる理由を3つ挙げています。抽出時にノイズが入ること（土台の3.2万エンティティには不完全な断片が多い）、グラフの近接関係が「意味は関連しているが事実は間違った」内容を選びやすく、罠文書にはまること、そしてHippoRAG 2が抽出した述語の文字列を捨て、関係の意味も失っていることです。\n\n### なぜagentは負けるのか？ 推論の前に、まず見つける\n\nここが、この論文で最も重要な対照実験です。\n\nFile-System Agentが負けたのは、「見つけられない」からでしょうか。それとも、「見つけても使えない」からでしょうか。\n\n著者は固定した150問を使い、土台と全コーパスの2段階で比較します。追加する対照群は**Agent+BM25**。モデル、harness、80回の予算、判定モデルをすべて固定し、生のファイルツリー用ツールだけを「BM25による順位付き検索」と「チャンクの読み取り」に交換します。また、最初の検索には元の質問を使うよう強制します。\n\n| 手法 | 土台 | 全件 | 文書再現率 | 呼び出し回数 | token |\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*原論文Table 4に基づいて整理。固定した150問を、同じ機会に採点し直した結果です。最初の2列は各段階のcombined score。文書再現率、各問の呼び出し回数、各問のtoken数は全コーパスでの値です。*\n\n答えは明確です。**問題は「見つける」側にあります。**\n\n全コーパスで、File-System Agentが正解文書を少なくとも1件見つけた割合は39.0%。BM25は71.6%でした。\n\n著者は、正解文書を少なくとも1件見つけた問題も調べています。その部分集合で、File-System Agentは85.9点、BM25は73.8点でした。資料にたどり着いたagentは、推論や統合に強みを発揮しています。ただし、この2つの値は、それぞれの手法が文書を見つけた別々の問題集合から得られた記述値です。直接の優劣比較には使えません。\n\n検索ツールを交換するだけで、Agent+BM25は全コーパスで69.4点を取りました。元のFile-System Agentより32.5点、Native BM25より14.6点高くなっています。ヒット率は78.0%へ上がり、各問のtoken数は895Kから101Kへ、約9分の1に減りました。\n\n著者の結論は、**agentの推論は、全体を順位付けした後に置くとよい**、というものです。全体の順位付けをファイルツリーの逐次探索で置き換えると、データが増えるほど、関連する枝までたどり着きにくくなります。\n\n\n> [!NOTE]\n> \n> **Harnessも重要**\n> \n> 著者は土台の150問で、生のファイルを読む3種類のagent harnessも比較しています。著者版は86.3点、Pi-Agentは82.3点、Codexは43.9点。Native BM25は82.1点でした（原論文Table 5）。\n> \n> 同じモデル、コーパス、判定モデルでも、harnessを変えると40点以上の差が出ます。先ほどのAgent+BM25の対照実験には、3つのうち最も成績がよかった著者版が使われています。\n\n\n### BM25の強みはどこから来る？\n\n著者も、このコーパスがBM25に有利なことは認めています。企業内の質問には、プロジェクト名、チケット番号、人名といった正確な語句の手がかりがよく現れます。罠文書は「意味は近いが事実が違う」ため、厳密な語句照合のほうが引っかかりにくいのです。\n\nそこで、2つの対照実験を行います。\n\n- **質問の言い換え**：表現を変えて語句の重なりを減らします。土台ではBM25が63.9、File-System Agentが73.3、DenseRAGが51.8になります。言い換え後は、小規模データベースでのagentの強みがより明確になりますが、BM25は引き続き密なベクトルとグラフによる検索を上回ります。\n- **上位10チャンクを取得**：検索深度を2倍にすると、BM25は83.0、DenseRAGは70.0で、差は残ります。\n\n### 読むときに押さえておきたいこと\n\n1. **評価セットはひとつだけ。**EnterpriseRAG-Benchは模擬的な企業コーパスです。質問中の語句の手がかりや罠の設計は、語彙検索と意味検索の相対的な性能に影響します。\n2. **密なベクトルによる検索には小型モデルを使用。**embeddingはすべてQwen3-Embedding-0.6Bです。より大きいembeddingモデルでDenseRAGの成績が変わるかは、測っていません。\n3. **ハイブリッド検索は未評価。**各流派の単独パイプラインを比較しており、BM25と密なベクトルによる検索の融合や、BM25の後にrerankerをつなぐ一般的な構成は含まれません。最も近いのはAgent+BM25です。\n4. **回答モデルは1種類、各問は1回実行。**不確実性は問題の再抽出から推定しており、繰り返し実行によるばらつきは測っていません。\n5. **コードとデータ。**付録にはコード・データの補足資料の内容と対応関係が記載されていますが、v3本文には公開ダウンロード先がありません。\n\n## 結論\n\nこの論文は、28段階、約450倍の入れ子のデータベースを作り、問題、正解文書、罠を固定したまま、背景文書だけを増やしました。この条件では、次のような結果になります。\n\n1. **勝者は固定されず、交差点がある。**小規模ではFile-System Agentがわずかに先行します。約1,000万tokenを超えると、共通するすべての段階でBM25が先行し、全コーパスでは20点近い差になります。\n2. **BM25は安く、安定している。**各問約5.8K tokenで、索引構築にLLMも不要です。コストと精度のトレードオフの低コスト側をしっかり押さえています。\n3. **Agentの問題は見つけられないこと。**ファイルツリーのツールをBM25の順位付き検索に変えると、同じagentが全コーパスで36.9点から69.4点へ上がり、tokenは9分の1になります。\n4. **グラフ型RAGは構築で行き詰まる。**LightRAGを外挿すると、1台で約4年かかります。構築できたHippoRAG 2も、得点はBM25を下回りました。\n\n企業コーパスに対する著者の実務的な提案は明快です。**標準はBM25。複数の資料を統合する問いにはAgent+BM25。**LLMでグラフを作る索引は、10万〜100万件の文書規模では採用を説得しにくくなります。検討するなら、構築コストがほぼ線形で、質問の多くが関係を尋ねる場合でしょう。\n\nデータが増えると、30年前の手法が戻ってきました。今度は、agentの前に立って道を開いてくれます。\n","imageSizes":{"/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png":{"width":700,"height":550}}}