Directrices generales

Firma de solicitudes: todas las operaciones de la API en tiempo de ejecución y de desarrollo del modelo de Amazon Lex en referencia de la API utilizan Signature Version 4 para autenticar solicitudes. Para obtener más información acerca de la autenticación de solicitudes, consulte Proceso de firma Signature Version 4 en la Referencia general de Amazon Web Services.

Para PostContent, Amazon Lex utiliza la opción de carga sin firma que se describe en Cálculos de firma para el encabezado de autorización: transferencia de cargas en un solo fragmento (AWS Signature Version 4) en la Referencia de la API de Amazon Simple Storage Service (S3).

Al utilizar la opción de carga sin firma, no incluya el hash de la carga en la solicitud canónica. En su lugar, utilice la cadena literal "UNSIGNED-PAYLOAD" como hash de la carga. Incluya también un encabezado con el nombre x-amz-content-sha256 y el valor UNSIGNED-PAYLOAD en la solicitud PostContent.

Tenga en cuenta lo siguiente sobre el modo en que Amazon Lex captura los valores de ranura de los enunciados del usuario:

Amazon Lex utiliza los valores de enumeración facilitados en una definición de tipo de ranura para entrenar a sus modelos de machine learning. Suponga que define una intención denominada GetPredictionIntent con el siguiente enunciado de muestra:

"Tell me the prediction for {Sign}" 

Donde {Sign} es un slot de tipo personalizado ZodiacSign y Tiene 12 valores de enumeración, de Aries a Pisces. Por el enunciado del usuario “Tell me the prediction for…”, Amazon Lex entiende que lo que sigue es un signo del zodíaco.

Cuando en el campo valueSelectionStrategy se ha establecido ORIGINAL_VALUE con la operación PutSlotType o se ha seleccionado Expandir valores en la consola, si el usuario dice “Tell me the prediction for earth”, Amazon Lex deduce que “earth” es un ZodiacSign y se lo pasa a la aplicación cliente o a las funciones de Lambda. Debe comprobar que los valores de slot sean válidos antes de usarlos en su actividad de cumplimiento.

Si establece el campo valueSelectionStrategy en TOP_RESOLUTION utilizando la operación PutSlotType o si se ha seleccionado Restrict to slot values and synonyms en la consola, los valores devueltos se limitan a los valores definidos para el tipo de slot. Por ejemplo, si el usuario dice "Tell me the prediction for earth", el valor no se reconocería porque no es uno de los valores definidos para el tipo de slot. Cuando se definen sinónimos para los valores slot, se reconocen como si fueran un valor de slot, pero se devuelve el valor de slot en lugar del sinónimo.

Cuando Amazon Lex llama a una función de Lambda o devuelve el resultado de una interacción de voz con la aplicación cliente, no se garantiza el uso de mayúsculas y minúsculas para los valores de ranura. Por ejemplo, si obtiene valores para el tipo de ranura integrado AMAZON.Movie y un usuario dice o escribe “Lo que el viento se llevó”, podría devolver “Lo Que El Viento Se Llevó”, “lo que el viento se llevó” o “Lo que el Viento se Llevó”. En el caso de las interacciones de texto, el uso de mayúsculas y minúsculas en los valores de slot coincide con el texto introducido o con el valor de slot, en función del valor del campo valueResolutionStrategy.

Al definir los valores de los slots que contienen acrónimos, utilice los siguientes patrones:

Amazon Lex no admite el tipo de ranura integrado AMAZON.LITERAL que sí admite Alexa Skills Kit. Sin embargo, Amazon Lex admite la creación de tipos de ranura personalizados que puede utilizar para implementar esta funcionalidad. Como se mencionó anteriormente, puede capturar valores fuera de la definición del tipo de slot personalizado. Añada otros valores de enumeración diferentes para aumentar la precisión del reconocimiento automático de voz (ASR) y la comprensión del lenguaje natural (NLU).

Los tipos de slot integrados AMAZON.DATE y AMAZON.TIME capturan fechas y horas relativas y absolutas. Las fechas y horas relativas se resuelven para la región donde Amazon Lex procesa la solicitud.

Para el tipo de ranura integrado AMAZON.TIME, si el usuario no especifica si una hora es antes o después del mediodía, esa hora es ambigua y Amazon Lex volverá a preguntar al usuario. Recomendamos utilizar preguntas que permitan obtener la hora absoluta. Por ejemplo, para una pregunta como «¿Cuándo quieres recibir la pizza?» Puede decir «6 p. m.» o «a las 6 de la tarde».

Si proporciona datos de aprendizaje confusos en el bot, se reducirá la capacidad de Amazon Lex para comprender la entrada del usuario. Estudie estos ejemplos:

Imagine que dispone de dos intenciones (OrderPizza y OrderDrink) en su bot y ambas están configuradas con un enunciado "I want to order". Este enunciado no corresponde a una intención específica que Amazon Lex pueda aprender durante el desarrollo del modelo de lenguaje para el bot en tiempo de compilación. Como resultado, cuando un usuario dice este enunciado en tiempo de ejecución, Amazon Lex no puede elegir una intención con un alto nivel de confianza.

Otro ejemplo podría ser cuando define una intención personalizada para obtener una confirmación del usuario (por ejemplo, MyCustomConfirmationIntent) y configura la intención con los enunciados "Yes" y "No". Tenga en cuenta que Amazon Lex también cuenta con un modelo de lenguaje para comprender las confirmaciones del usuario. Esto puede generar situaciones conflictivas. Cuando el usuario responde afirmativamente, ¿significa que se trata de una confirmación de la intención en curso o que el usuario solicita la intención personalizada que usted ha creado?

En general, los enunciados de muestra que proporcione deben corresponder a una intención específica y, de forma opcional, a valores de slot específicos.

Las operaciones de la API en tiempo de ejecución PostContent y PostText toman un ID de usuario como el parámetro obligatorio. Los desarrolladores lo pueden establecer en cualquier valor que cumpla las limitaciones descritas en la API. Recomendamos no usar este parámetro para enviar cualquier información confidencial, por ejemplo, inicios de sesión de los usuarios, mensajes de correo o números de la seguridad social. Este ID se utiliza principalmente para identificar de forma exclusiva la conversación con un bot (puede haber varios usuarios que pidan pizza).

Si la aplicación cliente utiliza Amazon Cognito para la autenticación, podría utilizar el ID de usuario de Amazon Cognito como ID de usuario de Amazon Lex. Tenga en cuenta que cualquier función de Lambda configurada para el bot debe tener su propio mecanismo de autenticación para identificar al usuario en cuyo nombre Amazon Lex invoca la función de Lambda.

Le animamos a que defina una intención que capture la intención de un usuario de interrumpir la conversación. Por ejemplo, puede definir una intención (NothingIntent) con enunciados de ejemplo (“No quiero nada”, “salir”, “adiós”), sin ranuras y sin ninguna función de Lambda configurada como enlace de código. Esto permite a los usuarios cerrar una conversación con fluidez.