Genauigkeits-Benchmarks

Ergebnisse aus gespeicherten Evaluierungsartefakten. Die angezeigten Daten sind die Messdaten.

OCR-Engine-Upgrade: PP-OCRv5 → PP-OCRv6

Gemessen am 09.07.2026 auf einer lokalen RTX-3090-GPU mit dem Produktionsimage (paddleocr==3.7.0, CUDA 12.9). Testobjekte: ein echtes 24-MP-HEIC-Kameradokument (polnischer Text, von Menschen transkribierte Referenzdaten) sowie die Beispielrechnungs- und Beleg-PDFs des Repositorys (pdftotext-Referenzdaten). Die Bewertung verwendet reihenfolgeunabhängigen Multiset-Recall und -Präzision.

Die bereitgestellte Konfiguration verwendet PP-OCRv6 medium mit text_det_box_thresh=0.5. Der niedrigere Box-Schwellenwert gewinnt schwache Zeilen aus Bereichen mit Glanz und Perspektive in Kamerafotos zurück (+20 Prozentpunkte Wort-Recall), ohne Regression bei sauber gerenderten Seiten.

Metrik	PP-OCRv5 (vorherig)	PP-OCRv6 medium + box_thresh 0.5 (aktuell)
Kamerafoto-Worttreffer	0.670	0.865 (+29 %)
Kamerafoto-Polnisch-Diakritika-Treffer	0.562	0.775 (+38 %)
Kamerafoto-Wortpräzision	0.986	0.955
Kamerafoto-Zahlentreffer	0.000	0.000
Kassenbon-Zahlentreffer	0.818	1.000 (+22 %)
Gedruckte Rechnung, dicht bedruckt (Treffer/Präzision)	1.000 / 1.000	1.000 / 1.000
GPU-Warm-Latenz (RTX 3090, dicht bedruckte Seite)	~0.55 s	~1.13 s

Der Wort-Recall auf gedruckten gerenderten Seiten (Rechnungs- und Beleg-PDFs) beträgt bei beiden Engine-Versionen 1.000 – die Verbesserung konzentriert sich auf Kamerafotos, bei denen Perspektive, Glanz und Komprimierung den Detektor belasten. Der numerische Recall (Beträge, Daten, Kennungen) ist der beste Näherungswert für die Feldextraktionsgenauigkeit, da Felder aus diesen Tokens zugeordnet werden.

Foto-Engine: Kameradokument-Vorverarbeitung

Gemessen am 09.07.2026 (gleiche Hardware und gleiches Bild wie beim OCR-Engine-Benchmark). Die Foto-Engine wendet vor der OCR auf Kamera-Uploads geometrische Entzerrung und Orientierungsklassifikation an. Sie wurde absichtlich nur für IMAGE-Uploads aktiviert – eine Entzerrung bereits ebener gerenderter Seiten führt durch verzerrte ausgerichtete Pixel zu einer Regression des Wort-Recalls von 1.000 auf 0.635.

Metrik	Ohne Vorverarbeitung (Basislinie)	Mit Entzerrung (Kamera-Uploads)
Kamerafoto-Worttreffer	0.865	0.921 (+6.6 %)
Kamerafoto-Polnisch-Diakritika-Treffer	0.775	0.854 (+10.2 %)
Kamerafoto-Wortpräzision	0.955	0.961
Gedruckte dichte Seite. Worttreffer	1.000	0.635 (Regression, absichtlich nur für Fotos)

Der Gewinn durch die Entzerrung ist real, setzt jedoch voraus, dass der OCR-Dienst das transformierte Seitenbild zurückgibt, damit Begrenzungsrahmen im korrekten transformierten Koordinatenraum gezeichnet werden. Die Beschränkung auf Fotos verhindert die Regression bei dicht gefüllten Seiten. Die Funktion wird über die Umgebungsvariable OCR_PHOTO_TRANSFORMS_ENABLED gesteuert.

Mehrrechnungs-PDF-Trennungserkennung

Gemessen am 21.07.2026 mit dem synthetischen beschrifteten Auswertungsdatensatz, der von scripts/gen_split_eval.py erzeugt und von scripts/eval_doc_split.py bewertet wurde. Der Detektor verwendet die eingebettete Textebene (pdftotext), um Signale für Seitengrenzen (Rechnungskopfzeilen, Muster für Datumsbeschriftungen, Schlüsselwörter für Dokumenttypen) vor jedem OCR- oder LLM-Aufruf zu finden; die Grenzerkennung ist daher kostenlos.

Bedingung	Grenzpräzision	Grenztreffer	F1	Ausgewertete Dokumente
Sauberer Text (kein OCR-Rauschen)	1.000	1.000	1.000	660
OCR-Rauschen auf Zeichenebene: 2 %	-	-	0.969	660

The eval set mixes multi-invoice PDFs with single-invoice negatives. Precision and recall are computed on exact page-index boundary matches. The 2 %% OCR noise model applies per-character confusion, dropping, and swapping (including colon loss, which breaks label regexes). At that noise level the detector achieves F1 0.969, which motivated the suggest-and-confirm UX: boundaries are offered to the user for review rather than applied silently.

Methodologische Hinweise

Alle Zahlen stammen aus im Repository versionierten Auswertungsartefakten (docs/ocr-calibration/*.json, docs/OCR_IMAGE_CALIBRATION.md). Ergebnisse der Trennungserkennung befinden sich in docs/ocr-calibration/split_detection_results.json. Es werden keine Zahlen geschätzt oder extrapoliert.
Die OCR-Bewertung verwendet reihenfolgeunabhängigen Multiset-Recall und -Präzision: Die Metrik zählt, ob jedes Wort-Token der Referenzdaten in der OCR-Ausgabe vorkommt (Recall) und ob jedes Token der OCR-Ausgabe in den Referenzdaten vorkommt (Präzision), ohne Unterschiede in der Lesereihenfolge zu bestrafen. Dies ist ein besserer Näherungswert für die Feldextraktionsgenauigkeit als Metriken zur Sequenzähnlichkeit, die empfindlich auf Änderungen bei der Zeilensegmentierung reagieren, obwohl diese den Tokeninhalt nicht beeinflussen.
Die Referenzdaten für Kamerafotos sind eine menschliche Transkription des Testdokuments (docs/IMG_2375.HEIC). Die Referenzdaten für gedruckte Seiten werden mit pdftotext erzeugt, demselben Werkzeug, das im Schnellpfad für digitale PDFs verwendet wird.
Präzision und Recall der Trennungserkennung messen exakte Übereinstimmungen von Seitenindizes in synthetisch erzeugten mehrteiligen Rechnungs-PDFs mit bekannten Grenzen. Der Auswertungsdatensatz deckt eine Reihe von Rechnungstypen, Datumsformaten und Lieferantennamen ab.
Benchmark-Wiederholungen nach jeder Engine-Änderung können mit den Skripten in scripts/ ausgelöst werden. Neue Ergebnisse werden in dev-artifacts/ (von Git ignoriert) abgelegt und nach Überprüfung versioniert.

Fragen zur Methodik oder zu den Ergebnissen: [email protected]

Noch nicht gemessen

Zwei Zahlen, nach denen ein Käufer fragen wird, fehlen auf dieser Seite bewusst, weil keine Auswertung sie belegt:

Extraktionsgenauigkeit auf Feldebene (Precision, Recall, F1 oder exakte Übereinstimmung pro Feld wie Rechnungsnummer, Summe oder Steuernummer). Die OCR-Zahlen oben messen, ob die Wörter gelesen werden, nicht ob der richtige Wert im richtigen Feld landet. Ein annotierter Testdatensatz wird aufgebaut; bis er existiert, wird kein Prozentwert veröffentlicht.
Ende-zu-Ende-Latenz (p50 und p95 vom Upload bis zum Ergebnis). Zeiten pro Verarbeitungsschritt werden als Metriken erfasst, aber es wurde noch keine Baseline veröffentlicht.

Wo DocSolved nachweislich schlechter abschneidet: Kamerafotos glänzender oder gewölbter Seiten (Wort-Recall 0,865 gegenüber 1,000 auf einer sauber gedruckten Seite), Zahlen auf demselben Foto (Zahlentreffer 0,000, unverändert gegenüber der vorherigen Engine, während ein Erkennungsschwellenwert, den wir nicht ausliefern, dort 1,000 erreicht), polnische diakritische Zeichen auf Fotos (0,775) und Foto-Entzerrung auf einer bereits flachen Seite (0,635, weshalb sie nur bei Kamerafotos läuft). Diese Fälle lassen sich prüfen, statt ihnen zu vertrauen: In einem gescannten Dokument trägt ein extrahiertes Feld die Verankerung, die der Abgleich herstellen konnte — den zugeordneten Quelltext, einen Abgleichstatus und eine Position auf der Seite, wenn der Wert verankert werden konnte — und kann einen Konfidenzwert tragen. Felder aus strukturierten E-Rechnungen durchlaufen gar kein OCR; sie stammen aus den Quelldaten und brauchen diese Signale nicht.

Maschinenlesbare Zahlen: docs/benchmarks/results.json im Repository, abgeleitet aus den eingecheckten Artefakten, und die Methodik in docs/benchmarks/METHODOLOGY.md.