Meta、推薦システム研究エージェントによるサーバー間での数日間にわたるGPU実験の引き継ぎを実現、運用上の修復回数を1ラウンド当たり0.5回に削減

Metaの研究チームはAuto-RecSysを公開し、数分でフィードバックを得られる小規模実験にとどまっていた自動研究エージェントを、1回のトレーニングに数日を要することもある産業規模の推薦システムへ適用しようとしている。このシステムはモデルのトレーニング自体を短縮するものではなく、複数のアイデアを異なるサーバー上で非同期に実行し、研究者をジョブの投入、監視、再実行といった作業から解放する。

中核となる設計思想は、「認知」と「手順」の分離だ。エージェントは、モデルごとに用意されたMarkdown形式のplaybookを通じて、コード内の重要箇所、検証プロセス、既知の行き止まり、成功した戦略を把握する。一方、GPUの種類、リソース権限、パッケージレイヤーのバージョン、ジョブの状態など、曖昧さが許されない情報は、固定schemaのJSON／JSONLと決定論的スクリプトで処理する。集中管理されたメモリには、アイデアの登録表、追記型の実験履歴、セッションの軌跡、コード差分のドラフトが保存される。このため、元のサーバーやエージェントのセッションが停止しても、別のセッションがコンテキストを復元し、リモートのトレーニングジョブを照会して分析を継続できる。

Auto-RecSysには、さらに2つの進化ループが設けられている。Execution Evolution Loopは、失敗の軌跡から「二度と行わない」ためのルールと再利用可能なパイプラインを抽出する。Idea Evolution Loopは、完了した実験に基づいて次の仮説を調整する。チームが同一の推薦モデルで31回のイテレーションを実施したところ、安定期における重大な運用上の修復は平均4.0回から1.3回に減少した。第21ラウンドでモデルのベースラインを変更した後、一時的にエラーが増加したものの、第26～31ラウンドには0.5回まで減少し、6ラウンド中5ラウンドでは運用上の修復が不要だった。最長の事例では、人間の介入を求めることなく、110回のtool callを連続して実行した。

ただし、これらの数値が主に測定しているのはインフラストラクチャの信頼性であり、対照群は存在しない。また、新しいアイデアを実装する際の推論やデバッグは集計から除外されており、推薦指標や研究成果の成功率も報告されていない。データは、1つのモデルを対象とした31ラウンドの社内実行履歴に限られ、システムとコードも公開されていない。エンジニアリングチームは今後、playbookの更新が独立して検証されているか、複数人が共有状態を同時に変更した際の競合をどう解決するか、さらに、エージェントが過去の経験を自動適用することで高コストなGPUジョブを気付かれないまま浪費する可能性がないかに注目すべきだ。