Sofortantwort
LLM Evaluation einfach erklärt
Systematische Bewertung von LLM-Qualität, Zuverlässigkeit und Sicherheit.
- Kurz gesagt
- Evals messen Qualität, Korrektheit, Sicherheit und Konsistenz von LLM-Ausgaben
- Typischer Einsatz
- RAG-Pipeline-Optimierung, Modell-Vergleich, Regression-Testing
- Wichtig zu wissen
- LLM-as-Judge anhand menschlich bewerteter Fälle kalibrieren
LLM Evaluation im Überblick
Eine Evaluation macht konkrete Anforderungen prüfbar. Ein Assistent für interne Richtlinien soll etwa die richtige Quelle nennen, bei fehlender Information offen bleiben und keine geschützten Dokumente ausgeben. Lege diese Kriterien vor dem Vergleich fest. Verwende dieselben Testfälle für Ausgangsversion und Kandidat und protokolliere Modell, Prompt, Indexstand und Bewertungsregeln.
Was soll der Test messen?
| Kriterium | Geeignete Prüfung |
|---|---|
| Ausgabeformat und zulässige Quellen-IDs | Schema und Regeln automatisch prüfen |
| RAG-Retrieval | Prüfen, ob relevante Passagen im abgerufenen Kontext landen und weit oben stehen |
| Quellenbindung | Jede überprüfbare Aussage gegen die angegebene Passage abgleichen |
| Antwortrelevanz | Bewerten, ob die Antwort die gestellte Frage abdeckt |
| Kritische Fehler | Separat ausweisen, etwa unerlaubte Offenlegung oder erfundene Regeln |
Ragas bietet unter anderem Context Precision, Context Recall, Faithfulness und Response Relevancy. Faithfulness bewertet, ob der gegebene Kontext Aussagen stützt. Ist die Quelle selbst falsch oder veraltet, braucht es zusätzlich eine Prüfung gegen eine verlässliche Referenz.
Beispiel mit gespeicherten Antworten
Dieses Beispiel prüft gespeicherte Ausgaben einer RAG-Anwendung mit festem Antwortformat. Es läuft mit Python ohne Zusatzpakete. Die IDs in allowed_sources stehen für Passagen, die für den jeweiligen Testfall abgerufen und freigegeben wurden.
def passes_source_check(output, allowed_sources, *, should_abstain):
status = output.get("status")
sources = output.get("source_ids")
if not isinstance(sources, list):
return False
if should_abstain:
return status == "insufficient_evidence" and not sources
return (
status == "answered"
and bool(sources)
and all(isinstance(source, str) and source in allowed_sources for source in sources)
)
assert passes_source_check(
{"status": "answered", "source_ids": ["richtlinie-7"]},
{"richtlinie-7"},
should_abstain=False,
)
assert passes_source_check(
{"status": "insufficient_evidence", "source_ids": []},
{"richtlinie-7"},
should_abstain=True,
)
assert not passes_source_check(
{"status": "answered", "source_ids": ["erfundene-quelle"]},
{"richtlinie-7"},
should_abstain=False,
)Der Test prüft Status und Quellen-IDs. Für die Quellenbindung musst du zusätzlich den Antworttext mit dem Inhalt der zitierten Passage vergleichen.
LLM-as-Judge kalibrieren
Gib dem Bewertungsmodell eine Rubrik mit Beispielen für bestanden, durchgefallen und unklar. Vergleiche seine Urteile zunächst mit menschlich bewerteten Fällen. Tausche bei Paarvergleichen die Reihenfolge der Antworten, um Positionseffekte zu erkennen. Dokumentiere Richtermodell und Rubrik und prüfe kritische oder strittige Fälle fachlich. Weise seltene schwere Fehler und Ergebnisse pro Fehlergruppe separat aus.
Schritt für Schritt
Wie LLM-Evaluation zu verlässlichen Entscheidungen führt
Aufgabe und Qualitätsmaßstab definieren
Lege fest, welche konkrete Aufgabe das Modell unterstützt und was eine hilfreiche, sichere und angemessene Antwort ausmacht. Ein allgemeiner Benchmark kann diese Anforderungen nur teilweise abbilden.
Repräsentative Fälle zusammenstellen
Sammle typische Anfragen, schwierige Randfälle und bekannte Risiken aus dem realen Nutzungskontext. Herkunft, Ziel und erwartete Bewertung jedes Falls müssen nachvollziehbar dokumentiert sein.
Automatische und menschliche Prüfung verbinden
Nutze wiederholbare Kriterien für Struktur, Fakten oder Regeln und ergänze sie durch qualifizierte Bewertung, wenn Kontext, Sicherheit oder Nuance wichtig sind. Prüfer brauchen klare Leitfäden und Möglichkeiten für Unsicherheit.
Änderungen gegen eine Basis vergleichen
Bewerte neue Modelle, Prompts und Retrieval-Logik gegen eine bekannte Ausgangsversion. Prüfe Verbesserungen nach Fehlergruppe und lasse wichtige Qualitäts- oder Sicherheitswerte nicht hinter einer Gesamtzahl verschwinden.
Konkretes Beispiel
Ein Antwortassistent wird vor der Freigabe geprüft
Ein Team entwickelt einen Assistenten für interne Richtlinien. Er soll schnell helfen, darf aber keine Regeln erfinden oder vertrauliche Informationen unkontrolliert preisgeben.
Unzureichender Test
Das Team probiert einzelne Fragen spontan aus und bewertet die Antworten nach Gefühl. Schwierige Fälle, Quellenbindung und eine Vergleichsbasis für spätere Änderungen fehlen noch.
Evaluation Suite
Eine versionierte Fallsammlung prüft Quellenbezug, hilfreiche Zurückhaltung und kritische Fehlerfälle. Automatische Checks und menschliche Bewertungen liefern gemeinsam die Grundlage für Freigabe und weitere Verbesserung.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Macht Qualitätsansprüche für konkrete Aufgaben nachvollziehbar und wiederholbar prüfbar.
- Deckt schwierige Fälle und Sicherheitsgrenzen auf, die bei spontanen Tests oft fehlen.
- Ermöglicht Vergleiche zwischen Modell-, Prompt- und Systemversionen.
Das solltest du beachten
- Eine Testsuite kann reale Nutzung nie vollständig abbilden und muss regelmäßig gepflegt werden.
- Automatische Bewertungen können dieselben blinden Flecken wie das bewertete System enthalten.
- Gute Gesamtwerte können schwere Fehler in seltenen, aber wichtigen Fällen verdecken.
Vertiefung · für FortgeschritteneVon der Aufgabe zur prüfbaren Modellqualität
Qualität im Kontext
- Benchmark
- Standardisierter Test für den Vergleich von Modellen oder KI-Systemen.
- Guardrails
- Regeln zur Sicherstellung des korrekten Verhaltens von KI.
- RAG
- Kombination von LLMs mit externen Wissensdatenbanken für Genauigkeit.
- Prompt Engineering
- Die Technik, Anweisungen für KI-Modelle optimal zu gestalten.
- Model Risk Management
- Systematisches Management von Risiken durch ML-Modelle in Produktion.
