Webinar-Zusammenfassung: Geben Sie Ihrem Text-Chatbot eine menschlich klingende Stimme

Chat-Agenten sind zu einem festen Bestandteil des Enterprise-Software-Stacks geworden. Die meisten Unternehmen haben einen oder entwickeln einen. Weniger Unternehmen haben geklärt, was passiert, wenn Nutzer lieber einfach sprechen möchten.

Sprache verändert die Interaktion auf eine Weise, die über Komfort hinausgeht. Nutzer drücken Frustration, Dringlichkeit und Verwirrung über ihren Tonfall aus – Signale, die Text vollständig ausblendet. Ein Kunde, der „meine Bestellung ist nicht angekommen“ schreibt, und ein Kunde, der es hörbar besorgt sagt, senden unterschiedliche Signale – und ein Agent, der nur das Transkript lesen kann, arbeitet nur mit der Hälfte der Informationen.

Die Frage, die sich die meisten Teams jetzt stellen, ist nicht, ob sie Sprache hinzufügen sollten, sondern wie sie das tun, ohne alles neu aufzubauen, was bereits funktioniert.

Im Live-Workshop: Geben Sie Ihrem Text-Chatbot eine menschlich klingende Stimme, erläuterten Paul Asjes (Developer Experience), Bhargavi Bhatt (Customer Experience) und Fergal Burnett (Product Marketing, ElevenAPI) die technischen Anforderungen beim Hinzufügen von Sprache zu einem bestehenden Agenten und wie eine funktionierende Integration konkret aussieht.

Warum die Entwicklung mit Sprache schwieriger ist, als sie scheint

Eine der zentralen Herausforderungen ist die Sprecherwechselerkennung. Menschen erkennen anhand von Intonation, Rhythmus und Kontext, wann jemand ausgeredet hat. Voice Activity Detection, der Standardansatz, erkennt dagegen nur Stille.

Das Ergebnis ist oft ein System, das jede Pause als Aufforderung zum Sprechen auffasst: Es unterbricht, fällt Menschen mitten im Gedanken ins Wort und behandelt natürliche Zögern, als wären es abgeschlossene Sätze.

Technisch funktioniert es, im Gespräch nicht.

Kontext ist die andere Hälfte des Problems. Den Gesprächsverlauf bei jedem Sprecherwechsel an ein LLM zu übergeben, ist notwendig, aber nicht ausreichend. Dieselben Worte haben je nach Aussprache eine andere Bedeutung: „Mir geht es gut“, erleichtert gesagt, und „Mir geht es gut“, frustriert gesagt, ergeben dasselbe Transkript, aber eine andere Interaktion. Ein Sprachsystem, das diese Dimension ignoriert, wird immer etwas unpassend klingen – unabhängig davon, wie leistungsstark die einzelnen Modelle sind.

Hinzu kommt der Engineering-Aufwand. Teams, die ihre eigene Sprachorchestrierung betreiben, müssen Logik für Sprecherwechsel, Unterbrechungen und Latenzanalysen dauerhaft pflegen. Das ist kein einmaliges Projekt.

So fügen Sie einem bestehenden Agenten Sprache hinzu

Der sauberste Ansatz ist eine duale WebSocket-Architektur. 

1. Eine Verbindung läuft zwischen Client und ElevenLabs API, eine weitere zwischen Ihrem Server und der ElevenLabs API
2. Der Nutzer spricht in sein Mikrofon, das Audio wird an die ElevenLabs API gesendet, dort transkribiert und an Ihren Server weitergeleitet
3. Ihr Server übergibt dem LLM den vollständigen Gesprächsverlauf, den er von der ElevenLabs API erhält, und die gestreamte Antwort geht zur Audiosynthese zurück
4. Dies kann beginnen, bevor das LLM die Generierung abgeschlossen hat – so bleibt die Latenz bis zum ersten Byte gering 

Der zentrale Integrationspunkt ist die Methode onTranscript , die am Ende jedes Sprecherwechsels ausgelöst wird und den vollständigen Gesprächsverlauf an das LLM übergibt. 

Ein contextualUpdate zu Beginn der Sitzung übernimmt alles, was im Textteil des Gesprächs passiert ist, bevor der Nutzer zu Sprache wechselt. So kann ein einzelner Agent über beide Modalitäten hinweg arbeiten, ohne Kontext zu verlieren.

Einige Punkte, die Sie bei der Entwicklung beachten sollten:

1. Die Wahl des LLM ist bei Sprache wichtiger als im Chat. Modelle für tiefgehendes Reasoning führen zu Pausen, die im Audio wie unnatürliches Zögern wirken, selbst wenn die Antwortqualität höher ist. Bei Echtzeit-Sprache gewinnen schnellere Modelle bei der wahrgenommenen Qualität fast immer.
2. WebRTC statt WebSockets für Audio. WebRTC bietet integrierte Echo- und Rauschunterdrückung. Das ist besonders auf Mobilgeräten oder in lauten Umgebungen wichtig. Bei WebSockets für die Audioübertragung müssen Sie sich selbst darum kümmern.
3. Fordern Sie Nutzer nicht auf, eine Sprache auszuwählen. Das unterbricht den Gesprächsfluss. Die Sprache in den ersten Sekunden des Gesprochenen zu erkennen und festzulegen, ist ein besseres Muster – und ermöglicht einen reibungslosen Wechsel, ohne dass Nutzer etwas tun müssen.
4. Trennen Sie Ihr Sprecherwechselmodell von Ihrem LLM. Wenn das LLM entscheiden soll, ob ein Nutzer ausgeredet hat, erhöht das bei jedem Sprecherwechsel Latenz und Kosten. Ein dediziertes Sprecherwechselmodell erledigt das schneller und präziser. Behandeln Sie es daher als eigenständige Komponente in der Architektur.

Wie viel Infrastruktur Sie selbst betreiben sollten

Die richtige Antwort hängt davon ab, was bereits vorhanden ist. Wenn Sie einen funktionierenden Chat-Agenten haben, ist das Hinzufügen einer Sprachschicht – bei unverändertem LLM, Orchestrierung und Geschäftslogik – meist der schnellste und risikoärmste Weg. 

Sie bauen nichts neu auf. Sie ergänzen ein bereits funktionierendes System um eine Audio-Oberfläche.

Wenn die Anforderungen Telefonie, Management von Bereitstellungskanälen, integrierte Tests und Analysen umfassen, ist es sinnvoll, mehr vom Stack an eine Voice-Agent-Plattform zu übergeben. Die beiden Ansätze schließen sich nicht aus: Teams können mit einer schlanken Sprachschicht beginnen und Plattformfunktionen ergänzen, wenn der Anwendungsfall reift.

Demo: Sprache zu einem bestehenden Chatbot hinzufügen

Diese Demo zeigt einen Nutzer mitten in einem Gespräch mit einem textbasierten Reiseplanungs-Chatbot. Er fragt nach Empfehlungen für Viertel und Essen für eine Reise nach Japan.

Was wir gezeigt haben:

• Der Chatbot wurde um eine Sprachschicht erweitert, ohne Änderungen am zugrunde liegenden Agenten.
• Der Nutzer wechselte mitten im Gespräch vom Tippen zum Sprechen – der Agent behielt über beide Modalitäten hinweg den vollständigen Kontext.
• Der Nutzer sprach Niederländisch; der Agent erkannte den Sprachwechsel automatisch
• Als der Agent unterbrochen und gebeten wurde, mitten im Satz wieder zu Englisch zu wechseln, tat er das – und beendete die Antwort ungefragt mit leicht niederländischem Akzent.
• Während des gesamten Gesprächs konnte der Nutzer dank Unterbrechungserkennung dem Agenten auf natürliche Weise ins Wort fallen, ohne dass dieser seinen Zug beendete.

Warum das wichtig ist: 

Die Demo zeigte keinen speziell entwickelten Voice-Agent. Sie zeigte einen bereits funktionierenden Text-Agenten, über den eine Sprachschicht gelegt wurde. Kontextverarbeitung, Spracherkennung und Verhalten bei Unterbrechungen kamen vollständig aus der Sprachschicht – der zugrunde liegende Text-Agent blieb unverändert. 

Sehen Sie sich die vollständige Session an

Sehen Sie sich das vollständige Webinar hier an.