In diesem Leitfaden finden Sie allgemeine Best Practices für das Design aller Arten von Agents.
Außerdem sollten Sie den Leitfaden zum Design von Sprach-Agents und den Leitfaden zu Best Practices für die Verwendung des Dialogflow CX-Dienstes lesen.
Allgemeine Empfehlungen
Agents iterativ entwickeln
Wenn der Agent groß oder komplex ist, erstellen Sie zuerst einen Dialog, in dem nur Anfragen der obersten Ebene behandelt werden. Nachdem Sie die Grundstruktur erstellt haben, testen Sie die Dialogpfade, um zu überprüfen, ob sie alle möglichen Routen abdecken, die ein Endnutzer durchlaufen kann.
Wenn sich Ihr Agent weiterentwickelt, sollten Sie die Funktion Testfälle für die testgetriebene Entwicklung verwenden.
Vordefinierte Agents
Dialogflow CX bietet Agent-Vorlagen, die Ihnen den Einstieg erleichtern. Vordefinierte Agents decken gängige Anwendungsfälle wie Finanzdienstleistungen, Telekommunikation und Reisen ab. Sie enthalten bereits Intents und Entitäten, die häufig gestellte Anfragen abdecken. Fügen Sie für Ihr Unternehmen spezifische Routen und Fulfillment-Optionen hinzu und Sie haben in kürzester Zeit einen funktionierenden Agent.
Integrationen und Dienste verbinden
Es gibt mehrere Möglichkeiten, Dialogflow CX-Agents zu integrieren. In diesem Abschnitt finden Sie Best Practices für die Auswahl der Integrationsmethode.
Integrationen
Dialogflow CX-Integrationen bieten eine sofort einsatzbereite Benutzeroberfläche für Ihren Agent. Wenn Sie eine Integration verwenden, müssen Sie die Dialogflow CX API nicht direkt aufrufen, da dies von der Integration übernommen wird. Diese Integrationen können einen Text-Agenten bereitstellen, den Sie auf Ihrer Website einbetten, mit anderen Messaging-Plattformen verbinden oder als Telefonieschnittstelle nutzen können.
Dialogflow CX API
Wenn keine der vorgefertigten Integrationen geeignet ist oder Sie die Schnittstelle für Ihr System anpassen möchten, können Sie die Dialogflow CX API direkt verwenden. Bei diesem Ansatz müssen Sie die Benutzeroberfläche für Ihren Agenten implementieren oder eine vorhandene Benutzeroberfläche verwenden.
Webhooks
Wenn Ihr Agent nicht vollständig mit statischen Daten definiert werden kann, müssen Sie Webhooks verwenden, um Ihren Dienst zu verbinden und einen Agent bereitzustellen, der dynamische Szenarien verarbeiten kann. Dies gilt unabhängig davon, ob Sie Integrationen oder die Dialogflow CX API verwenden.
Agent-Ressourcen
Dialogflow CX-Agent-Ressourcen können auf viele Arten verwendet werden, um ein gewünschtes Ergebnis zu erzielen. In diesem Abschnitt finden Sie Tipps zur Auswahl der richtigen Ressourcen für die richtigen Szenarien.
Abläufe und Seiten
Abläufe und Seiten geben Ihrem Agent eine Struktur. Sie können sich Seiten als Knoten in einem Zustandsautomaten und Flows als Gruppen zusammengehöriger Seiten vorstellen. Sie steuern Übergänge zwischen Knoten mit Status-Handlern, die aufgerufen werden, wenn eine Intention erkannt wird, eine Bedingung erfüllt ist oder ein Ereignis ausgelöst wird.
Ein einfacher Agent kann mit einem einzelnen Ablauf funktionieren, aber komplexe Agents sind fast immer besser mit mehreren Abläufen konzipiert. Jeder Ablauf sollte ein übergeordnetes Thema für Ihren Agenten darstellen. Jede Seite, die mit dem Ablauf verknüpft ist, trägt dazu bei, das Thema zu behandeln. Außerdem kann jeder Ablauf eigene Einstellungen haben und einer Teilmenge von Teammitgliedern gehören. So lässt sich die Arbeit beim Entwerfen großer Agents aufteilen.
Wenn Sie einen großen, komplexen Agent entwerfen, müssen Sie die Grenzwerte für „Abläufe pro Agent“ und „Seiten pro Ablauf“ berücksichtigen. Diese Limits tragen dazu bei, dass Ihr Agent leistungsfähig bleibt.
Wenn Ihr Agent-Design zu viele Abläufe pro Agent enthält, fassen Sie zusammengehörige Themen in einem einzigen Ablauf zusammen. Sie könnten beispielsweise die folgenden Themen in einem einzigen Ablauf „Guthaben abrufen“ kombinieren:
- Girokontostand abrufen
- Guthaben für Einsparungen abrufen
- Hypothekensaldo abrufen
- Guthaben abrufen
Wenn Ihr Agent-Design zu viele Seiten pro Ablauf hat, sollten Sie zusammengehörige Seiten kombinieren und viele Routen pro Seite verwenden.
Wenn Sie weiterhin Schwierigkeiten mit dem Ablauf und den Seitenlimits haben, liegt das möglicherweise daran, dass Sie zu viel Geschäftslogik in den Agenten selbst integriert haben. Erwägen Sie, diese Logik in Webhooks zu verschieben.
In den folgenden Listen wird die Granularität der Konversationssteuerung von Agent-Ressourcen in aufsteigender Reihenfolge aufgeführt:
- Agents (ein Agent bearbeitet alle Unterhaltungen)
- Abläufe (ein Ablauf behandelt ein oder mehrere zusammengehörige Unterhaltungsthemen)
- Seiten (eine Seite umfasst einen oder mehrere zusammenhängende Gesprächsbeiträge)
- Routen (eine Route verarbeitet einen Nutzer-Intent oder eine Bedingungsprüfung)
Intent-Parameter im Vergleich zu Formularparametern
Die wichtigste Methode, mit der Ihr System strukturierte Daten vom Endnutzer erhält, sind Parameter. Sie können Parameter für Absichten (Absichtsparameter) oder Seiten (Formularparameter) verwenden.
Der Hauptzweck einiger Seiten besteht darin, bestimmte Informationen vom Endnutzer zu erfassen. Beispielsweise kann eine Seite so gestaltet sein, dass die Kontaktdaten des Endnutzers erfasst werden. In diesem Fall sollten Sie immer Formularparameter verwenden, um diese Informationen zu erfassen.
In einigen Fällen kann es sinnvoll sein, Endnutzerinformationen zu erfassen, während von einer Seite zur nächsten gewechselt wird. Wenn der Endnutzer beispielsweise zu Beginn der Unterhaltung ein bestimmtes Produkt anfordert, möchten Sie das gewünschte Produkt erfassen, während Sie zur entsprechenden Bestellseite wechseln. In diesem Fall verwenden Sie Intent-Parameter als Teil von Intent-Routen.
Es gibt auch Situationen, in denen die Verwendung von Intent- und Formularparametern ideal ist. Wenn der Endnutzer beispielsweise zu Beginn des Gesprächs ein kleines T-Shirt bestellt, möchten Sie den gewünschten Größenparameter (klein) erfassen, während Sie zur Seite für die T-Shirt-Bestellung wechseln. Auf der Seite für die T-Shirt-Bestellung werden möglicherweise zusätzliche Informationen wie die gewünschte Farbe abgefragt. Die Seite für die T-Shirt-Bestellung sollte Formularparameter für Größe und Farbe enthalten. In diesem Beispiel wurde der Parameter „size“ bereits angegeben und weitergegeben. Der Agent fragt daher nur die Farbe an. Andere Unterhaltungen folgen jedoch möglicherweise einem anderen Pfad, bei dem der Endnutzer die gewünschte Größe nicht angibt, wenn die Seite für die T-Shirt-Bestellung aktiv wird. Wenn Sie diesen Parameter auf beide Arten definieren, ist Ihr Agent flexibler beim Extrahieren der Informationen.
Routen und Route-Gruppen
Wenn Sie zu einer anderen Seite wechseln, eine Antwortnachricht in die Warteschlange stellen oder einen Webhook aufrufen möchten, wenn ein Intent abgeglichen oder eine Bedingung erfüllt wird, verwenden Sie Routen.
Wenn Sie auf mehreren Seiten dieselben Routen verwenden, sollten Sie Routengruppen verwenden. So vermeiden Sie unnötige Duplikate in Ihrem Agent-Design.
Wiederverwendung von Intents
Wenn Sie mehrere Intents mit ähnlichen Trainingsformulierungen definieren, sollten Sie in Erwägung ziehen, Intents auf mehreren Seiten wiederzuverwenden. Im Idealfall definieren Sie einige Allzweck-Intents, die auf vielen Seiten verwendet werden, und einige spezifische Intents, die nur auf einer einzelnen Seite verwendet werden. So vermeiden Sie unnötige Duplikate in Ihrem Agent-Design.
Bestätigungs-Intents sollten beispielsweise in der Regel als wiederverwendbare Intents definiert werden.
Ein confirmation.yes-Intent könnte Trainingsformulierungen wie die folgenden haben:
- Ja
- Ja
- Ja
- Ok
- Ja, das möchte ich
- und ob
- absolut
- Ja, bitte
Ein confirmation.no-Intent könnte Trainingsformulierungen wie die folgenden haben:
- no
- nah
- Nein
- auf keinen Fall
- nicht für mich
- auf keinen Fall
- Nein, danke
Diese wiederverwendbaren Bestätigungs-Intents können in vielen Szenarien für Ihren Agenten verwendet werden.
In einigen Fällen sollten Sie auch spezielle Bestätigungs-Intents erstellen.
Wenn Sie beispielsweise eine Bestellung bestätigen, kann es sinnvoll sein, einen speziellen order.confirmation.yes-Intent mit Trainingsformulierungen wie den folgenden zu verwenden:
- Die Bestellung sieht gut aus.
- Ich nehme diese Bestellung an
Außerdem ein spezieller order.confirmation.no-Intent mit Trainingsformulierungen wie:
- Ich möchte diese Bestellung nicht
- Ich nehme diese Bestellung nicht an
Wenn Ihre Bestellbestätigungsseite aktiv ist, sollten Intent-Routen für alle vier Intents infrage kommen. So wird sichergestellt, dass alle allgemeinen oder spezifischen Bestätigungen des Endnutzers angemessen behandelt werden.
Standardmäßig auszuschließender Intent
Sie sollten den Standard-Intent für negative Beispiele mit Formulierungen füllen, die Ihre Endnutzer möglicherweise sagen, die aber keinem Intent in Ihrem Agent zugeordnet werden sollen.
Auftragsausführung
Es gibt viele Möglichkeiten, Fulfillment zu verwenden, um auf den Endnutzer zu reagieren. Während einer Unterhaltungsrunde kann der Agent mehrere Nachrichten an die Antwortwarteschlange anhängen. Die verkettete Warteschlange wird am Ende der Unterhaltungsrunde an den Endnutzer gesendet. In diesem Abschnitt werden die einzelnen Optionen zum Erstellen der Nachrichten beschrieben.
- Auftragsausführung für Seiteneinstieg: Diese Auftragsausführung wird aufgerufen, wenn die Seite zum ersten Mal aktiv wird.
Das ist nützlich, wenn Sie eine Nachricht benötigen, die den Zweck der Seite beschreibt und nur einmal gesagt werden soll, während die Seite aktiv ist.
Beispiel:
- Was möchtest du über dein Girokonto wissen?
- Welche Art von Produkt möchten Sie kaufen?
- Ich benötige einige Informationen zu dem Shirt, das du bestellen möchtest.
- Routen: Diese Auftragsausführung wird aufgerufen, wenn entweder eine Intent-Route oder eine Bedingungsroute mit Auftragsausführung aufgerufen wird.
Das ist nützlich, wenn Sie eine Nachricht senden möchten, die auf die Endnutzereingabe reagiert und Informationen zur Intent-Übereinstimmung, zur erfüllten Bedingung (die eine Bedingung für den Abschluss des Formulars sein kann) oder zum Übergang enthält.
Beispiel:
- Ja, Japan ist in Ihrem internationalen Tarif enthalten. (Intent-Übereinstimmung)
- Möchten Sie wirklich 300 T-Shirts kaufen? (Vergleichsbedingung erfüllt)
- Okay, dein Termin ist morgen um 7:00 Uhr. (Formular ausfüllen)
- Okay, sprechen wir jetzt über Erdferkel. (Übergang)
- Event-Handler: Diese Auftragsausführung wird aufgerufen, wenn ein Ereignis ausgelöst wird.
Das ist nützlich, wenn Sie eine Nachricht wünschen, die auf das Ereignis reagiert.
Beispiel:
- Der Wert der Aktie, die Sie kaufen möchten, ist gerade um 10 % gestiegen. (benutzerdefiniertes Ereignis)
- Kannst du das anders formulieren? (Ereignis ohne Übereinstimmung)
- Erstaufforderungen für Formulare: Diese Auftragsausführung wird aufgerufen, wenn der Agent Formulare ausfüllt.
In diesen Nachrichten sollte dem Endnutzer eine konkrete Frage gestellt werden.
Jeder Formularparameter hat eine eigene erste Aufforderung.
Beispiel:
- Welche T-Shirt-Größe möchten Sie?
- Welche Farbe soll das T-Shirt haben?
- Handler für erneute Eingabeaufforderungen für Formulare: Diese Ausführung wird aufgerufen, wenn der Agent ein Formular ausfüllt und die Auswahl des Endnutzers für den aktuellen Parameter nicht versteht.
Diese Ausführung ist nur erforderlich, wenn die Nachricht für die erneute Eingabeaufforderung von der ursprünglichen Eingabeaufforderung abweichen soll.
Wenn keine Handler für die erneute Eingabeaufforderung vorhanden sind, verwendet der Kundenservicemitarbeiter einfach die erste Eingabeaufforderung als Nachricht für die erneute Eingabeaufforderung.
Beispiel:
- Ich verstehe das nicht. Könntest du bitte eine gültige Farbe für das T-Shirt angeben?
Benennung
In diesem Abschnitt finden Sie Tipps zur Benennung von Agent-Ressourcen.
Intent-Benennung
Wenn Ihr Agent viele Intents hat, sollten Sie ein Namensschema in Betracht ziehen, mit dem Sie diese besser organisieren können. Es ist üblich, Intent-Namen mit Satzzeichen zu segmentieren, wobei die Genauigkeit von links nach rechts zunimmt. Darüber hinaus sollte ein Intent-Name die Absicht des Endnutzers für eine Unterhaltungsrunde widerspiegeln.
Es gibt viele gute Namensschemas, beispielsweise:
- phone-service.order.cancel
- phone-service.order.create
- phone-service.order.change
- tv-service.order.cancel
- tv-service.order.create
- tv-service.order.change
- account.balance.get
- account.balance.pay
- account.address.get
- account.address.update
Übergänge
Übergänge, die in Status-Handlern definiert sind, ermöglichen die Steuerung der Unterhaltung durch Ändern der aktiven Seite. In diesem Abschnitt finden Sie Tipps zur Organisation Ihrer Agent-Übergänge.
Kostenlose Übergänge
Wenn Sie eine Route definieren, die einen Übergang auslöst, sollten Sie berücksichtigen, dass es möglicherweise eine komplementäre oder inverse Route gibt.
Beispiel:
- Wenn Sie eine Intent-Route für confirmation.yes haben, sollten Sie eine weitere Route für confirmation.no definieren.
- Wenn Sie eine Bedingungsroute mit einem booleschen
=-Operator definieren, sollten Sie eine weitere Route mit!=definieren.
Endnutzereingaben verarbeiten
Dieser Abschnitt enthält Richtlinien für Intents und Trainingsformulierungen, damit Ihr Agent Endnutzereingaben optimal verarbeiten kann.
Mindestens 20 Trainingsformulierungen definieren
Sie sollten für jeden Intent mindestens 20 Trainingsformulierungen haben. Andernfalls hat das NLU-Modell möglicherweise nicht genügend Informationen, um Ihre Intention richtig zuzuordnen. Dies ist eine Mindestanforderung. Idealerweise sollten Sie mehr definieren, insbesondere für Head-Intents großer Agents, wo etwa 50 wünschenswert sind.
Intent-Bias berücksichtigen
Wenn für einen oder mehrere Intents deutlich mehr Trainingsformulierungen als für andere Intents vorhanden sind, führt dies aufgrund von unausgewogenen Daten dazu, dass das NLU-Modell die größeren Intents bevorzugt. Diese Intention kann auftreten, wenn sich die Anzahl der Trainingsformulierungen um eine Größenordnung oder mehr unterscheidet.
In einigen Fällen ist dieses Verhalten erwünscht, da Sie möglicherweise einige Intents definieren, die häufiger abgeglichen werden sollen als andere, weil sie häufiger mit Endnutzereingaben im Live-Traffic übereinstimmen.
In anderen Fällen ist dieses Verhalten möglicherweise unerwünscht, da Sie keine Bevorzugung dieser größeren Intentionen wünschen. Wenn das der Fall ist, sollten Sie die Anzahl der Trainingsformulierungen für diese größeren Intents auf die gleiche Größenordnung wie bei anderen Intents reduzieren. Beispiel:
| Trainingsformulierungen für Intent A | Trainingsformulierungen für Intent B | Bias für Intention B |
|---|---|---|
| 20 | 50 | Nein |
| 20 | 200 | Eventuell geöffnet |
| 20 | 2000 | Ja |
Verwendung von Entitäten und Anzahl der Trainingsformulierungen
Für alle Entitätstypen, die in einer Intention verwendet werden:
- Annotieren Sie jedes Beispiel für die Entitätstypen.
- Geben Sie für jeden Entitätstyp mindestens fünf Trainingsformulierungen mit annotierten Beispielen an.
- Geben Sie mindestens dreimal so viele Trainingsformulierungen wie Entitätstypen an. Wenn Sie beispielsweise 10 verschiedene Entitätstypen für Anmerkungen in einem Intent verwenden, sollten Sie mindestens 30 Trainingsformulierungen haben.
Trainingsformulierungen sollten natürlich klingen
Trainingsformulierungen sollten dialogorientiert und natürlich sein und dem entsprechen, was Nutzer tatsächlich sagen. Verwenden Sie nach Möglichkeit Endnutzereingaben, die in der Produktion erfolgt sind, als Trainingsdaten und achten Sie besonders auf die häufigsten.
Erforderliche Vielfalt bei Trainingsformulierungen
Fügen Sie Variationen von Fragen, Befehlen und Verben sowie Synonyme für häufig verwendete Substantive hinzu, damit Ihre Formulierungen ein breites Spektrum möglicher Anfragen abdecken.
Es ist am besten, sowohl kurze Formulierungen wie „Rechnung bezahlen“ als auch längere Formulierungen und Sätze wie „Ich habe gerade etwas per Post erhalten, in dem steht, dass ich meinen Kontoauszug bezahlen muss“ zu verwenden. Es gibt kein empfohlenes Verhältnis von kurzen zu langen Wortgruppen. Sie sollten sich jedoch an den tatsächlichen Endnutzereingaben orientieren, die in der Produktion an Ihren Agent gesendet werden.
Es ist wichtig, Trainingsformulierungen zu definieren, die sich in Länge, Formulierung und Satzstruktur unterscheiden, damit Ihr Agent gut trainiert wird. Es ist nicht notwendig, Vielfalt um der Vielfalt willen hinzuzufügen, aber es ist notwendig, genügend Vielfalt zu bieten, damit das NLU-Modell die Absicht des Endnutzers aus einer Vielzahl von Endnutzereingaben erfolgreich erkennen kann. Wenn Sie nicht genügend Vielfalt haben, besteht die Gefahr einer Überanpassung. Mit anderen Worten: Es besteht die Gefahr, dass das Modell zu eng an die von Ihnen bereitgestellten Beispiele gebunden ist und nicht ausreichend auf andere Beispiele verallgemeinert wird.
Vielfalt bei der Großschreibung
Die Groß- und Kleinschreibung wird je nach NLU-Modell Ihres Agents unterschiedlich berücksichtigt.
Standard-NLU
Beim Standard-NLU-Modell wird die Groß-/Kleinschreibung nicht berücksichtigt. In seltenen Fällen müssen Sie Trainingsformulierungen hinzufügen, die sich nur in der Groß- und Kleinschreibung unterscheiden. Das ist in der Regel der Fall, wenn Sie erwarten, dass Endnutzer Texteingaben in Großbuchstaben machen.
Alternative Ansätze könnten sein:
- ML-Klassifizierungsschwellenwert senken
- Endnutzereingaben werden in Kleinbuchstaben umgewandelt, bevor sie an Dialogflow CX gesendet werden.
Erweiterte NLU
Im Gegensatz zum Standard-NLU-Modell wird beim erweiterten NLU-Modell zwischen Groß- und Kleinschreibung unterschieden. Wir empfehlen, die relevanten in Großbuchstaben geschriebenen Trainingsdaten zu testen und hinzuzufügen, um die Abgleichsraten für Intentionen zu erhöhen.
Unnötige Vielfalt bei Trainingsformulierungen
Vermeiden Sie triviale Variationen bei Trainingsformulierungen, da sie dem NLU-Modell doppelte Informationen liefern. Nehmen Sie beispielsweise keine Varianten auf, die sich nur durch Folgendes unterscheiden:
- Groß- und Kleinschreibung: Wenn Sie das Standard-NLU-Modell verwenden, vermeiden Sie doppelte Formulierungen wie „außer ‚Bestelle ein Ticket‘“ und „außer ‚bestelle ein Ticket‘“, es sei denn, es handelt sich um seltene Fälle. Das erweiterte NLU-Modell unterscheidet jedoch zwischen Groß- und Kleinschreibung und erfordert mehr Trainingsformulierungen, um die Anzahl der Intent-Übereinstimmungen zu erhöhen. Weitere Informationen finden Sie im Abschnitt Groß- und Kleinschreibung.
- Füllwörter: Beispiel: „Okay, bestelle ein Ticket“ und „Bestelle ein Ticket“.
- Satzzeichen: Beispiele: „Kannst du mir bitte helfen?“ und „Kannst du mir bitte helfen?!“
Konsistenz der Anmerkungen
Der für eine Anmerkung ausgewählte Teil der Trainingsformulierung sollte genau den Text enthalten, der zur Übereinstimmung mit einer Entität erforderlich ist, also weder mehr noch weniger Wörter. Außerdem sollten ähnliche Teile von Trainingsformulierungen für den gesamten Intent annotiert werden.
In der folgenden Tabelle sehen Sie beispielsweise gute und schlechte Möglichkeiten, Anmerkungen mit der Systementität @sys.date zu versehen:
| Gut | Fehlerhaft |
|---|---|
| Abreise am 7. September | Abfahrt am 7. September |
| Abreise am 4. Juli | Am 4. Juli verlassen |
Semantisch sinnvolle Anmerkungen für Systementitäten verwenden
Die semantische Bedeutung eines Teils einer Trainingsformulierung, der für eine Annotation ausgewählt wurde, kann durch den restlichen Text in der Trainingsformulierung beeinflusst werden. Beispiel:
| Trainingsformulierung mit Anmerkungen | Semantische Bedeutung von annotiertem Text |
|---|---|
| Ich bin 7 Jahre alt. | Das Alter einer Person |
| Der Vertrag ist 7 Jahre lang gültig. | Eine Zeitdauer |
Die Modelle für maschinelles Lernen von Dialogflow CX berücksichtigen die semantische Bedeutung beim Abgleich von Systementitäten. Die semantische Bedeutung des Teils der Trainingsformulierung muss der beabsichtigten semantischen Bedeutung der Systementität entsprechen.
Verwenden Sie beispielsweise nicht die Systementität @sys.duration für die Annotation des ersten Beispiels „7 Jahre“ oben.
Die semantische Bedeutung von „7 Jahre“ entspricht keiner einfachen Zeitdauer.
Wählen Sie stattdessen „7“ für die Anmerkung aus und verwenden Sie die Systementität @sys.number.
Intents definieren, um Antworten zu verarbeiten, die nicht den Richtlinien entsprechen
Sie können Intentionen definieren, um Antworten zu verarbeiten, die nicht den Richtlinien entsprechen. Ihr Agent könnte beispielsweise fragen: „Wann reisen Sie?“, worauf der Endnutzer antwortet: „Das weiß ich noch nicht.“ Diese Antwort entspricht nicht dem Prompt für den Formularparameter. Wenn Ihr Agent jedoch einen Intent-Pfad hat, der dieser Antwort entspricht, kann er die Situation gut bewältigen.
@sys.any vermeiden
Vermeiden Sie die Verwendung des Systementitätstyps @sys.any.
Sie sollte nur verwendet werden, wenn Sie alle Möglichkeiten ausgeschöpft haben, einschließlich der Erstellung benutzerdefinierter Entitäten.
Dieser Entitätstyp ist sehr allgemein und kann zu unerwünschtem Verhalten führen.
Wenn Sie diesen Entitätstyp verwenden, sollten Sie nicht mehrere Teile einer einzelnen Trainingsformulierung damit annotieren, da dies zu Unklarheiten führt und das Verhalten des Agents nicht definiert ist.
Die Verwendung von @sys.any mit Formularparametern ist weniger gefährlich, da der Agent beim Auffordern von Formularparametern bestimmte Informationen erwartet.
Anmerkungen sollten eine Vielzahl von Entitätswerten enthalten
Wenn Sie annotierte Trainingsformulierungen definieren, sollten Sie eine Vielzahl von Beispielen für Entitätswerte in den Formulierungen verwenden. Sie sollten nicht immer dasselbe Beispiel für die Annotationen verwenden. Im folgenden Beispiel sehen Sie gute und schlechte Anmerkungen für einen Produktentitätstyp:
| Gut | Fehlerhaft |
|---|---|
| Ich möchte ein Hemd kaufen | Ich möchte ein Hemd kaufen |
| Neuen Hut bestellen | Ein neues T-Shirt bestellen |
| Lege eine Smartwatch in meinen Einkaufswagen. | Leg ein Hemd in meinen Einkaufswagen. |
Benutzerdefinierte Entitäten sollten vielfältig sein
Benutzerdefinierte Entitäten sollten eine Vielzahl von Beispielen abdecken. Das NLU-Modell sorgt für eine Vielfalt an grammatischen Formen, aber Sie müssen alle möglichen Elemente einschließen.
Aggressiv übereinstimmende Entitäten vermeiden
Definieren Sie keine Entitäten, die praktisch allgemeingültig sind. Das beeinträchtigt die Leistung und Qualität von ML. Fast alles in jeder Trainingsformulierung wird sonst als mögliche Übereinstimmung gewertet.
Karten- und Listenentitäten sollten sich auf eindeutige Werte konzentrieren
Entitätstypen für Karten und Listen sollten einen begrenzten Umfang haben, der unterschiedliche Werte eines Informationstyps erfasst. Halten Sie Ihre Entitäten prägnant, kurz und einfach.
Wenn Ihre Entitätswerte kompliziert sind, kann es daran liegen, dass Trainingsformulierungen für Intents besser auf Ihre Situation zugeschnitten sind. Hier ein Beispiel für eine Endnutzereingabe:
- „Wie kann ich mit Tarif A ein Auslandsgespräch führen?“
- „Daten-Roaming im Ausland zu Tarif B verwenden.“
Erstellen Sie nicht Entitätstypen sowohl für die Aktionen als auch für die Tarife, wie im Folgenden:
| Entitätstyp „Aktionen“ | Entitätstyp „Tarife“ |
|---|---|
| „Wie kann ich ein Auslandsgespräch führen?“ | „Plan A“ |
| „Daten-Roaming im Ausland verwenden“ | „Plan B“ |
Verwenden Sie stattdessen Trainingsformulierungen und Intent-Abgleich, um die Aktionen zu erfassen, und Entitäten, um die Tarife zu erfassen.
RegExp-Entitäten verwenden, um Kennzeichnungen zu erfassen, die keine Wörter sind
Wenn Sie Endnutzereingaben erfassen, die keine Wortkennzeichnungen enthalten, sollten Sie RegExp-Entitäten verwenden. Wenn Sie beispielsweise Produkt-IDs wie „AA-256“ oder „AC-436“ erfassen möchten, verwenden Sie eine reguläre Ausdrucksentität wie „[A-Z]{2}-\d{3}“.
Verschachteln Sie zusammengesetzte Entitäten nicht.
Verwenden Sie in zusammengesetzten Entitäten nicht mehr als eine Verschachtelungsebene. Jede Verschachtelungsebene beeinträchtigt die Qualität erheblich.
Ähnliche Intents vermeiden
Jeder Intent sollte die Absicht des Endnutzers erfassen. Wenn Sie verschiedene Intents mit ähnlichen Trainingsformulierungen definieren, ist die Zuordnung möglicherweise unzuverlässig, da das NLU-Modell nicht mit ausreichender Sicherheit bestimmen kann, welcher Intent zugeordnet werden soll.
Wenn zwei Trainingsformulierungen dieselbe Intention repräsentieren, sollten sie zum selben Intent gehören. Beispiel: „change current bill due date“ (Ändere das aktuelle Rechnungsdatum) und „more time to pay“ (Mehr Zeit zum Bezahlen) sollten beide zur selben Intention gehören, da in beiden Fällen eine Änderung des Fälligkeitsdatums angefragt wird. „Kann ich mit Tarif A ein Auslandsgespräch führen?“ und „Kann ich mit Tarif A Daten-Roaming im Ausland verwenden?“ könnten jedoch zu unterschiedlichen Intents gehören, da der Endnutzer in jedem Fall etwas anderes möchte.
Ähnliche Entitätstypen vermeiden
Sie sollten nicht mehrere Entitätstypen mit ähnlichen Entitätseinträgen definieren, da dies zu Unklarheiten für das NLU-Modell führen kann.
Ereignisse ohne Übereinstimmung in der Produktion verwenden, um Ihre Intents zu verbessern
Wenn Sie Ihren Agent in der Produktion ausführen, ist es unvermeidlich, dass einige Endnutzereingaben zu Ereignissen ohne Übereinstimmung führen. Sie haben drei Möglichkeiten, Ihren Agenten zu verbessern:
- Fügen Sie die Endnutzereingabe dem gewünschten Intent als Trainingsformulierung hinzu. Das ist jedoch nicht immer die beste Option. Wenn Sie dies mehrmals für den Intent tun, kann dies zu einer Intent-Voreingenommenheit führen.
- Bereinigen Sie die Trainingsformulierungen für den gewünschten Intent, damit sie alle die Intention genau widerspiegeln. In einigen Fällen kann es vorkommen, dass Intents mit Trainingsformulierungen, die sich stark unterscheiden, nicht zugeordnet werden.
- Wenn Intents, die nicht mit der Endnutzereingabe übereinstimmen sollen, Trainingsformulierungen enthalten, die mit der Endnutzereingabe übereinstimmen könnten, löschen Sie diese Trainingsformulierungen.
Sonderzeichen vermeiden
Sonderzeichen in Trainingsformulierungen ({, _, #, [ usw.) werden ignoriert.
Eine Ausnahme bilden Emoticons, die wie erwartet funktionieren.
Füllwörter vermeiden
Füllwörter sind Wörter, die Sie ignorieren können und den Text trotzdem verstehen. Beispiel:
- gefallen
- kannst du bitte
- hmmm
- wie wäre es mit
Es ist unnötig, aber harmlos, Füllwörter in Trainingsformulierungen zu verwenden, da diese vom NLU-Modell ignoriert werden. Sie sollten jedoch keine Trainingsformulierungen definieren, die sich nur durch Füllwörter unterscheiden.
Definieren Sie niemals Entitäten, die aus Füllwörtern bestehen.
Mit ML-Einstellungen experimentieren
Mit den ML-Einstellungen können Sie anpassen, wie Endnutzereingaben verarbeitet werden. In den meisten Fällen funktionieren die Standardeinstellungen gut. Möglicherweise möchten Sie die Einstellungen jedoch optimieren, um die Leistung Ihres Agents zu verbessern.
Auf den Endnutzer reagieren
In diesem Abschnitt finden Sie Richtlinien für die Verwendung der Auftragsausführung, um auf den Endnutzer zu reagieren.
Endnutzer begrüßen
Für einen neu erstellten Agent wird automatisch eine Intent-Route für den Begrüßungs-Intent erstellt. Sie sollten diese Route bearbeiten, um eine Erfüllungsnachricht einzufügen, mit der der Endnutzer begrüßt wird. In dieser Nachricht sollte der Agent beschrieben werden und der Endnutzer sollte erfahren, was er kann.
Endnutzerinformationen bestätigen
Es ist oft am besten, in Antworten die vom Endnutzer bereitgestellten Informationen zu wiederholen. So weiß der Endnutzer, dass der Agent seine Anfrage versteht.
Wenn ein Intent zugeordnet wird und ein Übergang erfolgt, informieren Sie den Endnutzer darüber, dass die Unterhaltung auf seiner Anfrage basiert. Beispiel:
| Dialog | Beschreibung |
|---|---|
| Endnutzer: I have questions about my checking account. Agent: Okay, what would you like to know about your checking account? |
Die Endnutzereingabe hat zu einer Intent-Übereinstimmung geführt und es wurde eine Route verfolgt, die eine Fulfillment-Nachricht und einen Übergang zu einer Seite enthielt, auf der Fragen zum Girokonto beantwortet werden. Der Kundenservicemitarbeiter bestätigt, dass der Endnutzer Informationen zu seinem Girokonto erhalten möchte. |
Wiederholen Sie nach dem Ausfüllen des Formulars die vom Endnutzer angegebenen Daten. Beispiel:
| Dialog | Beschreibung |
|---|---|
| Endnutzer: Morgen Agent: Okay, dein Haarschnitt ist für morgen um 19:00 Uhr geplant. Kann ich dir sonst noch bei etwas weiterhelfen? |
Der Endnutzer hat den Formularparameter „Datum“ angegeben. Das war der letzte Formularparameter auf der aktiven Seite. Der Kundenservicemitarbeiter hat die Uhrzeit und das Datum eines geplanten Haarschnitts bestätigt. |
Gespräch leiten
Der Agent sollte die Unterhaltung mit dem Endnutzer immer steuern. Das ist ganz einfach, wenn Sie jede Antwort mit einer Frage beenden, z. B.:
- Kann ich dir sonst noch bei etwas weiterhelfen?
- Was möchtest du über Beagles wissen?
- Möchten Sie diese Bestellung stornieren oder aufgeben?
- Wobei kann ich Ihnen helfen?
- Reisen Sie allein oder mit einer anderen Person?
Achten Sie beim Definieren dieser Fragen darauf, nicht mehrere Fragen zu stellen, z. B.:
- Sind Sie noch da? Auf welche Dienstleistung bezieht sich Ihre Anfrage?
- Möchten Sie diese Bestellung trotzdem aufgeben? Möchten Sie noch etwas hinzufügen?
Der Endnutzer antwortet möglicherweise nur auf eine der Fragen und Ihr Agent kann diese Situation möglicherweise nicht richtig verarbeiten.
Fehler und unerwartete Endnutzereingaben verarbeiten
In diesem Abschnitt finden Sie Tipps zum Umgang mit Fehlern und unerwarteten Endnutzereingaben.
Event-Handler für integrierte Ereignisse erstellen
Sie sollten Event-Handler für die eingebundenen Ereignisse erstellen, sofern zutreffend. Die Verarbeitung dieser Ereignisse ähnelt dem Abfangen von Ausnahmen in der Softwareprogrammierung. Je nach Situation sollten Sie die Ereignisse mit parameterspezifischen, seitenbezogenen oder ablaufbezogenen Event-Handlern verarbeiten.
Webhook-Fehler behandeln
Wenn Ihr Webhook-Dienst fehlschlägt, ist es wichtig, dass Ihr Agent den Fehler ordnungsgemäß verarbeiten kann. Dazu definieren Sie Event-Handler für die Webhook-spezifischen integrierten Ereignisse. So gehen Sie am besten vor, wenn Webhook-Fehler auftreten:
- Geben Sie kein Umstellungsziel aus dem Status-Handler an, der den Webhook-Aufruf auslöst. Andernfalls wird der Webhook-Fehler-Event-Handler nicht aufgerufen. Legen Sie stattdessen das Übergangsziel in der Webhook-Antwort des Webhook-Dienstes fest.
Wählen Sie eine Seite aus, auf der ein Fehlerzähler auf null gesetzt werden kann. Diese Seite sollte aktiv sein, bevor die Seite, die einen Webhook-Aufruf auslöst, aktiv ist. Die Auftragsausführung für den Einstieg auf dieser Seite sollte den Fehlerzähler mit einer Voreinstellung für den Auftragsausführungsparameter auf
0initialisieren. Beispiel:Parameter Wert webhook-error-count0Erstellen Sie eine Webhook-Fehlerseite, auf der Webhook-Fehlerereignisse verarbeitet werden:
Bei der Auftragsausführung für den Eintrag sollte der Fehler für den Endnutzer bestätigt werden. Außerdem sollte ein Sitzungsparameter für den Fehlerzähler mithilfe einer Voreinstellung für den Auftragsausführungsparameter erhöht werden. Beispiel:
Parameter Wert webhook-error-count$sys.func.ADD($session.params.webhook-error-count, 1)Definieren Sie eine Bedingungsroute mit einer Bedingung, dass die Anzahl der Fehler kleiner als die maximal zulässige Anzahl ist. z. B.
$session.params.webhook-error-count <= 3. Diese Route sollte eine Auftragsausführung haben, die den Endnutzer darüber informiert, dass der Agent es noch einmal versuchen wird. Für diese Route sollte ein Übergangsziel auf PREVIOUS_PAGE oder auf eine beliebige Seite festgelegt sein, auf der ein weiterer Versuch unternommen werden kann, den Webhook aufzurufen.Definieren Sie einen bedingten Pfad mit einer Bedingung, dass die Anzahl der Fehler größer als das maximal zulässige ist (z. B.
$session.params.webhook-error-count > 3). Dieser Pfad sollte eine Ausführung haben, die den Endnutzer darüber informiert, dass der Kundenservicemitarbeiter keine weiteren Versuche unternimmt. Für diese Route sollte ein Übergangsziel auf eine Seite festgelegt sein, die keine Webhook-Wiederholungen auslöst.
Der Webhook-Ereignishandler sollte ein Umstellungsziel haben, das zur Webhook-Fehlerseite führt.
Tools
In diesem Abschnitt finden Sie Tipps zur Verwendung von Tools zur Verbesserung des Agent-Designs.
Validierungstool verwenden
Sie sollten immer das Validierungstool verwenden, um Ihren Agent zu prüfen. Mit diesem Tool lassen sich einige der in diesem Leitfaden beschriebenen Probleme finden.
Funktion für Testläufe verwenden
Sie sollten immer Testläufe für Ihren Agenten definieren. Diese Testläufe können helfen, Regressionen zu verhindern, während Ihr Agent weiterentwickelt wird, um mehr Szenarien zu bewältigen.