Docling को अक्सर web scraper के साथ मिला दिया जाता है, लेकिन वह वैसा tool नहीं है। यह IBM Research का एक document-conversion toolkit है — जो अब LF AI & Data Foundation project है — और आपके पास मौजूद files (PDF, DOCX, PPTX, XLSX, HTML, images) को Markdown या JSON में बदल देता है। इसकी अपनी tagline भी यही है: "अपने documents को gen AI के लिए तैयार करें।"
तो यह review किसी converter की hands-on जांच है, crawler की नहीं। नीचे दी गई हर चीज़ को एक CPU-only machine (macOS arm64, Python 3.14.2, Docling 2.111.0) पर मापा गया, scripts से score किया गया, और जहाँ failure हुआ, उसे failure ही दर्ज किया गया। इसका repo बहुत बड़ा है और हर दिन बदलता रहता है — 63,069 stars, 4,449 forks, और metadata pull वाले दिन ही एक push — इसलिए यहाँ दिए गए issue counts या version numbers को स्थायी truth नहीं, बल्कि एक snapshot समझें।
Docling असल में क्या है — और क्या नहीं
Docling की हर चीज़ की core unit DoclingDocument है: किसी file को उस structure में parse करें, फिर Markdown, HTML, DocTags, या lossless JSON में export करें। इसका code MIT-licensed है (individual model licenses अलग-अलग हो सकते हैं), इसकी शुरुआत IBM Research Zurich में हुई, और इस लेख के समय latest release v2.112.0 थी, जो मैंने यह run करने से दो दिन पहले publish हुई थी।
इसकी सबसे बड़ी strength PDF और image pipeline है। वह pipeline सिर्फ string parsing नहीं है — यह machine-learning models का एक stack है: RT-DETR layout model, TableFormer table-structure model, optional vision-language model, और scans के लिए RapidOCR। ये models page layout, reading order, और table structure को recover करते हैं। यही हिस्सा review करने लायक है, और यही हिस्सा किसी HTML-only test में कभी नहीं दिखेगा।
एक बात बहुत confusion बचा देती है। Docling कुछ fetch नहीं करता। यह JavaScript render नहीं करता, anti-bot walls नहीं तोड़ता, और crawl नहीं करता। आप file देते हैं; यह उसे समझता है। Crawling किसी और tool का काम है, और आगे चलकर यह इसलिए important होगा क्योंकि लोग पूछते हैं कि क्या Docling Firecrawl को replace करता है (नहीं करता — वे एक-दूसरे के पूरक हैं, और मैं बताऊँगा क्यों)।
पहली बार चलाने पर जो कोई आपको नहीं बताता
pip install docling Python 3.14.2 पर साफ़-सुथरे ढंग से complete हो जाता है। फिर आप venv देखते हैं, और वह 1.3 GB का निकलता है। Docling पूरा ML stack hard dependencies के रूप में खींच लेता है, भले आप सिर्फ HTML file convert कर रहे हों:
| Dependency | On-disk size (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ bundled models) | 75.6 |
| docling_parse | 30 |
और यह एक भी PDF convert करने से पहले की बात है। असली friction पहली PDF conversion पर आता है, क्योंकि उसी समय models download होते हैं। एक fresh, isolated HuggingFace cache पर, पहली PDF conversion में लगभग 224 seconds लगे — और उसका लगभग पूरा हिस्सा download time था, compute नहीं। layout और TableFormer models मिलाकर disk पर करीब 506 MiB लेते हैं (342 MiB TableFormer + 164 MiB layout, du से verified), और RapidOCR site-packages में लगभग 40 MB के PP-OCRv4 weights खींच लेता है। उसी file की दूसरी conversion? 0.55 seconds। Models cache हो जाते हैं; toll एक बार देना पड़ता है।
एक संख्या जिसे आपको नज़रअंदाज़ करना चाहिए: coldstart script model_download_mb को 1060.2 दिखाता है। इसे footprint के रूप में quote न करें। यह os.walk से आता है जो symlinks follow करता है, और HuggingFace cache हर model file को blobs/ में एक बार रखता है, फिर snapshots/ symlink के रूप में फिर से दिखाता है — इसलिए walk 14 model files को दो बार गिन लेता है। du-matching, symlink-de-duplicated figure करीब 506 MiB है (blobs-only 505.4 MiB)। Docling benchmark करने वालों के लिए takeaway साफ़ है: download bytes और on-disk bytes को अलग-अलग report करें, क्योंकि वे अलग चीज़ें हैं।
Container बनाने वालों को एक दूसरी जटिलता भी काटती है। Weights दो अलग locations पर, दो अलग schedules पर बँटे हुए हैं। Layout और TableFormer models HF_HOME को मानते हैं और पहली PDF conversion पर download होते हैं। RapidOCR के models ऐसा नहीं करते — वे …/site-packages/rapidocr/models/ में चले जाते हैं, आपकी cache config को पूरी तरह bypass करके। अगर आप image pre-bake कर रहे हैं या air-gap कर रहे हैं, तो दोनों caches संभालनी होंगी; सिर्फ HF_HOME set करने से दूसरा हिस्सा नहीं पकड़ेगा।
अब निष्पक्ष पक्ष। Docling के पहले के releases के बाद, project ने docling-slim ship किया — लगभग 50 MB का core, जिससे आप HTML के लिए pip install docling-slim[format-html] कर सकते हैं, बिना torch खींचे। इसलिए default docling metapackage के लिए 1.3 GB वाला weight सच है, लेकिन अब वह पूरी तरह अनिवार्य नहीं रहा। मैंने default package test किया क्योंकि pip install docling अभी भी वही देता है, लेकिन heaviness अब unaddressed flaw नहीं है — modular fix मौजूद है, और issue #2393 में tracked है।
Setup के दौरान एक छोटा-सा papercut भी मिला, जिसे बताना ज़रूरी है: import docling; docling.__version__ चलाने पर AttributeError: module 'docling' has no attribute '__version__' आता है। Module बस उसे expose नहीं करता। काम करने वाला तरीका है importlib.metadata.version("docling"), जो '2.111.0' लौटाता है। यह एक मामूली DX annoyance है, और July 2026 से upstream में issue #3733 के रूप में open है।
Table Fidelity: जहाँ TableFormer अपनी कीमत वसूलता है
Tables ही वह वजह हैं जिनसे लोग साधारण PDF-to-text dump की जगह Docling चुनते हैं, इसलिए मैंने machine-readable ground truth वाली सात table PDFs बनाईं और output को cell-by-cell score किया। दो metrics important हैं, और वे एक जैसी चीज़ नहीं हैं: cell recall वह हिस्सा है जितने ground-truth values detected table में कहीं भी मिल गए; in-row rate वह हिस्सा है जो सही row में पहुँचे। इन दोनों को मिला देना tool को ज़्यादा अच्छा दिखाता है, इसलिए यहाँ दोनों हैं:
| Table (stress) | Detected | Cell recall | In-row rate | Note |
|---|---|---|---|---|
| T1 simple bordered grid (5×8), alone on page | No | 0.0 | — | classified as <!-- image -->, all cells dropped |
| T2 borderless (only a header rule) | Yes | 1.00 | 1.00 | perfect, exact grid |
| T3 merged 2-level colspan header | Yes | 1.00 | 0.97 | all values found; one header value shifts a row |
| T4 merged rowspan row-label, alone on page | No | 0.0 | — | classified as <!-- image --> |
| T5 colspan header + borderless | Yes | 1.00 | 0.97 | all values found; same header-row shift as T3 |
| T6 financials, blank column, right-aligned | Yes | 1.00 | 1.00 | blank column preserved, not shifted |
| T7 wide 12-column grid | Yes | 1.00 | 1.00 | no column shift on a wide table |
जिन पाँच tables को Docling ने detect किया, उनमें ground-truth का हर value निकल आया — cell recall हर जगह 1.00। उन पाँच में से तीन पर हर value अपनी सही row में भी पहुँची। दो multi-level-header cases (T3 और T5) में एक header value अपनी original row से फिसलकर नीचे चली गई, जिससे in-row 0.97 हो गया — data सब मौजूद है, बस stacked header में row assignment एक बार डगमगा गई।
कठिन structural cases ने उम्मीद से बेहतर पकड़ बनाई। दो-level colspan header GitHub-flavored Markdown में सही flatten हुआ ("Q1 2026" label अपने दो spanned columns पर repeat हुआ, जो colspan को GFM में collapse करने का सही तरीका है)। सिर्फ header rule वाली borderless grid (T2) बिल्कुल सही आई। 12-column wide table (T7) में भी shift नहीं हुआ। और पूरी तरह blank financial column (T6) खाली cells के रूप में preserve हुई, न कि drop या collapse। यह official TableFormer TEDS scores के अनुरूप है — 95.4 simple, 90.1 complex, 93.6 all-tables — जिन्हें model card Camelot (73.0) और EDD (88.3) से बहुत ऊपर benchmark करता है।
Merged cells पर एक चेतावनी ज़रूरी है, क्योंकि एक open issue इसका उलटा भी कहती है। Issue #3698 बताता है कि V1 और V2 merged rows और columns को सही नहीं संभालते। मेरे fixtures पर, simple colspan (T3/T5) और rowspan values ठीक से flatten हुईं, बस ऊपर बताया गया multi-level-header row shift रहा। लेकिन #3698 के failing cases irregular multi-row/multi-column merges और multi-page tables हैं — pathological end। मेरे tests simple end पर थे। इसलिए सही, संकीर्ण कथन यह है: simple colspan और rowspan यहाँ recover हुए (multi-level headers में row shift हो सकता है); complex और irregular merges अभी भी documented open problem हैं। यह नहीं कि "merged cells काम करते हैं," और यह भी नहीं कि "merged cells टूटे हुए हैं।"
वह जाल: अकेली table page पर गायब हो सकती है
Table पर फिर नज़र डालें — T1 और T4 detect ही नहीं हुईं। Docling ने <!-- image --> दिया और हर cell गिरा दिया, बिना कोई error दिखाए। T1 एक बिलकुल सामान्य bordered 5×8 grid है। यह इतना चिंताजनक था कि जब तक मैंने असल trigger isolate नहीं किया, मैंने इसे table-parsing weakness कहने से इनकार किया, इसलिए मैंने scripted A/B बनाया।
पहले, मैंने obvious explanations को हटा दिया। Text layer intact है — pypdfium2 T1 से 327 characters और T4 से 221 characters पढ़ता है, यानी ये असली digital PDFs हैं, scanned images नहीं। OCR बंद (do_ocr=False) करने से भी मदद नहीं मिलती; tables फिर भी गिर जाती हैं। और DoclingDocument को सीधे inspect करने पर len(doc.tables) == 0 और len(doc.pictures) == 1 मिलता है — layout model ने पूरे table region को Picture classify कर दिया था।
फिर निर्णायक test। मैंने वही T1 और T4 tables दोबारा render कीं, इस बार उन्हें कुछ सामान्य body paragraphs के बीच रखकर, और फिर convert किया। दोनों perfect आईं: len(doc.tables) == 1, proper GFM tables निकलीं, और T4b का rowspan label "North" अपनी तीन rows में सही ढंग से repeat हुआ। Table वही। बदला सिर्फ यह कि वह sparse page पर अकेला था या text में embedded था।
तो असली caveat यह नहीं कि TableFormer fragile है — असली बात यह है कि Docling का RT-DETR layout model page context इस्तेमाल करता है, और कोई छोटी table अगर लगभग खाली page पर अकेली हो, तो उसे Picture समझकर silently drop किया जा सकता है। यह व्यवहार में बहुत आसानी से हो जाता है, क्योंकि invoices, spec sheets, और cropped exports अक्सर ऐसे ही दिखते हैं: एक page पर एक table, आसपास कोई prose नहीं। उपाय साधारण और असरदार है — layout model को page context दें, या conversion के बाद doc.tables post-check करें और जहाँ count zero हो, उन pages को flag करें। यह issue #3495 (एक table का Table और Picture दोनों के रूप में detect होना) के आसपास की बात है, लेकिन page-sparsity trigger — वही table, अकेली होने पर drop, embedded होने पर convert — मुझे कहीं published नहीं मिला। मापा हुआ, पहले documented नहीं; ऐसा bug नहीं जिसे कोई जानता ही न हो।
असली scans पर OCR: RapidOCR, EasyOCR नहीं
Scanned PDFs वह जगह हैं जहाँ बहुत से converters चुपचाप fail हो जाते हैं, इसलिए मैंने Docling को दो असली scans दिए जिनकी मापी गई 0-character text layer थी — pypdfium2 zero recoverable characters report करता है, जो पुष्टि करता है कि output OCR से आया है, किसी छिपी text layer से नहीं।
Single-page ocr_test.pdf CPU पर 14.3 seconds में साफ़ निकल आया: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," verbatim recover हुआ। चार-page nemotron_multipage.pdf ने चारों pages पर OCR चलाया, कुल 70.1 seconds में (17.5 s/page), और हर page पर वही test sentence निकली। Default OCR अपने-आप चल गया — कोई flag नहीं, कोई config नहीं।
एक detail जिसे बहुत-सी write-ups गलत बताती हैं: default OCR engine RapidOCR है, EasyOCR नहीं। मैंने पहली run पर PP-OCRv4 .pth weights download होते देखकर इसे confirm किया। बहुत-से मौजूदा blogs और पुरानी Docling FAQ text अभी भी कहते हैं कि EasyOCR default है; वह जानकारी पुरानी है। EasyOCR अब एक extra है जिसे आप opt-in करते हैं। जो caveat सच रहता है: OCR scale पर slow path है, और यहाँ सबकुछ CPU-only ceiling है — GPU होने पर ये time काफ़ी घट जाते हैं।
असली PDFs, reading order, और per-page time
Synthetic fixtures specific behaviors साबित करती हैं; real PDFs यह साबित करते हैं कि चीज़ सच में काम करती है। मैंने दो born-digital academic papers चलाए — 9-page Docling technical report और 15-page "Attention Is All You Need," दोनों two-column, tables और formulas के साथ।
15-page Attention paper पर, सभी पाँच section markers — Abstract, Introduction, Background, Conclusion, References — linearized Markdown में document order में दिखते हैं, despite two-column layout। हर content probe (Transformer, encoder, BLEU, multi-head) मौजूद है, और famous multi-column results tables चार detected tables के रूप में दर्ज हुईं। यह असली reading-order और column-merge recovery है, जो RAG chunking के लिए core value proposition है — अगर linearizer two-column page को interleaved nonsense में बदल दे, तो document को समझदारी से chunk नहीं किया जा सकता।
Timing एक उलटा सा सबक देती है। Per-page time page count से नहीं, बल्कि हर page पर कितनी structure है उससे तय होता है। ज़्यादा dense 9-page report 14.95 seconds per page पर चला — 15-page paper के 5.99 seconds per page से धीमा — क्योंकि उसमें tables और figures ज़्यादा थे, और हर एक extra layout तथा TableFormer inference trigger करता है। इसलिए CPU पर "seconds per page" length का नहीं, structural density का function है। यह single CPU-only run है; यह production number नहीं, ceiling है।
Multi-Format और lossless-JSON का दावा
Docling unified multi-format parsing का दावा करता है, इसलिए मैंने एक DOCX, एक XLSX, और एक PPTX ज्ञात content और ground-truth probes के साथ बनाए, फिर दो चीज़ें जाँचीं: क्या probes Markdown में दिखते हैं, और क्या export_to_dict() के जरिए JSON round-trip के बाद भी बचे रहते हैं।
| File | Convert s | MD probes found | Tables in MD | Probes survive JSON |
|---|---|---|---|---|
report.docx (headings + merged-"Total" table + bullets) | 0.137 | 7/7 | 1 | Yes |
workbook.xlsx (2 sheets, blank column) | 0.016 | 6/6 | 2 | Yes |
deck.pptx (3 slides, bullets + table) | 0.038 | 6/6 | 1 | Yes |
सभी content probes Markdown में पहुँच गए, tables recover हुईं (DOCX की merged "Total" row और XLSX की दोनों sheets सहित), और हर probe export_to_dict() JSON में भी बचा रहा — यही evidence lossless-DoclingDocument claim के लिए मायने रखता है, कम-से-कम साफ़ inputs पर। ये formats format-native backends से गुजरते हैं, ML models से नहीं, इसलिए वे कुछ मिलीसेकंड में चलते हैं और पूरी तरह offline काम करते हैं। Scope ईमानदार है: हर format की एक साफ़ file breadth साबित करती है, pathological Office files का stress test नहीं।
HTML: faithful, लेकिन साफ़ नहीं
यही caveat तय करता है कि Docling आपकी RAG pipeline में आएगा या नहीं, इसलिए ध्यान से पढ़ें। Docling पूरे HTML document को convert करता है। यह readability-style main-content extraction नहीं करता। मैंने यह मापा कि site chrome कितना बचता है, Docling के अपने output में nav, TOC, cookie, और footer marker lines गिनकर।
| Page | Non-blank MD lines | Boilerplate lines | % boilerplate | Article starts at line |
|---|---|---|---|---|
| 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% | — |
Wikipedia जैसी chrome-heavy page पर लगभग 13% Markdown lines nav/TOC/footer boilerplate हैं, और असली article line 28 तक शुरू नहीं होता — output "move to sidebar / Contents / Toggle the table of contents" से खुलता है और "CS1 maint… / Search Wikipedia" पर बंद होता है। साफ़ content pages (books, quotes) पर यह लगभग 0% है, इसलिए यह per-page tax नहीं, template-chrome problem है। Docling आपको faithful full-document Markdown देता है, clean main-article extraction नहीं। Upstream HTML furniture problem को issue #1865 (closed) और #1930 (open) में track करता है।
दो बातें इसे निष्पक्ष बनाती हैं। पहली, HTML के मामले में Docling कोई ML model नहीं चलाता — यह एक simple pipeline पर BeautifulSoup backend है। "vision models आपकी page पढ़ रही हैं" वाली कहानी PDF और images पर लागू होती है; Docling को HTML दें, तो layout या TableFormer machinery कुछ नहीं चलाती। दूसरी, PDF path header और footer furniture classification की कोशिश करता है, इसलिए "कहीं भी boilerplate removal नहीं" कहना बहुत कड़ा दावा होगा — खास तौर पर HTML backend ही chrome वापस देता है।
यह किसके मुकाबले खड़ा है — और Thunderbit कहाँ फिट होता है
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ
जिस tool से लोग Docling की तुलना सबसे ज़्यादा करते हैं, वह Firecrawl है, इसलिए यहाँ positioning table है। पहले एक चेतावनी: यह documentation-level comparison है, same-machine benchmark नहीं। मैंने इन fixtures पर Firecrawl नहीं चलाया। यहाँ केवल Docling column measured है; Firecrawl column उसकी public docs से लिया गया है।
| Axis | Firecrawl (per its docs) | Docling (measured here) |
|---|---|---|
| Core job | Crawl + scrape the live web → Markdown | Convert a document you already have → Markdown/JSON |
| Fetching / JS render / anti-bot | Yes (hosted browser) | No — you supply the file |
| Main-content extraction | Yes | No — faithful full-document (~13% chrome on Wikipedia) |
| PDF table structure (ML) | limited | Yes — TableFormer (TEDS 93.6 official; cell recall 1.00, in-row 0.97–1.00 on detected fixtures) |
| Scanned PDF / OCR | limited | Yes — RapidOCR by default (recovered a 0-text-layer scan) |
| Format breadth | web pages | PDF/DOCX/PPTX/XLSX/HTML/EPUB/images |
| Deployment | hosted API (+ self-host) | local pip library, offline, no API key |
| Setup weight | API key / light client | 1.3 GB default install + ~506 MiB models (or docling-slim) |
| License | commercial / source-available | MIT |
एक line में बात: Firecrawl तब उपयोगी है जब आपका data live web पर हो और उसे crawling, JS rendering, और main-content cleanup की ज़रूरत हो। Docling तब उपयोगी है जब document पहले से आपके पास हो — खासकर PDFs, scans, और table-heavy Office files — और आपको faithful, offline, structure-preserving conversion चाहिए जिसमें table और OCR की असली समझ हो। ये दोनों एक-दूसरे के पूरक हैं। एक realistic pipeline एक से crawl करती है और दूसरे से documents convert करती है।
यहीं मैं Thunderbit के बारे में साफ़ बोलूँगा, क्योंकि मैं यहाँ काम करता हूँ और अगर मैं दिखावा करूँ कि कुछ और है, तो आपको शक होना चाहिए। Thunderbit और Docling एक ही काम नहीं करते, और मैं उन्हें जबरन बराबर नहीं ठहराऊँगा। Developers के लिए Thunderbit एक AI scraping API, MCP server, और CLI है, और इसकी work unit live web page है: POST /distill किसी URL को clean, LLM-ready Markdown में बदलता है (JS rendering, anti-bot, और CAPTCHA को संभालते हुए, जिन्हें Docling explicitly नहीं छूता), और POST /extract आपकी defined JSON Schema के आधार पर schema-matched structured JSON लौटाता है। यह RAG pipeline का fetch-and-clean हिस्सा है। Docling local-document end है — PDF, scan, spreadsheet, जो आपकी disk पर पहले से पड़ा है। अगर आपका corpus web pages है, तो Thunderbit API, इसके MCP tools (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract), या CLI (npx @thunderbit/thunderbit-cli) लें। अगर PDFs और scans हैं, तो Docling लें। अगर दोनों हैं — जो real pipelines में अक्सर होता है — तो दोनों को साथ जोड़िए, और कोई भी दूसरे बनने की कोशिश नहीं कर रहा।
अंतिम निष्कर्ष: provisional, और अभी कुछ homework बाकी है
मैं आपको 0–100 की एक single score नहीं दूँगा, क्योंकि यहाँ weighted total में उन चीज़ों की penalties भी शामिल हो जाएँगी जिनका Docling ने दावा ही नहीं किया (जैसे crawling), और फिर उन्हें comparable मान लिया जाएगा। जिन fixtures पर मैंने test किया, हर dimension पर स्थिति यह है:
- Setup / first run: भारी — 1.3 GB venv, ~506 MiB models, ~224s first PDF, ~0.55s warm — लेकिन
docling-slimweight से बाहर निकलने का विकल्प देता है। - Table fidelity: जब table detect हो जाए तो मज़बूत (5/5 पर cell recall 1.00, in-row 0.97–1.00), और इन fixtures पर official TEDS story से मेल खाती है।
- Table detection robustness: sparse-page trap — अकेली table Picture बनकर गिर सकती है।
doc.tablespost-check करें। - Scanned / OCR: काम करता है, RapidOCR by default; scale पर धीमा।
- Multi-format: solid, और JSON round-trip intact है।
- HTML: faithful, लेकिन साफ़ नहीं — main-content extraction नहीं।
- Developer experience: साफ़ 3-line API और व्यवस्थित
DoclingDocument, बस missing__version__के साथ।
यह किसके लिए है: वे teams जो PDFs, scans, और Office files पर आधारित RAG या data pipelines बना रही हैं और जिन्हें offline, structure-preserving conversion तथा table + OCR की असली समझ चाहिए। यह किसके लिए नहीं है: जिसे live-web crawling या clean main-article HTML extraction चाहिए — वह अलग tool का काम है।
और क्योंकि यह review है, press release नहीं, इसलिए सीमाएँ label पर ही रहेंगी। यह एक targeted probe है — 7 synthetic tables plus 2 real PDFs, एक CPU-only machine पर — TEDS-scale accuracy benchmark नहीं। कुछ चीज़ें मैंने test नहीं कीं, और आपको भी pipeline भरोसा करने से पहले करनी चाहिए: optional VLM (GraniteDocling) path, असल docling-slim footprint, कोई GPU run, complex और irregular merged cells plus multi-page tables, formula-to-LaTeX fidelity, और — production में शायद सबसे बड़ा surprise — batch memory growth, thread/GIL scaling, और object lifecycle की durability across thousands of conversions। Docling उस चीज़ में मजबूत है जिसका यह दावा करता है, measured है, marketed नहीं; और इसके कुछ असली किनारे हैं जिन्हें corpus पर भरोसा करने से पहले map करना होगा। sparse-page caveat जानिए, first-run download के लिए budget रखिए, और at-scale behavior खुद verify कीजिए।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ Get Started Free
FAQs
क्या Docling एक web scraper या crawler है? नहीं। Docling उन documents को convert करता है जो आपके पास पहले से हैं — PDF, DOCX, PPTX, XLSX, HTML, images — और उन्हें Markdown या JSON में बदलता है। यह URLs fetch नहीं करता, JavaScript render नहीं करता, और anti-bot handling भी नहीं करता। live web crawling Firecrawl या Thunderbit’s web API जैसे tools का अलग काम है; Docling उस file से शुरू होता है जो आप देते हैं।
Docling का install और first-run download कितना बड़ा है?
Default docling metapackage लगभग 1.3 GB का venv बनाता है क्योंकि यह full ML stack को hard dependencies के रूप में खींचता है (सिर्फ torch ही 536 MiB है)। पहली PDF conversion disk पर लगभग 506 MiB के layout और TableFormer models + लगभग 40 MB RapidOCR weights डाउनलोड करती है, और लगभग 224 seconds लेती है — लगभग पूरा समय download में जाता है। दूसरी conversion लगभग 0.55 seconds होती है। अगर आपको सिर्फ lightweight formats चाहिए, तो docling-slim (~50 MB core) heavy path छोड़ देता है।
क्या Docling OCR करता है, और किस engine से? हाँ। बिना text layer वाली scanned PDF पर Docling का OCR अपने-आप चालू हो जाता है और मेरे test में text साफ़ recover हुआ। Default engine RapidOCR है, EasyOCR नहीं — जो पुराने write-ups में अक्सर गलत बताया जाता है। EasyOCR अब opt-in extra है। OCR scale पर slow path है, खासकर CPU पर।
Docling ने मेरी table को image क्यों बना दिया या उसे drop क्यों कर दिया?
सबसे संभावित कारण sparse-page effect है। Docling का RT-DETR layout model page context इस्तेमाल करता है, और लगभग खाली page पर अकेली छोटी table Picture के रूप में classify होकर silently drop हो सकती है। वही table अगर body text के बीच हो, तो ठीक convert हो जाती है। उपाय है layout model को page context देना, या conversion के बाद doc.tables को post-check करके जहाँ count zero हो, उस page को flag करना।
Docling बनाम Firecrawl — किसे इस्तेमाल करूँ? काम अलग हैं, इसलिए आमतौर पर यह either/or नहीं होता। Firecrawl live web crawl करता है, JavaScript render करता है, और main content निकालता है। Docling आपके पास मौजूद documents को convert करता है, जिसमें real PDF table structure और OCR होता है, और यह पूरी तरह offline चलता है। अगर source web pages हैं, तो web tool इस्तेमाल करें (Firecrawl, या Thunderbit API/MCP/CLI)। अगर PDFs, scans, या Office files हैं, तो Docling लें। असली pipelines में अक्सर दोनों साथ चलते हैं।
