Copilot Studioで構築された会話型エージェントは、需要と負荷の増加に自動でスケールするプラットフォーム上で動作します。 しかし、会話型エージェントはしばしばカスタムロジックやバックエンドAPIへの呼び出しを用いており、カスタムロジックが非効率的であったり、基盤となるAPIやバックエンドシステムがスケーリング性に欠けるため遅延が生じます。
パフォーマンステストは、異なる負荷パターン下でのエージェントのパフォーマンスと安定性を評価します。 ユーザーベースが増えるにつれて潜在的な問題を特定し、エージェントが機能し応答性を保ち続けることを保証します。 負荷時に会話エージェントをテストしなければ、開発やテスト中は正常に動作しても、実際のユーザートラフィックでは失敗することがあります。
パフォーマンステストの技術的側面に取り組む前に、望ましいユーザー体験を捉える受け入れ基準を定義し、異なる負荷パターンを生み出す会話型ユースケースを特定しましょう。 この記事では、パフォーマンステストの計画段階を簡単に説明し、会話型エージェント向けに負荷を生成する技術的詳細についての指針を提供します。
パフォーマンステストの計画を立てましょう
パフォーマンステスト計画には明確な目標と具体的な受理基準が必要です。 例えば、あるテストは標準負荷下でのシステムのパフォーマンスを測定しますが、他のテストは意図的にシステムが応答しなくなるほど極端なストレスを生み出します。 Copilot Studioで構築された会話型エージェントのパフォーマンスを測定する際は、エージェントのベースラインパフォーマンスか予想される重負荷を測定するテストを設計しつつ、過度なストレスを発生させるテストを設定しないようにしましょう。
Warnung
ユーザーの期待を超える負荷が発生すると、メッセージ消費の過剰や環境の望ましくないスロットリングが発生する可能性があります。 制限や消費超過を避けるために、以下の点を確認してください:
- あなたのテストは現実的なユーザー行動を模倣しています。
- テナントや環境には十分なライセンスと請求ポリシーが割り当てられています。
ユーザーの行動を理解する
テスト計画は、ユーザーが異なる会話型ユースケースでどのように振る舞うかを分析することから始めましょう。 負荷テストの観点から見ると、ユーザーの行動はユースケースによって異なる場合があります。例えば、「フライトを予約したい」や「返品ポリシーは?」など、特定のユースケースを動かすユーザー数、ユーザーのエンゲージメントパターン(例えば、正午に一度に接続するユーザーと一日を通して徐々に接続するユーザーなど)が異なります。
以下の表は、銀行の会話エージェントに対する期待されるユーザー行動を示しています。
| 使用事例 | 一般的なユーザー発話 | 交戦パターン |
|---|---|---|
| ローン申請 | 新しいローンが必要です 新しいローンを申し込みたいのですが ... |
1日を通して平均1,000人の同時利用者 |
| バランス調査 | 私の口座残高はいくらですか 口座残高を見せて ... |
1万人の同時利用者が正午頃に接続しています |
| 追加のユースケース | … | … |
テスト計画の作成
ユーザー行動をユースケースやエンゲージメントパターンで定義した後、パフォーマンステスト計画の詳細を考えましょう。 最低限、会話型エージェントのパフォーマンステスト計画には、目的、テストシナリオ、主要業績評価指標、詳細なテストデータ、成功基準を明示すべきです。
もしチームがすでにテスト ケースを作成 したり Copilot Studioキットを使って評価用の会話シナリオを定義しているなら、これらのシナリオを再利用してテスト計画の作成を始めることができます。
以下のテスト計画例は銀行の会話型エージェント向けです。 この計画は、以前に特定された会話型ユースケースを用いて、ベースラインテストシナリオとロードテストシナリオを定義します。 ベースラインのテストは正常なパフォーマンスを評価し、通常の使用時の問題を特定しますが、負荷が増えるとシステムがピークユーザーの活動をどのように処理するかが明らかになるかもしれません。
| セクション | 詳細 |
|---|---|
| Objective | 銀行の会話エージェントのベースラインおよび負荷状況下のパフォーマンスを評価してください。 |
| Scope |
対象範囲:ベースラインおよび負荷試験。 範囲外:ストレステスト。 |
| 主要業績評価指標 (KPI) |
|
| テストシナリオ |
基準試験
|
| テスト データ |
|
| Tools |
|
| 成功基準 |
|
技術関係者やビジネス関係者と協力し、組織のニーズに合ったテスト計画を作成しましょう。 例で示した主要なパラメータに同意します。 Apache JMeterのようなツールを使ってテストスクリプトを作成する方法については、 パフォーマンステストの参考サンプルやガイドラインで学びましょう。
複数ターンの会話をシミュレートします
計画に指定されたテストデータは、計画されたパフォーマンステストドライブが複数ターンにわたる会話を意味します。 マルチターン会話とは、シミュレートされたユーザーと会話エージェントの間で送信される一連のやり取りメッセージのことです。 パフォーマンステストは複数ターンの対話を促し、生成される負荷が実際のユーザーの行動に似ているようにすべきです。 また、長期間実行されるアクションやAPI呼び出しは、ユーザーが特定の選択をしたり、会話内で特定のメッセージパターンを送信した場合にのみ呼び出されます。
以下の例では、銀行のバックエンドAPIはユーザーが 貯蓄口座を選択した後にのみ呼び出します。 最初のメッセージの応答時間は、エージェントの意図認識エンジンのみが関与するため、1秒未満です。 最後のメッセージはバックエンドAPIからの応答を待ち、追加の遅延が生じます。 複数ターンの会話をシミュレートしなければ、パフォーマンスの問題は発生しなかったでしょう。
マルチターンの会話をシミュレートするには、テストデータの準備とテストスクリプトの作成の両方を計画する必要があります。 テストデータに一連のユーザー発話を含めると、例のように完全な会話フローを呼び出します。 テストスクリプトが1つの会話内で複数の発言を送信するようにしましょう。