Alexa Conversationsのしくみ

Alexa ConversationsではAI主導のダイアログ管理モデルを使用して、スキルで幅広いフレーズや予期しない会話フローに応答して目的を達成できるようにします。Alexa Conversationsのダイアログ管理モデルには次の3つのステージが含まれます。

1. オーサリング - 開発者は、スキルでサポートできるさまざまな会話エクスペリエンスを表すアノテーション付きダイアログを提供します。ダイアログの作成とアノテーションを含むオーサリングの詳細については、Alexa Conversationsのダイアログの作成およびAlexa Conversationsでのダイアログオーサリングのベストプラクティスを参照してください。
2. ビルド - Alexa Conversationsはダイアログシミュレーターを使用して、ダイアログ管理モデルをトレーニングするダイアログバリアントにアノテーション付きダイアログを展開します。ダイアログバリアントは、自然に発生するダイアログの流れを表すものです。
3. ランタイム - Alexa Conversationsはトレーニングされたダイアログ管理モデルを評価し、受信イベントを処理してアクションを予測します。Alexa Conversationsモデリングアーキテクチャの基礎となっている科学的な詳細については、Science innovations power Alexa Conversations dialogue management（英語）を参照してください。

このページでは、ダイアログシミュレーターとランタイムに発生するものを中心に詳細を説明しています。また、Alexa Conversationsについてで説明されているダイアログアクトなど、Alexa Conversationsの基本的な概念に精通した読者を対象としています。

• ダイアログシミュレーター
  • 発話のバリエーション
  • スロット値のバリエーション
  • 不足しているAPI引数をリクエストおよび通知する
  • ユーザーによるスロット値の修正
  • Confirming APIs
  • Confirming arguments
  • 1回のターンで複数のAPIを呼び出す
  • プロアクティブなオファー
  • コンテキストのキャリーオーバー
• ランタイム
  • コンテキストメモリ
  • 名前付きエンティティの認識
  • アクション予測
  • 引数入力
  • エンティティ解決
• 関連トピック

ダイアログシミュレーター

ダイアログシミュレーターは、アノテーション付きダイアログを一般化してトレーニングデータを生成することで、ユーザーがスキルと対話するさまざまな方法に対応します。たとえば、ユーザーは、特定の機能を呼び出したり、リクエストされた情報を順不同で提供したり、以前に提供した情報を変更したりする目的でさまざまな発話を行います。

ダイアログシミュレーターは、スロットタイプ、API定義、発話セット、応答を含むアノテーション付きダイアログを数万に及ぶダイアログバリアント、フレーズのバリエーション、一般的でない選択肢に拡張することでトレーニングデータを生成し、潜在的なダイアログパスの範囲を拡大します。この拡張によってダイアログ管理モデルの堅牢性が向上し、開発者はユーザーがスキルを操作する際に考えられるあらゆる方法を識別してコーディングする代わりに、スキルの機能開発に集中できるようになります。

以下のセクションでは、ダイアログの拡張方法について説明します。

• 発話のバリエーション
• スロット値のバリエーション
• 不足しているAPI引数をリクエストおよび通知する
• ユーザーによるスロット値の修正
• Confirming APIs
• Confirming arguments
• 1回のターンで複数のAPIを呼び出す
• プロアクティブなオファー
• コンテキストのキャリーオーバー

発話のバリエーション

Alexa Conversationsスキルを設定するときは、発話セットを作成して、ユーザーがAlexaに応答するさまざまな方法をグループ化します。各発話セットに、サンプル発話のリストをそれぞれ指定します。ダイアログシミュレーターでは、これらのサンプル発話を使用してダイアログバリアントを生成します。

例

映画を検索するためのダイアログを提供します。発話セットには、「だれが{movie}を監督しましたか？」と「{movie}の監督はだれですか？」の両方が含まれています。 バリアントでは、ダイアログシミュレーターにより、ユーザー発話が発話セット内の別のサンプル発話に置き換えられます。

スロット値のバリエーション

スロットを指定するには、ビルトインスロットタイプを選択するか、ビルトインスロットタイプをスロット値で拡張するか、値を使用してカスタムスロットタイプを作成します。ダイアログマネージャーは、これらのスロットをランダムにサンプリングしてダイアログバリアントを生成します。

例

おすすめの映画を提案するダイアログを提供します。このバリアントでは、ダイアログシミュレーターは、スロット値「犯罪」と「クエンティンタランティーノ」を「コメディ」と「ガイリッチー」に置き換えます。

不足しているAPI引数をリクエストおよび通知する

APIの呼び出しに必要なすべての引数のリクエストと通知を示すアノテーション付きダイアログを提供する必要があります。その際、個々の引数に対してRequest Argsダイアログアクトを使用して応答を作成する必要があります。たとえば、都市と日付を必要とするweather APIの場合、「どの都市ですか？」などの応答や「日付はいつですか？」などの応答を作成する必要があります。

ダイアログシミュレーターはダイアログを自動的に拡張し、不足しているAPI引数をリクエストするバリアントを作成します。これらのダイアログのバリアントは、ユーザーが1回のターンでリクエストされたすべてのスロットを提供しなかった場合（情報不足）や、リクエストよりも多くの情報を提供した場合（情報過剰）にも対応します。

例

おすすめの映画を提案するために監督とジャンルをリクエストするダイアログを提供します。ダイアログには、監督とジャンルをリクエストするための応答が含まれています。ダイアログシミュレーターは、RecommendMovieの不足しているAPI引数をリクエストするダイアログバリアントを生成します。

ユーザーによるスロット値の修正

ユーザーによるスロット値の修正を示すアノテーション付きダイアログを提供する必要はありません。ダイアログシミュレーターは、ダイアログを自動的に拡張してこのようなバリアントを作成します。

例

ユーザーによる修正を含むダイアログを提供しなかった場合、ダイアログシミュレーターは次のようなダイアログのバリエーションを生成します。

Confirming APIs

Confirm API / Affirmダイアログアクト（API確認/肯定）を使用して、APIを呼び出す前にAlexaがユーザーにAPI引数を確認する必要があることを示すダイアログを提供します。特定のAPIを呼び出す各ダイアログは、API Success/API Failureダイアログアクトよりも前に、APIの引数を確認するターンで提供する必要があります。Confirm API/Denyダイアログアクト（API確認/否定）を使用して、アノテーション付きダイアログを提供する必要はありません。ユーザーが確認を否定した場合、ダイアログシミュレーターは、組み込みのreqmore応答をレンダリングするダイアログバリアントを自動的に生成します。ただし、別のダイアログフローをサポートする場合は、Confirm API/Denyを使用してアノテーション付きダイアログを提供できます。

例

おすすめの映画を提案して購入を尋ねるダイアログと、ユーザーによる映画購入の意志を確認するダイアログを提供します。ダイアログシミュレーターは、ReserveMovie APIを呼び出す前に、このAPIを確認するダイアログバリエーションを生成します。

Confirming arguments

Confirm Args/Affirm（引数を確認/肯定）を使用してダイアログを提供し、リクエスト後にAlexaが引数を確認する必要があることを示します。特定の引数をリクエストする各ダイアログは、Request Argsダイアログアクトの後に、引数を確認するターンで提供する必要があります。ダイアログシミュレーターが、APIを呼び出す前に、Confirm APIとConfirm Argsの両方が適用されるダイアログバリアントを生成しようとした場合、そのターンではConfirm APIが優先され、必要なすべての引数がユーザーに確認されます。Confirm Args/Denyダイアログアクトを使用して、アノテーション付きダイアログを提供する必要はありません。ユーザーが確認を否定した場合、ダイアログシミュレーターは、引数を再度リクエストするダイアログバリアントを自動的に生成します。ただし、Confirm Args/Denyを使用してアノテーション付きダイアログを提供し、別のダイアログフローを提供できます。

例

おすすめの映画を提案するために監督とジャンルをリクエストするダイアログと、監督を確認するダイアログを提供します。ダイアログシミュレーターは、次に進む前に監督を確認するダイアログバリエーションを生成します。

1回のターンで複数のAPIを呼び出す

API SuccessおよびAPI Failureダイアログアクトを使用して、Alexaの1回のターンで複数のAPIを呼び出すアノテーション付きダイアログを提供できます。ダイアログシミュレーターは、バリアントを作成するときにこれらのAPIのシーケンスを決定論的に処理するため、この順序は変更されません。

例

1回のターンで2つのAPIを呼び出すダイアログを提供し、最初にユーザーのデフォルトの都市を含むユーザー設定を取得し、その都市の天気を取得してから結果をレンダリングします。

プロアクティブなオファー

ユーザーが元のAPIを呼び出して結果を受け取った後に、新しいAPIを呼び出すダイアログフローをプロアクティブにオファーするアノテーション付きダイアログを提供できます。新しいAPIを提供するには、API Success/API Failureターンで終わるダイアログをOffer Next API（次のAPIを提供）ターンで拡張します。これには、同じターンでの引数のリクエストや、以前のAPI呼び出しからの引数の引き渡しを含めることもできます。

Offer Next APIのターンの後で、ダイアログを完了する必要はありません。ダイアログシミュレーターは、新しいAPIを呼び出す別のダイアログがある限り、ダイアログバリアントを作成するときにダイアログを自動的に完了します。ただし、Offer Next APIのターンの後でダイアログを完了して、別のダイアログフローを提供することができます。プロアクティブなオファーは決定論的ではありません。ダイアログバリアントは、異なるAPIをプロアクティブにオファーする場合と、APIをプロアクティブにオファーしない場合があります。

Offer Next API/Denyダイアログアクトを使用して、アノテーション付きダイアログを提供する必要はありません。ダイアログシミュレーターは、ユーザーがオファーを否定した場合、組み込みのreqmore応答をレンダリングするダイアログバリアントを自動的に生成します。ただし、Offer Next API/Denyを使用してアノテーション付きダイアログを提供し、別のダイアログフローを提供することができます。

例

レストランで席を予約するためのダイアログを提供します。Offer Next APIを使用してこのダイアログを拡張し、APIでUberを予約します。

コンテキストのキャリーオーバー

コンテキストのキャリーオーバーを示すアノテーション付きダイアログを提供する必要はありません。ダイアログシミュレーターは、アノテーション付きダイアログからダイアログバリアントを生成する際に、代名詞を含むターン（「それを購入して」など）を導入することで、この機能をサポートしています。キャリーオーバーは、後のランタイムステージの引数入力で、API引数に入力するために、ダイアログ全体でユーザーとAlexaが言及したすべてのスロットをAlexa Conversationsが考慮する際に行われます。

例

映画を購入するためのダイアログを提供します。ダイアログシミュレーターは、代名詞を含むターンを導入します。

ランタイム

Alexa Conversationsランタイムは、推論エンジンを含むいくつかのコンポーネントを使用して、トレーニングされたダイアログ管理モデルを評価します。推論エンジンは、外部からイベント（ユーザーが「映画「スターウォーズ」の上映時刻を検索して」と話しかけるなど）を受け取り、各セッションの会話履歴を維持してダイアログコンテキストを管理し、ダイアログの状態を維持して、情報をランタイム内の複数のコンポーネント間で調整します。

ランタイムはイベントを処理し、発生するアクションを予測します。このようなアクションには、ユーザーへの応答、AWS Lambda関数の呼び出し、計算の実行などがあります。ランタイムは、予測されたアクションを暗黙的に実行するか、またはAPIの呼び出しに変換します。

次の図は、機械学習トレーニングを受けたダイアログ管理モデルをホストし、イベントの処理、アクションの生成を行うAlexa Conversations推論エンジンの概念モデルです。

推論エンジンは、コンテキストメモリを使用してダイアログコンテキストを管理し、状態を追跡します。また、機械学習でトレーニングされた次の3つのドメイン固有モデルも追跡します。

• 名前付きエンティティの認識 - このモデルでは、ユーザー発話のスロットにタグを付けます。
• アクションの予測 - このモデルでは、次に発生するアクションを予測します。
• 引数入力 - このモデルでは、コンテキストからのエンティティをアクション引数に入力します。エンティティは、ユーザーが言及したスロット、または以前のAPIからの戻り値です。推論エンジンは、引数入力が完了した後にエンティティの解決を実行します。

コンテキストメモリ

コンテキストメモリは、ユーザーの発話を追跡し、エンティティ（ユーザーが言及したスロットや、以前のAPIからの戻り値）、予測されるアクション、Alexaの応答などの結果をモデル化する短期メモリです。コンテキストメモリは各セッションのダイアログコンテキストを維持し、セッション中には常に最新の状態に保たれます。

名前付きエンティティの認識

名前付きエンティティの認識は、口頭での発話（ユーザーが「映画「スターウォーズ」の上映時刻を検索して」と話しかけるなど）を推論エンジンが受け取った後の最初のステップです。名前付きエンティティの認識では、ユーザーの発話がスロットタイプに対応するフレーズに分割されます。

名前付きエンティティの認識により、これらのフレーズはスロットとして解釈され、そのスロットがコンテキストメモリに保存されます。その後、ダイアログ管理モデルではこれらのスロットを使用して、APIの呼び出しやAlexaの応答のレンダリングなどのアクションを実行します。開発者コンソールのテストタブにあるAlexaシミュレーターのデバッグ機能では、名前付きエンティティの認識によるフレーズとスロットタイプが表示されます。詳細については、Alexa Conversationsスキルモデルのデバッグを参照してください。

例

映画のチケットを予約するスキルを設計します。このスキルにはFindShowtimesのAPI定義があり、これにはMovieTitle型の引数titleが含まれています。

ユーザーが「映画『スターウォーズ』の上映時刻を検索して」と話しかけた場合、名前付きエンティティの認識では「スターウォーズ」が認識され、「スターウォーズ」をフレーズとして抽出し、このフレーズをMovieTitleスロットタイプとして次のようにラベル付けします。

{映画|Other}{スターウォーズ|MovieTitle}{の|Other}{上映時刻|Other}{を|Other}{検索して|Other}

Otherは、名前付きエンティティの認識で特定のスロットタイプが認識されなかったことを意味します。

後のランタイムステージでは、引数入力モデルによって、API定義FindShowtimesのMovieTitle引数に「スターウォーズ」と入力されます。この場合は、ユーザー指定のスロットです。

アクション予測

次に、アクション予測によって現在の会話のコンテキストが処理され、次に実行するアクションタイプとアクション名が予測されます。次の3つのアクションタイプがあります。

• API - スキルエンドポイントでAPIを呼び出します（チケット購入トランザクションの実行など）。
• 応答 - ユーザーに対する応答をレンダリングします（トランザクション結果の通知や追加情報のリクエストなど）。
• システム - 次のユーザー発話を待機します。このアクションタイプは、すべてのタスクが実行されたことを示す内部／システムアクションです。

アクション名にはAPI定義名または応答名を使用できます。推論エンジンは、システムアクションタイプが予測されるまで、1回のターンでアクション予測を複数回実行することがあります。Alexaシミュレーターのデバッグ機能では、APIアクションタイプと応答アクションタイプが表示されます。詳細については、Alexa Conversationsスキルモデルのデバッグを参照してください。

例

映画のチケットを予約するスキルを設計します。このスキルにはFindShowtimesのAPI定義があり、これにはMovieTitle型の引数titleが含まれています。次のダイアログで、ユーザーは「映画「スターウォーズ」の上映時刻を検索して」と話しかけます。

ユーザー： 映画「スターウォーズ」の上映時刻を検索して。
（API FindShowtimesを呼び出します。）
Alexa： 神戸XYZシネマで午後10時に上映されています。

このユーザー発話ではアクション予測が3回実行されています。最初の実行では、FindShowtimesという名前のAPIアクションタイプが予測され、APIが呼び出されます。2回目の実行では、InformMovieShowtimesという名前の応答アクションタイプが予測され、応答がレンダリングされます。3回目の実行では、システムアクションタイプが予測されます。このアクションタイプでは、アクション予測を終了し、現在のターンを終了して次のユーザー発話を待ちます。

引数入力

アクション予測がAPIアクションまたはResponseアクションを予測する場合は、次にエンティティを引数に入力する方法を決定します。エンティティは、ユーザーが言及したスロット、または以前のAPIからの戻り値です。引数入力では、コンテキストメモリデータを使用して、使用可能なすべてのエンティティにアクセスします。引数入力では、ユーザーとAlexaがダイアログ全体で言及したスロットを考慮するために、コンテキストのキャリーオーバーをサポートしています。引数入力は（エンティティと同じ型の）引数への入力に最も可能性の高いエンティティを選択します。このエンティティは、推論エンジンがアクションを呼び出すときに使用されます。

例

映画のチケットを予約するスキルを設計します。スキルにはFindShowtimesのAPI定義が含まれています。この定義には、MovieTitle型の引数（title）があり、スロットタイプShowTimeInfoを返します。これには、プロパティtime（スロットタイプAMAZON.Time）とtheaterName（スロットタイプTheaterName）があります。次のダイアログでは、ユーザーが「映画「スターウォーズ」の上映時刻を検索して」と話しかけます。

ユーザー： 映画「スターウォーズ」の上映時刻を検索して。
（API FindShowtimesを呼び出します。）
Alexa： 神戸XYZシネマで午後10時に上映されています。

推論エンジンは次のステップを実行します。

1. 名前付きエンティティの認識では、MovieTitleスロットタイプとして「スターウォーズ」というラベルが付けられ、コンテキストメモリに「スターウォーズ」スロットをエンティティタイトルとして保存します。
2. アクション予測では、最初の実行時にFindShowTimesという名前のAPIアクションを予測します。
3. 引数入力では、titleエンティティの「スターウォーズ」を使用してFindShowTimes APIのtitle引数に入力し、APIを呼び出します。
4. アクション予測は2回目の実行で、InformMovieShowtimesという名前の応答アクションを予測します。
5. 引数入力では、timeエンティティ（APIの戻り値のプロパティ）を使用してInformMovieShowtimes応答のtime引数に入力し、theaterNameエンティティ（APIの戻り値の別のプロパティ）を使用してInformMovieShowtimes応答のtheaterName引数に入力した後に、応答をレンダリングします。

エンティティ解決

アクション予測インスタンスがAPIアクションタイプを予測する場合、推論エンジンは引数入力が完了した後にエンティティ解決を実行します。API引数に入力するエンティティごとに、エンティティ解決はビルド時エンティティ（動的エンティティの場合はランタイムエンティティ）を検索し、一致する場合はフレーズを標準値に解決します。推論エンジンは、エンティティ解決の結果を個別のペイロードとして、スキルへのAPI呼び出しリクエストに挿入します。詳細については、リクエストを受け取るを参照してください。

エンティティ解決の詳細については、カスタムスロットタイプのエンティティ解決を参照してください。動的エンティティの詳細については、カスタマイズした対話に動的エンティティを使用するを参照してください。

関連トピック

• Alexa Conversationsについて
• Alexa Conversationsのダイアログアクトリファレンス
• Alexa Conversationsを使用した開発の概要

最終更新日: 2022 年 01 月 14 日