AutoSynthData: エンタープライズエージェント向けトレーニングデータの自動生成


ADVERTISEMENT

AutoSynthDataのアーキテクチャとタスク生成パイプライン

ServiceNow CoreAIが発表した「AutoSynthData」は、エンタープライズ環境(ITSMやハイブリッド環境など)において、LLMベースのエージェントが抱える能力のギャップ(弱点)を自律的に特定し、効果的なトレーニングデータを自動生成するためのフレームワークである。

エージェント環境におけるタスクの抽象化は以下の3要素で定義される: $$\text{task} = (\text{システム仕様}, \text{ユーザープロンプト}, \text{検証器 (Verifier)})$$

AutoSynthDataのパイプラインは、主に「Targetフェーズ」と「Multiplyフェーズ」の2段階で構成される。

  1. Targetフェーズ(コアサンプルの生成): ターゲットモデルの失敗例と、より強力な教師モデルの成功例を分析して「能力仕様カード(Capability Specification Cards)」を作成する。これをもとに、環境内で実行可能かつ現実的(Realism)、かつ難易度の高いタスクのコアセットを並列生成する。

  2. Multiplyフェーズ(バリエーションの拡張): 承認されたターゲットサンプルを基に、エンティティ、初期環境状態、ワークフローの構成、プロンプトの表現などを変化させた新規バリエーションを網羅的に拡張する。なお、増幅されたサンプルからさらに別のサンプルを派生させることは禁止されており(多段増幅の制限)、世代間のドリフトや品質低下を抑制する設計となっている。


品質の保証と評価メカニズム:検証・批評・修正ループ

合成データの最大課題である「ハルシネーションの混入」「実行不可能なタスクの生成」「不適切な検証ロジック」を回避するため、AutoSynthDataは厳格な品質管理ループを実装している。生成されたすべての候補タスクは、サンプルレベルとバッチレベルの双方向からレビューを受ける。

  • 正の検証(Positive Verification): 意図された正解の軌跡(Reference Trajectory)をターゲット環境で実際に実行し、得られた状態が検証器(Verifier)の基準を満たすかをチェックする。
  • 負の検証(Negative Verification): 意図的に改変された不適切なアウトカムや失敗状態が、検証器によって正しく弾かれる(失敗判定になる)ことを確認する。これにより、緩すぎる検証器による誤った報酬付与を防ぐ。
  • 批評と修正(Critique and Repair): 検証に失敗した候補は、クリティック(批評モデル)に送られ、状態の不整合やツールの誤用、検証ロジックの欠陥が診断される。あらかじめ設定されたリトライ回数の上限内で、診断結果に基づいたピンポイントの修正が施される。
  • バッチレベルのメタレビュー: 生成されたデータセット全体を俯瞰し、特定のタスクファミリーへの偏りや、カバレッジの抜け落ちがないかを動的にモニタリング・調整する。

EnterpriseOps Gymにおける実験結果とパフォーマンス

EnterpriseOps Gymベンチマークを用いた検証では、AutoSynthDataの有効性が実証されている。

  • Hybridドメインでの検証: ターゲットモデルに gemma-4-26B-A4B-it、教師モデルに Qwen3.8-27B を用いて約2,000件の合成トレーニングデータを約18時間で生成した。Supervised Fine-Tuning(SFT)を適用した結果、平均 Pass@1 が 35%の相対的向上(7.2ポイント増) を記録し、ターゲットモデルと参照モデル間の性能ギャップの59%を埋めることに成功した。
  • ITSMドメインでの検証: 教師モデルに DeepSeek-V4.1-Flash を用いた実験では、平均 Pass@1 が18.77%から27.18%へと大幅に向上し、異なるエンタープライズドメインにおいても汎用的に機能することが証明された。

開発者・エンジニア視点での考察

  1. 静的データセットから「モデル適応型カリキュラム」へのパラダイムシフト: 従来の固定されたインストラクションデータセットを用いた学習と異なり、AutoSynthDataは「モデルが今どこでつまずいているか」のフィードバックループを回し続ける。この動的な難易度較正(Capability Boundaryの追従)は、特定ドメイン特化型エージェントの育成コストを劇的に下げるアプローチとして、今後のLLM継続事前学習やSFTの標準手法になり得る。

  2. 実環境シミュレータ(Gym)と検証器分離アーキテクチャの重要性: 生成されたタスクの品質を担保するため、コードの実行環境(アダプター)と制御ロジック(コントローラー)を完全に分離している点が極めて堅牢である。単にプロンプトを模倣するだけでなく、環境の状態遷移やAPIの整合性をプログラム的に検証(Positive/Negative Verification)する仕組みは、エージェント向け合成データパイプラインを自社構築する際の必須要件と言える。

  3. SFTから強化学習(RL)への拡張ポテンシャル: 本論文・ブログで示された手法は主にSFTを対象としているが、ポリシーの更新に合わせて生成ターゲットをシフトさせる仕組みは、将来的にRL(強化学習)環境における報酬モデリングやロールアウトデータの自動生成へシームレスに応用可能である。エンタープライズ特有の複雑なワークフロー自動化において、試行錯誤のデータを自律生成する基盤として非常に高い拡張性を持っている。

Source / 元記事

この記事について

著者
AIBloom AI編集部
初回公開
最終更新

この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。

元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。

重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。

About AIBloom

ADVERTISEMENT