Ein Modell fügte einer Tabellenzelle ein Zeichen hinzu. Die Schema-Validierung sah es nicht.

Ein Modell, das eine Tabelle transkribieren soll, verbessert sie manchmal. Nicht böswillig und nicht oft – aber verlässlich genug, dass eine eigene Prüfung nötig war.

Der Fall, der sie auslöste, war klein. Eine Zelle in einem Darlehensdokument lautete 循環貸款, ein revolvierendes Darlehen. Das Modell gab 循環貸款等 zurück – dieselben Wörter mit angehängtem 等, wodurch aus einem bestimmten Instrument „revolvierende Darlehen und so weiter" wurde. Ein Zeichen. Beim flüchtigen Vergleich mit dem Scan sieht man es nicht.

Warum die üblichen Prüfungen es verfehlen

Die meisten Tabellenextraktionen werden per Schema validiert. Ist die Spalte da? Stimmt der Typ? Ist die Zeilenzahl plausibel? Das Schema beantwortet alle drei und meldet Erfolg, denn die Spalte bleibt die Spalte und der Typ bleibt eine Zeichenkette. Der Wert ist auf eine Weise falsch, die keine strukturelle Prüfung ausdrücken kann.

Nur der Vergleich mit der Quelle erkennt es. Nachdem das Modell eine Zelle erzeugt hat, stellt der Prüfer deshalb eine engere Frage: Steht genau dieser Text in der Textebene der Seite, aus der die Tabelle stammt? Nicht „ist dieser Wert plausibel" – genau diese Frage hat den Fehler erzeugt.

Wie das in der Ausgabe aussieht

Eine vom Dokument bestätigte Zelle wird normal geliefert. Eine nicht bestätigbare Zelle wird markiert, und die gesamte Lieferung gilt als „mit Warnungen" statt als sauberer Erfolg. Das Manifest hält die Einzelheiten fest:

{
  "outcome": "succeeded_with_warnings",
  "warnings": [
    "extra_fields:2",
    "unconfirmed_cells:个人关键信息"
  ],
  "source_pages": 7
}

Das ist ein echtes Manifest dieser Seite, ohne Identifikatoren. Es sagt drei Dinge: Die Extraktion ist brauchbar, zwei nicht im Schema verlangte Felder wurden erzeugt, und eine Spalte konnte gar nicht bestätigt werden. Wer diese Datei erhält, weiß genau, welche Spalte von Hand zu prüfen ist.

Was der Produktionsstand zeigt

Von den auf dieser Seite verzeichneten Tabellenlieferungen waren 13 von 14 mit Warnungen statt sauber markiert. Vier enthielten unbestätigte Zellen. Es wäre leicht, das als Problem darzustellen; die ehrliche Lesart ist, dass die Prüfung tut, wofür sie gebaut wurde, und die Alternative – alle vierzehn als Erfolg zu melden – in mindestens vier Fällen eine Lüge gewesen wäre.

Die Lehre gilt über Tabellen hinaus. Wann immer ein Modell etwas reproduzieren soll, das bereits in einem Dokument steht, sagt eine strukturelle Prüfung, dass die Form stimmt, und nichts darüber, ob der Inhalt stimmt. Wenn der Inhalt zählt, muss er mit der Quelle verglichen werden.

Was daraus folgt

1. Behandeln Sie „unbestätigt" als Frage, nicht als Fehlschlag. Diese Zelle braucht einen menschlichen Blick; die übrigen 99 % des Blatts nicht.
2. Verlangen Sie keinen Wert, den das Dokument nicht enthält. Ein Modell, das eine Lücke füllen soll, füllt sie.
3. Vergleichen Sie die Warnungszahl mit der Zahl der definierten Spalten. Zusätzliche Felder sind die Spur eines Modells, das den Umfang still erweitert.

Um das Verhalten am eigenen Dokument zu sehen: Die Strukturvorschau ist kostenlos und liefert die erkannten Tabellen und Spalten, bevor Credits ausgegeben werden.