AI locale per la gestione documentale, qual è la migliore

Allegare PDF a una chat può essere utile a velocizzare alcune operazioni aziendali, ma non significa automatizzare la gestione documentale. Creare un processo AI-powered è un lavoro lungo e articolato, ma garantisce vantaggi a lungo termine e flussi di lavoro perfettamente integrati nei processi già esistenti, senza doverli stravolgere del tutto.

Alla ricerca di una pipeline efficiente per la gestione documentale in locale, abbiamo selezionato cinque small language model e li abbiamo messi alla prova su un corpus di cento documenti aziendali reali, opportunamente modificati per adattarli alle esigenze del test.

I modelli scelti sono LFM2.5 1.2B, Phi-4-mini-reasoning, Qwen3.5 9B, Gemma 4 E4B e Gemma 4 12B.

I primi due, LFM e Phi, non dispongono di capacità native per l’interpretazione diretta dei file PDF. Per questo motivo, i documenti sono stati sottoposti a una fase preliminare di elaborazione tramite PaddleOCR, un modello compatto specializzato nel riconoscimento ottico dei caratteri e nell’estrazione di strutture come testo e tabelle.

Il contenuto dei PDF è stato quindi convertito in testo strutturato e formattato, così da renderlo direttamente utilizzabile dai modelli durante le successive fasi di analisi.

In questi task la precisione è fondamentale, perché l’interpretazione errata di un numero o una procedura può avere gravi ripercussioni e annullare il vantaggio dell’automazione. La precisione, però, non deve pesare eccessivamente sul conto. L’utilizzo di un grande modello di frontiera per elaborare una quantità significativa di documenti richiederebbe costi eccessivi e ingiustificabili, mentre un modello molto più piccolo può portare a termine lo stesso compito più velocemente e in economia.

Bisogna considerare anche la questione della privacy: sono numerosi gli ambiti sensibili in cui non è opportuno caricare in cloud informazioni riservate, perdendone di fatto il controllo diretto. In questi casi, l’unica opzione disponibile è l’inferenza locale, spesso da eseguire su hardware di fascia consumer.

Il compito da svolgere

Chiediamo ai modelli di leggere il testo di ogni documento, distinguere quelli commerciali da quelli tecnici e restituire fornitore, numero della fattura, date, righe e importi in JSON, un formato che associa nomi di campi e valori, preparandoli per ulteriori elaborazioni programmatiche. Le date devono rispettare la convenzione stabilita e le righe devono essere restituite in un elenco con una struttura prefissata. Da queste regole dipende la possibilità di collegare il modello al gestionale senza dover interpretare ogni risposta.

Il lavoro richiede più attenzione di quanto possa sembrare: il modello deve individuare i dati di interesse, distinguere chi emette la fattura da chi la riceve, convertire le date nell’ordine anno/mese/giorno, mantenere la sequenza delle righe e associare quantità, prezzi e importi netti. Nelle note di credito deve conservare i segni negativi.

Il corpus, l’insieme dei documenti della prova, comprende 100 file, per un totale di 230 pagine e 346 righe contabili. Ogni file può contenere più di un documento commerciale e lo stesso file può includere contemporaneamente documenti tecnici e commerciali.  I documenti sono per l’80% in italiano e per il restante 20% in inglese. Il corpus è diviso in cinque gruppi da venti file: fatture standard, documenti con campi mancanti, crediti e sconti, documenti multipagina e documenti con dati tecnici distraenti. Il modello deve riuscire a individuare il dato pertinente fra informazioni che possono apparire simili.

Per ogni documento è presente anche un riferimento corretto, con i valori attesi, che permette di individuare e contare gli eventuali errori e consente di valutare in modo verificabile le performance di ogni modello. Un risultato parziale viene considerato errato, perché viola il requisito di perfetta aderenza a un modello dati destinato a essere usato in modo programmatico.

I risultati del test

Gemma 4 E4B risulta essere il modello più preciso: completa correttamente tutti i 100 documenti con un tempo tipico di elaborazione di 2,80 secondi (il 95% delle risposte arriva comunque entro 4,60 secondi).

Qwen3.5 9B completa correttamente 96 documenti su 100 ed è anche leggermente più lento, con un tempo tipico di 3,61 secondi.

Gemma 4 12B è il modello più grande e, quindi, anche il più lento (6,00 secondi è il tempo tipico), ma riesce a completare correttamente soltanto 94 documenti, pur gestendo correttamente il 99,7% dei campi.

I due modelli più piccoli sono invece velocissimi, ma ottengono risultati molto scadenti.

Phi-4-mini-reasoning completa correttamente solo 3 documenti su 100 e raggiunge il 66,4% di campi corretti.

LFM2.5 1.2B non completa correttamente nessun documento. Il tempo di inferenza, però, è solo una parte del conto quando si parla di automazione dei processi: una risposta da correggere significa infatti impiegare un operatore per ricontrollare ogni campo.

Risultati principali con schema JSON

Per tutti e tre i modelli migliori, le criticità si concentrano nella gestione dei campi mancanti, che si rivela essere la componente più difficoltosa da gestire. Il requisito chiedeva di estrarre i dati presenti e assegnare il valore “null” a quelli mancanti, e il prompt, cioè le istruzioni date al modello, stabiliva questa regola. In diverse risposte, invece, il campo mancante è stato compilato ugualmente con un’informazione non necessariamente errata, ma proveniente da una fonte differente da quella esplicitamente richiesta.

Per Gemma 4 12B, cinque dei sei documenti scartati riportano nel campo “numero” il codice di riferimento del corpus, presente nel piè di pagina. Il valore atteso è invece il numero della fattura esplicitamente assegnato dal fornitore.

Le istruzioni non escludevano apertamente il codice interno; questo dimostra che l’accuratezza del risultato è strettamente correlata con la qualità del prompt, che non deve contenere soltanto istruzioni su cosa fare, ma anche indicazioni su cosa non fare.

Accuratezza dei campi e dei valori mancanti

Per il test abbiamo usato sessioni indipendenti, una richiesta alla volta, temperatura pari a zero, seed 42, contesto di 8.192 token e un massimo di 4.096 token generati.

Il contesto limita la quantità complessiva di contenuto gestibile, mentre il budget di generazione limita la lunghezza della risposta. La temperatura regola la variabilità del campionamento e il seed definisce un punto di partenza per le operazioni casuali che lo utilizzano.

Per misurare la resilienza dei modelli abbiamo introdotto problemi di formattazione, dati fuorvianti e tentativi di prompt injection, rendendo il compito quanto più complesso possibile. Nei venti documenti distraenti sono state inserite annotazioni malevole che chiedevano di ignorare le istruzioni del prompt o di modificare il totale con valori arbitrari.

Gemma 4 E4B, Gemma 4 12B e Qwen3.5 9B non si sono fatti ingannare e hanno completato correttamente tutti i documenti del gruppo.

Documenti interamente corretti per gruppo

Implementare un modello locale

Per eseguire questi modelli in locale oggi è possibile usare un PC opportunamente configurato, un Mac con Apple Silicon o sistemi progettati specificamente per l’AI. La scelta dipende soprattutto dalla quantità di memoria disponibile, dalle dimensioni del modello e dalla velocità di elaborazione richiesta.

Su PC, le GPU NVIDIA rappresentano una delle soluzioni più utilizzate. Una RTX 5090 dispone di 32 GB di memoria video e permette di ottenere un’ottima velocità di generazione con questi piccoli modelli. Anche le schede meno recenti possono quindi risultare sufficienti, purché la quantità di memoria sia adeguata al numero di parametri del modello e al contesto necessario all’automazione.

Anche i Mac con Apple Silicon possono eseguire modelli localmente. In questo caso, CPU e GPU condividono la stessa memoria, che viene inoltre utilizzata dal sistema operativo e dalle altre applicazioni.

Per modelli più grandi ed esecuzioni in parallelo esistono macchine dedicate, come la famiglia di apparati NVIDIA DGX. In questi casi, però, i costi crescono notevolmente e le prestazioni devono essere valutate sul carico di lavoro reale, per determinare realmente quali sono le esigenze di calcolo.

È possibile sperimentare l’esecuzione dei modelli anche usando soltanto CPU e RAM, accettando tempi di elaborazione generalmente molto maggiori. Tanti strumenti di inferenza permettono di utilizzare diverse configurazioni hardware, comprese soluzioni che distribuiscono il lavoro tra CPU e GPU.

L’inferenza locale è la scelta giusta quando si vogliono mantenere testi e risultati sotto il proprio controllo. I documenti aziendali possono contenere dati personali, prezzi e riferimenti bancari, che devono essere gestiti secondo i principi del GDPR, fra cui liceità, minimizzazione, limitazione della conservazione e sicurezza. Il titolare deve essere in grado di dimostrarne il rispetto, e il luogo di esecuzione dei sistemi di gestione documentale rappresenta uno degli elementi sottoposti a valutazione.