小規模モデルを使用したエージェント コーディング ワークフロー

それでは

こんにちは。

私はホセです。イアンとゾーイも一緒です。

LLM については誰もが知っています。

レシピの検索、YouTube 動画の要約、コーディングなど、あらゆることに使用しています。

Gemini モデルのような大規模な LLM は、本当に素晴らしいことができますが、この講演では、小規模言語モデルについてお話しします。

40 億ものパラメータを持つモデルは小さくはないため、これらも LLM ですが、今後はフロンティア モデルと小規模言語モデル、つまりロケットと自転車を区別していきます。

小規模モデルについては、フロンティア モデルの代替としてではなく、主にフロンティア モデルを補完するものとして説明します。

小規模言語モデルのメリットは、特にオープンで、オープンウェイトで、ダウンロード可能な場合に、すべて説明しますが、まずはコストについて見てみましょう。

この講演のために、私は多くのベンチマークを実行してきました。そのうちの 1 つは、200 の中程度および困難なタスクのデータセットで、1 億 3,100 万近くのトークンを使用し、費用は 9 ドル未満でした。

このテストには Gemma 4 を使用したため、ダウンロードして自分のハードウェアで無料で実行することもできましたが、公平な比較のために商用ゲートウェイで実行しました。

では、フロンティア モデルの費用はどのくらいになるのでしょうか。

トークン キャッシュなどの要因に応じて、約 20 ～ 200 倍。

自転車は最も速い移動手段ではないかもしれませんが、最も効率的な移動手段であることは間違いありません。

このスマートフォンは

ここで当然生じる疑問は、品質と精度にどのような違いがあるかということです。

この特定のデータセットでは、Gemma 4 はタスクの 53% を解決できます。

これは次の 2 つのことを意味します。

左側のタスクを実行するためにフロンティア モデルを使用している場合は、過剰である可能性があります。

右側のタスクを小さなモデルで実行する場合は、モデルを解決策に導くか、より大きなモデルを使用する必要があります。

この講演では、すべてのトークンを最大限に活用する方法をご紹介します。

Zoe が小規模モデルの選択方法を説明し、Ian が Gemma モデルについて説明します。これにより、これらのモデルで何ができるかについて、考え方を整理する方法を理解できます。

次に、Android Studio で Gemma 4 を試す方法を簡単に紹介します。最後に、小さなモデルを日常のワークフローに組み込む方法と、実際の Android 開発ベンチマークを紹介し、小さなモデルで何ができるかを直感的に理解できるようにします。

それでは、Zoe に引き継ぎます。

Jose さん、ありがとうございました。

つまり、すべてに 1 つのモデルを使用することは、大げさな手段の割に成果が小さいということですね。

効率的ですが、少し不釣り合いです。

つまり、小さなモデルを考えることは、ツールセットを拡張するようなものです。

ワークフローに何を取り入れるべきかを知るには、ツールセットを開き、何が利用可能か、その仕様は何か、何に適しているかを確認する必要があります。

そのため、小規模モデルを選択するには、小規模モデルについて知る必要があります。

言語モデルを考えるときにほとんどの人が思い浮かべるモデルの種類は、自己回帰言語モデルです。

これは、トークンにチャンク化された入力に基づいて、候補のリストから最も可能性の高い次のトークンを選択するため、自己回帰的です。

そして、選択された最も可能性の高い次のトークンが入力に戻り、処理が続行されます。これにより、一貫性のある、インテリジェントな回答を生成できますが、線形に動作することなど、以下を含みます（ただしこれらに限定されません）いくつかの注意点があります。

そのため、非線形に作業できます。

拡散モデルも同じアプローチですが、一度に 1 つのトークン ブロックを処理します。

まるでスケッチに焦点が合っていくような感じです。

この場合、DiffusionGemma は一度に 256 トークンのチャンクを処理します。

つまり、基本的に、ブロック全体で機能するパスを取得し、より短いレイテンシで結果を生成できます。

つまり、私たちのツールセットには、文章を書くことができるモデルがあります。

これは間違いです。

つまり、埋め込みモデルとは、基本的に画像やテキスト、あるいはその他のあらゆる概念といったオブジェクトをベクトルに変換するものです。

これにより、座標を高次元空間にマッピングして、2 つのものを概念的に比較できます。

たとえば、ホットドッグがサンドイッチである場合、それらは近い空間に導かれるか、近い空間に配置される可能性が高くなります。

このため、2 つのコンセプトが関連しているかどうかを確認できることは、モデルパスではなく、少しの数学と言えます。これも数学と言えますが、このパラダイムはさらに進んでいます。

また、1 つのタスクを非常に高い精度で実行できる、より小規模で専門的なモデルもあります。

たとえば、自然言語を API 呼び出しに変換する関数モデル、名前から機能がわかるビジョンモデル、特定のパラメータに基づいて入力にスコアを付ける分類器などがあります。

選択肢がたくさんありますね。

モデルにはさまざまな種類があり、ディメンション、サイズ、コンテキスト ウィンドウ、機能、メモリ使用量が異なります。ツールボックスを開いてあらゆる可能性を考慮すると、オプションは指数関数的に増え、DIY ファンなら大喜びするか、選択肢が多すぎて身動きが取れなくなるほどです。

では、実際に小規模モデルを選択するにはどうすればよいでしょうか。

まずは、ローカルで実行できるオープンな小規模モデルのツールボックスである Gemma モデルを開いてみましょう。

Ian、よろしくお願いします。

ありがとう、Zoe。

Jose が最初に述べたように、小規模言語モデルは、そのままの状態でタスクの約 50% を実行できます。

しかし、なぜローカルモデルを選択するのでしょうか？

つまり、4 つのことが重要になります。

1 つ目はプライバシーです。

たとえば、API キー、独自のコード、または文字どおりノートパソコンから持ち出せないものなどです。

2 つ目はレイテンシです。

そのため、モデルが実際にメモリ（グラフィック メモリまたはユニファイド メモリ）に読み込まれると、計算が完了するとすぐにレスポンスが返されます。

そのため、サーバーへのラウンドトリップ時間がなく、追加のレイテンシ コストも発生しません。

次は限界費用ゼロです。

そのため、モデルの実行場所を制御できると、モデルの費用対効果が高くなります。

たとえば、ローカルマシンで何かを実行している場合、エラーループで追加の再試行が行われている可能性があります。

費用はかかりません。また、その部分に予期せぬ API 費用が発生することもありません。

4 つ目はオフライン アクセスです。

つまり、飛行機、電車、バス、地下鉄など、基本的にハードウェア上でモデルを実行できる場所であればどこでも使用できます。

これは素晴らしいことですが、こうした決定を下す際には、考慮すべき 2 つの大きな要素があります。

1 つ目はメモリ、2 つ目は速度です。

この図の下部にある 2 つのモデル、26B と 31B を見てください。どちらも、16 ビット量子化である BF16 で実行するには 50 GB を超えるビデオ RAM が必要です。

ここでの課題は、多くのハードウェアに適合しないことです。

そこで、量子化と呼ばれるプロセスを実行して、精度を 4 ビットの浮動小数点数に縮小します。

これで少し妥当な値になりました。

14 GB と 17 GB ですよね？

これは、ユニファイド メモリを搭載した Mac などに適合します。

この場合の課題は、通常のトレーニング後の量子化では、重みを圧縮すると、ベースモデルからモデルの精度が少し低下することです。これに対処する手法があります。

これは量子化認識トレーニングと呼ばれます。

この方法では、モデルはトレーニング時に、より小さいサイズになることを認識するようにトレーニングされるため、実際には損失が少なくなります。

これにより、RAM 要件が 75% 削減され、これらのデバイスに適合できるようになりました。

さらに一歩進めて、

多くのスマートフォンで動作するモバイル量子化アプローチでは、さまざまなレイヤがどのように動作し、どのサイズで動作できるかを理解することで、これらのモデルをさらに縮小できます。

つまり、量子化にはさまざまな方法があります。

つまり、11.4 GB の Gemma E2B が 1.1 GB に縮小されます。

そのため、現在ではミドルエンドからハイエンドのスマートフォンで、より合理的に利用できるようになっています。

次はスピードです。

そのため、自己回帰モデルを使用する場合、Zoe が述べたように、次のトークンセットを予測することになります。

たとえば、コーディング タスクでは、メソッド シグネチャの末尾や、開き括弧や閉じ括弧など、実際にはかなり予測可能なトークンが多数見つかることがあります。

そこで、投機的デコードと呼ばれる手法を使用できます。

この機能では、より小さなドラフトモデルを使用して複数のトークンを予測し、その後、より大きなモデルで検証します。

この動作が Gemma 4 アーキテクチャで機能する理由は、同じ KV キャッシュを共有しているためです。

これは、モデルの短期記憶のようなものと考えてください。

つまり、小さなドラフトモデルが 3 つまたは 4 つのトークンを事前に予測し、大きなモデルが同じ KV キャッシュを参照して、基本的に出力を検証します。

これにより、モデルの出力品質を実際に低下させることなく、パフォーマンスを約 3 倍高速化できます。これは、モデルが予測を行い、それが正しいかどうかを判断するだけだからです。

繰り返しになりますが、これは実行するタスクによって多少異なります。

そのため、クリエイティブな文章作成など、変動性の高いものにはあまり適していませんが、JSON 構造やコーディングなど、予測可能なものには非常に適しています。

では、これらのモデルを実際に評価するにはどうすればよいでしょうか。

そこで、最もわかりやすい方法として、LiveCodeBench や MMLU などのベンチマークを見て、スコアを確認することが考えられます。

ただし、これはモデルの能力に関する大まかな指標にすぎません。

本当に必要なのは、実行されているスタック全体を評価することです。

つまり、使用しているモデル、重み、量子化アプローチ、ランタイムの推論（llama.cpp、Ollama、LiteRT など）、使用しているエージェント ハーネス（Pi、OpenCode、Antigravity など）、そしてコンテキスト ウィンドウ（モデルが処理できるようにするすべてのデータのスペース）です。

これらすべての要素の組み合わせによって、実現可能性が決まります。

簡単な例を挙げると、Android Bench で Gemma 4 のテストを行っていたとき、デフォルトの 32k コンテキストで Ollama バージョンを実行していました。

そして、バグを探すテストの 1 つで、エージェント ハーネスの圧縮によってそのファイルがメモリから移動され、モデルがタスクを完了できずに失敗することがわかりました。

コンテキストを 32k から 256k に増やすだけで、メモリに保持できるようになり、モデルはその特定のテストに合格できるようになりました。

その結果、この特定のジョブの成功率は 2 倍になりました。

このように、これらの小さな要因の 1 つでも、このモデルが適しているかどうかに大きな影響を与える可能性があります。

では、実際に独自の評価を行うにはどうすればよいでしょうか。

そこで、3 つの簡単な提案があります。

1 つは、Git 履歴（すでに成功している一連の PR）を取得し、それらをモデルへのプロンプト入力として使用して、モデルのパフォーマンスを確認することです。

次に、モデルの出力が正しいかどうかを評価するのに役立つ、決定論的なグレーダーのようなものが必要です。

これには 2 つの優れた例があります。

コンパイラと単体テストがあります。

生成されたものは何でも、そのツールで実行できます。その特定のタスクが成功したかどうかを、合格 / 不合格のような形で教えてくれます。

3 つ目は、ログの軌跡です。

そのため、エージェントを実行する際には、エージェントのさまざまな動作をトレースし、どこで成功し、どこで失敗したかを確認できるようにする必要があります。これを使用して、モデルがツールをどの程度適切に操作して使用できるかを評価できます。

質問の枠組みを「このモデルは、この大規模なフロンティア モデルと同じくらいスマートか？」から、

「このハードウェアで、この特定の構成で、このタスクは可能か？」

それを把握するために、Google は「Are we there yet?」というフレームワークを考案しました。

または AWTY。

このフレームワークの基本原則は、さまざまなタスクを準備状況の観点から評価することです。

モデル自体、使用している推論エンジン、ハーネス、ハードウェア構成です。

それによって、準備ができているかどうかがわかります。

たとえば、特定のタスクの信頼性を確認する場合、

たとえば 10 回連続で実行した場合、毎回同じ処理が行われるか？

レイテンシを確認している可能性があります。

リアルタイムのレスポンスが必要な場合もあります。

タスクの処理速度のしきい値はどのくらいですか？

また、RAM の要件を確認することもできます。

つまり、デバイスが搭載している RAM だけでなく、デバイスの RAM、つまり、利用可能なカーブアウト、そしてそのハードウェアで実行する必要がある他のアプリケーションや他のツールも考慮する必要があります。

RAM の 50% を使用できるのか、10% しか使用できないのか。

そして、最終的なエナジースコアが算出されます。

緑色であれば、構成の準備が整っていることを意味します。

オレンジ、黄色、赤の場合は、構成の変更が必要になる可能性があります。

低レイテンシを実現するために、より高速なアクセラレータが必要な場合や、より高性能な、より大きなモデルが必要な場合もあります。

ぜひ、こちらをご確認ください。

現在プレビュー版が公開されています。このツールの有用性について、ぜひフィードバックをお寄せください。

評価の設定方法については、後ほど Zoe が詳しく説明します。それでは、Jose にバトンタッチして、Gemma 4 を簡単に使い始める方法を紹介してもらいます。

Ian さん、ありがとうございました。

そうですね。今すぐ Gemma 4 を試す最も簡単な方法は、Android Studio を使用することでしょう。

その方法をご紹介しましょう。

ノートパソコンに切り替えてください。

さあどうぞ

設定のモデル プロバイダ ページに移動して Gemma を選択すると、各モデルのサイズが明確にわかります。

モデルをハードドライブにダウンロードするだけです。

これにより、llama.cpp サーバーが開き、起動します。このサーバーは、最初から正しく構成されています。

ただし、独自の llama.cpp サーバー、Ollama、LM Studio など、お好みのものを使用することもできます。

そのためには、ここでローカル プロバイダを追加します。

また、リモート プロバイダを介して小規模なモデルを使用することも理にかなっています。

OpenAI または Anthropic と互換性がある限り、ここで追加して接続できます。

では、見てみましょう。

Android Studio でモデルを選択するには、このプルダウンを使用します。

Gemma 4 26B を選択して、「ViewModel とは何ですか？」と質問できます。

違いますね。

ここで重要なのは、モデルを変更すると、会話全体が最初から新しいモデルに再送信されるということです。

そのため、モデルとの会話が非常に長くなり、新しい会話に切り替えたい場合は、新しい会話を開始するか、会話を圧縮するか、何らかの対応が必要になります。

では、スライドに戻り、小さなモデルで実行できるさまざまなワークフローについて、Zoe から説明してもらいましょう。

Jose さん、ありがとうございました。Ian さん、Gemma モデルの概要と、私たちがそこに到達しているかどうかについて、ありがとうございました。

ここまで、モデルの種類とその仕様について見てきました。次は、モデルに実行させることができるジョブの種類について理解しましょう。

1 つ目のタイプのジョブは、おそらく皆さんがすでに行っているものです。デバッグやトラブルシューティングなどのコーディング ワークフローや、テスト カバレッジの拡大など、誰もが（少なくとも私は）手作業で行うことを深く皮肉を込めて懐かしむようなものです。

必要があります

これらは、おそらく誰もがすでに、気づかないうちに実践していることだと思います。

しかし、それ以上のことを考えていただきたいと思います。

小規模モデルはオープンウェイトでローカルに実行できることを考えると、時間を節約できるものは何でしょうか。

必要があります

ロケットを使わないという話なのに、なぜ脳を使うのでしょうか？

では、その先にある、小規模モデルでできることとは何でしょうか？

どのようなワークフローに AI を導入すれば、作業が楽になり、より多くのことを行うためのキャパシティを確保できるでしょうか。

たとえば、ドキュメントが常に変更内容を反映して最新の状態に保たれるようにすることや、自動回帰テストを pre-commit フックの一部として組み込むこと、ワークフローの一部としてエージェントが受け取るコンテキストを最適化して、処理をさらに高速化することなどが挙げられます。

これらはほんの一例です。

そして、最終的には、ある程度は無限の可能性があり、アーキテクチャが限界となります。実装方法については、さまざまなことが考えられます。

仕様、ツール、ワークフローが揃っても、どこから始めればよいかわからない場合は、

そのためにベンチマークがあります。

また、Ian が言ったように、一般的なリーダーボード、特に Python 用のリーダーボードでは、小規模なモデルが Android ワークフローに役立つかどうかはほとんどわかりません。

たとえば、乾式壁用のドリルについて詳しく知っていても、コンクリート用のドリルについてはあまり知らないかもしれません。

ただし、独自の評価に投資する必要があります。

独自のアーキテクチャのテストに投資する必要がありますが、その前に、すべてのリソースを投入したくない場合があります。

時間、費用、労力がかかるため、一般公開されているベンチマークを調べることで、独自の評価に投資する前に、アイデアを得て候補を絞り込むことができます。

ベンチマークを評価する際には、3 つの点に注目する必要があります。

少しメタな話になりますが、基本的に、まずこのモデルが行っているタスクの種類は何でしょうか。

指定の度合い。

このタスクは、あなたがモデルに与えるタスクに似ていますか？

2 つ目は、タスクのスコープです。

ドキュメントの作成、PR の解決、あなたが担当しているような仕事など、どのような仕事でしょうか？

最後に、システムの複雑さは、提供する複雑さと同様ですか？

ここで、Python ベンチマークが Android の代表的なベンチマークにならない理由がわかります。

そのため、Android エコシステムと Android の作業を把握するベンチマークである Android Bench を構築しています。

最初のバージョンには、PR サイズの Android タスクが 100 個含まれています。Harbor を通じて、エージェント、モデル、スキルの組み合わせをテストできます。

2.0 では、より複雑な長時間実行タスクを導入し、現在与えられているようなジョブでフロンティア モデルがどのような能力を発揮できるかを把握します。

それでは、Jose にバトンタッチして、この取り組みで得られた結果と、小規模なモデルを最適化する方法をいくつか紹介してもらいます。

ありがとう、ゾーイ。

では、小さなモデルで解決できるタスクと、解決が難しくなるタスクを見てみましょう。

そして、タスクを小、中、大、長期的な 4 つのカテゴリに任意に定義しましょう。

長期的なタスクとは、人間が完了するまでに数日または数週間かかる可能性のあるタスクです。

たとえば、移行や大規模なリファクタリングなどです。ネタバレになりますが、これらは小さなモデルではできません。

少なくとも 1 回で。

これについては後ほど説明します。

小さなタスクですね。

1 つまたは 2 つのファイルの読み取りと書き込みが必要なジョブであり、多くの知識は必要ありません。

たとえば、小さなモデルは Compose、少なくとも Compose の基本をかなり得意としています。

たとえば、要素間に 8 dp のスペースを設ける、ハードコードされた色ではなくテーマを使用する、文字列を抽出する、などです。

小さなモデルでも簡単に処理できます。

このタスクは、より高度なトピックを扱っていますが、タスク自体は簡単です。

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

この場合、難しさは知識ではなく、範囲にあります。

プロンプトは、最適化するコンポーザブルと、その問題（フレームごとに再コンポーズされていること）を実際に示しています。

そのため、Gemma 4 などの小さなモデルでも、このジョブは非常に簡単になります。

この場合は 3 分かかり、1 行の変更です。

それでは

これで、小規模モデルとは何かについて、かなりよく理解できたと思います。

小さなタスクとは何かを見てみましょう。

中程度のタスクを見てみましょう。

小規模モデルでも、ほとんどのタスクを実行できるはずです。

このタスクでは、Pocket Casts アプリからのリクエストにユーザー エージェントが含まれておらず、再試行ロジックにもエラーがあります。

このプロンプトは少し難易度が高くなります。まず、2 つのことを同時にリクエストしていること、そして、それらがコードベースのどこにあるかについてのヒントがないことが理由です。

しかし、法案は可決されました。

10 分かかりました。

3 つのファイルが変更されました。

ちなみに、OpenRouter を通じて 6 セントかかりました。

次に、同じデータセットで失敗したタスクを見てみましょう。

これは、かなり包括的なレポートまたはプロンプトを含む Now in Android の例ですが、クラス名やファイルが言及されていないため、エージェントはアプリのアーキテクチャ、データレイヤ、同期メカニズムなどを理解するために、より多くの労力を費やす必要があります。そのため、この特定の実行では失敗しました。

ほぼすべてが正しく実装されていましたが、最初の同期の値が -1 であると想定されていました。実際には 0 です。

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

以上が、

このバグは、エージェントが単体テスト（既存の単体テスト）を実行していれば、検出されていたはずです。

これは、一般的に、小規模なモデルがフロンティア モデルよりも少し早く停止する傾向があることを示しています。

エージェントには、問題の確認ではなく、修正を依頼しただけです。

そのため、検証ステップを含むようにタスクを変更する必要があるかもしれません。

これについても後ほど説明します。

では、大きなタスクについて説明します。

この定義では、大規模なタスクの約半分が毎回合格します。

失敗したもののいくつかは、実際には小規模モデルには長すぎて複雑すぎるため、できることはあまりありません。

しかし、実際に何が起こったかを見ると、モデルが 90% 程度は正しかったことがわかるものもあります。

そのうちの 1 つを選択しましょう。

このテストは不安定なため、選択しました。

実行される時間の約半分をパスします。

そのため、これは小規模モデルでできることの最先端だと考えています。

少なくとも 4 月のモデルです。

これは、Coil ライブラリで不正な形式の URL を解析することに関するものです。

ご覧のとおり、PR の説明はかなり包括的で、素晴らしいのですが、要件が 1 つ抜けています。

では、簡単に見てみましょう。

すべての実行で、一般的な URL エンコードとエラーがチェックされましたが、不適切にエンコードされた文字のテストを追加したのは半数のみでした。

評価に失敗しなかったもの。

すべての実行がほぼ完璧ですが、小さなモデルが必ずしも追加のステップを実行するとは限らないことがわかります。

指示には従いますが、フロンティア モデルのようにユーザーに好印象を与えようとはしません。

最近のエージェントでは、エフォートを設定できることをご存じですか？

小さなモデルを使用する場合は、設定が低すぎることを考慮してください。

そこで、大きなタスクを、小さなモデルで 50% 程度の確率で完了できるタスクと定義しましょう。これは、Gemma 4 31B が Android Bench v1 データセットに対して達成できるレベルです。これは、ゾーイが以前に話した内容です。

長期的なタスクについて説明する前に、小規模モデルでこれらのタスクを処理できるようにする方法はありますか？

もちろんです。しかも、これらの作業にはまったく手間がかかりません。

まず、Ian が言及したように、Gemma 4 などのモデルをローカルで使用している場合は、正しく構成されていることを確認してください。

たとえば、Ollama を使用して Gemma 4 を提供する場合、デフォルトのコンテキスト ウィンドウは 32,000 トークンですが、実際にはその 8 倍のトークンをサポートしています。

もちろん、Android Studio で Gemma 4 を使用する場合は、設定する必要はありません。

デフォルトで正しく構成されています。

Google の一連の評価では、フルコンテキストを有効にすることで、結果が 26% から 53% に向上しました。

次に、Android CLI ツールである Android CLI を使用します。特にドキュメントの検索に使用します。

モデルは基本に忠実であるため、これは必ずしも当てはまるわけではありませんが、新しい API やニッチな API を使用する場合は、ドキュメントを用意することが重要です。

私たちの経験では、ウェブ検索ツールを使用するよりもはるかに優れています。

次に、確認のヒントを追加します。

この件については話し合いました。

テストの実行方法、利用可能なテストの種類、エミュレータの管理方法などをモデルに指示します。これは AGENTS.md ファイルで行うことができます。これにより、すべてのエージェントが指示を利用できるようになります。これは良いことです。

お持ちのはずです。

ただし、AGENTS.md ファイルが非常に長い場合は注意が必要です。さまざまなエージェントを試してみると、一部のエージェントには膨大なシステム プロンプトとツール説明があり、小さなモデルのパフォーマンスを低下させているように見えることがあります。

実際に OpenCode でこれらのベンチマークを実行してみたところ、pi よりもパフォーマンスが大幅に低下しました。これは、より大きなツール記述とシステム プロンプトを使用しているためと考えられます。

次に、スキルを追加し、スキルを削除します。

小規模なモデルでは、新しいニッチな API を使用する際に、少し後押しが必要になる場合があります。ただし、たとえば一般的な Compose スキルでコンテキストを埋めることは避けた方がよいでしょう。

では、長期的なタスクはどうでしょうか。

これらは、数十のファイルにまたがり、重大なアーキテクチャ上の決定を必要とするタスクであり、通常は、計画を作成し、さまざまなタスクを実行するサブエージェントの群れを開始する思考モデルによって処理されます。

長期的なタスクの例としては、アプリ全体を XML から Compose に移行する、複雑なアプリをゼロから作成する、クロスプラットフォーム アプリをネイティブ Android に変換する、などが挙げられます。

長期的なタスクに特化した Android Bench V2 の結果を見ると、フロンティア モデルのスコアは 3 ～ 40% です。

そのため、小さなモデルでは、このタスクは手に負えないと言っても差し支えないでしょう。

しかし、最初の分析をフロンティア モデルにルーティングし、より単純なタスクをより小さなモデルにカスケードする方が、トークンとクレジットの効率がはるかに高くなります。

その方法を見てみましょう。

ゾーイに戻ります。

Jose さん、ありがとうございました。

カスケードについては後ほど説明しますが、その前に、いくつかの方法をご紹介します。あるいは、詳細解説に入る前に、一歩下がって、さまざまなモデルのオーケストレーションがどのように役立つか、他の方法をご紹介します。

たとえば、オーケストレーションは、ブロックされないようにするのに役立ちます。

プロバイダがダウンした場合、API レート制限に達した場合、イアンが言ったように飛行機や電車に乗っている場合など、フォールバック モデルを設定しておけば、オンラインでもローカルでも、何かが起きても継続できます。

オーケストレーションによって、より適切な回答を得ることもできます。

たとえば、小さなモデルを単独で動作させ、少しサポートが必要なときにアドバイザーを呼び出して、そのサポートを受けることができます。

また、さまざまなタイプのモデルや異なるモデルがすべて同じタスクを一度に実行する評議会を設置し、さまざまな回答と、各モデルの重みとバイアスが結果にどのように影響したかを評価することもできます。

また、別のモデルをテストとして使用することもできます。

つまり、ピアレビューのようなものです。

このグラフでそれがわかります。

そしてもちろん、最後に、オーケストレーションは、カスケードのようなものを通じて費用対効果を高めるのに役立ちます。

基本的には、手動で設定できます。たとえば、計画用に 1 つのモデルを設定し、実行用に別のモデルを設定し、テスト用にさらに別のモデルを設定できます。

これを行うには、クラウドで行う方法や、LiteLLM プロキシを設定してローカルで行う方法など、複数の方法があります。

または、分類器を使用して、リクエストに基づいて適切なタイプのモデルに自動的にルーティングすることもできます。これは、Ian が言及したプロキシのアイデアですが、自動化されています。

最後に、Jose が講演の最初に投げかけた質問に戻りましょう。小規模モデルとフロンティア モデルの品質と精度の違いは何でしょうか。

コンピュータ サイエンスの多くの事柄と同様に、答えは「状況による」です。

しかし、これはエンジニアリングできるものであるということを、皆様に持ち帰っていただきたいと思います。

これは、設定方法やピースの操作方法によって違いを生み出すことができるものです。

最初のステップは、適切なツールを選択することです。

ツールには複数の種類があります。

それらをよく知り、探索する。

そして、どのような仕事に適しているか、どのような仕事ができるかを見極めます。

2 つ目は、モデルがタスクを実行するために取得するスコープを調整することです。

たとえば、タスクの指示、タスクに適切なコンテキストのみを提供すること、独自の作業を確認する方法などです。

次に、もちろん、モデルを単独でテストするのではなく、セットアップ全体をテストする必要があります。これは、セットアップ全体をテストすることで違いが生じるためです。また、たとえば、要素の構成を変えてセットアップすると、得られる結果を微調整できる可能性があります。

そして最終的には、独自の評価を設定または作成する必要があります。

そして最後に、自転車とロケットをオーケストレーションすることで、どちらか一方を選択する必要がなくなり、効果的に費用をかけることができます。

しかし最も重要なのは、引き続き探索し、構築し、楽しむことができるということです。

Android Bench とその結果からモデルの候補リストを作成するか、Android Studio で Gemma 4 を使い始めることで、今すぐ始めることができます。

ありがとうございました