Benchmark di precisione

Risultati ricavati da artefatti di valutazione approvati. Le date indicate sono le date di misurazione.

Aggiornamento motore OCR: PP-OCRv5 → PP-OCRv6

Misurato il 2026-07-09 su una GPU RTX 3090 locale con l'immagine di produzione (paddleocr==3.7.0, CUDA 12.9). Oggetti: un documento fotografato reale in HEIC da 24 MP (testo polacco, riferimento trascritto da una persona) e i PDF di esempio di fatture/ricevute del repository (riferimento pdftotext). La valutazione usa richiamo e precisione di multinsieme indipendenti dall'ordine.

La configurazione distribuita è PP-OCRv6 medium con text_det_box_thresh=0.5. La soglia più bassa per i riquadri recupera linee deboli nelle aree con riflessi o prospettiva delle foto (+20 punti di richiamo delle parole), senza regressioni sulle pagine pulite sottoposte a rendering.

Metrica	PP-OCRv5 (precedente)	PP-OCRv6 medium + box_thresh 0.5 (attuale)
Richiamo parole (foto fotocamera)	0.670	0.865 (+29 %)
Richiamo diacritici polacchi (foto fotocamera)	0.562	0.775 (+38 %)
Precisione parole (foto fotocamera)	0.986	0.955
Richiamo numerico (foto fotocamera)	0.000	0.000
Richiamo numerico (ricevuta)	0.818	1.000 (+22 %)
Fattura stampata densa (richiamo/precisione parole)	1.000 / 1.000	1.000 / 1.000
Latenza GPU a caldo (RTX 3090, pagina densa)	~0.55 s	~1.13 s

Il richiamo delle parole sulle pagine stampate sottoposte a rendering (PDF di fatture e ricevute) è 1,000 in entrambe le versioni del motore: il miglioramento è concentrato sulle foto, in cui prospettiva, riflessi e compressione mettono alla prova il rilevatore. Il richiamo numerico (importi, date, identificatori) è l'indicatore più vicino all'accuratezza dell'estrazione dei campi, poiché i campi vengono associati a questi token.

Motore fotografico: pre-elaborazione documenti fotocamera

Misurato il 2026-07-09 (stesso hardware e immagine del benchmark del motore OCR). Il motore fotografico applica il raddrizzamento geometrico e la classificazione dell'orientamento ai caricamenti dalla fotocamera prima dell'OCR. Si è scelto di abilitarlo solo per i caricamenti IMAGE: il raddrizzamento applicato a pagine già piane e sottoposte a rendering causa una regressione del richiamo delle parole da 1,000 a 0,635, distorcendo i pixel allineati.

Metrica	Senza pre-elaborazione (riferimento)	Con raddrizzamento (caricamenti fotocamera)
Richiamo parole (foto fotocamera)	0.865	0.921 (+6.6 %)
Richiamo diacritici polacchi (foto fotocamera)	0.775	0.854 (+10.2 %)
Precisione parole (foto fotocamera)	0.955	0.961
Richiamo parole. Pagina densa stampata	1.000	0.635 (regressione. Solo per foto per design)

Il miglioramento dovuto al raddrizzamento è reale, ma richiede che il servizio OCR restituisca l'immagine della pagina trasformata, affinché i riquadri delimitatori siano disegnati nello spazio di coordinate corretto, cioè trasformato. La limitazione alle sole foto evita la regressione sulle pagine dense. La funzionalità è controllata dalla variabile d'ambiente OCR_PHOTO_TRANSFORMS_ENABLED.

Rilevamento suddivisione PDF multi-fattura

Misurato il 2026-07-21 con il set di valutazione sintetico etichettato generato da scripts/gen_split_eval.py e valutato da scripts/eval_doc_split.py. Il rilevatore usa il livello di testo incorporato (pdftotext) per individuare segnali di confine tra pagine, quali intestazioni delle fatture, schemi di etichette di data e parole chiave del tipo di documento, prima di qualsiasi chiamata OCR o LLM; pertanto il rilevamento dei confini non comporta costi.

Condizione	Precisione dei confini	Richiamo dei confini	F1	Documenti valutati
Testo pulito (senza rumore OCR)	1.000	1.000	1.000	660
Rumore OCR a livello di caratteri: 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.

Note metodologiche

Tutti i numeri provengono da artefatti di valutazione versionati nel repository (docs/ocr-calibration/*.json, docs/OCR_IMAGE_CALIBRATION.md). I risultati del rilevamento della suddivisione si trovano in docs/ocr-calibration/split_detection_results.json. Nessun numero è stimato o estrapolato.
La valutazione OCR usa richiamo e precisione di multinsieme indipendenti dall'ordine: la metrica conta se ogni token di parola di riferimento appare nell'output OCR, ossia il richiamo, e se ogni token dell'output OCR appare nel riferimento, ossia la precisione, senza penalizzare le differenze nell'ordine di lettura. È un indicatore migliore dell'accuratezza dell'estrazione dei campi rispetto alle metriche di somiglianza delle sequenze, sensibili ai cambiamenti nella segmentazione delle righe che non incidono sul contenuto dei token.
Il riferimento per la foto scattata con la fotocamera è una trascrizione umana del documento di prova (docs/IMG_2375.HEIC). Il riferimento per la pagina stampata è ricavato da pdftotext, lo stesso strumento usato nel percorso rapido per i PDF digitali.
Precisione e richiamo del rilevamento della suddivisione misurano le corrispondenze esatte dell'indice di pagina su PDF multi-fattura generati sinteticamente con confini noti. Il set di valutazione copre vari tipi di fattura, formati di data e nomi di fornitori.
Le nuove esecuzioni dei benchmark dopo qualsiasi modifica del motore possono essere attivate con gli script in scripts/. I risultati aggiornati vengono salvati in dev-artifacts/, ignorato da Git, e vengono sottoposti a commit dopo la revisione.

Domande sulla metodologia o sui risultati: [email protected]

Non ancora misurato

Due numeri che un acquirente chiederà sono volutamente assenti da questa pagina, perché nessuna valutazione li supporta:

Accuratezza dell'estrazione a livello di campo (precisione, recall, F1 o corrispondenza esatta per campo, come numero di fattura, totale o partita IVA). I numeri OCR sopra misurano se le parole vengono lette, non se il valore giusto finisce nel campo giusto. Un set di valutazione annotato è in preparazione; finché non esiste, nessuna percentuale viene pubblicata.
Latenza end-to-end (p50 e p95 dal caricamento al risultato). I tempi per fase sono registrati come metriche, ma nessuna baseline è stata pubblicata.

Dove DocSolved notoriamente rende meno: foto di pagine lucide o curve (recall delle parole 0,865 contro 1,000 su una pagina stampata pulita), i numeri sulla stessa foto (richiamo numerico 0,000, invariato rispetto al motore precedente, mentre una soglia di rilevamento che non distribuiamo raggiunge 1,000), diacritici polacchi nelle foto (0,775) e raddrizzamento applicato a una pagina già piatta (0,635, motivo per cui agisce solo sulle foto da fotocamera). Questi casi si possono verificare invece di darli per buoni: in un documento scansionato un campo estratto porta l'ancoraggio che l'abbinamento è riuscito a stabilire — il testo di origine abbinato, uno stato di corrispondenza e una posizione nella pagina quando il valore è ancorato — e può portare un punteggio di affidabilità. I campi delle fatture elettroniche strutturate non passano affatto dall'OCR; provengono dai dati di origine e non hanno bisogno di questi segnali.

Numeri leggibili dalla macchina: docs/benchmarks/results.json nel repository, derivati dagli artefatti versionati, e la metodologia in docs/benchmarks/METHODOLOGY.md.