アーカイブ / LLM / AI Agent
依頼の言い換えと類似機能の追加で、AIの関数呼出しはどう変わるか
On the Robustness of Agentic Function Calling
On the Robustness of Agentic Function Callingの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Compact function definition example (top), and agent’s output, triggering the function call with assigned parameter values (bottom), per user request "What is the record for the highest number of points scored by a single player in an NBA game?".
概要
- BFCLを基にした200件で、依頼の言い換えと関連関数の追加が関数呼出しに与える影響を評価した。
- 言い換え時の得点低下には、同じ場所の別表記を正解と認めない採点上の問題が含まれた。
- 関連関数を加えた条件では、誤った関数の選択や引数の割当て違いなどが観察された。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、On the Robustness of Agentic Function Callingの仕組み
- 01元の依頼と関数群
- 02関連依頼を生成
- 03関数定義を生成
- 04重複を除外
- 05拡張関数群
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
AIの関数呼出しは、利用者の依頼に合わせて機能を選び、場所や期間などの値を引数として指定する処理である。たとえば天気を尋ねる依頼なら、天気を取得する関数を選び、対象の場所を渡す。
元の設問で正しく呼び出せても、同じ意味の言い換えや似た機能の追加で結果が変わる可能性がある。著者らは、利用者の表現と利用可能な関数群が変化する場面を想定し、この二種類の変化に対する安定性を調べた。
手法
著者らは、関数呼出しの評価データBFCLから、難しい単発の依頼200件を使った。言い換え条件ではLlama3.1-70Bで依頼の意味と、金額や年数など引数に渡す値を保った別表現を生成した。著者の一人が50例を目視確認し、意味や引数値のずれは見つからなかった。
関数群の拡張では、元の依頼に関連する別の依頼をLlama3.1-70Bで作り、それに応じる関数定義をCodeLlama-13Bで生成した。関数の属性をまとめた表現の類似度で元の関数と実質的に同じ候補を除き、元の関数群に追加する。モデルの出力はASTという呼出しの構造を照合する方法で採点し、関数の実行結果は調べていない。
新規性
著者らは、関数呼出しの正答率に加え、依頼を同じ意味で言い換えた場合と、関連する関数を選択肢に加えた場合の安定性を測る評価データを構築した。追加関数は元の関数と実質的に同じものを選別して除いている。
言い換え時の得点低下については、モデルの呼出しが変わった事例だけでなく、同じ場所を指す表記を正解として認めない採点上の問題を分析した。入力の変化と評価方法の影響を分けて考える必要性を示した点も貢献である。
従来手法との違い
比較の基準は、元の依頼と元の関数群を使うBFCLの事例である。元の関数群は平均2.7個で、著者らは関連関数を平均約3個加え、平均5.6個の関数群を作った。言い換えた依頼では元の関数群を使い、拡張した関数群では元の依頼を使う。
この三条件の比較により、依頼の表現と関数の選択肢を別々に変えた影響を調べた。言い換え条件には正解値との完全一致による採点の問題が含まれる一方、拡張条件では関数の選択や引数の割当てなどの誤りが観察された。
実験結果
著者らは、BFCLを基にした200件で9モデルを評価し、ASTによる関数呼出しの得点を報告した。Qwen2.5-72Bの得点は、元の依頼と関数群で0.975、言い換えた依頼と元の関数群で0.850、元の依頼と拡張した関数群で0.965だった。これらは200件の平均であり、実行成功率ではない。
著者らの分析では、言い換え条件の誤りの70～90％が引数値の不一致に由来した。「Miami, FL」は元の場所を指していても、採点用の正解候補にないため不正解となる例である。拡張条件では、誤った関数の選択、関数の呼出し数の違い、引数の割当て違いなどが見られた。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の売上照会を業務関数へ振り分ける仕組みの導入前に、似た集計関数を取り違えないか調べる。元データとして実際の問い合わせ文と関数定義を集め、期待する関数名と引数の正解ラベルを担当者が付ける。追加学習用データやセンサーは想定しない。
担当者が期間や部署を保った言い換えを確認し、商品別など関連する関数を選択肢に加える。各条件で得た関数名と引数を正解ラベルと照合し、混同した依頼の一覧を出す。現場の関数説明と採点規則への調整を要する、効果未検証の応用案である。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：対象業務から少数の実際の依頼文と関数定義を集め、担当者が期待する関数名と引数の正解ラベルを付ける。追加学習用データやセンサーは不要と想定するが、依頼の言い換えは意味と引数値を確認し、追加する関数は既存機能との重複を点検する。
元の依頼と関数群でのASTに相当する構造一致率を基準値とし、言い換え時と関連関数追加時の一致率を比べる。関数選択、引数、呼出し数の誤りを別々に数え、同義表記だけで不正解になった例は担当者が確認する。その結果を使って、現場の関数定義と採点規則を調整する。
限界と課題
著者らが明記した限界は、評価が単一のデータセットに限られることと、関連する依頼・関数の生成に複数の言語モデルを使い、時間のかかる処理を事前に行っていることである。別のデータセットや、無関係な関数も加える条件での検討は今後の課題としている。
編集上の検証事項は、業務で使う関数説明でも同様の評価条件を作れるか、地名や部署名の同義表記をどう採点するかである。この研究の得点は関数呼出しの構造に関するもので、関数の実行結果や複数回のやり取りを含む業務の達成率を示さない。
出典
元のタイトル・要旨を確認する（英語）
On the Robustness of Agentic Function Calling
Large Language Models (LLMs) are increasingly acting as autonomous agents, with function calling (FC) capabilities enabling them to invoke specific tools for tasks. While prior research has primarily focused on improving FC accuracy, little attention has been given to the robustness of these agents to perturbations in their input. We introduce a benchmark assessing FC robustness in two key areas: resilience to naturalistic query variations, and stability in function calling when the toolkit expands with semantically related tools. Evaluating best-performing FC models on a carefully expanded subset of the Berkeley function calling leaderboard (BFCL), we identify critical weaknesses in existing evaluation methodologies, and highlight areas for improvement in real-world agentic deployments.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01