Amazon Lex を使った Bot の作成

Jeff Barr がブログでの紹介の投稿でご説明したように、Amazon Lex は、開発者が音声とテキストを使用してアプリケーションで対話式のインターフェイスを構築できるようにするサービスです。Amazon Lex を使うと、すべての開発者が Amazon Alexa に採用されている深層学習技術と同じ技術を利用し、自然言語での高度な対話ボット (チャットボット) を短時間で簡単に構築できるようになります。Amazon Lex では、自動音声認識 (ASR) という音声をテキストに変換するための高度な深層学習テクノロジーと、テキストの意図を理解するための自然言語理解 (NLU) を利用できます。これにより、ユーザーにとって使いやすく魅力的なアプリケーションを構築できます。

では、Amazon Lex で機能的なチャットボットを開発するには、どうすればいいでしょうか。ドキュメント内の例の 1 つを利用すれば、1、2 分でチャットボットを使用してやり取りを開始することができます。もちろん、これはきっかけにはなりますが、まったく十分とはいえません。では、チャットボットを構築するために、何をする必要があるかを見てみましょう。

基本

チャットボット設計は、確立基準がほとんどない発生期の領域です。実際のユーザーとやり取りしなければ、何が面倒で何が快適かを理解することはできません。このセクションは、ボット設計のガイドではなく、設計上の考慮事項を探るものとして扱うことをお勧めします。以下は、Amazon Alexa との何百万回ものやり取りから学んだことです。

Simon Sinek はチャットボットがなぜ存在するかという疑問から始めることを奨励しています。優れた設計は明確な目標から始まります。それにはまず、ユーザーがどんな人か、何を達成しようとしているのかを理解する必要があります。

また、モダリティとミディアムのことも考える必要があります。音声インターフェイスは確かに便利ですが、ユーザーが注意を払っていなかったり、単に聞こえていなかったりすることも想定して、最後のプロンプトを繰り返したり、「何?」とか「どこまでいったっけ?」といった反応にも適切に対応できなければなりません。テキストのインターフェイスでは、これは不要でしょう。一部のテキストインターフェイスでは、画像とボタンの付いたレスポンスカードもサポートされています。

インターフェイスを設計する者にとって、強調は不可欠な手法です。これは、情報を提示したり、特定の選択肢を推奨する基準となります。明確性を実現するための規則はモード (ウェブ UI かチャットか音声か) によって異なります。目標とモードに応じて、強調のためのツールは異なる可能性があります。次の例を見て、3 つのそれぞれのモードにおける注文方法について検討してみてください。

	これで注文してよろしいですか。 (はい/いいえ)	____ を注文したいとのことですが、それでよろしいですか。
ウェブ (ポイントアンドクリック)	チャット (テキスト)	言語 (音声認識)

ウェブの場合、「注文を確定する」を強調することで、それが推奨される選択肢であることを明確化し、このアクションによって顧客が注文にコミットすることを確認する必要があります。チャットでは、オプションを括弧で囲むことで、ユーザーに何が期待されているかを示すのが慣例となっています。また、テキストの配置や空白文字、大文字などで強調することもできます。

音声操作では、このような慣例に代わって、注文がいつ実行されるかをユーザー自身がコントロールしていることを保証する新しい基準が必要となります。たとえば、注文に大幅な変更がある場合は、確認することができます。さらに、音声の場合、強調のためにゆっくりと話すなど、話す速度をコントロールすることも可能です。他の方法が使用できない場合は、単に繰り返すだけでもかまいません。以下の例を見てみましょう。

CoffeeBot の構築

ボイスボットを使用して、あまり一般的に使用されることのない言葉を含む会話 (たとえば、カフェラテを注文するときの「トリプルモカをお願いします」など) をサポートする必要があるとします。もちろん、ボットに命令するのがお好きな方は、「トリプルモカ、頼む」と言ってもかまいません。

ここでは、Amazon Lex コンソールを使用してカスタムボットを作成してみましょう。これを「CoffeeBot」と呼んで、Amazon Lex を呼び出すための適切なアクセス許可を持つ IAM ロールを使用します。この実行手順については、『Amazon Lex 入門ガイド』を参照してください。

Lex の用語

Jeff がブログで説明したように、Amazon Lex ではインテントやスロットタイプ、スロットが使用されます。再利用可能性を促進するために、インテントとスロットタイプは AWS アカウントに関連付けられ、複数の Amazon Lex ボットによって使用されます。変更を実行するに従い、Amazon Lex がそれらリソースのバージョンを自動的に追跡することがわかると思います。そのため、テストしている特定のバージョンのボットに何が使用されているかを正確に把握できます。これは一見、それほど大事でないことのように感じられるかもしれませんが、並列開発と継続的開発の両方をサポートすることは極めて重要なことです。

会話の流れ

新しいボットを開始する際には多くの場合、1 つのタイプのリクエストで通常どのような会話が行われるかを録音し、それらのリクエストを分析して、より広範なリクエストの場合を推定することが有効です。CoffeeBot では、人々がコーヒーショップでどのようにモカを注文するかに焦点を当てることにします。

実際の注文は、このモカの例よりずっと複雑で、10 万種類以上のコーヒー飲料が存在する可能性があります。自然な会話は決まった順序に進まないし、会話の途中でユーザーの気が変わったり、ユーザーが会話の一部をスキップする可能性もあります。このような流れの柔軟さが自然な会話の特徴です。

ではここで、CoffeeBot が「ダブルショートモカ」と聞いた場合を考えてみましょう。この場合、ユーザーは「エスプレッソダブルのショート (8 オンス) モカ」を頼んだのでしょうか。それとも実際にはサイズには触れずに「ダブルショットモカ」を頼んだのでしょうか。今一度、入力を憲章する必要があります。このシリーズの次の投稿では、入力の検証についてお話しします。

会話のインターフェイスを設計する際、的を絞ることが重要です。これまでにお話しした複雑性の一部は、ユーザーが誰かを「認識」し、支払いを処理できるアプリから始めることで自然と解消されます。特に寒い日や雨の日などには、天気の話を会話のトピックに含めてもいいでしょう。このようなたわいもない話をモデル化することは楽しいかもしれませんが、時間を最も有効に使っているとはいえないでしょう。あればいいなと思うものではなく、ユーザーエクスペリエンスを大幅に強化する開発作業に焦点を当てましょう。

会話: 情報

上記のような分析は、会話の構造を明らかにするものです。情報の断片は個別に共有することも一緒に共有することもできます。また、多数の可能な順序の 1 つとして共有することもできます。さらには、一定の飲み物のアドオンをオプションとして追加することも可能です。しかし最終的には、モカを注文するために認識されなければならない特定の値セットがあります。これまでに解明した情報の重要なサブセットに対応し、これらのスロットがフィードバックループを使用し時間をかけて洗練されていくのだということを理解したうえで、まずは CoffeeBot の一部のスロットタイプから開始します。

開発チームは共有リソースを検出しやすいように独自の規則を作成しますが、ここでは「cafe」をプレフィックスとして使用します。

会話: 目標

次に、Amazon Lex の用語で「インテント」として知られる目標を定義します。ボットは最終的には複数のインテントを使用する可能性がありますが、まずは 1 つから始めましょう (複数のボットが同じインテント、および同じインテントの異なるバージョンを使用することができます)。

ユーザーが実際に言うと予想される内容をいくつか例として提示することが重要です。Amazon Lex では、これらの例は「発話」と呼ばれます。これが重要なのは、Amazon Lex が機械学習モデルのトレーニングを行い、正しいインテントを認識するようにするためです。このテキストは、ユーザーの言うことに完全に一致している必要はありません。また、小さいセットから始めて、その後変形を追加していくのが最良です。

各発話は 1 つ以上のスロットを参照しますが、これらのスロットは定義されている必要があります。各スロットは、ユーザーから値を引き出すために Amazon Lex が使用する 1 つ以上のプロンプトと関連付けることができます。Amazon Lex ダイアログマネージャーはスロット値を追跡します。また、以下のように、それぞれの必要なスロットの優先度を使用して、次に求めるスロットを決定することもできます。

この時点で、ボットはコーヒーを注文できる状態になります。フルフィルメントについては、パート 2 の投稿でお話しします。

会話: テスト

次に、ボットを構築してテストします。モバイルアプリができてからでは他の多くの要素がからんでくるため、この段階で、できているものをテストしてエラーを検出し修正することは非常に有効です。テストは Amazon Lex コンソールに表示されるオーバーレイで実行できます。

何が起こったのでしょうか。発話としてはこのとおりのテキストを設定していませんでしたが、「I want a mocha (モカをお願いします)」という入力テキストは、作成された cafeOrderBeverageIntent と照合され、発話が I want a {BeverageType: mocha} ({BeverageType: モカ} をお願いします) として解釈されました。続いて、Amazon Lex は BeverageSize が必要であると判断し、このスロットのデフォルトのプロンプト、つまり What size?  tall, medium, large? (サイズはどうなさいますか?  トールとミディアム、ラージがございますが?) というプロンプトを表示しました。

最後に、すべての必要なスロットが満たされたら、Amazon Lex はリクエストどおりに値を表示します (クライアントにパラメーターを返す)。

会話: 流れ

では、Lex が理解できなかった場合はどうでしょうか。この場合は、コンソールにあるインテントエディタの明確化プロンプトを使用して、何か別の内容を引き出そうと試みることができます。他のすべてが失敗した場合、安全に終了します。

この設定では、Amazon Lex は 3 回まで他の明確化プロンプトを使用し、その後、中断フレーズの 1 つを使用して断念していることがわかります。では、なぜ複数のプロンプトを使用するのでしょうか。確かに、必要なのは 1 つだけかもしれませんが、複数のプロンプトが存在することで、Amazon Lex は選択することができ、自発性を維持できるのです。

また、ユーザーが注文を確定する直前にボットがプロンプトを表示するように設定することもできます。確認プロンプトは、コンソールのインテントエディタにリストされています。

確認プロンプトは、セットアップしたすべての単一スロット、特に、他のスロットが満たされた場合にのみ必要となるスロットに含める必要はありません。必要なスロットをプロンプトに含めることは良い考えですが、コードフックを使用してプロンプトをカスタマイズすることもできます (詳細は次回の投稿でお伝えします)。

確認プロンプトには、スロット値を含むことができます。どうように使用するか、見てみましょう。

予想どおり、Amazon Lex は必要なスロットが満たされたことを判断し、確認プロンプトを表示しました。また、「nope (ううん)」を正確に解釈し、中断しました。2 回目では、Amazon Lex は「yep (うん)」を肯定表現として正確に解釈し、値を表示しました。

これは何を示しているのでしょうか。追加設定がない場合、Amazon Lex は確認プロンプトから、ユーザーがサイズの変更を希望していることを正確に解釈しました。

まとめ

この投稿では、ボット設計に関連する基本的な決定事項についてお話ししました。ここでは、会話の流れを実際に観察することから始め、特定の取引に的を絞り、いくつかのデフォルト値のあるインタラクティブなボットをすばやく構築しました。その後、テストコンソールで、ボットが予想どおりに動作することを確認しました。

パート 2 では、さらなる検討事項についてお話しするとともに、この基本的なボットが音声を認識できるように開発を進めます。

注意: パート 1 とパート 2 のコード は Github リポジトリにあります。

ご不明の点またはご提案があれば、下記までコメントをお寄せください。

今回のブログの投稿者について

Niranjan Hira はソリューションアーキテクトとして、お客様がビジネス上の課題に対処するために最適な構成要素を組み立てるのをお手伝いしています。時間があるときには、いろいろな物を分解して、元に戻せるかどうか試しています。

Harshal Pimpalkhute は、Amazon Lex チームのプロダクトマネージャーとして機械が人と (うまく) やり取りするための取り組みに献身しています。