Docling hamnar ofta i samma fack som web scraper-verktyg, men det är inte ett sådant. Det är ett dokumentkonverteringsverktyg från IBM Research — numera ett projekt inom LF AI & Data Foundation — som tar filer du redan har (PDF, DOCX, PPTX, XLSX, HTML, bilder) och gör om dem till Markdown eller JSON. Deras egen slogan är bokstavligen: "Get your documents ready for gen AI."
Det här är alltså en praktisk genomgång av en konverterare, inte en crawler. Allt nedan mättes på en enda CPU-baserad maskin (macOS arm64, Python 3.14.2, Docling 2.111.0), med resultat från skript och misslyckanden räknade som misslyckanden. Repositoriet är enormt och rör sig dagligen — 63,069 stars, 4,449 forks och en push samma dag som jag hämtade metadata — så se alla versions- och feluppgifter här som en ögonblicksbild, inte som ett konstant tillstånd.
Vad Docling faktiskt är (och inte är)
Allt i Docling utgår från DoclingDocument: parse:a en fil till den strukturen och exportera sedan till Markdown, HTML, DocTags eller förlustfri JSON. Koden är MIT-licensierad (enskilda modelllicenser kan variera), den har sitt ursprung i IBM Research Zurich, och när detta skrivs är senaste releasen v2.112.0, publicerad två dagar innan jag körde testet.
Den stora styrkan är vägen för PDF och bilder. Den vägen handlar inte om strängparsning — den bygger på en stack av maskininlärningsmodeller: en RT-DETR-modell för layout, TableFormer för tabellstruktur, en valfri vision-language-modell och RapidOCR för skannade filer. Tillsammans återskapar de sidlayout, läsordning och tabellstruktur. Det är den delen som är värd att granska, och den som ett test med enbart HTML aldrig skulle fånga upp.
En viktig skillnad sparar en vecka av förvirring. Docling hämtar inget. Det renderar inte JavaScript, bryter inte igenom antibot-skydd och crawler inte webben. Du tillhandahåller filen; Docling tolkar den. Crawling är ett annat verktygs uppgift, vilket blir viktigt längre fram när folk frågar om Docling ersätter Firecrawl (det gör det inte — de kompletterar varandra, och jag kommer till varför).
Första körningen ingen varnade för
pip install docling går igenom utan problem på Python 3.14.2. Sedan tittar du på din venv, och den är 1.3 GB. Docling drar in hela ML-stacken som hårda beroenden även om du bara tänker konvertera en HTML-fil:
| Beroende | Storlek 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öljande modeller) | 75.6 |
| docling_parse | 30 |
Det här är innan du ens konverterar en enda PDF. Den första PDF-konverteringen är där friktionen verkligen märks, eftersom det är då modellerna laddas ner. I en färsk, isolerad HuggingFace-cache tog första PDF-konverteringen cirka 224 sekunder — och nästan allt var nedladdning, inte beräkning. Layout- och TableFormer-modellerna landar som ~506 MiB på disk (342 MiB TableFormer + 164 MiB layout, verifierat med du), och RapidOCR hämtar ungefär 40 MB PP-OCRv4-vikter till site-packages. Andra konverteringen av samma fil? 0.55 sekunder. Modellerna cachas; du betalar avgiften en gång.
Ett tal du bör ignorera: coldstart-skriptet skriver ut model_download_mb som 1060.2. Citat inte det som footprint. Det kommer från ett os.walk som följer symlänkar, och HuggingFace-cachen lagrar varje modellfil en gång under blobs/ och exponerar den sedan igen via symlänkar i snapshots/ — så genomgången räknar de 14 modellfilerna dubbelt. Den du-motsvarande, symlink-avduplicerade siffran är ~506 MiB (endast blobs: 505.4 MiB). Slutsatsen för alla som benchmarkar Docling: redovisa nedladdningsbytes och bytes på disk som två separata mått, eftersom de faktiskt är det.
Det finns också en andra detalj som biter dem som bygger en Docling-container. Vikterna delas upp på två platser och två tidpunkter. Layout- och TableFormer-modellerna följer HF_HOME och laddas ner vid första PDF-konverteringen. RapidOCRs modeller gör inte det — de hamnar i …/site-packages/rapidocr/models/ och går helt förbi din cache-konfiguration. Om du förbereder en image i förväg eller kör air-gapped måste du hantera båda cacharna, och hur mycket du än sätter HF_HOME fångar du inte den andra.
Nu till det rättvisa. Sedan Doclings tidigare versioner har projektet släppt docling-slim — en kärna på cirka 50 MB som låter dig köra pip install docling-slim[format-html] för HTML utan att dra in torch. Så 1.3 GB-vikten är verklig för standardpaketet docling, men den går nu att välja bort. Jag testade standardpaketet eftersom det fortfarande är det man får av pip install docling, men tyngden är inte ett olöst fel — den modulära lösningen finns och spåras i issue #2393.
Under uppsättningen stötte jag på en liten irriterande detalj värd att nämna: import docling; docling.__version__ ger AttributeError: module 'docling' has no attribute '__version__'. Modulen exponerar helt enkelt inte det attributet. Det som fungerar är importlib.metadata.version("docling"), som returnerar '2.111.0'. En liten DX-ruffsighet, öppen upstream sedan juli 2026 som issue #3733.
Tabellenas kvalitet: där TableFormer tjänar sina poäng
Tabeller är anledningen till att folk överhuvudtaget väljer Docling framför ett vanligt PDF-till-text-dump, så jag genererade sju tabell-PDF:er med maskinläsbar facitdata och betygsatte utdata cell för cell. Två mått spelar roll, och de är inte samma sak: cellrecall är andelen facitvärden som finns någonstans i den detekterade tabellen; andelen i rätt rad är andelen som hamnar i rätt rad. Att blanda ihop de två gör verktyget bättre än det är, så här är båda:
| Tabell (stress-test) | Upptäckt | Cellrecall | Andel i rätt rad | Kommentar |
|---|---|---|---|---|
| T1 enkel tabell med ram (5×8), ensam på sidan | Nej | 0.0 | — | klassificerad som <!-- image -->, alla celler tappades |
| T2 utan ramar (bara en rubriklinje) | Ja | 1.00 | 1.00 | perfekt, exakt rutnät |
| T3 sammanslagen 2-nivå colspan-rubrik | Ja | 1.00 | 0.97 | alla värden hittades; ett rubrikvärde flyttas en rad |
| T4 sammanslagen rowspan för radetikett, ensam på sidan | Nej | 0.0 | — | klassificerad som <!-- image --> |
| T5 colspan-rubrik + utan ramar | Ja | 1.00 | 0.97 | alla värden hittades; samma radförskjutning som i T3 |
| T6 financials, tom kolumn, högerjusterad | Ja | 1.00 | 1.00 | tom kolumn bevarades, inte förskjuten |
| T7 bred tabell med 12 kolumner | Ja | 1.00 | 1.00 | ingen kolumnförskjutning i bred tabell |
På de fem tabeller som Docling faktiskt upptäckte kom alla facitvärden med — cellrecall 1.00 rakt igenom. I tre av de fem hamnade varje värde dessutom i rätt rad. I de två fallen med flernivårubriker (T3 och T5) glider ett rubrikvärde av sin ursprungliga rad, vilket sänker andelen i rätt rad till 0.97 — all data finns där, men radtilldelningen svajar ett steg i en staplad rubrik.
De svåra strukturella fallen klarade sig bättre än jag väntade mig. Den tvånivåiga colspan-rubriken plattades ut korrekt till GitHub-flavoured Markdown (etiketten "Q1 2026" upprepades över sina två spännviddskolumner, vilket är rätt sätt att kollapsa en colspan till GFM). Det gränslösa rutnätet med bara en rubriklinje (T2) kom igenom exakt. Den breda 12-kolumnstabellen (T7) försköts inte. Och en helt tom finanskolumn (T6) bevarades som tomma celler i stället för att tappas eller kollapsas. Det stämmer med de officiella TableFormer TEDS-siffrorna — 95.4 enkel, 90.1 komplex, 93.6 alla tabeller — som modelkortet placerar klart över Camelot (73.0) och EDD (88.3).
En varning om sammanslagna celler är på sin plats, eftersom det finns ett öppet ärende som säger motsatsen. Issue #3698 rapporterar att V1 och V2 hanterar sammanslagna rader och kolumner fel. I mina testfall plattades enkel colspan (T3/T5) och rowspan-värden ut korrekt, med bara den nämnda radförskjutningen i flernivårubrikerna. Men #3698:s fallande exempel gäller oregelbundna fler-rads-/flerkolumnssammanslagningar och tabeller över flera sidor — den patologiska änden. Mina tester ligger i den enkla änden. Så den korrekta formuleringen är snäv: enkel colspan och rowspan återställdes här (flernivårubriker kan flytta en rad); komplexa och oregelbundna sammanslagningar är fortfarande ett dokumenterat öppet problem. Inte "sammanslagna celler fungerar", inte heller "sammanslagna celler är trasiga".
Fällan: en tabell ensam på en sida kan försvinna
Titta tillbaka på tabellen — T1 och T4 upptäcktes inte alls. Docling skrev ut <!-- image --> och tappade alla celler, utan felmeddelande. T1 är ett helt vanligt rutnät med ram i formatet 5×8. Det är tillräckligt oroande för att jag inte ville kalla det en svaghet i tabellparsningen förrän jag isolerat vad som faktiskt utlöste det, så jag byggde ett skriptat A/B-test.
Först uteslöt jag de uppenbara förklaringarna. Textlagret är intakt — pypdfium2 läser 327 tecken från T1 och 221 från T4, så det här är riktiga digitala PDF:er, inte skannade bilder. Att stänga av OCR (do_ocr=False) hjälper inte; tabellerna försvinner ändå. Och när jag inspekterade DoclingDocument direkt visade det sig att len(doc.tables) == 0 medan len(doc.pictures) == 1 — layoutmodellen hade klassat hela tabellområdet som en Picture.
Sedan det avgörande testet. Jag renderade om exakt samma T1- och T4-tabeller, men den här gången omgivna av några vanliga brödtextstycken, och konverterade igen. Båda kom igenom perfekt: len(doc.tables) == 1, korrekta GFM-tabeller exporterades, och T4b:s rowspan-etikett "North" upprepades korrekt över sina tre rader. Samma tabell. Den enda variabeln som ändrades var om den stod ensam på en gles sida eller var inbäddad i text.
Så den verkliga brasklappen är inte att TableFormer är skör — det är att Doclings RT-DETR-layoumodell använder sidkontext, och en liten tabell ensam på en annars nästan tom sida riskerar att läsas som en Picture och försvinna tyst. Det här är lätt att stöta på i praktiken, eftersom det är exakt hur fakturor, specifikationsblad och beskurna exports ser ut: en tabell per sida, ingen omgivande brödtext. Lösningen är tråkig men effektiv — ge layoutmodellen sidkontext, eller kontrollera doc.tables efter konvertering och flagga sidor där antalet är noll. Det ligger nära issue #3495 (en tabell detekterad både som Table och Picture), men just sidgleshetsutlösaren — samma tabell försvinner när den är isolerad, konverteras när den bäddas in — hittade jag ingen publicerad beskrivning av. Mätt, inte tidigare dokumenterat; inte ett fel ingen kände till.
OCR på riktiga skanningar: RapidOCR, inte EasyOCR
Skannade PDF:er är där många konverterare tyst misslyckas, så jag matade Docling med två äkta skanningar med ett mätt textlager på 0 tecken — pypdfium2 rapporterar noll återvinningsbara tecken, vilket bekräftar att all utdata kommer från OCR, inte från ett dolt textlager.
Den ensidiga ocr_test.pdf kom tillbaka ren på 14.3 sekunder på CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," återställdes ordagrant. Den fyrsidiga nemotron_multipage.pdf körde OCR på alla fyra sidorna på totalt 70.1 sekunder (17.5 s/sida) och skrev ut den upprepade testsatsen på varje sida. Standard-OCR startade automatiskt — ingen flagga, ingen konfiguration.
Här är detaljen många genomgångar har fel: standardmotorn för OCR är RapidOCR, inte EasyOCR. Jag bekräftade det genom att se PP-OCRv4 .pth-vikterna laddas ner vid första körningen. Många befintliga bloggar och äldre Docling-FAQ:er säger fortfarande att EasyOCR är standard; det är inaktuellt. EasyOCR är nu ett extra tillval du själv måste aktivera. Det som fortfarande stämmer är detta: OCR är den långsamma vägen i stor skala, och allt här är ett tak för CPU-only — en GPU skulle minska tiderna tydligt.
Riktiga PDF:er, läsordning och tid per sida
Syntetiska fixtures bevisar specifika beteenden; riktiga PDF:er bevisar att det faktiskt fungerar. Jag körde två digitalt födda akademiska artiklar — Doclings 9-sidiga tekniska rapport och 15-sidiga "Attention Is All You Need," båda i tvåspaltsformat med tabeller och formler.
I den 15-sidiga Attention-artikeln dyker alla fem sektionsmarkörer — Abstract, Introduction, Background, Conclusion, References — upp i dokumentordning i den linjäriserade Markdownen, trots tvåspaltslayouten. Alla innehållsmarkörer (Transformer, encoder, BLEU, multi-head) finns där, och de välkända resultat-tabellerna i flera kolumner registreras som fyra detekterade tabeller. Det är genuin återställning av läsordning och kolumnsammanfogning, vilket är kärnvärdet för RAG-chunking — man kan inte chunk:a ett dokument vettigt om linjäriseraren gör tvåspaltsidor till en röra av sammanflätad text.
Tidsmätningen ger en motintuitiv lärdom. Tid per sida styrs av hur mycket struktur som finns på varje sida, inte av hur många sidor dokumentet har. Den tätare 9-sidiga rapporten gick på 14.95 sekunder per sida — långsammare per sida än 15-sidiga artikeln på 5.99 sekunder per sida — eftersom den innehåller fler tabeller och figurer, och varje sådan triggar mer layout- och TableFormer-inferens. Så "sekunder per sida" på CPU är en funktion av strukturell densitet, inte längd. Det här är en enda körning på CPU-only; det är ett tak, inte en produktionssiffra.
Flerformat och påståendet om förlustfri JSON
Docling marknadsför en enhetlig parser för flera format, så jag genererade en DOCX, en XLSX och en PPTX med känd innehållsdata och kontrollerade två saker: kommer markörerna med i Markdownen, och överlever de JSON-rundresan via export_to_dict().
| Fil | Konvertering s | MD-markörer hittade | Tabeller i MD | Markörer överlever JSON |
|---|---|---|---|---|
report.docx (rubriker + sammanslagen "Total"-tabell + punktlistor) | 0.137 | 7/7 | 1 | Ja |
workbook.xlsx (2 blad, tom kolumn) | 0.016 | 6/6 | 2 | Ja |
deck.pptx (3 slides, punktlistor + tabell) | 0.038 | 6/6 | 1 | Ja |
Alla innehållsmarkörer hamnade i Markdownen, tabeller återställdes (inklusive DOCX-filens sammanslagna "Total"-rad och båda XLSX-bladen), och varje markör överlevde också JSON via export_to_dict() — vilket är den bevisning som spelar roll för påståendet om förlustfri DoclingDocument, åtminstone på rena inputfiler. Dessa format går genom formatspecifika backends i stället för ML-modeller, vilket är varför de körs på tiotals millisekunder och fungerar helt offline. Omfattningen är ärlig: en ren fil per format visar bredd, inte ett stress-test av patologiska Office-filer.
HTML: trogen, men inte ren
Det här är brasklappen som avgör om Docling hör hemma i din RAG-pipeline, så läs noga. Docling konverterar hela HTML-dokumentet. Det gör ingen readability-liknande extraktion av bara huvudinnehållet. Jag mätte hur mycket sidans chrome som överlever genom att räkna nav-, TOC-, cookie- och footer-rader i Doclings egen output.
| Sida | Icke-tomma MD-rader | Boilerplate-rader | % boilerplate | Artikeln börjar på rad |
|---|---|---|---|---|
| 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 sida med mycket chrome, som Wikipedia, är ungefär 13% av Markdown-raderna nav-/TOC-/footer-boilerplate, och den riktiga artikeln börjar inte förrän på rad 28 — utdata öppnar med "move to sidebar / Contents / Toggle the table of contents" och avslutar med "CS1 maint… / Search Wikipedia." På rena innehållssidor (books, quotes) är det runt 0%, så detta är ett problem med sidans layoutmall, inte en avgift per sida. Docling ger dig trogen fullständig Markdown för hela dokumentet, inte ren extraktion av huvudartext. Uppströms hanteras HTML-möblemanget i issue #1865 (stängd) och #1930 (öppen).
Två saker gör bedömningen rättvis. För det första kör Docling på HTML inga ML-modeller alls — det är en BeautifulSoup-backend i en enkel pipeline. Historien om "visionmodeller som läser din sida" gäller bara för PDF och bilder; matar du Docling med HTML så triggas varken layout- eller TableFormer-maskineriet. För det andra försöker PDF-vägen faktiskt klassificera header- och footer-möblemang, så påståendet att det inte sker någon boilerplate-rensning alls vore för starkt — det är just HTML-backenden som lämnar tillbaka sidans chrome.
Hur den står sig (och var Thunderbit passar in)
Prova Thunderbit för extraktion av webbdata
Det verktyg Docling oftast jämförs med är Firecrawl, så här är en positions-tabell. En viktig brasklapp direkt: det här är en jämförelse på dokumentationsnivå, inte en benchmark på samma maskin. Jag körde inte Firecrawl på dessa fixtures. Endast Docling-kolumnen är uppmätt här; Firecrawl-kolumnen kommer från deras publika dokumentation.
| Aspekt | Firecrawl (enligt deras dokumentation) | Docling (uppmätt här) |
|---|---|---|
| Kärnuppgift | Crawler + scrape av live-webben → Markdown | Konvertera ett dokument du redan har → Markdown/JSON |
| Hämtning / JS-rendering / antibot | Ja (hostad browser) | Nej — du levererar filen |
| Extraktion av huvudinnehåll | Ja | Nej — trogen full dokumentstruktur (~13% chrome på Wikipedia) |
| PDF-tabellstruktur (ML) | Begränsad | Ja — TableFormer (TEDS 93.6 officiellt; cellrecall 1.00, i rätt rad 0.97–1.00 på detekterade fixtures) |
| Skannad PDF / OCR | Begränsad | Ja — RapidOCR som standard (återställde en skanning med 0-teckenslager) |
| Formatbredd | webbsidor | PDF/DOCX/PPTX/XLSX/HTML/EPUB/bilder |
| Driftsättning | hostad API (+ self-host) | lokal pip-bibliotek, offline, ingen API-nyckel |
| Installationsvikt | API-nyckel / lätt klient | 1.3 GB standardinstallation + ~506 MiB modeller (eller docling-slim) |
| Licens | kommersiell / source-available | MIT |
En radversion: Firecrawl är verktyget när din data ligger på live-webben och behöver crawling, JavaScript-rendering och städning av huvudinnehåll. Docling är verktyget när du redan har dokumentet — särskilt PDF:er, skanningar och Office-filer med mycket tabeller — och vill ha trogen, offline, strukturbevarande konvertering med verklig förståelse för tabeller och OCR. De kompletterar varandra. En realistisk pipeline crawlar med det ena och konverterar dokument med det andra.
Och här ska jag vara rak med Thunderbit, eftersom jag arbetar här och du med rätta skulle vara misstänksam om jag låtsades något annat. Thunderbit och Docling gör inte samma jobb, och jag tänker inte tvinga fram en likhet. För utvecklare är Thunderbit ett AI-scraping-API plus MCP-server plus CLI, och arbetsenheten är den levande webbsidan: POST /distill gör om en URL till ren, LLM-redo Markdown (med hantering av JavaScript-rendering, antibot och CAPTCHA som Docling uttryckligen inte rör), och POST /extract returnerar strukturerad JSON som matchar ett schema du själv definierar. Det är hämta-och-städa-delen av en RAG-pipeline. Docling är den lokala dokumentänden — PDF:en, skanningen, kalkylarket som redan ligger på din disk. Om din korpus är webbsidor, använd Thunderbits API, MCP-verktyg (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) eller CLI (npx @thunderbit/thunderbit-cli). Om det är PDF:er och skanningar, välj Docling. Om det är båda — vilket de flesta riktiga pipelines är — kombinerar du dem, och ingen av dem försöker vara den andra.
Slutsatsen: preliminär, med hemläxa kvar
Jag tänker inte ge dig ett enda betyg mellan 0 och 100, eftersom ett viktat totalbetyg här skulle lägga in straff för sådant Docling aldrig lovat att göra (som crawling) och låtsas att det är jämförbart. Per dimension, på de fixtures jag testade:
- Installation / första körning: tung — 1.3 GB venv, ~506 MiB modeller, ~224 s första PDF, ~0.55 s varm körning — men
docling-slimlåter dig välja bort vikten. - Tabellkvalitet: stark när en tabell väl detekteras (cellrecall 1.00 på 5/5, i rätt rad 0.97–1.00), i linje med den officiella TEDS-bilden på dessa fixtures.
- Robusthet i tabellidentifiering: den glesa-sidan-fällan — en isolerad tabell kan falla bort som en Picture. Kontrollera
doc.tablesefteråt. - Skannade filer / OCR: fungerar, RapidOCR som standard; långsamt i stor skala.
- Flerformat: stabilt, med intakt JSON-rundresa.
- HTML: trogen, men inte ren — ingen extraktion av endast huvudinnehåll.
- Utvecklarupplevelse: ren 3-raders API och ett snyggt
DoclingDocument, minus den saknade__version__.
Vem det är för: team som bygger RAG- eller datapipelines över PDF:er, skanningar och Office-filer och vill ha offline, strukturbevarande konvertering med verklig tabell- och OCR-förståelse. Vem det inte är för: den som behöver live-webbcrawling eller ren extraktion av huvudartiklar i HTML — det är ett annat verktyg.
Och eftersom det här är en recension och inte ett pressmeddelande, stannar begränsningarna kvar på etiketten. Det här är ett riktat test — 7 syntetiska tabeller plus 2 riktiga PDF:er på en CPU-baserad maskin — inte en TEDS-skala-accuracy-benchmark. Flera saker testade jag inte och du bör själv testa innan du bygger en pipeline på Docling: den valfria VLM-vägen (GraniteDocling), den faktiska docling-slim-storleken, någon GPU-körning, komplexa och oregelbundna sammanslagna celler plus tabeller över flera sidor, formel-till-LaTeX-trohet, och — det som sannolikt överraskar dig mest i produktion — hållbarheten i batch-minnestillväxt, tråd-/GIL-skalning och objektlivscykel över tusentals konverteringar. Docling är starkt där det påstår sig vara starkt, mätt snarare än marknadsfört, och det har riktiga kanter som du vill kartlägga innan du litar på det med en hel datamängd. Känn till fällan med glesa sidor, budgetera för nedladdningen vid första körningen och verifiera själv hur det beter sig i stor skala.
Prova Thunderbit för extraktion av webbdata Get Started Free
Vanliga frågor
Är Docling en web scraper eller crawler?
Nej. Docling konverterar dokument du redan har — PDF, DOCX, PPTX, XLSX, HTML, bilder — till Markdown eller JSON. Det hämtar inte URL:er, renderar inte JavaScript och hanterar inte antibot. Crawl av live-webben är en separat uppgift som sköts av verktyg som Firecrawl eller Thunderbits webb-API; Docling börjar från filen du själv tillhandahåller.
Hur stor är Doclings installation och nedladdning vid första körningen?
Standardpaketet docling skapar en venv på omkring 1.3 GB eftersom det drar in hela ML-stacken (torch ensamt är 536 MiB) som hårda beroenden. Den första PDF-konverteringen laddar ner cirka 506 MiB layout- och TableFormer-modeller till disk plus ungefär 40 MB RapidOCR-vikter, och tar runt 224 sekunder — nästan helt nedladdningstid. Den andra konverteringen tar ungefär 0.55 sekunder. Om du bara behöver lätta format kan docling-slim (kärna på cirka 50 MB) hoppa över den tunga vägen.
Gör Docling OCR, och med vilken motor?
Ja. På en skannad PDF utan textlager startar Doclings OCR automatiskt och återställde texten rent i mitt test. Standardmotorn är RapidOCR, inte EasyOCR — ett vanligt misstag i äldre genomgångar. EasyOCR är numera ett tillval du måste aktivera själv. OCR är den långsamma vägen i stor skala, särskilt på CPU.
Varför blev min tabell en bild eller försvann helt i Docling?
Troligen på grund av effekten med gles sida. Doclings RT-DETR-layoumodell använder sidkontext, och en liten tabell ensam på en nästan tom sida kan klassificeras som en Picture och tappas utan felmeddelande. Samma tabell fungerar fint när den omges av brödtext. Lösningen är att ge layoutmodellen mer sidkontext, eller att kontrollera doc.tables efter konvertering och flagga sidor där antalet är noll.
Docling vs Firecrawl — vilket ska jag välja?
Olika jobb, så det är oftast inte antingen eller. Firecrawl crawlar live-webben, renderar JavaScript och extraherar huvudinnehåll. Docling konverterar dokument du redan har, med riktig PDF-tabellstruktur och OCR, helt offline. Om din källa är webbsidor, använd ett webbverktyg (Firecrawl eller Thunderbits API/MCP/CLI). Om det är PDF:er, skanningar eller Office-filer, använd Docling. I de flesta riktiga pipelines används båda.
