Docling bywa wrzucany do jednego worka z web scraperami, ale scraperem nie jest. To zestaw narzędzi do konwersji dokumentów od IBM Research — dziś projekt LF AI & Data Foundation — który bierze pliki, które już masz (PDF, DOCX, PPTX, XLSX, HTML, obrazy) i zamienia je na Markdown albo JSON. Sam slogan mówi wprost: „Get your documents ready for gen AI.”
To więc praktyczna recenzja konwertera, a nie crawlера. Wszystko poniżej zostało zmierzone na jednej maszynie CPU-only (macOS arm64, Python 3.14.2, Docling 2.111.0), ocenione na podstawie skryptów, a błędy zapisane jako błędy. Repozytorium jest ogromne i rośnie z dnia na dzień — 63 069 gwiazdek, 4 449 forków i push tego samego dnia, w którym pobrałem metadane — więc traktuj każdą liczbę wersji czy błędów jako migawkę, a nie stałą wartość.
Czym Docling jest, a czym nie jest
Podstawową jednostką w Docling jest DoclingDocument: parsujesz plik do tej struktury, a potem eksportujesz go do Markdown, HTML, DocTags albo bezstratnego JSON. Kod jest na licencji MIT (poszczególne modele mogą mieć różne licencje), projekt powstał w IBM Research Zurich, a najnowsze wydanie w chwili pisania tego tekstu to v2.112.0, opublikowane dwa dni przed moim testem.
Najważniejsza funkcja to obsługa PDF-ów i obrazów. I nie chodzi tu o zwykłe parsowanie tekstu — pod spodem działa cały stos modeli uczenia maszynowego: model układu RT-DETR, model struktury tabel TableFormer z Hugging Face, opcjonalny model vision-language oraz RapidOCR dla skanów. Te modele odtwarzają układ strony, kolejność czytania i strukturę tabel. To właśnie ten element ma największą wartość w recenzji, i to właśnie ten element test HTML-only nigdy by nie pokazał.
Jedno rozróżnienie oszczędza tydzień zamieszania. Docling niczego nie pobiera. Nie renderuje JavaScriptu, nie przebija się przez blokady anty-bot, nie crawluje. Ty dostarczasz plik, a on zajmuje się zrozumieniem jego struktury. Crawlowanie to zadanie innego narzędzia — i to ma znaczenie później, gdy ktoś pyta, czy Docling zastępuje Firecrawl (nie zastępuje — te narzędzia się uzupełniają, a zaraz wyjaśnię dlaczego).
Pierwsze uruchomienie, o którym nikt Cię nie ostrzega
pip install docling przechodzi bez problemu na Pythonie 3.14.2. Potem patrzysz do virtualenv i widzisz 1,3 GB. Docling dociąga cały stos ML jako twarde zależności, nawet jeśli finalnie konwertujesz tylko plik HTML:
| Zależność | Rozmiar na dysku (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ dołączone modele) | 72,1 |
| docling_parse | 30 |
I to jeszcze zanim przekonwertujesz choćby jeden PDF. Prawdziwe tarcie pojawia się przy pierwszej konwersji PDF-a, bo wtedy pobierane są modele. Na świeżym, odizolowanym cache HuggingFace pierwsza konwersja PDF trwała około 224 sekund — i prawie cały ten czas zajmowało pobieranie, a nie obliczenia. Modele układu i TableFormer zajmują około 506 MiB na dysku (342 MiB TableFormer + 164 MiB model układu, zweryfikowane przez du), a RapidOCR pobiera około 40 MB wag PP-OCRv4 do site-packages. Druga konwersja tego samego pliku? 0,55 sekundy. Modele są już w cache; tę opłatę płacisz tylko raz.
Jedną liczbę możesz zignorować: skrypt coldstart pokazuje model_download_mb na poziomie 1060,2. Nie cytuj tego jako rzeczywistego footprintu. Wynika to z os.walk, który podąża za symlinkami, a cache HuggingFace zapisuje każdy plik modelu raz w blobs/, a potem udostępnia go ponownie jako symlink w snapshots/ — więc przejście liczy 14 plików modelu dwa razy. Prawidłowa, zgodna z du, zduplikowana przez symlinki wartość to około 506 MiB (tylko blobs: 505,4 MiB). Wniosek dla każdego, kto benchmarkuje Docling: podawaj osobno liczbę pobranych bajtów i liczbę bajtów na dysku, bo to nie to samo.
Jest jeszcze jeden haczyk, który uderza w osoby budujące kontener z Doclingiem. Wagi rozkładają się na dwie lokalizacje i dwa harmonogramy. Modele układu i TableFormer respektują HF_HOME i pobierają się przy pierwszej konwersji PDF-a. Modele RapidOCR już nie — trafiają do …/site-packages/rapidocr/models/, całkowicie omijając konfigurację cache. Jeśli przygotowujesz obraz wcześniej albo pracujesz w środowisku air-gapped, musisz obsłużyć oba cache’e, a samo ustawienie HF_HOME nie załatwi drugiego z nich.
Teraz uczciwy punkt. Od wcześniejszych wersji Docling projekt dostarcza docling-slim — około 50 MB rdzenia, który pozwala zrobić pip install docling-slim[format-html] dla HTML bez dociągania torch. Tak więc waga 1,3 GB jest realna dla domyślnego metapakietu docling, ale teraz jest już opcjonalna. Testowałem domyślny pakiet, bo to właśnie on dostajesz po pip install docling, ale ciężar nie jest niezaadresowaną wadą — istnieje modularne rozwiązanie, opisane w issue #2393.
Podczas konfiguracji trafiła mi się jeszcze jedna drobna niedogodność, którą warto odnotować: import docling; docling.__version__ zwraca AttributeError: module 'docling' has no attribute '__version__'. Moduł po prostu nie udostępnia tej informacji. Działający sposób to importlib.metadata.version("docling"), który zwraca '2.111.0'. To drobna irytacja dla dev experience, zgłoszona upstream już w lipcu 2026 jako issue #3733.
Wierność tabel: tam, gdzie TableFormer naprawdę zasługuje na swoją reputację
Tabele są powodem, dla którego ktokolwiek sięga po Docling zamiast zwykłego zrzutu PDF do tekstu, więc wygenerowałem siedem PDF-ów z tabelami i maszynowo czytelnym ground truth, a potem oceniłem wynik komórka po komórce. Liczą się dwie metryki i nie są tym samym: cell recall to odsetek wartości z ground truth obecnych gdziekolwiek w wykrytej tabeli; in-row rate to odsetek wartości trafiających do właściwego wiersza. Mieszanie tych dwóch rzeczy upiększa wynik, więc pokazuję obie:
| Tabela (test) | Wykryta | Cell recall | In-row rate | Uwagi |
|---|---|---|---|---|
| T1 zwykła tabelka z ramką (8 wierszy × 5 kolumn), sama na stronie | Nie | 0,0 | — | sklasyfikowana jako <!-- image -->, wszystkie komórki pominięte |
| T2 bez ramek (tylko linia nagłówka) | Tak | 1,00 | 1,00 | idealnie, dokładna siatka |
| T3 scalony nagłówek colspan na 2 poziomach | Tak | 1,00 | 0,97 | wszystkie wartości znalezione; jedna wartość nagłówka przesuwa się o wiersz |
| T4 scalony wiersz rowspan w etykiecie, sama na stronie | Nie | 0,0 | — | sklasyfikowana jako <!-- image --> |
| T5 nagłówek colspan + brak ramek | Tak | 1,00 | 0,97 | wszystkie wartości znalezione; ten sam przesunięty wiersz nagłówka co w T3 |
| T6 finansowa, pusty kolumnowy blok, wyrównanie do prawej | Tak | 1,00 | 1,00 | pusty kolumnowy blok zachowany, nic nie zniknęło |
| T7 szeroka siatka 12 kolumn | Tak | 1,00 | 1,00 | brak przesunięcia kolumn w szerokiej tabeli |
W pięciu tabelach, które Docling wykrył, każda wartość z ground truth przeszła dalej — cell recall 1,00 w całej grupie. W trzech z tych pięciu każda wartość trafiła też do właściwego wiersza. W dwóch przypadkach z wielopoziomowym nagłówkiem (T3 i T5) jedna wartość nagłówka przesuwa się ze swojego pierwotnego wiersza, obniżając in-row do 0,97 — wszystkie dane są obecne, tylko przypisanie do wiersza lekko się rozjeżdża przy zagnieżdżonym nagłówku.
Trudniejsze strukturalne przypadki wypadły lepiej, niż się spodziewałem. Dwupoziomowy nagłówek colspan został poprawnie spłaszczony do GitHub-flavored Markdown (etykieta „Q1 2026” powtórzona nad dwoma rozpiętymi kolumnami — i tak właśnie powinno się spłaszczać colspan do GFM). Tabela bez ramek, z samą linią nagłówka (T2), przeszła idealnie. Szeroka tabela 12-kolumnowa (T7) nie przesunęła się. A całkowicie pusta kolumna finansowa (T6) została zachowana jako puste komórki, zamiast zostać usunięta albo scalona. To zgadza się z oficjalnymi wynikami TableFormer TEDS — 95,4 dla prostych, 90,1 dla złożonych, 93,6 dla wszystkich tabel — które model card benchmarkuje wyraźnie powyżej Camelot (73,0) i EDD (88,3).
Ostrożnie z komórkami scalonymi, bo istnieje otwarte zgłoszenie mówiące o czymś przeciwnym. Issue #3698 raportuje, że V1 i V2 źle obsługują scalone wiersze i kolumny. W moich fixture’ach zwykłe colspan (T3/T5) i rowspan były spłaszczane poprawnie, z wyjątkiem wspomnianego przesunięcia wiersza przy wielopoziomowym nagłówku. Ale przypadki z #3698 dotyczą nieregularnych połączeń wielu wierszy i kolumn oraz tabel wielostronicowych — czyli skrajnie problematycznego końca skali. Moje testy dotyczą prostszego końca. Poprawne, precyzyjne stwierdzenie brzmi więc tak: proste colspan i rowspan zostały tu odtworzone poprawnie (wielopoziomowe nagłówki mogą przesunąć wiersz); złożone i nieregularne scalania nadal są znanym, otwartym problemem. Nie: „scalone komórki działają”, ale też nie: „scalone komórki są całkowicie zepsute”.
Pułapka: tabela sama na stronie może zniknąć
Spójrz znowu na tabelę — T1 i T4 nie zostały w ogóle wykryte. Docling wypisał <!-- image --> i zgubił wszystkie komórki, bez żadnego błędu. T1 to zupełnie zwykła tabela 8×5 z ramką. To było na tyle niepokojące, że nie chciałem tego nazwać słabością parsowania tabel, dopóki nie ustaliłem, co dokładnie to wywołuje, więc zrobiłem skryptowy test A/B.
Najpierw wykluczyłem oczywiste wyjaśnienia. Warstwa tekstowa jest nienaruszona — pypdfium2 odczytuje 327 znaków z T1 i 221 z T4, więc to prawdziwe cyfrowe PDF-y, a nie skany. Wyłączenie OCR (do_ocr=False) nie pomaga; tabele nadal znikają. A gdy zajrzałem bezpośrednio do DoclingDocument, okazało się, że len(doc.tables) == 0, podczas gdy len(doc.pictures) == 1 — model układu sklasyfikował cały obszar tabeli jako Picture.
Potem test rozstrzygający. Ponownie wyrenderowałem identyczne tabele T1 i T4, ale tym razem otoczyłem je kilkoma zwykłymi akapitami i znów przekonwertowałem. Obie przeszły perfekcyjnie: len(doc.tables) == 1, poprawnie wygenerowane tabele GFM, a etykieta rowspan „North” w T4b została prawidłowo powtórzona przez trzy wiersze. Ta sama tabela. Jedyna zmienna to to, czy stała sama na pustej stronie, czy była osadzona w tekście.
Czyli prawdziwe zastrzeżenie nie brzmi „TableFormer jest kruchy”, tylko raczej: model układu RT-DETR używa kontekstu strony, a mała tabela sama na niemal pustej stronie może zostać odczytana jako Picture i po cichu wyrzucona. To łatwo spotkać w praktyce, bo właśnie tak wyglądają faktury, specyfikacje i przycięte eksporty: jedna tabela na stronie, bez otaczającego tekstu. Rozwiązanie jest banalne i skuteczne — daj modelowi układu kontekst strony albo po konwersji sprawdzaj doc.tables i oznaczaj strony, gdzie liczba wynosi zero. To jest blisko issue #3495 (tabela wykryta jednocześnie jako Table i Picture), ale sam trigger wynikający z pustej strony — ta sama tabela znika, gdy stoi sama, a działa, gdy jest osadzona w tekście — nie znalazłem nigdzie opisanego. Zmierzone, wcześniej nieudokumentowane; nie jest to błąd, o którym nikt nie wiedział.
OCR na prawdziwych skanach: RapidOCR, nie EasyOCR
Skanowane PDF-y to miejsce, gdzie wiele konwerterów po cichu się wykłada, więc podałem Doclingowi dwa prawdziwe skany z pomierzoną warstwą tekstową 0 znaków — pypdfium2 zwraca zero odzyskiwalnych znaków, co potwierdza, że cały wynik musi pochodzić z OCR, a nie z ukrytej warstwy tekstu.
Jednostronicowy ocr_test.pdf wrócił czysto w 14,3 sekundy na CPU: „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” odzyskane dosłownie. Czterostronicowy nemotron_multipage.pdf uruchomił OCR na wszystkich czterech stronach w 70,1 sekundy łącznie (17,5 s/stronę), wypisując powtórzone zdanie testowe na każdej stronie. Domyślny OCR uruchomił się automatycznie — bez flagi, bez konfiguracji.
Oto szczegół, który większość opisów myli: domyślnym silnikiem OCR jest RapidOCR, a nie EasyOCR. Potwierdziłem to, obserwując pobieranie wag PP-OCRv4 .pth przy pierwszym uruchomieniu. Wiele istniejących blogów i starszych FAQ o Docling nadal twierdzi, że domyślny jest EasyOCR; to już nieaktualne. EasyOCR jest teraz dodatkiem opcjonalnym. Zgadza się natomiast to, że OCR jest wolną ścieżką przy dużej skali, a wszystko tutaj to górny pułap dla CPU-only — GPU znacząco skróciłoby te czasy.
Prawdziwe PDF-y, kolejność czytania i czas na stronę
Zsyntetyzowane fixture’y pokazują konkretne zachowania; prawdziwe PDF-y pokazują, czy to w ogóle działa. Uruchomiłem dwa natywnie cyfrowe teksty akademickie — 9-stronicowy raport techniczny Docling i 15-stronicowy „Attention Is All You Need”, oba w układzie dwukolumnowym z tabelami i wzorami.
W 15-stronicowym tekście Attention wszystkie pięć znaczników sekcji — Abstract, Introduction, Background, Conclusion, References — pojawia się w kolejności dokumentu w linearyzowanym Markdownzie, mimo dwukolumnowego układu. Każdy ważny fragment treści (Transformer, encoder, BLEU, multi-head) jest obecny, a słynne wielokolumnowe tabele wyników są rozpoznane jako cztery wykryte tabele. To realne odzyskanie kolejności czytania i scalenie kolumn, czyli kluczowa wartość dla chunkingu RAG — nie da się sensownie pociąć dokumentu, jeśli linearyzator zamieni dwukolumnową stronę w chaos z przeplotem linii.
Czas pokazuje coś nieoczywistego. Czas na stronę zależy od tego, ile struktury jest na stronie, a nie od samej liczby stron. Gęstszy raport 9-stronicowy działał z prędkością 14,95 sekundy na stronę — wolniej niż 15-stronicowy papier, który miał 5,99 sekundy na stronę — ponieważ ma więcej tabel i figur na stronę — 3 tabele na 9 stronach kontra 4 na 15 — a każdy taki element uruchamia dodatkowe wnioskowanie układu i TableFormer. To mała różnica, a w wartościach bezwzględnych gęstszy dokument ma mniej tabel, nie więcej. Zatem „sekundy na stronę” na CPU zależą od gęstości struktury, nie od długości. To pojedynczy run CPU-only; to pułap, a nie liczba produkcyjna.
Obsługa wielu formatów i obietnica bezstratnego JSON
Docling reklamuje ujednolicone parsowanie wielu formatów, więc wygenerowałem DOCX, XLSX i PPTX ze znaną treścią i znacznikami kontrolnymi, a potem sprawdziłem dwie rzeczy: czy znaczniki pojawiają się w Markdownzie i czy przechodzą przez round-trip JSON przez export_to_dict().
| Plik | Czas konwersji (s) | Znaczniki w MD | Tabele w MD | Znaczniki zachowane w JSON |
|---|---|---|---|---|
report.docx (nagłówki + tabela scalona „Total” + listy) | 0,137 | 7/7 | 1 | Tak |
workbook.xlsx (2 arkusze, pusty kolumnowy blok) | 0,016 | 6/6 | 2 | Tak |
deck.pptx (3 slajdy, listy + tabela) | 0,038 | 6/6 | 1 | Tak |
Wszystkie znaczniki treści trafiły do Markdowna, tabele zostały odtworzone (w tym scalony wiersz „Total” w DOCX i oba arkusze XLSX), a każdy znacznik przetrwał też JSON z export_to_dict() — i to właśnie jest dowód potrzebny do potwierdzenia claimu o bezstronnym, bezstratnym DoclingDocument, przynajmniej dla czystych danych wejściowych. Te formaty przechodzą przez backendy natywne dla danego formatu, a nie przez modele ML, dlatego działają w dziesiątkach milisekund i całkowicie offline. Zakres jest uczciwy: po jednym czystym pliku na format potwierdza szerokość obsługi, ale nie stanowi testu ekstremalnie problematycznych plików Office.
HTML: wierny, ale nieczysty
To właśnie ten caveat decyduje, czy Docling nadaje się do Twojego pipeline’u RAG, więc przeczytaj uważnie. Docling konwertuje cały dokument HTML. Nie robi ekstrakcji głównej treści w stylu readability. Zmierzyłem, ile „chrome’u” strony przetrwało, licząc w wyjściu Doclinga wiersze z nawigacją, TOC, cookies i stopką.
| Strona | Niepustych linii MD | Linii boilerplate | % boilerplate | Artykuł zaczyna się w linii |
|---|---|---|---|---|
| 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 stronie pełnej elementów interfejsu, jak Wikipedia, około 13% linii Markdown to nawigacja/TOC/stopka, a właściwy artykuł zaczyna się dopiero w linii 28 — wynik otwiera się od „move to sidebar / Contents / Toggle the table of contents” i kończy na „CS1 maint… / Search Wikipedia.” Na czystych stronach z treścią (books, quotes) to około 0%, więc to nie jest podatek naliczany od każdej strony, tylko problem szablonowego chrome’u. Docling daje wierny Markdown całego dokumentu, a nie czystą ekstrakcję głównego artykułu. Upstream śledzi problem elementów HTML w issue #1865 (zamknięte) i #1930 (otwarte).
Dwie rzeczy warto tu doprecyzować. Po pierwsze, w samym HTML Docling nie uruchamia żadnych modeli ML — działa na backendzie BeautifulSoup w prostym pipeline. Historia o „modelach wizyjnych czytających stronę” dotyczy tylko PDF-ów i obrazów; jeśli podasz HTML, mechanizmy układu i TableFormer nie odpalają się wcale. Po drugie, ścieżka PDF faktycznie próbuje klasyfikować nagłówki i stopki, więc stwierdzenie „w ogóle nie usuwa boilerplate” byłoby zbyt mocne — to konkretnie backend HTML zwraca ten chrome.
Jak wypada na tle innych narzędzi (i gdzie pasuje Thunderbit)
Wypróbuj Thunderbit do ekstrakcji danych z sieci
Najczęściej porównywanym narzędziem dla Doclinga jest Firecrawl, więc oto tabela pozycjonująca. Jedno zastrzeżenie na start, bo ma znaczenie: to porównanie na poziomie dokumentacji, a nie benchmark na tej samej maszynie. Nie uruchamiałem Firecrawl na tych fixture’ach. Tylko kolumna Doclinga jest tu zmierzona; kolumna Firecrawl pochodzi z publicznej dokumentacji.
| Oś | Firecrawl (według dokumentacji) | Docling (zmierzone tutaj) |
|---|---|---|
| Główne zadanie | Crawlowanie + scraping żywej sieci → Markdown | Konwersja dokumentu, który już masz → Markdown/JSON |
| Pobieranie / render JS / anty-bot | Tak (hostowana przeglądarka) | Nie — dostarczasz plik |
| Ekstrakcja głównej treści | Tak | Nie — wierny pełny dokument (~13% chrome’u na Wikipedii) |
| Struktura tabel w PDF (ML) | ograniczona | Tak — TableFormer (oficjalny TEDS 93,6; cell recall 1,00, in-row 0,97–1,00 na wykrytych fixture’ach) |
| Skanowany PDF / OCR | ograniczone | Tak — RapidOCR domyślnie (odzyskany skan z 0-warstwą tekstową) |
| Zakres formatów | strony WWW | PDF/DOCX/PPTX/XLSX/HTML/EPUB/obrazy |
| Wdrożenie | hostowane API (+ self-host) | lokalna biblioteka pip, offline, bez API key |
| Waga startowa | API key / lekki klient | 1,3 GB domyślnej instalacji + ~506 MiB modeli (albo docling-slim) |
| Licencja | komercyjna / source-available | MIT |
Wersja w jednym zdaniu: Firecrawl to narzędzie, gdy Twoje dane są w żywej sieci i potrzebujesz crawlnięcia, renderowania JS oraz czyszczenia głównej treści. Docling jest narzędziem, gdy dokument już masz — szczególnie PDF-y, skany i Office z dużą liczbą tabel — i chcesz wiernej, offline’owej konwersji zachowującej strukturę oraz rzeczywiste rozumienie tabel i OCR. Te narzędzia się uzupełniają. Realistyczny pipeline crawluje jednym i konwertuje dokumenty drugim.
I tu będę całkiem wprost mówił o Thunderbit, bo pracuję tutaj i słusznie byłbyś podejrzliwy, gdybym udawał coś innego. Thunderbit i Docling nie robią tego samego i nie będę sztucznie ich zrównywał. Dla developerów Thunderbit to AI scraping API plus MCP server plus CLI, a jednostką pracy jest żywa strona WWW: POST /distill zamienia URL w czysty, gotowy dla LLM Markdown (obsługując renderowanie JS, anty-bot i CAPTCHA, których Docling w ogóle nie dotyka), a POST /extract zwraca dopasowany do schematu JSON zdefiniowany przez Twój JSON Schema. To jest etap pobierania i czyszczenia w pipeline RAG. Docling jest etapem lokalnego dokumentu — PDF-a, skanu, arkusza kalkulacyjnego już siedzącego na dysku. Jeśli Twoim źródłem są strony WWW, sięgnij po API Thunderbit, jego narzędzia MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) albo CLI (npx @thunderbit/thunderbit-cli). Jeśli to PDF-y i skany, wybierz Docling. Jeśli jedno i drugie — a tak wygląda większość realnych pipeline’ów — użyj ich razem, bo żadne z nich nie próbuje udawać drugiego.
Werdykt: na razie pozytywny, ale z pracą domową do zrobienia
Nie dam Ci jednej oceny 0–100, bo ważony wynik w tym przypadku dorzuciłby kary za rzeczy, których Docling nigdy nie obiecywał robić (jak crawling), i udawał, że da się to porównać jeden do jednego. Per wymiar, na testowanych fixture’ach:
- Setup / pierwsze uruchomienie: ciężkie — virtualenv 1,3 GB, ~506 MiB modeli, ~224 s pierwszego PDF-a, ~0,55 s po rozgrzaniu — ale
docling-slimpozwala uniknąć tej wagi. - Wierność tabel: mocna, gdy tabela zostanie wykryta (cell recall 1,00 w 5/5, in-row 0,97–1,00), zgodna z oficjalną historią TEDS na tych fixture’ach.
- Niezawodność wykrywania tabel: pułapka pustej strony — izolowana tabela może zniknąć jako Picture. Warto sprawdzać
doc.tablespo konwersji. - Skan / OCR: działa, RapidOCR domyślnie; przy dużej skali wolne.
- Wiele formatów: solidnie, z zachowanym round-trip JSON.
- HTML: wierny, ale nieczysty — bez ekstrakcji głównej treści.
- Developer experience: czyste API w 3 liniach i porządny
DoclingDocument, minus brak__version__.
Dla kogo to jest: dla zespołów budujących RAG albo pipeline’y danych na bazie PDF-ów, skanów i plików Office, które chcą offline’owej konwersji zachowującej strukturę oraz prawdziwego rozumienia tabel i OCR. Dla kogo to nie jest: dla każdego, kto potrzebuje crawlować żywą sieć albo wyciągać czysty główny artykuł z HTML — do tego jest inne narzędzie.
A ponieważ to recenzja, a nie materiał prasowy, ograniczenia zostają na wierzchu. To jest test celowany — 7 syntetycznych tabel plus 2 prawdziwe PDF-y na jednej maszynie CPU-only — a nie benchmark dokładności w skali TEDS. Kilku rzeczy nie testowałem, a powinieneś je sprawdzić, zanim oprzesz na Doclingu swój pipeline: opcjonalną ścieżkę VLM (GraniteDocling), rzeczywisty rozmiar docling-slim, jakikolwiek run na GPU, złożone i nieregularne scalone komórki oraz tabele wielostronicowe, zgodność wzorów z LaTeX-em i — co najłatwiej zaskakuje w produkcji — trio trwałości: narastanie pamięci w batchach, skalowanie przez wątki/GIL oraz cykl życia obiektów przy tysiącach konwersji. Docling jest mocny tam, gdzie twierdzi, że jest mocny, a nie marketingowo „wszędzie”, i ma realne krawędzie, które warto zmapować, zanim mu zaufasz na całym korpusie. Znaj sparse-page caveat, zaplanuj budżet na pierwsze pobranie i sam sprawdź zachowanie przy skali.
Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free
FAQ
Czy Docling jest web scraperem albo crawlerem? Nie. Docling konwertuje dokumenty, które już masz — PDF, DOCX, PPTX, XLSX, HTML, obrazy — do Markdown albo JSON. Nie pobiera URL-i, nie renderuje JavaScriptu i nie obsługuje anty-bot. Crawlowanie żywej sieci to osobne zadanie realizowane przez narzędzia takie jak Firecrawl albo web API Thunderbit; Docling startuje od pliku, który mu podasz.
Jak duża jest instalacja Docling i pobranie przy pierwszym uruchomieniu?
Domyślny metapakiet docling daje około 1,3 GB virtualenv, bo pobiera cały stos ML jako twarde zależności (sam torch to 536 MiB). Pierwsza konwersja PDF-a pobiera około 506 MiB modeli układu i TableFormer na dysk plus około 40 MB wag RapidOCR i trwa około 224 sekund — prawie wyłącznie na pobieranie. Druga konwersja to około 0,55 sekundy. Jeśli potrzebujesz tylko lekkich formatów, docling-slim (około 50 MB rdzenia) omija ciężką ścieżkę.
Czy Docling robi OCR i z jakim silnikiem? Tak. Na zeskanowanym PDF-ie bez warstwy tekstowej OCR uruchamia się automatycznie i w moim teście odzyskał tekst bez problemu. Domyślnym silnikiem jest RapidOCR, a nie EasyOCR — to częsty błąd w starszych opisach. EasyOCR jest teraz dodatkiem opcjonalnym. OCR to wolna ścieżka przy dużej skali, szczególnie na CPU.
Dlaczego Docling zamienił moją tabelę w obraz albo ją zgubił?
Najbardziej prawdopodobny powód to efekt pustej strony. Model układu RT-DETR w Docling używa kontekstu strony, a mała tabela stojąca samotnie na niemal pustej stronie może zostać sklasyfikowana jako Picture i wyrzucona bez błędu. Ta sama tabela otoczona tekstem działa poprawnie. Rozwiązaniem jest dostarczenie modelowi większego kontekstu strony albo sprawdzenie doc.tables po konwersji i oznaczenie każdej strony, gdzie liczba wynosi zero.
Docling vs Firecrawl — czego użyć? To różne zadania, więc zwykle nie chodzi o wybór albo-albo. Firecrawl crawluje żywą sieć, renderuje JavaScript i wyciąga główną treść. Docling konwertuje dokumenty, które już masz, z prawdziwą strukturą tabel PDF i OCR, całkowicie offline. Jeśli źródłem są strony WWW, użyj narzędzia webowego (Firecrawl albo API/MCP/CLI Thunderbit). Jeśli to PDF-y, skany albo pliki Office, użyj Docling. W większości realnych pipeline’ów stosuje się oba.
