Empfehlungen und Einschränkungen zur Erstellung von Virtual Agent-Slots

• Entitäten, die den festgelegten maxLength-Wert überschreiten, werden nicht akzeptiert. Wenn beispielsweise der Entitätswert „123456“ lautet, die max. Länge auf 7 eingestellt ist und der Kunde „78“ sagt, dann behandelt der Bot die neue Entität als „noMatch“, da die neu extrahierte Entität „12345678“ ist und die Länge jetzt 8 beträgt, und behält den Rest als „123456“ bei.
• Korrektur von Fällen, die nicht explizit sind oder sich im mittleren Teil der extrahierten Entität befinden. In den folgenden Beispielen war die zuvor extrahierte Entität 1299554464.
  
  Beispiele für funktionierende Korrekturen:
  • „Keine Änderung der letzten beiden Ziffern von 64 auf 62“
  • „Die letzten beiden Ziffern sollten 62 sein“

Beispiel für nicht funktionierende Korrekturen :

• • „Nr. 62.“ Der LLM kann nicht feststellen, was geändert werden soll.
  • „Nein, ich meinte 62.“ Der LLM kann nicht feststellen, was geändert werden soll.
  • „Ändern Sie 55 in 44.“ Dieser Eintrag ist für das LLM schwer zu bestimmen, da er sich in der Mitte der Entität befindet.
  • „Die Entität sollte mit einer 5 beginnen.“ Möglicherweise fügt das LLM am Anfang eine 5 hinzu oder korrigiert „1299554464“ erwartungsgemäß in „5299554464“.

• Mit größeren Zahlenwerten hat das LLM keine Probleme, allerdings erhöht sich dadurch die Wahrscheinlichkeit einer schwierigeren Korrektur. Größere numerische Werte sind am Anfang oder in der Mitte des Wertes schwieriger zu korrigieren. Aufgrund dieser Einschränkung empfiehlt Genesys die Verwendung mehrerer Steckplätze. Wenn also eine Kreditkartennummer extrahiert wird, fordern Sie die Daten in 4-stelligen Blöcken an. Eventuelle Fehler treten innerhalb der letzten vier Ziffern auf, was die Korrektur erleichtert.

Fälle, die gut funktionieren, sind:

• Einfache Ziffernextraktion aller Längen. Beispiel: „Meine Kreditkartennummer ist 0123456789012232.“
• Ziffernextraktion über mehrere Runden mit Ziffern im lexikalischen Format. Zum Beispiel:
  • Teilnehmer: „Meine Karte beginnt mit 0011“ Bot: „Ich habe bisher 0011 bekommen, bitte fahren Sie fort.“
  • Teilnehmer: „Dann 7831“<i class=”fa-sharp fa-regular fa-arrow-right”></i> „Ich habe bisher die Nummer 0011 7831 erhalten, bitte fahren Sie fort.“
  • Teilnehmer: „Sieben eins doppel null“<i class=”fa-sharp fa-regular fa-arrow-right”></i> „Ich habe bisher die Nummer 0011 7831 7100 erhalten, bitte fahren Sie fort.“
  • Teilnehmer: „Endlich, 3333“<i class=”fa-sharp fa-regular fa-arrow-right”></i> „Ich habe 0011 7831 7100 3333, ist das richtig?“
• Explizite Korrekturen; zum Beispiel: „Ändern Sie die letzten beiden Ziffern von 84 in 82.“
• Das LLM behandelt „Double“ als zwei von allem, was danach kommt; zum Beispiel doppelte 2 = 22. Die ASR sollte diese Antwort zunächst in 22 umwandeln. „Triple“/„Treble“ sind drei dieser Ziffern und „Quadruple“ sind vier.
• Das LLM behandelt „Oh“ in erwarteten Situationen als „0“, nicht in unerwarteten Situationen wie „Oh, Entschuldigung, das meinte ich.“

• Entitäten, die den festgelegten maxLength-Wert überschreiten, werden nicht akzeptiert. Wenn beispielsweise der Entitätswert „A12345“ lautet, die max. Länge auf 7 festgelegt ist und der Kunde „67“ sagt, dann behandelt der Bot die neue Entität als „noMatch“ und behält die Entität „A12345“, da die neu extrahierte Entität „A1234567“ ist und die Länge jetzt 8 beträgt.
• Über mehrere Runden hinweg duplizierte Zeichen. Wenn in Runde 1 die extrahierte Entität „AB78G“ ist und der Kunde in der nächsten Runde mit einem anderen „g“ beginnt, kann das LLM fälschlicherweise „AB78G“ statt „AB78GG“ zurückgeben.
• Mehrdeutige Korrekturen. Zum Beispiel: „Nein, ich habe AZ gesagt.“ Zu einer mehrdeutigen Korrektur kann es kommen, wenn der Kunde in Runde 1 „A wie Apfel, C 72“ sagt, was als „AC72“ extrahiert wird; in der nächsten Runde kann er dann eine schwierige Korrektur vornehmen, wie etwa „Nein, ich habe AZ gesagt.“
• Das LLM hat keine Probleme mit größeren alphanumerischen Werten. Allerdings erhöht sich dadurch die Wahrscheinlichkeit einer schwierigeren Korrektur. Größere numerische Werte sind am Anfang oder in der Mitte des Wertes schwieriger zu korrigieren. Aufgrund dieser Einschränkung empfiehlt Genesys die Verwendung mehrerer Steckplätze. Wenn also eine Passnummer extrahiert wird, fordern Sie die Daten in 3-Zeichen-Blöcken an. Eventuelle Fehler treten innerhalb der letzten 3 Ziffern auf, was die Korrektur erleichtert. 

Fälle, die gut funktionieren, sind:

• Alphanumerische Extraktion aller Längen mit phonetischer Schreibweise von Buchstaben, vereinfachten Buchstaben und Ziffern. Beispiel: „Meine Passnummer ist A für Apple, B für Beta, C für Charlie, D 8909.“
• Alphanumerische Extraktion über mehrere Durchläufe mit Ziffern im lexikalischen Format, zum Beispiel:
  • Teilnehmer: „Meine Mitgliedsnummer beginnt mit AB11“ Bot: „Ich habe bisher AB11 bekommen, bitte fahren Sie fort.“
  • Teilnehmer: „Dann C wie Charlie und Z wie Zeta“ Bot: „Ich habe bisher AB11 CZ bekommen, bitte fahren Sie fort.“
  • Teilnehmer: „beta alpha“ Bot: „Ich habe bisher AB11 CZ BA, bitte fahren Sie fort.“
  • Teilnehmer: „Endlich 99“ Bot: „Ich habe AB11 CZ BA 99, ist das richtig?“
• Explizite Korrekturen. Beispiel: „Nein, der letzte Buchstabe hätte Z für Zeta sein müssen, nicht c.“
• Das LLM behandelt „Double“ als zwei von allem, was danach kommt; zum Beispiel doppelte 2 = 22. Die ASR sollte diese Antwort zunächst in 22 umwandeln. „Triple“/„Treble“ sind drei dieser Ziffern und „Quadruple“ sind vier.
• Das LLM behandelt „Oh“ in erwarteten Situationen als „0“, nicht in unerwarteten Situationen wie „Oh, Entschuldigung, das meinte ich.“

• Adressen
  • Adressformat gemäß länderspezifischen Standards. Der Bot-Teilnehmer muss sich auf die von Ihnen bereitgestellte Beschreibung verlassen, um das richtige Format sicherzustellen.
  • Gehäuse: Normalerweise wird die Groß- und Kleinschreibung korrekt verwendet. Es kann jedoch vorkommen, dass das extrahierte Entity entweder vollständig in Kleinbuchstaben oder vollständig in Großbuchstaben zurückgegeben wird.
• E-Mails
  • Falsche Identifizierung von benutzerdefinierten Domänennamen bei Multiturn-Konversationen. Häufigere und genauere Rückgaben sind möglich, wenn die E-Mails in einer einzigen Runde bereitgestellt werden.
  • Fälle, in denen ASR-Transkriptionen Bindestriche, Punkte und Unterstriche nicht konvertieren können.
• Names
  • Beim Ausschreiben langer Namen fehlen oder werden Zeichen umgestellt.

Die Modellausgabe nach jedem Aufruf enthält zwei Teile: die extrahierte Entität und einen Booleschen Wert, der angibt, ob die Extraktion abgeschlossen ist oder nicht und ob der Status der Entitätserkennung „in Bearbeitung“ oder „abgeschlossen“ ist. Für die Freiform verwendet der Bot die bereitgestellte Beschreibung.

• Anhand der Beschreibung beurteilt das Modell, ob die Entität erfasst ist oder ob in der Beschreibung erwähnte Teile fehlen. Eine Beschreibung sollte im Idealfall enthalten, worum es bei der Entität geht und welche anderen Unterentitäten oder Teile einer Entität sie enthalten muss.
• Auch ein Vorspulen ist möglich. Wenn der Kunde explizit etwas Ähnliches sagt wie:  „Ich bin fertig, das ist es, das ist alles, ich habe es nicht, ich weiß nicht“ und so weiter, ändert sich der Extraktionsstatus auf „Abgeschlossen“ und überschreibt die Unterentitätssammlung basierend auf der Beschreibung.

In diesen Beispielen ist der Slot „person_name“, um den Vor- und Nachnamen einer Person zu beschreiben. 

• Der Bot-Teilnehmer erwähnt konkret, welcher Teil der Entität bereitgestellt wird.

Klicken Sie auf das Bild, um es zu vergrößern.

• Der Bot-Teilnehmer gibt nur im ersten Zug an, welcher Teil des Namens angegeben wird. Das Modell geht davon aus, dass die nächste Unterentität, die der Bot-Teilnehmer angibt, der Nachname ist.

Klicken Sie auf das Bild, um es zu vergrößern.

• Es werden beide Unterentitäten gleichzeitig bereitgestellt und der Status ändert sich nach dem ersten Durchgang auf „Abgeschlossen“.

Klicken Sie auf das Bild, um es zu vergrößern.

• Der Status bleibt in „In Bearbeitung“, da der Bot-Teilnehmer angibt, dass es sich bei der bereitgestellten Entität um einen zweiten Vornamen handelt, der in der Beschreibung nicht erwähnt wird. Bei der nächsten vom Bot-Teilnehmer bereitgestellten Entität wird erwartungsgemäß davon ausgegangen, dass es sich um den Nachnamen handelt.

Klicken Sie auf das Bild, um es zu vergrößern.

• Obwohl der Bot-Teilnehmer dies nicht angibt und „van der“ als Nachname angenommen werden sollte, ist dies wahrscheinlich nicht der Fall, da „van der“ ein häufig verwendetes Nachnamenpräfix und kein tatsächlicher Nachname ist.

Klicken Sie auf das Bild, um es zu vergrößern.

In diesen Beispielen lautet der Slot „delivery_address“, um eine Lieferadresse einschließlich Hausnummer und PIN-Code zu beschreiben. 

• Das Gespräch bleibt bestehen, bis sowohl die Hausnummer als auch der PIN-Code angegeben sind; fügt am Anfang der Adresse die Hausnummer und am Ende den PIN-Code hinzu.

Klicken Sie auf das Bild, um es zu vergrößern.

• Obwohl kein PIN-Code angegeben wurde, ändert sich der Status auf „Abgeschlossen“, da der Bot-Teilnehmer angibt, dass er fertig ist. Dieser Status wird nicht eintreten, wenn der Teilnehmer nicht „das war‘s“ sagt und erst mit der Eingabe eines PIN-Codes wird der Status auf „abgeschlossen“ gesetzt.

Klicken Sie auf das Bild, um es zu vergrößern.

Diese Beispiele beschreiben Szenarien für ein vorzeitiges Verlassen des Bereichs für einen Lieferadressen-Slot, der eine Lieferadresse mit einer Hausnummer und einem PIN-Code beschreibt.

• Beispiel 1 Beispiel für einen vorzeitigen Ausstieg

Klicken Sie auf das Bild, um es zu vergrößern.

• Beispiel 2: Beispiel für einen vorzeitigen Ausstieg.

Klicken Sie auf das Bild, um es zu vergrößern.

• Beispiel 3: Beispiel für einen vorzeitigen Ausstieg.

Klicken Sie auf das Bild, um es zu vergrößern.

• Beispiel 4: Beispiel für einen vorzeitigen Ausstieg.

Klicken Sie auf das Bild, um es zu vergrößern.

Informationen zu Beispielkonversationen, die die Funktion der Freiform-Sloterfassung demonstrieren, finden Sie unter Beispiele für die Erfassung von Freiform-Slots .