Docling recenze: Co IBM převodník z dokumentů do Markdownu skutečně dělá s vašimi PDF

Docling bývá často řazen mezi web scrapery, ale tím není. Jde o nástroj pro převod dokumentů z dílny IBM Research — dnes projekt nadace LF AI & Data Foundation — který vezme soubory, které už máte k dispozici (PDF, DOCX, PPTX, XLSX, HTML, obrázky), a převede je do Markdownu nebo JSONu. Jeho vlastní slogan zní doslova: „Připravte své dokumenty pro gen AI.“

Tahle recenze je tedy praktickým testem převodníku, ne crawleru. Všechno níže bylo měřeno na jednom CPU-only stroji (macOS arm64, Python 3.14.2, Docling 2.111.0), výsledky jsou bodované ze skriptů a chyby jsou vedené jako chyby. Repozitář je obrovský a mění se prakticky denně — 63 069 hvězdiček, 4 449 forků a push ve stejný den, kdy jsem stahoval metadata — takže jakýkoli počet problémů nebo verze berte jen jako momentku, ne neměnný stav.

Co Docling vlastně je — a co není

Základní jednotkou všeho v Doclingu je DoclingDocument: soubor se nejdřív naparsuje do této struktury a teprve potom se exportuje do Markdownu, HTML, DocTags nebo bezeztrátového JSONu. Kód je pod licencí MIT (licence jednotlivých modelů se liší), vznikl v IBM Research Zurich a v době psaní je nejnovější verze v2.112.0, vydaná dva dny před tímto testem.

Hlavní schopností je zpracování PDF a obrázků. To ale není obyčejné parsování textu — stojí za tím sada ML modelů: model rozložení RT-DETR, model pro strukturu tabulek TableFormer, volitelný vision-language model a RapidOCR pro skeny. Tyto modely obnovují rozvržení stránky, pořadí čtení i strukturu tabulek. A přesně to je část, která stojí za recenzi — a kterou by čistě HTML test nikdy neodhalil.

Jeden rozdíl ušetří spoustu zmatku. Docling nic nestahuje. Nerenderuje JavaScript, neobchází anti-bot ochrany a neskenuje web. Vy mu dodáte soubor; on z něj vytěží porozumění. Crawlování je práce jiného nástroje, což je důležité hlavně ve chvíli, kdy se někdo začne ptát, zda Docling nahrazuje Firecrawl (nenahrazuje — doplňují se, a hned vysvětlím proč).

První spuštění, na které vás nikdo nepřipraví

pip install docling proběhne na Pythonu 3.14.2 bez problémů. Pak se ale podíváte do virtuálního prostředí a ono má 1,3 GB. Docling si totiž jako pevné závislosti stáhne celý ML stack, i kdybyste chtěli převádět jen HTML:

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)	75.6
docling_parse	30

A to všechno ještě před tím, než převedete jediné PDF. Skutečné tření přichází při prvním převodu PDF, protože právě tehdy se stahují modely. Na čerstvé, izolované HuggingFace cache trvalo první převedení PDF asi 224 sekund — a skoro všechno z toho byl download, ne výpočet. Layout + TableFormer modely zabírají na disku cca 506 MiB (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řevedení stejného souboru? 0,55 sekundy. Modely jsou v cache; jednorázově zaplatíte průchod.

Jedno číslo raději ignorujte: coldstart skript vypisuje model_download_mb 1060.2. Necitujte to jako skutečnou stopu. Vychází z os.walk, který následuje symlinky, a HuggingFace cache ukládá každý modelový soubor jednou do blobs/ a pak ho znovu zpřístupní jako symlink v snapshots/ — takže průchod spočítá 14 souborů dvakrát. Číslo odpovídající du, bez zdvojení přes symlinky, je cca 506 MiB (jen blobs 505,4 MiB). Poučení pro každého, kdo Docling benchmarkuje: uvádějte zvlášť stažená data a data skutečně uložená na disku, protože nejsou totéž.

Je tu i druhý háček, který zlobí každého, kdo staví Docling do kontejneru. Vážení se stahují na dvou místech a podle dvou různých plánů. Modely layoutu a TableFormer respektují HF_HOME a stáhnou se při prvním převodu PDF. Modely RapidOCR ale ne — končí v …/site-packages/rapidocr/models/ a vaše cache nastavení úplně obcházejí. Pokud image předpřipravujete nebo izolujete od sítě, musíte řešit obě cache a samotné HF_HOME vás před tou druhou neochrání.

A teď fér část. Od starších verzí Doclingu projekt vydal docling-slim — jádro o velikosti zhruba 50 MB, které vám dovolí pip install docling-slim[format-html] pro HTML bez přitažení torchu. Takže těch 1,3 GB je u výchozího docling metabalíčku reálných, ale už to není neřešitelný problém. Testoval jsem výchozí balíček, protože přesně to vám pořád dá pip install docling, ale těžkopádnost už není neopravená vada — modulární řešení 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 tuto hodnotu prostě nevystavuje. Funkční cesta je importlib.metadata.version("docling"), která vrátí '2.111.0'. Je to drobná bolest pro vývojáře, na upstreamu otevřená od července 2026 jako issue #3733.

Věrnost tabulek: kde TableFormer opravdu dává smysl

Tabulky jsou důvodem, proč někdo sáhne po Doclingu místo obyčejného převodu PDF na text, takže jsem vygeneroval sedm PDF tabulek s strojově čitelnou referencí a vyhodnocoval výstup buňku po buňce. Důležité jsou dvě metriky a nejsou to totéž: cell recall je podíl hodnot z referenčních dat, které se objeví kdekoli v nalezené tabulce; in-row rate je podíl těch hodnot, které skončí ve správném řádku. Směšovat je by nástroj zbytečně vylepšovalo, takže uvádím obě:

Tabulka (zátěž)	Detekováno	Cell recall	In-row rate	Poznámka
T1 jednoduchá tabulka s rámečkem (5×8), sama na stránce	Ne	0.0	—	klasifikováno jako <!-- image -->, všechny buňky ztraceny
T2 bez rámečku (jen horní linka)	Ano	1.00	1.00	přesné, perfektní mřížkové rozložení
T3 sloučená hlavička se 2 úrovněmi colspan	Ano	1.00	0.97	všechny hodnoty nalezeny; jedna hlavička se posune o řádek
T4 sloučený rowspan u popisků řádku, sama na stránce	Ne	0.0	—	klasifikováno jako <!-- image -->
T5 colspan v hlavičce + bez rámečku	Ano	1.00	0.97	všechny hodnoty nalezeny; stejný posun hlavičky jako u T3
T6 finance, prázdný sloupec, zarovnání doprava	Ano	1.00	1.00	prázdný sloupec zachován, neposunut
T7 široká mřížka o 12 sloupcích	Ano	1.00	1.00	u široké tabulky nedošlo k posunu sloupců

U pěti tabulek, které Docling skutečně detekoval, prošla každá referenční hodnota — cell recall 1.00 napříč všemi případy. Ve třech z těchto pěti tabulek navíc každá hodnota skončila i ve správném řádku. U dvou případů s víceúrovňovou hlavičkou (T3 a T5) jedna hodnota hlavičky sklouzla o řádek vedle, takže in-row rate spadl na 0,97 — data jako taková byla přítomná, jen přiřazení k řádku se u naskládané hlavičky trochu rozkymácelo.

Nejtěžší strukturální případy obstály lépe, než jsem čekal. Dvouúrovňová colspan hlavička se správně zploštila do GitHub-flavored Markdownu (popisek „Q1 2026“ se zopakoval přes oba spojené sloupce, což je správný způsob, jak colspan převést do GFM). Bezrámečková tabulka s jedinou horní linkou (T2) prošla přesně. Široká 12sloupcová tabulka (T7) se neposunula. A plně prázdný finanční sloupec (T6) zůstal jako prázdné buňky, místo aby se zahodil nebo slil. To odpovídá i oficiálním TEDS výsledkům TableFormeru — 95,4 jednoduché, 90,1 složité, 93,6 všechny tabulky — přičemž model card vychází výrazně lépe než Camelot (73,0) a EDD (88,3).

Pozor ale na sloučené buňky, protože existuje otevřený issue, který tvrdí opak. Issue #3698 uvádí, že V1 a V2 špatně zacházejí se sloučenými řádky a sloupci. U mých testovacích dat se jednoduché colspan (T3/T5) i rowspan hodnoty rozkládaly správně, s výjimkou výše zmíněného posunu u víceúrovňové hlavičky. Chybové případy v #3698 ale pokrývají nepravidelné vícerádkové a vícesloupcové sloučení a tabulky přes více stran — tedy patologický krajní scénář. Moje testy jsou ten jednoduchý konec spektra. Přesné tvrzení tedy zní úzce: jednoduché colspan a rowspan se zde obnovily správně (víceúrovňové hlavičky se ale mohou posunout o řádek); složitá a nepravidelná sloučení zůstávají zdokumentovaný otevřený problém. Ne „sloučené buňky fungují“, ale také ne „sloučené buňky jsou rozbité“.

Past: tabulka sama na stránce může zmizet

Vraťte se k tabulce — T1 a T4 nebyly detekovány vůbec. Docling vypsal <!-- image --> a zahodil všechny buňky bez jakékoli chyby. T1 je naprosto běžná 5×8 mřížka s rámečkem. 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 porovnání.

Nejdřív jsem vyloučil zjevné možnosti. Textová vrstva je v pořádku — pypdfium2 přečte z T1 327 znaků a z T4 221 znaků, takže jde o skutečné digitální PDF, ne o naskenované obrázky. Vypnutí OCR (do_ocr=False) nepomáhá; tabulky se stejně ztratí. A když jsem se podíval přímo do DoclingDocument, platilo len(doc.tables) == 0 a len(doc.pictures) == 1 — model rozvržení klasifikoval 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 textu, a převedl znovu. Obě prošly perfektně: len(doc.tables) == 1, vypsaly se správné GFM tabulky a u T4b se popisek rowspan „North“ správně opakoval přes tři řádky. Stejná tabulka. Změnila se jen jediná věc: jestli stála sama na úsporné stránce, nebo byla zasazená do textu.

Skutečné omezení tedy není křehkost TableFormeru, ale to, že layout model RT-DETR v Doclingu používá kontext stránky a malá tabulka na téměř prázdné stránce se může bez varování vyhodnotit jako Picture a potichu zahodit. V praxi je to snadné trefit, protože přesně tak vypadají faktury, technické listy i ořezané exporty: jedna tabulka na stránku, žádný okolní text. Oprava je nudná, ale účinná — dejte layout modelu kontext stránky, nebo po převodu zkontrolujte doc.tables a stránky s nulovým počtem označte. To souvisí s issue #3495 (tabulka detekovaná zároveň jako Table i Picture), ale konkrétní spouštěč „sparsity page“ — stejná tabulka zmizí, když je osamocená, a projde, když je zasazená do textu — jsem nikde publikovaný nenašel. Změřené, dříve nezdokumentované; ne bug, o kterém by nikdo nevěděl.

OCR na skutečných skenech: RapidOCR, ne EasyOCR

Naskenované PDF bývají místem, kde hodně převodníků tiše selže, takže jsem Doclingu dal dva skutečné skeny s naměřenou textovou vrstvou 0 znaků — pypdfium2 hlásí nula obnovitelných znaků, takže jakýkoli výstup je OCR, ne skrytá textová vrstva po cestě.

Jednostránkové ocr_test.pdf se na CPU vrátilo čistě za 14,3 sekundy: text „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,“ se obnovil doslova. Čtyřstránkové nemotron_multipage.pdf spustilo OCR na všech čtyřech stránkách a dalo celkově 70,1 sekundy (17,5 s/strana), přičemž na každé stránce vypsalo stejnou testovací větu. Výchozí OCR se spustilo automaticky — žádný flag, žádná konfigurace.

Tady je detail, který spousta článků uvádí špatně: výchozí OCR engine je RapidOCR, ne EasyOCR. Potvrdil jsem to podle stahování vah PP-OCRv4 .pth při prvním spuštění. Hodně starších blogů a i starší texty v Docling FAQ pořád tvrdí, že výchozí je EasyOCR; to už je neaktuální. EasyOCR je dnes extra, který si přidáte až volitelně. Co pořád platí: OCR je při větším měřítku pomalá cesta a všechno tady je strop CPU-only běhu — GPU by tyto časy citelně zkrátilo.

Reálná PDF, pořadí čtení a čas na stránku

Syntetické fixture ukazují konkrétní chování; reálná PDF ukážou, jestli to opravdu funguje. Spustil jsem dva akademické články vytvořené přímo do PDF — 9stránkovou technickou zprávu o Doclingu a 15stránkový „Attention Is All You Need“, oba dvousloupcové, s tabulkami a vzorci.

U 15stránkového článku Attention se všech pět značek sekcí — Abstract, Introduction, Background, Conclusion, References — objevuje v lineárním Markdownu ve správném pořadí dokumentu, navzdory dvousloupcovému rozvržení. Každý kontrolní pojem (Transformer, encoder, BLEU, multi-head) je přítomen a slavné vícesloupcové výsledkové tabulky se zaznamenaly jako čtyři detekované tabulky. To je skutečná obnova pořadí čtení i sloupců, což je hlavní hodnota pro chunkování v RAG — dokument nejde rozumně rozdělit, pokud linearizátor rozbije dvousloupcovou stránku na zamotané prokládání textu.

A časování přináší trochu protiintuitivní poučení. Čas na stránku neurčuje počet stran, ale to, kolik struktury je na jednotlivých stránkách. Hustší 9stránková zpráva běžela za 14,95 sekundy na stránku — tedy pomaleji na stránku než 15stránkový článek s 5,99 sekundy na stránku — protože obsahuje víc tabulek a obrázků a každý z nich spouští víc inference v layoutu a TableFormeru. 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.

Více formátů a tvrzení o bezeztrátovém JSONu

Docling slibuje jednotné parsování více formátů, takže jsem vygeneroval DOCX, XLSX a PPTX se známým obsahem a kontrolními body, a pak ověřoval dvě věci: objeví se kontrolní body v Markdownu a přežijí i JSON round-trip přes export_to_dict().

Soubor	Převedení s	MD kontrolní body nalezeny	Tabulky v MD	Kontrolní body přežijí v 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 slid y, 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ů v XLSX) a každý kontrolní bod přežil i JSON z export_to_dict() — to je důkaz pro tvrzení o bezeztrátovém DoclingDocument, alespoň na čistých vstupech. Tyto formáty jdou přes nativní backendy, ne přes ML modely, proto běží v desítkách milisekund a fungují plně offline. Rozsah je poctivý: jeden čistý soubor pro každý formát ukazuje šířku podpory, ne stresový test patologických Office souborů.

HTML: věrné, ale nevyčištěné

Tady je caveat, který rozhodne, zda Docling patří do vašeho RAG pipeline, takže čtěte pozorně. Docling převádí celý HTML dokument. Nedělá žádnou „readability“ extrakci hlavního obsahu. Změřil jsem, kolik webového okolí zůstane, počítáním řádků s navigací, TOC, cookie lištou a patičkou v samotném výstupu Doclingu.

Stránka	Počet ne-prázdných řá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ě „chrome“ obsahem, jako je Wikipedia, tvoří asi 13 % řádků Markdownu navigace/TOC/patička a skutečný článek nezačne dřív než na řádku 28 — výstup otevře „move to sidebar / Contents / Toggle the table of contents“ a uzavře „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 okolí, ne o daň za každou stránku. Docling vám dává věrný Markdown celého dokumentu, ne čistou extrakci hlavního článku. Upstream řeší HTML nábytek v issue #1865 (uzavřeno) a #1930 (otevřeno).

Dvě věci to dělají fér. Zaprvé, u HTML Docling nespouští žádné ML modely — běží to přes BeautifulSoup v jednoduchém pipeline. Příběh o tom, že „vision modely čtou vaši stránku“, platí jen pro PDF a obrázky; když Doclingu pošlete HTML, nespustí se ani layout, ani TableFormer. Zadruhé, PDF cesta se přece jen snaží rozpoznávat hlavičky a patičky, takže tvrdit „žádné odstraňování boilerplate vůbec“ by bylo moc silné. Je to konkrétně HTML backend, který ten webový chrome vrací zpátky.

Jak si vede v porovnání — a kam 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čátek, protože na tom záleží: jde o srovnání na úrovni dokumentace, ne o benchmark na stejném stroji. Firecrawl jsem na těchto fixturech nespouštěl. Sloupec Doclingu je měřený tady; sloupec Firecrawl je z veřejné dokumentace.

Osa	Firecrawl (dle dokumentace)	Docling (měřeno zde)
Hlavní úkol	Crawl + scrapování živého webu → Markdown	Převod dokumentu, který už máte → Markdown/JSON
Fetching / render JS / anti-bot	Ano (hostovaný prohlížeč)	Ne — soubor dodáte vy
Exktrakce hlavního obsahu	Ano	Ne — věrný celý dokument (~13 % boilerplate 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 detekovaných fixturech)
Skenované PDF / OCR	omezeně	Ano — RapidOCR ve výchozím nastavení (obnovil sken s 0 textovou 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
Náročnost nastavení	API klíč / lehký klient	výchozí instalace 1,3 GB + ~506 MiB modelů (nebo docling-slim)
Licence	komerční / source-available	MIT

Jednověté shrnutí: Firecrawl je nástroj pro situace, kdy jsou data na živém webu a potřebujete crawl, render JS a vyčištění hlavního obsahu. Docling je nástroj pro situace, kdy už dokument máte — zejména PDF, skeny a Office soubory plné tabulek — a chcete věrný, offline převod zachovávající strukturu s opravdu použitelným porozuměním tabulkám a OCR. Doplňují se. Realistický pipeline jedním nástrojem crawlne a druhým dokumenty převede.

A tady budu otevřený i k Thunderbit, protože tu pracuji a bylo by divné předstírat opak. Thunderbit a Docling nedělají totéž a nebudu je násilně stavět na roveň. Pro vývojáře je Thunderbit AI scraping API plus MCP server plus CLI a jeho jednotkou práce je živá webová stránka: POST /distill převede URL na čistý, pro LLM připravený Markdown (zvládá JS rendering, anti-bot i CAPTCHA, kterých se Docling výslovně netýká) a POST /extract vrátí strukturované JSONy odpovídající schématu, které si definujete přes JSON Schema. To je část pipeline pro fetch a čištění RAG. Docling je naopak lokální dokumentová část — PDF, sken nebo tabulka už uložená na disku. Pokud jsou vaším korpusem webové stránky, sáhněte po Thunderbit API, MCP nástrojích (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) nebo CLI (npx @thunderbit/thunderbit-cli). Pokud jde o PDF a skeny, sáhněte po Doclingu. Pokud jde o obojí — což je většina reálných pipeline — kombinujte je, protože ani jeden se nesnaží být tím druhým.

Verdikt: předběžný, ale domácí úkoly zůstávají

Nebudu vám dávat jedno jediné skóre 0–100, protože vážený součet by tady míchal do sebe penalizace za věci, které Docling nikdy netvrdil, že umí (třeba crawlování), a předstíral by, že jsou srovnatelné. Po jednotlivých dimenzích, na mých testovaných fixturech:

• Nastavení / první běh: těžké — 1,3 GB venv, ~506 MiB modely, ~224 s první PDF, ~0,55 s warm — ale docling-slim vám tu váhu umožní obejít.
• Věrnost tabulek: silná, když je tabulka deteková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 fixturech.
• Robustnost detekce tabulek: past na sparsnou stránku — izolovaná tabulka může spadnout jako Picture. Po převodu kontrolujte doc.tables.
• Skeny / OCR: funguje, výchozí RapidOCR; ve velkém pomalé.
• Více formátů: solidní, JSON round-trip drží.
• HTML: věrné, ale nevyčištěné — žádná extrakce hlavního obsahu.
• Developer experience: čisté 3řádkové API a přehledný DoclingDocument, jen bez __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 crawl ž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í přiznané. Jde o cílený probe — 7 syntetických tabulek plus 2 reálná PDF na jednom CPU-only stroji — ne o benchmark přes TEDS v plném rozsahu. Některé věci jsem netestoval a před nasazením do produkce byste měli také: volitelnou VLM cestu (GraniteDocling), skutečnou velikost docling-slim, jakýkoli GPU běh, složitá a nepravidelná sloučení buněk a tabulky přes více stran, přesnost převodu vzorců do LaTeXu a — co vás v produkci pravděpodobně překvapí nejvíc — trojici odolnosti: růst paměti v dávkách, škálování přes vlákna/GIL a životní cyklus objektů během tisíců převodů. Docling je silný v tom, co slibuje, a měřením spíš než marketingem to potvrzuje. Zároveň má ostré hrany, které si budete chtít zmapovat, než mu svěříte celý korpus. Počítejte s pastí na sparse page, vyhraďte prostor pro první download a chování ve velkém si ověřte sami.

Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free

Časté dotazy

Je Docling web scraper nebo crawler? Ne. Docling převádí dokumenty, které už máte — PDF, DOCX, PPTX, XLSX, HTML, obrázky — do Markdownu nebo JSONu. Nestahuje URL, nespouští JavaScript a neřeší anti-bot ochrany. Crawl živého webu je samostatná práce, kterou dělají nástroje jako Firecrawl nebo Thunderbit web API; Docling začíná až u souboru, který mu dodáte.

Jak velká je instalace Doclingu a první download při spuštění? Výchozí metabalíček docling vytvoří zhruba 1,3GB virtuální prostředí, protože jako pevné závislosti stahuje celý ML stack (jen torch má 536 MiB). První převod PDF stáhne na disk asi 506 MiB modelů layoutu a TableFormeru plus asi 40 MB vah RapidOCR a zabere zhruba 224 sekund — skoro celý ten čas je download. Druhé převedení trvá asi 0,55 sekundy. Pokud potřebujete jen lehčí formáty, docling-slim (jádro ~50 MB) se těžké cesty vyhne.

Dělá Docling OCR a jakým enginem? Ano. U naskenovaného PDF bez textové vrstvy se OCR spustí automaticky a v mém testu text obnovilo čistě. Výchozím enginem je RapidOCR, ne EasyOCR — to je častý omyl ve starších článcích. EasyOCR je dnes jen volitelný doplněk. OCR je při větším měřítku pomalá cesta, hlavně na CPU.

Proč Docling udělal z mé tabulky obrázek nebo ji zahodil? Nejspíš kvůli efektu sparse page. 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 klasifikovaná jako Picture a zahodit se bez chyby. Stejná tabulka obklopená textem se převede správně. Řešení je dát layout modelu víc kontextu stránky nebo po převodu zkontrolovat doc.tables a označit stránky s nulovým počtem.

Docling vs. Firecrawl — co mám použít? Jsou to různé úlohy, takže většinou nejde o volbu buď–anebo. Firecrawl crawlne živý web, renderuje JavaScript a extrahuje hlavní obsah. Docling převádí dokumenty, které už máte, a umí skutečnou strukturu tabulek v PDF i OCR, plně offline. Pokud je zdrojem web, použijte webový nástroj (Firecrawl nebo Thunderbit API/MCP/CLI). Pokud jde o PDF, skeny nebo Office soubory, použijte Docling. Většina reálných pipeline používá oba.