Docling päätyy usein samaan lokeroon verkkokaapijoiden kanssa, vaikka se ei ole sellainen. Kyseessä on IBM Researchin dokumenttien muunnostyökalu — nykyisin LF AI & Data Foundation -hankkeena — joka ottaa jo hallussasi olevat tiedostot (PDF, DOCX, PPTX, XLSX, HTML, kuvat) ja muuntaa ne Markdowniksi tai JSONiksi. Sen oma slogan on kirjaimellisesti: "Get your documents ready for gen AI."
Tämä on siis käytännönläheinen arvio muuntimesta, ei crawlerista. Kaikki alla oleva mitattiin yhdellä CPU-only-koneella (macOS arm64, Python 3.14.2, Docling 2.111.0), tulokset pisteytettiin skripteillä ja virheet kirjattiin virheinä. Repositorio on valtava ja kehittyy jatkuvasti — 63 069 tähteä, 4 449 forkkausta ja push samana päivänä, kun noudin metadatan — joten suhtaudu tässä näkyviin ongelmamääriin ja versioihin tilannekuvana, ei vakiona.
Mitä Docling oikeasti on — ja mitä se ei ole
Kaiken Doclingissa keskiössä on DoclingDocument: tiedosto parsitaan siihen rakenteeseen ja viedään sitten Markdowniksi, HTML:ksi, DocTagseiksi tai häviöttömäksi JSONiksi. Koodi on MIT-lisensoitu (yksittäiset mallilisenssit vaihtelevat), se sai alkunsa IBM Research Zurichissa, ja tätä kirjoittaessa uusin julkaisu on v2.112.0, julkaistu kaksi päivää ennen tätä testiä.
Päänäkyvin ominaisuus on PDF- ja kuvapolku. Se ei ole merkkijonopohjaista purkamista — vaan koneoppimismallien pino: RT-DETR-asettelumalli, TableFormer -taulukkorakennemalli, valinnainen vision-language-malli sekä RapidOCR skannauksille. Nämä mallit palauttavat sivuasettelun, lukujärjestyksen ja taulukkorakenteen. Juuri sitä kannattaa arvioida, eikä sitä näkisi koskaan HTML-only-testissä.
Yksi ero säästää helposti viikon väärinkäsityksiltä. Docling ei hae mitään. Se ei renderöi JavaScriptiä, se ei läpäise bottisuojauksia eikä se crawlata. Sinä tuot tiedoston, se ymmärtää sen. Crawlauksen hoitaa eri työkalu, ja sillä on merkitystä myöhemmin, kun joku kysyy korvaako Docling Firecrawl’n (ei korvaa — ne täydentävät toisiaan, ja palaan siihen myöhemmin).
Ensimmäinen ajo, josta kukaan ei varoita
pip install docling onnistuu siististi Python 3.14.2:ssa. Sitten katsot virtuaaliympäristöä, ja se on 1,3 GB. Docling vetää koko ML-pinon kovina riippuvuuksina, vaikka muuttaisit vain HTML-tiedoston:
| Riippuvuus | Levykoko (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ mukana tulevat mallit) | 75,6 |
| docling_parse | 30 |
Tämäkin on vasta ennen kuin yksikään PDF on muunnettu. Ensimmäinen PDF-muunnos on se hetki, jolloin oikea kitka tuntuu, koska silloin mallit ladataan. Tuoreessa, eristetyssä HuggingFace-välimuistissa ensimmäinen PDF-muunnos vei noin 224 sekuntia — ja lähes kaikki siitä oli latausta, ei laskentaa. Layout- ja TableFormer-mallit vievät levyltä yhdessä noin 506 MiB (342 MiB TableFormer + 164 MiB layout, du-varmennettuina), ja RapidOCR hakee noin 40 MB PP-OCRv4-painoja site-packages-hakemistoon. Sama tiedosto toiseen kertaan? 0,55 sekuntia. Malleihin tehdään vain yksi maksullinen lataus; sen jälkeen ne ovat välimuistissa.
Yksi luku, jonka voit unohtaa: kylmäkäynnistysskripti tulostaa model_download_mb-arvoksi 1060,2. Älä siteeraa sitä jalanjälkenä. Se syntyy os.walk-kierrosta, joka seuraa symlinkkejä, ja HuggingFace-välimuisti tallentaa jokaisen mallitiedoston kerran blobs/-hakemistoon ja näyttää sen sitten uudelleen snapshots/-symlinkkinä — joten läpikäynti laskee 14 mallitiedostoa kahdesti. du-vastineinen, symlinkit poistava luku on noin 506 MiB (pelkät blobsit 505,4 MiB). Doclingia vertaavalle tärkeä opetus: ilmoita latausmäärä ja levyllä oleva koko erillisinä lukuina, koska ne ovat eri asioita.
Toinen yksityiskohta iskee helposti Docling-konttia rakentavaan. Painot jakautuvat kahteen paikkaan eri aikataululla. Layout- ja TableFormer-mallit noudattavat HF_HOME-asetusta ja latautuvat ensimmäisellä PDF-muunnoksella. RapidOCR:n mallit eivät — ne päätyvät …/site-packages/rapidocr/models/-polkuun ja ohittavat välimuistiasetuksesi kokonaan. Jos rakennat kuvaa valmiiksi tai tarvitset air-gapped-ympäristöä, sinun on huomioitava molemmat välimuistit, eikä HF_HOME:n asettaminen yksin riitä.
Reiluuden vuoksi: aiempien Docling-julkaisujen jälkeen projekti toi mukaan docling-slim -vaihtoehdon — noin 50 MB:n ytimen, jonka avulla voit asentaa pip install docling-slim[format-html] HTML-käyttöön ilman torchia. Niinpä 1,3 GB:n paino on totta oletuspaketissa docling, mutta se on nykyään valinnainen. Testasin oletuspakettia, koska juuri sen pip install docling edelleen antaa, mutta raskaus ei ole korjaamaton ongelma — modulaarinen ratkaisu on olemassa ja seurannassa issue #2393:ssa.
Asennuksen aikana törmäsin yhteen pieneen mutta mainitsemisen arvoiseen ärsytykseen: import docling; docling.__version__ heittää virheen AttributeError: module 'docling' has no attribute '__version__'. Moduuli ei yksinkertaisesti paljasta versiota sillä tavalla. Toimiva tapa on importlib.metadata.version("docling"), joka palauttaa '2.111.0'. Pieni kehittäjäkokemuksen miinus, yhä auki upstreamissa heinäkuusta 2026 alkaen issue #3733:ssa.
Taulukoiden tarkkuus: missä TableFormer todella ansaitsee paikkansa
Taulukot ovat syy siihen, miksi kukaan tarttuu Doclingiin tavallisen PDF->teksti-dumppauksen sijaan, joten tein seitsemästä taulukkopohjaisesta PDF:stä koneellisesti luettavan totuuden ja pisteytin tulokset solu solulta. Kaksi mittaria on tärkeää, eikä ne ole sama asia: cell recall tarkoittaa sitä osuutta totuusarvoista, joka löytyy jostain havaitusta taulukosta; in-row rate tarkoittaa osuutta, joka osuu oikealle riville. Näiden sekoittaminen kaunistelisi tulosta, joten tässä molemmat:
| Taulukko (stressitesti) | Havaittu | Cell recall | In-row rate | Huomio |
|---|---|---|---|---|
| T1 tavallinen reunustettu 5×8-ruudukko, yksin sivulla | Ei | 0,0 | — | luokiteltu <!-- image -->-merkinnäksi, kaikki solut katosivat |
| T2 reunaton (vain otsikkoviiva) | Kyllä | 1,00 | 1,00 | täydellinen, täsmällinen ruudukko |
| T3 yhdistetty 2-tasoinen colspan-otsikko | Kyllä | 1,00 | 0,97 | kaikki arvot löytyivät; yksi otsikkoarvo siirtyi rivillä |
| T4 rowspan-rivimerkintä, yksin sivulla | Ei | 0,0 | — | luokiteltu <!-- image -->-merkinnäksi |
| T5 colspan-otsikko + reunaton | Kyllä | 1,00 | 0,97 | kaikki arvot löytyivät; sama rivisiirtymä kuin T3:ssa |
| T6 talousluvut, tyhjä sarake, oikealle tasattu | Kyllä | 1,00 | 1,00 | tyhjä sarake säilyi eikä siirtynyt |
| T7 leveä 12-sarakkeinen ruudukko | Kyllä | 1,00 | 1,00 | sarakkeet eivät siirtyneet leveässä taulukossa |
Niissä viidessä taulukossa, jotka Docling tunnisti, jokainen totuusarvo tuli läpi — cell recall 1,00 kautta linjan. Kolmessa noista viidestä jokainen arvo myös päätyi oikealle riville. Kahdessa monitasoisen otsikon tapauksessa (T3 ja T5) yksi otsikkoarvo luiskahtaa alkuperäiseltä riviltään, jolloin in-row putoaa arvoon 0,97 — kaikki data on mukana, mutta rivijaottelu horjuu yhdellä pinotussa otsikossa.
Vaikeat rakenteelliset tapaukset kestivät paremmin kuin odotin. Kaksitasoinen colspan-otsikko litistyi oikein GitHub-flavored Markdowniksi ("Q1 2026" -merkintä toistui kahden laajennetun sarakkeensa yllä, mikä on oikea tapa purkaa colspan GFM-muotoon). Reunaton ruudukko, jossa oli vain otsikkoviiva (T2), tuli läpi täsmälleen oikein. Leveä 12-sarakkeinen taulukko (T7) ei siirtynyt. Ja täysin tyhjä taloussarake (T6) säilyi tyhjinä soluina sen sijaan, että se olisi pudotettu tai litistetty. Tämä on linjassa TableFormerin virallisten TEDS-tulosten kanssa — 95,4 simple, 90,1 complex, 93,6 all-tables — ja mallikortti vertaa niitä selvästi Camelotiin (73,0) ja EDD:hen (88,3).
Yksi varoitus yhdistetyistä soluista, koska avoin issue väittää päinvastaista. Issue #3698 kertoo, että V1 ja V2 käsittelevät huonosti yhdistettyjä rivejä ja sarakkeita. Osoitteissani yksinkertainen colspan (T3/T5) ja rowspan-arvot litistyivät oikein, lukuun ottamatta edellä mainittua monitasoisen otsikon rivisiirtymää. Mutta #3698:n epäonnistuvat tapaukset ovat epäsäännöllisiä monirivisiä ja monisarakkeisia yhdistelmiä sekä monisivuisia taulukoita — patologinen ääripää. Omiani ovat yksinkertainen pää. Tarkka väite on siis kapea: yksinkertaiset colspan- ja rowspan-arvot palautuivat täällä oikein (monitasoiset otsikot voivat siirtää riviä); monimutkaiset ja epäsäännölliset yhdistelmät ovat edelleen tiedossa oleva avoin ongelma. Ei "yhdistetyt solut toimivat" eikä myöskään "yhdistetyt solut ovat rikki".
Ansakuoppa: yksin sivulla oleva taulukko voi kadota
Katso taulukkoa uudelleen — T1 ja T4 eivät olleet havaittuja lainkaan. Docling tulosti <!-- image -->-merkinnän ja pudotti kaikki solut ilman virhettä. T1 on aivan tavallinen reunustettu 5×8-ruudukko. Tämä oli sen verran hälyttävää, etten halunnut kutsua sitä taulukonparsimisen heikkoudeksi ennen kuin olin eristänyt todellisen syyn, joten tein skriptatun A/B-testin.
Ensiksi suljin pois ilmeiset selitykset. Tekstikerros on ehjä — pypdfium2 lukee T1:stä 327 merkkiä ja T4:stä 221, joten nämä ovat oikeita digitaalisia PDF:iä, eivät skannattuja kuvia. OCR:n kytkeminen pois (do_ocr=False) ei auta; taulukot silti katoavat. Ja kun tarkistin DoclingDocument-objektin suoraan, len(doc.tables) == 0 ja len(doc.pictures) == 1 — layout-malli oli luokitellut koko taulukkoalueen Pictureksi.
Sitten ratkaiseva testi. Piirsin samat T1- ja T4-taulukot uudelleen, mutta tällä kertaa niitä ympäröi muutama tavallinen kappale, ja tein muunnoksen uudelleen. Molemmat tulivat läpi täydellisesti: len(doc.tables) == 1, oikeat GFM-taulukot tulostuivat, ja T4b:n rowspan-otsikko "North" toistui oikein sen kolmen rivin yli. Sama taulukko. Ainoa muuttunut tekijä oli se, oliko se yksinään tyhjällä sivulla vai upotettuna tekstiin.
Todellinen varoitus ei siis ole, että TableFormer olisi haurasta kamaa — vaan että Doclingin RT-DETR-layoutmalli käyttää sivukontekstia, ja pieni taulukko lähes tyhjällä sivulla tulkitaan helposti kuvaksi ja pudotetaan hiljaa. Tämä on käytännössä helppo osua, koska juuri tältä laskut, tuoteselosteet ja rajatut vientitiedostot näyttävät: yksi taulukko per sivu, ei ympäröivää tekstiä. Toimiva korjaus on tylsä mutta tehokas — anna layout-mallille sivukontekstia tai tarkista doc.tables jälkikäteen ja liputa sivut, joilla määrä on nolla. Tämä liittyy läheisesti issue #3495:een (taulukko havaittiin sekä Table- että Picture-muodossa), mutta juuri tämä sivun harvuuden laukaisema käytös — sama taulukko katoaa yksinään, mutta toimii tekstin keskellä — ei löytynyt julkaistuna mistään. Mitattu, ei aiemmin dokumentoitu; ei kuitenkaan sellainen bugi, jota kukaan ei olisi tiennyt.
OCR oikeista skanneista: RapidOCR, ei EasyOCR
Skannatut PDF:t ovat kohta, jossa moni muunnin epäonnistuu hiljaa, joten syötin Doclingille kaksi aitoa skannia, joissa oli mitattu 0-merkin tekstikerros — pypdfium2 raportoi nollan palautettavaa merkkiä, joten kaikki tulos on OCR:ää, ei piilossa kulkevaa tekstikerrosta.
Yksisivuinen ocr_test.pdf palautui siististi 14,3 sekunnissa CPU:lla: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," palautui sanatarkasti. Nelisivuinen nemotron_multipage.pdf ajoi OCR:n kaikille neljälle sivulle yhteensä 70,1 sekunnissa (17,5 s/sivu), ja toisti testilauseen jokaisella sivulla. Oletus-OCR käynnistyi automaattisesti — ei lippua, ei asetusta.
Tässä on yksityiskohta, jonka moni kirjoitus saa väärin: oletus-OCR-moottori on RapidOCR, ei EasyOCR. Varmistin tämän katsomalla, kun PP-OCRv4:n .pth-painot latautuivat ensimmäisellä ajolla. Moni olemassa oleva blogi ja vanhempi Doclingin FAQ-teksti sanoo yhä, että oletus on EasyOCR; se on vanhentunutta tietoa. EasyOCR on nykyään lisäosa, jonka otat erikseen käyttöön. Ja tämä pitää edelleen paikkansa: OCR on hidas polku skaalassa, ja kaikki tässä on mitattu CPU-only-kattona — GPU leikkaisi ajat merkittävästi.
Oikeat PDF:t, lukujärjestys ja aika per sivu
Synteettiset testit todistavat yksittäiset käyttäytymiset; oikeat PDF:t todistavat, että asia toimii käytännössä. Ajoin kaksi syntyperäistä akateemista paperia — 9-sivuisen Docling-teknisen raportin ja 15-sivuisen "Attention Is All You Need" -julkaisun — molemmat kaksipalstaisia, taulukoilla ja kaavoilla.
15-sivuisessa Attention-paperissa kaikki viisi osamerkkiä — Abstract, Introduction, Background, Conclusion, References — näkyvät dokumentin järjestyksessä lineaaristetussa Markdownissa, vaikka asettelu on kaksipalstainen. Jokainen sisältöä kuvaava tarkistuspiste (Transformer, encoder, BLEU, multi-head) löytyy, ja kuuluisat monipalstaiset tulostaulukot tunnistuvat neljäksi taulukoksi. Tämä on aitoa lukujärjestyksen ja palstojen yhdistämisen palautusta, eli RAG-sirpaloinnin ydinarvoa — dokumenttia ei voi paloitella järkevästi, jos linearisointi sotkee kaksipalstaisen sivun sekavaksi vuorotteluksi.
Ajat kertovat hieman vastoin intuitiota olevan opetuksen. Aika per sivu määräytyy enemmän sivun rakenteellisen tiheyden kuin sivumäärän mukaan. Tiheä 9-sivuinen raportti vei 14,95 sekuntia per sivu — hitaampi per sivu kuin 15-sivuinen paperi, joka vei 5,99 sekuntia per sivu — koska raportissa on enemmän taulukoita ja kuvia, ja jokainen niistä laukaisee lisää layout- ja TableFormer-päättelyä. Niinpä "sekuntia per sivu" CPU:lla on rakenteellisen tiheyden, ei pituuden, funktio. Tämä on yhden CPU-only-ajon tulos; se on yläraja, ei tuotantoluku.
Monimuotoisuus ja häviöttömän JSONin väite
Docling mainostaa yhtenäistä monimuotoparsintaa, joten loin DOCX-, XLSX- ja PPTX-tiedostot tunnetulla sisällöllä ja totuusankkureilla, ja tarkistin kaksi asiaa: näkyvätkö ankkurit Markdownissa, ja säilyvätkö ne JSON-round-tripissä export_to_dict()-kutsun kautta.
| Tiedosto | Muunnos s | MD-ankkurit löytyivät | Taulukot MD:ssä | Ankkurit säilyvät JSONissa |
|---|---|---|---|---|
report.docx (otsikot + yhdistetty "Total"-taulukko + luettelot) | 0,137 | 7/7 | 1 | Kyllä |
workbook.xlsx (2 välilehteä, tyhjä sarake) | 0,016 | 6/6 | 2 | Kyllä |
deck.pptx (3 diaa, luettelot + taulukko) | 0,038 | 6/6 | 1 | Kyllä |
Kaikki sisältöankkurit päätyivät Markdowniin, taulukot palautuivat (myös DOCX:n yhdistetty "Total"-rivi ja molemmat XLSX-välilehdet) ja jokainen ankkuri säilyi myös export_to_dict()-JSONissa — ja tämä on se näyttö, joka merkitsee häviöttömän DoclingDocument-väitteen kannalta, ainakin puhtailla syötteillä. Nämä formaatit kulkevat formaattikohtaisten taustajärjestelmien kautta, eivät ML-mallien, minkä vuoksi ne toimivat kymmenissä millisekunneissa ja täysin offline-tilassa. Rajaus on rehellinen: yksi puhdas tiedosto per formaatti osoittaa laajuutta, ei patologisten Office-tiedostojen stressitestiä.
HTML: uskollinen, mutta ei siisti
Tämä on se varoitus, joka ratkaisee kuuluuko Docling RAG-putkeesi, joten lue tarkasti. Docling muuntaa koko HTML-dokumentin. Se ei tee readability-tyyppistä pääsisällön poimintaa. Mittasin, kuinka paljon sivun navigaatio-, sisällysluettelo-, eväste- ja alatunnistemateriaalia säilyy laskemalla niiden rivien määrän Doclingin omassa tulosteessa.
| Sivu | Ei-tyhjiä MD-rivejä | Sivukrääsää | Krääsän osuus | Artikkeli alkaa riviltä |
|---|---|---|---|---|
| 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% | — |
Sivulla, jossa on paljon ympäröivää rakennetta, kuten Wikipediassa, noin 13 % Markdown-riveistä on navigaatio-/sisällysluettelo-/alatunnistemateriaalia, ja varsinainen artikkeli alkaa vasta riviltä 28 — tuloste alkaa "move to sidebar / Contents / Toggle the table of contents" -sisällöllä ja päättyy "CS1 maint… / Search Wikipedia" -merkintään. Siisteillä sisältösivuilla (books, quotes) osuus on noin 0 %, joten kyse on mallipohjan koristelusta, ei jokaisen sivun verosta. Docling antaa uskollisen koko dokumentin Markdownin, ei siistiä pääartikkelin poimintaa. Upstream seuraa HTML-kalusteongelmaa issue #1865:ssa (suljettu) ja #1930:ssa (avoin).
Kaksi asiaa pitää tämän reiluna. Ensinnäkin HTML:n kohdalla Docling ei aja lainkaan ML-malleja — se on BeautifulSoup-taustainen yksinkertainen putki. Tarina siitä, että "näkemismallit lukevat sivusi", pätee vain PDF:iin ja kuviin; kun syötät Doclingille HTML:n, layout- ja TableFormer-koneisto ei käynnisty. Toiseksi PDF-polku yrittää kyllä otsikko- ja alatunnistemateriaalin luokittelua, joten väite "ei lainkaan boilerplate-poistoa" olisi liian vahva — nimenomaan HTML-taustajärjestelmä palauttaa koristelun.
Mihin se asettuu verrattuna muihin — ja missä Thunderbit sopii kuvaan
Kokeile Thunderbitiä verkkodatan poimintaan
Yleisin vertailukohta Doclingille on Firecrawl, joten tässä on asemointitaulukko. Yksi huomio heti alkuun, koska sillä on väliä: tämä on dokumentaatiotasoinen vertailu, ei samassa koneessa ajettu benchmark. En ajanut Firecrawl’ta näillä aineistoilla. Vain Docling-sarake on mitattu täällä; Firecrawl-sarake perustuu sen julkisiin dokumentaatioihin.
| Ominaisuus | Firecrawl (dokumentaationsa mukaan) | Docling (mitattu tässä) |
|---|---|---|
| Ydintehtävä | Crawl + scrape live-verkkoa → Markdown | Muunna jo hallussasi oleva dokumentti → Markdown/JSON |
| Haku / JS-renderöinti / bottisuojaus | Kyllä (hostattu selain) | Ei — sinä annat tiedoston |
| Pääsisällön poiminta | Kyllä | Ei — uskollinen koko dokumentti (~13% krääsää Wikipediassa) |
| PDF-taulukkorakenne (ML) | rajoitettu | Kyllä — TableFormer (TEDS 93,6 virallisesti; cell recall 1,00, in-row 0,97–1,00 havaitulla aineistolla) |
| Skannattu PDF / OCR | rajoitettu | Kyllä — RapidOCR oletuksena (palautti 0-tekstikerroksen skannauksen) |
| Formaattien laajuus | verkkosivut | PDF/DOCX/PPTX/XLSX/HTML/EPUB/kuvat |
| Käyttöönotto | hostattu API (+ oma hostaus) | paikallinen pip-kirjasto, offline, ei API-avainta |
| Asennuksen paino | API-avain / kevyt asiakas | 1,3 GB oletusasennus + noin 506 MiB malleja (tai docling-slim) |
| Lisenssi | kaupallinen / lähdekoodin saatavuus | MIT |
Yhdellä rivillä: Firecrawl on työkalu silloin, kun data on live-webissä ja tarvitsee crawlauksen, JS-renderöinnin ja pääsisällön siivouksen. Docling on työkalu silloin, kun dokumentti on jo hallussasi — erityisesti PDF:t, skannit ja taulukkorikkaat Office-tiedostot — ja haluat uskollisen, offline-tilassa toimivan, rakennetta säilyttävän muunnoksen, jossa on oikea taulukko- ja OCR-ymmärrys. Ne täydentävät toisiaan. Realistinen putki crawlataan yhdellä ja muunnetaan dokumentit toisella.
Ja tässä kohtaa olen rehellinen Thunderbitistä, koska työskentelen täällä, ja olisit aivan oikeassa epäillessäsi, jos väittäisin muuta. Thunderbit ja Docling eivät tee samaa työtä, enkä aio väkisin tehdä niistä samanarvoisia. Kehittäjille Thunderbit on AI-scraping API + MCP-palvelin + CLI, ja sen työyksikkö on live-verkkosivu: POST /distill muuttaa URL:n siistiksi, LLM-valmiiksi Markdowniksi (hoitaen JS-renderöinnin, bottisuojauksen ja CAPTCHA:n, joihin Docling ei puutu), ja POST /extract palauttaa skeemaan sopivaa jäsenneltyä JSONia määrittelemäsi JSON Scheman avulla. Se on RAG-putken hakemis- ja siivouspää. Docling on paikallisen dokumentin pää — PDF, skanni, taulukko, joka jo makaa levylläsi. Jos aineistosi on verkkosivuja, tartu Thunderbitin API:iin, MCP-työkaluihin (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) tai CLI:hin (npx @thunderbit/thunderbit-cli). Jos aineistosi on PDF:iä ja skanneja, tartu Doclingiin. Jos se on molempia — kuten useimmissa oikeissa putkissa — käytä niitä yhdessä, eikä kumpikaan yritä olla toinen.
Tuomio: alustava, ja vielä on kotitehtäviä
En anna sinulle yhtä 0–100-pistemäärää, koska painotettu yhteissumma rankaisisi Doclingia asioista, joita se ei koskaan väittänyt tekevänsä (kuten crawlauksen), ja teeskentelisi niiden olevan vertailukelpoisia. Ominaisuuskohtaisesti, testaamillani aineistoilla:
- Asennus / ensimmäinen ajo: raskas — 1,3 GB venv, noin 506 MiB malleja, noin 224 s ensimmäinen PDF, noin 0,55 s lämmin ajo — mutta
docling-slimantaa mahdollisuuden välttää painon. - Taulukkotarkkuus: vahva silloin, kun taulukko havaitaan (cell recall 1,00 kaikissa 5/5, in-row 0,97–1,00), ja vastaa näillä aineistoilla virallista TEDS-tarinaa.
- Taulukon tunnistuksen luotettavuus: sparse-page-ansa — yksinäinen taulukko voi pudota Pictureksi. Tarkista
doc.tablesjälkeenpäin. - Skannit / OCR: toimii, RapidOCR oletuksena; hidas skaalassa.
- Moniformaattisuus: vakaa, ja JSON-round-trip säilyy.
- HTML: uskollinen, ei siisti — ei pääsisällön poimintaa.
- Kehittäjäkokemus: selkeä kolmen rivin API ja siisti
DoclingDocument, miinus puuttuva__version__.
Kenelle se sopii: tiimeille, jotka rakentavat RAG- tai dataputkia PDF:ien, skannien ja Office-tiedostojen päälle ja haluavat offline-tilassa toimivan, rakennetta säilyttävän muunnoksen sekä aidon taulukko- ja OCR-ymmärryksen. Kenelle se ei sovi: kenelle tahansa, joka tarvitsee live-verkon crawlauksen tai siistin pääartikkelin HTML-poiminnan — siihen on eri työkalu.
Ja koska tämä on arvostelu eikä lehdistötiedote, rajat pysyvät näkyvissä. Tämä on kohdennettu testi — 7 synteettistä taulukkoa plus 2 oikeaa PDF:ää yhdellä CPU-only-koneella — ei TEDS-tason tarkkuusbenchmark. Useita asioita en testannut, ja sinunkin pitäisi testata ne ennen kuin nojaat putkessasi Doclingiin: valinnainen VLM-polku (GraniteDocling), todellinen docling-slim-jalanjälki, GPU-ajo, monimutkaiset ja epäsäännölliset yhdistetyt solut sekä monisivuiset taulukot, kaavojen LaTeX-tarkkuus sekä — kaikkein todennäköisimmin tuotannossa yllättävä — kestävyys kolmiossa: eräajon muistinkasvu, thread/GIL-skaalaus ja objektien elinkaari tuhansien muunnosten yli. Docling on vahva siinä, mitä se väittää tekevänsä, mitattuna eikä markkinoituna, mutta sillä on oikeita reunoja, jotka kannattaa kartoittaa ennen kuin luotat siihen korpuksen kanssa. Tunne sparse-page-varoitus, budjetoi ensimmäisen ajon lataus ja varmista itse skaalakäyttäytyminen.
Kokeile Thunderbitiä verkkodatan poimintaan Get Started Free
Usein kysytyt kysymykset
Onko Docling verkkokaapuri vai crawler? Ei. Docling muuntaa jo hallussasi olevat dokumentit — PDF, DOCX, PPTX, XLSX, HTML, kuvat — Markdowniksi tai JSONiksi. Se ei hae URL-osoitteita, renderöi JavaScriptiä eikä hoida bottisuojauksia. Live-verkon crawlauksen hoitavat erilliset työkalut, kuten Firecrawl tai Thunderbitin web API; Docling lähtee liikkeelle tiedostosta, jonka annat sille.
Kuinka suuri Doclingin asennus ja ensimmäisen ajon lataus ovat?
Oletus docling-metapaketti tuottaa noin 1,3 GB:n venvin, koska se vetää koko ML-pinon kovina riippuvuuksina (pelkkä torch on 536 MiB). Ensimmäinen PDF-muunnos lataa levylle noin 506 MiB layout- ja TableFormer-malleja sekä noin 40 MB RapidOCR-painoja, ja vie noin 224 sekuntia — lähes kokonaan latausaikaa. Toinen muunnos on noin 0,55 sekuntia. Jos tarvitset vain kevyitä formaatteja, docling-slim (noin 50 MB:n ydin) ohittaa raskaan polun.
Tekeekö Docling OCR:ää, ja millä moottorilla? Kyllä. Skannatussa PDF:ssä ilman tekstikerrosta Doclingin OCR käynnistyy automaattisesti, ja palautti tekstin puhtaasti omassa testissäni. Oletusmoottori on RapidOCR, ei EasyOCR — tämä menee usein sekaisin vanhemmissa kirjoituksissa. EasyOCR on nykyään valinnainen lisäosa. OCR on hidas polku skaalassa, erityisesti CPU:lla.
Miksi Docling muutti taulukon kuvaksi tai pudotti sen?
Todennäköisimmin kyse on sparse-page-ilmiöstä. Doclingin RT-DETR-layoutmalli käyttää sivukontekstia, ja pieni taulukko lähes tyhjällä sivulla voi luokittua Pictureksi ja kadota ilman virheilmoitusta. Sama taulukko toimii, jos sen ympärillä on leipätekstiä. Korjaus on antaa layout-mallille sivukontekstia tai tarkistaa doc.tables muunnoksen jälkeen ja merkitä sivut, joilla määrä on nolla.
Docling vs Firecrawl — kumpaa pitäisi käyttää? Eri työt, joten kyse on yleensä enemmän yhdistelmästä kuin joko–tai-valinnasta. Firecrawl crawlata live-verkon, renderöi JavaScriptin ja poimii pääsisällön. Docling muuntaa jo hallussasi olevat dokumentit, joissa on oikea PDF-taulukkorakenne ja OCR, täysin offline-tilassa. Jos lähde on verkkosivuja, käytä web-työkalua (Firecrawl tai Thunderbitin API/MCP/CLI). Jos lähde on PDF:iä, skanneja tai Office-tiedostoja, käytä Doclingia. Useimmissa oikeissa putkissa käytetään molempia.
