ServiceNow、エージェントの失敗をトレーニングデータに変える

実際のエンタープライズシステムにAIエージェントを導入したことのあるチームなら、誰もが同じ苦労を知っている。モデルは広く能力を備えているのに、自社固有のツール、自社固有のポリシー、自社固有の混沌としたステートマシンに直面した途端、つまずく。

ServiceNowの研究部門CoreAIは、そうしたつまずきを資産に変えようとするシステムを公開した。AutoSynthDataと呼ばれ、その前提は、モデルの失敗こそが、そのモデルをトレーニングするための最も価値ある原材料だというものである。

中核となる仕組み

このパイプラインは、実際の環境で、対象モデルとより強力な教師モデルを同じ診断タスクに実行させることから始まる。対象モデルが失敗し、教師モデルが成功した箇所に、能力のギャップがある。AutoSynthDataはそのギャップを、チームが「ケイパビリティ仕様カード（capability specification cards）」と呼ぶものへと蒸留する。これは、関与するツール、ワークフロー、最終状態、許容されるバリエーションを、元の評価プロンプトやエンティティの詳細を除去して記述した、サニタイズ済みの説明である。

これらのカードが新しいタスクの生成の種になる。重要なのは、生成器が元の評価軌跡を一切見ないため、得られるデータは暗記した手順ではなく、根底にある能力を試すものになることだ。このフレームワークはこれを2つのフェーズでスケールさせる。ターゲットフェーズでは、中核タスクを並列に作成する。増殖フェーズでは、検証済みのタスクを取り、新しい文言、新しいエンティティ構成、新しい初期状態を備えたバリエーションを生み出す。データのドリフトを防ぐルールが1つある。増殖されたサンプルは、さらなる増殖の種にはできない。

生成する価値のあるタスクの3条件

ServiceNowは、もっともらしく見えるリクエストでは十分ではないと明言している。生成されたタスクは、同時に3つの条件を満たさなければならない。

実行可能であること。つまり、ルールを守りながらリクエストを完了する実行可能な経路が、環境内に少なくとも1つ存在すること。現実的であること。つまり、誰も取らない技術的に有効な行動ではなく、実ユーザーが実際に依頼する作業を反映していること。そして難しいこと。つまり、真の弱点を狙っていること。取るに足らないタスクは何も教えず、不可能なタスクは間違った教訓を教える。

各タスクには検証器が付属し、検証器も独自の基準を満たさなければならない。プロンプトとシステム状態に整合していること、制約違反を拒否できるだけの健全性があること、1つの参照経路に固執するのではなく、あらゆる有効な解を受け入れられるだけの完全性があること。

品質ゲートこそが本当の成果物

ここで注目すべきなのは、タスク生成ではない。チェックである。

すべての候補は2つのゲートを通る。ポジティブゲートは、環境内で参照解を実行し、意図した答えが実際に検証器を満たすことを確認する。これにより、プロンプト、初期状態、成功基準の間の不一致を捉える。ネガティブゲートは、最終状態を意図的に改変し、誤った結果が実際に拒否されることを確認する。2つ目のゲートは、仕様が不十分な検証器、つまり不正なエージェント軌跡を喜んで報酬を与えてしまいかねない種類の検証器を捉えるものである。

候補が失敗すると、クリティックが破綻を診断し、壊れた参照や矛盾する状態を見つけ、作業を即座に破棄するのではなく、範囲を限定した修復を指示する。サンプルレベルより上では、バッチレビューが集合全体を監視する。どのタスククラスタが過剰に代表されているか、どの次元が欠けているか、どの生成パターンが停滞し続けているか。その後、コントローラが次のバッチを、残っているギャップへと方向づける。

そもそもなぜ合成データが必要なのか

立ち戻って、なぜこれが重要かを問う価値がある。エンタープライズエージェントにとって理想的なトレーニングデータは、実システムで実作業を行う実在の人々の記録に、正しくラベルを付けたものである。そうしたデータは希少で機微であり、収集にもコストがかかる。しかも、その多くはプライバシーやコンプライアンス上の理由で社外に持ち出せない。

合成生成は脱出口だが、既知の失敗モードを伴う。モデルからタスクを生成すれば、そのモデルの盲点を引き継ぎ、得られるデータは大量に見えてもほとんど何も教えないことがある。AutoSynthDataの貢献はまるごと、生成を囲む仕組みによってデータの誠実さを保つことにある。悪いタスクを拒否するゲート、反復を防ぐ多様性チェック、エージェントがまだ習得していないものに狙いを定め続けるカリキュラムである。検証なき生成はノイズである。これはそれをシグナルにしようとする試みだ。

数字が語ること、語らないこと

エンタープライズエージェントタスク向けのオープンソース環境であるEnterpriseOps Gymでのテストでは、AutoSynthDataのサンプル2,000件でファインチューニングしたGemmaベースのモデルが、ハイブリッド領域においてPass@1指標をベースライン比で35パーセント改善した。ITSM領域では、合成データによる教師ありファインチューニングによって、平均Pass@1が18.77パーセントから27.18パーセントに上昇した。

これらは特定のベンチマークにおける実際の改善であり、一般的な結果と同じではない。このパイプラインの中心的な依存関係は正直であり、率直に述べておく価値がある。正しい振る舞いを示すための、かなり強力な教師モデルと、テストを行うための正確なシミュレーション環境が必要である。高忠実度のサンドボックスと信頼できる決定論的検証器を持たない企業にとって、実行レイヤーの構築それ自体が真剣なエンジニアリングプロジェクトである。AutoSynthDataはその作業を取り除くのではない。作業の目的を変えるのだ。

教師モデルという落とし穴

この設計には、一文を割く価値のある依存関係がある。パイプライン全体は、弱いモデルと強いモデルの間のギャップで動いている。実験では、教師モデルは対象モデルよりはるかに大きなモデルだった。これは、借りてくるフロンティアシステムがある場合には機能する。自分自身がフロンティアである場合、あるいはタスクが非常に特殊化していて、それを実演できるより強いモデルが存在しない場合には、うまく機能しない。その場合、パイプラインは学ぶ相手を持たず、依存している能力ギャップは単なる壁である。トレーニングデータ生成の研究は、最終的に必ずこれに突き当たる。誰かがどこかで問題をすでに解決している限り、手法はスケールするのだ。

これがエンタープライズAIの形である理由

このリリースの興味深い点は、エンタープライズAIが実際にどこに立っているかについて、何を認めているかである。ボトルネックはもはや、有能なモデルを手に入れることではない。ボトルネックは、有能なモデルを、特定の組織の、特定のツールとルールの内側で、正しく動作させることにある。そこでは失敗は微妙で、状態空間は大きい。

長年、答えは手動アノテーションだった。それは遅く、高コストで、スケールしにくい。AutoSynthDataは、評価セットを漏らさずに失敗を抽出し、検証し、多様化できれば、失敗そのものにシグナルが含まれているという主張である。このパイプラインはHugging Faceで研究用に公開されており、チームは同じ方法論を用いた強化学習が次だと述べている。

もしこれが広く機能するなら、示唆されるのは、エンタープライズAIで希少なスキルが移り変わることだ。データを獲得することから、信頼できるデータを内部で生成できるほど優れた環境を構築することへと変わる。それはより難しい問題であり、より持続的な問題である。なぜなら、企業の環境は競合他社がコピーできないものだからだ。