レイヤー 2: エージェント失敗のトリアージ

評価スコアを解釈し、重点分野を特定した後、なぜ個々のテスト ケースが失敗したのか、誰が対応すべきかを判断してください。

本記事はテスト ケース レベルでの失敗の診断のための構造化された指針を提供します。 根本原因を分類し、エージェント、評価、インフラの問題を区別し、適切な次の行動を選ぶのに役立ちます。

準備

失敗トリアージを始める前に:

1. スコア解釈および準備度評価を完了し、どの評価セットに注意が必要かを特定してください。
2. 準備状況とリスクに基づいて、最優先度の高い故障に集中しましょう。

トリアージ前チェック: インフラの健全性を確認する

個々の失敗を診断する前に、評価実行中に依存関係が正常であったかを確認してください。 インフラストラクチャの問題は、エージェントや評価の問題のように見える障害を引き起こすことがありますが、どちらにも関係ありません。

次の条件を確認します。

• サポート情報ソースがアクセス可能で、完全にインデックス化されている。
• API バックエンドやコネクタがエラーやタイムアウト、レート制限応答を返さないこと。
• 認証トークンが実行中有効であること。
• 評価環境が意図されたエージェント構成に一致していること。

依存関係が正常でない場合は、問題を修正し、評価を再度実行してから次に進んでください。 異常な実行から結果をトリアージすると、不正確な結論が生じる可能性があります。

手順0: 失敗の優先順位付け

個別のテスト ケースをトリアージする前に、まずどこに注力するか決定してください。

失敗の優先順位は以下の通りです:

失敗が多数ある場合 (例: 15 件以上)、すべてを個別にトリアージする必要はありません。 スコアが最も低い評価セットから始め、いくつかの失敗を手動で確認してください。 もし根本原因が共通していれば、それを修正することで多くの失敗をまとめて解決できます。

失敗したテストの品質シグナルを特定する

評価結果で失敗したテスト ケースが示されていても、品質シグナルが明確に特定できない場合は、評価セットと採点方法を用いてシグナルを推論してください。

以下にその例を示します。

• 評価セットは、安全性、グラウンディング、ツール使用などの能力領域を示します。
• キーワード マッチやルーブリックベースのスコアリングなどの採点方法は、より詳細なコンテキストを提供します。

意図された品質信号を特定することで、最も関連性の高い診断質問を選ぶことができます。

手順 1: 評価セットアップを検証する

各失敗について、エージェントの実際の応答、期待値、評価方法を手動で確認してください。

以下の質問を順番に進めてください。 結果が出たらやめてください。

1. エージェントの応答は受け入れ可能でしょうか? 実際のユーザーは、評価に失敗してもこの回答に満足するでしょうか？

   • はいの場合、評価設定に問題があります。グレーダーまたは期待される値が間違っています。
   • いいえの場合、次の質問に進んでください。

2. 期待される回答はソースに対して最新かつ正確ですか?

   • はいの場合は、次の質問に進んでください。
   • いいえの場合、評価設定に問題があります。期待される回答が古いか間違っています。

3. テスト ケースは現実的なユーザー入力を反映していますか?

   • はいの場合は、次の質問に進んでください。
   • いいえなら、評価設定に問題があります。テスト ケースが非現実的です。

4. 合理的な代替応答が正解となり得る場合でも、グレーダーがそれを許容していないことはありますか?

   • はいの場合、評価設定に問題があります。グレーダーが厳格すぎて有効なバリエーションを考慮していません。
   • いいえの場合、次の質問に進んでください。

5. 評価方法はテスト対象に適していますか?

   • はいの場合、その評価は有効です。 手順 2: エージェントの診断へ進みます。
   • いいえの場合、評価セットアップに問題があります。評価方法はこの品質シグナルに適していません。

応答の受容性の判断

以下のシグナルを使って、エージェントの応答が許容されるかどうかを判断してください:

• 同じ重要な事実、異なる表現 → 多くの場合受容可能 (採点者が厳しすぎる可能性がある)。
• ソースに記載されている重要な情報が欠落している→ 多くの場合、受容不可。
• 「十分かどうか」の閾値が曖昧 → 受け入れ基準が不明確である可能性があります (手順 4 にフラグ付け)。

判断に迷う場合は、期待される答えだけでなく、実際の内容を元のソースと照合してください。

これらの指標は判断の参考になりますが、判断を置き換えるものではありません。

一般的な評価セットアップの失敗タイプ

グレーダーの検証

グレーダーの信頼性は信頼できるトリアージの前提条件です。 グレーダー自体が信頼できない場合、関与したすべての失敗を誤判定してしまいます。

グレーダーの信頼性を検証するには:

1. 手動レビューで合否が明確なテスト ケースを 5～10 件選びます。
2. 評価を実行し、グレーダーの出力と手動の判定を比較してください。
3. グレーダーが 20% 以上のケースで判定が一致しない場合は、エージェントのデバッグを行う前にグレーダーを再調整してください。

グレーダーの点検が必要な兆候:

• 同じテスト ケースで、実行ごとに判定が異なります。
• モデル ベースの採点を使用する評価セットでは失敗が集中する一方で、決定論的手法では合格します。
• グレーダーは、エージェントの応答を確認しても再現できない問題を指摘します。

グレーダー再調整のオプション:

• 可能な限り決定論的手法を使用してください。
• ルーブリックに明確な「許容可能」と「許容不可」の例を追加してください。
• キーワード セットを拡大し、同義語や適切な言い換えを含めるようにします。
• セマンティック同等性のチェックには、意味の比較をキーワード一致 (すべて) の代わりに使用してください。

手順 2: エージェントを診断する

この時点で評価は有効であり、エージェントは誤った応答を生成しました。 エージェント設定で何が問題だったのかを診断してください。

事実の正確性や知識の根拠に関する失敗がないか確認する

ツール呼び出しの失敗を確認する

トリガー ルーティングの失敗を確認する

トーンや応答品質の不具合を確認する

安全と境界の失敗を確認する

エスカレーションと正常なエラーの確認

診断後、失敗パターンを根本原因ごとに修正戦略にマッピングします。

手順 3: プラットフォームの制限を特定する

評価が正しく、合理的な設定変更で結果が改善しない場合、問題はプラットフォームの制限かもしれません。

プラットフォーム制限指標

プラットフォーム制限のアクション パス

1. 制限事項を明確に記録してください (何が失敗したか、試したこと、設定が原因ではない証拠など)。
2. 可能な場合は回避策を適用してください (例: 検索性を向上させるためにソース ドキュメントを再構成する)。
3. テスト ケースを既知の制限としてマークするか、無関係な進行を妨げないように閾値を調整してください。
4. 証拠を添えてプラットフォーム チームにエスカレーションします。
5. プラットフォームの機能が更新された際に再評価するため、失敗ログで項目を追跡してください。

分類後は、プラットフォームの制限への対応に関する回避策やエスカレーション ガイダンスを確認します。

失敗がフレームワークに合わない場合

一部の失敗は単一の根本原因タイプにはっきりと分類できない場合があります。 次のような例がよく見られます。

• バックエンド データ品質の問題: サポート情報ソースの内容は実質正しいが、曖昧に書かれているため、エージェントも評価も間違っていません。
• 断続的なインフラ問題: ネットワークのタイムアウト、API レート制限、および再現性のないコネクタ問題。
• モデル バージョンの変更: 開始しなかったプラットフォーム モデルのアップデート後にエージェントの挙動が変わりました。
• 曖昧なテスト ケース: シナリオが曖昧で、合理的な人の間でも正解について見解が異なります。

推奨される対応: 観察した内容 (障害、エージェントの応答、確認した事項) を記録してください。 その項目を失敗ログに「未分類」として記録してください。 失敗が再発した場合、追加の証拠によって分類可能になることがよくあります。

複合原因への対応

単一の失敗に複数の根本原因が関与することもあります。 以下にその例を示します。

• 期待される回答がやや古い (評価設定) ことと、サポート情報ソースが不完全 (エージェント設定) であることによる事実の正確性の失敗。
• ツールの説明が曖昧 (エージェント構成) であり、かつオーケストレーションが条件付きツール呼び出しをサポートしていない (プラットフォーム制限) 場合のツール呼び出し失敗。

推奨方法: 失敗ごとにトリアージ全体を実施します。 複数の根本原因タイプが該当する場合は、優先順位に従って対処してください:

1. まず評価を修正し、エージェントの変更が実際に効果を発揮するかどうかを正確に把握できるようにします。
2. エージェントの設定を修正して、残された障害が本当にプラットフォームの問題かどうかを判断してください。
3. 1 と 2 が解決した後に、プラットフォームの制限を記録します。

変更ごとに影響を受けたテスト ケースを再実行してから進めてください。

マルチターン会話失敗の対応

マルチターン シナリオでは、失敗はターン間でのみ現れます。

マルチターン問題を疑うタイミング

• エージェントは初期のターンでは正確に応答しますが、後のターンで自分の回答と矛盾します。
• エージェントは後のターンで前のツール呼び出しや知識取得のコンテキストを失います。
• エスカレーションのタイミングは、会話履歴全体を考慮したときにのみ適切に判断できます。
• 会話が長くなるにつれて、エージェントのトーンは徐々に低下します。
• エージェントはユーザーが既に提供した情報を再度求めます。

追加の診断質問

マルチターン問題の修正ガイダンス

• コンテキスト損失: 会話状態の設定を確認してください。 ツールの出力や重要な事実がターン間で保持されるようにしてください。
• 矛盾点: 一貫性を保つよう指示を追加します (例:「この会話における前回の応答と一貫性を保ってください」)。
• 再質問: プラットフォームの会話メモリ構成を確認してください。
• 長い会話の劣化: 会話要約やコンテキストの剪定戦略を検討します。

合格したテスト ケースの検証 (誤検知チェック)

このフレームワークは失敗したテスト ケースに焦点を当てています。 しかし、誤って合格したテスト ケースは隠れた品質のギャップを生むことがあります。

推奨事項: 各評価実行で合格したテスト ケースの 5〜10% を手動でレビューし、特に以下の場合に行うことを推奨します。

• モデルベースのグレーディング (誤検知のリスクが高い)
• 主観的なシグナル (トーン、有用性)
• 以前失敗していたが変更後にパスしたテスト

もし誤検知が見つかったら、グレーダーを再調整します。

次の手順

失敗トリアージを完了した後:

• レイヤー 3: 失敗パターンを修復戦略にマップする を使用します。
• レイヤー4: パターンを分析してシステム上の問題を特定します。
• フレームワークの層が実際のシナリオでどのように連携して機能するかを示した実践例をご確認ください。