CIはパスした。しかし、あなたのエージェントは「オペレーター・レディ」ではない

前四半期、あるエンタープライズ・クライアントにドキュメント・エージェントを導入しました。

私たちのテストスイートの合格率は94%でした。

パイロット運用開始から3週間後、エージェントは読み取れない請求書に対して返金処理を開始しました。しかも、それはエラーもログも出さず、静かに行われました。エージェントは、一見正しそうに見える誤った回答をただ出していたのです。

その間、私たちのCIはずっとグリーン（合格）のままでした。

問題はモデルでもプロンプトでもありませんでした。問題は、テストしていなかった6%のデータにありました。その6%は、オペレーターから送られてきた最初の「本物のデータ」だったのです。

これはエッジケースではありません。「オペレーター・レディ（運用準備完了）」であるかどうかの定義そのものです。

「プロダクション・レディ（本番環境対応）」とは、インフラストラクチャに関するものです。サービスが稼働し続け、負荷を処理できることを意味します。

「オペレーター・レディ」はそれとは異なります。それは、エージェントを作っていない人のためにエージェントが機能することを意味します。設計していないデータに対しても機能し、現実的な結果を伴う意思決定を行うことを意味します。

ほとんどのテストパイプラインは、自身で作成したデータセットに対する合格率を測定するものです。実際のデータがテストセットと異なる場合に何が起こるかは測定しません。

バリデーション成功率97%のモデルは、一見良さそうに見えます。しかし、失敗する3%に注目してください。

もしエージェントがリトライ中に欠落したフィールドをデフォルト値で埋めてしまうなら、あなたは「サイレント・エラー・マシン（静かにエラーを出す機械）」を作ったことになります。スキーマはパスしますが、データは間違っています。

これを解決するには、「スキーマの妥当性」と「コンテンツの確信度」を切り離してください。

私たちはすべてのレスポンスに確信度（confidence score）を追加しました。確信度が低い場合は、リトライする代わりに人間のレビューをトリガーするようにしました。この変更により、最初の18件のインシデントのうち14件を検知できました。

テストセットは「あなたが想定したもの」をカバーします。オペレーターのデータは「あなたが漏らしたもの」をカバーします。

私たちのケースでは、単一ページの請求書をテストしていました。しかし、オペレーターはスキャンされたPDFの複数ページにわたる請求書を使用しました。エージェントはその新しいフォーマットに対応できませんでした。

単にパーサーを修正するだけでは不十分です。本番稼働前に、実際のオペレーターのデータでテストしてください。

引き渡しを行う前に、現在はオペレーター自身のデータから50件のドキュメントを必須としています。合成データ（synthetic data）は使いません。彼らのデータを使います。

また、完全な監査証跡（audit trail）も必要です。モデルが何を返したかだけでなく、モデルが「何をしなかったか」もログに記録してください。

最小限の監査証跡に必要なもの：

  • フィールドレベルの確信度を含む出力
  • エージェントがリトライしたかどうかを示すフォールバック・インジケーター
  • ドキュメントを正確に再現するための入力ハッシュ
  • 使用された特定のモデルとプロンプトのバージョン

エージェントをオペレーターに渡す前に、以下の5つの項目を確認してください：

  • オペレーターの実際のデータから50件以上のサンプルを実行する。
  • スキーマチェックは通過したが、後続のプロセスでエラーを引き起こした出力をログから探す。
  • 不正な入力を与えて、エージェントが安全に失敗（fail safely）することを確認する。
  • 特定のドキュメントに何が起きたかを5分以内に回答できるようにしておく。
  • エージェントに必要最小限の権限しか与えられていないことを確認する。

私たちのテスト合格率は94%でした。初月のエラー率は8%でした。

確信度の追加、実世界でのテスト、そしてログの改善を行った後、エラー率は1.4%まで低下しました。

問題はテストのスコアではなく、テストの範囲（スコープ）でした。

Source: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

Optional learning community: https://t.me/GyaanSetuAi