Skip to content

Robloxスタジオ用エージェント型AIアシスタントのベンチマークにOpenGameEvalを使用

AIアシスタントのパフォーマンスを評価する初のRoblox Studioネイティブ評価フレームワークとベンチマーク

課題 

クリエイターはRoblox StudioのAIアシスタントを活用してRoblox体験の開発を加速させていますが、インタラクティブな開発タスクにおいて、AIアシスタントとその基盤となる大規模言語モデル(LLM)がどの程度機能しているかを評価することは、依然として課題となっています。 従来のコーディングやエージェントベースのベンチマークは、孤立したステートレスなタスクに焦点を当てていますが、Robloxの開発ワークフローでは、3D階層構造にわたる推論、マルチプレイヤー環境におけるクライアント・サーバー間のやり取りの管理、ステートフルなワールドへの変更といったタスクにおけるパフォーマンスを測定するための、専用の評価手法が求められています。

この課題に対処するため、我々はOpenGameEvalを導入します。これは、再現可能なRoblox Studio環境において、LLMベースのAIアシスタントの性能を評価するオープンソースの評価フレームワークおよびネイティブベンチマークデータセットです。OpenGameEvalとその公開リーダーボードが、より広範なAI研究コミュニティにとって、ツールの使用、エージェント的推論、および長期的なタスク解決に関連するモデルのコア機能を評価するための独自のテストの場となることを期待しています。

OpenGameEval’のリーダーボードは、Roblox開発のためのモデルの有効性の現在のスナップショットを提供します。

ソリューション

OpenGameEval評価フレームワークは、Robloxの開発環境を再現するように設計されています。各評価は、Roblox Studioにおける編集時およびプレイ時の動作をシミュレートした環境内で実行されます。これにより、物理演算、ネットワーク通信、マルチプレイヤー間の相互作用など、観測される動作が、クリエイターやプレイヤーが実際に体験するものと同一であることが保証されます。 

このフレームワークには入力シミュレーション機能が組み込まれており、ユーザーの操作(ボタンクリック、キーボード入力、カメラ操作など)を必要とする開発タスクを評価するために不可欠な、複雑なプレイヤーとの相互作用をプログラム的に再現することが可能です。

評価アーキテクチャ全体は、統一された使いやすいAPIによってカプセル化されています。この抽象化により、研究パートナーは、基盤となる環境ハーネスを変更することなく、同一のベンチマークタスクを実行する多様なLLMベースのエージェンティックシステムをベンチマークすることができます。

undefined

OpenGameEvalベンチマークデータセット

OpenGameEvalベンチマークデータセットは、オープンソースで手作業によりキュレーションされた47のテストケースからなるスイートであり、厳格かつ反復的なプロセスを通じて、完全に人間による検証を経た上で、このフレームワーク上に構築されています。私たちは、ドメインエキスパートからプロンプトを収集し、AIモデルに必要なコンテキストを提供するためにカスタマイズされたRoblox体験環境を構築し、評価と権威ある解答を手作業で作成し、包括性、汎用性、安定性を保証するためにすべてのシナリオを徹底的な人間によるレビューにかけます。  

初期リリースには、ゲームメカニクス、環境構築、キャラクターアニメーション、インターフェースデザイン、サウンドデザインなど、一般的なRoblox開発タスクに由来するシナリオが含まれています。OpenGameEvalベンチマークは実行可能なユニットテストを利用し、そのスコアリング手法をpass@k、cons@k、all@kといった業界標準の指標と整合させることで、データセットにおけるモデルのパフォーマンスを定量化します。研究パートナーは、OpenGameEvalの実行から評価結果を収集した後、これらの指標を独自に再現することができます。

一般的な関数レベルのコーディング課題とは異なり、OpenGameEvalはコアコンポーネントのエンドツーエンドテストを可能にします。成功するモデルは、インスタンス階層のナビゲーション、オブジェクトの状態の分析、環境内のコンテキストからユーザーの意図を導き出すなど、いくつかの異なるスキルを習得する必要があります。

多段階タスクとコンテキストの変動 

Robloxのコーディングタスクでは、体験内の既存のコンテキストをナビゲートし、望ましい結果を達成するために複数の絡み合ったスクリプトやインスタンスを調査するために、多くの場合、複数のステップが必要となります。以下の例では、OpenGameEvalは実際のゲームインスタンス環境を表すサンドボックス内の複数の要素を検証し、モデルが関連する複数のスクリプト、クライアント/サーバー間の相互作用、およびプロンプトの本来の意図を適切に考慮できることを確認します。  

ユーザーのプロンプト: 

ダメージを受けてから2秒後に開始し、毎秒10のHPを回復するHP回復システムを実装してください。

プレイスファイルのコンテキスト:

武器、チーム、および主要なプレイメカニズムが既に設定されたレーザータグ体験。

想定される推論手順: 

  1. 文脈の把握: さまざまな検索ツールを使って体験を調査します。これには、検索範囲を調整しながら複数の検索ステップを踏む必要がある場合が多いです: 

    1. ダメージやプレイヤーのHPに関する既存のスクリプトを特定し、そのロジックを理解する。

    2. HP回復スクリプトを追加する最適な場所を推論する(例:サーバー側かクライアント側か? コアゲームスクリプトの一部としてか、独立したプレイヤースクリプトとしてか?)。 

  2. 実装:プレイヤーの体力を操作するために適切なAPIを使用してLuauコードを記述する。スクリプトは以下を行う必要がある: 

    1. 回復が必要な適切なタイミングを捕捉し、回復がどのように行われるべきかを定義する。 

    2. 特定のダメージスクリプトに限定せず、すべてのダメージに対して汎用的に適用可能であること。

検証可能な評価: 

実行可能なテスト(サンドボックス化されたゲームインスタンスで実行)により、テストプレイヤーに対してダメージイベントを発生させ、以下を検証します:

  1. サーバー側でHPの回復が正しく処理され、クライアント側で反映されていること。

  2. 2秒の遅延が経過する前に回復が始まらないこと。 

  3. HPは1秒あたり10の割合で回復する。

undefined

AIモデルの堅牢性と文脈理解を効果的にテストするため、タスクは多様な環境条件下で提示されます。例えば、「4方向信号機のスクリプト作成」タスクには、開発環境の初期状態に基づいた3つの文脈のバリエーションが含まれています。 

ユーザーからの指示: 

単純な4方向信号機のスクリプトを書いてください。

バリエーション1:

ベースプレートのみを含む空のプレイスファイル。スクリプトのない「TrafficLight」という名前の信号機モデルが利用可能です。 

モデルは、TrafficLightモデル内のさまざまな部分を探索し、オン/オフの状態を切り替える方法を見つける必要があります。 

バリエーション2:

郊外の環境が設定されたプレイスファイル。スクリプトなしの「Traffic Signal」という名前の信号機モデルが複数用意されています。 

モデルはまず、この体験内を探索し、他のオブジェクトの中から信号機を正しく特定する必要があります。信号機モデルはバリエーション1とは異なるロジックで構成されており、モデルはこの体験に固有の解決策を実装する必要があります。 

バリエーション3:

郊外の環境が設定されたプレイスファイル。複数の信号機モデルと歩行者用信号機モデルが用意されている。信号機用のスクリプトは削除されているが、歩行者用信号機用のスクリプトは残されている。 

モデルは、信号機と歩行者用信号機の違いを識別し、適切なオブジェクトに対して変更を加える必要があります。歩行者用信号機の存在は、モデルの混乱を招くのでしょうか、それとも役立つのでしょうか?

undefined
ベースプレート上の信号機。
undefined
アセットとスクリプトを含む体験内の信号機。

文脈や複雑さの異なる環境において、一見類似したタスクに対するモデルの挙動を理解することに興味があります。

初期結果

OpenGameEvalベンチマークは、インタラクティブ開発におけるAIアシスタントの現状を診断するための実証データを提供します。テストケースは、単一操作(アトミック操作)と、多段階の文脈推論を必要とする操作との能力を区別するように設計されています。 

初期のテストでは、モデルは一般的に単一操作には優れているものの、文脈推論には苦戦していることが明らかになりました。パーティクルエミッターの設定やプレイヤーのジャンプ力の変更など、単一のインスタンスを直接操作するタスクにおいて、モデルは最高の成功率を達成しています。主要なモデルはほぼ完璧な成功率を示しており、構文的なコード生成や基本的なAPI知識における熟練度を証明しています。

これとは対照的に、協調動作、文脈に基づくフィルタリング、および深いAPI統合を必要とするタスクにおいては、依然として大きな格差が存在します。前述の体力回復システムや4方向信号機のような例では、すべてのモデルにおいてpass@kスコアが依然として非常に低いままです。

急速な進化

モデルの進化に伴い、こうした格差は解消されていくものと予想されますが、すでに興味深い進展が見られています。「Robloxのロゴを立方体のように緑色に変える」という指示を与える評価タスクでは、当初、対象オブジェクトの名前に「ロゴ」や「Roblox」という単語が明示的に含まれていなかったため、すべてのモデルが失敗していました。 

undefined

しかし、最近の評価では、一部のモデルが単純なキーワードマッチングを超え、構造的推論へと移行することで、この課題をうまく解決していることが示されています。具体的には、詳細なインスタンス検査(名前だけでなくプロパティも含む)や協調的推論を活用し、「Robloxロゴ」を表す可能性が最も高いオブジェクトを特定しています。 

今後の展望 

私たちは、AI分野の急速な進歩を追跡するため、OpenGameEvalの継続的な拡張と維持に尽力しています。現在のOpenGameEvalフレームワークとベンチマークは、あくまで基盤に過ぎません。当プラットフォームがRoblox Studioのエージェント型AIアシスタント評価における標準であり続けることを確実にするため、私たちの戦略的ロードマップは以下の3つの主要な目標に焦点を当てています:

  • パフォーマンスの透明性を通じてクリエイターを支援する:リーダーボードとベンチマークデータセットを定期的に更新するとともに、クリエイターがモデルを比較し、コード生成、アセット挿入、ツールオーケストレーションにおけるパフォーマンスを理解するのに役立つ、明確で透明性の高い要約を提供します。

  • 研究開発の加速:評価を標準化するためにAPIアダプターを維持・拡張し、研究パートナーが次世代AIアシスタントの開発に向けて、高速でスムーズかつ再現性のあるベンチマークを実行できるようにします。

  • コミュニティ主導のアプローチの採用:実世界のクリエイターの意図を継続的に取り入れ、コミュニティからの貢献を積極的に募ることで、このベンチマークが最先端のRoblox開発と進化するAI機能を確実に反映し続けるようにします。

フレームワーク、データセット、公開リーダーボードが一体となることで、OpenGameEvalはRoblox開発におけるAIを活用した創作を評価するための、透明性が高く協働的な基盤となります。これにより、クリエイターコミュニティ全体が進捗を測定し、知見を共有し、より優れたアシスタントを構築できるよう支援します。

謝辞:OpenGameEvalプロジェクトは、Robloxのチーム間の重要な共同作業の結果です。Vlad Shcherbanショーン・ダニガン、およびジャック・ルーイザベラ・ティンブレント・ヴィンセントの洞察力は、このリリースの形成に大いに役立ちました。私たちは、パートナー・チームと元チーム・メンバーに深く感謝しています。