Linee guida generali

Richieste di firma: tutte le operazioni API di esecuzione e creazione di modelli Amazon Lex Documentazione di riferimento API utilizzano la firma V4 per l'autenticazione delle richieste. Per ulteriori informazioni sulle richieste di autenticazione, consulta la pagina relativa al processo di firma Signature Version 4 nella Riferimenti generali di Amazon Web Services.

InfattiPostContent, Amazon Lex utilizza l'opzione di payload non firmato descritta in Signature Calculations for the Authorization Header: trasferimento del payload in a Single Chunk (AWS Signature versione 4) nel riferimento all'API Amazon Simple Storage Service (S3).

Se utilizzi l'opzione di payload senza firma, non includere l'hash di payload nella richiesta canonica. In alternativa, puoi utilizzare la stringa letterale "UNSIGNED-PAYLOAD" come hash di payload. Dovrai inoltre includere un'intestazione denominata x-amz-content-sha256 e il valore UNSIGNED-PAYLOAD nella richiesta PostContent.

Tieni presente quanto segue su come Amazon Lex acquisisce i valori degli slot dagli enunciati degli utenti:

Amazon Lex utilizza i valori di enumerazione forniti in una definizione del tipo di slot per addestrare i suoi modelli di apprendimento automatico. Supponiamo di definire un intento denominato GetPredictionIntent con la seguente enunciazione di esempio:

"Tell me the prediction for {Sign}" 

In cui {Sign} è uno slot di tipo personalizzato ZodiacSign. Sono presenti 12 valori di enumerazione, da Aries a Pisces. Dall'espressione dell'utente «Dimmi la previsione per...» Amazon Lex capisce che quello che segue è un segno zodiacale.

Quando il valueSelectionStrategy campo è impostato per l'ORIGINAL_VALUEutilizzo dell'PutSlotTypeoperazione o se nella console è selezionato Expand values, se l'utente dice «Dimmi la previsione per la terra», Amazon Lex deduce che «earth» è un ZodiacSign e lo passa all'applicazione client o alle funzioni Lambda. Prima di utilizzare i valori di slot per l'operazione di creazione, verifica che contengano valori validi.

Se imposti il campo valueSelectionStrategy su TOP_RESOLUTION tramite l'operazione PutSlotType oppure se nella console è selezionata l'opzione Restrict to slot values and synonyms (Limita a valori slot e sinonimi), i valori restituiti vengono limitati in base ai valori definiti per il tipo di slot. Ad esempio, se l'utente dice "Tell me the prediction for earth", questo valore non verrà riconosciuto perché non rientra nei valori definiti per il tipo di slot. Quando definisci i sinonimi per valori di slot, questi vengono riconosciuti esattamente come i valori di slot, tuttavia, al posto del sinonimo viene restituito il valore di slot.

Quando Amazon Lex richiama una funzione Lambda o restituisce il risultato di un'interazione vocale con l'applicazione client, il caso dei valori dello slot non è garantito. Ad esempio, se stai cercando valori per il tipo di slot integrato Amazon.movie e un utente dice o digita «Via col vento», Amazon Lex potrebbe restituire «Via col vento», «andato col vento» o «Via col vento». Nelle interazioni di testo, la distinzione tra maiuscole e minuscole nei valori di slot corrisponde al testo immesso o al valore di slot, a seconda del valore del campo valueResolutionStrategy.

Quando definisci i valori degli slot che contengono acronimi, utilizza i seguenti schemi:

Amazon Lex non supporta il tipo di slot integrato AMAZON.LITERAL supportato dall'Alexa Skills Kit. Tuttavia, Amazon Lex supporta la creazione di tipi di slot personalizzati che puoi utilizzare per implementare questa funzionalità. Come accennato nel punto precedente, puoi acquisire i valori al di fuori della definizione del tipo di slot personalizzato. Per migliorare l'accuratezza del riconoscimento vocale automatico (ASR) e della comprensione del linguaggio naturale (NLU), puoi aggiungere ulteriori valori di enumerazione diversi.

I tipi di slot incorporati AMAZON.DATE e AMAZON.TIME acquisiscono date e orari sia assoluti che relativi. Le date e gli orari relativi vengono risolti nella regione in cui Amazon Lex elabora la richiesta.

Per il tipo di slot AMAZON.TIME integrato, se l'utente non specifica che l'ora è precedente o successiva a mezzogiorno, l'ora è ambigua e Amazon Lex lo richiederà nuovamente. Ti consigliamo quindi di utilizzare prompt che consentano di ottenere un orario assoluto. Ad esempio, puoi utilizzare prompt simili al seguente "When do you want your pizza delivered? You can say 6 PM or 6 in the evening."

Fornire dati di formazione confusi nel bot riduce la capacità di Amazon Lex di comprendere l'input dell'utente. Esamina questi esempi:

Supponiamo di disporre di due intenti (OrderPizza e OrderDrink) nel bot, entrambi configurati con enunciazione "I want to order". Questo enunciato non corrisponde a un intento specifico da cui Amazon Lex può imparare durante la creazione del modello linguistico per il bot in fase di compilazione. Di conseguenza, quando un utente inserisce questo enunciato in fase di esecuzione, Amazon Lex non è in grado di scegliere un intento con un elevato grado di sicurezza.

Consideriamo un altro esempio in cui si definisce un intento personalizzato per ottenere una conferma da parte dell'utente (ad esempio MyCustomConfirmationIntent) e si configura l'intento con le enunciazioni "Yes" e "No". Tieni presente che Amazon Lex dispone anche di un modello linguistico per comprendere le conferme degli utenti. la presenza di questo modello può determinare una situazione conflittuale. Infatti, quando l'utente risponde con un "Yes", non è chiaro se si tratta di una conferma relativa all'intento in corso o di una richiesta dell'utente relativa all'intento personalizzato creato.

In generale, le enunciazioni di esempio fornite devono essere mappate a un intento specifico e, facoltativamente, a valori di slot specifici.

Le operazioni delle API di runtime PostContent e PostText accettano un ID utente come parametro obbligatorio. Gli sviluppatori possono impostare questo parametro su qualsiasi valore che soddisfi i vincoli descritti nell'API. Consigliamo di non utilizzare questo parametro per inviare informazioni riservate quali credenziali di accesso, e-mail o numeri di previdenza sociale dell'utente. Questo ID viene utilizzato principalmente per identificare in modo univoco la conversazione con un bot (potrebbero essere presenti più utenti che ordinano la pizza).

Se la tua applicazione client utilizza Amazon Cognito per l'autenticazione, puoi utilizzare l'ID utente Amazon Cognito come ID utente Amazon Lex. Tieni presente che qualsiasi funzione Lambda configurata per il tuo bot deve disporre di un proprio meccanismo di autenticazione per identificare l'utente per conto del quale Amazon Lex sta richiamando la funzione Lambda.

Consigliamo di definire un intento che consenta di rilevare l'intenzione dell'utente di interrompere una conversazione. Ad esempio, puoi definire un intent (NothingIntent) con enunciati di esempio («I don't want anything», «exit», «bye bye»), senza slot e nessuna funzione Lambda configurata come code hook. Questo intento consentirebbe agli utenti di chiudere correttamente una conversazione.