Docling sering dimasukkan ke kategori yang sama dengan web scraper, padahal sebenarnya bukan. Ini adalah toolkit konversi dokumen dari IBM Research — kini menjadi proyek LF AI & Data Foundation — yang mengambil file yang sudah Anda miliki (PDF, DOCX, PPTX, XLSX, HTML, gambar) lalu mengubahnya menjadi Markdown atau JSON. Tagline resminya bahkan secara harfiah berbunyi: "Get your documents ready for gen AI."
Jadi ini adalah ulasan langsung tentang sebuah konverter, bukan crawler. Semua pengujian di bawah dilakukan pada satu mesin CPU-only (macOS arm64, Python 3.14.2, Docling 2.111.0), diberi skor dari skrip, dan kegagalan dicatat sebagai kegagalan. Repositori ini sangat besar dan terus berubah setiap hari — 63.069 bintang, 4.449 fork, dan ada commit di hari yang sama ketika saya menarik metadatanya — jadi anggaplah jumlah isu atau nomor versi di sini sebagai potret sesaat, bukan sesuatu yang tetap.
Apa Itu Docling Sebenarnya (dan Bukan)
Unit dasar di Docling adalah DoclingDocument: file diparse ke struktur itu, lalu diekspor ke Markdown, HTML, DocTags, atau JSON lossless. Kodenya berlisensi MIT (lisensi model individual bisa berbeda), berasal dari IBM Research Zurich, dan saat tulisan ini dibuat rilis terbaru adalah v2.112.0, dipublikasikan dua hari sebelum saya menjalankan pengujian ini.
Kemampuan utamanya ada pada jalur PDF dan gambar. Jalur ini bukan parsing string — melainkan tumpukan model machine learning: model tata letak RT-DETR, model struktur tabel TableFormer, model vision-language opsional, dan RapidOCR untuk hasil scan. Model-model itu memulihkan layout halaman, urutan baca, dan struktur tabel. Itulah bagian yang layak diuji, dan bagian yang tidak akan pernah terlihat oleh tes yang hanya mengandalkan HTML.
Ada satu perbedaan yang menghindarkan Anda dari kebingungan berhari-hari. Docling tidak mengambil apa pun dari web. Ia tidak merender JavaScript, tidak menembus anti-bot wall, dan tidak melakukan crawling. Anda membawa filenya; Docling memahaminya. Crawling adalah tugas alat lain, dan ini penting nanti ketika orang bertanya apakah Docling menggantikan Firecrawl (tidak — keduanya saling melengkapi, dan saya akan jelaskan alasannya).
Run Pertama yang Tidak Banyak Orang Peringatkan
pip install docling berhasil mulus di Python 3.14.2. Lalu Anda melihat venv-nya, dan ukurannya 1,3 GB. Docling menarik seluruh stack ML sebagai dependensi wajib, bahkan jika yang Anda konversi hanya file HTML:
| Dependensi | Ukuran di disk (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ model bawaan) | 72.1 |
| docling_parse | 30 |
Itu pun sebelum Anda mengonversi satu PDF saja. Konversi PDF pertama adalah saat hambatan sebenarnya muncul, karena di situlah model mulai diunduh. Pada cache HuggingFace yang baru dan terisolasi, konversi PDF pertama memakan waktu ~224 detik — dan hampir semuanya habis untuk unduhan, bukan komputasi. Model layout plus TableFormer memakan ruang ~506 MiB di disk (342 MiB TableFormer + 164 MiB layout, diverifikasi dengan du), dan RapidOCR mengambil sekitar 40 MB bobot PP-OCRv4 ke site-packages. Konversi kedua untuk file yang sama? 0,55 detik. Modelnya sudah dicache; bayar ongkosnya sekali.
Ada satu angka yang sebaiknya Anda abaikan: skrip coldstart menampilkan model_download_mb sebesar 1060,2. Jangan jadikan itu footprint. Angka itu berasal dari os.walk yang mengikuti symlink, sementara cache HuggingFace menyimpan setiap file model satu kali di bawah blobs/ lalu menampilkannya lagi lewat symlink snapshots/ — jadi traversal itu menghitung 14 file model dua kali. Angka yang cocok dengan du dan sudah menghindari duplikasi symlink adalah ~506 MiB (hanya blobs: 505,4 MiB). Intinya bagi siapa pun yang membenchmark Docling: laporkan bytes unduhan dan bytes di disk sebagai dua angka berbeda, karena memang berbeda.
Ada satu kerutan lagi yang akan menjebak siapa pun yang membangun container Docling. Bobot model tersebar di dua lokasi dengan dua jadwal berbeda. Model layout dan TableFormer mengikuti HF_HOME dan diunduh saat konversi PDF pertama. Model RapidOCR tidak — ia mendarat di …/site-packages/rapidocr/models/, sepenuhnya melewati konfigurasi cache Anda. Jika Anda sedang menyiapkan image secara pre-bake atau air-gapped, Anda harus menangani kedua cache itu, dan seberapa pun Anda menyetel HF_HOME tidak akan menangkap yang kedua.
Sekarang bagian yang adil. Sejak rilis Docling sebelumnya, proyek ini merilis docling-slim — core sekitar 50 MB yang memungkinkan Anda pip install docling-slim[format-html] untuk HTML tanpa menyeret torch. Jadi bobot 1,3 GB memang nyata untuk metapackage default docling, tetapi kini sifatnya opsional. Saya menguji paket default karena itulah yang masih diberikan oleh pip install docling, namun beban berat itu bukan lagi kelemahan yang dibiarkan tanpa solusi — perbaikan modularnya sudah ada, tercatat di issue #2393.
Saat setup, saya juga menemukan satu hal kecil yang cukup mengganggu: import docling; docling.__version__ memunculkan AttributeError: module 'docling' has no attribute '__version__'. Modulnya memang tidak mengeksposnya. Cara yang benar adalah importlib.metadata.version("docling"), yang mengembalikan '2.111.0'. Ini cuma gangguan kecil DX, dan sudah terbuka sejak Juli 2026 sebagai issue #3733.
Akurasi Tabel: Di Sini TableFormer Menunjukkan Nilainya
Tabel adalah alasan orang memakai Docling alih-alih dump PDF-to-text biasa, jadi saya membuat tujuh PDF tabel dengan ground truth yang bisa dibaca mesin dan menilai hasilnya sel per sel. Ada dua metrik yang penting, dan keduanya bukan hal yang sama: cell recall adalah persentase nilai ground truth yang muncul di mana pun dalam tabel yang terdeteksi; in-row rate adalah persentase yang jatuh ke baris yang benar. Mencampuradukkan keduanya akan membuat alat tampak lebih baik dari sebenarnya, jadi berikut keduanya:
| Tabel (stress) | Terdeteksi | Cell recall | In-row rate | Catatan |
|---|---|---|---|---|
| T1 grid berbingkai sederhana (8 baris × 5 kolom), sendirian di halaman | Tidak | 0.0 | — | diklasifikasikan sebagai <!-- image -->, semua sel hilang |
| T2 tanpa garis tepi (hanya ada rule header) | Ya | 1.00 | 1.00 | sempurna, grid tepat |
| T3 header colspan 2 tingkat-2 yang digabung | Ya | 1.00 | 0.97 | semua nilai ditemukan; satu nilai header bergeser satu baris |
| T4 row-label rowspan yang digabung, sendirian di halaman | Tidak | 0.0 | — | diklasifikasikan sebagai <!-- image --> |
| T5 header colspan + tanpa border | Ya | 1.00 | 0.97 | semua nilai ditemukan; pergeseran baris header yang sama seperti T3 |
| T6 data keuangan, kolom kosong, rata kanan | Ya | 1.00 | 1.00 | kolom kosong dipertahankan, tidak bergeser |
| T7 grid lebar 12 kolom | Ya | 1.00 | 1.00 | tidak ada pergeseran kolom pada tabel lebar |
Pada lima tabel yang berhasil dideteksi Docling, semua nilai ground truth berhasil lewat — cell recall 1.00 di semua kasus. Pada tiga dari lima itu, setiap nilai juga jatuh di baris yang benar. Pada dua kasus header multi-level (T3 dan T5), satu nilai header meleset dari baris asalnya, sehingga in-row turun ke 0.97 — semua datanya ada, hanya penempatan barisnya yang sedikit goyah pada header bertingkat.
Kasus struktural yang sulit ternyata lebih tahan dari yang saya duga. Header colspan dua tingkat diratakan dengan benar ke GitHub-flavored Markdown (label "Q1 2026" diulang di atas dua kolom yang dicakupnya, dan itu cara yang tepat untuk meratakan colspan ke GFM). Grid tanpa border dengan hanya rule header (T2) keluar secara presisi. Tabel lebar 12 kolom (T7) tidak bergeser. Dan kolom keuangan yang sepenuhnya kosong (T6) tetap dipertahankan sebagai sel kosong, bukan dibuang atau digabung. Ini konsisten dengan skor resmi TableFormer TEDS — 95,4 simple, 90,1 complex, 93,6 all-tables — yang pada model card dibenchmark jauh di atas Camelot (73,0) dan EDD (88,3).
Satu peringatan soal merged cells, karena ada issue terbuka yang bilang sebaliknya. Issue #3698 melaporkan bahwa V1 dan V2 salah menangani baris dan kolom yang digabung. Pada fixture saya, colspan sederhana (T3/T5) dan nilai rowspan diratakan dengan benar, dengan hanya pergeseran baris pada header bertingkat yang disebut di atas. Namun kasus gagal di #3698 adalah merge multi-baris/multi-kolom yang tidak rapi dan tabel multi-halaman — bagian patologis yang paling ekstrem. Pengujian saya berada di ujung yang sederhana. Jadi pernyataan yang akurat harus sempit: colspan dan rowspan sederhana berhasil dipulihkan di sini (header bertingkat bisa menggeser satu baris); merge yang kompleks dan tidak teratur masih merupakan masalah terbuka yang terdokumentasi. Bukan "merged cells berfungsi", juga bukan "merged cells rusak".
Jebakannya: Tabel yang Sendirian di Satu Halaman Bisa Hilang
Lihat lagi tabel di atas — T1 dan T4 sama sekali tidak terdeteksi. Docling mengeluarkan <!-- image --> dan membuang semua sel tanpa error. T1 adalah grid biasa berbingkai dengan 8 baris dan 5 kolom. Itu cukup mengkhawatirkan sampai saya menolak menyebutnya sekadar kelemahan parsing tabel sebelum mengisolasi pemicunya, jadi saya membuat A/B yang terskrip.
Pertama, saya menyingkirkan penjelasan yang paling jelas. Lapisan teksnya utuh — pypdfium2 membaca 327 karakter dari T1 dan 221 dari T4, jadi ini PDF digital sungguhan, bukan gambar hasil scan. Mematikan OCR (do_ocr=False) tidak membantu; tabelnya tetap hilang. Lalu saat saya memeriksa DoclingDocument secara langsung, len(doc.tables) == 0 sementara len(doc.pictures) == 1 — model layout telah mengklasifikasikan seluruh area tabel sebagai Picture.
Lalu tes penentu. Saya merender ulang T1 dan T4 yang sama persis, tetapi kali ini dikelilingi beberapa paragraf isi biasa, lalu dikonversi lagi. Keduanya masuk dengan sempurna: len(doc.tables) == 1, tabel GFM keluar dengan benar, dan label rowspan T4b "North" diulang dengan benar di tiga barisnya. Tabelnya sama. Satu-satunya variabel yang berubah hanyalah apakah ia berdiri sendiri di halaman yang sangat kosong atau tertanam di dalam teks.
Jadi caveat yang sebenarnya bukan bahwa TableFormer rapuh — melainkan bahwa model layout RT-DETR milik Docling bergantung pada konteks halaman, dan tabel kecil yang berdiri sendiri di halaman yang hampir kosong sangat mudah dibaca sebagai Picture lalu dibuang diam-diam. Ini gampang sekali terjadi di praktik, karena memang begitu bentuk invoice, lembar spesifikasi, dan hasil ekspor yang dipotong: satu tabel per halaman, tanpa teks di sekelilingnya. Solusinya sederhana dan efektif — berikan konteks halaman ke model layout, atau cek ulang doc.tables setelah konversi dan tandai halaman yang jumlahnya nol. Ini berdekatan dengan issue #3495 (tabel terdeteksi sebagai Table sekaligus Picture), tetapi pemicu khusus karena halaman yang terlalu kosong — tabel yang sama hilang saat sendirian, lalu berhasil saat ditempatkan dalam teks — saya tidak menemukan publikasinya di mana pun. Terukur, belum terdokumentasi sebelumnya; bukan bug yang tak seorang pun tahu.
OCR pada Scan Asli: RapidOCR, Bukan EasyOCR
PDF hasil scan adalah tempat banyak konverter diam-diam gagal, jadi saya memberi Docling dua scan sungguhan dengan lapisan teks 0 karakter yang terukur — pypdfium2 melaporkan nol karakter yang bisa dipulihkan, memastikan output apa pun berasal dari OCR, bukan teks tersembunyi yang ikut menempel.
File satu halaman ocr_test.pdf kembali bersih dalam 14,3 detik di CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," berhasil dipulihkan verbatim. File empat halaman nemotron_multipage.pdf menjalankan OCR pada keempat halaman dalam total 70,1 detik (17,5 dtk/halaman), dan menampilkan kalimat uji yang berulang di tiap halaman. OCR default aktif otomatis — tanpa flag, tanpa konfigurasi.
Detail yang paling sering salah ditulis orang adalah ini: mesin OCR default-nya adalah RapidOCR, bukan EasyOCR. Saya memastikannya dengan melihat bobot PP-OCRv4 .pth diunduh pada run pertama. Banyak blog dan FAQ Docling lama masih bilang default-nya EasyOCR; itu sudah usang. Sekarang EasyOCR adalah ekstra opsional yang harus Anda pilih sendiri. Caveat yang tetap benar: OCR adalah jalur lambat saat skala besar, dan semua angka di sini adalah batas atas pada CPU-only — GPU akan memangkas waktu ini secara signifikan.
PDF Nyata, Urutan Baca, dan Waktu per Halaman
Fixture sintetis membuktikan perilaku tertentu; PDF nyata membuktikan bahwa alat ini benar-benar bekerja. Saya menjalankan dua paper akademik digital asli — laporan teknis Docling 9 halaman dan "Attention Is All You Need" 15 halaman, keduanya dua kolom dengan tabel dan formula.
Pada paper Attention 15 halaman, kelima penanda bagian — Abstract, Introduction, Background, Conclusion, References — muncul dalam urutan dokumen di Markdown yang sudah dilinearisasi, meski layout-nya dua kolom. Semua probe konten (Transformer, encoder, BLEU, multi-head) muncul, dan tabel hasil multi-kolom yang terkenal terdeteksi sebagai empat tabel. Itu benar-benar pemulihan urutan baca dan penggabungan kolom, yang menjadi nilai inti untuk chunking RAG — Anda tidak bisa melakukan chunking dengan baik kalau linearizer mengacak halaman dua kolom menjadi teks campur aduk yang tak masuk akal.
Timing-nya memberi pelajaran yang agak tidak intuitif. Waktu per halaman ditentukan oleh seberapa banyak struktur yang ada di tiap halaman, bukan oleh jumlah halaman. Laporan 9 halaman yang lebih padat berjalan pada 14,95 detik per halaman — lebih lambat per halaman daripada paper 15 halaman yang hanya 5,99 detik per halaman — karena ia memuat lebih banyak tabel dan figur per halaman — 3 tabel di 9 halaman dibanding 4 di 15 halaman — dan setiap item memicu lebih banyak inferensi layout dan TableFormer. Itu margin yang tipis, dan secara absolut dokumen yang lebih padat justru punya lebih sedikit tabel, bukan lebih banyak. Jadi "detik per halaman" di CPU adalah fungsi kepadatan struktur, bukan panjang dokumen. Ini hanya satu run CPU-only; ini batas atas, bukan angka produksi.
Multi-Format dan Klaim JSON Lossless
Docling mengiklankan parsing multi-format terpadu, jadi saya membuat DOCX, XLSX, dan PPTX dengan konten yang sudah diketahui dan probe ground truth, lalu memeriksa dua hal: apakah probe muncul di Markdown, dan apakah semuanya bertahan pada round-trip JSON melalui export_to_dict().
| File | Konversi dtk | Probe MD ditemukan | Tabel di MD | Probe bertahan di JSON |
|---|---|---|---|---|
report.docx (heading + tabel gabungan "Total" + bullet) | 0.137 | 7/7 | 1 | Ya |
workbook.xlsx (2 sheet, kolom kosong) | 0.016 | 6/6 | 2 | Ya |
deck.pptx (3 slide, bullet + tabel) | 0.038 | 6/6 | 1 | Ya |
Semua probe konten muncul di Markdown, tabel berhasil dipulihkan (termasuk baris gabungan "Total" pada DOCX dan kedua sheet XLSX), dan setiap probe juga bertahan melewati JSON export_to_dict() — ini bukti yang penting untuk klaim DoclingDocument lossless, setidaknya pada input yang bersih. Format-format ini lewat backend asli format, bukan lewat model ML, sebab itu mereka berjalan dalam puluhan milidetik dan bisa bekerja sepenuhnya offline. Cakupannya jujur: satu file bersih per format membuktikan keluasan, bukan uji stres terhadap file Office yang patologis.
HTML: Setia, Tapi Tidak Bersih
Ini caveat yang akan menentukan apakah Docling pantas masuk pipeline RAG Anda, jadi baca dengan teliti. Docling mengonversi seluruh dokumen HTML. Ia tidak melakukan ekstraksi konten utama ala readability. Saya mengukur seberapa banyak chrome situs yang ikut bertahan dengan menghitung baris nav, TOC, cookie, dan footer di output Docling sendiri.
| Halaman | Baris MD non-kosong | Baris boilerplate | % boilerplate | Artikel mulai di baris |
|---|---|---|---|---|
| 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% | — |
Pada halaman yang penuh chrome seperti Wikipedia, sekitar 13% baris Markdown adalah boilerplate nav/TOC/footer, dan artikel aslinya baru mulai di baris 28 — output dibuka dengan "move to sidebar / Contents / Toggle the table of contents" dan ditutup dengan "CS1 maint… / Search Wikipedia." Pada halaman konten yang bersih (books, quotes) angkanya sekitar 0%, jadi ini masalah chrome template, bukan pajak per halaman. Docling memberi Anda Markdown seluruh dokumen yang setia, bukan ekstraksi artikel utama yang bersih. Upstream mencatat masalah furniture HTML ini di issue #1865 (ditutup) dan #1930 (masih terbuka).
Ada dua hal yang membuat penilaian ini tetap adil. Pertama, khusus HTML, Docling sama sekali tidak menjalankan model ML — backend-nya adalah BeautifulSoup dalam pipeline sederhana. Cerita soal "model vision membaca halaman Anda" hanya berlaku untuk PDF dan gambar; jika Anda memberi Docling HTML, maka seluruh mesin layout dan TableFormer tidak akan aktif. Kedua, jalur PDF memang mencoba klasifikasi furniture header dan footer, jadi mengatakan "tidak ada penghapusan boilerplate sama sekali" akan terlalu berlebihan — yang mengembalikan chrome adalah backend HTML, secara spesifik.
Perbandingannya Seperti Apa (dan Di Mana Thunderbit Cocok)
Coba Thunderbit untuk Ekstraksi Data Web
Alat pembanding utama yang sering disebut orang bersama Docling adalah Firecrawl, jadi berikut tabel posisinya. Satu catatan penting di depan, karena ini penting: ini adalah perbandingan level dokumentasi, bukan benchmark di mesin yang sama. Saya tidak menjalankan Firecrawl pada fixture ini. Hanya kolom Docling yang diukur di sini; kolom Firecrawl diambil dari dokumentasi publiknya.
| Aspek | Firecrawl (menurut dokumennya) | Docling (diukur di sini) |
|---|---|---|
| Tugas inti | Crawl + scrape web langsung → Markdown | Mengonversi dokumen yang sudah Anda miliki → Markdown/JSON |
| Fetching / render JS / anti-bot | Ya (browser ter-host) | Tidak — Anda yang menyediakan file |
| Ekstraksi konten utama | Ya | Tidak — full document yang setia (~13% chrome di Wikipedia) |
| Struktur tabel PDF (ML) | terbatas | Ya — TableFormer (TEDS resmi 93.6; cell recall 1.00, in-row 0.97–1.00 pada fixture yang terdeteksi) |
| PDF scan / OCR | terbatas | Ya — RapidOCR secara default (berhasil membaca scan dengan layer 0 teks) |
| Cakupan format | halaman web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/gambar |
| Deployment | API ter-host (+ self-host) | library pip lokal, offline, tanpa API key |
| Bobot setup | API key / client ringan | instalasi default 1.3 GB + ~506 MiB model (atau docling-slim) |
| Lisensi | komersial / source-available | MIT |
Versi singkatnya: Firecrawl adalah alat yang tepat saat data Anda ada di web langsung dan butuh crawling, rendering JS, dan pembersihan konten utama. Docling adalah alat yang tepat saat Anda sudah memegang dokumennya — terutama PDF, scan, dan file Office yang kaya tabel — dan ingin konversi offline yang setia, menjaga struktur, dengan pemahaman tabel dan OCR yang nyata. Keduanya saling melengkapi. Pipeline yang realistis melakukan crawling dengan satu alat dan konversi dokumen dengan yang lain.
Di sini saya akan jujur soal Thunderbit, karena saya bekerja di sana dan wajar kalau Anda skeptis jika saya pura-pura tidak memihak. Thunderbit dan Docling tidak mengerjakan tugas yang sama, dan saya tidak akan memaksakan kesetaraan palsu. Untuk developer, Thunderbit adalah AI scraping API plus MCP server plus CLI, dan unit kerjanya adalah halaman web langsung: POST /distill mengubah URL menjadi Markdown bersih siap LLM (menangani rendering JS, anti-bot, dan CAPTCHA yang secara eksplisit tidak disentuh Docling), dan POST /extract mengembalikan JSON terstruktur yang cocok skema melalui JSON Schema yang Anda definisikan. Itu adalah ujung fetch-and-clean dari pipeline RAG. Docling adalah ujung dokumen lokal — PDF, scan, spreadsheet yang sudah ada di disk Anda. Jika korpus Anda berupa halaman web, gunakan API Thunderbit, tools MCP-nya (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract), atau CLI (npx @thunderbit/thunderbit-cli). Jika isinya PDF dan scan, gunakan Docling. Jika keduanya — yang memang terjadi di sebagian besar pipeline nyata — pakailah keduanya bersama, karena salah satunya tidak sedang berusaha menjadi yang lain.
Putusan: Sementara, dan Masih Ada PR yang Harus Dikerjakan
Saya tidak akan memberi Anda skor tunggal 0–100, karena total berbobot di sini akan memasukkan penalti untuk hal-hal yang tidak pernah diklaim Docling sebagai tugasnya (seperti crawling) dan berpura-pura semuanya bisa dibandingkan. Per dimensi, pada fixture yang saya uji:
- Setup / run pertama: berat — venv 1,3 GB, model ~506 MiB, ~224 dtk PDF pertama, ~0,55 dtk warm — tetapi
docling-slimmemberi opsi untuk menghindari beban itu. - Akurasi tabel: kuat ketika tabel terdeteksi (cell recall 1.00 pada 5/5, in-row 0.97–1.00), sesuai dengan cerita TEDS resmi pada fixture ini.
- Ketahanan deteksi tabel: jebakan sparse-page — tabel yang sendirian bisa hilang sebagai Picture. Cek ulang
doc.tables. - Scan / OCR: berfungsi, RapidOCR secara default; lambat saat skala besar.
- Multi-format: solid, dengan round-trip JSON tetap utuh.
- HTML: setia, tapi tidak bersih — tidak ada ekstraksi konten utama.
- Pengalaman developer: API 3 baris yang rapi dan
DoclingDocumentyang tertata, minus__version__yang hilang.
Untuk siapa alat ini cocok: tim yang membangun RAG atau pipeline data di atas PDF, scan, dan file Office yang ingin konversi offline, menjaga struktur, serta memahami tabel dan OCR secara nyata. Untuk siapa tidak cocok: siapa pun yang membutuhkan crawling web langsung atau ekstraksi artikel utama HTML yang bersih — itu alat yang berbeda.
Dan karena ini sebuah ulasan, bukan siaran pers, batasannya tetap dicantumkan. Ini adalah pengujian terarah — 7 tabel sintetis plus 2 PDF nyata pada satu mesin CPU-only — bukan benchmark akurasi skala TEDS. Ada beberapa hal yang belum saya uji dan sebaiknya Anda uji sebelum mengandalkan Docling dalam pipeline: jalur VLM opsional (GraniteDocling), footprint docling-slim yang sebenarnya, run GPU apa pun, merged cells yang kompleks dan tidak teratur plus tabel multi-halaman, ketepatan formula ke LaTeX, dan — yang paling mungkin mengejutkan Anda di produksi — triad ketahanan dari pertumbuhan memori batch, skalabilitas thread/GIL, dan siklus hidup objek di ribuan konversi. Docling kuat pada apa yang memang ia klaim, terukur alih-alih sekadar dipasarkan, dan ada beberapa batas nyata yang sebaiknya Anda petakan sebelum mempercayakan korpus padanya. Pahami caveat sparse-page, siapkan anggaran untuk unduhan run pertama, dan verifikasi sendiri perilakunya pada skala besar.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah Docling itu web scraper atau crawler? Bukan. Docling mengonversi dokumen yang sudah Anda miliki — PDF, DOCX, PPTX, XLSX, HTML, gambar — menjadi Markdown atau JSON. Ia tidak mengambil URL, tidak merender JavaScript, dan tidak menangani anti-bot. Crawling web langsung adalah tugas terpisah yang ditangani oleh alat seperti Firecrawl atau API web Thunderbit; Docling memulai dari file yang Anda berikan.
Seberapa besar instalasi Docling dan unduhan run pertamanya?
Metapackage default docling menghasilkan venv sekitar 1,3 GB karena menarik seluruh stack ML (torch saja 536 MiB) sebagai dependensi wajib. Konversi PDF pertama mengunduh sekitar 506 MiB model layout dan TableFormer ke disk plus sekitar 40 MB bobot RapidOCR, dan memakan sekitar 224 detik — hampir semuanya waktu unduh. Konversi kedua sekitar 0,55 detik. Jika Anda hanya butuh format ringan, docling-slim (core sekitar 50 MB) menghindari jalur berat.
Apakah Docling melakukan OCR, dan memakai engine apa? Ya. Pada PDF scan tanpa layer teks, OCR Docling aktif otomatis dan berhasil memulihkan teks dengan bersih pada pengujian saya. Engine default-nya adalah RapidOCR, bukan EasyOCR — kekeliruan yang umum di tulisan lama. EasyOCR kini menjadi ekstra opsional. OCR adalah jalur lambat saat skala besar, terutama di CPU.
Mengapa Docling mengubah tabel saya menjadi gambar atau menghilangkannya?
Kemungkinan besar karena efek sparse-page. Model layout RT-DETR milik Docling memakai konteks halaman, dan tabel kecil yang berdiri sendiri di halaman yang hampir kosong bisa diklasifikasikan sebagai Picture lalu dibuang tanpa error. Tabel yang sama jika dikelilingi teks isi akan dikonversi dengan baik. Solusinya adalah memberi konteks halaman pada model layout, atau mengecek ulang doc.tables setelah konversi dan menandai halaman apa pun yang jumlahnya nol.
Docling vs Firecrawl — sebaiknya pakai yang mana? Tugasnya berbeda, jadi biasanya bukan pilihan salah satu saja. Firecrawl melakukan crawling web langsung, merender JavaScript, dan mengekstrak konten utama. Docling mengonversi dokumen yang sudah Anda pegang, dengan struktur tabel PDF dan OCR yang nyata, sepenuhnya offline. Jika sumber Anda adalah halaman web, pakai alat web (Firecrawl, atau API/MCP/CLI Thunderbit). Jika sumbernya PDF, scan, atau file Office, pakai Docling. Dalam banyak pipeline nyata, keduanya dipakai bersama.
