<EbeneX/>
LLM DevOps · Updated 19. Februar 2026

LLM Evaluation

Definition

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.

Fortgeschritten 2 Min. Lesezeit EN: LLM Evaluation (Evals)

Einfach erklärt

„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

Technischer Deep Dive

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

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.

Evals messen Qualität, Korrektheit, Sicherheit und Konsistenz von LLM-Ausgaben

Automatisierte Evals skalieren, menschliche Evals sind Goldstandard

LLM-as-Judge: Ein starkes Modell bewertet die Ausgaben eines anderen

RAG-Pipeline-Optimierung

Messen ob abgerufene Dokumente relevant sind und ob die Antwort korrekt aus dem Kontext abgeleitet wurde

Modell-Vergleich

Verschiedene LLMs oder Fine-Tuning-Varianten auf denselben Testfällen vergleichen

Regression-Testing

Nach Prompt-Änderungen oder Modell-Updates sicherstellen, dass die Qualität nicht gesunken ist

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.

Dein persönliches Share-Bild für Instagram – 1080×1080px, bereit zum Posten.