RAG-Systeme (Retrieval-Augmented Generation) revolutionieren die Informationsverarbeitung, doch ihre Besonderheiten stellen traditionelle Testmethoden vor Herausforderungen. Während klassische APIs mit einer vollständigen Antwort antworten, führen RAG-Anwendungen zwei komplexe Schritte aus: die Suche nach relevantem Kontext und die Generierung einer Antwort. Diese Dualität erfordert einen zweigeteilten Testansatz, der sowohl Leistung als auch Qualität berücksichtigt.
Warum herkömmliche Lasttests für RAG-Systeme unzureichend sind
Ein Standard-Lasttest misst lediglich die Antwortzeit einer API. Doch bei RAG-Anwendungen verbergen sich hinter dieser Metrik zwei kritische Phasen: die Suche nach passendem Kontext und die Generierung der Antwort. Die erste Phase beeinflusst die Zeit bis zum ersten Token (TTFT), die zweite die Inter-Token-Latenz.
- TTFT (Time to First Token): Zeigt, wie lange Nutzer auf eine erste Reaktion warten – ein entscheidender Faktor für Nutzerzufriedenheit.
- Inter-Token-Latenz: Misst die Geschwindigkeit, mit der die Anwendung neue Tokens generiert, sobald die erste Antwort erschienen ist.
Ein System mit schneller Generierung, aber langsamer Initialisierung wirkt unzuverlässig, während ein System mit schneller Erstantwort, aber langsamer Generierung für kurze Anfragen akzeptabel, aber für längere Dokumente frustrierend ist. Eine einfache Mittelwertbildung dieser Metriken ist daher irreführend.
Zwei Testdimensionen: Leistung und Antwortqualität
Ein effektiver RAG-Testansatz besteht aus zwei unabhängigen, aber komplementären Testverfahren:
1. Leistungstests
Diese messen die technische Performance unter Last und umfassen:
- TTFT: Zeit bis zur ersten Antwort – der kritischste Nutzerindikator.
- Inter-Token-Latenz: Geschwindigkeit der Token-Generierung während der Antwort.
- Tokens pro Sekunde: Wichtig für lange Antworten wie Dokumentzusammenfassungen.
- p95/p99-Latenz: Zeigt das Verhalten unter Last an, besonders relevant für Spitzenzeiten.
Tools wie k6 eignen sich ideal für diese Tests, da sie Streaming-Protokolle und spezifische LLM-Metriken unterstützen – im Gegensatz zu klassischen Lasttest-Tools wie JMeter, die für atomare Request-Response-Zyklen konzipiert sind.
2. Qualitätstests
Diese bewerten, ob die generierten Antworten tatsächlich auf den abgerufenen Kontext zurückzuführen sind oder ob das Modell Halluzinationen produziert. Hier kommen Tools wie DeepEval ins Spiel, die mit einem LLM als "Richter" arbeiten.
Wichtige Qualitätsmetriken:
- Faithfulness: Ist die Antwort tatsächlich im Kontext verankert oder erfunden?
- Antwortrelevanz: Beantwortet die Antwort die eigentliche Frage oder klingt nur plausibel?
- Kontext-Präzision: Werden die richtigen Kontextchunks abgerufen und korrekt priorisiert?
- Kontext-Recall: Fehlen relevante Informationen im abgerufenen Kontext?
Ein Beispiel: Bei niedriger Faithfulness, aber hohem Kontext-Recall liegt das Problem möglicherweise in der Prompt-Optimierung, nicht im Retrieval-System.
Automatisierte CI/CD-Integration für RAG-Tests
Die Integration beider Testverfahren in eine CI/CD-Pipeline ist entscheidend, um Regressionsfehler frühzeitig zu erkennen. Ein typischer Workflow sieht wie folgt aus:
1. Leistungstests mit k6
import http from 'k6/http';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '1m', target: 50 },
{ duration: '2m', target: 200 },
{ duration: '1m', target: 0 }
],
thresholds: {
'http_req_duration': ['p(95)<2000'],
'time_to_first_token': ['p(95)<1000'],
},
};
export default function () {
const res = http.get(');
check(res, {
'status is 200': (r) => r.status === 200,
});
}2. Qualitätstests mit DeepEval
Ein Beispiel-Testfall für einen Dokumentationsassistenten, der Fragen zu JMeter beantwortet:
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase
from deepeval.models import GeminiModel
# Richtermodel für die Bewertung
judge_model = GeminiModel(
model="gemini-3.5-flash",
api_key=os.getenv("GEMINI_API_KEY"),
)
# Qualitätstests definieren
faithfulness_metric = FaithfulnessMetric(threshold=0.75, model=judge_model)
answer_relevancy_metric = AnswerRelevancyMetric(threshold=0.8, model=judge_model)
# Testfall für eine spezifische Frage
def test_jmeter_non_gui_mode_answer():
frage = "Wie starte ich JMeter im Nicht-GUI-Modus?"
ergebnis = anfrage_an_rag_app(frage)
testfall = LLMTestCase(
input=frage,
actual_output=ergebnis["answer"],
retrieval_context=ergebnis["retrieved_chunks"],
)
for metrik in [faithfulness_metric, answer_relevancy_metric]:
metrik.measure(testfall)
status = "ERFOLG" if metrik.success else "FEHLER"
print(f"[{status}] {metrik.__class__.__name__}: {metrik.score:.3f}")
fehlgeschlagene_metriken = [m for m in [faithfulness_metric, answer_relevancy_metric]
if not m.success]
if fehlgeschlagene_metriken:
namen = ", ".join(m.__class__.__name__ for m in fehlgeschlagene_metriken)
raise AssertionError(f"Qualitätstest fehlgeschlagen: {namen}")3. Integration in GitHub Actions
Die Tests werden automatisch bei jedem Pull Request ausgeführt. Schlägt einer der Tests fehl, wird die Pipeline abgebrochen und das Entwicklungsteam erhält eine Benachrichtigung. Dies verhindert, dass fehlerhafte Änderungen in die Produktion gelangen.
Praktische Empfehlungen für RAG-Tests
- Priorisiere TTFT: Nutzer erwarten eine schnelle erste Antwort, selbst wenn die Generierung länger dauert.
- Kombiniere Metriken: Nutze sowohl Leistungstests als auch Qualitätstests, um ein vollständiges Bild zu erhalten.
- Automatisiere früh: Führe Tests bereits in der Entwicklungsphase ein, um Probleme frühzeitig zu erkennen.
- Analysiere Fehlschläge: Bei fehlgeschlagenen Qualitätstests hilft die Unterscheidung zwischen Retrieval- und Generierungsproblemen bei der gezielten Fehlerbehebung.
Die Zukunft der RAG-Optimierung liegt in der nahtlosen Integration von Leistung und Qualität. Nur so lassen sich Anwendungen entwickeln, die sowohl schnell als auch zuverlässig sind – ein entscheidender Faktor für Akzeptanz und Vertrauen in KI-getriebene Systeme.
KI-Zusammenfassung
Learn how to properly test RAG applications for both speed (TTFT, ITL) and quality (faithfulness, relevancy) in your CI/CD pipeline to prevent regressions before they reach production.