Docling viene spesso messo nello stesso calderone degli scraper web, ma non è così. È un toolkit di conversione documenti 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, detto proprio in modo letterale, è: "Prepara i tuoi documenti per la gen AI."
Questa, quindi, è una recensione pratica di un convertitore, non di un crawler. Tutto quello 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 star, 4.449 fork, e un push nello stesso giorno in cui ho scaricato i metadati — quindi considera qualunque numero di versione o conteggio qui come uno snapshot, non come una costante.
Cos'è davvero Docling (e cosa non è)
L'unità base di tutto in Docling è DoclingDocument: analizzi un file e lo trasformi in quella struttura, poi esporti in Markdown, HTML, DocTags o JSON lossless. Il codice è licenziato MIT (le licenze dei singoli modelli variano), nasce all'IBM Research Zurich e, al momento in cui scrivo, l'ultima release è la v2.112.0, pubblicata due giorni prima del mio test.
La capacità principale riguarda PDF e immagini. E non si tratta di un semplice parsing di stringhe: dietro c'è una pila di modelli di machine learning, con un modello di layout RT-DETR, il modello di struttura tabelle TableFormer, un modello visione-linguaggio opzionale e RapidOCR per le scansioni. Questi modelli ricostruiscono layout della pagina, ordine di lettura e struttura delle tabelle. È proprio questa la parte che vale la pena recensire, ed è anche quella che un test limitato all'HTML non vedrebbe mai.
C'è però una distinzione importante che fa risparmiare una settimana di confusione. Docling non recupera nulla dal web. Non renderizza JavaScript, non supera i blocchi anti-bot, non fa crawling. Tu gli dai il file; lui lo interpreta. Il crawling è il lavoro di un altro strumento, e questo conta quando qualcuno chiede se Docling sostituisce Firecrawl (non lo fa — si completano a vicenda, e tra poco vedrai perché).
Il primo avvio che nessuno ti avverte di aspettare
pip install docling va a buon fine senza intoppi su Python 3.14.2. Poi però apri la venv e scopri che pesa 1,3 GB. Docling si porta dietro l'intero stack ML come dipendenza obbligatoria, anche se devi convertire soltanto 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) | 75,6 |
| docling_parse | 30 |
E questo ancora prima di convertire un singolo PDF. La prima conversione di un PDF è dove arriva il vero attrito, perché è lì che i modelli vengono scaricati. Su una cache HuggingFace nuova e isolata, la prima conversione di un PDF ha richiesto circa 224 secondi — e quasi tutto era tempo di download, non di calcolo. I modelli di layout più 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 dentro site-packages. La seconda conversione dello stesso file? 0,55 secondi. I modelli vengono messi in cache; il costo lo paghi una volta sola.
Un numero da ignorare: lo script di cold start stampa model_download_mb pari a 1060,2. Non citarlo come ingombro reale. Viene da un os.walk che segue i symlink, e la cache HuggingFace salva ogni file modello una sola volta in blobs/ e poi lo riespone come symlink in snapshots/ — quindi il walk conta i 14 file modello due volte. La cifra corretta, deduplicata via symlink e coerente con du, è circa 506 MiB (soli blobs: 505,4 MiB). La lezione per chi fa benchmark su Docling: bytes scaricati e bytes su disco vanno riportati come metriche separate, perché sono due cose diverse.
C'è un secondo dettaglio che colpisce chi costruisce un container con Docling. I pesi si dividono su due percorsi e con tempi diversi. I modelli di layout e TableFormer rispettano HF_HOME e si scaricano alla prima conversione di un PDF. I modelli di RapidOCR no: finiscono in …/site-packages/rapidocr/models/, aggirando del tutto la tua configurazione di cache. Se stai preparando un'immagine pre-caricata o completamente isolata, devi gestire entrambe le cache, e nessun settaggio di HF_HOME intercetterà la seconda.
Detto questo, c'è anche il lato corretto della questione. Nelle release più recenti, il progetto ha introdotto docling-slim — un core da circa 50 MB che ti permette di fare pip install docling-slim[format-html] per l'HTML senza trascinarti dietro torch. Quindi il peso da 1,3 GB è reale per il metapacchetto docling di default, ma ormai è una scelta opt-out. Ho testato il pacchetto standard perché è ancora quello che ottieni con pip install docling, ma l'eccesso di peso non è un difetto irrisolto: la soluzione modulare esiste ed è tracciata nell'issue #2393.
Durante la configurazione mi sono imbattuto in un piccolo problema da segnalare: import docling; docling.__version__ genera AttributeError: module 'docling' has no attribute '__version__'. Il modulo semplicemente non espone quel dato. Il controllo corretto è importlib.metadata.version("docling"), che restituisce '2.111.0'. È una piccola seccatura per la DX, aperta upstream da luglio 2026 come issue #3733.
Fedeltà delle tabelle: dove TableFormer si guadagna il posto
Le tabelle sono il motivo per cui qualcuno sceglie Docling al posto di un semplice dump PDF-to-text, quindi ho generato sette PDF con tabelle e ground truth leggibile da macchina, e ho valutato l'output cella per cella. Due metriche contano, e non sono la stessa cosa: il cell recall è la percentuale dei valori reali presenti in qualunque punto della tabella rilevata; l'in-row rate è la percentuale che finisce nella riga corretta. Confonderle rende il tool migliore di quanto sia davvero, quindi eccole entrambe:
| Tabella (stress) | Rilevata | Cell recall | In-row rate | Nota |
|---|---|---|---|---|
| T1 griglia semplice bordata (5×8), isolata sulla pagina | No | 0,0 | — | classificata come <!-- image -->, tutte le celle perse |
| T2 senza bordi (solo una linea sull'intestazione) | Sì | 1,00 | 1,00 | perfetta, griglia esatta |
| T3 intestazione colspan a 2 livelli | Sì | 1,00 | 0,97 | tutti i valori presenti; un valore di intestazione slitta di una riga |
| T4 row label con rowspan unito, isolata sulla pagina | No | 0,0 | — | classificata come <!-- image --> |
| T5 intestazione colspan + senza bordi | Sì | 1,00 | 0,97 | tutti i valori presenti; stesso slittamento di riga della 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 shift di colonna in una tabella larga |
Nelle cinque tabelle che Docling ha rilevato, ogni valore della ground truth è passato: cell recall 1,00 ovunque. In tre di queste cinque, ogni valore è finito anche nella riga giusta. Nei due casi con intestazioni multilivello (T3 e T5), un valore dell'intestazione scivola fuori dalla riga originale, abbassando l'in-row a 0,97: i dati ci sono tutti, ma l'assegnazione della riga traballa di uno su un'intestazione stratificata.
I casi strutturalmente più difficili hanno retto meglio di quanto mi aspettassi. L'intestazione colspan a due livelli è stata appiattita correttamente in Markdown GitHub-flavored (l'etichetta "Q1 2026" viene ripetuta sulle due colonne span, che è il modo giusto di comprimere un colspan in GFM). La griglia senza bordi con solo la regola dell'intestazione (T2) è passata in modo impeccabile. La griglia larga da 12 colonne (T7) non ha fatto shift. E una colonna finanziaria completamente vuota (T6) è stata preservata come celle vuote, senza essere eliminata o compressa. Questo è coerente con i punteggi ufficiali TEDS di TableFormer — 95,4 per le tabelle semplici, 90,1 per le complesse, 93,6 su tutte le tabelle — e il model card la mette ben sopra Camelot (73,0) ed EDD (88,3).
Una nota di cautela sui merged cells, perché esiste un issue aperto che dice il contrario. 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 sopra. Ma i casi che falliscono in #3698 sono merge irregolari multi-riga/multi-colonna e tabelle multi-pagina — il caso patologico estremo. I miei sono il caso semplice. Quindi l'affermazione corretta è limitata: qui sono stati recuperati correttamente colspan e rowspan semplici (le intestazioni multilivello possono però slittare di una riga); i merge complessi e irregolari restano un problema aperto documentato. Non "i merged cells funzionano", né "i merged cells sono rotti".
La trappola: una tabella da sola su una pagina può sparire
Guarda di nuovo la tabella: T1 e T4 non sono state rilevate affatto. Docling ha emesso <!-- image --> e ha perso tutte le celle, senza errori. T1 è una normalissima griglia bordata 5×8. È abbastanza preoccupante da farmi escludere una debolezza generica del parsing finché non avessi isolato il vero fattore scatenante, così ho costruito un test A/B scriptato.
Per prima cosa ho escluso le spiegazioni ovvie. Il layer di testo è intatto — pypdfium2 legge 327 caratteri da T1 e 221 da T4, quindi sono PDF digitali veri, non immagini scannerizzate. Disattivare l'OCR (do_ocr=False) non aiuta: le tabelle continuano a sparire. E ispezionando direttamente DoclingDocument, len(doc.tables) == 0 mentre len(doc.pictures) == 1: il modello di layout aveva classificato l'intera area della tabella come Picture.
Poi il test decisivo. Ho renderizzato di nuovo le stesse tabelle T1 e T4, ma questa volta circondate da alcuni paragrafi normali, e ho riconvertito. Entrambe sono passate perfettamente: len(doc.tables) == 1, tabelle GFM corrette generate, e l'etichetta rowspan "North" di T4b ripetuta correttamente sulle tre righe. Stessa tabella. L'unica variabile cambiata era se si trovasse da sola in una pagina quasi vuota o immersa nel 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 e isolata in una pagina quasi vuota rischia di essere interpretata come Picture e scartata senza rumore. È un caso facile da incontrare nella pratica, perché è esattamente l'aspetto di fatture, schede tecniche e esportazioni ritagliate: una tabella per pagina, nessun testo attorno. La correzione è banale ed efficace: dare al modello di layout un contesto di pagina, oppure controllare dopo la conversione doc.tables e segnalare le pagine in cui il conteggio è zero. Questo è vicino all'issue #3495 (una tabella rilevata sia come Table sia come Picture), ma il trigger specifico della pagina sparsa — stessa tabella, persa se isolata, convertita se inserita nel testo — non l'ho trovato documentato altrove. Misurato, non già documentato; non un bug che nessuno conosceva.
OCR su scansioni vere: RapidOCR, non EasyOCR
I PDF scannerizzati sono il punto in cui molti convertitori falliscono in silenzio, quindi ho dato a Docling due scansioni reali con un layer di testo misurato pari a 0 caratteri — pypdfium2 restituisce zero caratteri recuperabili, confermando che qualsiasi output provenga da OCR e non da un layer di testo nascosto.
Il PDF singolo 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 su ogni pagina. L'OCR di default si è attivato automaticamente — nessun flag, nessuna configurazione.
Ecco il dettaglio che molti articoli sbagliano: il motore OCR predefinito è RapidOCR, non EasyOCR. L'ho verificato vedendo scaricare al primo avvio i pesi .pth di PP-OCRv4. Molti blog esistenti e vecchi testi FAQ di Docling dicono ancora che il default sia EasyOCR; è informazione superata. EasyOCR ora è un extra opzionale. Il caveat che resta vero: l'OCR è il percorso lento su larga scala, e tutto ciò che vedi qui è un tetto misurato su CPU-only — una GPU ridurrebbe in modo significativo questi tempi.
PDF reali, ordine di lettura e tempo per pagina
I fixture sintetici dimostrano comportamenti specifici; i PDF reali dimostrano che il sistema funziona davvero. Ho eseguito due paper accademici nativamente 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 su Attention, tutti e cinque i marker di sezione — Abstract, Introduction, Background, Conclusion, References — compaiono nell'ordine corretto del documento nel Markdown linearizzato, nonostante il layout a due colonne. Ogni punto chiave cercato (Transformer, encoder, BLEU, multi-head) è presente, e le famose tabelle dei risultati multi-colonna vengono registrate come quattro tabelle rilevate. È un vero recupero dell'ordine di lettura e della fusione delle colonne, che è il valore centrale per il chunking RAG: non puoi dividere in chunk un documento in modo sensato se il linearizzatore trasforma una pagina a due colonne in un guazzabuglio interlacciato.
Il timing insegna 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, ha girato a 14,95 secondi per pagina — più lento per pagina del paper da 15 pagine, che ha fatto 5,99 secondi per pagina — perché contiene più tabelle e figure, e ciascuna innesca più inferenza di layout e TableFormer. Quindi i "secondi per pagina" su CPU dipendono dalla densità strutturale, non dalla 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 multi-formato unificato, quindi ho generato un DOCX, un XLSX e un PPTX con contenuti noti e probe di ground truth, poi ho verificato due cose: i probe compaiono nel Markdown e sopravvivono al round-trip JSON tramite export_to_dict()?
| File | Tempo conv. s | Probe MD trovati | Tabelle nel MD | Probe sopravvivono nel JSON |
|---|---|---|---|---|
report.docx (titoli + tabella con "Total" unito + bullet) | 0,137 | 7/7 | 1 | Sì |
workbook.xlsx (2 fogli, colonna vuota) | 0,016 | 6/6 | 2 | Sì |
deck.pptx (3 slide, bullet + tabella) | 0,038 | 6/6 | 1 | Sì |
Tutti i probe sono finiti nel Markdown, le tabelle sono state recuperate (compresa la riga "Total" unita nel DOCX e entrambi i fogli dell'XLSX), e ogni probe ha superato anche il JSON di export_to_dict(), che è l'evidenza che conta per la promessa di DoclingDocument lossless, almeno su input puliti. Questi formati passano attraverso backend nativi del formato invece che attraverso i modelli ML, ed è per questo che girano in decine di millisecondi e funzionano completamente offline. Il perimetro è onesto: un file pulito per formato dimostra ampiezza, non una prova 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 leggilo con attenzione. Docling converte l'intero documento HTML. Non fa estrazione del contenuto principale in stile readability. Ho quantificato quanta parte della chrome del sito sopravvive contando le righe di navigazione, indice, cookie e footer nell'output di Docling.
| Pagina | Righe MD non vuote | Righe boilerplate | % boilerplate | L'articolo inizia 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 è boilerplate di navigazione/indice/footer, e l'articolo vero non inizia 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 (books, quotes) siamo circa allo 0%, quindi è un problema di template e chrome, non una tassa per ogni pagina. Docling ti dà un Markdown fedele dell'intero documento, non un'estrazione pulita del solo articolo principale. Upstream tiene traccia del problema dell'arredamento HTML nell'issue #1865 (chiuso) e nel #1930 (aperto).
Due cose rendono questo giudizio equo. Primo, sull'HTML Docling non esegue alcun modello ML: usa un backend BeautifulSoup in una pipeline semplice. La storia dei "modelli visivi che leggono la pagina" vale solo per PDF e immagini; se passi HTML a Docling, non parte nessun meccanismo di layout o TableFormer. Secondo, il percorso PDF prova comunque a classificare header e footer come arredamento, quindi dire "nessuna rimozione del boilerplate" sarebbe troppo forte: è il backend HTML, nello specifico, che restituisce la chrome.
Come si posiziona rispetto agli altri strumenti (e dove entra Thunderbit)
Prova Thunderbit per l'estrazione di dati dal web
Lo strumento con cui più spesso si confronta Docling è Firecrawl, quindi ecco una tabella di posizionamento. Una precisazione iniziale, perché conta: questo è un confronto a livello di documentazione, non un benchmark sulla stessa macchina. Non ho eseguito Firecrawl su questi fixture. Qui è misurata solo la colonna Docling; la colonna Firecrawl viene dalla documentazione pubblica.
| Asse | Firecrawl (secondo la sua documentazione) | Docling (misurato qui) |
|---|---|---|
| Lavoro principale | Crawl + scraping del web live → Markdown | Convertire un documento che hai già → Markdown/JSON |
| Fetch / rendering JS / anti-bot | Sì (browser ospitato) | No — fornisci tu il file |
| Estrazione del contenuto principale | Sì | No — documento completo fedele (~13% di chrome su Wikipedia) |
| Struttura 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 | limitata | Sì — RapidOCR di default (ha recuperato una scansione con layer testo a 0) |
| Ampiezza dei formati | pagine web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/immagini |
| Deploy | API hosted (+ self-host) | libreria pip locale, offline, senza API key |
| Peso di setup | API key / client leggero | installazione di default da 1,3 GB + ~506 MiB di modelli (oppure docling-slim) |
| Licenza | commerciale / source-available | MIT |
La sintesi in una riga: Firecrawl è lo strumento giusto quando i tuoi dati sono sul web live e richiedono 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 e rispettosa della struttura, con vero supporto per tabelle e OCR. Si completano a vicenda. Una pipeline realistica usa uno per il crawling e l'altro per la conversione dei documenti.
Ed è qui che sarò diretto su Thunderbit, visto che ci lavoro e avresti ragione a diffidare se fingessi il contrario. Thunderbit e Docling non fanno la stessa cosa, e non forzerò un'equivalenza. Per gli sviluppatori, Thunderbit è una scraping API con AI più server MCP più CLI, e la sua 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 non tocca esplicitamente), mentre POST /extract restituisce JSON strutturato allineato allo schema tramite uno JSON Schema che definisci tu. Questo è il lato fetch-and-clean di una pipeline RAG. Docling è il lato documento locale — il PDF, la scansione, il foglio di calcolo già presente sul 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 sono PDF e scansioni, usa Docling. Se sono entrambe le cose — come accade nella maggior parte delle pipeline reali — li combini, e nessuno dei due sta cercando di essere l'altro.
Il verdetto: provvisorio, con compiti ancora da fare
Non ti darò un singolo punteggio da 0 a 100, perché un totale pesato qui incorporerebbe penalità per cose che Docling non ha mai promesso di fare (come il crawling) e fingerebbe che siano comparabili. Per dimensione, sui fixture che ho testato:
- Setup / primo avvio: pesante — venv da 1,3 GB, modelli da ~506 MiB, ~224 s per il primo PDF, ~0,55 s a caldo — ma
docling-slimti permette di 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 su questi fixture.
- Robustezza del rilevamento tabelle: la trappola della pagina sparsa — 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 — nessuna estrazione del contenuto principale.
- Developer experience: API pulita in 3 righe e un
DoclingDocumentordinato, con l'eccezione del__version__mancante.
Per chi è: team che costruiscono pipeline RAG o data pipeline su PDF, scansioni e file Office e vogliono conversione offline, rispettosa della struttura, con vero supporto a tabelle e OCR. Per chi non è: chiunque abbia bisogno di crawling del web live o di estrazione pulita dell'articolo principale in HTML — quello è un altro strumento.
E poiché questa è una recensione e non un comunicato stampa, i limiti restano dichiarati. Si tratta di una prova mirata — 7 tabelle sintetiche più 2 PDF reali su una sola macchina CPU-only — non di un benchmark di accuratezza su scala TEDS. Ci sono diverse cose che non ho testato e che dovresti verificare prima di affidare una pipeline a Docling: il percorso opzionale VLM (GraniteDocling), l'effettivo ingombro di docling-slim, un run su GPU, i merged cells complessi e irregolari più le tabelle multi-pagina, la fedeltà formula-to-LaTeX e — quella che più facilmente ti sorprenderà in produzione — il triangolo della durabilità composto da crescita della memoria batch, scaling thread/GIL e lifecycle degli oggetti su migliaia di conversioni. Docling è forte su ciò che dichiara, misurato più che pubblicizzato, e ha limiti reali che conviene mappare prima di fidarsi di un corpus intero. Conosci il caveat della pagina sparsa, metti in budget il download del primo avvio e verifica tu stesso il comportamento su larga scala.
Prova Thunderbit per l'estrazione di dati dal web Get Started Free
FAQ
Docling è uno scraper o un crawler web? No. Docling converte documenti che possiedi già — PDF, DOCX, PPTX, XLSX, HTML, immagini — in Markdown o JSON. Non recupera URL, non renderizza JavaScript e non gestisce anti-bot. Il crawling del web live è un compito separato, gestito da strumenti come Firecrawl o dall'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 genera una venv da circa 1,3 GB perché scarica l'intero stack ML come dipendenza obbligatoria (solo torch pesa 536 MiB). La prima conversione di un 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 i formati leggeri, docling-slim (core da circa 50 MB) evita il percorso pesante.
Docling fa OCR? Con quale motore? Sì. Su un PDF scannerizzato senza layer di testo, l'OCR di Docling si attiva automaticamente e nel mio test ha recuperato il testo in modo pulito. Il motore predefinito è RapidOCR, non EasyOCR — un errore comune nei testi più vecchi. EasyOCR è ora 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 persa?
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 errore. La stessa tabella, se circondata da testo, viene convertita correttamente. La soluzione è fornire al modello un contesto di pagina oppure controllare dopo la conversione doc.tables e segnalare le pagine con conteggio zero.
Docling vs Firecrawl: quale dovrei usare? Sono lavori diversi, quindi di solito non è una scelta esclusiva. Firecrawl esegue crawling del web live, renderizza JavaScript ed estrae il contenuto principale. Docling converte documenti che hai già, con vero supporto a struttura PDF e OCR, completamente offline. Se la 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.
