Il Parsing di Documenti con AI Spiegato: Da PDF a Dati Strutturati

Cos'è il document parsing?

Il document parsing è il processo di estrazione di informazioni strutturate da documenti non strutturati o semi-strutturati. Un documento PDF di una fattura contiene le stesse informazioni di un record nel database — fornitore, importo, data — ma in un formato pensato per la lettura umana, non per i sistemi informatici.

Il parser ha il compito di fare da ponte: riceve il documento in forma grezza e restituisce un oggetto dati strutturato (JSON, XML, CSV) che il sistema informatico può elaborare automaticamente.

Input vs Output

Input (documento grezzo)

Fattura PDF con testo, loghi, tabelle, timbri, firma digitale, 3 pagine

Output (dati strutturati)

{"fornitore": "Rossi S.r.l.",
 "piva": "IT01234567890",
 "numero": "FT-2026-0042",
 "data": "2026-03-10",
 "totale": 1830.00,
 "iva": 330.00}

Approcci tradizionali al document parsing

Prima dell'AI moderna, il document parsing veniva fatto con approcci che funzionavano bene in condizioni controllate ma erano fragili nella realtà:

Regex e regole di posizione

Il parser cerca pattern come "Totale: [0-9]+,[0-9]{2}" nel testo estratto dall'OCR. Funziona solo se il layout è fisso. Non appena cambia un carattere nel template, la regex non matcha più.

Template matching

Per ogni fornitore si definisce un template con le coordinate esatte dei campi. Estrae il testo in quelle coordinate. Richiede un template per ogni layout diverso. Con 100 fornitori → 100 template da mantenere.

Form recognizer ML

Modelli ML addestrati su dataset di documenti specifici (es. solo fatture italiane). Migliore generalizzazione rispetto a regex, ma richiede training su molti esempi annotati. Difficile da adattare a nuovi tipi documento.

Il parsing con Vision Language Model

I VLM moderni hanno rivoluzionato il document parsing eliminando il bisogno di template o training specifico per ogni tipo di documento.

Il processo:

Il documento viene convertito in immagine (o già è un'immagine)
L'immagine viene codificata come sequenza di token visivi
Il modello riceve: immagine + prompt che descrive cosa estrarre
Il modello produce un JSON con i campi richiesti
Il sistema valida il JSON e lo schema

Il prompt esempio per una fattura:

Sei un assistente specializzato nell'estrazione di dati da fatture italiane.
Analizza l'immagine e estrai i seguenti campi in formato JSON:
- fornitore: ragione sociale del fornitore
- piva_fornitore: partita IVA del fornitore (11 cifre)
- numero_fattura: numero del documento
- data_fattura: data di emissione (formato YYYY-MM-DD)
- imponibile: importo imponibile totale (numero decimale)
- iva: importo IVA totale (numero decimale)
- totale: importo totale della fattura (numero decimale)
- scadenza: data di scadenza del pagamento (formato YYYY-MM-DD)

Rispondi SOLO con il JSON, senza testo aggiuntivo.

Campi estraibili per tipo documento italiano

Documento	Campi principali estraibili
Fattura di acquisto	Fornitore, P.IVA, numero, data, scadenza, imponibile, IVA (22%/10%/4%), totale, IBAN, righe dettaglio
DDT	Mittente, destinatario, numero DDT, data, vettore, righe articoli (codice, descrizione, q.tà, UM, peso), causale
Ordine d'acquisto	Acquirente, fornitore, numero ordine, data, condizioni, righe (articolo, q.tà, prezzo, IVA), totale
Nota di credito	Come fattura + riferimento fattura originale, causale della rettifica
Contratto	Parti (nome, CF/P.IVA), oggetto, valore, durata, data inizio/fine, rinnovo, penali, recesso
Nota spese	Dipendente, data, categoria (trasferta/vitto/alloggio/altro), importo, IVA, fornitore, riferimento progetto

Le sfide specifiche dei documenti italiani

Layout altamente variabile

Ogni software gestionale produce fatture con layout completamente diverso. Non esiste uno standard grafico. Zucchetti, TeamSystem, Fatture in Cloud, Excel, Word — ognuno produce un layout unico. Il VLM deve capire la struttura semantica indipendentemente dal layout.

Aliquote IVA multiple

Una singola fattura può avere righe con aliquote IVA diverse (22%, 10%, 4%, 0% esente). Il parser deve estrarre l'imponibile e l'IVA per ogni aliquota, non solo il totale generale.

Formati di importo ambigui

In Italia il separatore decimale è la virgola (es. "1.234,56"). Alcuni sistemi usano il punto (es. "1,234.56"). Il parser deve gestire entrambi i formati. Errori comuni: "1.234" interpretato come 1234 invece di 1.234.

Scansioni di documenti cartacei

Molte PMI ancora ricevono fatture cartacee da alcuni fornitori. Le scansioni hanno qualità variabile, possono essere storte, con rumore di fondo, timbri sopra al testo. Il preprocessing è fondamentale.

Benchmark accuratezza per tipo documento

Tipo documento	Qualità	Qwen 7B	Qwen 72B
Fattura PDF nativa	Alta	96%	98%
Fattura scansionata	Alta	93%	96%
Fattura scansionata	Bassa	82%	87%
DDT con tabelle	Alta	91%	94%
Contratto multi-pagina	Alta	88%	92%
Nota spese con scontrini	Mista	79%	85%

* Accuratezza misurata come % di campi estratti correttamente (exact match) su dataset di 500 documenti italiani reali. Hardware: RTX 4090, Ollama, temperatura 0.

JSON Schema enforcement: garantire output strutturato

Un problema comune con i VLM è che a volte producono output non valido: JSON malformato, campi mancanti, o valori nel formato sbagliato. Per garantire un output strutturato e affidabile:

Schema validation: Ogni output viene validato contro un JSON Schema. Campi obbligatori mancanti → il documento va in revisione.
Retry con prompt raffinato: Se il JSON non è valido, il sistema fa una seconda chiamata all'AI con un prompt più specifico sul campo problematico.
Valori null espliciti: Se un campo non è presente nel documento, l'AI deve restituire null (non una stringa vuota, non omettere il campo).
Type coercion: Gli importi vengono sempre convertiti in float, le date in formato ISO 8601, i booleani in true/false.