Que sont les critères spéciaux ?

Les critères spéciaux peuvent être personnalisés pour regrouper des intentions de modèle et des entités dans un PatternMatchingModel. En utilisant ce regroupement, il est possible d’accéder à des types d’entités plus avancés, ce qui contribue à améliorer la précision de la reconnaissance de l’intention.

Pour connaître les paramètres régionaux pris en charge, consultez cette page.

Modèles et expressions exactes

Il existe deux types de chaîne utilisés dans le détecteur de correspondance de modèles : « expressions exactes » et « modèles ». Il est important de comprendre les différences.

Les expressions exactes sont des chaînes de mots exacts que vous souhaitez faire correspondre. Par exemple :

« Emmenez-moi à l’étage sept ».

Un modèle est une expression qui contient une entité marquée. Les entités sont marquées avec des « {} » pour définir leur emplacement dans le modèle. Le texte présent entre des « {} » référence l’ID d’entité. Dans l’exemple précédent, vous pouvez être amené à extraire le nom de l’étage dans une entité nommée « floorName ». Pour ce faire, vous pouvez utiliser un modèle comme celui-ci :

« Emmenez-moi à l’étage {floorName} »

Structure d’un PatternMatchingModel

Le PatternMatchingModel contient un ID pour référencer ce modèle, une liste d’objets PatternMatchingIntent et une liste d’objets PatternMatchingEntity.

Intentions de critères spéciaux

Les objets PatternMatchingIntent représentent une collection d’expressions utilisées pour évaluer des paroles ou du texte dans le IntentRecognizer. Si les expressions correspondent, alors le IntentRecognitionResult retourné a l’ID du PatternMatchingIntent correspondant.

Entités de critères spéciaux

Les objets PatternMatchingEntity représentent une référence d’entité individuelle et ses propriétés correspondantes, qui indiquent à IntentRecognizer comment la traiter. Tous les objets PatternMatchingEntity doivent avoir un ID présent dans une expression, sinon la mise en correspondance n’a jamais lieu.

Restrictions de dénomination d’entité

Les noms d’entité contenant le caractère « : » affectent un rôle à une entité.

Types d’entité

Entité Any

L’entité « Any » correspond à n’importe quel texte qui apparaît dans cet emplacement, quel que soit le texte qu’il contient. Si nous prenons l’exemple précédent qui utilise le modèle « Emmenez-moi à l’étage {floorName} », l’utilisateur peut dire quelque chose du genre :

« Emmenez-moi à l’étage Parking 2 »

Dans ce cas, l’entité « floorName » correspond à « Parking 2 ».

Ces entités sont des correspondances approximatives qui tentent de faire correspondre le moins de mots possible, sauf s’ils apparaissent au début ou à la fin d’un énoncé. Observez le modèle suivant :

« Emmenez-moi à l’étage {floorName1} {floorName2} »

Dans ce cas, l’énoncé « Emmenez-moi à l’étage Parking 2 » présente des correspondances, et retourne floorName1 = « Parking » et floorName2 = « 2 ».

Il peut être difficile de gérer du texte capturé supplémentaire. Peut-être que l’utilisateur a continué à parler et que l’énoncé a capturé plus d’informations que sa commande. « Emmenez-moi à l’étage Parking 2 Oui Janice j’ai ». Dans ce cas, floorName1 est correct, mais floorName2 correspond à « 2 Oui Janice j’ai ». Il est important d’être conscient de la façon dont les entités sont mises en correspondance pour adapter votre scénario comme il se doit. Le type d’entités « Any » est le moyen de mise en correspondance le plus simple et le moins précis.

Entité de liste

L’entité « List » est constituée d’une liste d’expressions qui vont guider le moteur dans sa recherche de correspondance. L’entité « List » a deux modes. « Strict » et « Fuzzy ».

Supposons que nous disposions d’une liste d’étages pour notre ascenseur. Étant donné que nous utilisons la reconnaissance vocale, nous ajoutons également des entrées à l’aide du format lexical.

« 1 », « 2 », « 3 », « hall », « rez-de-chaussée », « un », « deux », « trois »

Quand une entité ayant un ID est de type « List » en mode « Strict », le moteur établit une correspondance seulement si le texte de l’emplacement apparaît dans la liste.

« emmenez-moi à l’étage un » est une correspondance.

« emmenez-moi à l’étage 5 » n’est pas une correspondance.

Notez qu’au delà de l’entité, c’est toute l’intention qui ne va pas correspondre.

Quand une entité est de type d’ID « List » est utilisée en mode « Fuzzy », le moteur établit tout de même une correspondance avec l’intention, et retourne le texte qui apparaît dans l’emplacement de l’énoncé, même s’il ne figure pas dans la liste. Cet correspondance est utile en arrière-plan pour améliorer la reconnaissance vocale.

Avertissement

Les entités de liste floues sont implémentées, mais pas intégrées dans la partie reconnaissance vocale. Par conséquent, elles correspondent aux entités, mais n’améliorent pas la reconnaissance vocale.

Entité PrebuiltInteger

L’entité « PrebuiltInteger » est utilisée quand vous vous attendez à obtenir un entier dans cet emplacement. Elle ne correspond pas à l’intention si un entier est introuvable. La valeur de retour est une représentation sous forme de chaîne du nombre.

Exemples de correspondances et de valeurs de retour valides

"Deux mille cent cinquante-cinq" -> "2155"

"first" -> "1"

"a" -> "1"

"quatre zéro sept un" -> "4071"

S’il existe du texte non reconnu, par exemple un nombre, l’entité et l’intention ne correspondront pas.

Exemples de correspondances non valides

« au troisième »

"premier étage je pense"

"deuxième plus trois"

"trente-trois et bref"

Prenons notre exemple d’ascenseur.

« Emmenez-moi à l’étage {floorName} »

Si « floorName » est une entité entière prédéfinie, on s’attend à ce que le texte qui se trouve dans l’emplacement représente un entier. Ici, il est possible d’établir correctement une correspondance avec un numéro d’étage, mais pas avec un nom d’étage tel que « hall ».

Regroupement des éléments obligatoires et facultatifs

Dans le modèle, il est permis d’inclure des mots ou des entités qui pourraient être présents dans l’énoncé. Cela est particulièrement utile pour les déterminants tels que « le », « un » ou « une ». Cela ne présente aucune différence fonctionnelle par rapport au codage en dur des nombreuses combinaisons, mais peut contribuer à réduire le nombre de modèles nécessaires. Indiquez les éléments facultatifs avec « [ » et « ] ». Indiquez les éléments obligatoires avec « ( » et « ) ». Vous pouvez inclure plusieurs éléments dans le même groupe en les séparant par un caractère « | ».

Pour voir comment cela réduirait le nombre de modèles nécessaires, considérez l’ensemble suivant :

« Emmenez-moi au {floorName} »

« Emmenez-moi à {floorName} »

« Emmenez-moi {floorName} »

« Emmenez-moi à {floorName}, s’il vous plaît »

« Emmenez-moi au {floorName}, s’il vous plaît »

« Emmenez-moi {floorName}, s’il vous plaît »

« Conduisez-moi {floorName}, s’il vous plaît »

« Conduisez-moi à {floorName}, s’il vous plaît »

Ils peuvent tous être réduits à un modèle unique avec un regroupement et des éléments facultatifs. Tout d’abord, il est possible de regrouper « à » et « au » comme mots facultatifs comme suit : « [à | au], et ensuite, nous pouvons également rendre le « s’il vous plaît » facultatif. Enfin, nous pouvons regrouper les « Conduisez » et « Emmenez » en fonction de vos besoins.

« (Conduisez | Emmenez) moi [à | au] {floorName} [s’il vous plaît] »

Il est également possible d’inclure des entités facultatives. Imaginez qu’il y ait plusieurs niveaux de parking et que vous vouliez faire correspondre le mot qui précède le {floorName}. Pour ce faire, vous pouvez utiliser un modèle comme celui-ci :

« Emmenez-moi au [{floorType}] {floorName} »

Les éléments facultatifs sont également utiles si vous utilisez la reconnaissance des mots clés et une fonction Push-To-Talk (appuyer pour parler). Cela signifie parfois que le mot clé est présent, et parfois non. En supposant que votre mot clé était « ordinateur », votre modèle ressemblerait à ceci.

« [Ordinateur] Emmène-moi à {floorName} »

Notes

Bien qu’il soit utile d’utiliser des éléments facultatifs, cela augmente les risques de collisions de modèles. Cela survient lorsque deux modèles peuvent correspondre à la même expression parlée. Si cela se produit, le problème peut parfois être résolu en séparant les éléments facultatifs en modèles distincts.

Rôles d’entité

Dans le modèle, il peut y avoir un scénario dans lequel vous souhaitez utiliser la même entité plusieurs fois. Considérez le scénario de réservation d’un vol d’une ville à une autre. Dans ce cas, la liste des villes est la même, mais il est nécessaire de connaître la ville d’où provient l’utilisateur et la ville qui est la destination. Pour ce faire, vous pouvez utiliser un rôle attribué à une entité à l’aide d’un ’:’.

« Réservez un vol de {city:from} à {city:destination} »

Avec un modèle comme celui-ci, le résultat contiendra deux entités intitulées "city:from" et "city:destination", mais elles feront toutes deux référence à l’entité "city" à des fins de correspondance.

Priorité de correspondance d’intention

Parfois, plusieurs modèles correspondent au même énoncé. Dans ce cas, le moteur donne la priorité aux modèles suivants.

  1. Expressions exactes.
  2. Modèles avec des entités supplémentaires.
  3. Modèles avec des entités Integer.
  4. Modèles avec des entités List.
  5. Modèles avec des entités Any.
  6. Modèles avec plus d’octets mis en correspondance.
    • Exemple : le modèle « sélectionnez {quelque chose} sur la gauche » aura davantage de priorité que « sélectionnez {quelque chose} ».

Étapes suivantes