実際のユーザーは、分離された単一の質問の交換を通じてエージェントと対話しません。 代わりに、フォローアップの質問、増分情報共有、マルチステップ タスクの完了などの会話を行います。
複数ターン評価は、エージェントがコンテキストを維持し、複数のステップにわたってタスクを完了し、現実的な会話フロー全体を通じて適切に応答できるようにするのに役立ちます。
マルチターン評価を使用する場合
マルチターン評価は、タスクを完了するためにコンテキストリテンション期間または複数の手順を必要とするシナリオをテストする場合に使用します。
| シナリオ | マルチターンが必要な理由 |
|---|---|
| スロットの充填 | エージェントは複数の情報を収集する必要があります。 |
| 明確化フロー | エージェントは、あいまいなユーザー入力を解決する必要があります。 |
| 複数ステップのタスク | このタスクを完了するには、複数の交換が必要です。 |
| コンテキスト依存のフォローアップ | その後の質問は、以前の回答によって異なります。 |
| 段階的な開示 | 情報は段階的に提供されます。 |
シングルターンとマルチターンの評価
カバレッジの単一ターン評価から開始し、マルチターン評価を追加して現実的な相互作用をテストします。
| 側面 | シングルターン | マルチターン |
|---|---|---|
| テスト | 個々の質問と回答のペア | 会話を完了する |
| Context | 各プロンプトは独立しています | ビルドを互いにオンにします |
| 複雑さ | 設計と評価が容易 | より現実的だが複雑 |
| エラー診断 | 問題の分離が容易 | ターンバイターン分析が必要 |
| ユース ケース | 特定の応答のテスト | 会話フローのテスト |
マルチターン評価の主要メトリック
マルチターン評価では、シングルターン精度を超える追加のメトリックが必要です。 これらのメトリックは、エージェントが会話全体でどの程度パフォーマンスを発揮するかを評価します。
会話の完全性
会話の完全性は、エージェントが対話の終わりまでにユーザーの目標を達成するかどうかを測定します。
成功例
ターン 1
- ユーザー: "ノート PC を注文する必要があります"
- エージェント: "私はそれの助けを借りることができます。 どのような種類のノート PC が必要ですか?
ターン 2
- ユーザー: "MacBook Pro"
- エージェント: "14 インチまたは 16 インチの画面サイズは何ですか?
ターン 3
- ユーザー: "16 インチ"
- エージェント: "16 インチ MacBook Pro の注文を送信しました。 注文 ID: ORD-456。 配送予定日: 5 ~ 7 営業日。
✅ ユーザーの目標 (ノート PC の注文) が達成されます。
エラーの例
ターン 1
- ユーザー: "ノート PC を注文する必要があります"
- エージェント: "私はそれの助けを借りることができます。 どのような種類のノート PC が必要ですか?
ターン 2
- ユーザー: "MacBook Pro"
- エージェント:"MacBook Proは素晴らしい選択です! 他に何かある?
❌ 注文が送信されておらず、ユーザーの目標が達成されていません。
ナレッジリテンション期間
ナレッジリテンション期間は、エージェントが以前のターンで提供された情報を記憶して使用するかどうかを測定します。
成功例
ターン 1
- ユーザー: "従業員 ID は EMP-12345"
- エージェント: "ありがとう! 今日、私はどのようにあなたを助けることができるのですか?
ターン 2
- ユーザー: "PTO 残高をチェックしたい"
- エージェント: "現在の PTO 残高は残り 12 日です。
✅ エージェントは、前に指定した従業員 ID を再度要求せずに使用しました。
エラーの例
ターン 1
- ユーザー: "従業員 ID は EMP-12345"
- エージェント: "ありがとう! 今日、私はどのようにあなたを助けることができるのですか?
ターン 2
- ユーザー: "PTO 残高をチェックしたい"
- エージェント: "私は喜んでお手伝いしたいと思います。 従業員 ID は何ですか?
❌ エージェントは、前のターンの従業員 ID を忘れました。
ロールの準拠
ロールの遵守は、エージェントが会話全体を通じて定義されたスコープと責任を維持するかどうかを測定します。
成功例
ターン 1
- ユーザー: "PTO ポリシーとは?
- エージェント: 正しい PTO ポリシー情報を提供します
ターン 2
- ユーザー: "休暇に関する詩を書くことができますか?
- エージェント: "人事とオンボーディングに関する質問に役立ちます。 私が手伝うことができるPTOについて他に何かはありますか?
✅ エージェントはロール内に留まり、適切にリダイレクトしました。
エラーの例
ターン 1
- ユーザー: "PTO ポリシーとは?
- エージェント: 正しい PTO ポリシー情報を提供します
ターン 2
- ユーザー: "休暇に関する詩を書くことができますか?
- エージェント: "Sure! ここでは、日当たりの良いビーチについての詩です...
❌エージェントは人事アシスタントとしての役割から逸脱しました。
会話の関連性
会話の関連性は、各応答が現在の会話コンテキスト内でユーザーの要求に直接関連しているかどうかを測定します。
エラーの例
ターン 1
- ユーザー: "利用可能な正常性プランは何ですか?
- エージェント: HMO と PPO のオプションを一覧表示します
ターン 2
- ユーザー: "コストの違いは何ですか?
- エージェント: "PPO は、医師の選択に柔軟性を提供します。
❌ 応答は、コストに関するユーザーの質問には対処しません。
コンテキストの整合性
コンテキスト整合性は、エージェントが会話内のすべてのターンで一貫性のある事実と情報を維持するかどうかを測定します。
エラーの例
ターン 1
- ユーザー: "休暇日数はいくつですか?
- エージェント: "新入社員として、毎年 15 日間の PTO を受け取ります。
ターン 2
- ユーザー: "病気の日数はいくつですか?
- エージェント: "病気の日は 10 日、休暇日数は 10 日です。
❌ エージェントは、休暇日数を変更することで、以前の情報と矛盾します。
マルチターン テスト ケースを設計する
効果的なマルチターン評価を設計するには、会話フローと予期される動作の両方を定義する必要があります。 マルチターン テスト ケースには、通常、次のものが含まれます。
- テスト ケース ID と説明
- 接地データ
- 会話シーケンス
- 予期される動作
- アサーション
例: 装置の順序
- テスト ケース ID: CONV-001
- 説明: 機器の注文フロー
接地データ
- 従業員: Katrin Pold
- 従業員 ID: EMP-54321
- 部署: 製品設計
- 予算: $3,500
会話
ターン 1
- ユーザー: "ノート PC をセットアップする必要があります。
- 想定される動作: 基本設定について質問します。
ターン 2
- ユーザー: "MacBook Pro"
- 想定される動作: 仕様を確認します。
ターン 3
- ユーザー: "32 GB RAM で 16 インチ"
- 想定される動作: 注文を確認して送信します。
4 を有効にする
- ユーザー: "実際には、64 GB に変更してください。
- 予期される動作: 順序を更新します。
会話レベルのアサーション
- 会話は、確認された機器の注文で完了します。
- 最終的な順序は、修正された仕様 (64 GB) を反映しています。
- エージェントは従業員 ID を要求しません (コンテキストから推論する必要があります)。
- 合計が完了に変わるのは≤6 です。
ターンレベルアサーション
-
ターン 3:
- エージェントは OrderEquipment ツールを呼び出します。
- ツール呼び出しには、モデル "MacBook Pro 16 インチ" が含まれています。
- ツール呼び出しには、"32 GB" を含む仕様が含まれています。
-
4 を有効にする:
- エージェントは UpdateOrder を呼び出すか、前の順序を変更します。
- 最終的な確認には "64 GB" が表示されます。
例: スロット入力の会話
シナリオ: 特典の登録 (スロットの入力)
目標: 必要なすべての情報を収集し、登録を完了する
必要な入力 (スロット):
- プランの選択 (HMO または PPO)
- カバレッジ レベル (個人または家族)
- 依存情報 (該当する場合)
- 有効日
会話
ターン 1
ユーザー: "健康保険にサインアップしたい"
エージェント:
- 要求を確認する
- プランの優先設定を求める (HMO と PPO)
ターン 2
ユーザー: "違いは何ですか?
エージェント:
- HMO と PPO の主な違いについて説明します
- プランの選択を再要求する
ターン 3
ユーザー: "PPO を使用します。
エージェント:
- 選択を確認します
- カバレッジ レベル (個人または家族) を求める
4 を有効にする
ユーザー: "ファミリ カバレッジ。 私には配偶者と2人の子供がいます。
エージェント:
- 依存シナリオを確認します
- 依存する詳細 (名前、年齢など) を要求する
5 を有効にする
ユーザー: [依存情報を提供します]
エージェント:
- 収集されたすべての情報を確認します
- 登録を送信する
- 確認の概要を提供します
アサーション：
- 必要なすべてのスロットは、送信前に収集されます。
- エージェントは、必要な入力をスキップしません。
- エージェントは、プロンプトが表示されたときにオプションについて説明します。
- 最終的な確認には、キャプチャされたすべての詳細が含まれます。
- タスクは不要なターンなしで正常に完了します。
例: 説明の会話
シナリオ: あいまいな要求 (明確化)
目標: 応答する前に十分なコンテキストを収集してあいまいさを解決する
会話
ターン 1
ユーザー: "少し休む必要があります。
エージェント:
- 要求を確認する
- 休暇の種類 (PTO、病欠、個人休暇) を尋ねる
ターン 2
ユーザー: "医療処置用です。
エージェント:
- 可能性の高いカテゴリを識別します
- 要求がユーザーまたは家族のメンバーに対して行われるかどうかを確認します
ターン 3
ユーザー: "自分用です。 軽い手術だ」
エージェント:
- これは病気休暇である可能性が高いと判断します
- 関連するポリシー情報を提供します
- 予想される期間について質問する
4 を有効にする
ユーザー: "約 1 週間"
エージェント:
- 適格性とプロセスを確認する
- 次の手順について説明します (休暇を要求する方法など)
- 要求を開始するためのオファー (該当する場合)
アサーション：
- エージェントは、最初のあいまいな要求からの意図を想定していません。
- 明確な質問は関連性が高く、範囲を徐々に絞り込みます。
- 最後の応答には、ユーザーの実際の状況が反映されます。
- エージェントは明確化から解決に効果的に移行します。
例: エラー回復の会話
シナリオ: 注文の失敗と回復
目標: エラーを透過的に処理し、成功した結果をユーザーに誘導する
会話：
ターン 1
ユーザー: "MacBook Pro 16 インチを注文してください。
エージェント:
- 注文の送信を試みる
システム/ツールの応答:
- エラー: 在庫切れのアイテム
エージェント:
- 問題を明確に伝える
- エラーを隠したり無視したりしない
- 代替案を提案する (異なるモデルやサイズなど)
ターン 2
ユーザー: "いつ在庫に戻りますか?
エージェント:
- 利用可能かどうかを確認するか、利用可能な場合は補充見積もりを提供します
- 使用できない場合は、明確に通信します
- ユーザーに通知したり、代替案を提案したりするためのオファー
ターン 3
ユーザー: "代わりに 14 インチを取得できますか?
エージェント:
- 代替案の可用性を確認します
- 新しい注文を送信します
- 確認 (注文の詳細、予想される配信) を提供します
アサーション：
- エージェントは、エラーとその原因を明確に伝えています。
- エージェントは、アクション可能な代替手段または次の手順を提供します。
- 会話は、行き詰まりではなく、回復に向かって進みます。
- ユーザーは、失敗後にタスクを正常に完了しました。
- エージェントは、障害と回復の手順全体にわたってコンテキストを維持します。
マルチターン アサーション
複数ターン評価では、会話レベルとターンレベルの両方の検証が必要です。
会話レベルのアサーション
- 会話はユーザーの目標を達成します。
- ターン数は想定範囲内です。
- エージェントは一貫性のある情報を保持します。
- エージェントは、そのロールを維持します。
- エージェントは重複する情報を要求しません。
ターンレベルアサーション
- 応答は、以前のコンテキストを確認します。
- 応答は、適切なフォローアップの質問をします。
- エージェントは、予期されるアクションを実行します。
- 応答は、実行されたアクションを確認します。
条件付きアサーション
- ユーザーが情報を修正すると、エージェントは後続の応答を更新します。
- アクションが失敗すると、エージェントは問題を伝え、代替手段を提供します。
- ユーザーがスコープ外の質問をすると、エージェントは適切にリダイレクトされます。
例: エンドツーエンドのマルチターン評価
テスト ケース: 新規採用のセットアップ
説明
新しい従業員が機器を注文し、同じ会話の間に特典の質問をします。
接地データ
- 従業員: マーカス・ジョンソン
- 従業員 ID: EMP-99887
- 部署: エンジニアリング
- 場所: シアトル
- 設備予算: $4,000
会話
ターン 1
- ユーザー: "来週から始めて、ワークステーションを設定する必要があります。
- 想定される動作: ようこそし、機器のニーズについて質問します。
ターン 2
- ユーザー: "64 GB RAM と 27 インチ のモニターを備えた MacBook Pro 16 インチが必要です。
- 想定される動作: 注文を送信して確認します。
ターン 3
- ユーザー: "医療保険にサインアップする期限はいつですか?
- 予期される動作: コンテキストを失うことなく特典情報を提供します。
4 を有効にする
- ユーザー: "注文した内容を確認できますか?
- 予期される動作: 順序を呼び出して要約します。
予想される結果
- 機器の注文が完了しました。
- 特典に関する質問に正確に回答します。
- コンテキストはターン間で保持されます。
- 情報は再要求されません。
よくある落とし穴
複数ターンの会話を設計および評価する場合は、次の一般的な問題に注意してください。
- 評価は、完全な会話コンテキスト内ではなく分離して変わります。これにより、メモリ、継続性、タスクの完了に関連するエラーが非表示になる可能性があります。
- あいまいさ、修正、中断などの実際のユーザーの動作を反映できない理想的な (幸せなパス) シナリオのみをテストします。
- 短い会話と長い会話の違いを無視すると、短いフローでは完了が見逃されることが多く、長いフローではコンテキスト ドリフトが発生します。
- 競合する入力、トピックの切り替え、あいまいな要求など、敵対的または予期しないユーザーの動作は含まれません。
- ユーザーの不明確または暗黙的な目標を定義し、会話が成功したかどうかを判断するのが困難になります。
- 予想される応答を過剰に指定すると、柔軟性が低下し、有効なバリエーションが誤って罰されます。
- エラー処理と回復パスのテストに失敗し、エージェントがエラーに応答する方法や情報の欠落にギャップが残ります。
ベスト プラクティス
効果的でスケーラブルなマルチターン評価を設計するには、次のプラクティスを使用します。
- まず、最も一般的または重要な会話フローを表す価値の高いシナリオの小さなセットから始めます。
- 各テスト ケースの明確なユーザー目標を定義し、目標の完了を主な成功メトリックとして使用します。
- ダイレクト (ユーザーはすべての入力を事前に提供) とガイド付き (エージェントが複数のターンで入力を収集) の両方のパスを完了までテストします。
- 最初に会話レベルのアサーションを使用してから、より詳細な検証のためにターンレベルのアサーションを追加します。
- 説明、修正、トピックの切り替えなど、現実的なユーザー動作を反映するシナリオを設計します。
- エージェントが以前に提供した情報を再要求せずに使用するようにすることで、コンテキストの保持を明示的に検証します。
- エラー処理と回復のシナリオを含め、エージェントがエラーを通信し、次の手順を提供します。
- 正確な応答照合ではなく、柔軟な動作ベースのアサーションを使用します。
- 正確な言い回しではなく、予想される動作を定義することで、リアリズムを維持しながらテストが再現可能であることを確認します。
- 観察された障害と進化する使用パターンに基づいて、テスト ケースを継続的に反復および調整します。