olmOCR di Allen AI: estrarre PDF per LLM senza perdere struttura e provenienza
olmOCR è un progetto open source per convertire PDF complessi in testo strutturato. Cosa risolve, perché OCR non basta e come controllare i risultati prima di usarli in RAG.
Scritto da Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Un PDF leggibile da un umano può essere pessimo per una pipeline AI
olmOCR è un progetto di Allen AI dedicato alla conversione di PDF in contenuto utilizzabile da modelli linguistici. Il problema non è soltanto riconoscere caratteri. Un PDF può mescolare colonne, note, tabelle, figure, intestazioni ripetute e ordine di lettura ambiguo. Se il testo estratto mette insieme elementi lontani della pagina, un sistema RAG riceve un documento apparentemente completo ma semanticamente deformato.
Questo conta perché la qualità del retrieval comincia prima degli embedding. Un assistente non può citare correttamente una procedura se il passaggio rilevante è stato spezzato, se una tabella è diventata una sequenza senza relazione fra righe e colonne o se una nota a piè pagina è finita nel corpo del testo. Il modello generativo può rendere la risposta convincente, ma non può riparare in modo affidabile una struttura persa a monte.
Il repository presenta olmOCR come strumento orientato a PDF difficili e a output pensato per dati LLM. Questo non significa che ogni documento vada convertito nello stesso modo. Una scansione storica, un bilancio con tabelle dense e un manuale tecnico hanno errori e requisiti diversi. La scelta della pipeline deve partire dal tipo di decisione che quel testo dovrà supportare.
Che cosa va preservato oltre alle parole
Un’estrazione utile conserva almeno ordine di lettura, titoli, paragrafi, riferimenti alle pagine, relazioni tabellari e collegamento con il file di origine. Per documenti regolati sono importanti anche data, versione, autore e permessi. Senza provenienza, correggere un errore o rispondere a una contestazione diventa molto più difficile.
Le tabelle meritano un test dedicato. Il testo OCR può riconoscere perfettamente tutti i numeri e tuttavia associare un valore alla colonna sbagliata. In un report finanziario o in un protocollo medico, questo errore è più grave di un carattere mancante. Le immagini con didascalie e i diagrammi pongono un problema analogo: il contenuto visuale non deve essere inventato dal modello durante l’indicizzazione.
| Controllo | Perché conta | Esempio di errore |
|---|---|---|
| Ordine | Mantiene il ragionamento del documento | Colonne lette una riga alternata all’altra |
| Tabelle | Preserva relazioni fra dati | Valore corretto nella colonna errata |
| Pagine | Permette citazioni verificabili | Risposta senza punto di controllo |
| Intestazioni | Riduce rumore nei chunk | Titolo ripetuto trattato come contenuto |
| Versione | Evita fonti obsolete | Procedura superata recuperata come attuale |
Un controllo qualità prima del RAG
La verifica non dovrebbe iniziare con una domanda al chatbot. Prima si seleziona un campione di pagine difficili: doppie colonne, tabelle, elenchi, note, scansioni inclinate e pagine con grafica. Per ogni pagina si confrontano PDF e output, registrando errori di testo, struttura e provenienza. Solo quando il campione supera una soglia decisa dal team ha senso indicizzare il resto.
Poi conviene eseguire domande con risposta verificabile e fonte nota. La pipeline va misurata separatamente: il passaggio richiesto è stato estratto? viene recuperato? la risposta lo usa senza aggiungere affermazioni? Questo isolamento è essenziale. Se una risposta è sbagliata, permette di capire se correggere OCR, chunking, retrieval o prompt invece di sostituire modelli alla cieca.
Un altro punto è il costo. Elaborare PDF lunghi può richiedere GPU, API o tempi significativi. I file dovrebbero essere deduplicati tramite hash, la conversione resa riproducibile e i risultati versionati. Se cambia il parser, bisogna sapere quali documenti rieseguire e quale output è servito in una risposta passata.
Sicurezza e limiti editoriali
Un PDF è anche input non fidato. Può contenere istruzioni rivolte a un modello, dati personali o testo bianco invisibile all’utente. La fase di estrazione non deve accordare al documento alcun privilegio operativo. I dati vanno classificati prima dell’indicizzazione e l’assistente deve trattare il contenuto recuperato come informazione, non come istruzione di sistema.
Infine, un buon OCR non conferma la verità del documento. Trasforma un supporto in dati più consultabili; non verifica affermazioni, licenze o attualità. Per un sito editoriale o una base aziendale resta necessario attribuire la fonte e distinguere testo primario, commento e materiale non verificato.
Verdetto
olmOCR è interessante perché affronta un collo di bottiglia spesso nascosto nelle demo RAG: la qualità reale dei documenti. Il suo valore va dimostrato su pagine difficili del proprio archivio, con confronti visivi e domande con fonte attesa. Se l’output conserva struttura e provenienza, la fase successiva di retrieval parte da basi migliori. Se non le conserva, cambiare LLM non risolverà il problema originario.