Gemessen, nicht versprochen.
Die Zahlen, die Klorn veröffentlicht, woher jede stammt und was jede nicht aussagen kann. Jedes hier genannte Set und Skript liegt im öffentlichen Repository.
Drei Zahlen und ihre Quellen
- ≥90 %Recall bei dringenden Mails, CI-Untergrenze
Eine Änderung am Klassifikator, die den Recall bei dringenden Mails auf dem synthetischen Gate-Set unter 90 % drückt, lässt den Build scheitern.
Quelle: eval-floors.ts - 95,5 %Silent-Präzision
Gemessen auf dem von Hand gelabelten Set echter Mails: Von 22 Nachrichten, die Klorn unter Silent abgelegt hat, waren 21 als Silent gelabelt. Drei Durchläufe am 2026-08-26, jedes Mal identisch.
Quelle: eval/README.md - 0Nicht freigegebene Aktionen
Senden, endgültiges Löschen und Weiterleiten an externe Adressen warten auf eine Freigabe und protokollieren einen Beleg, der an einen Hash des Versendeten gebunden ist. Eine Auto-Antwort-Regel, die du selbst angelegt hast, zählt als diese Freigabe.
Im Code durchgesetzt: attention-floor.ts
Keine Gesamtgenauigkeit. Das Set echter Mails ist älter als die Spuren Meeting und Info: Seine Labels verwenden drei Spuren, es kann die anderen beiden also nicht bewerten und muss für alle fünf neu gelabelt werden. Bis es neu gelabelt ist, nennen wir daraus keine Gesamtgenauigkeit. Die Silent-Präzision oben stammt aus demselben Set und hat dieselben Grenzen.
Wie die Evaluation läuft
Die eingecheckten Sets
In packages/api/eval/ liegen zwei Sets. Das Set echter Mails (real-eval-set.json) enthält
53 echte E-Mails, von Hand gelabelt und von personenbezogenen Daten bereinigt. Das synthetische Gate-Set
(judge-eval-set.json) enthält 56 erfundene E-Mails ohne personenbezogene Daten.
Der Runner
Im Verzeichnis packages/api bewertet pnpm eval:real den Klassifikator gegen das Set echter Mails;
pnpm eval:judge tut dasselbe für das synthetische Set.
Das Gate in der CI
Jeder Pull Request, der den Klassifikator ändert, schickt das synthetische Gate-Set durch das Modell, mit drei durchgesetzten Untergrenzen: 80 % insgesamt, 90 % Recall bei dringenden Mails und 90 % Silent-Präzision. Ein Lauf unter einer dieser Grenzen scheitert. Hat der Job keinen Modellschlüssel, etwa bei einem Pull Request aus einem Fork, wird er mit einem Hinweis übersprungen, statt als bestanden zu gelten.
Eine zweite Prüfung braucht kein Modell und läuft bei jedem CI-Testlauf: Der regelbasierte Schnellpfad und der Schlüsselwort-Fallback müssen auf demselben Set 70 % erreichen, eine übersehene dringende Nachricht muss in Queue statt in Silent landen, und eine Marketingnachricht darf nie als dringend markiert werden.
Das Set echter Mails wird in denselben Pull Requests nur als Bericht bewertet. Seine Kategorie für dringende Mails hat 4 gelabelte Nachrichten, zu wenige, als dass eine Untergrenze von 90 % etwas aussagen würde.
Am 2026-10-14 mit dem Repository abgeglichen. Stimmt hier etwas nicht? Sag es uns.