Alexa Live 2020のまとめの続き。今回はライブで参加していたセッションから「Conversational Interfaces Faster with Alexa Conversations」です。
Alexa Conversations、以前のニュースだとスキル開発を大きく変えるような印象でしたが、どうでしょうか？今回はスライドの内容と合わせて、少し噛み砕いてみましたのでちょっと長いです。2回に分けてまとめます。
目次
Conversational Interfaces Faster with Alexa Conversations
現在のスキル
- ２つの対話方法。one-shot-interactionとmulti-turn interaction
- one-shot-interaction
- 一つの要求に対し一つの応答として返す
- フロントエンドが発話をデータ化して、バックエンドが処理
- インテント・発話のモデルとマッチしている
- multi-turn interaciton
会話デザインへの挑戦
- ターン毎にコール＆レスポンスして、バックエンドが次の質問を決める
- ターンごとにステートが変わっていく
- ハッピーパスの通りに進めばリニアな会話フローになる。
- インテント・発話のモデルでかんたんにできる。
- ユーザがハッピーパスからそれるとどうなるか？
Alexa Conversations
- ディープラーニングでハッピーパスを解析してパスからそれた場合に対応する
- 会話のコンテキストを記録する
- メリット
- より自然に人間らしい会話
- バックエンドのコードから、ダイアログのステート管理を減らす
- 既存スキルへの追加も可能、1から書き直さなくて良い
- モデルのトレーニングデータを減らす
iRobotの事例
- スケジュール実行に関するチャレンジ
- 最初に実装したときは数百もの発話でローカライズを含めると気が遠くなる作業だった
- ウイザード形でYes/Noにした
- すべての部屋を掃除するか、個々の部屋を掃除するか、などで、自由な質問形式は認識に問題があった
- Yes/Noの回答で次の質問を決めるようにした
- すべての部屋を掃除しないなら、個々の部屋を順に聞く
- Alexa Conversationのリストサポートと動的エンティティがこのギャップを埋めた
- Alexa Conversationsのメリット
- パワフルな音声モデル
- よりよいスロット解決
- コンテキストへの理解
- リストサポート
- デモ
- 複数の部屋（スロット）を一度に発話
- 途中で時間を訂正したり、曜日を追加したり
実装
- 2つの実装方法。default dialog manager/custom skill dialog manager
- default dialog manager
- Alexa Conversationsをデフォルトのdialog managerとする
- すべての会話がAlexa Conversationsにコントロールされる
- custom skill dialog manager
- カスタムスキルのdialog managerとする
- あるタスクを実現するための会話の一部をAlexa Conversationsがコントロールする
- 例えばスロット収集とか、提案・確認
- 会話のステート管理と5つのコンポーネント
サンプルダイアログ
- 例
ユーザ：水曜日に掃除をスケジュールして
Alexa ：どこを掃除しますか？
ユーザ：台所
Alexa ：水曜日に台所を掃除するようにスケジュールします。よろしいですか？
ユーザ：はい
Alexa ：わかりました。Max（ロボット掃除機の名前）は、水曜日に台所を掃除するようにスケジュールしました。 - このやり取りの中で、必要な情報＝スロットを抑える
- 「水曜日」
- 「台所」
- 「Max」
スロット
- 2種類のスロット
- singular slot
- 単一の値を表す
- 「水曜日」や「台所」は個々の値
- compound slot
- 複合的な値セットを表す
- APIから返される
- スケジュールの結果として「Max」「場所」「日時」が返される
- singular slot
- 開発者コンソールでのやりかた
- サンプルのダイアログを作っていく。
- ユーザとAlexaのやり取りが見える。
- スロットが設定されていればそれも見える。
- singular slotの作成
- スロット値が並ぶ。これまでのスロットと同じ感じに見える。
- スロット値が並ぶ。これまでのスロットと同じ感じに見える。
- compound slotの作成
- 一つのスロットタイプの中に複数のプロパティ（スロット）名・スロットタイプがプロパティとして並んでいるように見える。
- これらがAPIから返される
- サンプルのダイアログを作っていく。
発話セット
- サンプルダイアログは一つの可能性のあるパスを示している
- ユーザが違う反応をした場合はどうなるか？
- Alexa Conversationならこのバリエーションに対応できる
- 発話セットを使うことでこのバリエーションを開発者が明示的に書かなくて済む
- 発話のバリエーションが一つの発話セットにまとめられる
- 発話のバリエーションが一つの発話セットにまとめられる
- ユーザの発話に紐づく発話セットが特定できたら、発話セットが対話の中でどういう機能を示すか？が必要になる。これが"dialog acts"
- 対話中のそれぞれの行をカテゴライズする
- Invoke
- ユーザ：水曜日に掃除のスケジュールをしたい
- スケジューリングを最初に「トリガー」する
- Inform
- Alexa：どこを掃除しますか？
- ユーザ：台所
- ユーザが「情報を伝える・回答する」
- Affirm
- Alexa：水曜日に台所を掃除するようスケジュールします、よろしいですか？
- ユーザ：はい
- 「確認」に対する回答
- 開発者コンソール
- 2つの方法で対話と発話セット・dialog actを紐付ける
- １. すでに作成した発話セットを選択して、dialog actと紐付け
- ２. 新規に発話セットを作成して、サンプル発話を入力。そして、dialog actと紐付ける
- 2つの方法で対話と発話セット・dialog actを紐付ける
レスポンステンプレート
- レスポンステンプレートで、ユーザーの発言に応答する
- ユーザーのdialog actを特定するのと同様に、システムやAlexaによるレスポンスについてもdialog actを特定する必要がある
- ”Request"
- ユーザ：水曜日に掃除のスケジュールをしたい
- Alexa：どこを掃除しますか？
- 追加情報を要求
- "Confirm"
- Alexa：水曜日に台所を掃除するようスケジュールします、よろしいですか？
- ユーザへの確認
- "Notify"
- Alexa：水曜日に台所を掃除するようスケジュールしまあした。
- 結果の通知
- ”Request"
- 開発者コンソール
- 発話セットの作成と同じように、サンプルダイアログのページでレスポンステンプレートをインラインで作成できる
- 同様にdialog actも設定が必要
- レスポンステンプレートとdialog actの紐付けができたら、APIと紐付ける
API
- 引数
- APIの実行に必要
- APIに投げる前にAlexa Conversationが収集する
- オプション扱いの引数も可能
- 結果
- compound slotとして返す
- 開発者コンソール
- APIの名前と引数を指定
- 必須チェックのとぐる
ロジック
- リクエスト
- リクエストタイプはAlexa Conversation専用のもの
- スロット値がrequest entityで渡ってくる
- エンティティ解決も当然できる
- レスポンス
- return entitiyでcompound slotを返している
- 全体像
- Alexa Conversationsが必要なスロットを収集して全部揃ったら確認
- 確認できたらAPIに投げてそのレスポンスをユーザに返す
メリット
- State management
- ステート管理をやってくれる
- ハッピーパスを提供すれば、パスからそれたものをAlexa Conversationsが補完してくれる？
- 開発者が多数の組み合わせを考える必要はない。
- Confirmations
- APIを呼び出す直前に必要な引数が揃っていればユーザに確認する
- User correction
- Alexa Conversationはユーザが途中で気が変わって変更するのに対応している
- これ用のサンプルダイアログを作る必要はない
- Proactive offers
- スケジュールを作成したあとなら、いつでもスケジュールの確認をするように促せる？
- Interoperability
- 既存のスキルの一部にAlexa Conversationsを追加する事が可能
Big Skyの事例
- よい音声体験を提供するには多数のことを考える必要がある
- どのようにユーザと対話するか？
- スロットをどのように収集するか？
- カスタムの天気アラートはこれまで一つだけだった
- 複数の種類のアラートや複数の場所の設定を自然な会話で行うのは面倒だったため
- Alexa Conversations
- スロットハンドリングを任せれるのでデザインに集中できる
- いくつかのサンプルダイアログを登録すればあとはAIが自動生成してくれる
- 会話の途中でのユーザの変更にもcorrectionで対応できる、コードを書かなくても良い
- 既存スキルの拡張もしやすい
個人的まとめ（前半）
とりあえず実装イメージがなんとなくわかったところまでの所感。
- 対話モデル側が抽象化されて複雑になった印象だけど、バックエンドへのリクエストが実際に飛んでくるまでにある程度やってくれるということなので、実装自体は確かに手間ではないかもしれない。
- ハッピーパス（サンプルダイアログ）をいくつか登録するだけ、サンプル発話とかはよしなに生成してくれるというのは本当みたいだし、それなら確かに楽だけど、精度は気になる。
- ユースケース的には、ダイアログモデルのよりリッチなもの、というイメージ。以前の発表であったクロススキルでAlexaが提案してくれる感じはどこへいったんだろう・・・
残りはちょびっとだけど次のエントリで。
