Wie man die Qualität eines KI-Modells wirklich prüft

Die perfekte Antwort kann der eigentliche Fehler sein

Die Antwort wirkt makellos. Sie ist knapp, freundlich und sprachlich sauber. Nur die zugrunde liegende Information ist veraltet.

Ein Beispiel: Ein Serviceassistent erklärt einem Kunden eine Vertragsregel. Das Sprachmodell trifft den gewünschten Ton und verwendet die richtige Fachbezeichnung. Seine Auskunft stammt jedoch aus einer überholten Dokumentversion. Der Ton sitzt. Die Quelle nicht.

Wer hier nur Stil, Vollständigkeit oder Ähnlichkeit mit einer Referenzantwort bewertet, kann dem System gute Noten geben und trotzdem am eigentlichen Risiko vorbeimessen. Entscheidend wäre gewesen: Hat die Suche das maßgebliche Dokument geliefert? Hat das Modell dessen Gültigkeit erkannt? Hätte es bei widersprüchlichen Quellen stoppen müssen?

Damit verschiebt sich der Prüfgegenstand. Eine belastbare LLM-Evaluation bewertet selten nur das Basismodell. Sie prüft die veröffentlichte Konfiguration aus Modell, Systemanweisung, Datenzugriff, Werkzeugen und nachgelagerten Regeln. Genau dieses System erzeugt später die Antwort.

Ein öffentlicher KI-Benchmark kann zeigen, dass ein Modell bestimmte Aufgaben unter festgelegten Testbedingungen beherrscht. Ob es im eigenen Prozess zuverlässig arbeitet, beantwortet er nicht.

Vor dem Test steht der Satz: Das darf nicht passieren

Wer Modellqualität messen will, sollte nicht mit einer langen Sammlung beliebiger Prompts beginnen. Zuerst braucht es eine präzise Beschreibung der Aufgabe und ihres möglichen Scheiterns.

Für den beispielhaften Serviceassistenten könnte die Aufgabe lauten: Beantworte Vertragsfragen ausschließlich auf Basis aktuell freigegebener Dokumente. Nenne Unsicherheit bei widersprüchlichen Quellen. Gib keine verbindliche Auskunft, wenn die Grundlage fehlt. Das ist prüfbarer als die Vorgabe, hilfreich und korrekt zu antworten.

Aus dieser Beschreibung entsteht ein Fehlerkatalog. Manche Fehler betreffen nur das Format. Andere verfälschen eine Aussage, verwenden die falsche Quelle oder lösen eine unzulässige Handlung aus. Diese Fehler sind nicht gleichwertig. Ein fehlendes Pflichtfeld lässt sich häufig automatisch abfangen; eine überzeugend formulierte Falschauskunft möglicherweise nicht.

Erst danach wird der Evaluationsdatensatz gebaut. Er sollte typische Aufgaben enthalten, aber auch die Stellen abbilden, an denen das System ins Rutschen geraten kann: unvollständige Eingaben, nahezu gleichnamige Dokumente, veraltete Fassungen, widersprüchliche Regeln, ungewöhnliche Formulierungen und Anfragen außerhalb des vorgesehenen Bereichs.

Jeder Testfall braucht eine nachvollziehbare Erwartung. Dazu gehören die zulässigen Quellen, akzeptable Antwortvarianten, verbotene Ergebnisse und die Wirkung eines Fehlers. Für offene Aufgaben ist nicht immer eine einzige Musterantwort sinnvoll. Dann muss das Bewertungsraster beschreiben, welches beobachtbare Verhalten als korrekt gilt.

Ein Teil der Fälle sollte bis zum abschließenden Vergleich unangetastet bleiben. Wird jedes bekannte Beispiel wiederholt zum Nachschärfen von Prompts und Regeln verwendet, optimiert das Team irgendwann auf seine eigene Prüfung. Das Testset wird besser bestanden, ohne dass das System außerhalb dieses Sets robuster geworden sein muss.

Ein Gesamtscore kann die gefährlichste Schwäche verdecken

Die Versuchung ist groß, alle Ergebnisse in einer Zahl zusammenzuführen. Das erleichtert Präsentationen, verrechnet aber Fehler, die betrieblich nicht austauschbar sind. Gute Formulierungen dürfen keine falsche Quellenbindung kompensieren.

Eine belastbare Prüfung trennt deshalb mehrere Ebenen:

• Formale Korrektheit: Sind Format, Pflichtfelder, Datentypen und zulässige Werte korrekt?
• Faktische Absicherung: Lassen sich relevante Aussagen auf die bereitgestellten Quellen zurückführen?
• Aufgabenverhalten: Befolgt das System die fachlichen Regeln und erkennt es die Grenzen seines Auftrags?
• Robustheit: Bleibt das Verhalten bei Varianten, fehlendem Kontext und widersprüchlichen Eingaben stabil?
• Betriebliche Eignung: Sind Antwortzeit, Werkzeugnutzung und Ressourcenbedarf für den konkreten Einsatz vertretbar?

Automatische Tests sind stark, wenn Eigenschaften eindeutig überprüfbar sind. Ein JSON-Objekt ist gültig oder ungültig. Ein Pflichtfeld ist vorhanden oder fehlt. Ein Werkzeug wurde mit erlaubten Parametern aufgerufen oder nicht. Bedeutungsfehler erkennen solche Kontrollen jedoch nur, wenn sie zuvor formalisiert wurden.

Für offene Antworten braucht es menschliches Urteil oder ein belastbares Bewertungsmodell. Statt pauschal nach „gut“ oder „schlecht“ zu fragen, sollte das Raster beobachtbare Merkmale verlangen: Die Antwort nennt ihre Grundlage, trennt Tatsachen von Annahmen und verzichtet auf eine Aussage, wenn die Quelle nicht trägt.

Der aussagekräftige Bericht ist deshalb kein einzelner Durchschnittswert. Er zeigt Ergebnisse nach Fallgruppe und Fehlerklasse. Kritische Fehler können zusätzlich als Ausschlusskriterium behandelt werden. Je nach Einsatz kann bereits eine unzulässige Aktion schwerer wiegen als viele stilistisch gelungene Antworten.

Human-in-the-Loop ist ein Messverfahren, kein Notausgang

Menschliche Prüfer werden dort gebraucht, wo Bedeutung, fachlicher Kontext oder mehrere vertretbare Antworten ins Spiel kommen. Ihr Urteil ist jedoch nicht automatisch einheitlich. Ein gutes Verfahren arbeitet mit gemeinsamen Beispielen, klaren Kriterien und einer geregelten Klärung strittiger Fälle.

Besonders aufschlussreich sind blinde Paarvergleiche. Die prüfende Person vergleicht die Ausgaben einer bestehenden und einer neuen Systemversion, ohne deren Herkunft zu kennen. So wird weniger leicht die vermeintlich modernere Variante bevorzugt. Treten wiederholt Unklarheiten auf, ist das nicht nur ein Problem der Prüfer: Oft ist das Bewertungsraster selbst noch zu unscharf.

Ein Human-in-the-Loop-Ansatz bedeutet dabei nicht, jede Ausgabe dauerhaft manuell abzunehmen. Menschen kennzeichnen Grenzfälle, kalibrieren das Bewertungsverfahren und entscheiden dort, wo automatische Regeln keine belastbare Aussage liefern.

Ein zweites Sprachmodell bleibt ein Sprachmodell

Ein LLM kann große Mengen von Antworten vorsortieren, anhand eines Rasters bewerten oder paarweise vergleichen. Als sogenannter LLM-as-a-Judge ist es besonders dann nützlich, wenn die Kriterien konkret sind und seine Urteile regelmäßig mit menschlichen Bewertungen abgeglichen werden.

Neutral ist dieses Messgerät nicht. Das urteilende Modell kann sprachliche Eleganz mit Richtigkeit verwechseln oder auf Reihenfolge und Formulierung der vorgelegten Antworten reagieren. Ein einfacher Gegencheck besteht darin, die Position zweier Vergleichsantworten zu tauschen und strittige Fallgruppen separat zu prüfen.

Vor allem darf der Judge nicht mehr wissen, als ihm vorgelegt wird. Soll er die Quellenbindung bewerten, benötigt er die relevanten Quellen und ein Kriterium dafür, welche davon maßgeblich ist. Ohne diese Grundlage bewertet er Plausibilität, nicht Belegbarkeit.

Ein einzelner Durchlauf ist nur eine Momentaufnahme

Generative Systeme können auf dieselbe Eingabe unterschiedlich reagieren. Relevante Testfälle sollten deshalb wiederholt ausgeführt werden. Nicht die beste Einzelantwort zählt, sondern die Stabilität des gewünschten Verhaltens.

Auch der Vergleich selbst braucht kontrollierte Bedingungen. Dokumentiert werden sollten mindestens Modellversion, Systemanweisung, Datenbestand, Werkzeugdefinitionen und Ausgabeparameter. Andernfalls erscheint eine neue Modellversion womöglich überlegen, obwohl tatsächlich der Suchindex aktualisiert oder der Prompt verändert wurde.

Beim Fehler aus dem Einstieg wäre deshalb zuerst die Prozessspur zu prüfen: Welches Dokument hat die Suche geliefert? Welche Passage gelangte in den Kontext? Hat das Modell eine veraltete Fassung ausgewählt oder war die aktuelle Fassung gar nicht verfügbar? Ein Modellwechsel behebt keine veraltete Wissensbasis.

Wer KI-Systeme testen will, braucht daher zwei Perspektiven. Die Ende-zu-Ende-Prüfung zeigt, ob der gesamte Ablauf funktioniert. Komponententests grenzen die Ursache ein: Datenabruf, Antwortgenerierung, Werkzeugaufruf oder Regelprüfung. Erst diese Trennung macht aus einem Fehler eine konkrete Verbesserung.

Benchmarks beantworten eine andere Frage

Ein KI-Benchmark ist nicht wertlos. Er schafft Vergleichbarkeit unter den Bedingungen seiner Aufgaben und kann bei einer Vorauswahl helfen. Er ist jedoch kein Freigabezertifikat für einen eigenen Geschäftsprozess.

Öffentliche Tests bilden weder die interne Sprache noch die vorhandenen Dokumente, Berechtigungen und Grenzfälle eines Unternehmens ab. Bei frei verfügbaren Aufgaben lässt sich außerdem nicht immer ausschließen, dass ähnliche Inhalte bereits im Training eines Modells vorkamen. Ein gutes Ergebnis sagt dann weiterhin etwas über die Testleistung aus, aber weniger über die Übertragbarkeit auf neue Situationen.

Die sinnvolle Rollenverteilung ist klar: Benchmarks liefern Hinweise auf allgemeine Fähigkeiten. Ein eigener Evaluationsdatensatz prüft die Eignung für den vorgesehenen Einsatz. Die Entscheidung fällt auf Basis des Fehlerprofils, nicht auf Basis der prominentesten Zahl.

Nach der Freigabe verändert sich der Test

Ein System kann einen sorgfältig gebauten Testkorpus bestehen und später auf Eingaben treffen, die darin nicht vorkamen. Dokumentbestände wachsen, Begriffe verändern sich, neue Ausnahmefälle tauchen auf. Evaluation endet deshalb nicht mit dem ersten produktiven Einsatz.

Hilfreich ist die Verbindung aus einem festen Regressionstest und einem veränderlichen Satz neuer Grenzfälle. Der feste Teil zeigt, ob bekannte Fähigkeiten erhalten bleiben. Der veränderliche Teil prüft, ob das System auch mit neuen Mustern umgehen kann.

Reale Fehler sind dafür besonders wertvoll. Nach fachlicher Prüfung können sie als neue Testfälle in den Korpus einfließen. Dabei zählt nicht nur die fehlerhafte Ausgabe. Gesichert werden müssen auch die beteiligte Systemversion, die verwendete Quelle und der relevante Verarbeitungsschritt. Sonst lässt sich der Fall später nicht reproduzieren.

Die Freigabe bleibt damit eine begrenzte Aussage: Diese konkrete Systemversion erfüllt unter den geprüften Bedingungen eine definierte Aufgabe. Ihre bekannten Fehler sind sichtbar und für den Einsatz ausreichend begrenzt. Ändern sich Modell, Datenzugriff oder Werkzeuge, muss diese Aussage erneut geprüft werden.

Belastbare Qualität hinterlässt Spuren

Aus Sicht der ANORA-Redaktion liegt hier der entscheidende Perspektivwechsel: Nicht das Modell erhält ein allgemeines Gütesiegel. Bewertet wird eine klar bezeichnete Systemkonfiguration in einem klar begrenzten Einsatz.

Beim nächsten Modellvergleich ist deshalb nicht die eindrucksvollste Antwort ausschlaggebend. Entscheidend ist, ob dieselbe Konfiguration den schwierigen Fall wiederholt richtig behandelt, die maßgebliche Quelle verwendet und bei fehlender Grundlage kontrolliert stoppt.

Wer diese Spuren sehen kann, erkennt belastbare Modellqualität. Wer nur eine glänzende Einzelausgabe sieht, erkennt vor allem eine gute Demo.