Lilith Lilith.
編集イラスト: エージェントはデモを完璧にこなす。なぜ本番環境で失敗するのか?
Lilithのイラスト · 編集リミックス

AIエージェントと本番環境でのあがり症

LLMエージェントを訓練し、アプリでフォームに入力するようにテストすると、デモ中には開発者が計画したとおりに正確に入力される。Hugging Faceのブログに掲載されたIBM Researchの研究者によるレポートは、その後に続く問題を強調している。同じエージェントを実際のクライアントに展開すると、まったく同じユーザープロンプトに対して、異なるステップシーケンスで応答して失敗することがよくある。

著者らは、この現象をAIエージェントの根本的な信頼性の問題として説明している。あるインスタンスでタスクを正常に完了したにもかかわらず、同じシステムが繰り返しの呼び出しでわずかに変更されたロジックを適用し、ツールセットから別の関数を呼び出し、最終的にエラー結果を生成する可能性があるという問題である。

現在のリーダーボードは再現性ではなくパフォーマンスを測定する

研究所は従来のベンチマーク(SWE-benchなど)で最高スコアを達成するために競争しているが、研究者らはその明らかな盲点を指摘している。リーダーボードと評価スイートは、主に1回の成功、つまりエージェントが特定の試行で目標に到達したという事実を報酬としている。しかし、本番環境への展開では、100回目の呼び出しでも定型タスクを安定して完了するボットが必要である。

エージェントフレームワークの信頼性と一貫したパフォーマンスの指標は、現在の評価エコシステムには欠けている。しかし、企業でのAIの採用において重要なのは、アシスタントが時々天才的な能力を発揮することではなく、手作業による修正を必要とせずに、日常の平均的な負荷の下で信頼できることである。

解決への道は直線的ではない

不整合性は、次に生成されるトークンの確率に基づいて動作する言語モデルの性質から生じている。変動性を排除することは容易ではない。モデルの自由度を厳しく制限する(温度をゼロにする、出力フォーマットを厳格にするなど)と、環境が予期せず変化したとき(UIに予期しないポップアップウィンドウが表示された場合など)に、システムがエラーから回復する能力を失うからである。

真の解決策は、同一であるがわずかに異なる状況を通して、繰り返し実行(ストレステスト)でエージェントをテストし、パスの安定性の実際の割合を計算する、より高度な評価パイプラインを展開することにある。

信頼性ベンチマークの台頭が見られるだろう

市場の変化の証拠は、絶対的な成功スコアから「実稼働可能(production-ready)」な指標へと関心が移ることだろう。タスク解決能力だけでなく、同じタスクに対する手順の予測可能性に基づいてモデルを認定する新しい評価ツールの登場が予想される。

Lilithの判定

デモでAIエージェントを披露するのは、脱出ゲームで会計士を評価するようなものだ。本番環境で必要なのは、近道の天才的な発見者ではなく、まったく同じマスで100回連続して転ばない人物である。

外部リンクは最後に置いています。まずここで簡潔に解説 — 他人のサイトを探し回る必要はありません。

元の記事 ↗