TL;DR

Dieser Artikel untersucht Methoden zur Verringerung der Latenz in Retrieval Augmented Generation (RAG)-Systemen, insbesondere in Echtzeit-Sprachinteraktionen für Anwendungen im Kundendienst/Support.

Einführung

Mit der Einführung von Retrieval Augmented Generation (RAG) ist es für viele Unternehmen einfacher, auf die generativen Fähigkeiten von Large Language Models (LLMs) zuzugreifen, ohne auf teure oder komplexe Trainingsmethoden wie Pre-Training, Feintuning, RLHF oder Adapter zurückgreifen zu müssen. RAG ermöglicht es Unternehmen, Wissensdatenbanken zu erstellen, die große Mengen an Informationen enthalten, und nur die relevanten Teile abzurufen, um LLMs mit einer umfassenden Antwort zu versorgen, ohne die Informationen direkt in das LLM zu integrieren.

Was ist die RAG?

Bei RAG ruft ein Modell relevante Dokumente oder Informationen aus einer großen Datenbank ab und erzeugt dann eine Antwort unter Verwendung dieser abgerufenen Informationen. RAG verwendet typischerweise ein zweiteiliges System: einen Retriever und einen Generator. Der Retriever sucht auf der Grundlage einer Abfrage nach relevanten Dokumenten oder Passagen, wobei häufig Methoden wie Sparse, Dense und Hybrid Retrieval zum Einsatz kommen, wobei die semantische (vektorbasierte) Suche häufig für schnelle und kontextgenaue Ergebnisse verwendet wird. Der Generator (oft ein Modell wie GPT) synthetisiert die abgerufenen Informationen, um die endgültige Antwort zu generieren. Dadurch kann das Modell genauere und sachlich korrekte Antworten liefern.

Zwei der beliebtesten Anwendungsfälle für die RAG sind:

1. Kundenbetreuung: Bereitstellung von externen/internen Informationen eines Unternehmens in einem konversationellen Format unter Verwendung von virtuellen Agenten/Assistenten/Chatbots für Endnutzer und Automatisierung von FAQ- und Q&A-Modulen, was zu einer hohen Eingrenzungsrate führt.

2. Unternehmenssuche: Durch die Verbindung mit Datenquellen wie Google Drive, Confluence, JIRA, Zendesk, Websites, statischen Dateien usw. werden private Unternehmensinformationen durchsuchbar und bieten präzisere Antworten.

Sprache und akzeptable Gesprächslatenz

Bei der Nutzung von RAG für den Kundenservice erfolgt die Informationsbeschaffung oder Konversation mit LLMs typischerweise über Sprach- oder digitale Kanäle (z.B. Web, WhatsApp, SMS, etc.). Die Latenzzeit ist ein kritischer Faktor in der Echtzeitkommunikation, da sie die Qualität und Effektivität des Gesprächs erheblich beeinflussen kann. In der Echtzeitkommunikation bezieht sich die Latenz auf die Verzögerung zwischen dem Zeitpunkt, an dem ein Ton vom Sprecher erzeugt wird, und dem Zeitpunkt, an dem er vom Zuhörer gehört wird.

Der Sprachkanal hat eine geringe Toleranz für Latenzzeiten, und die ITU-T (International Telecommunication Union's Telecommunication Standardization Sector) (International Union of Telecommunication Standard Sector) empfiehlt eine Einweg-Latenzzeit von 100 ms für interaktive Aufgaben und 150 ms für Konversationsfälle, an denen Menschen auf beiden Seiten beteiligt sind. Digitale Kanäle haben im Allgemeinen eine höhere Toleranzschwelle als Sprachkanäle. Dieser Artikel analysiert speziell die Latenz von Sprachkanälen bei der Verwendung von RAG für Interaktionen zwischen Mensch und virtuellem Assistenten/Agenten/Chatbot.

Eine einseitige Latenz von 150 ms ist mit einer RAG-ähnlichen Architektur, bei der mehrere Komponenten an der Sprachverarbeitung beteiligt sind, fast unmöglich zu erreichen. Mit der richtigen Optimierung der Sprachverarbeitungslogik und der KI-Modelle können jedoch nahezu Echtzeit-Erfahrungen erzielt werden. Die Endnutzer virtueller Assistenten/Agenten/Chatbots sind verzögerungstoleranter als bei Gesprächen von Mensch zu Mensch, die sehr empfindlich auf Latenzzeiten reagieren.

End-to-End-Ansicht eines Sprachanrufs

End-to-end view of a voice call

Eine Sprachanruf-Pipeline mit RAG kann in verschiedene Komponenten unterteilt werden. Sie beginnt typischerweise mit einem Gespräch, das vom Endbenutzer über eine Webanwendung oder ein Telefon initiiert wird, wobei die Netzwerklatenz ansteigt, bis die Stimme den Dienst erreicht. Sobald die Stimme den Dienst erreicht, wird sie in einem ersten Schritt mit Hilfe eines Speech to Text (STT)-Dienstes in Text umgewandelt. Der transkribierte Text wird dann zum Abrufen von Informationen verwendet, und der abgerufene Kontext wird an ein LLM weitergeleitet, um eine Antwort zu generieren. Diese generierte Antwort wird dann an einen Text to Speech (TTS)-Dienst gesendet, der den Text wieder in Sprache umwandelt. Schließlich wird die Stimme über das Netz an die Webanwendung oder das Telefon zurückgesendet, um dem Endbenutzer vorgespielt zu werden.

Gerät/Anwendung/Browser

Ein Gespräch mit dem Endbenutzer beginnt in der Regel mit einem Gerät/Anwendung/Browser, das mit dem Internet verbunden ist. Das Endgerät/die Anwendung/der Browser spielt eine entscheidende Rolle bei der Latenzzeit, da es/sie die Audiodaten erfasst und die Kodierung durchführt. Es übernimmt auch die Antwort, indem es die Audiodaten empfängt und dekodiert.

In der Regel haben Sie drei Optionen für Endgeräte:

1. PSTN-Telefon Wenn Endbenutzer physische Nummern wählen, anstatt die Anruffunktion innerhalb der Anwendung oder des Webbrowsers zu verwenden, müssen die Audiodaten an ein PSTN-Gateway gesendet werden, bevor sie zur Transkription an den Speech-to-Text- oder ASR-Dienst gesendet werden.

2. Mobile Anwendungen : Mobile Anwendungen können Audio über WebSockets oder WebRTC streamen. WebSockets, die auf TCP aufbauen, können jedoch in Netzwerken mit hoher Latenz unter Leistungsproblemen leiden.

3. Web-Browser : Webbrowser sind jetzt ausgestattet mit WebRTC für die Echtzeitkommunikation ausgestattet, die Medien-Streaming mit niedriger Latenz auf der Grundlage von UDP ermöglicht.

Empfehlung: Niedrige Latenzzeiten lassen sich am besten erreichen, wenn die Anwendung auf WebRTC basiert.

Uplink- und Downlink-Netz

Die Latenzbedingungen von Uplink- und Downlink-Netzen sind unterschiedlich und für die Endnutzer nicht vorhersehbar, so dass es schwierig ist, hier spezifische Empfehlungen zu geben.

Dienst "Sprache zu Text

Dieser Schritt ist von entscheidender Bedeutung, da der Dienst Sprache in Text für die weitere Verarbeitung umwandelt. Es ist wichtig, eine hohe Genauigkeit bei geringer Latenz zu erreichen, da die Genauigkeit dieses Schritts die Gesamteffizienz der Antwort-Pipeline beeinflusst. Verschiedene Anbieter, wie z. B. Speechmatics, Deepgram, Google ASR und AWS Transcribe, bieten Speech-to-Text-Dienste an. Es sind zwei Modi verfügbar:

1. Voraufgezeichnete Verarbeitung (Stapelverarbeitung) Stapelverarbeitung: Ein aufgezeichneter Audiopuffer oder eine Datei wird in Stücken an den Anbieter von Speech to Text gesendet. Bei diesem Ansatz muss in der Regel vor der Verarbeitung auf Stille gewartet werden, was die Latenzzeit erhöht.

2. Streaming in Echtzeit Die Äußerungen des Endnutzers werden in dem Moment an den STT-Dienst gesendet, in dem sie empfangen werden, was eine schnellere Transkription ermöglicht, aber möglicherweise zu Problemen mit der Genauigkeit führt. Eine effiziente Voice Activity Detection (VAD) ist beim Echtzeit-Streaming unerlässlich.

Empfehlung: Niedrige Latenzzeiten lassen sich besser mit Echtzeit-Streaming als mit Stapelverarbeitung bei Sprache-zu-Text-Diensten erreichen.

Ab 2025 stehen auch neuere Optionen wie AssemblyAI und OpenAI Whisper API (Beta) zur Verfügung, von denen viele von Haus aus Echtzeit-Endpointing unterstützen, um die Reaktionsfähigkeit zu verbessern.

Informationsbeschaffung

Die in RAG verwendeten Suchmethoden sind entscheidend für das Auffinden relevanter, qualitativ hochwertiger Dokumente oder Passagen, die das generative Modell verwenden kann, um informative Antworten zu erzeugen. Die Wahl der Suchmethode, ob sparse, dense oder hybrid, hängt von Faktoren wie der Genauigkeit der Antworten, der Latenzzeit und den rechnerischen Beschränkungen ab. Hybride Retrieval-Methoden, die spärliche und dichte Techniken kombinieren, werden immer beliebter, da sie Präzision mit Recall kombinieren können, was sie in RAG-Systemen sehr effektiv macht.

Bei der Vektorsuche, die auch als semantische Suche bezeichnet wird, werden in der Regel Einbettungen (Vektordarstellungen) von Text verwendet und dann über diese Einbettungen gesucht, um die ähnlichsten Ergebnisse zu finden. Die Latenzzeit bei der Vektorsuche kann durch die Verwendung kürzerer (aber immer noch kontextgenauer) Einbettungsvektoren und schnellerer Rescoring-Algorithmen zum Herausfiltern irrelevanten Kontexts verringert werden. Die Implementierung von Zwischenspeichern und lokalen Vektordatenbanken kann die Suchlatenz ebenfalls verbessern.

Empfehlung: Für Echtzeitgespräche ist die semantische Suche aufgrund ihrer Schnelligkeit und Effizienz generell die bessere Wahl. Sie ermöglicht einen nahezu sofortigen Abruf, was für die Aufrechterhaltung des Flusses von Live-Interaktionen unerlässlich ist.

Zwar unterstützt MongoDB Atlas Search jetzt die Vektorsuche, doch für Anwendungen mit geringerer Latenz und in Echtzeit sind dedizierte Vektordatenbanken wie Weaviate, Qdrant, Pinecone oder FAISS im Allgemeinen leistungsfähiger.

LLM-Verarbeitung

Der Generierungsteil des RAG-Systems verwendet ein LLM, um kohärente und kontextuell relevante Antworten auf der Grundlage der abgerufenen Informationen und der Benutzeranfrage zu erzeugen. Time to First Token (TTFT) ist eine wichtige Leistungskennzahl. Sie bezieht sich auf die Zeit, die ein Modell benötigt, um nach Erhalt einer Eingabeaufforderung das erste Token der Ausgabe zu erzeugen. Diese Kennzahl ist entscheidend für interaktive Anwendungen wie Chatbots, virtuelle Assistenten und die Generierung von Inhalten in Echtzeit.

Bei Stapelverarbeitungsmodellen wie Google Chat Bison bezieht sich die TTFT im Allgemeinen auf die Zeit, die für die Generierung der gesamten Antwort benötigt wird, was zu Verzögerungen führen kann, da der Text to Speech (TTS)-Dienst warten muss, bis die gesamte Antwort generiert ist, bevor er sie verarbeiten kann. Im Gegensatz dazu kann bei Streaming-Modellen wie Gemini 1.5 Pro die TTFT ab dem Moment gemessen werden, in dem das erste Token generiert wird, was eine sofortige Ausgabe ermöglicht. Das bedeutet, dass der TTS-Dienst mit der Verarbeitung und Bereitstellung von Teilen der Antwort beginnen kann, sobald diese verfügbar sind. Dadurch wird das Benutzererlebnis durch die Verringerung der wahrgenommenen Latenzzeit erheblich verbessert.

Die Zukunft von RAG könnte Fortschritte sehen, bei denen die Retriever-Komponente minimiert oder ganz eliminiert wird, was durch ausgefeiltere Modelle mit größeren Kontextfenstern erreicht wird, wie z. B. die Google Vertex Gemini-Modellfamilie. Mehrere andere Faktoren wirken sich ebenfalls auf die LLM-Antwortgenerierung aus, und Optimierungen wie die Reduzierung der Promptgröße oder die Verwendung von Kontext-Caching können die Latenzzeit verringern. In manchen Fällen können Sie sich für ein Small Language Model (SLM) anstelle eines LLM entscheiden, um eine gewisse Genauigkeit für schnellere Antwortzeiten einzutauschen. Anbieter wie FireworksAI konzentrieren sich auf die Optimierung von Modellen speziell für Latenzzeiten. Kleine Sprachmodelle wie Claude 3 Haiku oder Mistral 7B Instruct erfreuen sich ebenfalls zunehmender Beliebtheit für latenzkritische Anwendungen, bei denen ein umfassendes LLM nicht notwendig ist.

Empfehlung: Die LLM-Ausgabe im Streaming-Modus kann die Latenzzeit erheblich verringern, so dass TTS die generierte Antwort früher wiedergeben kann. Ziehen Sie auch schnellere Modelle wie Google Gemini Flash 8B in Betracht, die geringere Latenzzeiten bieten.

Text-to-Speech-Dienst

Dieser Schritt ist entscheidend, da der Dienst den Text in Sprache umwandelt, die dann wiedergegeben oder gestreamt werden kann. Anbieter wie Amazon Polly, Google TTS und Eleven Labs bieten Text-to-Speech-Dienste an, in der Regel in zwei Modi:

1. Voraufgezeichnete Verarbeitung (Stapelverarbeitung) Stapelverarbeitung: Konvertiert große Textmengen in einem einzigen asynchronen Vorgang in Sprache. Dies ist nützlich für Anwendungen, bei denen die Echtzeitverarbeitung nicht entscheidend ist, wie z. B. bei der Erzeugung von Audio für E-Books, Podcasts oder voraufgezeichnete Ankündigungen.

2. Streaming in Echtzeit Unverzichtbar für Anwendungen, die eine sofortige Sprachausgabe erfordern, wie z. B. virtuelle Assistenten, interaktive Sprachdialogsysteme (IVR) und Echtzeit-Kommunikationstools.

Empfehlung: Echtzeit-Streaming ist im Vergleich zur Stapelverarbeitung vorzuziehen, um niedrige Latenzzeiten zu erreichen.

Schlussfolgerung

Die Latenzzeit bei Echtzeit-Sprachanwendungen mit RAG wird von vielen Faktoren beeinflusst und kann durch verschiedene Optimierungstechniken kontrolliert werden. Die folgende Tabelle fasst die zu erwartende maximale Zwei-Wege-Latenz in verschiedenen Phasen der Sprachkommunikation zusammen. Mit Optimierungen können Sie erhebliche Verbesserungen der Latenzzeiten erwarten. In der Tabelle sind die durch das Gerät und die Uplink-/Downlink-Netzwerke verursachten Latenzen nicht berücksichtigt.

1. Semantische Suche - Die Vektordatenbank basiert auf MongoDB

2. LLM - ohne Streaming

3. LLM - mit Streaming

Durch die Implementierung dieser Optimierungsstrategien können Sie die Latenz in Sprachanwendungen, die die RAG-Pipeline verwenden, drastisch reduzieren und so reibungslosere und effizientere Echtzeitgespräche gewährleisten.

Kontakt aufnehmen

Besuchen Sie unser Vonage AI Studio für den Aufbau von Sprachkonversationen mit geringer Latenz oder kontaktieren Sie uns über Vonage Community Slack oder Nachricht an uns auf X.