Um die Latenzparität über 32 Sprachen hinweg zu erreichen, ohne das Modell aufzublähen, war eine Modell-Routing-Ebene erforderlich, die wir nicht erwartet hatten. Notizen aus dem Latency War Room.
Bei unserem Sprachprodukt gab es zwei Beschwerden, die wir intern nicht klären konnten. Bei englischsprachigen Unternehmenskunden fühlte sich die KI bissig an. Bei Kunden, die Mandarin sprechen – und zunehmend auch bei Kunden, die Vietnamesisch, Tagalog und Hindi sprechen – fühlte sich die KI träge an. Die Lücke, gemessen vom Schweigen des Anrufers bis zur ersten Silbe der KI, betrug 260 ms auf Englisch und 540 ms auf Mandarin. Beide Zahlen lagen innerhalb des veröffentlichten Latenzbudgets.
Nur einer von ihnen fühlte sich bei einem Telefonat akzeptabel.
Der Instinkt eines jeden Entwicklungsteams, das eine Latenzlücke erkennt, besteht darin, das Modell zu bearbeiten. Schnellere Schlussfolgerung. Kleineres Modell. Bessere Quantisierung. Das haben wir alles gemacht. Es verschaffte uns auf der ganzen Linie 60 ms, was nichts brachte – der relative Abstand war immer noch da und Englisch blieb doppelt so schnell.
Die eigentliche Lösung ergab sich aus einer anderen Beobachtung: Wir behandelten die Latenz als Modellproblem, obwohl es sich tatsächlich um ein Routing-Problem handelte.
Die Aufteilung der 540-ms-Mandarin-Antwort in Segmente war das erste, was das Problem klärte. Die Abrechnung sah ungefähr so aus:
Auf dem englischen Weg kamen die gleichen Segmente bei 80/60/90/80/40 vor. Die beiden Segmente, die dramatisch voneinander abwichen, waren Speech-to-Text und Large-Model-Generierung. STT war in Mandarin langsamer, weil das akustische Modell mit einem längeren Kontextfenster trainiert wurde – notwendig für die tonale Disambiguierung –, das den ersten Token um 80 ms verschob.
Die Modellgenerierung war langsamer, da der Tokenisierer auf Mandarin mehr Token pro Zeichen mit gleicher Bedeutung erzeugte als auf Englisch.
Beides war kein Modellfehler. Beides waren Kompromisse, die von unabhängigen Teams stillschweigend angesammelt wurden, um ihre eigenen Metriken zu optimieren – STT für Genauigkeit, LLM für Generierungsqualität. Die Latenzkosten waren real, aber es war niemandes Gewinn- und Verlustrechnung.
Wir haben aufgehört, alle Sprachen über ein einziges LLM zu leiten. Stattdessen haben wir vor der Generierung eine dünne Klassifizierungsschicht aufgebaut, die in weniger als 8 ms drei Dinge erkennt: die Sprache der eingehenden Äußerung, die Konversationsabsichtsklasse und ob die Anfrage eines von etwa 40 Hochfrequenzmustern ist, die wir durch Clustering von 2 Millionen Anrufsegmenten identifiziert haben.
Wenn der Klassifikator ein Hochfrequenzmuster in einer nicht-englischen Sprache identifiziert, leiten wir die Generierung an ein kleineres, sprachspezialisiertes Modell weiter, das dieses Muster direkt verarbeitet. Das kleinere Modell wurde auf Millionen von Vervollständigungen desselben Musters destilliert, sodass seine Qualität auf diesen spezifischen Pfaden im Rahmen des Rauschens des großen Modells liegt – aber seine Latenz beim ersten Token beträgt etwa ein Drittel.
Wenn der Klassifikator eine Endabsicht erkennt – alles, was nicht in den 40 Mustern liegt – wird die Anfrage wie zuvor an das große Modell weitergeleitet. Der größte Teil des Latenzabfalls ist auf die Tatsache zurückzuführen, dass die Hochfrequenzmuster vorhanden sind Auch die Muster, die etwa 78 % des Anrufvolumens ausmachen. Die Tail Cases zahlen die ursprüngliche Latenz, sind aber selten.
Der Dünnsichter war der Teil des Projekts, für den niemand ein Budget hatte. Der Aufbau dauerte länger als der Aufbau des Routingsystems selbst, da die Fehlermöglichkeiten subtil waren. Ein Klassifikator, der 1 % der Anfragen fehlleitet und an ein kleines Modell weiterleitet, das sie nicht verarbeitet, erzeugt Halluzinationen und nicht nur verschlechterte Antworten.
Drei Dinge sorgten dafür, dass der Klassifikator funktionierte. Zunächst wurde das Training auf realem Produktionsverkehr und nicht auf synthetischen Daten durchgeführt. Zweitens wurde ein Konfidenzwert zurückgegeben, den der Router als Schwellenwert festlegen konnte – alles unter einem Konfidenzwert von 0,91 fällt automatisch auf das große Modell durch.
Drittens haben wir es sechs Wochen lang im Schatten der bestehenden Pipeline eingesetzt, wobei das große Modell die Wahrheit lieferte, bevor der Datenverkehr tatsächlich an kleine Modelle weitergeleitet wurde.
Bei der Schattenbereitstellung wurden vier Klassen von Fehlern gefunden, die der Offline-Testsatz übersehen hatte. Zwei davon ließen sich in den Trainingsdaten leicht beheben. Zwei erforderliche bewusste Routing-Regeln: Alles, was Identitätsprüfung, Zahlungen oder Terminstornierung betrifft, geht immer an das große Modell, unabhängig von der Zuverlässigkeit des Klassifikators, da die Kosten einer Halluzination auf diesen Pfaden höher sind als der Latenzgewinn.
Während die LLM- und STT-Änderungen überprüft wurden, arbeitete ein paralleles Team an der Sprachausgabe. Das 50 ms lange TTS-Erstaudio auf Englisch war praktisch unschlagbar; Die Lücke von 70 bis 90 ms bei den meisten nicht-englischen Sprachen wurde durch kleinere Sprachmodelle, weniger aggressives Caching und einen einzigen gemeinsamen GPU-Pool verursacht, der Englisch unter Last Vorrang einräumte.
Wir teilen die TTS-Infrastruktur in sprachgebundene Pools auf. Mandarin TTS läuft jetzt in einem eigenen Pool mit eigenen Skalierungsregeln auf Hardware in der Nähe der Regionen, aus denen der Großteil unseres Mandarin-Verkehrs stammt. Die Latenz sank innerhalb von zwei Wochen nach der Umstellung von 70–90 ms auf 45 ms.
Nichts davon war klug; Es handelte sich um eine Infrastrukturarbeit, um die sich niemand die Mühe gemacht hatte, weil die geringfügige Verbesserung einer einzelnen Sprache sie für sich genommen nicht gerechtfertigt hatte.
Die Lektion – und wir schreiben sie jetzt intern nieder – ist, dass „wir nicht in diese Investition investiert haben, weil keine einzelne benutzerorientierte Kennzahl dies rechtfertigte“ genau die Art von Entscheidung ist, die über einen Zeitraum von vier Jahren zu einer Lücke von 280 ms zwischen zwei Sprachen führt.
Eine kleine, aber folgenreiche Änderung, die wir intern vorgenommen haben, betraf die Art und Weise, wie das Latenz-Dashboard des Teams Berichte erstellt. Früher haben wir die p50 und p95 der End-to-End-Latenz, gemittelt über alle Sprachen, anhand eines einzelnen SLO verfolgt. Das Armaturenbrett sah die meiste Zeit grün aus.
Das neue Dashboard meldet p50 und p95 pro Sprache gegen a Parität SLO – die Lücke zwischen der langsamsten und der schnellsten unterstützten Sprache hat ein eigenes Budget, das separat durchgesetzt wird. Wir legen das Paritätsbudget auf 60 ms fest. Wenn die Lücke das Budget übersteigt, wird der Bereitschaftsdienst gerufen.
Das Paritäts-Dashboard macht etwas, was das durchschnittliche Dashboard nicht konnte: Es macht Regressionen in der langsamsten Sprache mit der gleichen Dringlichkeit sichtbar wie Regressionen in der schnellsten. Wenn Sie über 32 Sprachen mitteln, verschiebt eine 200-ms-Regression in Vietnamesisch den Durchschnitt um 6 ms. Wenn Sie die Parität messen, wird das Dashboard um 200 ms verschoben.
Nach der Routing-Arbeit, den TTS-Pools und dem Paritäts-Dashboard liegt unsere schlechteste Sprache (Kantonesisch, hauptsächlich weil der unterstützende Akustikmodellkorpus kleiner ist) bei 320 ms. Englisch ist bei 220 ms. Die verbleibende Lücke von 100 ms ist real und wir wissen ungefähr, wo sie liegt – das kantonesische STT-Akustikmodell ist älter und noch nicht auf der neuen Architektur, und wir werden es im dritten Quartal neu trainieren.
Aber „die langsamste Sprache ist 100 ms hinter der schnellsten“ ist eine andere Konversation als „die langsamste Sprache ist 280 ms hinter der schnellsten“. Ersteres ist eine bekannte Regression mit einer geplanten vierteljährlichen Korrektur. Letzteres war ein kundenbedingter Notfall, von dem wir nicht wussten, dass wir ihn hatten.
Drei Dinge, in der Reihenfolge ihrer Priorität, wenn wir den Latenzstapel mit dem, was wir jetzt wissen, von Grund auf neu aufbauen würden.
Nichts davon ist eine neuartige Forschung. Nichts davon erforderte ein Papier. Es war erforderlich, die Latenzparität als Produktverpflichtung zu behandeln und dann die unrühmliche Infrastruktur zu finanzieren, um die Verpflichtung zu unterstützen. Wir haben jetzt die Parität, die wir brauchen. Wir hatten es vier Jahre lang nicht.
KI-Rezeptionisten, Großhandelsrouten, virtuelle Nummern – aufgebaut auf einer Plattform mit transparenten Preisen und einem 24/7-NOC.