エージェントの挙動は本番環境で初めてわかる

**タイトル: エージェントが本番環境で何をするかは、実際に投入してみるまでわからない** 従来のソフトウェアを本番環境にリリースするとき、何が起こるかはかなり予想がつきます。ユーザーはボタンをクリックし、フォームに入力し、予め決められたパスをたどります。テストスイートはコードパスの80〜90%をカバーし、監視ツールはエラーレート、応答時間、データベースクエリといったおなじみの項目を追跡します。何かが壊れたときは、スタックトレースやログを確認します。 エージェントの動作はこれとは異なります。エージェントは自然言語の入力を受け付け、可能なクエリの範囲は無限です。エージェントは大規模言語モデルによって駆動されており、プロンプトの微妙な違いに敏感で、同じ入力に対しても異なる出力を生成することがあります。さらに、開発時に完全に予測するのが難しい、多段階の推論チェーン、ツール呼び出し、検索操作を通じて意思決定を行います。 これは、エージェントのための本番環境監視には、従来のオブザーバビリティとは異なる機能が必要であることを意味します。この記事では、エージェントのオブザーバビリティがなぜ独自の課題を抱えるのか、何を監視すべきか、そして大規模にエージェントを展開しているチームから私たちが学んだことについて探っていきます。 **エージェントが従来のソフトウェアと異なる理由** エージェントを本番環境に展開しているチームと協業する中で、監視アプローチに影響を与える2つの重要な違いを観察しました。 **エージェントは無限の入力空間を持つ** 従来のソフトウェアは、有限で制約された入力空間を持ちます。ユーザーはボタン、ドロップダウン、フォーム、特定のフォーマットを持つAPIコールを通じて操作します。決済フローを設計するとき、画面の正確な順序と可能なユーザー操作を知っています。失敗モードを列挙できるため、エラー処理は網羅的になり得ます。 これに対してエージェントは、主な入力として自然言語を受け付けます。自然言語には有効な入力の固定セットがありません。ユーザーは同じリクエストを無数の方法で表現できます。曖昧だったり具体的だったり、形式的だったりカジュアルだったり、1つのメッセージに複数の意図を組み合わせたり、1つのリクエストを複数のターンにまたがって伝えたりします。 カスタマーサポートエージェントを考えてみましょう。従来のソフトウェアでは、ユーザーは「注文履歴」に移動し、注文をクリックし、「返金をリクエスト」をクリックし、最後に事前定義されたオプションがあるフォームに入力します。パスは固定されており、テスト可能です。 エージェントの場合、ユーザーは次のように言うかもしれません： 「注文を返品したい」 「先週買った靴のお金を返してもらうのを手伝ってくれますか？」 「届いた商品が破損しているんですが、どうすればいいですか？」 「注文番号 #12345 返金お願いします」 これらはすべて同じ根本的な意図を表していますが、エージェントはそのバリエーションを理解し、関連情報を抽出し、適切なアクションを決定する必要があります。この無限の入力空間は、実際のユーザーがエージェントと対話し始めるまで、エージェントがどのように使用されるかを完全に予測できないことを意味します。 **LLMは小さな変化に対して頑健ではない** 2つ目の重要な違いは、LLMがプロンプトへの敏感性と非決定的な振る舞いを示すことです。入力の小さな変化でも異なる出力につながることがあり、同じ入力でも異なる結果を生むことがあります。 これにはいくつかの理由があります。LLMは生成中に確率的サンプリングを使用するため、ばらつきが生じます。最も重要なのは、LLMが言い回し、文脈、指示の順序の微妙な変化に対して異なる反応を示すことです。 この非決定性は、開発中に観察した振る舞いが、本番環境で起こることと一致しない可能性があることを意味します。テストでは確実に動作したプロンプトが、遭遇しなかったエッジケースで失敗するかもしれません。評価中にツールを正しく使用したエージェントが、言い回しがわずかに異なるユーザークエリに対して、時々間違ったツールを選択するかもしれません。 **エージェントのための本番環境監視は異なる** 従来のアプリケーションパフォーマンス監視（APM）ツールは、レイテンシ、トラフィック、エラー、飽和度といったメトリクスに焦点を当てます。それらはHTTPリクエスト、データベースクエリ、システムリソースを追跡します。これらは、可能なコードパスがわかっている構造化された決定的システムのために設計されています。 エージェントのオブザーバビリティには、それらを取り巻くシステムメトリクスだけでなく、入力と出力そのものを監視することが必要です。 **自然言語インタラクションの監視** エージェントがユーザーと会話しているとき、主要なシグナルは会話そのものの中に存在します。以下をキャプチャする必要があります： **完全なプロンプト-レスポンスのペア**: リクエストが発生したことだけでなく、ユーザーが何を尋ね、エージェントが何と応答したか **マルチターンの文脈**: エージェントは1つの会話の一部として複数のやり取りにまたがって動作することが多いため、関連するインタラクションをグループ化する必要がある **エージェントの軌跡と中間ステップ**: エージェントは最終的な出力に到達するために多段階のパスをたどり、ツールを呼び出し、選択肢を通じて推論することができます。最終的な応答だけでなく、軌跡の各ステップの可視性が必要です これは従来のロギングとは質的に異なります。従来のWebリクエストは「POST /api/checkout 200 OK 342ms」と要約されるかもしれません。エージェントのインタラクションは、潜在的に数十のステップを含む自然言語の会話であり、それがうまくいったかどうかという問いは、ステータスコードからは答えられません。 **大規模な人間の判断の課題** 自然言語のインタラクションは、適切に評価するために人間の判断を必要とすることがよくあります。この応答は役に立ちますか？エージェントはユーザーの意図を理解しましたか？口調は適切でしたか？関連する情報を検索しましたか？ 開発中はこれは管理可能です。トレースを手動で確認し、プロンプトを調整し、反復します。しかし本番環境では、数千、数百万のインタラクションを処理しているかもしれません。人間のレビュアーは1時間に50〜100のトレースを有意義に評価できますが、1日1,000リクエストの場合、完全な手動レビューには毎日10〜20時間の専任の人間の時間が必要になります。これは重要な疑問を提起します：手動レビューがスケールしないとき、どうやって人間の知性を本番データに適用するのか？ 私たちは、2つの相補的なアプローチが効果的であることを発見しました。 **構造化された人間のレビューのためのアノテーションキュー** アノテーションキューは、人間のレビューを可能な限り効率的にするのに役立ちます。レビュアーに本番ログを探し回らせるのではなく、アノテーションキューは事前定義された評価基準を用いて、構造化されたフォーマットで特定の実行を提示します。 効果的なアノテーションキューシステムでは、以下が可能です： **特定のトレースをレビューのためにルーティングする**: すべてをレビューする代わりに、特定のサブセット（否定的なフィードバックがあった実行、高コストのインタラクション、特定の時間枠からのクエリなど）をキューに送る **レビュー基準を定義する**: レビュアーが正確に何を評価すべきか（関連性、正確性、口調、安全性）を知るための評価基準を設定する **チームコラボレーションを可能にする**: 複数のレビュアーが進捗追跡と役割割り当てを行いながらキューを処理できる **フィードバックループを作成する**: レビューされたデータに修正を加えて注釈を付け、評価データセットに追加できる アノテーションキューは、新しい失敗モードを理解しようとしたり、評価者のためのトレーニングデータを構築したり、専門的なクエリに関する専門家のドメインフィードバックを得たりしようとするときに特に価値があります。 **考慮すべきトレードオフ**: アノテーションキューには専任のレビュアーの時間が必要であり、改善サイクルに遅延をもたらす可能性があります。包括的なカバレッジを試みるよりも、特定の高価値なトレースに焦点を当てたときに最も効果的であることがわかりました。 **人間の判断の代理としてのLLM** 2つ目のアプローチは、人間の判断をスケールさせるためにLLM自体を使用することです。LLMは完璧な評価者ではありませんが、人間にはできない規模で多くの品質次元を評価できます。 特に、オンライン評価者を設定して、すべての実行またはサンプリングされたサブセットに対して、本番トラフィック上で自動的に実行させることができます。これらの評価者は以下をチェックできます： **参照不要の品質メトリクス**: 正解の答えを必要としない、一貫性や口調などの属性 **安全性とコンプライアンス**: 応答に機密情報が含まれているか、ポリシーに違反しているか、有害な振る舞いを示しているか **フォーマット検証**: 出力が期待される構造に従っているか、必要な要素を含んでいるか **トピック分類**: ユーザーがどのようなカテゴリのリクエストをしているか LLMは、人間のレビューを超える規模で自然言語を評価できます。人間が数十のトレースをレビューする間、LLM評価者は数千を評価し、潜在的な問題にフラグを立て、集計メトリクスを提供できます。 しかし、LLMベースの評価者には限界があります。

エージェントの挙動は本番環境で初めてわかる

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト