【DL輪読会】Robust Function-Calling for On-Device Language Model via Function Masking

DEEP LEARNING JP [DL Papers] Robust Function-Calling for On-Device Language Model via Function Masking Yuya IMAI, Matsuo Iwasawa Lab http://deeplearning.jp/ 1

• http://deeplearning.jp/

書誌情報 • タイトル：Robust Function-Calling for On-Device Language Model via Function Masking • 会議：ICLR 2025 Spotlight • 著者：Qiqiang Lin, Muning Wen, Qiuying Peng, Guanyu Nie, Junwei Liao, Jun Wang, Xiaoyun Mo, Jiamu Zhou, Cheng Cheng, Yin Zhao, Jun Wang, Weinan Zhang • TL;DR：LLMのFunction-Callingにおいて関数名ではなく説明文理解で選ぶよう に学習させ、小型モデルでも高精度を実現する • リンク： – https://openreview.net/forum?id=yVQcr4qjD6 – https://arxiv.org/abs/2410.04587 2

• https://openreview.net/forum?id=yVQcr4qjD6
• https://arxiv.org/abs/2410.04587

背景 LLMの関数呼び出し (Function-Calling) • 天気APIや決済APIなどの外部ツールを呼び出す • 候補リスト（関数名・パラメータ名・デフォルト値・説明文）から、ユーザ意図 に最も合致する関数を選択し、各パラメータを正しい型・形式で出力することが 求められる 3

背景 ベンチマーク間での性能不安定 既存の関数呼び出し特化モデルは、ベンチマークが変わると性能が大きく変わる 4

背景 ベンチマーク間での性能不安定 考えられる原因 • 関数名に誤誘導：`fetch_data` のような名称が学習時の用法（例：DB取得）に 強く結び付いてしまい、テスト時に別用途だと誤選択する。 • パラメータ名に誤誘導：`timeout` を秒の整数と学習していると、テスト側で `"10s"` の文字列仕様でも既習パターンに引きずられ誤った引数を生成する。 • 命名流儀の攪乱：CamelCase／snake_case の違いなど命名スタイルのブレだけ で自信度や選択が乱れ、軽量モデルほど汎化が難しくなる。 5

背景 ベンチマーク間での性能不安定 ケーススタディ • 関数名・引数名をランダム文字列に置換すると、精度が大幅低下。(モデル: xLAM-1.3B-fc) • つまり「説明文に十分な手がかりがあるのに名前に過剰適合していた」ことがわ かった。 6

手法 全体像 • 枠組みはSupervised Fine-Tuning • 学習用のデータ合成を工夫 – 1. Function Masking – 2. Irrelevance-Augmented Dataset 7

手法 1. Function Masking • 背景 – 多くのモデルは関数名やパラメータ名に強く依存 → 名前が紛らわしいと誤判定。 • 例）parse_data が JSON用かCSV用か不明確。 • パラメータの型や形式が異なる（例: timeout=10 vs timeout="10s"）と失敗。 • 手法 – 訓練時に 関数名やパラメータ名をランダム文字列に置換。 – モデルは description（自然言語の説明文） を手がかりに学習。 – デフォルト値もランダム化して説明に追加 → 説明に注目させる。 – 実装上は、訓練データの 33% のサンプルにマスクを適用（残りはそのまま）することで、 「名前が使える場合の学習」「名前が頼りにならない場合の学習」の両方をバランスよく行う。 8

手法 2. Irrelevance-Augmented Dataset • 背景 – 従来の訓練セットは必ず正解となる関数が含まれる形式。 – その結果、モデルは常に何か選ぶ傾向を持ち、無関係な関数まで呼び出してしまう。 • 手法 – 拡張方法： • 既存サンプルから正解関数を削除。 • ラベルを「空リスト（=どれも該当しない）」に置換。 – xLAM-function-calling-60k に 7,500件の追加データを構築。 – これにより「該当関数がない → 何も呼ばない」という判断を学習可能に。 9

実験 評価セットアップ • ベンチマーク – BFCL：多様な言語・タスク（Python, REST, JavaScript, Java）で関数呼び出しの正確性と実 行可能性を評価する大規模ベンチマーク。 – API-Bank：対話文脈から既知APIを呼び出すタスクと候補リストから正しいAPIを選ぶタスク で評価するベンチマーク。 – Seal-Tools：4,000以上の自動生成APIを含み、多様な生活ドメインで汎化性能を測る最新大 規模ベンチマーク。 – Tool-Alpaca：合成生成された小規模データでツール利用シナリオを簡易に評価するベンチ マーク。 – Nexus Raven：65種類のAPIを対象に、API呼び出しの正確性をテストする標準的ベンチマー ク。 • 指標 – BFCLは AST(構文的に正しいか)と Executable Function(正しく動作するか)の二系統で評価。 – 他ベンチは F1 を採用。 10

実験 総合結果(BFCL) Hammer-7B は BFCL 全体で、同規模のオープンモデルを上回り、 総合では GPT-4 に次ぐ 11

実験 (参考)BFCLのSimple/Multiple/Parallel/Parallel Multiple 12

実験 Ablation: Masking比率 学習データ内の、Function Maskingを適用する比率を変化させ、純粋な性能と汎化 性能を測る • 対象モデル：Qwen2-1.5B • 学習データ：Seal-Tools 訓練セット • 手順：関数マスキングの適用比率を変化させて、それぞれ1エポックのFineTuningを実施 • 評価：Seal-Tools（同一タスク）と API-Bank（別タスク）の両方で性能比較 13

実験 Ablation: Masking比率 結果：マスク比率を高くすると同一タスクでは学習効率が下がるが異分野への汎化 性能が向上し、最適値は約33%とされた。 14

実験 Ablation: Irrelevance-Augmented Data比率 • 「無関係な関数候補を誤って選ばない能力」を強化するため、学習時にどの程度 irrelevance-augmented dataを混ぜるのが適切か • 比率の例：30% の場合 → 学習バッチの30%を Irrelevance データ、70%を通常の xLAM-function-calling-60k から構成。 15

実験 Ablation: Irrelevance-Augmented Data比率 • 結果 – Irrelevance データ比率が高いほど、「無関係な候補を正しく棄却する能力」は向上。 – しかし同時に、「通常の関数呼び出し性能」が低下する傾向がある。 – 総合性能の観点では約10%の比率が最もバランスが良いと報告。 16

まとめ • 課題認識 – 既存の関数呼び出しモデルは、関数名やパラメータ名に過度に依存してしまい、ベンチマーク や実環境で命名規則が異なると性能が大きく低下する問題があった。 • 提案の要点 – 1. Function Masking により、名前をランダム文字列に置換 → 説明文に基づく理解を強化。 – 2. Irrelevance-Augmented Dataset により、適切な関数が存在しない状況でも誤って選ばない 能力を獲得。 – 3. 軽量モデル（1.5B〜7B）でも、汎化性能と安定性を大幅に向上。 • 成果 – Hammer-7Bは GPT-4シリーズに迫る性能 をBFCLで達成。 – 特に複雑な「複数関数・並列関数」タスクで優れた精度を示した。 – API-Bank、Seal-Toolsなど複数ベンチマークでも安定して高い結果。 – 小型Hammerモデルも既存の同規模モデルを上回る。 17

まとめ • 意義 – オンデバイス環境（スマホやエッジデバイス）での軽量かつ堅牢なエージェント実装に貢献。 – APIやツール群が頻繁に変わる現場でも、汎化性能により誤動作を減らせる。 • 今後の展望 – マルチターン・マルチステップの関数呼び出しをさらに強化（Hammer 2.1で既に改善中）。 – 説明文が少ないAPIにも対応可能な手法の検討。 – 大規模モデルとのハイブリッド運用による実用化加速。 18