レイヤー 1: 評価スコアを解釈し、準備状況を判断する

エージェントの評価を実行した後、通常はスコアは得られるものの、最も重要な質問「そのエージェントは展開の準備ができているか？」に対して即答できません。

このレイヤーでは、個々のテスト ケースの失敗原因を調査する前に、評価スコアの解釈と準備状況の確認に重点を置いています。 スコアを判断基準として使用し、エージェントを展開できるか、反復作業を続けるべきか、あるいは展開をブロックすべきかを判断します。 この手順は、より詳細な分析が必要な箇所を特定するのにも役立ちます。

スコアの解釈の目的

このレイヤーは、以下のような高レベルの準備状況に関する質問への回答に役立ちます:

• エージェントは展開する準備ができていますか？
• そうでない場合、どの分野にまず注力すべきでしょうか？
• さらなるイテレーション作業に進む前に、対処すべきブロック要因はありますか？

この手順は意図的に軽く設計されています。 ほとんどの場合、すでに手元にある評価結果を使用すれば、10～15 分で完了させることができます。

準備

このレイヤーを開始する前に、以下ができていることを確認してください:

• 個々のテストケースの合格の不合格結果。
• 1 つ以上の評価セット (たとえば、安全性、基礎知識、業務上の正確性、ツールの使用など) の総合スコア。

評価結果がまだ得られていない場合は、まず評価セットを実行し、スコアが判明したらこの手順に戻ってください。

評価セット レベルでのスコアの解釈

まずは、個々のテストケースではなく、評価セットのスコアを確認することから始めましょう。

評価セットは、安全性、中核となる業務行動、ナレッジの定着、ツールの活用など、さまざまなリスクや能力領域を表しています。 このレベルでスコアを分析することで、失敗が局所的なものか、それとも組織的なものかを判断するのに役立ちます。

次の質問について考えてみましょう。

• 安全性やコンプライアンスに関するスコアで、しきい値を下回っているものはありますか？
• コアビジネスの評価基準は、最低限の期待値を満たしていますか？
• 重要度に対して、最も弱い評価セットはありますか？

現段階では、根本原因ではなく、シグナルに焦点を当ててください。

合格率を次の 2 つの観点から解釈します:

• 評価セットごと: この割合はテストされている特定の機能にとって何を示していますか？
• 品質のシグナルごと: このパーセンテージは、同じ信号をテストするすべての評価セットで何を示していますか?

合格率が低い場合でも、必ずしもそのエージェントが間違っているとは限りません。 調査が必要なことを示していると捉えてください。 問題は、エージェント、評価環境、あるいはプラットフォームのいずれかにある可能性があります。

リスクに基づいてしきい値を設定する

すべてのエージェントに同じしきい値を適用しないでください。 エージェントのリスクプロファイルに基づいてしきい値を設定します。 以下の要素を考慮します。

リスクベースのしきい値の例

この表はあくまで参考となる目安であり、普遍的な基準ではありません。

これらの例を使用し、それぞれのリスク状況を踏まえて調整してください。

しきい値キャリブレーションの例

以下の例は、中程度のリスクにさらされる顧客対応エージェントに対する、キャリブレーションの一例を示しています。

準備状況を判定する

評価セットの得点を使用して、全体的な準備状況の評価結果を決定します。 一般的な準備状態には、次のようなものがあります:

• ブロック: 安全性、コンプライアンス、あるいは重大な業務上の不具合により、展開が妨げられる。
• 反復処理: エージェントには将来性が感じられるが、重点的な改善が必要です。
• 条件付き展開: 制限がドキュメント化され、監視されている場合にエージェントを展開可能です。
• 展開: このエージェントは、すべての必須評価セットにおいてしきい値を満たしています。

準備態勢の判断は、単一の普遍的なスコアではなく、リスク許容度や利用状況に基づいて行う必要があります。

イテレーションの完了を判断する

以下の基準を使用し、トリアージの段階から展開や監視の段階に移行できるタイミングを判断してください。

イテレーションが完了する条件:

• 調整したしきい値を含め、すべての評価セットがしきい値を上回っている。
• 既知の課題については、責任者と対応スケジュールをドキュメントに明記して記録されている。
• 再実行の結果は一貫性があり、実行間のばらつきは 5% 未満である。
• エージェントの構成に関する問題として分類されているブロッキングの問題が残っていない。

イテレーションが完了していない条件:

• しきい値は満たされているが、残りの不具合の原因は解明されていません。
• スコアが向上したのは、難易度の高いテスト ケースが除外されたからに過ぎない。
• プラットフォームの制限事項について、ドキュメント化されていないが、暗黙のうちに受け入れられている。

スコアにおける非決定性の取り扱い

言語モデルに基づくエージェントや採点システムは、出力結果にばらつきが生じます。 以下の実践方法を取り入れてください:

• 基準を確立する: スコアを基準値として扱う前に、評価セット全体を少なくとも 3 回実行してください。 その平均値を一時的なスコアとして使用してください。 3 回未満の実行では、真のシグナルとノイズを区別することはできません。
• 実行ごとのスコアばらつき: 言語モデルのグレーダーでは 5% 程度のばらつきは正常です。 稼働率の変動が 10% を超える場合は、エージェントの問題と断定する前に、グレーダーの信頼性を調査してください。 詳細については、採点者の検証をご覧ください。
• 是正措置後のスコアの変動を解釈する: テストケースが 30 件未満の評価セットの場合、1 つのテスト ケースが「不合格」から「合格」に変わるだけで、スコアが 3% 以上変動します。 小さな動きを過剰に解釈する必要はありません。 テストケースが 50 件以上の評価セットについては、5% 以上の変化を有意な変化と判断してください。 判断に迷った場合は、評価を 3 回繰り返し実行し、その平均値を基準値の平均と比較してください。
• 不安定なテストケースを特定する (合格することもあれば失敗することもある): 3 回中 2 回合格するテストケースはボーダーラインです。 さらに調査が必要です。 期待値が厳しすぎる (評価設定) のか、それともエージェントが本質的に一貫性を欠いている (エージェントの構成) のか？ エージェントが、互いに異なるがどちらも許容可能な 2 つの応答を生成した場合、評価基準が厳しすぎる場合。

次の手順

スコアを分析し、どこに重点を置くべきかを特定したあとは、次を行います:

• レイヤー 2: エラーをトリアージして、失敗したテスト ケースを診断します。
• 「レイヤー 3: エラーパターンを修復戦略にマッピングする」を使用して、対象を絞った修正を適用します。
• レイヤー4: パターンを分析してシステム上の問題を特定します。
• フレームワークの層が実際のシナリオでどのように連携して機能するかを示した実践例をご確認ください。

失敗しているテストケースが 10 件を超える場合は、個々の失敗の原因を特定する前に、その傾向を分析してください。