はじめに
Amazon Lexでは、組み込みインテントという、一般的なアクションに対して、AWS側で用意されている組み込みインテントライブラリが利用できます。
FallbackIntentは、ユーザーの発話がボットの想定するインテントと一致しない場合や、ユーザーの入力内容をスロット値として認識できない場合に誘発される組み込みインテントです。
今回は、FallbackIntentについて解説します。
組み込みインテントは、以下の通りインテントの追加することで利用できますが、例外としてFallbackIntentは、ボット作成時にデフォルトで追加されます。
また、FallbackIntentは削除することができません。
FallbackIntentでは、以下を追加することはできません。
- サンプル発話
- スロット
- 確認プロンプト
誘発されるケース
FallbackIntentは、以下の状況で誘発されます。
- ConnectからLexを呼ぶなどのオーディオ入力で、ノイズや声が聞き取れない場合
- ユーザーの入力が、ボットが想定するインテントのサンプル発話と一致しない場合
- ユーザー入力をインテントのスロット値として認識せず、試行回数を超えた場合
2点目と3点目のケースを解説します
サンプル発話と一致しない
サンプル発話と一致しない場合、FallbackIntentが誘発されるか、実際に試して確認します。
インテント（free）のサンプル発話は、「テスト」のみを設定します。もちろんFallbackIntentも存在します。
サンプル発話には設定されていない「こんにちは」を入力すると、以下の通りFallbackIntentが誘発されました。
ログは以下の通りです。ログの中では、interpretations内でFallbackIntentが記載されており、誘発されたことが確認できます。
コード (クリックすると展開します)
{
"timestamp": "2024-03-27T02:18:09.462Z",
"messageVersion": "2.0",
"bot": {
"name": "cm-hirai-test",
"version": "DRAFT",
"id": "5KMU82IFR2",
"aliasName": "TestBotAlias",
"aliasId": "TSTALIASID",
"localeId": "ja_JP"
},
"sessionState": {
"sessionAttributes": {},
"intent": {
"name": "FallbackIntent",
"state": "ReadyForFulfillment",
"confirmationState": "None",
"slots": {}
},
"dialogAction": {
"type": "Close"
},
"originatingRequestId": "e39bf83a-2402-4840-b8ec-2b55cb5aa732"
},
"inputTranscript": "こんにちは",
"missedUtterance": true,
"utteranceContext": {},
"sessionId": "540835513398385",
"dialogEventLogs": [
{
"nextStep": {
"dialogAction": {
"type": "InvokeDialogCodeHook"
}
},
"dialogStepLabel": "Intent/FallbackIntent/StartIntent"
},
{
"nextStep": {
"dialogAction": {
"type": "EndConversation"
}
},
"dialogStepLabel": "Intent/FallbackIntent/StartIntent/CodeHook/Success"
}
],
"requestId": "e39bf83a-2402-4840-b8ec-2b55cb5aa732",
"isTestWorkbenchTraffic": false,
"inputMode": "Text",
"operationName": "RecognizeText",
"interpretations": [
{
"intent": {
"name": "FallbackIntent",
"state": "ReadyForFulfillment",
"confirmationState": "None",
"slots": {}
},
"interpretationSource": "Lex"
},
{
"nluConfidence": "0.4",
"intent": {
"name": "free",
"slots": {}
},
"interpretationSource": "Lex"
}
],
"developerOverride": false
}試行回数を超えた場合
続いて、試行回数を超えた場合、FallbackIntentが誘発されますケースを解説します。
主に以下のときに誘発されます。
- 設定された試行回数後に、インテントがユーザーの入力内容をスロット値として認識しない場合
- 設定された試行回数後に、インテントが確認プロンプトへの応答としてユーザーの入力内容を認識しない場合
スロット値として認識しない場合を例に、実際に試してみます。
試行回数については、 スロットの[詳細オプション]→[その他のプロンプトオプション]から確認できます。デフォルトでは4回です。
それでは試してみます。
スロットタイプはAmazon.Numberを設定していますので、数字以外の入力は認識しません。
「はい」と入力します。
最大試行回数が4回なので、認識しない値を5回入力すると、FallbackIntentが誘発されました。
FallbackIntentをコンソール上で確認してみる
コンソール上に記載されている通り、サンプル発話やスロット、確認プロンプトの設定画面がなく、設定できません。
ダイアログコードフックは、デフォルトでアクティブでした。ただし、ボットの設定でLambdaを紐づけていないので、利用はできません。
ユースケース
FallbackIntentには、以下のようなユースケースが考えられます。
- エラーハンドリング
- ユーザーの入力がボットの想定外の場合、FallbackIntentを使ってエラーメッセージを返すことができます。Lambda関数で適切なレスポンスを定義しておけば、ユーザーエクスペリエンスを損なうことなく、スムーズにエラーハンドリングができます。
- 別のインテントへの誘導
- ユーザーの発話から適切なインテントが特定できない場合、FallbackIntentが誘発後、事前にFallbackIntentで設定した別のインテントを誘発させることができます。
- Lexから人へのエスカレーション
- FallbackIntentが一定回数呼び出された場合、Lambda関数でその回数を検知することで、人へのエスカレーションが可能です。
最後に
今回は、FallbackIntentについて解説しました。
他の組み込みインテントとは異なる部分やFallbackIntentのユースケースなどが頭の中で整理できました。どなたかの参考になれば幸いです。
7
