Parsing dei PDF per il RAG: da PyPDF a dots.ocr

Un RAG costruito con cura che risponde male. La prima reazione è dare la colpa al modello linguistico, la seconda agli embedding. Quasi sempre il problema sta prima di entrambi: nel momento in cui il testo viene estratto dai PDF. Se il parsing perde una tabella o mescola le colonne, nessun passaggio a valle può rimediare: è il classico garbage in, garbage out, e vale doppio perché l’errore entra nel database e ci resta.

Non tutti i PDF sono uguali

Un PDF può contenere il testo in due modi che non hanno niente in comune.

PDF "digitale"                          PDF "scansionato"
il testo è codificato come caratteri    ogni pagina è un'immagine
→ basta leggerlo                        → serve un OCR che la "guardi"

I digitali sono la maggior parte dei libri moderni, dei paper e dei manuali: il testo è già dentro il file, si seleziona con il mouse. Gli scansionati sono fotocopie, libri vecchi, documenti cartacei digitalizzati: pixel, non lettere. E poi ci sono i misti: corpo in testo nativo, ma tabelle, formule e grafici incollati come immagini. Sono quelli che ingannano, perché gli strumenti base ci lavorano “bene” e perdono in silenzio la parte che contava.

La regola pratica che risolve metà dei casi: apri il PDF e prova a selezionare il testo. Se ci riesci, il primo livello basta.

Livello 1: PyPDF e PyMuPDF

Sono le fondamenta. Librerie leggere, zero modelli, istantanee: centinaia di pagine al secondo.

from pypdf import PdfReader

reader = PdfReader("libro.pdf")
for page in reader.pages:
    text = page.extract_text()

PyMuPDF (fitz) fa la stessa cosa più in fretta e aggiunge l’estrazione di immagini, link e metadati. Nessuno dei due fa OCR, capisce le tabelle o riconosce il layout: su un PDF digitale con testo lineare vanno benissimo, su tutto il resto perdono struttura senza dirlo. Il knowledge bot sui libri di game design usa PyPDF e non ha mai avuto bisogno d’altro: 232 capitoli, 5.234 chunk, PDF digitali.

Livello 2: gli specialisti, Docling e Marker

Quando la struttura conta, servono strumenti che capiscano la pagina, non che la leggano.

Docling (IBM Research) combina due modelli: uno riconosce il layout (titoli, paragrafi, tabelle, figure, note), l’altro ricostruisce le tabelle cella per cella, comprese quelle unite o annidate. Il numero che colpisce è l’accuratezza sulle tabelle, 97,9%. Gira su CPU e su Mac, circa quattro secondi a pagina, e restituisce Markdown o JSON pronti per il chunking.

from docling.document_converter import DocumentConverter

result = DocumentConverter().convert("report.pdf")
markdown = result.document.export_to_markdown()

Marker (Datalab) è una pipeline OCR completa: testo base, riconoscimento delle scansioni, layout, Markdown. Il suo punto forte sono le formule matematiche, convertite in LaTeX, e le lingue: più di novanta. GPU opzionale, e funziona anche sull’acceleratore dei Mac con Apple Silicon. Se lavori con paper scientifici, è lui.

Livello 3: dots.ocr, un solo modello per tutto

Qui cambia l’approccio. Docling e Marker sono pipeline: un modello per il layout, uno per l’OCR, uno per le tabelle, in catena. dots.ocr è un unico vision-language model che guarda l’immagine della pagina e produce direttamente l’output strutturato: testo, tabelle in HTML, formule in LaTeX, perfino grafici in SVG.

Pipeline:   PDF → layout → OCR → tabelle → output     (tre modelli)
dots.ocr:   PDF → VLM → output                        (uno solo)

Nei benchmark è allo stato dell’arte e su testo e tabelle fa meglio di modelli commerciali molto noti. Il prezzo è l’hardware: serve una GPU NVIDIA con almeno 8 GB di memoria, l’installazione passa da CUDA, e non gira su Mac. È lo strumento per un server che deve digerire scansioni difficili in quantità, non per il portatile.

Come scegliere: tre domande

Domanda	Se la risposta è…	Allora
Che tipo di PDF ho?	Testo selezionabile	PyPDF o PyMuPDF, e hai finito
	Tabelle complesse, layout a colonne	Docling
	Formule, paper scientifici	Marker
	Scansioni difficili, grafici, tutto insieme	dots.ocr
Che hardware ho?	Solo CPU o un Mac	Docling o Marker
	GPU NVIDIA	dots.ocr diventa un’opzione
Cosa mi serve davvero?	Estrazione veloce e “abbastanza buona”	Il livello più basso che funziona
	Fedeltà assoluta di tabelle e formule	Il livello più alto che l’hardware regge

Il testo si seleziona?
├── SÌ → PyPDF / PyMuPDF
└── NO, o ci sono tabelle e formule critiche
    ├── GPU NVIDIA disponibile? → dots.ocr
    ├── contano soprattutto le tabelle → Docling (CPU/Mac)
    ├── contano soprattutto le formule → Marker (CPU/Mac/MPS)
    └── caso generale senza GPU → Docling

L’errore tipico: un parser per tutti

Si sceglie PyPDF perché è veloce, lo si prova su due PDF puliti, funziona, e lo si lancia su mille documenti aziendali misti. Il RAG risponde male e nessuno capisce perché: le tabelle dei contratti sono sparite, le intestazioni dei report si sono mescolate al corpo, i grafici sono diventati stringhe vuote. Nel database vettoriale è entrato testo rotto, e il modello lo cita con la massima sicurezza.

L’approccio che funziona è un triage: classificare i documenti prima di estrarli (digitale, complesso, scansione) e instradare ciascuno al parser che gli spetta. Non tutti al più potente: riprocessare con dots.ocr un PDF digitale è uno spreco di ore e di GPU, e non migliora niente.

Dove sta andando il campo

2020-2023  pipeline modulari: OCR → layout → post-processing
2024       framework integrati: Docling, Marker
2025+      modelli unificati: un VLM guarda la pagina e fa tutto

La direzione è chiara: da catene di componenti a modelli unici che capiscono la pagina intera. Ma non rende obsoleti gli strumenti semplici. Per un PDF digitale, PyPDF resta la scelta più intelligente: zero dipendenze, zero attesa, nessun modello da scaricare. Vale la pena chiedersi se l’anello più debole del proprio sistema non sia proprio il primo.

In sintesi

Concetto	In una riga
Perché conta	Il testo estratto male entra nel database e nessun modello lo ripara
Il test da fare prima	Se il testo del PDF si seleziona, basta PyPDF o PyMuPDF
Docling	Layout e tabelle (97,9%) su CPU e Mac
Marker	Formule in LaTeX, 90+ lingue, anche su Mac
dots.ocr	Un solo modello, qualità al top, ma GPU NVIDIA obbligatoria
Come scegliere	Tipo di PDF, hardware, precisione richiesta; poi un triage per documento