Quando i documenti si ribellano

Pagina 1: Riepilogo conto, due colonne. Pagina 15: Stesso conto, tre colonne, nomi delle intestazioni diversi. Pagina 47: Una scansione con una macchia di caffè. Pagina 89: La pagina dei totali, che fa riferimento a transazioni estratte 70 pagine fa.

Questo è un singolo "documento".

La tua pipeline di estrazione funziona a meraviglia su di esso. Pagina dopo pagina, ogni transazione finisce nella colonna giusta. Gli importi vengono analizzati in modo pulito. Le date sembrano corrette. Lo spedisci.

Poi chiama la contabilità. Crediti e debiti non tornano. Sono fuori di 3.200 €. Non perché una singola pagina fosse sbagliata, ma perché la pagina 12 usa le virgole per i decimali e la pagina 68 usa i punti. Il tuo parser ha gestito entrambi correttamente, isolatamente. Insieme, hanno prodotto due diverse interpretazioni di "1.234" e nessuno se n'è accorto finché l'equazione di bilancio non si è rotta.

L'estrazione della singola pagina può essere perfetta mentre il documento nel suo complesso è spazzatura.

Un documento, quindici personalità

I documenti lunghi non sono monolitici. Sono sezioni cucite insieme con layout diversi, qualità di scansione diverse e idee diverse su come dovrebbero apparire i numeri.

Un vero estratto conto bancario di 120 pagine che abbiamo elaborato aveva:

Cambi di layout: - Pagine 1-10: Verticale, tabella transazioni a due colonne - Pagine 11-50: Orizzontale, tre colonne con un saldo progressivo - Pagine 51-80: Di nuovo verticale, nomi delle intestazioni completamente diversi - Pagine 81-120: Pagine di riepilogo con totali aggregati

Variazione di qualità: - Pagine 1-40: PDF nativo, livello di testo pulito - Pagine 41-60: Scansionato a un certo punto, necessita di OCR - Pagine 61-80: Scansionato con annotazioni scritte a mano nei margini - Pagine 81-120: Di nuovo PDF nativo

Sorprese semantiche: - Tre conti separati raggruppati in un unico estratto conto - Sotto-estratti conto annidati all'interno dell'estratto conto principale - Totali a pagina 118 che fanno riferimento a una transazione a pagina 3

Qualsiasi sistema di estrazione che tratti questo come "un documento, un passaggio" avrà vita dura. Il layout a pagina 11 invalida le ipotesi di pagina 1. La qualità della scansione a pagina 45 richiede una strategia di estrazione completamente diversa rispetto al PDF pulito di pagina 5.

La domanda non è "abbiamo estratto correttamente ogni pagina?" È "abbiamo estratto l'intera cosa in modo coerente?"

Cosa succede quando non dividi

L'approccio ingenuo è quello di gettare l'intero documento in un unico passaggio di estrazione e sperare per il meglio. Ecco cosa succede realmente:

Le context window si riempiono. Anche i modelli di grandi dimensioni soffocano su 120 pagine di dati di transazione. Iniziano a perdere righe intorno alla pagina 40, silenziosamente. Nessun errore, nessun avviso. Solo transazioni mancanti che emergono solo quando qualcuno esegue la riconciliazione.

La confusione del layout si accumula. Il modello apprende il layout a due colonne dalle pagine 1-10, poi incontra tre colonne a pagina 11. A volte si adatta. A volte unisce due colonne e produce transazioni fantasma con descrizioni concatenate. A pagina 51, quando il layout cambia di nuovo, tutto è perduto.

Una pagina cattiva avvelena tutto. Quella scansione macchiata di caffè a pagina 47? In un'estrazione a passaggio singolo, un importo letto male ha un effetto a cascata. Il saldo progressivo si sposta, il modello "corregge" le transazioni successive per farle corrispondere, e ora hai dati dall'aspetto plausibile che sono sbagliati in modi che non puoi rilevare facilmente.

La soluzione è la segmentazione: dividere il documento in pezzi coerenti, estrarre ciascuno indipendentemente, quindi riassemblare con la convalida tra segmenti.

Ma il layout non è l'unica cosa che varia su 120 pagine. Anche la qualità fisica delle pagine reagisce.

Lo scanner vince sempre

I cambiamenti di layout sono almeno logici. Qualcuno ha progettato un formato a tre colonne per le pagine 11-50 e un formato a due colonne per il resto. Puoi ragionarci sopra.

La qualità della scansione è il caos.

Arriva un estratto conto di 120 pagine. Le pagine 1-40 sono PDF nativi: livello di testo pulito, coordinate perfette, estraibili fino al glifo. Poi arriva la pagina 41 e il livello di testo svanisce. Qualcuno ha stampato l'estratto conto, lo ha scansionato di nuovo e ha unito il risultato. Ora stai facendo OCR sui pixel invece di leggere testo da un documento strutturato.

Questo è il caso facile. Ecco cosa arriva effettivamente:

La foto col telefono. Qualcuno ha tenuto il telefono sopra l'estratto conto invece di usare uno scanner. Il flash della fotocamera cancella l'angolo in alto a destra, esattamente dove si trova il saldo di chiusura. L'immagine è nitida al centro e sfocata ai bordi. I punti luce sovraesposti creano macchie bianche che inghiottono le cifre. Rileviamo questo misurando i rapporti dei pixel sovraesposti e le macchie di luce speculare. Se più del 15% di una pagina è bruciato, stai guardando una foto, non una scansione.

La reliquia fax a 75 DPI. Un estratto conto che è passato attraverso un fax da qualche parte nella sua vita. La risoluzione è così bassa che un "8" e un "6" sono indistinguibili. Un "3" potrebbe essere un "8". La confidenza dell'OCR scende sotto il 50% e ora stai tirando a indovinare gli importi. A 75 DPI, la nitidezza dei bordi crolla. La magnitudine del gradiente Sobel che legge 15+ su una scansione pulita scende sotto 2,5. I singoli caratteri smettono di avere bordi.

La trasparenza dello sfondo. Un rullo usurato nell'alimentatore di documenti dello scanner lascia una striscia grigia su ogni pagina. O peggio: l'inchiostro della pagina precedente si è trasferito durante l'alimentazione, e ora la pagina 47 ha un testo fantasma della pagina 46 che traspare. L'OCR non sa quale livello di testo sia quello reale. Estrae entrambi e improvvisamente hai transazioni fantasma che non esistono.

La sezione ruotata. Le pagine 51-60 sono state scansionate in orizzontale ma i metadati del PDF dicono verticale. Il testo è di traverso. L'OCR a volte può gestire una rotazione di 90 gradi, ma 2-3 gradi di inclinazione da una pagina disallineata nell'alimentatore? Questo trasforma le linee rette della tabella in linee leggermente curve, e l'allineamento delle colonne, la cosa da cui dipende la tua logica di estrazione, diventa inaffidabile.

Il precipizio della qualità all'interno di un singolo documento:

Questo è il vero problema. Non è che alcuni documenti siano scansioni cattive. È che la pagina 40 è immacolata e la pagina 41 è terribile, nello stesso file. La tua pipeline deve gestire entrambi gli estremi e tutto ciò che sta nel mezzo, e deve sapere, per pagina, quanto fidarsi di ciò che ha estratto.

È qui che i modelli ML visivi si guadagnano da vivere. L'OCR tradizionale fissa i singoli caratteri e tira a indovinare. Un modello di visione vede l'intera pagina: la struttura della tabella, l'allineamento delle colonne, il contesto attorno a quella cifra macchiata di caffè. Può leggere "12.345,67 €" anche quando il punto decimale è oscurato, perché capisce come appare un estratto conto, non solo cosa decodificano i singoli glifi.

Il passaggio dall'OCR a livello di testo alla comprensione visiva a livello di pagina è ciò che rende sopravvivibili le scansioni degradate. Una reliquia fax che sconfigge il riconoscimento dei caratteri ha ancora una struttura visibile: righe, colonne, importi in posizioni prevedibili. Un modello di visione che ha visto migliaia di estratti conto può estrarre dal pattern anche quando i pixel sono grezzi.

Il campo minato dell'equazione di bilancio

Per gli estratti conto bancari, c'è un'equazione spietata: start_balance + credits - debits = end_balance.

Quattro parole. Infiniti modi per romperle.

Riferimenti tra pagine. Il saldo di apertura è a pagina 1. Il saldo di chiusura è a pagina 120. L'equazione abbraccia ogni segmento, ogni esecuzione, ogni cambio di layout nel mezzo. Se qualsiasi segmento viene estratto in modo errato, l'equazione si rompe. Ma quale? Con 7 segmenti e 4.000 transazioni, trovare i dati errati è un problema a sé stante.

Transazioni a cavallo di pagina. Una descrizione della transazione si estende sulle pagine 47-48: - Pagina 47: "BONIFICO A ACME CORP" - Pagina 48: "RIF: 12345 - PAGAMENTO FATTURA"

Una transazione o due? Contala due volte e il saldo si rompe esattamente per l'importo di una transazione. Il tipo di errore che sembra plausibile finché qualcuno non fa un audit. La soluzione è la sovrapposizione: quando dividiamo il documento in segmenti, le pagine di confine sono condivise tra esecuzioni adiacenti. Entrambe le esecuzioni vedono la transazione, ma l'aggregatore deduplica in base alle coordinate della pagina durante il riassemblaggio. Sopravvive solo una copia.

Roulette delle impostazioni locali (locale). Stessa banca, stesso estratto conto: - Segmento 1: 1.234,56 € (virgola decimale) - Segmento 2: 1,234.56 € (punto decimale)

Analizza entrambi "correttamente" secondo la loro convenzione locale e ottieni due numeri diversi. All'equazione di bilancio non importano le convenzioni. Vede solo che la somma è sbagliata.

Caos delle convenzioni sui segni. Banca A: i debiti sono negativi. Banca B: tutti gli importi positivi, con una colonna D/A separata. Banca C: debiti tra parentesi, (1.234,56). L'equazione presuppone segni coerenti. Se l'estrazione non normalizza prima di sommare, i crediti annullano i debiti e l'estratto conto sembra vuoto.

La trappola della tolleranza di 0,02 €. Un estratto conto di 120 pagine potrebbe avere migliaia di transazioni, ciascuna analizzata dal testo renderizzato e portando con sé il rischio di arrotondamento a livello di fonte. Richiedere una corrispondenza esatta rifiuta documenti validi. Troppa tolleranza nasconde errori reali. 0,02 € è ciò su cui siamo atterrati dopo aver eseguito dati di produzione. Abbastanza stretto da rilevare errori, abbastanza largo da sopravvivere all'arrotondamento.

Rigoroso, poi intelligente, poi disperato

Quando stavamo costruendo la pipeline di convalida di Holofin, abbiamo provato a eseguire tutte le correzioni contemporaneamente. Mascherava problemi di qualità dei dati. Documenti che avrebbero dovuto essere segnalati passavano indisturbati. Quindi l'abbiamo ricostruita in tre fasi. L'ordine è il design.

Fase 1: Rigorosa. Ogni transazione deve avere una data di valuta. Ogni importo deve essere analizzato. L'equazione di bilancio deve reggere entro la tolleranza. Se la fase rigorosa passa, i dati sono di alta qualità e abbiamo finito. La maggior parte dei documenti puliti si ferma qui.

Se la fase rigorosa fallisce, annotiamo cosa è fallito e andiamo avanti.

Fase 2: Normalizzazione. I dati sono stati estratti in modo pulito, ma le convenzioni si scontrano tra i segmenti. Separatori decimali misti: virgole nel segmento 1, punti nel segmento 3. Date ambigue: 01/02/2024 potrebbe essere il 2 gennaio o il 1° febbraio a seconda della localizzazione della banca. Convenzioni sui segni che si invertono tra i segmenti. La normalizzazione unifica questi aspetti prima di rieseguire il controllo del saldo.

Fase 3: Revisione umana. Quando l'automazione non riesce a risolverlo, il documento viene segnalato a un operatore. Non "qualcosa non va, buona fortuna", ma "segmento 4, pagine 41-60, i crediti sono superiori di 3,20 € rispetto al previsto. Inizia da lì."

Perché questo ordine è importante: il rigoroso per primo preserva la qualità dei dati. Normalizziamo solo quando il rigoroso fallisce. Coinvolgiamo un essere umano solo quando la normalizzazione non è sufficiente.

Eseguire tutto contemporaneamente maschererebbe i problemi. Un documento che necessitava di revisione umana dovrebbe essere trattato diversamente da uno che ha superato la fase rigorosa. L'ordine è il segnale di qualità.

Quando la maggior parte del documento va bene

Hai segmentato il mostro di 120 pagine. Ogni segmento estratto indipendentemente. Punteggi di qualità allegati per pagina. E adesso?

I segmenti devono tornare ad essere un unico documento. Saldo di apertura dal primo segmento, saldo di chiusura dall'ultimo, ogni credito e debito sommato attraverso tutti loro. Poi l'equazione di bilancio viene eseguita un'ultima volta, non per segmento, ma sull'intera cosa.

Quando passa, hai finito. Quando fallisce, la domanda interessante è dove.

È qui che la maggior parte delle pipeline prende la decisione sbagliata. Il saldo è fuori di 3,20 €, quindi l'intero documento viene rifiutato. L'operatore ricarica, riestrae, riconvalida, tutte le 120 pagine, perché un segmento ha inciampato.

Questa è la risposta sbagliata. In produzione, la maggior parte dei documenti è per lo più corretta.

Diciamo che il segmento 4 su 7 ha la discrepanza. Gli altri sei segmenti sono puliti, convalidati, riconciliati, esportabili. Non li buttiamo via. Segnaliamo il segmento 4, evidenziamo la mancata corrispondenza e lasciamo che l'operatore risolva il conflitto con il PDF sorgente fianco a fianco. Il buon lavoro rimane buono. Il segmento cattivo riceve attenzione umana.

La fonte: una vera scansione di estratto conto con cambi di qualità a metà documento

L'estrazione: i bounding box tracciano ogni valore alla sua fonte, anche su pagine degradate

L'operatore vede esattamente cosa deve essere corretto. Non "il tuo documento è fallito", ma "segmento 4, pagine 41-60, i crediti sono superiori di 3,20 € rispetto al previsto e la pagina 47 aveva una bassa confidenza OCR (34%). Inizia da lì."

Questa è la differenza tra una pipeline che elabora documenti e una che rispetta il tempo dell'operatore.

I principi che sopravvivono alla produzione

Se stai costruendo qualcosa di simile, queste sono le lezioni che sono rimaste:

• Segmenta prima di estrarre. Tratta i cambiamenti di layout come confini, non come rumore.
• Misura prima di fidarti. I punteggi di qualità per pagina ti dicono dove l'estrazione è fragile.
• Convalida tra segmenti, non solo all'interno. Una pagina può essere corretta mentre il documento è sbagliato.
• Degrada con grazia, in ordine. Convalida rigorosa prima. Normalizzazione poi. Revisione umana per ultima. L'ordine codifica la qualità.
• Registra tutto ciò che l'utente non ha chiesto. Le correzioni di sistema sono invisibili nell'interfaccia utente e visibili nell'audit trail.

Gli estratti conto bancari sono lo stress test, migliaia di transazioni, layout multipli, qualità di scansione che cambia a metà documento e un'equazione di bilancio che richiede perfezione su tutto questo. Se la tua pipeline sopravvive a questo, le fatture a pagina singola sono un errore di arrotondamento.

L'estrazione è risolta a pagina 1. La coerenza è risolta a pagina 120. E lo spazio tra loro, i cambi di layout, le macchie di caffè, le reliquie fax, le convenzioni sui segni, è dove le pipeline ingenue vanno a morire e l'ingegneria attenta si guadagna da vivere.

Costruisci per il mostro di 120 pagine fin dal primo giorno. Quelli a pagina singola si prenderanno cura di se stessi.