ツール呼び出し対応のローカルLLMを評価する方法

ツール呼び出しへ対応したモデルを比べるとき、「1回ツールを呼べた」だけでは情報が足りない。

必要なツールを選べるか、正しい引数を作れるか、呼ぶ必要がない場面で余計な呼び出しをしないかを分けて評価する。

最初は副作用のない固定ツールを用意する

外部サービスやファイルを書き換えない、評価専用のツールを2〜3個用意する。

例として、

• get_weather_fixture(city) — 固定した天気JSONを返す
• lookup_document_fixture(id) — 固定した文章を返す
• calculator_fixture(a,b) — 計算結果を返す

といった形にできる。

実世界のAPI障害やデータ品質を、モデルの判断力へ混ぜないためだ。

4種類の試験を分ける

1. ツールの選択

質問に必要なツールを選べるかを見る。

2. 引数

必須項目、型、値が定義に合っているかを見る。

3. 不要な呼び出しと拒否

普通に回答できる質問でツールを呼ばないか、許可されていない操作を求められたときにどう振る舞うかを見る。

4. 複数段階の処理

一つ目の結果を読んで、次に使うツールを選ぶ処理は別に評価する。

モデルが出した呼び出し内容を保存する

最終点だけでなく、モデルが実際に出したツール名と引数を残す。

モデル / リビジョン:
実行環境 / バージョン:
質問:
利用可能なツール:
モデルが出した呼び出し:
検証結果:
期待したツール:
期待した引数:

モデルが正しい内容を出していても、アプリ側の定義が誤っていて検証に失敗したなら、モデルの失敗と同じ扱いにはしない。

外部ツールの実行成功をモデル単体の点数にしない

外部ツールの通信エラー、権限、外部データの品質はモデル以外の要因だ。評価では、呼び出し内容の生成と実際の実行を分ける。

安全な実行前検証の組み方は、ローカルLLMのツール呼び出しに実行前検証を入れる方法で整理している。モデル比較では、まずどのツールと引数を選んだかに集中すると原因を切り分けやすい。