Benchmarki dokładności

Aktualizacja silnika OCR: PP-OCRv5 → PP-OCRv6

Pomiar wykonano 2026-07-09 na lokalnym GPU RTX 3090 z obrazem produkcyjnym (paddleocr==3.7.0, CUDA 12.9). Badano rzeczywisty 24 MP dokument HEIC z aparatu (tekst polski, ręcznie sporządzona wartość referencyjna) oraz przykładowe PDF-y faktury i paragonu z repozytorium (wartość referencyjna z pdftotext). Ocena wykorzystuje niewrażliwą na kolejność kompletność i precyzję wielozbiorów.

Wdrożona konfiguracja to PP-OCRv6 medium z text_det_box_thresh=0.5. Niższy próg pól odzyskuje słabo widoczne wiersze z obszarów odblasków i perspektywy na zdjęciach z aparatu (+20 pkt proc. kompletności słów), bez regresji na czystych renderowanych stronach.

Kompletność słów na drukowanych renderowanych stronach (PDF-y faktur i paragonów) wynosi 1.000 dla obu wersji silnika. Poprawa dotyczy zdjęć z aparatu, gdzie perspektywa, odblaski i kompresja obciążają detektor. Kompletność liczb (kwot, dat i identyfikatorów) jest najbliższym wskaźnikiem dokładności ekstrakcji pól, ponieważ pola są dopasowywane na podstawie tych tokenów.

Silnik fotograficzny: wstępne przetwarzanie dokumentów z kamery

Pomiar wykonano 2026-07-09 (na tym samym sprzęcie i obrazie co test silnika OCR). Silnik zdjęć stosuje geometryczne prostowanie i klasyfikację orientacji przesłań z aparatu przed OCR. Został włączony wyłącznie dla przesłań IMAGE, ponieważ prostowanie zastosowane do już płaskich renderowanych stron powoduje regresję kompletności słów z 1.000 do 0.635 przez zniekształcenie wyrównanych pikseli.

Korzyść z prostowania jest rzeczywista, ale wymaga zwrócenia przez usługę OCR przekształconego obrazu strony, aby pola ograniczające były rysowane we właściwej, przekształconej przestrzeni współrzędnych. Ograniczenie do zdjęć zapobiega regresji dla gęstych stron. Funkcja jest kontrolowana przez zmienną środowiskową OCR_PHOTO_TRANSFORMS_ENABLED.

Wykrywanie podziału PDF z wieloma fakturami

Pomiar wykonano 2026-07-21 przy użyciu syntetycznego oznakowanego zbioru oceny wygenerowanego przez scripts/gen_split_eval.py i ocenionego przez scripts/eval_doc_split.py. Detektor używa osadzonej warstwy tekstowej (pdftotext) do wyszukiwania sygnałów granic stron (nagłówków faktur, wzorców etykiet dat i słów kluczowych typu dokumentu) przed wywołaniem OCR lub LLM, więc wykrywanie granic jest bezpłatne.

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.

Uwagi metodologiczne

• Wszystkie liczby pochodzą z zatwierdzonych artefaktów oceny w repozytorium (docs/ocr-calibration/*.json, docs/OCR_IMAGE_CALIBRATION.md). Wyniki wykrywania podziału znajdują się w docs/ocr-calibration/split_detection_results.json. Żadne liczby nie są szacowane ani ekstrapolowane.
• Ocena OCR wykorzystuje niewrażliwą na kolejność kompletność i precyzję wielozbiorów: metryka sprawdza, czy każdy token słowa z wartości referencyjnej występuje w wyniku OCR (kompletność) oraz czy każdy token wyniku OCR występuje w wartości referencyjnej (precyzja), bez karania za różnice w kolejności odczytu. To lepszy wskaźnik dokładności ekstrakcji pól niż metryki podobieństwa sekwencji, które są wrażliwe na zmiany segmentacji wierszy niewpływające na zawartość tokenów.
• Wartość referencyjna dla zdjęcia z aparatu to ręczna transkrypcja dokumentu testowego (docs/IMG_2375.HEIC). Wartość referencyjna dla drukowanej strony pochodzi z pdftotext, tego samego narzędzia używanego w szybkiej ścieżce cyfrowych PDF-ów.
• Precyzja i kompletność wykrywania podziału mierzą dokładne dopasowania indeksów stron w syntetycznie wygenerowanych PDF-ach z wieloma fakturami o znanych granicach. Zbiór oceny obejmuje różne typy faktur, formaty dat i nazwy dostawców.
• Ponowne uruchomienie benchmarków po każdej zmianie silnika można wywołać skryptami w scripts/. Nowe wyniki trafiają do dev-artifacts/ (ignorowanego przez git) i są zatwierdzane po weryfikacji.

Pytania dotyczące metodologii lub wyników: [email protected]

Jeszcze niezmierzone

Dwóch liczb, o które zapyta kupujący, celowo nie ma na tej stronie, bo nie stoi za nimi żadna ewaluacja:

• Dokładność ekstrakcji na poziomie pól (precyzja, czułość, F1 lub dokładne dopasowanie dla pól takich jak numer faktury, suma czy NIP). Powyższe liczby OCR mierzą, czy słowa są odczytywane, a nie czy właściwa wartość trafia do właściwego pola. Oznaczony zbiór ewaluacyjny jest w przygotowaniu; dopóki nie powstanie, nie publikujemy żadnego procentu.
• Opóźnienie od początku do końca (p50 i p95 od przesłania do wyniku). Czasy poszczególnych etapów są rejestrowane jako metryki, ale nie opublikowano żadnej wartości bazowej.

Gdzie DocSolved radzi sobie gorzej, o czym wiemy: zdjęcia błyszczących lub wygiętych stron (czułość słów 0,865 wobec 1,000 na czystym wydruku), liczby na tym samym zdjęciu (kompletność liczb 0,000, bez zmian względem poprzedniego silnika, podczas gdy nieudostępniany przez nas próg detekcji osiąga tam 1,000), polskie znaki diakrytyczne na zdjęciach (0,775) oraz prostowanie zdjęcia zastosowane do już płaskiej strony (0,635, dlatego działa tylko na zdjęciach z aparatu). Takie przypadki można sprawdzić, zamiast im ufać: w zeskanowanym dokumencie wyodrębnione pole niesie zakotwiczenie, które udało się ustalić dopasowaniu — dopasowany tekst źródłowy, status dopasowania oraz położenie na stronie, gdy wartość da się zakotwiczyć — i może nieść ocenę pewności. Pola ze strukturalnych e-faktur w ogóle nie przechodzą przez OCR; pochodzą z danych źródłowych i nie potrzebują tych sygnałów.

Liczby w formie maszynowej: docs/benchmarks/results.json w repozytorium, wyprowadzone z zapisanych artefaktów, oraz metodologia w docs/benchmarks/METHODOLOGY.md.