Benchmark
Standardisierte Tests und Datensätze, mit denen KI-Modelle objektiv verglichen werden – von MMLU für Allgemeinwissen bis HumanEval für Code-Fähigkeiten.
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.
„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:
| Art | Methode | Skalierbarkeit | Genauigkeit |
|---|---|---|---|
| Menschlich | Annotator bewertet | Niedrig | Hoch |
| Regelbasiert | Exakter Match, Regex | Hoch | Begrenzt |
| Modellbasiert | LLM-as-Judge | Hoch | Mittel-Hoch |
| Hybrid | LLM + menschliche Stichproben | Mittel | Hoch |
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, ...}
# 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"
# 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
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.
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.
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.
Framework speziell für RAG-Evaluation (Faithfulness, Answer Relevancy, Context Recall)
LangChain-Plattform für Tracing, Testing und Evaluation von LLM-Apps
Open-Source-Tool für Prompt-Testing und LLM-Evaluation
Eval-Plattform mit Dataset-Management und LLM-as-Judge
OpenAIs Framework für Modell-Evaluation