top of page

自律型ボクシング・ベンチマークがAIレイテンシーをリングに上げる

ある開発者が自律型ボクシング・シミュレーション内でGemini Flash Liveをテストしたことによると、Googleは今週、異例のベンチマークに挑むことになった。このプロジェクトでは、静的な質問の代わりに、攻撃を認識し、応答を選び、シミュレーション上のパンチが当たる前に行動しなければならないファイターを用いる。

この前提は、暴力的なテーマから想像される以上に興味深い。このGoogle horizonは、コーディングに要する時間や数千の学術的な質問ではなく、1秒未満の時間で測られる。優れた推論をしても、応答が遅ければ攻撃を受ける。

開発者によれば、Gemini Flash Liveは視覚情報を使ってパンチをかわし、カウンターを繰り出せるという。一方、8GBメモリのNvidia GeForce RTX 5060 Tiで動作するローカルモデルは、判断を出すまでにより長い時間を要するとされる。ただし、最初のReddit投稿には、公開リーダーボード、再現可能なコード、完全な結果、独立した検証はいずれも添えられていなかった。

そのため、このプロジェクトは創造的なデモと、擁護可能なベンチマークの中間に位置する。中心的な問いには依然として価値がある。AIエージェントが変化する環境で動作する場合、応答時間も知能の一部として数えるべきなのだろうか。

ボクシング・シミュレーションは遅延をダメージに変換する

この実験は、遅いモデルの応答を即時の競技上の不利に変換することで、レイテンシーを可視化する。

作成者は、判断速度、適応力、戦略を試すためのAI制御ボクシング対戦としてこの仕組みを説明している。各モデルは現在の試合に関する情報を受け取る。視覚をサポートするモデルは追加の視覚データも受け取れるが、正確な形式やサンプリング頻度は明らかにされていない。

このシミュレーションは、意図的に緩い「ストリートルール」を採用している。何でもありで、ファイターはダウンしただけでは敗北しない。レフェリーが10まで数えるか、相手がノックアウト後にファイターの体力の50%に相当するダメージを与えなければならない。

こうしたルールは継続的なプレッシャーを生む。モデルは、状態、位置、相手、残り時間が絶えず変化するため、各攻防を独立したプロンプトとして扱うことはできない。環境が動き続ける中で行動を選ばなければならない。

開発者によると、目的は固定された答えを持つ問題集をもう一つ作るよりも、より楽しめるテストを作ることだったという。ボクシングという表現は、失敗について直感的な説明も与える。遅れた回答は抽象的なレイテンシー値としてではなく、ブロックの失敗や応じられないコンビネーションとして現れる。

この明快さは有用だが、誤解を招く可能性もある。アニメーション化されたファイターは、モデルがシーン全体を継続的に見て、理解し、制御しているような印象を与える。実際の基盤システムは、ゲーム状態をテキストに変換し、定期的に画像を送信し、あるいはモデルを小さなアクションメニューに制限しているだけかもしれない。

こうした実装上の選択が、システムが実際に何を測定しているかを決める。「dodge」「block」「counter」から選ぶモデルが直面する問題は、移動、タイミング、方向、攻撃選択を独立して制御するエージェントの問題とは異なる。

元の投稿では、アクション空間、プロンプト形式、更新間隔、ネットワーク条件、乱数シード、試合数は明かされていない。完全なスコア分布も提示されていない。したがって、Geminiが回避やカウンターを行えるという主張は、確立されたモデルランキングではなく、作成者の観察として扱うべきである。

それでも、このコンセプトは静的な評価がしばしば隠す問題を露わにする。多くのベンチマーク問題では、モデルが考える間、事実上世界が停止する。現実のインターフェース、ロボット、ゲーム、ライブアシスタントには、そのような特権はない。

GoogleのLive APIは、連続した音声、画像、テキストストリームを用いる低レイテンシーのインタラクション向けに設計されている。ボクシング環境は、その設計を測定可能な帰結へと押し進める。応答が遅れれば、前の判断が意味を持つ前に次の状態が到来する。

Google horizonがミリ秒で測られる理由

ここで重要なGoogle horizonは、Geminiがどれだけ長くタスクを追えるかではなく、知覚と行動のループがどれだけ迅速に有用性を保てるかだ。

AI研究者はすでに、エージェント能力を論じる際に「time horizon」を用いている。METRは、タスク完了のtime horizonを、エージェントが指定された成功確率に到達する人間のタスク所要時間として定義している。現在の測定は主に、ソフトウェアエンジニアリング、機械学習、サイバーセキュリティの作業に焦点を当てている。

この枠組みは、より長い人間の労働時間を必要とするタスクを、エージェントが確実に完了できるかを問う。ボクシング・プロジェクトが問うのは別のことだ。判断が、結果を変えられるほど短くなっていく時間枠の中に届くかを試す。

両方の考え方は重要だが、説明なしに同じスコアにまとめるべきではない。コーディングエージェントは、リポジトリが通常は待ってくれるため、計画を修正するのに数分を費やせる。飛んでくるパンチに直面するファイターには、反応できる有効な瞬間が一度しかないかもしれない。

これにより、少なくとも4種類の遅延が生じる。

第一に、シミュレーションは現在の状態を収集しなければならない。視覚が関係する場合、画像または動画フレームをキャプチャしてエンコードする必要がある。古いフレームは、推論が始まる前に優れた判断を損なう可能性がある。

第二に、アプリケーションはその入力を送信しなければならない。ローカルデプロイメントはインターネット経由の転送を回避できるが、それでもシリアライズ、スケジューリング、メモリのコストを負担する。ホスト型システムにはネットワークの変動性が加わる。

第三に、モデルは行動を推論しなければならない。より大きな推論予算は計画を改善し得るが、同時に時間も消費する。ライブ環境では、追加の熟考が実用上の性能を下げることがある。

第四に、アプリケーションは応答を解析して実行しなければならない。ゲームが必要とするのが簡潔なコマンドであれば、冗長な説明は役に立たない。出力制約、ツール呼び出し、不正な形式の応答はいずれも、最終的な行動までの時間に影響する。

Googleは以前、Multimodal Live APIを双方向ストリームをサポートするステートフルなWebSocketサービスとして説明している。2024年の開発者向け投稿で同社は、その世代のサービスについて、最初のトークン出力が600ミリ秒だったと報告した。この数値は、条件が特定されていない状況でのプラットフォーム側の主張であり、ボクシングシステムのエンドツーエンドの反応時間を測定したものではない。

この違いは決定的に重要だ。最初のトークンまでのレイテンシーは、行動完了までのレイテンシーと同じではない。有用な評価では、脅威が観測可能になった瞬間から、シミュレーターが有効な防御行動を受理する瞬間までを測定する必要がある。

また、平均だけでなく分布も報告すべきだ。9回の攻防で素早く反応し、10回目で停止するファイターは試合に負け得る。応答の最も遅い5%のようなテールレイテンシーは、平均値よりも生存をよく予測するかもしれない。

作成者によるローカル環境との比較は、この問題を具体化する。投稿によれば、8GBのRTX 5060 Tiで動くモデルは推論に時間がかかり、時間スケーリングの必要性が示唆される。シミュレーションを遅くすれば、これらのモデルも参加できるようになるが、競技の性質は変わる。

時間スケーリングは、ローカルモデルが同等の思考機会を与えられたときに良い行動を選べるかを答えられる。リアルタイムプレイは、デプロイメント全体が同等の環境的プレッシャーの下で有用な行動を生み出せるかを答えられる。これらは別々のテストであり、別々のリーダーボードを生むべきだ。

高速なマルチモーダルモデルが遅い推論モデルに圧力をかける

主な競争は、高速な知覚・行動システムと低速な熟考型モデルの間にあり、Googleと一つの特定の競合相手の対決ではない。

Gemini Flash Liveは、Googleがストリーミングインタラクション向けにLive APIを構築したため、この実験に適しているように見える。そのドキュメントによると、このサービスは連続した音声、画像、テキストを処理し、即時の応答を実現する。クライアントからサーバーへの接続では、アプリケーションバックエンドを経由する追加のホップも削減できる。

このアーキテクチャはGeminiに重要なシステム上の優位性を与える。これは、ボクシング戦略、一般的な推論、適応力における優位を証明するものではない。入力メディアが完了したプロンプト・応答サイクルを待たないワークロード向けに、モデルと配信レイヤーが設計されていることを意味する。

作成者のローカルモデルは、比較のもう一方を占める。コンシューマー向けハードウェアでモデルを動かすことは、プライバシー、制御、再現性、リモートサービスの可用性からの自由を提供する。しかし、メモリ制限はモデルサイズ、コンテキスト、画像処理、量子化の選択を制約し得る。

公正な比較では、どの制約が重要なのかを特定しなければならない。ローカルモデルがテキストを受け取り、Geminiが画像を受け取るなら、そのベンチマークはモダリティとデプロイメントを混同している。両者が同一のフレームを見ても、一方がリモートのストリーミングAPIを経由するなら、結果はモデル能力とインフラを混同する。

どちらの比較も無意味ではない。単に、異なる問いに答えているだけだ。

ライブコーチやインタラクティブキャラクター向けの技術を選ぶ製品開発者は、統合された結果に関心を持つ。モデルアーキテクチャ、ネットワーク、推論ハードウェア、インターフェース設計はすべて、ユーザー体験に影響する。推論能力を比較する研究者には、より強い統制が必要になる。

OpenAIのrealtime modelは、利用可能な別の経路を示している。文書化されたこのモデルはテキスト、音声、画像入力を受け付けるが、動画入力は記載していない。そのため、ボクシングの実装では、どの頻度で画像を送信するか、ゲームイベントとどう同期させるかを決める必要がある。

Google DeepMindのSIMA研究は、より直接的な歴史的参照を提供する。SIMAは画面画像と言語による指示を用い、その後、3Dゲーム内でキーボードとマウスの操作を出力する。DeepMindは、600の基本スキルにわたる評価を報告し、初期タスクはおよそ10秒で完了するよう設計されていた。

このSIMA researchは、インタラクティブ環境が研究者を引き付ける理由も示した。統制されたソフトウェア内で、知覚、言語、記憶、行動、結果を組み合わせるからだ。環境はすべての観測とコマンドを記録できる。

ボクシング・シミュレーションは、そのループをさらに圧縮する。10秒のナビゲーションタスクでは、ためらいから立て直す余地がある。回避行動は、ほぼ即座に有効期限を迎える可能性がある。

ここで、より遅い推論モデルは圧力に直面する。ベンチマークはしばしば、難しい問題に追加の計算を費やすモデルを評価する。ボクシングでは、行動の時間枠が閉じた後に限界的な改善が到着すれば、同じ振る舞いが不利になり得る。

この圧力はモデル提供者に限られない。自律型インターフェースを構築する開発者は、すべての選択を大規模モデルに委ねるべきかを決めなければならない。実用的なシステムでは、即時の防御に高速なコントローラーを使い、攻防の合間の戦略にはより遅いモデルを参照するかもしれない。

そのようなハイブリッドは、両極端を上回る可能性がある。同時に、ベンチマークが単一のモデルではなく、設計されたエージェントを測定することになるため、帰属は複雑になる。この緊張関係は、スキャフォールディングとツール設計が結果に強く影響するエージェント評価全般にすでに存在している。

楽しいデモは、まだ信頼できるAIベンチマークではない

統制された入力、反復試行、完全なタイミングデータがなければ、ボクシング対戦は戦略とシステムエンジニアリングを切り分けられない。

ベンチマークには、環境と勝者以上のものが必要だ。スコアが表すと主張する能力、すなわち定義された構成概念が必要である。「ボクシング知能」は、反応速度、戦術的選択、長期的な適応、視覚理解、または総合的な試合の成功を指し得る。

こうした結果は、互いに矛盾し得る。反応型モデルは頻繁に回避できても、攻勢に転じる機会を作れないかもしれない。戦略型モデルは、後で相手のパターンを突くために限定的なダメージを受け入れる可能性がある。ビジョンモデルは、テキストのみの参加者より豊富な情報を受け取るため、適応的に見えるかもしれない。

ルールも、もう一つの交絡要因となる。ノックアウト後の攻撃を許可し、追加ダメージを要求することは、通常とは異なるインセンティブを生む。従来のボクシング知識で訓練されたモデルは、公認ルールには適した行動を選んでも、シミュレーター独自の条件下では十分に機能しない可能性がある。

だからといって、この環境が無効になるわけではない。新しいルールは、指示追従と適応を試せる。ただし、プロンプトにはそれらのルールを一貫して明記し、評価者はモデルが理解したことを検証しなければならない。

ランダム性も別の問題をもたらす。格闘ゲームでは一般に、当たり判定、移動、ダメージ、タイミングにばらつきがある。1試合が偶然の連続で決まることもある。信頼できるランキングには、開始位置を入れ替えた反復対戦、制御されたシード、信頼区間が必要だ。

モデルの同一性についても、より厳密な扱いが求められる。「Gemini Flash Live」は、必ずしも固定されたスナップショットではなく、モデル群と提供形態を表している。プレビューサービスは変更され得る。再現可能な結果には、正確なモデル識別子、APIバージョン、日付、リージョン、システムプロンプト、生成設定、ツールスキーマを記録すべきだ。

ハードウェア比較にも同じく慎重さが必要である。「RTX 5060 Ti上のローカルモデル」では、モデル、パラメータ数、量子化、推論エンジン、コンテキスト長、画像エンコーダーを特定できない。いずれも応答時間を大きく変え得る。

信頼できる公開であれば、少なくとも3つのスコア群を提示すべきだ。

意思決定の質

  • 与えたダメージと受けたダメージ

  • 成功したブロック、回避、カウンター

  • 無効な行動または戦略的に整合しない行動

  • 複数の対戦相手スタイルに対する成績

タイミング性能

  • 状態取得の遅延

  • ネットワークおよびキューの遅延

  • 最初の実用可能な行動までの時間

  • エンドツーエンド遅延の中央値とテール値

適応性能

  • ラウンドをまたいだ改善

  • 繰り返される相手パターンへの対応

  • 戦術が通用しなくなった後の立て直し

  • 未知のルールまたはファイターへの汎化

評価には、単純なベースラインも含めるべきだ。手作業でコーディングした反応型ポリシーなら、攻撃が閾値を超えたら常に回避する、といったものが考えられる。ランダムポリシーは下限を示す。スクリプト化された戦術ポリシーは、言語モデルが予測可能なルールを超える価値を加えているかを示せる。

AIがそれらのベースラインに安定して勝てないなら、派手な挙動で主張を救うべきではない。逆に、未知の条件でもそれらに勝てるなら、このプロジェクトは単なる視覚的デモを超えるものになる。

人間との比較も役立つ可能性があるが、慎重な設計が必要だ。人間の反応時間、インターフェースへの慣れ、ゲームに関する知識はいずれも結果に影響する。人間にも、モデルと同じ観測可能な情報と行動制約を与えるべきだ。

したがって、制作者が時間スケーリングについて抱く不確実性は建設的である。それは、ベンチマークで最も重要な未解決の選択肢を浮き彫りにしている。同一の実時間は実運用可能な応答性を評価する一方、正規化された時間は調整済みの計算資源の下で意思決定の質を評価する。

最善の答えは、両方を公開することだ。一方の部門ではシミュレーション時計を固定し、もう一方では各エージェントに与えた計算量を追跡しつつ、イベントを停止またはスケーリングできる。そうすれば読者は、賢いが遅いポリシーと、速いが浅いポリシーを区別できる。

METRのtime-horizon methodologyは、明示的なタスク尺度に対して成功確率を定義する価値を示している。同組織のソフトウェアタスクは大きく異なるが、根本的な教訓は応用できる。すなわち、スコアは時間の意味と信頼性の推定方法を正確に示さなければならない。

現時点のボクシングプロジェクトには、その方法論的な層が欠けている。それが整うまで、「Gemini can dodge punches」のような表現は観測された1回の実行を説明しているにすぎない。比較可能な能力を立証するものではない。

インタラクティブなベンチマークが静的スコアでは見落とすものを明らかにする

統制されたボクシングアリーナは、単発の設問セットでは見えなくなる、古い知覚、遅れた行動、弱い立て直しを露呈させることができる。

従来の言語モデルベンチマークでは通常、固定された入力を与え、回答を待つ。この設計は再現性と低コストの採点を支える一方、ためらいのコストを取り除いてしまう。

インタラクティブな環境は、そのコストを取り戻す。次の観測は前の行動に依存する一方、対戦相手や世界は変化し続ける。誤りは1つの不正解で終わるのではなく、累積する。

そのため、見せ方が遊び心のあるものであっても、ボクシングはエージェントの挙動を試す場として妥当だ。モデルは状態を維持し、行動を選び、結果を観測し、方針を修正しなければならない。これらはロボット、画面操作エージェント、ライブアシスタント、自律型ゲームキャラクターにも関係する要求である。

この環境は、最終的な成功率では隠れる失敗も明らかにできる。モデルは最新フレームを統合していないため、矛盾したコマンドを出すかもしれない。有用な要約が記憶にないため、失敗した戦術を繰り返すかもしれない。正しく計画しても、実行の機会をすべて逃す可能性がある。

Googleのリアルタイムスタックは、継続的なマルチモーダル入力をサポートするため、特に関連性が高い。しかし、ライブストリームへのアクセスが正確な時間的推論を保証するわけではない。モデルは、何が変化したかを判断し、動きをノイズから区別し、最近の観測を正しい行動に結び付けなければならない。

ここではフレームレートが重要になる。より多くの画像を送れば時間的なカバレッジは改善できるが、帯域幅と処理負荷は増える。少なく送れば遅延を減らせるが、攻撃の開始を見逃すかもしれない。最適なレートは、モデルと環境の両方に依存する。

したがって評価設計者は、観測パイプラインをエージェントの一部として扱わなければならない。モデル名だけを報告すれば、推論が始まる前に勝敗を左右し得る決定が見えなくなる。

ボクシング形式は、静的なスイートよりも適応を明確に試すこともできる。評価者は、積極的なプレッシャー、守備的なカウンター、反復的なコンビネーション、欺くような動きなど、異なるスタイルの対戦相手をプログラムできる。モデルはまず既知のスタイルに対峙し、その後、未知の組み合わせに挑める。

真の適応スコアは、証拠が蓄積した後の行動変化を測るべきだ。単にランダムに異なる行動を選んだからといって、モデルに報いるべきではない。後半の意思決定は、開始時点では利用できなかったパターンを活用していなければならない。

この設計は、AI研究の実験場としてのゲームのより広い歴史ともプロジェクトを結び付ける。DeepMindは、ゲームが変化する目標を持つ応答的なリアルタイム環境を提供すると指摘している。また、物理実験ではしばしば不足する計測機能も備えている。

ただし、ボクシングベンチマークは、また一つの閉じた見世物になることを避けるべきだ。ダウンロード可能な環境、固定プロトコル、機械可読なログがなければ、視聴者はファイターが勝った理由を検証できない。娯楽性は注目を集めるが、透明性は科学的価値を生む。

同じ教訓は、エンタープライズ向けエージェントのテストにも当てはまる。画面操作エージェントが最終的にワークフローを完了できたとしても、予測不能に停止したり、古い情報に基づいて動作したりすれば、利用者を苛立たせる。チームには、観測、意思決定、タイミング、立て直しを示すトレースが必要だ。

視覚的なアリーナは、それらのトレースを理解しやすくする。エージェントがブロックに失敗する様子を見る方が、パーセンタイルのグラフを読むより直感的だ。重要なのは、その分かりやすさを保ちながら、有意義な比較に必要な統制を加えることである。

結果を信頼に値するものにするには

このプロジェクトが有用な評価になるのか、それとも独創的なソーシャルメディアの実演にとどまるのかは、3つのシグナルで決まる。

第1のシグナルは、再現可能な公開である。制作者は、環境、ルール、プロンプト、行動スキーマ、タイミングロジック、固定されたモデル構成を公開すべきだ。リプレイには、タイムスタンプ付きの観測と受け付けられた行動を含めるべきである。

独立した利用者が同様のランキングを再現できれば、この公開は主張を強める。小さなプロンプトやネットワークの変更で結果が逆転するなら、主張は弱まる。

第2のシグナルは、2トラックのリーダーボードだ。一方のトラックでは、同一のリアルタイム条件を強制する。もう一方では、評価者が速度とは別に行動の質を比較できるよう、計算資源を正規化または開示する。

これにより、公平性の定義が一つしかないふりをせずに、時間スケーリングの問題を解決できる。両トラックで安定したランキングが得られれば、幅広い能力に関する主張を支持する。ランキングが分かれるなら、遅延と推論の質が依然として別物であることを示す。

第3のシグナルは、より幅広いモデルとベースラインのカバレッジである。Gemini Flash Liveは、他のホスト型プロバイダーの固定スナップショット、開示されたローカルモデル、手作業でコーディングしたコントローラー、ランダムポリシーと対戦すべきだ。別のマルチモーダル部門を明確にラベル付けしない限り、各システムには比較可能な観測を与えるべきである。

Geminiが反復シード、未知の対戦相手、透明な遅延測定の下でも競争力を保つなら、Googleの展望は意味を持つものになる。より豊富なビジョン情報や有利なタイミングによってのみ勝つなら、そのベンチマークは統合上の優位性を記録するものになるだろう。

現時点では、検証済みの結果はいずれの結論も確立していない。情報源は開発中の作業に関する開発者の説明であり、中核となる性能主張は独立して検証されていない。この不確実性は、却下ではなく、より良い測定を促すべきだ。

次に有用な一歩は単純である。楽しさを残しつつ、仕組みを明らかにする。ログを公開し、速度と戦略を分け、他の開発者にも同じ対戦を実行させることだ。一時停止された試合を支配するモデルは、時計が動き続ける状況でも生き残れるだろうか。この問いは、シミュレートされたボクシングを超えて広がる。リアルタイムAIが、世界が再び変化する前に知覚を行動へと変えられるかを試すものだ。

 
 

無料で始めましょう

ローカルファーストのパーソナル知識管理付きAIアシスタント

より良いAI体験のために、

remio は現在、 Windows 10+ (x64)M-Chip Mac のみをサポートしています。

脳内に検索バーを追加

ただremioに尋ねるだけ

すべてを思い出す

何も整理しない

bottom of page