2026年9月16日、MLCommonsは新たにエンドツーエンドのリトリーバル強化生成（RAG）およびエッジエージェント推論テストを含むMLPerf Inference v6.1の結果を発表しました。[1] プライベートAI購入者にとって有用な進展は、より広範な測定単位の導入です。ワークフローに関する証拠は、短時間のモデル応答テストでは解決できない疑問に答えられます。当社の推奨は、これらの結果をパイロット設計に活用し、その後実際の展開を別途測定することです。

本記事は2026年9月26日時点の情報を反映しています。Software Tailorによるベンチマーク提出や、 AI Server展開 が公開された結果を再現することを保証するものではありません。

スコアを比較する前にワークロードを理解する

今回のリリースでは、リトリーバルと生成をまたぐRAGワーク、および繰り返しのターンと履歴の蓄積を伴うエッジエージェントワークロードが説明されています。[1] これらは購入者にとって有用な区別です。ドキュメントアシスタントとコーディングワークフローはどちらも言語モデルを呼び出しますが、その周辺作業は別々に調査する価値があります。

検討中の業務運用から比較を始めてください。入力、期待される出力、そして業務が完了するポイントを明確にします。ドキュメント回答は引用された箇所が開ける状態で初めて完成といえます。エージェントタスクは、回答が利用可能になる前に検証済みのツール結果を必要とする場合があります。これらはMLPerfが課す追加要件ではなく、提案された受け入れ境界です。

ベンチマークの境界をその説明の隣に置きます。結果がカバーする各段階と提案されたアプリケーションに属する各段階をマークしてください。明確なギャップは有用です。パイロットが測定すべき作業を特定できるからです。単一の総合スコアにギャップを隠すことは、比較を行う意義を失わせます。

コーパスの準備と質問への回答を分ける

MLCommonsが8月に発表したRAGベンチマークでは、ベクトルデータベースを作成する取り込みパイプラインと、それを用いて質問応答を行うパイプラインを区別しています。後者は複数回のリトリーバルと推論を繰り返すことが可能です。[2] これにより、準備作業が回答作業と並列して可視化されます。

自社のドキュメントコレクションを評価する組織向けに、当社が提案するパイロットは2つの記録を持ちます。1つは定義済みコレクションの準備を記述し、もう1つはそのコレクションに対する固定質問セットへの回答を記述します。両記録にドキュメントのバージョンと準備設定を保持し、回答が同一の起点に遡れるようにします。

次に制御されたドキュメント更新を加えます。変更が質問応答経路に反映されるタイミングと、移行中にユーザーが見るものを観察します。これを独自の結果を持つアプリケーションテストとして扱います。外部ベンチマークの取り込み結果は、別のドキュメントストアに対する更新保証を意味しません。

この区別は、調達部門が単一の応答時間保証を求める場合に特に有用です。チームは保証が既に準備済みのコレクションから始まるのか、新規ドキュメントの検索可能化を含むのかを明確にできます。 キャパシティプランニング記事 その区別をビジネス上の意思決定に発展させます。

エージェントのシーケンスをシーケンスとして扱います。

迅速な最初の回答は、証拠を繰り返し検査しツールを呼び出すアプリケーションにとって不完全な受け入れ基準です。私たちの提案する評価方法は、タスク全体を可視化したままにします。連続するリクエスト、許可された操作、最終結果を記録し、アプリケーションがどこで待機したか、または介入が必要だったかを検査します。

オープンエンドの作業を追加する前に、結果が既知のタスクを使用してください。小規模な架空の在庫で十分であり、エージェントが意図したアイテムを要求し、正しい結果を受け取り、それを次の応答に反映しているかを確認できます。 AI Server 統合手順 その例を用いて接続チェックとツール実行を分離します。

長い入力やフォローアップのターンを意図的に追加してください。これらのケースは報告書で名前を付けて保持し、説明のない平均値に混ぜ込まないでください。テストが早期に終了した場合は、停止理由と未完了の内容を記録してください。評価者が完了したタスクと偶然早く到達した部分的な回答を区別できると、結果の解釈が容易になります。

比較条件を付けたままにしてください。

MLCommons は Closed と Open の区分、およびシステムの可用性カテゴリを区別します。結果ページには変更履歴へのリンクもあり、公開された結果は後に修正または無効化される可能性があります。[3] したがって、調達記録は参照した正確な結果と確認日を保存すべきです。

提案するショートリストシートには、ベンチマークのバージョン、ワークロード、シナリオ、システム構成、報告された指標を含めます。区分と可用性カテゴリも追加してください。候補結果がこれらの項目で異なる場合は、順位付けの前に違いを説明してください。これは証拠を解釈するための規律であり、異なるシステムが比較できないという主張ではありません。

意図したインストール用の別の列を保持してください。そこには組織が使用を想定するモデル、展開トポロジー、アプリケーションワークロードを記述すべきです。公開された構成が提案された予算や運用環境内で再現できない場合は、それを明確に示してください。結果は調査の参考になるかもしれませんが、黙って受け入れ目標にしてはいけません。

ベンチマークをパイロットブリーフに変換してください。

実用的な成果は範囲を限定した実験です。正確性を検査できるタスクを選び、ワークロードの段階を定義し、タイミングの境界を明示します。候補サプライヤーに、公開された証拠が提案された経路のどの部分をカバーしているかを尋ねます。残りの質問は、名前付きの受け入れ基準を持つローカルパイロットに割り当てます。

Software Tailor にとって有用な 展開に関する議論 はそのブリーフと意図したデータ境界から始まります。組織の規則の下で共有可能な代表的な入力、または同じワークフローを実行する架空の同等物を用意してください。ビジネス受け入れ、セキュリティチェック、測定されたパフォーマンスは別々の所見として保持します。

ベンチマークは購入者に提案されたインストールについてより良い質問を残すべきです。最終的な購入決定にはそのインストールに関する回答が必要です。

参考文献

[1] MLCommons. MLPerf Inference v6.1 結果発表. 2026年9月16日公開。2026年9月26日閲覧。

[2] MLCommons。 MLPerf エンドツーエンド RAG 推論ベンチマークの紹介. 2026年8月26日公開。2026年9月26日閲覧。

[3] MLCommons。 MLPerf 推論：データセンター現在の結果と方法論の概要。2026年9月26日閲覧。

関連記事

Get it from Microsoft