ローカルLLMによるツールコール:実践的評価

ツールコールにはどのローカルモデルを使用すべきですか?

GenAIやエージェントアプリケーションを構築する際、最も切迫した永続的な問題の1つは 、「ツールコールにはどのローカルモデルを使用すべきか」です。 Docker の同僚や開発者コミュニティから、開発者がローカルモデルを実行し、実験するのに役立つローカル推論エンジンである Docker Model Runner に取り組み始めて以来、何度も何度も声を聞き続けました。 

これは一見単純な質問ですが、驚くほど微妙な答えが返ってきます。非常に特殊なケースで答えを出そうとしたときでさえ 、「単純なツールをモデルに公開したらどうなるか」 5 。
それに対する明確な答えがないことに気づきました。ローカルLLMモデルは 、制御、コスト効率、プライバシーを提供しますが、構造化されたツールの使用に関しては、いつ、どのように行動するかを決定すると、非常に異なる動作をする可能性があります。私たちは深く掘り下げて、これをきちんとテストすることにしました。まずは手動の実験から始めて、テストをスケールするためのフレームワークを構築しました。このブログでは、その旅を記録し、ツールコールのリーダーボードで上位にランクされたモデルを共有します。

最初の試み:手動テスト

私たちの最初の直感は、何かをすばやく作成して手動で試してみることでした。

そこで、AI を活用したショッピング アシスタントである Chat2Cart を作成しました。これは、ユーザーがチャットを介して対話し、ショッピング カートを作成、変更、チェックアウトできるものです。自然な会話を通じて、ユーザーはチャットインターフェースから製品の検索、アイテムの追加や削除、購入の完了やキャンセルを行うことができます。

異なる LLM 間でのテストをサポートするために、ローカル モデル (Docker Model Runner または Ollama 経由) と OpenAI API を使用してホストされたモデルを簡単に切り替えることができるモデル セレクターを追加しました。

OpenAIのGPT-4 またはGPT-3。5期待どおりに動作し、経験はかなりスムーズでした。 

• 必要なときにツールを呼び出す
• 不必要なツールの使用を回避
• ツールの応答を自然に処理

しかし、ローカルモデルは?そこで課題が表面化し始めました。

ローカルモデルの不具合

私たちは、Berkeley Function-Calling Leaderboardにリストされているいくつかのローカルモデルで実験を開始しました。私たちの目標は、理想的には 10 億個未満のパラメータを持つ、より小さなモデルを見つけることだったため、xLAM-2-8b-fc-r と watt-tool-8B をテストしました。私たちはすぐにいくつかの繰り返し発生する問題に遭遇しました。

• 熱心な呼び出し:「こんにちは!」のような挨拶メッセージのためにさえツールが呼び出されていました。
• ツールの選択が間違っている: モデルは、カートが空のときに追加すべきときに検索したり、削除しようとしたりします
• 無効な引数: product_name や quantity などのパラメーターが欠落しているか、形式が正しくありません
• 無視された応答: モデルはツールの出力に応答しないことが多く、会話がぎこちなかったり、不完全であったりしました
  

この時点で、手動テストでは拡張性がないことは明らかでした。モデルが異なれば失敗の仕方も異なり、呼び出しロジックに苦労するモデルもあれば、ツールの引数や応答を誤って処理するモデルもありました。テストは遅いだけでなく、信頼性も低かった。これらのモデルは非決定論的であるため、動作の信頼性の高い読み取りを得るためだけに、各シナリオを複数回実行する必要がありました。

再現性があり、測定可能で、高速なテストセットアップが必要でした。

2つ目の試み:スケーラブルなテストツール

私たちの目標は、学問的な厳密さではありませんでした。
それは、「2で十分な答えを出してください。数週間ではなく、3日です」というものでした。

数日で、モデルテストを作成しました、これは次の機能を備えた柔軟なプロジェクトです

• 複数の有効なツールコールシーケンスを持つ実際の テストケース を定義
• 多くのモデル(ローカルおよびホスト型)に対して実行します
• ツールコールの精度、ツールの選択、レイテンシの追跡
• 分析(または最終的な微調整)のために すべてを ログに記録する

仕組み

モデルテストの核となる考え方はシンプルで、ツールを使ったリアルな会話をシミュレートし、モデルに推論と行動の余地を与え、その動作が理にかなっているかどうかを確認することです。

各テストケースには、次のものが含まれます。

• プロンプト (例:「iPhoneをカートに入れる」)
• カートの初期状態 (オプション)
• 1 つ以上の 有効なツール呼び出しバリアント (多くの場合、複数の正解があるため)
  

一般的なケースを次に示します。

{
  "prompt": "Add iPhone to cart",
  "expected_tools_variants": [
    {
      "name": "direct_add",
      "tools": [{ "name": "add_to_cart", "arguments": { "product_name": "iPhone" } }]
    },
    {
      "name": "search_then_add",
      "tools": [
        { "name": "search_products", "arguments": { "query": "iPhone" } },
        { "name": "add_to_cart", "arguments": { "product_name": "iPhone 15" } }
      ]
    }
  ]
}

この場合、「 単に「iPhone」を追加するだけ」 と 「最初に検索してから結果を追加する」 の両方を許容できると考えます。「iPhone」は実際の製品名ではありませんが、私たちはそれで問題ありません。厳密すぎる精度を目指したのではなく、現実的な振る舞いを目指しました。

各テストケースは、テストスイートに属します。2つのビルトインスイートを提供しています。ただし、スイート全体、個々のテスト ケース、または複数のテスト ケースの選択を実行できます。さらに、必要に応じてテストをグループ化するための独自のカスタムスイートを作成することもできます。 

• シンプル: グリーティング、ワンステップアクション
  
• 複雑:マルチステップ推論とツールチェーン

エージェントループ

テストを実際のエージェントの動作に近づけるために、最大 5 ラウンドのエージェント ループをシミュレートします。

例：

ユーザー: 「iPhone 5 をカートに追加して」

1. モデル: 「iPhoneの 5を検索させてください...」
   
   1. ツール: (返品商品リスト)
      
2. モデル: 「商品Xをカートに追加しています...」
   
   1. ツール: (カートを更新)
      
3. モデル: 「完了」
   → よかった、テストに合格しました!
   

しかし、モデルがラウンド 5後も続けたい場合は?

これで完了です、私の友人、 テストは失敗しました。時間切れです。

オール・オア・ナッシングではない

私たちは、完璧な予測を必要とするテストの設計を意図的に避けました。

• モデルが常に正確な製品名を知っていることを要求したわけではありません。
• 重要なのは、 ツールシーケンスが意図に対して理にかなっているかどうか でした。

これにより、トークンの完全一致だけでなく、エージェントに実際に求める推論や行動の種類に焦点を当てることができました。

測定した内容

私たちのテスト出力は、最終的なF1 スコアまで抽出され、次の3つのコアディメンションがカプセル化されています。

F1 スコアは、精度 (モデルが有効なツール呼び出しを行った頻度) と再現率 (想定されたツール呼び出しを行った頻度) の 2 つの調和平均です。

また、レイテンシ (秒単位の平均実行時間) も追跡しましたが、これは F1 の計算には含まれていませんでした。これは、速度とユーザーエクスペリエンスを評価するのに役立っただけです。

モデルと321、後でテスト570:どのモデルがツールコールを釘付けにしましたか?

210バッチ実行を使用して、3570つのテストケースで21モデルをテストしました。

ハードウェア:MacBook Pro M4 Max、 128GB RAM
ランナー: test-all-models.sh

総合ランキング(ツールセレクションF1別):

トップパフォーマー

全モデルの中で、OpenAIのGPT-4 は、ツール選択F1 スコア 0でトップに立った。974、平均 5 秒未満で応答を完了します。ホストされており、ローカルモデル探索の焦点ではありませんが、信頼できるベンチマークとして機能し、いくつかのグラウンドトゥルースを提供しました。

ローカル側では、Qwen 3 (14B)がGPT-4 と 0にほぼ匹敵する優れた結果をもたらしました。971F1 スコアですが、レイテンシーが大幅に長くなります (インタラクションあたり ~142 秒)。

より速いものを探しているなら、Qwen 3 (8B) も F1 スコア 0を達成しました。933、レイテンシーをほぼ半分(~84 秒)に短縮し、速度とツール使用精度の魅力的なバランスを実現しています。

Claude 3 Haikuのようなホストモデルも非常に好成績を収め、 0を打った。933並外れた速度で1 F(3.56秒平均レイテンシー)、クラウドベースのオファリングによって設定される高いハードルをさらに示しています。

アンダーパフォーマー

すべてのモデルがツールコールをうまく処理したわけではありません。量子化されたワット 8Bモデルは、パラメータの精度に苦労し、ツール選択F1 スコアはわずか 0に終わりました。484。同様に、LLaMAベースのXLam 8Bバリアントは、正しいツールパスを完全に見逃すことがよくあり、F1 スコアは 0でした。570。これらのモデルは他のタスクに適しているかもしれませんが、構造化されたツールの使用テストでは、期待に応えられません。

量子化

また、一部のモデルでは 、量子化された バリアントと 非量子化された バリアントの両方で実験を行いましたが、いずれの場合も、ツール呼び出しの動作やパフォーマンスに 有意差は見られませんでした 。これは、少なくともテストしたモデルとシナリオでは、精度や推論の品質に悪影響を与えることなく、リソース使用量を削減するために量子化が有益であることを示唆しています。

私たちの推奨事項

ツールコールの精度を最大限に高めることが目標であれば、Qwen 3 (14B) または Qwen 3 (8B) が最善の策であり、どちらもローカルで正確であり、 8B バリアントは著しく高速です。

速度とパフォーマンスをうまくトレードオフするために、Qwen 2.5 堅実なオプションとして際立っていました。リアルタイムのエクスペリエンスをサポートするのに十分な速度でありながら、適切なツール選択精度を維持しています。

特にリソースに制約のある環境で、より軽量なものが必要な場合、 LLaMA 3 Groq 7B バリアントは、はるかに低いコンピューティング フットプリントで適度なパフォーマンスを提供します。

私たちが学んだこととこれが重要な理由

私たちのテストでは、Qwenファミリーのモデルが、ツールコールのオープンソースオプションの中で群を抜いていることを確認しました。しかし、いつものように、トレードオフがあります。アプリケーションを設計する際には、精度とレイテンシのバランスを取る必要があります

• Qwenモデルが圧倒的多数:Qwenの8Bバージョンでさえ、他のどのローカルモデルよりも優れたパフォーマンス3
  
• 推論 = レイテンシ: 精度の高いモデルほど時間がかかり、多くの場合、大幅に時間がかかります。

ツールコールは、ほぼすべての現実世界のGenAIアプリケーションの中核をなすものです。エージェントを構築する場合でも、エージェントのワークフローを作成する場合でも、LLMはいつどのように行動すべきかを把握する必要があります。このシンプルなフレームワークのおかげで、「どのモデルを選ぶべきかわからない」が「3つの優れたオプションに絞り込み、それぞれに明確な長所と短所がある」になりました。

エージェントアプリケーションのモデルを評価している場合は、当て推量をスキップしてください。 model-test を試して、テスト用に自分だけのものにしてください! 

さらに詳しく

• Docker Model Runner の設計アーキテクチャの内部をご覧ください。 
• モデル分散仕様の背後にある ストーリー をご覧ください
• Docker Model Runner のクイックスタートガイドをお読みください。
• Model Runner のドキュメントが見つかります。
• Docker Navigator ニュースレターを購読してください。
• Docker は初めてですか? アカウントを作成します。 
• ご質問はございますか? Docker コミュニティがお手伝いします。