Docling blir stadig plassert i samme kategori som webscrapere, men det er det ikke. Det er et verktøysett for dokumentkonvertering fra IBM Research — nå et prosjekt under LF AI & Data Foundation — som tar filer du allerede har (PDF, DOCX, PPTX, XLSX, HTML, bilder) og gjør dem om til Markdown eller JSON. Slagordet deres er bokstavelig talt: "Gjør dokumentene dine klare for generativ AI."
Dette er altså en praktisk test av en konverterer, ikke en crawler. Alt under er målt på én CPU-basert maskin (macOS arm64, Python 3.14.2, Docling 2.111.0), poengene er hentet fra skript, og feil er registrert som feil. Repoet er enormt og endrer seg hele tiden — 63 069 stjerner, 4 449 forks, og en commit samme dag som jeg hentet metadata — så se på eventuelle tall og versjonsangivelser her som et øyeblikksbilde, ikke som en konstant.
Hva Docling faktisk er (og ikke er)
Den sentrale enheten i Docling er DoclingDocument: analyser en fil inn i den strukturen, og eksporter deretter til Markdown, HTML, DocTags eller tapsfri JSON. Koden er MIT-lisensiert (enkeltmodeller kan ha egne lisenser), opprinnelsen er IBM Research Zurich, og per i dag er nyeste release v2.112.0, publisert to dager før jeg kjørte testen.
Hovedstyrken ligger i PDF- og bildebanen. Den banen handler ikke om strengparsing — den bygger på en pakke med maskinlæringsmodeller: en RT-DETR-layoutmodell, TableFormer-modellen for tabellstruktur, en valgfri visjon-språkmodell og RapidOCR for skannede dokumenter. Disse modellene gjenoppretter sidelayout, leserekkefølge og tabellstruktur. Det er den delen som er verdt å vurdere, og den delen en test kun mot HTML aldri ville avslørt.
Én viktig forskjell sparer deg for mye forvirring. Docling henter ingenting. Den rendrer ikke JavaScript, den bryter ikke gjennom anti-bot-vegger, og den crawler ikke. Du leverer filen; den tolker innholdet. Crawling er en annen oppgave, og det blir viktig senere når folk spør om Docling kan erstatte Firecrawl (det kan den ikke — de utfyller hverandre, og jeg forklarer hvorfor senere).
Første kjøring: ingen advarte deg om dette
pip install docling går gjennom uten problemer på Python 3.14.2. Så åpner du venv-en, og den er på 1,3 GB. Docling drar med seg hele ML-stacken som faste avhengigheter, selv om du bare skal konvertere en HTML-fil:
| Avhengighet | Størrelse på disk (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ medfølgende modeller) | 75.6 |
| docling_parse | 30 |
Og dette er før du har konvertert én eneste PDF. Den første PDF-konverteringen er der friksjonen virkelig merkes, fordi det er da modellene lastes ned. I en fersk, isolert HuggingFace-cache tok første PDF-konvertering omtrent 224 sekunder — og nesten alt av tiden er nedlasting, ikke beregning. Layout- og TableFormer-modellene utgjør omtrent 506 MiB på disk (342 MiB TableFormer + 164 MiB layout, verifisert med du), og RapidOCR henter rundt 40 MB med PP-OCRv4-vekter inn i site-packages. Andre konvertering av samme fil? 0,55 sekunder. Modellene er cachet; du betaler avgiften én gang.
Én verdi bør du ignorere: coldstart-scriptet skriver ut model_download_mb som 1060.2. Ikke siter det som faktisk fotavtrykk. Det kommer fra en os.walk som følger symbolske lenker, og HuggingFace-cachen lagrer hver modellfil én gang under blobs/ og eksponerer den igjen som symbolske lenker under snapshots/ — så gjennomgangen teller de 14 modellfilene to ganger. Tallet som samsvarer med du, og som de-dupliserer symbolske lenker, er omtrent 506 MiB (kun blobs: 505,4 MiB). Lærdommen for alle som benchmarker Docling: rapporter nedlastede bytes og bytes på disk som to separate tall, fordi de er nettopp det.
Det er også en annen snubletråd som treffer alle som bygger en Docling-container. Vektene ligger i to ulike caches og lastes ned på to ulike tidspunkt. Layout- og TableFormer-modellene følger HF_HOME og lastes ned ved første PDF-konvertering. RapidOCRs modeller gjør ikke det — de havner i …/site-packages/rapidocr/models/, helt utenom cache-oppsettet ditt. Hvis du forbereder et image på forhånd eller kjører air-gapped, må du håndtere begge cachene, og ingen mengde HF_HOME-oppsett fanger opp den andre.
Når det er sagt, skal vi være rettferdige. Siden tidligere versjoner har prosjektet sluppet docling-slim — en kjerne på rundt 50 MB som lar deg pip install docling-slim[format-html] for HTML uten å trekke inn torch. Så 1,3 GB er reelt for standardpakken docling, men det er nå et valg du kan slippe unna. Jeg testet standardpakken fordi det fortsatt er det pip install docling gir deg, men tyngden er ikke en uadressert feil — den modulære løsningen finnes, og er sporet i issue #2393.
Under oppsettet støtte jeg på en liten irritasjon verdt å nevne: import docling; docling.__version__ gir AttributeError: module 'docling' has no attribute '__version__'. Modulen eksponerer den rett og slett ikke. Det som faktisk virker, er importlib.metadata.version("docling"), som returnerer '2.111.0'. En liten DX-ulempe, åpen oppstrøms siden juli 2026 som issue #3733.
Tabelltrofasthet: der TableFormer faktisk fortjener plassen sin
Tabeller er grunnen til at noen velger Docling fremfor en ren PDF-til-tekst-dump, så jeg laget sju tabell-PDF-er med maskinlesbar fasit og scoret resultatet celle for celle. To mål betyr noe, og de er ikke det samme: celle-recall er andelen fasitverdier som finnes et eller annet sted i den oppdagede tabellen; in-row-rate er andelen som havner i riktig rad. Å blande disse to gjør verktøyet penere enn det er, så her er begge:
| Tabell (stress-test) | Oppdaget | Celle-recall | In-row-rate | Notat |
|---|---|---|---|---|
| T1 enkel tabell med rammer (5×8), alene på siden | Nei | 0.0 | — | klassifisert som <!-- image -->, alle celler falt bort |
| T2 uten rammer (kun linje under overskrift) | Ja | 1.00 | 1.00 | perfekt, nøyaktig rutenett |
| T3 sammenslått 2-nivås colspan-overskrift | Ja | 1.00 | 0.97 | alle verdier funnet; én overskriftsverdi flyttes én rad |
| T4 sammenslått rowspan-radlabel, alene på siden | Nei | 0.0 | — | klassifisert som <!-- image --> |
| T5 colspan-overskrift + uten rammer | Ja | 1.00 | 0.97 | alle verdier funnet; samme radforskyvning som i T3 |
| T6 finans-tabell, tom kolonne, høyrejustert | Ja | 1.00 | 1.00 | tom kolonne beholdt, ikke forskjøvet |
| T7 bred 12-kolonners tabell | Ja | 1.00 | 1.00 | ingen kolonneforskyvning i bred tabell |
Av de fem tabellene Docling faktisk oppdaget, kom alle fasitverdiene med — celle-recall 1.00 på hele brettet. I tre av de fem havnet hver verdi også i riktig rad. I de to tilfellene med flernivå-overskrift (T3 og T5) sklir én overskriftsverdi ut av opprinnelig rad, og in-row faller til 0,97 — alle dataene er der, men radplasseringen vingler én plass på en stablet overskrift.
De vanskelige strukturtilfellene holdt overraskende godt. 2-nivås colspan-overskriften ble flatet ut korrekt til GitHub-flavored Markdown (etiketten "Q1 2026" ble gjentatt over de to kolonnene den spenner over, som er riktig måte å komprimere en colspan til GFM på). Den rammeløse tabellen med bare en topp-linje (T2) kom gjennom helt korrekt. Den brede tabellen med 12 kolonner (T7) forskjøv ikke kolonner. Og en helt tom finanskolonne (T6) ble bevart som tomme celler i stedet for å bli droppet eller slått sammen. Det stemmer med de offisielle TableFormer TEDS-scorene — 95,4 enkel, 90,1 kompleks, 93,6 alle tabeller — som modellkortet benchmarker godt over Camelot (73,0) og EDD (88,3).
Et forbehold om sammenslåtte celler er på sin plass, fordi det finnes en åpen sak som sier det motsatte. Issue #3698 rapporterer at V1 og V2 håndterer sammenslåtte rader og kolonner dårlig. I mine testfiler ble enkle colspan-tilfeller (T3/T5) og rowspan-verdier flatet ut riktig, med bare den nevnte radforskyvningen i flernivå-overskriftene. Men feiltilfellene i #3698 gjelder uregelmessige sammenslåinger over flere rader og kolonner samt tabeller som går over flere sider — altså det patologiske ytterpunktet. Mine tester dekker den enkle enden. Den presise formuleringen er derfor snever: enkle colspan- og rowspan-verdier ble gjenfunnet her (flernivå-overskrifter kan flytte én rad); komplekse og uregelmessige sammenslåinger er fortsatt et dokumentert åpent problem. Ikke «sammenslåtte celler fungerer», og ikke «sammenslåtte celler er ødelagte».
Fellen: En tabell alene på en side kan forsvinne
Se tilbake på tabellen — T1 og T4 ble ikke oppdaget i det hele tatt. Docling skrev ut <!-- image --> og kastet hver eneste celle, uten feil. T1 er et helt normalt 5×8-rutenett med rammer. Det er såpass bekymringsfullt at jeg ikke ville kalle det en svakhet i tabellparsing før jeg hadde isolert hva som faktisk utløste det, så jeg bygde en skriptet A/B-test.
Først utelukket jeg de åpenbare forklaringene. Tekstlaget er intakt — pypdfium2 leser 327 tegn fra T1 og 221 fra T4, så dette er ekte digitale PDF-er, ikke skannede bilder. Å slå av OCR (do_ocr=False) hjelper ikke; tabellene forsvinner fortsatt. Og når jeg ser direkte på DoclingDocument, er len(doc.tables) == 0 mens len(doc.pictures) == 1 — layoutmodellen hadde klassifisert hele tabellområdet som et bilde.
Så kom avgjørende test. Jeg rendret de identiske T1- og T4-tabellene på nytt, denne gangen omgitt av noen vanlige avsnitt med brødtekst, og konverterte på nytt. Begge kom gjennom perfekt: len(doc.tables) == 1, korrekte GFM-tabeller ble skrevet ut, og T4b sin rowspan-label "North" ble gjentatt riktig over de tre radene. Samme tabell. Den eneste variabelen som endret seg, var om den stod alene på en sparsom side eller var innleiret i tekst.
Så det egentlige forbeholdet er ikke at TableFormer er skjør — det er at Doclings RT-DETR-layoutmodell bruker sidekontekst, og en liten tabell alene på en nesten tom side kan bli lest som et bilde og falle ut uten advarsel. Dette er lett å treffe i praksis, fordi det er akkurat slik fakturaer, spesifikasjonsark og utskårne eksportfiler ofte ser ut: én tabell per side, uten omkringliggende tekst. Løsningen er kjedelig, men effektiv — gi layoutmodellen sidekontekst, eller sjekk doc.tables etter konvertering og marker sider der antallet er null. Dette ligger nært issue #3495 (en tabell oppdaget både som Table og Picture), men den spesifikke side-sparsity-utløsende faktoren — samme tabell forsvinner når den er isolert, men konverteres når den er omgitt av tekst — fant jeg ikke publisert noe sted. Målt, ikke tidligere dokumentert; ikke en feil ingen kjente til.
OCR på ekte skann: RapidOCR, ikke EasyOCR
Skannede PDF-er er der mange konverterere stille og rolig feiler, så jeg matet Docling med to ekte skannede filer med et målt tekstlag på 0 tegn — pypdfium2 rapporterer null gjenvinnbare tegn, som bekrefter at alt som kommer ut er OCR og ikke et skjult tekstlag under overflaten.
Én-siders ocr_test.pdf kom tilbake rent på 14,3 sekunder på CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," gjenopprettet ordrett. Den fire sider lange nemotron_multipage.pdf kjørte OCR på alle fire sidene på totalt 70,1 sekunder (17,5 s/side), og skrev ut den gjentatte testsetningen per side. Standard-OCR startet automatisk — ingen flagg, ingen konfigurasjon.
Her er detaljen mange omtaler feil: standard OCR-motor er RapidOCR, ikke EasyOCR. Jeg bekreftet det ved å se PP-OCRv4-.pth-vektene lastes ned ved første kjøring. Mange eksisterende blogger og eldre FAQ-tekster om Docling sier fortsatt at EasyOCR er standard; det er utdatert. EasyOCR er nå et tillegg du må aktivt velge. Forbeholdet som fortsatt gjelder, er at OCR er den trege veien i stor skala, og alt her er en øvre grense for CPU-only — en GPU ville redusert disse tidene betydelig.
Ekte PDF-er, leserekkefølge og tid per side
Syntetiske filer beviser bestemte egenskaper; ekte PDF-er beviser at ting faktisk fungerer. Jeg kjørte to digitale akademiske artikler — den 9 sider lange Docling-tekniske rapporten og 15-siders "Attention Is All You Need", begge i to kolonner med tabeller og formler.
I 15-siders Attention-artikkelen dukker alle fem seksjonsmarkørene — Abstract, Introduction, Background, Conclusion, References — opp i dokumentrekkefølge i den lineære Markdown-en, til tross for todelt kolonnelayout. Alle innholdsmarkører (Transformer, encoder, BLEU, multi-head) finnes, og de kjente resultattabellene med flere kolonner registreres som fire oppdagede tabeller. Det er reell gjenoppretting av leserekkefølge og kolonnefletting, som er kjernen i verdien for RAG-chunking — du kan ikke dele opp et dokument fornuftig hvis lineariseringen gjør en tospaltet side om til sammenvevd støy.
Tidsmålingen gir en litt kontraintuitiv lærdom. Tid per side styres av hvor mye struktur som finnes på hver side, ikke av antall sider. Den tettere 9-siders rapporten brukte 14,95 sekunder per side — tregere per side enn den 15-siders artikkelen på 5,99 sekunder per side — fordi den har flere tabeller og figurer, og hver av dem utløser mer layout- og TableFormer-inferens. Så «sekunder per side» på CPU er en funksjon av strukturtetthet, ikke lengde. Dette er én CPU-basert kjøring; det er et tak, ikke et produksjonstall.
Flere formater og påstanden om tapsfri JSON
Docling markedsfører samlet parsing av flere formater, så jeg laget en DOCX, en XLSX og en PPTX med kjent innhold og fasitmarkører, og sjekket to ting: kommer markørene med i Markdown, og overlever de JSON-runden via export_to_dict()?
| Fil | Konvertering s | MD-markører funnet | Tabeller i MD | Markører overlever JSON |
|---|---|---|---|---|
report.docx (overskrifter + tabell med sammenslått "Total" + punktlister) | 0.137 | 7/7 | 1 | Ja |
workbook.xlsx (2 ark, tom kolonne) | 0.016 | 6/6 | 2 | Ja |
deck.pptx (3 lysbilder, punktlister + tabell) | 0.038 | 6/6 | 1 | Ja |
Alle innholdsmarkørene kom med i Markdown, tabellene ble gjenfunnet (inkludert DOCX-ens sammenslåtte "Total"-rad og begge XLSX-arkene), og hver markør overlevde også JSON-en fra export_to_dict() — som er den relevante dokumentasjonen for påstanden om tapsfri DoclingDocument, i det minste på rene filer. Disse formatene går gjennom formatspesifikke backends i stedet for ML-modellene, og derfor kjører de på titalls millisekunder og fungerer helt offline. Omfanget er ærlig: én ren fil per format sier noe om bredde, ikke om en stress-test av patologiske Office-filer.
HTML: trofast, men ikke ren
Dette er forbeholdet som avgjør om Docling hører hjemme i RAG-pipelinen din, så les nøye. Docling konverterer hele HTML-dokumentet. Den gjør ikke main-content-ekstraksjon i stil med readability. Jeg målte hvor mye sidemeny og annet fast innhold som overlever ved å telle linjer for nav, innholdsfortegnelse, cookies og footer i Doclings egen output.
| Side | Ikke-tomme MD-linjer | Boilerplate-linjer | % boilerplate | Artikkelen starter på linje |
|---|---|---|---|---|
| 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% | — |
På en side med mye fast innhold, som Wikipedia, er rundt 13 % av Markdown-linjene navigasjon/innholdsfortegnelse/footer-støy, og selve artikkelen begynner ikke før linje 28 — outputen åpner med "move to sidebar / Contents / Toggle the table of contents" og avslutter med "CS1 maint… / Search Wikipedia." På rene innholdssider (books, quotes) er det rundt 0 %, så dette er et problem med mal- og sidekledning, ikke en ekstra kostnad per side. Docling gir deg trofast Markdown for hele dokumentet, ikke ren uthenting av hovedinnhold. Oppstrøms sporer HTML-møbleringsproblemet i issue #1865 (lukket) og #1930 (åpen).
To ting gjør dette rettferdig. For det første kjører Docling ingen ML-modeller på HTML i det hele tatt — det er en BeautifulSoup-backend på en enkel pipeline. Historien om at «visjonsmodellene leser siden din» gjelder bare PDF og bilder; gir du Docling HTML, fyrer ingen av layout- eller TableFormer-mekanismene. For det andre prøver PDF-banen faktisk å klassifisere sidehoder og bunntekst som møblering, så «ingen fjerning av støy i det hele tatt» ville vært for sterkt sagt — det er HTML-backenden, spesifikt, som leverer tilbake all kledningen.
Hvordan den står seg — og hvor Thunderbit passer inn
Prøv Thunderbit for webdatauttrekk
Verktøyet folk oftest sammenligner Docling med er Firecrawl, så her er en posisjonstabell. Én viktig presisering før vi går videre, fordi den betyr noe: dette er en sammenligning på dokumentasjonsnivå, ikke en benchmark kjørt på samme maskin. Jeg kjørte ikke Firecrawl på disse testfilene. Bare Docling-kolonnen er målt her; Firecrawl-kolonnen er hentet fra offentlige dokumenter.
| Akse | Firecrawl (ifølge dokumentasjonen) | Docling (målt her) |
|---|---|---|
| Hovedoppgave | Crawler og scraping av live web → Markdown | Konvertere et dokument du allerede har → Markdown/JSON |
| Henting / JS-rendering / anti-bot | Ja (hostet nettleser) | Nei — du leverer filen |
| Uttrekk av hovedinnhold | Ja | Nei — trofast full dokument (ca. 13 % boilerplate på Wikipedia) |
| PDF-tabellstruktur (ML) | Begrenset | Ja — TableFormer (TEDS 93,6 offisielt; celle-recall 1,00, in-row 0,97–1,00 på oppdagede testfiler) |
| Skannet PDF / OCR | Begrenset | Ja — RapidOCR som standard (gjenopprettet en skann med 0-tegns tekstlag) |
| Formatbredde | nettsider | PDF/DOCX/PPTX/XLSX/HTML/EPUB/bilder |
| Drift | hostet API (+ selvhost) | lokal pip-bibliotek, offline, ingen API-nøkkel |
| Oppsettsvekt | API-nøkkel / lett klient | 1,3 GB standardinstallasjon + ~506 MiB modeller (eller docling-slim) |
| Lisens | kommersiell / kildekode-tilgjengelig | MIT |
Kortversjonen er: Firecrawl er verktøyet når dataene dine ligger på live web og du trenger crawling, JavaScript-rendering og rydding av hovedinnhold. Docling er verktøyet når du allerede har dokumentet — spesielt PDF-er, skann og Office-filer med mye tabeller — og vil ha trofast, offline, strukturbevarende konvertering med reell forståelse av tabeller og OCR. De utfyller hverandre. En realistisk pipeline crawler med det ene og konverterer dokumenter med det andre.
Da vil jeg også være ærlig om Thunderbit, siden jeg jobber her, og det ville vært rimelig å bli skeptisk hvis jeg lot som noe annet. Thunderbit og Docling gjør ikke samme jobb, og jeg kommer ikke til å late som om de er like. For utviklere er Thunderbit en AI-scraping-API pluss MCP-server pluss CLI, og arbeidsenheten er den levende nettsiden: POST /distill gjør en URL om til ren, LLM-klar Markdown (og håndterer JS-rendering, anti-bot og CAPTCHA som Docling eksplisitt ikke rører), og POST /extract returnerer strukturert JSON som matcher skjemaet du definerer via en JSON Schema. Det er hente-og-rense-delen av en RAG-pipeline. Docling er den lokale dokumentenden — PDF-en, skanningen, regnearket som allerede ligger på disken din. Hvis kilden din er nettsider, bruk Thunderbits API, MCP-verktøy (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) eller CLI-en (npx @thunderbit/thunderbit-cli). Hvis det er PDF-er og skann, bruk Docling. Hvis det er begge deler — som i de fleste reelle pipeline-oppsett — bruker du dem sammen, og ingen av dem prøver å være den andre.
Konklusjonen: foreløpig, med lekser igjen
Jeg kommer ikke til å gi deg en enkel totalscore fra 0 til 100, fordi en vektet sum her ville blande inn straffepoeng for ting Docling aldri påsto å gjøre (som crawling) og late som om det var sammenlignbart. Per dimensjon, på testene jeg kjørte:
- Oppsett / første kjøring: tungt — 1,3 GB venv, ~506 MiB modeller, ~224 s første PDF, ~0,55 s varm kjøring — men
docling-slimlar deg slippe unna tyngden. - Tabelltrofasthet: sterk når en tabell faktisk oppdages (celle-recall 1.00 på 5/5, in-row 0,97–1,00), i tråd med den offisielle TEDS-historien på disse testene.
- Robusthet i tabelloppdagelse: fellen med sparsomme sider — en isolert tabell kan falle ut som et bilde. Sjekk
doc.tablesetterpå. - Skann / OCR: fungerer, RapidOCR som standard; tregt i stor skala.
- Flere formater: solid, og JSON-runden holder.
- HTML: trofast, men ikke ren — ingen main-content-uttrekk.
- Utvikleropplevelse: ren API med tre linjer og en ryddig
DoclingDocument, minus den manglende__version__.
Hvem passer det for: team som bygger RAG- eller datapipelines over PDF-er, skann og Office-filer, og som vil ha offline, strukturbevarende konvertering med ekte tabell- og OCR-forståelse. Hvem passer det ikke for: alle som trenger live-web-crawling eller ren uttrekk av hovedinnhold i HTML — det er et annet verktøy.
Og siden dette er en anmeldelse og ikke en pressemelding, får også begrensningene stå på etiketten. Dette er en målrettet test — 7 syntetiske tabeller pluss 2 ekte PDF-er på én CPU-basert maskin — ikke en TEDS-skala nøyaktighetsbenchmark. Flere ting jeg ikke testet, og som du bør teste før du baserer en pipeline på Docling: den valgfrie VLM-banen (GraniteDocling), det faktiske fotavtrykket til docling-slim, en reell GPU-kjøring, komplekse og uregelmessige sammenslåtte celler samt tabeller over flere sider, formel-til-LaTeX-trofasthet, og — det som mest sannsynlig overrasker deg i produksjon — utholdenhetstesten for minnevekst i batch, skalering med tråder/GIL og objektlivssyklus gjennom tusenvis av konverteringer. Docling er sterk der den påstår å være sterk, målt heller enn markedsført, og den har reelle kanter du bør kartlegge før du stoler på den med en hel korpus. Kjenn til fellen med sparsomme sider, budsjettér for nedlastingen ved første kjøring, og verifiser oppførselen i stor skala selv.
Prøv Thunderbit for webdatauttrekk Get Started Free
Vanlige spørsmål
Er Docling en webscraper eller crawler? Nei. Docling konverterer dokumenter du allerede har — PDF, DOCX, PPTX, XLSX, HTML, bilder — til Markdown eller JSON. Den henter ikke URL-er, rendrer ikke JavaScript og håndterer ikke anti-bot. Crawling av live web er en separat oppgave som løses av verktøy som Firecrawl eller Thunderbits web-API; Docling starter fra filen du legger inn.
Hvor stor er Docling-installasjonen og første nedlasting?
Standardpakken docling gir en venv på rundt 1,3 GB fordi den trekker inn hele ML-stacken som harde avhengigheter (bare torch er 536 MiB). Første PDF-konvertering laster ned omtrent 506 MiB med layout- og TableFormer-modeller til disk, pluss rundt 40 MB RapidOCR-vekter, og tar cirka 224 sekunder — nesten bare nedlastingstid. Andre konvertering er rundt 0,55 sekunder. Hvis du bare trenger lette formater, hopper docling-slim (kjerne på rundt 50 MB) over den tunge banen.
Har Docling OCR, og med hvilken motor? Ja. På en skannet PDF uten tekstlag starter OCR automatisk, og i testen min ble teksten hentet ut rent. Standardmotoren er RapidOCR, ikke EasyOCR — en vanlig misforståelse i eldre omtaler. EasyOCR er nå et valgfritt tillegg. OCR er den trege delen i stor skala, særlig på CPU.
Hvorfor gjorde Docling tabellen min om til et bilde eller droppet den?
Sannsynligvis på grunn av det sparsomme side-utfallet. Doclings RT-DETR-layoutmodell bruker sidekontekst, og en liten tabell alene på en nesten tom side kan klassifiseres som et bilde og forsvinne uten feilmelding. Den samme tabellen, omgitt av brødtekst, konverteres fint. Løsningen er enten å gi layoutmodellen mer sidekontekst, eller å sjekke doc.tables etter konvertering og flagge sider der antallet er null.
Docling vs Firecrawl — hvilken bør jeg bruke? Ulike jobber, så det er som regel ikke enten/eller. Firecrawl crawler live web, rendrer JavaScript og henter ut hovedinnhold. Docling konverterer dokumentene du allerede har, med ekte PDF-tabellstruktur og OCR, helt offline. Hvis kilden din er nettsider, bruk et webverktøy (Firecrawl, eller Thunderbits API/MCP/CLI). Hvis det er PDF-er, skann eller Office-filer, bruk Docling. De fleste reelle pipeline-oppsett bruker begge.
