Wie ich KI-Systeme bewerte

Der Benchmark ist nicht das System

Als ich einen Extraktions-Provider für eine produktive Dokumenten-Pipeline wählen musste, erwies sich die Schlagzeilen-Genauigkeitszahl als 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, denn ein Benchmark misst das Modell isoliert, und ein Produktivsystem führt es nie isoliert aus. Entscheidend ist, ob die Ausgabe den Kontakt mit allem Nachgelagerten übersteht: dem Schema, in das sie passen muss, dem Budget, gegen das sie läuft, und der manuellen Nacharbeit, die eine falsche Antwort einem Menschen später aufzwingt.

Ich bewerte also nicht ein Modell. Ich bewerte das Modell in der Naht, in der es sitzt.

Was ich tatsächlich vergleiche

Drei Dinge, in dieser Reihenfolge.

Struktur. Passt die Ausgabe jedes Mal in ein striktes Schema? In der Pipeline muss jede Extraktion in einem typisierten Pydantic-Schema landen. Ein Provider, der flüssige, korrekt aussehende Prosa liefert, aber das Schema nicht zuverlässig erzeugt, ist beim einzigen Test durchgefallen, der für ein automatisiertes System zählt — der nächste Schritt kann sie nicht konsumieren.

Genauigkeit pro Nacharbeit, nicht Schlagzeilen-Genauigkeit. Die echten Kosten einer falschen Extraktion sind die menschliche Zeit, sie nachgelagert zu finden und zu korrigieren. Ein günstigerer Provider, der einen Nachmittag Datenbereinigung braucht, ist nicht günstiger. Als ich einen spezialisierten OCR-Dienst, ein Allzweck-LLM (gpt-4o) und ein dokumenten-natives Modell verglich, lief die Entscheidung darauf hinaus: Der OCR-Dienst gab rohe beschriftete Boxen zurück, die ohne eine eigene Normalisierungsschicht in kein Schema passten; das allgemeine LLM erzeugte sauberes JSON, patzte aber bei schlechten Scans; das dokumenten-native Modell war genau genug, um gar keine Format-Nacharbeit zu brauchen. Der Preis pro Seite war das Zünglein an der Waage, nicht der entscheidende Faktor.

Fehlerverhalten. Scheitert es laut oder leise? Ein Modell, das einen Fehler wirft, ist sicher — das System stoppt und fällt zurück. Ein Modell, das eine selbstbewusste, wohlgeformte, falsche Antwort zurückgibt, ist das gefährliche, denn nichts Nachgelagertes weiß, dass es ihr misstrauen soll.

Validieren, bevor du vertraust

Dieser letzte Punkt treibt eine konkrete Design-Regel: Fallback bei Validierungsfehler, nicht nur bei API-Fehlern. Jedes Ergebnis wird gegen sein Schema validiert, bevor es akzeptiert wird, und ein Validierungsfehler fällt zu einem anderen Provider durch — denselben Weg, den ein klarer Fehler nehmen würde. Die Kosten sind die Latenz eines zweiten Aufrufs; was es erkauft, ist, dass eine plausible-aber-falsche Extraktion nicht stillschweigend in die Bücher gelangt.

Eine selbstbewusste Antwort, die am Schema scheitert, ist gefährlicher als ein Fehler. Ein Fehler stoppt; ein plausibler-aber-falscher Wert fließt nachgelagert weiter und taucht Wochen später auf.

Die ehrliche Lücke: Ich habe es noch nicht gemessen

Hier ist, was ich nicht vorgeben werde: In dieser Pipeline ist die Extraktionsgenauigkeit in der Praxis hoch, aber ungemessen. Es gibt noch keine Evaluierungsschicht — die obige Validierungsregel fängt fehlerhafte Ausgabe ab, nicht plausible-aber-falsche. Das ist die echte Grenze, und sie zu benennen, ist Teil der Bewertung.

Würde ich die Eval bauen — und für ein Kundensystem würde ich das —, wären es vier Teile:

• Ein Golden Set. Ein paar Hundert Dokumente mit handverifizierten Feldwerten, bewusst zu den schwierigen Fällen gewichtet (schlechte Scans, ungewöhnliche Layouts), nicht nur den einfachen.
• Bewertung auf Feldebene. Exakter Abgleich für strukturierte Felder — Daten, Summen, Steuer — und unscharfer Abgleich für Namen; Precision und Recall pro Feld berichtet, nie zu einer globalen Prozentzahl zusammengefasst, die verbirgt, wo es tatsächlich scheitert.
• Eine Aufschlüsselung pro Provider und pro Stufe, sodass der Wechsel eines Providers zu einem messbaren Regressionstest wird statt einer Ermessensfrage.
• Ein Nacharbeits-Log. Jede manuelle Korrektur erfasst, denn die Korrekturrate pro Feld ist die Metrik Genauigkeit-pro-Nacharbeit — sie schließt die Schleife zurück zu den einzigen Kosten, die zählen.

Die Bewertung ist der Teil, den die meisten KI-Demos überspringen. Sie ist auch der Teil, der entscheidet, ob einem System zugetraut werden kann, unbeaufsichtigt zu laufen. Das obige Rahmenwerk ist, was ich zu dieser Frage mitbringe.