Diretrizes gerais

Assinatura de solicitações: todas as operações de API de runtime e de criação de modelo do Amazon Lex no Referência da API usam Signature V4 em solicitações de autenticação. Para obter mais informações sobre a autenticação de solicitações, consulte Processo de cadastramento do Signature versão 4 na Referência geral da Amazon Web Services.

Para PostContent, o Amazon Lex usa a opção de carga não assinada descrita em Cálculos de assinatura para o cabeçalho de autorização: transferência de carga em um único bloco (AWS Signature versão 4) na Referência de API do Amazon Simple Storage Service (S3).

Quando você usar a opção de carga não assinada, não inclua o hash da carga na solicitação canônica. Em vez disso, use a string literal "UNSIGNED-PAYLOAD" como o hash de carga. Inclua também um cabeçalho com o nome x-amz-content-sha256 e o valor UNSIGNED-PAYLOAD na solicitação PostContent.

Observe o seguinte sobre como o Amazon Lex captura valores de slot de declarações de usuário:

O Amazon Lex usa os valores de enumeração fornecidos em uma definição de tipo de slot para treinar seus modelos de machine learning. Suponha que você defina uma intenção chamada GetPredictionIntent com a seguinte amostra de declaração:

"Tell me the prediction for {Sign}" 

Onde {Sign} é um slot de ZodiacSign do tipo personalizado. Ele tem 12 valores de enumeração, de Aries a Pisces. Da declaração do usuário "Informe a previsão para ...", o Amazon Lex entende que o que vem a seguir é um signo do zodíaco.

Quando o campo valueSelectionStrategy é definido como ORIGINAL_VALUE usando a operação PutSlotType, ou se Expandir valores for selecionado no console, se o usuário disser "Informe-me a previsão da terra", o Amazon Lex inferirá que "terra" é um ZodiacSign e passará isso para seu aplicativo cliente ou para funções do Lambda. Você deve verificar quais valores do slot são válidos antes de usá-los em sua atividade de cumprimento.

Se você define o campo valueSelectionStrategy para TOP_RESOLUTION usando a operação PutSlotType, ou se Restrict to slot values and synonyms está selecionada no console, os valores retornados são limitados aos valores que você definiu para o tipo de slot. Por exemplo, se o usuário diz "Fale a previsão para terra", o valor não seria reconhecido, porque não é um dos valores definidos para o tipo de slot. Ao definir sinônimos para valores de slot, eles são reconhecidos da mesma forma que um valor de slot. No entanto, o valor de slot é retornado ao invés do sinônimo.

Quando o Amazon Lex chama uma função do Lambda ou retorna o resultado de uma interação de fala com o aplicativo cliente, a capitalização dos valores do slot não é garantida. Por exemplo, se você estiver inferindo valores para o tipo de slot integrado AMAZON.Movie e um usuário disser ou digitar "E o vento levou", o Amazon Lex poderá retornar "E o vento levou", "e o vento levou" ou "E o Vento Levou". Em interações de texto, a capitalização dos valores de slot corresponde ao texto inserido ou ao valor de slot, dependendo do valor do campo valueResolutionStrategy.

Ao definir valores de slot que contêm acrônimos, use os seguintes padrões:

O Amazon Lex não oferece suporte ao tipo de slot integrado AMAZON.LITERAL, diferentemente do Alexa Skills Kit. No entanto, o Amazon Lex oferece suporte à criação de tipos de slot personalizados que você pode usar para implementar essa funcionalidade. Como mencionado na observação anterior, você pode capturar valores fora da definição de tipo de slot personalizado. Adicione mais e diversificados valores de enumeração para aumentar a precisão de reconhecimento automático de voz (ASR) e compreensão de linguagem natural (NLU).

Os tipos de slot integrado AMAZON.DATE e AMAZON.TIME capturam as datas e horas absolutas e relativas. As datas e horas relativas são resolvidas na região em que o Amazon Lex está processando a solicitação.

Para o tipo de slot integrado AMAZON.TIME, se o usuário não especificar que um horário é antes ou depois do meio-dia, o horário será ambíguo e o Amazon Lex perguntará ao usuário novamente. Recomendamos que um horário absoluto seja escolhido para as solicitações. Por exemplo, use uma solicitação como "Em qual horário você deseja que a pizza seja entregue? Você pode dizer 18h ou 6 da tarde".

O fornecimento de dados de treinamento confusos em seu bot reduz a capacidade do Amazon Lex de compreender a entrada do usuário. Considere estes exemplos:

Suponha que você tenha duas intenções (OrderPizza e OrderDrink) no seu bot e ambas estejam configuradas com uma declaração "Quero pedir". Essa declaração não é mapeada para uma intenção específica da qual o Amazon Lex possa aprender ao criar o modelo de linguagem para o bot no tempo de criação. Como resultado, quando um usuário insere essa declaração em runtime, o Amazon Lex não pode escolher uma intenção com alto grau de confiança.

Considere outro exemplo, em que você define uma intenção personalizada para obter uma confirmação do usuário (por exemplo, MyCustomConfirmationIntent) e configura a intenção com as declarações "Sim" e "Não". Observe que o Amazon Lex também tem um modelo de linguagem para entender confirmações de usuário. Isso pode criar uma situação de conflito. Quando o usuário responde com um "Sim", isso significa que é uma confirmação da intenção em andamento ou que o usuário está solicitando a intenção personalizada que você criou?

Em geral, a amostra de declarações fornecida deve ser mapeada para uma intenção específica e, opcionalmente, para valores de slot específicos.

As operações de API de runtime PostContent e PostText reconhecem um ID de usuário como o parâmetro obrigatório. Os desenvolvedores podem configurar isso para qualquer valor que atenda às restrições descritas na API. Recomendamos que você não use esse parâmetro para enviar informações confidenciais como logins de usuário, e-mails ou números de seguro social. Esse ID é usado principalmente para identificar exclusivamente a conversa com um bot (pode haver vários usuários pedindo pizza).

Se o aplicativo cliente usar o Amazon Cognito para autenticação, você poderá usar o ID de usuário do Amazon Cognito como o ID de usuário do Amazon Lex. Observe que qualquer função do Lambda configurada para o bot deve ter seu próprio mecanismo de autenticação para identificar o usuário em cujo nome o Amazon Lex está invocando a função do Lambda.

Recomendamos que você defina uma intenção que capte a intenção de um usuário de interromper a conversa. Por exemplo, você pode definir uma intenção (NothingIntent) com amostra de declarações ("Eu não quero nada", "sair", "tchau tchau"), nenhum slot e nenhuma função do Lambda configurada como um hook de código. Isso permite que os usuários fechem uma conversa com tranquilidade.