Docling ajunge adesea pus în aceeași categorie cu web scraper-ele, dar nu este deloc așa. Este un set de instrumente pentru conversia documentelor, creat de IBM Research — acum proiect LF AI & Data Foundation — care ia fișiere pe care le ai deja (PDF, DOCX, PPTX, XLSX, HTML, imagini) și le transformă în Markdown sau JSON. Sloganul lor spune, literalmente: „Pregătește-ți documentele pentru gen AI.”
Așadar, aceasta este o recenzie practică a unui convertor, nu a unui crawler. Tot ce urmează a fost măsurat pe o singură mașină cu CPU only (macOS arm64, Python 3.14.2, Docling 2.111.0), cu scoruri obținute din scripturi și eșecuri consemnate ca eșecuri. Repo-ul este uriaș și se schimbă zilnic — 63.069 de stele, 4.449 de fork-uri și un push chiar în ziua în care am preluat metadatele — așa că tratează orice număr de versiune sau orice număr de issue de aici ca pe un instantaneu, nu ca pe o constantă.
Ce este Docling, de fapt, și ce nu este
Unitatea de bază în Docling este DoclingDocument: parsezi un fișier în această structură, apoi exporți în Markdown, HTML, DocTags sau JSON fără pierderi. Codul este sub licență MIT (licențele modelelor individuale pot diferi), proiectul a pornit la IBM Research Zurich, iar la momentul redactării cea mai nouă versiune este v2.112.0, publicată cu două zile înainte să rulez testele.
Capabilitatea principală este fluxul pentru PDF și imagini. Iar acel flux nu înseamnă simplă parsare de șiruri — este un strat de modele de machine learning: un model de layout RT-DETR, modelul de structură a tabelelor TableFormer, un model opțional vision-language și RapidOCR pentru scanări. Aceste modele refac layout-ul paginii, ordinea de citire și structura tabelelor. Aceasta este partea care merită evaluată, și exact acea parte pe care un test doar pe HTML nu o vede niciodată.
O diferență importantă elimină o săptămână de confuzie. Docling nu preia nimic de pe web. Nu redă JavaScript, nu trece de barierele anti-bot și nu face crawling. Tu îi dai fișierul; el se ocupă de înțelegerea lui. Crawling-ul este treaba altui instrument, iar asta contează mai târziu când lumea întreabă dacă Docling îl înlocuiește pe Firecrawl (nu îl înlocuiește — sunt complementare, iar imediat explic de ce).
Prima rulare despre care nimeni nu te avertizează
pip install docling reușește curat pe Python 3.14.2. Apoi te uiți în venv și vezi 1,3 GB. Docling trage întregul stack de ML ca dependențe obligatorii, chiar și dacă tu convertești doar un fișier HTML:
| Dependență | Dimensiune pe disc (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ modelele incluse) | 75.6 |
| docling_parse | 30 |
Și asta înainte să convertești măcar un singur PDF. Prima conversie de PDF este momentul în care apare adevărata fricțiune, pentru că atunci se descarcă modelele. Pe un HuggingFace cache nou, izolat, prima conversie PDF a durat ~224 de secunde — iar aproape tot timpul acela a fost descărcare, nu calcul. Modelele de layout plus TableFormer ocupă ~506 MiB pe disc (342 MiB TableFormer + 164 MiB layout, verificat cu du), iar RapidOCR descarcă ~40 MB de greutăți PP-OCRv4 în site-packages. A doua conversie a aceluiași fișier? 0,55 secunde. Modelele sunt cache-uite; taxa o plătești o singură dată.
Un număr pe care ar trebui să-l ignori: scriptul de cold start afișează model_download_mb = 1060.2. Nu cita asta ca footprint real. Valoarea vine dintr-un os.walk care urmărește symlink-uri, iar cache-ul HuggingFace stochează fiecare fișier al modelului o singură dată în blobs/, apoi îl expune din nou ca symlink în snapshots/ — așa că parcurgerea numără de două ori cele 14 fișiere ale modelelor. Valoarea corectă, de tip du, fără dublare prin symlink-uri, este ~506 MiB (doar blobs: 505,4 MiB). Concluzia pentru oricine face benchmark pe Docling: raportează separat bytes descărcați și bytes ocupați pe disc, pentru că sunt lucruri diferite.
Mai există un detaliu care îi încurcă pe cei care construiesc un container Docling. Greutățile modelelor se împart în două locuri și după două mecanisme diferite. Modelele de layout și TableFormer respectă HF_HOME și se descarcă la prima conversie PDF. Modelele RapidOCR nu — ajung în …/site-packages/rapidocr/models/, ocolind complet setarea de cache. Dacă pregătești imaginea din timp sau lucrezi într-un mediu air-gapped, trebuie să gestionezi ambele cache-uri, iar simplul fapt că setezi HF_HOME nu prinde și al doilea set de fișiere.
Acum partea corectă. În versiunile mai vechi ale Docling, proiectul a lansat docling-slim — un nucleu de ~50 MB care îți permite să faci pip install docling-slim[format-html] pentru HTML fără să tragi după tine torch. Așadar, greutatea de 1,3 GB este reală pentru metapachetul implicit docling, dar acum este opțională. Am testat pachetul implicit pentru că asta primești încă la pip install docling, însă „greutatea” nu mai este un defect nerezolvat — există deja soluția modulară, urmărită în issue #2393.
În timpul configurării am întâlnit și un mic defect de experiență a dezvoltatorului: import docling; docling.__version__ aruncă AttributeError: module 'docling' has no attribute '__version__'. Modulul pur și simplu nu expune acest atribut. Verificarea care funcționează este importlib.metadata.version("docling"), care returnează '2.111.0'. E o mică bătaie de cap, deschisă upstream din iulie 2026 ca issue #3733.
Fidelitatea tabelelor: locul unde TableFormer își câștigă reputația
Tabelele sunt motivul pentru care cineva alege Docling în locul unui simplu export PDF-to-text, așa că am generat șapte PDF-uri cu tabele și ground truth citibil de mașină, apoi am notat rezultatele celulă cu celulă. Contează două metrici, și nu sunt același lucru: cell recall este proporția valorilor din ground truth prezente oriunde în tabelul detectat; in-row rate este proporția care ajung în rândul corect. Dacă le amesteci, lași instrumentul să pară mai bun decât este, așa că le vezi pe ambele:
| Tabel (stress) | Detectat | Cell recall | In-row rate | Notă |
|---|---|---|---|---|
| T1 grilă simplă cu bordură (5×8), singură pe pagină | Nu | 0.0 | — | clasificat ca <!-- image -->, toate celulele pierdute |
| T2 fără borduri (doar o linie de antet) | Da | 1.00 | 1.00 | perfect, grilă exactă |
| T3 antet cu colspan pe 2 niveluri | Da | 1.00 | 0.97 | toate valorile sunt găsite; o valoare din antet sare un rând |
| T4 etichetă de rând cu rowspan îmbinat, singură pe pagină | Nu | 0.0 | — | clasificat ca <!-- image --> |
| T5 antet cu colspan + fără borduri | Da | 1.00 | 0.97 | toate valorile sunt găsite; aceeași deplasare de rând ca la T3 |
| T6 date financiare, coloană goală, aliniere la dreapta | Da | 1.00 | 1.00 | coloana goală este păstrată, nu mutată |
| T7 grilă lată cu 12 coloane | Da | 1.00 | 1.00 | fără deplasare de coloană într-un tabel lat |
Dintre cele cinci tabele detectate de Docling, fiecare valoare din ground truth a trecut mai departe — cell recall 1.00 pe toată linia. La trei dintre cele cinci, fiecare valoare a ajuns și în rândul corect. În cele două cazuri cu antet pe mai multe niveluri (T3 și T5), o valoare din antet alunecă din rândul ei inițial, iar in-row coboară la 0,97 — toate datele există, doar alocarea pe rând se clatină cu unul la un antet suprapus.
Cazurile structurale dificile s-au comportat mai bine decât mă așteptam. Antetul cu colspan pe două niveluri a fost aplatizat corect în Markdown GitHub-flavored (eticheta „Q1 2026” s-a repetat peste cele două coloane acoperite, exact cum trebuie să comprimi un colspan în GFM). Grila fără borduri, cu doar o linie de antet (T2), a trecut exact. Tabelul lat cu 12 coloane (T7) nu s-a deplasat. Iar o coloană financiară complet goală (T6) a fost păstrată ca celule goale, nu eliminată sau compactată. Asta este în linie cu scorurile oficiale TableFormer TEDS — 95,4 simplu, 90,1 complex, 93,6 toate tabelele — pe care model card-ul le poziționează mult peste Camelot (73,0) și EDD (88,3).
Un avertisment despre celulele îmbinate, pentru că există un issue deschis care spune contrariul. Issue #3698 raportează că V1 și V2 gestionează greșit rândurile și coloanele îmbinate. În fixture-urile mele, colspan-ul simplu (T3/T5) și valorile rowspan au fost aplatizate corect, cu excepția deplasării de rând notate la antetele pe mai multe niveluri. Dar cazurile care eșuează în #3698 sunt îmbinările neregulate, pe mai multe rânduri/coloane, și tabelele care trec peste mai multe pagini — adică zona patologică. Ale mele sunt zona simplă. Așadar, formularea corectă este una restrânsă: colspan-urile și rowspan-urile simple au fost recuperate aici (antetele pe mai multe niveluri pot deplasa un rând); îmbinările complexe și neregulate rămân o problemă deschisă documentată. Nu „celulele îmbinate merg”, dar nici „celulele îmbinate sunt rupte”.
Capcana: un tabel singur pe o pagină poate dispărea
Uită-te din nou la tabel — T1 și T4 nu au fost detectate deloc. Docling a emis <!-- image --> și a eliminat toate celulele, fără nici o eroare. T1 este o grilă perfect obișnuită, cu bordură, 5×8. Asta m-a făcut să refuz să numesc problema o slăbiciune generică de parsare a tabelelor până n-am izolat exact ce o declanșează, așa că am construit un test A/B scriptat.
Mai întâi am eliminat explicațiile evidente. Strat-ul de text există — pypdfium2 citește 327 de caractere din T1 și 221 din T4, deci sunt PDF-uri digitale reale, nu imagini scanate. Dacă opresc OCR-ul (do_ocr=False), nu se schimbă nimic; tabelele tot dispar. Iar dacă inspectez direct DoclingDocument, len(doc.tables) == 0 în timp ce len(doc.pictures) == 1 — modelul de layout clasificase întreaga zonă a tabelului drept Picture.
Apoi testul decisiv. Am randat din nou exact aceleași tabele T1 și T4, de data aceasta înconjurate de câteva paragrafe obișnuite de text, și am convertit încă o dată. Ambele au trecut perfect: len(doc.tables) == 1, tabele GFM corecte au fost emise, iar eticheta rowspan din T4b, „North”, s-a repetat corect pe cele trei rânduri. Același tabel. Singura variabilă schimbată a fost dacă stătea singur pe o pagină săracă sau era încorporat în text.
Așadar, avertismentul real nu este că TableFormer ar fi fragil — ci că modelul RT-DETR de layout din Docling folosește contextul paginii, iar un tabel mic, singur pe o pagină aproape goală, poate fi citit ca Picture și eliminat în liniște. E ușor să întâlnești asta în practică, pentru că exact așa arată facturi, fișe tehnice și exporturi decupate: un tabel pe pagină, fără text în jur. Soluția este plictisitoare, dar eficientă — oferă context paginii modelului de layout sau verifică după conversie doc.tables și marchează paginile unde numărul este zero. Acest lucru este apropiat de issue #3495 (un tabel detectat și ca Table, și ca Picture), dar declanșatorul specific al paginii sărace — același tabel, dispare când e izolat, trece când e în text — nu l-am găsit documentat nicăieri. Măsurat, nu documentat anterior; nu este un bug complet necunoscut, dar nici unul deja notat public.
OCR pe scanări reale: RapidOCR, nu EasyOCR
PDF-urile scanate sunt locul unde multe convertoare eșuează în tăcere, așa că am alimentat Docling cu două scanări autentice care au avut un text layer măsurat la 0 caractere — pypdfium2 raportează zero caractere recuperabile, confirmând că orice rezultat vine din OCR, nu dintr-un strat de text ascuns.
Fișierul ocr_test.pdf, o singură pagină, a revenit curat în 14,3 secunde pe CPU: „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” recuperat ad litteram. PDF-ul pe patru pagini nemotron_multipage.pdf a rulat OCR pe toate cele patru pagini în 70,1 secunde în total (17,5 s/pagină), emițând propoziția de test repetată pe fiecare pagină. OCR-ul implicit s-a pornit automat — fără flag, fără configurare.
Detaliul pe care multe articole îl greșesc este acesta: motorul OCR implicit este RapidOCR, nu EasyOCR. Am confirmat asta urmărind descărcarea greutăților PP-OCRv4 .pth la prima rulare. Multe bloguri existente și texte mai vechi din FAQ-ul Docling spun încă faptul că EasyOCR este implicit; acelea sunt informații depășite. EasyOCR este acum un extra opțional. Avertismentul care rămâne adevărat: OCR este calea lentă la scară mare, iar tot ce am măsurat aici reprezintă un plafon pe CPU only — pe GPU, timpii ar scădea semnificativ.
PDF-uri reale, ordinea de citire și timpul pe pagină
Fixture-urile sintetice dovedesc comportamente punctuale; PDF-urile reale dovedesc că treaba chiar funcționează. Am rulat două articole academice născute digital — raportul tehnic Docling de 9 pagini și „Attention Is All You Need” de 15 pagini, ambele în două coloane, cu tabele și formule.
Pe articolul de 15 pagini Attention, toate cele cinci marcatoare de secțiune — Abstract, Introduction, Background, Conclusion, References — apar în ordinea documentului în Markdown-ul liniarizat, în ciuda layout-ului pe două coloane. Fiecare element de probă (Transformer, encoder, BLEU, multi-head) este prezent, iar celebrele tabele de rezultate pe mai multe coloane apar ca patru tabele detectate. Asta înseamnă recuperare autentică a ordinii de citire și a îmbinării coloanelor, adică exact valoarea de bază pentru chunking în RAG — nu poți fragmenta logic un document dacă linearizatorul îți transformă o pagină cu două coloane într-un amestec intercalat fără sens.
Timpul oferă și o lecție contraintuitivă. Timpul pe pagină este dictat de câtă structură există pe fiecare pagină, nu de numărul de pagini. Raportul dens de 9 pagini a rulat cu 14,95 secunde pe pagină — mai lent per pagină decât articolul de 15 pagini, care a avut 5,99 secunde pe pagină — pentru că înghesuie mai multe tabele și figuri, iar fiecare declanșează mai multă inferență de layout și TableFormer. Așadar, „secunde pe pagină” pe CPU depind de densitatea structurală, nu de lungime. Aceasta este o singură rulare pe CPU only; este un plafon, nu un număr de producție.
Multi-format și promisiunea de JSON fără pierderi
Docling promovează parsarea unificată multi-format, așa că am generat un DOCX, un XLSX și un PPTX cu conținut cunoscut și probe de ground truth, apoi am verificat două lucruri: apar probele în Markdown și supraviețuiesc ele round-trip-ului JSON prin export_to_dict().
| Fișier | Conversie s | Probe în MD găsite | Tabele în MD | Probele supraviețuiesc în JSON |
|---|---|---|---|---|
report.docx (heading-uri + tabel cu "Total" îmbinat + bullets) | 0.137 | 7/7 | 1 | Da |
workbook.xlsx (2 foi, coloană goală) | 0.016 | 6/6 | 2 | Da |
deck.pptx (3 slide-uri, bullets + tabel) | 0.038 | 6/6 | 1 | Da |
Toate probele de conținut au ajuns în Markdown, tabelele au fost recuperate (inclusiv rândul „Total” îmbinat din DOCX și ambele foi din XLSX), iar fiecare probă a supraviețuit și în JSON-ul export_to_dict() — aceasta este dovada relevantă pentru afirmația de JSON „fără pierderi” a DoclingDocument, cel puțin pe fișiere curate. Formatele acestea trec prin backend-uri native, nu prin modelele ML, motiv pentru care rulează în zeci de milisecunde și funcționează complet offline. Domeniul de acoperire este onest: un fișier curat per format confirmă lățimea suportului, nu un test de stres pe fișiere Office patologice.
HTML: fidel, dar nu curat
Acesta este avertismentul care decide dacă Docling intră sau nu în pipeline-ul tău RAG, așa că citește-l cu atenție. Docling convertește întregul document HTML. Nu face extracție de conținut principal în stil readability. Am cuantificat cât chrome de site supraviețuiește, numărând liniile de nav, TOC, cookie și footer din output-ul Docling.
| Pagină | Linii MD non-goale | Linii boilerplate | % boilerplate | Articolul începe la linia |
|---|---|---|---|---|
| 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% | — |
Pe o pagină încărcată cu chrome, cum e Wikipedia, ~13% din liniile Markdown sunt boilerplate de navigare/TOC/footer, iar articolul real începe abia la linia 28 — output-ul pornește cu „move to sidebar / Contents / Toggle the table of contents” și se încheie cu „CS1 maint… / Search Wikipedia.” Pe pagini curate de conținut (books, quotes), procentul e ~0%, deci problema este una de șablon și chrome, nu o taxă aplicată fiecărei pagini. Docling îți oferă Markdown fidel pentru documentul întreg, nu extracție curată a articolului principal. Upstream urmărește problema mobilierului HTML în issue #1865 (închis) și #1930 (deschis).
Două lucruri păstrează evaluarea corectă. În primul rând, pe HTML Docling nu rulează niciun model ML — folosește un backend BeautifulSoup într-un pipeline simplu. Povestea cu „modelele de viziune care îți citesc pagina” se aplică doar la PDF și imagini; dacă îi dai HTML lui Docling, nu pornește nici mecanismul de layout, nici TableFormer. În al doilea rând, calea PDF încearcă totuși clasificarea header/footer-ului, deci o afirmație de genul „nu elimină deloc boilerplate” ar fi prea puternică — anume backend-ul HTML este cel care returnează chrome-ul.
Cum se compară și unde intră Thunderbit
Încearcă Thunderbit pentru extragerea datelor web
Instrumentul de referință cu care lumea compară Docling este Firecrawl, așa că iată o tabelă de poziționare. O precizare importantă de la început: aceasta este o comparație la nivel de documentație, nu un benchmark pe aceeași mașină. Nu am rulat Firecrawl pe aceste fișiere. Doar coloana Docling este măsurată aici; coloana Firecrawl provine din documentația publică.
| Axă | Firecrawl (conform doc) | Docling (măsurat aici) |
|---|---|---|
| Rol principal | Crawl + scrape pentru web-ul live → Markdown | Conversia unui document deja deținut → Markdown/JSON |
| Fetching / redare JS / anti-bot | Da (browser găzduit) | Nu — tu furnizezi fișierul |
| Extracție conținut principal | Da | Nu — document întreg, fidel (~13% chrome pe Wikipedia) |
| Structura tabelelor în PDF (ML) | limitat | Da — TableFormer (TEDS oficial 93,6; cell recall 1,00, in-row 0,97–1,00 pe fișierele detectate) |
| PDF scanat / OCR | limitat | Da — RapidOCR implicit (a recuperat o scanare cu 0 text layer) |
| Lățime de formate | pagini web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/imagine |
| Deployment | API găzduit (+ self-host) | bibliotecă locală pip, offline, fără API key |
| Greutate la setup | API key / client ușor | instalare implicită de 1,3 GB + ~506 MiB modele (sau docling-slim) |
| Licență | comercial / source-available | MIT |
Versiunea scurtă: Firecrawl este instrumentul potrivit când datele tale sunt pe web-ul live și ai nevoie de crawling, redare JS și curățare de conținut principal. Docling este instrumentul potrivit când deja ai documentul — mai ales PDF-uri, scanări și fișiere Office pline de tabele — și vrei o conversie fidelă, offline, care păstrează structura și înțelege cu adevărat tabelele și OCR-ul. Se completează reciproc. Un pipeline realist face crawl cu unul și conversia documentelor cu celălalt.
Și aici voi fi direct cu Thunderbit, pentru că lucrez aici și ar fi corect să fii suspicios dacă aș pretinde altceva. Thunderbit și Docling nu fac același lucru și nu o să forțez o echivalență falsă. Pentru dezvoltatori, Thunderbit este un API de scraping AI plus server MCP plus CLI, iar unitatea lui de lucru este pagina web live: POST /distill transformă un URL în Markdown curat, gata pentru LLM (gestionând redarea JS, anti-bot și CAPTCHA, lucruri pe care Docling în mod explicit nu le atinge), iar POST /extract returnează JSON structurat, potrivit schemei, printr-un JSON Schema definit de tine. Acesta este capătul de fetch-and-clean al unui pipeline RAG. Docling este capătul local pentru documente — PDF-ul, scanarea, foaia de calcul deja aflate pe discul tău. Dacă sursa ta este formată din pagini web, folosește API-ul Thunderbit, instrumentele MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) sau CLI-ul (npx @thunderbit/thunderbit-cli). Dacă ai PDF-uri și scanări, folosește Docling. Dacă le ai pe ambele — ceea ce se întâmplă în majoritatea pipeline-urilor reale — le combini, iar niciunul nu încearcă să fie celălalt.
Verdictul: provizoriu, cu teme rămase
Nu îți dau un singur scor de la 0 la 100, pentru că un total ponderat ar introduce penalizări pentru lucruri pe care Docling nu a pretins niciodată că le face (cum ar fi crawling-ul) și ar pretinde că sunt comparabile. Pe fiecare dimensiune, în fixture-urile testate:
- Setup / prima rulare: greu — venv de 1,3 GB, ~506 MiB modele, ~224 s la primul PDF, ~0,55 s la warm run — dar
docling-slimte scapă de greutate. - Fidelitatea tabelelor: puternică atunci când tabelul este detectat (cell recall 1,00 în 5/5, in-row 0,97–1,00), în linie cu povestea oficială TEDS pe aceste fișiere.
- Robustețea detecției de tabele: capcana paginii sărace — un tabel izolat poate fi pierdut ca Picture. Verifică după conversie
doc.tables. - Scanări / OCR: funcționează, RapidOCR implicit; lent la scară mare.
- Multi-format: solid, cu round-trip JSON intact.
- HTML: fidel, nu curat — fără extracție a conținutului principal.
- Experiența dezvoltatorului: API curat, în 3 pași, și un
DoclingDocumentordonat, minus lipsa lui__version__.
Pentru cine este: echipe care construiesc RAG sau pipeline-uri de date peste PDF-uri, scanări și fișiere Office și care vor conversie offline, cu păstrarea structurii și înțelegere reală a tabelelor plus OCR. Pentru cine nu este: oricine are nevoie de crawling live pe web sau de extracția curată a articolului principal din HTML — pentru asta ai alt instrument.
Și fiindcă aceasta este o recenzie, nu un comunicat de presă, limitările rămân la vedere. Aceasta este o verificare țintită — 7 tabele sintetice plus 2 PDF-uri reale pe o singură mașină CPU only — nu un benchmark de acuratețe la scara TEDS. Mai multe lucruri pe care nu le-am testat și pe care ar trebui să le verifici înainte să mizezi un pipeline pe Docling: calea opțională VLM (GraniteDocling), footprint-ul real al docling-slim, orice rulare pe GPU, celulele îmbinate complexe și neregulate plus tabelele pe mai multe pagini, fidelitatea formulelor în LaTeX și — cel mai probabil să te surprindă în producție — triada de durabilitate formată din creșterea memoriei în batch, scalarea thread/GIL și ciclul de viață al obiectelor pe mii de conversii. Docling este puternic acolo unde pretinde că este, măsurat mai degrabă decât promovat, și are margini reale pe care vei vrea să le cartografiezi înainte să ai încredere în el cu un corpus. Ține cont de capcana paginii sărace, bugetează descărcarea de la prima rulare și verifică singur comportamentul la scară.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
Întrebări frecvente
Docling este un web scraper sau un crawler?
Nu. Docling convertește documentele pe care deja le ai — PDF, DOCX, PPTX, XLSX, HTML, imagini — în Markdown sau JSON. Nu preia URL-uri, nu redă JavaScript și nu gestionează anti-bot. Crawling-ul web-ului live este o altă sarcină, rezolvată de instrumente precum Firecrawl sau API-ul web Thunderbit; Docling pornește de la fișierul pe care i-l dai.
Cât de mare este instalarea Docling și descărcarea la prima rulare?
Metapachetul implicit docling produce un venv de ~1,3 GB, pentru că trage întregul stack ML (doar torch are 536 MiB) ca dependențe obligatorii. Prima conversie PDF descarcă ~506 MiB de modele de layout și TableFormer pe disc plus ~40 MB de greutăți RapidOCR și durează aproximativ 224 de secunde — aproape totul fiind timp de descărcare. A doua conversie durează ~0,55 secunde. Dacă ai nevoie doar de formate ușoare, docling-slim (~50 MB nucleu) evită calea grea.
Face Docling OCR și cu ce motor?
Da. Pe un PDF scanat fără text layer, OCR-ul Docling pornește automat și, în testul meu, a recuperat textul corect. Motorul implicit este RapidOCR, nu EasyOCR — o confuzie frecventă în articolele mai vechi. EasyOCR este acum un extra opțional. OCR-ul este calea lentă la scară mare, mai ales pe CPU.
De ce a transformat Docling tabelul meu în imagine sau l-a eliminat?
Cel mai probabil din cauza efectului de pagină săracă. Modelul RT-DETR de layout folosit de Docling se bazează pe contextul paginii, iar un tabel mic, singur pe o pagină aproape goală, poate fi clasificat ca Picture și eliminat fără eroare. Același tabel, dacă este înconjurat de text, se convertește normal. Soluția este să oferi context modelului de layout sau să verifici după conversie doc.tables și să marchezi orice pagină unde numărul este zero.
Docling vs Firecrawl — pe care ar trebui să-l folosesc?
Sunt pentru joburi diferite, deci de obicei nu e o alegere exclusivă. Firecrawl face crawl pe web-ul live, redă JavaScript și extrage conținutul principal. Docling convertește documentele pe care deja le ai, cu structură reală pentru tabele în PDF și OCR, complet offline. Dacă sursa este web, folosește un instrument de web (Firecrawl sau API/MCP/CLI Thunderbit). Dacă ai PDF-uri, scanări sau fișiere Office, folosește Docling. În majoritatea pipeline-urilor reale, le folosești pe ambele.
