Il tuo LLM non è una pipeline documentale

C'è un momento in ogni progetto AI in cui la demo sembra così buona che il tuo cervello inizia silenziosamente a cancellare codice. Guardi un modello "leggere" un estratto conto e pensi: ci siamo. Possiamo saltare l'OCR. Possiamo saltare il parsing del layout. Forse possiamo saltare metà della pipeline. Nella versione cinematografica, qualcuno preme Invio e una cascata di JSON scende dal cloud.

Nella realtà, la cascata è un gocciolamento. E qualcuno deve comunque portare il mocio.

Scriviamo questo basandoci sulle cicatrici accumulate cercando di far eseguire a LLM e VLM l'estrazione end-to-end su PDF finanziari. Non documenti di tre pagine curati con una crenatura perfetta, ma i PDF poco affascinanti che arrivano in produzione: 120 pagine, layout multipli e qualche scansione nel mezzo, con una macchia di caffè che funge da utile filigrana intorno a pagina 42.

Se vuoi subito la conclusione: i modelli sono ottimi assistenti all'interno di una pipeline documentale. Ma sono pessime pipeline.

Il primo successo

Il mio primo successo è stato quasi cinematografico. Ho mostrato a un modello vision-language una pagina pulita. "Dammi data, commerciante, importo, saldo." Ha obbedito, educatamente, in JSON. I confini della tabella sembravano giusti. I segni decimali erano corretti. Ho scritto un messaggio su Slack al team che iniziava con "E se…"

Questa è la parte in cui la telecamera stacca su un montaggio di me che provo "E se…" su un estratto conto reale.

Stessa banca, template diverso. Totali rinominati da "Questo periodo" a "Subtotale". Addebiti stampati come positivi. Un'interruzione di pagina che taglia a metà la descrizione di una riga. Uno slogan nell'intestazione che il modello decide essere l'ultima riga di una transazione. Una scansione con griglie grigio chiaro che svaniscono quel tanto che basta per confondere il rilevamento delle righe. Righe perse, contenuto alterato, ripetizioni.

L'essere utile è il problema. L'essere utile non è verificabile.

Ecco un esempio concreto di dove i VLM inciampano anche con l'affermazione di Mistral AI di avere il "miglior modello OCR al mondo".

Confrontando i due, la colonna Credito scompare e diversi valori finiscono nelle colonne sbagliate, un classico fallimento della struttura tabellare.

Al contrario, i modelli di Holofin sono addestrati specificamente per la struttura delle tabelle finanziarie. Su queste pagine, che sono nella fascia bassa della scala di complessità, recuperano l'intero schema e correggono le assegnazioni delle celle con perfetta accuratezza. Se vuoi sostituire l'inserimento manuale dei dati, ottenere la struttura corretta nella fase di OCR non è negoziabile.

I modi silenziosi in cui un modello può sbagliare

Ciò che ci innervosisce non sono gli errori evidenti. Quelli sono facili da intercettare. Ciò che ci innervosisce sono quelli plausibili.

Puoi guardare l'output di un modello e sentire che va tutto bene. I numeri sono formattati. I campi sono presenti. Il JSON è valido. Solo più tardi noti che un "Totale" apparentemente ragionevole è una cifra da inizio anno, o che un saldo di apertura è stato letto come una transazione, o che una riga andata a capo ha unito due commercianti in una chimera che non è mai esistita. Nessuno ha lanciato un errore; il sistema ha continuato imperterrito.

Pensavamo che questo fosse un problema di accuratezza. Non lo è (o non solo). È un problema di calibrazione. L'accuratezza è "Quanto siamo vicini?". La calibrazione è "Quanto dovremmo fidarci di questo?". I modelli sembrano accurati nelle demo. Le pipeline hanno bisogno di calibrazione in produzione.

Come abbiamo visto, ci sono post di blog e test pubblici che lo confermano. Alcuni VLM commercializzati come "capaci di OCR" possono effettivamente leggere tabelle ordinate su pagine ordinate, ma inciampano esattamente nel tipo di disordine che abbiamo appena descritto. Qualità della scansione, drift del layout, segno degli importi: i tipi di variazioni che sono routine nel mondo reale trasformano estrazioni sicure in finzione sicura. Non serve malizia per avere allucinazioni; basta la pagina 57.

Il costo che nessuno cita nella demo

C'è anche il conto.

Prendi un esempio conservativo: un estratto conto di 120 pagine. Anche se lo dividi in chunk di due pagine per richiesta, stai inviando ~60 prompt. Aggiungerai istruzioni, forse alcuni esempi per stabilizzare gli output. Se stai usando un VLM, ogni pagina è un embedding dell'immagine oltre ai token. Moltiplica per 60. Moltiplica per i nuovi tentativi. Moltiplica per un secondo passaggio quando ti rendi conto di aver bisogno di verifica. La latenza sale da "scattante" a "prepararsi un tè". Il costo sale da centesimi a euro.

Ordine di grandezza, non una promessa: elaborare un file di oltre 100 pagine con un singolo grande VLM può finire nel quartiere dei "diversi euro per documento", e minuti di tempo reale.

Puoi, ovviamente, ridimensionare tutto questo, ma nota cosa implica. Gli stessi trucchi che lo rendono accessibile (modelli più piccoli, meno chiamate, prompt più stretti) di solito derivano dal fare meno con il modello e più con il codice. Il che ci porta alla parte noiosa e inevitabile.

E il conto si gonfia silenziosamente quando aggiungi "k-LLM" o ingegnosità Agentic. Instradi le pagine strane a un secondo modello, campioni due volte per essere più sicuro, aggiungi un passaggio di verifica, forse prima fai una didascalia e poi estrai: ogni rete di sicurezza è un altro viaggio di andata e ritorno e un altro tassametro che corre. Quello che sembrava una chiamata diventa un piccolo comitato, e il costo si gonfia.

La pipeline che finisci per costruire comunque

A un certo punto abbiamo smesso di chiedere "Un modello può leggere questo?" e abbiamo iniziato a chiedere "Se il modello legge questo, possiamo provarlo?"

La prova non è sexy. Significa che mantieni le coordinate per ogni token. Significa che puoi mostrare a un regolatore il riquadro di pixel a pagina 83 che è diventato "€-1.237,45". Significa che riconcili i saldi di apertura e chiusura tra le pagine, e vai nel panico se la somma dei delta non corrisponde. Significa che noti quando due totali diversi vivono sulla stessa pagina e non sono d'accordo sull'essere totali.

Puoi fare tutto questo con i modelli. Ma una volta che hai scritto abbastanza impalcatura per essere sicuro (la ridondanza OCR, la geometria, i parser rigorosi, la riconciliazione) accade una cosa strana: il modello non è più l'eroe. È lo specialista che chiami per le dispute e i casi limite.

Questa è una buona cosa.

Dove il modello brilla davvero

Ci piacciono ancora questi modelli. Ci piacciono solo nell'ambito giusto.

Se due passaggi deterministici non sono d'accordo sulla convenzione del segno 'Debito/Credito' — ad esempio, importi stampati come positivi con una colonna D/C separata, chiedi al modello di arbitrare e spiegare la sua scelta. Se un'intestazione è cambiata silenziosamente da 'Frais' a 'Frais de tenue de compte' o 'Commissions d’intervention', chiedi al modello di mapparla al tuo schema canonico. Se c'è una nota a piè di pagina come 'dont TVA 20 %' o una sezione 'CB différé' che sposta il momento in cui vengono applicati gli importi, chiedi al modello di segnalarlo prima di classificare erroneamente un lotto di transazioni.

In altre parole: tratta il modello come un giudice o un traduttore. Non chiedergli di essere lo scanner, il parser e il contabile.

Ma i modelli non stanno migliorando?

Assolutamente. Ci piacerebbe avere torto tra sei mesi. Contesti più ampi riducono il dolore del chunking. Le backbone di visione continuano a migliorare. Il tool-use e il multi-pass aiutano moltissimo.

Anche allora, le parti che ci interessano per i documenti finanziari non scompaiono: provenienza, riconciliazione, rilevamento del drift e la capacità di spiegare qualsiasi numero a qualcuno a cui non importano i tuoi prompt. Modelli migliori rendono le decisioni di giudizio più pulite. Non ci assolvono dall'offrire ricevute.

Se il tuo caso d'uso è "estrarre totali da pagine singole patinate", forse la scatola nera va bene. Se il tuo caso d'uso è "ingerire 120 pagine di estratti conto di qualità mista da 17 banche, rispettare uno SLA e superare un audit", vorrai comunque i guardrail. Vorrai anche che il conto sia prevedibile.

La checklist invisibile che ci portiamo dietro

Non stampiamo più una checklist; la cerchiamo a tastoni come le chiavi in tasca. Possiamo elaborare un estratto conto di 120 pagine senza andare in timeout? Conserviamo la provenienza di pagina e coordinate per ogni valore estratto? Se sommiamo le transazioni, otteniamo il delta del saldo o abbiamo un buco da qualche parte? Cosa succede quando un modello si blocca a pagina 87: continuiamo o nascondiamo il glitch in una busta JSON ordinata? Potremmo eseguire questo con i modelli spenti e ottenere comunque qualcosa di utilizzabile? Noteremo quando una banca spedisce silenziosamente il "Template v7" e sposta una colonna, o il sistema accetterà educatamente la nuova realtà e archivierà sciocchezze sotto i nomi di campo corretti?

Queste non sono domande di deep learning. Sono domande di software. Il che è confortante, onestamente.

Se devi scegliere una battaglia, scegline una piccola

La cosa che riduce costantemente i costi e aumenta la fiducia è la disciplina dello scopo. Chiedi al modello di scegliere tra candidati, non di inventare la struttura. Chiedi un indice, non un paragrafo. Raggruppa insieme le celle ambigue in modo che 20 decisioni costino un viaggio di andata e ritorno. Metti tutto in cache se puoi: se hai visto un template, impara le sue stranezze una volta e riutilizza quella conoscenza. E quando il modello perde, assicurati che perda in un modo che un umano possa correggere con un clic.

Fai questo e otterrai la magia dove conta: negli angoli strani dove le regole diventano fragili. Salta questo passaggio e otterrai un modo molto costoso per sbagliare con sicurezza.

LLM e VLM rimangono la parte più deliziosa dello stack, purché non siano l'intero stack. Il lavoro non è eliminare le parti noiose. Il lavoro è costruire cose noiose affinché la magia abbia qualcosa di solido su cui poggiare.

In Holofin, ci appoggiamo a quella disciplina: costruire prima l'impalcatura affidabile — provenienza, riconciliazioni, controlli di drift, poi invitare i modelli ad arbitrare dove le regole si confondono. Mantiene i fallimenti locali e rumorosi, rende i costi prevedibili e lascia che la magia faccia la sua parte senza portare l'intero carico.

Aggiornamento dicembre 2025: Mistral OCR 3

Abbiamo rivisitato questo argomento nel dicembre 2025 quando Mistral ha rilasciato mistral-ocr-3. Nonostante la nuova versione e le continue affermazioni di una migliore comprensione dei documenti, abbiamo osservato gli stessi problemi spaziali sulle tabelle: colonne che si uniscono, valori che finiscono nelle celle sbagliate e la colonna Credito che scompare sugli stessi campioni di estratto conto bancario. La sfida fondamentale del recupero della struttura tabellare rimane irrisolta dai VLM general-purpose.