Wie optimieren Sie die Latenz für Conversational AI?

Bei den meisten Anwendungen ist die Latenz kein großes Problem. Bei der Konversations-KI ist es jedoch die Latenz, die gute von großartigen Anwendungen unterscheidet.

Zunächst einmal ist das Ziel der Konversations-KI recht anspruchsvoll: Sie soll dasselbe Gefühl, denselben Tastsinn und dieselbe Stimme wie bei einer menschlichen Konversation bieten und dabei die Intelligenz eines Menschen übertreffen. Um dies zu erreichen, muss eine Anwendung ohne lange Pausen kommunizieren. Andernfalls wird der Realismus zerstört.

Die Latenzprobleme der Konversations-KI werden durch ihren stückweisen Charakter noch verschärft. Konversations-KI ist eine Reihe von Zwischenprozessen, die alle in ihren jeweiligen Bereichen als hochaktuell gelten. Jeder dieser Prozesse verursacht eine zusätzliche Latenz.

Als Unternehmen für generative Spracherkennung haben wir lange Zeit untersucht, wie die Latenz für Konversations-KI minimiert werden kann. Heute möchten wir unsere Erkenntnisse weitergeben, in der Hoffnung, dass sie für jeden hilfreich sind, der an der Entwicklung von Konversations-KI-Anwendungen interessiert ist.

Die vier Kernkomponenten

Jede Konversations-KI-Anwendung umfasst mindestens vier Schritte: Sprache-zu-Text, Sprecherwechsel, Textverarbeitung (d. h. LLMs) und Text-zu-Sprache. Obwohl diese Schritte parallel ausgeführt werden, verursacht jeder Schritt dennoch eine gewisse Latenz.

Insbesondere die Latenzgleichung der Konversations-KI ist einzigartig. Viele Prozesslatenzprobleme können auf einen einzigen Engpass reduziert werden. Wenn beispielsweise eine Website eine Datenbankanforderung stellt, bestimmt die Netzwerklatenz des Webs die Gesamtlatenz, während die VPC-Latenz des Back-Ends nur unwesentlich dazu beiträgt. Die Latenzkomponenten der Konversations-KI variieren jedoch nicht drastisch. Sie sind ungleichmäßig, aber der Latenzbeitrag jeder Komponente liegt innerhalb eines Grades der anderen. Dementsprechend wird die Latenz durch die Summe mehrerer Teile bestimmt.

Automatische Spracherkennung

Das „Ohr“ des Systems

Automatische Spracherkennung (ASR) – manchmal auch als Sprache-zu-Text (STT) bezeichnet – ist der Prozess der Umwandlung gesprochener Audiodaten in geschriebenen Text.

Die Latenz von ASR ist nicht die Zeit, die zum Generieren von Text benötigt wird. Der Spracherkennungsprozess läuft im Hintergrund, während der Benutzer spricht. Stattdessen ist die Latenz die Zeit zwischen dem Ende der Rede und dem Ende der Textgenerierung.

Dementsprechend können kurze und lange Sprechintervalle eine ähnliche ASR-Latenz verursachen. Und da Spracherkennungsmodelle relativ optimiert sind, beträgt die Latenz, einschließlich des Netzwerk-Roundtrips, normalerweise weniger als 100 ms. (In manchen Fällen gibt es überhaupt keine Netzwerklatenz, da das Modell im Browser eingebettet ist, wie Chrome/Chromium$

Sprecherwechsel / Unterbrechung

Der „Instinkt“ des Systems

Turn-Taking/Interruption (TTI) ist ein Zwischenprozess, der bestimmt, wann ein Benutzer mit dem Sprechen fertig ist. Das zugrunde liegende Modell wird als Voice Activity Detector (oder VAD) bezeichnet.

Beim Abwechseln kommt ein komplexer Regelsatz zum Einsatz. Ein kurzer Redeschwall (z. B. „ähm“) sollte keinen Redewechsel auslösen, sonst würde sich das Gespräch zu abgehackt anfühlen. Stattdessen muss es beurteilen, wann ein Benutzer tatsächlich versucht, die Aufmerksamkeit des Modells zu erregen. Außerdem muss ermittelt werden, wann der Benutzer mit der Übermittlung seiner Gedanken fertig ist.

Ein guter VAD wird nicht signalisieren Sie eine neue Abbiegung, wenn es Stille erkennt. Zwischen den Wörtern (und Sätzen) herrscht Stille, und das Modell muss sicher sein, dass der Benutzer tatsächlich mit dem Sprechen fertig ist. Um dies zuverlässig zu erreichen, muss eine Schwelle der Stille (oder genauer gesagt, des Fehlens von Sprache) gefunden werden. Dieser Vorgang erzwingt eine Verzögerung, die für den Benutzer eine Latenz bedeutet.

Technisch gesehen, wenn alle anderen Konversations-KI-Komponenten null Latenz, die TTI zugeschriebene Latenz wäre eine gute Sache. Menschen warten einen Moment, bevor sie auf Sprache reagieren. Eine Maschine, die eine ähnliche Pause macht, verleiht der Interaktion Realismus. Da jedoch bei anderen Komponenten der Konversations-KI bereits Latenzen auftreten, ist eine minimale TTI-Latenz ideal.

Textverarbeitung

Das Gehirn des Systems

Als nächstes muss das System eine Antwort generieren. Heute wird dies normalerweise mit einem Large Language Model (LLM) wie GPT-4 oder Gemini Flash 1.5 erreicht.

Die Wahl des Sprachmodells macht einen wesentlichen Unterschied. Modelle wie Gemini Flash 1.5 sind unglaublich schnell und generieren Ausgaben in weniger als 350 ms. Robustere Modelle, die komplexere Abfragen verarbeiten können – wie GPT-4-Varianten und Claude – könnten zwischen 700 und 1000 ms benötigen. Die Auswahl des richtigen Modells ist normalerweise der einfachste Weg, um bei der Optimierung eines Konversations-KI-Prozesses die Latenz zu senken.

Die Latenz des LLM ist jedoch die Zeit, die benötigt wird, um Start Token generieren. Diese Token können sofort in den nachfolgenden Text-to-Speech-Prozess gestreamt werden. Da die Text-to-Speech-Umwandlung durch die natürliche Geschwindigkeit einer menschlichen Stimme verlangsamt wird, ist das LLM in der Lage, diese zuverlässig zu überholen – alles, was zählt, ist die Latenz des ersten Tokens (also die Zeit bis zum ersten Byte).

Über die Wahl des Modells hinaus gibt es noch weitere Faktoren, die zur Latenz eines LLM beitragen. Hierzu gehören die Eingabelänge und die Größe der Wissensdatenbank. Je größer der Wert ist, desto länger ist die Latenz. Es läuft auf ein einfaches Prinzip hinaus: Je mehr der LLM berücksichtigen muss, desto länger dauert es. Dementsprechend müssen Unternehmen eine Balance zwischen einem gesunden Maß an Kontext finden, ohne das Modell zu überlasten.

Text-to-Speech-Konvertierung

Das Maul des Systems

Die letzte Komponente der Konversations-KI ist Text-to-Speech (TTS). Die Nettolatenz der Text-to-Speech-Funktion ist die Zeit, die benötigt wird, um nach dem Empfang der Eingabetoken von der Textverarbeitung mit dem Sprechen zu beginnen. Das ist alles – da zusätzliche Token schneller bereitgestellt werden als menschliche Sprache, ist die Latenz bei der Text-to-Speech-Umwandlung **streng genommen die Zeit bis zum ersten Byte.

Bisher war die Text-to-Speech-Funktion besonders langsam und benötigte bis zu 2–3 Sekunden, um Sprache zu generieren. Moderne Modelle wie unsere Turbo-Engine sind jedoch in der Lage, Sprache mit nur 300 ms Latenz zu generieren. Tatsächlich kann unsere V2/V2.5 Flash-TTS-Engine eine Audiolatenz von 200 ms bis zum ersten Byte erreichen, das ist der beste Wert in diesem Bereich (da müssen wir schon ein bisschen angeben!).

Weitere Mitwirkende

Über die vier Komponenten hinaus gibt es noch einige zusätzliche Faktoren, die zur Nettolatenz der Konversations-KI beitragen.

Netzwerklatenz

Beim Senden von Daten von einem Ort zum anderen kommt es immer zu Latenzen. Bei einigen Konversations-KI-Anwendungen sollten die ASR-, TTI-, LLM- und TTS-Prozesse idealerweise am selben Ort stattfinden, sodass die einzige Quelle nicht unerheblicher Netzwerklatenz die Pfade zwischen Sprecher und Gesamtsystem sind.

Funktionsaufruf

Es gibt zahlreiche Konversations-KI-Anwendungen zum Aufrufen von Funktionen (d. h. zur Schnittstelle mit Tools und Diensten). Beispielsweise könnte ich die KI mündlich bitten, das Wetter zu überprüfen. Dies erfordert zusätzliche API-Aufrufe auf der Textverarbeitungsebene, was je nach Bedarf zu erheblich längeren Latenzen führen kann.

Wenn ich beispielsweise mündlich eine Pizza bestellen muss, sind möglicherweise mehrere API-Aufrufe erforderlich, einige davon mit übermäßiger Verzögerung (z. B. bei der Verarbeitung einer Kreditkarte).

Ein Konversations-KI-System kann jedoch die mit Funktionsaufrufen verbundenen Verzögerungen bekämpfen, indem es das LLM auffordert, dem Benutzer zu antworten, bevor der Funktionsaufruf abgeschlossen ist (z. B. „Lass mich das Wetter für dich checken“). Dies simuliert eine reale Konversation und lässt den Benutzer nicht ohne Beteiligung zurück.

Diese asynchronen Muster werden normalerweise durch die Nutzung von Webhooks erreicht, um lang andauernde Anfragen zu vermeiden.

Telefonie

Eine weitere gängige Funktion von Konversations-KI-Plattformen besteht darin, dem Benutzer die Einwahl über das Telefon zu ermöglichen (oder in einigen Fällen das Tätigen eines Telefonanrufs im Namen des Benutzers). Bei der Telefonie kommt es zu zusätzlichen Latenzen – und diese Latenz kann stark von der geografischen Lage abhängen.

Grundsätzlich kommt es bei der Telefonie zu einer zusätzlichen Latenz von 200 ms, wenn sie auf die gleiche Region beschränkt bleibt. Bei internationalen Anrufen (z. B. Asien → USA) kann sich die Reisezeit erheblich verlängern und die Latenz kann bis zu 500 ms betragen. Dieses Muster kann häufig auftreten, wenn Benutzer Telefonnummern außerhalb der Region haben, in der sie sich befinden, wodurch ein Wechsel zu den Telefonnetzen ihres Basislandes erforderlich wird.

Ein abschließender Gedanke

Wir hoffen, dass diese Rundreise zur Erkundung der Konversations-KI interessant war. Zusammenfassend lässt sich sagen, dass Anwendungen eine Latenz von unter einer Sekunde anstreben sollten. Dies kann normalerweise durch die Wahl des richtigen LLM für die jeweilige Aufgabe erreicht werden. Sie sollten außerdem mit dem Benutzer kommunizieren, wenn im Hintergrund komplexere Prozesse ausgeführt werden, um lange Pausen zu vermeiden.

Letztendlich besteht das Ziel darin, Realismus zu schaffen. Ein Benutzer muss das Gefühl haben, mit einem Menschen zu sprechen und gleichzeitig die Vorteile eines Computerprogramms nutzen zu können. Durch eine Straffung der Teilprozesse ist dies nun möglich.

Bei Elevenlabs optimieren wir jeden Teil eines Konversations-KI-Systems mit unseren hochmodernen STT- und TTS-Modellen. Indem wir an jedem Teil des Prozesses arbeiten, können wir nahtlose Gesprächsabläufe erreichen. Diese Top-Down-Ansicht der Orchestrierung ermöglicht es uns, die Latenz an jeder Stelle ein wenig zu reduzieren – sogar um 1 ms.