すべてを一度に尋ねる

ノード全体の初期プロンプトとして、提供してもらう必要がある情報の単位をユーザーに明確に伝えるプロンプトを指定します。 このプロンプトを最初に表示すると、ユーザーは、すべての詳細を一度に提供し、情報の各部分について一度に 1 つずつプロンプトが出されるのを待たないようにすることができます。

例えば、ユーザーがピザを注文しようとしてノードがトリガーされた場合、「I can take your pizza order. Tell me what size pizza you want and the time that you want it delivered.」のような最初のプロンプトで応答できます。

この最初の要求でユーザーから情報が 1 つでも提供された場合、このプロンプトは表示されません。 例えば、初期入力は、 I want to order a large pizza. 「アシスタントが入力を分析するときに、ピザのサイズとして large を認識し、指定された値を サイズ スロットに入力します。 スロットの 1 つに情報が取り込まれたので、ピザのサイズ情報をもう一度尋ねることを避けるために、初期プロンプトの表示をスキップします。 代わりに、情報が提供されていない残りのスロットのプロンプトを表示します。

スロット機能を有効にした「カスタマイズ」ペインから、 「すべてプロンプト」 チェック・ボックスを選択して初期プロンプトを有効にします。 この設定により、「どのスロットにも情報が取り込まれていない場合は、これを最初に尋ねる (If no slots are pre-filled, ask this first)」フィールドがノードに追加されるので、そこにユーザーにすべての情報の提供を求めるテキストを指定できます。

複数の値を取り込む

一連の項目を入力するように求めて、それらを 1 つのスロットに保存することができます。

例えば、ピザにトッピングを追加するかどうかをユーザーに尋ねることができます。 そのためには、エンティティー (@toppings) とその値として受け入れる値 (ペパロニ、チーズ、マッシュルームなど) を定義します。 ユーザーにトッピングを尋ねるスロットを追加します。 複数の値が提供された場合は、エンティティー・タイプの values プロパティーを使用して取り込みます。

後でユーザー指定のトッピングを参照するには、<? $entity-name.join(',') ?> 構文を使用して、トッピング配列内の各項目をリストし、値をコンマで区切ります。 例: I am ordering you a $size pizza with <? $toppings.join(',') ?> for delivery by $time.

値の形式を再設定する

ユーザーに情報の提供を求めて、入力された情報を応答で参照する必要があるので、わかりやすい形式で値を表示できるように値の形式を再設定することを検討してください。

例えば、時刻値は hh:mm:ss という形式で保存されます。 スロットの JSON エディターを使用して、時刻値の保存時に hour:minutes AM/PM という形式を使用するように形式を再設定することができます。

{
  "context":{
    "time": "<? @sys-time.reformatDateTime('h:mm a') ?>"
  }
}

ゼロの処理

スロット条件で @sys-number を使用すると、ユーザーが入力で指定する数値を取り込む場合に便利です。 ただし、ユーザーが数値 (0) ゼロを指定すると、予期したとおりに動作しません。 ゼロが有効な数値として処理されず、条件が false と評価され、アシスタントによって再度数値の指定を求めるプロンプトが表示されます。 この動作を防止するには、スロット条件でゼロ以上の @sys-number の言及をチェックします。

数値の言及をチェックするスロット条件でゼロが適切に処理されるようにするには、以下の手順を実行します。

1. スロット条件フィールドに @sys-number >= 0 を追加して、コンテキスト変数の値とテキスト・プロンプトを指定します。

   入力でチェックする内容は、スロット・コンテキスト変数に保存される内容と同じです。 しかし、このケースでは、数値 (5 など) だけを保存しようとしています。 5 > = 0 は保存するつもりはありません。 保存される内容を変更するには、コンテキスト変数の値を編集する必要があります。

2. 「スロットのカスタマイズ (Customize slot)」 アイコンをクリックして、編集するスロットを開きます。 「オプション」 メニューから、JSON エディターを開きます。

3. コンテキスト変数値を変更します。

   値は以下のようになります。

   {
     "context": {
       "number": "@sys-number >= 0"
     }
   }
   

   これを、以下のように変更します。

   {
     "context": {
       "number": "@sys-number"
     }
   }
   

4. 変更内容を保存します。

コンテキスト変数値に対して行った変更は、 「チェック対象 (Check for)」 フィールドに反映されません。 保存された内容を確認するには、JSON エディターを再オープンする必要があります。

ゼロを数値として受け入れない場合は、ゼロをチェックするスロットの条件付き応答を追加でき、さらに、ゼロより大きい数値を指定する必要があることをユーザーに伝えます。 ただし、入力として指定された場合は、スロット条件でゼロを認識できるようにすることが重要です。

確認を取る

収集した情報が正確かつ完全であることを確認するようにユーザーに求めるスロットを、他のスロットの後に追加します。 スロットで #yes または #no のインテントと一致する応答を検索することができます。

複雑な応答 ユーザーはこのダイアログの別の場面では、肯定や否定を文 (「はい、午後 5 時に届けてください」や「今夜は人数が少ないので、小さいのにします」) で示すことがあるため、slot_in_focus プロパティーを使用することにより、このスロットのみに関してはプロンプトに対して「はい」または「いいえ」という応答が必要であることをスロット条件の中で明確にします。

(#yes || #no) && slot_in_focus

slot_in_focus プロパティーは常にブール値 (true または false) に評価されます。 ブール値の結果が必要な条件にそれを組み込みます。 例えば、エンティティー・タイプをチェックしてからエンティティー値を保存するスロット条件では使用しないでください。

Not found のプロンプトで、ユーザーに「はい (Yes)」または「いいえ (No)」の応答を求めていることを明確に示します。

{
  "output":{
    "text": {
      "values": [
        "Respond with Yes to indicate that you want the order to
         be placed as-is, or No to indicate that you do not."
      ]
    }
  }
}

Found のプロンプトでは、「いいえ」の応答 (#no) をチェックする条件を追加します。 この応答が検出された場合は、情報を求める質問を最初からやり直し、それまでに保存したコンテキスト変数はリセットします。

{
  "conditions": "#no",
  "output":{
    "text": {
      "values": [
        "Let's try this again. Tell me what size pizza
         you want and the time..."
      ]
    }
  },
  "context":{
    "size": null,
    "time": null,
    "confirmation": null
  }
}

お客様からの要約情報の収集

保存して後で参照できるスロットを使用して、ダイアログ・ノードにフリー・フォーム・テキストを入力するように求めるプロンプトをユーザーに出すことができます。 これを行うには、以下の手順を実行します。

1. チェック対象 フィールドに、特殊プロパティー slot_in_focusを追加します。

2. オプションで、名前を付けて保存 フィールドのスロットのコンテキスト変数名を変更します。 例えば、summaryのような名前に変更することができます。

3. 存在しない場合は、確認してください フィールドで、ユーザーに自由記述式の情報を提供するように依頼します。 例: Can you summarize the problem?

4. 入力をお客様の正確な単語で保管するには、JSON エディターを使用して保存内容を編集します。

5. 「スロットのカスタマイズ (Customize slot)」 アイコンをクリックして、編集するスロットを開きます。 「オプション」 メニューから、JSON エディターを開きます。

6. コンテキスト変数値を変更します。

   値は以下のようになります。

   {
     "context": {
       "summary": "slot_in_focus"
     }
   }
   

   $summary コンテキスト変数に保存されている値を変更します。 ユーザーが送信するテキストをキャプチャーして保管する必要があります。 これを行うには、入力テキストをキャプチャーする SpEL 式を使用します。

   {
     "context": {
       "summary": "<? input.text ?>"
     }
   }
   

7. 変更内容を保存します。

コンテキスト変数値に対して行った変更は、 「チェック対象 (Check for)」 フィールドに反映されません。 保存された内容を確認するには、JSON エディターを再オープンする必要があります。

スロットのコンテキスト変数値を置換する

ユーザーがスロットを含むノードを終了する前の任意の時点で、ユーザーがスロットに新しい値を指定すると、新しい値がスロット・コンテキスト変数に保存され、前の値が置き換えられます。 Found 条件に定義されている特別なプロパティーを使用して、この置換が発生したことをダイアログで明示的に確認することができます。

• event.previous_value: このスロットのコンテキスト変数の以前の値。
• event.current_value: このスロットのコンテキスト変数の現在の値。

例えば、フライトの予約のダイアログで行き先の都市を尋ねるとします。 ユーザーが「Paris」と入力したとします。 この場合、$destination スロット・コンテキスト変数を パリに設定します。 その後、ユーザーは Oh wait. I want to fly to Madrid instead と入力します。 Found 条件を次のように設定すると、ダイアログでこのタイプの変更を正常に処理できます。

ユーザーが応答すると、 @destination が検出された場合は、以下のようになります。

Condition: (event.previous_value != null) &&
           (event.previous_value != event.current_value)
    Response: Ok, updating destination from
    <? event.previous_value ?> to <? event.current_value ?>.
Response: Ok, destination is $destination.

このスロット構成により、「Ok, updating the destination from Paris to Madrid.」と応答してユーザーによる目的地の変更に対応できます。

スロットへの情報の取り込みの混乱の回避

ユーザー入力が評価されると、それに最初に適合するスロット条件を持つスロットだけに情報が取り込まれます。 誤った解釈の原因として考えられる以下の事象が発生していないか検査して、それに対処してください。

• 問題: 同じエンティティーが複数のスロットで使用されている。

  例えば、@sys-date が 1 つのスロットでは出発日の取り込みに使用され、別のスロットでは到着日の取り込みに使用されている場合などです。

  解決策: スロットに日付を保存する前にそれが何の日付であるかを明確化するようユーザーに求める、スロットの found 条件を使用します。

• 問題: 用語の全部または一部が、複数のスロット条件のエンティティーと一致している。

  例えば、あるスロットで @id のような構文を使用して製品 ID (GR1234) を取り込み、別のスロットで @number などの構文を使用して数値 (1234) を取り込んでいる場合、BR3344 などのID が含まれるユーザー入力が、@number スロットによって数値参照であると断定され、$number コンテキスト変数に 3344 が取り込まれることがあります。

  解決策: スロットのリスト内で、より長いパターン (@id) を取り込むエンティティー条件を持つスロットを、より短いパターン (@number) を取り込む条件を持つスロットよりも上位に配置します。

• 問題: ある用語が複数のシステム・エンティティー・タイプとして認識されている。

  例えば、ユーザーが May 2 と入力した場合、アシスタントは @sys-date (2017-05-02) と @sys-number (2) の両方のエンティティーを認識します。

  解決策: スロット機能に固有のロジックでは、1 つのユーザー入力で 2 つのシステム・エンティティーが認識された場合は、長い方のエンティティーが使用されます。 したがって、アシスタントがテキスト内で両方のシステム・エンティティーを認識したとしても、長い方のシステム・エンティティー (@sys-date つまり 2017-05-02) のみが登録されてスロットに適用されます。

  改良されたシステム・エンティティーを使用する場合は、この回避策は不要です。 更新されたエンティティーでは、日付参照は @sys-date の言及としてのみ認識され、@sys-number の言及としても扱われるということはありません。 詳細については、システム・エンティティーを参照してください。

Found の応答と Not Found の応答に条件を追加する

スロットごとに、条件付き応答と関連アクションを使用して、ユーザーから必要な情報を抽出することができます。 これを行うには、以下の手順を実行します。

1. 条件付き Found 応答および Not Found 応答を追加するスロットの 「スロットのカスタマイズ (Customize slot)」 アイコンをクリックします。

2. その他 メニューから 条件付き応答を有効にするを選択します。

3. 条件と、その条件が満たされている場合に表示される応答を入力します。

   検出された例: スロットは夕食の予約の時間を待っています。 これは、*「チェック対象 (Check for)」*フィールドで @sys-time を使用して取り込むことができます。 無効な時刻が保存されないようにするには、提供された時刻がレストランの最終座席時刻より前であるかどうかをチェックする条件付き応答 (例: @sys-time.after('21:00:00')) を追加します。 対応する応答は、 「最後の座席は午後 9 時 (our last seating is at 9PMのようになります。

   Not found の例: スロットは、テイクアウト・オーダーのピザの数に対して @sys-number エンティティーを予期しています。 true の Not found 条件は、会話に数値が指定されていない場合 (例えば、 We need to know how many pizzas you want.) に備えて、ユーザーにプロンプトを出すメッセージを表示するために使用されることがあります。

4. 条件が満たされた場合に次に起こることをカスタマイズする場合は、 「ハンドラーのカスタマイズ」 アイコンをクリックします。

   「チェック対象 (Check for)」フィールドに指定されている値タイプに一致する値をユーザーが指定したときに表示される「検出された応答 (Found responses)」については、以下のいずれかのアクションを選択できます。

   • 進む (Move on) (デフォルト): 応答の表示後に、次の空スロットへ進むようにアシスタントに指示します。 関連する応答で、ユーザーの入力が認識されたことをユーザーに明確に示します。 例えば、OK です。 $date にスケジュールする必要があります。
   • スロットをクリアして再度プロンプトを出す: 誤った値をピックアップする可能性があるエンティティーを 「チェック対象 (Check for)」 フィールドで使用している場合は、考えられる解釈の誤りを検出する条件を追加し、このアクションを使用して現在のスロット値をクリアし、正しい値を求めるプロンプトを出します。
   • 「応答にスキップ (Skip to response)」: 定義した条件が満たされている場合は、このノードの残りのスロットを埋める必要はありません。このアクションを選択して残りのスロットをスキップし、次にノード・レベルの応答に直接進みます。 例えば、ユーザーの年齢が 16 歳未満かどうかを検査する条件を追加できます。 その場合は、ユーザーの運転記録について質問する残りのスロットをスキップすることができます。

   「Not found」の応答 (ユーザーが有効な値を指定しない場合に表示される) については、以下のいずれかのアクションを選択できます。

   • ユーザー入力を待機する (Wait for user input) (デフォルト): 会話が一時停止され、アシスタントはユーザーの応答を待機します。 最も単純な事例では、ユーザーに提供してもらう必要がある情報のタイプをより明確に示すテキストをここで指定できます。 このアクションと条件付き応答を併用する場合、その条件付き応答は、ユーザーの回答のどこが間違っていて、代わりにどんな情報を提供する必要があるのかを明確に示すものにしてください。

   • 再プロンプト (Prompt again): Not found の応答の後で、アシスタントはスロット・プロンプトを再度繰り返し、ユーザーの応答を待機します。 このアクションと条件付き応答を併用する場合、その応答は、ユーザーが提供した回答のどこが間違っているかだけを説明するものにすることができます。 ユーザーに提供してもらう必要のある情報のタイプは、通常はスロットのプロンプトで説明されるので、ここで繰り返し説明する必要はありません。

     このオプションを選択する場合は、Not found の応答のバリエーションを 1 つ以上追加して、まったく同じテキストがユーザーに複数回表示されることがないようにすることを検討してください。 さまざまな言い回しを用いて、提供してもらう必要のある情報とその形式をユーザーに説明することができます。

   • このスロットをスキップ (Skip this slot): 現在のスロットへの情報の取り込みの試行を停止し、代わりに次の空スロットのプロンプトに進むようにアシスタントに指示します。 このオプションは、スロットをオプションにし、なおかつそのスロットでユーザーに情報を求めるプロンプトを表示したい場合に役立ちます。 例えば、 外部、 暖炉の近くで、 非公開などのレストランの座席設定をキャプチャーする @seating エンティティーがあるとします。 その状況で、ユーザーに「座席の好みはありますか?」というプロンプトを出して @seating.values をチェックするスロットを追加しているとします。 有効な応答が提供されると、好みに関する情報が $seating_preferences に保存されるようになっています。 しかし、ユーザーが有効な値を提供しない場合にはこのスロットに情報を取り込むのをやめるようアシスタントに指示したい場合には、Not found の応答の次のステップとしてこのアクションを選択することができます。

   • 「応答にスキップ (Skip to response)」: 定義した条件が満たされている場合は、このノードの残りのスロットを埋める必要はありません。このアクションを選択して残りのスロットをスキップし、次にノード・レベルの応答に直接進みます。 例えば、片方向フライト情報をキャプチャーするときに、スロット・プロンプトが 「往復チケットを購入しますか?」 の場合、「Not found」条件で #Noを確認できます。 #No が見つかった場合は、このオプションを使用して、返品フライトに関する情報をキャプチャーする残りのスロットをスキップし、代わりにノード・レベルの応答に直接進みます。

   **「戻る」**をクリックして、スロットの編集ビューに戻ります。

5. 別の条件付き応答を追加するには、「応答の追加 (Add a response)」 をクリックしてから、条件と、その条件が満たされている場合に表示される応答を入力します。

   何が使用されていても、必ず少なくとも 1 つの応答を追加してください。 このキャッチオール応答では、条件フィールドをブランクのままにすることができます。 アシスタントは空の条件フィールドに true 特殊条件を自動的に取り込みます。

6. **「保存」**をクリックして変更を保存し、スロットの編集ビューを閉じ、ノードの編集ビューに戻ります。

試行が複数回失敗した場合に先に進む

Not found の条件付き応答を使用することにより、ユーザーが複数回試行してもスロットに正しく回答できない場合に、そのスロットから離脱できるようにすることができます。 キャッチ・オール応答で、JSON エディターを開き、Not found の応答が返された回数を追跡するカウンター・コンテキスト変数を追加します。 それより前のノードで、初期カウンター・コンテキスト変数の値が 0 に設定されていることを確認してください。

この例では、アシスタントによりピザのサイズが尋ねられます。 ユーザーがこの質問に 3 回誤って回答すると、ユーザーの変数にサイズ (M) が適用されます。 (ユーザーが注文情報の確認を求められたときに常にサイズを訂正できる確認スロットを含めることができます。)

チェック対象 (Check for): @size 保存名 (Save it as): $size Not found の catchall 条件:

{
  "output": {
    "text": {
      "values": [
        "What size did you want? We have small, medium, and large."
      ],
      "selection_policy": "sequential"
    }
  },
  "context": {
    "counter": "<? context['counter'] + 1 ?>"
  }
}

3 回の試行後に異なる応答をするために、次のような別の Not Found の条件を追加します。

{
  "conditions": "$counter > 1",
  "output": {
    "text": {
      "values": [
        "We will bring you a size medium pizza."
      ]
    }
  },
  "context": {
    "size": "medium"
  }
}

この Not found 条件は、デフォルトで true になる Not found の catchall 条件よりも正確です。 したがって、この応答を移動して、元の条件付き応答より前に配置する必要があります。そうしなければ、これはトリガーされません。 条件付き応答を選択し、上矢印を使用して上に移動します。

Found 応答が不要な場合は非表示にする

複数のスロットに Found 応答を指定した場合に、ユーザーが複数のスロットの値を一度に入力すると、1 つ以上のスロットの Found 応答が表示されます。 すべてのスロットの Found 応答を返す必要がある場合もあれば、何も返す必要がない場合もあります。

Found 応答を非表示にするには、Found 応答ごとに次のいずれかを実行します。

• 特定のスロットに情報が取り込まれた場合に応答を表示しないようにする条件を、応答に追加します。 例えば、!($size && $time) のような条件を追加すると、コンテキスト変数 $size と $time が両方とも提供された場合に応答を非表示にすることができます。
• !all_slots_filled 条件を応答に追加します。 この設定により、すべてのスロットに情報が取り込まれると、応答が表示されなくなります。 確認スロットを組み込む場合は、この方法を使用しないでください。 確認スロットもスロットであるため、一般的には、確認のスロット自体に情報が取り込まれるまでは、Found 応答を非表示にする必要があります。

プロセスを終了する要求を処理する

ユーザーがノードを終了しようとしていることを認識できる 1 つ以上のスロット・ハンドラーを追加します。

例えば、ペットのグルーミング予約をスケジュールするための情報を収集するノードで、 Forget it. I changed my mind などの発話を認識する #cancel インテントを条件とするハンドラーを追加できます。

1. このハンドラーの JSON エディターで、すべてのスロット・コンテキスト変数にダミー値を入力して、欠落している情報をノードが尋ね続けるのを回避します。 ハンドラーの応答に、Ok, we'll stop there. No appointment will be scheduled.などのメッセージを追加します。

2. 以下のオプションから、アシスタントが次に実行するアクションを選択します。

   • 再プロンプト (Prompt again) (デフォルト): 本題から外れた質問を尋ねる直前にユーザーが対話していたスロットのプロンプトを表示します。
   • 現在のスロットをスキップ (Skip current slot): 本題から外れた質問を尋ねる直前にユーザーが対話していたスロットの後のスロットに関連付けられているプロンプトを表示します。 また、アシスタントはスキップされたスロットにこれ以上情報の取り込みを試行しません。
   • 応答にスキップ (Skip to response): 本題から外れた質問を尋ねる直前にユーザーが対話していたスロットを含め、残りのすべての空スロットのプロンプトをスキップします。

3. ノード・レベルの応答で、スロット・コンテキスト変数のいずれかにダミー値が設定されていないかをチェックする条件を追加します。 見つかった場合は、「 If you decide to make an appointment later, I'm here to help. If not found, it display the standard summary message for the node, such as I am making a grooming appointment for your $animal at $time on $date. 」のような最終メッセージを表示します。

次に、ピザの例でハンドラーを定義する JSON のサンプルを示します。 前述のように、コンテキスト変数はすべてダミー値に設定されることに注意してください。 実際、$size コンテキスト変数は dummy に設定されます。 この $size 値は、ノード・レベルの応答をトリガーして、該当するメッセージを表示し、スロット・ノードを終了します。

{
"conditions": "#cancel",
 "output": {
   "text": {
     "values": [
       "Ok, we'll stop there. No pizza delivery will be scheduled."
     ],
    "selection_policy": "sequential"
    }
  },
"context": {
   "time": "12:00:00",
   "size": "dummy",
   "confirmation":"true"
}
}

重要: この条件より前に評価される条件で使用されているロジックを考慮して、異なる条件を組み込んでください。 ユーザー入力を受け取ると、条件は次の順序で評価されます。

• リストされている順序で処理されるスロット・ハンドラー。
• 最初のスロット条件。
• 現在のスロット・レベルの Found の条件。
• 脱線が許可される場合は、ルート・レベルのノード条件で一致がチェックされます (ダイアログ・ツリーのルートまたはルート・フォルダーの最後の anything else ノードを除く)。
• 現在のスロット・レベルの Not found の条件。
• 最後の anything else ノードの条件。

スロット・ハンドラーとして、常に true と評価される条件 (特殊条件、 true および anything_else など) を追加する場合は注意してください。 スロットごとに、スロット・ハンドラーが true と評価された場合は、Not found の条件が完全にスキップされます。 したがって、常に true と評価されるスロット・ハンドラーを使用すると、実質的にすべてのスロットの Not found の条件が評価されなくなります。

例えば、ネコ以外の動物のトリミングを行うとします。 Animal スロットで、catを Animal スロットに保存しないようにする次のスロット条件を使用したくなるでしょう。

Check for @animal && !@animal:cat, then save it as $animal.

また、猫を受け入れないことをユーザーに通知するには、動物スロットの Not found の条件に以下の値を指定します。

If @animal:cat then, "I'm sorry. We do not groom cats."

論理は合っていますが、#exit スロット・ハンドラーも定義する場合は、条件評価の順序を考慮すると、この Not found の条件はトリガーされない可能性が濃厚です。 代わりに、次のスロット条件を使用することができます。

Check for @animal, then save it as $animal.

catという応答に対処するために、この値を Found 条件に追加します。

If @animal:cat then, "I'm sorry. We do not groom cats."

$animal コンテキスト変数の値は現在「ネコ」に設定されていますが、それは許可されないため、Found 条件の JSON エディターで値をリセットします。

{
  "output":{
    "text": {
      "values": [
        "I'm sorry. We do not groom cats."
      ]
    }
  },
  "context":{
    "animal": null
  }
}