Woher kommt die Wartezeit bei einem KI-basierten Telefonsystem?
Nachdem der Anruf zunächst über die Telefonleitung und die SIP/PBX-Route geleitet wurde, gelangt die Sprache an ein Sprachverarbeitungsmodul. Das System muss dann feststellen, ob der Anrufer seine Aussage beendet hat, und anschließend die entsprechenden Unternehmenswerkzeuge anhand eines Modells aufrufen. Abschließend wird die Antwort in Sprache umgewandelt und an das Telefon zurückgesendet. Wenn eine Abfrage in einem CRM-System oder die Erstellung eines Tickets erforderlich ist, entsteht eine Verzögerung, die als wahrnehmbare Verzögerung empfunden wird. Nur der erste Token des Modells wird berücksichtigt, wodurch der tatsächliche Pfad, den der Anrufer erlebt, ignoriert wird.
End-to-End-Analyse der Latenz bei KI-gestützter Sprachdienstleistung| Phase | Messbeginn und -ende | Häufige Risiken |
|---|
| Telefonübertragung | Anruf- und Sprachplattform für den Einstieg und Austritt | Datenübertragung über Telefonleitungen, Dekodierung, Netzwerkstörungen und Paketverluste |
| Bogenidentifizierung | Der Benutzer muss aufhören zu sprechen, bis das System den Abbruch bestätigt. | Zu lange warten oder zu früh aufhören. |
| Beispielantwort | Senden einer gültigen Eingabe, um Inhalte zu generieren, die abgespielt werden können. | Lange Kontexte, Modellwahl und komplexe Schlussfolgerungen |
| Anruf zur Werkzeugbestellung | API verwenden, um verfügbare Ergebnisse abzurufen. | Unternehmenssysteme: Umgang mit Timeout, Wiederholungsversuchen und Warteschlangen |
| Audio-Wiedergabe | Der Text oder die Audio-Datei wird von der Quelle (z. B. Computer, Smartphone) an das Telefon gesendet und dort abgespielt. | Synthetische Pufferung, Wartefunktion beim ersten Start und Abspielen stoppen |
VAD löst das Problem der Erkennung von „Sprechen oder Stille“; die Erkennung basiert auf der Frage, „ist die Rede beendet?“
Der VAD-Server bestimmt in der Regel, wann eine Sprache beginnt und endet, basierend auf Lautstärke und Stille. Ein semantischer VAD schätzt zusätzlich, ob die Bedeutung noch nicht vollständig ausgedrückt wurde. Eine längere Wartezeit kann das Abschneiden reduzieren, erhöht aber auch die Pausen. Eine zu schnelle Reaktion kann dazu führen, dass Sätze wie „Ähm… ich möchte das ändern“ in zwei Teile getrennt werden. Die Parameter können nicht für alle Fälle gleich verwendet werden. Für Namen, vollständige Adressen, Codes und offene Beschreibungen sind unterschiedliche Toleranzwerte für Pausen erforderlich.
"Barge-in" bezieht sich auf das Unterbrechen eines Gesprächs, bedeutet aber nicht, dass die Gesprächsrunde beendet ist.
"Barge-in" ermöglicht es dem Anrufer, während der KI-Ausgabe zu unterbrechen und die ursprüngliche Antwort zu beenden. Dies ist nützlich, um Informationen zu korrigieren, über bereits bekannte Inhalte zu springen oder die Menüstruktur zu verkürzen. Dabei ist zu beachten, dass "Barge-in" und die automatische Erkennung, dass der Benutzer fertig ist, zwei unterschiedliche Funktionen sind. In der Regel sollten Unterbrechungen erlaubt sein; die Entscheidung, ob eine Aufzeichnung, eine notwendige Information oder eine wichtige Feldabfrage unterbrochen werden darf, sollte jedoch auf den spezifischen Unternehmensprozessen und den rechtlichen Anforderungen basieren. Das globale Deaktivieren von "Barge-in" kann zu einer langsameren Kommunikation führen, während die globale Aktivierung möglicherweise dazu führt, dass wichtige Inhalte nicht vollständig abgespielt werden.
Konzentrieren Sie sich nicht nur auf den durchschnittlichen Latenzwert, sondern berücksichtigen Sie auch die p50-, p95- und die Fehlerraten.
Der Durchschnittswert kann durch wenige, sehr langsame oder sehr schnelle Beispiele verzerrt werden. p50 gibt einen Überblick über die typischen Gesprächsdauer, während p95 die längeren, aber dennoch häufigen Ausnahmen betrachtet. Zusätzlich werden Informationen darüber aufgezeichnet, wie lange ein Benutzer mit dem Sprechen wartet, bis eine Antwort erfolgt, wie lange das Tool benötigt, um eine Aufgabe abzuschließen, ob es zu Fehlern kommt, wie lange auf eine Antwort gewartet werden muss und ob Unterbrechungen erfolgreich waren. Jedes Beispiel muss außerdem mit Informationen über die Aufgabe, die Netzwerkverbindung, die Sprache und die Verwendung des Unternehmens-APIs versehen werden. Andernfalls würden die verschiedenen Szenarien vermischt und es wäre unmöglich, das Problem zu identifizieren.
Verzögerungen und Drehzeiten sollten zusammen erfasst werden.| Beobachtungspunkte | Ereignisdefinition | Verwendungszweck |
|---|
| Die erste Antwort verzögert sich. | Bestätigung, dass der Vorgang abgeschlossen ist, bis der Benutzer eine Antwort erhält. | Unterscheidung nach Reihenfolge, Modellen und Wartezeiten |
| Das Werkzeug wartet | Die API stellt die Ergebnisse zur Verfügung. | Identifizieren Sie Engpässe in Unternehmenssystemen oder bei Drittanbietern. |
| Fehlerhafte Abschneidung | Der Nutzer hat begonnen zu antworten, bevor er die ursprüngliche Frage vollständig gestellt hatte. | Anpassen der VAD-Strategie, der Spalten- und Zeilenstrategie |
| Fehlerwartung | Der Benutzer hat seine Eingabe abgeschlossen, aber das System bleibt stumm. | Überprüfung abschließen, Überprüfung abgelaufen und Werkzeugstatus |
| Der Kommentar wurde erfolgreich veröffentlicht. | Nachdem der Benutzer geantwortet hat, wird die ursprüngliche Antwort gestoppt und die neue Eingabe beibehalten. | Überprüfung der Konsistenz zwischen der Abspielaktion und dem Kontext. |
Für die realistischen Telefontests sind Geräusche, Echo, Akzente und lange Felder erforderlich.
Ein Mikrofon, das in einem ruhigen Büro verwendet wird, kann die Qualität von Anrufen über Mobiltelefone, im Auto, Headsets, Bluetooth-Kopfhörern oder Festnetztelefonen nicht repräsentieren. Der Test sollte mindestens folgende Aspekte abdecken: Hintergrundgeräusche, Echo, Signalstörungen, unterschiedliche Sprechgeschwindigkeiten, typische Akzente, Zahlen, alphanumerische Zeichen und lange Adressen. Ziel ist es, nicht nur die korrekte Wiedergabe, sondern auch die Möglichkeit des Systems zu überprüfen, die Informationen wiederzugeben und dem Benutzer die Möglichkeit zu geben, Fehler zu korrigieren. Wenn die Genauigkeit weiterhin unsicher ist, soll der Test gestoppt werden.
Wenn Sie lange auf eine Antwort warten, füllen Sie die Stille nicht mit falscher Bestätigung.
CRM-, ERP- oder Auftrags-APIs können mehrere Sekunden oder sogar einen asynchronen Prozess benötigen. Das System kann durch kurze Statusmeldungen für eine gewisse Klarheit sorgen, aber nicht vor dem Rückgab der Ergebnisse sagen, dass die Aufgabe abgeschlossen ist. Wenn die akzeptable Zeit im Gespräch überschritten ist, sollte ein Status "Warten auf Bestätigung" oder eine manuelle Bearbeitung eingerichtet werden, und eine eindeutige Kennung sollte verwendet werden, um eine erneute Ausführung zu vermeiden. Eine Optimierung der Verzögerung, die die Genauigkeit der Ergebnisse beeinträchtigt, führt lediglich dazu, dass der Fehler schneller kommuniziert wird.
„3 Sekunden“ kann lediglich ein Designziel sein, und nicht eine von GoGoCha öffentlich kommunizierte Service Level Agreement (SLA).
Die öffentlich zugänglichen Fallstudien von GoGoCha belegen die Funktionalität des Telefons als Zugangspunkt und des Echtzeit-Dispatch-Workflows, aber es gibt keine öffentlich verfügbaren Informationen über die End-to-End-Latenzverteilung, die Telekommunikationsumgebung, Gesprächsbeispiele oder SLAs. Produktziele sollten nicht als bereits erreichte Service-Level formuliert werden, ohne dass die gleichen Ereignisse definiert und tatsächlich gemessen wurden. Unternehmen sollten die p50-, p95- und Fehlerraten unter ihren eigenen PBX/SIP-, API- und Spitzenbedingungen neu definieren.
