Ihre RAG-Pipeline besteht einen Standard-Lasttest mit Bravour. Die p95-Latenz sieht gut aus. Die Fehlerraten liegen nahe bei Null.

Ihre RAG-Pipeline besteht einen Standard-Lasttest mit Bravour. Die p95-Latenz sieht gesund aus. Die Fehlerraten liegen nahe bei Null. Dennoch berichten Nutzer von Antworten, die der Frage ausweichen, Dokumente zitieren, die nicht existieren, oder irrelevante Absätze aus einem Whitepaper hervorholen, das vor sechs Monaten hochgeladen wurde. Das Dashboard sagt, alles sei in Ordnung. Die Nutzererfahrung sagt, es sei kaputt.

Diese Diskrepanz besteht, weil herkömmliche Performance-Tests für Request-Response-Systeme entwickelt wurden, nicht für Systeme, die „denken“. Wenn Sie tausend parallele Anfragen an einen REST-Endpunkt senden, erfahren Sie, ob Ihre Server stabil bleiben. Sie erfahren nichts darüber, ob Ihre Retrieval-Schicht die richtigen Chunks abruft, ob Ihr Prompt-Template den Kontext bewahrt oder ob das Modell Quellen erfindet, wenn der Vektorspeicher leer ausgeht. Standard-Lasttests messen die Geschwindigkeit. RAG-Anwendungen erfordern, dass Sie das Verständnis messen.

Jenseits von Status Code 200

Ein typischer API-Lasttest prüft drei Dinge: Verfügbarkeit, Latenz und Durchsatz. Er fragt, ob der Server geantwortet hat, wie lange es gedauert hat und wie viele gleichzeitige Nutzer er überstanden hat. Für eine RAG-Anwendung sind diese Zahlen Voraussetzungen, keine Schlussfolgerungen. Eine schnelle falsche Antwort bleibt eine falsche Antwort, und falsche Antworten im großen Maßstab sind teurer als langsame.

RAG fügt jeder Anfrage zwei unterschiedliche Phasen hinzu. Zuerst wandelt das System eine Benutzerfrage in ein Embedding um, fragt einen Vektorspeicher ab und ruft eine Menge von Kontext-Chunks ab. Zweitens packt es diese Chunks in einen Prompt, sendet alles an ein Sprachmodell und streamt eine Vervollständigung zurück. Traditionelle Tests fassen diese oft in einer einzigen Metrik für die „Antwortzeit“ zusammen. Sie behandeln die Retrieval-Engine und den Generator als eine einzige Blackbox.

Sie müssen diese Box aufbrechen. Wenn Ihre Vektordatenbank unter Last langsamer wird, steigt die Retrieval-Latenz. Das LLM antwortet vielleicht immer noch schnell, aber es antwortet auf Basis von minderwertigem Kontext, der in Eile abgerufen wurde. Alternativ bleibt die Vektorsuche flink, während sich die LLM-Warteschlange staut, was die Time-to-First-Token erhöht, bis die Nutzer auf einen blinkenden Cursor starren. Ein einziger End-to-End-Timer verbirgt beide Fehler.

Testen Sie das Retrieval, nicht nur die Datenbank

Die meisten Teams führen einen schnellen Benchmark für die Vektorsuche durch und betrachten die Retrieval-Schicht als getestet. Dieser Benchmark misst in der Regel, wie schnell die Datenbank die nächsten Nachbarn (Nearest Neighbors) für eine handverlesene Abfrage zurückgibt. Er misst selten, ob diese Nachbarn tatsächlich die Antwort enthalten.

Die Retrieval-Qualität verändert sich unter Last auf subtile Weise. Unter gleichzeitiger Belastung können sich Approximate-Nearest-Neighbor-Indizes anders verhalten als im isolierten Zustand. Chunking-Strategien, die in einem Notebook perfekt aussah, beginnen, Kontext über Grenzen hinweg zu vermischen, wenn zehntausend Dokumente um denselben Embedding-Raum konkurrieren. Eine Abfrage, die in einer ruhigen Umgebung den idealen Absatz liefert, könnte eine irreführende Marketing-Folie ausgeben, wenn der Index gerade neu aufgebaut wird oder wenn Metadaten-Filter unter Anfragedruck wegfallen.

Um dies richtig zu testen, benötigen Sie einen Ground-Truth-Datensatz. Kuratieren Sie Fragen, bei denen Sie bereits wissen, welche Quelldokumente erscheinen sollten. Führen Sie diese Fragen mit unterschiedlichen Nebenläufigkeitsstufen aus und prüfen Sie, ob die erwarteten Chunks in den Top-k-Ergebnissen landen. Verfolgen Sie die Trefferquote (Hit Rate), nicht nur die Abfragedauer. Wenn Ihre Top-fünf-Chunks die entscheidende Quelle komplett verfehlen, ist Ihre Retrieval-Pipeline gescheitert, noch bevor das LLM überhaupt aufgewacht ist.

Sie sollten auch die Randbereiche unter Belastung testen. Senden Sie Abfragen, auf die es im Korpus keine Antwort gibt. Senden Sie mehrdeutige Fragen, die mehreren Domänen zugeordnet werden könnten. Senden Sie lange Fragen, die das Token-Limit Ihres Embedding-Modells überschreiten und stillschweigend gekürzt werden. Beobachten Sie, was die Retrieval-Schicht zurückgibt. In jedem Fall ist der Fehlermodus wichtiger als die verstrichenen Millisekunden.

Wenn das Modell lautlos versagt

Sobald die Chunks das LLM erreichen, lügt das Standard-Lasttesting weiter