Wie ich KI-Systeme bewerte

Der Benchmark ist nicht das System

Als ich für eine produktive Dokumenten-Pipeline einen Anbieter für die Extraktion auswählen musste, war die Genauigkeitszahl aus dem Datenblatt die am wenigsten nützliche Größe, die ich hatte. Ein Modell kann in einem öffentlichen Benchmark gut abschneiden und trotzdem die falsche Wahl sein. Ein Benchmark misst das Modell für sich allein, und im Produktivbetrieb läuft es nie für sich allein.

Entscheidend ist, ob die Ausgabe den Kontakt mit allem übersteht, was danach kommt: mit dem Schema, in das sie passen muss, mit dem Budget, gegen das sie läuft, und mit der Nacharbeit, die eine falsche Antwort später einem Menschen aufzwingt.

Ich bewerte deshalb kein Modell. Ich bewerte das Modell an der Stelle, an der es sitzt.

Was ich tatsächlich vergleiche

Drei Dinge, in dieser Reihenfolge.

Struktur. Passt die Ausgabe jedes Mal in ein striktes Schema? In dieser Pipeline muss jede Extraktion in einem typisierten Pydantic-Schema landen. Ein Anbieter, der flüssige, richtig aussehende Prosa liefert, das Schema aber nicht verlässlich trifft, ist bei dem einzigen Test durchgefallen, der für ein automatisiertes System zählt, weil der nächste Schritt mit seiner Ausgabe nichts anfangen kann.

Genauigkeit pro Nacharbeit statt Genauigkeit auf dem Papier. Was eine falsche Extraktion wirklich kostet, ist die Zeit, sie später zu finden und zu korrigieren. Ein günstigerer Anbieter, der einen Nachmittag Datenbereinigung nach sich zieht, ist nicht günstiger.

Beim Vergleich eines spezialisierten OCR-Dienstes, eines allgemeinen Sprachmodells (gpt-4o) und eines dokumenten-nativen Modells lief die Entscheidung genau darauf hinaus. Der OCR-Dienst gab rohe beschriftete Boxen zurück, die ohne eigene Normalisierungsschicht in kein Schema passten. Das allgemeine Modell erzeugte sauberes JSON, patzte aber bei schlechten Scans. Das dokumenten-native Modell war genau genug, um gar keine Nacharbeit am Format zu brauchen, sodass am Ende der Seitenpreis den Ausschlag gab, ohne je das Kriterium gewesen zu sein.

Fehlerverhalten. Scheitert es laut oder leise? Ein Modell, das einen Fehler wirft, ist ungefährlich: Das System hält an und fällt zurück. Gefährlich ist das Modell, das eine selbstbewusste, wohlgeformte und falsche Antwort zurückgibt, denn nichts weiter unten in der Kette weiß, dass es ihr misstrauen sollte.

Validieren, bevor man vertraut

Daraus folgt eine konkrete Entwurfsregel: Der Rückfall greift auch bei Validierungsfehlern und nicht nur bei API-Fehlern. Jedes Ergebnis wird gegen sein Schema geprüft, bevor es angenommen wird, und ein Validierungsfehler nimmt denselben Weg wie ein klarer Fehler, nämlich zum nächsten Anbieter. Das kostet die Latenz eines zweiten Aufrufs, dafür gelangt keine plausible falsche Extraktion stillschweigend in die Bücher.

Eine selbstbewusste Antwort, die am Schema scheitert, ist gefährlicher als ein Fehler. Ein Fehler hält an. Ein plausibler falscher Wert fließt weiter und taucht Wochen später wieder auf.

Die ehrliche Lücke, und was ihr Schließen gezeigt hat

Eine frühere Fassung dieses Textes endete hier mit einem Eingeständnis: Die Genauigkeit in dieser Pipeline war im Alltag hoch, aber ungemessen. Aus der Lücke wurde ein Arbeitspaket. Der Prüfstand existiert inzwischen, und ihn zu bauen hat mich mehr gelehrt als seine Ergebnisse.

Er besteht aus den vier Teilen oben, ungefähr in dieser Reihenfolge gebaut.

Ein kleines, von Hand gelabeltes Golden Set schlägt ein großes ungelabeltes. Zehn Dokumente, Feld für Feld bewertet, dazu ein Abgleich über 60 Dokumente gegen die gespeicherten Extraktionen des bisherigen Anbieters und ein Klassifikationslauf über 35 Stück gewöhnlicher Post. Zehn klingt dünn. Es reichte, um eine Anbietermigration zu entscheiden, weil jedes Feld einzeln bewertet wird und ein Fehltreffer pro Feld eindeutig ist.

Eine Schicht konstant zu halten hat den eigentlichen Wert lokalisiert. Ein günstiges allgemeines Sprachmodell und den spezialisierten Dienst über identisches Markdown laufen zu lassen zeigte, dass der Extraktionsschritt fast Massenware ist: Der günstige Extraktor hielt zu etwa einem Zweihundertstel der Kosten mit. Was der bisherige Anbieter wirklich wert war, lag in seinem Parsing. Kein Benchmark aus dem Datenblatt hätte mir das gesagt; gezeigt hat es erst, eine Schicht festzuhalten und die andere zu tauschen.

Ende zu Ende zog das dokumenten-native Modell auf jedem datentragenden Feld gleich oder vorbei, bei einem Bruchteil der Kosten. Konkrete Feld-Genauigkeiten nenne ich hier bewusst nicht, und der Grund gehört zum Thema: Der Korpus, auf dem sie beruhen, ist nicht mehr reproduzierbar, weil die Handlabels außerhalb der Versionierung lagen. Eine Zahl, die man nicht nachrechnen kann, ist keine Messung, sondern eine Behauptung. Das neue Gold-Set entsteht gerade, diesmal versioniert.

Das Abweichungsprotokoll war das eigentliche Ergebnis, nicht die Quote. Jede Divergenz wurde von Hand geprüft statt weggemittelt, und ein erheblicher Teil ging darauf zurück, dass die Referenz falsch lag: Kassenberichte, die der bisherige Anbieter in seinem eigenen Bestand als Rechnungen abgelegt hatte. Die rohe Übereinstimmungsquote bestrafte den Herausforderer dafür, recht zu haben. Ein Prüfstand, der seiner eigenen Referenz vertraut, misst etwas anderes.

Die Ergebnisse waren auch nicht durchgehend gut, und genau deshalb wird pro Feld ausgewertet statt über eine Gesamtquote. Auf gemischter Alltagspost fiel die Typklassifikation deutlich schwächer aus als auf sauberen Lieferantenrechnungen. Beides hat benennbare Ursachen: eine Taxonomie, die für die alltäglichen deutschen Dokumenttypen zu grob war, und eine Empfängerfrage, die eine fachliche Entscheidung ist und kein Extraktionsfehler, denn Lieferantenrechnungen laufen auf den Inhaber und nicht auf die Firmierung.

Der vierte Teil fehlt weiterhin. Korrekturen passieren in einer Prüfliste, aber die Korrekturrate pro Feld wird noch nicht als Kennzahl geführt, die in den Vergleich zurückfließt. Das ist die nächste Lücke, und es ist die, die den Kreis zur Genauigkeit pro Nacharbeit schließen würde.

Die Bewertung ist der Teil, den die meisten KI-Demos überspringen, und zugleich der Teil, der entscheidet, ob man einem System zutrauen kann, unbeaufsichtigt zu laufen.