Se hai mai provato a estrarre dati strutturati da una polizza di carico utilizzando un servizio OCR generico, conosci già il risultato: non funziona. Almeno non affidabilmente. E nella conformità del commercio internazionale, «non affidabilmente» equivale a «per nulla».
In Atlas Verify elaboriamo migliaia di documenti commerciali: polizze di carico, certificati biologici, certificati fitosanitari, certificati di origine, fatture commerciali, liste di imballaggio e decine di altri. All'inizio abbiamo valutato tutte le principali piattaforme OCR sul mercato. Hanno fallito tutte lo stesso test: fornendo un documento su cui non erano state specificamente addestrate, il risultato va da incompleto a pericolosamente errato.
Questo articolo spiega perché abbiamo costruito un processo personalizzato di elaborazione documentale, cosa rende i documenti commerciali particolarmente difficili e quali principi ingegneristici guidano il nostro approccio.
Il problema della varietà documentale
La maggior parte dei servizi OCR è ottimizzata per una serie limitata di documenti. Google Document AI eccelle con fatture e ricevute. AWS Textract gestisce bene i moduli strutturati. Azure Form Recognizer può essere addestrato su modelli personalizzati. Ma il commercio internazionale genera una varietà impressionante di documentazione.
Nel solo nostro sistema gestiamo oltre 35 tipi distinti di documenti. Una polizza di carico non assomiglia a un certificato biologico. Un certificato fitosanitario USDA condivide pochissima struttura con uno emesso dall'UE. Un avviso di arrivo di una compagnia può essere un PDF strutturato con tabelle ordinate; quello di un'altra, un fax scansionato con annotazioni a mano.
L'intuizione fondamentale è che ogni tipo di documento ha il proprio schema, un insieme specifico di campi rilevanti per la verifica della conformità. Una polizza di carico richiede speditore, destinatario, parte da notificare, numeri dei container, nome della nave, porti di carico e scarico e descrizioni delle merci. Un certificato biologico richiede agente certificatore, nome dell'attività, ID NOP, prodotti certificati e date di validità.
Gli strumenti OCR generici non comprendono questi schemi. Estraggono testo. Possono individuare tabelle. Ma non sanno che la stringa «MEDU4107760» è un numero di container o che «NOP ID: 7880315519» è un identificatore critico da verificare nella USDA Organic Integrity Database. Senza conoscenza degli schemi, l'OCR è soltanto una conversione testuale costosa.
Perché «abbastanza buono» è pericoloso
Nella maggior parte delle applicazioni software, un'accuratezza del 95% è eccellente. Nella conformità commerciale è un rischio.
Considera un numero di container. Il formato standard (ISO 6346) è composto da quattro lettere seguite da sette cifre, con l'ultima come cifra di controllo. Se l'OCR legge male un solo carattere, uno «0» diventa una «O», un «8» una «B», il numero non è valido. I sistemi a valle che tentano di tracciare quel container non restituiranno risultati e la catena di verifica si interromperà silenziosamente.
Lo stesso principio vale per ID NOP, codici HS, numeri IMO e date di certificazione. Un errore di un solo carattere può cambiare interamente il significato. Un codice HS 0901.11 (caffè non torrefatto, non decaffeinato) rispetto a 0901.12 (caffè non torrefatto, decaffeinato) attiva aliquote tariffarie, requisiti normativi e profili di rischio diversi.
La nostra architettura
Il nostro processo di elaborazione documentale ha tre fasi, ciascuna progettata per massimizzare l'accuratezza nelle specifiche sfide della documentazione commerciale.
Fase 1: Classificazione del documento — Prima di estrarre qualsiasi dato, identifichiamo il tipo di documento. La classificazione determina lo schema di estrazione da applicare, i campi da cercare e come convalidare i risultati.
Fase 2: Estrazione basata su schemi — Con il documento classificato, applichiamo un modello di estrazione specifico che sa esattamente quali campi cercare e dove compaiono tipicamente in quel tipo di documento. È profondamente diverso dall'OCR generico, che estrae tutto e lascia l'interpretazione all'utente.
Fase 3: Convalida incrociata — I dati estratti vengono confrontati automaticamente con fonti esterne. I numeri dei container vengono convalidati nelle API delle compagnie di navigazione. Gli ID NOP vengono controllati nella USDA Organic Integrity Database. I codici portuali vengono verificati nel World Port Index. Questa fase rileva sia errori OCR sia dati fraudolenti.
Lezioni apprese
Dopo aver elaborato decine di migliaia di documenti commerciali, sono emersi diversi principi:
1. La specializzazione di settore supera l'approccio generico. Ogni tentativo di utilizzare un servizio OCR generico richiedeva tanta elaborazione successiva che dedicavamo più tempo ingegneristico a correggerne il risultato di quanto avremmo impiegato per costruire una soluzione personalizzata.
2. La classificazione è la base. Sbagliare il tipo di documento si ripercuote su ogni passaggio successivo. Investiamo molto nell'accuratezza della classificazione perché tutto ciò che segue dipende da essa.
3. La convalida è più importante dell'estrazione. Estrarre un numero di container è utile. Confermare che sia un container reale su una nave reale nel porto corretto è ciò che conta davvero per la conformità.
4. I risultati strutturati consentono l'automazione. L'obiettivo non è digitalizzare documenti per la lettura umana. È produrre dati strutturati leggibili dalle macchine che alimentino direttamente processi automatici di verifica.
Costruire un processo affidabile di elaborazione documentale per il commercio internazionale è davvero difficile. I documenti sono diversi, i requisiti di accuratezza estremi e le conseguenze degli errori significative. Ma è anche fondamentale: ogni capacità di verifica che sviluppiamo dipende dalla lettura e comprensione accurate dei documenti che accompagnano le merci lungo le filiere globali.