Baidu Unlimited-OCR: un documento lungo in un solo passaggio, on-premise

Il nucleo è un'attenzione modificata nel decoder, che mantiene costante la memoria. I modelli OCR classici basati su Transformer lasciano crescere la cosiddetta KV cache con la lunghezza del documento. Più lungo è il PDF, più memoria serve, finché a un certo punto non entra più in un'unica elaborazione.

Unlimited-OCR sostituisce questa parte con la Reference Sliding Window Attention (R-SWA). In questo modo la KV cache resta costante, indipendentemente dalla lunghezza del documento. È esattamente questo il senso del termine one-shot long-horizon parsing: un documento lungo viene letto in un solo passaggio, invece di essere scomposto in sezioni per poi riassemblare i risultati.

Degno di nota è il percorso di addestramento. Il team non è partito da zero, ma ha continuato l'addestramento a partire dal checkpoint di DeepSeek-OCR: con l'encoder congelato e solo il decoder adattato in circa 4.000 passaggi. Il modello si colloca così in linea diretta con DeepSeek-OCR, che abbiamo già inquadrato nel contesto dello stack. Codice e pesi sono disponibili apertamente su GitHub.

Il vero problema con i documenti lunghi non è la singola pagina, ma la coerenza tra le pagine. Se un modello taglia un documento di 60 pagine in blocchi da dieci pagine, si perde esattamente ciò che conta nella quotidianità B2B: una tabella che prosegue oltre il salto di pagina, una clausola che si riferisce a una sezione precedente, una voce il cui riferimento si trova venti pagine prima.

Una KV cache costante permette di mantenere l'intero documento in un unico contesto. La memoria non cresce con la lunghezza, quindi la struttura resta intatta su tutte le pagine. Di riflesso il processo diventa anche più veloce: Baidu indica, in modalità base, 5.580 token al secondo contro 4.951 di DeepSeek-OCR, e con un limite di output di 6.000 token il divario è di circa il 35 per cento.

Quanto all'accuratezza, Unlimited-OCR raggiunge su OmniDocBench v1.5 93,23 punti, 6,22 in più rispetto alla base DeepSeek-OCR, e su v1.6 93,92 punti. Questi sono i numeri del paper. Sui vostri documenti conta alla fine come il modello gestisce le vostre tabelle, timbri e moduli, non la media di un set di test pubblico. Un fenomeno correlato è quello degli LLM subquadratici, che rendono il contesto lungo più economico on-premise.

Il valore si genera dove documenti lunghi e strutturati devono diventare dati puliti e ricercabili. Alcuni esempi concreti:

• Contratti e accordi quadro. Rimandi incrociati e allegati restano leggibili nel loro contesto, invece di frammentarsi ai confini dei blocchi.
• Manuali tecnici e norme. Documenti lunghi con figure, tabelle e sezioni numerate in un solo passaggio.
• Fatture e ricevute di più pagine. Un testo estratto in modo pulito è il presupposto per l'elaborazione strutturata successiva, ad esempio verso la fattura elettronica.
• Archivi e pratiche. Fondi documentali finora disponibili solo come scansione diventano leggibili dalla macchina, senza doverli affidare a un servizio cloud.

In quasi tutti i casi l'OCR non è l'obiettivo, ma il primo passo. Un testo analizzato in modo pulito è la base per una base di conoscenza con RAG: quanto migliore è il parsing, tanto meglio la ricerca troverà in seguito il punto giusto.

Non ogni compito documentale richiede il riconoscimento classico del testo, ed è una valutazione onesta da fare. Esiste ormai un intero filone che non converte affatto i documenti in testo, ma li interroga come immagini, con modelli come ColPali o ColQwen. Abbiamo descritto a parte questo approccio senza OCR.

La regola pratica che si è dimostrata valida per noi:

• Vi servono i caratteri effettivi (importi di fattura, clausole contrattuali, estrazione strutturata, trasferimento a un altro sistema): allora l'OCR è quasi indispensabile, e un modello come Unlimited-OCR è qui particolarmente valido.
• Vi serve il punto giusto, non il testo completo (rispondere a una domanda su un archivio ampio, ritrovare un'immagine): allora la ricerca visiva nei documenti può essere la via più diretta.

Spesso valgono entrambe le cose insieme. Unlimited-OCR rende la parte OCR di questo stack più economica e più affidabile sui documenti lunghi.

Un buon valore di benchmark è un motivo per testare il modello, non un motivo per metterlo in produzione. Prima di inserire Unlimited-OCR in un processo cliente, verificherei quattro cose:

🔸 Documenti tedeschi e scrittura a mano. I numeri del benchmark dicono poco sui moduli tedeschi, sugli atti vecchi o sulle annotazioni manoscritte. Questo va verificato su un set di test proprio, fatto di documenti reali.

🔸 Tabelle e layout. Nei documenti B2B è la fedeltà di tabelle e colonne a determinare l'utilità. Qui vale la pena il confronto diretto con lo stack attuale.

🔸 Hardware ed esercizio. 3B come MoE con circa 500M di parametri attivi è realistico on-premise. Cosa questo significhi concretamente in termini di memoria GPU e throughput va misurato prima del rollout, non stimato.

🔸 Licenza e provenienza. La licenza MIT consente l'uso commerciale on-premise senza note a piè di pagina. Il fatto che la traccia del modello porti a uno degli autori di DeepSeek-OCR è un segnale di qualità, ma non sostituisce la verifica propria.

Ciò che trovo davvero interessante in questa pubblicazione non è tanto il modello in sé quanto la direzione: documenti lunghi in un solo passaggio, abbastanza piccoli per il proprio data center, con una licenza che non limita nessuno. È esattamente lì che l'elaborazione documentale nelle PMI sta diventando concreta. Quale dei vostri documenti fareste elaborare per primo?