Con modelli che leggono la struttura del documento — tabelle, righe spezzate, intestazioni — invece di riconoscere solo i caratteri. L'accuratezza si misura su documenti veri prima di andare in produzione, e i casi che il modello non chiude finiscono a una persona con il documento aperto.
Quasi tutte le aziende che ci chiamano per il ciclo passivo hanno già provato a leggere i documenti in automatico. Spesso hanno anche già comprato qualcosa. La frase con cui iniziano è sempre la stessa: «l'OCR ce l'abbiamo, ma i documenti li controlliamo lo stesso».
Non è un problema di prodotto scadente. È che l'OCR classico risolve un problema diverso da quello che hanno.
Cosa fa un OCR tradizionale e dove si ferma?
Un OCR riconosce caratteri: guarda dei pixel e dice che quella forma è una "3". È un lavoro che sa fare benissimo da vent'anni, e si ferma esattamente un passo prima di quello che serve — capire cosa significa quel numero dentro il documento.
Quello che serve a un ufficio acquisti è un'altra cosa: capire che quel documento è un DDT, che ha una tabella, che ogni riga della tabella è un articolo, e che il numero in fondo a destra su quella riga è la quantità consegnata — non il prezzo, non il numero di colli, non il progressivo di riga.
I sistemi tradizionali colmano la distanza con le maschere: si dice al software che su quel modulo, per quel fornitore, la quantità sta in un certo rettangolo. Funziona, finché il documento sta nel rettangolo.
Quali documenti mandano in crisi l'OCR?
Quattro casi, e sono la normalità di un ufficio acquisti: il documento fotografato, i venti fornitori con venti moduli, la tabella spezzata su più pagine e il campo letto bene ma attribuito male.
Il documento fotografato. Il DDT arriva in magazzino, il magazziniere lo fotografa col telefono sotto il portico. Storto, con l'ombra della mano su due righe e il riflesso della pellicola sopra il totale. Nessuna maschera regge una foto: le coordinate non esistono più.
Venti fornitori, venti layout. Ogni fornitore ha il suo modulo, e in un'azienda manifatturiera i fornitori sono decine. Ogni layout è una maschera da disegnare e da mantenere. Il conto si ribalta prima di arrivare a metà anagrafica: si spende più a configurare che a digitare.
La tabella che si spezza. Un ordine da quaranta righe arriva su tre pagine. La tabella riparte a pagina due senza intestazione, e a pagina tre ci sono in mezzo le condizioni di trasporto. Un lettore che ragiona per rettangoli vede tre tabelle diverse — o una sola con dentro del testo che non c'entra.
Il campo letto bene e attribuito male. È il caso peggiore perché non sembra un errore. L'OCR legge "340" correttamente e lo mette nel campo quantità: peccato che su quel modulo 340 fossero i chili, e i pezzi fossero 12. Il dato è giusto, il significato no, e a valle il riscontro a tre vie salta senza che si capisca perché.
Cos'è l'OCR intelligente?
È un modello che interpreta il documento invece di riconoscerne i caratteri. La differenza è tutta qui: guarda la struttura, non le coordinate. Riconosce che c'è una tabella perché ne capisce la forma, che quella colonna è una quantità perché ne capisce il ruolo nel documento, e che la riga a pagina due è la continuazione di quella a pagina uno.
È il motivo per cui abbiamo costruito DoqEngine, il motore che usiamo per questa parte: non riconosce caratteri, interpreta layout complessi, tabelle e grafici e trasforma una scansione in dati con un significato. Su Co.Mas è quello che ha reso possibile il resto — oltre 12.000 documenti l'anno prelevati da Adiuto, letti e riconsegnati al flusso come dati confrontabili.
La conseguenza pratica che interessa a chi paga: un fornitore nuovo, o un fornitore che cambia modulo, di solito non richiede nessun lavoro di configurazione. È il costo che con le maschere non finiva mai.
Come si misura l'accuratezza prima di usarlo?
Su un campione di documenti veri dell'azienda, campo per campo, confrontando quello che estrae il sistema con quello che legge una persona sugli stessi documenti. È la parte che chi vende estrazione dati salta volentieri, e che invece decide se il progetto funziona.
Non si misura "l'accuratezza del sistema": si misura campo per campo, su documenti veri dell'azienda. Numero documento, data, partita IVA fornitore, codice articolo, quantità, prezzo unitario, totale riga. Sono sette campi con sette accuratezze diverse, e la media fra loro non vuol dire niente — un sistema al 96% che sbaglia sistematicamente la quantità è inutile, uno all'88% che sbaglia solo la data di consegna è già in produzione.
Il metodo è noioso e non ha alternative: si prende un campione di documenti reali, si estrae, e si confronta con quello che una persona ha letto sugli stessi documenti. Da lì escono due numeri per campo — quante volte il sistema risponde, e quante volte risponde giusto — e si decide quali campi vanno in automatico e quali restano in verifica umana. Si parte da pochi campi sicuri e si allarga con lo storico, non il contrario.
Cosa succede ai documenti che il sistema non riesce a leggere?
Finiscono a una persona, con scritto cosa manca e su quale riga. Nessun sistema chiude il 100%, e uno che dichiara di farlo sta nascondendo qualcosa in una coda che nessuno guarda.
Il valore sta nella forma dell'eccezione. «Documento non elaborato» non serve a niente. «Riga 7: quantità illeggibile, il resto del documento è a posto» è una cosa che una persona chiude in venti secondi guardando l'originale — e quel documento contribuisce comunque a tutte le altre sei righe.
La regola che seguiamo è che un'eccezione deve dire cosa manca e su quale riga, e deve avere un posto e un nome. Se la coda non ha un responsabile, dopo tre mesi qualcuno la svuota di corsa e siamo tornati al punto di partenza — con in più una licenza da pagare.
Quando non conviene?
Quando i documenti sono già dati: se il ciclo è tutto su fattura elettronica e ordini fatti a sistema, non c'è niente da leggere e il problema è un altro.
Quando il volume è basso e i fornitori sono pochi: con sei fornitori che mandano sempre lo stesso formato, il tempo di lettura a mano è già poco e il margine è sottile.
Quando i documenti non vengono archiviati. Se il DDT resta nel raccoglitore in magazzino o su WhatsApp, il primo problema da risolvere non è leggerlo: è averlo.
Le domande che tornano
Domande frequenti
- Abbiamo già un OCR nel documentale. Non basta quello?
- Basta finché i documenti sono strutturati e sempre uguali: una fattura elettronica non ha bisogno di essere letta, è già dati. Il punto in cui l'OCR del documentale si ferma è il documento di trasporto scansionato, dove non serve riconoscere i caratteri ma capire che quella tabella ha una riga per articolo e che la colonna a destra è la quantità. Se oggi qualcuno ricontrolla a mano quello che l'OCR ha estratto, l'OCR non sta facendo il lavoro: lo sta spostando.
- Quanto deve essere accurato per andare in produzione?
- La domanda giusta non è la percentuale, è cosa succede all'errore. Un campo sbagliato che finisce in una coda di eccezioni costa trenta secondi; un campo sbagliato che entra in una registrazione costa una fattura pagata male. Noi misuriamo su un campione di documenti veri dell'azienda, campo per campo, e mandiamo in produzione solo i campi che stanno sopra la soglia — gli altri restano in verifica umana finché non ci arrivano anche loro.
- I documenti escono dall'azienda?
- È una scelta che si fa prima e si mette per iscritto, non una conseguenza di quale servizio era più comodo da chiamare. L'estrazione può girare su macchine vostre quando i documenti sono sensibili o quando il cliente lo chiede; in altri casi il cloud costa molto meno e non tocca niente di riservato. Quello che non facciamo è deciderlo dopo.
- Cosa succede quando un fornitore cambia il modulo?
- Con l'OCR a maschere si rompe tutto e qualcuno se ne accorge dalle anomalie in coda. Con un modello che legge la struttura del documento invece delle coordinate, un layout nuovo di solito passa senza che nessuno tocchi niente — ed è il motivo principale per cui abbiamo smesso di usare le maschere.
