レイヤー 4: パターンを分析し、エージェントを継続的に改善する

個々のテストケースの失敗をトリアージした後、修正を加えてもエージェント全体のパフォーマンスにほとんど改善が見られないことがあります。 この結果は、無関係な失敗の集合ではなく、根本的な問題が存在することを示していることが多いです。

パターン分析は、複数の失敗したテストケースを横断して、繰り返されるシグナルや共通の根本原因を特定するのに役立ちます。 パターン分析を活用し、各失敗を個別に修正するのではなく、失敗グループをまとめて対処する変更に注力しましょう。

重要

失敗トリアージと修正対応の変更を適用を完了した後に、このガイダンスを活用してください。 パターン分析は、少なくとも 5 件の失敗をトリアージした後に最も有効です。

パターン分析を利用するタイミング

パターン分析は、以下のいずれかの条件が見られる場合に最も有効です。

  • 多数の失敗が同じ評価セットで発生する場合。
  • 似たような症状で失敗が繰り返される場合。
  • 個々のテスト ケースの改善点が全体のスコアを動かさない場合。
  • ある領域の改善が別の領域で回帰を引き起こす。

このような場合、失敗を個別に修正するのは非効率的です。 パターン分析は、失敗に共通するパターンを特定し、根本原因に対応するために役立ちます。

集中分析

個々の失敗を分類した後、全体の中からパターンを探しましょう。

パターン 想定される原因 おすすめのアクション
80% 以上の失敗は評価設定の問題である 評価スイートの調整が必要であり、エージェントの変更ではありません エージェントの反復を一時停止する まず評価の質を見直して修正し、その後、正確な結果を得るために再実行してください。
80% 以上の失敗は、ある分野のエージェント設定の問題 (例えば、すべて知識関連) によるものです 体系的なエージェント構成のギャップ その領域に是正対応を重点的に行ってください。 この問題はしばしばアーキテクチャ上の問題 (例えばサポート情報ソースの構造) であり、個別のテスト ケースの修正ではありません。
80% 以上の失敗がプラットフォームの制限によるものである エージェントがプラットフォームの限界に達した エージェントの範囲を再評価します。 プラットフォーム チームにエスカレーションします。 適切な場合は閾値を調整したり、影響を受けた項目を既知の制限として扱う。
失敗は根本原因の種類ごとに均等に分散している 単一のシステム的な問題はない 修復マッピングを用いて個別に対応を継続してください。

集中分析の方法

  1. 根本原因タイプごとに分類した失敗を集計してください:

    • 評価設定の問題
    • エージェント構成の問題
    • プラットフォームの制限
    • 未分類

  2. 各タイプごとに割合を計算してください。

  3. もし、いずれかのタイプが 80％ 以上となった場合 (全体的な問題を示している)、個別のケースではなく、カテゴリ全体を見直してください。

  4. もしエージェントの構成上の問題が特定の品質シグナルに集中している場合 (例えば、6 つのうち 5 つが知識グラウンディング)、そのパターンはアーキテクチャ上の根本原因を示します。

シグナル横断パターン

失敗が複数の評価セットにわたって発生する場合、共通の根本原因を示すことが多いです。 以下のパターンを探してください:

パターン 想定される原因 調査すべき内容
事実の正確さと知識の根拠の両方が失敗している サポート情報ソースの問題 (誤っている、欠落している、アクセスできない、または情報が古い) 知識構成、インデックス状況、コンテンツの最新性
ツール呼び出しとトリガー ルーティングの両方が失敗する オーケストレーション構成の問題: トピックとツールが正しく連携されていない トピックのツールへのルーティング方法を確認する 切断されたフローや誤設定されたフローがないか確認します。
トーンは不十分だが、精度は基準を満たしている エージェントは正解を得ているが、適切に伝えていない プロンプトの書き方の指示に注力する。精度面の仕組みは十分に機能しています。
安全性は合格だが、正確性が不合格 エージェントが過度に制約されている可能性があり、慎重になりすぎて、本来答えるべき場面で回答を拒否することがある 正当な回答を妨げる過度に広い制限がないか、安全指示の内容を見直してください。
エッジケースを除いてすべて合格 主要な挙動は安定している マージンでの堅牢性の拡大に注力しましょう。このパターンは良い兆しです。
正確性は向上していますが、トーンは低下している 指示の競合 — 新しい正確性の指示がトーンの指示を押しのけている可能性があります 最近のプロンプトの変更を確認し、「指示予算」を念頭に置いてください。
複数の評価セットが同時に劣化している おそらく単一の根本原因が広範囲に影響している 最近のシステム プロンプトの変更、サポート情報ソースの更新、またはプラットフォーム モデルの更新がないか確認してください。

シグナル横断パターンの対処方法

  1. 共通の根本原因を特定する: もし 2 つのシグナルが同時に失敗した場合、サポート情報ソース、プロンプト セクション、ツール構成などの共通の依存関係がある可能性が高いです。
  2. 共通の依存関係を修正する: 各信号を個別に修正しないようにしてください。
  3. 両方の評価セットを再実行する: 修正後に両方のセットが改善されているか確認してください。
  4. 一方のみが改善した場合、両者の根本原因は共通ではありません。 残りの失敗は個別にトリアージします。

反復ごとのトレンド分析

反復サイクルを通じてスコアがどのように変化するかを追跡し、改善戦略が効果があるかを把握しましょう。

傾向 解釈 アクション
反復を経てスコアが向上する 是正措置が機能している 閾値に達するまで継続します。
変更後もスコアが横ばいのまま 修復は根本原因を狙っているわけではありません 再トリアージ。根本原因の分類が間違っている可能性があります。
変更後のスコア悪化 回帰 ― 変更によって何かが壊れた 変更をロールバックします。 何が後退したのか、なぜそうなったのかを調査してください。
一方の評価セットは改善し、もう一方は悪化しています トレードオフ ― 一つのディメンションを改善すると別のディメンションが悪化する 多くの場合、命令の競合が原因で発生する結合を調査します (体験 3 を参照)。
評価ごとにスコアが変動する (±10% 以上の変動) グレーダーの不安定性やエージェントの非決定性 まずグレーダーの信頼性を検証してください (グレーダー検証を参照)。 各反復につき少なくとも 3 回は実行してください。

トレンド ビューの構築

各反復ごとに以下を記録してください:

  • 日
  • 変更内容
  • 評価セット
  • 変更前スコア
  • 次のスコア
  • 差分

この情報は次のことに役立ちます:

  • 閾値に向かって収束していることを確認する
  • 回帰を迅速に特定する
  • 早期に停滞を検出する (体験 2)

失敗を記録する

構造化された失敗記録は、反復サイクルを通じて組織的な知識を構築します。 記録がなければ、チームはしばしば同じ調査作業を繰り返します。

なぜ失敗を記録するのか

  • 将来のトリアージを迅速化する: 既知の失敗パターンを即座に認識します。
  • エスカレーションの根拠を構築する: プラットフォームの制限事項の記録を蓄積し、プラットフォーム チームに対して強力なケースを作成します。
  • チーム学習を促進する: 複数のメンバーが同じエージェントに取り組む際、ログによって重複調査を防ぐことができます。
  • 既知の課題を追跡する: 「修正しない」または「既知の制限」と分類された失敗も忘れずに追跡してください。

失敗ログのテンプレートを使用する

チームの規模やプロセスの成熟度に応じて、失敗ログ テンプレートを利用して、簡易もしくは詳細な形式で失敗を記録します。

記録事項

最低限、各トリアージ済みの失敗について以下の情報を記録してください:

  1. どのテスト ケース が失敗したか。
  2. どのような根本原因の種類に分類したか。
  3. 具体的に何がうまくいかなかったのか。
  4. 修正のために何を変えたのか。
  5. 修正が成功したかどうか。

未解決の失敗については、以下も記録してください:

  • これまでに試したこと。
  • なぜそれが未解決のままなのか。
  • 再評価のタイミング (例:「プラットフォーム更新 X 後」)。

継続的な改善ワークフロー

各トリアージおよび是正サイクルの後にこのチェックリストを使って、結果と次の手順を記録したか確認してください。

反復後チェックリスト

サインアップできましたか? タスク
✓ トリアージ済みの失敗をすべて失敗ログに記録してください。
✓ 根本原因の集中を特定して記録してください。
✓ シグナル横断パターンを確認します。
✓ トレンド追跡のためにスコアを記録します。
✓ 既知の制限を回避策で記録してください。
✓ 残された失敗に基づいて次の反復の優先順位を特定します。
✓ 再実行スケジュール (どの評価セットを、いつ) を設定する。

反復をやめるタイミング

終了する条件:

  • すべての評価セットが閾値を超えています。
  • 既知のギャップを記録しました。
  • スコアが安定している (< 5% の変動)。
  • シグナルのブロックに関するエージェント設定に未解決の問題はありません。

反復を停止しない条件:

  • 継続的な失敗を調査しなかった。
  • 閾値を達成するために難しいテスト ケースを除外した。
  • プラットフォームの制限を記録しなかった。

詳細については、反復完了のタイミングの判断をご参照ください。

次の手順

  • フレームワークの層が実際のシナリオでどのように連携して機能するかを示した実践例をご確認ください。
  • 失敗ログテンプレートを使って調査結果を追跡しましょう。
  • Last updated on