KI-Evaluierung: so messen Sie, ob eine KI-Automatisierung zuverlässig ist

Wer nicht misst, rät. Und Raten skaliert mit dem Volumen

Klassische Software verhält sich bei gleicher Eingabe gleich. Ein Sprachmodell nicht. Es antwortet nach Wahrscheinlichkeit, reagiert auf kleinste Änderungen der Anweisung, und ein Modellwechsel des Anbieters verschiebt Ergebnisse, ohne dass sich an Ihrem Code etwas ändert. Deshalb reicht die Demo nicht. Was drei Fälle bestehen, kann an dreihundert scheitern.

Wie groß der Unterschied zwischen Eindruck und Messung ist, zeigt der CRAG-Benchmark von Meta (Yang et al., 2024). Große Sprachmodelle ohne Wissensanbindung beantworteten dort höchstens rund 34 Prozent der Faktenfragen korrekt. Einfaches RAG kam auf rund 44 Prozent, gut gebaute Industrielösungen auf rund 63 Prozent. Diese Zahlen stammen aus einem öffentlichen Benchmark, nicht aus Ihrem Anwendungsfall. Aber sie zeigen: Die Bauqualität macht den Unterschied, und niemand sieht diesen Unterschied ohne Messung.

In einem Projekt mit einem Berufsgeheimnisträger deckte erst ein gezielter Negativtest auf, dass das System eine Zahl erfand, die in keinem Dokument stand. Alle positiven Fälle waren grün. Ohne den Negativtest wäre die Erfindung als belegte Auskunft durchgegangen. Genau dafür gibt es Evals: nicht um zu zeigen, dass etwas funktioniert, sondern um zu finden, wo es nicht funktioniert.

Das Testset: echte Fälle, erwartete Antworten, bewusste Fallen

Ein Testset ist eine Liste aus Eingaben und dem, was als richtige Ausgabe gilt. Es entsteht aus dem Tagesgeschäft: echte Rechnungen mit bekannten Werten, echte Kundenfragen mit der Antwort, die ein erfahrener Mitarbeiter gegeben hätte, echte Verträge mit den Klauseln, die gefunden werden müssen. Anonymisiert, wo nötig, aber real. Erfundene Testfälle prüfen erfundene Probleme.

Drei Sorten von Fällen gehören hinein. Positive Fälle, die das System lösen muss. Verweigerungsfälle, in denen die richtige Antwort „dazu liegt nichts vor" lautet; sie prüfen, ob das System erfindet. Grenzfälle: unleserliche Scans, widersprüchliche Dokumente, Fragen mit eingeschleusten Anweisungen. Wer nur positive Fälle testet, misst, wie gut das System bei Rückenwind ist.

Zur Größe: Ein Start mit 15 bis 30 Fällen ist besser als kein Start. Aber 15 von 15 richtig sagt wenig über die Quote im Betrieb; erst dreistellige Testmengen tragen Prozentangaben. Das Testset wächst deshalb mit: Jeder Fehler aus dem Betrieb wird ein neuer Testfall. In dem genannten Projekt begann das Set mit 15 Fällen, davon 4 Verweigerungsfälle, und lag nach wenigen Wochen bei über 30. Wie der Kontext für solche Fälle aufgebaut wird, beschreibt Context Engineering für KI-Prozesse.

Welche Kennzahlen zählen und was sie wirklich messen

Eine einzige Zahl reicht nicht. Ein System kann sehr genau und dabei unbrauchbar langsam sein, oder schnell und günstig, aber jeden fünften Fall halluzinieren. Die Tabelle zeigt die Kennzahlen, die sich in Automatisierungsprojekten bewährt haben, und was jede von ihnen nicht sieht.

Zwei Kennzahlen werden regelmäßig unterschätzt. Die Verweigerungsquote in beide Richtungen: Wie oft antwortet das System, obwohl es nicht sollte, und wie oft verweigert es, obwohl die Antwort vorlag? Und die Antwortzeit als Verteilung: In unserem Testaufbau mit einem lokalen Modell mittlerer Größe kamen erste Worte nach zwei bis drei Sekunden, die volle Antwort nach rund zwanzig. Für eine Sachbearbeitung im Hintergrund ist das egal, für einen Chat am Empfang nicht.

Regressionsläufe: bei jeder Änderung das ganze Set neu

Regression heißt: Etwas, das funktionierte, funktioniert nach einer Änderung nicht mehr. Bei KI-Systemen ist das der Normalfall, nicht die Ausnahme. Vier Auslöser verlangen einen kompletten Neulauf des Testsets: ein neues Modell oder eine neue Modellversion, eine geänderte Anweisung (Prompt), neue oder geänderte Dokumente in der Wissensbasis, und geänderte Schwellen in den Guardrails.

Das Muster ist dasselbe wie bei automatisierten Softwaretests: Der Lauf ist ein Befehl, das Ergebnis ein Bericht mit Vergleich zum letzten Stand. Ein Rückgang unter eine definierte Grenze blockiert die Freigabe. Ohne diese Automatik wird der Lauf beim dritten Mal übersprungen. In dem genannten Projekt zeigte ein solcher Lauf, dass eine Härtung gegen Halluzination im Gegenzug richtige Antworten verweigerte. Ohne Regressionslauf hätte man die Härtung als Verbesserung gefeiert.

Beim Wechsel zwischen einem Cloud-Modell und einem lokal betriebenen Modell ist der Regressionslauf die einzige belastbare Grundlage. Ein kleineres Modell kann in Ihrem Fall gleich gut sein oder deutlich schlechter; die Benchmarks der Anbieter sagen es nicht. Mehr dazu in Kleine Sprachmodelle und Open-Weights-Modelle im Vergleich.

Ein Modell als Prüfer: nützlich, aber mit klaren Grenzen

Freitext lässt sich nicht per Feldvergleich prüfen. Deshalb setzt die Praxis ein zweites Modell als Bewerter ein (LLM-as-a-Judge): Es bekommt Frage, Kontext, Antwort und ein Bewertungsraster und urteilt. Zheng et al. (2023) haben gezeigt, dass starke Modelle bei solchen Bewertungen in über 80 Prozent der Fälle mit menschlichen Bewertern übereinstimmen, was der Übereinstimmung zwischen Menschen entspricht.

Dieselbe Arbeit dokumentiert die Grenzen. Bewertermodelle bevorzugen die erste von zwei Antworten (Positionsverzerrung), längere Antworten (Ausführlichkeitsverzerrung) und die Ausgaben ihrer eigenen Modellfamilie. Bei Rechen- und Logikaufgaben irren sie häufiger. Und ein Prüfmodell ist selbst ein Modell: In dem genannten Projekt stufte ein kleiner Prüfer einen unpassenden Treffer als korrekt ein. Behoben hat das erst ein stärkeres Modell mit einem zweiten Prüfdurchgang.

Daraus folgen drei Regeln. Erstens: Der Prüfer braucht selbst ein Testset, an dem seine Urteile gegen menschliche Urteile geeicht werden. Zweitens: Wo eine exakte Prüfung möglich ist, etwa bei Beträgen, Daten und Pflichtfeldern, ist sie dem Modell vorzuziehen. Drittens: Bei Geld, Recht und Personal bleibt die letzte Bewertung beim Menschen, das Modell sortiert vor. Warum das so ist, steht in KI-Halluzinationen vermeiden.

Abnahmekriterien vor dem Go-live

Ein Go-live ohne Abnahmekriterien ist ein Pilot ohne Ende. Bewährt hat sich, vor dem Bau festzulegen, was „gut genug" heißt, und zwar je Kennzahl. Die Werte hängen vom Fall ab; eine Rechnungsextraktion braucht andere Schwellen als ein interner Wissensassistent. Der Rahmen ist aber übertragbar.

Kurz gesagt

KI-Evaluierung ist der Unterschied zwischen einer Demo und einem System, dem Sie Ihre Prozesse anvertrauen. Das Testset kommt aus echten Fällen und enthält bewusst Verweigerungs- und Grenzfälle. Die Kennzahlen decken Genauigkeit, Vollständigkeit, Halluzination, Zeit und Kosten ab. Jede Änderung löst einen Neulauf aus, und ein Modell als Prüfer hilft, ersetzt aber weder exakte Prüfungen noch den Menschen bei kritischen Entscheidungen. Wer diese Schleife vor dem Go-live aufbaut, muss später nicht raten. Grundbegriffe erklärt das KI-Glossar 2026, den Weg vom Pilot zum Betrieb der Leitfaden Prozessautomation.

• Yang, X. et al. (Meta), CRAG — Comprehensive RAG Benchmark, arXiv:2406.04744, 2024, https://arxiv.org/abs/2406.04744
• Zheng, L. et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, arXiv:2306.05685, 2023, https://arxiv.org/abs/2306.05685
• Es, S. et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, arXiv:2309.15217, 2023, https://arxiv.org/abs/2309.15217
• Yan, S.-Q. et al., Corrective Retrieval Augmented Generation, arXiv:2401.15884, 2024, https://arxiv.org/abs/2401.15884
• Liu, N. F. et al., Lost in the Middle: How Language Models Use Long Contexts, arXiv:2307.03172, 2023, https://arxiv.org/abs/2307.03172
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), Funktion „Measure", 2023, https://www.nist.gov/itl/ai-risk-management-framework
• OWASP Foundation, OWASP Top 10 for Large Language Model Applications, Version 2025, https://owasp.org/www-project-top-10-for-large-language-model-applications/