Docling sering disangka web scraper, padahal bukan. Ini adalah toolkit konversi dokumen dari IBM Research — sekarang menjadi proyek LF AI & Data Foundation — yang mengambil file yang sudah kamu punya (PDF, DOCX, PPTX, XLSX, HTML, gambar) lalu mengubahnya menjadi Markdown atau JSON. Slogannya memang secara harfiah: "Get your documents ready for gen AI."
Jadi ini ulasan langsung untuk sebuah konverter, bukan crawler. Semua pengujian di bawah dilakukan di satu mesin hanya-CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), dengan skor yang diambil dari skrip, dan kegagalan dicatat apa adanya sebagai kegagalan. Repositorinya sangat besar dan terus bergerak setiap hari — 63.069 bintang, 4.449 fork, dan ada push pada hari yang sama saat saya mengambil metadata — jadi anggap angka isu atau versi di sini sebagai cuplikan, bukan angka tetap.
Sebenarnya Apa Docling Itu (dan Bukan Apa)
Satuan utama di Docling adalah DoclingDocument: file di-parse ke struktur ini, lalu diekspor ke Markdown, HTML, DocTags, atau JSON lossless. Kodenya berlisensi MIT (lisensi model individual bisa berbeda), awalnya dikembangkan di IBM Research Zurich, dan saat tulisan ini dibuat rilis terbaru adalah v2.112.0, terbit dua hari sebelum saya menjalankan pengujian ini.
Kemampuan andalannya ada pada jalur PDF dan gambar. Jalur ini bukan sekadar membaca 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 tata letak halaman, urutan baca, dan struktur tabel. Itulah bagian yang memang layak diulas, dan bagian yang tak akan pernah kelihatan kalau kamu cuma mengetes HTML.
Ada satu perbedaan yang menyelamatkan kamu dari kebingungan seminggu penuh. Docling tidak mengambil apa pun dari web. Ia tidak merender JavaScript, tidak menembus anti-bot, dan tidak melakukan crawling. Kamu bawa filenya; Docling yang memahami isinya. Crawling adalah tugas alat lain, dan ini penting nanti saat orang bertanya apakah Docling menggantikan Firecrawl (tidak — keduanya saling melengkapi, dan saya akan jelaskan alasannya).
Run Pertama yang Tidak Diberi Peringatan
pip install docling berjalan mulus di Python 3.14.2. Lalu kamu melihat virtual environment-nya, dan ukurannya 1,3 GB. Docling menarik seluruh tumpukan ML sebagai dependensi wajib, bahkan kalau yang kamu konversi cuma 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) | 75.6 |
| docling_parse | 30 |
Itu pun sebelum kamu mengonversi satu PDF pun. Konversi PDF pertama adalah titik ketika friksi yang sesungguhnya muncul, karena saat itulah model diunduh. Pada cache HuggingFace yang baru dan terisolasi, konversi PDF pertama memakan waktu sekitar 224 detik — dan hampir semuanya habis untuk unduhan, bukan komputasi. Model layout plus TableFormer berukuran sekitar 506 MiB di disk (342 MiB TableFormer + 164 MiB layout, diverifikasi dengan du), dan RapidOCR mengunduh sekitar 40 MB bobot PP-OCRv4 ke site-packages. Konversi kedua untuk file yang sama? 0,55 detik. Modelnya sudah tersimpan; biaya itu cuma dibayar sekali.
Ada satu angka yang sebaiknya kamu 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 sekali di bawah blobs/ lalu menampilkannya lagi sebagai symlink snapshots/ — jadi walk tersebut menghitung 14 file model dua kali. Angka yang cocok dengan du dan sudah menghindari duplikasi symlink adalah sekitar 506 MiB (khusus blobs: 505,4 MiB). Pelajaran untuk siapa pun yang membandingkan Docling: laporkan byte unduhan dan byte di disk sebagai dua angka terpisah, karena memang berbeda.
Ada satu kerumitan lagi yang akan mengganggu siapa pun yang membangun container Docling. Bobotnya terbagi di dua lokasi dengan dua jadwal berbeda. Model layout dan TableFormer mengikuti HF_HOME dan diunduh saat konversi PDF pertama. Model RapidOCR tidak — mereka mendarat di …/site-packages/rapidocr/models/, melewati konfigurasi cache kamu sama sekali. Kalau kamu melakukan pre-bake atau air-gap untuk image, kamu harus menangani dua cache ini, dan sebanyak apa pun kamu mengatur HF_HOME, itu tidak akan menyentuh yang kedua.
Sekarang bagian yang adil. Sejak rilis-rilis awal Docling, proyek ini meluncurkan docling-slim — core sekitar 50 MB yang memungkinkan kamu pip install docling-slim[format-html] untuk HTML tanpa menyeret torch. Jadi bobot 1,3 GB itu memang nyata untuk metapackage default docling, tetapi sekarang sudah bisa dihindari. Saya menguji paket default karena itulah yang masih diberikan pip install docling, tetapi beban berat ini bukan cacat yang tidak diatasi — solusi modularnya sudah ada, dilacak di issue #2393.
Saat setup, saya menemukan satu detail kecil yang layak dicatat: import docling; docling.__version__ memunculkan AttributeError: module 'docling' has no attribute '__version__'. Modulnya memang tidak mengeksporkannya. Cara cek yang berhasil adalah importlib.metadata.version("docling"), yang menghasilkan '2.111.0'. Ini gangguan kecil untuk DX, dan sudah terbuka di upstream sejak Juli 2026 sebagai issue #3733.
Akurasi Tabel: Di Sini TableFormer Membuktikan Nilainya
Tabel adalah alasan utama orang memilih Docling dibanding sekadar dump PDF ke teks biasa, jadi saya membuat tujuh PDF tabel dengan ground truth yang bisa dibaca mesin dan menilai hasilnya sel per sel. Ada dua metrik penting, dan keduanya tidak sama: cell recall adalah proporsi nilai ground-truth yang muncul di mana pun dalam tabel terdeteksi; in-row rate adalah proporsi nilai yang jatuh ke baris yang benar. Mencampuradukkan keduanya akan membuat alat terlihat lebih bagus dari kenyataannya, jadi berikut keduanya:
| Tabel (uji stres) | Terdeteksi | Cell recall | In-row rate | Catatan |
|---|---|---|---|---|
| T1 grid sederhana berbingkai (5×8), sendiri di halaman | Tidak | 0.0 | — | diklasifikasikan sebagai <!-- image -->, semua sel hilang |
| T2 tanpa border (hanya garis header) | Ya | 1.00 | 1.00 | sempurna, grid tepat |
| T3 header colspan 2 level yang digabung | Ya | 1.00 | 0.97 | semua nilai ditemukan; satu nilai header bergeser satu baris |
| T4 label baris rowspan yang digabung, sendiri di halaman | Tidak | 0.0 | — | diklasifikasikan sebagai <!-- image --> |
| T5 header colspan + tanpa border | Ya | 1.00 | 0.97 | semua nilai ditemukan; pergeseran baris header sama seperti T3 |
| T6 laporan keuangan, kolom kosong, rata kanan | Ya | 1.00 | 1.00 | kolom kosong tetap 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 lewat — cell recall 1.00 untuk semuanya. Pada tiga dari lima, setiap nilai juga jatuh di baris yang benar. Pada dua kasus header bertingkat (T3 dan T5), satu nilai header meleset dari baris asalnya, sehingga in-row turun ke 0.97 — semua datanya ada, hanya penetapan barisnya yang goyah satu tingkat pada header bertumpuk.
Kasus struktur yang sulit ternyata bertahan lebih baik dari dugaan saya. Header colspan dua tingkat diratakan dengan benar ke GitHub-flavored Markdown (label "Q1 2026" diulang di atas dua kolom yang dicakupnya, dan itu memang cara yang benar untuk meratakan colspan ke GFM). Grid tanpa border yang hanya punya garis header (T2) tampil persis seperti aslinya. Tabel lebar 12 kolom (T7) tidak bergeser. Dan kolom finansial yang sepenuhnya kosong (T6) tetap dipertahankan sebagai sel kosong, bukan dibuang atau digabung. Ini sejalan dengan skor resmi TableFormer TEDS — 95,4 simple, 90,1 complex, 93,6 semua tabel — yang di model card nilainya jauh di atas Camelot (73,0) dan EDD (88,3).
Ada satu catatan penting soal merged cell, karena ada issue terbuka yang mengatakan kebalikannya. 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 sudah disebut tadi. Namun kasus gagal di #3698 adalah gabungan multi-baris/multi-kolom yang tidak teratur dan tabel lintas halaman — ujung patologisnya. Punya saya adalah ujung yang sederhana. Jadi pernyataan yang akurat harus sempit: colspan dan rowspan sederhana berhasil dipulihkan di sini (header bertingkat bisa bergeser satu baris); gabungan yang kompleks dan tidak teratur masih merupakan masalah terbuka yang terdokumentasi. Bukan "merged cell bekerja," bukan pula "merged cell 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 5×8 berbingkai yang sangat normal. Itu cukup mengkhawatirkan sampai saya yakin bukan sekadar kelemahan parsing tabel, jadi saya membuat uji A/B berbasis skrip.
Pertama, saya menyingkirkan penjelasan yang paling jelas. Lapisan teksnya utuh — pypdfium2 membaca 327 karakter dari T1 dan 221 dari T4, jadi ini benar-benar PDF digital, bukan hasil scan. Mematikan OCR (do_ocr=False) juga tidak membantu; tabel tetap hilang. Dan saat saya memeriksa DoclingDocument langsung, len(doc.tables) == 0 sementara len(doc.pictures) == 1 — model layout mengklasifikasikan seluruh area tabel sebagai Picture.
Lalu tes penentunya. Saya merender ulang T1 dan T4 yang sama persis, kali ini dikelilingi beberapa paragraf isi biasa, lalu mengonversinya lagi. Keduanya keluar sempurna: len(doc.tables) == 1, tabel GFM yang benar dihasilkan, dan label rowspan T4b "North" berulang dengan benar di tiga barisnya. Tabelnya sama. Satu-satunya variabel yang berubah hanyalah apakah ia berdiri sendiri di halaman yang kosong atau tertanam di dalam teks.
Jadi peringatan yang sebenarnya bukan bahwa TableFormer rapuh — melainkan bahwa model layout RT-DETR milik Docling memakai konteks halaman, dan tabel kecil yang berdiri sendiri di halaman yang nyaris kosong sangat mungkin dibaca sebagai Picture lalu dibuang diam-diam. Ini mudah terjadi di dunia nyata, karena memang begitu bentuk invoice, lembar spesifikasi, dan ekspor hasil potong: satu tabel per halaman, tanpa paragraf penjelas di sekitarnya. Solusinya sederhana dan efektif — beri model layout konteks halaman, atau periksa ulang doc.tables setelah konversi dan tandai halaman yang jumlahnya nol. Ini berdekatan dengan issue #3495 (tabel terdeteksi sekaligus sebagai Table dan Picture), tetapi pemicu berupa halaman yang terlalu kosong — tabel yang sama hilang saat sendirian, berhasil saat dikelilingi teks — saya tidak menemukan publikasinya sebelumnya. Terukur, belum pernah terdokumentasi; bukan bug yang tak seorang pun tahu.
OCR pada Scan Nyata: RapidOCR, Bukan EasyOCR
PDF hasil scan adalah tempat banyak konverter diam-diam gagal, jadi saya memberi Docling dua scan asli dengan lapisan teks 0 karakter yang terukur — pypdfium2 melaporkan nol karakter yang bisa dipulihkan, menegaskan bahwa output apa pun memang OCR, bukan lapisan teks tersembunyi di belakangnya.
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 secara verbatim. File empat halaman nemotron_multipage.pdf menjalankan OCR di keempat halaman dengan total 70,1 detik (17,5 dtk/halaman), dan menampilkan kalimat uji yang sama di setiap halaman. OCR default berjalan otomatis — tanpa flag, tanpa konfigurasi.
Detail yang sering salah ditulis banyak ulasan 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 teks FAQ Docling lama masih bilang default-nya EasyOCR; itu sudah usang. Kini EasyOCR adalah tambahan opsional yang harus kamu aktifkan sendiri. Catatan yang tetap benar: OCR adalah jalur lambat pada skala besar, dan semua angka di sini adalah batas atas di mesin CPU saja — 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 rumus.
Pada paper Attention 15 halaman, kelima penanda bagian — Abstract, Introduction, Background, Conclusion, References — muncul sesuai urutan dokumen di Markdown linear, meski tata letaknya dua kolom. Semua probe konten (Transformer, encoder, BLEU, multi-head) ada, dan tabel hasil multi-kolom yang terkenal terdeteksi sebagai empat tabel. Itu adalah pemulihan urutan baca dan penggabungan kolom yang nyata, yang menjadi nilai inti untuk chunking RAG — kamu tidak bisa melakukan chunking dengan benar kalau linearizer mengacak halaman dua kolom jadi campuran yang tidak masuk akal.
Soal waktu, pelajarannya justru agak berlawanan dengan intuisi. Waktu per halaman ditentukan oleh seberapa banyak struktur di tiap halaman, bukan oleh jumlah halaman. Laporan 9 halaman yang lebih padat berjalan di 14,95 detik per halaman — lebih lambat per halaman dibanding paper 15 halaman yang hanya 5,99 detik per halaman — karena ia memuat lebih banyak tabel dan gambar, dan masing-masing memicu inference layout dan TableFormer tambahan. Jadi "detik per halaman" di CPU bergantung pada kepadatan struktur, bukan panjang dokumen. Ini satu run di CPU saja; angkanya adalah ceiling, bukan angka produksi.
Multi-Format dan Klaim Lossless JSON
Docling mempromosikan parsing terpadu lintas format, jadi saya membuat DOCX, XLSX, dan PPTX dengan konten yang sudah diketahui serta probe ground-truth, lalu memeriksa dua hal: apakah probe muncul di Markdown, dan apakah semuanya bertahan di round-trip JSON lewat 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 masuk ke Markdown, tabel berhasil dipulihkan (termasuk baris "Total" yang digabung pada DOCX dan kedua sheet XLSX), dan setiap probe juga bertahan di JSON export_to_dict() — itulah bukti yang relevan untuk klaim DoclingDocument lossless, setidaknya pada input yang bersih. Format-format ini melewati backend yang sesuai format, bukan model ML, itulah sebabnya mereka berjalan dalam hitungan puluhan milidetik dan sepenuhnya offline. Cakupannya jujur: satu file bersih per format membuktikan keluasan, bukan uji stres file Office yang patologis.
HTML: Setia, Tapi Tidak Bersih
Ini adalah catatan yang menentukan apakah Docling cocok untuk pipeline RAG kamu, jadi baca baik-baik. Docling mengonversi seluruh dokumen HTML. Ia tidak melakukan ekstraksi konten utama ala readability. Saya mengukur berapa banyak chrome situs yang 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 sebenarnya 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 kamu Markdown dokumen penuh yang setia, bukan ekstraksi artikel utama yang bersih. Upstream melacak persoalan furniture HTML ini di issue #1865 (ditutup) dan #1930 (terbuka).
Ada dua hal yang membuat penilaian ini adil. Pertama, khusus HTML Docling tidak menjalankan model ML sama sekali — ia memakai backend BeautifulSoup di pipeline sederhana. Cerita "model penglihatan membaca halaman kamu" hanya berlaku untuk PDF dan gambar; kirim HTML ke Docling, dan mesin layout maupun TableFormer tidak akan aktif. Kedua, jalur PDF memang mencoba klasifikasi header dan footer sebagai furniture, jadi klaim "tidak ada penghapusan boilerplate sama sekali" akan terlalu keras — yang membawa chrome kembali justru backend HTML-nya.
Perbandingan dengan yang Lain (dan Posisi Thunderbit)
Coba Thunderbit untuk Ekstraksi Data Web
Alat utama yang sering dibandingkan dengan Docling adalah Firecrawl, jadi berikut tabel posisinya. Ada satu catatan di awal, karena ini penting: ini adalah perbandingan tingkat dokumentasi, bukan benchmark pada mesin yang sama. Saya tidak menjalankan Firecrawl pada fixture ini. Hanya kolom Docling yang diukur di sini; kolom Firecrawl berasal dari dokumentasi publiknya.
| Aspek | Firecrawl (menurut dokumentasinya) | Docling (diukur di sini) |
|---|---|---|
| Tugas inti | Crawl + scrape web live → Markdown | Konversi dokumen yang sudah kamu punya → Markdown/JSON |
| Fetching / render JS / anti-bot | Ya (browser hosted) | Tidak — kamu yang menyediakan file |
| Ekstraksi konten utama | Ya | Tidak — dokumen penuh 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 hasil scan / OCR | terbatas | Ya — RapidOCR secara default (berhasil memulihkan scan dengan 0 lapisan teks) |
| Cakupan format | halaman web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/gambar |
| Deployment | API hosted (+ 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 saat data kamu ada di web live dan butuh crawling, render JS, serta pembersihan konten utama. Docling adalah alat saat kamu sudah memegang dokumennya — terutama PDF, scan, dan file Office yang banyak tabel — dan ingin konversi yang setia, offline, mempertahankan struktur, dengan pemahaman tabel dan OCR yang nyata. Keduanya saling melengkapi. Pipeline yang realistis akan memakai satu untuk crawling dan satu lagi untuk konversi dokumen.
Di sini saya jujur soal Thunderbit, karena saya bekerja di sini dan kamu wajar curiga kalau saya pura-pura netral. Thunderbit dan Docling bukan alat yang sama, dan saya tidak akan memaksakan kesetaraannya. Untuk developer, Thunderbit adalah AI scraping API plus MCP server plus CLI, dan satuan kerjanya adalah halaman web live: POST /distill mengubah URL menjadi Markdown bersih yang siap untuk LLM (menangani render JS, anti-bot, dan CAPTCHA yang secara eksplisit tidak disentuh Docling), dan POST /extract mengembalikan JSON terstruktur yang cocok dengan skema melalui JSON Schema yang kamu definisikan. Itu adalah sisi fetch-and-clean dari pipeline RAG. Docling adalah sisi dokumen lokal — PDF, scan, spreadsheet yang sudah ada di disk kamu. Kalau korpusmu berupa halaman web, pakai API Thunderbit, tools MCP-nya (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract), atau CLI (npx @thunderbit/thunderbit-cli). Kalau isinya PDF dan scan, pakai Docling. Kalau keduanya — yang memang paling sering di pipeline nyata — pakailah berpasangan, dan tidak ada yang berusaha menjadi yang lain.
Putusan: Sementara, Dengan Pekerjaan Rumah yang Masih Ada
Saya tidak akan memberi skor tunggal 0–100, karena total berbobot di sini akan memasukkan penalti untuk hal-hal yang memang tidak pernah dijanjikan Docling (seperti crawling) lalu berpura-pura semuanya sebanding. Per dimensi, pada fixture yang saya uji:
- Setup / run pertama: berat — venv 1,3 GB, model ~506 MiB, PDF pertama ~224 dtk, warm ~0,55 dtk — tetapi
docling-slimmemberi opsi keluar dari beban tersebut. - Akurasi tabel: kuat saat 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 halaman kosong — tabel yang sendirian bisa hilang sebagai Picture. Periksa
doc.tablessetelah konversi. - Scan / OCR: bekerja, RapidOCR sebagai default; lambat pada skala besar.
- Multi-format: solid, dengan round-trip JSON tetap utuh.
- HTML: setia, bukan bersih — tidak ada ekstraksi konten utama.
- Developer experience: API 3 baris yang rapi dan
DoclingDocumentyang bersih, minus__version__yang hilang.
Cocok untuk siapa: tim yang membangun RAG atau pipeline data di atas PDF, scan, dan file Office yang ingin konversi offline, mempertahankan struktur, serta pemahaman tabel dan OCR yang nyata. Tidak cocok untuk siapa: siapa pun yang butuh crawling web live atau ekstraksi HTML artikel utama yang bersih — itu pekerjaan alat yang berbeda.
Dan karena ini ulasan, bukan siaran pers, batasannya tetap ditulis jelas. Ini adalah probe terarah — 7 tabel sintetis plus 2 PDF nyata di satu mesin CPU-only — bukan benchmark akurasi skala TEDS. Ada beberapa hal yang tidak saya uji dan sebaiknya kamu uji sebelum mempertaruhkan pipeline pada Docling: jalur VLM opsional (GraniteDocling), footprint docling-slim yang sebenarnya, run GPU apa pun, merged cell kompleks dan tidak teratur plus tabel lintas halaman, fidelitas formula ke LaTeX, dan — yang paling mungkin mengejutkan kamu di produksi — triad ketahanan berupa pertumbuhan memori batch, skalabilitas thread/GIL, dan lifecycle objek di ribuan konversi. Docling kuat pada apa yang diklaimnya, diukur bukan dipasarkan, dan ia punya sisi-sisi tajam yang sebaiknya dipetakan sebelum kamu mempercayakan korpus kepadanya. Ketahui catatan tentang sparse-page, siapkan anggaran untuk unduhan run pertama, dan verifikasi sendiri perilaku pada skala besar.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah Docling itu web scraper atau crawler? Tidak. Docling mengonversi dokumen yang sudah kamu 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 live adalah tugas terpisah yang dikerjakan alat seperti Firecrawl atau API web Thunderbit; Docling mulai dari file yang kamu berikan.
Seberapa besar instalasi Docling dan unduhan saat pertama kali dijalankan?
Metapackage default docling menghasilkan venv sekitar 1,3 GB karena menarik seluruh tumpukan 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 waktu sekitar 224 detik — hampir semuanya waktu unduh. Konversi kedua sekitar 0,55 detik. Kalau kamu hanya butuh format ringan, docling-slim (core ~50 MB) melewatkan jalur berat itu.
Apakah Docling melakukan OCR, dan memakai engine apa? Ya. Pada PDF hasil scan tanpa lapisan teks, OCR Docling berjalan otomatis dan berhasil memulihkan teks dengan bersih dalam pengujian saya. Engine default-nya adalah RapidOCR, bukan EasyOCR — kesalahan umum dalam tulisan-tulisan lama. EasyOCR sekarang menjadi tambahan opsional. OCR adalah jalur lambat pada skala besar, terutama di CPU.
Mengapa tabel saya berubah jadi gambar atau hilang di Docling?
Kemungkinan besar karena efek halaman yang terlalu kosong. Model layout RT-DETR 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 akan terkoversi dengan baik. Solusinya adalah memberi konteks halaman pada model layout, atau memeriksa ulang doc.tables setelah konversi dan menandai halaman yang jumlahnya nol.
Docling vs Firecrawl — mana yang sebaiknya saya pakai? Tugasnya berbeda, jadi biasanya bukan pilihan salah satu. Firecrawl melakukan crawl web live, merender JavaScript, dan mengekstrak konten utama. Docling mengonversi dokumen yang sudah kamu miliki, dengan struktur tabel PDF dan OCR yang nyata, sepenuhnya offline. Jika sumbermu adalah halaman web, gunakan alat web (Firecrawl, atau API/MCP/CLI Thunderbit). Jika isinya PDF, scan, atau file Office, gunakan Docling. Sebagian besar pipeline nyata memakai keduanya.
