KI-Modell-Evaluation: Eigenes Evaluations-Set in fünf Schritten aufbauen

Eine KI-Modell-Evaluation macht einen Modellwechsel messbar, statt ihn auf Bauchgefühl und Vorführeindruck zu stützen. Ein eigenes Evaluations-Set zeigt in Stunden, ob ein Modell für Ihre realen Geschäftsprozesse präzise genug arbeitet und ob eine neue Version dasselbe leistet wie die alte.

Die verbreitete Annahme, ein KI-Anbieter lasse sich in wenigen Wochen austauschen, hält selten stand. Das Problem liegt meist nicht bei der Schnittstelle. Es steckt in Prompts, Sonderlogik und fehlenden Qualitätsmaßstäben. Wenn niemand schriftlich festgelegt hat, welche Antwort in welchem Fall als korrekt gilt, kann auch niemand nachweisen, dass ein neues Modell gleich gut oder besser arbeitet.

Ein Evaluations-Set bildet Geschäftsentscheidungen ab, nicht Allgemeinwissen

Ein Evaluations-Set ist eine versionierte Sammlung echter oder sorgfältig anonymisierter Testfälle samt erwarteten Ergebnissen und klaren Bewertungskriterien. Es bildet nicht den allgemeinen Wissensstand eines Modells ab, sondern die Aufgaben, für die Ihr Unternehmen Geld ausgibt oder Risiken trägt.

Der typische Fehler: Teams testen mit einer Handvoll freundlicher Beispielprompts aus einem Workshop. Die Ergebnisse sehen überzeugend aus, weil die Fälle klar formuliert sind und keine widersprüchlichen Daten enthalten. Im Betrieb kommt dann eine eingescannte Rechnung mit handschriftlicher Ergänzung, eine Kundenanfrage ohne Vertragsnummer oder ein Logistikfall mit zwei abweichenden Lieferadressen. Genau diese Fälle gehören in die Evaluation.

Ein Versicherungsdienstleister, der eingehende E-Mails vorsortiert, braucht mehr als den Text der Nachricht als Testfall. Der Fall enthält die erwartete Kategorie, etwa „Schadenmeldung“, die erlaubten Folgeschritte und den Hinweis, ob ein Mensch zwingend prüfen muss. „Modell A klingt verständlicher als Modell B“ hilft hier nicht. Relevant ist, ob das Modell einen Kündigungswunsch fälschlich als allgemeine Anfrage einordnet und damit eine Frist gefährdet.

Schritt 1: Einen Anwendungsfall klar abgrenzen

Ein Evaluations-Set wird klein begonnen und auf einen Prozess zugeschnitten. Wählen Sie einen Anwendungsfall, dessen Nutzen und Fehlerkosten bekannt sind: die Klassifikation von Support-Tickets, die Extraktion von Feldern aus Dokumenten oder die Prüfung von Vertragsklauseln gegen interne Richtlinien.

Formulieren Sie vor der Datensammlung einen Prüfsatz: „Das Modell extrahiert aus Frachtbriefen Sendungsnummer, Abholort und Empfängeradresse in strukturierter Form.“ Dieser Satz grenzt die Aufgabe ein. „KI soll Dokumente verstehen“ ist dagegen keine prüfbare Anforderung, sondern eine Wunschformel.

Legen Sie je Feld fest, welche Trefferquote Sie verlangen. Bei der Sendungsnummer darf fast nichts danebengehen. Bei der Empfängeradresse kann ein niedrigerer Wert akzeptabel sein, wenn unsichere Antworten zuverlässig gekennzeichnet und an die Sachbearbeitung gegeben werden. Qualität heißt hier nicht, jede Eingabe fehlerfrei zu lösen. Qualität heißt, Fehler nicht unbemerkt ins operative System durchzulassen.

Schritt 2: Testfälle aus dem Betrieb ziehen statt aus dem Lehrbuch

Die besten Testfälle liegen bereits in Ticketsystemen, Postfächern und Fachanwendungen. Ziehen Sie Fälle aus einem Zeitraum, der saisonale Besonderheiten enthält: Monatsenden bei der Rechnungsverarbeitung, Eskalationen und unvollständige Anfragen im Kundenservice.

Einige Dutzend sorgfältig ausgewählte Fälle reichen für den Anfang. Das genügt, um Unterschiede zwischen Modellen sichtbar zu machen, und ist klein genug, um jedes Ergebnis ernsthaft zu prüfen. Leichte Standardfälle dürfen enthalten sein, aber sie dürfen das Bild nicht dominieren. Ein Set, das nur Routine abbildet, belohnt ein Modell für eine Leistung, die im Alltag kaum Probleme macht.

Ein praxistauglicher Fall für die Vertragsprüfung sieht so aus:

• Eingabe: Auszug aus einem Liefervertrag, inklusive Anlage mit abweichender Haftungsregelung.
• Erwartung: Das Modell markiert die Klausel, zitiert die Textstelle und ordnet sie der internen Prüfkategorie „Haftung über Standard“ zu.
• Abnahmeregel: Ein Zitat ohne korrekte Kategorie gilt als Fehler. Eine korrekte Kategorie ohne nachvollziehbare Fundstelle ebenfalls.

Personenbezogene Daten und Geschäftsgeheimnisse gehören nicht unkontrolliert in externe Testumgebungen. Anonymisierung ist nötig, aber sie darf den Fall nicht entkernen. Ersetzen Sie Namen, Beträge und Adressen systematisch; behalten Sie Satzbau, Dokumentstruktur und fachliche Konflikte bei. Wer aus Angst vor dem Datenschutz nur künstliche Musterfälle nutzt, misst später eine Fantasiequalität.

Schritt 3: Erwartete Ergebnisse präzise festlegen

Jeder Fall braucht einen Goldstandard: das Ergebnis, das als korrekt akzeptiert wird. Bei Extraktionsaufgaben ist das einfach. Für eine Rechnung enthält der Goldstandard etwa Rechnungsnummer, Betrag, Währung und Fälligkeitsdatum.

Schwieriger wird es bei Zusammenfassungen oder Antwortentwürfen. Starre Musterantworten sind dort oft falsch, weil mehrere Formulierungen fachlich richtig sein können. Bewerten Sie stattdessen einzelne Kriterien. Ein Entwurf für eine Kundenantwort muss die Vertragsnummer nennen, keine Zusage außerhalb der Kompetenz geben und den nächsten Prozessschritt erklären. Die Wortwahl ist zweitrangig.

Bewahren Sie die Bewertungskriterien neben den Testdaten auf, versioniert. Wenn eine Fachabteilung eine Richtlinie ändert, muss nachvollziehbar sein, ab wann ein Ergebnis als Fehler zählt. Ohne Versionierung vergleichen Teams alte und neue Modelle gegen wechselnde Regeln. Das erzeugt Diskussionen, aber keine belastbare Entscheidung.

Schritt 4: Kennzahlen an Geschäftsschäden ausrichten

Eine einzelne Gesamtquote führt in die Irre. Ein Modell mit hoher Trefferquote kann unbrauchbar sein, wenn die wenigen Fehler genau die regulatorisch kritischen Fälle treffen. Gewichten Sie Fehler deshalb nach ihrem Schaden.

Für die Ticketklassifikation bietet sich eine Konfusionsmatrix an. Sie zeigt, welche Kategorien das Modell verwechselt. Wird „Störung im Zahlungsverkehr“ regelmäßig als „allgemeine Frage“ erkannt, ist das ein operatives Risiko. Verwechselt das Modell zwei Unterkategorien ohne unterschiedliche Bearbeitungsfrist, wiegt der Fehler weniger schwer.

Ergänzen Sie fachliche Qualität um Laufzeit und Kosten pro Fall. Ein Modell, das pro Dokument länger braucht, als der Prozess auf eine Antwort wartet, scheidet aus, egal wie gut es antwortet. Ein günstigeres Modell kann die bessere Wahl sein, wenn es die Mindestqualität erreicht und seine Fehler über eine sichere Übergabe an Mitarbeitende abgefangen werden. Das ist Architektur statt Markentreue.

Schritt 5: KI-Modell-Version einfrieren, Compliance nachweisen, Testlauf automatisieren

Ein Evaluations-Set entfaltet seinen Wert erst durch Wiederholung. Führen Sie den Testlauf bei jedem Modellwechsel aus, aber auch nach Prompt-Anpassungen, Änderungen an den Wissensquellen oder neuen Modellversionen des bestehenden Anbieters. Anbieter ändern das Verhalten ihrer Modelle, ohne dass sich Ihr Code ändert. Wer die Modellversion nicht einfriert, testet heute etwas anderes als morgen.

Die Umsetzung muss nicht überladen sein. Ein kleines Programm sendet jeden Testfall an das Modell, prüft das strukturierte Ergebnis gegen den Goldstandard und erzeugt einen Bericht. Für offene Antworten kann ein zweites Modell als Bewerter helfen. Die kritischen Fälle prüfen trotzdem Fachleute. Ein Modell darf nicht unbeaufsichtigt die Qualität eines anderen bescheinigen, wenn es um Compliance oder geschäftskritische Entscheidungen geht.

Speichern Sie pro Lauf Modellname, Modellversion, Prompt-Version, Datenstand, Antwortzeit und Ergebnis. Nach einigen Monaten sehen Sie mehr als den heutigen Gewinner. Sie erkennen, wann sich die Qualität verschlechtert hat und welche Änderung dafür verantwortlich war. Diese Nachweisbarkeit ist für regulierte Branchen mehr wert als ein beeindruckender Bildschirmausschnitt aus einem Chatfenster.

Überprüfbare Wechsel statt Abhängigkeit

Ein Anbieterwechsel scheitert häufig daran, dass Prompts und Spezialfunktionen in Fachanwendungen gewachsen sind. Die Evaluation macht diese Abhängigkeiten sichtbar. Wenn Modell B dieselben Fälle erhält wie Modell A und nach denselben Regeln bewertet wird, wird aus einer Absicht ein überprüfbarer Migrationsschritt.

Das heißt nicht, dass jeder Anbieter austauschbar ist. Manche Funktionen sind fachlich sinnvoll und rechtfertigen eine Bindung. Der Unterschied liegt in der bewussten Entscheidung: Sie kennen den Preis dieser Bindung und besitzen eine Ausgangsbasis für Alternativen. Testfälle, Prompts und Bewertungslogik bleiben in Ihrem Verantwortungsbereich. Wie eine Architektur aussieht, die den Modellwechsel von Anfang an vorsieht, beschreibt der Beitrag KI-Readiness: Systeme für den Modellwechsel bauen.

Häufige Fragen zur KI-Modell-Evaluation

Wer definiert den Goldstandard? Die Fachabteilung legt fest, was im Prozess korrekt und zulässig ist. KI-Verantwortliche übersetzen das in prüfbare Formate und automatisierte Testläufe. Bei risikoreichen Fällen gehört die Compliance an den Tisch, bevor die Bewertung produktiv genutzt wird.

Kann ein öffentlicher Benchmark ein eigenes Evaluations-Set ersetzen? Nein. Öffentliche Benchmarks messen breite Fähigkeiten, nicht die Qualität in Ihren Dokumenten, Begriffen und Prozessregeln. Ein Modell kann dort hervorragend abschneiden und trotzdem Ihre Rechnungsformate oder Freigabelogik schlecht verarbeiten.

Wie oft sollte die Evaluation laufen? Vor jedem Modellwechsel und vor jeder produktiven Änderung an Prompts oder Datenquellen. Bei hohem Volumen oder regulatorischer Relevanz in festen Intervallen. Neue Fehlfälle aus dem Betrieb wandern zeitnah ins Set.

Der nächste Schritt: Ihre ersten Fälle sammeln

Wählen Sie einen Prozess, dessen Fehlerkosten Sie kennen, und ziehen Sie ein paar Dutzend echte Fälle aus dem letzten Quartal, anonymisiert und mit dem Ergebnis, das damals richtig war. Mit dieser Sammlung klären wir in eine halbe Stunde, ob Ihr aktuelles Modell die Aufgabe trägt und was ein Wechsel kosten würde: Potenzial-Check buchen.