Allgemeine Richtlinien

Signieren von Anfragen — Alle Amazon Lex Lex-Modellerstellungs- und Runtime-API-Operationen API-Referenz verwenden die Signatur V4 zur Authentifizierung von Anfragen. Weitere Informationen zur Authentifizierung von Anfragen finden Sie unter Signature Version 4-Signaturprozess im Allgemeine Amazon Web Services-Referenz.

Denn Amazon Lex verwendet die unsignierte Payload-OptionPostContent, die in Signature Calculations for the Authorization Header: Transfering Payload in a Single Chunk (AWS Signature Version 4) in der Amazon Simple Storage Service (S3) API-Referenz beschrieben ist.

Schließen Sie den Hash der Nutzlast nicht in die kanonische Anforderung ein, wenn Sie die nicht signierte Nutzlast-Option verwenden. Verwenden Sie stattdessen die Literalzeichenfolge "UNSIGNED-PAYLOAD" als Hash der Nutzlast. Fügen Sie zudem einen Header namens x-amz-content-sha256 und den Wert UNSIGNED-PAYLOAD in die PostContent-Anforderung ein.

Beachten Sie Folgendes darüber, wie Amazon Lex Slot-Werte aus Benutzeräußerungen erfasst:

Amazon Lex verwendet die Aufzählungswerte, die Sie in einer Slot-Typdefinition angeben, um seine Machine-Learning-Modelle zu trainieren. Angenommen, Sie definieren eine Absicht namens GetPredictionIntent mit der folgenden Beispieläußerung:

"Tell me the prediction for {Sign}" 

Dabei ist {Sign} ein Slot des benutzerdefinierten Typs ZodiacSign. Er hat 12 Aufzählungswerte, Aries bis Pisces. Aus der Benutzeräußerung „Erzähl mir die Vorhersage für...“ Amazon Lex versteht, dass es sich bei dem Folgenden um ein Sternzeichen handelt.

Wenn das valueSelectionStrategy Feld so eingestellt ist, dass die PutSlotType Operation ORIGINAL_VALUE verwendet wird, oder wenn in der Konsole Werte erweitern ausgewählt ist und der Benutzer sagt: „Erzählen Sie mir die Vorhersage für die Erde“, leitet Amazon Lex davon ab, dass „Erde“ ein ist, ZodiacSign und leitet es an Ihre Client-Anwendung oder Lambda-Funktionen weiter. Stellen Sie sicher, dass die Slot-Werte gültig sind, ehe Sie diese in einer Erfüllungsaktivität verwenden.

Wenn das Feld valueSelectionStrategy mithilfe der Operation PutSlotType auf TOP_RESOLUTION gesetzt wird oder wenn Restrict to slot values and synonyms in der Konsole ausgewählt wird, werden die zurückgegebenen Werte auf die Werte beschränkt, die Sie als Slot-Typ angegeben haben. Wenn der Benutzer beispielsweise sagen würde, „Gib mir die Vorhersage für Erde“, würde der Wert nicht erkannt werden, weil er nicht zu den Werten gehört, die als Slot-Typ definiert sind. Wenn Sie Synonyme für Slot-Werte definieren, werden sie ebenfalls als Slot-Wert erkannt, jedoch wird der Slot-Wert anstelle des Synonyms zurückgegeben.

Wenn Amazon Lex eine Lambda-Funktion aufruft oder das Ergebnis einer Sprachinteraktion mit Ihrer Client-Anwendung zurückgibt, kann die Groß- und Kleinschreibung der Slot-Werte nicht garantiert werden. Wenn Sie beispielsweise Werte für den integrierten Slot-Typ Amazon.Movie ermitteln und ein Benutzer „Vom Winde verweht“ sagt oder eingibt, gibt Amazon Lex möglicherweise „Vom Winde verweht“, „Vom Winde verweht“ oder „Vom Winde verweht“ zurück. Bei Textinteraktionen entspricht die Groß-/Kleinschreibung der Slot-Werte dem eingegebenen Text oder dem Slot-Wert, abhängig von dem Wert im Feld valueResolutionStrategy.

Verwenden Sie bei der Definition von Slot-Werten, die Akronyme enthalten, die folgenden Muster:

Amazon Lex unterstützt den integrierten Steckplatztyp AMAZON.LITERAL, den das Alexa Skills Kit unterstützt, nicht. Amazon Lex unterstützt jedoch die Erstellung benutzerdefinierter Slot-Typen, mit denen Sie diese Funktionalität implementieren können. Wie es oben bereits erwähnt ist, können Sie Werte außerhalb der benutzerdefinierten Slot-Typ-Definition erfassen. Sie können weitere, verschiedene Aufzählungswerte hinzufügen, um die Genauigkeit der automatischen Spracherkennung (ASR) und das Verstehen der natürlichen Sprache (NLU) zu verstärken.

Die integrierten Slot-Typen AMAZON.DATE und AMAZON.TIME erfassen sowohl absolute als auch relative Datums- und Zeitangaben. Relative Datums- und Uhrzeitangaben werden in der Region festgelegt, in der Amazon Lex die Anfrage bearbeitet.

Wenn der Benutzer für den AMAZON.TIME integrierten Slot-Typ nicht angibt, dass eine Uhrzeit vor oder nach Mittag liegt, ist die Uhrzeit mehrdeutig und Amazon Lex fordert den Benutzer erneut auf. Wir empfehlen Aufforderungen, in denen nach der absoluten Zeit gefragt wird. Verwenden Sie beispielsweise eine Aufforderung wie "Wann möchten Sie Ihre Pizza geliefert bekommen? Sie können 6 Uhr morgen oder 6 Uhr abends angeben."

Die Bereitstellung verwirrender Trainingsdaten in Ihrem Bot verringert die Fähigkeit von Amazon Lex, Benutzereingaben zu verstehen. Berücksichtigen Sie die folgenden Beispiele:

Angenommen, Sie haben zwei Absichten (OrderPizza und OrderDrink) in Ihrem Bot und beide wurden mit der Äußerung"Ich möchte bestellen" konfiguriert. Diese Äußerung entspricht keiner bestimmten Absicht, aus der Amazon Lex lernen kann, während das Sprachmodell für den Bot zur Build-Zeit erstellt wird. Wenn ein Benutzer diese Äußerung zur Laufzeit eingibt, kann Amazon Lex daher keine Absicht mit einem hohen Maß an Sicherheit auswählen.

Erwägen Sie ein weiteres Beispiel, in dem Sie eine benutzerdefinierte Absicht für eine Bestätigung vom Benutzer definieren (beispielsweise MyCustomConfirmationIntent), und konfigurieren Sie die Absicht mit den Äußerungen "Ja" und "Nein". Beachten Sie, dass Amazon Lex auch über ein Sprachmodell für das Verständnis von Benutzerbestätigungen verfügt. Dies kann widersprechende Situation schaffen. Wenn der Benutzer mit "Ja" antwortet, bedeutet dies, dass es eine Bestätigung für die laufende Absicht ist, oder dass der Benutzer die benutzerdefinierte Absicht anfordert, die Sie erstellt haben?

Im Allgemeinen sollten die Beispieläußerungen, die Sie bereitstellen, zu einer bestimmten Absicht gehören und, optional, zu bestimmten Slot-Werten.

Die Laufzeit-API-Operationen PostContent und PostText nehmen eine Benutzer-ID als erforderlichen Parameter. Developer können diese auf jeden Wert stellen, der den in der API beschriebenen Einschränkungen übereinstimmt. Wir empfehlen, dass Sie nicht mit diesem Parameter vertrauliche Informationen wie Benutzerkonten, E-Mails oder Sozialversicherungsnummern senden. Diese ID wird in erster Linie dafür benutzt, eindeutig Konversation mit einem Bot zu identifizieren (Es kann mehrere Benutzer geben, die Pizza bestellen).

Wenn Ihre Client-Anwendung Amazon Cognito für die Authentifizierung verwendet, können Sie die Amazon Cognito Cognito-Benutzer-ID als Amazon Lex Lex-Benutzer-ID verwenden. Beachten Sie, dass jede für Ihren Bot konfigurierte Lambda-Funktion über einen eigenen Authentifizierungsmechanismus verfügen muss, um den Benutzer zu identifizieren, in dessen Namen Amazon Lex die Lambda-Funktion aufruft.

Wir empfehlen, dass Sie eine Absicht definieren, die eine Absicht des Benutzers, die Konversation zu beenden, erfasst. Sie können beispielsweise eine Absicht (NothingIntent) mit Beispieläußerungen („Ich will nichts“, „exit“, „bye bye“), ohne Slots und ohne Lambda-Funktion, die als Code-Hook konfiguriert ist, definieren. Auf diese Weise können Benutzer einer Konversation elegant beenden.