Amazon Lex の Assisted NLU でボットの精度を向上させる

Amazon Lex におけるボットの精度向上は、顧客が自然にコミュニケーションを行う方法をどう扱うかから始まります。顧客は同じリクエストを数十通りの異なる表現で伝えたり、1 つの文の中に複数の情報を組み合わせたり、しばしば曖昧な表現を使ったりします。[Amazon Lex](https://aws.amazon.com/lex/features/) の [Assisted NLU](https://docs.aws.amazon.com/lexv2/latest/dg/assisted-nlu.html)（自然言語理解）機能は、これらの自然言語のバリエーションを処理することで、ボットの精度向上をサポートします。従来の自然言語理解システムはこの多様性に対処するのが難しく、その結果、顧客が同じことを繰り返したり、会話から離れてしまったりすることがあります。 **課題:** ルールベースの 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が初めての場合は、[入門ガイド](https://docs.aws.amazon.com/lexv2/latest/dg/getting-started.html)から始めることをお勧めします。 ## 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 の有効化](https://docs.aws.amazon.com/lexv2/latest/dg/assisted-nlu.html) をご覧ください。 プログラムによる設定については、[NluImprovementSpecification API リファレンス](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_NluImprovementSpecification.html) を参照してください。 ## 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](https://docs.aws.amazon.com/lexv2/latest/dg/test-workbench.html) および [デモ動画](https://www.youtube.com/watch?v=FNxm6wSD3i4) を参照してください。 **重要**: テストセットの実行を設定する際は、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 が生成した生テキストを返したりすることはできません。

Amazon Lex の Assisted NLU でボットの精度を向上させる

背景や根拠まで確認しますか？

調べる

選ぶ

サイト