Alexa Live 2020メモ: Conversational Interfaces Faster with Alexa Conversations②

Alexa Live 2020のまとめの続き。前回に続き「Conversational Interfaces Faster with Alexa Conversations」のPart2です。

前回でだいたい実装イメージのところまで終わってますが、裏側でどんなことをやっているかのところをまとめたいと思います。

f:id:kun432:20200805124135p:plain

Conversational Interfaces Faster with Alexa Conversations

Technical deep dive

dialogue simulator
- 開発者が想定する会話パターンに多くのバリエーションを追加するためのコンポーネント
- 開発者が作成したすべてのアセット（APIリファレンス、スロット、レスポンスのテンプレート、サンプルダイアログなど）をダイアログシミュレータに渡す
- シミュレータが2つのステップで会話パターンを生成する
  - １. 考えられる他の異なる会話フローをシミュレーションする
  - ２. 上記に自然言語的なバリエーションを追加する
    - 例：「映画が見たいです」or 「おすすめの映画を教えて」
    - パラフレージング（言い換え）を使ってこれらを生成する
- これらにより、何万ものバリエーションを生成して対話モデルのためのトレーニングに使用する
フレームワーク
- dialog simulatorはゴールオリエンテッドな会話をゲームとして捉える
  - ユーザにはゴール（目的）がある
  - Alexaはそのゴールを達成するためのAPIやリソースにアクセスできる
  - 例）天気を聞く
    - ユーザのゴールは天気を知ること
    - Alexaは場所と日時を元に天気を返すことができるAPIを持つ
  - ユーザとAlexaが協力してゴールを達成するための共同会話になる
    - ユーザが自分のゴールをAleaxに少しづつ伝える
    - Alexaがこの情報を収集、足りなければそれを得るために追加の質問を行う
実際の動き
- ハッピーパスの場合。
  - ユーザが自分のゴールを伝える（inform）ところからスタートする
    - 「天気を教えて」
  - Alexaは天気を取得するAPIを要求しているように見える
    - 天気を取得するAPIは、都市名と日時の２つの引数が必要
    - これらのスロットを要求、ユーザに都市と日付を尋ねる
  - ユーザがスロットの値を伝える（inform）
    - 都市名と日時
  - Alexaがスロット値をユーザに確認（confirm）
  - ユーザが肯定（affirm）する
    - 全否定するかもしれない
    - 複数のスロットのうち、1つは肯定、もう1つは否定するかもしれない
  - 確認に対しユーザが肯定すれば、Alexaは・・・
    - スロット値を引数としてAPIに渡して結果を受け取る
    - ユーザが指定した場所・日時の天気を発話レスポンスとして返す
- ハッピーパス以外の、異なるパスや、異なるユーザの挙動についてもシミュレーションを行う
  - ユーザが想定よりも協力的
    - 「天気が知りたい」に対して「まず」場所を聞いたら、場所だけでなく日時も返してきた
    - 必要な情報はもう揃っているので追加質問せずに回答を返す
  - ユーザが途中で気が変わる
    - 「（シアトルの）天気が知りたい」に対して日付を聞いたら、ユーザの気が変わって「ボストン」という新しい場所が返ってきた。
    - 場所が変わったことを理解した上で、再度日付を聞く
  - ユーザが非協力的
    - 「天気が知りたい」に対して場所・日付を聞いたら、日付だけが返ってきた。
    - 場所だけが足りないので場所を再度聞く
- ユーザの挙動をシミュレートするだけでなく、Alexaの挙動もシミュレート
  - ユーザの現在行っていることから、Alexaが積極的にスキルの機能を提供する
  - Alexaがスロットの値やAPIを確認する
異なる対話パスをシミュレートすることが重要
- 会話にはノンリニアな対話パスが多数あり、実際にスキルのユーザが異なる振る舞いをして異なるパスを通るかもしれない。
- 事前にシミュレートすることで・・・
  - 堅牢な対話モデルを作ることができる
  - 開発者が余計な努力をしなくて住む
Alexa Conversationにおける対話モデル
- 最新のディープラーニング技術によって、最先端のパフォーマンスを提供する
- １. Named Entity Recognition model (NER)
  - スロット
    - 開発者によって定義され、スロット値の一覧を含む
    - APIやレスポンステンプレートに渡す必要がある情報の単位
  - NERにより、ユーザの発言から抽出される
- ２. Action Prediction model（AP）
  - Alexaが取るべき最適な次のアクションを予測
    - ユーザの発言をインプットとして使う
    - これまでの全体の会話も考慮
  - 取りうる別のアクション候補も予測する
    - APIレスポンスの結果を返して次に最適なものを選択
- ３. Argument Filling model（AF）
  - 全体の会話から、API入力値とレスポンステンプレート入力値を埋めていく
  - NERが認識したスロットから、互換性のあるものを見て値を拾っていく
    - 「今日のシアトル」→「今日」が日時で、「シアトル」が場所と認識している
  - APが次に取るべきアクションは「確認」と判断
  - この結果を踏まえて、AFが確認用テンプレートの引数にこれらの値を埋め込む
    - 「今日のシアトルの天気でよろしいですか？」
    - そしてAPIに投げる
      - 引数が足りなければAPIに投げない

その他

Arriveの事例

駐車場を音声で探すサービス
- Alexa Conversationsにより、すべての会話の定義をすることなく、複雑なユースケースに対応
  - ユーザの訂正をかんたんに取得できる
  - バックエンドの修正を最小限にして既存スキルへの拡張が可能
  - スロットを多数用意したり、スロットを確認したり、せずに済むのでコードが減った
- 大変な入力処理をAlexa Conversationsに任せて、スキル内の意味あるコンテンツによりフォーカスできる