AIエージェントがQAに合格していても本稼働で失敗する理由

継続的学習は、エージェントを展開後に改善するためのエンジニアリングの分野になりつつあります。エージェントは、すでに機能していたものを壊すことなく、改善されます。

AIエージェントは、事前の評価に合格していても、本稼働で1週間後に失敗することがあります。那も矛盾ではありません。評価セットは、チームが事前にテストした内容を反映しています。本稼働では、不思議なフレーズ、不足しているコンテキスト、ツールのエッジケース、不耐性のあるユーザー、矛盾するポリシー、ベンチマーク設計者が想定していないワークフローなど、欠けているケースが現れます。

エージェントは、ユーザーによって常に修正されます。ユーザーは失望します。セッションが終了すると、ログが保存され、次のユーザーは基本的に同じシステムに遭遇します。

これが、継続的学習がエージェントエンジニアリングの中心になりつつある理由です。継続的学習は、1つの製品の機能ではありません。エージェントを経験から改善し、すでに機能していたものを保持するための方法のカテゴリです。クラシックの継続的学習の研究は、カタストロフィックな忘却なしに時間の経過とともに学習する問題を枠組み付けました。エージェントは、その問題を広げます。変更されるものは、モデルであるかもしれませんが、プロンプト、ツール、スキル、ワークフロー、またはメモリである可能性もあります。

その区別は重要です。なぜなら、エージェントのほとんどの失敗は、モデルを更新することによって解決されないからです。

微調整の反射は狭すぎる

チームがAIシステムを改善する計画について話し合うとき、デフォルトの計画はしばしば次のようになります。失敗を収集し、より良い回答をラベル付けし、モデルを微調整します。那は理解できる本能です。教師ありの微調整、直接的好みの最適化、グループ相対的ポリシーの最適化、およびパラメーターエフィシャントな方法であるLoRAは、モデル自体が変更される必要がある場合に役立つツールです。

しかし、多くの本稼働の失敗は、モデル重みの失敗ではありません。システムの失敗です。

エージェントは、古いメモリに依存している可能性があります。必要な確認をスキップする可能性があります。ツールを間違った引数で呼び出す可能性があります。あるいは、間違ったワークフローにケースをルーティングする可能性があります。問題は、ベースモデルの能力ではありません。コンテキスト、メモリ、ツールインターフェイス、またはワークフローがベースモデルを囲むものです。

現代のエージェントには複数のレイヤーがあります。モデルは推論し、生成します。モデルを囲むハーネスは、プロンプト、ツール、スキル、コード、ルーティング、ワークフローを定義します。メモリは、事実と学習された手順をセッション間で運びます。継続的学習は、どのレイヤーが変更されるべきか、変更がどのくらい小さくできるか、変更が実際に役立ったかどうかを判断するという規律です。

修正は、メモリへの書き込みである可能性があります。修正は、プロンプトの編集である可能性があります。修正は、ツールのラッパー、ルーティングのルール、またはワークフローのパッチである可能性があります。微調整は、利用可能なまま残るべきですが、毎回の失敗に対する最初の答えではありません。

ベンチマークは役立つが、本稼働ではほとんど得られない

エージェントのハーネス自体を最適化するための興味深い研究があります。GEPA、Meta-Harness、および関連するプロンプトまたはワークフローの最適化アプローチは、エージェントをシステムとして扱い、ミューテーションし、テストします。候補を提案し、実行し、スコアの良いバージョンを保持します。

それは正しい方向です。それは、改善を「重みを更新する」狭い枠組みから「エージェントを改善する」広い枠組みに移します。

しかし、落とし穴があります。通常、これらの方法はベンチマークを前提としています。タスクは繰り返し実行でき、評価者は候補Aが候補Bよりも優れているかどうかを判断できる必要があります。ベンチマークがなければ、最適化はより優れたツールで行われる推測になります。

これは、ほとんどのチームが本稼働で持っているものではありません。

持っているのはログです。トレース、ユーザーの修正、サポートチケット、サムネイルのイベント、エスカレーションノート、および時折の専門家のフィードバックです。これらのシグナルは貴重ですが、まだベンチマークではありません。何かが起こったことを示しますが、再生する方法、成功の見方、修正のスコアリング方法については自動的に示しません。

そのギャップは、多くの継続的学習の取り組みが停滞する場所です。チームは経験を持っていますが、まだ学習環境を持っていません。

ログは教訓ではない

本稼働ログは、1つのパスを通した相互作用を記録します。ユーザーはフライトを尋ねました。エージェントは検索しました。ユーザーは日付が間違っていると言いました。那は失敗の証拠ですが、学習するには十分ではありません。

ログは、反実を定義しません。エージェントは確認を求めるべきでしたか。エージェントは以前のコンテキストから日付を推測するべきでしたか。エージェントは異なるツールを呼び出すべきでしたか。エージェントは曖昧さが解消されるまで進行しないべきでしたか。人間はトレースを読んだ後で答えを知るかもしれませんが、システムはその構造を無料で得ることはできません。

継続的学習が機能するためには、生の失敗を再生可能なものに変える必要があります。那は、エージェントが再び直面するタスク、パターンを再現するユーザーまたはシミュレーター、エージェントが呼び出すツール、成功を定義する評価者を意味します。評価者は、最終的な答え、ツールの呼び出し、ポリシーの境界、待機時間、コスト、またはすべての組み合わせを確認する可能性があります。

これは、作業の目に見えない部分ですが、改善を実現する部分です。失敗が再生可能な環境になると、具体的な質問を問うことができます。提案された変更は実際に動作を修正しましたか。

そのステップがないと、チームはほとんどメモリから修正しています。

David SilverとRichard Suttonは、経験の時代について説明しました。エージェントは、静的な人間のデータではなく、世界との相互作用から主に学習します。企業のエージェントにとって、そのビジョンは、汚れた本稼働の経験を再生可能な環境、スコア付け、再利用可能な環境に変えることに依存しています。

経験だけでは十分ではありません。経験はテスト可能なものにしなければなりません。

回帰は隠れたコスト

失敗がテスト可能になっても、最も難しい部分は残ります。修正を適用することなく、他のものを壊さないことです。

複雑なエージェントを維持したことがある人は、そのパターンをみたことがあります。エスカレーションを追加して、エージェントが攻撃的な返金要求をエスカレートするようにします。ただし、通常の返金要求もエスカレートされます。ツールの呼び出しを1つのワークフローで削減します。ただし、別のワークフローでは必要なチェックをスキップします。古いメモリを修正します。ただし、エージェントは修正を別の製品ラインに過剰に一般化します。

各パッチは、ローカルでは意味をなします。システムは、まだグローバルに漂い続けます。

これは、エージェント版のカタストロフィックな忘却です。ニューラルネットワークでは、通常、古い能力を新しいトレーニングによって上書きすることを指します。エージェントでは、失敗はより広範で、見るのがより難しいことがあります。忘却は、プロンプト、ツール、メモリ、ルーティング、ワークフローで発生する可能性があります。忘却は、トレーニング曲線上的のクリーンなメトリックとして現れません。ユーザーが「これは以前は動作していました」と言うことによって現れます。

それが、回帰コントロールが最終的なレビューのステップであるべきではない理由です。回帰コントロールは、学習ループ自体の中に含まれる必要があります。

目標は、新しい失敗のパフォーマンスを最大化することだけではありません。新しいケースを改善し、古いケースを保持することです。機能する修正はすべて、エージェントの成長するメモリの一部になるべきです。実践では、古い失敗は回帰テストになります。エージェントの歴史は、アーカイブではなく、制約になります。

これは、継続的学習がより真剣なソフトウェアエンジニアリングのように、プロンプトのこね回しよりもなります。変更は、より優れたものであるべきではありません。変更は、測定された動作を改善し、システムがすでに獲得していたものを劣化させないものであるべきです。

実用的継続的学習の要件

本稼働用の継続的学習ループには、4つの特性が必要です。

第一に、失敗は再生可能でなければなりません。単発の失敗は、逸話です。再生可能で評価された環境は、テストです。エージェントが同じパターンに再び直面するまで、誰も修正が機能したことを証明できないからです。

第二に、診断は全体的に行わなければなりません。修正は、モデルに属する可能性がありますが、メモリ、プロンプト、ツールレイヤー、またはワークフローに属する可能性もあります。最善の修正は、通常、失敗を説明する最小の耐久性のある変更です。

第三に、学習は一生涯にわたるべきです。エージェントは、来週の動作を今週の改善によって秘密裏に無効にすべきではありません。以前の成功は、最適化中に制約として、ではなくて、デプロイ後の驚きとして扱われるべきではありません。

第四に、ループは効率的でなければなりません。改善が毎回、四半期ごとの再トレーニングプロジェクトを必要とする場合、システムは本稼働のペースを維持することはできません。ループは、安価な修正を最初に試し、必要に応じてエスカレートし、検証を変更の近くに保つ必要があります。

これらは、エージェントが盲目的に自己更新するべきではないことを意味しません。逆を意味します。改善は、測定可能なものになるべきです。各変更には、テスト、前後比較のスコア、および回帰チェックが必要です。

これが、継続的学習を、漠然とした志向からエンジニアリングの規律に変えるものです。

エージェントの将来は、コンテキストウィンドウの拡大、ベースモデルの強化、またはツールの増加のみによって定義されません。それらは重要になります。しかし、企業にとってより重要な質問は、デプロイの後についてです。

エージェントが明日失敗した場合、システムはその失敗をテストに変えることができますか。修正を正しいレイヤーにルーティングできますか。修正が役立ったことを証明できますか。修正が他のものを壊さなかったことを証明できますか。

答えが「いいえ」の場合、エージェントは本稼働から実際に学習していません。リスクを蓄積しています。

次に重要になるエージェントは、より優れたことを行うでしょう。彼らは複利効果を生み出すでしょう。