規模を拡大する前の音声エージェント評価チェックリスト

成功は、確認済みのビジネス上の成果として定義します。予約の流れであれば、正しい日時、サービス、発信者の情報が記録され、音声での確認内容がその記録と一致していることを確認します。会話が滑らかだったことや、文字起こしが空でないことは、完了の十分な証拠にはなりません。

接続、会話の品質、タスクの完了を分けて考えます。通信事業者による拒否は、名前の聞き間違いとは別の失敗であり、どちらも予約APIがエラーを返すこととは異なります。修正が正しい層に向かうよう、失敗のカテゴリーを記録してください。

対応する予定のタスクと言語から、テストセットを作ります。可能な限り、同意を得たテスターと架空のデータを使ってください。エンジンや連携を変えた後に同じ評価を繰り返せるよう、プロンプトとシナリオの指示はバージョン管理します。

以下のケースは出発点となるチェックリストです。これは提案するテストであり、すべてのエンジンが合格するという意味ではありません。自社のアプリケーションにとって重要な発信者の行動や障害の条件を追加してください。

• 期待される結果が明確な、単純な依頼。
• 会話の途中で名前、電話番号、予約時刻が訂正されるケース。
• エージェントの発話中に割り込み、別の依頼をするケース。
• 背景の雑音、無音、聞き慣れないアクセント、対応する各言語。
• ナレッジベースにない質問と、エージェントが対応を許されていない依頼。
• バックエンドが利用できない状態、重複したイベント、完了前に発信者が切断するケース。
• 担当者への引き継ぎの依頼。アプリケーションに実際に実装されている引き継ぎ動作に対してテストします。

シナリオ、エンジンとプロンプトのバージョン、通話ID、接続結果、タスクの結果、通話時間、費用を記録します。同じエージェントに自分の回答を採点させるのではなく、レビュー担当者が元のビジネス上の記録を確認してください。

応答性については、測定する区間を定義します。たとえば、発信者の発話の終わりから、エージェントの音声が聞こえ始めるまでです。分布、サンプルサイズ、テスト条件を報告してください。1回の速いデモを、一般的なレイテンシーの約束にしてはいけません。

• タスク完了率 = 確認済みの完了数 / そのタスクで評価した会話数。
• 接続率 = 接続した通話数 / 発信を試みた通話数。別に報告します。
• 完了あたりの費用 = パイロットの総費用 / 確認済みの完了数。完了が0件の場合は算出不能と報告します。
• 平均値で誤った予約や作り話の回答が隠れないよう、重大なエラーは別に記録します。

通話記録でステータス、文字起こし、cost_microsを確認します。通話がつながらなかった場合は、プロンプトを変える前にfailure_codeとfailure_reasonを確認してください。請求額は使用量イベントと照合します。通話は完了したのにアプリケーションが更新されなかった場合は、webhookの配信履歴を確認します。

通話の開始時には冪等キーを使い、リクエストを再試行しても二重に発信されないようにします。自社のイベントハンドラーが重複した配信を正しく扱えるかテストし、保存された結果を確認してください。認証とwebhookの署名検証は、パイロットを拡大する前に連携に組み込んでおくべきものです。

事前に決めた合格基準を満たし、重大な障害に担当者が決まっていて、運用の手順がテスト済みであれば拡大します。基準値はユースケースのリスクと価値に応じて決めてください。すべての音声ワークフローに当てはまる完了率というものはありません。

トラフィックは段階的に増やし、失敗した通話を確認し、実際の支出を予算と比較します。プロンプトやモデルの変更には、元に戻す手段を残しておいてください。事例として公開する場合は、測定結果を方法と制約とあわせて共有します。

このリソースはWixzel Voiceが公開しています。製品の詳細は以下の参考資料に基づきます。評価に関する推奨は提案する方法であり、ベンチマークの結果ではありません。

• 通話エラーと失敗コード
• webhookの配信と検証
• 冪等性による安全な再試行

誤りを見つけた場合は、修正を送ってください。