Allgemeine Best Practices für das Design von Agents

Dieser Leitfaden enthält allgemeine Best Practices für die Entwicklung aller Arten von Agents.

Weitere Informationen finden Sie auch im Leitfaden zur Entwicklung von Sprach-Agents und in den Best Practices für die Verwendung des Dialogflow-Dienstes.

Allgemeine Empfehlung

Agents iterativ entwickeln

Wenn der Agent groß oder komplex ist, erstellen Sie zuerst einen Dialog, in dem nur Anfragen der obersten Ebene behandelt werden. Sobald die Grundstruktur festgelegt ist, iterieren Sie die Unterhaltungspfade, um sicherzustellen, dass Sie alle möglichen Routen abdecken, die ein Endnutzer nehmen kann.

Während sich der Agent weiterentwickelt, können Sie für die testgesteuerte Entwicklung die Testlauffunktion verwenden.

Vordefinierte Agents

Dialogflow 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 die Auftragsausführung hinzu, um schnell einen funktionierenden Agent zu erstellen.

Integrationen und Verknüpfung Ihrer Dienste

Es gibt mehrere Möglichkeiten, Dialogflow-Agents einzubinden. In diesem Abschnitt finden Sie Best Practices zur Auswahl der Einbindung.

Integrationen

Die Integrationen von Dialogflow bieten eine einsatzbereite Benutzeroberfläche für Ihren Agent. Wenn Sie eine Integration verwenden, müssen Sie die Dialogflow API nicht direkt aufrufen, da dies für Sie erledigt wird. Diese Integrationen können einen Text-Agent bereitstellen, den Sie auf Ihrer Website einbetten, mit anderen Messaging-Plattformen verbinden oder eine Telefonieschnittstelle bereitstellen können.

Dialogflow API

Wenn keine der gebrauchsfertigen Integrationen geeignet ist oder Sie die Schnittstelle für Ihr System anpassen möchten, können Sie die Dialogflow API direkt verwenden. Bei diesem Ansatz müssen Sie die Benutzeroberfläche für Ihren Agent implementieren oder eine vorhandene 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 API verwenden.

Agent-Ressourcen

Die Ressourcen des Dialogflow-Agents können auf viele verschiedene Arten verwendet werden, um ein gewünschtes Ergebnis zu erzielen. Dieser Abschnitt enthält Ratschläge zur Auswahl der richtigen Ressourcen für die richtigen Szenarien.

Abläufe und Seiten

Abläufe und Seiten geben dem Agent Struktur. Sie können sich Seiten als Knoten in einem Zustandsautomaten und Abläufe als Gruppen verwandter Seiten vorstellen. Übergänge zwischen Knoten steuern Sie mit Zustands-Handlern. Diese werden aufgerufen, wenn ein Intent zugeordnet, eine Bedingung erfüllt oder ein Ereignis aufgerufen wird.

Ein einfacher Agent kann bei einem einzelnen Ablauf gut funktionieren. Komplexe Agents sind jedoch fast immer besser für mehrere Abläufe geeignet. Jeder Ablauf sollte ein übergeordnetes Thema für Ihren Agent darstellen, wobei jede mit dem Ablauf verknüpfte Seite zur Verarbeitung des Themas beiträgt. Darüber hinaus kann jeder Ablauf eigene Einstellungen haben und einer Teilmenge von Teammitgliedern zugewiesen sein. Dies hilft, die Arbeit beim Entwerfen großer Agents aufzuteilen.

Beim Entwerfen eines großen, komplexen Agents müssen Sie die Limits"Abläufe pro Agent" und "Seiten pro Ablauf" berücksichtigen. Diese Limits tragen zu einer konstanten Leistung des Agents bei.

Wenn Ihr Agent-Design zu viele Abläufe pro Agent hat, können Sie verwandte Themen in einem einzigen Ablauf kombinieren. Beispielsweise können Sie die folgenden Themen zu einem einzigen Ablauf für das Abrufen des Ausgleichs kombinieren:

• Girokonto abrufen
• Sparguthaben erhalten
• Hypothekensaldo abrufen
• Guthaben abrufen

Wenn das Agent-Design zu viele Seiten pro Ablauf hat, kombinieren Sie ähnliche Seiten und nutzen Sie viele Routen pro Seite.

Wenn Sie immer noch Probleme mit Ablauf- und Seitenlimits haben, ist möglicherweise zu viel Geschäftslogik in den Agent selbst integriert. Ziehen Sie in Betracht, diese Logik auf Webhooks zu übertragen.

Im Folgenden wird der Detaillierungsgrad der Unterhaltungssteuerung von Agent-Ressourcen in aufsteigender Reihenfolge aufgeführt:

1. Agents (ein Kundenservicemitarbeiter kümmert sich um alle Unterhaltungen)
2. Abläufe (ein Ablauf behandelt ein oder mehrere verwandte Unterhaltungsthemen)
3. Seiten (eine Seite behandelt eine oder mehrere zusammengehörige Unterhaltungsrunden)
4. Routen (eine Route verarbeitet eine Nutzer-Intent- oder Bedingungsprüfung)

Intent- und Formularparameter im Vergleich

Ihr System erhält hauptsächlich mithilfe von Parametern strukturierte Daten vom Endnutzer. Sie können Parameter entweder für Intents (Intent-Parameter) oder Seiten (Formularparameter) verwenden.

Manche Seiten dienen hauptsächlich dazu, bestimmte Informationen von Endnutzern zu erheben. Beispielsweise kann eine Seite so gestaltet sein, dass sie die Kontaktdaten des Endnutzers erfasst. In diesem Fall sollten Sie zum Erfassen dieser Informationen immer Formularparameter verwenden.

In einigen Fällen möchten Sie möglicherweise Endnutzerinformationen erfassen, während Sie von einer Seite zu einer anderen wechseln. 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. Verwenden Sie in diesem Fall Intent-Parameter als Teil von Intent-Routen.

Es gibt auch Situationen, in denen sowohl Intent- als auch Formularparameter ideal sind. Wenn der Endnutzer beispielsweise zu Beginn der Unterhaltung ein T-Shirt in Größe S anfordert, möchten Sie den gewünschten Größenparameter (S) erfassen, während Sie zur Seite mit der Hemdenbestellung wechseln. Auf der Seite für die T-Shirt-Bestellung werden eventuell zusätzliche Informationen abgefragt, z. B. die gewünschte Farbe. Die Seite zur Bestellung von T-Shirts sollte Formularparameter für Größe und Farbe enthalten. In diesem Beispiel wurde der Größenparameter bereits angegeben und übertragen, sodass der Agent nur die Farbe anfordert. Andere Unterhaltungen können jedoch einem anderen Pfad folgen, bei dem der Endnutzer nicht die gewünschte Größe angegeben hat, wenn die Seite mit der T-Shirt-Bestellung aktiv wird. Wenn Sie diesen Parameter auf beide Arten definieren, kann der Agent die Informationen flexibler extrahieren.

Routen und Routengruppen

Wenn Sie zu einer anderen Seite wechseln, eine Antwortnachricht in die Warteschlange stellen oder einen Webhook aufrufen möchten, wenn ein Intent übereinstimmt oder eine Bedingung erfüllt ist, verwenden Sie Routen.

Wenn Sie denselben Satz von Routen auf mehreren Seiten verwenden, verwenden Sie Routengruppen. So vermeiden Sie unnötige Duplikate im Agent-Design.

Intent-Wiederverwendung

Wenn Sie mehrere Intents mit ähnlichen Trainingsformulierungen definieren müssen, empfiehlt es sich, Intents für mehrere Seiten wiederzuverwenden. Idealerweise sollten Sie einige allgemeine Intents definieren, die auf vielen Seiten verwendet werden, und bestimmte Intents, die nur auf einer einzelnen Seite verwendet werden. So vermeiden Sie unnötige Duplikate im Agent-Design.

Bestätigungs-Intents sind beispielsweise wiederverwendbare Intents. Ein confirmation.yes-Intent könnte folgende Trainingsformulierungen enthalten:

• yes
• ja
• Ja
• Ok
• ja, tue ich
• ganz sicher
• absolut
• Ja, bitte

Ein confirmation.no-Intent könnte folgende Trainingsformulierungen enthalten:

• no
• nah
• nö
• auf keinen Fall
• nicht für mich
• absolut nicht
• nein danke

Diese wiederverwendbaren Bestätigungs-Intents können in vielen Szenarien für Ihren Agent verwendet werden.

In einigen Fällen sollten Sie auch spezielle Bestätigungs-Intents erstellen. Wenn Sie beispielsweise eine Bestellung bestätigen, möchten Sie möglicherweise einen speziellen order.confirmation.yes-Intent mit Trainingsformulierungen wie den folgenden haben:

• die Bestellung sieht gut aus
• Ich akzeptiere diese Bestellung

Ein spezieller order.confirmation.no-Intent mit Trainingsformulierungen wie:

• Ich möchte diese Bestellung nicht haben
• Ich akzeptiere diese Bestellung nicht.

Wenn die Bestellbestätigungsseite aktiv ist, sollten die Intent-Routen für alle vier Intents enthalten sein. Dadurch wird sichergestellt, dass jede allgemeine oder spezifische Bestätigung des Endnutzers ordnungsgemäß verarbeitet wird.

Standardmäßig auszuschließender Intent

Sie sollten den standardmäßigen negativen Intent mit Wortgruppen füllen, die Ihre Endnutzer möglicherweise sagen, die jedoch keinem Intent in Ihrem Agent entsprechen sollten.

Fulfillment

Es gibt viele Möglichkeiten, die Auftragsausführung zu verwenden, um dem Endnutzer zu antworten. Während einer Unterhaltungsrunde kann der Agent mehrere Nachrichten an die Antwortwarteschlange anhängen. Die verkettete Warteschlange wird dann am Ende der Unterhaltungsrunde an den Endnutzer gesendet. In diesem Abschnitt werden die einzelnen Optionen zum Erstellen der einzelnen Nachrichten beschrieben.

• Auftragsausführung: Diese Auftragsausführung wird aufgerufen, wenn die Seite erstmals aktiv wird. Dies ist nützlich, wenn Sie eine Nachricht erhalten möchten, in der der Zweck der Seite beschrieben wird, und die nur einmal gesagt werden sollte, während die Seite aktiv ist. Beispiel:
  • Was möchten Sie über Ihr Girokonto wissen?
  • Welche Art von Produkt möchten Sie kaufen?
  • Ich brauche ein paar Informationen zu dem T-Shirt, das Sie bestellen möchten.
• Routen: Diese Auftragsausführung wird aufgerufen, wenn entweder eine Intent-Route oder eine Bedingungsroute mit Auftragsausführung aufgerufen wird. Dies ist nützlich, wenn Sie eine Nachricht benötigen, die dem Endnutzer über die Intent-Zuordnung, die erfüllte Bedingung (die eine Bedingung für das Ausfüllen von Formularen sein kann) oder den Übergang antwortet. Beispiel:
  • Ja, Ihr internationaler Tarif umfasst Japan. (Intent-Übereinstimmung)
  • Möchten Sie wirklich 300 T-Shirts kaufen? (Vergleichsbedingung erfüllt)
  • Ok, dein Termin ist morgen früh um 07:00 Uhr. (Ausfüllen des Formulars)
  • Okay, sprechen wir jetzt über Erdferkel. (Übergang)
• Event-Handler: Diese Auftragsausführung wird beim Aufrufen eines Ereignisses aufgerufen. Dies ist nützlich, wenn Sie eine Nachricht benötigen, die auf den Termin reagiert. Beispiel:
  • Der Wert der Aktie, die Sie kaufen möchten, ist gerade um 10 % gestiegen. (benutzerdefiniertes Ereignis)
  • Kannst du das umformulieren? (Ereignis ohne Übereinstimmung)
• Erste Aufforderungen für Formulare: Diese Auftragsausführung wird aufgerufen, wenn der Agent das Formular ausfüllt. In diesen Nachrichten sollte dem Endnutzer eine spezifische Frage gestellt werden. Jeder Formularparameter hat eine eigene anfängliche Eingabeaufforderungsausführung. Beispiel:
  • Welche Größe möchten Sie?
  • Welche Farbe möchten Sie haben?
• Reprompt-Handler für Formulare: Diese Auftragsausführung wird aufgerufen, wenn der Agent das Formular ausfüllt und die Endnutzerauswahl für den aktuellen Parameter nicht versteht. Diese Auftragsausführung ist nur erforderlich, wenn sich eine Meldung der Aufforderung von der ursprünglichen Nachricht unterscheiden soll. Wenn keine Handler für die Eingabeaufforderung vorhanden sind, verwendet der Agent einfach die anfängliche Eingabeaufforderung als Meldung der Aufforderung. Beispiel:
  • Das verstehe ich nicht. Bitte geben Sie eine gültige Farbe für das Hemd an.

Benennung

Dieser Abschnitt enthält Hinweise zum Benennen von Agent-Ressourcen.

Intent-Benennung

Wenn Ihr Agent viele Intents hat, sollten Sie ein Benennungsschema 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

Mit in Status-Handlern definierten Übergängen können Sie die Unterhaltung steuern, indem Sie die aktive Seite ändern. Dieser Abschnitt enthält Hinweise zur Organisation der Agent-Umstellungen.

Kostenlose Umstellungen

Berücksichtigen Sie beim Definieren einer Route, die einen Übergang auslöst, dass es eine komplementäre oder umgekehrte Route geben kann.

Beispiel:

• Wenn Sie eine Intent-Route für confirmation.yes haben, können Sie eine andere Route für confirmation.no definieren.
• Wenn Sie eine Bedingungsroute mit einem booleschen =-Operator definieren, können Sie eine andere Route mit != definieren.

Endnutzereingaben verarbeiten

Dieser Abschnitt enthält Richtlinien für Intents und Trainingsformulierungen, damit Ihr Agent Endnutzereingaben optimal verarbeiten und 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 Ihren Intent entsprechend abzugleichen. Dies ist nur eine minimale Richtlinie. Idealerweise sollten Sie mehr definieren, insbesondere für Head-Intents großer Agents, bei denen etwa 50 wünschenswert sind.

Absichtsverzerrungen erkennen

Wenn ein oder mehrere Intents deutlich mehr Trainingsformulierungen als andere Intents haben, führt das dazu, dass das NLU-Modell aufgrund von unausgewogenen Daten zugunsten der größeren Intents gewichtet. Diese Intent-Verzerrung kann auftreten, wenn die Anzahl der Trainingsformulierungen um eine Größenordnung oder mehr variiert.

In einigen Fällen ist dies das gewünschte Verhalten, da Sie möglicherweise einige Intents definieren, die häufiger abgeglichen werden sollten als andere, da sie Endnutzereingaben entsprechen, die im Live-Traffic häufiger beobachtet werden.

In anderen Fällen kann dieses Verhalten unerwünscht sein, da Sie keine Voreingenommenheit zugunsten dieser übergeordneten Intents wünschen. Reduzieren Sie in diesem Fall die Anzahl der Trainingswortgruppen für diese größeren Intents, damit sie die gleiche Größenordnung wie andere Intents haben. Beispiel:

Trainingsformulierungen für Intent A	Trainingsformulierungen für Intent B	Verzerrung für Intent B
20	50	Nein
20	200	Grenzwertig
20	2000	Ja

Entitätsnutzung und Anzahl der Trainingsformulierungen

Für alle Entitätstypen, die in einem Intent 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 Annotationen in einem Intent verwenden, sollten Sie mindestens 30 Trainingsformulierungen haben.

Trainingsformulierungen sollten natürlich sein

Trainingsformulierungen sollten dialogorientiert und natürlich sein und dem entsprechen, was die Teilnehmenden tatsächlich sagen. Verwenden Sie nach Möglichkeit Endnutzereingaben aus der Produktion als Trainingsdaten und achten Sie dabei besonders auf die am häufigsten verwendeten.

Erforderliche Vielfalt der Trainingsformulierungen

Fügen Sie Varianten von Fragen, Befehlen, Verben und Synonyme für gängige Substantive hinzu, damit Ihre Formulierungen ein breites Spektrum möglicher Anfragen abdecken.

Am besten verwenden Sie kürzere Formulierungen wie „Zahle meine Rechnung“ sowie längere Formulierungen und Sätze wie „Ich habe gerade eine E-Mail mit dem Hinweis „Ich muss meine Rechnung bezahlen“ erhalten“. Es wird kein Anteil von kurzen zu langen Sätzen empfohlen. Sie sollten jedoch auf den tatsächlichen Endnutzereingaben basieren, die in der Produktion an den Agent gesendet werden.

Das Definieren von Trainingsformulierungen, die sich in Länge, Formulierung und Satzstruktur unterscheiden, ist wichtig, um ein gutes Training für den Agent zu gewährleisten. Abwechslung ist aus Gründen der Vielfalt nicht erforderlich, aber sie muss so vielfältig sein, dass das NLU-Modell die Absicht des Endnutzers anhand einer Vielzahl von Endnutzereingaben erfolgreich erkennen kann. Bei nicht ausreichender Vielfalt kann es zu Überanpassung kommen. Mit anderen Worten: Es besteht die Gefahr, dass das Modell zu eng an die von Ihnen angegebenen Beispiele gebunden ist und sich nicht ausreichend auf andere Beispiele verallgemeinern lässt.

Unterschiedliche Großschreibung

In seltenen Fällen müssen Sie möglicherweise Trainingsformulierungen hinzufügen, die sich nur in der Groß-/Kleinschreibung unterscheiden. Das ist normalerweise der Fall, wenn Sie erwarten, dass Endnutzer Texteingaben in Großbuchstaben schreiben.

Alternative Ansätze könnten sein:

• Den ML-Klassifizierungsschwellenwert senken
• Endnutzereingaben reduzieren, bevor sie an Dialogflow gesendet werden

Unnötige Vielfalt von Trainingsformulierungen

Vermeiden Sie triviale Abweichungen in den Trainingsformulierungen, da diese doppelte Informationen für das NLU-Modell bereitstellen. Schließen Sie beispielsweise keine Varianten ein, die sich nur durch Folgendes unterscheiden:

• Großschreibung (außer seltene Fälle): z. B. „Ticket bestellen“ oder „Ticket bestellen“.
• Füllwörter: z. B. „OK, Ticket bestellen“ und „Ticket bestellen“.
• Zeichensetzung: Zum Beispiel "Können Sie mir bitte helfen?" und "Können Sie mir bitte helfen?".

Konsistenz von Annotationen

Die für eine Annotation ausgewählte Trainingsformulierung sollte den gesamten Text und höchstens den Text enthalten, der für die Übereinstimmung mit einer Entität erforderlich ist. Achten Sie außerdem darauf, dass ähnliche Teile von Trainingsformulierungen für den gesamten Intent mit Anmerkungen versehen werden.

Die folgende Tabelle zeigt beispielsweise gute und schlechte Möglichkeiten für das Annotieren mit der Systementität @sys.date:

Gut	Schlecht
Abreise am 7. September	Abflug am 7. September
Abreise am 4. Juli	Abreise am 4. Juli

Semantisch aussagekräftige Annotationen für Systementitäten verwenden

Die semantische Bedeutung einer für eine Annotation ausgewählten Trainingsformulierung kann durch den Rest des Textes in einer Trainingsformulierung beeinflusst werden. Beispiel:

Annotierte Trainingsformulierung	Semantische Bedeutung von kommentiertem Text
Ich bin 7 Jahre alt	Alter einer Person
Der Vertrag ist 7 Jahre lang gültig.	Eine Zeitdauer

Die ML-Modelle von Dialogflow berücksichtigen beim Abgleichen von Systementitäten semantische Bedeutung. Die semantische Bedeutung der Trainingsformulierung muss der beabsichtigten semantischen Bedeutung der Systementität entsprechen.

Verwenden Sie beispielsweise nicht die Systementität @sys.duration für die Annotation zum ersten „7 Jahre“-Beispiel oben. Die semantische Bedeutung von „7 Jahre“ passt nicht zu einer einfachen Zeitdauer. Stattdessen sollten Sie „7“ für die Annotation auswählen und die Systementität @sys.number verwenden.

Intents definieren, um nicht konforme Formularantworten zu verarbeiten

Sie können Intents definieren, um nicht konforme Antworten beim Ausfüllen von Formularen zu verarbeiten. Beispielsweise könnte der Agent fragen: „Wie lauten Ihre Reisedaten?“, gefolgt von der Antwort des Endnutzers mit „Ich weiß noch nicht“. Diese Antwort entspricht nicht der Eingabeaufforderung für Formularparameter, aber wenn Ihr Agent eine Intent-Route hat, die mit dieser Antwort übereinstimmen kann, kann der Agent die Situation gut bewältigen.

@sys.any vermeiden

Vermeiden Sie die Verwendung des Systementitätstyps @sys.any. Es sollte nur verwendet werden, wenn Sie alle Möglichkeiten ausgeschöpft haben, einschließlich des Erstellens benutzerdefinierter Entitäten. Dieser Entitätstyp ist sehr breit gefasst und kann zu unerwünschtem Verhalten führen.

Wenn Sie diesen Entitätstyp verwenden, sollten Sie nicht mehrere Teile einer einzelnen Trainingsformulierung mit diesem Entitätstyp annotieren, da dies zu Unklarheiten führt und das Agent-Verhalten nicht definiert ist.

Die Verwendung von @sys.any mit Formularparametern ist weniger gefährlich, da der Agent bei der Aufforderung zur Eingabe von Formularparametern bestimmte Informationen erwartet.

Hinweis: Einige Systementitäten sind nicht verfügbar, wenn Sie die Agent-Bereitstellung regionalisieren. @sys.any wird manchmal als Problemumgehung empfohlen.

Anmerkungen sollten verschiedene Entitätswerte enthalten

Wenn Sie Trainingsformulierungen mit Anmerkungen definieren, sollten Sie verschiedene Beispiele für Entitätswerte verwenden. Sie sollten nicht immer dasselbe Entitätsbeispiel für die Annotationen verwenden. Das folgende Beispiel zeigt gute und schlechte Anmerkungen für einen Produktentitätstyp:

Gut	Schlecht
ich möchte ein hemd kaufen	ich möchte ein hemd kaufen
Einen neuen Hut bestellen	Ein neues Hemd bestellen
Füge dem Einkaufswagen eine Smartwatch hinzu.	Ein T-Shirt in den Einkaufswagen legen

Benutzerdefinierte Entitäten sollten Vielfalt enthalten

Benutzerdefinierte Entitäten sollten eine Vielzahl von Beispielen abdecken. Das NLU-Modell bietet Abwechslung bei grammatischen Formen, aber Sie müssen alle möglichen Elemente angeben.

Vermeiden Sie Entitäten mit aggressiver Übereinstimmung.

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 als mögliche Übereinstimmung bewertet.

Zuordnungs- und Listenentitäten sollten sich auf unterschiedliche Werte konzentrieren

Zuordnungs- und Listenentitätstypen sollten einen begrenzten Umfang haben, in dem unterschiedliche Werte eines Typs von Informationen erfasst werden. Halten Sie Ihre Entitäten prägnant, kurz und einfach.

Wenn Ihre Entitätswerte kompliziert sind, kann das daran liegen, dass Intent-Trainingsformulierungen besser zu Ihrer Situation passen. Betrachten Sie beispielsweise die folgenden Endnutzereingaben:

• „Wie kann ich mit Tarif A ein Auslandsgespräch tätigen?“
• „Internationales Daten-Roaming mit Tarif B verwenden“

Erstellen Sie keine Entitätstypen sowohl für die Aktionen als auch für die Pläne, z. B.:

Entitätstyp für Aktionen	Entitätstyp des Tarifs
„Wie kann ich ein Auslandsgespräch führen?“	„Plan A“
„Internationales Daten-Roaming nutzen“	„Plan B“

Stattdessen sollten Sie Trainingsformulierungen und Intent-Abgleiche verwenden, um die Aktionen und Entitäten für die Pläne zu erfassen.

RegExp-Entitäten verwenden, um Nicht-Wort-IDs zu erfassen

Wenn Sie Endnutzereingaben erfassen, die keine Wortkennungen sind, sollten Sie RegExp-Entitäten verwenden. Zur Erfassung von Produkt-IDs wie "AA-256" oder "AC-436" verwenden Sie beispielsweise eine Regexp-Entität wie "[A-Z]{2}-\d{3}".

Verschachtelte zusammengesetzte Entitäten vermeiden

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 der Abgleich möglicherweise unzuverlässig, da das NLU-Modell nicht mit ausreichender Sicherheit bestimmen kann, welcher Intent abgeglichen werden soll.

Wenn zwei Trainingsformulierungen dieselbe Intention repräsentieren, sollten sie zum selben Intent gehören. Beispielsweise sollten „Fälligkeitsdatum der aktuellen Rechnung ändern“ und „Mehr Zahlungszeit“ zum selben Intent gehören, da beide eine Änderung des Fälligkeitsdatums anfordern. Die Frage „Kann ich mit Tarif A international telefonieren?“ und „Kann ich internationales Daten-Roaming mit Tarif A verwenden?“ können jedoch zu verschiedenen Intents gehören, da der Endnutzer jeweils etwas anderes möchte.

Ähnliche Entitätstypen vermeiden

Vermeiden Sie es, mehrere Entitätstypen mit ähnlichen Entitätseinträgen zu definieren, da dies zu Unklarheiten im NLU-Modell führen kann.

No-Match-Ereignisse in der Produktion verwenden, um die Intents zu verbessern

Wenn Sie den Agent in der Produktion ausführen, ist es unvermeidlich, dass einige Endnutzereingaben zu nicht übereinstimmenden Ereignissen führen. Sie haben drei Möglichkeiten, diese Empfehlungen zur Verbesserung Ihres Agents zu nutzen:

• Fügen Sie die Endnutzereingabe als Trainingsformulierung zum gewünschten Intent hinzu. Dies ist jedoch nicht immer die beste Option. Wenn Sie dies mehrmals für den Intent tun, kann dies zu Intent-Verzerrungen führen.
• Bereinigen Sie die Trainingsformulierungen für den gewünschten Intent, damit sie alle die Intention genau widerspiegeln. In einigen Fällen können Intents mit unterschiedlichen Trainingsformulierungen den Abgleich für den Intent verhindern.
• Wenn Intents, die nicht mit der Endnutzereingabe abgeglichen werden sollen, Trainingsformulierungen haben, die mit der Endnutzereingabe übereinstimmen könnten, löschen Sie diese Trainingsformulierungen.

Sonderzeichen vermeiden

Sonderzeichen in Trainingsformulierungen ({, _, #, [ usw.) werden ignoriert. Eine Ausnahme stellen Emoticons dar, die wie erwartet funktionieren.

Füllwörter vermeiden

Füllwörter sind Wörter, die Sie ignorieren und den Text trotzdem verstehen können. Beispiel:

• gefallen
• kannst du bitte
• hmmm
• wie wäre es mit

Die Verwendung von Füllwörtern in Trainingsformulierungen ist unnötig, aber harmlos, 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

Über die ML-Einstellungen lässt sich anpassen, wie Endnutzereingaben verarbeitet werden. In den meisten Fällen funktionieren die Standardeinstellungen gut. Sie können die Einstellungen jedoch optimieren, um die Leistung des Agents zu verbessern.

Dem Endnutzer antworten

Dieser Abschnitt enthält Richtlinien für die Verwendung der Auftragsausführung, um dem Endnutzer zu antworten.

Den Endnutzer willkommen heißen

Ein neu erstellter Agent hat eine automatisch erstellte Intent-Route für den Begrüßungs-Intent. Sie sollten diese Route so bearbeiten, dass sie eine Nachricht zur Auftragsausführung enthält, mit der der Endnutzer begrüßt wird. Diese Nachricht sollte den Agent beschreiben und dem Endnutzer ein Gefühl dafür geben, was er leisten kann.

Endnutzerinformationen bestätigen

Häufig ist es am besten, die von den Endanwendenden in Antworten gegebenen Informationen zu wiederholen. Dadurch weiß der Endnutzer, dass der Agent seine Anfrage versteht.

Wenn ein Intent zugeordnet wird und ein Übergang stattfindet, informieren Sie den Endnutzer darüber, dass die Unterhaltung basierend auf seiner Anfrage fortsetzt. Beispiel:

Dialog	Beschreibung
Endnutzer: Ich habe Fragen zu meinem Girokonto. Agent: Okay, was möchten Sie über Ihr Girokonto wissen?	Die Endnutzereingabe führte zu einem Intent-Abgleich. Es wurde eine Route gefolgt, die eine Nachricht zur Auftragsausführung enthielt und zu einer Seite wechselte, auf der Fragen zum Girokonto bearbeitet wurden. Hinweis: 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 bereitgestellten Daten. Beispiel:

Dialog	Beschreibung
Endnutzer: Morgen Agent: Okay, Ihr Haarschnitt ist für morgen um 19:00 Uhr geplant. Kann ich sonst noch weiterhelfen?	Der Endnutzer hat den Datumsformularparameter angegeben, der der letzte Formularparameter auf der aktiven Seite war. Der Kundenservicemitarbeiter hat Datum und Uhrzeit eines geplanten Friseurs bestätigt.

Das Gespräch leiten

Der Agent sollte die Unterhaltung immer mit dem Endnutzer leiten. Dies erreichen Sie ganz einfach, indem Sie jede Antwort mit einer Frage beenden, z. B.:

• Kann ich sonst noch weiterhelfen?
• Was möchtest du über Beagle wissen?
• Möchtest du diese Bestellung stornieren oder aufgeben?
• Wie kann ich Ihnen heute helfen?
• Reisen Sie allein oder mit jemandem?

Vermeiden Sie beim Definieren dieser Fragen mehrere Fragen wie:

• Sind Sie noch hier? Auf welche Dienstleistung bezieht sich Ihre Anfrage?
• Möchtest du diese Bestellung trotzdem haben? Möchtest du etwas hinzufügen?

Möglicherweise beantwortet der Endnutzer nur eine der Fragen und Ihr Agent geht mit dieser Situation möglicherweise nicht richtig um.

Umgang mit Fehlern und unerwarteten Endnutzereingaben

Dieser Abschnitt enthält Hinweise zum Umgang mit Fehlern und unerwarteten Endnutzereingaben.

Event-Handler für integrierte Ereignisse erstellen

Erstellen Sie gegebenenfalls Event-Handler für die integrierten Ereignisse. Die Verarbeitung dieser Ereignisse ähnelt dem Erfassen von Ausnahmen in der Softwareprogrammierung. Je nach Situation können Sie die Ereignisse mit parameterspezifischen Event-Handlern, seitenspezifischen Event-Handlern oder ablaufspezifischen Event-Handlern verarbeiten.

Webhook-Fehler behandeln

Wenn Ihr Webhook-Dienst fehlschlägt, muss der Agent den Fehler ordnungsgemäß beheben können. Dazu definieren Sie Event-Handler für die Webhook-spezifischen integrierten Ereignisse. Hier ist ein empfohlener Ansatz zur Behebung von Webhook-Fehlern:

• Geben Sie kein Übergangsziel aus dem Status-Handler an, das den Webhook-Aufruf auslöst. Andernfalls wird der Event-Handler für Webhook-Fehler 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 initialisiert werden kann. Diese Seite sollte vor der Seite aktiv sein, die einen Webhook-Aufruf auslöst. Bei der Auftragsausführung für diese Seite sollte der Fehlerzähler 0 mithilfe einer Voreinstellung für Auftragsausführungsparameter initialisiert werden. Beispiel:

  Parameter	Wert
  webhook-error-count	0

• Erstellen Sie eine Webhook-Fehlerseite, die Webhook-Fehlerereignisse verarbeitet:

  • Die Auftragsausführung sollte den Fehler für den Endnutzer bestätigen und den Sitzungsparameter eines Fehlerzählers mithilfe einer Voreinstellung für Auftragsausführungsparameter erhöhen. Beispiel:

    Parameter	Wert
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Definieren Sie eine Bedingungsroute mit einer Bedingung, durch die die Fehleranzahl unter dem zulässigen Maximum liegt. (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 versucht. Für diese Route sollte ein Übergangsziel auf PREVIOUS_PAGE oder auf eine beliebige Seite festgelegt sein, die einen weiteren Versuch zum Aufrufen des Webhooks ausführen kann.

  • Definieren Sie eine Bedingungsroute mit einer Bedingung, bei der die Fehleranzahl größer 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 den Vorgang nicht mehr wiederholt. Für diese Route sollte ein Übergangsziel auf eine Seite festgelegt sein, die keine Webhook-Wiederholungsversuche auslöst.

• Der Webhook-Event-Handler sollte ein Übergangsziel haben, das zur Webhook-Fehlerseite übergeht.

Tools

Dieser Abschnitt enthält Tipps zur Verwendung von Tools zur Verbesserung des Agent-Designs.

Validierungstool verwenden

Sie sollten den Agent immer mit dem Validierungstool prüfen. Das Tool erkennt einige der in diesem Leitfaden beschriebenen Probleme.

Testlauffunktion verwenden

Sie sollten immer Testfälle für Ihren Agent definieren. Diese Testläufe können Regressionen verhindern, während der Agent weitere Szenarien bearbeiten kann.