Docling blir ofte puttet i samme boks som webscrapers, men det er det ikke. Det er et dokumentkonverteringsværktøj fra IBM Research — nu et projekt under LF AI & Data Foundation — som tager de filer, du allerede har (PDF, DOCX, PPTX, XLSX, HTML og billeder), og omdanner dem til Markdown eller JSON. Deres egen tagline er helt bogstaveligt: "Get your documents ready for gen AI."
Det her er altså en praktisk test af en konverter, ikke en crawler. Alt nedenfor er målt på én CPU-only-maskine (macOS arm64, Python 3.14.2, Docling 2.111.0), scoret med scripts, og fejl er registreret som fejl. Repositoriet er kæmpestort og udvikler sig fra dag til dag — 63.069 stars, 4.449 forks og en push samme dag, som jeg hentede metadata — så tag eventuelle tal for issues eller versioner her som et øjebliksbillede, ikke en fast sandhed.
Hvad Docling faktisk er — og ikke er
Enheden i Docling er DoclingDocument: parse en fil ind i den struktur, og eksporter derefter til Markdown, HTML, DocTags eller tabsfri JSON. Koden er MIT-licenseret (de enkelte model-licenser varierer), den stammer fra IBM Research Zurich, og på tidspunktet for denne anmeldelse er den nyeste release v2.112.0, udgivet to dage før jeg kørte testen.
Den store styrke er PDF- og billedsporet. Det handler ikke om simpel tekstparsing — det er en pakke af maskinlæringsmodeller: en RT-DETR layoutmodel, TableFormer til tabelstruktur, en valgfri vision-language-model og RapidOCR til scanninger. Modellerne genskaber sidelayout, læserækkefølge og tabelstruktur. Det er den del, der er værd at vurdere, og det er også den del, en ren HTML-test aldrig vil fange.
En vigtig forskel sparer dig for en uge med forvirring. Docling henter ikke noget. Den renderer ikke JavaScript, den bryder ikke igennem anti-bot-værn, og den crawler ikke. Du giver filen; den forstår indholdet. Crawling er et andet værktøjs opgave, og det bliver vigtigt senere, når folk spørger, om Docling kan erstatte Firecrawl (det kan den ikke — de supplerer hinanden, og jeg forklarer hvorfor).
Første kørsel, som ingen advarer dig om
pip install docling lykkes uden problemer på Python 3.14.2. Derefter kigger du i dit venv, og det er 1,3 GB. Docling trækker hele ML-stakken ind som hårde afhængigheder, selv hvis du kun skal konvertere en HTML-fil:
| Afhængighed | 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 det er før du har konverteret én eneste PDF. Den første PDF-konvertering er dér, hvor friktionen virkelig mærkes, fordi det er dér, modellerne bliver hentet. På en frisk, isoleret HuggingFace-cache tog den første PDF-konvertering ca. 224 sekunder — og næsten det hele var download, ikke beregning. Layout- og TableFormer-modellerne fylder ca. 506 MiB på disk (342 MiB TableFormer + 164 MiB layout, verificeret med du), og RapidOCR henter omkring 40 MB PP-OCRv4-vægte ind i site-packages. Anden gang du konverterer den samme fil? 0,55 sekunder. Modellerne er cachet; du betaler tolden én gang.
Ét tal bør du ignorere: coldstart-scriptet udskriver model_download_mb som 1060,2. Brug ikke det som fodaftryk. Det kommer fra en os.walk, der følger symlinks, og HuggingFace-cachen gemmer hver model-fil én gang under blobs/ og eksponerer den igen som et snapshots/-symlink — så gennemløbet tæller de 14 model-filer to gange. Den du-svarende, symlink-deduplicerede størrelse er ca. 506 MiB (kun blobs: 505,4 MiB). Pointen for alle, der benchmarker Docling: rapportér download-bytes og bytes på disk som to separate tal, fordi de er forskellige.
Der er også et andet benspænd, som rammer alle, der bygger en Docling-container. Vægtene ligger i to forskellige caches og downloades efter to forskellige regler. Layout- og TableFormer-modellerne respekterer HF_HOME og hentes ved første PDF-konvertering. RapidOCRs modeller gør ikke — de lander i …/site-packages/rapidocr/models/ og går helt uden om din cache-konfiguration. Hvis du vil pre-bygge eller air-gappe et image, skal du håndtere begge caches, og ingen mængde HF_HOME-opsætning fanger den anden.
Fair nok — også den positive side. Siden Doclings tidligere versioner har projektet udgivet docling-slim — en kerne på omkring 50 MB, som lader dig pip install docling-slim[format-html] til HTML uden at trække torch med. Så 1,3 GB er stadig reelt for standardpakken docling, men den er nu valgfri. Jeg testede standardpakken, fordi det stadig er det, pip install docling giver dig, men tyngden er ikke en uløst fejl — den modulære løsning findes og er sporet i issue #2393.
Under opsætningen ramte jeg også en lille irritationsmoment, som er værd at nævne: import docling; docling.__version__ giver AttributeError: module 'docling' has no attribute '__version__'. Modulet eksponerer den bare ikke. Den virksomme løsning er importlib.metadata.version("docling"), som returnerer '2.111.0'. Det er en lille DX-irritation, åben upstream siden juli 2026 som issue #3733.
Tabeltrohed: dér hvor TableFormer for alvor tjener sin plads
Tabeller er grunden til, at nogen overhovedet vælger Docling frem for en simpel PDF-til-tekst-dump, så jeg genererede syv tabel-PDF’er med maskinlæsbar ground truth og scorede outputtet celle for celle. To metrics betyder noget, og de er ikke det samme: cell recall er andelen af ground-truth-værdier, der findes et eller andet sted i den detekterede tabel; in-row rate er andelen, der ender i den korrekte række. Hvis man blander de to sammen, ser værktøjet bedre ud, end det er — så her er begge:
| Tabel (stress) | Detekteret | Cell recall | In-row rate | Note |
|---|---|---|---|---|
| T1 simpelt indrammet gitter (5×8), alene på siden | Nej | 0.0 | — | klassificeret som <!-- image -->, alle celler tabt |
| T2 uden rammer (kun en header-linje) | Ja | 1.00 | 1.00 | perfekt, nøjagtigt gitter |
| T3 flettet 2-niveaus colspan-header | Ja | 1.00 | 0.97 | alle værdier fundet; én header-værdi flytter en række |
| T4 flettet rowspan-rækkelabel, alene på siden | Nej | 0.0 | — | klassificeret som <!-- image --> |
| T5 colspan-header + uden rammer | Ja | 1.00 | 0.97 | alle værdier fundet; samme række-forskydning som T3 |
| T6 finans, tom kolonne, højrejusteret | Ja | 1.00 | 1.00 | tom kolonne bevaret, ikke forskubbet |
| T7 bredt gitter med 12 kolonner | Ja | 1.00 | 1.00 | ingen kolonneforskydning på en bred tabel |
På de fem tabeller, Docling faktisk detekterede, kom alle ground-truth-værdier med — cell recall 1.00 hele vejen igennem. På tre af de fem havnede hver værdi også i den rigtige række. På de to tilfælde med flerniveaus-headere (T3 og T5) glider én header-værdi ud af sin oprindelige række, så in-row falder til 0,97 — alle data er der, men rækketilknytningen vakler en smule på en stablet header.
De svære strukturelle tilfælde holdt bedre, end jeg havde forventet. Den to-niveaus colspan-header blev fladet korrekt ud til GitHub-flavored Markdown ("Q1 2026"-labelen blev gentaget over de to spandede kolonner, hvilket er den rigtige måde at kollapse en colspan til GFM på). Det rammefri gitter med kun en header-linje (T2) kom igennem præcist. Og den brede tabel med 12 kolonner (T7) flyttede ikke noget. Den helt tomme finanskolonne (T6) blev bevaret som tomme celler i stedet for at blive droppet eller kollapset. Det stemmer med de officielle TableFormer TEDS-scorer — 95,4 simple, 90,1 complex, 93,6 all-tables — som modelkortet benchmarker langt over Camelot (73,0) og EDD (88,3).
Et ord om flettede celler, fordi der ligger et åbent issue, der siger det modsatte. Issue #3698 rapporterer, at V1 og V2 håndterer flettede rækker og kolonner forkert. På mine fixtures blev simple colspan (T3/T5) og rowspan-værdier fladet korrekt ud, med kun den nævnte række-forskydning i flerniveaus-headerne. Men #3698’s fejlsituationer er uregelmæssige multi-row/multi-column-fletninger og tabeller over flere sider — den patologiske ende. Mine er den simple ende. Så den præcise konklusion er snæver: simple colspan- og rowspan-værdier blev genfundet her (flerniveaus-headere kan flytte én række); komplekse og uregelmæssige fletninger er stadig et dokumenteret åbent problem. Ikke "flettede celler virker", ikke "flettede celler er ødelagte".
Fælden: En tabel alene på en side kan forsvinde
Se tilbage på tabellen — T1 og T4 blev slet ikke detekteret. Docling udskrev <!-- image --> og smed hver eneste celle væk uden fejl. T1 er et helt almindeligt indrammet 5×8-gitter. Det er bekymrende nok til, at jeg nægtede at kalde det en svaghed i tabelparsing, før jeg havde isoleret, hvad der faktisk udløste det, så jeg lavede en scriptet A/B-test.
Først udelukkede jeg de oplagte forklaringer. Tekstlaget er intakt — pypdfium2 læser 327 tegn fra T1 og 221 fra T4, så det er rigtige digitale PDF’er, ikke scannede billeder. At slå OCR fra (do_ocr=False) hjælper ikke; tabellerne forsvinder stadig. Og når man inspicerer DoclingDocument direkte, er len(doc.tables) == 0, mens len(doc.pictures) == 1 — layoutmodellen havde klassificeret hele tabelområdet som et Picture.
Så kom den afgørende test. Jeg gengav de samme T1- og T4-tabeller, men denne gang omgivet af nogle almindelige brødtekstafsnit, og konverterede igen. Begge kom igennem perfekt: len(doc.tables) == 1, korrekte GFM-tabeller blev udskrevet, og T4b’s rowspan-label "North" blev korrekt gentaget over sine tre rækker. Samme tabel. Den eneste ændring var, om den stod alene på en sparsom side eller var indlejret i tekst.
Så den reelle advarsel er ikke, at TableFormer er skrøbelig — det er, at Doclings RT-DETR-layoutmodel bruger sidekontekst, og en lille tabel alene på en næsten tom side risikerer at blive læst som et Picture og droppet uden advarsel. Det er let at ramme i praksis, for det er præcis sådan fakturaer, specifikationsark og beskårne eksportfiler ofte ser ud: én tabel pr. side, ingen omkringliggende tekst. Løsningen er kedelig og effektiv — giv layoutmodellen sidekontekst, eller tjek doc.tables efter konvertering og markér sider, hvor antallet er nul. Det ligger tæt på issue #3495 (en tabel detekteret både som Table og Picture), men den konkrete sparse-page-trigger — samme tabel, droppet når den står alene, konverteret når den er indlejret — kunne jeg ikke finde publiceret noget sted. Målt, ikke tidligere dokumenteret; ikke en fejl, som ingen kendte til.
OCR på rigtige scanninger: RapidOCR, ikke EasyOCR
Scannede PDF’er er dér, hvor mange konvertere stille fejler, så jeg fodrede Docling med to ægte scanninger med et målt tekstlag på 0 tegn — pypdfium2 rapporterer ingen genskabelige tegn, hvilket bekræfter, at alt output er OCR og ikke et skjult tekstlag nedenunder.
Den ene side i ocr_test.pdf kom rent tilbage på 14,3 sekunder på CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," genskabt ordret. Den fire sider lange nemotron_multipage.pdf kørte OCR på alle fire sider på i alt 70,1 sekunder (17,5 s/side) og udskrev den gentagne test-sætning per side. Standard-OCR blev aktiveret automatisk — ingen flag, ingen konfiguration.
Her er detaljen, som mange artikler tager fejl af: standard-OCR-motoren er RapidOCR, ikke EasyOCR. Jeg bekræftede det ved at se PP-OCRv4 .pth-vægtene blive hentet ved første kørsel. Mange eksisterende blogs og ældre Docling-FAQ-tekster siger stadig, at EasyOCR er standard; det er forældet. EasyOCR er nu et ekstra tilvalg. Advarslen, der stadig gælder, er den samme: OCR er den langsomme vej i stor skala, og alt her er et CPU-only-loft — en GPU ville reducere tiderne markant.
Rigtige PDF’er, læserækkefølge og tid pr. side
Syntetiske fixtures beviser specifikke adfærdsmønstre; rigtige PDF’er beviser, at det faktisk virker. Jeg kørte to born-digital akademiske artikler — den 9-siders Docling-rapport og 15-siders "Attention Is All You Need", begge i to spalter med tabeller og formler.
På den 15-siders Attention-artikel optræder alle fem sektionsmarkører — Abstract, Introduction, Background, Conclusion, References — i dokumentrækkefølge i den lineariserede Markdown, på trods af to-spalte-layoutet. Alle indholdsprompts (Transformer, encoder, BLEU, multi-head) er med, og de berømte resultattabeller i flere spalter registreres som fire detekterede tabeller. Det er reel genfinding af læserækkefølge og kolonne-sammenlægning, og det er kerneværdien for RAG-chunking — man kan ikke chunk’e et dokument meningsfuldt, hvis linearizeren smadrer en tospaltet side til sammenblandet nonsens.
Tidsmålingen giver en lidt kontraintuitiv lektie. Tid pr. side styres af, hvor meget struktur der er på hver side, ikke af antallet af sider. Den tættere 9-siders rapport kørte med 14,95 sekunder pr. side — langsommere pr. side end den 15-siders artikel på 5,99 sekunder pr. side — fordi den indeholder flere tabeller og figurer, og hver af dem udløser mere layout- og TableFormer-inferens. Så "sekunder pr. side" på CPU er en funktion af strukturel tæthed, ikke længde. Det er en enkelt CPU-only kørsel; det er et loft, ikke et produktions-tal.
Multi-format og påstanden om tabsfri JSON
Docling markedsfører samlet multi-format parsing, så jeg genererede en DOCX, en XLSX og en PPTX med kendt indhold og ground-truth-probes, og tjekkede derefter to ting: kommer probes frem i Markdown, og overlever de JSON-rundturen via export_to_dict()?
| Fil | Konvertering s | MD-probes fundet | Tabeller i MD | Probes overlever JSON |
|---|---|---|---|---|
report.docx (overskrifter + flettet "Total"-tabel + bullets) | 0.137 | 7/7 | 1 | Ja |
workbook.xlsx (2 ark, tom kolonne) | 0.016 | 6/6 | 2 | Ja |
deck.pptx (3 slides, bullets + tabel) | 0.038 | 6/6 | 1 | Ja |
Alle indholdsprobes kom med i Markdown, tabellerne blev genskabt (inklusive DOCX’ens flettede "Total"-række og begge XLSX-ark), og hver probe overlevede også export_to_dict()-JSON’en — hvilket er den evidens, der betyder noget for påstanden om tabsfri DoclingDocument, i hvert fald på rene inputs. Formaterne går gennem format-native backends i stedet for ML-modellerne, og derfor kører de på få millisekunder og fungerer helt offline. Omfanget er ærligt: én ren fil pr. format viser bredde, ikke en stresstest af patologiske Office-filer.
HTML: Trofast, men ikke ren
Det her er den advarsel, som afgør, om Docling passer ind i din RAG-pipeline, så læs nøje. Docling konverterer hele HTML-dokumentet. Den laver ikke readability-lignende udtræk af hovedindholdet. Jeg målte, hvor meget site-chrome der overlever, ved at tælle linjer med nav, TOC, cookie og footer-markører i Doclings eget output.
| Side | Ikke-tomme MD-linjer | Boilerplate-linjer | % boilerplate | Artiklen 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 meget chrome som Wikipedia er cirka 13% af Markdown-linjerne nav/TOC/footer-boilerplate, og den egentlige artikel starter først på linje 28 — outputtet åbner med "move to sidebar / Contents / Toggle the table of contents" og slutter med "CS1 maint… / Search Wikipedia." På rene indholdssider (books, quotes) er det omkring 0%, så det her er et problem med templates og chrome, ikke en skat per side. Docling giver dig trofast fulddokument-Markdown, ikke ren udtrækning af hovedartiklen. Upstream tracker HTML-møbleringsproblemet i issue #1865 (lukket) og #1930 (åben).
To ting gør vurderingen fair. For det første kører Docling på HTML slet ingen ML-modeller — det er en BeautifulSoup-backend i en simpel pipeline. Historien om "vision-modeller, der læser din side" gælder kun for PDF og billeder; giver du Docling HTML, aktiveres hverken layout- eller TableFormer-mekanikken. For det andet forsøger PDF-sporet faktisk at klassificere header- og footer-furniture, så påstanden "ingen boilerplate-fjernelse overhovedet" ville være for stærk — det er specifikt HTML-backenden, der returnerer chrome’en.
Hvordan det står i forhold til andre — og hvor Thunderbit passer ind
Prøv Thunderbit til udtræk af webdata
Det værktøj, folk oftest sammenligner Docling med, er Firecrawl, så her er en positioneringstabel. Én vigtig advarsel på forhånd: det her er en sammenligning på dokumentationsniveau, ikke en benchmark på samme maskine. Jeg kørte ikke Firecrawl på disse fixtures. Kun Docling-kolonnen er målt her; Firecrawl-kolonnen kommer fra deres offentlige docs.
| Akse | Firecrawl (ifølge deres docs) | Docling (målt her) |
|---|---|---|
| Kerneopgave | Crawl + scrape det levende web → Markdown | Konverter et dokument, du allerede har → Markdown/JSON |
| Hentning / JS-rendering / anti-bot | Ja (hostet browser) | Nej — du leverer filen |
| Udtræk af hovedindhold | Ja | Nej — trofast fulddokument (~13% chrome på Wikipedia) |
| PDF-tabelstruktur (ML) | begrænset | Ja — TableFormer (officiel TEDS 93,6; cell recall 1,00, in-row 0,97–1,00 på detekterede fixtures) |
| Scannede PDF’er / OCR | begrænset | Ja — RapidOCR som standard (genskabte en scan uden tekstlag) |
| Formatbredde | websider | PDF/DOCX/PPTX/XLSX/HTML/EPUB/billeder |
| Udrulning | hostet API (+ self-host) | lokal pip-library, offline, ingen API-nøgle |
| Opsætningsvægt | API-nøgle / let klient | 1,3 GB standard-installation + ca. 506 MiB modeller (eller docling-slim) |
| Licens | kommerciel / source-available | MIT |
Den korte version: Firecrawl er værktøjet, når dine data ligger på det levende web og skal crawles, have JS-rendering og renses til hovedindhold. Docling er værktøjet, når du allerede har dokumentet — især PDF’er, scanninger og Office-filer med mange tabeller — og vil have en trofast, offline, strukturbevarende konvertering med reel tabel- og OCR-forståelse. De supplerer hinanden. En realistisk pipeline crawler med det ene og konverterer dokumenter med det andet.
Og her vil jeg være helt ærlig om Thunderbit, fordi jeg arbejder her, og du med rette ville være skeptisk, hvis jeg lod som om andet. Thunderbit og Docling løser ikke samme opgave, og jeg vil ikke presse en kunstig lighed ned over dem. For udviklere er Thunderbit en AI scraping-API plus MCP-server plus CLI, og arbejdsenheden er den levende webside: POST /distill gør en URL til ren, LLM-klar Markdown (og håndterer JS-rendering, anti-bot og CAPTCHA, som Docling eksplicit ikke rører), mens POST /extract returnerer struktureret JSON, der matcher et schema, du selv definerer, via JSON Schema. Det er hente-og-rense-delen af en RAG-pipeline. Docling er den lokale dokumentdel — PDF’en, scanningen, regnearket, der allerede ligger på disken. Hvis dit corpus er websider, så brug Thunderbits API, MCP-værktøjer (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) eller CLI’en (npx @thunderbit/thunderbit-cli). Hvis det er PDF’er og scanninger, så brug Docling. Hvis det er begge dele — hvilket det er i de fleste rigtige pipelines — kombinerer du dem, og ingen af dem prøver at være den anden.
Konklusionen: Foreløbig, med lektier tilbage
Jeg vil ikke give dig en enkelt score fra 0 til 100, fordi en vægtet total her ville blande straf sammen for ting, Docling aldrig har lovet at gøre (som crawling), og lade som om det var sammenligneligt. På de dimensioner, jeg testede:
- Opsætning / første kørsel: tung — 1,3 GB venv, ca. 506 MiB modeller, ca. 224 s første PDF, ca. 0,55 s varm — men
docling-slimlader dig vælge tyngden fra. - Tabeltrohed: stærk, når en tabel først er detekteret (cell recall 1,00 på 5/5, in-row 0,97–1,00), i tråd med den officielle TEDS-historie på disse fixtures.
- Robusthed i tabeldetektion: sparse-page-fælden — en isoleret tabel kan forsvinde som et Picture. Tjek
doc.tablesbagefter. - Scannede dokumenter / OCR: virker, RapidOCR er standard; langsom i stor skala.
- Multi-format: solid, med intakt JSON-rundtur.
- HTML: trofast, men ikke ren — ingen main-content extraction.
- Developer experience: ren 3-linjers API og et pænt
DoclingDocument, minus den manglende__version__.
Hvem det er til: teams, der bygger RAG- eller datapipelines over PDF’er, scanninger og Office-filer, og som vil have offline, strukturbevarende konvertering samt reel tabel- og OCR-forståelse. Hvem det ikke er til: alle, der har brug for live-web crawling eller ren hovedartikel-udtrækning fra HTML — det er et andet værktøj.
Og fordi det her er en anmeldelse og ikke en pressemeddelelse, bliver begrænsningerne på etiketten. Det her er en målrettet probe — 7 syntetiske tabeller plus 2 rigtige PDF’er på én CPU-only-maskine — ikke en TEDS-skala-accuracy benchmark. Flere ting testede jeg ikke, og det bør du selv gøre, før du satser en pipeline på Docling: den valgfri VLM-sti (GraniteDocling), det faktiske docling-slim-fodaftryk, en GPU-kørsel, komplekse og uregelmæssige flettede celler plus tabeller over flere sider, formel-til-LaTeX-trohed og — den, der mest sandsynligt overrasker dig i produktion — holdbarheden i batch-memory growth, thread/GIL-skalering og object lifecycle på tværs af tusindvis af konverteringer. Docling er stærk dér, hvor den lover det, og det er målt frem for markedsført, men den har også reelle grænser, som du bør kortlægge, før du stoler på den med et helt korpus. Kend sparse-page-advarslen, budgetér for første-run-downloaden, og verificér selv, hvordan den opfører sig i stor skala.
Prøv Thunderbit til udtræk af webdata Get Started Free
FAQ
Er Docling en webscraper eller crawler? Nej. Docling konverterer dokumenter, du allerede har — PDF, DOCX, PPTX, XLSX, HTML, billeder — til Markdown eller JSON. Den henter ikke URL’er, renderer ikke JavaScript og håndterer ikke anti-bot. Crawling af det levende web er et separat job, som værktøjer som Firecrawl eller Thunderbits web API løser; Docling starter fra den fil, du leverer.
Hvor stor er Doclings installation og første download?
Standardpakken docling giver et venv på omkring 1,3 GB, fordi den trækker hele ML-stakken ind som hårde afhængigheder (torch alene er 536 MiB). Den første PDF-konvertering downloader cirka 506 MiB layout- og TableFormer-modeller til disk plus omkring 40 MB RapidOCR-vægte, og tager cirka 224 sekunder — næsten alt sammen downloadtid. Anden konvertering tager cirka 0,55 sekunder. Hvis du kun har brug for lette formater, springer docling-slim (ca. 50 MB kerne) den tunge vej over.
Laver Docling OCR, og med hvilken motor? Ja. På en scannet PDF uden tekstlag aktiveres Doclings OCR automatisk og genskabte teksten rent i min test. Standardmotoren er RapidOCR, ikke EasyOCR — en almindelig fejl i ældre beskrivelser. EasyOCR er nu et ekstra tilvalg. OCR er den langsomme vej i stor skala, især på CPU.
Hvorfor gjorde Docling min tabel til et billede eller droppede den?
Det er sandsynligvis sparse-page-effekten. Doclings RT-DETR-layoutmodel bruger sidekontekst, og en lille tabel alene på en næsten tom side kan blive klassificeret som et Picture og droppet uden fejl. Den samme tabel, omgivet af brødtekst, konverteres fint. Løsningen er enten at give layoutmodellen sidekontekst eller at tjekke doc.tables efter konvertering og markere sider, hvor antallet er nul.
Docling vs Firecrawl — hvilken skal jeg vælge? Det er forskellige jobs, så det er typisk ikke enten/eller. Firecrawl crawler det levende web, renderer JavaScript og udtrækker hovedindhold. Docling konverterer dokumenter, du allerede har, med reel PDF-tabelstruktur og OCR, helt offline. Hvis din kilde er websider, så brug et webværktøj (Firecrawl eller Thunderbits API/MCP/CLI). Hvis det er PDF’er, scanninger eller Office-filer, så brug Docling. I de fleste rigtige pipelines bruger man begge.
