Es war schnell und fühlte sich langsam an
Drei Wochen Arbeit brachten die mittlere Antwortzeit von viereinhalb Sekunden auf unter drei, und die Rückmeldungen änderten sich überhaupt nicht. Wir hatten die Zahl auf unserem Dashboard optimiert statt die, die Menschen erleben.
Die Optimierung, die nichts änderte
Wir hatten ein Latenzproblem in dem Sinne, dass Nutzer den Assistenten langsam nannten. Also haben wir die Arbeit gemacht: schnellerer Reranker, weniger Kandidaten, vorgewärmter Index, paralleler Abruf. Die mittlere Gesamtantwortzeit fiel von rund viereinhalb Sekunden auf unter drei.
Die nächste Rückmelderunde sagte, der Assistent sei langsam. Nicht etwas besser, nicht verbessert: unverändert. Das ist ein irritierendes Ergebnis und vollständig erklärbar — wir hatten nie gemessen, worauf Nutzer reagierten.
Die Zahl, die Menschen spüren
Die Zeit bis zum ersten Token. Alles, bevor das erste Wort erscheint, ist Stille, und in der Stille wohnt die Ungeduld. Unsere Pipeline verbrachte fast ihre gesamte Zeit in diesem Fenster: Abruf, Reranking, Prompt-Aufbau — und erst danach ein Modell, das seine Antwort über ein paar Sekunden streamt.
Wir hatten also anderthalb Sekunden am Streaming-Teil gespart, den Nutzer als eintreffenden Text erleben, und den stillen Teil fast unberührt gelassen. Auf dem Dashboard ist das ein Drittel schneller. Im Chatfenster ist es dieselbe Wartezeit, gefolgt von etwas flotterem Text.
Die Forschung zu genau dieser Zahl
Horton und Kollegen veröffentlichten in jenem Oktober eine Arbeit speziell zur Verkürzung der Zeit bis zum ersten Token und behandeln die Verzögerung vor Beginn der Generierung als eigenes Optimierungsziel statt als Teil einer Gesamtdauer.
Nützlich war, sie als eigenständige Kennzahl benannt zu sehen. Wir hatten ein allgemeines Latenzbudget, und sobald das Budget in Stille und Streaming zerlegt war, war sofort offensichtlich, in welche Hälfte unsere drei Wochen geflossen waren und über welche Hälfte die Nutzer klagten.
| Was wir geändert haben | Wirkung auf die Stille |
|---|---|
| Schnellerer Reranker | Gering. Er war nie der Engpass |
| Abrufstatus an den Nutzer streamen | Groß. Aus Stille wurde Fortschritt |
| Generierung auf Teilkontext starten | Mittel und riskant. Zurückgenommen |
| Embeddings häufiger Fragen cachen | Mittel bei Wiederholungsfragen |
Was tatsächlich gewirkt hat
Dem Nutzer sagen, was geschieht. Die Oberfläche zeigt heute durchsuche die Dokumentation, dann vier Passagen gefunden, dann strömt die Antwort ein. Die Gesamtzeit ist unverändert, und das Erleben ist völlig anders — denn eine Wartezeit mit Information ist nicht dasselbe wie eine Wartezeit.
Das ist kein Trick. Die Meldungen sind echt: Sie geben die tatsächliche Stufe wieder, und dauert der Abruf ungewöhnlich lange, bleibt die Meldung länger stehen. Das ist ehrlich und sagt dem Nutzer zugleich, dass etwas Bestimmtes passiert, statt dass das System hängt.
Was wir versucht und zurückgenommen haben
Die Generierung vor dem Ende des Abrufs zu starten, auf den ersten Passagen, damit die ersten Wörter früher erscheinen. Das nahm der Stille knapp eine Sekunde und veränderte Antworten, weil das Modell sich auf eine Richtung festlegte, bevor die beste Passage eingetroffen war.
Wir haben es auf dem Referenzset gefangen statt im Betrieb, und das ist der eine Teil dieser Episode, über den wir froh sind. Eine Optimierung, die verändert, was das System sagt, ist keine Latenzänderung — sie musste als Qualitätsänderung bewertet werden, und dabei fiel sie durch.
Wo Streaming die falsche Antwort ist
Nicht jede Antwort sollte strömen. Wo die Ausgabe ein strukturierter Datensatz ist, den ein nachgelagerter Schritt verbraucht, bringt Streaming nichts und kostet die Möglichkeit, vor der Anzeige zu validieren. Solche Schritte liefern vollständig oder gar nicht.
Falsch ist es auch, wo eine Teilantwort in die Irre führt. Eine Antwort, die mit die Frist beträgt vierzehn Tage beginnt und mit sofern der Rahmenvertrag nichts anderes bestimmt fortfährt, liest sich nach zwei Sekunden ganz anders als nach vier — und wer nach dem ersten Halbsatz handelt, wurde von unserer Oberfläche in die Irre geführt, nicht von unserem Modell.
Was wir heute messen
Drei Zahlen je Anfrage statt einer: Zeit bis zum ersten Token, Gesamtdauer und die Zeit je Pipeline-Stufe. Die erste steht auf dem Dashboard, das Kunden sehen, denn sie entspricht dem, was deren Nutzer ihnen sagen werden.
Wir halten außerdem fest, ob die Antwort bis zum Ende strömte oder der Nutzer weggeklickt hat. Abbrüche während der Stille sind das klarste Signal, dass eine Schwelle überschritten wurde — und es bewegte sich, als die Fortschrittsmeldungen kamen. So wissen wir, dass sie nicht bloß kosmetisch waren.
Was wir nicht behaupten
Wir behaupten nicht, die Gesamtlatenz sei gleichgültig. Sie zählt, besonders bei Schritten, auf die kein Mensch wartet, wo sie Durchsatz und Kosten bestimmt. Unser Punkt ist, dass die beiden Zahlen verschiedenen Zwecken dienen und wir die eine benutzt hatten, um über die andere nachzudenken.
Wir behaupten auch nicht, Fortschrittsmeldungen heilten ein wirklich langsames System. Jenseits weniger Sekunden helfen sie nicht mehr, und ein System, das regelmäßig acht Sekunden sucht, hat ein Architekturproblem, das keine noch so ehrliche Erzählung verdeckt.