Allgemeine Richtlinien

Signierungsanfragen — Alle Amazon Lex-Modellerstellungs- und Runtime-API-Operationen in der VersionAPIReferenz 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 der Amazon Simple Storage Service (S3) API-Referenz unter Signaturberechnungen für den Autorisierungsheader: Transfering Payload in a Single Chunk (AWS Signature Version 4) 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 Benutzeraussage „Sag mir die Vorhersage für...“ Amazon Lex versteht, dass das Folgende ein Sternzeichen ist.

Wenn dasvalueSelectionStrategy Feld so eingestellt ist, dass derPutSlotType VorgangORIGINAL_VALUE verwendet wird, oder wenn in der Konsole Werte erweitern ausgewählt ist und der Benutzer „Sag mir die Vorhersage für die Erde“ sagt, leitet Amazon Lex ab, dass „Erde“ ein ist,ZodiacSign und übergibt sie an Ihre Client-Anwendung oder Lambda-Funktionen. 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 in Amazon.Movie integrierten Slot-Typ ermitteln möchten 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 Daten und Uhrzeiten werden in der Region festgelegt, in der Amazon Lex die Anfrage bearbeitet.

Wenn der Benutzer beimAMAZON.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 dazu 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."

Wenn Sie in Ihrem Bot verwirrende Trainingsdaten bereitstellen, verringert sich 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 zum Zeitpunkt der Erstellung 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 verfügt, um Benutzerbestätigungen zu verstehen. 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-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“) definieren, ohne Steckplätze und ohne Lambda-Funktion, die als Code-Hook konfiguriert ist. Auf diese Weise können Benutzer einer Konversation elegant beenden.