Amazon Lex の Assisted NLU でボットの精度を向上させる
本文の状態
日本語全文を表示中
詳細モードで約23分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
AWS Machine Learning Blog
AWS は、顧客の自然な発話や曖昧な表現に対応する新機能「Assisted NLU」を Amazon Lex に追加し、チャットボットの認識精度を高めることを発表した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Amazon Lex におけるボットの精度向上は、顧客が自然にコミュニケーションを行う方法をどう扱うかから始まります。顧客は同じリクエストを数十通りの異なる表現で伝えたり、1 つの文の中に複数の情報を組み合わせたり、しばしば曖昧な表現を使ったりします。Amazon Lex の Assisted NLU（自然言語理解）機能は、これらの自然言語のバリエーションを処理することで、ボットの精度向上をサポートします。従来の自然言語理解システムはこの多様性に対処するのが難しく、その結果、顧客が同じことを繰り返したり、会話から離れてしまったりすることがあります。
課題: ルールベースの NLU システムでは、開発者が考えられるすべての発話バリエーションを手動で設定する必要があり、これは時間がかかる作業でありながら、まだカバー範囲に隙間が残ります。「ホテルを予約する」というデータで訓練されたホテル予約ボットは、「旅行のための宿泊施設を予約したい」と顧客が言った場合に失敗します。「12 月 15 日から 18 日まで、シアトル市内のロケーションでスイートルームを予約してほしい」といった複雑なリクエストでは、重要な詳細（部屋の種類、場所、日付）が見失われがちです。「予約についてサポートが必要だ」といった曖昧な表現は、ボットが顧客が予約したいのか、確認したいのか、変更したいのか、キャンセルしたいのかを推測させることになります。
解決策: Amazon Lex Assisted NLU機能は、大規模言語モデル（LLM）を活用して自然言語のバリエーションを理解し、ボットの精度を向上させます。手動での設定は不要です。従来の機械学習（ML）とLLMを組み合わせることで、Assisted NLUは実際の顧客がどのようにコミュニケーションを行うかを処理し、認識精度を高める自然な対話体験を創出します。
Assisted NLU（プライマリモード、フォールバックモード、および意図の曖昧さ解消を含む）は、標準的なAmazon Lex料金に含まれており、追加費用はかかりません。
本記事では、Assisted NLUを効果的に実装する方法について学びます。効果的な意図とスロットの説明を用いてボット設計を改善する方法や、Test Workbenchを使用して実装を検証する方法、さらに新規および既存のボットにおいて従来のNLUからAssisted NLUへの移行計画を立てる方法について解説します。
前提条件: このガイドでは、Amazon Lexの概念（意図、スロット、発話）に精通していることを前提としています。Amazon Lexが初めての場合は、入門ガイドから始めることをお勧めします。
Assisted NLU の紹介
Amazon Lex Assisted NLU は、大規模言語モデル（LLM）を活用して、意図分類とスロット解決の機能を強化します。ユーザーの入力を理解するために、登録された意図やスロットの名前および説明を利用します。入力に含まれる誤字、複雑な表現、複数のスロットを同時に抽出する処理も、すべてのバリエーションを手動で設定する必要なく処理可能です。Amazon Lex Assisted NLU は自然言語理解タスク全体のパフォーマンスを向上させ、平均して 92 パーセントの意図分類精度と 84 パーセントのスロット解決精度を達成しています。数百社のアクティブな顧客が Assisted NLU に導入されており、実環境での展開においてこれらの改善が検証されています。顧客からは、意図分類の精度が 11～15 パーセント向上し、フォールバック応答が 23.5 パーセント減少し、ノイズの多い入力への対応が 30 パーセント改善されたという報告があります。早期採用者からは、会話型 AI の実装において顕著な改善が見られ、初期テスト結果に基づいてより広範な展開を計画している事例も複数あります。
Assisted NLU は以下の 2 つのモードで動作します：
- プライマリモード：LLM をすべてのユーザー入力を処理する主要手段として使用
- フォールバックモード：従来の NLU をまず使用し、信頼度が低い場合や FallbackIntent にルーティングされる場合にのみ LLM の呼び出しを実行
Amazon Lex コンソールで数回の選択を行うだけで Assisted NLU を有効化できます。ボットのロケール設定に移動し、Assisted NLU をオンにし、希望のモードを選択して、ボットを構築してください。
詳細な設定手順、API リファレンス、および段階的な有効化ガイドについては、Amazon Lex 開発者ガイドの Assisted NLU の有効化 をご覧ください。
プログラムによる設定については、NluImprovementSpecification API リファレンス を参照してください。
1. Assisted NLU 実装のためのベストプラクティス
以下のベストプラクティスは、モードの選択、記述の作成、スロットの最適化、および意図の曖昧さ解消を網羅し、Assisted NLU から最大限の効果を引き出すのに役立ちます。
1.1 運用モード：プライマリとフォールバック
プライマリモードでは、LLM（大規模言語モデル）がすべてのユーザー入力に対して使用されます。一方、フォールバックモードでは、まず従来の NLU（自然言語理解）が使用され、信頼度が低い場合や FallbackIntent（フォールバック意図）にルーティングされる場合にのみ LLM の呼び出しが行われます。
DO:
- 新しいボットを構築する場合、または意図ごとにトレーニングデータが限られている場合（20 未満のサンプル発話）、プライマリモードを使用してください。
例：患者が「膝について誰かに見てほしい」「来週心臓専門医と予約してほしい」と発言し、広範な発話エンジニアリングを必要としない、診察予約を扱うヘルスケア用ボットなど。
- 既存のボットで既に良好に動作している場合は、フォールバックモードを使用してください。
例：95% の精度を誇る確立された銀行用ボットで、「残高を確認」ではなく「残高はどうなっているか？」といったバリエーションで時々失敗する場合でも、LLM がこれらのエッジケースを検出します。
- Amazon CloudWatch Logs 内の fulfilledByAssistedNlu メトリクスを監視し、ユースケースに最適なモードを判断してください。フォールバックモードでリクエストの 30% 以上が LLM を呼び出す場合、一貫性を保つためにプライマリモードへの切り替えを検討してください。
避けるべきこと:
- 精度向上が見込めないのに、よく動作しているボットに対して A/B テストなしにプライマリモードへ切り替えないでください。これにより不要なレイテンシが生じる可能性があります。
- 一つのモードがすべてのユースケースに通用すると考えないでください。適切なモードは、特定のデータ分布とユーザーの言語パターンによって決定されます。
1.2 効果的な意図記述の作成
意図記述は、チーム向けのドキュメントではなく、LLM（大規模言語モデル）に対するプロンプトです。これらは分類に使用される主要なシグナルであり、その品質が直接精度を決定します。これは、プロンプトの質が LLM の出力品質を決定することと同じ原理です。一貫したパターンは信頼できる結果をもたらします：「[動詞] を [対象/エンティティ] する [文脈/制約]」という形式です。
- 「～を行う」という記述は、意図の目的にアンカー（固定点）を打ち、LLM がユーザーが達成しようとしていることを評価する方法と整合性を持たせます。
- 動詞は明確な区別を生み出します。「予約する」「キャンセルする」「変更する」「確認する」などの動詞は曖昧さがなく、LLM が意図を自信を持って区別できるようにします。
- 対象とエンティティはターゲットを特定します。「ホテルを予約する」対「車を予約する」対「フライトを予約する」は、それぞれ異なるユーザーのゴールにマッピングされます。
- 文脈はエッジケース（境界事例）を解決します。例えば、「医療上の緊急事態によるフライトキャンセル」という制約を追加した記述と、「スケジュールの衝突によるフライトキャンセル」という記述では、違約金の免除資格や返金ポリシーを判断する際に役立つ可能性があります。
DO:
1.2 効果的な意図記述の作成
意図記述は、チーム向けのドキュメントではなく、LLM（大規模言語モデル）に対するプロンプトです。これらは分類に使用される主要なシグナルであり、その品質が直接精度を決定します。これは、プロンプトの質が LLM の出力品質を決定することと同じ原理です。一貫したパターンは信頼できる結果をもたらします：「[動詞] を [対象/エンティティ] する [文脈/制約]」という形式です。
- 「～を行う」という記述は、意図の目的にアンカー（固定点）を打ち、LLM がユーザーが達成しようとしていることを評価する方法と整合性を持たせます。
- 動詞は明確な区別を生み出します。「予約する」「キャンセルする」「変更する」「確認する」などの動詞は曖昧さがなく、LLM が意図を自信を持って区別できるようにします。
- 対象とエンティティはターゲットを特定します。「ホテルを予約する」対「車を予約する」対「フライトを予約する」は、それぞれ異なるユーザーのゴールにマッピングされます。
- 文脈はエッジケース（境界事例）を解決します。例えば、「医療上の緊急事態によるフライトキャンセル」という制約を追加した記述と、「スケジュールの衝突によるフライトキャンセル」という記述では、違約金の免除資格や返金ポリシーを判断する際に役立つ可能性があります。
DO:
- インテントの説明は「Intent to...」から始め、その後に明確な動詞を続けてください。
例："Intent to book a hotel room for overnight accommodation"
- 既存のサンプル発話（utterances）から説明を導き出してください。これらはユーザーがどのように話すかを反映しており、LLM に対する最も強力なシグナルとなります。
例："book a room"や"reserve a suite"といった説明は、"Intent to book or reserve a hotel room or suite for an overnight stay"となります。
- 類似するインテントの区別（disambiguation）が必要な場合は、ドメインコンテキストを追加してください。
例："Intent to book a hotel room on StayBooker"とすることで、LLM の理解を具体化できます。
- 実際の会話分析から得られるユーザーの語彙を模倣してください。
例：顧客が"reservation"と言う場合、その用語を一貫して使用してください。
- デプロイ前にエッジケース（edge case）の発話に対して説明を検証してください。
例："I need a place to stay"という文が正しく BookHotel インテントにルーティングされるか確認してください。
避けるべき点：
- 説明欄は空にするか、プレースホルダーテキストを使用してください。
悪い例："TBD"や"Intent 1"では、LLM（大規模言語モデル）に対して何のシグナルも伝わりません。
- 単一の意図に複数のアクションを組み合わせないでください。
悪い例："ホテル予約と管理を行う意図"は、別々の意図に分割することを検討してください。
- 異なる意図間で重複する言語表現を使用しないでください。
悪い例："口座残高を確認する"と"口座取引履歴を確認する"では、分類が混乱します。
- 説明欄にスロット値や具体的な例を含めないでください。
悪い例："シアトルのホテルを2泊予約する意図"は、マッチングの条件を過度に制限してしまいます。
1.3 スロット説明の改善
スロット説明は、LLM（大規模言語モデル）に対して、何を抽出すべきか、またそれをどのように解釈すべきかという文脈的なシグナルを提供します。説明がより強力で具体的であればあるほど、LLM は関連する値を効果的に優先できるようになります。Assisted NLU（支援型自然言語理解）が進化するにつれ、スロット説明は抽出決定においてますます重要な役割を果たすようになります。今日、正確な説明を作成しておくことは、将来の改善を自動的に活用できるボットを用意することにつながります。効果的な説明には、以下のパターンに従ってください：[スロットが捉えるもの] [文脈的制約] [有効値ガイダンス]
- スロットがキャプチャする内容は、スロットがユーザーの入力から抽出する特定の情報の一部を定義します。例えば、都市名、日付、または数値などが該当します。
- 文脈制約は範囲を絞り込みます。「ホテル予約のチェックイン日であり、チェックアウトや予約日ではない」という指示により、LLM は「12 月 15 日から 18 日まで」のような入力から正しい日付を抽出できます。
- 有効値ガイダンスは曖昧さを解消します。「USD、EUR、JPY などの 3 文字の ISO 通貨コード」という指示により、LLM は「ユーロ」や「日本円」といった入力を標準コードに変換でき、スロットタイプ内で完全な通貨カタログを維持する必要がありません。
DO:
翻訳全文
- スロット記述を使用して、専用の組み込みスロットタイプを必要とせずに値を解決します。
例：空港コードを取得するには、AMAZON.AlphaNumeric を使用し、記述に「有効な IATA 空港コード（例：SEA, JFK, LAX）」と記載します。LLM はこの文脈を使用して自然言語からコードを抽出し、「シアトルから出発する」という表現を SEA にマッピングしますが、カスタムスロットタイプですべての値を列挙する必要はありません。
- 2 つの AMAZON.Number スロット（宿泊日数とゲスト数）がある場合、記述は LLM が類似したスロットタイプを区別するために重要です。
例：「ホテル滞在の宿泊日数」対「チェックインするゲストの数」— これらがなければ、LLM は「3」という値を正しいスロットに割り当てるのに苦労する可能性があります。
- スロットの意図内での役割を明確にします。
例：ホテル予約の意図に対して「チェックイン日」と指定することで、チェックイン日、チェックアウト日、予約日の間の曖昧さを排除できます。
- ビジネスルールに一致する制約を指定します。
例：「ホテル滞在の宿泊日数」は、これは部屋数やゲスト数ではなく、期間のカウントであることを明確にします。
- スロット記述を使用して、拡張された値解決を行うカスタムスロットについて各値の意味を定義します。
例：Standard（標準）、Deluxe（デラックス）、Suite（スイート）の値を持つ RoomType カスタムスロットで、「ホテルの部屋のタイプ。Standard は基本ルーム、Deluxe は追加アメニティ付きの中級階層ルーム、Suite は最も広々とした最上級階層のラグジュアリールームで、キッチンが備わっている」という記述を使用すると、LLM は自然言語を正しいカテゴリにマッピングできます。顧客が「キッチンがある部屋」や「最大の部屋」と言った場合、LLM は記述内で提供された意味的な文脈に基づいて、これらを Suite に解決します。
避けるべき点:
- スロット記述を空のままにしないこと、特にカスタムスロットでは特に重要です。
悪い例：説明のない「支払い」というスロットは、LLM に期待する通貨フォーマットについての指針を与えません。
- スロットタイプだけで十分な文脈が得られると仮定しないこと。
悪い例：AMAZON.Number タイプだけでは、宿泊日数、ゲスト数、部屋数、または確認番号のいずれを指すのかを特定できません。
- スロットタイプと矛盾する記述を使用しないこと。
悪い例：「口座番号」と説明しながら AMAZON.Number タイプを使用すると、フォーマットされた口座番号の抽出に問題が生じる可能性があります。
- ビジネスロジックが変更された際に記述を更新することを忘れないこと。
悪い例：国際都市への展開を開始しても、「米国のみ」という記述をそのまま残す場合などです。
1.4 インテントの曖昧さ解消に関するベストプラクティス
複数のインテントがユーザーの入力に一致する可能性がある場合、支援型 NLU（Natural Language Understanding：自然言語理解）は、ユーザーの意図を明確にするために曖昧さ解消のオプションを表示します。適切に設計された曖昧さ解消により、摩擦を減らし、会話を軌道に乗せることができます。
実施すべきこと：
- 重複しない、明確で区別された意図名と説明を使用してください。これらは LLM が曖昧さ解消の判断を行うために使用する主要な入力です。
例：「BookHotelRoom」を「将来の日付のホテル部屋を予約する」という説明付きで、「CancelHotelReservation」を「既存のホテル予約をキャンセルする」という説明付きで使う – 目的が明確に区別されています。
- 技術的な意図名に対して、ユーザーフレンドリーな表示名を提供してください。表示名が実際の意図名と一致し、それを明確に表現していることを確認してください。
例：意図名「ModifyReservationDates」に「予約日を変更する」という表示名を付与することで、ユーザーにとって選択肢が即座に明確になります。
- 意図オプションの最大数を慎重に設定してください。十分な選択肢を提供することと、テストを通じて意思決定のパラライシス（判断麻痺）を防ぐことのバランスを取ってください。
例：曖昧さ解消は最大で 3〜4 のオプションに制限します。「ホテルを予約する」が 6 つの意図に一致する可能性がある場合、意図設計が細分化されすぎています。
- ユーザーの入力を認識した上で、簡潔な曖昧さ解消メッセージを作成してください。ユーザーが適切な意図オプションを選択するように自然に誘導します。
例：「ホテル予約のお手伝いをいたします。ご希望は？」と続けて明確な選択肢を示すようにし、「意図を選択してください」とだけ表示するのではなく。
- 曖昧な発話で徹底的にテストしてください。曖昧さ解消のフローが自然であり、常に正しい意図オプションを提示していることを検証します。
例：「予約についてサポートが必要です」といったフレーズを、予約、変更、キャンセルの各意図に対してテストし、正しいオプションが表示されるか確認します。
避けるべきこと：
- 重複する意図名や説明を使用しない。これらは LLM が曖昧さ解消の判断を行うために使用する主要な入力です。
例：「BookHotelRoom」を「将来の日付のホテル部屋を予約する」という説明付きで、「CancelHotelReservation」を「既存のホテル予約をキャンセルする」という説明付きで使う – 目的が明確に区別されています。
- 技術的な意図名に対して、ユーザーフレンドリーな表示名を提供してください。表示名が実際の意図名と一致し、それを明確に表現していることを確認してください。
例：意図名「ModifyReservationDates」に「予約日を変更する」という表示名を付与することで、ユーザーにとって選択肢が即座に明確になります。
- 意図オプションの最大数を慎重に設定してください。十分な選択肢を提供することと、テストを通じて意思決定のパラライシス（判断麻痺）を防ぐことのバランスを取ってください。
例：曖昧さ解消は最大で 3〜4 のオプションに制限します。「ホテルを予約する」が 6 つの意図に一致する可能性がある場合、意図設計が細分化されすぎています。
- ユーザーの入力を認識した上で、簡潔な曖昧さ解消メッセージを作成してください。ユーザーが適切な意図オプションを選択するように自然に誘導します。
例：「ホテル予約のお手伝いをいたします。ご希望は？」と続けて明確な選択肢を示すようにし、「意図を選択してください」とだけ表示するのではなく。
- 曖昧な発話で徹底的にテストしてください。曖昧さ解消のフローが自然であり、常に正しい意図オプションを提示していることを検証します。
例：「予約についてサポートが必要です」といったフレーズを、予約、変更、キャンセルの各意図に対してテストし、正しいオプションが表示されるか確認します。
避けるべきこと：
- 曖昧解消パターンを無視しないでください。頻繁に曖昧解消トリガーとなる意図を監視し、混乱を減らすためにそれらを洗練させてください。
悪い例：「予約を確認する」というフレーズが常に「ViewReservation」、「ModifyReservation」、および「VerifyReservation」の間で曖昧解消を引き起こす場合、これらの意図を統合するか明確化してください。
- 曖昧解消を包括的な解決策として使用しないでください。会話の大半が曖昧解消に到達する場合、意図設計には根本的な改善が必要です。
悪い例：ユーザー要求の大多数が曖昧解消を引き起こす場合、これはより良い曖昧解消メッセージではなく、再設計が必要な重複する意図定義を示しています。
- 曖昧解消の失敗への対応を忘れないでください。ユーザーがどのオプションも選択しない場合に備えて、明確なフォールバック戦略を用意してください。
悪い例：ユーザーが「どちらも違う」や「別のもの」と言う際に、同じ曖昧解消オプションを繰り返し表示するのではなく、人間サポートへエスカレーションさせるべきです。
- 曖昧解消を設定して放置するものとして扱わないでください。ユーザーの選択を継続的に分析し、混乱ポイントを特定して、時間とともに意図の分離を改善してください。
悪い例：ユーザーがどの曖昧解消オプションを選択するかを一度もレビューしないこと。3 つの選択肢が表示されたときに全員が 2 番目のオプションを選ぶ場合、1 番目と 3 番目のオプションは不要かもしれません。
これらのベストプラクティスを適用した後、体系的なテストを通じて設定を検証してください。
2. Assisted NLU の実装テスト
意図とスロットの説明を準備した上で、次のステップは検証です。Amazon Lex テストワークベンチを使用して、Assisted NLU 設定が実際の世界の発話のバリエーションをどの程度適切に処理できるかを測定してください。
テストワークベンチの設定と使用方法については、Test Workbench Documentation および デモ動画 を参照してください。
重要: テストセットの実行を設定する際は、Assisted NLU が有効になっているボットとエイリアスを選択してください。選択されたエイリアスが Fallback または Primary モードが設定されたバージョンを指している場合にのみ、テストで Assisted NLU が実行されます。
2.1 何をテストすべきか
Assisted NLU が最も価値を発揮する箇所に焦点を当ててください：エッジケース。標準的な表現から外れた入力をテストして、Assisted NLU が実際の現場の複雑さをどのように処理するかを検証します:
- タイポや文法エラー: "i wanna book an hotell"
- 口語的表現: "hook me up with a room downtown"
- 曖昧なリクエスト: "I need transportation"
- 不完全な発話: "booking for next week"
スロットのバリエーション
組み込みスロットについては、日付形式（"next Tuesday", "the 15th"）、場所の別名（"NYC", "New York City"）、名前のバリエーション（"Bob" と "Robert" の比較）、およびメール形式（"john dot doe at gmail dot com"）などのバリエーションをテストしてください。
カスタムスロットについては、ユーザーの発話が定義された値にマッピングされるかテストしてください。特に拡張モードでは重要です。例えば、「RoomType」スロットにおいて「largest room」という表現が「Suite」に解決されることを確認します。
オープンエンドな生成 AI アプリケーションとは異なり、LLM が自由形式のテキストを直接ユーザーに返す場合と違い、Assisted NLU は LLM を、ボット定義によって制約された分類および抽出エンジンとして厳密に使用します。LLM はボット定義で定義されたインテントを選択し、スロット値を抽出するのみです。新しいインテントを発明したり、ボット定義外のアクションをトリガーしたり、エンドユーザーに LLM が生成した生テキストを返したりすることはできません。
原文を表示
Improving bot accuracy in Amazon Lex starts with handling how customers communicate naturally. Your customers express the same request in dozens of different ways, combine multiple pieces of information in one sentence, and often speak ambiguously. The Assisted NLU (natural language understanding) feature in Amazon Lex helps you improve bot accuracy by handling these natural language variations. Traditional natural language understanding systems struggle with this variability, which can lead customers to repeat themselves or abandon conversations.
The challenge: Rule-based NLU systems require developers to manually configure every possible utterance variation, a time-consuming task that still leaves coverage gaps. A hotel booking bot trained on “book a hotel” fails when your customers say, “I’d like to reserve accommodations for my trip.” Complex requests like “Book me a suite at your downtown Seattle location for December 15th through the 18th” often lose critical details (room type, location, dates). Ambiguous phrases like “I need help with my reservation” leave bots guessing whether customers want to book, view, modify, or cancel.
The solution: Amazon Lex Assisted NLU feature uses large language models (LLM) to understand natural language variations and improve bot accuracy. No manual configuration required. By combining traditional machine learning (ML) with LLMs, Assisted NLU handles how real customers communicate, creating natural conversational experiences that improve recognition accuracy.
Assisted NLU (including Primary mode, Fallback mode, and intent disambiguation) is included at no additional cost with standard Amazon Lex pricing.
In this post, you will learn how to implement Assisted NLU effectively. You will learn how to improve your bot design with effective intent and slot descriptions, validate your implementation using Test Workbench, and plan your transition from traditional NLU to Assisted NLU for both new and existing bots.
Prerequisites: This guide assumes that you’re familiar with Amazon Lex concepts including intents, slots, and utterances. If you’re new to Amazon Lex, start with the Getting Started Guide.
Introducing Assisted NLU
Amazon Lex Assisted NLU uses LLMs to enhance intent classification and slot resolution capabilities. It uses the names and descriptions of your intents and slots to understand user inputs. It handles typos, complex phrasing, and multi-slot extraction without requiring you to manually configure every variation. Amazon Lex Assisted NLU improves performance across natural language understanding tasks, achieving 92 percent intent classification accuracy and 84 percent slot resolution accuracy on average. With hundreds of active customers onboarded to Assisted NLU, customer feedback validates these improvements in real-world deployments. Customers have reported intent classification increases of 11–15 percent, 23.5 percent fewer fallback responses, and 30 percent better handling of noisy inputs. Early adopters have reported significant improvements in their conversational AI implementations, with several planning broader rollouts based on initial testing results.Assisted NLU operates in two modes:
- Primary mode: Uses the LLM as the primary means of processing every user input
- Fallback mode: Uses traditional NLU first, LLM invocation happens only when confidence is low or would route to FallbackIntent
You can enable Assisted NLU with a few selections in the Amazon Lex console. Navigate to your bot’s locale settings, toggle on Assisted NLU, select your preferred mode, and build your bot.
For detailed configuration instructions, API references, and step-by-step enablement guides, see Enabling Assisted NLU in the Amazon Lex Developer Guide.
For programmatic configuration, refer to the NluImprovementSpecification API reference.
1. Best practices for Assisted NLU implementation
The following best practices will help you get the most out of Assisted NLU, covering mode selection, description writing, slot optimization, and intent disambiguation.
1.1 Operating modes: Primary vs. Fallback
Primary mode uses the LLM for every user input. Fallback mode uses traditional NLU first, LLM invocation happens only when confidence is low or would route to FallbackIntent.
DO:
- Use Primary mode when building new bots or when you have limited (fewer than 20 sample utterances per intent) training data.
Example: A healthcare bot handling appointment scheduling where patients say, "I need to see someone about my knee" or "Book me with a cardiologist next week" without needing extensive utterance engineering.
- Use Fallback mode when you have existing bots that already perform well.
Example: An established banking bot with 95% accuracy that occasionally fails on variations like "What's my balance looking like?" instead of "Check balance" where the LLM catches these edge cases.
- Monitor the fulfilledByAssistedNlu metric in Amazon CloudWatch Logs to determine the right mode for your use case. If more than 30 percent of requests invoke the LLM in Fallback mode, consider switching to Primary for consistency.
DON’T:
- Switch to Primary mode without A/B testing if you have a well-performing bot because you might introduce unnecessary latency without accuracy gains.
- Assume one mode works for every use case because your specific data distribution and user language patterns determine the right mode.
1.2 Crafting effective intent descriptions
Intent descriptions are prompts to the LLM, not documentation for your team. They are the primary signal used for classification, and their quality directly determines accuracy, just as prompt quality determines LLM output quality. A consistent pattern delivers reliable results: Intent to [action verb] [object/entity] [context/constraints]
- “Intent to…” anchors the description in purpose, aligning with how the LLM evaluates what the user is trying to accomplish.
- Action verbs create clear separation. Book, cancel, modify, and check are unambiguous, allowing the LLM to confidently distinguish between intents.
- Objects and entities specify the target. "Book a hotel" vs. "book a car" vs. "book a flight" each map to a distinct user goal.
- Context resolves edge cases. Adding constraints like "Intent to cancel a flight due to medical emergency" vs. "Intent to cancel a flight for schedule conflict" context can help to determine waiver eligibility and refund policies.
DO:
- Start descriptions with "Intent to..." followed by a clear action verb.
Example: "Intent to book a hotel room for overnight accommodation".
- Derive descriptions from your existing sample utterances. They reflect how users speak and provide the strongest signal for the LLM.
Example: Descriptions like "book a room" and "reserve a suite" become: "Intent to book or reserve a hotel room or suite for an overnight stay".
- Add domain context when you have similar intents that need disambiguation.
Example: "Intent to book a hotel room on StayBooker" grounds the LLM’s understanding.
- Mirror your users’ vocabulary from real conversation analytics.
Example: If customers say "reservation", use that term consistently.
- Test descriptions against edge case utterances before deploying.
Example: Verify "I need a place to stay" correctly routes to BookHotel .
DON’T:
- Leave descriptions empty or use placeholder text.
Bad example: "TBD" or "Intent 1" provides no signal to the LLM.
- Combine multiple actions in a single intent.
Bad example: "Intent to book and manage hotel reservations" consider splitting into separate intents.
- Use overlapping language across different intents.
Bad example: "Check account balance" and "Check account transactions" will confuse classification.
- Include slot values or specific examples in the description.
Bad example: "Intent to book a hotel in Seattle for 2 nights" over constrains matching.
1.3 Improving slot descriptions
Slot descriptions provide contextual signal to the LLM about what information to extract and how to interpret it. The stronger and more specific your description, the more effectively the LLM can prioritize relevant values. As Assisted NLU evolves, slot descriptions will carry increasing weight in extraction decisions. Writing precise descriptions today prepares your bot to benefit from future improvements automatically. Effective descriptions follow this pattern: [What the slot captures] [contextual constraints] [valid value guidance]
- What the slot captures defines the specific piece of information that the slot extracts from the user’s input, such as a city name, date, or count.
- Contextual constraints narrow scope. "Check-in date for the hotel reservation, not the checkout or booking date" helps the LLM extract the correct date from inputs like "December 15th through the 18th".
- Valid value guidance resolves ambiguity. "Three-letter ISO currency code such as USD, EUR, or JPY" lets the LLM resolve inputs like “euros” or “Japanese yen” to the standard code without maintaining a full currency catalog in the slot type.
DO:
- Use slot descriptions to resolve values without a dedicated built-in slot type.
Example: To capture airport codes, use AMAZON.AlphaNumeric with the description "A valid IATA airport code (for example, SEA, JFK, LAX)". The LLM uses this context to extract codes from natural language, mapping "I'm flying out of Seattle" to SEA, without enumerating every value in a custom slot type.
- If you have two AMAZON.Number slots (nights + guests), the description is important to help LLM differentiate between similar slot types.
Example: "Number of nights for the hotel stay" vs "Number of guests checking in" — without these, the LLM could struggle to assign "3" to the right slot.
- Clarify the slot’s role within the intent.
Example: "Date of check-in" for a hotel booking intent removes ambiguity between check-in, checkout, and reservation dates.
- Specify constraints that match your business rules.
Example: "Number of nights in the hotel stay" clarifies this is a duration count, not a room count or guest count.
- Use slot descriptions to define each value’s meaning for custom slots with expanded value resolution.
Example: A RoomType custom slot with values Standard, Deluxe, and Suite and the description "Type of hotel room. Standard is a basic room, Deluxe is a mid-tier room with extra amenities, Suite is the top-tier luxury room with the most space and best features and kitchen attached" helps the LLM map natural language to the right category. If a customer says, “a room with a kitchen,” or “largest room” the LLM resolves these to Suite based on the semantic context provided in the description.
DON’T:
- Leave slot descriptions empty, especially for custom slots.
Bad example: "Payment" with no description gives the LLM no guidance on what currency formats to expect.
- Assume that the slot type alone provides enough context.
Bad example: AMAZON.Number could be nights, guests, rooms, or confirmation numbers without a description.
- Use descriptions that conflict with the slot type.
Bad example: Describing "account number" but using AMAZON.Number type might cause extraction issues with formatted account numbers.
- Forget to update descriptions when business logic changes.
Bad example: Expanding to international cities but keeping "United States only" in the description.
1.4 Intent disambiguation best practices
When multiple intents could match a user’s input, Assisted NLU presents disambiguation options to clarify the user’s goal. Well-designed disambiguation reduces friction and keeps conversations on track.
DO:
- Use clear, distinct intent names and descriptions that don’t overlap. These are the primary inputs the LLM uses for disambiguation decisions.
Example: "BookHotelRoom" with description "Reserve a hotel room for future dates" vs "CancelHotelReservation" with description "Cancel an existing hotel booking" – clearly separated purposes.
- Provide user-friendly display names for technical intent names. Make sure display names align with and clearly represent the actual intent names.
Example: Intent name "ModifyReservationDates" with display name "Change my reservation dates" makes the option immediately clear to users.
- Configure the maximum number of intent options thoughtfully. Balance between providing enough choices and avoiding decision paralysis through testing.
Example: Limit disambiguation to 3–4 options maximum; if "book hotel" could match 6 intents, your intent design is too fragmented.
- Craft concise disambiguation messages that acknowledge the user’s input. Guide users naturally toward selecting the right intent option.
Example: "I can help you with hotel reservations. Did you want to:" followed by clear options, rather than "Please select an intent:".
- Test thoroughly with ambiguous utterances. Validate that the disambiguation flow feels natural and consistently presents the correct intent options.
Example: Test phrases like "I need help with my reservation" across booking, modification, and cancellation intents to make sure correct options appear.
DON’T:
- Ignore disambiguation patterns. Monitor which intents frequently trigger disambiguation and refine them to reduce confusion.
Bad example: If "check my reservation" constantly triggers disambiguation between "ViewReservation", "ModifyReservation", and "VerifyReservation", consolidate or clarify these intents.
- Use disambiguation as an umbrella solution. If most conversations hit disambiguation, your intent design needs fundamental improvement.
Bad example: If the majority of user requests trigger disambiguation, this indicates overlapping intent definitions that need redesign—not better disambiguation messages.
- Forget to handle disambiguation failures. Have a clear fallback strategy when users don’t select any option.
Bad example: Showing the same disambiguation options repeatedly when users say "neither" or "something else" instead of escalating to human support.
- Treat disambiguation as set-and-forget. Continuously analyze user selections to identify confusion points and improve intent separation over time.
Bad example: Never reviewing which disambiguation options users select; if everyone picks option two when shown three choices, options one and three might be unnecessary.
After you’ve applied these best practices, validate your configuration through systematic testing.
2. Testing your Assisted NLU implementation
With your intent and slot descriptions in place, the next step is validation. Use the Amazon Lex Test Workbench to measure how well your Assisted NLU configuration handles real-world utterance variations.
For Test Workbench setup and usage, see the Test Workbench Documentation and demo video.
Important: When configuring your test set execution, make sure to select the bot and alias where Assisted NLU is enabled. The test will only exercise Assisted NLU if the selected alias points to a version with Fallback or Primary mode configured.
2.1 What to test
Focus on where Assisted NLU adds the most value: Edge casesTest inputs that deviate from standard phrasing to verify Assisted NLU handles real-world messiness:
- Typos and grammatical errors: "i wanna book an hotell"
- Colloquial expressions: "hook me up with a room downtown"
- Ambiguous requests: "I need transportation"
- Incomplete utterances: "booking for next week"
Slot variations
For built-in slots, test variations like date formats (“next Tuesday”, “the 15th”), location aliases (“NYC”, “New York City”), first name variations (“Bob” vs “Robert”), and email formats (“john dot doe at gmail dot com”).
For custom slots, test that user phrasing maps to defined values, especially in expand mode. For example, verify that “largest room” resolves to “Suite” for a RoomType slot.
Unlike open-ended generative AI applications where the LLM produces free-form text returned directly to users, Assisted NLU uses the LLM strictly as a classification and extraction engine constrained by your bot definition. The LLM can only select an intent and extract slot values defined in your bot definition. It can’t invent new intents, trigger actions outside your bot definition, or return raw LLM-generated text to end use
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み