Consignes générales

Demandes de signature : toutes les opérations d'API de création de modèles et d'exécution d'Amazon Lex dans le cadre de la signature V4 Référence API utilisent la signature V4 pour authentifier les demandes. Pour plus d'informations sur l'authentification des demandes, consultez Processus de signature Signature Version 4 dans le document Référence générale d'Amazon Web Services.

Amazon Lex utilise en effet l'option de charge utile non signée décrite dans la section Calculs de signature pour l'en-tête d'autorisation : transfert de la charge utile en un seul morceau (AWS Signature Version 4) dans le document de référence d'API Amazon Simple Storage Service (S3). PostContent

Lorsque vous utilisez l'option de charge utile non signée, n'incluez pas le hachage de la charge utile dans la demande canonique. A la place, utilisez la chaîne littérale « UNSIGNED-PAYLOAD » comme hachage de la charge utile. Incluez également un en-tête avec le nom x-amz-content-sha256 et la valeur UNSIGNED-PAYLOAD dans la demande PostContent.

Notez ce qui suit à propos de la façon dont Amazon Lex capture les valeurs des créneaux à partir des énoncés des utilisateurs :

Amazon Lex utilise les valeurs d'énumération que vous fournissez dans une définition de type d'emplacement pour entraîner ses modèles d'apprentissage automatique. Supposons que vous définissiez une intention appelée GetPredictionIntent avec l'exemple d'énoncé suivant :

"Tell me the prediction for {Sign}" 

Où {Sign} est une option du type personnalisé ZodiacSign. Elle comporte 12 valeurs d'énumération (Aries jusqu'à Pisces). Extrait de l'énoncé de l'utilisateur « Dites-moi la prédiction pour... » Amazon Lex comprend que ce qui suit est un signe du zodiaque.

Lorsque le valueSelectionStrategy champ est configuré pour ORIGINAL_VALUE utiliser l'PutSlotTypeopération, ou si Expand values est sélectionné dans la console, si l'utilisateur dit « Donnez-moi la prédiction pour la Terre », Amazon Lex en déduit que « Earth » est un ZodiacSign et le transmet à votre application cliente ou aux fonctions Lambda. Vous devez vérifier que les valeurs d'options sont valides avant de les utiliser dans votre activité d'exécution.

Si vous définissez le champ valueSelectionStrategy sur TOP_RESOLUTION à l'aide de l'opération PutSlotType, ou si Restrict to slot values and synonyms est sélectionné dans la console, les valeurs renvoyées sont limitées aux valeurs que vous avez définies pour le type d'option. Par exemple, si l'utilisateur dit « Tell me the prediction for earth », la valeur ne sera pas reconnue parce qu'il ne s'agit pas de l'une des valeurs définies pour le type d'option. Lorsque vous définissez des synonymes pour des valeurs d'option, ils sont reconnus comme une valeur d'option, mais la valeur d'option est renvoyée à la place du synonyme.

Lorsqu'Amazon Lex appelle une fonction Lambda ou renvoie le résultat d'une interaction vocale avec votre application cliente, le respect des valeurs des créneaux n'est pas garanti. Par exemple, si vous recherchez des valeurs pour le type de machine à sous intégré à Amazon.MOVIE et qu'un utilisateur dit ou tape « Autant en emporte le vent », Amazon Lex peut renvoyer « Autant en emporte le vent », « Autant en emporte le vent » ou « Autant en emporte le vent ». Dans des interactions textuelles, la casse des valeurs d'option correspond au texte saisi ou à la valeur d'option, en fonction de la valeur du champ valueResolutionStrategy.

Lorsque vous définissez des valeurs d'emplacement contenant des acronymes, utilisez les modèles suivants :

Amazon Lex ne prend pas en charge le type de slot intégré AMAZON.LITERAL pris en charge par le kit Alexa Skills. Amazon Lex prend toutefois en charge la création de types d'emplacements personnalisés que vous pouvez utiliser pour implémenter cette fonctionnalité. Comme mentionné dans le point précédent, vous pouvez capturer des valeurs en dehors de la définition du type d'option personnalisé. Ajoutez plusieurs valeurs d'énumération variées pour optimiser la reconnaissance vocale automatique (ASR) et la précision de la compréhension du langage naturel (NLU).

Les types d'options prédéfinis AMAZON.DATE et AMAZON.TIME capturent les dates et heures absolues et relatives. Les dates et heures relatives sont résolues dans la région où Amazon Lex traite la demande.

Pour le type de créneau AMAZON.TIME intégré, si l'utilisateur ne précise pas d'heure avant ou après midi, l'heure est ambiguë et Amazon Lex le demandera à nouveau à l'utilisateur. Nous vous recommandons d'utiliser des invites qui impliquent une heure absolue. Par exemple, utilisez une invite, telles que « When do you want your pizza delivered? You can say 6 PM or 6 in the evening ».

Le fait de fournir des données d'entraînement confuses à votre bot réduit la capacité d'Amazon Lex à comprendre les informations saisies par les utilisateurs. Prenez en compte les exemples suivants :

Supposons que vous ayez deux intentions (OrderPizza et OrderDrink) dans le bot et que les deux soient configurées avec un énoncé « I want to order ». Cet énoncé ne correspond pas à une intention spécifique dont Amazon Lex peut tirer des leçons lors de la création du modèle de langage du bot au moment de la création. Par conséquent, lorsqu'un utilisateur saisit cet énoncé au moment de l'exécution, Amazon Lex ne peut pas identifier une intention avec un degré de certitude élevé.

Envisagez un autre exemple où vous définissez une intention personnalisée pour obtenir une confirmation de l'utilisateur (par exemple, MyCustomConfirmationIntent) et configurez l'intention avec les énoncés « Yes » et « No ». Notez qu'Amazon Lex dispose également d'un modèle linguistique permettant de comprendre les confirmations des utilisateurs. Cela peut créer une situation conflictuelle. Lorsque l'utilisateur répond par « Yes », cela signifie-t-il qu'il s'agit d'une confirmation de l'intention en cours ou que l'utilisateur demande l'intention personnalisée que vous avez créée ?

En général, les exemples d'énoncé que vous fournissez doivent correspondre à une intention spécifique et éventuellement à des valeurs d'option spécifiques.

Les opérations d'API d'exécution PostContent et PostText utilisent un ID utilisateur comme paramètre obligatoire. Les développeurs peuvent lui attribuer n'importe quelle valeur conformes aux contraintes décrites dans l'API. Nous vous recommandons de ne pas utiliser ce paramètre pour envoyer des informations confidentielles, telles que des identifiants de connexion, des e-mails ou des numéros de sécurité sociale. Cet identifiant est principalement utilisé pour identifier une conversation avec un bot (il peut y avoir plusieurs utilisateurs qui commandent une pizza).

Si votre application cliente utilise Amazon Cognito pour l'authentification, vous pouvez utiliser l'identifiant utilisateur Amazon Cognito comme identifiant utilisateur Amazon Lex. Notez que toute fonction Lambda configurée pour votre bot doit disposer de son propre mécanisme d'authentification pour identifier l'utilisateur au nom duquel Amazon Lex appelle la fonction Lambda.

Nous vous incitons à définir une intention qui capture l'intention d'un utilisateur d'interrompre la conversation. Par exemple, vous pouvez définir une intention (NothingIntent) avec des exemples d'énoncés (« Je ne veux rien », « exit », « bye bye »), sans emplacements ni fonction Lambda configurée comme crochet de code. Cela permet aux utilisateurs de mettre fin élégamment à une conversation.