Recenzja Docling: Co tak naprawdę robi konwerter dokumentów IBM z plikami PDF

Docling często trafia do jednego worka z web scraperami, ale nim nie jest. To zestaw narzędzi do konwersji dokumentów stworzony przez 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. Ich własne hasło brzmi dosłownie: „Get your documents ready for gen AI.”

To więc praktyczna recenzja konwertera, a nie crawlera. Wszystko poniżej zostało zmierzone na jednym komputerze z samym CPU (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 zmienia się codziennie — 63 069 gwiazdek, 4 449 forków i push tego samego dnia, w którym pobrałem metadane — więc każdą liczbę związaną z wersją czy liczbą problemów traktuj raczej jako migawkę niż stałą wartość.

Czym Docling jest, a czym nie jest

Podstawową jednostką w Docling jest DoclingDocument: najpierw parsujesz plik do tej struktury, a potem eksportujesz do Markdown, HTML, DocTags albo bezstratnego JSON-a. Kod jest na licencji MIT (licencje poszczególnych modeli mogą się różnić), projekt powstał w IBM Research Zurich, a w chwili pisania tego tekstu najnowszym wydaniem jest 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 — to cały stos modeli uczenia maszynowego: model układu RT-DETR, model struktury tabel TableFormer, opcjonalny model vision-language oraz RapidOCR do skanów. Te modele odtwarzają układ strony, kolejność czytania i strukturę tabel. To właśnie ten obszar warto ocenić, i właśnie tego nie pokaże test ograniczony wyłącznie do HTML.

Jest jeszcze jedno rozróżnienie, które oszczędza tydzień chaosu. Docling niczego nie pobiera z internetu. Nie renderuje JavaScriptu, nie przebija się przez anty-botowe blokady, nie crawluje. Ty dostarczasz plik, on go rozumie. Crawlowanie to zadanie innego narzędzia — i to ważne później, kiedy ktoś pyta, czy Docling zastępuje Firecrawl (nie zastępuje — te narzędzia się uzupełniają, a za chwilę wyjaśnię dlaczego).

Pierwsze uruchomienie, o którym nikt nie ostrzega

pip install docling przechodzi bez problemu na Pythonie 3.14.2. Potem patrzysz na virtualenv i widzisz 1,3 GB. Docling ściąga cały stos ML jako twarde zależności, nawet jeśli masz zamiar konwertować wyłącznie 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)	75.6
docling_parse	30

A to wszystko jeszcze zanim przekonwertujesz pierwszy PDF. Prawdziwe tarcie pojawia się przy pierwszej konwersji PDF-a, bo wtedy pobierane są modele. Na świeżym, odizolowanym cache HuggingFace pierwsza konwersja PDF-a zajęła około 224 sekund — i niemal cały ten czas to pobieranie, a nie obliczenia. Modele układu i TableFormer zajmują na dysku łącznie około 506 MiB (342 MiB TableFormer + 164 MiB model układu, potwierdzone 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ą cache’owane; płacisz za to tylko raz.

Jedną liczbę powinieneś zignorować: skrypt cold start wypisuje model_download_mb równe 1060,2. Nie cytuj tego jako rzeczywistego footprintu. To wynik os.walk, które podąża za symlinkami, a cache HuggingFace zapisuje każdy plik modelu raz w blobs/, a następnie udostępnia go ponownie przez symlink w snapshots/ — więc przejście liczy 14 plików modelu dwa razy. Prawidłowy, zgodny z du wynik po odduplikowaniu symlinków to około 506 MiB (same blobs to 505,4 MiB). Wniosek dla osób benchmarkujących Docling: rozdzielaj pobrane bajty i faktyczny rozmiar na dysku, bo to nie jest to samo.

Jest też druga pułapka, która uderza każdego, kto buduje kontener z Docling. Wagi rozkładają się na dwa miejsca i według dwóch harmonogramów. 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 z wyprzedzeniem albo pracujesz w środowisku air-gapped, musisz obsłużyć oba cache’e, a samo ustawienie HF_HOME nie wystarczy.

Teraz uczciwa część. W nowszych wydaniach projektu pojawił się docling-slim — rdzeń o rozmiarze około 50 MB, który pozwala wykonać pip install docling-slim[format-html] dla HTML-a bez dociągania torch. Czyli 1,3 GB dla domyślnego pakietu docling to realna wartość, ale dziś jest to opcja do wyłączenia. Testowałem domyślny pakiet, bo to nadal właśnie on instaluje się po pip install docling, ale ciężar nie jest już niezaadresowaną wadą — modularne rozwiązanie istnieje i jest śledzone w issue #2393.

Podczas konfiguracji trafił mi się jeszcze jeden drobiazg wart odnotowania: import docling; docling.__version__ zwraca AttributeError: module 'docling' has no attribute '__version__'. Moduł po prostu tego nie udostępnia. Działający sposób to importlib.metadata.version("docling"), który zwraca '2.111.0'. To drobna niedogodność dla developerów, otwarta w upstreamie od lipca 2026 jako issue #3733.

Wierność tabel: tam, gdzie TableFormer naprawdę się przydaje

Tabele są głównym powodem, dla którego ktoś sięga po Docling zamiast zwykłego zrzutu PDF-to-text, więc przygotowałem siedem tabel PDF z maszynowo czytelnym ground truth i oceniłem wynik komórka po komórce. Liczą się dwie metryki i nie są one tym samym: cell recall to odsetek wartości z ground truth obecnych gdziekolwiek w wykrytej tabeli; in-row rate to odsetek, który trafił do właściwego wiersza. Mieszanie tych pojęć zawyża ocenę narzędzia, więc pokazuję oba wyniki:

Tabela (test)	Wykryta	Cell recall	In-row rate	Uwagi
T1 prosta tabela z obramowaniem (5×8), samotna na stronie	Nie	0.0	—	sklasyfikowana jako <!-- image -->, wszystkie komórki pominięte
T2 bez obramowania (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 etykiety rowspan, samotny na stronie	Nie	0.0	—	sklasyfikowana jako <!-- image -->
T5 nagłówek colspan + brak obramowania	Tak	1.00	0.97	wszystkie wartości znalezione; ten sam przesunięty wiersz nagłówka co w T3
T6 finanse, pusty kolumna, wyrównanie do prawej	Tak	1.00	1.00	pusta kolumna zachowana, bez przesunięć
T7 szeroka siatka 12-kolumnowa	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 poprawnie — cell recall 1.00 dla wszystkich. 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 zjeżdża z oryginalnego wiersza, obniżając in-row rate do 0.97 — dane są obecne, tylko przypisanie do wiersza lekko się rozjeżdża przy warstwowym nagłówku.

Trudniejsze przypadki strukturalne wypadły lepiej, niż się spodziewałem. Dwupoziomowy nagłówek colspan został poprawnie spłaszczony do GitHub-flavored Markdown (etykieta „Q1 2026” powtarza się nad obydwiema spójnymi kolumnami, co jest właściwym sposobem spłaszczenia colspan do GFM). Tabela bez obramowania, z samą linią nagłówka (T2), przeszła bezbłędnie. Szeroka tabela 12-kolumnowa (T7) nie przesunęła się. A całkowicie pusta kolumna finansowa (T6) została zachowana jako puste komórki, a nie usunięta czy scalona. To jest zgodne z oficjalnymi wynikami TEDS TableFormer — 95,4 dla prostych, 90,1 dla złożonych, 93,6 łącznie — które karta modelu benchmarkuje znacznie powyżej Camelot (73,0) i EDD (88,3).

Warto zachować ostrożność przy scalonych komórkach, bo istnieje otwarty issue, który sugeruje coś przeciwnego. Issue #3698 zgłasza, że V1 i V2 źle obsługują scalone wiersze i kolumny. W moich testach proste colspan (T3/T5) i wartości rowspan zostały spłaszczone poprawnie, z wyjątkiem wspomnianego przesunięcia wiersza przy wielopoziomowym nagłówku. Ale przypadki z #3698 dotyczą nieregularnych scalonych układów wielu wierszy i kolumn oraz tabel wielostronicowych — czyli najbardziej patologicznego końca spektrum. Moje testy dotyczą prostszego końca. Precyzyjny wniosek brzmi więc tak: proste colspan i rowspan zostały tu poprawnie odzyskane (wielopoziomowe nagłówki mogą przesunąć wiersz); złożone i nieregularne scalania pozostają znanym otwartym problemem. Nie „scalone komórki działają”, nie „scalone komórki są zepsute”.

Pułapka: tabela sama na stronie może zniknąć

Spójrz jeszcze raz na tabelę — T1 i T4 w ogóle nie zostały wykryte. Docling zwrócił <!-- image --> i bez żadnego błędu usunął wszystkie komórki. T1 to zwyczajna, obramowana siatka 5×8. 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 przygotowałem test A/B w skrypcie.

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) nic nie zmienia; tabele nadal znikają. A gdy zajrzałem bezpośrednio do DoclingDocument, okazało się, że len(doc.tables) == 0, a 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, tym razem otoczone kilkoma zwykłymi akapitami tekstu, i znów je przekonwertowałem. Obie przeszły perfekcyjnie: len(doc.tables) == 1, wygenerowane poprawne tabele GFM, a etykieta „North” w T4b z rowspan poprawnie powtórzyła się w trzech wierszach. Ta sama tabela. Zmienna była tylko jedna — czy stała samotnie na skąpo zapełnionej stronie, czy była osadzona w tekście.

Czyli prawdziwe zastrzeżenie nie brzmi „TableFormer jest kruchy”, tylko: model układu RT-DETR w Doclingu korzysta z kontekstu strony, a mała tabela sama na niemal pustej stronie może zostać uznana za obraz i po cichu pominięta. W praktyce łatwo na to trafić, bo właśnie tak wyglądają faktury, specyfikacje i przycięte eksporty: jedna tabela na stronę, bez otaczającego tekstu. Naprawa jest prosta i skuteczna — daj modelowi układu kontekst strony albo po konwersji sprawdź doc.tables i oznacz strony, gdzie liczba tabel wynosi zero. To jest blisko issue #3495 (tabela wykryta jednocześnie jako Table i Picture), ale konkretny trigger związany z pustą stroną — ta sama tabela znika jako samotna, a działa po dodaniu tekstu — nie znalazłem nigdzie wcześniej opisany. Zmierzone, wcześniej nieudokumentowane; nie bug, 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 zmierzonym tekstem o długości 0 znaków — pypdfium2 zwraca zero odzyskiwalnych znaków, co potwierdza, że każdy wynik to OCR, a nie ukryta warstwa tekstowa.

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, zajmując łącznie 70,1 sekundy (17,5 s/stronę), i wypisał powtarzające się zdanie testowe na każdej stronie. OCR uruchomił się automatycznie — bez flagi, bez konfiguracji.

Jeden 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 tekstów FAQ o Doclingu nadal twierdzi, że domyślny jest EasyOCR; to już nieaktualne. EasyOCR jest dziś dodatkiem, który trzeba świadomie włączyć. Zostaje za to prawdą jedno zastrzeżenie: OCR jest wolną ścieżką przy skali, a wszystko tutaj to pułapka wydajności na CPU — GPU znacząco skróciłoby te czasy.

Prawdziwe PDF-y, kolejność czytania i czas na stronę

Syntetyczne testy pokazują konkretne zachowania; prawdziwe PDF-y pokazują, czy to naprawdę działa. Uruchomiłem dwa natywnie cyfrowe artykuły naukowe — 9-stronicowy raport techniczny Docling oraz 15-stronicowy „Attention Is All You Need”, oba w dwóch kolumnach, z tabelami i wzorami.

W 15-stronicowym artykule o Attention wszystkie pięć znaczników sekcji — Abstract, Introduction, Background, Conclusion, References — pojawia się w kolejności dokumentu w liniowym Markdownzie, mimo układu dwukolumnowego. Każdy sprawdzany termin (Transformer, encoder, BLEU, multi-head) jest obecny, a słynne wielokolumnowe tabele wyników zostały wykryte jako cztery osobne tabele. To realne odzyskanie kolejności czytania i scalenia kolumn, czyli sedno wartości dla chunkingu pod RAG — nie da się sensownie pociąć dokumentu, jeśli linearizer zamienia dwukolumnową stronę w bezsensowną mieszankę tekstu.

Timing daje zaskakującą lekcję. Czas na stronę zależy od ilości struktury na stronie, a nie od samej liczby stron. Gęstszy 9-stronicowy raport działał z prędkością 14,95 sekundy na stronę — wolniej niż 15-stronicowy artykuł, który miał 5,99 sekundy na stronę — ponieważ zawiera więcej tabel i ilustracji, a każda z nich uruchamia dodatkowe wnioskowanie układu i TableFormer. Czyli „sekundy na stronę” na CPU to funkcja gęstości struktury, a nie długości dokumentu. To pojedynczy test na CPU-only; to górny limit, nie liczba produkcyjna.

Wiele formatów i obietnica bezstratnego JSON-a

Docling reklamuje jednolite parsowanie wielu formatów, więc wygenerowałem DOCX, XLSX i PPTX ze znaną zawartością oraz punktami kontrolnymi ground truth, a potem sprawdziłem dwie rzeczy: czy te punkty pojawiają się w Markdownie i czy przechodzą przez round-trip do JSON-a przez export_to_dict().

Plik	Konwersja s	Znalezione punkty w MD	Tabele w MD	Punkty przechodzą do JSON
report.docx (nagłówki + scalona tabela „Total” + wypunktowania)	0.137	7/7	1	Tak
workbook.xlsx (2 arkusze, pusta kolumna)	0.016	6/6	2	Tak
deck.pptx (3 slajdy, wypunktowania + tabela)	0.038	6/6	1	Tak

Wszystkie punkty kontrolne trafiły do Markdowna, tabele zostały odzyskane (w tym scalony wiersz „Total” z DOCX-a i oba arkusze XLSX), a każdy punkt przeszedł też przez JSON z export_to_dict() — i to jest dowód istotny dla obietnicy bezstratnego DoclingDocument, przynajmniej na czystych wejściach. Te formaty idą przez natywne backendy, a nie przez modele ML, dlatego działają w dziesiątkach milisekund i w pełni offline. Zakres jest uczciwy: jeden czysty plik na format pokazuje szerokość wsparcia, a nie test patologicznych plików Office.

HTML: wiernie, ale nie czyściutko

To właśnie ta uwaga decyduje, czy Docling nadaje się do Twojego pipeline’u RAG, więc przeczytaj ją uważnie. Docling konwertuje cały dokument HTML. Nie robi ekstrakcji głównej treści w stylu readability. Zmierzyłem, ile elementów nawigacji i szablonu przechodzi do wyniku, licząc linie z oznaczeniami nav, spisu treści, cookies i stopki w wyjściu samego Doclinga.

Strona	Niepustych linii MD	Linie 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 z dużą ilością szablonu, jak Wikipedia, około 13% linii Markdowna to boilerplate z nawigacji/spisu treści/stopki, a prawdziwy artykuł zaczyna się dopiero w linii 28 — wynik otwiera się od „move to sidebar / Contents / Toggle the table of contents”, a kończy na „CS1 maint… / Search Wikipedia.” Na czystych stronach z treścią (books, quotes) to około 0%, więc to problem szablonu, a nie podatek nakładany na każdą stronę. Docling daje wierny Markdown całego dokumentu, a nie czystą ekstrakcję samego artykułu. W upstreamie problem mebli HTML jest śledzony w issue #1865 (zamknięte) i #1930 (otwarte).

Dwie rzeczy sprawiają, że ocena pozostaje uczciwa. Po pierwsze, dla HTML-a Docling nie uruchamia żadnych modeli ML — działa na backendzie BeautifulSoup w prostym pipeline. Historia o „modelach widzących Twoją stronę” dotyczy tylko PDF-ów i obrazów; jeśli podasz Doclingowi HTML, żaden mechanizm układu ani TableFormer nie rusza. 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 właśnie backend HTML zwraca cały ten szkielet strony.

Jak wypada na tle innych narzędzi i gdzie pasuje Thunderbit

Wypróbuj Thunderbit do ekstrakcji danych z internetu

Narzędziem, do którego ludzie najczęściej porównują Docling, jest Firecrawl, więc poniżej tabela pozycjonująca. Jedna uwaga na start, bo to ważne: to porównanie na poziomie dokumentacji, a nie benchmark na tym samym komputerze. Nie uruchamiałem Firecrawl na tych samych testach. Tylko kolumna Docling jest tutaj zmierzona; kolumna Firecrawl pochodzi z publicznej dokumentacji.

Oś	Firecrawl (wg dokumentacji)	Docling (zmierzone tutaj)
Główne zadanie	Crawl + scrape żywego webu → Markdown	Konwersja dokumentu, który już masz → Markdown/JSON
Pobieranie / render JS / anty-bot	Tak (hostowana przeglądarka)	Nie — sam dostarczasz plik
Ekstrakcja głównej treści	Tak	Nie — wierny pełny dokument (~13% boilerplate na Wikipedii)
Struktura tabel PDF (ML)	ograniczona	Tak — TableFormer (oficjalny TEDS 93.6; cell recall 1.00, in-row 0.97–1.00 na wykrytych testach)
Skan PDF / OCR	ograniczone	Tak — RapidOCR domyślnie (odzyskany skan z zerową 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 klucza API
Waga konfiguracji	klucz API / lekki klient	1,3 GB instalacji domyślnej + ~506 MiB modeli (albo docling-slim)
Licencja	komercyjna / source-available	MIT

W skrócie: Firecrawl wybierasz wtedy, gdy dane są na żywym webie i trzeba je crawlować, renderować JS i czyścić z głównej treści. Docling wybierasz wtedy, gdy dokument już masz — szczególnie PDF-y, skany i Office z dużą liczbą tabel — i zależy Ci na wiernej, offline’owej konwersji zachowującej strukturę oraz prawdziwym rozumieniu tabel i OCR. Te narzędzia się uzupełniają. Realny pipeline crawluje jednym i konwertuje dokumenty drugim.

W tym miejscu powiem wprost o Thunderbit, bo pracuję tutaj i słusznie byłbyś podejrzliwy, gdybym udawał coś innego. Thunderbit i Docling nie robią tego samego i nie zamierzam na siłę udawać, że jest inaczej. Dla developerów Thunderbit to AI scraping API + serwer MCP + CLI, a jego jednostką pracy jest żywa strona WWW: POST /distill zamienia URL w czysty Markdown gotowy dla LLM-ów (obsługując renderowanie JS, anty-bot i CAPTCHA, których Docling w ogóle nie dotyka), a POST /extract zwraca strukturalny JSON zgodny ze schematem, który sam definiujesz w JSON Schema. To jest etap pobierania i czyszczenia w pipeline RAG. Docling jest lokalnym etapem dokumentowym — PDF, skan, arkusz kalkulacyjny już leżący na dysku. Jeśli Twoim korpusem 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 chodzi o PDF-y i skany, wybierz Docling. Jeśli chodzi o oba typy danych — a tak wygląda większość realnych pipeline’ów — łączysz je, i żadne z tych narzędzi nie próbuje być drugim.

Werdykt: wstępny, z zadaniem domowym do zrobienia

Nie dam Ci jednej oceny 0–100, bo ważona suma mieszałaby kary za rzeczy, których Docling nigdy nie obiecywał (jak crawling), i udawałaby, że są porównywalne. Per wymiar, na testach, które wykonałem:

• Konfiguracja / pierwsze uruchomienie: ciężkie — virtualenv 1,3 GB, modele ~506 MiB, pierwszy PDF ~224 s, warm ~0,55 s — ale docling-slim pozwala tę wagę ominąć.
• Wierność tabel: mocna, gdy tabela zostanie wykryta (cell recall 1.00 w 5/5, in-row 0.97–1.00), zgodnie z oficjalną historią TEDS na tych testach.
• Odporność wykrywania tabel: pułapka skąpej strony — samotna tabela może zniknąć jako Picture. Po konwersji sprawdzaj doc.tables.
• Skan / OCR: działa, RapidOCR domyślnie; wolne przy skali.
• Wiele formatów: solidnie, a round-trip JSON pozostaje nienaruszony.
• HTML: wiernie, ale nie czyściutko — bez ekstrakcji głównej treści.
• Doświadczenie deweloperskie: prosty, 3-linijkowy API i uporządkowany DoclingDocument, minus brak __version__.

Dla kogo to jest: dla zespołów budujących RAG albo pipeline’y danych na PDF-ach, skanach i plikach 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 crawlowania żywego webu albo czystej ekstrakcji głównego artykułu z HTML — to zadanie dla innego narzędzia.

A ponieważ to recenzja, a nie materiał promocyjny, ograniczenia zostają na etykiecie. To jest test punktowy — 7 syntetycznych tabel i 2 prawdziwe PDF-y na jednym komputerze CPU-only — a nie benchmark dokładności na poziomie TEDS. Kilku rzeczy nie testowałem i Ty też powinieneś, zanim zaufasz Doclingowi w pipeline produkcyjnym: opcjonalnej ścieżki VLM (GraniteDocling), rzeczywistego footprintu docling-slim, jakiegokolwiek uruchomienia na GPU, złożonych i nieregularnych scalonych komórek oraz tabel wielostronicowych, zgodności wzorów z LaTeX-em oraz — najłatwiejszego do przeoczenia w produkcji — trwałości przyrostu pamięci w batchach, skalowania z wątkami/GIL i cyklu życia obiektów przy tysiącach konwersji. Docling jest mocny w tym, co deklaruje, i daje się mierzyć, a nie sprzedawać hasłami, ale ma też realne ograniczenia, które warto znać, zanim zaufasz mu swoim korpusem. Znaj sparsity-page caveat, zaplanuj pobranie przy pierwszym uruchomieniu i sam sprawdź zachowanie przy dużej skali.

Wypróbuj Thunderbit do ekstrakcji danych z internetu Get Started Free

FAQ

Czy Docling to web scraper albo crawler? 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ów. Crawlowanie żywego internetu to osobne zadanie wykonywane 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 pierwsze pobranie modeli? Domyślny pakiet docling tworzy virtualenv o wielkości około 1,3 GB, ponieważ ściąga pełny 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 — niemal wyłącznie z powodu pobierania. Druga konwersja trwa około 0,55 sekundy. Jeśli potrzebujesz tylko lekkich formatów, docling-slim (rdzeń ~50 MB) omija ciężką ścieżkę.

Czy Docling robi OCR i jakiego używa silnika? Tak. Na zeskanowanym PDF-ie bez warstwy tekstowej OCR uruchamia się automatycznie i w moim teście poprawnie odzyskał tekst. Domyślnym silnikiem jest RapidOCR, nie EasyOCR — to częsty błąd w starszych opisach. EasyOCR jest dziś dodatkiem włączanym opcjonalnie. OCR jest wolny przy skali, szczególnie na CPU.

Dlaczego Docling zamienił moją tabelę w obraz albo ją pominął? Najprawdopodobniej zadziałał efekt skąpej strony. Model układu RT-DETR w Doclingu używa kontekstu strony, a mała tabela stojąca sama na niemal pustej stronie może zostać sklasyfikowana jako Picture i zniknąć bez błędu. Ta sama tabela otoczona tekstem działa poprawnie. Rozwiązanie: daj modelowi układu kontekst strony albo po konwersji sprawdzaj doc.tables i oznaczaj strony, na których liczba tabel wynosi zero.

Docling vs Firecrawl — którego użyć? To różne zadania, więc zwykle nie chodzi o wybór „albo-albo”. Firecrawl crawluje żywy web, renderuje JavaScript i wyciąga główną treść. Docling konwertuje dokumenty, które już masz, z prawdziwą strukturą tabel PDF i OCR, w pełni offline. Jeśli źródłem są strony WWW, użyj narzędzia webowego (Firecrawl albo API/MCP/CLI Thunderbit). Jeśli są to PDF-y, skany lub pliki Office, użyj Docling. W większości realnych pipeline’ów oba narzędzia pracują razem.