いわさです。
Amazon Lex は AWS 上でボットを構築出来るサービスです。
Lex には既にバージョンやエイリアスの概念があって、ボットの挙動を変更したり新しい機能を追加したりすることがしやすいサービスです。
一方で、これまでボットが変更される度に手動あるいはカスタムスクリプトなどでテストを実行する必要がありました。
本日 Amazon Lex に「テストワークベンチ」という新機能が発表されました。
東京リージョンでも利用可能です。
このテストワークベンチを使うと、大きくはボットに対する「テストデータの管理」と「テスト実行」を行うことが出来ます。
本日は実際にこちらの機能を使ってみましたので使い方などを紹介します。
使い方の流れですが、テストセットと呼ばれるテストデータを用意します。あとはそのテストセットをどのボットのどのエイリアスに対して実行するか選択するだけです。
テストデータの管理
まずはテストセットを作成する必要があります。
テストセットの作成方法は 2 種類あって、テストデータをファイルで用意してそれをアップロードするか、運用中のボットの会話ログを元に自動作成する方法があります。
この記事では後者の会話ログを元に自動作成を行ってみました。
前者の事前に用意されたテストデータをアップロードする方法は次の AWS 公式ブログで紹介されていますのでそちらをご参照ください。
事前にボットエイリアスを用意
運用中のボットの会話ログから自動作成するにあたって条件がいくつかあります。
まず対象のボットエイリアスはドラフト以外である必要があります。
そしてエイリアスの会話ログが有効化されている必要があります。
会話ログの有効化方法は以下も参考にしてください。
今回は次のようにドラフト以外で会話ログを有効化したエイリアスを使用します。
CloudWatch Logs に次のテキストベースの会話ログが出力されている状態です。
エイリアスを指定してテストセットを自動生成する
テストセットの新規作成を行うと、作成方法を選択することが出来ます。
左の「Generate a baseline test set」が今回行おうとしている既存の会話ログからの自動生成です。
右の「Upload a file to this test set」は外部にテストデータが存在していてそれをアップロードすることでテストセットを作成する場合に使用することが出来ます。
さらに、取り込み対象のボットエイリアスと言語まで指定します。
なお、会話ログは今回はテキストを使用しますが、オーディオも選択可能です。
作成を開始すると、作成タスクが実行され数分後に次のように完了状態となりました。
しかし、このまますぐにテストを実行することは出来ません。
画面には次のようなメッセージが表示されています。
This test set is not ready to test yet. Download the test set and annotate any necessary correctioins to the file.Then update this test set with the annotated file and you will be ready to execute a test after validation.
次に必要なステップですが、この状態のテストセットから一度テストデータをダウンロードします。そしてデータの確認あるいは修正を行った後にアップロードすることでテストセットが更新され、テストが実行出来る状態となります。
まずは次のダウンロードボタンを押してデータをダウンロードします。
次のような会話データが CSV 形式でダウンロードされました。
なるほど、テストセット用のフォーマットではありますが、基本的には会話した内容がそのまま使われていますね。
"Line Number","Conversation Number","Source","Input","Expected Output Intent","Expected Output Slot 1"
"1","1","User","花を注文したい","OrderFlowers",""
"2","1","Agent","どのような花を注文しますか?","",""
"3","1","User","ユリとバラ","OrderFlowers","FlowerType = ユリ バラ"
"4","1","Agent","何日に ユリ バラ を受け取りますか?","",""
"5","1","User","明後日の昼","OrderFlowers",""
"6","1","Agent","何日に ユリ バラ を受け取りますか?","",""
"7","1","User","明後日","OrderFlowers","PickupDate = 2023-06-10"
"8","1","Agent","何時に ユリ バラ を受け取りますか?","",""
"9","1","User","お昼","OrderFlowers","PickupTime = 12:00"
"10","1","Agent","わかりました。ユリ バラ は 2023-06-10 の 12:00 に受け取ることができます。これでよろしいですか?","",""
"11","1","User","いいね","OrderFlowers",""
"12","1","Agent","わかりました。ユリ バラ は 2023-06-10 の 12:00 に受け取ることができます。これでよろしいですか?","",""
"13","1","User","はい","OrderFlowers",""ここでは特に修正せずに Update test set からファイルを直接アップロードします。
アップロード後テストセットのステータスが更新され、次のようにテストが実行出来る状態となりました。
テスト実行
ではテストを実行してみましょう。
テストセット画面から Execute test を選択します。
続いてどのボットのどのエイリアス、言語に対して実行するかを選択します。
ここまでの流れからすると、複数エイリアス・言語に対しては個別にテストセットを用意してテスト実行する必要がありますね。そりゃそうかという感じではありますが。
多言語対応している場合はそのあたり気をつけたいところです。
テスト実行のパフォーマンスについてはテストデータが少なかったので今回はなんとも判断出来ないところでした。
私が試した際には数秒で実行が完了しました。
完了したテストは、Test results 画面に一覧で表示されており、詳細の表示やダウンロードが可能です。
テスト結果の詳細を確認すると次のように成功した件数や、カバーされているスロットやテスト実行中のやり取りの詳細などを確認することが出来ます。
失敗させてみる
ここで既存のボットを少し修正し、敢えてテストが失敗する状態を作ってみましょうか。
スロット値に制限を設定し、テストケースで使用されているスロット値を削除しておきます。
期待どおりであれば、スロット値がうまく設定されずにテストが失敗してほしいところです。
テストを実行してみました。
なお、Test results 画面ではテストが成功したのか失敗したのかはわからないですね。完了したことだけがわかります。
しかし、テスト詳細を確認してみると次のようにテストが失敗していることがわかりますね。
Detailed Results からテストケースごとの詳細なやり取りを確認することが出来ます。
ちょっとわかりにくいかもしれませんが、許可されていないバラをスロットにセットしようとして失敗しています。
そこでボット側は再度質問を繰り返すわけですが、テストケースではそのあたりは想定されていないので「何の花を注文しますか？」に対して「明後日のお昼」と回答してしまっていますね。
良いですね。
さいごに
本日は Amazon Lex で自動テストを実行出来る、テストワークベンチが利用可能になったので使ってみました。
開発中の単純なやり取りであれば従来どおりのテストウィンドウで確認しながらで良いと思いますが、リリース前に大規模なデータでリグレッションテストを実行した場合など非常に役立つのではないでしょうか。
テストデータの準備がちょっと面倒ですが、実行は非常に簡単です。
利用料金についてはアップデートアナウンスにも公式ドキュメントにも記述がなかったので、機能の利用に関する追加の料金は発生しなさそうです。
今回であれば通常のテキストリクエストに関する料金のみで済みそうですが、記述がなかったというだけなので後日実際の料金の発生状態は改めて確認したいと思います。
7
