docling viene spesso messo nello stesso calderone dei web scraper, ma non lo è. È un toolkit di conversione documentale di IBM Research — oggi progetto della LF AI & Data Foundation — che prende file che possiedi già (PDF, DOCX, PPTX, XLSX, HTML, immagini) e li trasforma in Markdown o JSON. Il suo slogan dice tutto: "Prepara i tuoi documenti per la gen AI."
Questa quindi è una recensione pratica di un convertitore, non di un crawler. Tutto ciò che segue è stato misurato su una sola macchina CPU-only (macOS arm64, Python 3.14.2, Docling 2.111.0), con punteggi ricavati da script e i fallimenti registrati come fallimenti. Il repository è enorme e cambia ogni giorno — 63.069 stelle, 4.449 fork e un push nello stesso giorno in cui ho scaricato i metadati — quindi considera ogni numero di versione o conteggio qui come una fotografia del momento, non come un valore fisso.
Cos’è davvero Docling (e cosa non è)
L’unità fondamentale in Docling è DoclingDocument: si analizza un file in quella struttura, poi si esporta in Markdown, HTML, DocTags o JSON lossless. Il codice è sotto licenza MIT (le licenze dei singoli modelli possono variare), nasce a IBM Research Zurich e, al momento della scrittura, l’ultima release è la v2.112.0, pubblicata due giorni prima dei miei test.
La capacità principale è il percorso PDF e immagini. E non si tratta di semplice parsing di stringhe: c’è dietro una pila di modelli di machine learning — un modello di layout RT-DETR, il modello per la struttura delle tabelle TableFormer, un modello vision-language opzionale e RapidOCR per le scansioni. Questi modelli ricostruiscono il layout della pagina, l’ordine di lettura e la struttura delle tabelle. È questa la parte che vale la pena valutare, ed è una parte che un test limitato all’HTML non vedrebbe mai.
C’è una distinzione che evita una settimana di confusione: Docling non scarica nulla. Non renderizza JavaScript, non supera le difese anti-bot e non fa crawling. Tu gli dai il file; lui lo interpreta. Il crawling è compito di un altro strumento, e questo conta quando poi qualcuno chiede se Docling sostituisca Firecrawl (non lo fa: sono complementari, e tra poco vedremo perché).
La prima esecuzione che nessuno ti racconta
pip install docling va a buon fine senza problemi su Python 3.14.2. Poi però guardi l’ambiente virtuale e scopri che pesa 1,3 GB. Docling si porta dietro l’intero stack ML come dipendenza obbligatoria anche se devi convertire solo un file HTML:
| Dipendenza | Dimensione su disco (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ modelli inclusi) | 72,1 |
| docling_parse | 30 |
E questo prima ancora di convertire un singolo PDF. La prima conversione di un PDF è il punto in cui arriva il vero attrito, perché è lì che i modelli vengono scaricati. Su una cache HuggingFace nuova e isolata, la prima conversione PDF ha richiesto circa 224 secondi — e quasi tutto era tempo di download, non di calcolo. I modelli di layout e TableFormer occupano circa 506 MiB su disco (342 MiB TableFormer + 164 MiB layout, verificati con du), mentre RapidOCR scarica circa 40 MB di pesi PP-OCRv4 in site-packages. La seconda conversione dello stesso file? 0,55 secondi. I modelli vengono cacheati; il pedaggio lo paghi una sola volta.
Un numero che conviene ignorare: lo script di cold start mostra un model_download_mb di 1060,2. Non citarlo come footprint reale. Dipende da un os.walk che segue i symlink, mentre la cache HuggingFace salva ogni file una sola volta in blobs/ e poi lo reespone tramite symlink in snapshots/, quindi il walk conta due volte i 14 file dei modelli. Il dato corretto, allineato a du e deduplicato rispetto ai symlink, è circa 506 MiB (solo blobs: 505,4 MiB). Il messaggio per chiunque voglia fare benchmark di Docling è semplice: separa i byte scaricati dai byte occupati su disco, perché non sono la stessa cosa.
C’è anche un secondo dettaglio che morde chi prova a mettere Docling in container. I pesi si dividono in due posizioni e con due tempistiche diverse. I modelli di layout e TableFormer rispettano HF_HOME e si scaricano alla prima conversione PDF. I modelli di RapidOCR, invece, no: finiscono in …/site-packages/rapidocr/models/, ignorando del tutto la configurazione della cache. Se stai pre-costruendo un’immagine o lavorando in air-gap, devi gestire entrambe le cache, e nessuna impostazione di HF_HOME ti salverà dalla seconda.
Detto questo, va fatta una precisazione corretta. Nelle release precedenti, il progetto ha introdotto docling-slim — un core da circa 50 MB che permette pip install docling-slim[format-html] per l’HTML senza trascinarsi dietro torch. Quindi il peso di 1,3 GB è reale per il metapacchetto docling di default, ma oggi è evitabile. Ho testato il pacchetto completo perché è ancora quello che installa pip install docling, ma la pesantezza non è un difetto irrisolto: la soluzione modulare esiste ed è tracciata nell’issue #2393.
Durante la configurazione ho notato anche una piccola seccatura da segnalare: import docling; docling.__version__ solleva AttributeError: module 'docling' has no attribute '__version__'. Il modulo semplicemente non lo espone. Il controllo corretto è importlib.metadata.version("docling"), che restituisce '2.111.0'. Un fastidio minore per la DX, aperto a monte da luglio 2026 come issue #3733.
Fedeltà delle tabelle: dove TableFormer si guadagna il pane
Le tabelle sono il motivo per cui qualcuno sceglie Docling invece di un semplice dump PDF-to-text, così ho generato sette PDF con tabelle e ground truth leggibili dalla macchina e ho valutato l’output cella per cella. Due metriche contano, e non sono la stessa cosa: cell recall è la quota di valori di riferimento presenti da qualche parte nella tabella rilevata; in-row rate è la quota che finisce nella riga corretta. Confonderle rende il tool più bello di quanto sia davvero, quindi ecco entrambe:
| Tabella (stress test) | Rilevata | Cell recall | In-row rate | Nota |
|---|---|---|---|---|
| T1 griglia semplice con bordi (8 righe × 5 colonne), da sola nella pagina | No | 0.0 | — | classificata come <!-- image -->, tutte le celle perse |
| T2 senza bordi (solo una linea d’intestazione) | Sì | 1.00 | 1.00 | perfetta, griglia esatta |
| T3 intestazione a 2 livelli con colspan unito | Sì | 1.00 | 0.97 | tutti i valori presenti; un valore di intestazione slitta di una riga |
| T4 etichetta di riga con rowspan unito, da sola nella pagina | No | 0.0 | — | classificata come <!-- image --> |
| T5 intestazione con colspan + senza bordi | Sì | 1.00 | 0.97 | tutti i valori presenti; stesso slittamento di riga visto in T3 |
| T6 dati finanziari, colonna vuota, allineata a destra | Sì | 1.00 | 1.00 | colonna vuota preservata, non spostata |
| T7 griglia larga da 12 colonne | Sì | 1.00 | 1.00 | nessuno spostamento di colonna in una tabella ampia |
Nelle cinque tabelle che Docling ha rilevato, tutti i valori del ground truth sono passati — cell recall 1.00 su tutta la linea. In tre di queste cinque, ogni valore è finito anche nella riga corretta. Nei due casi con intestazioni multilivello (T3 e T5), un valore di intestazione scivola fuori dalla riga originale, abbassando l’in-row a 0,97: i dati ci sono tutti, ma l’assegnazione alla riga vacilla di uno su un’intestazione impilata.
I casi strutturali difficili hanno retto meglio di quanto mi aspettassi. L’intestazione a due livelli con colspan è stata appiattita correttamente in Markdown stile GitHub (l’etichetta "Q1 2026" si ripete sulle due colonne spanned, che è il modo giusto di comprimere un colspan in GFM). La griglia senza bordi e con solo una linea d’intestazione (T2) è passata identica. La griglia larga a 12 colonne (T7) non ha subito shift. E una colonna finanziaria completamente vuota (T6) è stata preservata come celle vuote invece di essere eliminata o compressa. Questo è coerente con i punteggi ufficiali TEDS di TableFormer — 95,4 simple, 90,1 complex, 93,6 all-tables — che nella model card superano di molto Camelot (73,0) ed EDD (88,3).
Una nota di cautela sui merged cells, perché c’è un issue aperto che racconta l’opposto. L’issue #3698 segnala che V1 e V2 gestiscono male righe e colonne unite. Nei miei fixture, i semplici colspan (T3/T5) e i valori rowspan sono stati appiattiti correttamente, con il solo slittamento di riga nelle intestazioni multilivello già citato. Ma i casi fallimentari di #3698 riguardano merge irregolari multi-riga/multi-colonna e tabelle su più pagine — il lato patologico del problema. I miei test sono il lato semplice. Quindi l’affermazione corretta è stretta: i semplici colspan e rowspan sono stati recuperati qui (le intestazioni multilivello possono spostare una riga); i merge complessi e irregolari restano un problema aperto documentato. Non “le celle unite funzionano”, ma nemmeno “le celle unite sono rotte”.
La trappola: una tabella sola in pagina può sparire
Riguarda la tabella sopra: T1 e T4 non sono state rilevate affatto. Docling ha emesso <!-- image --> e ha scartato tutte le celle, senza alcun errore. T1 è una griglia perfettamente normale, con bordi, 8 righe e 5 colonne. La cosa era abbastanza preoccupante da impedirmi di chiamarla semplicemente una debolezza del parsing delle tabelle, così ho isolato il vero trigger con un test A/B scriptato.
Prima ho escluso le spiegazioni ovvie. Il layer testuale è intatto — pypdfium2 legge 327 caratteri da T1 e 221 da T4, quindi sono veri PDF digitali, non immagini scansionate. Disattivare OCR (do_ocr=False) non cambia nulla: le tabelle continuano a sparire. E guardando direttamente DoclingDocument, len(doc.tables) == 0 mentre len(doc.pictures) == 1 — il modello di layout aveva classificato l’intera regione della tabella come Picture.
Poi il test decisivo. Ho renderizzato di nuovo le stesse tabelle T1 e T4, questa volta circondate da normali paragrafi di corpo testo, e ho riconvertito. Entrambe sono passate perfettamente: len(doc.tables) == 1, tabelle GFM corrette emesse, e l’etichetta rowspan di T4b "North" ripetuta correttamente sulle sue tre righe. Stessa tabella. L’unica variabile cambiata era se si trovava da sola in una pagina spoglia oppure inserita in un testo.
Quindi il vero caveat non è che TableFormer sia fragile: è che il modello di layout RT-DETR di Docling usa il contesto della pagina, e una tabella piccola da sola su una pagina quasi vuota rischia di essere letta come una Picture e scartata in silenzio. È facile incontrarlo nella pratica, perché è esattamente come appaiono fatture, schede tecniche ed export ritagliati: una tabella per pagina, senza testo attorno. La soluzione è banale ed efficace: dare al modello di layout un po’ di contesto di pagina, oppure controllare a posteriori doc.tables dopo la conversione e segnalare le pagine con conteggio zero. Questo è vicino all’issue #3495 (una tabella rilevata sia come Table sia come Picture), ma il trigger legato alla scarsità della pagina — stessa tabella, scartata se isolata, convertita se immersa nel testo — non l’ho trovato pubblicato altrove. Misurato, non documentato in precedenza; non è un bug che nessuno conosceva.
OCR su scansioni reali: RapidOCR, non EasyOCR
I PDF scansionati sono il punto in cui molti convertitori falliscono in silenzio, così ho passato a Docling due scansioni reali con un layer testuale misurato a 0 caratteri — pypdfium2 restituisce zero caratteri recuperabili, confermando che ogni output è OCR, non un layer testuale nascosto.
Il PDF a pagina singola ocr_test.pdf è tornato pulito in 14,3 secondi su CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," recuperato parola per parola. Il PDF di quattro pagine nemotron_multipage.pdf ha attivato l’OCR su tutte e quattro le pagine in 70,1 secondi totali (17,5 s/pagina), emettendo la frase di test ripetuta per ogni pagina. L’OCR di default si è attivato automaticamente — nessun flag, nessuna configurazione.
Il dettaglio che molti articoli sbagliano è questo: il motore OCR predefinito è RapidOCR, non EasyOCR. L’ho confermato vedendo scaricare i pesi .pth di PP-OCRv4 al primo avvio. Molti blog e vecchi testi FAQ su Docling dicono ancora che EasyOCR sia il default; è un’informazione superata. EasyOCR oggi è un extra opzionale. Il caveat che invece resta vero: l’OCR è il percorso lento su larga scala, e tutto ciò che vedi qui è un limite misurato su CPU — una GPU abbasserebbe sensibilmente questi tempi.
PDF reali, ordine di lettura e tempo per pagina
I fixture sintetici dimostrano comportamenti specifici; i PDF reali dimostrano che la cosa funziona davvero. Ho testato due articoli accademici nativi digitali — il report tecnico di Docling di 9 pagine e "Attention Is All You Need" di 15 pagine, entrambi a due colonne con tabelle e formule.
Nel paper di 15 pagine Attention, tutti e cinque i marcatori di sezione — Abstract, Introduction, Background, Conclusion, References — compaiono nell’ordine del documento nel Markdown linearizzato, nonostante il layout a due colonne. Ogni probe di contenuto (Transformer, encoder, BLEU, multi-head) è presente, e le famose tabelle dei risultati multi-colonna vengono riconosciute come quattro tabelle distinte. È un vero recupero dell’ordine di lettura e del merge tra colonne, cioè il valore centrale per il chunking in RAG: non puoi spezzare un documento in modo sensato se il linearizzatore trasforma una pagina a due colonne in un miscuglio interleavato senza senso.
Il tempo racconta una lezione controintuitiva: il tempo per pagina dipende da quanta struttura c’è in ogni pagina, non dal numero di pagine. Il report da 9 pagine, più denso, è andato a 14,95 secondi per pagina — peggio del paper da 15 pagine, che si è fermato a 5,99 secondi per pagina — perché contiene più tabelle e figure per pagina — 3 tabelle in 9 pagine contro 4 in 15 — e ognuna innesca più inferenze di layout e TableFormer. Il margine è sottile e, in termini assoluti, il documento più denso ha meno tabelle, non di più. Quindi “secondi per pagina” su CPU è una funzione della densità strutturale, non della lunghezza. Questo è un singolo run CPU-only; è un limite superiore, non un numero da produzione.
Multi-formato e la promessa del JSON lossless
Docling pubblicizza un parsing unificato multi-formato, così ho generato un DOCX, un XLSX e un PPTX con contenuti noti e probe di riferimento, poi ho controllato due cose: i probe compaiono nel Markdown e sopravvivono al round-trip JSON tramite export_to_dict()?
| File | Tempo di conversione (s) | Probe trovati nel MD | Tabelle nel MD | Probe sopravvissuti nel JSON |
|---|---|---|---|---|
report.docx (titoli + tabella unita "Total" + elenco puntato) | 0.137 | 7/7 | 1 | Sì |
workbook.xlsx (2 fogli, colonna vuota) | 0.016 | 6/6 | 2 | Sì |
deck.pptx (3 slide, elenco puntato + tabella) | 0.038 | 6/6 | 1 | Sì |
Tutti i probe sono arrivati nel Markdown, le tabelle sono state recuperate (inclusa la riga "Total" unita nel DOCX e entrambi i fogli dell’XLSX) e ogni probe è sopravvissuto anche al JSON di export_to_dict() — che è l’evidenza utile per la promessa di DoclingDocument lossless, almeno su input puliti. Questi formati passano attraverso backend nativi del formato invece dei modelli ML, motivo per cui funzionano in decine di millisecondi e completamente offline. Il perimetro è onesto: un file pulito per formato dimostra ampiezza, non un test di stress su file Office patologici.
HTML: fedele, ma non pulito
Questo è il caveat che decide se Docling ha senso nella tua pipeline RAG, quindi va letto con attenzione. Docling converte l’intero documento HTML. Non fa main-content extraction in stile readability. Ho quantificato quanto del chrome del sito sopravvive contando nel suo output le righe di navigazione, indice, cookie e footer.
| Pagina | Righe MD non vuote | Righe boilerplate | % boilerplate | Inizio articolo alla riga |
|---|---|---|---|---|
| Wikipedia "Web scraping" | 255 | 34 | 13,3% | 28 |
| scrapethissite/forms | 63 | 1 | 1,6% | — |
| books.toscrape | 65 | 0 | 0,0% | — |
| quotes.toscrape | 35 | 0 | 0,0% | — |
Su una pagina piena di chrome come Wikipedia, circa il 13% delle righe Markdown sono boilerplate di navigazione/indice/footer, e il vero articolo non comincia fino alla riga 28 — l’output si apre con "move to sidebar / Contents / Toggle the table of contents" e si chiude con "CS1 maint… / Search Wikipedia." Su pagine pulite e contenutistiche (books, quotes) siamo intorno allo 0%, quindi è un problema di chrome del template, non un costo fisso per pagina. Docling ti dà Markdown fedele dell’intero documento, non un’estrazione pulita dell’articolo principale. A monte il problema dei mobili HTML è tracciato nell’issue #1865 (chiuso) e #1930 (aperto).
Due precisazioni mantengono la valutazione equa. Primo: su HTML Docling non esegue alcun modello ML — usa un backend BeautifulSoup in una pipeline semplice. La storia dei “modelli vision che leggono la pagina” vale solo per PDF e immagini; se passi HTML a Docling, non si attivano né il layout né TableFormer. Secondo: il percorso PDF tenta comunque una classificazione di header e footer, quindi dire “nessuna rimozione del boilerplate” sarebbe troppo forte: è il backend HTML, in particolare, a restituire il chrome.
Come si colloca rispetto agli altri strumenti (e dove entra Thunderbit)
Prova Thunderbit per l’estrazione di dati dal web
Lo strumento con cui Docling viene più spesso confrontato è Firecrawl, quindi ecco una tabella di posizionamento. Una precisazione iniziale, perché conta: questa è una comparazione a livello documentazione, non un benchmark eseguito sulle stesse macchine. Non ho eseguito Firecrawl su questi fixture. Qui è misurata solo la colonna Docling; la colonna Firecrawl arriva dalla documentazione pubblica.
| Asse | Firecrawl (secondo la sua documentazione) | Docling (misurato qui) |
|---|---|---|
| Compito principale | Crawling + scraping del web live → Markdown | Convertire un documento che possiedi già → Markdown/JSON |
| Fetch / rendering JS / anti-bot | Sì (browser gestito) | No — fornisci tu il file |
| Estrazione del contenuto principale | Sì | No — documento completo fedele (~13% di chrome su Wikipedia) |
| Struttura delle tabelle PDF (ML) | limitata | Sì — TableFormer (TEDS ufficiale 93,6; cell recall 1.00, in-row 0.97–1.00 sui fixture rilevati) |
| PDF scansionati / OCR | limitato | Sì — RapidOCR di default (ha recuperato una scansione con layer testuale a 0) |
| Ampiezza dei formati | pagine web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/immagini |
| Distribuzione | API gestita (+ self-host) | libreria locale via pip, offline, senza API key |
| Peso di setup | API key / client leggero | installazione default da 1,3 GB + modelli da ~506 MiB (oppure docling-slim) |
| Licenza | commerciale / source-available | MIT |
La versione breve: Firecrawl è lo strumento giusto quando i dati sono sul web live e servono crawling, rendering JS e pulizia del contenuto principale. Docling è lo strumento giusto quando hai già il documento — soprattutto PDF, scansioni e file Office ricchi di tabelle — e vuoi una conversione fedele, offline, che preservi la struttura e comprenda davvero tabelle e OCR. Sono complementari. Una pipeline realistica usa uno per fare crawling e l’altro per convertire i documenti.
Ed è qui che sarò molto chiaro su Thunderbit, dato che ci lavoro e sarebbe giusto essere sospettosi se fingessi il contrario. Thunderbit e Docling non fanno lo stesso lavoro, e non forzerò un’equivalenza artificiale. Per gli sviluppatori, Thunderbit è un’API di scraping AI più server MCP più CLI, e l’unità di lavoro è la pagina web live: POST /distill trasforma un URL in Markdown pulito, pronto per LLM (gestendo rendering JS, anti-bot e CAPTCHA che Docling dichiaratamente non tocca), mentre POST /extract restituisce JSON strutturato allineato allo schema che definisci con JSON Schema. Questo è il lato fetch-and-clean di una pipeline RAG. Docling è il lato documento locale — il PDF, la scansione, il foglio di calcolo già sul tuo disco. Se il tuo corpus è fatto di pagine web, usa l’API di Thunderbit, i suoi strumenti MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) o la CLI (npx @thunderbit/thunderbit-cli). Se invece hai PDF e scansioni, usa Docling. Se hai entrambi — che è la situazione più comune nelle pipeline reali — i due strumenti si affiancano, senza cercare di sostituirsi a vicenda.
Verdetto: provvisorio, con qualche compito ancora aperto
Non ti darò un punteggio unico da 0 a 100, perché una media pesata qui finirebbe per penalizzare Docling per cose che non ha mai promesso di fare (come il crawling) e fingerebbe che siano comparabili. Per singola dimensione, sui fixture che ho testato:
- Setup / prima esecuzione: pesante — ambiente da 1,3 GB, modelli da ~506 MiB, prima PDF ~224 s, warm ~0,55 s — ma
docling-slimti fa evitare il peso. - Fedeltà delle tabelle: forte quando una tabella viene rilevata (cell recall 1,00 su 5/5, in-row 0,97–1,00), in linea con la storia ufficiale di TEDS sui miei fixture.
- Robustezza nel rilevamento delle tabelle: la trappola delle pagine sparse — una tabella isolata può sparire come Picture. Controlla
doc.tablesdopo la conversione. - Scansioni / OCR: funziona, RapidOCR di default; lento su larga scala.
- Multi-formato: solido, con round-trip JSON intatto.
- HTML: fedele, non pulito — niente main-content extraction.
- Developer experience: API pulita in 3 righe e
DoclingDocumentordinato, a parte l’assenza di__version__.
A chi serve: team che costruiscono pipeline RAG o di data processing su PDF, scansioni e file Office e vogliono conversione offline, che preservi la struttura e comprenda davvero tabelle e OCR. A chi non serve: chi ha bisogno di crawling del web live o di estrazione pulita dell’articolo principale da HTML — quello è un altro strumento.
E siccome questa è una recensione, non un comunicato stampa, i limiti restano scritti in chiaro. Questo è un probe mirato — 7 tabelle sintetiche più 2 PDF reali su una sola macchina CPU-only — non un benchmark di accuratezza su scala TEDS. Diverse cose che non ho testato e che dovresti verificare prima di puntare una pipeline su Docling: il percorso opzionale VLM (GraniteDocling), il footprint reale di docling-slim, qualsiasi esecuzione su GPU, le celle unite complesse e irregolari più le tabelle multi-pagina, la fedeltà da formula a LaTeX e — la cosa che più probabilmente ti sorprenderà in produzione — la tenuta nel tempo sotto carico per memoria batch, scalabilità thread/GIL e ciclo di vita degli oggetti su migliaia di conversioni. Docling è forte su ciò che promette, misurato più che raccontato, e ha bordi reali che conviene mappare prima di fidarsi di un corpus intero. Conosci il caveat delle pagine sparse, metti a budget il download iniziale e verifica tu stesso il comportamento su larga scala.
Prova Thunderbit per l’estrazione di dati dal web Get Started Free
FAQ
Docling è un web scraper o un crawler?
No. Docling converte documenti che possiedi già — PDF, DOCX, PPTX, XLSX, HTML, immagini — in Markdown o JSON. Non scarica URL, non renderizza JavaScript e non gestisce i sistemi anti-bot. Il crawling del web live è un lavoro separato, affidato a strumenti come Firecrawl o all’API web di Thunderbit; Docling parte dal file che gli fornisci.
Quanto pesa l’installazione di Docling e il primo download?
Il metapacchetto docling di default crea un ambiente virtuale da circa 1,3 GB perché scarica l’intero stack ML come dipendenza obbligatoria (solo torch pesa 536 MiB). La prima conversione PDF scarica circa 506 MiB di modelli di layout e TableFormer su disco, più circa 40 MB di pesi RapidOCR, e richiede circa 224 secondi — quasi tutto tempo di download. La seconda conversione richiede circa 0,55 secondi. Se ti servono solo formati leggeri, docling-slim (core da ~50 MB) evita il percorso pesante.
Docling fa OCR e con quale motore?
Sì. Su un PDF scansionato senza layer testuale, l’OCR di Docling si attiva automaticamente e nel mio test ha recuperato il testo in modo pulito. Il motore di default è RapidOCR, non EasyOCR — un errore molto comune nelle descrizioni più vecchie. EasyOCR oggi è un extra opzionale. L’OCR è il percorso lento su larga scala, soprattutto su CPU.
Perché Docling ha trasformato la mia tabella in un’immagine o l’ha scartata?
Molto probabilmente per l’effetto pagina sparsa. Il modello di layout RT-DETR di Docling usa il contesto della pagina, e una tabella piccola da sola su una pagina quasi vuota può essere classificata come Picture e scartata senza errori. La stessa tabella, se circondata da testo, viene convertita correttamente. La soluzione è fornire al modello di layout più contesto di pagina, oppure controllare a posteriori doc.tables dopo la conversione e segnalare qualsiasi pagina con conteggio zero.
Docling vs Firecrawl — quale dovrei usare?
Sono lavori diversi, quindi di solito non è un aut aut. Firecrawl esegue crawling del web live, renderizza JavaScript ed estrae il contenuto principale. Docling converte documenti che hai già, con vera struttura delle tabelle PDF e OCR, completamente offline. Se la tua fonte sono pagine web, usa uno strumento web (Firecrawl o l’API/MCP/CLI di Thunderbit). Se sono PDF, scansioni o file Office, usa Docling. Nella maggior parte delle pipeline reali si usano entrambi.
