KI-Evaluation verständlich erklärt: Metriken und Testverfahren

Die KI-Evaluation (Qualitätsbewertung) befasst sich mit der systematischen Messung und Überprüfung der Leistungsfähigkeit von KI-Modellen und Applikationen. Da generative Sprachmodelle (LLMs) nicht-deterministisch arbeiten – also auf dieselbe Frage leicht unterschiedliche Antworten geben können –, stossen klassische Software-Testmethoden hier an ihre Grenzen. Eine strukturierte Evaluation ist unverzichtbar, um die Verlässlichkeit und Sicherheit von KI-Systemen im Unternehmenseinsatz zu garantieren.

Die Herausforderung: Das Messen des Unvorhersehbaren

Bei herkömmlicher Software führt eine Eingabe A immer zur Ausgabe B. Bei einem LLM kann die Eingabe A zu zehn verschiedenen Formulierungen führen, die alle fachlich korrekt sind. Um die Qualität zu messen, müssen Entwickler daher auf neue Bewertungsverfahren ausweichen.

Die drei Säulen der KI-Evaluation sind:

Methode	Geschwindigkeit	Kosten	Semantisches Verständnis	Eignung für CI/CD
Human Evaluation	sehr langsam	sehr hoch	sehr hoch	ungeeignet
BLEU / ROUGE	sehr schnell	sehr gering	keines	gut, aber oberflächlich
LLM-as-a-Judge	mittel	mittel	hoch	sehr gut

In der Praxis kombinieren reife Teams alle drei: BLEU/ROUGE für schnelle Plausibilitätschecks, LLM-as-a-Judge für die laufende automatisierte Bewertung und stichprobenartige Human Evaluation als Kontrollinstanz.

1. Human Evaluation (Menschliche Bewertung)

Fachexperten lesen die Antworten der KI und bewerten diese nach Relevanz, Genauigkeit und Tonalität.

• Vorteil: Höchste Qualität und Erkennung subtiler Fehler.
• Nachteil: Extrem teuer, langsam und nicht für kontinuierliche Tests im CI/CD-Prozess geeignet.

2. Automatische linguistische Metriken

Verfahren wie BLEU (Bilingual Evaluation Understudy) oder ROUGE (Recall-Oriented Understudy for Gisting Evaluation) vergleichen die Wortübereinstimmungen zwischen der KI-Antwort und einer perfekten Referenzantwort (Ground Truth).

• Vorteil: Blitzschnell und billig.
• Nachteil: Sie messen nur die Ähnlichkeit der Worte, nicht die semantische Bedeutung. Sagt die KI „Der Zug kommt pünktlich“ statt „Die Bahn verspätet sich nicht“, bewerten diese Metriken die Antwort fälschlicherweise als schlecht.

3. LLM-as-a-Judge (KI als Schiedsrichter)

Hierbei wird ein übergeordnetes Sprachmodell mit einem speziellen Bewertungs-Prompt gefüttert. Es erhält die Benutzerfrage, den Dokumentenkontext und die zu bewertende KI-Antwort. Die Schiedsrichter-KI analysiert die Logik und vergibt Scores (z. B. von 1 bis 5) für verschiedene Kriterien. Dies hat sich als praktikabler Mittelweg für automatisierte Tests etabliert.

---

Spezifische Metriken für RAG-Systeme (RAGAS-Framework)

Speziell bei Retrieval-Augmented Generation (RAG) wird die Evaluation in zwei Teile zerlegt: das Retrieval (Suchen der Dokumente) und die Generation (Formulieren der Antwort). Beliebte Frameworks wie RAGAS nutzen hierzu drei Kern-Metriken:

1. Faithfulness (Treue zum Kontext): Misst, ob die generierte Antwort ausschliesslich auf den gefundenen Dokumenten basiert oder ob das Modell eigene Behauptungen hinzuerfindet (Halluzinationen).
2. Answer Relevance (Antwort-Relevanz): Prüft, ob das Modell tatsächlich die Frage des Nutzers beantwortet hat oder ob es am Thema vorbeiredet.
3. Context Recall (Kontext-Abdeckung): Misst, ob das Retrieval-System alle relevanten Dokumente gefunden hat, die zur Beantwortung der Frage zwingend nötig gewesen wären.

Diese Aufteilung ist der entscheidende Vorteil gegenüber der Bewertung eines reinen Large Language Models: Eine schlechte Antwort lässt sich eindeutig dem Retrieval (schlechtes Chunking oder ungenaue Vektorsuche) oder der Generation zuordnen. Wie diese Metriken im Detail mit dem RAGAS-Framework erhoben werden, vertieft der Beitrag zur RAG-Evaluation.

---

Praxisbeispiel: Eine Modelländerung sauber bewerten

Ein Team möchte ein günstigeres Sprachmodell einführen und muss belegen, dass die Qualität nicht leidet:

• Ausgangslage: Golden Dataset mit 80 Fragen, bisheriges Modell erreicht eine durchschnittliche Faithfulness von 0.92.
• Test: Nach dem Modellwechsel läuft dasselbe Dataset automatisiert durch eine LLM-as-a-Judge-Pipeline.
• Ergebnis: Faithfulness fällt auf 0.78 – das neue Modell halluziniert häufiger. Die Änderung wird verworfen, bevor sie Nutzer erreicht.

Ohne dieses messbare Vorgehen wäre der Qualitätsverlust erst über Beschwerden im Live-Betrieb aufgefallen. Genau hier wirkt die Evaluation als Frühwarnsystem gegen Halluzinationen.

---

Best Practice: Aufbau eines „Golden Datasets“

Bevor Sie Änderungen an Ihren System-Prompts, Embedding-Modellen oder Chunk-Grössen vornehmen, sollten Sie ein Golden Dataset erstellen. Dies ist eine Sammlung von 50 bis 100 repräsentativen Testfragen, inklusive der dazugehörigen korrekten Referenzantworten.

Nach jeder Änderung lassen Sie die Testfragen automatisch generieren und bewerten (z. B. über ein automatisiertes LLM-as-a-Judge Skript). Nur so lässt sich wissenschaftlich belegen, ob eine Systemänderung das System verbessert oder an anderer Stelle zu Verschlechterungen führt.

[!TIP] Eine kontinuierliche Evaluation schützt vor bösen Überraschungen im Live-Betrieb. Besuchen Sie allerate.dev, um mehr über unser Vorgehen beim Testen und Absichern von Enterprise-KI-Systemen zu erfahren.