Googleがautofinetuneを公開：エージェントがTPU上でSFTとGRPOの学習設定を自動探索

Googleの開発者チームは、従来は人手で試行錯誤を繰り返す必要があったLLMの後学習を、継続的に実行できるエージェントループへと変える`autofinetune`を公開した。ユーザーはまず`program.md`で、変更を許可するハイパーパラメータ、リソース制限、評価目標を定義し、単一の`run.py`を用意する。するとAntigravity CLIとGemini Flash 3.7がプログラムを変更し、Tunixジョブを起動して評価結果を読み取る。改善したバージョンはGitにcommitし、性能が低下したバージョンは元に戻す。また、一連の軌跡をTSVに記録する。

最初の事例では、単一のCloud TPU v5e上でFunctionGemma 270Mをファインチューニングした。エージェントは数時間で20回の実験を実行し、LoRA rank、alpha、対象となるprojection layer、optimizer、learning rate、batch sizeを調整できる一方、dataset、epoch数、model architectureは変更できない。2つ目の事例では、TPU v6e、Gemma 3 1B、GSM8Kを使ってGRPOを実行し、LoRA、rollout temperature、KL penalty、system promptを探索した。Googleによると、約40回の実験後、独自の総合指標が約10%向上したという。

技術的な価値は新しい最適化アルゴリズムにあるのではなく、「仮説の提示—プログラムの変更—高コストな学習—測定—version control」という流れを、監査可能なループとしてパッケージ化した点にある。明確かつ限定的なsearch spaceをバッチで探索する用途に適している。ただし、エンジニアリングチームはいくつかの点に注意する必要がある。GRPOの事例では数値の正解率とフォーマットの正解率を単純に加算しているため、エージェントがproxy metricを過剰に最適化する可能性がある。また、公開データは2つのmodelと2本のサンプルtrajectoryに限られ、Bayesian optimization、Population Based Training、人手によるハイパーパラメータ調整との比較も行われていない。ブログでは40回の実験に2〜3日を要したとしている一方、repositoryには45回、約4日と記載されており、実験報告にはなお整理が必要であることがうかがえる。repositoryではさらに、TPU VMのクラッシュに対するworkaroundを事前に適用するよう求め、権限確認をスキップする例も示している。実データとクラウドアカウントを使用する場合は、あらかじめcredentialを分離し、変更可能なファイルとTPU予算を制限したうえで、holdout test setを用いて最良の設定を再検証すべきだ。