Wo die Millisekunden hingehen: ein Latenzbudget für RAG
Eine RAG-Anfrage erscheint langsam, lange bevor sie tatsächlich langsam ist. Zu wissen, welche der fünf Phasen dafür verantwortlich ist, macht den Unterschied zwischen einer gezielten Korrektur und drei Wochen des Ersetzens des falschen Komponenten.
Was passiert ist
Benutzer berichten, dass der Assistent langsam ist. Das Team profilert das Modell, stellt fest, dass die Generierung der Flaschenhals ist, und verbringt einen Sprint damit, es zu optimieren. Die wahrgenommene Latenz bewegt sich kaum, weil das eigentliche Problem eine sequenzielle Kette war: Die Retrieval-Funktion wartete auf die Query-Umschreibung, die Reranking-Funktion wartete auf die Retrieval-Funktion, und keine davon überlappte sich.
Warum es für Deployment-Teams wichtig ist
Latenz ist ein Budget, und wie bei jedem Budget ist die erste Anforderung, zu wissen, wohin es geht. Eine typische RAG-Anfrage hat fünf Stufen — Query-Verständnis, Retrieval, Reranking, Verpackung, Generierung — und in einem gesunden System liegen diese bei etwa 20 bis 60 Millisekunden, 20 bis 60, 40 bis 150, vernachlässigbar und 300 bis 900 Millisekunden jeweils. Zwei Zahlen sind wichtiger als die Gesamtsumme: Die Zeit bis zum ersten Token, die die Benutzer tatsächlich wahrnehmen, und die p99, die sie sich merken.
Was dagegen unternommen werden kann
Instrumentieren Sie jede Stufe separat, bevor Sie etwas optimieren; die meisten Teams irren sich darüber, welche Stufe dominant ist. Suchen Sie dann nach Arbeit, die sequenziell durchgeführt wird, die sich jedoch überlappen könnte — Query-Umschreibung und Embedding können parallel mit Metadatenabfragen durchgeführt werden. Reduzieren Sie die Kandidatensammlung, die an den Reranker gesendet wird, bevor Sie den Reranker selbst optimieren. Cachen Sie aggressiv: Retrieval und Reranking sind deterministisch für eine gegebene Corpusversion, und Supportanfragen wiederholen sich weit häufiger, als Teams erwarten.
Der billige Gewinn
Streamen. Die Zeit bis zum ersten Token ist ebenso eine Produktentscheidung wie eine technische, und das Streamen einer partiellen Antwort bei 400 Millisekunden fühlt sich wesentlich schneller an als eine vollständige Antwort bei 1.400 Millisekunden. Dies ist in der Regel die größte veränderte wahrgenommene Leistung, die verfügbar ist, und sie kostet nur einen Nachmittag.