Docling bývá často házený do stejné škatulky jako web scrapery, ale scraper to není. Jde o sadu nástrojů pro převod dokumentů z IBM Research — dnes projekt LF AI & Data Foundation — která vezme soubory, které už máš po ruce (PDF, DOCX, PPTX, XLSX, HTML, obrázky), a převede je do Markdownu nebo JSONu. Jejich vlastní slogan je doslova „Připravte své dokumenty pro gen AI“.
Tahleta recenze je tedy praktický test převodníku, ne crawleru. Všechno níže bylo měřeno na jednom počítači jen s CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), výsledky vycházejí ze skriptů a selhání jsou vedená jako selhání. Repozitář je obrovský a mění se denně — 63 069 hvězdiček, 4 449 forků a push ve stejný den, kdy jsem stahoval metadata — takže jakýkoli počet chyb nebo verzi ber jako momentální snímek, ne jako konstantu.
Co Docling skutečně je (a čím není)
Základní jednotkou všeho v Doclingu je DoclingDocument: soubor se nejdřív naparsuje do téhle struktury a z ní se pak exportuje Markdown, HTML, DocTags nebo bezztrátový JSON. Kód je pod licencí MIT (jednotlivé modely mohou mít jiné licence), projekt vznikl v IBM Research Zurich a v době psaní je nejnovější vydání v2.112.0, publikované dva dny předtím, než jsem test spustil.
Klíčová schopnost je práce s PDF a obrázky. Tady nejde o parsování řetězců — ale o sadu modelů strojového učení: model rozvržení RT-DETR, model pro strukturu tabulek TableFormer, volitelný vision-language model a RapidOCR pro skeny. Tyhle modely obnovují rozvržení stránky, pořadí čtení a strukturu tabulek. To je ta část, která stojí za recenzi, a taky ta část, kterou by test zaměřený jen na HTML vůbec neodhalil.
Jeden rozdíl ti ušetří týden zmatků. Docling nic nestahuje. Nevykresluje JavaScript, neprolamuje anti-bot ochrany, necrawluje. Ty dodáš soubor; on z něj vytáhne význam. Crawling je práce jiného nástroje, a to je důležité později, až se někdo zeptá, jestli Docling nahrazuje Firecrawl (nenahrazuje — doplňují se, a za chvíli vysvětlím proč).
První spuštění, na které tě nikdo nepřipraví
pip install docling proběhne na Pythonu 3.14.2 čistě. Pak se ale podíváš do virtualenvu a zjistíš, že má 1,3 GB. Docling si jako tvrdé závislosti stahuje celý ML stack, i když budeš převádět jen HTML soubor:
| Závislost | Velikost na disku (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ přibalené modely) | 72,1 |
| docling_parse | 30 |
A to ještě předtím, než převedeš jediné PDF. První převod PDF je chvíle, kdy se ukáže skutečné tření, protože právě tehdy se stahují modely. Na čerstvé, izolované cache HuggingFace trval první převod PDF asi 224 sekund — a téměř všechno z toho byl download, ne výpočet. Modely pro layout plus TableFormer zabírají cca 506 MiB na disku (342 MiB TableFormer + 164 MiB layout, ověřeno přes du) a RapidOCR si do site-packages stáhne asi 40 MB vah PP-OCRv4. Druhý převod stejného souboru? 0,55 sekundy. Modely jsou v cache; poplatek platíš jen jednou.
Jedno číslo můžeš ignorovat: coldstart skript vypisuje model_download_mb na úrovni 1060,2. To ale jako velikost nepoužívej. Pochází to z os.walk, které následuje symlinky, zatímco cache HuggingFace ukládá každý modelový soubor jednou do blobs/ a pak ho znovu zpřístupňuje přes symlink v snapshots/ — takže průchod počítá 14 souborů dvakrát. Číslo odpovídající du, se symlinky deduplikované, je cca 506 MiB (jen blobs 505,4 MiB). Závěr pro každého, kdo Docling benchmarkuje: uváděj zvlášť stažená data a zvlášť data skutečně zabraná na disku, protože to není totéž.
Je tu ještě druhá past, která potrápí každého, kdo chce Docling nacpat do kontejneru. Váhy se dělí mezi dvě místa a stahují se podle dvou různých pravidel. Modely pro layout a TableFormer respektují HF_HOME a stáhnou se při prvním převodu PDF. Modely RapidOCR ale ne — ukládají se do …/site-packages/rapidocr/models/ a tvoje nastavení cache úplně obcházejí. Pokud image předpřipravuješ nebo provozuješ v air-gapped prostředí, musíš ošetřit obě cache a samotné HF_HOME ti na druhou z nich nestačí.
Teď férová poznámka. V novějších verzích projekt vydal docling-slim — přibližně 50MB jádro, díky kterému můžeš dát pip install docling-slim[format-html] pro HTML bez tahání torchu. Těch 1,3 GB je tedy u výchozího metabalíčku docling reálných, ale dnes už je to volitelná zátěž. Testoval jsem výchozí balíček, protože přesně to dostaneš po pip install docling, ale těžkopádnost už není neřešený problém — modulární oprava existuje a je vedená v issue #2393.
Při nastavování jsem narazil ještě na jednu drobnost, kterou stojí za to zmínit: import docling; docling.__version__ vyhodí AttributeError: module 'docling' has no attribute '__version__'. Modul tuhle hodnotu prostě nevystavuje. Funkční cesta je importlib.metadata.version("docling"), která vrátí '2.111.0'. Je to maličkost, ale pro vývojáře nepříjemná, a na upstreamu je to od července 2026 otevřené jako issue #3733.
Přesnost tabulek: tam si TableFormer vydělává
Tabulky jsou důvod, proč někdo sáhne po Doclingu místo prostého převodu PDF na text, takže jsem vygeneroval sedm PDF s tabulkami a strojově čitelnou referencí a hodnotil výstup buňku po buňce. Důležité jsou dvě metriky a nejsou to totéž: cell recall je podíl referenčních hodnot, které se objevily někde v rozpoznané tabulce; in-row rate je podíl, který skončil ve správném řádku. Když se to zamění, nástroj to vypadá líp, než je, takže tady jsou obě:
| Tabulka (zátěž) | Rozpoznána | Cell recall | In-row rate | Poznámka |
|---|---|---|---|---|
| T1 jednoduchá ohraničená mřížka (8 řádků × 5 sloupců), samostatně na stránce | Ne | 0,0 | — | klasifikováno jako <!-- image -->, všechny buňky ztraceny |
| T2 bez okrajů (jen horní pravidlo) | Ano | 1,00 | 1,00 | perfektní, přesná mřížka |
| T3 sloučená hlavička se 2 úrovněmi colspan | Ano | 1,00 | 0,97 | všechny hodnoty nalezeny; jedna hodnota hlavičky se posune o řádek |
| T4 sloučený řádek rowspan, samostatně na stránce | Ne | 0,0 | — | klasifikováno jako <!-- image --> |
| T5 hlavička colspan + bez okrajů | Ano | 1,00 | 0,97 | všechny hodnoty nalezeny; stejný posun řádku hlavičky jako u T3 |
| T6 finanční tabulka, prázdný sloupec, zarovnání doprava | Ano | 1,00 | 1,00 | prázdný sloupec zachován, neposunul se |
| T7 široká mřížka o 12 sloupcích | Ano | 1,00 | 1,00 | žádný posun sloupců u široké tabulky |
U pěti tabulek, které Docling rozpoznal, prošla všechny referenční hodnoty — cell recall 1,00 napříč celou sadou. U tří z těchto pěti skončila každá hodnota i ve správném řádku. U dvou případů s víceúrovňovou hlavičkou (T3 a T5) jedna hodnota hlavičky sjede z původního řádku, takže in-row rate spadne na 0,97 — data tam jsou všechna, jen přiřazení řádku se u vrstvené hlavičky lehce zhoupne.
Složitější strukturální případy dopadly líp, než jsem čekal. Dvouúrovňová hlavička s colspan se správně zploštila do GitHub-flavored Markdownu („Q1 2026“ se opakuje nad dvěma sloupci, které pokrývá, což je správný způsob, jak colspan v GFM rozpadnout). Tabulka bez okrajů, jen s horní linií (T2), prošla přesně. Široká 12sloupcová tabulka (T7) se neposunula. A finanční sloupec úplně bez obsahu (T6) zůstal jako prázdné buňky, místo aby se ztratil nebo zkolaboval. To odpovídá i oficiálním TEDS skóre TableFormeru — 95,4 u jednoduchých, 90,1 u složitých, 93,6 celkově — které modelovou kartu řadí výrazně nad Camelot (73,0) i EDD (88,3).
Pozor ale na sloučené buňky, protože existuje otevřený issue, který tvrdí opak. Issue #3698 hlásí, že V1 a V2 špatně pracují se sloučenými řádky a sloupci. Na mých testech se jednoduché colspany (T3/T5) i rowspany zploštily správně, s výjimkou výše zmíněného posunu řádku u víceúrovňové hlavičky. Problémové případy v #3698 ale zahrnují nepravidelné vícenásobné sloučení přes řádky i sloupce a tabulky přes více stran — tedy patologický konec spektra. Moje testy pokrývají ten jednoduchý konec. Správné tvrzení je tedy úzké: jednoduché colspany a rowspany tu prošly (víceúrovňové hlavičky ale mohou posunout řádek); složité a nepravidelné merge scénáře zůstávají zdokumentovaný otevřený problém. Ne „sloučené buňky fungují“, ne „sloučené buňky nefungují“.
Past: tabulka samotná na stránce může zmizet
Podívej se zpátky do tabulky — T1 a T4 se vůbec nerozpoznaly. Docling vypsal <!-- image --> a zahodil všechny buňky, bez jakékoli chyby. T1 je naprosto běžná mřížka 8 řádků × 5 sloupců s okraji. To je dost znepokojivé na to, abych to neoznačil za slabinu parsování tabulek, dokud jsem neizoloval skutečný spouštěč, a tak jsem udělal skriptovaný A/B test.
Nejprve jsem vyloučil zjevná vysvětlení. Textová vrstva je v pořádku — pypdfium2 přečte z T1 327 znaků a z T4 221, takže jde o skutečné digitální PDF, ne o naskenovaný obrázek. Vypnutí OCR (do_ocr=False) nepomůže; tabulky mizí dál. A když jsem se podíval přímo do DoclingDocument, len(doc.tables) == 0, zatímco len(doc.pictures) == 1 — layout model označil celou oblast tabulky jako Picture.
Pak přišel rozhodující test. Stejné tabulky T1 a T4 jsem znovu vyrenderoval, tentokrát obklopené několika obyčejnými odstavci, a převedl je znovu. Obě prošly perfektně: len(doc.tables) == 1, správně vyexportované GFM tabulky a u T4b se popisek rowspanu „North“ správně opakoval přes tři řádky. Stejná tabulka. Změnila se jen jediná věc: byla sama na řídké stránce, nebo byla vložená do textu.
Skutečné upozornění tedy není to, že by TableFormer byl křehký — ale to, že layout model RT-DETR v Doclingu používá kontext stránky a malá tabulka samotná na jinak téměř prázdné stránce může být tiše vyhodnocena jako Picture a zahozena. V praxi je to snadné trefit, protože přesně tak vypadají faktury, technické listy a oříznuté exporty: jedna tabulka na stránku, žádný okolní text. Oprava je nudná, ale funkční — dej layout modelu kontext stránky, nebo po převodu zkontroluj doc.tables a stránky s nulovým počtem označ. To je blízko k issue #3495 (tabulka rozpoznaná zároveň jako Table i Picture), ale konkrétní spouštěč řídké stránky — stejná tabulka ztracená izolovaně, správně převedená v textu — jsem nikde zveřejněný nenašel. Změřené, dříve nedokumentované; ne chyba, o které by nikdo nevěděl.
OCR na skutečných skenech: RapidOCR, ne EasyOCR
Naskenovaná PDF patří mezi místa, kde hodně převodníků tiše selhává, takže jsem Doclingu dal dva skutečné skeny s naměřenou textovou vrstvou o 0 znacích — pypdfium2 hlásí nulový počet obnovitelných znaků, takže jakýkoli výstup je OCR, ne skrytá textová vrstva v pozadí.
Jednostránkový ocr_test.pdf se na CPU vrátil čistě za 14,3 sekundy: „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,“ a text se obnovil doslova. Čtyřstránkový nemotron_multipage.pdf spustil OCR na všech čtyřech stránkách celkem za 70,1 sekundy (17,5 s/strana) a na každé stránce vypsal opakovanou testovací větu. Výchozí OCR se spustilo automaticky — bez přepínače, bez konfigurace.
A tady je detail, který většina textů uvádí špatně: výchozí OCR engine je RapidOCR, ne EasyOCR. Potvrdil jsem to tak, že jsem při prvním běhu viděl stahování vah PP-OCRv4 .pth. Hodně starších článků a FAQ k Doclingu pořád píše, že výchozí je EasyOCR, ale to už je zastaralé. EasyOCR je dnes doplněk, který si musíš zapnout sám. Platí ale i dál: OCR je ve velkém měřítku pomalá cesta a všechno tady je strop na CPU — GPU by ty časy snížilo znatelně.
Reálné PDF, pořadí čtení a čas na stránku
Syntetické testy dokazují konkrétní chování; skutečné PDF zase ukazují, že to funguje v praxi. Otestoval jsem dva born-digital akademické texty — 9stránkovou technickou zprávu o Doclingu a 15stránkový „Attention Is All You Need“, oba ve dvousloupcovém layoutu s tabulkami a vzorci.
Na 15stránkovém Attention paperu se všech pět značek sekcí — Abstract, Introduction, Background, Conclusion, References — objeví v linearizovaném Markdownu ve správném pořadí dokumentu, navzdory dvousloupcovému rozvržení. Každý kontrolní výskyt obsahu (Transformer, encoder, BLEU, multi-head) je přítomen a slavné tabulky s výsledky ve více sloupcích jsou zachycené jako čtyři rozpoznané tabulky. To je skutečné obnovení pořadí čtení a sloučení sloupců, což je jádro hodnoty pro RAG chunking — dokument nejde rozumně rozdělit na bloky, když linearizátor promíchá dvousloupcovou stránku do nesmyslné směsi.
Z časování plyne protiintuitivní poučení. Čas na stránku neurčuje počet stran, ale množství struktury na každé stránce. Hustší 9stránková zpráva běžela 14,95 sekundy na stránku — tedy pomaleji na stránku než 15stránkový paper, který vyšel na 5,99 sekundy na stránku — protože na každé stránce má víc tabulek a obrázků — 3 tabulky na 9 stran proti 4 na 15 — a každý takový objekt spouští další inference layoutu a TableFormeru. To je úzký rozdíl a v absolutním měřítku má hustší dokument tabulek méně, ne víc. Takže „sekundy na stránku“ na CPU jsou funkcí strukturální hustoty, ne délky. Jde o jeden CPU-only běh; je to strop, ne produkční číslo.
Multi-format a tvrzení o bezztrátovém JSONu
Docling slibuje jednotné parsování více formátů, takže jsem vygeneroval DOCX, XLSX a PPTX s předem známým obsahem a kontrolními body, a pak jsem zkontroloval dvě věci: objeví se kontrolní body v Markdownu a přežijí round-trip do JSONu přes export_to_dict()?
| Soubor | Převod s | MD kontrolní body nalezeny | Tabulky v MD | Kontrolní body přežijí JSON |
|---|---|---|---|---|
report.docx (nadpisy + tabulka s merged „Total“ + odrážky) | 0,137 | 7/7 | 1 | Ano |
workbook.xlsx (2 listy, prázdný sloupec) | 0,016 | 6/6 | 2 | Ano |
deck.pptx (3 snímky, odrážky + tabulka) | 0,038 | 6/6 | 1 | Ano |
Všechny kontrolní body se objevily v Markdownu, tabulky se obnovily (včetně sloučeného řádku „Total“ v DOCX a obou listů XLSX) a každý kontrolní bod přežil i JSON přes export_to_dict(). To je důkaz pro tvrzení o bezztrátovém DoclingDocument, alespoň na čistých vstupech. Tyhle formáty jdou přes nativní backendy, ne přes ML modely, proto běží v desítkách milisekund a fungují plně offline. Rozsah testu je poctivý: jeden čistý soubor na formát dokládá šíři, ne zátěžový test patologických Office souborů.
HTML: věrné, ale ne čisté
Tady je upozornění, které rozhodne, jestli Docling patří do tvé RAG pipeline, takže čti pozorně. Docling převádí celý HTML dokument. Nedělá main-content extraction ve stylu Readability. Změřil jsem, kolik z webové „výzdoby“ přežije, tím, že jsem v jeho vlastním výstupu spočítal řádky s navigací, TOC, cookies a patičkou.
| Stránka | Neblank řádků MD | Řádky s boilerplate | % boilerplate | Článek začíná na řádku |
|---|---|---|---|---|
| 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 % | — |
Na stránce s hodně „chromem“, jako je Wikipedia, tvoří asi 13 % řádků Markdownu navigace/TOC/patička a samotný článek nezačne dřív než na řádku 28 — výstup otevírá „move to sidebar / Contents / Toggle the table of contents“ a končí „CS1 maint… / Search Wikipedia.“ Na čistých obsahových stránkách (books, quotes) je to zhruba 0 %, takže jde o problém šablonového chromu, ne o daň za každou stránku. Docling ti dá věrný Markdown celého dokumentu, ne vyčištěný hlavní článek. Upstream problém s HTML nábytkem sleduje v issue #1865 (uzavřený) a #1930 (otevřený).
Dvě věci tady udržují férovost. Zaprvé, u HTML Docling vůbec nespouští ML modely — běží přes BeautifulSoup backend v jednoduchém pipeline. Příběh o tom, že tvoje stránky čtou vision modely, platí jen pro PDF a obrázky; když Doclingu dáš HTML, nespustí se ani layout, ani TableFormer. Zadruhé, PDF cesta se přece jen snaží klasifikovat hlavičky a patičky, takže tvrzení „žádné odstraňování boilerplate vůbec“ by bylo moc silné — právě HTML backend vrací chrom v plné podobě.
Jak si stojí vedle ostatních (a kde zapadá Thunderbit)
Vyzkoušejte Thunderbit pro extrakci webových dat
Nástroj, se kterým se Docling nejčastěji srovnává, je Firecrawl, takže tady je srovnávací tabulka. Jedno upozornění hned na začátku, protože je důležité: jde o srovnání na úrovni dokumentace, ne o benchmark na stejném počítači. Firecrawl jsem na těchto testovacích datech nespouštěl. Změřený je tady jen Docling; sloupec Firecrawl vychází z veřejné dokumentace.
| Osa | Firecrawl (podle dokumentace) | Docling (změřeno zde) |
|---|---|---|
| Hlavní úloha | Crawl + scrapování živého webu → Markdown | Převod dokumentu, který už máš → Markdown/JSON |
| Fetching / render JS / anti-bot | Ano (hostovaný browser) | Ne — soubor dodáváš ty |
| Exktrakce hlavního obsahu | Ano | Ne — věrný celý dokument (~13 % chromu na Wikipedii) |
| Struktura tabulek v PDF (ML) | omezeně | Ano — TableFormer (oficiální TEDS 93,6; cell recall 1,00, in-row 0,97–1,00 na rozpoznaných fixturech) |
| Naskenované PDF / OCR | omezeně | Ano — RapidOCR jako výchozí (obnovil sken s 0znakovou vrstvou) |
| Šíře formátů | webové stránky | PDF/DOCX/PPTX/XLSX/HTML/EPUB/obrázky |
| Nasazení | hostované API (+ self-host) | lokální pip knihovna, offline, bez API klíče |
| Váha při instalaci | API klíč / lehký klient | 1,3 GB výchozí instalace + ~506 MiB modelů (nebo docling-slim) |
| Licence | komerční / source-available | MIT |
Jednověté shrnutí: Firecrawl je správný nástroj, když jsou tvoje data na živém webu a potřebuješ crawling, renderování JS a vyčištění hlavního obsahu. Docling je správný nástroj, když už dokument máš — hlavně PDF, skeny a Office soubory s hodně tabulkami — a chceš věrný, offline převod zachovávající strukturu s opravdovým porozuměním tabulkám a OCR. Tyhle nástroje se doplňují. Reálný pipeline často crawl řeší jedním a převod dokumentů druhým.
A tady budu úplně upřímný i ohledně Thunderbit, protože u nás pracuji a bylo by správně podezřelé, kdybych předstíral opak. Thunderbit a Docling nedělají stejnou práci a nebudu z nich dělat umělou rovnost. Pro vývojáře je Thunderbit AI scraping API plus MCP server plus CLI a jeho pracovní jednotkou je živá webová stránka: POST /distill převede URL na čistý, pro LLM připravený Markdown (včetně renderování JS, anti-bot i CAPTCHA, kterých se Docling výslovně nedotýká) a POST /extract vrací strukturovaný JSON odpovídající schématu, které si sami definujete. To je část pipeline pro fetch a čištění. Docling je naopak část pro lokální dokumenty — PDF, sken, tabulka, která už leží na disku. Pokud je tvůj korpus web, sáhni po Thunderbit API, jeho MCP nástrojích (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) nebo CLI (npx @thunderbit/thunderbit-cli). Pokud jde o PDF a skeny, vezmi Docling. Pokud obojí — což je v praxi nejčastější — kombinuješ je a ani jeden se nesnaží být tím druhým.
Verdikt: předběžný, s domácími úkoly
Nebudu ti dávat jediné skóre 0–100, protože vážený součet by tady penalizoval věci, které Docling nikdy nesliboval (třeba crawling), a tvářil by se, že je to srovnatelné. Po jednotlivých dimenzích a na testovaných fixturech:
- Instalace / první běh: těžké — 1,3 GB venv, ~506 MiB modelů, ~224 s první PDF, ~0,55 s teplý běh — ale
docling-slimumožní zátěž obejít. - Přesnost tabulek: silná, když je tabulka rozpoznána (cell recall 1,00 u 5/5, in-row 0,97–1,00), v souladu s oficiálním příběhem TEDS na těchto testech.
- Robustnost detekce tabulek: past na řídké stránce — izolovaná tabulka se může ztratit jako Picture. Po převodu kontroluj
doc.tables. - Skeny / OCR: funguje, RapidOCR jako výchozí; ve velkém pomalé.
- Multi-format: solidní, s neporušeným JSON round-tripem.
- HTML: věrné, nečisté — bez extrakce hlavního obsahu.
- Developer experience: čisté třířádkové API a přehledný
DoclingDocument, minus chybějící__version__.
Pro koho to je: pro týmy, které staví RAG nebo datové pipeline nad PDF, skeny a Office soubory a chtějí offline převod zachovávající strukturu a skutečné porozumění tabulkám i OCR. Pro koho to není: pro kohokoli, kdo potřebuje crawling živého webu nebo čistou extrakci hlavního HTML článku — na to je jiný nástroj.
A protože je to recenze, ne tisková zpráva, limity zůstávají uvedené. Jde o cílený průzkum — 7 syntetických tabulek plus 2 reálné PDF na jednom CPU-only stroji — ne o benchmark přesnosti ve stylu TEDS ve velkém měřítku. Několik věcí jsem netestoval a ty bys to také měl, než na Docling vsadíš pipeline: volitelnou VLM cestu (GraniteDocling), skutečnou velikost docling-slim, jakýkoli GPU běh, složité a nepravidelné merged buňky plus tabulky přes více stran, věrnost převodu vzorců do LaTeXu a — to, co tě v produkci pravděpodobně překvapí nejvíc — odolnost při růstu paměti v batchi, škálování thread/GIL a životní cyklus objektů napříč tisíci převodů. Docling je silný v tom, co slibuje, a je měřený, ne jen marketingově popsaný, ale má i ostré hrany, které si budeš chtít zmapovat, než mu svěříš celý korpus. Když znáš past na řídké stránce, počítej s prvním downloadem a sám si ověř chování ve velkém měřítku.
Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free
Často kladené otázky
Je Docling web scraper nebo crawler?
Ne. Docling převádí dokumenty, které už máš — PDF, DOCX, PPTX, XLSX, HTML, obrázky — do Markdownu nebo JSONu. Nestahuje URL, nevykresluje JavaScript ani neřeší anti-bot ochrany. Crawl živého webu je samostatná práce nástrojů jako Firecrawl nebo webového API Thunderbitu; Docling začíná od souboru, který mu dodáš.
Jak velká je instalace Doclingu a první download?
Výchozí metabalíček docling vytvoří virtualenv o velikosti zhruba 1,3 GB, protože si jako tvrdé závislosti stahuje celý ML stack (jen torch má 536 MiB). První převod PDF stáhne asi 506 MiB modelů pro layout a TableFormer na disk plus asi 40 MB vah RapidOCR a trvá kolem 224 sekund — skoro celý čas je download. Druhý převod trvá asi 0,55 sekundy. Pokud potřebuješ jen lehčí formáty, docling-slim (cca 50 MB jádro) těžkou cestu vynechá.
Dělá Docling OCR a jakým enginem?
Ano. U naskenovaného PDF bez textové vrstvy OCR v Doclingu naskočí automaticky a v mém testu text obnovil čistě. Výchozí engine je RapidOCR, ne EasyOCR — častý omyl ve starších článcích. EasyOCR je dnes volitelný doplněk. OCR je ve velkém měřítku pomalá cesta, hlavně na CPU.
Proč Docling změnil moji tabulku na obrázek nebo ji zahodil?
Nejspíš kvůli efektu řídké stránky. Layout model RT-DETR v Doclingu používá kontext stránky a malá tabulka sama na téměř prázdné stránce může být bez chyby klasifikována jako Picture a zahozena. Stejná tabulka obklopená běžným textem projde správně. Řešení je dát layout modelu kontext stránky, nebo po převodu zkontrolovat doc.tables a označit každou stránku s nulovým počtem tabulek.
Docling vs Firecrawl — co bych měl použít?
Jsou to jiné úlohy, takže většinou nejde o volbu buď–anebo. Firecrawl crawlne živý web, vykreslí JavaScript a vytáhne hlavní obsah. Docling převádí dokumenty, které už máš, s opravdovou strukturou tabulek v PDF a OCR, plně offline. Pokud je zdroj web, použij webový nástroj (Firecrawl nebo Thunderbit API/MCP/CLI). Pokud jde o PDF, skeny nebo Office soubory, použij Docling. Většina reálných pipeline používá oba.
