MLCommons、RAG 推論の初ベンチマーク「MLPerf End-to-End RAG」を発表

MLCommons の MLPerf Inference ワーキンググループは、新しいエンドツーエンドの検索拡張生成（RAG）ベンチマークの初公開を発表します。RAG は、重みだけに頼るのではなく、クエリ実行時に取得した文書から回答を生成するため、ハルシネーション（幻覚現象）を減らし、最新かつ機密性の高い知識を活用できます。この特性により、言語モデルのデプロイにおいて最も一般的な手法の一つとなっています。

本番環境で稼働する RAG システムは単一のモデルではなく、関連文書を取得し、それらを推論して根拠ある回答を生成する複数のモデルからなるパイプラインです。

検索拡張生成（RAG）パイプラインでは、まずソースデータを取得・チャンク化し、保存と検索のために意味的なベクトル埋め込みに変換します。その後、取得した関連データとユーザーのクエリを組み合わせて、正確なモデル駆動型の回答を生成します。このベンチマークは、こうした一連のプロセス全体を測定するものです。

本ベンチマークは、以下の 2 つのワークロードを中心に構築されています。

• ドキュメントコレクションからベクトルデータベースを構築するインジェストパイプライン
• ベクトルデータベースに対してクエリを実行し、十分な証拠が揃うまで複数回の「取得→推論」ステップを繰り返して回答する Q&A（質問応答）パイプライン

これら 2 つの要素を組み合わせることで、実際の RAG デプロイメントを支配する要因——異なる役割と規模を持つ複数のモデルが反復ループの中で動作するという現実——を捉えることができます。単一モデル向けのベンチマークでは測定できない部分です。

MLPerf において、RAG パイプライン全体をエンドツーエンドで評価する初のマルチコンポーネント推論ベンチマークが発表されました。本記事では、このワークロードの独自性、データセットとタスク、モデルと指標、そしてリファレンス実装について解説します。

なぜエンドツーエンドの RAG なのか？

RAG は急速に普及し、多くの導入事例において不可欠な技術となっています。クエリ時に取得した文書に基づいて回答を生成することで、ハルシネーション（幻覚）を抑制し、回答の鮮度を保つことができます。また、一般モデルが学習していない独自データや機密情報を活用できるため、企業が求める特性をすべて満たしています。

本質的に RAG はマルチコンポーネントシステムであり、その挙動は個々のコンポーネント単体ではなく、それらがどのように組み合わされ、連携して提供されるかによって生み出されます。従来のシングルモデル LLM ベンチマークではこれを捉えきれません。これらは通常 1 つのモデルを 1 つのプロンプトで評価するものであり（トークナイザーやデトークナイザーが関与しないケースがほとんど）、実際の RAG 導入を支配するパイプライン固有の挙動は測定されず、複数のモデルを同時に提供することによる最適化の可能性も探求されてきませんでした。

さらにこれは、エージェント AI のベンチマークに向けた重要な一歩でもあります。RAG はエージェントが利用するツールの一つであり、そのマルチコンポーネントかつマルチモデルの提供における課題は、完全なエージェントベンチマークで測定すべきことの初体験と言えます。今回の取り組みは、将来のエージェントベンチマークが構築するための基盤となるものです。

これは、従来の LLM ベンチマークでは見られなかった新たな最適化の道を開くものです。このパイプラインは、1 つのプロンプトに対して 1 つのモデルを実行するのではなく、異なる役割とサイズを持つ複数のモデルを並列で実行するため、単一モデル向けベンチマークには存在しない制御レバーが提出者に与えられます。具体的には以下の点が挙げられます。

– モデル配置：コンポーネントをシステム上にどのようにマッピングするか。例えば、小型および大型の言語モデルを別々のアクセラレータに割り当てるか、あるいは E2E 精度基準を満たしつつ、軽量コンポーネントを CPU で異なる精度レベルで実行するかなどです。

– コレジデンス：1 つのデバイス上で複数のモデルをどのように共有するか。メモリパーティショニングやハードウェアレベルでの分離を通じて実現します。

– マルチステージ呼び出しのスケジューリング：異種アクセラレータ間におけるパイプライン全体、および各構成要素内でのマクロバッチ処理とマイクロバッチ処理を組み合わせて、多数の並行タスクを効果的なパイプラインとして重畳実行する方法です。

– プレフィックスキャッシング：マルチホップコンテキストは各ホップごとに成長するため、共有プレフィックスの再利用により、計算集約型の事前填充（prefill）をメモリ集約型に変換できます。

– システムレベル最適化/KPI：CPU/GPU/NIC/ストレージにわたる効果的なパイプライン実装を通じて、実際のデプロイメントシナリオを模倣したシステムレベルの KPI を示すことです。

データセットとタスク選定

本タスクは、FRAMES ベンチマークを用いて、Wikipedia ドキュメント群に対するマルチホップクエリへの回答です。

824 件のクエリがあり、それぞれに正解となる回答と、その回答に必要な Wikipedia アーティクルの URL が含まれています。

本ベンチマークには、2,515 件の Wikipedia HTML アーティクルが凍結スナップショットとして同梱されており、すべての提出者が同一のコーパスをインデックス化できるようになっています。

約 107,000 件のパッセージ（セグメント）を用意しており、各アーティクルは埋め込みとインデックス作成のために 768 文字ごとに分割され、32 文字の重なりを持たせています。

FRAMES が採用された理由は、公開データであり事実性が保証されており、明確な正解が存在する点です。また、数値計算、表解析、時間的推論、複数の制約条件への対応、後処理など、多様な推論タイプをカバーしています。

何より重要なのは、そのクエリが「マルチホップ（複数段階）」であることです。これが FRAMES を RAG システムに対する厳しいテストにしている理由です。マルチホップのクエリは単一のパッセージから回答を得ることはできず、一度に現れない複数の事実を結びつける必要があります。つまり、すべての工程で役割を果たさなければなりません。

例えば（図 1）:

「ソーシャルメディア企業の本部で Rahul Ligma 氏と Daniel Johnson 氏と共に写真に写った人物は、正式な診断を受けていないにもかかわらず特定の症候群を持っていると主張しています。この症候群は誰の名前にちなんで名付けられたのでしょうか？」→ 正解：Hans Asperger

単一のパッセージに答えはありません。パイプラインは、複数の記事にまたがる 3 つの事実を結びつける必要があります。具体的には、「その写真を投稿したのは誰か（Elon Musk）」「彼が患っていると主張する症候群（アスペルガー症候群）」「その名前の由来となった人物（Hans Asperger）」です。証拠がつながるまで、検索を段階的に再構成し続ける必要があります。

図 1: マルチホップ E2E RAG の例

本ベンチマークは、このデータセットを 2 つの独立したパイプラインを通じて検証します。それぞれが独自の MLPerf ワークロードとなります。

データ取り込み（e2e-rag-db）はデータベース構築のために一度だけ実行され、Q&A（e2e-rag-qna）が採点対象となるエンドツーエンドの処理パイプラインです。

図 2: E2E RAG のデータ取り込みと Q&A パイプライン

データ取り込みパイプラインは、コーパスを検索可能なベクトルデータベースに変換するもので、これは一度きりの作業です。まず、ベンチマークに同梱された 2,515 件の Wikipedia HTML ファイルから各記事の本文を抽出します。この際、参考文献やナビゲーションなどの Wikipedia 固有のメタデータは除去されます。表やリストも削除されることなく、行ごとにテキストとして平坦化（フラット化）されます。

次に、そのテキストを 768 文字ごとのチャンクに分割し、それぞれに元の Wikipedia URL を付与して追跡可能にします。このサイズは調整済みで、チャンクが大きすぎると無関係なテキストが混入し、小さすぎると関連する事実が分断されてしまいます。境界付近にある事実を切り離さないよう、32 文字のオーバーラップ（重複領域）を設定しています。

最後に、各チャンクを 768 次元のベクトルに変換してエンコードし、FAISS HNSW グラフにインデックス登録します。これにより高速な近似類似度検索が可能になります。このようにして作成されたベクトルデータベースが、すべての Q&A 実行で参照される基盤となります。

QnA パイプラインは、インジェストパイプラインで生成されたデータベース（E2E-RAG-DB）をループ処理してクエリに回答します。単一のモデル呼び出しではなく、これは QnA タスクとして扱われます。クエリはサブクエリを含む反復ループを通じて複数のコンポーネントを通過し、最終的な回答に至ります。

まずクエリライターが、最大 3 つの焦点を絞ったサブクエリに分解します。各サブクエリはインジェスト時と同じ埋め込みモデル（embedder）でベクトル化され、データベースから最も類似した文脈を取得するために利用されます。次にランカー（reranker）がこれらの候補を重複排除し、関連性の高い順に再排序して上位の数件を残します。

ドキュメントグレーダーは取得された各文脈の関連性を判定し、回答に寄与するもののみを保持します。さらに充分性チェッカーが、蓄積された証拠だけでクエリに答えられるかを判断します。もし不十分であれば、クエリライターは新たなサブクエリを生成して検索範囲を広げ、最大 5 回のホップまでループを繰り返します。

証拠が十分になったか、あるいはホップ制限に達した時点で、回答生成モジュールが保持された文脈に基づいて最終回答を作成します。もし証拠が不足している場合は「Unknown」と返却されます。

モデル選択

• コンポーネント：モデル / パラメータ数 / 参照精度 / レイヤー / ベクトル次元
• Embedding：intfloat/e5-base-v2 / 110M / FP32 / 12768 / per passage
• Reranking：ColBERTv2.0 / 110M / FP32 / 12128 / per token
• Query Rewriter：GPT-OSS-120B / 120B / 5.1B ActiveMX / FP4 / 36– / –
• Sufficiency Checker：GPT-OSS-120B / – / – / – / –
• Final Answer Generation：GPT-OSS-120B / – / – / – / –
• Document Grader：GPT-OSS-20B / 20B / 3.6B ActiveMX / FP4 / 24– / –
• Judge：Llama-3.1-8B / 8B / BF16 / 36– / –

すべてのモデルは MLCommons-Storage からダウンロード可能です。

埋め込みエンコーダーには intfloat/e5-base-v2 を採用しています。検索用にクエリとパッセージの別々のエンコーディングで訓練されたこのモデルは、RAG（Retrieval-Augmented Generation）におけるクエリからドキュメントへのマッチングに適しており、標準的なベンチマーク（MTEB、BEIR）でも高い性能を発揮します。また、パラメータ数はコンパクトな 1.1 億で、広く採用されています。

再ランク化には ColBERTv2.0 を使用し、一般的なクロスエンコーダーではなく、後期相互作用（late interaction）を採用しています。トークンレベルでのマッチングにより、パッセージを単一のベクトルに圧縮する従来の手法よりも細粒度な関連性を捉えることができ、新しいドメインへの汎化性も優れています。これは、企業利用で一般的であるプライベートな文書コレクションに適した特徴です。

推論が中心となるクエリの書き換え（良いサブクエリへの変換）、証拠の十分性の判断、最終回答の生成といったタスクは GPT-OSS-120B が担当します。このモデルはオープンソースであり、MLPerf の参加者によってすでに広く展開され、最適化が進んでいます。

文書の評価（再ランク化されたパッセージが関連性を持つかどうかの判定）には GPT-OSS-20B を使用します。これは大量の分類処理を伴うタスクであり、小規模なモデルを採用することで、実運用における「簡単な作業は適切なサイズのモデルに割り振り、すべてを最大規模のモデルに任せない」という現実的なデプロイメント戦略を反映しています。また、120B モデルと同じ gpt-oss アーキテクチャを採用しているため、サポートにかかる追加コストはほとんどありません。

評価者（judge）には Llama-3.1-8B-Instruct を採用しました。これは、評価対象となる GPT-OSS モデルとは異なるファミリーから意図的に選定されており、自己偏倚バイアスを回避するためです。このモデルは、精度テストが完了した後に回答を採点します。

パフォーマンス指標

MLPerf Inference では従来、オフラインとサーバーという 2 つの運用シナリオが定義されてきました。今回の初回実施では「オフライン」に焦点を当てています。これはすべてのリクエストが同時に利用可能であり、最大のスループットを実現するためにスケジューリングできるケースです。「サーバー」モードは次回以降のラウンドで取り扱います。

各パイプラインは独自のスループット指標を報告します。データ取り込みでは「1 秒あたりの文書数」、Q&A では「1 秒あたりのタスク数」が用いられます。

データ取り込みにおいては、「1 秒あたりの文書数」が自然な単位です。各文書は、解析（parse）、チャンク化（chunk）、埋め込み（embed）、インデックス作成という一連の処理を経て流れていきます。提出者はこの「文書」を作業の基本単位として扱うため、「1 秒あたりの文書数」であればシステム間で直接比較が可能になります。

Q&A については、言語モデルで一般的に用いられる「1 秒あたりのトークン数」という指標は適していません。なぜなら、このパイプラインでは異なるサイズの 2 つの言語モデルが、言語モデル以外のコンポーネントとともに動作しており、単一のトークンレートではシステム全体を表現できないからです。「1 秒あたりのホップ数」のような指標も解釈が難しい場合があります。Q&A タスクはホップ数が可変であるためです。

「1 秒あたりのタスク数」という指標は、これらの問題を回避し、最も重要な単位——つまり、エンドツーエンドで回答された 1 つのクエリ——を測定することで解決します。他のベンチマークと比較すると数字が小さく見えるかもしれませんが、これは 1 クエリあたり最大 5 ホップ、そして 10 回以上の言語モデル呼び出しが発生しうるためです。

QnA パイプラインは、言語モデル生成に内在する非決定性に加え、再現が難しい複雑で動的なワークロードです。パフォーマンス測定では、各ホップの各段階に対して記録された参照入力が用意され、ホップ数と取得されるドキュメント数が固定されます。出力は通常通り生成されますが破棄されるため、パイプラインは実際の処理を行いながら、実行ごとのばらつきを最小限に抑えることができます。

精度指標について

検索品質（必要な Wikipedia URL に対するもの）は公式の指標ではありません。これはデータベース整合性のチェックであり、提出者が独自に構築したベクトルデータベースが参照と同等の挙動を示し、全員が同じコーパスから回答していることを確認するために使用されます。

824 クエリセット全体における参照値：

• Metric：Value
• Final answer：35%
• Precision / Recall / F1：75% / 70% / 69%

提出された回答の精度が、参照精度の少なくとも 97% に達している場合に限り有効とみなされます。

回答精度は、クエリが求める推論の種類によっても変動します。以下の内訳は参考情報であり、1 つのクエリに複数の推論タイプが含まれることもあります。

• Reasoning type：Answer accuracy
• Multiple constraints：38%
• Post-processing：34%
• Temporal：32%
• Tabular：31%
• Numerical：31%

複数の制約条件を持つクエリは、主に離散的な事実の収集を必要とするため、密度検索と言語モデルが得意とする領域であり、スコアが高くなる傾向があります。一方、数値や表形式のクエリは最も困難です。これらは文章や表から正確な数値を引き出し、それらに対して計算を行う必要があるため、数字の読み間違い一つや、表をまたぐチャンク境界のミスがクエリの失敗に直結します。時間関連や後処理が必要なクエリはその中間に位置し、日付の演算や検索結果に対する最終的な変換処理が必要です。

これらのギャップを埋めるには、自然とアジェンシー型のパイプラインへの移行が求められます。具体的には、システムがエンティティや関係を照会できる知識グラフまたは構造化インデックスの構築、数値が破損せずに取り込まれるよう表形式データを意識したパースとチャンキング手法、そして計算処理や単位変換を担うコードインタプリタなどのツールを回答生成ステップに組み込むことです。これらはすべて、今日までの固定された「検索→読み込み」ループから脱却し、必要な情報をどのように見つけ、どう処理するかを自律的に選択するエージェントへと進化させるための一歩です。

コンプライアンス

E2E-RAG-QnA では、単一のコンプライアンステスト「TEST09（出力トークン長さの検証）」が要求されます。これは LoadGen のパフォーマンスモードでワークロードを再実行し、audit.config を用いて回答生成器からの平均出力トークン長さを基準値と比較するものです。LoadGen が参照実装に対して確認するのは、平均 OSL が 273.81 トークンであり、±10% の許容範囲（246.43〜301.19）内にあるかどうかです。このチェックは、パフォーマンスモードで基準よりも体系的に短い回答を生成して作業量を減らそうとする提出物を防ぐ役割を果たします。

この検証はパイプラインの 1 つの工程における単一の集計値であり、検索や再ランク付け、中間クエリや充分性判定のための LLM 呼び出しに対するガード機能はありません。今後の改訂では、分布レベルやコンポーネントごとのコンプライアンスカバレッジを追加する可能性があります。

最適化の機会

E2E RAG パイプラインは、ベクトル DB の生成から推論サービングフレームワーク、密・疎カーネル、KV キャッシュを考慮したスケジューリングに至るまで、推論スタック全体にわたって多層的な最適化の余地を意図的に設けて設計されています。参照実装はいくつかの次元において明確ではあるものの未最適化のベースラインを提供しており、精度を損なうことなく、提出者がシステムやカーネルの改善を探求できる余地を残しています。

CPU パイプライン：MLPerf Loadgen は、このオフラインシナリオにおいて、824 のクエリ/タスクをすべて一度にサービングフレームワークへ提供します。これにより、提出者は E2E パイプライン全体およびその構成要素それぞれにおいて、対応するアクセラレータへの適切なアフィニティとメモリ配置戦略を考慮し、CPU の複数のコア間でタスクをどのようにスパンさせるかを探索できる大きな機会が得られます。

GPU 分割と KV キャッシュのバランス：アクセラレータ内およびアクセラレータ間での低レイテンシを実現する効果的なマルチモデル配置により、計算・通信・ストレージに関与するすべての構成要素アクセラレータを飽和させます。これには、効率的な低レイテンシかつ高スループットの CPU-GPU 間の相互作用や、マクロバッチとマイクロバッチにわたる GPU-GPU/アクセラレータ間の相互作用における計算と通信のバランス調整が含まれ、パイプラインをタイトに維持します。

異なる精度を持つマルチモデル：E2E の精度基準を満たす限り、選択されたすべてのモデルは異なる精度で動作させることができます。これにより、システムレベルで最高のパフォーマンスを提供できる適切な精度を選択的に選定し、さらなるイノベーションの機会が生まれます。

結論

これは、単一のモデルを孤立して測定するのではなく、RAG パイプライン全体をエンドツーエンドで計測するための MLPerf 初のベンチマークです。展開された RAG システムを実際に支配している要素——異なる役割とサイズを持つ複数のモデルが、反復的なマルチホップループを通じて一緒にサービングされる様子——を捉えています。

これは、将来の Agentic RAG（エージェント型 RAG）への道を開くものです。その中核をなす「検索→推論→決定」のループは、エージェントを駆動するループと本質的に同じです。今後はツール利用や構造化された情報取得、システムが情報を発見・処理する方法における自律性の向上など、自然な次のステップへと進み、完全なエージェンシーベンチマークへと着実に近づいていきます。近い将来には EndPoints/Agentic Intercept を通じて、コミュニティと共にこのベンチマークを進化させていくことを楽しみにしています。

参考文献

• E2E-RAG リファレンス実装の始め方
• リファレンス実装
• MLPerf Inference Benchmark データダウンロード
• 遅延最適化推論のための新たな GPT-OSS ベンチマークと DeepSeek R1 の更新 – MLCommons
• E2E-RAG 用の MLPerf Inference ルール
• FRAMES Paper（論文）

謝辞

MLCommons E2E RAG タスクフォースの参加者、MLPerf Inference ワーキンググループ、および MLCommons プラットフォームエンジニアリングチームに対し、このベンチマーク開発におけるフィードバック、サポート、指導に心から感謝いたします。業界と学術界を問わず、さまざまな提案の評価に多大な貢献をいただいたすべての関係者に深く敬意を表します。異なるタイムゾーンを超えた協力により、初めてとなるユニークなベンチマーク定義を実現できたことに、皆様に感謝申し上げます。

また、マルチホップベンチマークに内在する非決定性（non-determinism）への対応策のアイデアを提供してくれた Multi-Turn Taskforce にも謝意を表します。

特に、FRAMES データセットの著者である Satyapriya Krishna 氏には、議論に参加して明確化と指導を提供いただいたことに心から感謝いたします。

MLPerf によるエンドツーエンドの RAG（Retrieval-Augmented Generation）推論ベンチマークの導入について

本記事は、MLCommons で初めて公開されたものです。