現場で最大97%の精度を実現するエンドサイドデバイス向けAIエージェント最適化フレームワークをリリース。

AIxivコラムは、本サイト上で学術的・技術的な内容を掲載するコラムです。過去数年間で、このサイトの AIxiv コラムには 2,000 件を超えるレポートが寄せられ、世界中の主要な大学や企業のトップ研究室がカバーされ、学術交流と普及を効果的に促進しています。共有したい優れた作品がある場合は、お気軽に寄稿するか、報告のために当社までご連絡ください。提出メールアドレス: liyazhou@jiqizhixin.com; zhaoyunfeng@jiqizhixin.com

この記事は、MIT-IBM Watson AI Lab と協力して NEXA AI チームによって開発されました。最初の著者である Wei Chen (Chen Wei) は、NEXA AI の共同創設者、CEO、主任科学者であり、スタンフォード大学で博士号を取得しており、人工知能研究において豊富な経験を持っています。共著者の Zhiyuan Li は、NEXA AI の共同創設者兼 CTO であり、スタンフォード大学の卒業生であり、Google と Amazon Lab126 でエンドサイド AI の最前線で長年研究開発の経験を積んできました。他の 2 人の共著者は、MIT と IBM の Zhen Guo 氏と Yikang Shen 氏です。

自律的な意思決定と問題解決ができる AI エージェントはますます重要になってきています。これらのエージェントが効果的に機能するには、最適な行動方針を決定し、計画された行動を実行する計画プロセスが必要です。

このペーパーでは、計画とアクションの実行を 2 つのコンポーネントに分離する、効率的なデバイス側の計画アクション フレームワークを提案します。エッジ デバイス向けに最適化された計画エージェント (Octo-planner) と、オクトパス モデルを使用してアクション エージェントを実行するアクション エージェントです。関数を実行します。 Octo-planner は、まずタスクを一連のサブステップに分割することでユーザーのクエリに応答し、その後、Octopus アクション エージェントによって実行されます。リソースに制約のあるデバイスのパフォーマンスを最適化するために、コンテキスト学習の代わりにモデルの微調整を採用し、応答時間を改善しながら計算コストとエネルギー消費を削減します。

私たちのアプローチには、GPT-4 を使用して、利用可能な機能に基づいてさまざまな計画クエリと応答を生成し、その後データ品質を確保するための検証が含まれます。厳選されたデータセットに基づいて Phi-3 Mini モデルを微調整し、ドメイン内テスト環境で 97% の成功率を達成しました。

マルチドメイン計画の課題に対処するために、機能の異なるサブセットでトレーニングされた LoRA 重みを結合するマルチ LoRA トレーニング手法を開発しました。このアプローチは、リソースに制約のあるデバイスでの計算効率を維持しながら、複雑なマルチドメイン クエリを柔軟に処理します。

• ペーパー: https://arxiv.org/pdf/2406.18082

• デモ: https://www.nexa4ai.com/octo-planner#video

• モデルページ: https: //huggingface.co/NexaAIDev/octopus-planning

1 はじめに

人工知能 (AI) エージェントは、自律的な意思決定を可能にし、業務効率を向上させることで、さまざまな業界を大きく変革してきました。これらのエージェントは、最適な行動方針の決定、計画された行動の実行、結果の要約を含む重要な計画プロセスに依存しています。 Gemini-Pro や GPT-4 などの大規模言語モデル (LLM) は、この分野での可能性を示しています。

これらのモデルは、複雑な計画タスクを実行する際に課題に直面し、人間のパフォーマンスに匹敵するレベルに到達するのに苦労していますが、単純なタスクを処理する場合には依然として効果的であるため、実用的なアプリケーションが容易になります。そのようなアプリケーションの 1 つは、MultiOn、Simular AI、Adept AI などの企業が提供する AI アシスタント ツールです。これらは、LLM の力を活用して、さまざまな分野でインテリジェントなアシスタントを提供します。

さらに、Rabbit R1、Humane AI Pin、Limitless ペンダントなどの消費者向け AI ハードウェア製品は、LLM をユーザーフレンドリーなデバイスに統合し、スマート アシスタントをよりアクセスしやすくし、大きな注目を集めています。 AI エージェントの成功は、基盤となる LLM のパフォーマンスに依存します。タスクのデモンストレーションで微調整を行わずに事前トレーニング済みモデルを使用したエージェントの成功率は、デスクトップ アプリケーションの 12% からモバイル アプリケーションの 46% までと比較的低く、一方、微調整されたモデルを活用したエージェントは、トレーニング データと同様のタスクでより良いパフォーマンスを示しました。タスクで最大 80% の成功率を達成します。

ただし、LLM を使用する AI エージェントは、高い計算要件とインフラストラクチャ費用によりコストが高く、広範な導入が制限されています。オンデバイス AI エージェントがないため、リアルタイム処理、オフライン機能、プライバシーの強化を必要とするアプリケーションが制限されます。オンデバイス AI エージェントは、遅延の短縮、オフライン操作、コストの削減、データ セキュリティの向上などのメリットをもたらします。 Octopus V2 などのアクション モデルは関数呼び出しで 95% 以上の精度を達成していますが、デバイス側の計画モデルがまだ不足しています。一般的なエージェント フレームワークは単一モデルのコンテキスト学習を使用し、各プロンプトで長い機能の説明と計画の指示を必要とします。このアプローチは、コンテキストの長さが制限されているデバイス側モデルでは非現実的であり、エッジ デバイスでの遅延とバッテリー消費が大きくなります。

このペーパーでは、効率、適応性、リソースの制約という重要な課題に対処するオンデバイス プランニング エージェントである Octo-planner を紹介します。当社のプラン アクション フレームワークは、プランニングとアクションの実行を 2 つのコンポーネントに分離します。エッジ デバイス (Octo-planner) での使用に最適化されたプランニング エージェントと、Octopus モデルを使用して機能を実行するアクション エージェントです。

少数ショットのヒントよりも微調整を優先することで、計算コストが削減され、キーバリュー (KV) キャッシュ要件が最小限に抑えられます。私たちのアプローチでは、GPT-4 を使用して計画データを生成および検証し、そのデータを使用してオンデバイス展開用に Phi-3 Mini を微調整します。ドメイン内テストでは、この微調整により計画の成功率が 97% に向上したことが示されました。マルチドメイン計画の課題に対処するために、機能の異なるサブセットでトレーニングされた LoRA 重みをマージするマルチ LoRA トレーニング手法を開発しました。このアプローチは、リソースに制約のあるデバイスでの計算効率を維持しながら、複雑なマルチドメイン クエリを柔軟に処理します。

単純なタスク用の事前定義された関数に焦点を当て、微調整を活用することで、AI エージェントを現実世界のアプリケーションでより実用的でアクセスしやすく、コスト効率の高いものにすることを目指しています。

この取り組みは、AI をよりアクセスしやすく便利にするための継続的な取り組みに貢献することを目的としています。 AI エージェントの可能性とエッジ コンピューティングの限界の間のギャップを埋めることで、さまざまな分野でのスマート オンデバイス アシスタントの導入を促進したいと考えています。私たちのアプローチをオープンソース化することで、オンデバイス AI のさらなる革新を促し、高度なプランニング機能の範囲を拡大したいと考えています。

2 関連作品

プランニング エージェント: 言語モデルは、プランニング エージェント システムの鍵となっています。 OpenAI の Assistant API のような独自のモデルは、ユーザーのクエリと利用可能な機能に基づいてポリシーを生成することに優れています。最近の進歩により、物事の仕組みにおける言語モデルの機能がさらに拡張されました。 ReAct フレームワークは、限られた行動スペースで計画と行動を統合しますが、アリババ グループの研究では、複雑なタスクにおける個別の計画モデルと行動モデルの有効性が強調されています。ロボット工学では、言語モデルはタスクレベルの計画にも使用されることが増えています。注目すべき例としては、LLM を使用して高レベルのタスクを具体的なサブタスクに分解する SayCan や、テキストからビデオへの動的モデルで長期計画を強化するビデオ言語プランニング (VLP) などがあります。一般的なポリシーから特定のロボットタスクに至るまで、計画システムにおける言語モデルの幅広い用途は、さまざまな意思決定プロセスにおける言語モデルの重要性と適応性の増大を浮き彫りにしています。

長いコンテキストに対する微調整された代替案: 言語モデルを微調整して特定の手がかりやコンテキスト情報を内部化することで、入力の長さを短縮し、効率を向上させることができます。このアプローチには、注意深く厳選されたタスク固有のデータセットでモデルをトレーニングすることが含まれます。この手法は、応答品質を犠牲にすることなくクエリ処理効率を向上させることができるため、コンテキスト ウィンドウが限られたモデルにとって特に有益です。微調整が成功するかどうかは、多様で高品質のデータセットを使用して、さまざまなプロンプトの文言にわたってモデルを一般化できるかどうかに大きく依存します。適切に実装されれば、微調整によりアプリケーション固有の対話が簡素化され、実際の展開におけるコンテキストの長さの制約や計算上の課題を解決できます。

LoRA と Multi-LoRA: 低ランク適応 (LoRA) は、事前トレーニングされた言語モデルを特定のタスクに効率的に適応させることができます。すべてのパラメータを更新する微調整とは異なり、LoRA は事前トレーニングされた重みを凍結し、各層にトレーニング可能な低ランク行列を追加するため、トレーニング可能なパラメータと計算要件が大幅に削減されます。 Multi-LoRA はこの概念を拡張して、複数のタスク固有のアダプターを推論時にトレーニング、結合、または切り替えできるようにし、単一の基本モデルでさまざまなタスクを効率的に処理できるようにします。これらの方法に基づいて、研究者はモデル適応のさまざまな側面に対処するためにいくつかの関連するバリアントを開発しました。LoRA + 最適化された学習率、VeRA はランダム投影を使用、AdaLoRA は適応ランクを実装、DoRA は重みを分解、Delta-LoRA は事前トレーニングされた重みを更新します。これらのバリアントは、特定のシナリオで効率やパフォーマンスをさらに向上させるように設計されています。

3 メソッド

このセクションでは、オンデバイス プランニングのフレームワークであるアクション エージェントを紹介します。まず、効率的な問題解決を可能にする計画エージェントとアクション エージェントの統合について説明します。次に、幅広い機能のサポートや追加の機能セットのプラグ アンド プレイ機能など、計画エージェント向けのデータセット設計とトレーニング プロセスについて詳しく説明します。最後に、エージェントのパフォーマンスを評価するために使用されるベンチマークの概要を説明します。

3.1 計画とアクションのエージェント フレームワーク

私たちの計画とアクションのアプローチは、計画とアクションの実行プロセスを 2 つのコンポーネントに分割することで、一般的なエージェントのフレームワークとは異なります。この分離によりモジュール性が向上し、各コンポーネントの専用の最適化が可能になります。フレームワークは次のように動作します:

計画フェーズ: ユーザーのクエリ q が与えられると、計画モデル πplan はタスクを一連のサブステップに分解します。正式には:

{τ1, τ2, ..., τn} - πplan (q;F )

ここで、F は関数で記述できる集合、τi は i 番目の実行ステップです。 πplan は命令トリミング中に F を内部化します。

アクションフェーズ: 実行シーケンスの各ステップで、アクションモデル πaction を採用します。ステップ i では、現在の状態観測 Oi が与えられると、アクション モデルが実行されます:

Oi+1 = πaction (τi, Oi), (2)

ここで、Oi+1 と τi+1 は次のステップに渡されて実行を継続します。この反復プロセスにより、タスクのサブステップの一貫した進行が保証されます。

アクション モデルには、デバイス側の関数呼び出し用に設計された Octopus モデルを使用します。図 2 は、プラン/アクション フレームワークと単一モデル LLM エージェントの違いを示しています。

^{図 2: 単一 LLM エージェントとプランアクション エージェントのフレームワークの比較。 (左) 単一 LLM エージェント: タスクの計画とアクションの実行のための統合モデル。 (右) プランアクション エージェント: 特化したプランニング モデルがタスクをサブタスクに分解し、別個のアクション モデルが各サブタスクを順番に実行します。}

フレームワークのモジュール設計には、いくつかの利点があります:

• 専門化: 計画とアクションの実行を分離することで、各モデルを特定の役割に合わせて最適化し、複雑なタスクのパフォーマンスを向上させます。

• スケーラビリティ: 計画とアクションの機能を個別に拡張し、さまざまなタスクの複雑さに効率的に適応できます。

• 説明可能性: 段階を明示的に分離することで、意思決定プロセスの透明性が向上します。

• 適応性: システム全体の変更を必要とせずに、ドメイン固有の知識や制約を任意のフェーズに簡単に統合できます。

3.2 計画データセット

私たちのフレームワークは、アクション モデルとして Octopus モデルを使用し、計画エージェントのトレーニングのみが必要です。次のデータセット形式を使用して計画エージェントを微調整します:

チャット モデルの事前トレーニング用の や などの特別なマーカーはオプションです。モバイル アプリ上のほとんどのタスクは 5 ステップ未満で構成されているという発見に基づいて、n を 1 ～ 5 に設定します。データセットの生成とキュレーションのプロセスには以下が含まれます:

1. データセットの収集: 利用可能な関数 F が与えられると、大規模な言語モデル (GPT-4) を使用して、これらの関数によって応答される多様なクエリを生成します。クエリの多様性を確保するために、モデルの温度設定を増やします。その後、指定されたデータ セット形式で応答が生成されます。生成プロセス中に機能の説明を使用することが重要ですが、最終的なデータセットには含めないようにしてください。代わりに、計画モデルはトレーニング中にこの関数情報を内部化します。

2. データ検証: クエリと応答のペアの正確性を評価する検証ツールとして同じ言語モデルを使用します。最初の生成中にいくつかのエラーがありましたが、モデルが生成されたコンテンツを有効または無効に効果的に分類し、誤った出力を除外してデータセットの品質を維持できることがわかりました。

さまざまな数のサブステップのデータ ポイントの例を以下に示します。

データセット コレクションの視覚化については、図 3 を参照してください。関数の例については付録 7.1 で説明します。

3.3 ベースライン設計

私たちの評価は、慎重に構築されたテスト データセットに依存しています。このデータセットは、自動生成、専門家による検証、実証的テストを組み合わせた多段階アプローチを使用して、現実世界の計画の複雑さを表すように設計されています。

このプロセスは、GPT-4 を使用して自動的に生成された 1000 データ ポイントの初期データセットから始まります。これらのデータ ポイントは、その完全性と関連性を保証するために厳格な品質保証プロセスを受けます。品質評価基準は次のとおりです。

• 各ステップは既存の機能に対応している必要があります。

• ステップの順序は正しい必要があります。

評価の信頼性を確保するために、人間による検証段階を追加しました。このフェーズには、エンドツーエンドのモデル実行用のサンプルのサブセットを選択することが含まれます。これにより、結果の精度を検証し、モデルのパフォーマンスの包括的な評価を実行します。

提案された計画モデルを評価するために、GPT-4 を Oracle として使用し、生成された計画の正確さを判断します。この選択は、GPT-4 が特定の使用例で効率的に実行されることを示す経験的観察に基づいています。

4 実験設計

私たちの実験設計では、オンデバイス AI エージェント計画における Octo-planner のパフォーマンスを評価します。私たちの目標は、新しいドメインや機能への適応性を維持しながら、リソースに制約のあるデバイスに効率的かつ正確な計画モデルを展開するための最適な構成を特定することです。私たちの実験は 4 つの主要な領域に焦点を当てています:

1. 完全な微調整と LoRA の間のパフォーマンスと効率のトレードオフ。

2. 異なる関数セットを同時に処理する場合の Multi-LoRA の精度。

3. さまざまなベースモデルとスケールの性能比較。

4. データセットのサイズが精度に与える影響 (トレーニング サンプルの範囲は 100 ～ 1000)。

Phi-3 Mini とその他のいくつかの代替モデルをベースモデルとして使用し、厳選されたデータセットに対して教師あり微調整を実行します。トレーニングには完全な微調整と LoRA テクノロジーが含まれます。すべての実験で、データセットのサイズを利用可能な関数の数の 800 倍に設定し、NVIDIA A100 GPU で微調整しました。両方の手法で最適化されたハイパーパラメータを使用します: 学習率 5×10-6、バッチ サイズ 4、ウォームアップ比 0.2、2 エポックのトレーニング。 LoRA の場合、target_modules をすべて線形に設定します。

5 結果

5.1 フルファインチューニングと LoRA

表 1 は、フルファインチューニングと LoRA 手法に関する計画モデルの詳細な比較を示しています。私たちの実験では、これらの方法のパフォーマンスに大きな違いがあることがわかりました。フルファインチューニングでは98.1%の精度で最高のパフォーマンスを実現し、優れたパフォーマンスを発揮します。対照的に、LoRA のパフォーマンスはランク サイズに依存します。ランク 64 およびアルファ 256 では、LoRA は 85.1% の精度を達成しますが、ランク 16 およびアルファ 32 まで低下すると、精度は 72.9% に低下します。これらの結果は、LoRA を使用した場合のモデルのパフォーマンスと計算効率の間のトレードオフを浮き彫りにしています。完全な微調整により精度が向上しますが、LoRA はリソース効率の点でより魅力的な代替手段を提供し、パフォーマンスはランク構成に依存します。

^{表 1: 全額罰金- チューニングと LoRA ベンチマーク}

5.2 マルチ LoRA トレーニングとマージ

は特定の関数セットで有効ですが、実際のアプリケーションでは多くの場合、新しい機能を処理する必要がありますまたは拡張された関数セット。この課題に対処するために、関数の異なるサブセットでトレーニングされた各 LoRA 重みを同じ基本モデルにマージする方法を提案します。このアプローチでは、さまざまな関数セットからの知識を組み合わせた構成モデルを作成し、リソースに制約のある環境での複雑なマルチドメイン クエリに対するスケーラブルなソリューションを提供します。

このアプローチを評価するために、LoRA ドメインごとに関数をランダムに選択し、それらをワークフローに組み合わせてベンチマーク データセットを構築しました。クエリとプランは GPT-4 によって生成されます。たとえば、マージされた 2 つの LoRA をテストする場合、クエリには Android 機能、e コマース機能、またはその両方が同じ確率で含まれる可能性があります。

次のコード ブロックは、ベンチマーク データセット内のクエリの例と、マルチ LoRA マージ モデルの対応する推論結果を示しています。

表 2 は、マルチ LoRA マージ手法のパフォーマンス結果を示しています。個々の LoRA は、一貫したハイパーパラメーター (ランク 64、lora_alpha 256、target_modules が「オールリニア」に設定) でトレーニングされました。シングルドメイン Android 関数セット LoRA は 85.1% の精度を達成します。両方のドメイン (Android と e コマース) の LoRA を組み合わせると、精度は 82.2% にわずかに低下します。さらにマージすると精度は次のように低下​​します。3 つのドメイン (ビデオ ストリーミングの追加) では 78.9%、4 つのドメイン (出張の追加) では 69.7% です。これらの結果は、より多くの関数セットを統合するにつれて、特に 3 番目のドメインを追加した後、精度が徐々に低下する傾向を示しています。

^{表 2 : マルチ LoRA ベンチマーク}

5.3 異なるベースモデルを使用した完全な微調整

チューニング後に異なるベースモデルを使用したベースライン精度。 Google Gemma 2b は 85.6% の精度を達成しましたが、より大型の Gemma 7b は 99.7% の精度で優れていました。 Microsoft Phi-3 Mini も好調で、98.1% の精度を達成しました。これらの結果は、私たちのフレームワークがさまざまなデバイス側 LLM に適応し、より大きなモデルが一般に高い精度を達成することを示しています。

5.4 異なるデータセットサイズを使用した完全な微調整

デフォルトのトレーニング データセットには 1000 のデータ ポイントが含まれており、さまざまなタスクの複雑さを表すために 1 ～ 5 のステップ シーケンス (各 200) に均等に分散されています。関数セットの統合効率を最適化し、合成データの生成コストに対処するために、データセットのサイズがモデルのパフォーマンスに与える影響を研究します。表 4 は、さまざまなトレーニング データセット サイズのベースライン精度を示しています。

結果は、データセットのサイズと精度の間に明確な相関関係があることを示しています。 1000 ポイントのデータセット全体では 98.1% の精度が達成されましたが、データ セットを 500 データ ポイントに減らすと精度は 92.5% に低下しました。さらにデータ ポイントを 250 個と 100 個に減らすと、精度はそれぞれ 85.3% と 78.1% になります。これらの調査結果は、最適なパフォーマンスを得るには、1,000 を超えるデータ ポイントを含むトレーニング データセットを使用することが推奨されることを示唆しています。

6 結論

この記事では、Octopus V2 などのモバイル エージェントと連携するように設計されたデバイス側のプランニング エージェントである Octo-planner を紹介します。

計画と行動実行を分離することで、専門性と適応性を高めます。私たちのアプローチは、38 億パラメータの LLM である Phi-3 Mini を微調整して、エッジ デバイス上でネイティブに実行できるようにし、ドメイン内テストで 97% の成功率を達成しました。計算要件を削減し、レイテンシーとバッテリー寿命を改善し、完全な再トレーニングを行わずにモデル機能をスケーリングするマルチ LoRA テクノロジーを実装しました。 Octo-planner は、データ プライバシー、遅延、オフライン機能などの AI 導入の問題の解決に貢献します。これは、パーソナルデバイス向けの実用的で洗練された AI エージェントへの進歩を表しています。

モデルの重みをオープンソース化することで、オンデバイス AI のイノベーションを推進し、パフォーマンスやセキュリティを犠牲にすることなく日常生活を向上させる、効率的でプライバシーを尊重したアプリケーションの開発を促進することを目指しています。

7. 制限と今後の取り組み

現在のモデルは特定の携帯電話の使用例では効果的に機能しますが、より広範な適用性に関しては制限があります。

リアルタイムのフィードバックに基づいて計画ステップとアクションの実行を交互に繰り返す ReAct のようなフレームワークとは異なり、私たちのモデルはすべての計画を事前に行います。この事前に計画されたアプローチは、単純なタスクを処理する場合にはより効率的ですが、実行中に条件が変化する可能性がある複雑なシナリオや予測不可能なシナリオでは適応性が低くなる可能性があります。

今後の作業は、動的環境への適応性を向上させるために、リアルタイムの観察に基づいた反復的な計画手法の探索に焦点を当てます。また、モノのインターネット、ロボティクス、スマート ホーム システムなど、モバイル アプリケーションを超えてその機能を拡張するために、計画モデルをさまざまなアクション モデルと統合することも検討する予定です。これらの進歩により、現在の制限に対処し、オンデバイス プランニング モデルの多機能性を拡張し、効率的でローカライズされた AI 処理と複雑な現実世界のニーズとの間のギャップを埋めることができます。

以上が現場で最大97%の精度を実現するエンドサイドデバイス向けAIエージェント最適化フレームワークをリリース。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。