ToolSpectrum: Towards Personalized Tool Utilization for Large Language Models

生成日: 2026-05-24 02:20

# ToolSpectrum: Towards Personalized Tool Utilization for Large Language Models

- LLM が外部ツールを呼び出す際、機能だけでなく、ユーザープロファイル、環境、アプリのポリシーを合わせて考慮できるかを問うベンチマークである。
- ToolSpectrum は 9 ドメイン、23 アプリ、42 API からなり、Profile、Environment、Profile & Environment の三つの設定で評価する。
- 主要モデルでも、ユーザー条件と環境条件を同時に扱う場面では性能が大きく落ち、とくに optional parameters の選択が弱い。

## Abstract（日本語訳）

外部ツールを大規模言語モデル（LLM）に統合することは、リアルタイム情報やドメイン固有サービスへアクセスする能力を高める。しかし既存の手法は、ユーザー指示に従って機能的に適切なツールを選ぶことに狭く焦点を当てており、ツール選択における文脈に応じたパーソナライゼーションを見落としている。この見落としは、特に重なり合うツール群の中から文脈要因に基づいて細かな選択を行う必要がある場合に、ユーザー満足度の低下と非効率なツール利用をもたらす。このギャップを埋めるため、本論文では、パーソナライズされたツール利用に関する LLM の能力を評価するためのベンチマーク ToolSpectrum を導入する。具体的には、パーソナライゼーションの二つの主要な次元であるユーザープロファイルと環境要因を定式化し、それぞれ単独の影響と相乗的な影響を分析する。ToolSpectrum に対する広範な実験を通じて、パーソナライズされたツール選択が多様なシナリオでユーザー体験を大きく改善することを示す。しかし、最先端の LLM であっても、ユーザープロファイルと環境要因を統合して推論する能力には限界があり、一方の次元を他方の犠牲にして優先しがちである。本論文の知見は、ツール拡張 LLM における文脈に応じたパーソナライゼーションの必要性を示すとともに、現在のモデルの重要な限界を明らかにする。データとコードは近日公開予定である。

## 論文の面白いところ

この論文は、ツール利用を「正しい API を選ぶ」問題だけとして扱わない。現実のエージェントでは、同じ目的を満たすツールが複数あり、どれがよいかはユーザーや状況によって変わる。たとえば移動手段の予約では、飛行機、列車、タクシー、ホテル予約などの API があり、さらに年齢、予算、天候、アプリの利用規約が選択に関わる。通常の tool learning ベンチマークは、指示を満たすための機能選択や実行形式を主に見る。ToolSpectrum はそこに、ユーザープロファイルと環境という条件を入れ、ツール呼び出しの妥当性をより生活場面に近づけている。面白いのは、強いモデルでも「条件を一つずつ見る」ことは比較的できるが、「複数条件の衝突を処理する」段階で大きく崩れる点である。これは、アプリ操作型エージェントを実用に近づける際に、単なる API 呼び出し精度だけでは評価が足りないことを示している。論文の主張は派手ではないが、ツールを使う LLM の評価設計として素直で使いやすい。

## 問題設定

対象となる問題は、LLM がユーザー指示、ユーザープロファイル、環境情報、ツール集合を受け取り、最も適切なツール呼び出しを返すことである。出力は、アプリ名、API 名、required parameters、optional parameters を含む構造化された辞書として定義される。required parameters は、出発地や目的地のように、ユーザー指示から直接抽出される必須引数である。optional parameters は、座席種別、価格帯、画像品質など、プロファイルや環境から決まるパーソナライズ用の引数である。さらに、ユーザーの指示がアプリのポリシーに反する場合、モデルはツール呼び出しを返さず None を返す必要がある。これは通常の分類や API 選択より難しい。モデルは、ユーザーの目的を理解し、似た機能をもつツールを比較し、条件を引数へ写し、場合によっては実行しない判断もしなければならない。評価は APP、API、RP、OP の四つの粒度で F1 を計算し、どの段階で失敗するかを分けて見る。

## 提案手法

ToolSpectrum は、ショッピング、エンターテインメント、旅行、配送、食料品、知識、ニュース、健康、金融の 9 ドメインから作られている。著者らは App Store や Google Play の利用場面を参考にし、GPT-4o で初期的なアプリと API の設計を生成した後、人手で整理している。ツール集合には 23 アプリと 42 API が含まれ、Amazon と Temu、Ctrip の列車予約と航空券予約のように、機能が重なる候補も置かれる。ユーザープロファイルは、年齢、身長、職業、収入などの demographics、興味や性格に関する自然文、アプリ利用や購買の嗜好からなる。環境は、天候、時刻、場所、ネットワーク状態、端末条件、アプリのドメインポリシーを含む。データは Profile、Environment、Profile & Environment の三つに分けられ、それぞれ 450、220、330 サンプルがある。生成したプロファイルとツール呼び出し結果は、GPT-4o によるスコアリングと人手確認で品質管理され、平均点が低いものは除外される。最終的な評価では、GPT-4o、Claude 3.5 Sonnet、o1-mini、DeepSeek 系、Qwen 系、LLaMA 系などを同じ形式で比較する。

## 結果

主結果では、閉じた API 型モデルが多くの指標でオープンモデルを上回るが、差は一様ではない。GPT-4o と DeepSeek-R1 は全体として高い性能を示すものの、Profile & Environment 設定の OP ではそれぞれ 0.45 と 0.50 にとどまる。APP や API のような粗い粒度では比較的よく当たるが、optional parameters のように個別条件を引数へ落とす段階で性能が下がる。Profile 単独、Environment 単独より、両方を同時に使う Profile & Environment の設定で大きく悪化することも明確である。これは、条件が増えると、モデルが一方を優先し、もう一方を見落とすためと説明されている。モデルサイズを大きくしても単純には解決しない。たとえば Qwen2.5-72B-Instruct は Qwen2.5-32B-Instruct に比べて大きな改善を示さない。エラー分析では、GPT-4o の誤りの 37% がパーソナライズ特徴と optional parameters の対応理解不足、31% がプロファイルと環境の関係理解不足、22% がユーザー指示の誤解と分類されている。追加実験では、Chain-of-Thought や階層的プロンプトが一部の指標を改善するが、複合条件下の弱さは残る。

## 具体例

たとえば、15 歳の学生が「北京から西安までの航空券を予約してほしい」と依頼したとする。ユーザープロファイルには、収入が限られ、安い選択肢を好むことが書かれている。環境には、当日の天候が雷雨であることと、未成年は保護者の同意なしに長距離移動のチケットを購入できないというドメインポリシーがある。このとき、単に指示だけを見るモデルは Ctrip の bookTicket API を選び、移動手段を flight、座席を economy class として呼び出すかもしれない。天候だけを見るなら、飛行機ではなく列車を選ぶ判断もありうる。しかしプロファイルとポリシーまで含めるなら、期待される出力はチケット予約の実行ではなく、APP、API、params を null にすることである。モデルが間違えやすいのは、予算だけに反応して economy class を選ぶ、または雷雨だけに反応して train を選ぶ場合である。ToolSpectrum は、このような「一見もっともらしいが、条件の一部を落としている」ツール呼び出しを測るための評価である。

ToolSpectrum: Towards Personalized Tool Utilization for Large Language Models

LLM が外部ツールを呼び出す際、機能だけでなく、ユーザープロファイル、環境、アプリのポリシーを合わせて考慮できるかを問うベンチマークである。
ToolSpectrum は 9 ドメイン、23 アプリ、42 API からなり、Profile、Environment、Profile & Environment の三つの設定で評価する。
主要モデルでも、ユーザー条件と環境条件を同時に扱う場面では性能が大きく落ち、とくに optional parameters の選択が弱い。

Abstract（日本語訳）

外部ツールを大規模言語モデル（LLM）に統合することは、リアルタイム情報やドメイン固有サービスへアクセスする能力を高める。しかし既存の手法は、ユーザー指示に従って機能的に適切なツールを選ぶことに狭く焦点を当てており、ツール選択における文脈に応じたパーソナライゼーションを見落としている。この見落としは、特に重なり合うツール群の中から文脈要因に基づいて細かな選択を行う必要がある場合に、ユーザー満足度の低下と非効率なツール利用をもたらす。このギャップを埋めるため、本論文では、パーソナライズされたツール利用に関する LLM の能力を評価するためのベンチマーク ToolSpectrum を導入する。具体的には、パーソナライゼーションの二つの主要な次元であるユーザープロファイルと環境要因を定式化し、それぞれ単独の影響と相乗的な影響を分析する。ToolSpectrum に対する広範な実験を通じて、パーソナライズされたツール選択が多様なシナリオでユーザー体験を大きく改善することを示す。しかし、最先端の LLM であっても、ユーザープロファイルと環境要因を統合して推論する能力には限界があり、一方の次元を他方の犠牲にして優先しがちである。本論文の知見は、ツール拡張 LLM における文脈に応じたパーソナライゼーションの必要性を示すとともに、現在のモデルの重要な限界を明らかにする。データとコードは近日公開予定である。

論文の面白いところ

この論文は、ツール利用を「正しい API を選ぶ」問題だけとして扱わない。現実のエージェントでは、同じ目的を満たすツールが複数あり、どれがよいかはユーザーや状況によって変わる。たとえば移動手段の予約では、飛行機、列車、タクシー、ホテル予約などの API があり、さらに年齢、予算、天候、アプリの利用規約が選択に関わる。通常の tool learning ベンチマークは、指示を満たすための機能選択や実行形式を主に見る。ToolSpectrum はそこに、ユーザープロファイルと環境という条件を入れ、ツール呼び出しの妥当性をより生活場面に近づけている。面白いのは、強いモデルでも「条件を一つずつ見る」ことは比較的できるが、「複数条件の衝突を処理する」段階で大きく崩れる点である。これは、アプリ操作型エージェントを実用に近づける際に、単なる API 呼び出し精度だけでは評価が足りないことを示している。論文の主張は派手ではないが、ツールを使う LLM の評価設計として素直で使いやすい。

問題設定

対象となる問題は、LLM がユーザー指示、ユーザープロファイル、環境情報、ツール集合を受け取り、最も適切なツール呼び出しを返すことである。出力は、アプリ名、API 名、required parameters、optional parameters を含む構造化された辞書として定義される。required parameters は、出発地や目的地のように、ユーザー指示から直接抽出される必須引数である。optional parameters は、座席種別、価格帯、画像品質など、プロファイルや環境から決まるパーソナライズ用の引数である。さらに、ユーザーの指示がアプリのポリシーに反する場合、モデルはツール呼び出しを返さず None を返す必要がある。これは通常の分類や API 選択より難しい。モデルは、ユーザーの目的を理解し、似た機能をもつツールを比較し、条件を引数へ写し、場合によっては実行しない判断もしなければならない。評価は APP、API、RP、OP の四つの粒度で F1 を計算し、どの段階で失敗するかを分けて見る。

提案手法

ToolSpectrum は、ショッピング、エンターテインメント、旅行、配送、食料品、知識、ニュース、健康、金融の 9 ドメインから作られている。著者らは App Store や Google Play の利用場面を参考にし、GPT-4o で初期的なアプリと API の設計を生成した後、人手で整理している。ツール集合には 23 アプリと 42 API が含まれ、Amazon と Temu、Ctrip の列車予約と航空券予約のように、機能が重なる候補も置かれる。ユーザープロファイルは、年齢、身長、職業、収入などの demographics、興味や性格に関する自然文、アプリ利用や購買の嗜好からなる。環境は、天候、時刻、場所、ネットワーク状態、端末条件、アプリのドメインポリシーを含む。データは Profile、Environment、Profile & Environment の三つに分けられ、それぞれ 450、220、330 サンプルがある。生成したプロファイルとツール呼び出し結果は、GPT-4o によるスコアリングと人手確認で品質管理され、平均点が低いものは除外される。最終的な評価では、GPT-4o、Claude 3.5 Sonnet、o1-mini、DeepSeek 系、Qwen 系、LLaMA 系などを同じ形式で比較する。

結果

主結果では、閉じた API 型モデルが多くの指標でオープンモデルを上回るが、差は一様ではない。GPT-4o と DeepSeek-R1 は全体として高い性能を示すものの、Profile & Environment 設定の OP ではそれぞれ 0.45 と 0.50 にとどまる。APP や API のような粗い粒度では比較的よく当たるが、optional parameters のように個別条件を引数へ落とす段階で性能が下がる。Profile 単独、Environment 単独より、両方を同時に使う Profile & Environment の設定で大きく悪化することも明確である。これは、条件が増えると、モデルが一方を優先し、もう一方を見落とすためと説明されている。モデルサイズを大きくしても単純には解決しない。たとえば Qwen2.5-72B-Instruct は Qwen2.5-32B-Instruct に比べて大きな改善を示さない。エラー分析では、GPT-4o の誤りの 37% がパーソナライズ特徴と optional parameters の対応理解不足、31% がプロファイルと環境の関係理解不足、22% がユーザー指示の誤解と分類されている。追加実験では、Chain-of-Thought や階層的プロンプトが一部の指標を改善するが、複合条件下の弱さは残る。

具体例

たとえば、15 歳の学生が「北京から西安までの航空券を予約してほしい」と依頼したとする。ユーザープロファイルには、収入が限られ、安い選択肢を好むことが書かれている。環境には、当日の天候が雷雨であることと、未成年は保護者の同意なしに長距離移動のチケットを購入できないというドメインポリシーがある。このとき、単に指示だけを見るモデルは Ctrip の bookTicket API を選び、移動手段を flight、座席を economy class として呼び出すかもしれない。天候だけを見るなら、飛行機ではなく列車を選ぶ判断もありうる。しかしプロファイルとポリシーまで含めるなら、期待される出力はチケット予約の実行ではなく、APP、API、params を null にすることである。モデルが間違えやすいのは、予算だけに反応して economy class を選ぶ、または雷雨だけに反応して train を選ぶ場合である。ToolSpectrum は、このような「一見もっともらしいが、条件の一部を落としている」ツール呼び出しを測るための評価である。