大規模 RAG では BM25 が強い：検索手法のスケーリング研究

導入

RAG システムの検索部分には、古典的な BM25、密ベクトル検索、グラフインデックス、そして Agent が順番に探索する方式など、さまざまな選択肢がある。しかし、これらは別々のベンチマークや単一のコーパスサイズで評価されることが多く、実際にコーパスが大きくなったときにどの方式が強いのかは見えにくかった。

論文「BM25 Wins at Scale」は、この問題をスケーリングの観点から検証している。研究では、コーパスサイズを 28 の厳密にネストした段階に分け、全体で約 450 倍の幅を持たせた。その一方で、質問セットと、関連文書・敵対文書からなる固定の基盤部分は変えない。さらに、読者モデルと評価手順も統一し、精度、構築コスト、クエリトークン、レイテンシを測定している。

主なポイント

• 勝者はスケールによって変わる。 最小規模の共有ティアでは、File-System Agent が最も良い結果を出した。探索空間が小さい場合、逐次的にファイルや文書をたどる能力が役立つ。
• Agent 型探索は高コストになりやすい。 基盤ティアでは、File-System Agent のクエリトークン消費は 39 倍に達する。コーパスが大きくなると、逐次探索だけでは十分な候補を見つけにくくなる。
• 約 1000 万コーパストークン付近で BM25 が逆転。 その後のより大きな共有ティアでは、BM25 が継続して首位に立ち、最大規模では差が約 20 ポイントに近づく。
• BM25 は低コスト側の強い基準になる。 LLM による構築処理を必要としないため、インデックス作成や検索のコストを抑えやすい。
• 密ベクトル検索は効率的だが精度では届かない。 この実験設定では、効率面の魅力はあるものの、BM25 を上回る精度には至らなかった。
• グラフ型 RAG には構築の壁がある。 一部のグラフ方式は実運用規模に達する前に構築コストの制約に直面し、スケーラブルな変種も共有ティアでは BM25 を下回った。

意義と影響

この研究は「BM25 が常に万能」という単純な主張ではない。むしろ重要なのは、RAG の優劣はコーパス規模によって変わるという点だ。小規模では Agent の探索と推論が有効でも、大規模になるほど、全体から候補を高速にランキングする仕組みが重要になる。

実務上は、複雑な Agent やグラフ構築を最初から標準にする前に、BM25 のような語彙検索を強力なベースラインとして検証すべきだろう。特に大規模な社内文書検索や知識ベース QA では、精度だけでなく、構築コスト、クエリトークン、レイテンシも無視できない。

より現実的な設計は、Agent に検索全体を任せることではなく、まず BM25 などで広く候補を集め、その後に Agent や読者モデルで推論・再ランキング・回答生成を行う形かもしれない。RAG の評価には、単一スコアではなく、スケールしたときの振る舞いを見る視点が必要だ。

出典：Hugging Face Daily Papers