RAG-Systeme mit echten Evals prüfen: Qualität vor Demo-Effekt

Eine RAG-Demo wirkt schnell überzeugend: Dokument hochladen, Frage stellen, flüssige Antwort erhalten. Für einen produktiven Fachprozess reicht dieser Eindruck nicht. Das System muss die richtigen Quellen finden, relevante Passagen verwenden, Unsicherheit zeigen und bei fehlender Evidenz kontrolliert abbrechen. Genau dafür braucht es Evals.

Die Aufgabe vor der Metrik definieren

Retrieval-Augmented Generation kann sehr unterschiedliche Produkte beschreiben. Eine interne Suche, juristische Recherche und ein Support-Assistent haben andere Fehlerkosten. Bevor eine Metrik ausgewählt wird, braucht jeder Anwendungsfall eine klare Aufgabe:

• Welche Quellen sind zulässig und aktuell?
• Welche Antwortform wird erwartet?
• Muss jede Aussage eine Fundstelle besitzen?
• Welche Fehler sind tolerierbar?
• Wann muss ein Mensch entscheiden?
• Wann soll das System ausdrücklich keine Antwort geben?

Diese Regeln werden zu prüfbaren Fällen. Ein Datensatz sollte häufige Aufgaben, seltene Grenzfälle, widersprüchliche Quellen, fehlende Information und unzulässige Anfragen enthalten.

Ein guter Testdatensatz kommt aus der Praxis

Synthetische Fragen helfen beim Start, spiegeln aber oft die Struktur wider, die das Modell selbst erzeugen würde. Repräsentative Fälle von Fachanwendern sind wertvoller. Sie zeigen Abkürzungen, Mehrdeutigkeiten und implizites Wissen aus dem realen Arbeitsablauf.

Jeder Testfall kann enthalten:

Der Datensatz wird versioniert. Sonst lässt sich später nicht erklären, warum eine neue Chunking-Strategie oder ein anderes Modell angeblich besser ist.

Retrieval und Antwort getrennt messen

Wenn die richtige Passage nicht im Kontext liegt, kann auch ein gutes Modell die Aufgabe nicht zuverlässig lösen. Retrieval-Metriken prüfen deshalb, ob relevante Dokumente und Passagen in den ersten Ergebnissen vorkommen. Precision, Recall, Mean Reciprocal Rank oder nDCG können je nach Suchaufgabe helfen.

Danach folgt die Antwortprüfung. Wichtige Dimensionen sind:

1. fachliche Richtigkeit,
2. Vollständigkeit der notwendigen Aussagen,
3. Bindung an die bereitgestellten Quellen,
4. korrekte Zitate und Fundstellen,
5. passende Ablehnung bei fehlender Evidenz,
6. Einhaltung von Format und Richtlinien.

Ein einziger Gesamtscore versteckt Zielkonflikte. Mehr Treffer können Recall erhöhen und gleichzeitig irrelevanten Kontext, Kosten und Fehlerrisiko steigern.

Modellbewertung braucht Kalibrierung

Ein LLM kann andere Modellantworten schnell bewerten, sollte aber nicht unkontrolliert als Wahrheit gelten. Ein kleiner, von Fachleuten bewerteter Gold-Datensatz zeigt, ob die automatische Bewertung mit menschlichen Urteilen übereinstimmt. Besonders juristische, medizinische oder sicherheitsrelevante Aussagen brauchen fachliche Kontrolle.

Blindbewertungen reduzieren Marken- und Formulierungsbias. Bewertende Personen sollten klare Kriterien und Beispiele erhalten. Uneinigkeit ist nützlich: Sie zeigt oft, dass die Produktanforderung selbst noch nicht eindeutig ist.

Änderungen gegen eine feste Basis prüfen

Chunk-Größe, Embeddings, Filter, Reranker, Prompt und Generierungsmodell beeinflussen das Ergebnis. Wird alles gleichzeitig geändert, ist eine Verbesserung nicht erklärbar. Ein sauberes Experiment verändert möglichst eine relevante Komponente und vergleicht:

• Qualitätsmetriken je Fallgruppe,
• Latenz p50 und p95,
• Token- und Infrastrukturkosten,
• Fehlerrate und Ablehnungsverhalten,
• Auswirkung auf besonders kritische Fälle.

Die beste Durchschnittsqualität ist nicht automatisch die beste Produktentscheidung. Ein lokales Modell kann bei etwas niedrigerem Gesamtscore richtig sein, wenn vertrauliche Daten die externe Verarbeitung ausschließen und kritische Fälle den Grenzwert erreichen.

Evals im Betrieb fortführen

Ein RAG-System verändert sich mit Dokumenten, Berechtigungen und Nutzungsweisen. Neue Dokumentversionen können alte Aussagen widersprechen. Deshalb gehören Zugriffskontrolle, Aktualität und Quellenlöschung in die laufenden Prüfungen.

Fehler aus der Produktion werden nach Bereinigung sensibler Daten zu neuen Regressionstests. Qualitätsmetriken und Kosten werden je Release verglichen. Bei einem deutlichen Rückgang kann der Rollout gestoppt oder auf die vorige Konfiguration zurückgestellt werden.

Ein minimaler Eval-Datensatz

Schon 30 bis 50 sauber kuratierte Fälle sind wertvoller als hunderte automatisch erzeugte Fragen ohne Fachprüfung. Ein maschinenlesbarer Fall kann so aussehen:

{
  "id": "contract-termination-014",
  "question": "Welche Kündigungsfrist gilt für diesen Vertrag?",
  "permitted_sources": ["contract-2025-04", "terms-v7"],
  "required_claims": ["Frist", "Fristbeginn"],
  "forbidden_claims": ["nicht belegte Ausnahme"],
  "must_cite": true,
  "abstain_when_sources_conflict": true,
  "risk": "high"
}

Für jeden Release werden Retrieval-Treffer, Quellenbezug, notwendige Aussagen, verbotene Aussagen, Ablehnung, Latenz und Kosten getrennt gespeichert. Kritische Fälle erhalten ein hartes Gate: Ein besserer Durchschnitt darf keinen neu entstandenen Fehler bei einer rechtlich oder sicherheitsrelevanten Kernfrage verdecken.

Welche Modellroute diese Evals durchlaufen soll, klärt die Entscheidung zwischen lokalen LLMs und Frontier-Modellen. Sobald das System Werkzeuge aufruft, werden zusätzlich die Werkzeugrechte und Freigaben für AI-Agenten relevant.

Quellen und Vertiefung

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• Information Retrieval: Evaluation
• Retrieval-Augmented Generation Paper

Fazit

RAG-Qualität wird nicht durch eine überzeugende Einzelantwort belegt. Ein versionierter Datensatz, getrennte Retrieval- und Antwortmetriken, fachliche Kalibrierung und Regressionstests machen Fortschritt messbar. Erst dann lässt sich entscheiden, ob eine Demo den Sprung in einen produktiven Prozess verdient.