LLM Evaluation

Wie du Modellantworten gegen reale Aufgaben, wichtige Fehlerfälle und klare Qualitätsmaßstäbe prüfst

Methoden und Metriken zur systematischen Bewertung der Qualität, Zuverlässigkeit und Sicherheit von Large Language Models und KI-Anwendungen – von automatisierten Benchmarks bis zu menschlichem Feedback.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Evals messen Qualität, Korrektheit, Sicherheit und Konsistenz von LLM-Ausgaben
  2. Automatisierte Evals skalieren, menschliche Evals sind Goldstandard
  3. LLM-as-Judge: Ein starkes Modell bewertet die Ausgaben eines anderen

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: Ein starkes Modell bewertet die Ausgaben eines anderen

LLM Evaluation im Überblick

„Das Modell antwortet gut” ist keine ausreichende Qualitätssicherung. LLM Evaluation (kurz: Evals) ist die systematische Antwort auf die Frage: Wie gut ist gut genug, und wie messen wir das?

Evals definieren konkrete Testfälle mit erwarteten Ausgaben oder Bewertungskriterien. Automatisierte Pipelines führen diese Tests nach jeder Änderung aus – genau wie Unit Tests in der Softwareentwicklung.

Evaluationsarten:

ArtMethodeSkalierbarkeitGenauigkeit
MenschlichAnnotator bewertetNiedrigHoch
RegelbasiertExakter Match, RegexHochBegrenzt
ModellbasiertLLM-as-JudgeHochMittel-Hoch
HybridLLM + menschliche StichprobenMittelHoch

Technisch betrachtet

RAGAS – RAG-Evaluation

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

# Testdaten
data = {
    "question": ["Was ist RAG?", "Wie funktioniert Chunking?"],
    "answer": ["RAG steht für...", "Chunking teilt..."],
    "contexts": [["Kontext 1..."], ["Kontext 2..."]],
    "ground_truth": ["RAG ist...", "Chunking ist..."],
}

dataset = Dataset.from_dict(data)
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)
# {'faithfulness': 0.92, 'answer_relevancy': 0.87, ...}

Promptfoo – Prompt-Testing

# promptfooconfig.yaml
prompts:
  - "Beantworte folgende Frage präzise: {{question}}"
  - "Du bist ein Experte. Frage: {{question}}"

providers:
  - openai:gpt-4o-mini
  - anthropic:claude-3-haiku-20240307

tests:
  - vars:
      question: "Was ist die Hauptstadt von Frankreich?"
    assert:
      - type: contains
        value: "Paris"
      - type: llm-rubric
        value: "Die Antwort ist korrekt und präzise"

  - vars:
      question: "Erkläre Quantencomputing"
    assert:
      - type: llm-rubric
        value: "Die Erklärung ist verständlich und korrekt"
      - type: not-contains
        value: "Ich weiß es nicht"

Eval-Metriken im Überblick

# Wichtige Metriken für verschiedene Use Cases

# 1. Faktische Korrektheit
def check_factual_accuracy(answer: str, ground_truth: str) -> float:
    # LLM bewertet ob Antwort mit Ground Truth übereinstimmt
    ...

# 2. Halluzinations-Erkennung (Faithfulness)
def check_faithfulness(answer: str, context: str) -> float:
    # Ist jede Aussage in der Antwort durch den Kontext belegt?
    ...

# 3. Antwort-Vollständigkeit
def check_completeness(answer: str, question: str) -> float:
    # Beantwortet die Antwort alle Aspekte der Frage?
    ...

Schritt für Schritt

Wie LLM-Evaluation zu verlässlichen Entscheidungen führt

  1. 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.

  2. 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.

  3. 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.

  4. Ä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 Fortgeschrittene

Von der Aufgabe zur prüfbaren Modellqualität

Wissenskarte

Qualität im Kontext

Benchmark
Tests zur objektiven Bewertung von KI-Modellen.
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.
LLM Evaluation verbindet reale Aufgaben, repräsentative Fälle und mehrere Qualitätskriterien, damit Änderungen am System nicht nur schneller, sondern auch nachvollziehbar besser werden. LLM Evaluation gliedert sich in: Benchmark, Guardrails, RAG, Prompt Engineering, Model Risk Management.

01Einsatzbereiche

Wann ist LLM Evaluation sinnvoll?

Geeignet für

  • RAG-Pipeline-OptimierungMessen ob abgerufene Dokumente relevant sind und ob die Antwort korrekt aus dem Kontext abgeleitet wurde
  • Modell-VergleichVerschiedene LLMs oder Fine-Tuning-Varianten auf denselben Testfällen vergleichen
  • Regression-TestingNach Prompt-Änderungen oder Modell-Updates sicherstellen, dass die Qualität nicht gesunken ist

↑ Inhalt

02Werkzeuge

Womit LLM Evaluation umgesetzt wird

↑ Inhalt

Merksatz

LLM Evaluation ist wie eine Fahrprüfung für KI-Modelle

Nicht nur ob das Auto fährt (funktioniert), sondern ob es sicher fährt, Verkehrsregeln kennt, in Stresssituationen richtig reagiert und keine Fußgänger überfährt. Verschiedene Prüfer (Metriken) testen verschiedene Aspekte.

  1. Evals messen Qualität, Korrektheit, Sicherheit und Konsistenz von LLM-Ausgaben
  2. Automatisierte Evals skalieren, menschliche Evals sind Goldstandard
  3. LLM-as-Judge: Ein starkes Modell bewertet die Ausgaben eines anderen

04Anwenden

LLM Evaluation praktisch anwenden

↑ Inhalt

05Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

06FAQ

Häufige Fragen zu LLM Evaluation

Was ist LLM-as-Judge?

Ein starkes LLM (z. B. GPT-5) bewertet die Ausgaben eines anderen Modells anhand definierter Kriterien. Günstiger und skalierbarer als menschliche Bewertung, aber nicht perfekt – das Richter-Modell kann selbst Fehler machen oder eigene Biases haben. Gut als erste Filterung, nicht als alleiniger Goldstandard.

Was sind die wichtigsten RAG-Metriken?

Faithfulness: Ist die Antwort durch den Kontext belegt (keine Halluzinationen)? Answer Relevancy: Beantwortet die Antwort die Frage? Context Precision: Sind die abgerufenen Dokumente relevant? Context Recall: Wurden alle relevanten Dokumente abgerufen? Diese vier Metriken decken die wichtigsten Fehlerquellen in RAG-Systemen ab.

Wie viele Test-Cases brauche ich?

Es gibt keine feste Regel, aber: Für erste Orientierung reichen 20-50 repräsentative Fälle. Für produktionsreife Systeme sollten es 200-500+ sein, die alle wichtigen Kategorien abdecken. Wichtiger als Quantität ist Repräsentativität – die Test-Cases müssen echte Nutzungsszenarien widerspiegeln.

↑ Inhalt

07Weiterlernen

Was möchtest du als Nächstes verstehen?

↑ Inhalt