AIエージェントが実験的なプロトタイプから実際のアプリケーションへと移行する中で、その挙動を理解し、パフォーマンスを監視し、出力を体系的に評価する能力が重要になります。
このレッスンを終えると、以下のことができるようになります:
このレッスンの目的は、「ブラックボックス」のようなエージェントを透明性のある、管理可能で信頼できるシステムに変えるための知識を提供することです。
注: 安全で信頼できるAIエージェントを展開することが重要です。信頼できるAIエージェントの構築のレッスンもぜひご覧ください。
LangfuseやAzure AI Foundryのような可観測性ツールは、通常、エージェントの実行をトレースとスパンとして表現します。
可観測性がない場合、AIエージェントは「ブラックボックス」のように感じられます。その内部状態や推論が不透明で、問題の診断やパフォーマンスの最適化が困難です。一方、可観測性を備えたエージェントは「ガラスボックス」となり、信頼を構築し、意図した通りに動作することを保証するために必要な透明性を提供します。
AIエージェントを本番環境に移行する際には、新たな課題や要件が生じます。可観測性はもはや「あると便利」なものではなく、重要な能力となります。
エージェントの挙動を監視し理解するためには、さまざまな指標やシグナルを追跡する必要があります。具体的な指標はエージェントの目的によって異なる場合がありますが、いくつかは普遍的に重要です。
以下は、可観測性ツールが監視する最も一般的な指標の一部です:
レイテンシー: エージェントの応答速度はどれくらいか?長い待ち時間はユーザー体験に悪影響を与えます。タスクや個々のステップのレイテンシーをトレースして測定する必要があります。例えば、すべてのモデル呼び出しに20秒かかるエージェントは、より高速なモデルを使用するか、モデル呼び出しを並列実行することで高速化できる可能性があります。
コスト: エージェントの実行あたりの費用はどれくらいか?AIエージェントは、トークンごとに課金されるLLM呼び出しや外部APIに依存します。頻繁なツール使用や複数のプロンプトは、コストを急速に増加させる可能性があります。例えば、エージェントが品質をわずかに向上させるためにLLMを5回呼び出す場合、そのコストが正当化されるか、呼び出し回数を減らすか、より安価なモデルを使用するべきかを評価する必要があります。リアルタイム監視により、予期しないスパイク(例: 過剰なAPIループを引き起こすバグ)も特定できます。
リクエストエラー: エージェントが失敗したリクエストの数はどれくらいか?これにはAPIエラーやツール呼び出しの失敗が含まれます。本番環境でこれらに対してエージェントをより堅牢にするために、フォールバックやリトライを設定できます。例えば、LLMプロバイダーAがダウンしている場合、バックアップとしてLLMプロバイダーBに切り替えることができます。
ユーザーフィードバック: ユーザーからの直接的な評価は貴重な洞察を提供します。これには、明示的な評価(👍/👎、⭐1-5など)やテキストコメントが含まれます。一貫して否定的なフィードバックがある場合、それはエージェントが期待通りに機能していない兆候です。
暗黙的なユーザーフィードバック: ユーザーの行動は、明示的な評価がなくても間接的なフィードバックを提供します。これには、即座の質問の言い換え、繰り返しのクエリ、リトライボタンのクリックなどが含まれます。例えば、ユーザーが同じ質問を繰り返し尋ねる場合、それはエージェントが期待通りに機能していない兆候です。
正確性: エージェントが正しいまたは望ましい出力を生成する頻度はどれくらいか?正確性の定義はさまざまです(例: 問題解決の正確性、情報検索の正確性、ユーザー満足度)。最初のステップは、エージェントにとって成功が何を意味するかを定義することです。正確性は、自動チェック、評価スコア、タスク完了ラベルを通じて追跡できます。例えば、トレースを「成功」または「失敗」としてマークすることができます。
自動評価指標: 自動評価を設定することも可能です。例えば、エージェントの出力が役立つか正確かどうかをスコアリングするためにLLMを使用できます。また、エージェントのさまざまな側面をスコアリングするのに役立つオープンソースライブラリもいくつかあります。例えば、RAGエージェント向けのRAGASや、有害な言語やプロンプトインジェクションを検出するLLM Guardなどです。
実際には、これらの指標を組み合わせることで、AIエージェントの健全性を最も包括的に把握できます。この章の例のノートブックでは、これらの指標が実際の例でどのように見えるかを示しますが、まずは典型的な評価ワークフローについて学びます。
トレースデータを収集するには、コードを計測する必要があります。目標は、エージェントコードを計測して、可観測性プラットフォームでキャプチャ、処理、可視化できるトレースや指標を生成することです。
OpenTelemetry (OTel): OpenTelemetryは、LLMの可観測性における業界標準として浮上しています。これは、テレメトリーデータを生成、収集、エクスポートするためのAPI、SDK、ツールのセットを提供します。
既存のエージェントフレームワークをラップし、OpenTelemetryスパンを可観測性ツールに簡単にエクスポートできる計測ライブラリが多数あります。以下は、OpenLit計測ライブラリを使用してAutoGenエージェントを計測する例です:
import openlit
openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)
この章の例のノートブックでは、AutoGenエージェントを計測する方法をデモンストレーションします。
手動スパン作成: 計測ライブラリは良いベースラインを提供しますが、より詳細またはカスタムの情報が必要な場合もあります。手動でスパンを作成して、カスタムアプリケーションロジックを追加することができます。さらに、カスタム属性(タグやメタデータとも呼ばれる)で自動または手動で作成されたスパンを強化することも可能です。これらの属性には、ビジネス固有のデータ、中間計算、デバッグや分析に役立つコンテキスト(例: user_id
、session_id
、model_version
)などが含まれます。
Langfuse Python SDKを使用してトレースとスパンを手動で作成する例:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
可観測性は指標を提供しますが、評価はそのデータを分析し(およびテストを実施し)、AIエージェントがどれだけうまく機能しているか、どのように改善できるかを判断するプロセスです。言い換えれば、トレースや指標を取得した後、それを使ってエージェントを評価し、意思決定を行う方法です。
AIエージェントは非決定論的であり、更新やモデルの挙動の変化を通じて進化することが多いため、定期的な評価が重要です。評価を行わなければ、「スマートエージェント」が実際にうまく機能しているのか、それとも性能が低下しているのかを知ることはできません。
AIエージェントの評価には、オフライン評価とオンライン評価の2つのカテゴリがあります。どちらも価値があり、補完し合うものです。通常、最低限必要なステップとしてオフライン評価から始めます。
これは、制御された環境でエージェントを評価するもので、通常はテストデータセットを使用し、ライブユーザークエリは使用しません。期待される出力や正しい挙動が分かっているデータセットを使用し、それに対してエージェントを実行します。
例えば、数学の文章題エージェントを構築した場合、既知の答えを持つ100問のテストデータセットを使用するかもしれません。オフライン評価は、開発中に行われることが多く(CI/CDパイプラインの一部になることもあります)、改善を確認したり、性能低下を防ぐために使用されます。その利点は、再現可能であり、正解があるため明確な正確性指標を得られることです。また、ユーザークエリをシミュレートし、エージェントの応答を理想的な答えと比較したり、前述の自動指標を使用して測定することもできます。
オフライン評価の主な課題は、テストデータセットが包括的で関連性を保つことを保証することです。エージェントは固定されたテストセットでうまく機能しても、本番環境では非常に異なるクエリに直面する可能性があります。そのため、テストセットを新しいエッジケースや実世界のシナリオを反映した例で更新し続ける必要があります。小規模な「スモークテスト」ケースと大規模な評価セットを組み合わせると効果的です: 小規模なセットは迅速なチェックに、大規模なセットは広範な性能指標に役立ちます。
これは、ライブの実世界環境、つまり本番環境での実際の使用中にエージェントを評価することを指します。オンライン評価では、エージェントのパフォーマンスをリアルタイムで監視し、結果を継続的に分析します。
例えば、成功率、ユーザー満足度スコア、またはライブトラフィックにおける他の指標を追跡するかもしれません。オンライン評価の利点は、ラボ環境では予期できないことを捉えられることです。時間の経過とともにモデルのドリフト(入力パターンの変化に伴うエージェントの効果の低下)を観察したり、テストデータには含まれていなかった予期しないクエリや状況を検出できます。本番環境でのエージェントの挙動を真に把握することができます。
オンライン評価では、前述のように暗黙的および明示的なユーザーフィードバックを収集したり、シャドウテストやA/Bテスト(新しいバージョンのエージェントを並行して実行し、古いバージョンと比較する)を実施することが含まれる場合があります。課題としては、ライブインタラクションに対する信頼性の高いラベルやスコアを得るのが難しいことがあります。ユーザーフィードバックや下流の指標(例: ユーザーが結果をクリックしたかどうか)に依存することが多いです。
オンライン評価とオフライン評価は相互排他的ではなく、非常に補完的です。
AIエージェントを本番環境で運用する際、問題が発生することがあります。以下は、よくある問題とその解決策の例です。
問題 | 解決策 |
---|---|
エージェントが期待通りに動作しない | - エージェントのプロンプトを見直し、明確で具体的な指示を与えるようにする。 - エージェントの出力を評価するためのシステムを構築する。 |
複雑なタスクでエージェントが失敗する | - 複雑なタスクに特化した大規模モデルを使用する。 - 複雑なタスクに対応するための推論に特化したモデルを使用する。 |
AIエージェントツールの呼び出しがうまくいかない | - エージェントシステム外でツールの出力をテスト・検証する。 - 定義されたパラメータ、プロンプト、ツールの名前を改善する。 |
マルチエージェントシステムが一貫性を欠く | - 各エージェントに与えるプロンプトを見直し、具体的かつ互いに区別できるようにする。 - “ルーティング”やコントローラーエージェントを使用して、適切なエージェントを選択する階層型システムを構築する。 |
これらの問題の多くは、観測性を導入することでより効果的に特定できます。前述したトレースやメトリクスは、エージェントのワークフロー内で問題が発生している箇所を正確に特定するのに役立ち、デバッグや最適化を大幅に効率化します。
AIエージェントを本番環境に展開する際のコスト管理のための戦略を以下に示します。
小規模モデルの使用:
小規模言語モデル(SLM)は、特定のエージェントユースケースで十分な性能を発揮し、コストを大幅に削減できます。前述の通り、評価システムを構築して大規模モデルとの性能比較を行うことで、SLMがユースケースにどれだけ適しているかを理解するのが最善です。例えば、意図の分類やパラメータ抽出のような単純なタスクにはSLMを使用し、複雑な推論には大規模モデルを使用することを検討してください。
ルーターモデルの使用:
類似の戦略として、さまざまなサイズのモデルを使い分ける方法があります。LLM/SLMやサーバーレス関数を使用して、リクエストの複雑さに応じて最適なモデルにルーティングすることができます。これにより、コストを削減しつつ、適切なタスクでの性能を確保できます。例えば、単純なクエリは小型で高速なモデルにルーティングし、複雑な推論タスクには高価な大規模モデルを使用する、といった方法です。
レスポンスのキャッシュ:
よくあるリクエストやタスクを特定し、それらのレスポンスを事前に用意しておくことで、エージェントシステムを通過する類似リクエストの量を減らすことができます。さらに、基本的なAIモデルを使用して、リクエストがキャッシュされたリクエストとどれだけ類似しているかを識別するフローを実装することも可能です。この戦略は、よくある質問や一般的なワークフローに対して、コストを大幅に削減するのに役立ちます。
このセクションのサンプルノートブックでは、観測性ツールを使用してエージェントを監視・評価する方法の例を確認できます。
Azure AI Foundry Discordに参加して、他の学習者と交流したり、オフィスアワーに参加したり、AIエージェントに関する質問に答えてもらいましょう。
免責事項:
この文書は、AI翻訳サービス Co-op Translator を使用して翻訳されています。正確性を追求しておりますが、自動翻訳には誤りや不正確な部分が含まれる可能性があることをご承知ください。元の言語で記載された文書が正式な情報源とみなされるべきです。重要な情報については、専門の人間による翻訳を推奨します。この翻訳の使用に起因する誤解や誤認について、当方は一切の責任を負いません。