Vad är mönstermatchning?

Mönstermatchning kan anpassas för att gruppera mönstervsikter och entiteter i en PatternMatchingModel. Med hjälp av den här gruppering är det möjligt att komma åt mer avancerade entitetstyper som gör avsiktsigenkänningen mer exakt.

Information om språk som stöds finns här.

Mönster jämfört med exakta fraser

Det finns två typer av strängar som används i mönstermatchare: "exakta fraser" och "mönster". Det är viktigt att förstå skillnaderna.

Exakta fraser är strängar av de exakta ord som du vill matcha. Till exempel:

"Ta mig till våning sju".

Ett mönster är en fras som innehåller en markerad entitet. Entiteter markeras med "{}" för att definiera platsen inuti mönstret och texten i "{}" refererar till entitets-ID:t. Med det föregående exemplet kanske du vill extrahera golvnamnet i en entitet med namnet "floorName". Du skulle göra det med ett mönster som det här:

"Ta mig till golvet {floorName}"

Disposition av en PatternMatchingModel

PatternMatchingModel Innehåller ett ID som refererar till modellen efter, en lista över PatternMatchingIntent objekt och en lista över PatternMatchingEntity objekt.

Avsikter för mönstermatchning

PatternMatchingIntent objekt representerar en samling fraser som används för att utvärdera tal eller text i IntentRecognizer. Om fraserna matchas har den IntentRecognitionResult returnerade ID:t för det PatternMatchingIntent som matchades.

Mönstermatchande entiteter

PatternMatchingEntity objekt representerar en enskild entitetsreferens och dess motsvarande egenskaper som anger hur den IntentRecognizer ska behandlas. Alla PatternMatchingEntity objekt måste ha ett ID som finns i en fras, annars matchas det inte.

Begränsningar för entitetsnamngivning

Entitetsnamn som innehåller tecknen ":" tilldelar en roll till en entitet.

Typer av entiteter

Valfri entitet

Entiteten "Alla" matchar all text som visas i det facket oavsett vilken text den innehåller. Om vi överväger vårt tidigare exempel med mönstret "Ta mig till golvet {floorName}" kan användaren säga något i stil med:

"Ta mig till golvet parkering 2

I det här fallet skulle entiteten "floorName" matcha "parkering 2".

Dessa entiteter är lata matchningar som försöker matcha så få ord som möjligt om det inte visas i början eller slutet av ett yttrande. Tänk på följande mönster:

"Ta mig till golvet {floorName1} {floorName2}"

I det här fallet skulle yttrandet "Ta mig till golvet parkering 2" matcha och returnera floorName1 = "parkering" och floorName2 = "2".

Det kan vara svårt att hantera extra insamlad text. Kanske användaren fortsatte att prata och yttrandet fångade mer än deras kommando. "Ta mig till golvet parkering 2 ja Janice jag hörde om att låt oss". I det här fallet skulle floorName1 vara korrekt, men floorName2 skulle = "2 ja Janice jag hörde talas om det låt oss". Det är viktigt att vara medveten om hur entiteterna matchar och justera scenariot på rätt sätt. Entitetstypen Alla är den mest grundläggande och minst exakta typen av matchning.

Lista entitet

Entiteten "Lista" består av en lista med fraser som vägleder motorn om hur den ska matchas. Entiteten "Lista" har två lägen. "Strikt" och "Fuzzy".

Vi antar att vi har en lista över våningar för vår hiss. Eftersom vi har att göra med tal lägger vi även till poster med hjälp av det lexikala formatet.

"1", "2", "3", "lobby", "bottenvåningen", "en", "två", "tre"

När en entitet av typen ID "List" används i läget "Strikt" matchar motorn endast om texten i facket visas i listan.

"ta mig till våning ett" kommer att matcha.

"ta mig till våning 5" kommer inte.

Det är viktigt att observera att hela avsikten inte matchar, inte bara entiteten.

När en entitet av typen ID "List" används i "Fuzzy"-läge matchar motorn fortfarande avsikten och returnerar texten som visades i facket i yttrandet, även om den inte finns i listan. Den här matchningen är användbar i bakgrunden för att göra taligenkänningen bättre.

Varning

Fuzzy-listentiteter implementeras, men integreras inte i taligenkänningsdelen. Därför matchar de entiteter, men förbättrar inte taligenkänningen.

Fördefinierad heltalsentitet

Entiteten "PrebuiltInteger" används när du förväntar dig att få ett heltal i det facket. Den matchar inte avsikten om det inte går att hitta ett heltal. Returvärdet är en strängrepresentation av talet.

Exempel på giltiga matchnings- och returvärden

"Två tusen hundra femtiofem" -> "2155"

"first" -> "1"

"a" -> "1"

"fyra oh sju en" -> "4071"

Om det finns text som inte kan identifieras som ett tal matchar inte entiteten och avsikten.

Exempel på en ogiltig matchning

"den tredje"

"Första våningen tror jag"

"second plus three"

"trettiotre och i alla fall"

Tänk på vårt hissexempel.

"Ta mig till golvet {floorName}"

Om "floorName" är en fördefinierad heltalsentitet är förväntningarna att den text som finns i facket representerar ett heltal. Här skulle ett golvnummer matcha bra, men ett golv med ett namn som "lobby" skulle inte göra det.

Gruppering av obligatoriska och valfria objekt

I mönstret tillåts det att inkludera ord eller entiteter som "kan" finnas i yttrandet. Detta är särskilt användbart för determinerare som "the", "a" eller "an". Detta har ingen funktionell skillnad jämfört med att hårdkoda de många kombinationerna, men kan bidra till att minska antalet mönster som behövs. Ange valfria objekt med "[" och "]". Ange nödvändiga objekt med "(" och ")". Du kan inkludera flera objekt i samma grupp genom att avgränsa dem med ett |-tecken.

Om du vill se hur detta skulle minska antalet mönster som behövs bör du överväga följande uppsättning:

"Ta mig till {floorName}"

"Ta mig {floorName}"

"Ta mig {floorName}"

"Ta mig till {floorName} tack"

"Ta mig {floorName} tack"

"Ta mig {floorName} tack"

"Ta med mig {floorName} tack"

"Ta mig till {floorName} tack"

Alla dessa kan reduceras till ett enda mönster med gruppering och valfria objekt. Först är det möjligt att gruppera "till" och "the" tillsammans som valfria ord så här: "[till | och sedan kan vi göra "please" valfritt också. Slutligen kan vi gruppera "bring" och "take" efter behov.

"(Bring | Take) me [to | the] {floorName} [please]"

Det går också att inkludera valfria entiteter. Anta att det finns flera parkeringsnivåer och att du vill matcha ordet före {floorName}. Du kan göra det med ett mönster som det här:

"Ta mig till [{floorType}] {floorName}"

Valfria alternativ är också användbara om du använder nyckelordsigenkänning och en push-to-talk-funktion. Det innebär att nyckelordet ibland finns, och ibland inte. Förutsatt att nyckelordet var "dator" skulle ditt mönster se ut ungefär så här.

"[Dator] Ta mig till {floorName}"

Kommentar

Även om det är bra att använda valfria objekt ökar risken för mönsterkollisioner. Här kan två mönster matcha samma talade fras. Om detta inträffar kan det ibland lösas genom att separera de valfria objekten i separata mönster.

Entitetsroller

I mönstret kan det finnas ett scenario där du vill använda samma entitet flera gånger. Överväg scenariot med att boka ett flyg från en stad till en annan. I det här fallet är listan över städer densamma, men det är nödvändigt att veta vilken stad som är användaren som kommer från och vilken stad som är målet. För att åstadkomma detta kan du använda en roll som tilldelats en entitet med hjälp av ":".

"Boka en flygresa från {city:from} till {city:destination}"

Med ett mönster som detta finns det två entiteter i resultatet märkta "city:from" och "city:destination", men båda refererar till entiteten "stad" i matchande syfte.

Avsiktsmatchningsprioritet

Ibland matchar flera mönster samma yttrande. I det här fallet prioriterar motorn mönster enligt följande.

  1. Exakta fraser.
  2. Mönster med fler entiteter.
  3. Mönster med heltalsentiteter.
  4. Mönster med listentiteter.
  5. Mönster med alla entiteter.
  6. Mönster med fler byte matchade.
    • Exempel: Mönstret "välj {something} till vänster" har högre prioritet än "välj {something}".

Nästa steg