Allgemeine Best Practices für das Design von Kundenservicemitarbeitern

In diesem Leitfaden finden Sie allgemeine Best Practices für das Design aller Arten von Agenten.

Sehen Sie sich auch den Leitfaden zum Design von Sprach-Agents speziell für das Design von Sprach-Agents und den Leitfaden mit Best Practices für die Verwendung des Dialogflow CX-Dienstes an.

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. Sobald die grundlegende Struktur steht, können Sie die Unterhaltungspfade iterieren, um sicherzustellen, dass Sie alle möglichen Wege abdecken, die ein Endnutzer einschlagen könnte.

Während sich Ihr Agent weiterentwickelt, sollten Sie die Funktion Testfälle für die testgesteuerte 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 Routen und Auftragsausführungen hinzu, die für Ihr Unternehmen spezifisch sind, und Sie erstellen schnell einen funktionierenden Agenten.

Integrationen und Verbinden Ihrer Dienste

Es gibt mehrere Möglichkeiten, Dialogflow CX-Agenten einzubinden. In diesem Abschnitt finden Sie Best Practices für die Auswahl der Integrationsmethode.

Integrationen

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

Dialogflow CX API

Wenn keine der einsatzbereiten Integrationen geeignet ist oder Sie die Oberfläche 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

Sofern Ihr Agent nicht vollständig mit statischen Daten definiert werden kann, müssen Sie Webhooks verwenden, um Ihren Dienst zu verbinden und einen Agenten bereitzustellen, der dynamische Szenarien verarbeiten kann. Dies gilt unabhängig davon, ob Sie Integrationen oder die Dialogflow CX API verwenden.

Ressourcen für KI-Agenten

Dialogflow CX-Agentenressourcen 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 verleihen Ihrem Agenten Struktur. Sie können sich Seiten als Knoten in einer Zustandsmaschine und Abläufe als Gruppen zusammengehöriger Seiten vorstellen. Sie steuern Übergänge zwischen Knoten mit Zustands-Handlern, die aufgerufen werden, wenn ein Intent übereinstimmt, eine Bedingung erfüllt ist oder ein Ereignis aufgerufen wird.

Ein einfacher KI-Agent kann mit einem einzigen Ablauf gut funktionieren, aber komplexe KI-Agenten sind fast immer besser mit mehreren Abläufen konzipiert. Jeder Ablauf sollte ein übergeordnetes Thema für Ihren Agenten darstellen, wobei jede mit dem Ablauf verknüpfte Seite zur Bearbeitung des Themas beiträgt. Darüber hinaus kann jeder Ablauf eigene Einstellungen haben und von einer Teilmenge von Teammitgliedern verwaltet werden. Das hilft, die Arbeit beim Entwerfen großer Agenten aufzuteilen.

Wenn Sie einen großen, komplexen Agenten entwerfen, müssen Sie die Limits 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 verwandte Themen in einem einzigen Ablauf zusammen. Sie können beispielsweise die folgenden Themen zu einem einzigen „Kontostand abrufen“-Flow kombinieren:

• Guthaben auf dem Girokonto abrufen
• Sparbetrag abrufen
• Hypothekensaldo abrufen
• Guthaben abrufen

Wenn Ihr Agentenentwurf zu viele Seiten pro Ablauf enthält, kombinieren Sie ähnliche Seiten und verwenden Sie viele Routen pro Seite.

Wenn Sie weiterhin Probleme mit den Limits für Abläufe und Seiten haben, liegt das möglicherweise daran, dass Sie zu viel Geschäftslogik in den Agenten selbst eingebunden haben. Sie sollten diese Logik in Webhooks verschieben.

Im Folgenden wird die Granularität der Unterhaltungssteuerung von Agentenressourcen in aufsteigender Reihenfolge aufgeführt:

1. Agenten (ein Agent verarbeitet alle Unterhaltungen)
2. Abläufe (ein Ablauf verarbeitet ein oder mehrere verwandte Gesprächsthemen)
3. Seiten (eine Seite verarbeitet einen oder mehrere zusammengehörige Gesprächsbeiträge)
4. Routen (eine Route verarbeitet eine Nutzerabsicht oder eine Bedingungsprüfung)

Intent-Parameter im Vergleich zu Formularparametern

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

Der Hauptzweck einiger Seiten besteht darin, bestimmte Informationen vom Endnutzer zu erfassen. Eine Seite kann beispielsweise 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 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. 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 der Unterhaltung ein kleines Hemd anfordert, möchten Sie den gewünschten Größenparameter (klein) erfassen, während Sie zur Seite für die Hemdbestellung wechseln. Auf der Bestellseite für das Shirt werden möglicherweise zusätzliche Informationen abgefragt, z. B. die gewünschte Farbe. Die Bestellseite für das T-Shirt sollte Formularparameter für Größe und Farbe enthalten. In diesem Beispiel wurde der Parameter „Größe“ bereits angegeben und weitergegeben, sodass der Agent nur nach der Farbe fragt. Andere Unterhaltungen können jedoch einen anderen Verlauf nehmen, bei dem der Endnutzer die gewünschte Größe nicht angegeben hat, wenn die Seite zur Bestellung von T-Shirts aktiv wird. Wenn Sie diesen Parameter auf beide Arten definieren, ist Ihr KI-Agent flexibler beim Extrahieren der Informationen.

Hinweis: Wenn Sie Parameter mit derselben ID oder demselben Anzeigenamen in verschiedenen Intents oder Formularen definieren, müssen der Entitätstyp und andere Einstellungen für alle Definitionen gleich sein. Wenn sich der Entitätstyp oder andere Parametereinstellungen unterscheiden, verwenden Sie für jede Definition eine eindeutige Parameter-ID oder einen eindeutigen Anzeigenamen.

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 oder eine Bedingung erfüllt ist, verwenden Sie Routen.

Wenn Sie dieselben Routen auf mehreren Seiten verwenden, sollten Sie Routengruppen verwenden. So vermeiden Sie unnötige Duplikate im Design Ihres KI-Agenten.

Intent-Wiederverwendung

Wenn Sie mehrere Intents mit ähnlichen Trainingsformulierungen definieren, sollten Sie Intents auf mehreren Seiten wiederverwenden. Idealerweise sollten Sie einige allgemeine Intents definieren, die auf vielen Seiten verwendet werden, und einige spezifische Intents, die nur auf einer einzigen Seite verwendet werden. So vermeiden Sie unnötige Duplikate im Design Ihres KI-Agenten.

Bestätigungs-Intents werden beispielsweise am besten als wiederverwendbare Intents definiert. Ein Intent confirmation.yes könnte Trainingsformulierungen wie die folgenden enthalten:

• Ja
• yeah
• yep
• Ok
• Ja, ich möchte das
• you bet
• absolut
• Ja, bitte

Ein Intent confirmation.no könnte Trainingsformulierungen wie die folgenden enthalten:

• no
• nah
• Nein
• no way
• 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, möchten Sie möglicherweise einen speziellen order.confirmation.yes-Intent mit Trainingsformulierungen wie den folgenden haben:

• die Reihenfolge sieht für mich gut aus
• Ich akzeptiere diese Bestellung

Und ein spezieller Intent order.confirmation.no mit Trainingsformulierungen wie:

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

Wenn die Seite zur Bestellbestätigung aktiv ist, sollten Intent-Routen für alle vier Intents im Bereich liegen. So wird sichergestellt, dass jede allgemeine oder spezifische Bestätigung des Endnutzers angemessen verarbeitet wird.

Standardmäßig auszuschließender Intent

Sie sollten den negativen Standard-Intent mit Formulierungen füllen, die Ihre Endnutzer möglicherweise verwenden, die aber mit keinem Intent in Ihrem Agenten übereinstimmen sollten.

Auftragsausführung

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

• Ausführung des Seiteneintrags: Diese Ausführung wird aufgerufen, wenn die Seite zum ersten Mal aktiv wird. Sie ist nützlich, wenn Sie eine Nachricht wünschen, die den Zweck der Seite beschreibt, und sie sollte nur einmal angesagt werden, 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 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 wünschen, die dem Endnutzer auf die Intent-Übereinstimmung, die erfüllte Bedingung (die eine Bedingung für das Ausfüllen des Formulars sein kann) oder den Übergang antwortet. Beispiel:
  • Ja, Japan ist in Ihrem internationalen Tarif enthalten. (Intent Match)
  • Möchten Sie wirklich 300 T-Shirts kaufen? (Vergleichsbedingung erfüllt)
  • Ok, dein Termin ist morgen früh um 7:00 Uhr. (form filling completion)
  • Okay, sprechen wir jetzt über Erdferkel. (Übergang)
• Event-Handler: Dieser Fulfillment wird aufgerufen, wenn ein Ereignis ausgelöst wird. Das ist nützlich, wenn Sie eine Nachricht wünschen, die auf das Ereignis reagiert. Beispiel:
  • Die Aktie, die Sie kaufen möchten, ist gerade um 10 % gestiegen. (benutzerdefiniertes Ereignis)
  • Können Sie das bitte anders formulieren? (Ereignis „Keine Übereinstimmung“)
• Erste Prompts für Formulare: Diese Ausführung wird aufgerufen, wenn der Agent das Formular ausfüllt. In diesen Nachrichten sollte dem Endnutzer eine bestimmte Frage gestellt werden. Jeder Formularparameter hat eine eigene Ausführung der ersten Aufforderung. Beispiel:
  • Welche Größe soll das Shirt haben?
  • Welche Farbe soll das Shirt haben?
• Nachfrage-Handler für Formulare: Diese Auftragsausfü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 Nachfrage von der ursprünglichen Aufforderung unterscheiden soll. Wenn keine Reprompt-Handler vorhanden sind, verwendet der Agent einfach den ursprünglichen Prompt als Reprompt-Nachricht. Beispiel:
  • Das habe ich nicht verstanden. Können Sie bitte eine gültige Farbe für das 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 Benennungsschema verwenden, mit dem Sie sie 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

In Zustands-Handlern definierte Übergänge ermöglichen die Steuerung der Unterhaltung durch Ändern der aktiven Seite. In diesem Abschnitt finden Sie Tipps zum Organisieren der Agentenübergänge.

Kostenlose Umstellungen

Wenn Sie eine Route definieren, die einen Übergang auslöst, sollten Sie berücksichtigen, dass es möglicherweise eine komplementäre 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 eine weitere Route mit != definieren.

Umgang mit Endnutzereingaben

In diesem Abschnitt finden Sie Richtlinien für Intents und Trainingsformulierungen, damit Ihr Agent Eingaben von Endnutzern optimal verarbeiten kann.

Mindestens 20 Trainingsformulierungen definieren

Sie sollten mindestens 20 Trainingsformulierungen für jeden Intent haben. Andernfalls hat das NLU-Modell möglicherweise nicht genügend Informationen, um Ihre Absicht richtig zuzuordnen. Dies ist eine Richtlinie für das absolute Minimum. Idealerweise sollten Sie mehr definieren, insbesondere für Head-Intents großer Agenten, bei denen etwa 50 wünschenswert sind.

Intent Bias beachten

Wenn ein oder mehrere Intents deutlich mehr Trainingsformulierungen als andere haben, führt dies dazu, dass das NLU-Modell aufgrund des Ungleichgewichts der Daten die größeren Intents bevorzugt. Eine Intent-Verzerrung kann auftreten, wenn sich die Anzahl der Trainingsformulierungen um ein Vielfaches unterscheidet.

In einigen Fällen ist dies erwünscht, da Sie möglicherweise Intents definieren, die häufiger als andere erkannt werden sollen, weil sie Eingaben von Endnutzerinnen und Endnutzern entsprechen, die im Live-Traffic häufiger auftreten.

In anderen Fällen ist dieses Verhalten möglicherweise unerwünscht, da Sie keine Verzerrung zugunsten dieser größeren Intents möchten. Dann sollten Sie die Anzahl der Trainingsformulierungen für diese größeren Intents reduzieren, sodass sie in der gleichen Größenordnung wie bei anderen Intents liegen. Beispiel:

Trainingsformulierungen für Intent A	Trainingsformulierungen für Intent B	Bias für Absicht B
20	50	Nein
20	200	Eventuell geöffnet
20	2000	Ja

Entitätsverwendung und Anzahl der Trainingsformulierungen

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

• Annotieren Sie alle Beispiele der 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 konversationell und natürlich sein und dem entsprechen, was Nutzer tatsächlich sagen. Verwenden Sie nach Möglichkeit Endnutzereingaben, die in der Produktion aufgetreten sind, als Trainingsdaten. Achten Sie dabei besonders auf die am häufigsten vorkommenden Eingaben.

Erforderliche Vielfalt an Trainingsformulierungen

Verwenden Sie verschiedene Varianten von Fragen, Befehlen, Verben und Synonymen für gängige Substantive, damit Ihre Formulierungen ein breites Spektrum möglicher Anfragen abdecken.

Es ist sinnvoll, sowohl kurze Formulierungen wie „Rechnung bezahlen“ als auch längere Formulierungen und Sätze wie „Ich habe gerade Post bekommen, in der steht, dass ich meinen Kontostand ausgleichen muss“ einzubeziehen. Es gibt kein empfohlenes Verhältnis von kurzen zu langen Wortgruppen. Sie sollten sich an den tatsächlichen Eingaben der Endnutzerinnen und Endnutzer orientieren, die in der Produktion bei Ihrem KI-Agenten eingehen.

Es ist wichtig, Trainingsformulierungen zu definieren, die sich in Länge, Formulierung und Satzstruktur unterscheiden, um ein gutes Training für Ihren Agenten zu gewährleisten. Es ist nicht notwendig, Vielfalt um der Vielfalt willen hinzuzufügen, aber es ist notwendig, genügend Vielfalt bereitzustellen, 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.

Groß- und Kleinschreibung

Die Berücksichtigung der Groß-/Kleinschreibung hängt davon ab, welches NLU-Modell Ihr Agent verwendet.

Standard-NLU

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

Alternative Ansätze könnten sein:

• ML-Klassifizierungsschwellenwert senken
• Eingaben von Endnutzern in Kleinbuchstaben umwandeln, bevor sie an Dialogflow CX gesendet werden.

Erweitertes NLU

Im Gegensatz zum Standard-NLU-Modell wird beim erweiterten NLU-Modell die Groß-/Kleinschreibung berücksichtigt. Wir empfehlen, die relevanten Trainingsdaten mit Großschreibung zu testen und hinzuzufügen, um die Übereinstimmungsraten für die Absicht zu erhöhen.

Unnötige Vielfalt an Trainingsformulierungen

Vermeiden Sie triviale Variationen in Trainingsformulierungen, da sie dem NLU-Modell doppelte Informationen liefern. Fügen Sie beispielsweise keine Varianten hinzu, die sich nur durch Folgendes unterscheiden:

• Groß-/Kleinschreibung: Wenn Sie das Standard-NLU-Modell verwenden, sollten Sie doppelte Wortgruppen wie „Bestelle ein Ticket“ und „bestelle ein Ticket“ vermeiden, außer in seltenen Fällen. Das erweiterte NLU-Modell unterscheidet jedoch zwischen Groß- und Kleinschreibung und erfordert mehr Trainingsformulierungen, um die Intent-Übereinstimmungen zu erhöhen. Weitere Informationen finden Sie im Abschnitt Varianten der Groß-/Kleinschreibung.
• Füllwörter: Beispiel: „Okay, bestell ein Ticket“ und „Bestell ein Ticket“.
• Satzzeichen: Beispiel: „Können Sie mir bitte helfen?“ und „Können Sie mir bitte helfen!?“

Konsistenz der Annotationen

Der für eine Annotation ausgewählte Teil der Trainingsformulierung sollte genau den Text umfassen, der zur Übereinstimmung mit einer Entität erforderlich ist, also weder mehr noch weniger Wörter. Achten Sie außerdem darauf, dass ähnliche Teile von Trainingsformulierungen für den gesamten Intent annotiert sind.

In der folgenden Tabelle finden Sie beispielsweise gute und schlechte Möglichkeiten, mit der Systementität @sys.date zu annotieren:

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

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

Die semantische Bedeutung eines für eine Annotation ausgewählten Teils einer Trainingsphrase kann durch den restlichen Text in einer Trainingsphrase beeinflusst werden. Beispiel:

Annotierte Trainingsformulierung	Semantische Bedeutung des annotierten Textes
Ich bin 7 Jahre alt	Das Alter einer Person
Der Vertrag ist 7 Jahre gültig.	Eine Zeitdauer

Die Machine-Learning-Modelle von Dialogflow CX berücksichtigen die semantische Bedeutung beim Abgleich von Systementitäten. Die semantische Bedeutung des Teils der Trainingsformulierung muss mit der beabsichtigten semantischen Bedeutung der Systementität übereinstimmen.

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 nicht 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 Antworten beim Ausfüllen von Formularen zu verarbeiten

Sie können Intents definieren, um nicht konforme Antworten beim Ausfüllen von Formularen zu verarbeiten. Beispiel: Der Agent fragt: „Wann möchten Sie reisen?“ Der Endnutzer antwortet: „Das weiß ich noch nicht.“ Diese Antwort erfüllt nicht die Aufforderung für den Formularparameter. Wenn Ihr Agent jedoch eine Intent-Route im Bereich hat, die mit dieser Antwort übereinstimmt, 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 mit diesem Entitätstyp annotieren, da dies zu Mehrdeutigkeiten führt und das Verhalten des KI-Agenten nicht definiert ist.

Es ist weniger gefährlich, @sys.any mit Formularparametern zu verwenden, da der Agent bestimmte Informationen erwartet, wenn er nach Formularparametern fragt.

Hinweis: Einige Systementitäten sind nicht verfügbar, wenn Sie Ihre Agentenbereitstellung regionalisieren. Manchmal wird @sys.any als Behelfslösung empfohlen.

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. Sie sollten nicht immer dasselbe Entitätsbeispiel für die Annotationen verwenden. Das folgende Beispiel zeigt gute und schlechte Annotationen für einen Produktentitätstyp:

Gut	Fehlerhaft
Ich möchte ein Hemd kaufen.	Ich möchte ein Hemd kaufen.
Bestelle einen neuen Hut	Bestelle ein neues Hemd
Füge meinem Einkaufswagen eine Smartwatch hinzu	Füge ein Hemd meinem Einkaufswagen hinzu

Benutzerdefinierte Entitäten sollten vielfältig sein

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

Entitäten vermeiden, die aggressiv abgeglichen werden

Definieren Sie keine Entitäten, die praktisch allgemeingültig sind. Das beeinträchtigt die Leistung und Qualität von ML. Fast alles in jedem Trainingssatz wird als mögliche Übereinstimmung bewertet.

Map- und Listenentitäten sollten sich auf unterschiedliche Werte konzentrieren.

Entitätstypen für Zuordnungen und Listen sollten einen begrenzten Umfang haben, der eindeutige Werte eines Informationstyps erfasst. Halten Sie Ihre Entitäten prägnant, kurz und einfach.

Wenn Ihre Entitätswerte kompliziert sind, liegt das möglicherweise daran, dass Intent-Trainingsformulierungen besser für Ihre Situation geeignet sind. Beispiel für eine Endnutzereingabe:

• „Wie kann ich mit Tarif A einen internationalen Anruf tätigen?“
• „Ich nutze internationales Daten-Roaming mit Tarif B.“

Erstellen Sie keine Entitätstypen für die Aktionen und die Pläne, wie im folgenden Beispiel:

Entitätstyp „Aktionen“	Entitätstyp „Pläne“
„Wie kann ich einen internationalen Anruf tätigen?“	„Plan A“
„Internationales Daten-Roaming verwenden“	„Plan B“

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

RegEx-Entitäten verwenden, um nicht wortbasierte Kennungen zu erfassen

Wenn Sie Eingaben von Endnutzern erfassen, die nicht wortbasierte Kennungen enthalten, sollten Sie RegEx-Entitäten verwenden. Wenn Sie beispielsweise Produkt-IDs wie „AA-256“ oder „AC-436“ erfassen möchten, verwenden Sie eine Regex-Entität wie „[A-Z]{2}-\d{3}“.

Verschachtelung zusammengesetzter 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 Nutzerabsicht 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 Absicht darstellen, sollten sie zum selben Intent gehören. Beispiel: „Fälligkeitsdatum der aktuellen Rechnung ändern“ und „mehr Zeit zum Bezahlen“ sollten beide zur selben Intent gehören, da beide eine Änderung des Fälligkeitsdatums anfordern. „Kann ich mit Tarif A ins Ausland telefonieren?“ und „Kann ich mit Tarif A internationales Daten-Roaming nutzen?“ könnten jedoch zu unterschiedlichen Intents gehören, da der Endnutzer in jedem Fall etwas anderes möchte.

Ähnliche Entitätstypen vermeiden

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

Ereignisse ohne Übereinstimmung in der Produktion verwenden, um Ihre Intents zu verbessern

Wenn Sie Ihren Agenten in der Produktion ausführen, ist es unvermeidlich, dass einige Endnutzereingaben zu Ereignissen ohne Übereinstimmung führen. Sie können diese Möglichkeiten nutzen, um Ihren Agenten auf eine der folgenden drei Arten zu verbessern:

• Fügen Sie die Eingabe des Endnutzers als Trainingsformulierung zum gewünschten Intent hinzu. Das ist jedoch nicht immer die beste Option. Wenn Sie dies für den Intent oft tun, kann dies zu einer Intent-Verzerrung führen.
• Bereinigen Sie die Trainingsformulierungen für den gewünschten Intent, sodass sie alle die Intention genau widerspiegeln. In einigen Fällen können Intents mit Trainingsformulierungen, die voneinander abweichen, eine Zuordnung für den Intent verhindern.
• Wenn Intents, die nicht mit der Endnutzereingabe übereinstimmen sollten, Trainingsformulierungen haben, 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, ohne dass der Text dadurch unverständlich wird. 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 die Eingabe des Endnutzers verarbeitet wird. In den meisten Fällen funktionieren die Standardeinstellungen gut. Möglicherweise möchten Sie die Einstellungen jedoch optimieren, um die Leistung Ihres KI-Agenten zu verbessern.

Dem Endnutzer antworten

In diesem Abschnitt finden Sie Richtlinien zur Verwendung der Auftragsausführung, um auf die Endnutzerin oder den Endnutzer zu reagieren.

Endnutzer begrüßen

Ein neu erstellter Agent hat eine automatisch erstellte Intent-Route für den Willkommens-Intent. Sie sollten diese Route so bearbeiten, dass sie eine Ausführungsnachricht enthält, die den Endnutzer begrüßt. Diese Nachricht sollte den Agenten beschreiben und dem Endnutzer einen Eindruck davon vermitteln, was er kann.

Informationen für Endnutzer bestätigen

Es ist oft am besten, die von Endnutzerinnen und ‑nutzern bereitgestellten Informationen in Antworten zu wiederholen. So weiß der Endnutzer, dass der KI-Agent seine Anfrage versteht.

Wenn ein Intent erkannt wird und ein Übergang erfolgt, teilen Sie dem Endnutzer mit, dass die Unterhaltung basierend auf 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 hat zu einer Intent-Übereinstimmung geführt und es wurde eine Route verfolgt, die eine Ausführungsnachricht und einen Übergang zu einer Seite enthielt, auf der Fragen zum Girokonto behandelt werden. Der Kundenservicemitarbeiter bestätigt, dass der Endnutzer Informationen zu seinem Girokonto erhalten möchte.

Wenn das Formular ausgefüllt ist, wiederholen Sie die vom Endnutzer angegebenen 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 Formularparameter für das Datum angegeben, der der letzte Formularparameter auf der aktiven Seite war. Der Agent hat die Uhrzeit und das Datum eines geplanten Haarschnitts bestätigt.

Einstieg in die Unterhaltung

Der KI-Agent sollte die Unterhaltung mit dem Endnutzer immer steuern. Das lässt sich ganz einfach erreichen, indem Sie jede Antwort mit einer Frage beenden, wie:

• Kann ich sonst noch weiterhelfen?
• Was möchtest du über Beagles wissen?
• Möchtest du die Bestellung stornieren oder aufgeben?
• Wobei kann ich dir helfen?
• Reisen Sie allein oder mit jemandem?

Achten Sie beim Formulieren dieser Fragen darauf, dass Sie nicht mehrere Fragen stellen, wie z. B.:

• Sind Sie noch hier? Für welchen Dienst interessieren Sie sich?
• Möchten Sie diese Bestellung trotzdem? Möchten Sie noch etwas hinzufügen?

Der Endnutzer antwortet möglicherweise nur auf eine der Fragen und Ihr 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 Eingaben von Endnutzern.

Event-Handler für integrierte Ereignisse erstellen

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

Webhook-Fehler beheben

Wenn Ihr Webhook-Dienst fehlschlägt, ist es wichtig, dass Ihr Agent den Fehler ordnungsgemäß verarbeiten kann. Dazu definieren Sie Ereignis-Handler für die webhookspezifischen integrierten Ereignisse. Hier ist ein empfohlener Ansatz für den Umgang mit Webhook-Fehlern:

• Geben Sie kein Übergangsziel aus dem Zustandshandler an, der den Webhook-Aufruf auslöst. Andernfalls wird der Webhook-Fehler-Ereignis-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 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 mithilfe einer Ausführungsparameter-Voreinstellung auf 0 initialisieren. Beispiel:

  Parameter	Wert
  webhook-error-count	0

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

  • Die Eingabeausführung sollte den Fehler für den Endnutzer bestätigen und einen Sitzungsparameter für den Fehlerzähler mithilfe einer Voreinstellung für den Ausführungsparameter erhöhen. 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 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 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 unternehmen kann.

  • Definieren Sie eine Bedingungsroute mit einer Bedingung, dass die Fehleranzahl größer als die maximal zulässige Anzahl ist (z. B. $session.params.webhook-error-count > 3). Diese Route sollte eine Ausführung haben, die den Endnutzer darüber informiert, dass der Agent es nicht noch einmal versucht. Für diese Route sollte ein Übergangsziel auf eine Seite festgelegt werden, die keine Webhook-Wiederholungen auslöst.

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

Tools

In diesem Abschnitt finden Sie Tipps zur Verwendung von Tools, um das Design von KI-Agenten zu verbessern.

Validierungstool verwenden

Sie sollten Ihren Agent immer mit dem Validierungstool prüfen. Dieses Tool findet einige der in diesem Leitfaden beschriebenen Probleme.

Testläufe verwenden

Sie sollten immer Testfälle für Ihren Agenten definieren. Diese Testfälle können dazu beitragen, Regressionen zu verhindern, während Ihr Agent weiterentwickelt wird, um mehr Szenarien zu verarbeiten.