パターン マッチングとは
パターン マッチングをカスタマイズして、パターン インテントと PatternMatchingModel 内のエンティティをグループ化することができます。 このグループ化を使用すると、より正確な意図認識の精度を高めるために役立つ高度なエンティティ型にアクセスできます。
サポートされているロケールについては、こちらを参照してください。
パターンと正確な語句
パターン マッチャーで使用される文字列には、"正確な語句" と "パターン" の2種類があります。 この違いを理解することは重要です。
正確な語句は、一致させたい単語そのものの文字列です。 次に例を示します。
"Take me to floor seven"。
パターンとは、マークされたエンティティを含む語句です。 エンティティは、パターン内の場所を定義するために "{}" でマークされ、"{}" 内のテキストはエンティティ ID を参照します。 前の例では、"floorName" という名前のエンティティで floor 名を抽出することが必要になる場合があります。 これを行うには、次のようなパターンを使用します。
"Take me to floor {floorName}"
PatternMatchingModel の概要
PatternMatchingModel には、そのモデルを参照するための ID、PatternMatchingIntent オブジェクトのリスト、および PatternMatchingEntity オブジェクトのリストが含まれています。
パターン マッチング意図
PatternMatchingIntent オブジェクトは、IntentRecognizer 内のスピーチやテキストを評価するために使用される語句のコレクションを表します。 語句が一致する場合、返される IntentRecognitionResult には、一致した PatternMatchingIntent の ID があります。
パターン マッチング エンティティ
PatternMatchingEntity オブジェクトは、個々のエンティティ参照と、それに対応するプロパティを表します。このプロパティにより、オブジェクトをどのように処理するかが IntentRecognizer に指示されます。 すべての PatternMatchingEntity オブジェクトには、語句に存在する ID が含まれている必要があります。そうではない場合は、一致しません。
エンティティの名前付けに関する制約
":" 文字を含むエンティティ名により、エンティティにロールが割り当てられます。
エンティティの種類
Any エンティティ
"Any" エンティティは、含まれているテキストに関係なく、そのスロットに表示されるどのテキストとも一致します。 "Take me to floor {floorName}" というパターンを使用する前の例を考えた場合、ユーザーは次のように言う場合があります。
"Take me to the floor parking 2
この場合、"floorName" エンティティは "parking 2" と一致します。
これらのエンティティは、発話の先頭または末尾に出現する場合を除き、できるだけ少ない単語と一致させようとするレイジー一致です。 次のパターンを考慮してください:
"Take me to the floor {floorName1} {floorName2}"
この例では、発話 "Take me to the floor parking 2" が一致し、floorName1 = "parking" および floorName2 = "2" を返します。
余分にキャプチャされたテキストを処理するのは難しい場合があります。 ユーザーが発話を続け、発話がそのコマンドよりも多くキャプチャされる可能性があります。 "Take me to floor parking 2 yes Janice I heard about that let's"。 この例では、floorName1 は正しくなりますが、floorName2 は "2 yes Janice I heard about that let's" になります。 エンティティがどのように一致し、シナリオに合わせて適切に調整されるかを理解することが重要です。 Any エンティティ型は最も基本的で、最も精度の低い照合型です。
リスト エンティティ
"List" エンティティは、エンジンに照合方法を指示する語句のリストで構成されています。 "List" エンティティには 2 つのモードがあります。 "Strict" と "Fuzzy" です。
エレベーターのフロアのリストがあるとしましょう。 ここではスピーチを扱うため、語彙形式を使用するエントリも追加します。
"1", "2", "3", "lobby", "ground floor", "one", "two", "three"
型 ID "List" のエンティティが "Strict" モードで使用される場合、エンジンは、スロット内のテキストがリストに表示されている場合にのみ一致します。
"take me to floor one" が一致します。
"take me to floor 5"は一致しません。
エンティティだけでなく、全体的な意図が一致しないことに注意する必要があります。
型 ID が "List" のエンティティが "Fuzzy" モードで使用されるとき、エンジンは引き続き意図と一致し、発話内のスロットに表示されたテキストはリストに含まれていない場合でも返されます。 この一致は、音声認識を向上させるために、陰で役に立ちます。
警告
Fuzzy リスト エンティティは実装されていますが、音声認識部分には統合されていません。 そのため、エンティティは照合されますが、音声認識の向上にはつながりません。
事前構築済みの整数エンティティ
"PrebuiltInteger" エンティティは、そのスロットで整数を取得することが予想される場合に使用されます。 整数が見つからない場合は、意図と一致しません。 戻り値は、数値の文字列表現です。
有効な一致と戻り値の例を次に示します。
"Two Thousand one Hundred and five" -> "2155"
"first" -> "1"
"a" -> "1"
"four oh seven one" -> "4071"
数字として認識できないテキストがある場合は、エンティティと意図が一致しません。
無効な一致の例を次に示します。
"the third"
"first floor I think"
"second plus three"
"three-three and anyway"
エレベーターの例を考えてみましょう。
"Take me to floor {floorName}"
"floorName" が事前に構築された整数エンティティの場合は、スロット内にあるすべてのテキストが整数を表すことが想定されます。 ここでは、フロア番号は適切に一致しますが、"lobby" のような名前を持つフロアは一致しません。
必須項目と省略可能な項目のグループ化
パターンには、発話の中に存在する "可能性がある" 単語またはエンティティを含めることができます。 これは、特に、"the"、"a"、"an" などの限定詞にとって役立ちます。 これには、多くの組み合わせをハード コーディングすることによる機能上の違いはありませんが、必要なパターンの数を減らすために役立ちます。 "[" および "]" を使用して、オプションの項目を示します。 必須項目を "(" と ")" で表現します。 "|" 文字で区切ることによって、同じグループに複数の項目を含めることができます。
これによって、必要なパターンの数がどのように減少するかを確認するには、次のセットを参照してください:
"Take me to {floorName}"
"Take me the {floorName}"
"Take me {floorName}"
"Take me to {floorName} please"
"Take me the {floorName} please"
"Take me {floorName} please"
"Bring me {floorName} please"
"Bring me to {floorName} please"
これらはすべて、グループ化して省略可能な項目を含む 1 つのパターンにすることができます。 まず、"to" と "the" を省略可能な単語として、"[to | the]" のようにグループ化できます。そして、"please" も同様に省略可能にすることができます。 最後に、"bring" と "take" を必須なものとしてグループ化できます。
"(Bring | Take) me [to | the] {floorName} [please]"
省略可能なエンティティを含めることもできます。 駐車場の階が複数あり、{floorName} の前の単語を一致させる必要があるとします。 これを行うには、次のようなパターンを使用します。
"Take me to [{floorType}] {floorName}"
省略可能は、キーワード認識やプッシュトゥトーク機能を使う可能性がある場合にも便利です。 これは、キーワードが存在する場合もあれば、しない場合もあることを意味します。 キーワードが "computer" であるとすると、パターンは次のようになります。
"[Computer] Take me to {floorName}"
注意
省略可能な項目を使用すると便利ですが、パターンの競合が発生する可能性が高くなります。 この場合は、2 つのパターンが、同じ音声句と一致することがあります。 これが発生した場合は、省略可能な項目を、別のパターンとして分けると解決できることがあります。
エンティティのロール
パターン内では、同じエンティティを複数回使用するシナリオも考えられます。 ある都市から別の都市への航空便を予約するシナリオを考えてみましょう。 この場合、都市の一覧は同じですが、ユーザーの出発地と目的地がどの都市であるかを知る必要があります。 これを実現するには、":" を使用して、エンティティに割り当てられたロールを使用します。
"Book a flight from {city:from} to {city:destination}"
このようなパターンでは、"city: from" と "city: destination" というラベルの付いた 2 つのエンティティが結果に存在しますが、照合するために "city" エンティティを参照しています。
意図照合の優先順位
場合によっては、複数のパターンが同じ発話に一致することがあります。 この場合、エンジンは、次のようにパターンに優先順位を付けます。
- 正確な語句。
- より多くのエンティティを含むパターン。
- 整数エンティティを含むパターン。
- List エンティティを含むパターン。
- Any エンティティを含むパターン。
- より多くのバイトが一致するパターン。
- 例: パターン "select {something} on the left" は "select {something}" よりも優先度が高くなります。
次のステップ
- 単純なパターン マッチから始めてください。
- カスタム エンティティを使用してパターン マッチングを向上させる
- GitHub のサンプルを確認してください。