デバイス内言語モデルの進展

言語モデルは、コンピュータが人間の言語を理解して応答するのを助ける重要なツールだよ。これらは多くのアプリケーションで使われてて、特にワークフローの自動化に役立ってる。これらのモデルのキーとなる能力の一つは、関数を呼び出すことができることで、AIエージェントを作るのに便利なんだ。ただ、クラウドで動く大きなモデルを使うとプライバシーやコストに関する懸念が生じて、使うのに躊躇する人が多い。

この問題を解決するために、研究者たちはスマートフォンやコンピュータみたいなデバイスで動く小さなモデルに取り組んでる。この小さなモデルは、早くて安く使えることが多いけど、正確性やスピードに苦労することがあるんだ。この記事では、20億パラメータを持つオンデバイスモデルの新しい手法を紹介してる。このモデルは、正確性やレイテンシの面でGPT-4のような大きなモデルよりも優れてるんだ。

#AIエージェントを使った自動化ワークフロー

AIエージェントは、ソフトウェアアプリケーションでますます一般的になってるよ。MultiOnやAdept AIみたいなツールは、ユーザーがタスクをもっと効率的にこなすのを助けてる。Rabbit R1やHumane AI PinみたいなAI消費者向け製品の最近の増加は、インテリジェントアシスタントの需要を示してるね。AIエージェントは人間のリクエストを受けて、それを行動可能なステップに翻訳するのが上手くなってきてるけど、これを実現するのに大きなクラウドベースのモデルに依存してることが多い。

これらの大きなモデルは関数呼び出しをうまく処理できるけど、欠点もあるよ。たくさんの関数呼び出しが必要な場合、使用コストが高くなる可能性がある。たとえば、GPT-4のようなモデルを使うと、AIボットとの1時間の会話で約0.24ドルかかるんだ。さらに、プライバシーへの懸念が、敏感な情報をクラウドで処理するモデルの利用をためらわせる要因になってる。

#エッジデバイスの課題

コストを抑えてプライバシーを強化するために、エッジデバイスで動く小さなモデルを作るトレンドがあるよ。これらのデバイスにはスマートフォン、車、バーチャルリアリティヘッドセット、パソコンが含まれる。ただ、小さなモデルは処理速度が遅かったりバッテリーの持ちが限られてるため、連続使用にはあまり効果的じゃない。

研究によると、小さなモデルのエネルギー消費はかなり高く、1億パラメータのモデルで約0.1J/tokenになってる。これは、従来のリトリーバルメソッドを使うモデルが毎回の関数呼び出しで大量のバッテリーを消費する可能性があることを意味してて、デバイスが1日に扱える呼び出しの数を制限しちゃうんだ。

小さなモデルは通常、推論タスクに苦労していて、関数呼び出し能力を向上させるためにはかなりの調整が必要だよ。私たちの研究は、これらの問題を解決する方法を開発して、関数呼び出し時の正確性とスピードを向上させたんだ。

#手法の概要

新しい手法は、関数名をトークン化して、特別な関数トークンでモデルをファインチューニングすることにフォーカスしてる。これにより、モデルはソフトウェアアプリケーションの能力をもっとよく理解できるようになる。モデルが予測を行うとき、これらのトークンを使ってより正確な関数呼び出しを生成するんだ。

実際には、私たちのモデルは前よりも多くの関数呼び出しを処理できて、しかもすごく早くなった。コンテキストの長さを95%削減したことで、処理時間が直接的に早くなったんだ。たとえば、20億パラメータの私たちのモデルは、従来の方法と比べてバッテリーを消耗せずに37倍の関数呼び出しを可能にしてる。

#オンデバイスモデルにおける関連研究

大きな言語モデルをデバイスにデプロイするのはメモリやスピードの制限があるから難しいけど、Gemma-2BやLlama-7Bみたいな小さなオープンソースモデルがいくつか登場してる。推論速度を改善するための努力が、これらのモデルをモバイルデバイスで動かすためのフレームワークの開発につながったんだ。

小さなモデルの関数呼び出し能力を向上させるための重要な進展があったよ。最近のプロジェクトでは、70億や130億パラメータのモデルが大きなモデルと同じくらい効果的に外部APIを呼び出せることが示された。以前のバージョン、Octopus v1も、20億パラメータのモデルが同じレベルでパフォーマンスを発揮できることを証明してたんだ。

#関数呼び出し技術

言語モデルが改善されるにつれて、関数呼び出しの能力も向上してるよ。注目すべきプロジェクトは、高度な技術を用いて効率的なAPI呼び出しを実演してる。Octopus v1モデルは、パフォーマンスにおいて小さなモデルがより大きなモデルに匹敵する能力を示したよ。

私たちのアプローチは、関数呼び出しのためにリトリーバル拡張生成（RAG）と呼ばれる手法を使ってる。これは、モデルがユーザーのクエリに基づいて関連する関数を取得し、これらの関数をコンテキストとして利用して応答を生成するというものなんだ。

#モデルのファインチューニング

言語モデルのファインチューニングは、この分野における一般的な慣行だよ。人気のある方法の一つがLoRAで、限られたコンピュータ資源でもモデルが効果的に学習できるようにするもの。私たちの作業は、フルモデルのトレーニングとLoRAを統合して、そのパフォーマンスを比較してる。

LoRAはモデルの能力を拡張するのに役立ち、さまざまなタスクに対してアプリケーションの道を開くんだ。私たちの場合、スマートフォンの操作に関連する特定の関数を学習するために、Android APIのデータセットを利用したよ。

#関数の選択方法

適切な関数を呼び出すには複数のステップが必要だよ。最初のステップは、関数の説明を理解して、必要な引数を把握すること。私たちは、モデルがユーザーのクエリを見て、どの関数を呼ぶべきかを判断する方法を使ってる。

一つのオプションは、クエリとの類似性に基づいて最適な関数を特定する分類モデルを使うこと。もしくは、複数のモデルを組み合わせて関数名を正確に予測することもできる。このプロセスを上手く構造化することで、正確性と効率性を向上させられるんだ。

#関数トークンの革新

私たちの手法の重要な革新の一つは、関数トークンの導入だよ。これらのトークンは、特定の関数を表す特別な言葉みたいなもので、モデルの仕事をその関数を認識して呼び出すことに簡素化してる。

言語モデルが一般的な単語を認識することを学ぶのと同じように、私たちのモデルもトレーニングプロセスを通じてこれらの関数トークンを学ぶことができるんだ。これにより、特定のアクションを効率的に実行することに集中できるようになる。これらのトークンに対するモデルの知識を高めることで、関数呼び出しのパフォーマンスが向上するよ。

#トレーニング用データセットの収集

高品質なデータセットを作成することは、モデルのトレーニングと検証に不可欠だよ。私たちは、使いやすさ、使用頻度、技術的な複雑さに基づいてAndroid APIを集めた。このプロセスでは、現実的な関数実行を確保するためにAPIをカテゴリに整理したんだ。

システムAPI、アプリAPI、スマートデバイス管理APIの範囲をまとめた。この選択により、モデルがさまざまなシナリオで関数呼び出しを理解し、生成できるようになるよ。

#データの生成と検証

データセット生成のプロセスには、ポジティブな例とネガティブな例を作成することが含まれるよ。ポジティブな例は、単一のAPIで解決できるクエリで、ネガティブな例はどの関数にも対応しないクエリが含まれる。この2つのタイプをバランスよく保つことで、モデルの理解力と分析能力が向上するんだ。

データセットの質を確保するために、生成された関数呼び出しの正確性を評価する検証メカニズムを実装した。このシステムは、基準を満たさない結果が出た場合に結果を再生成するためのチェックを使うんだ。

#モデルのトレーニングと開発

私たちの開発はGoogleのGemma-2Bモデルに基づいてる。トレーニングには、フルモデルのトレーニングとLoRAアプローチの両方が含まれるよ。トレーニング中には、モデルが効率的に学習できるように最適化された技術を使ってる。

両方のトレーニング方法で、学習率を設定してトレーニングエポックの数を計画してる。パフォーマンスの評価は、私たちのモデルの結果をトップパフォーマンスのモデルと比較して、正確性とスピードのメトリックを測定することを含むんだ。

#Android関数呼び出し

私たちのモデルの動作を示すために、Androidシステム関数呼び出しに適用したよ。ユーザーのクエリに基づいて正確な関数呼び出しコマンドを生成することに集中した。これには、異なる方法を使ってクエリをサンプリングし、期待される結果にラベルを付けることが含まれるんだ。

私たちのモデルのパフォーマンスを他のモデルと比較することで、正確性とレイテンシを効果的に測定できたよ。このベンチマーキングプロセスは、リアルワールドのシナリオでの私たちのモデルの実用性を判断するのに役立つんだ。

#結果と評価

私たちの調査結果は、Octopusモデルが他のモデルと比較して素晴らしい結果を達成してることを示してる。高い正確性を持ちながら、低レイテンシで正しい関数呼び出しを生成することに成功したんだ。これは、GPT-4やGPT-3.5のような大きなモデルと比べても重要な改善だよ。

RAG技術がエラーを最小限に抑え、レイテンシを最適化するのにどれだけ効果的かを調べたよ。関連する関数の説明を取得することに焦点を当てることで、私たちのモデルは素晴らしいパフォーマンスを示したんだ。

#Android以外のアプリケーション

私たちのモデルの適用を広げる中で、車両やYelpやDoorDashのような消費者サービスでも機能するかどうかを探ってみたよ。同じベンチマーキング方法を適用することで、私たちのアプローチがさまざまな関数群で一貫したパフォーマンスレベルを維持していることがわかったんだ。

この適応力により、開発者は特定のニーズに合わせてモデルをカスタマイズでき、さまざまなアプリケーションでのユーティリティが向上するんだ。

#限られたデータでのトレーニング

私たちのモデルは、APIごとに1,000のデータポイントでうまく機能したけど、データポイントを減らしても効果的に動作するかどうかも調査したよ。分析の結果、データセットを100ポイントに減らしても、驚くべき正確性を維持できることがわかった。これにより、トレーニングプロセスがよりコスト効率的になるんだ。

少ないリソースでトレーニングできる能力は、効率的なAIエージェントを展開しようとする開発者にとってモデルをよりアクセスしやすくするね。

#結論

Octopusモデルは、オンデバイス言語モデルの分野で重要な進歩を示してる。私たちの手法は関数呼び出しを簡素化し、AIエージェントとのユーザーインタラクションを改善する。関数トークンの導入、効果的なデータセット収集と検証を組み合わせることで、正確で効率的な応答が可能になったんだ。

これからは、オンデバイス推論を重視したモデルを開発し、さまざまなアプリケーションのデプロイオプションを強化する計画だよ。私たちの目標は、プライバシーへの懸念とスピードのニーズをバランスよく提供し、ユーザーが自分に合ったものを選べるようにすることなんだ。

この研究を通じて、開発者がこれらの革新を活用して、さまざまなアプリケーションでユーザー体験を大幅に向上させるAIエージェントの作成を簡単にできるように促していきたいな。