LUIS アプリのパターン
重要
LUIS は 2025 年 10 月 1 日に廃止され、2023 年 4 月 1 日から新しい LUIS リソースを作成できなくなります。 継続的な製品サポートと多言語機能のベネフィットを得るために、LUIS アプリケーションを会話言語理解に移行することをお勧めします。
パターンは、複数の発話が非常に似ているときに、精度を改善するように設計されています。 パターンを使用すると、さらに数個の発話を提供しなくても意図の精度を高めることができます。
パターンは信頼度の低い意図を解決する
従業員に関連する組織図を報告する人事管理アプリがあるとします。 ある従業員の名前と関係を指定すると、LUIS はその従業員と関わりのある従業員を返します。 Tom という従業員の上司は Alice で、部下は Michael、Rebbeca、および Carl です。
| 発話 | 予測される意図 | 意図スコア |
|---|---|---|
| Who is Tom's subordinate? (Tom の部下は誰。) | GetOrgChart | 0.30 |
| Who is the subordinate of Tom? (Tom の部下は誰ですか。) | GetOrgChart | 0.30 |
アプリに文の長さが異なる、語順が異なる、および違う言葉 ("subordinate (部下)"、"manage (管理)"、"report (所属)" の同義語) が使用されている発話が 10 から 20 ある場合、LUIS が返す信頼度スコアは低くなることがあります。 LUIS が語順の重要度を理解できるように、パターンを作成します。
パターンは次のような状況を解決します。
- 意図スコアが低い
- 正しい意図が最上位のスコアではないが、最上位のスコアに近すぎる。
パターンは意図を保証するものではない
パターンではさまざまな予測手法を使用します。 パターンにテンプレートの発話の意図を設定することは、意図の予測を保証するものではありませんが、強力なシグナルになります。
パターンでは機械学習エンティティの検出は改善されない
パターンは主として、意図とロールの予測を支援するためのものです。 "pattern.any" エンティティは、自由形式のエンティティを抽出するために使用されます。 パターンではエンティティが使用されますが、パターンは機械学習エンティティの検出には役に立ちません。
複数の発話を 1 つのパターンにまとめた場合は、エンティティ予測の向上を期待しないでください。 アプリで単純エンティティを使用するには、発話を追加するか、リストエンティティを使用する必要があります。
パターンはエンティティのロールを使用する
パターン内の 2 つ以上のエンティティがコンテキスト上関連性がある場合、パターンはエンティティのロールを使用して、エンティティに関するコンテキスト情報を抽出します。
パターンありとなしの場合の予測スコア
発話例が十分に指定されている場合、LUIS はパターンなしで予測の信頼度を改善できます。 パターンがあれば、それほど多くの発話を指定しなくても信頼度スコアを改善できます。
パターン マッチング
パターンは、まずパターン内のエンティティを検出して、次に残りのワードとパターンの語順を検証することでマッチングを行います。 パターンが一致するには、パターン内にエンティティが必要です。 パターンは、文字レベルではなく、トークン レベルで適用されます。
Pattern.any エンティティ
pattern.any エンティティは、エンティティの表現が原因で発話の残りの部分からエンティティの終わりを判別するのが難しい自由形式データを見つけるために使用できます。
たとえば、従業員が会社のドキュメントを検索できる人事アプリを考えてみます。 このアプリでは、次の発話例を理解する必要があります。
- "HRF-123456 はどこにありますか?"
- "誰が HRF-123234 を作成しましたか?"
- "HRF-456098 はフランス語で発行されますか?"
ただし、各ドキュメントには、書式設定された名前 (上記の一覧で使用) と、「会社の新しい従業員からの配置換えリクエスト 2018 バージョン 5」などのわかりやすい名前の両方があります。
わかりやすい名前の発話は次のようになります。
- "会社の新しい従業員からの配置換えリクエスト 2018 バージョン 5 はどこですか?"
- "誰が "会社の新しい従業員からの配置換えリクエスト 2018 バージョン 5" を作成しましたか?"
- 会社の新しい従業員からの配置換えリクエスト 2018 バージョン 5 はフランス語で発行されますか?"
発話には、エンティティの終了位置に関して LUIS を混乱させる可能性のある単語が含まれています。 パターンで Pattern.any エンティティを使用すると、ドキュメント名の先頭と末尾を指定できるため、LUIS はフォーム名を正しく抽出できます。 たとえば、次のテンプレート発話の場合:
- {FormName} はどこですか[?]
- 誰が {FormName} を作成しましたか[?]
- {FormName} はフランス語で発行されますか[?]
パターンのベスト プラクティス:
すべきこと: 後のイテレーションでパターンを追加する
パターンを追加する前に、アプリがどのように動作するかを理解しておく必要があります。パターンは、発話の例よりも高い重み付けがされており、信頼性を歪めることになるためです。
アプリがどのように動作するかを理解したうえで、パターンがアプリに適用される際に追加します。 アプリの設計を繰り返すたびに追加する必要はありません。
それらをモデル設計の開始時に追加しても害はありませんが、モデルを発話でテストした後のほうが、各パターンがモデルをどのように変えるか確認しやすくなります。
やってはいけないこと: 多数のパターンを追加する
追加するパターンは、多くなりすぎないようにします。 LUIS は、少ない例をすばやく学習するように作られています。 不必要にシステムに負荷をかけないでください。
機能
機械学習では、"特徴" がデータを区別するための特性または属性であり、システムを使ってその観察と学習を行います。
機械学習の特徴は、LUIS にとって、概念を区別するものをどこで探すかに関する重要な手がかりとなります。 これらは LUIS で利用できるヒントですが、厳密な規則ではありません。 LUIS ではこれらのヒントをラベルと使用し、データを見つけます。
特徴は、f(x) = y のような関数として記述できます。 発話の例では、この特徴により、特性を区別するために発話の例のどこを調べるかが示されます。 この情報は、スキーマの作成に役立てるために使用します。
特徴の種類
特徴は、スキーマ設計の必要な部分です。 LUIS は、語句一覧とモデルの両方を特徴としてサポートしています。
- フレーズ リストの特徴
- 特徴としてのモデル (意図またはエンティティ)
発話の例の中で特徴を見つける
LUIS は言語ベースのアプリケーションであるため、特徴はテキストベースです。 区別する特性を示すテキストを選択します。 LUIS の場合、最小の単位はトークンです。 英語では、スペースや句読点を含まない、文字や数字が連続する範囲が 1 つのトークンです。
スペースと句読点はトークンではないため、特徴として使用できるテキストのヒントに焦点を当てます。 忘れずに、次のような単語のバリエーションを含めてください。
- 複数形
- 動詞の時制
- 略語
- スペルとスペルミス
それによって特性が区別されるため、テキストで以下を行う必要があるかどうかを決定します。
- 完全な単語または語句に一致する:正規表現エンティティを追加するか、特徴としてのリスト エンティティをエンティティまたは意図に追加することを検討します。
- 日付、時刻、または人名のようなよく知られた概念と一致する:エンティティまたは意図に対する特徴として事前構築済みのエンティティを使用します。
- 時間の経過と共に新しい例を学習する:エンティティまたは意図に対する特徴としての概念の例がいくつか含まれるフレーズ リストを使用します。
概念のフレーズ リストを作成する
フレーズ リストは、1 つの概念を記述する単語またはフレーズのリストです。 フレーズ リストは、大文字と小文字を区別しない一致として、トークン レベルで適用されます。
フレーズ リストを追加すると、特徴をグローバルに設定できます。 グローバル特徴はアプリ全体に適用されます。
語句一覧を使用する条件
LUIS アプリで、概念の新しい項目を一般化して識別する必要がある場合は、フレーズ リストを使用します。 フレーズ リストは、領域固有の語彙に似ています。 これらによって、意図とエンティティについての理解の質が向上します。
語句一覧の使用方法
フレーズ リストを使用すると、LUIS ではコンテキストの検討と一般化が行われ、類似しているが完全なテキスト一致ではない項目が識別されます。 以下の手順に従ってフレーズ リストを使用します。
- 機械学習エンティティから開始します。
- 発話の例を追加します。
- 機械学習エンティティを使用してラベルを付けます。
- フレーズ リストを追加します。
- 類似の意味を持つ単語を追加します。 考えられるすべての単語やフレーズを追加しないでください。 その代わりに、一度に数個の単語またはフレーズを追加します。 その後、再度トレーニングして発行します。
- 提案された単語を検討して追加します。
フレーズ リストの一般的なシナリオ
フレーズ リストの一般的なシナリオは、特定のアイデアに関連する単語をブーストすることです。
重要性を大幅に高めるためにフレーズ リストが必要になる可能性がある単語の良い例は、医学用語です。 これらの用語には、特定の物理的意味、化学的意味、治療上の意味、または抽象的な意味がある可能性があります。 フレーズ リストがないと、LUIS では対象ドメインにとってその用語が重要であることを判断できません。
たとえば、医学用語を抽出するには:
- 発話の例を作成し、それらの発話内の医学用語にラベルを付けます。
- 主題領域で使われる用語の例を含むフレーズ リストを作成します。 このフレーズ リストには、ラベルを付けた実際の用語と、同じ概念を説明する他の用語を含める必要があります。
- フレーズ リストで使用される概念を抽出するエンティティまたはサブエンティティに、フレーズ リストを追加します。 最も一般的なシナリオは、機械学習エンティティのコンポーネント (子) です。 フレーズ リストをすべての意図またはエンティティに適用する必要がある場合は、フレーズ リストをグローバル フレーズ リストとしてマークします。 API では、enabledForAllModels フラグによって、このモデルのスコープが制御されます。
語句一覧のトークンの一致
フレーズ リストは常にトークン レベルで適用されます。 次の表は、Ann という単語を含むフレーズ リストが、その順序で同じ文字のバリエーションにどのように適用されるかを示しています。
| "Ann" のトークン バリエーション | トークンが見つかったときのフレーズ リストの一致 |
|---|---|
| ANN aNN |
はい - トークンは Ann です |
| Ann's | はい - トークンは Ann です |
| Anne | いいえ - トークンは Anne です |
別のモデルの役に立つ特徴としてのモデル
モデル (意図またはエンティティ) を特徴として別のモデル (意図またはエンティティ) に追加できます。 既存の意図またはエンティティを特徴として追加することで、ラベル付けされた例を含む適切に定義された概念を追加することになります。
特徴としてのモデルを追加する場合、特徴を次のように設定できます。
特徴としてのエンティティを意図に使用するタイミング
意図にとってあるエンティティの検出が重要である場合は、そのエンティティを特徴としてその意図に追加します。
たとえば、意図 (BookFlight など) がフライトを予約することで、エンティティがチケット情報 (座席番号、出発地、目的地など) である場合、チケット情報のエンティティが見つかれば、BookFlight 意図の予測に非常に大きな重み付けが追加されるはずです。
特徴としてのエンティティを別のエンティティに使用するタイミング
エンティティ (A) の検出が、エンティティ (B) の予測にとって重要である場合は、エンティティ (B) に対する特徴として、エンティティ (A) を追加する必要があります。
たとえば、ある配送先住所エンティティが、1 つの番地サブエンティティに含まれている場合、その番地サブエンティティが見つかれば、配送先住所エンティティの予測に非常に大きな重み付けが追加されます。
- 配送先住所 (機械学習エンティティ):
- 番地の番号 (サブエンティティ)
- 番地 (サブエンティティ)
- 市区町村 (サブエンティティ)
- 都道府県 (サブエンティティ)
- 国/地域 (サブエンティティ)
- 郵便番号 (サブエンティティ)
特徴があり、入れ子になっているサブエンティティ
機械学習サブエンティティは、親エンティティに概念があることを示します。 親は、別のサブエンティティである場合も、最上位エンティティである場合もあります。 サブエンティティの値は、その親の特徴として機能します。
サブエンティティは、フレーズ リストと、特徴としてのモデル (もう 1 つのエンティティ) の両方を持つことができます。
サブエンティティにフレーズ リストがある場合、概念の語彙が増加しますが、予測の JSON 応答にはいかなる情報も追加されません。
サブエンティティに別のエンティティの特徴があるとき、JSON 応答にはその別のエンティティの抽出データが含まれます。
必須の特徴
モデルを予測エンドポイントから返すには、必須の特徴が検出される必要があります。 入力データが特徴と一致する必要があることがわかっている場合は、必須の特徴を使用します。
発話テキストは、必須の特徴と一致しない場合は抽出されません。
必須の特徴には、機械学習されたのではないエンティティを使用します。
- 正規表現エンティティ
- リスト エンティティ
- 事前構築済みのエンティティ
データにモデルが含まれると確信している場合は、その特徴を必須として設定します。 必須の特徴が見つからない場合は、何も返されません。
配送先住所の例を続けます。
配送先住所 (機械学習エンティティ)
- 番地の番号 (サブエンティティ)
- 番地 (サブエンティティ)
- 通りの名前 (サブエンティティ)
- 市区町村 (サブエンティティ)
- 都道府県 (サブエンティティ)
- 国/地域 (サブエンティティ)
- 郵便番号 (サブエンティティ)
事前構築済みのエンティティを使用した必須の特徴
通常、市区町村、都道府県、国、リージョンなどの事前構築済みのエンティティは、閉じたリストのセットです。つまり、時間の経過と共に大きく変化することはありません。 このようなエンティティは、関連する推奨の特徴を持つ可能性があります。また、それらの特徴に必須とマークすることができます。 ただし、isRequired フラグは、割り当て先のエンティティにのみ関連付けられており、階層には影響しません。 事前構築済みのサブエンティティ機能が見つからない場合、これは親エンティティの検出とリターンには影響しません。
必要な機能の例として、住所を検出することを検討します。 場合により、番地を要件とすることを検討します。 これにより、ユーザーは「1 Microsoft Way (Microsoft 通り 1 番地)」または「One Microsoft Way (Microsoft 通り一番地)」と入力することができ、どちらの場合も番地サブエンティティは数値の "1" に解決されます。 詳細については、「事前構築済みのエンティティ」の記事を参照してください。
リスト エンティティを使用した必須の特徴
リスト エンティティは、正規名のリストとして、そのシノニムと共に使用されます。 必須の特徴として、発話に正規名またはシノニムが含まれていない場合、予測エンドポイントの一部としてエンティティは返されません。
会社が限られた国や地域のみに荷物を出荷するとします。 顧客が国や地域を参照するための方法が複数含まれるリスト エンティティを作成できます。 LUIS によって発話のテキスト内の正確な一致が検出されない場合、(リスト エンティティの必須の特徴を持つ) エンティティは予測で返されません。
| 正規名** | シノニム |
|---|---|
| United States | 米国 U.S.A US 米国 0 |
チャット ボットなどのクライアント アプリケーションでは、フォローする質問をして助けることができます。 これは、国や地域の選択肢が限られていて必須であることを、顧客が理解する助けになります。
正規表現エンティティを使用した必須の特徴
必須の特徴として使用される正規表現エンティティは、豊富なテキスト照合機能を備えています。
配送先住所の例では、国や地域の郵便番号の構文規則を取り込んだ正規表現を作成できます。
グローバル特徴
最も一般的な使用方法は特徴を特定のモデルに適用することですが、特徴をグローバル特徴として構成し、アプリケーション全体に適用することができます。
グローバル特徴の最も一般的な使用法は、追加の語彙をアプリに追加することです。 顧客が第 1 言語を使用していても、同じ発話内で別の言語を使用可能であると想定される場合は、第 2 言語の単語を含む特徴を追加できます。
ユーザーは、すべての意図またはエンティティにわたって第 2 言語を使用することを期待するため、第 2 言語の単語をフレーズ リストに追加します。 フレーズ リストはグローバル特徴として構成します。
特徴を結合して利点を追加する
1 つの特性または概念を記述するために、複数の特徴を使用できます。 一般的なペアリングでは、次のものを使用します。
- フレーズ リストの特徴:同じモデルに対して複数の語句リストを特徴として使用できます。
- フィーチャーとしてのモデル: 事前構築済みエンティティ、正規表現エンティティ、リスト エンティティ。
例: 旅行アプリのチケット予約エンティティの特徴
基本的な例として、フライト予約の意図とチケット予約エンティティが使用される、フライト予約用のアプリを考えてみましょう。 チケット予約エンティティは、予約システムで航空機のチケットを予約するための情報をキャプチャします。
チケット予約のための機械学習エンティティには、出発地と目的地を取得するための 2 つのサブエンティティがあります。 これらの特徴は、最上位レベルのエンティティではなく、各サブエンティティに追加する必要があります。
チケット予約エンティティは機械学習エンティティであり、"出発地" や "目的地" などのサブエンティティを含みます。 これらのサブエンティティは、どちらも地理的な場所を示します。 場所を抽出し、"出発地" と "目的地" を区別できるようにするには、各サブエンティティに特徴が必要です。
| 型 | 出発地のサブエンティティ | 目的地のサブエンティティ |
|---|---|---|
| 特徴量としてのモデル | geographyV2 事前構築済みエンティティ | geographyV2 事前構築済みエンティティ |
| フレーズ リスト | 出発地の単語: start at、begin from、leave | 目的地の単語: to、arrive、land at、go、going、stay、heading |
| フレーズ リスト | 空港コード - 出発地と目的地の両方で同じリスト | 空港コード - 出発地と目的地の両方で同じリスト |
| フレーズ リスト | 空港名 - 出発地と目的地の両方で同じリスト | 空港コード - 出発地と目的地の両方で同じリスト |
空港コードや空港名を使用することが予想される場合、LUIS には、両方の種類のフレーズを使用するフレーズ リストが必要です。 空港コードは、チャットボットに入力したテキストによく見られる場合があります。一方、空港名は音声対応のチャットボットのような会話によく見られる場合があります。
特徴の照合の詳細は、モデルに対してのみ返され、フレーズ リストに対しては返されません。これは、予測 JSON ではモデルのみ返されるためです。
意図内でのチケット予約のラベル付け
機械学習エンティティを作成したら、発話の例を意図に追加し、親エンティティとすべてのサブエンティティにラベルを付ける必要があります。
チケット予約の例では、TicketBooking エンティティとテキスト内のすべてのサブエンティティを使用して、意図内の発話の例にラベルを付けます。
例: ピザの注文アプリ
2 番目の例では、ピザ レストランのアプリについて考えてみます。このアプリでは、注文を受けているピザの種類の詳細など、ピザの注文を受けます。 注文処理を完了するために、可能であれば、ピザの詳細を抽出する必要があります。
この例の機械学習エンティティは、入れ子になったサブエンティティ、フレーズ リスト、事前構築済みのエンティティ、およびカスタム エンティティにより、さらに複雑になります。
この例では、サブエンティティ レベルとサブエンティティ レベルの子で特徴を使用します。 どのレベルが特徴としてどのような種類のフレーズ リストまたはモデルを取得するかということは、エンティティ設計の重要な部分です。
サブエンティティには、エンティティの検出に役立つ特徴として多くのフレーズ リストを含めることができますが、各サブエンティティには特徴としてモデルが 1 つだけあります。 このピザ アプリでは、これらのモデルは主にリストです。
正しくラベル付けされた発話の例は、エンティティがどのように入れ子になっているかを示すように表示されます。