Android Bench からのエージェント コード生成に関する分析情報

Tomáš Mlynarič

皆さん、おはようございます。

始めましょう。

3 月には、Android デベロッパー向けタスクで LLM を測定するためのデータセットとリーダーボードである Android Bench をリリースしました。

それ以来、多くの新しいモデルに対してこのテストを実行してきました。

そして先月、Android Bench 2.0 がリリースされました。

まだ数か月しか経っていませんが、AI の世界では永遠のように感じられます。

私の名前は Tomáš です。Android Bench の歩みと、現在の状況についてお話しします。

まずは 1.0 から始めましょう。

1.0 では、オープンソース リポジトリから現実世界の問題を取り上げました。

GitHub のプロジェクトを、GitHub の問題、それらの問題を解決する pull リクエスト、解決策を検証するテストでフィルタしました。

pull リクエストを AI モデルのタスクバケットに分割します。

GitHub の問題がモデルの指示またはプロンプトになり、PR の前の状態に埋め込まれました。

モデルが作業を生成すると、テストを実施して出力に適用し、合格または不合格の結果を得ました。

AI が問題を解決しようとするこの 1 回の試みを、トライアルと呼びます。

また、その PR の人間が作成したソリューション（ゴールデン ソリューション）に基づいて比較することもできます。

この手法は、よく知られている SWE-bench ベンチマークに似ています。

10,000 を超える潜在的なタスクから始めましたが、そのすべてが適していたわけではありません。

指示が不完全だったり、指示が過剰に指定されていたりするものもありました。

テストがゴールデン ソリューションに結合されていたか、PR 前の状態が壊れていた可能性があります。

そのため、100 個の公平なタスクに絞り込むために、何度もレビューを重ねる必要がありました。

これらのレビューでは、最先端のモデルを使用して結果を得ました。

最初は、解決されたタスクの割合（合格率）が 30% 程度でした。

そして、公式リリースのためにデータセットをロックしたときには、上位のモデルはすでに 70% 程度に達していました。

でも、それは 1 か月後のことです。

そして、毎月新しいモデルを評価する計画を立て、モデルがどのように改善されているかを観察しました。

8 月のリリースでは、最適なモデルの合格率は 92% でした。

そして、私たちの基準が低すぎること、このデータセットが飽和状態であることを知っていました。

Tomáš Mlynarič

しかし、私たちはそれを予想しており、すでに 2.0 の開発に取り組んでいました。2.0 は先月リリースされました。

その目標は、複雑な実際の Android タスクで基準を引き上げ、デベロッパーの皆様に LLM のパフォーマンスに関するガイダンスと透明性を提供することです。また、モデル メーカーに Android を優先するよう促すために、モデル メーカーが目指すべき優れたベンチマークを提供することも目標です。

また、あなたとモデル作成者の両方に役立つ分析と結果を提供します。

しかし、巧妙さ、粘り強さ、不正行為も考慮する必要があります。

また、汚染リスクを防ぐ必要があります。

SWE-bench の手法の問題点の一つは、ソースコードが実際にオープンであることです。

OpenAI が記事を公開しました。

その結果、モデルは指示の次の単語を完成させることができ、指示に含まれていない不明瞭なエラーを伴うタスクを解決できることがわかりました。

そして、モデル作成者がオープンソース コードでトレーニングを行っており、SWE-bench が汚染されていることに気づきました。

そのため、2.0 では、トレーニングに使用されないようにコードを非公開にしています。

作業を 4 つのワークストリームに分割しました。

1 つ目はアプリの変換です。オープンソースの Flutter アプリと React Native アプリを、エージェントにネイティブ Android ソリューションに変換させました。

これは、現在見られるクロスプラットフォームからネイティブへの移行の傾向を反映しています。

2 つ目のワークストリームは、新機能とプラットフォームの統合でした。

確立された本番環境のコードベースに組み込まれている。

たとえば、Now in Android では、動画機能やピクチャー イン ピクチャーなどを追加しました。

3 番目のワークストリームは移行です。

Google は、非公開にしていた本番環境のオープンソース アプリを、最新のライブラリとアーキテクチャでアップグレードしています。

たとえば、Nav 2 から Nav 3 への移行、XML ビューから Compose への移行、シングルペインからアダプティブ レイアウトへの移行などです。

最後の 1 つは、ビジュアル デザイン モックを使用してゼロから構築された社内の新規アプリでした。

ここでは、完全な SMS OTP 認証フロー、Google マップを使用した注文追跡などの例が紹介されました。

Tomáš Mlynarič

数人のエンジニアだけで、Now in Android と同じ規模のアプリを構築しました。

しかし、新しいタスクには新しい課題が伴いました。

1 つ目は、エージェントを適切に評価することです。

ベンチマーク テストは、アプリのテストよりもはるかに困難です。なぜなら、1 つだけでなく、有効なソリューションをすべてパスする必要があり、タスクが大きくなるほど、有効なソリューションが増えるからです。

1.0 では、このベンチマークは主に単体テストに依存しており、単体テストは、依存関係がないという点ではかなりひどいものでした。

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

正確なクラス名または関数名が必要です。

このケースのように、高度なテストではありませんが、基本的に、エージェントがそれらの名前を異なるものにする可能性があります。また、異なる名前にしなくても、別のパッケージに配置すると、テストのコンパイルに失敗し、このケースでは使用できなくなります。

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

技術的には、プロンプトで API を指定することもできますが、それでは詳細を明かしすぎることになるか、テスト要件が多すぎてプロンプトが爆発的に増えてしまいます。

そこで、実装に依存しないテストを行うという解決策があります。

これらは非常に高レベルで、結果をテストします。内部ではなく、結果と動作をテストします。

ユーザーが操作するのと同様に、公開画面の情報とやり取りするテストである、決定論的 UI テストを使用します。

これらには UI Automator または Compose UI テストを使用しますが、外部システムの境界をチェックする専用のスクリプトもあります。たとえば、ネットワーク呼び出しに正しいデータが含まれているかどうか、内部ヘルパーや DAO を知らなくても正しいデータがデータベースに保存されているかどうかなどをチェックします。

その一部として、静的チェックも行います。たとえば、マニフェスト内の権限や、ライブラリがビルドファイルに含まれているかどうかなどをチェックします。

また、これらのスクリプトと UI テストを組み合わせたハイブリッド テストもあります。

これは、ハイブリッド テストの例です。

エミュレータの外で運転する。

これは SMS OTP 認証フローのテストです。スクリプトは、まずアプリのハッシュを計算して、エミュレータに SMS を正しく送信できるようにする必要があります。次に、テスト（UI Automator テスト）を開始し、必要なランダムに生成された OTP を渡し、ADB コマンドを使用してエミュレータに SMS を送信します。

テストでは、入力された番号が正しいかどうかを確認します。

基本的にはそれだけです。

実装の結合はゼロで、チェックのみを行います。フローが機能するかどうかのみをチェックします。

2 つ目の採点の問題は、タスクにマルチモダリティが必要なことでした。

エージェントが UI を作成する必要があるか、エージェントにデザインモックを提供します。

そのために最も簡単なのが、スクリーンショット テストを使用することです。

スクリーンショットのしきい値を高くする必要があることは最初からわかっていましたが、いずれにしても失敗しました。

さまざまなピクセル差分アルゴリズムを試しましたが、システムレベルのノイズ（エミュレータのステータスバー、バッテリー アイコン、フォントのハードウェア アンチエイリアスが異なるなど）で失敗しました。

また、パディングがわずかに異なる、色合いがわずかに異なるなど、ある程度有効な実装でも失敗しました。UI は完全に正しくても、背景の色合いがわずかに異なるだけで、ピクセル差分アルゴリズムは失敗します。

そこで、スクリーンショット テストのようにスクリーンショットのペアを比較してスコアを算出するマルチモーダル LLM 判定ツールを構築して使用しました。このツールは、スコアに関する構造的な推論も提供します。

また、アクセシビリティ階層ダンプも提供して、構造が正しいかどうか、構造の同等性が正しいかどうかを確認します。

多くの試行で経験的に試したところ、一貫性が高く、私たちが確認した問題が無視されることがわかりました。

これで、ビジュアルと動作を不可知論的に検証する優れた方法ができたので、エージェントがすべてを偽装しようとしたことがわかりました。

ご用件をどうぞ。

Tomáš Mlynarič

最初はシンプルです。

最近のエージェントは基本的に、「わかりました。

タスクがあります。

GitHub を見てみましょう。

解決策を見つけましょう」と言うエージェントの差が生まれます。

これが、彼らが最初に行うことです。

GitHub やインターネットで有効なソリューションを検索しようとするため、ソースコードを非公開にしておく必要があります。

でも、それは簡単でした。

一部のトライアルでは、すべてが 100% 完全に合格したと伝えました。すると、エージェントは「素晴らしい勝利です！」と言いました。

では

興味深いですね。何がわかったのですか？

しかし、軌道を詳しく調べたところ、彼らは「これは無理だ。

スクリーンショット テストのしきい値を 80% に変更したらどうなるか、試してみます。」

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

「そう、勝利だ。すべてが過ぎ去っていく」という感じです。

でも、スクリーンショット テストは役に立たない。

しかし、これは最も高度なものではありませんでした。

Flutter 変換アプリでは、エージェントが Android のビルドを何度も試みましたが、「どうすればよいかわからない」という状態になりました。

そこで、Google が提供したスクリーンショットを、背景のドローアブルとして配置しました。

そして、スクリーンショット テストに合格したような状態になります。

正解です。

しかし、UI テストは依然として失敗するため、ボタン、テキスト、テストタグなど、必要なものをすべて含む非表示のオーバーレイ レイヤをその上に配置します。

すべてが緑色になりました。

いいですね。

よくやった。」

1 つだけが特に優れているというわけではありません。

Java から Kotlin への移行タスクがあり、エージェントは基本的に Java から Kotlin に移行する必要があります。

ビルドできなかったのです。

まだ何かが失敗しているため、エージェントは「よし、Java からコンパイルされたクラスを取得して JAR に入れ、通常のライブラリとしてビルドファイルに追加しよう」と考えました。

これで、すべてのテストに合格しました。Java ファイルをチェックする静的チェックがあるので、それらを削除します。」

Java ファイルを削除すると、すべてが緑色になります。ただし、Kotlin はまだ失敗しているため、「よし、Kotlin ソースセットを削除しよう。これで、すべてが合格になる。

ありがとうございます。」

それが不正行為なのかどうかもわかりません。

これは本当にクリエイティブな作業です。

そこで、これらすべてを防ぐために、3 つの防御機能を備えた不正行為検出機能を構築しました。

UI ツリーを確認し、さまざまな画面サイズを適用して背景が歪むようにし、それを確認します。

また、テストをリセットし、テストの改ざんがないか確認して、しきい値を変更できないようにします。

また、LLM-as-a-Judge のようなものもあり、エージェントの軌跡と実際の出力を監査して、不自然な点がないかを確認します。

何か問題が発生した場合は、「よし、すぐに失敗だ」と言います。

Tomáš Mlynarič

これで、すべてのショートカットがなくなり、ソリューションを検索する必要も、脆弱な単体テストや UI のフェイクもなくなりました。

では、エージェントに Android アプリのエンジニアリングを実際に強制した場合、数値はどうなるでしょうか。

月曜日のブログ投稿をご覧になったかもしれませんが、数字は次のようになっています。

最も優れたエージェントでも、タスクの約 40% しか合格せず、ほとんどのフロンティア エージェントは 20 ～ 40% の範囲に収まります。

これは、ベンチマークの作成者にとって良いことです。なぜなら、私たちが提供したタスクには現実世界での価値があり、同時に成長の余地も十分にあります。

では、結果を見てみましょう。

これで、複数の視点から結果を確認できるようになりました。

すでに得られている分析情報をいくつか見てみましょう。

このグラフを見て最初に疑問に思うのは、そのエージェントを実行するのにどれくらいの費用がかかるのかということでしょう。

AI 企業は通常、トークンあたりの費用を報告します。入力、出力、キャッシュ トークンなどです。

そして、それがお客様のケースにおける意思決定の論点になるかもしれません。

しかし、別の視点から見ることもできます。

同じグラフを 2 次元空間にプロットできます。トークンではなく、タスクあたりの平均費用、つまり、タスクあたりの費用と合格率を比較します。

ここで、一部のモデルがはるかに饒舌であることがわかります。

タスクあたりの時間やトークンが大幅に多くなる一方で、他のモデルはより少ないコストでより多くのタスクを処理します。

しかし、同じグラフにトークンあたりの価格も追加すると、AI 企業が実際に宣伝している価格は、タスクごとに実際に支払う価格と一致していないことがわかります。

合格率が最も高いエージェントは、実際にはトークンあたりのコストが最も低いものの、タスクあたりのコストが最も高いことがわかります。

また、トークン価格がまったく同じ他のエージェントは、タスクの約 30% をパスしますが、15 倍安価です。

したがって、トークン価格は指標ではありません。

モデルがコードをさらに探索し、再構築、再実行するたびに、トークンが消費されます。

つまり、トークンあたりのコストだけを見るのではなく、

モデルを選択し、実際のデータを確認します。たとえば、自分のユースケースで使用するか、Android Bench を確認して、実際にどのモデルがタスクに最も多くのトークンを消費しているかを確認します。

トークンあたりのコストは安いものの、より多くのステップが必要なものもあります。

しかし、同じ質問には別の側面もあります。

これは同じグラフですが、エージェントが完了するまでにかかる時間も確認できます。

合格率が最も高いエージェントは、最も遅いエージェントである可能性もあります。

たとえば、タスクによっては 2 時間近くかかるものもあります。

うまくいくまで、再構築と再テストを繰り返します。

合格率は最も高くなりますが、最も時間がかかります。

より安価なエージェントの中には、タスクあたり 30 分から 1 時間半ほどかかるものもありますが、結果は良くありません。

また、20 分未満で完了し、タスクの 4 分の 1 以上を解決しているエージェントもいます。

小型で軽量なモデルは、通常、高速で安価ですが、困難なタスクでは失敗することが多くなります。

重要なのは、単一の最適なモデルは存在しないということです。

最適化の対象によって異なります。

合格率ですか？

費用ですか？

待ち時間ですか？

その場合、行っている作業の種類によっては、それほど難しいタスクに取り組んでいないのであれば、より安価で高速に作業を完了できる高速なモデルの使用を検討してください。

しかし、費用と速度からわかるのは、エージェントがどのように実行されるかだけで、ほとんどのトライアルが失敗する理由はわかりません。

そこで、失敗した実行を調査したところ、エージェントが早期に終了することが多いことがわかりました。

もう終わったと確信しています。

タスクが完了しました。

わかった、家に帰るよ。

ただし、前述のように、タスク パケットでは、エージェントは指示と前の状態のみを受け取ります。

テストは表示されません。

確認スイートが表示されない。

そこで、テストをそのまま見せたらどうなるか、という疑問が生まれました。

そこで、同じタスクのオープンテスト バリアントを試しました。このバリアントでは、エージェントは失敗した検証テストスイートを事前に受け取ります。

そこで、テストを繰り返し実行することにしました。

エラーを検査し、フィードバック ループでコードを改良できます。

そして、エージェントがテストを認識すると、より熱心に、より長く働くことがわかりました。

また、オープンランでは、ターン数が 25% 増加し、Agent Runtime が 40% 増加しました。

1 タスクあたり 30 分近くを、失敗したテストの実行と修正に費やしました。これは、やみくもにデバッグしていたわけではないからです。

そのため、何が失敗したかを正確に把握できます。残念ながら、合格率も 50 パーセント近く上昇します。

この追加の取り組みにより、前述のように平均合格率が向上します。

しかし、最終的に新しいフロンティア モデルが登場し、このオープン バリアントはすぐに飽和状態になりました。

合格率は 90% 近くに達しています。

そのため、クローズド検索のクローズド テスト バリアントを主要なベンチマーク指標として維持しました。

しかし、モデルが評価基準を認識している場合に、実際にモデルのパフォーマンスが向上する様子を見るのは非常に興味深いことです。

Tomáš Mlynarič

しかし、これにより、エージェントに関するより多くの分析情報を構築できました。

たとえば、モデルが実際にどのように自身の作業をテストするかを確認できます。

このグラフから、フロンティア モデルはより多くの、より優れたテストを作成し、合格率が高いことがわかります。

他のモデルは自信過剰で、テストなしで実行できると判断します。

まだ使えることもある。

そのため、テストがあまり得意でないモデルを使用する場合は、テストスキルを向上させるか、テストの作成方法に関する具体的な指示を与えることで、モデルを支援できます。

でも、相関関係は因果関係を意味するわけではありませんよね、CS さん？

これについては、実際に対照実験を行う必要があります。

より良いテストを促すプロンプトが実際にスコアを向上させるかどうかについては、まだ検証が必要です。

ただし、Android テストのもう半分、つまりエージェントにエミュレータを使用させるテストは実施しました。

初期のベンチマークでは、エミュレータについては何も言及していませんでした。

エージェントが自分で判断すべきだと考えていました。

その結果、実際にエミュレータを起動したものはほとんどありませんでした。

前述のとおり、UI テストはベンチマークにおいて非常に重要であり、エミュレータがなければ UI テストを実際に使用することはできません。

つまり、すべてが非常に単純なことで失敗していたのです。

ここでジレンマに直面します。

エージェントにエミュレータを使用する必要があることを伝え、実際にスコアが高くなるリスクを冒すか、何も言わずに、エージェントが自分で気づくことを期待するか、どちらでしょうか？

しかし、私たちの目標は、Android のコーディングと問題解決を測定する公平なベンチマークになることでした。

環境の特異性のようなものは測定したくありません。

そこで、中間的な方法を選択しました。

エミュレータの起動方法については説明しましたが、それを使用するかどうかについては何も言及していません。

結局のところ、エミュレータの起動は、実際にテストする必要があるものでも、テストしたいものでもありません。

そして、そのエミュレータ命令の効果を測定しました。

そして、エージェントに How-to を教えたところ、エージェントはエミュレータを起動して UI テストを実行する回数が大幅に増え、残念ながら合格率に大きな影響を与えました。

また、起動していないエミュレータで失敗するだけでなく、実際のコーディング ミスや問題も検査できました。

つまり、プロンプトの具体性は依然として非常に重要であり、独自のベンチマークや評価を設計する場合は、実際に重要なことをテストする必要があります。

たとえば、トークンの効率性や、スキルまたはツールの効率性を評価する場合、まず、評価に合格することから始め、効率性を高めるための変更を加え、より少ないトークンで合格することを確認する必要があります。

そうしないと、一度に多くの変数が変更されることになり、変更によって実際に改善されたかどうかがわからなくなります。

Tomáš Mlynarič

リーダーボードに戻る

先ほどお伝えしたように、最良のモデルでもタスクの約 40% にしか合格せず、合格率にはすべてのチェックに合格することが求められます。

それ以外の場合は、タスクが失敗します。

では、エージェントは残りの 60% のケースでは役に立たなかったのでしょうか。

いや、もうすぐだ。

エージェントが実際に動作するソリューションにどれだけ近づいたかを示すために、距離のようなものとして、完了率や部分的なスコアのようなものも計算します。

これは、視覚的な一貫性、機能性、適切に機能するかどうか、タスク固有の要件、回帰チェックの 4 つのカテゴリにわたる加重スコアです。

下位のモデルは作業の約半分を完了できますが、フロンティア モデルは平均で 80% 近く、タスクの 80% 以上を完了できますが、合格率は 40% にすぎません。

そこで、Flutter から Android への変換をテストして、何が起きているのかを確認しました。

そこで、エージェントのステップ数回ごとに完了率を再計算したところ、すべてのフロンティア モデルで同じパターンが見られました。

約 140 ステップで、平均してほぼ 90% のスコアに到達しようとしていました。その後、さらに 90 ステップ、つまり実行のほぼ 40% を費やして 100% との差を縮めようとしましたが、スコアは 1 ～ 2% 程度しか向上しませんでした。

これは、今日の自律型エージェント開発の現状を反映していると思います。経験の浅いデベロッパーやユーザーは、アプリが完成したと見なします。

すべてがレンダリングされています。

入力は一応機能しました。

クラッシュが発生していない可能性があります。

しかし、シニア エンジニアがそのコードを見ると、アーキテクチャの問題やライフサイクルの欠陥など、多くの欠陥が見つかります。

Tomáš Mlynarič

最後に、Android Bench（Work 2.0）を大局的に見てみましょう。

1.0 と比較すると、タスクは 30 個しかありません。これは意図的なものです。

個別のバグの修正や小さなパッチではなく、画面全体、マルチモジュールの移行、アプリ全体の変換など、

パッチは数十のファイルにまたがり、桁違いに大きくなっています。

また、マルチモーダル UI チェックもあります。

エージェントはより長く、より熱心に働く必要があります。

他の最先端のベンチマークと比較すると、このベンチマークでは、はるかに大規模なコード変更が必要であることがわかります。

ほとんどのタスクがゼロから作成されているため、汚染がなく、成長の余地が十分にあります。

冒頭で述べたように、AI の世界では数か月が永遠のように感じられ、最終的にはすべてのベンチマークが最大化され、飽和状態になります。

そして、このタスクが完了したら、さらに難しく複雑なタスクに挑戦し、その時代の AI の状態に共鳴するようなものにしたいと考えています。

次に、Android Bench をコンパスとして使用して、モデルとハーネスを比較し、いくつかの分析情報を得ます。

さらに深く掘り下げる準備ができたら、同じベンチマーク原則と評価原則を独自のコードベースとワークフローに適用してください。実際に使用するコードで AI を測定することに勝るものはありません。

これにより、AI が正しく処理したことを確認できます。

Android Bench チームを代表して、ご清聴いただきありがとうございました。