Ungültige Ausgaben unmöglich machen, statt bis zur Gültigkeit zu wiederholen
Eine Parse-Fehlerquote von zwei Prozent mit Wiederholung sieht auf einem Dashboard nach gelöstem Problem aus. Für die Pipeline ist es gelöst, für den Datensatz nicht — denn eine erfolgreiche Wiederholung sagt nichts darüber, warum der erste Versuch scheiterte.
Der Fehler, den wir unsichtbar gemacht hatten
Der Extraktionsschritt liefert ein JSON-Objekt gegen ein Schema. Rund zwei Prozent der Antworten ließen sich nicht parsen: ein Komma zu viel, ein Schlüssel ohne Anführungszeichen, ein Stück Prosa vor dem Objekt. Die Pipeline wiederholte einmal und war fast immer erfolgreich — die Kennzahl, die irgendwen erreichte, war also die Quote nach Wiederholung, und die war ausgezeichnet.
Diese Anordnung ist bequem und verwirft Information. Ein Modell, das bei einem bestimmten Dokument fehlerhafte Ausgaben erzeugt, sagt damit etwas über dieses Dokument — und wir hatten einen Mechanismus gebaut, der es still bat, es noch einmal zu versuchen, bis es aufhörte, es uns zu sagen.
Binden statt korrigieren
Die Alternative ist, die fehlerhafte Ausgabe unerreichbar zu machen. Die Erzeugung wird so eingeschränkt, dass an jeder Stelle nur vom Schema erlaubte Token entstehen können — das Ergebnis parst also konstruktionsbedingt, und aus strukturellen Gründen braucht es keine Wiederholung.
Dong und Kollegen veröffentlichten in jenem Winter XGrammar, eine Maschinerie für strukturierte Erzeugung, die solche Einschränkungen effizient genug machen soll, um sie regelmäßig statt als Sonderfall zu nutzen. Die Effizienz ist hier die ganze Frage: Gebundene Erzeugung ist seit Langem möglich und war teuer genug, um sie zu meiden.
Was dabei sichtbar wurde
Sobald strukturelle Fehler nicht mehr auftreten konnten, haben wir die zuvor nicht parsbaren Dokumente mit dem Rest verglichen. Die Extraktionsfehlerquote in dieser Gruppe lag nach Wiederholung etwa fünfmal so hoch wie bei Dokumenten, die beim ersten Mal parsten.
Die fehlerhafte Ausgabe war ein Signal gewesen. Die Dokumente, die sie erzeugten, waren die ungewöhnlichen: eine gescannte Seite mit einer zweiten Tabelle, ein Lieferant mit abweichendem Datumsformat, eine Notiz am Rand. Die Wiederholung hatte einen lauten Fehler in eine leise falsche Antwort verwandelt.
| Ansatz | Was man bekommt |
|---|---|
| Wiederholen bis es parst | Gültige Datensätze und ein verlorenes Signal |
| Erzeugung an die Grammatik binden | Gültig per Konstruktion, Signal anderswo erhalten |
| Binden plus Feldmarkierungen | Beides, um den Preis eines breiteren Schemas |
| Freitext und nachsichtig parsen | Keines von beidem. Machen wir nicht mehr |
Was wir vom alten Verhalten behalten haben
Das Signal, bewusst wiederhergestellt. Das Schema enthält heute je Feld eine Markierung für im Dokument nicht vorhanden, und der Schritt ist angewiesen, sie zu nutzen statt zu raten. Datensätze, bei denen mehrere Felder markiert zurückkommen, gehen in die Prüfung — genau die Population, die früher die Parse-Fehler identifizierten.
Das ist die allgemeine Lehre, die wir gezogen haben. Wenn man einen Fehlermodus beseitigt, prüfe man, was er mitgeteilt hat — denn eine Kennzahl, die besser wird, weil ein Symptom unterdrückt wurde, ist schlimmer als das Symptom.
Wo Binden die Sache verschlechtert
Wenn das Schema falsch ist. Ein gebundenes Modell kann nicht sagen, dass in Ihrer Aufzählung ein Wert fehlt; es wählt selbstsicher den nächstliegenden erlaubten, und der entstehende Datensatz ist gültig und falsch. Uns ist das bei einem Dokumenttyp passiert, dessen Status unsere Aufzählung nicht enthielt.
Deshalb enthält jede Aufzählung einen Sonstiges-Wert mit begleitendem Freitextfeld, und wir beobachten, wie oft er genutzt wird. An einem Anstieg merken wir, dass ein Schema hinter die Dokumente zurückgefallen ist — etwas, das Schemata still tun.
Was die Bindung kostet
Etwas Latenz und eine echte Einschränkung, wo sie nutzbar ist. Sie verlangt einen Serving-Stack, der sie unterstützt, was sie bei manchen gehosteten Anbietern ausschließt, und sie gilt für den Modellaufruf, nicht für die Pipeline — ein Schritt aus mehreren Aufrufen braucht die Bindung also bei jedem.
Bei Schritten, die Text für Menschen erzeugen, binden wir überhaupt nicht. Eine Grammatik über Prosa ist entweder so weit, dass sie nichts zusichert, oder so eng, dass die Sprache leidet — und die Prüfung gehört dort zu der Person, die es liest.
Was sich in den Zahlen geändert hat
Die Parse-Fehler gingen auf null, das war das uninteressanteste Ergebnis. Nützlich war, dass markierte Datensätze auf rund drei Prozent stiegen, etwas über der alten Parse-Fehlerquote, und dass die Fehlerquote in dieser markierten Gruppe hoch genug ist, dass die Prüfung die Zeit klar wert ist.
Die Gesamtgenauigkeit der Extraktion stieg um etwa anderthalb Punkte, vollständig aus der zuvor verborgenen Gruppe. Am Modell hat sich nichts geändert. Wir hatten schlicht aufgehört, die Fälle wegzuwerfen, mit denen es sich schwertat.
Was wir nicht behaupten
Wir behaupten nicht, gebundene Erzeugung verbessere die Richtigkeit. Sie sichert die Form zu. Der Genauigkeitsgewinn in unseren Zahlen kam daher, dass schwierige Dokumente in die Prüfung gehen, nicht daher, dass das Modell besser extrahiert — und beides zu verwechseln wäre der naheliegendste Fehler bei dieser Technik.
Wir behaupten auch nicht, Wiederholungen seien immer falsch. Bei einem vorübergehenden Netzwerkfehler ist eine Wiederholung genau richtig. Unser Einwand gilt der Wiederholung eines inhaltlichen Fehlschlags, wo der zweite Versuch keine zweite Chance unter gleichen Bedingungen ist, sondern eine neue Stichprobe aus einem Modell, dem diese Eingabe bereits schwerfiel.