Allgemeine Best Practices für das Design von Kundenservicemitarbeitern

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

Sehen Sie sich auch den Leitfaden zum Design von Voice-Agents an, der speziell auf das Design von Voice-Agents ausgerichtet ist, und den Leitfaden zu den Best Practices für die Verwendung des Conversational Agents-Dienstes (Dialogflow CX).

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.

Während Sie Ihren Bot weiterentwickeln, sollten Sie die Funktion Testfälle für die testgetriebene Entwicklung verwenden.

Vordefinierte Agents

Konversations-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 Ausführungen hinzu und Sie haben in kürzester Zeit einen funktionierenden Agent.

Integrationen und Dienste verknüpfen

Es gibt mehrere Möglichkeiten, Konversations-Agents (Dialogflow CX) zu integrieren. In diesem Abschnitt finden Sie Best Practices für die Auswahl der Einbindung.

Integrationen

Integrationen für Conversational Agents (Dialogflow CX) bieten eine sofort einsatzbereite Benutzeroberfläche für Ihren Agenten. Wenn Sie eine Integration verwenden, müssen Sie die API für Konversations-Agenten (Dialogflow CX) nicht direkt aufrufen, da dies von Integrationen erledigt wird. Diese Integrationen bieten einen Text-Agent, den du auf deiner Website einbetten kannst. können Sie sich mit anderen Messaging-Plattformen vernetzen, oder eine Telefonieschnittstelle bereitstellen.

Conversational Agents (Dialogflow CX) API

Wenn keine der gebrauchsfertigen Integrationen geeignet ist, oder die Benutzeroberfläche an dein System anpassen möchtest, können Sie verwenden Sie die Conversational Agents (Dialogflow CX) API direkt. Bei diesem Ansatz müssen Sie die Benutzeroberfläche für Ihren Bot implementieren oder eine vorhandene Benutzeroberfläche verwenden.

Webhooks

Wenn Ihr Agent nicht vollständig mit statischen Daten definiert werden kann, müssen Sie Webhooks um Ihren Dienst zu verbinden und einen Agent bereitzustellen, der dynamische Szenarien handhaben kann. Das gilt unabhängig davon, ob Sie Integrationen oder die Conversational Agents API (Dialogflow CX) verwenden.

Agent-Ressourcen

Die Ressourcen von Conversational Agents (Dialogflow CX) können auf viele Arten verwendet werden um ein gewünschtes Ergebnis zu erzielen. Dieser Abschnitt enthält Tipps zur Auswahl der richtigen Ressourcen. für die richtigen Szenarien.

Abläufe und Seiten

Abläufe und Seiten bieten Struktur für Kundenservicemitarbeiter. Stellen Sie sich Seiten als Knoten in einer Zustandsmaschine vor. und Abläufe als Gruppen verwandter Seiten. Über Status-Handler steuern Sie Übergänge zwischen Knoten. Sie werden aufgerufen, wenn eine Absicht übereinstimmt, eine Bedingung erfüllt ist oder ein Ereignis aufgerufen wird.

Ein einfacher Agent funktioniert möglicherweise gut mit einem einzigen Ablauf. Komplexere Bots sind jedoch fast immer besser mit mehreren Abläufen konzipiert. Jeder Ablauf sollte ein allgemeines Thema für den Kundenservicemitarbeiter darstellen. Jede Seite, die mit dem Ablauf verknüpft ist, sollte dabei helfen, das Thema zu bearbeiten. Außerdem kann jeder Ablauf eigene Einstellungen haben. und es kann sein, Gehört mir von einer Teilmenge von Teammitgliedern was hilft, die Arbeit beim Entwerfen großer Agents aufzuteilen.

Beim Entwerfen eines großen, komplexen Agents müssen Sie die „Flows pro Agent“ und „Seiten pro Besucherfluss“ . Diese Limits tragen dazu bei, die Leistung des Agents aufrechtzuerhalten.

Wenn Ihr Design zu viele Abläufe pro Kundenservicemitarbeiter enthält, kombinieren Sie ähnliche Themen in einem einzigen Ablauf. Beispiel: könnten Sie die folgenden Themen zu einem einzigen „Guthaben abrufen“ kombinieren, Ablauf:

  • Girokonto abrufen
  • Guthaben abrufen
  • Hypothekenrestschuld abrufen
  • Guthaben abrufen

Wenn Ihr Agentendesign zu viele Seiten pro Ablauf hat, kombinieren Sie ähnliche Seiten und verwenden Sie viele Routen pro Seite.

Wenn Sie immer noch Probleme mit Flows und Seitenlimits haben, kann das daran liegen, dass Sie zu viel Geschäftslogik in den Agent integriert haben. Wir empfehlen, diese Logik auf Webhooks zu verschieben.

Im Folgenden sind die Optionen für die Detaillierung der Unterhaltungssteuerung von Kundenservicemitarbeitern in absteigender Reihenfolge aufgeführt:

  1. Kundenservicemitarbeiter (ein Kundenservicemitarbeiter bearbeitet alle Unterhaltungen)
  2. Abläufe (ein Ablauf verarbeitet ein oder mehrere verwandte Unterhaltungsthemen)
  3. Seiten (eine Seite verarbeitet einen oder mehrere zusammenhängende Konversationsschritte)
  4. Routen (eine Route verarbeitet eine Nutzer-Intent- oder Bedingungsprüfung)

Intent-Parameter im Vergleich zu Formularparametern

Die Hauptmethode, mit der Ihr System strukturierte Daten vom Endnutzer erhält, sind Parameter. Sie können Parameter entweder für Intents (Intent-Parameter) oder für Seiten (Formularparameter) verwenden.

Der Hauptzweck einiger Seiten besteht darin, bestimmte Informationen vom Endnutzer zu erfassen. Beispielsweise kann eine Seite so konzipiert 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 können Sie Informationen zu den Endnutzern erheben, beim Wechsel von einer Seite zur anderen. Beispiel: wenn die Endnutzer*innen ein bestimmtes Produkt zu Beginn des Gesprächs möchten Sie das gewünschte Produkt während Sie zur entsprechenden Auftragsseite wechseln. Verwenden Sie in diesem Fall Intent-Parameter als Teil von Intent-Routen.

Es gibt auch Situationen, in denen sollten Sie sowohl Intent- als auch Formularparameter verwenden. Wenn der Endnutzer beispielsweise zu Beginn des Gesprächs ein kleines T-Shirt anfordert, sollten Sie den gewünschten Größenparameter („small“) erfassen, während Sie zur Seite für die T-Shirt-Bestellung wechseln. Auf der Seite zur Bestellung der T-Shirts werden Sie möglicherweise nach zusätzlichen Informationen gefragt, wie die gewünschte Farbe. Die Seite für die T-Shirt-Bestellung sollte Formularparameter für Größe und Farbe haben. In diesem Beispiel der Parameter „size“ wurde bereits angegeben. übertragen, sodass der Agent nur die Farbe anfordert. Andere Unterhaltungen können jedoch einen anderen Pfad verfolgen, bei dem der Endnutzer die gewünschte Größe nicht angegeben hat, als die Seite für die Bestellung des T-Shirts aktiv wird. Wenn Sie diesen Parameter auf diese beiden Arten definieren, kann Ihr Bot die Informationen flexibler extrahieren.

Routen und Routengruppen

Wenn Sie zu einer anderen Seite wechseln möchten, Antwortnachricht in die Warteschlange stellen, oder einen Webhook aufrufen, Intent oder ein condition [Zustand] erfüllt ist, nutzen Routen.

Wenn Sie auf mehreren Seiten dieselben Routen verwenden, sollten Sie Routengruppen verwenden. So vermeiden Sie unnötige Duplikate in Ihrem Agent-Design.

Intent-Wiederverwendung

Wenn Sie mehrere Intents mit ähnlichen Trainingsformulierungen definieren, sollten Sie überlegen, die Intents auf mehreren Seiten wiederzuverwenden. Idealerweise sollten Sie einige allgemeine Intents definieren, die auf vielen Seiten verwendet werden. und bestimmte Intents, die nur auf einer Seite verwendet werden. So vermeiden Sie unnötige Duplikate im Agent-Design.

Beispiel: Bestätigungs-Intents werden in der Regel am besten als wiederverwendbare Intents definiert. Ein confirmation.yes-Intent könnte z. B. folgende Trainingsformulierungen haben:

  • Ja
  • Ja
  • Klar
  • Ok
  • Ja, das tue ich.
  • Bestimmt
  • unbedingt
  • Ja, bitte.

Ein confirmation.no-Intent könnte z. B. folgende Trainingsformulierungen haben:

  • no
  • nah
  • Nein
  • Auf keinen Fall
  • Nicht für mich
  • absolut nicht
  • Nein, danke.

Diese wiederverwendbaren Bestätigungsabsichten können in vielen Szenarien für Ihren Kundenservicemitarbeiter verwendet werden.

In einigen Fällen sollten Sie auch spezielle Bestätigungs-Intents erstellen. Beispiel: wenn Sie eine Bestellung bestätigen, sollten Sie einen speziellen order.confirmation.yes-Intent mit Trainingsformulierungen wie:

  • die Bestellung sieht gut aus
  • Ich akzeptiere diese Bestellung

Und einen speziellen order.confirmation.no-Intent mit Trainingsformulierungen wie:

  • Ich möchte diese Bestellung nicht
  • Ich akzeptiere diesen Antrag nicht.

Wenn Ihre Bestellbestätigungsseite aktiv ist, Intent-Routen für alle vier Intents im Geltungsbereich liegen. So wird sichergestellt, dass jede allgemeine oder spezifische Bestätigung des Endnutzers ordnungsgemäß verarbeitet wird.

Standardmäßig auszuschließender Intent

Sie sollten den Standard-Negativ-Intent mit Formulierungen füllen, die Ihre Endnutzer sagen könnten, die aber keinem Intent in Ihrem Agenten entsprechen sollten.

Auftragsausführung

Es gibt viele Möglichkeiten, mithilfe von Auftragsausführungen auf den Endnutzer zu reagieren. Während einer Unterhaltungsrunde kann der Kundenservicemitarbeiter der Antwortwarteschlange mehrere Nachrichten anhängen. Die zusammengesetzte Warteschlange wird am Ende der Unterhaltungsrunde an den Endnutzer gesendet. In diesem Abschnitt werden die einzelnen Optionen zum Erstellen der einzelnen Nachrichten beschrieben.

  • Ausführung von Seiteneinträgen: Diese Auftragsausführung wird aufgerufen, wenn die Seite zum ersten Mal aktiv wird. Sie ist nützlich, wenn Sie eine Nachricht benötigen, die den Zweck der Seite beschreibt. Sie sollte nur einmal ausgesprochen werden, solange die Seite aktiv ist. Beispiel:
    • Was möchten Sie über Ihr Girokonto wissen?
    • Welche Art von Produkt möchten Sie kaufen?
    • Ich benötige einige Informationen zum Hemd, das Sie bestellen möchten.
  • 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 benötigen, die dem Endnutzer über die Intent-Übereinstimmung, die erfüllte Bedingung (z. B. eine Bedingung für den Abschluss des Ausfüllens eines Formulars) oder die Weiterleitung informiert. Beispiel:
    • Ja, Ihr internationaler Tarif gilt auch für Japan. (Intent-Abgleich)
    • Sind Sie sicher, dass Sie 300 Hemden kaufen möchten? (Vergleichsbedingung erfüllt)
    • Okay, dein Termin ist morgen früh um 07:00 Uhr. (Ausfüllen des Formulars)
    • Okay, reden wir jetzt über Erdmännchen. (Übergang)
  • Event-Handler: Diese Auftragsausführung wird aufgerufen, wenn ein Ereignis aufgerufen wird. Das ist nützlich, wenn Sie eine Nachricht benötigen, die auf das Ereignis reagiert. Beispiel:
  • Erste Aufforderungen für Formulare: Diese Auftragsausführung wird aufgerufen, wenn der Kundenservicemitarbeiter ein Formular ausfüllt. In diesen Nachrichten sollte dem Endnutzer eine bestimmte Frage gestellt werden. Für jeden Formularparameter gibt es eine eigene anfängliche Prompt-Ausführung. Beispiel:
    • Welche Größe soll das Hemd haben?
    • Welche Farbe soll das T-Shirt haben?
  • Handler für die erneute Eingabeaufforderung 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 sich die Nachricht für die erneute Aufforderung von der ursprünglichen Aufforderungsnachricht unterscheiden soll. Wenn keine Handler für die erneute Eingabeaufforderung vorhanden sind, verwendet der Kundenservicemitarbeiter einfach die erste Aufforderung als Aufforderung zur erneuten Eingabe. Beispiel:
    • Ich verstehe nicht. Geben Sie bitte eine gültige Farbe für das Hemd an.

Benennung

In diesem Abschnitt finden Sie Tipps zur Benennung von Ressourcen für Kundenservicemitarbeiter.

Intent-Benennung

Wenn Ihr Agent viele Intents sollten Sie ein Namensschema in Betracht ziehen, das Ihnen hilft, sie zu organisieren. 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

In Status-Handlern definierte Übergänge ermöglichen die Steuerung der Unterhaltung durch Ändern der aktiven Seite. In diesem Abschnitt finden Sie Tipps zur Organisation von Übergängen für Kundenservicemitarbeiter.

Kostenlose Umstellungen

Berücksichtigen Sie beim Definieren einer Route, die einen Übergang auslöst, dass es möglicherweise eine ergänzende oder umgekehrte 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 auch eine weitere Route mit != definieren.

Endnutzereingaben verarbeiten

Dieser Abschnitt enthält Richtlinien für Intents und Trainingsformulierungen, damit der Agent Endnutzereingaben optimal verarbeiten kann.

Definieren Sie mindestens 20 Trainingsformulierungen

Für jeden Intent sollten mindestens 20 Trainingsformulierungen vorhanden sein. Andernfalls hat das NLU-Modell möglicherweise nicht genügend Informationen um den Intent entsprechend anzupassen. Dies ist eine Mindestanforderung. Idealerweise sollten Sie mehr definieren, insbesondere für Haupt-Intents großer Bots, für die etwa 50 wünschenswert sind.

Absichtsverzerrung beachten

Wenn für einen oder mehrere Intents deutlich mehr Trainingsphrasen als für andere Intents vorhanden sind, führt dies aufgrund von ungleichgewichtigen Daten dazu, dass das NLU-Modell zugunsten der größeren Intents verzerrt wird. Dieser Voreingenommenheit kann auftreten, wenn sich die Anzahl der Trainingsphrasen um eine Größenordnung oder mehr unterscheidet.

In einigen Fällen ist das erwünscht, da Sie einige Intents definieren können, die häufiger als andere abgeglichen werden sollten, da sie Eingaben von Endnutzern entsprechen, die im Live-Traffic häufiger vorkommen.

In anderen Fällen kann dieses Verhalten unerwünscht sein, weil Sie keine Verzerrung zugunsten dieser größeren Intents wünschen. In diesem Fall Die Anzahl der Trainingsformulierungen für diese größeren Intents reduzieren in der gleichen Größenordnung wie andere Intents haben. Beispiel:

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

Verwendung von Entitäten und Anzahl der Trainingssätze

Für alle Entitätstypen, die in einem Intent verwendet werden:

  • Annotieren Sie jedes Beispiel für die Entitätstypen.
  • Für jeden Entitätstyp Geben Sie 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 sein

Trainingsformulierungen sollten dialogorientiert und natürlich sein. sollten sie mit dem übereinstimmen, was die Nutzer tatsächlich sagen. Verwenden Sie nach Möglichkeit Eingaben von Endnutzern, die in der Produktion aufgetreten sind, als Trainingsdaten. Achten Sie dabei besonders auf die häufigsten Eingaben.

Erforderliche Vielfalt an 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.

Am besten formulieren Sie kürzere Formulierungen wie „Bezahlen Sie meine Rechnung“, sowie längere Sätze und Sätze wie „Ich habe gerade eine E-Mail erhalten, in der steht, dass ich meinen Kontoauszug bezahlen muss.“ Es wird kein Verhältnis zwischen kurzen und langen Wortgruppen empfohlen. aber Sie sollten dafür die tatsächlichen Endnutzereingaben berücksichtigen, an den Agent in der Produktion gesendet.

Es ist wichtig, Trainingsformulierungen zu definieren, die sich in Länge, Formulierung und Satzstruktur unterscheiden, damit Ihr Kundenservicemitarbeiter gut geschult werden kann. Für den vielfältigen Sake ist es nicht notwendig, aber es ist notwendig, genügend Abwechslung dass das NLU-Modell die der verschiedenen Endnutzereingaben zu verstehen. Wenn die Vielfalt nicht ausreicht, besteht die Gefahr einer Überanpassung. Mit anderen Worten: besteht die Gefahr, dass das Modell zu eng miteinander verbunden ist. zu den konkreten Beispielen, die Sie und lassen sich nicht genügend auf andere Beispiele verallgemeinern.

Groß- und Kleinschreibung abwechslungsreich verwenden

Die Groß- und Kleinschreibung hängt davon ab, welches NLU-Modell der Kundenservicemitarbeiter verwendet.

Standard-NLU

Beim Standard-NLU-Modell wird die Groß- und Kleinschreibung nicht berücksichtigt. In seltenen Fällen müssen Sie möglicherweise Trainingsphrasen hinzufügen, die sich nur in der Groß- und Kleinschreibung unterscheiden. Dies gilt in der Regel für in denen Sie erwarten, dass Endnutzer Text in Großbuchstaben eingeben.

Alternative Ansätze könnten sein:

  • Den ML-Klassifizierungsschwellenwert verringern
  • Endnutzereingaben, bevor sie an Conversational Agents (Dialogflow CX) gesendet werden, werden in Kleinbuchstaben geschrieben.

Erweiterte NLU

Im Gegensatz zum Standard-NLU-Modell wird beim erweiterten NLU-Modell zwischen Groß- und Kleinschreibung unterschieden. Wir empfehlen, die relevanten großgeschriebenen Trainingsdaten zu testen und hinzuzufügen, um die Abgleichsraten für die Nutzerabsicht zu erhöhen.

Unnötige Vielfalt von Trainingsformulierungen

Vermeiden Sie unwesentliche Variationen bei Trainingsphrasen, da sie dem NLU-Modell doppelte Informationen liefern. Beispiel: enthalten keine Varianten, die sich nur in folgenden Punkten unterscheiden:

  • Großschreibung: Wenn Sie das Standard-NLU-Modell verwenden, vermeiden Sie doppelte Einträge. Wortgruppen wie „Ticket bestellen“ und „Ticket bestellen“ außer in seltenen Fällen Cases. Beim erweiterten NLU-Modell wird jedoch zwischen Groß- und Kleinschreibung unterschieden und es sind mehr Trainingsformulierungen, um mehr Intent-Übereinstimmungen zu erzielen. Weitere Informationen finden Sie im Abschnitt Groß- und Kleinschreibung.
  • Füllwörter: Beispiel: „Okay, Ticket bestellen“ und „Ticket bestellen“.
  • Interpunktion: z. B. „Können Sie mir bitte helfen?“ und „Können Sie mir bitte helfen!?“

Konsistenz von Anmerkungen

Die für eine Anmerkung ausgewählte Trainingsformulierung sollte Folgendes enthalten: und nicht mehr als den Text, der zum Abgleich mit einer Entität erforderlich ist. Achten Sie außerdem darauf, dass ähnliche Teile von Trainingsformulierungen für den gesamten Intent mit Anmerkungen versehen sind.

Beispiel: In der folgenden Tabelle sehen Sie gute und schlechte Erfahrungen, zum Annotieren mit der Systementität @sys.date:

Gut Fehlerhaft
Abreise: 7. September Abfahrt am 7. September
Abflug am 4. Juli Am 4. Juli

Verwenden Sie semantisch sinnvolle Anmerkungen für Systementitäten.

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

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

Die Modelle für maschinelles Lernen von Konversations-Agents (Dialogflow CX) berücksichtigen die semantische Bedeutung bei der Zuordnung von Systementitäten. Die semantische Bedeutung des Teils der Trainingsformulierung muss mit der beabsichtigten semantischen Bedeutung der Systementität übereinstimmen.

Verwenden Sie beispielsweise die Systementität @sys.duration nicht für die Anmerkung des ersten Beispiels „7 Jahre“ oben. Die semantische Bedeutung von „7 Jahre“ entspricht nicht einer einfachen Zeitspanne. Wählen Sie stattdessen „7“ für die Anmerkung aus und verwenden Sie die Systementität @sys.number.

Intents zur Verarbeitung nicht konformer Antworten zum Ausfüllen von Formularen definieren

Sie können Intents definieren, um nicht konforme Antworten beim Ausfüllen von Formularen zu verarbeiten. Beispiel: fragt Ihr Kundenservicemitarbeiter möglicherweise „wann reisen Sie an?“, gefolgt von der Endnutzerantwort „Ich weiß es noch nicht“. Diese Antwort erfüllt nicht die Eingabeaufforderung für den Formularparameter, Wenn Ihr Agent jedoch eine Intent-Route hat, die dieser Antwort entsprechen kann, kann der Kundenservicemitarbeiter die Situation gut handhaben.

Vermeiden Sie @sys.any

Verwenden Sie den Systementitätstyp @sys.any nicht. Sie sollten sie nur verwenden, wenn Sie alle anderen Möglichkeiten ausgeschöpft haben, einschließlich der Erstellung benutzerdefinierter Entitäten. Dieser Entitätstyp ist sehr weit gefasst und kann zu unerwünschtem Verhalten führen.

Wenn Sie diesen Entitätstyp verwenden, Vermeiden Sie es, mehrere Teile einer einzelnen Trainingsformulierung mit Anmerkungen zu versehen mit diesem Entitätstyp aus, da dies Unklarheiten schafft, und das Agent-Verhalten ist nicht definiert.

Die Verwendung von @sys.any mit Formularparametern ist weniger gefährlich, da der Kundenservicemitarbeiter beim Anfordern von Formularparametern bestimmte Informationen erwartet.

Anmerkungen sollten eine Vielzahl von Entitätswerten enthalten

Wenn Sie annotierte Trainingsformulierungen definieren, sollten Sie in den Formulierungen eine Vielzahl von Beispielen für Entitätswerte verwenden. Verwenden Sie für die Anmerkungen nicht immer dasselbe Entitätsbeispiel. Das folgende Beispiel zeigt gute und schlechte Anmerkungen für einen Produktentitätstyp:

Gut Fehlerhaft
Ich möchte ein Hemd kaufen. ich möchte ein T-Shirt kaufen
Einen neuen Hut bestellen Neues Hemd bestellen
Smartwatch in den Einkaufswagen legen 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 Vielfalt für grammatische Formen, Sie müssen jedoch 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 als mögliche Übereinstimmung bewertet.

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

Entitätstypen für Zuordnungen 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. Beispiele für Endnutzereingaben:

  • „Wie kann ich mit Tarif A einen Auslandsanruf führen?“
  • „Daten-Roaming im Ausland mit Tarif B verwenden“

Erstellen Sie nicht Entitätstypen sowohl für die Aktionen als auch für die Tarife, z. B.:

Entitätstyp „Aktionen“ Entitätstyp des Tarifs
„Wie kann ich ein Auslandsgespräch führen?“ Tarif A
"Verwendung von internationalem Daten-Roaming" „Plan B“

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

Mit regulären Regex-Entitäten kannst du Kennungen erfassen, die keine Wörter sind

Wenn Sie Endnutzereingaben erfassen, die keine Wortidentitäten enthalten, sollten Sie RegExp-Entitäten verwenden. Beispiel: Produkt-IDs wie „AA-256“ oder "AC-436", Regexp-Entität wie „[A–Z]{2}-\d{3}“.

Verschachteln von zusammengesetzten 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 die Zuordnung möglicherweise nicht zuverlässig, da das NLU-Modell nicht mit ausreichender Sicherheit bestimmen kann, welcher Intent übereinstimmt.

Wenn zwei Wortgruppen dieselbe Absicht haben, sollten sie zum selben Intent gehören. Beispielsweise sollten „Datum der aktuellen Rechnung ändern“ und „Mehr Zeit zum Bezahlen“ zur selben Absicht gehören, da in beiden Fällen eine Änderung des Fälligkeitsdatums angefordert wird. Sie können jedoch „Kann ich mit Tarif A ein Auslandsgespräch führen?“ und „Kann ich bei Tarif A internationales Daten-Roaming nutzen?“ zu verschiedenen Intents gehören, da die Endnutzer in jedem Fall etwas anderes wünschen.

Ähnliche Entitätstypen vermeiden

Sie sollten nicht mehrere Entitätstypen definieren mit ähnlichen Entitätseinträgen, da dies für das NLU-Modell zu Unklarheiten führen kann.

Verwende No-Match-Ereignisse in der Produktion, um deine Intents zu verbessern

Wenn Sie den Agent in der Produktion ausführen, ist es unvermeidlich, dass manche Endnutzereingaben zu nicht übereinstimmende Ereignisse. Sie können diese Empfehlungen nutzen, um Ihren Agent zu verbessern auf eine der folgenden drei Arten:

  • Fügen Sie die Endnutzereingabe dem gewünschten Intent als Trainingsformulierung hinzu. Dies ist jedoch nicht immer die beste Option. Wenn Sie dies für den Intent häufig tun, kann dies zu einer Intent-Voreingenommenheit führen.
  • Bereinigen Sie die Trainingsformulierungen für den gewünschten Intent. damit alle die Absicht widerspiegeln. In einigen Fällen können Intents mit unterschiedlichen Trainingsformulierungen die Zuordnung des Intents verhindern.
  • Intents, die nicht mit der Endnutzereingabe abgeglichen werden sollen Trainingsformulierungen haben, die der Endnutzereingabe entsprechen, diese Trainingsformulierungen löschen.

Sonderzeichen vermeiden

Sonderzeichen wie {, _, # und [ werden in Trainingsformulierungen ignoriert. Eine Ausnahme bilden Emoticons, wo sie wie erwartet funktionieren.

Vermeiden Sie Füllwörter.

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

  • gefallen
  • Können Sie bitte
  • hmmm
  • Wie wäre es mit

Es ist unnötig, aber harmlos, Füllwörter in Trainingsphrasen 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 keine Entitäten, die aus Füllwörtern bestehen.

Mit ML-Einstellungen experimentieren

Die ML-Einstellungen kann verwendet werden, um anzupassen, wie Endnutzereingaben verarbeitet werden. In den meisten Fällen funktionieren die Standardeinstellungen gut. Sie können die Einstellungen jedoch optimieren, um die Leistung Ihrer Kundenservicemitarbeiter zu verbessern.

Auf den Endnutzer reagieren

Dieser Abschnitt enthält Richtlinien für die Verwendung der Auftragsausführung Endanwendenden zu antworten.

Begrüßen Sie die Endnutzer

Ein neu erstellter Agent hat eine automatisch erstellte Intent-Route für den Begrüßungs-Intent. Du solltest diese Route bearbeiten, um eine Bestätigungsnachricht mit einer Begrüßung für den Endnutzer einzufügen. Diese Nachricht sollte den Bot beschreiben und dem Endnutzer einen Eindruck davon vermitteln, was er kann.

Endnutzerinformationen bestätigen

Es ist oft am besten, in den Antworten Informationen zu wiederholen, die der Endnutzer angegeben hat. Dadurch wird der Endnutzer darüber informiert, dass der Agent seine Anfrage versteht.

Wenn ein Intent zugeordnet wird und eine Weiterleitung erfolgt, informieren Sie den Endnutzer darüber, dass die Unterhaltung auf Grundlage seiner Anfrage fortgesetzt wird. Beispiel:

Dialog Beschreibung
Endnutzer: Ich habe Fragen zu meinem Girokonto.
Agent: Okay, was möchten Sie über Ihr Girokonto wissen?		 Die Eingabe des Endnutzers führte zu einer Intent-Übereinstimmung und einer Route wurde gefolgt, die eine Meldung zur Auftragsausführung und einen Wechsel zu einer Seite enthielt, auf der Kontofragen geprüft werden. Der Agent bestätigt, dass der Endnutzer mehr über sein Girokonto erfahren möchte.

Wiederholen Sie die vom Endnutzer bereitgestellten Daten, sobald das Ausfüllen des Formulars abgeschlossen ist. Beispiel:

Dialog Beschreibung
Endnutzer: Morgen
Kundenservicemitarbeiter: Okay, Ihr Termin für den Haarschnitt ist morgen um 19:00 Uhr. Kann ich sonst noch weiterhelfen?		 Der Endnutzer hat den Formularparameter „date“ 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 leiten. Das geht ganz einfach, indem du jede Antwort beendest. mit einer Frage wie:

  • Kann ich sonst noch weiterhelfen?
  • Was möchten Sie über Beagles wissen?
  • Möchten Sie diese Bestellung stornieren oder senden?
  • Wie kann ich Ihnen helfen?
  • Reisen Sie allein oder mit jemandem?

Wenn Sie diese Fragen definieren, stellen Sie nicht mehrere Fragen wie:

  • 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?

Die Endanwendenden antworten möglicherweise nur auf eine der Fragen, und der Agent geht mit dieser Situation möglicherweise nicht richtig um.

Umgang mit Fehlern und unerwarteten Endnutzereingaben

In diesem Abschnitt finden Sie Tipps zum Umgang mit Fehlern und unerwarteten Endnutzereingaben.

Event-Handler für integrierte Ereignisse erstellen

Sie sollten gegebenenfalls Event-Handler für die eingebundenen Ereignisse erstellen. Die Verarbeitung dieser Ereignisse ähnelt dem Abfangen von Ausnahmen bei der Softwareprogrammierung. Je nach Situation sollten Sie die Ereignisse mit Parameterspezifische Event-Handler, seitenspezifische Event-Handler oder ablaufspezifischen Event-Handlern.

Webhook-Fehler behandeln

Wenn der Webhook-Dienst fehlschlägt, ist es wichtig, dass Ihr Agent mit dem Fehler umgehen kann. Dazu definieren Sie Event-Handler für die webhookspezifischen vordefinierten Ereignisse. Hier ist ein empfohlener Ansatz zum Umgang mit Webhook-Fehlern:

  • Geben Sie kein Übergangsziel aus dem Status-Handler das die Webhook-Aufruf Andernfalls wird der Ereignis-Handler für Webhook-Fehler nicht aufgerufen. Legen Sie stattdessen das Übergangsziel in der Webhook-Antwort vom Webhook-Dienst 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. Die Eingabeausführung für diese Seite sollte den Fehlerzähler mit einer Voreinstellung für den Auftragsausführungsparameter auf 0 initialisieren. Beispiel:

    Parameter Wert
    webhook-error-count 0

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

    • Die Auftragsausführung des Eintrags sollte den Fehler für den Endnutzer bestätigen, Außerdem sollte er einen Sitzungsparameter für den Fehlerzähler mithilfe eines Voreinstellung für Auftragsausführungsparameter. Beispiel:

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

    • Definieren Sie eine Bedingungsroute mit der Bedingung, dass die Fehleranzahl unter dem zulässigen Maximum liegt. (z. B. $session.params.webhook-error-count <= 3). Diese Route sollte eine Ausführung haben, die den Endnutzer darüber informiert, dass der Kundenservicemitarbeiter es noch einmal versuchen wird. Für diese Route sollte folgendes Übergangsziel festgelegt sein: PREVIOUS_PAGE oder auf eine Seite, die einen weiteren Versuch unternehmen kann, den Webhook aufzurufen.

    • Bedingungsroute definieren, die eine Bedingung hat, die vom Fehler gezählt wird ist größer als zulässig (z. B. $session.params.webhook-error-count > 3). Diese Route sollte eine Auftragsausführung enthalten, die den Endnutzer benachrichtigt dass der Agent es nicht mehr versucht. Für diese Route sollte ein Übergangsziel auf eine Seite festgelegt sein, die keine Webhook-Wiederholungen auslöst.

  • Der Webhook-Ereignis-Handler sollte ein Umstellungsziel haben, das zur Webhook-Fehlerseite führt.

Tools

In diesem Abschnitt finden Sie Tipps zur Verwendung von Tools zur Verbesserung des Designs von Kundenservicemitarbeitern.

Validierungstool verwenden

Sie sollten Ihren Kundenservicemitarbeiter immer mit dem Bestätigungstool prüfen. Dieses Tool erkennt einige der in diesem Leitfaden beschriebenen Probleme.

Funktion „Testläufe“ verwenden

Sie sollten immer Testläufe für Ihren Agent. Diese Testfälle können dazu beitragen, Regressionen während der Agent weiterentwickelt wird, um weitere Szenarien zu bewältigen.

Zurück
Best Practices für die Dienstnutzung
Weiter
Best Practices für das Design von Voice-Agents