ToolHop: A Query-Driven Benchmark for Evaluating Large Language Models in Multi-Hop Tool Use

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

# ToolHop: A Query-Driven Benchmark for Evaluating Large Language Models in Multi-Hop Tool Use

- ToolHop は、LLM の multi-hop tool use を調べるためのベンチマークである。995 件のユーザークエリと、ローカルで実行できる 3,912 個のツールから成る。
- 既存の tool-use 評価は、先にツールを集めてからクエリを作ることが多く、ツール間の依存関係や最終回答の検証が弱かった。本論文は、クエリを先に置き、そこから必要なツール、説明文、実行コードを作る。
- 14 種の LLM を評価した結果、ツール利用は平均で正答率を上げたが、最良の GPT-4o でも mandatory tool use 条件の正答率は 49.04% にとどまった。複数のツールを順に使う場面は、なお難しい。

## Abstract（日本語訳）

multi-hop tool use の有効な評価は、大規模言語モデル（LLM）の理解、推論、function calling の能力を分析するうえで重要である。しかし、信頼できる評価データセットが不足しているため、この方向の進展は妨げられてきた。これに対して本論文は、multi-hop tool use を厳密に評価するために設計された、995 件のユーザークエリと 3,912 個の関連ツールから成るデータセット ToolHop を提示する。ToolHop は、ツール作成、文書の精緻化、コード生成を含む新しい query-driven なデータ構築手法により、多様なクエリ、有意味な相互依存関係、ローカルで実行可能なツール、詳細なフィードバック、検証可能な回答を備える。著者らは、LLaMA3.1、Qwen2.5、Gemini1.5、Claude3.5、GPT の 5 つのモデルファミリーに属する 14 種の LLM を評価し、multi-hop tool-use シナリオの処理に大きな課題があることを明らかにした。最も高い性能を示した GPT-4o の正答率は 49.04% であり、改善の余地が大きいことを示している。さらに分析により、モデルファミリーごとに tool-use 戦略の違いがあることが示され、より有効な手法の開発に向けた実用的な知見が得られた。コードとデータは https://huggingface.co/datasets/bytedance-research/ToolHop で公開されている。

## 論文の面白いところ

この論文の焦点は、LLM が「ツールを呼べるか」ではなく、「前のツールの出力を次のツールの入力として使い、最後まで破綻せず進められるか」にある。単発の API 呼び出しなら、現在のモデルでもかなり整って見える。しかし、発明者を調べ、生年月日を取り、その日付の曜日を求めるような問題では、途中の答えを正しく保持し、次の呼び出しに渡さなければならない。ToolHop はこの連鎖を評価するため、クエリから出発して必要なツールを作る設計を取る。これにより、ツール同士の依存関係が問題の構造に沿いやすくなる。

面白いのは、評価対象が単なる最終正答だけではない点である。ツールがローカルで実行できるため、存在しないツールを呼んだのか、存在しない引数を渡したのか、必須引数を落としたのかを区別できる。これは agent や function calling の実装を改善する際に扱いやすい情報である。さらに、GPT 系モデルは詳細なエラーフィードバックを受けると呼び出しを修正しやすいが、単に失敗とだけ返されると正答率が下がる。モデル単体の能力だけでなく、ツール側がどのような失敗情報を返すべきかにも示唆がある。

## 問題設定

multi-hop tool use では、ユーザーの複合的な質問をいくつかの部分問題に分け、それぞれに適したツールを順に呼び出す。各ツールの出力は、次のツール呼び出しの入力になる。したがって、モデルは質問文の理解、手順の分解、関数仕様の読解、引数の生成、返り値の解釈を続けて行う必要がある。既存の tool-use ベンチマークには、ツールを集めてから質問を作るものが多い。この作り方では、ツール間に自然な依存関係が生じにくく、multi-hop な推論を十分に測れない。

また、最終回答があらかじめ検証可能でない場合、評価は別のモデルによる判定や人手確認に寄りやすい。これは評価のばらつきやモデル依存を生む。ToolHop は、MoreHopQA のように少なくとも 3 つの atomic query に分解できる質問を土台にし、995 件の multi-hop クエリを作る。各クエリには 3 個から 7 個のツールが対応し、合計 3,912 個のツールが用意される。評価は、ツールを使わず直接答える条件、ツール利用を必須にする条件、ツールを任意で使える条件で行われる。

## 提案手法

ToolHop の構築は query-driven data construction と呼ばれる。まず multi-hop クエリを atomic subquery に分け、各部分問題に必要なツールの草案を作る。次に document refinement によって、ツール説明を詳しくし、引数の数や型をより現実の API に近づける。単純な string 引数だけでなく、array や object などの構造化された型も増やす。これにより、モデルはツール名だけでなく、説明文と引数仕様を読んで適切に呼び出す必要がある。

最後に、各ツール説明からローカル実行可能な関数コードを生成する。生成時には atomic query とその答えを使い、正しい入力には正しい出力を返すようにする。誤った入力や不完全な引数に対しては、例外処理により具体的なエラーメッセージを返す。この設計により、評価側は関数呼び出しを実際に走らせ、モデルの出力を機械的に検査できる。ToolHop は、クエリの多様性、有意味なツール間依存、ローカル実行、詳細なフィードバック、検証可能な回答を同時に満たすことを目標にしている。

## 結果

実験では、LLaMA3.1、Qwen2.5、Gemini1.5、Claude3.5、GPT の 5 ファミリーから 14 モデルを評価した。mandatory tool use 条件では、ツール利用により平均正答率が direct answer 条件より 12.29 ポイント上がった。GPT 系ではこの上昇が平均 23.59 ポイントと大きい。一方で、最良の GPT-4o でも正答率は 49.04% であり、multi-hop なツール利用はまだ安定していない。GPT-4o でも 9.45% のクエリに呼び出し上の幻覚が見られた。

モデルファミリーごとの違いも明確である。Qwen2.5 の一部モデルは並列ツール呼び出しを多く行い、前段の結果を待たずに後段の引数を埋めるため、誤った値を使いやすい。Claude3.5 は direct answer 条件で段階的推論を自発的に行いやすく、ツールの失敗を内部知識で補う場合がある。GPT 系は、詳細なエラーフィードバックが与えられると呼び出しを修正して正答に近づく傾向を示した。特に、呼び出しエラーを含むクエリでは、GPT-4o の正答率が詳細フィードバックありで 47.87%、単純な失敗通知のみで 24.47% となった。

## 具体例

たとえば、ユーザーが「Richard Hornsby & Sons の石油エンジンを開発した英国の発明家の生年月日は何曜日か」と尋ねる場面を考える。この質問に答えるには、まず発明と会社名から発明家を調べるツールを呼び、Herbert Akroyd Stuart という中間結果を得る。次に、その人物の生年月日を調べるツールに名前を渡し、28 January 1864 を得る。最後に、日付から曜日を計算するツールを呼び、Thursday という答えを出す。

ここで難しいのは、各段階の答えが次の段階の引数になることである。モデルが最初の人物名を取り違えると、以後の呼び出しは形として正しくても最終回答は誤る。また、日付を文字列として渡すべきところに別の型で渡したり、存在しない引数名を使ったりしても失敗する。ToolHop では、こうした失敗をツール実行時に検出し、単なる不正解ではなく呼び出しエラーとして扱う。このため、どのモデルが質問の分解に弱いのか、どのモデルが関数仕様の読解に弱いのかを分けて見やすい。

ToolHop: A Query-Driven Benchmark for Evaluating Large Language Models in Multi-Hop Tool Use

ToolHop は、LLM の multi-hop tool use を調べるためのベンチマークである。995 件のユーザークエリと、ローカルで実行できる 3,912 個のツールから成る。
既存の tool-use 評価は、先にツールを集めてからクエリを作ることが多く、ツール間の依存関係や最終回答の検証が弱かった。本論文は、クエリを先に置き、そこから必要なツール、説明文、実行コードを作る。
14 種の LLM を評価した結果、ツール利用は平均で正答率を上げたが、最良の GPT-4o でも mandatory tool use 条件の正答率は 49.04% にとどまった。複数のツールを順に使う場面は、なお難しい。

Abstract（日本語訳）

multi-hop tool use の有効な評価は、大規模言語モデル（LLM）の理解、推論、function calling の能力を分析するうえで重要である。しかし、信頼できる評価データセットが不足しているため、この方向の進展は妨げられてきた。これに対して本論文は、multi-hop tool use を厳密に評価するために設計された、995 件のユーザークエリと 3,912 個の関連ツールから成るデータセット ToolHop を提示する。ToolHop は、ツール作成、文書の精緻化、コード生成を含む新しい query-driven なデータ構築手法により、多様なクエリ、有意味な相互依存関係、ローカルで実行可能なツール、詳細なフィードバック、検証可能な回答を備える。著者らは、LLaMA3.1、Qwen2.5、Gemini1.5、Claude3.5、GPT の 5 つのモデルファミリーに属する 14 種の LLM を評価し、multi-hop tool-use シナリオの処理に大きな課題があることを明らかにした。最も高い性能を示した GPT-4o の正答率は 49.04% であり、改善の余地が大きいことを示している。さらに分析により、モデルファミリーごとに tool-use 戦略の違いがあることが示され、より有効な手法の開発に向けた実用的な知見が得られた。コードとデータは https://huggingface.co/datasets/bytedance-research/ToolHop で公開されている。

論文の面白いところ

この論文の焦点は、LLM が「ツールを呼べるか」ではなく、「前のツールの出力を次のツールの入力として使い、最後まで破綻せず進められるか」にある。単発の API 呼び出しなら、現在のモデルでもかなり整って見える。しかし、発明者を調べ、生年月日を取り、その日付の曜日を求めるような問題では、途中の答えを正しく保持し、次の呼び出しに渡さなければならない。ToolHop はこの連鎖を評価するため、クエリから出発して必要なツールを作る設計を取る。これにより、ツール同士の依存関係が問題の構造に沿いやすくなる。

面白いのは、評価対象が単なる最終正答だけではない点である。ツールがローカルで実行できるため、存在しないツールを呼んだのか、存在しない引数を渡したのか、必須引数を落としたのかを区別できる。これは agent や function calling の実装を改善する際に扱いやすい情報である。さらに、GPT 系モデルは詳細なエラーフィードバックを受けると呼び出しを修正しやすいが、単に失敗とだけ返されると正答率が下がる。モデル単体の能力だけでなく、ツール側がどのような失敗情報を返すべきかにも示唆がある。

問題設定

multi-hop tool use では、ユーザーの複合的な質問をいくつかの部分問題に分け、それぞれに適したツールを順に呼び出す。各ツールの出力は、次のツール呼び出しの入力になる。したがって、モデルは質問文の理解、手順の分解、関数仕様の読解、引数の生成、返り値の解釈を続けて行う必要がある。既存の tool-use ベンチマークには、ツールを集めてから質問を作るものが多い。この作り方では、ツール間に自然な依存関係が生じにくく、multi-hop な推論を十分に測れない。

また、最終回答があらかじめ検証可能でない場合、評価は別のモデルによる判定や人手確認に寄りやすい。これは評価のばらつきやモデル依存を生む。ToolHop は、MoreHopQA のように少なくとも 3 つの atomic query に分解できる質問を土台にし、995 件の multi-hop クエリを作る。各クエリには 3 個から 7 個のツールが対応し、合計 3,912 個のツールが用意される。評価は、ツールを使わず直接答える条件、ツール利用を必須にする条件、ツールを任意で使える条件で行われる。

提案手法

ToolHop の構築は query-driven data construction と呼ばれる。まず multi-hop クエリを atomic subquery に分け、各部分問題に必要なツールの草案を作る。次に document refinement によって、ツール説明を詳しくし、引数の数や型をより現実の API に近づける。単純な string 引数だけでなく、array や object などの構造化された型も増やす。これにより、モデルはツール名だけでなく、説明文と引数仕様を読んで適切に呼び出す必要がある。

最後に、各ツール説明からローカル実行可能な関数コードを生成する。生成時には atomic query とその答えを使い、正しい入力には正しい出力を返すようにする。誤った入力や不完全な引数に対しては、例外処理により具体的なエラーメッセージを返す。この設計により、評価側は関数呼び出しを実際に走らせ、モデルの出力を機械的に検査できる。ToolHop は、クエリの多様性、有意味なツール間依存、ローカル実行、詳細なフィードバック、検証可能な回答を同時に満たすことを目標にしている。

結果

実験では、LLaMA3.1、Qwen2.5、Gemini1.5、Claude3.5、GPT の 5 ファミリーから 14 モデルを評価した。mandatory tool use 条件では、ツール利用により平均正答率が direct answer 条件より 12.29 ポイント上がった。GPT 系ではこの上昇が平均 23.59 ポイントと大きい。一方で、最良の GPT-4o でも正答率は 49.04% であり、multi-hop なツール利用はまだ安定していない。GPT-4o でも 9.45% のクエリに呼び出し上の幻覚が見られた。

モデルファミリーごとの違いも明確である。Qwen2.5 の一部モデルは並列ツール呼び出しを多く行い、前段の結果を待たずに後段の引数を埋めるため、誤った値を使いやすい。Claude3.5 は direct answer 条件で段階的推論を自発的に行いやすく、ツールの失敗を内部知識で補う場合がある。GPT 系は、詳細なエラーフィードバックが与えられると呼び出しを修正して正答に近づく傾向を示した。特に、呼び出しエラーを含むクエリでは、GPT-4o の正答率が詳細フィードバックありで 47.87%、単純な失敗通知のみで 24.47% となった。

具体例

たとえば、ユーザーが「Richard Hornsby & Sons の石油エンジンを開発した英国の発明家の生年月日は何曜日か」と尋ねる場面を考える。この質問に答えるには、まず発明と会社名から発明家を調べるツールを呼び、Herbert Akroyd Stuart という中間結果を得る。次に、その人物の生年月日を調べるツールに名前を渡し、28 January 1864 を得る。最後に、日付から曜日を計算するツールを呼び、Thursday という答えを出す。

ここで難しいのは、各段階の答えが次の段階の引数になることである。モデルが最初の人物名を取り違えると、以後の呼び出しは形として正しくても最終回答は誤る。また、日付を文字列として渡すべきところに別の型で渡したり、存在しない引数名を使ったりしても失敗する。ToolHop では、こうした失敗をツール実行時に検出し、単なる不正解ではなく呼び出しエラーとして扱う。このため、どのモデルが質問の分解に弱いのか、どのモデルが関数仕様の読解に弱いのかを分けて見やすい。