Sprachassistenten im Betrieb: die Architekturentscheidungen, auf die es ankommt

Die Antwortzeit ist eine Anforderung

Eine Vorführung baut man an einem Nachmittag: Spracherkennung, Sprachmodell, Sprachausgabe. Dass echte Anrufer den Assistenten annehmen, ist eine andere Aufgabe. Im Betrieb ist ein Sprachassistent ein Echtzeitsystem, in dem Übertragung, Turn Detection, Modelle, externe Werkzeuge und Gesprächsführung um dieselbe Sekunde konkurrieren. Die meisten Entscheidungen darüber, ob er funktioniert, fallen früh in der Architektur, und sie lassen sich später nur teuer ändern.

Im Gespräch wechseln Menschen nach rund 200 Millisekunden. Eine halbe Sekunde fällt auf, längere Pausen wirken schnell wie Zögern oder wie eine abgerissene Leitung. Wie viel Verzögerung erträglich ist, hängt vom Fall ab. Ein Avatar zur Unterhaltung auf einer Messe darf mehr brauchen als ein Assistent, der unter Zeitdruck eine Buchung aufnimmt. Entscheidend ist, dass das Ziel bewusst gesetzt wird, je Anwendungsfall, bevor die Architektur steht.

Zwei Dinge machen dieses Ziel überhaupt erst belastbar. Es muss vom Anfang bis zum Ende gemessen werden, vom letzten Wort des Anrufers bis zum ersten Ton der Antwort, und zwar dort, wo der Anrufer sitzt. Und es muss die langsamen Momente ansehen statt des Durchschnitts. Entwickler nehmen dafür das 95. Perzentil, geschrieben p95: Ist jeder zwanzigste Wortwechsel langsam, enthalten bei zwanzig Wechseln je Gespräch etwa zwei von drei Gesprächen mindestens eine unangenehme Stille. Die Erzeugungszeit des Modells, die Zahl, die Anbieter gern nennen, lässt Übertragung, Turn Detection und Werkzeugaufrufe weg.

Spracherkennung, Sprachmodell und Sprachausgabe sind weitgehend Massenware und lassen sich mieten. Die Latenz versteckt sich in allem darum herum, und dort liegt die Arbeit.

Kaskade, Speech-to-Speech oder Mischform

Die erste Architekturentscheidung ist, wie viele Modelle im Gesprächskreis sitzen. Speech-to-Speech-Modelle sind schnell reif geworden. Sie kommen damit zurecht, dass jemand dazwischenredet, sie geben Hörsignale, während der Anrufer spricht, und sie halten Tonfall und Betonung. Denkleistung und Werkzeugaufrufe sind kein Grund mehr, sie zu meiden. Die Kontrolle ist es.

In der Mischform führt ein kleines, schnelles Modell das Gespräch und hält den Takt, während alles, was Genauigkeit, Regeln oder ein führendes System braucht, über Werkzeugaufrufe an größere Modelle geht. Der Anrufer hört ein durchgehendes Gespräch, und die Leitplanken laufen in der Textebene, wo sie leichter zu treffen sind. Was auch immer Sie bauen: Heben Sie die Mitschriften auf. Auswertung, Prüfung und jede spätere Verbesserung hängen daran.

Wo es läuft und was man einkauft

Der Ort ist eine Modellentscheidung. Wer Spracherkennung, Sprachmodell und Sprachausgabe jeweils einzeln nach dem Besten aussucht, bekommt oft einen Aufbau über mehrere Anbieter und Regionen, und jeder Sprung dazwischen kostet mehr, als die besseren Modelle einbringen. Nebeneinander laufende Modelle, die gut genug sind, schlagen meist verteilte ausgezeichnete. In Europa entscheidet oft die Frage, wo die Daten liegen dürfen, über die Region, bevor die Latenz es tut. Deshalb gehört sie in das erste Architekturgespräch.

Die Verbindung selbst braucht ein Protokoll, das für Ton gebaut ist: WebRTC für Browser und Apps, SIP für Telefonleitungen. Anfrage und Antwort über HTTP kostet bei jedem Wortwechsel Zeit und macht Unterbrechungen nahezu unmöglich. Das ist Installation, die niemand selbst bauen sollte. Rahmenwerke wie LiveKit oder Pipecat und die betreuten Plattformen bringen sie mit. Diese Installation einzukaufen ist vernünftig. Das Verhalten des Systems abzugeben nicht.

Alles bei einem Anbieter zu bündeln ist der schnellste Weg zu einem laufenden System. Der Preis ist eine Architektur, die sich kaum ändern lässt, wenn in einem halben Jahr ein besseres Modell erscheint.

Turn Detection ist eine Produktentscheidung

Zu entscheiden, wann der Anrufer fertig ist, ist der schwerste Teil des Kreises und der am meisten unterschätzte. Stille ist ein schwaches Signal. Wer eine Vorgangsnummer vorliest, sich korrigiert oder in einer zweiten Sprache nach einem Wort sucht, hält mitten im Satz über 700 Millisekunden inne. Eine feste Wartezeit schneidet solche Anrufer ab oder hängt an jeden Wortwechsel Leerlauf. Bei 800 Millisekunden je Wechsel und dreißig Wechseln sind das 24 Sekunden Stille.

Diese Wartezeit ist eine Festlegung darüber, wie Ihre Anrufer sprechen, und sie sollte sich je Ablauf unterscheiden: geduldig beim Aufnehmen einer Adresse, schnell bei einer Ja-Nein-Frage. Systeme im Betrieb verbinden die Erkennung von Sprachaktivität, das Signal der Spracherkennung für das Ende einer Äußerung und ein kleines Modell, das aus Wortwahl und Sprechmelodie vorhersagt, ob der Gedanke zu Ende ist. Die Erkenner selbst sind klein und günstig. Den Unterschied macht die Festlegung darum herum.

Wer nicht in seiner Muttersprache spricht, macht die längsten Pausen. Ein Schwellenwert, den man an Muttersprachlern im ruhigen Büro einstellt, schneidet deshalb einen großen Teil der echten Anrufer ab. Über allem steht die Tonqualität. Mikrofon, Echounterdrückung und Rauschunterdrückung kommen vor jedem Modell, besonders bei Avataren und Terminals in öffentlichen Räumen.

Wo Sprachassistenten im Betrieb brechen

Die meisten Fehler zeigen sich in einer Vorführung nicht. Diese hier tauchen mit echten Anrufern auf.

Keiner dieser Fehler liegt im Modell, also löst auch kein besseres Modell einen davon.

Warum mit einem Partner arbeiten und warum mit uns

Ein starkes eigenes Team kann die Punkte oben nehmen und direkt auf einer Plattform bauen. Ein Partner lohnt sich bei dem, was keine Plattform löst: den Assistenten in eine gewachsene Systemlandschaft einzupassen, europäische Anforderungen an die Daten zu erfüllen und Gespräche zu entwerfen, die mit echten Nutzern in echten Umgebungen halten.

• Anbindung an vorhandene Systeme. Als Teil der Apollogic-Gruppe, SAP- und Microsoft-Partner, verbinden wir Sprachassistenten mit den ERP-, CRM- und Servicesystemen, aus denen sie lesen und in denen sie handeln sollen.
• Europäische Anforderungen an die Daten. Standorte in Hamburg und Poznań, Betrieb in der EU, auf eigenen Servern, wo ein Projekt es braucht, und Erfahrung in regulierten Umgebungen wie Kliniken.
• Mehrsprachig von Haus aus. Deutsch, Englisch und Polnisch im Team, und Tests mit Sprechern, die nicht ihre Muttersprache sprechen, gehören bei uns zu jedem Projekt.
• Unabhängig vom Anbieter. Wir verkaufen keine Plattform, deshalb wählen wir die Bausteine, die zum Fall passen, und halten sie austauschbar.

Die Lagen, in denen wir üblicherweise arbeiten: Avatare für Messen und Veranstaltungen, wo offenes Gespräch in lauten Hallen mehr zählt als strenge Genauigkeit. Avatare zur Selbstbedienung an Standorten mit Kundenverkehr, mit Freisprechton, mehrsprachigem Publikum und Vorgängen, die zuverlässig in einem System ankommen müssen. Und Assistenten auf Unternehmenssystemen, wo Antworten und Handlungen aus Firmendaten kommen und jeder Schritt nachvollziehbar sein muss.

Wie ein Projekt bei uns läuft

Es gibt keinen einen richtigen Aufbau, deshalb fangen wir nicht mit einer Vorlage an. Ein Sprachprojekt läuft bei uns in drei Phasen, mit einem Entscheidungspunkt nach der ersten.

• Analyse. Wir sehen uns den ganzen Ablauf an: das Szenario und die Stellen, an denen Gespräche entgleisen, die Umgebung, die Systeme, die der Assistent erreichen muss, und wie genau die Antworten sein müssen. Ein Avatar zur Unterhaltung darf improvisieren, ein System, das Buchungen aufnimmt, nicht. Heraus kommen eine Architektur, Zielwerte für die Antwortzeit und ein zugeschnittener Pilot. Sie entscheiden, ob es weitergeht.
• Bauen und Pilot. Wir bauen den Assistenten, binden ihn an Ihre Systeme an und testen ihn mit echter Sprache: verschiedene Sprecher, Sprachen, Hintergrundgeräusche und Unterbrechungen, nicht im stillen Besprechungsraum.
• Livegang und Betrieb. Einführung mit Messung jeder Stufe, regelmäßige Durchsicht echter Gespräche, und Bausteine, die sich tauschen lassen, wenn bessere Modelle erscheinen.

Die Fragen, die Käufer üblicherweise stellen, gehören in die Analyse: wie der Assistent an ein vorhandenes Servicecenter oder die Telefonanlage angebunden wird, welche Sprachen er können muss, wo Aufzeichnungen liegen und wer sie erreicht, wie Anrufer erfahren, dass sie mit einer KI sprechen, wie es der EU AI Act verlangt, und wer das System nach dem Start betreibt und verbessert.

Ob Sie von einem Anwendungsfall aus starten, Anbieter vergleichen oder auf einem Prototyp sitzen, der mit echten Nutzern nicht hält: Das ist der Punkt, an dem wir üblicherweise einsteigen. Wie wir Vorhaben zuschneiden, steht auf der Seite So arbeiten wir.

theBlue.ai ist ein Enterprise-KI-Unternehmen mit Standorten in Hamburg und Poznań. Das Team arbeitet seit 2016 an KI-Projekten und gehört zur Apollogic-Gruppe mit über 120 Entwicklern. Mehr über uns lesen Sie auf der Seite Über uns.

Quellen: Stivers et al., „Universals and cultural variation in turn-taking in conversation“, PNAS 106(26), 2009 für den Abstand zwischen Sprechern. Cekura, August 2026 für die Verteilung der Antwortzeiten über sechs Plattformen. Teile dieses Artikels stammen aus dem Vortrag „Voice Agents: Where Latency Hides and How to Fight It“, den unsere CTO Agata Chudzińska am 29. September 2026 auf der ML Con in New York gehalten hat.

Häufige Fragen