Wie Echtzeit-Sprach-KI wirklich funktioniert (STT → LLM → TTS, erklärt)
Was zwischen „Hallo“ und der Antwort des Agenten passiert, in einfachen Worten. Kein Fachjargon, kein Drumherumreden.
Echtzeit-Sprach-KI ist eine dreistufige Pipeline mit zwei Orchestrierungs-Komponenten drumherum. Audio kommt herein → Speech-to-Text wandelt es in Wörter um → ein LLM entscheidet, was zu tun ist → Text-to-Speech wandelt die Antwort zurück in Audio. Drumherum gewickelt: Turn-Taking (wann hat der Anrufer aufgehört?) und Barge-in-Handling (was, wenn er uns unterbricht?). Das ist alles.
Die gesamte Pipeline muss in unter ~700 ms abgeschlossen sein, sonst fühlt es sich nicht mehr menschlich an. Über dieser Schwelle werden Anrufer unsicher, wiederholen sich und legen auf. Darunter vergessen sie, dass sie mit einer KI sprechen. Retells Stack läuft End-to-End bei etwa 600 ms. Das ist kein Glück. Es ist das Ergebnis davon, dass jede Stufe in die nächste streamt, statt darauf zu warten, dass sie fertig wird.
Der Großteil der Latenz versteckt sich dort, wo man es nicht erwartet. Nicht im STT, nicht im TTS – sondern in den Turn-Taking-Entscheidungen und der LLM-Time-to-First-Token. Wenn sich Ihr Build langsam anfühlt, sind das die beiden Stellen, an denen Sie zuerst suchen sollten.
Streaming ist der Trick. STT gibt alle ~50 ms partielle Transkripte aus, statt auf einen vollständigen Satz zu warten. Das LLM streamt Tokens, sobald sie generiert werden. TTS streamt Audio-Chunks, bevor die vollständige Antwort existiert. Nichts davon funktioniert, wenn eine einzelne Stufe darauf wartet, dass die vorherige „fertig“ wird.
Die Stacks von 2026 sehen architektonisch alle ähnlich aus. Was „produktionsreif“ von „Demo“ trennt, ist die Qualität der Orchestrierung – VAD-Tuning, Turn-Taking-Modelle, Unterbrechungs-Handling, Function-Call-Latenz. Dort fließt die eigentliche technische Investition hin.
Streift man das Marketing ab, ist ein Sprachagent eine Pipeline. Audio kommt über das Telefon herein. Software wandelt es in Text um. Ein Sprachmodell liest diesen Text, entscheidet, was zu sagen oder zu tun ist, und generiert eine Antwort. Weitere Software wandelt die Antwort zurück in Audio. Audio geht über das Telefon wieder hinaus. Der Anrufer hört es, sagt etwas, und die Schleife läuft erneut. Das ist es. Das ist das gesamte Produkt.
Der Grund, warum diese einfache Schleife Jahre brauchte, bis sie funktionierte, ist, dass all das in weniger als einer Sekunde geschehen muss. Jeder Teil der Pipeline muss streamen. Jeder Übergang zwischen den Stufen muss nahezu sofort erfolgen. Zwei Stufen müssen harte Echtzeit-Entscheidungen treffen – Turn-Taking („hat der Anrufer schon aufgehört zu sprechen?“) und Barge-in-Handling („der Anrufer hat gerade angefangen, über mich zu reden, was mache ich jetzt?“). Machen Sie irgendetwas davon falsch, zerfällt das Gespräch auf eine Weise, die Anrufer sofort bemerken, selbst wenn sie nicht artikulieren können, warum.
Dieser Artikel ist die marketingfreie Version davon, wie ein Sprachagent 2026 tatsächlich funktioniert. Wir gehen einen einzelnen Gesprächs-Turn von Anfang bis Ende durch, schauen, wo sich die Latenz versteckt, sprechen über die Orchestrierung, die Produktions-Stacks von Demos trennt, und räumen mit ein paar gängigen Missverständnissen darüber auf, was unter der Haube wirklich passiert.
Wenn Sie PM sind und verstehen wollen, was Ihre Ingenieure bauen, ist das hier für Sie. Wenn Sie Ingenieur sind und eine Plattform evaluieren gegenüber dem Selberbauen, ebenfalls für Sie. So oder so: Am Ende wissen Sie, was jedes Mal passiert, wenn jemand „Hallo“ sagt und eine KI „Hi“ zurücksagt.
Hier die Kurzfassung.
Ein Sprachagent besteht aus drei Dingen hintereinander mit zwei Dingen drumherum. Die drei hintereinander: STT → LLM → TTS. Speech-to-Text wandelt das Audio des Anrufers in Wörter um. Ein großes Sprachmodell liest diese Wörter (plus Ihren System-Prompt, das bisherige Gespräch und eine Beschreibung aller Tools, die der Agent aufrufen kann) und entscheidet, ob es sprechen oder eine Funktion aufrufen soll. Text-to-Speech wandelt die Antwort des Modells zurück in Audio.
Die zwei Dinge, die um diese Pipeline gewickelt sind: Turn-Taking und Barge-in. Turn-Taking ist das System, das entscheidet, wann der Anrufer einen Gedanken beendet hat, damit der Agent antworten kann – viel schwieriger, als es klingt, weil Menschen ständig mitten im Satz pausieren. Barge-in ist das System, das damit umgeht, wenn ein Anrufer den Agenten mitten in der Antwort unterbricht – ebenfalls schwieriger, als es klingt, denn man muss das TTS sofort stoppen, fallenlassen, was das Modell gerade sagen wollte, und wieder anfangen zuzuhören.
Warum das schwierig ist: Jede Stufe muss streamen, und jede Stufe hat ein Latenzbudget, das man nicht sprengen darf. Bringen Sie die gesamte Schleife unter ~700 ms und das Gespräch fühlt sich menschlich an. Geht es darüber, tut es das nicht. Das ist die ganze Aufgabe.
Gehen wir einen Gesprächs-Turn von Anfang bis Ende durch. Der Anrufer sagt „Hallo, ich würde gerne für nächsten Dienstagnachmittag eine Reinigung buchen“ – und 600 ms später antwortet der Agent. Hier ist alles, was dazwischen passiert.
Der Anruf trifft zuerst auf Ihre Telefonie-Schicht – einen SIP-Trunk, wenn Sie Ihren bestehenden Carrier nutzen, oder einen WebRTC-Stream, wenn Sie eine Retell-Nummer verwenden. So oder so erscheint das Audio des Anrufers als Strom kleiner Pakete, üblicherweise je 20 ms. Von dem Moment an, in dem der Anrufer zu sprechen beginnt, fließen diese Pakete in Höchstgeschwindigkeit in Ihren Stack. Der Netzwerk-Round-Trip ist das erste Stück des Latenzbudgets, das Sie nicht umgehen können: typischerweise 30–80 ms je nach Geografie und Carrier, bevor irgendeine KI-Arbeit stattgefunden hat.
VAD ist das leichtgewichtige Modell, das entscheidet, ob das hereinkommende Audio Sprache oder Stille ist. Es läuft auf jedem eingehenden Chunk, in Millisekunden. Warum überhaupt? Zwei Gründe. Erstens: Sie wollen keine Stille an Ihr STT senden – das verschwendet Rechenleistung und verwirrt das Turn-Taking. Zweitens: VAD ist das erste Signal, das Turn-Taking nutzt, um zu entscheiden, wann der Anrufer aufgehört hat zu sprechen. Schlechtes VAD ist einer der stillen Killer von Sprach-KI. Stellen Sie es zu eng ein und Sie schneiden den Anrufer mitten im Wort ab. Stellen Sie es zu locker ein und der Agent wirkt träge. Produktionsreife Stacks nutzen dafür ein kleines neuronales Netz, das speziell auf Telefonanruf-Audio trainiert ist, keinen generischen Energie-Schwellenwert.
Sobald VAD sagt „das ist Sprache“, wird das Audio in eine Streaming-STT-Engine geleitet. Das Schlüsselwort ist Streaming. Das STT wartet nicht, bis der Anrufer fertig ist. Es gibt alle ~50 ms partielle Transkripte aus – unvollständige Vermutungen, die revidiert werden, sobald mehr Audio eintrifft. Bei 200 ms könnte das Transkript also „Hallo ich würde gerne eine“ sagen. Bei 400 ms „Hallo ich würde gerne eine Reinigung für“. Bei 700 ms den vollständigen Satz. Modernes STT bewältigt außerdem Diarisierung (wer spricht – nützlich, wenn mehr als eine Person in der Leitung ist), Zwischenkorrektur (das Revidieren von „zwei“ zu „zwei Uhr dreißig“, sobald mehr Kontext eintrifft) und Robustheit gegen Geräusche für Anrufer am Lautsprecher oder am Flughafen.
Wenn Sie sich fragen, wo die meisten selbstgebauten Builds still scheitern, ist das eine der Stellen. Die Erkennungsgenauigkeit ist 2026 in Ordnung. Der schwierige Teil ist das Streaming, die Partials und die End-of-Utterance-Erkennung – nichts davon bekommen Sie von einer generischen „transkribiere diese Audiodatei“-API.
Das ist die schwarze Kunst. Turn-Taking ist das Modell, das entscheidet, wann der Anrufer einen Gedanken beendet hat, damit der Agent antworten kann. Es ist nicht einfach „warte 500 ms nach dem letzten Wort“. Menschen pausieren mitten im Satz, holen Luft, sagen „ähm“, während sie nachdenken. Ein naiver Timeout wird sie entweder abschneiden („Hallo, ich würde gerne—“ „Okay, was möchten Sie buchen?“) oder langsam wirken („...für nächsten Dienstagnachmittag.“ [Stille] [Stille] „Verstanden, lassen Sie mich nachsehen.“).
Die Produktionsantwort von 2026 ist ein kleines, schnelles neuronales Turn-Taking-Modell, das den Audio-Stream, das partielle Transkript und den Gesprächskontext nimmt und eine Wahrscheinlichkeit angibt, dass der Anrufer seinen Turn beendet hat. Es aktualisiert sich Dutzende Male pro Sekunde. Wenn die Konfidenz einen Schwellenwert überschreitet, beginnt der Turn des Agenten. Retells Turn-Taking-Modell bewältigt Backchannels („mhm“, „genau“), Zögerpausen und End-of-Utterance-Erkennung innerhalb eines End-to-End-Antwortbudgets von etwa 600 ms. (Wie unser Turn-Taking funktioniert.)
Wenn Sie eine Sache aus diesem Artikel mitnehmen: Der größte Teil des Unterschieds zwischen „fühlt sich menschlich an“ und „fühlt sich robotisch an“ lebt in dieser Stufe. Latenzbudget-technisch frisst Turn-Taking 150–300 ms Ihrer gesamten Antwortzeit. Qualitativ ist es der mit Abstand größte Faktor dafür, ob Ihre Anrufer den Agenten respektieren.
Sobald der Turn des Anrufers vorbei ist, wird das Sprachmodell mit allem aufgerufen, was es braucht: Ihrem System-Prompt, dem vollständigen Gesprächstranskript, jeglichem aus Ihrer Wissensdatenbank abgerufenen Wissen und der Liste der verfügbaren Funktionen. Das Modell hat bei jedem Turn zwei Optionen – eine gesprochene Antwort generieren oder ein Tool aufrufen (den Termin buchen, den Anruf weiterleiten, den Kundendatensatz nachschlagen).
Die Latenzmetrik, die hier zählt, ist die Time to First Token (TTFT). Nicht, wie lange die vollständige Antwort dauert – sondern, wie lange es dauert, bis das erste Wort zu streamen beginnt. Ein gutes LLM von 2026 erreicht TTFT in 150–300 ms für einen typischen Sprachagent-Prompt. Sobald Tokens zu streamen beginnen, streamen sie mit 50–100 pro Sekunde weiter, was schneller ist, als die meisten Menschen sprechen. Die TTS-Stufe beginnt also, bevor das Modell zu Ende gedacht hat. (Preisdetails zur LLM-Stufe.)
Wenn das Modell entscheidet, eine Funktion aufzurufen statt zu sprechen, zahlen Sie eine andere Latenz: den Round-Trip zu Ihrem Webhook (den Slot in Cal.com buchen, den Lead in Salesforce schreiben). Für die meisten voreingestellten Funktionen ist das schnell – einstellige hundert Millisekunden. Für langsame Drittanbieter-APIs kann es langsamer sein, und der Agent sagt dann typischerweise etwas wie „einen Moment, während ich das prüfe“, um die Lücke zu füllen. (Buchen, Weiterleiten, Wissensdatenbank.)
Sobald das LLM die ersten paar Tokens ausgibt, beginnt TTS. Moderne Sprachagenten streamen Audio in 200–400-ms-Chunks hinaus, sodass der Anrufer das erste Wort hört, bevor die vollständige Antwort überhaupt generiert wurde. Das ist der Trick, der die gesamte Pipeline schnell wirken lässt – jede Stufe gibt Output aus, bevor die vorherige Stufe fertig wird.
Das Sprach-Menü von 2026 hat drei Stufen: Retell-Plattform-Stimmen und Cartesia für schnelle, natürliche, latenzarme Stimmen zu 0,015 $/Min.; ElevenLabs für hochauflösendste Markenstimmen zu 0,040 $/Min.; und ein langer Schwanz an Stimmklonen für Premium-Anwendungsfälle. Die Time to First Audio (TTFA) ist die Metrik, die man beobachten muss – Produktions-Stacks erreichen 100–200 ms. In Blindtests mit Standardstimmen können die meisten Anrufer sie nicht zuverlässig von menschlichen unterscheiden. Was Sprach-KI 2026 verrät, ist nicht mehr die Stimme. Es ist das Timing.
Die obige Pipeline funktioniert großartig, bis der Anrufer das tut, was Menschen tatsächlich tun: unterbrechen. Sie fangen an, über den Agenten zu reden. Vielleicht haben sie gemerkt, dass sie Mittwoch meinten, nicht Dienstag. Vielleicht sind sie genervt. So oder so muss der Agent sofort aufhören zu sprechen, den Rest seiner geplanten Antwort fallenlassen und wieder anfangen zuzuhören – schnell.
Das ist Barge-in-Handling, und es ist ein weiterer stiller Killer von Sprach-KI. Ein naiver Build liest den Rest des TTS weiter vor, während der Anrufer spricht – das schlimmste Gefühl bei einem Telefonanruf. Ein guter Build schneidet das TTS innerhalb eines einzigen Audio-Chunks ab (unter 100 ms), verwirft, was das LLM sagen wollte, und startet einen frischen STT-Stream aus dem neuen Audio des Anrufers. Bonuspunkte, wenn das Modell weiß, was vor dem Abbruch gesagt wurde, damit es sich nicht wiederholt.
Rechnen Sie das Budget zusammen: Netzwerk (50 ms) + VAD/Turn-Taking (200 ms) + LLM TTFT (250 ms) + TTS TTFA (100 ms) = etwa 600 ms. So fühlt sich ein Sprachagent menschlich an. Keine dieser Zahlen ist magisch. Sie sind einfach das Ergebnis davon, aggressiv zu streamen und auf nichts zu warten, worauf man nicht warten muss.
Drei Unternehmen, die heute auf genau dieser Pipeline laufen und einen Blick wert sind.
Pine Park Health. Hausärztliche Versorgung für Senioren-Wohngemeinschaften. Telefon-Pingpong fraß ihren Terminplan auf. Sie setzten einen Retell-Sprachagenten vor ihre Terminplanungs-Leitung – dieselbe STT → LLM → TTS-Pipeline wie alle anderen, nur eng genug orchestriert, dass Anrufer nicht abbrachen. Der Terminplanungs-NPS stieg um 38 %. Ihr klinisches Personal verbrachte nicht mehr den halben Tag am Telefon.
SWTCH. Ein EV-Ladeunternehmen. Wenn ein Fahrer an einer defekten Ladestation gestrandet ist, ist „wir rufen Sie morgen zurück“ keine Antwort. Sie setzten Lucas – einen Retell-Agenten – in die Leitung. Lucas nimmt in Sekunden ab, führt Fahrer durch dringende Fehlerbehebung und tut das rund um die Uhr über dieselbe siebenstufige Pipeline. Die Support-Kosten sanken um mehr als 50 %.
Medical Data Systems. Inkasso. Reguliert, tonal sensibel, unerbittlich, wenn Gespräche aus dem Ruder laufen. Sie setzten Retell-Agenten auf Inbound-Anrufe und bewältigen nun 100 % des eingehenden Volumens mit nur 30 % der Anrufe, die an einen Menschen weitergeleitet werden, und ziehen rund 280.000 $ pro Monat ein. Die Pipeline ist dieselbe, die wir gerade durchgegangen sind. Der Unterschied ist Orchestrierungsdisziplin und ein langer Schwanz kleiner Entscheidungen über Turn-Taking, Barge-in und Prompt-Design. (Mehr Kundengeschichten hier.)
Der gemeinsame Nenner bei allen dreien: Keiner von ihnen versuchte, die Pipeline zu erfinden. Sie wählten eine Plattform, die die Orchestrierung gelöst hatte, konzentrierten ihre Arbeit auf die Teile, die ihrem Geschäft tatsächlich proprietär waren – den Prompt, die Wissensdatenbank, die Funktions-Endpoints – und gingen live.
Wenn Sie nichts anderes aus diesem Artikel behalten, behalten Sie das: STT und TTS sind nicht die Stelle, an der sich der Großteil Ihrer Latenz versteckt. Sie sind schnell. Die zwei Stellen, an die die Latenz tatsächlich geht, sind Turn-Taking und LLM-Time-to-First-Token.
Hier eine typische Budget-Aufschlüsselung für 2026 für einen Gesprächs-Turn auf einem Produktions-Stack:
Netzwerk-Round-Trip: 30–80 ms. Hauptsächlich Geografie und Ihr SIP-Carrier. Hier können Sie nicht viel tun.
VAD- + Turn-Taking-Entscheidung: 150–300 ms. Das ist die größte Variable. Ein schlechtes Turn-Taking-Modell kostet Sie 500 ms+ an wahrgenommener Latenz, ohne je in einem Benchmark aufzutauchen.
STT-Endtranskript: 50–100 ms nach Ende der Sprache. Streaming verbirgt das meiste davon in der vorherigen Stufe.
LLM-Time-to-First-Token: 150–400 ms. Stark abhängig von Modellwahl und Prompt-Größe.
TTS-Time-to-First-Audio: 100–200 ms.
Function Call (falls aufgerufen): 100–500 ms je nach API.
Ein produktionsreifer Stack bringt die Sprechen-oder-nicht-Sprechen-Teile davon in etwa 600 ms gesamt unter. Ein mittelmäßiger Stack landet bei 1,2–1,8 Sekunden. Der mittelmäßige Stack fühlt sich an wie ein Gespräch mit einem Chatbot, der Zeilen abliest. Der gute fühlt sich an wie eine Person.
Die zwei großen Hebel, wenn Sie optimieren wollen: Wählen Sie ein schnelles LLM mit niedriger TTFT (GPT 4.1, Claude 4.6 Sonnet, Gemini 3.0 Flash erreichen alle Produktionsziele), und nutzen Sie ein Turn-Taking-Modell, das auf echten Gesprächsdaten trainiert ist, keinen festen Stille-Schwellenwert. (Warum Latenz wichtig ist)
Ein paar Dinge, die erwähnenswert sind.
„Es sind nur drei APIs, die zusammengeklebt sind.“ Das stimmt, bis Sie versuchen, es echtzeitfähig wirken zu lassen. Dann merken Sie, dass das Kleben mehr zählt als die APIs. Die Orchestrierungsschicht – VAD-Tuning, Turn-Taking-Modell, Streaming-Koordination, Barge-in-Handling, Function-Call-Routing – ist die Stelle, an der produktionsreife Stacks tatsächlich leben. Sie können STT-Anbieter an einem Tag austauschen. Sie können die Orchestrierung nicht austauschen, ohne das halbe System neu zu schreiben.
„Größeres LLM = besserer Sprachagent.“ Nicht wirklich. Für die meisten Sprach-Anwendungsfälle schlägt ein schnelles Mittelklasse-Modell mit einem guten Prompt ein langsames Flaggschiff. Time-to-First-Token zählt mehr als reine Reasoning-Qualität, denn die Wahrnehmung des Anrufers wird fast vollständig von der Latenz geprägt. Retell lässt Sie LLMs mit einem Dropdown wechseln, genau weil die richtige Antwort vom Anwendungsfall abhängt – schweres Reasoning bekommt Claude 4.6 Sonnet, günstiges Hochvolumen bekommt GPT 5 nano, mehrsprachig bekommt Gemini 3.0 Flash, die Standardeinstellung ist GPT 4.1.
„Streaming ist ein Nice-to-have.“ Es ist die gesamte Architektur. Ohne Streaming warten Sie, bis der Anrufer fertig ist, dann warten Sie, bis das STT fertig ist, dann warten Sie, bis das LLM fertig ist, dann warten Sie, bis das TTS fertig ist, und Sie haben 3+ Sekunden verbraucht, bevor ein einziges Byte Audio zurückgeht. Der ganze Grund, warum Sprachagenten 2026 menschlich wirken, ist, dass jede Stufe anfängt, Output auszugeben, bevor die vorherige Stufe fertig ist.
„Sie brauchen ein speziell trainiertes Modell, damit das für Ihren Anwendungsfall funktioniert.“ Fast immer nein. Der Stack von 2026 ist so konzipiert, dass das Modell generisch bleibt und Ihr Prompt + Ihre Wissensdatenbank + Ihre Funktionen die Anpassung übernehmen. Speziell trainierte Modelle sind langsamer zu iterieren, langsamer in der Inferenz und veraltet, sobald ein neues Basismodell erscheint. Die meisten Teams, die „ein eigenes Modell brauchten“, brauchten tatsächlich einen besseren Prompt und eine bessere Wissensdatenbank.
„Die Stimme ist der schwierigste Teil.“ Sie ist tatsächlich einer der einfachsten Teile heute. Standard-TTS-Stimmen sind in Blindtests funktional nicht von menschlichen zu unterscheiden. Die schwierigsten Teile sind Turn-Taking und Barge-in – die Dinge, die Anrufer nicht bewusst bemerken, aber absolut spüren.
Echtzeit-Sprach-KI ist eine Streaming-Pipeline: Audio hinein → STT → LLM → TTS → Audio hinaus, mit Turn-Taking und Barge-in drumherum. Jede Stufe gibt Output aus, bevor die vorherige Stufe fertig wird, die gesamte Schleife schließt in unter 700 ms ab, und die Orchestrierung ist es, die Produktion von Demo trennt. Das ist die Architektur. Es ist keine Magie. Es sind ein paar konkrete technische Probleme, die gut gelöst wurden.
Die meisten Betreiber müssen das nicht selbst bauen. Sie müssen es gut genug verstehen, um zu wissen, was sie kaufen, wonach sie fragen sollten und wo der Build scheitern wird, wenn sie den falschen Anbieter wählen. Wenn dieser Artikel Sie den größten Teil des Weges dorthin gebracht hat, sind Sie in guter Verfassung.
Wenn Sie die Pipeline in Aktion sehen wollen, ist der schnellste Weg, etwas darauf zu bauen. Melden Sie sich kostenlos an unter dashboard.retellai.com – neue Konten erhalten 10 $ Guthaben, rund 90 Minuten Gespräch. Oder buchen Sie eine Demo, und wir gehen die Orchestrierung im Kontext Ihres tatsächlichen Anrufvolumens durch. Wenn Sie die Latenz lieber selbst hören möchten, rufen Sie unsere Live-Demo-Leitung an und sprechen Sie mit einem Agenten, der auf der obigen Pipeline läuft.
F: Was bedeutet STT → LLM → TTS eigentlich? A: Es sind die drei Kernstufen einer Sprach-KI-Pipeline. STT (Speech-to-Text) wandelt das Audio des Anrufers in Text um. Das LLM (großes Sprachmodell) liest diesen Text plus Ihren System-Prompt und entscheidet, was zu sagen oder welche Funktion aufzurufen ist. TTS (Text-to-Speech) wandelt die Antwort zurück in Audio. Wickeln Sie Turn-Taking und Barge-in-Handling darum, und das ist der gesamte Stack.
F: Wie schnell muss Echtzeit-Sprach-KI sein? A: Unter ~700 ms End-to-End-Antwortzeit ist die Schwelle, ab der sich das Gespräch menschlich anfühlt. Darüber beginnen Anrufer zu unterbrechen, sich zu wiederholen und aufzulegen. Produktions-Stacks wie Retell laufen bei etwa 600 ms.
F: Wohin geht die Latenz eigentlich? A: Hauptsächlich in Turn-Taking und LLM-Time-to-First-Token, nicht in STT oder TTS. Ein typisches Budget: Netzwerk 50 ms, VAD/Turn-Taking 200 ms, LLM TTFT 250 ms, TTS erstes Audio 100 ms. STT läuft parallel zur Sprache des Anrufers, fügt also obendrauf fast nichts hinzu.
F: Was ist Streaming und warum ist es wichtig? A: Jede Stufe der Pipeline gibt Output aus, bevor die vorherige Stufe fertig wird. STT gibt alle ~50 ms partielle Transkripte aus. Das LLM streamt Tokens, sobald sie generiert werden. TTS streamt Audio in 200–400-ms-Chunks. Ohne Streaming wartet jede Stufe auf die letzte, und Sie verbringen 3+ Sekunden, bevor ein einziges Byte Audio zum Anrufer zurückgeht.
F: Was ist Turn-Taking und warum ist es schwierig? A: Turn-Taking ist das System, das entscheidet, wann der Anrufer aufgehört hat zu sprechen, damit der Agent antworten kann. Es ist schwierig, weil Menschen mitten im Satz pausieren, Luft holen und „ähm“ sagen, während sie nachdenken. Ein naiver Timeout schneidet Anrufer ab oder wirkt langsam. Die Antwort von 2026 ist ein kleines neuronales Modell, das auf echtem Gesprächs-Audio trainiert ist und eine Wahrscheinlichkeit Dutzende Male pro Sekunde aktualisiert.
F: Was ist Barge-in-Handling? A: Es ist das, was passiert, wenn der Anrufer anfängt, über den Agenten zu reden. Ein guter Stack stoppt das TTS innerhalb von 100 ms, verwirft den Rest der geplanten Antwort und startet einen frischen STT-Stream aus dem neuen Audio des Anrufers. Ein schlechter Stack redet weiter – das schlimmste Gefühl bei einem Telefonanruf.
F: Muss ich die Pipeline selbst bauen? A: Fast nie im Jahr 2026. Die Orchestrierung – VAD, Turn-Taking, Barge-in, Streaming-Koordination, Function-Call-Routing – ist der Teil, in den ernsthafte technische Investition fließt. Die meisten Teams, die versuchen, sie selbst zu bauen, enden mit einer langsameren, schlechteren Version dessen, was von der Stange verfügbar ist. Bauen Sie die Teile, die Ihrem Geschäft proprietär sind: Prompt, Wissensdatenbank, Funktions-Endpoints, Workflows.
F: Spielt die Wahl des LLM wirklich so eine große Rolle? A: Ja, aber hauptsächlich für die Time-to-First-Token, nicht für die reine Qualität. Ein schnelles Mittelklasse-Modell mit einem guten Prompt schlägt für die meisten Sprach-Anwendungsfälle ein langsames Flaggschiff. Retell lässt Sie LLMs mit einem Dropdown wechseln – GPT 4.1 ist die Standardeinstellung, Claude 4.6 Sonnet für höheres Reasoning, GPT 5 nano für günstiges Volumen, Gemini 3.0 Flash für Mehrsprachigkeit. (Preise.)
F: Wie passt Function Calling in die Pipeline? A: Wenn das LLM entscheidet, eine Funktion aufzurufen statt zu sprechen, feuert die Plattform einen HTTPS-Webhook mit strukturierten Argumenten ab, die das Modell aus dem Gespräch extrahiert hat, und wartet dann auf die Antwort. Dieser Round-Trip fügt Latenz hinzu – üblicherweise ein paar hundert Millisekunden für schnelle APIs, mehr für langsame. Bei längeren Wartezeiten sagt der Agent typischerweise „einen Moment, während ich das prüfe“, um die Lücke zu füllen.
F: Was ist der Unterschied zwischen Sprach-KI und einem IVR? A: Ein IVR ist ein fester Entscheidungsbaum (drücken Sie die 1 für Abrechnung). Sprach-KI läuft auf der obigen Pipeline – offene Sprache hinein, LLM-Reasoning in der Mitte, natürliche Antwort hinaus. Anrufer navigieren keine Menüs. Sie sprechen einfach.
Sehen Sie, wie viel Ihr Unternehmen durch den Wechsel zu KI-gestützten Sprachagenten sparen könnte.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Eine Demo-Telefonnummer von Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
