Sviluppare o Acquistare un Parser di Documenti - Sei File che Hanno Bloccato il Nostro per Primi

Una volta, un TIFF in scala di grigi ha bloccato il nostro sistema di rilevamento del testo. Di per sé, il file non aveva niente di sbagliato. Memorizzava semplicemente 16 bit per pixel, e la maggior parte del codice per l'elaborazione delle immagini se ne aspetta 8.

Ogni parser in produzione accumula file come questo. Se stai valutando se sviluppare o acquistare un parser di documenti basato su un LLM, questo articolo ti offre un'anteprima di quella che sarà la tua futura coda di ticket di assistenza.

Punti Chiave

• Sviluppare un prototipo di parser di documenti basato su un LLM richiede solo un fine settimana. Tuttavia, renderlo capace di gestire i file reali dei clienti richiede anni di lavoro.
• La maggior parte dei guasti si verifica ancor prima che l'LLM veda il documento. I font mappano i caratteri in modo errato, i riquadri di pagina iniziano sotto lo zero, le scansioni usano pixel a 16 bit e le filigrane si mescolano al testo utile.
• Un modello più avanzato non corregge questi bug: cerca semplicemente di tirare a indovinare meglio partendo da un input che è già corrotto.
• La base di codice di Parseur contiene circa 150-300 correzioni dedicate esclusivamente a input anomali provenienti dal mondo reale, implementate in oltre 4.588 commit dal 2015 a oggi, e protette da 294 file di test.
• Ogni singola correzione è nata dal file di un cliente che ha generato un errore. Un team che decide di sviluppare il proprio parser scoprirà inevitabilmente gli stessi problemi, affrontandoli un ticket di assistenza alla volta.
• Scegli di sviluppare il tuo parser quando i documenti provengono da poche fonti note e mantengono formati fissi. Meglio acquistarlo, invece, quando ricevi file eterogenei da clienti e fornitori.

Perché il tuo parser del weekend si blocca al primo vero file del cliente

Un parser di documenti sviluppato nel weekend fallisce sui file reali perché la parte difficile non è l'IA, ma tutto ciò che trasforma il file originario in un formato leggibile dall'IA stessa. L'LLM riceve del testo o dei pixel. Se il font mente sulla propria codifica, se il riquadro della pagina è anomalo o se il formato dell'immagine è insolito, il modello legge spazzatura e ti restituisce comunque una risposta sicura di sé.

Il prototipo ha funzionato sui tuoi file di test perché questi ultimi erano semplici e ben formattati.

I veri file dei clienti, invece, sono complessi e insidiosi. Li affrontiamo e li correggiamo dal 2015. La nostra base di codice conta 4.588 commit e stimiamo che tra i 150 e i 300 di questi servano unicamente a correggere input anomali provenienti dal mondo reale. Ben 294 file di test assicurano che questi bug non si ripresentino, e molti di essi coincidono con l'esatto documento inviato da un cliente che ha causato il problema iniziale.

Ecco sei dei nostri casi limite preferiti.

Il PDF mostra il testo. Il livello di testo non è d'accordo.

Un PDF che mostra il testo in modo leggibile sullo schermo non sempre memorizza quello stesso testo in modo altrettanto chiaro. Tre file, in particolare, ce lo hanno dimostrato.

1. (cid:72) significa "e", se aggiungi 29

Alcuni PDF non memorizzano le lettere in sé, bensì il numero del disegno (glifo) di ciascuna lettera all'interno del font, un po' come il numero assegnato a un posto a sedere in un teatro. pdfminer, la libreria che usiamo per leggere il testo dai PDF, non può riconvertire quel numero in una lettera e restituisce quindi un codice come (cid:72).

Il trucco: molti di questi font elencano i propri glifi seguendo lo stesso ordine, ovvero l'ordine standard del Mac. In quell'elenco, lo spazio corrisponde al disegno numero 3. In ASCII, ovvero il sistema di codifica dei numeri che i computer usano per le lettere, lo spazio corrisponde al 32. Ogni lettera subisce un offset di un medesimo valore, 29. Aggiungi 29 a 72 e otterrai 101, il numero ASCII corrispondente alla lettera "e".

Senza questa correzione, il totale di una fattura viene letto come una riga di codici (cid:...). L'LLM si trova davanti a del puro rumore e si trova costretto a tirare a indovinare.

2. TToottaall

Alcuni strumenti PDF disegnano ogni carattere due volte nello stesso identico punto, probabilmente per simulare un font in grassetto. Sullo schermo l'effetto è perfetto, ma nel livello di testo la parola "Total" diventa "TToottaall".

La correzione rimuove qualsiasi carattere che si trovi nella stessa identica posizione di un altro. Sembra semplice, ma solo una volta che hai compreso il problema alla base.

3. Il font che mente sulla propria codifica

Lo standard PDF stabilisce che un font TrueType mappi i propri caratteri in UTF-16BE. Tuttavia, alcuni font in circolazione dichiarano esplicitamente di usare la codifica UTF-8 nella propria mappa dei caratteri. pdfminer crede ciecamente a questa informazione e, di conseguenza, legge spazzatura.

Abbiamo patchato pdfminer per ignorare tale dichiarazione e decodificare questi font nel modo in cui sono stati effettivamente scritti. Una libreria open source ti fornisce le basi; l'onere di applicarvi le patch necessarie spetta interamente a te.

Da dove inizia una pagina? Non sempre da zero

4. Una pagina A4 valida alta 0 pt

Il riquadro di una pagina PDF è definito da due angoli: inferiore sinistro e superiore destro. La maggior parte dei PDF inizia dal punto (0, 0), cosicché gli ultimi due valori numerici risultano essere direttamente la larghezza e l'altezza della pagina. Il codice programmato per leggere solo quei due numeri, perciò, funziona correttamente sulla stragrande maggioranza dei file.

Fino al giorno in cui è arrivato un PDF con un riquadro di pagina pari a [0, -841.89, 595.28, 0]. Si trattava di una normale pagina formato A4 che però iniziava sotto lo zero. A una lettura superficiale, risultava alta 0 pt. Il nostro controllo della risoluzione ha scartato d'istinto il documento come non valido. Eppure, qualsiasi visualizzatore di PDF lo apriva senza battere ciglio.

Immagini con più bit del previsto

5. La scansione a 16 bit

Ritorniamo al caso del TIFF menzionato nell'introduzione. I suoi pixel usavano 16 bit di grigio e la conversione precedente al rilevamento del testo tramite OCR andava regolarmente in crash. La correzione messa a punto converte l'immagine a 8 bit basandosi sul suo reale intervallo di valori. Questo dettaglio è fondamentale: alcuni scanner, infatti, scrivono dati a 12 bit all'interno di un file formattato a 16 bit, e una conversione semplicistica farebbe diventare l'intera scansione completamente nera.

Rumore che viene letto come testo

6. La filigrana DRAFT che si unisce alla frase

Anche una filigrana diagonale con la scritta "DRAFT" viene rilevata come testo. Le sue lettere finiscono in mezzo alle parole reali e il testo estratto può facilmente trasformarsi in "Total DR 1,250.00 AFT". Di fronte a questa stringa, il tuo LLM cercherà disperatamente di darle un senso logico.

La correzione elimina i caratteri leggermente ruotati: il testo reale, infatti, poggia dritto sulla riga, mentre una filigrana è inclinata.

Il vero costo dello sviluppo: i tuoi clienti diventano la tua suite di test

Ogni correzione che abbiamo elencato è partita dal file di un cliente che ha causato un errore, e nessuno di questi problemi può essere anticipato limitandosi a leggere le specifiche del formato PDF. Un team che sviluppa il proprio parser di documenti finirà inevitabilmente per scontrarsi con gli stessi file, scoprendoli un po' alla volta attraverso i propri ticket di assistenza.

Ognuno di essi segue inesorabilmente lo stesso ciclo: un utente confuso, l'invio di un file di esempio, ore spese nel debugging per trovare la causa radice, il rilascio di una correzione e l'aggiunta di un test affinché il problema non si ripresenti mai più. Ora moltiplica tutto questo per svariate centinaia di volte.

Un LLM non bypassa minimamente questo ciclo. Si limita a leggere ciò che la fase di estrazione gli passa. Quando l'estrazione è errata, il modello sbaglia con assoluta sicurezza e nessuno se ne accorge finché un importo finanziario non finisce nella colonna sbagliata. Il nostro articolo sugli LLM per l'elaborazione dei documenti approfondisce il lato modello di questa problematica, mentre il confronto dei costi tra sviluppare o acquistare un parser di documenti mette in cifre il lato ingegneristico relativo, ad esempio, all'elaborazione delle fatture.

Il prossimo modello non risolverà questo problema?

I modelli linguistici migliorano al ritmo di pochi mesi. Eppure, nessuna delle sei correzioni sopra descritte risulterebbe inutile. Un modello più intelligente che riceve un (cid:72) al posto di una "e", o un "DR 1,250.00 AFT" al posto di un importo totale, può solo fare una stima migliore. Il fornitore del tuo modello ti offre capacità di ragionamento superiori, ma non ti fornisce in alcun modo la pipeline di elaborazione dei PDF.

Quando sviluppare il proprio parser è la scelta giusta

Sviluppa il tuo parser personale quando i tuoi documenti provengono da pochissime fonti note e il loro formato non cambia mai nel tempo. Un'esportazione standardizzata dal tuo stesso sistema informatico è un ottimo esempio in tal senso. In questo scenario limitato, il prototipo sviluppato nel weekend potrebbe essere tutto ciò di cui avrai mai bisogno.

Nel valutare se sviluppare o acquistare un parser di documenti, la scelta migliore è acquistarlo quando i file provengono dall'esterno, ad esempio da clienti, fornitori e dai loro scanner. A quel punto, erediti in automatico ogni caso limite che queste fonti possono generare, e lo riceverai immancabilmente sotto forma di un nuovo ticket di assistenza.

Portaci il tuo file peggiore

Sì, vendiamo un parser di documenti, quindi tieni a mente questo aspetto leggendo il post. Resta il fatto che i sei file sopra descritti sono casi reali al 100%, così come reali sono stati i ticket di assistenza ad essi associati.

Abbiamo elaborato con successo oltre 100 milioni di documenti, e continuano a sorprenderci. Il prossimo file dal formato anomalo che atterrerà nella tua casella di posta ha altissime probabilità di essere uno di quelli che noi abbiamo già affrontato e risolto.

Quindi inviaci il file che ha bloccato il tuo ultimo strumento. Se dovesse bloccare anche Parseur, risolverlo sarà un nostro problema.

Ultimo aggiornamento il 12 novembre 2026