エージェントは、与えられた検索ツールやナレッジベースを呼ばず、パラメトリックメモリから答えるとき、ツールをスキップしている。スキップされた呼び出しは速く、エラーを返さず、レイテンシダッシュボードでは緑で表示される。しかしそれは間違っている。モデルが根拠を取らずに当てずっぽうで答えたからだ。直し方は決定論的だ。すべてのツール呼び出しのトレースをログに残し、新しいデータが必要なクエリでツールが実際に呼ばれたかを検証し、呼び出しがなければ評価を失敗させる。
なぜレイテンシダッシュボードはスキップされた呼び出しを隠すのか
ツール呼び出しは往復時間を加える。POST /api/v1/google を叩き、結果を待ち、それをモデルに戻すには数百ミリ秒と1クレジットがかかる。エージェントがそれをスキップして重みから直接答えると、リクエストは速く安くなる。p50は下がる。エラー率はゼロのままだ。当てずっぽうはランタイムが見られるエラーではないからだ。
つまりダッシュボードは、あなたが気にする失敗そのものを報酬として扱う。検索を起動すべきだったのにしなかった事実クエリは、正当にツールを必要としなかった雑談ターンと見分けがつかない。レイテンシもエラー率もトークン数も両者を区別できない。必要なシグナルはツールが発火したかどうかで、それはメトリクスではなくトレースにある。
LLMジャッジではなく決定論的にツール利用を検証する
「エージェントはツールを呼んだか」という問いには、決定論的なチェックがLLMジャッジに勝る。ジャッジはまた別のモデルで、ハルシネーションを起こしうるし、トークンを消費し、遅い。だがあなたは既に真実を持っている。ツール呼び出しのトレースだ。検索ツールへの呼び出しがトレースにあるか、ないか。それを検証する。
より強いチェックは2つの部分から成る。第一に、ツールが呼ばれたことを検証する。第二に、最終的な回答がツールの返したものを実際に参照していることを検証する。これでエージェントはツールを呼んでおきながら無視することができなくなる。ScavioのGoogleエンドポイントは実URL付きの organic 結果を返すので、回答がそのうちの一つを引用しているか確認できる。
import requests
API_KEY = "sk-your-key"
def search(query):
r = requests.post(
"https://api.scavio.dev/api/v1/google",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"query": query, "light_request": False},
)
r.raise_for_status()
return r.json()
def assert_grounded(query, agent_answer, tool_calls):
# 1) 決定論的: 検索ツールが実際に呼ばれた
assert any(c["name"] == "search" for c in tool_calls), \
f"agent skipped search for fact query: {query!r}"
# 2) 決定論的: 回答がツールの返したURLを引用している
results = search(query)
returned_urls = [item["link"] for item in results.get("organic", [])]
assert any(url in agent_answer for url in returned_urls), \
"answer does not reference any retrieved source"
# 評価ケースの例
assert_grounded(
query="latest stable python release",
agent_answer="Python 3.13 is current. Source: https://www.python.org/downloads/",
tool_calls=[{"name": "search", "args": {"query": "latest stable python release"}}],
)ループの中にモデルはいない。チェックは、あなたが見られる事実に対して通るか落ちるかだ。
事実クエリにはグラウンディングを強制する
スキップされた呼び出しを事後に検出するのは評価には良い。本番で防ぐ方がもっと良い。新しいデータが必要だと分かっているクエリには、モデルの判断に任せず検索呼び出しを強制する。
ほとんどのエージェントフレームワークは tool_choice を公開している。事実クエリの経路ではこれを required に設定する(または検索ツールを明示的に指定する)ことで、モデルは応答する前に POST /api/v1/google を叩き、実際のオーガニック結果から答えなければならなくなる。グラウンディングが重要かどうかをエージェントに決めさせているのではない。答えが学習データから来ないと既に分かっているケースについて、あなたが代わりに決めているのだ。
これは、少しのレイテンシと呼び出しあたり1クレジットを、本当に最新の回答と引き換える。事実経路では、それは毎回欲しいトレードだ。
正直な限界
決定論的なツール呼び出し検証は「呼んだか」については LLMジャッジに勝るが、そもそもどのクエリがツールを必要としたかは教えてくれない。それは誰かがラベル付けしなければならない。評価セットにはツール必須とマークされたケースが必要で、そうすればアサーションは、呼び出しの欠如がバグなのか、正しくツール不要だったのかを判断できる。
そのラベル付けこそが本当の仕事だ。正しい答えが現在のデータに依存する事実クエリのセットを作り、各々をツール必須とマークし、すべてに対して2部構成のアサーションを走らせる。決定論的チェックはラベルさえあれば安く正確だ。ラベルを得ることは、どんな自動化もあなたの代わりにやってくれない部分だ。