Ich sah, wie eine Drive-in-KI einen stotternden Menschen unterbrach. Dann baute ich etwas anderes.

Es gibt ein Video, das auf Reddit die Runde macht. Eine Frau am Drive-in-Schalter eines Wendy's versucht, einen Baconator zu bestellen. Sie stottert – eine Blockade beim „b“ – und die KI unterbricht sie mitten im Wort und schlägt fröhlich einen Frosty vor. Sie versucht es erneut. Das System interpretiert ihre Wiederholung als neue Bestellung. Drei Versuche später schreit sie „AGENT“ in eine Lautsprecherbox, der das egal ist.

Ich habe mir dieses Video wahrscheinlich dreißig Mal angesehen. Nicht, weil es lustig ist – ist es nicht –, sondern weil sich jedes Scheitern in dieser Interaktion präzise auf eine architektonische Entscheidung zurückführen lässt, die irgendjemand in einem Konferenzraum getroffen hat, vermutlich während er auf eine Folie schaute, auf der „86 % Erfolgsquote“ stand.

Diese verbleibenden 14 %? Das sind echte Menschen. Und ich würde behaupten, dass die Architektur von Anfang an nie für sie gebaut wurde.

Dies ist die Geschichte, warum mein Team bei Veriprajna den besseren Teil von zwei Jahren damit verbracht hat, den schnellsten Weg zur Marktreife in der Sprach-KI abzulehnen – und was wir stattdessen gebaut haben.

Was bedeutet „Enterprise-Grade-Sprach-KI“ eigentlich?

Die meisten Unternehmen in unserem Bereich tun etwas bemerkenswert Einfaches: Sie verbinden ein Mikrofon mit einer API. OpenAI, Google, Anthropic – such dir dein Lieblings-Large-Language-Model aus, leite Audio hinein, erhalte Text zurück, generiere eine Antwort. Ausliefern.

Ich nenne das den API-Wrapper-Ansatz, und er funktioniert wunderbar in einer Demo. Ruhiger Raum, klarer Sprecher, einfache Anfrage. Die Demo funktioniert immer.

Die Demo funktioniert immer. Der Drive-in um 23:47 Uhr mit einem im Leerlauf brummenden Diesel-Lkw hinter dir und einem schreienden Kleinkind auf der Rückbank – das ist der Ort, an dem Architektur wirklich zählt.

Das Wendy's-FreshAI-System – aufgebaut auf Vertex AI von Google Cloud – ist wahrscheinlich das prominenteste Beispiel für diesen Ansatz im großen Maßstab. Und die berichteten Kundenerfahrungen sagen alles über seine Grenzen aus: Kunden, die drei oder mehr Versuche für einfache Bestellungen brauchen, das System, das Menschen mitten im Satz unterbricht, um ihnen Artikel vorzuschlagen, nach denen sie nie gefragt haben, und eine Erfahrung, die für jeden mit einer Sprechstörung als „unbrauchbar“ beschrieben wird.

Dennoch expandiert Wendy's auf 500 bis 600 Standorte. Der Grund ist einfache Mathematik – das System erhöht den durchschnittlichen Bestellwert durch Upselling, und die Zahlen zur Personaleffizienz machen sich gut in einem vierteljährlichen Ergebnisbericht. Wenn du für den Durchschnitt optimierst, ist die Architektur ein Erfolg. Wenn du die Person bist, für die sie nicht funktioniert, ist die Architektur kaputt.

Ich habe diese Spannung ausführlich untersucht in der interaktiven Version unserer Forschung. Aber das Kernargument ist eines, das ich persönlich vorbringen möchte, weil es geprägt hat, wie wir alles bauen.

Die Nacht, in der uns klar wurde, dass das Mikrofon der falsche Ausgangspunkt war

Es war etwa 21 Uhr an einem Donnerstag im Spätfrühling. Ich, mein Mitgründer und zwei Ingenieure standen auf dem Parkplatz eines stillgelegten Taco Bell, den wir für Tests nutzen durften. Wir hatten unseren Prototyp an einem Pfosten montiert – ein Lautsprecher, ein Mikrofon, etwas Klebeband, das alles zusammenhielt. Wir hatten ihn im Labor wochenlang mit etwa 95 % Genauigkeit laufen lassen. Wir fühlten uns bereit.

Das erste Auto, das vorfuhr, war eine Frau in einem Honda Civic mit halb heruntergelassener Scheibe. Sie sagte deutlich genug: „Ich hätte gerne ein Nummer-drei-Combo.“ Das System hörte „island numb recon bowl“. Ich sah meinen Mitgründer an. Er sah auf den Boden.

Die Genauigkeit war nicht nur schlecht – sie war unbrauchbar. Wir standen noch zwei weitere Stunden auf diesem Parkplatz, führten Test um Test durch, und die Zahlen wurden nur schlechter, als der Abendverkehr zunahm. Ich erinnere mich an den genauen Moment, in dem ich aufhörte, Frustration zu empfinden, und anfing, etwas zu spüren, das eher an Angst grenzte: Das war kein Feinabstimmungsproblem. Unser gesamter Ansatz war falsch.

Das Problem war nicht das Sprachmodell. Das Modell war in Ordnung. Das Problem war alles, was passierte, bevor das Audio das Modell erreichte. Windgeräusche. Motorendröhnen. Das mechanische Summen einer Klimaanlage sechs Meter entfernt. Eine Autohupe drei Blocks weiter. Unser System konnte den Unterschied zwischen einer menschlichen Stimme und einem Dieselmotor nicht erkennen, weil es ihm auf der Signalebene niemand beigebracht hatte.

Das war der Moment, in dem ich etwas verstand, das die meisten Menschen in diesem Bereich meiner Meinung nach immer noch nicht verinnerlicht haben: Sprach-KI ist kein NLP-Problem. Sie ist zuerst ein Signalverarbeitungsproblem, zweitens ein linguistisches Problem und drittens ein NLP-Problem. Wenn deine erste Schicht kaputt ist, kann dich nichts weiter unten in der Kette retten.

Warum unterbricht Drive-in-KI immer wieder Menschen?

Der Übeltäter ist etwas, das Sprachaktivitätserkennung heißt – VAD. Es ist das System, das entscheidet, wann du angefangen hast zu sprechen und wann du aufgehört hast. In den meisten Wrapper-Lösungen ist es eine einfache Energieschwelle: Steigt der Ton über eine Linie, beginnt die Aufnahme; fällt der Ton unter eine Linie, stoppt die Aufnahme.

Denk mal darüber nach, in einem Drive-in. Du hältst eine halbe Sekunde inne, um auf die Menütafel zu schauen. Die Energie fällt ab. Die VAD entscheidet, dass du fertig bist. Sie sendet ein Satzfragment an das Modell, das Modell halluziniert eine Antwort auf eine Frage, die du nie zu Ende gestellt hast, und jetzt streitest du mit einer Lautsprecherbox.

Wir haben unsere VAD von Grund auf neu gebaut. Statt Energieschwellen verwenden wir neuronale Modelle – Silero, Cobra –, die einen Wahrscheinlichkeitswert für menschliche Sprache über verschiedene Frequenzen hinweg ausgeben. Statt eines binären An/Aus liefert unser System einen Konfidenzwert. Und statt einer statischen Pausentoleranz von 500 Millisekunden verwenden wir ein dynamisches Fenster von 600 bis 1.000 Millisekunden, das sich je nach Gesprächskontext anpasst.

Der Trick, der jedoch den größten Unterschied machte, war das, was wir spekulative Transkription nennen. Das System beginnt bei 250 Millisekunden mit der Audioverarbeitung, legt sich aber erst nach 600 Millisekunden bestätigter Stille auf einen Endpunkt fest. Diese Überlappung reduziert die wahrgenommene Latenz um 350 bis 600 Millisekunden und beseitigt gleichzeitig verfrühte Unterbrechungen.

Mein Mitgründer argumentierte wochenlang, das dynamische Pausenfenster sei überkonstruiert. Wir waren spät nachts im Büro – kalter Kaffee, Whiteboards voller Latenzdiagramme –, und er schob seinen Stuhl zurück und sagte: „Wir verbringen drei Ingenieurwochen mit einem Feature, das eine halbe Sekunde spart. Niemand hält an einem Drive-in eine ganze Sekunde inne. Das ist ein Eitelkeitsproblem.“ Ich sagte so etwas wie: „Und wenn du dich irrst, haben wir ein System gebaut, das jeden Kunden unterbricht, der nachdenken muss.“ Wir sprachen den Rest der Nacht nicht miteinander. Er ging gegen Mitternacht. Ich blieb und ließ weiter Simulationen laufen.

Dann testeten wir es mit echten Kunden. Es stellte sich heraus, dass Menschen ständig innehalten – sie schauen auf die Karte, drehen sich um, um einen Mitfahrer zu fragen, was er möchte, überlegen, ob sie wirklich Pommes brauchen. Eine ganze Sekunde natürlicher Pause ist keine Stille. Es ist Nachdenken. Mein Mitgründer schickte mir nach den Testergebnissen eine einzeilige Nachricht: „Du hattest recht. Tut mir leid wegen des Stuhls.“

Wenn du auf Geschwindigkeit statt auf Geduld optimierst, baust du ein System, das nur für Menschen funktioniert, die bereits wissen, was sie wollen.

80 Millionen Menschen

Stottern betrifft weltweit über 80 Millionen Menschen. Diese Zahl kam bei mir nach dem Parkplatz anders an.

Es äußert sich in Wiederholungen („b-b-b-baconator“), Dehnungen („mmmmilch“) und Blockaden – stillen Pausen mitten in einem Wort, in denen die Person körperlich keinen Laut hervorbringen kann.

Denk nun darüber nach, was eine Standard-VAD mit einer Blockade macht. Die Person hört mitten im Wort auf, Laute zu erzeugen. Das System interpretiert Stille als Ende des Sprechbeitrags. Es antwortet auf ein halbes Wort. Die Person versucht es erneut. Das System behandelt die Wiederholung als neue Bestellung. Innerhalb von zehn Sekunden hast du eine verwirrte KI, einen frustrierten Menschen und eine Schlange von Autos, die sich dahinter bildet.

Das ist kein Randfall. Das ist eine Designentscheidung. Wenn du ein ASR-Modell (Automatic Speech Recognition) fast ausschließlich mit „Standard“-US-Englisch trainierst – gut artikuliert, minimale Pausen –, triffst du eine Entscheidung darüber, für wen dein System da ist. Forschung zeigt, dass Conformer-basierte ASR-Modelle (eine neuronale Architektur, die Faltung mit Self-Attention für die Audioverarbeitung kombiniert), das Rückgrat der meisten modernen Systeme, ihre Leistung bei gestörter Sprache so stark verschlechtern, dass einige negative semantische Ähnlichkeitswerte zurückgeben. Nicht nur ungenau – semantisch invertiert.

Wenn dein KI-Modell bei gestörter Sprache negative semantische Werte zurückgibt, hast du kein System gebaut, das mit Randfällen kämpft. Du hast ein System gebaut, das nie dafür ausgelegt war, einen bedeutenden Teil der Menschheit zu hören.

Ein Investor sagte mir einmal ganz unverblümt: „Nutz einfach die API und optimiere später. Du verbrennst Runway für ein Problem, das einen kleinen Prozentsatz der Kunden betrifft.“ Ich rief die Zahlen auf meinem Handy auf – 80 Millionen Menschen allein mit Stottern, bevor du Akzente, ESL-Sprecher (English as a Second Language), ältere Kunden und alle mitzählst, die in einem lauten Auto bestellen. Ich beobachtete, wie sich sein Gesichtsausdruck veränderte. „Das ist kein kleiner Prozentsatz“, sagte er. „Nein“, sagte ich. „Ist es nicht.“

Wir optimieren selbstüberwachte Modelle mit neu annotierten Datensätzen unflüssiger Sprache. Wir verwenden synthetisches Einfügen von Unflüssigkeiten – wir nehmen flüssige Transkripte, fügen Blockaden und Wiederholungen hinzu und synthetisieren sie zu Trainingsaudio. Es ist mühsame Arbeit. Es ist nicht die Art von Sache, die in einer Feature-Vergleichstabelle auftaucht. Aber es ist der Unterschied zwischen einem System, das für alle funktioniert, und einem System, das für den Durchschnitt funktioniert.

Was passiert, wenn Sprach-KI am Edge statt in der Cloud läuft?

Jedes Wort, das in ein Drive-in-Mikrofon eines Wendy's gesprochen wird, reist über das öffentliche Internet zu einem Google-Rechenzentrum und zurück. Dieser Hin- und Rückweg kostet 100 bis 500 Millisekunden, bevor das Modell überhaupt mit der Verarbeitung beginnt. Bei der Sprachinteraktion ist der Goldstandard eine Reaktionszeit von unter 300 Millisekunden – alles darüber, und das Gespräch fühlt sich nicht mehr natürlich an. Bei 700 bis 900 Millisekunden fühlt es sich wie ein schlechtes Telefongespräch an. Bei zwei Sekunden fangen Menschen an, über das System hinwegzureden.

Wir haben alles an den Edge verlagert. Lokale Verarbeitung auf spezialisierter Hardware am Restaurantstandort. Unsere Latenz fiel auf 5 bis 10 Millisekunden.

Aber die eigentliche Erkenntnis war nicht nur die Geschwindigkeit – es war die Modellgröße. Ein Allzweck-LLM muss alles über alles wissen. Ein domänenspezifisches Small Language Model muss wissen, dass „Dave's Single“ ein Burger ist und kein Musikalbum. Dieser Fokus bedeutet schnellere Inferenz, vorhersehbarere Antworten und einen Bruchteil der Rechenkosten. Wir haben 3-fache Geschwindigkeitsverbesserungen und 30 bis 40 % niedrigere Betriebskosten im Vergleich zu cloudbasierten Ansätzen gesehen.

Die Edge-Architektur löste auch ein Problem, das wir nicht vollständig vorhergesehen hatten: Zuverlässigkeit. Wenn das Internet ausfällt – und das wird es –, wird ein cloudabhängiges System zu einem sehr teuren Briefbeschwerer. Unser System läuft weiter. Für die vollständige technische Aufschlüsselung unserer Edge-Architektur im Vergleich zu Cloud-Ansätzen kannst du dich vertiefen in das Forschungspapier.

Die regulatorische Wand, über die niemand spricht

CAN-ASC-6.2:2025 landete Anfang 2025 auf meinem Schreibtisch, und ich erinnere mich, dass ich es mit einem Gefühl zwischen Erleichterung und Bestätigung las – hier war ein Standard, der endlich aussprach, worauf wir hingearbeitet hatten: Menschen mit Behinderungen müssen in die Gestaltung, das Testen und die Governance von KI-Systemen einbezogen werden. Nicht als nachträglicher Einfall. Von Anfang an. Der European Accessibility Act tritt im Juni 2025 mit hohen Bußgeldern in Kraft, und der ADA wird neu ausgelegt, um digitale Barrieren für Menschen mit Sprechbehinderungen abzudecken. Ein nicht konformes System über 600 Standorte hinweg nachzurüsten kostet ungefähr fünfmal so viel, wie es kostet, es von Anfang an richtig zu bauen.

„Was, wenn wir nur einen wirklich teuren Weg bauen, um eine Burger-Bestellung aufzunehmen?“

Dieser Gedanke traf mich gegen 2 Uhr morgens, vielleicht sechs Monate nach Beginn der Entwicklung. Ich war allein im Büro und starrte auf ein Spektrogramm eines gestotterten Wortes, das unser System immer noch nicht verarbeiten konnte. Wir waren seit Monaten dran. Wir hatten den größten Teil unserer anfänglichen Finanzierung aufgebraucht. Und die API-Wrapper-Unternehmen lieferten Produkte aus, während wir noch Signalverarbeitungs-Pipelines debuggten.

Ich hätte es fast aufgegeben. Fast beschlossen, einfach die API zu wrappen, etwas auszuliefern und später zu iterieren wie alle anderen.

Aber „später iterieren“ ist eine Lüge in der Sprach-KI. Sobald du deine Architektur um cloudabhängige, VAD-schwellenbasierte, ausschließlich auf flüssige Sprache ausgerichtete Annahmen herum gebaut hast, verstärkt jede Kundeninteraktion diese Annahmen in deinen Trainingsdaten. Du iterierst nicht in Richtung Barrierefreiheit. Du iterierst von ihr weg.

Baue zuerst für den Randfall, und der Durchschnittsfall erledigt sich von selbst. Baue für den Durchschnitt, und der Randfall wird nie behoben.

Das Turn-Taking-Problem, das mich alles überdenken ließ

Es gibt eine Feinheit menschlicher Konversation, die wir völlig für selbstverständlich halten. Wenn du sagst „Ich hätte gerne einen Baconator und …“ – dieses nachklingende „und“ signalisiert, dass du noch nicht fertig bist. Ein menschlicher Kassierer würde warten. Die meisten Drive-in-KIs tun das nicht.

Wir haben das, was ich als konversationelle Grammatik verstehe, in unsere Endpointing-Logik eingebaut. Das System analysiert linguistische Hinweise in Echtzeit: Konjunktionen, die eine Fortsetzung signalisieren, Tonhöhenänderungen, die einen Abschluss signalisieren, den Ausdruck „das ist alles“, der genau das bedeutet, was er sagt. Wenn ein Kunde „das ist alles“ sagt, antwortet unser System in unter 200 Millisekunden, weil die Absicht eindeutig ist. Wenn er mit „und …“ verstummt, wartet es, selbst durch eine ganze Sekunde Stille hindurch.

Hier lebt auch unsere Human-in-the-Loop-Philosophie. Wir glauben nicht, dass KI die gesamte Transaktion unbeaufsichtigt abwickeln sollte. Einfache, transaktionale Anfragen – die erledigt die KI. Komplexe Situationen, frustrierte Kunden, reibungsintensive Momente – die werden an einen Menschen eskaliert, bevor die Interaktion zusammenbricht, nicht danach.

Das Ziel war nie, den Menschen am Drive-in zu ersetzen. Es war, sicherzustellen, dass kein Kunde jemals „AGENT“ in eine Maschine schreien muss, die nicht zuhört.

Ich komme immer wieder auf diese 86 % Erfolgsquote zurück, die Wendy's meldete. In den meisten Software-Kontexten wären 86 % ein Versagen. Stell dir eine Banking-App vor, die 86 % der Transaktionen korrekt verarbeitet. Stell dir ein Navigationssystem vor, das dich in 86 % der Fälle zum richtigen Ziel bringt. Der Drive-in hat irgendwie eine Fehlerquote normalisiert, die in jeder anderen Verbraucherinteraktion inakzeptabel wäre.

Das ist ein Architekturproblem, kein KI-Problem

Das Muster, das ich in der gesamten Branche sehe, sind Unternehmen, die Sprach-KI als eine Software-Schicht behandeln – etwas, das man mit dem richtigen API-Schlüssel auf die bestehende Infrastruktur aufsetzt. Und ich verstehe, warum. Es ist schnell, es ist billig, und die Demos sind unglaublich.

Aber der Drive-in ist keine Demo. Es sind Dieselmotoren und Wind und Kleinkinder und Akzente und Stottern und Menschen, die zum Nachdenken innehalten. Es ist die volle, nicht reduzierbare Komplexität menschlicher Kommunikation, die in der schlechtestmöglichen akustischen Umgebung stattfindet. Da kannst du dich nicht mit einem Wrapper hindurchmogeln.

Die Unternehmen, die diesen Markt gewinnen werden – und ich sage das mit der Voreingenommenheit von jemandem, der seine Karriere darauf gesetzt hat –, sind diejenigen, die bereit sind, in die Tiefe zu gehen. Tief in die Signalverarbeitung. Tief in die akustische Modellierung. Tief in die Linguistik dessen, wie Menschen tatsächlich sprechen, nicht wie ASR-Trainingsdaten sagen, dass sie sprechen sollten. Tief in die Edge-Infrastruktur, die nicht von einem Rechenzentrum tausend Meilen entfernt abhängt.

In der Sprach-KI gibt es keine Abkürzungen. Es gibt nur die rigorose, unglamouröse, zutiefst technische Arbeit, Systeme zu bauen, die jeden Kunden hören. Nicht 86 % von ihnen. Jeden Einzelnen.

Das ist es, was Enterprise-Grade bedeutet. Und bis die Branche diese Definition akzeptiert, werden wir weiterhin Videos von Drive-in-Lautsprechern anschauen, die das Wort „Baconator“ nicht verstehen können.