Google DeepMind の AI DevX チームによるこの記事は、FunctionGemma を特定の組織のツール呼び出しのルールに適応させるためのチュートリアルである。記事は FunctionGemma を、前月にリリースされた、関数呼び出し向けに特化してファインチューニングされた Google の Gemma 3 270M モデルの一バージョンだと説明している。記事の前提は、ツール呼び出しこそがエージェントにとって自然言語を実行可能なアクションに変えるものであり、汎用モデルは、どのリクエストをどのツールが扱うべきかという企業独自のルールを知らない、というものである。
記事が対象とする問題は、ツール選択の曖昧さ、つまり似たように見える 2 つ以上の関数の中からどれを選ぶかである。そのケーススタディでは、社内のナレッジベース検索と公開 Web 検索の間で質問を振り分けるようにモデルを訓練し、会社の出張費精算の上限についての質問が Google ではなく社内文書に回されるようにしている。続いて、同じプロセスを訓練コードを書かずに実行できる Hugging Face Spaces 上のデモ、FunctionGemma Tuning Lab を紹介している。
要点
- すでにツール呼び出しをサポートしているモデルをファインチューニングする理由として、3 つが挙げられている。似たような複数のツールのうちどれを選ぶべきかを解決すること、公開データにはないニッチなタスクや独自形式に特化すること、そして蒸留、すなわち大規模モデルを使ってより小さく高速なモデルのための合成訓練データを生成することである。
- ケーススタディでは、
bebechien/SimpleToolCallingデータセットで評価したベースの FunctionGemma モデルは、性能が最適とはいえないと説明されている。誤ったツールを選んだり、関数を呼び出す代わりにポリシーについて「話し合う」ことを申し出たりした。 - ケーススタディでは、記事が本番環境の標準とする 80/20 ではなく、50/50 の訓練・テスト分割を用いた。これは、未見の大量のデータに対する改善を示すために選ばれたものである。
- 記事の主な注意点はデータの順序に関するものである。このデータセットはすでにシャッフル済みだったためシャッフルを無効にしたが、カテゴリ順に並べられたデータで同じ設定を使うと、一方のツールでモデルを訓練し、もう一方のツールでテストすることになってしまう。記事の推奨は、独自データを事前に混ぜておくか、順序がわからない場合は
shuffle=Trueを設定することである。 - Hugging Face TRL の
SFTTrainerで 8 エポックの教師ありファインチューニングを行った後、モデルは企業ポリシーに厳密に従うようになったと説明されている。例えば、新しい Jira プロジェクトの作成についての質問に対してナレッジベース検索を呼び出す。記事は訓練損失の曲線を示しているが、精度の数値は報告していない。 - FunctionGemma Tuning Lab はノーコードのインターフェースとして紹介されている。関数スキーマは UI 上で JSON として定義し、訓練データはプロンプト、ツール名、引数から成る CSV としてアップロードし、学習率とエポック数はスライダーで設定し、損失曲線をリアルタイムで表示し、訓練の前後で自動評価を行う。ダウンロードしてローカルで実行することもできる。
- 以上はすべて、Google が自社のモデルとツールについて述べたものであり、評価ではなくチュートリアルとして書かれている。
背景
この記事は エージェント型ツール利用 のうちモデル側に位置づけられる。エージェントに対するツールの記述の仕方を変えるのではなく、モデルを変えて正しいツールを選ぶようにするのである。記事はその結果を、汎用アシスタントを厳格なビジネスロジックに従う特化型エージェントに変えるものとして示し、最後に FunctionGemma のファインチューニングに関する Google の技術ガイドと、モバイルアクション向けのファインチューニングに関する別のガイドを紹介している。