Docling sürekli web scraper’larla aynı kategoriye konuyor, ama aslında öyle değil. Bu araç, IBM Research kökenli — şimdi LF AI & Data Foundation çatısı altındaki bir proje — bir belge dönüştürme araç seti. Elinizde zaten موجود olan dosyaları (PDF, DOCX, PPTX, XLSX, HTML, görseller) alıp bunları Markdown ya da JSON formatına çeviriyor. Kendi sloganı bile doğrudan şu: "Get your documents ready for gen AI."
Yani bu yazı bir tarayıcıyı değil, bir dönüştürücüyü uygulamalı olarak inceliyor. Aşağıdaki tüm sonuçlar tek bir CPU-only makinede ölçüldü (macOS arm64, Python 3.14.2, Docling 2.111.0); skorlar script’lerden alındı ve başarısızlıklar başarısızlık olarak kaydedildi. Repo devasa ve her gün değişiyor — 63,069 yıldız, 4,449 fork ve metadata’yı çektiğim günle aynı gün yapılmış bir push — bu yüzden burada gördüğünüz sürüm veya hata sayısını sabit bir değer değil, anlık bir görüntü olarak değerlendirin.
Docling Gerçekte Nedir, Nedir Değildir?
Docling’de her şeyin temel birimi DoclingDocument’tir: bir dosyayı önce bu yapıya ayrıştırırsınız, ardından Markdown, HTML, DocTags ya da kayıpsız JSON olarak dışa aktarırsınız. Kod MIT lisanslıdır (tek tek model lisansları değişebilir), kökeni IBM Research Zurich’e dayanır ve bu yazı yazılırken en güncel sürüm, ben bu testi çalıştırmadan iki gün önce yayımlanan v2.112.0’dır.
Öne çıkan yetenek PDF ve görsel işleme yoludur. Bu yol basit bir string ayrıştırma değildir; RT-DETR düzen modeli, TableFormer tablo yapısı modeli, isteğe bağlı bir vision-language modeli ve taramalar için RapidOCR’den oluşan bir makine öğrenmesi yığınıdır. Bu modeller sayfa düzenini, okuma sırasını ve tablo yapısını geri kazanır. İncelemeye değer olan kısım da tam olarak burasıdır; yalnızca HTML üzerinde yapılan bir test bunu hiç gösteremez.
Bir ayrım, bir haftalık kafa karışıklığını engeller. Docling hiçbir şey çekmez. JavaScript render etmez, anti-bot engellerini aşmaz, crawl yapmaz. Dosyayı siz getirirsiniz; anlamlandırmayı o yapar. Tarama başka bir aracın işidir; bu nokta ileride insanların Docling’in Firecrawl’ın yerini alıp almadığını sorduğunda önem kazanacak (almıyor — birbirini tamamlıyorlar; nedenini birazdan anlatacağım).
İlk Çalıştırmada Sizi Kimse Uyarmıyor
pip install docling Python 3.14.2 üzerinde sorunsuz tamamlanıyor. Sonra sanal ortamınıza bakıyorsunuz ve boyut 1.3 GB. Docling, siz yalnızca HTML dönüştürüyor olsanız bile tüm ML yığınını zorunlu bağımlılık olarak çekiyor:
| Bağımlılık | Diskteki boyut (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ paket içi modeller) | 75.6 |
| docling_parse | 30 |
Bu, tek bir PDF bile dönüştürmeden önceki durum. Asıl sürtünme ilk PDF dönüştürmede başlıyor; çünkü modellerin indirilmesi o zaman gerçekleşiyor. Sıfırdan oluşturulmuş, izole bir HuggingFace önbelleğinde ilk PDF dönüştürme yaklaşık 224 saniye sürdü — ve bunun neredeyse tamamı hesaplama değil, indirme süreciydi. Düzen + TableFormer modelleri diskte toplam yaklaşık 506 MiB yer kaplıyor (342 MiB TableFormer + 164 MiB layout, du ile doğrulandı) ve RapidOCR yaklaşık 40 MB PP-OCRv4 ağırlığını site-packages içine indiriyor. Aynı dosyanın ikinci dönüştürmesi? 0.55 saniye. Modeller önbelleğe alınıyor; bedeli bir kez ödüyorsunuz.
Göz ardı etmeniz gereken bir sayı var: coldstart script’i model_download_mb olarak 1060.2 yazdırıyor. Bunu footprint olarak alıntılamayın. Sebebi, os.walk’un sembolik bağlantıları da takip etmesi; HuggingFace önbelleği her model dosyasını bir kez blobs/ altında saklıyor ve sonra snapshots/ üzerinden sembolik bağlantıyla yeniden gösteriyor — dolayısıyla yürüyüş 14 model dosyasını iki kez sayıyor. du ile uyumlu, symlink’ler çıkarılmış gerçek değer yaklaşık 506 MiB’dir (yalnızca blobs: 505.4 MiB). Docling’i benchmark eden herkes için çıkarım şu: indirme baytlarını ve diskteki baytları ayrı ayrı rapor edin, çünkü bunlar aynı şey değil.
Docling ile konteyner hazırlayanları vuran ikinci bir ayrıntı daha var. Ağırlıklar iki farklı yerde ve iki farklı zamanlamayla indiriliyor. Layout ve TableFormer modelleri HF_HOME ayarını dikkate alıyor ve ilk PDF dönüştürmede indiriliyor. RapidOCR’nin modelleri ise buna uymuyor — doğrudan …/site-packages/rapidocr/models/ içine gidiyor ve önbellek ayarlarınızı tamamen bypass ediyor. Bir imajı önceden hazırlıyor ya da air-gap ortamda çalıştırıyorsanız, iki önbelleği de ayrıca yönetmeniz gerekir; HF_HOME ayarlamak ikinci kısmı yakalamaz.
Ama hakkını verelim. Docling’in önceki sürümlerinden farklı olarak proje artık docling-slim sürümünü de sunuyor — torch’u çekmeden HTML için pip install docling-slim[format-html] yapmanızı sağlayan, yaklaşık 50 MB’lık çekirdek paket. Yani varsayılan docling meta paketi için 1.3 GB’lık ağırlık gerçektir; fakat artık bundan kaçınmak mümkün. Varsayılan paketi test ettim çünkü pip install docling hâlâ bunu getiriyor; ancak bu şişkinlik çözülmemiş bir kusur değil — modüler çözüm mevcut ve #2393 numaralı issue altında takip ediliyor.
Kurulum sırasında küçük ama sinir bozucu bir ayrıntıya da takıldım: import docling; docling.__version__ çalıştırınca AttributeError: module 'docling' has no attribute '__version__' hatası alıyorsunuz. Yani modül sürüm bilgisini doğrudan expose etmiyor. Çalışan yöntem importlib.metadata.version("docling"); bu da '2.111.0' döndürüyor. Küçük bir DX rahatsızlığı, Temmuz 2026’dan beri upstream’de issue #3733 olarak açık.
Tablo Doğruluğu: TableFormer’ın Parladığı Yer
İnsanların düz bir PDF-to-text dökümüne karşı Docling’i tercih etmesinin asıl nedeni tablolar; bu yüzden makine tarafından okunabilir ground truth içeren yedi tablo PDF’i ürettim ve çıktıyı hücre hücre puanladım. İki metrik önemli ve bunlar aynı şey değil: cell recall, ground truth değerlerinin tespit edilen tablonun herhangi bir yerinde bulunma oranıdır; in-row rate ise bunların doğru satıra yerleşme oranıdır. Bu ikisini karıştırmak aracı olduğundan iyi gösterir; bu yüzden ikisini de veriyorum:
| Tablo (zorlayıcı durum) | Tespit edildi | Cell recall | In-row rate | Not |
|---|---|---|---|---|
| T1 basit çerçeveli ızgara (5×8), sayfada tek başına | Hayır | 0.0 | — | <!-- image --> olarak sınıflandırıldı, tüm hücreler düştü |
| T2 çerçevesiz (yalnızca header çizgisi) | Evet | 1.00 | 1.00 | kusursuz, birebir ızgara |
| T3 birleştirilmiş 2 seviyeli colspan başlığı | Evet | 1.00 | 0.97 | tüm değerler bulundu; bir başlık değeri bir satır kaydı |
| T4 birleştirilmiş rowspan satır etiketi, sayfada tek başına | Hayır | 0.0 | — | <!-- image --> olarak sınıflandırıldı |
| T5 colspan başlığı + çerçevesiz yapı | Evet | 1.00 | 0.97 | tüm değerler bulundu; T3’tekiyle aynı başlık-satır kayması |
| T6 finansal tablo, boş sütun, sağa hizalı | Evet | 1.00 | 1.00 | boş sütun korundu, kaymadı |
| T7 geniş 12 sütunlu ızgara | Evet | 1.00 | 1.00 | geniş tabloda sütun kayması yok |
Docling’in tespit ettiği beş tabloda ground truth’taki tüm değerler geldi — cell recall her yerde 1.00. Bu beş tablonun üçünde tüm değerler doğru satıra da yerleşti. Çok seviyeli başlık içeren iki durumda (T3 ve T5) ise bir başlık değeri orijinal satırından kaydı ve in-row oranı 0.97’ye düştü — yani veri tamamen mevcut, yalnızca katmanlı başlıklarda satır ataması biraz sarsılıyor.
Zor yapısal vakalar beklediğimden daha iyi dayandı. İki seviyeli colspan başlığı GitHub-flavored Markdown’a doğru biçimde düzleştirildi ("Q1 2026" etiketi, kapsadığı iki sütunun üzerinde tekrarlandı; colspan’i GFM’ye çevirmenin doğru yolu da budur). Sadece başlık çizgisi olan çerçevesiz ızgara (T2) aynen korundu. Geniş 12 sütunlu tablo (T7) kaymadı. Ve tamamen boş bir finansal sütun (T6), atılmak ya da birleştirilmek yerine boş hücreler olarak korundu. Bu, resmî TableFormer TEDS skorlarıyla uyumlu: 95.4 basit, 90.1 karmaşık, 93.6 tüm tablolar — model kartı, Camelot (73.0) ve EDD (88.3) ile karşılaştırıldığında oldukça iyi bir performans gösteriyor.
Birleştirilmiş hücreler konusunda temkinli olun; çünkü bunun tersini söyleyen açık bir issue var. #3698 numaralı issue, V1 ve V2’nin birleştirilmiş satır ve sütunları doğru işlemekte zorlandığını bildiriyor. Benim testlerimde basit colspan (T3/T5) ve rowspan değerleri doğru şekilde düzleştirildi; yalnızca yukarıda bahsettiğim çok seviyeli başlık satır kayması görüldü. Ancak #3698’deki başarısızlıklar düzensiz çok satırlı/çok sütunlu birleştirmeler ve çok sayfalı tablolar gibi patolojik uç örnekler. Benimkiler ise basit tarafta kalıyor. Dolayısıyla doğru ifade dar kapsamlıdır: basit colspan ve rowspan burada kurtarıldı (çok seviyeli başlıklarda bir satır kayma olabilir); karmaşık ve düzensiz birleştirmeler ise hâlâ belgelenmiş açık bir sorun. Ne “birleştirilmiş hücreler çalışıyor” ne de “birleştirilmiş hücreler bozuk.”
Tuzak: Sayfada Tek Başına Duran Tablo Kaybolabilir
Tabloya tekrar bakın — T1 ve T4 hiç tespit edilmedi. Docling <!-- image --> üretti ve hiçbir hata vermeden tüm hücreleri düşürdü. T1, gayet sıradan çerçeveli 5×8 bir ızgara. Bunun tablo ayrıştırma zayıflığı olduğunu söylemeden önce neyin bunu tetiklediğini ayırmak istedim, bu yüzden script ile bir A/B testi kurdum.
Önce bariz açıklamaları eledim. Metin katmanı sağlam — pypdfium2, T1’den 327 karakter ve T4’ten 221 karakter okuyor; yani bunlar taranmış görüntü değil, gerçek dijital PDF’ler. OCR’yi kapatmak (do_ocr=False) işe yaramıyor; tablolar yine düşüyor. DoclingDocument’ı doğrudan inceleyince len(doc.tables) == 0 ve len(doc.pictures) == 1 çıkıyor — yani layout modeli tüm tablo bölgesini bir Picture olarak sınıflandırmış.
Sonra belirleyici test geldi. Aynı T1 ve T4 tablolarını bu kez birkaç sıradan paragrafla çevreleyip yeniden dönüştürdüm. İkisi de kusursuz geldi: len(doc.tables) == 1, doğru GFM tabloları üretildi ve T4b’nin "North" satır etiketi üç satır boyunca doğru şekilde tekrarlandı. Aynı tablo. Değişen tek şey, tablonun boş bir sayfada tek başına durup durmadığıydı.
O hâlde asıl uyarı TableFormer’ın kırılgan olması değil; Docling’in RT-DETR layout modelinin sayfa bağlamını kullanması ve küçük bir tablonun neredeyse bomboş bir sayfada tek başına kalınca Picture olarak okunup sessizce atılabilmesi. Bu pratikte çok kolay yaşanır; çünkü fatura, teknik föy ve kırpılmış çıktıların tam olarak görünümü budur: sayfa başına bir tablo, etrafta metin yok. Çözüm basit ve etkili — layout modeline sayfa bağlamı verin ya da dönüştürmeden sonra doc.tables değerini kontrol edip tablo sayısı sıfır olan sayfaları işaretleyin. Bu durum #3495 numaralı issue ile yakından ilişkili (aynı tablonun hem Table hem Picture olarak algılanması) ama sayfa seyrekliği tetikleyicisini — aynı tablo, tek başına kalınca düşüyor, metin içinde kalınca dönüştürülüyor — yayımlanmış halde bulamadım. Ölçülmüş, daha önce belgelenmemiş; kimsenin bilmediği bir bug değil.
Gerçek Taramalarda OCR: EasyOCR Değil, RapidOCR
Taranmış PDF’ler, birçok dönüştürücünün sessizce tökezlediği alanlardır; bu yüzden Docling’e ölçülmüş 0 karakterlik metin katmanı olan iki gerçek tarama verdim — pypdfium2, kurtarılabilir karakter sayısını sıfır olarak raporluyor; yani çıkan sonuçların hepsi OCR, gizli bir metin katmanının yan ürünleri değil.
Tek sayfalık ocr_test.pdf, CPU üzerinde 14.3 saniyede temiz şekilde geri geldi: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," ifadesi birebir kurtarıldı. Dört sayfalık nemotron_multipage.pdf ise dört sayfanın hepsinde OCR çalıştırdı; toplam süre 70.1 saniye oldu (17.5 sn/sayfa) ve test cümlesini her sayfada tekrar etti. Varsayılan OCR otomatik olarak devreye girdi — ek bayrak gerekmedi, ayar gerekmedi.
İncelemelerin çoğunun yanlış anlattığı kritik ayrıntı şu: varsayılan OCR motoru EasyOCR değil, RapidOCR. Bunu ilk çalıştırmada indirilen PP-OCRv4 .pth ağırlıklarını izleyerek doğruladım. Mevcut blogların ve eski Docling SSS metinlerinin çoğu hâlâ varsayılanın EasyOCR olduğunu söylüyor; bu bilgi güncel değil. EasyOCR artık yalnızca opsiyonel bir eklenti. Ancak değişmeyen uyarı şu: OCR büyük ölçekte yavaştır ve burada gördüğünüz tüm süreler CPU-only bir tavan değer; GPU bunu ciddi biçimde düşürür.
Gerçek PDF’ler, Okuma Sırası ve Sayfa Başı Süre
Sentetik testler belirli davranışları kanıtlar; gerçek PDF’ler ise aracın gerçekten işe yaradığını gösterir. İki dijital doğumlu akademik makale çalıştırdım — 9 sayfalık Docling teknik raporu ve 15 sayfalık "Attention Is All You Need"; ikisi de iki sütunlu, tablolar ve formüller içeriyor.
15 sayfalık Attention makalesinde beş bölüm işaretinin tamamı — Abstract, Introduction, Background, Conclusion, References — iki sütunlu düzende bile düzleştirilmiş Markdown içinde belge sırasıyla görünüyor. Her içerik ipucu (Transformer, encoder, BLEU, multi-head) mevcut ve meşhur çok sütunlu sonuç tabloları dört tespit edilmiş tablo olarak kayda geçiyor. Bu, gerçek okuma sırası ve sütun birleştirme geri kazanımıdır; RAG parçalama için temel değer de budur — iki sütunlu bir sayfayı iç içe geçmiş anlamsızlığa çeviren bir linearizer ile belgeyi mantıklı şekilde parçalayamazsınız.
Zamanlama beklenmedik bir ders veriyor. Sayfa başı süreyi belge uzunluğu değil, her sayfadaki yapısal yoğunluk belirliyor. Daha yoğun olan 9 sayfalık rapor, sayfa başına 14.95 saniye ile 15 sayfalık makaleden (sayfa başına 5.99 saniye) daha yavaş çıktı; çünkü içinde daha fazla tablo ve şekil var ve bunların her biri ekstra layout ve TableFormer çıkarımı tetikliyor. Yani CPU üzerinde “sayfa başına saniye”, uzunluktan çok yapısal yoğunluğun bir fonksiyonudur. Bu tek bir CPU-only çalıştırmadır; üretim değeri değil, üst sınırdır.
Çoklu Format ve Kayıpsız JSON İddiası
Docling birleşik çoklu format ayrıştırma sunduğunu söylüyor; bu yüzden bilinen içerik ve ground truth ipuçları içeren bir DOCX, bir XLSX ve bir PPTX ürettim, ardından iki şeyi kontrol ettim: ipuçları Markdown’da görünüyor mu ve export_to_dict() üzerinden JSON round-trip sırasında korunuyor mu?
| Dosya | Dönüştürme sn | MD’de bulunan ipuçları | MD’deki tablo sayısı | İpuçları JSON’da korunuyor mu |
|---|---|---|---|---|
report.docx (başlıklar + birleştirilmiş "Total" tablosu + madde işaretleri) | 0.137 | 7/7 | 1 | Evet |
workbook.xlsx (2 sayfa, boş sütun) | 0.016 | 6/6 | 2 | Evet |
deck.pptx (3 slayt, madde işaretleri + tablo) | 0.038 | 6/6 | 1 | Evet |
Tüm içerik ipuçları Markdown’a ulaştı, tablolar geri kazanıldı (DOCX’teki birleştirilmiş "Total" satırı ve XLSX’in iki sayfası dahil) ve her ipucu export_to_dict() JSON’unda da korundu — temiz girdiler üzerinde en azından kayıpsız DoclingDocument iddiası için önemli kanıt bu. Bu formatlar ML modelleri yerine formatın kendi arka plan mekanizmaları üzerinden işleniyor; bu yüzden onlarca milisaniyede tamamlanıyor ve tamamen çevrimdışı çalışıyor. Kapsam dürüst: format başına bir temiz dosya genişliği gösterir, patolojik Office dosyalarında stres testi yaptığını değil.
HTML: Sadık, Ama Temiz Değil
Bu, Docling’in RAG pipeline’ınıza girip girmeyeceğine karar veren nokta; dikkatle okuyun. Docling tüm HTML belgesini dönüştürür. Readability tarzı bir ana içerik çıkarımı yapmaz. Site çerçevesinden ne kadar şeyin korunduğunu, Docling’in kendi çıktısında nav, TOC, cookie ve footer işaret satırlarını sayarak ölçtüm.
| Sayfa | Boş olmayan MD satırı | Boilerplate satırı | % boilerplate | Makale şu satırda başlıyor |
|---|---|---|---|---|
| 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 gibi çok fazla arayüz öğesi olan bir sayfada Markdown satırlarının yaklaşık %13’ü nav/TOC/footer boilerplate’idir ve gerçek makale 28. satırdan sonra başlar — çıktı “move to sidebar / Contents / Toggle the table of contents” ile açılır ve “CS1 maint… / Search Wikipedia” ile kapanır. Temiz içerik sayfalarında (books, quotes) bu oran yaklaşık %0’dır; yani bu bir sayfa başı vergi değil, şablon çerçevesi problemidir. Docling size temiz ana makale çıkarımı değil, sadık ama tam belge Markdown’ı verir. Upstream, HTML’deki bu “mobilya” sorununu issue #1865 (kapalı) ve #1930 (açık) altında takip ediyor.
Bunu adil tutan iki nokta var. İlki, HTML tarafında Docling hiçbir ML modeli çalıştırmaz — basit bir pipeline üzerinde BeautifulSoup backend’i kullanır. Sayfanızı "görsel modeller okuyor" hikâyesi yalnızca PDF ve görseller için geçerlidir; Docling’e HTML verdiğinizde layout ve TableFormer mekanizmalarının hiçbiri devreye girmez. İkincisi, PDF yolunda header ve footer furniture sınıflandırması yapılır; bu yüzden “hiç boilerplate temizleme yok” demek fazla iddialı olur — şablon çerçevesini geri veren spesifik olarak HTML backend’idir.
Diğer Araçlarla Karşılaştırma ve Thunderbit’in Konumu
Web Veri Çekimi için Thunderbit’i Deneyin
İnsanların Docling’i karşılaştırdığı temel araç Firecrawl’dır; bu yüzden burada bir konumlandırma tablosu veriyorum. Başta küçük bir not önemli: bu, dokümantasyon seviyesinde bir karşılaştırmadır; aynı makinede yapılmış bir benchmark değildir. Firecrawl’ı bu test dosyalarında çalıştırmadım. Burada yalnızca Docling sütunu ölçülüdür; Firecrawl sütunu ise kendi kamuya açık dokümantasyonundan alınmıştır.
| Boyut | Firecrawl (dokümanlarına göre) | Docling (burada ölçülen) |
|---|---|---|
| Temel iş | Canlı web’i crawl + scrape edip Markdown’a dönüştürür | Zaten elinizde olan belgeyi Markdown/JSON’a dönüştürür |
| Fetch / JS render / anti-bot | Evet (barındırılan tarayıcı) | Hayır — dosyayı siz sağlarsınız |
| Ana içerik çıkarımı | Evet | Hayır — tam belgeyi sadık biçimde verir (Wikipedia’da ~%13 çerçeve) |
| PDF tablo yapısı (ML) | sınırlı | Evet — TableFormer (resmî TEDS 93.6; tespit edilen örneklerde cell recall 1.00, in-row 0.97–1.00) |
| Taranmış PDF / OCR | sınırlı | Evet — varsayılan RapidOCR (0 metin katmanlı taramayı kurtardı) |
| Format kapsamı | web sayfaları | PDF/DOCX/PPTX/XLSX/HTML/EPUB/görseller |
| Dağıtım | barındırılan API (+ self-host) | yerel pip kütüphanesi, çevrimdışı, API anahtarı yok |
| Kurulum ağırlığı | API anahtarı / hafif istemci | varsayılan kurulumda 1.3 GB + ~506 MiB modeller (veya docling-slim) |
| Lisans | ticari / source-available | MIT |
Tek cümlelik özet şu: Veriniz canlı web üzerindeyse ve crawling, JS render ve ana içerik temizliği gerekiyorsa Firecrawl doğru araçtır. Elinizde belge zaten varsa — özellikle PDF, tarama ve tablo ağırlıklı Office dosyaları — Docling doğru araçtır; çevrimdışı, yapıyı koruyan ve gerçek tablo ile OCR anlayışına sahip bir dönüşüm sunar. Birbirini tamamlarlar. Gerçekçi bir pipeline’da biriyle crawl edilir, diğeriyle belgeler dönüştürülür.
Burada kendi ürünümüz olan Thunderbit için de net olayım; çünkü burada çalışıyorum ve aksi halde sizi yanıltmaya çalışıyormuşum gibi görünmesi haklı bir şüphe olur. Thunderbit ve Docling aynı işi yapmıyor; bunu zorla eşitlemeyeceğim. Geliştiriciler için Thunderbit, bir AI scraping API’si + MCP server + CLI’dir ve çalışma birimi canlı web sayfasıdır: POST /distill bir URL’yi temiz, LLM’ye hazır Markdown’a çevirir (Docling’in açıkça dokunmadığı JS render, anti-bot ve CAPTCHA süreçlerini ele alır); POST /extract ise tanımladığınız JSON Schema üzerinden şemaya uyan yapılandırılmış JSON döndürür. Bu, bir RAG pipeline’ının fetch-and-clean kısmıdır. Docling ise yerel belge tarafıdır — PDF, tarama, diskinizde zaten duran elektronik tablo. Kaynağınız web sayfalarıysa Thunderbit’in API’sini, MCP araçlarını (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ya da CLI’ını (npx @thunderbit/thunderbit-cli) kullanın. PDF ve taramalar varsa Docling’i kullanın. İkisi de varsa — ki gerçek pipeline’ların çoğu böyledir — birlikte kullanın; hiçbirinin diğerinin yerine geçmeye çalıştığı yok.
Son Hüküm: Geçici, Üzerinde Çalışılacak Noktalarla Birlikte
Size tek bir 0–100 puan vermeyeceğim; çünkü burada ağırlıklı toplam yapmak, Docling’in hiç iddia etmediği şeyler için (örneğin crawling) ceza yazıp bunları karşılaştırılabilir sanmak olur. Test ettiğim örnekler bazında, boyutlara göre değerlendirme şöyle:
- Kurulum / ilk çalıştırma: ağır — 1.3 GB venv, ~506 MiB modeller, ilk PDF’de ~224 sn, sıcak çalıştırmada ~0.55 sn — ama
docling-slimbu ağırlığı seçmeli hale getiriyor. - Tablo doğruluğu: tablo tespit edilirse güçlü (5/5’te cell recall 1.00, in-row 0.97–1.00), bu örneklerde resmî TEDS anlatısıyla uyumlu.
- Tablo tespiti sağlamlığı: seyrek sayfa tuzağı — izole bir tablo Picture olarak düşebilir.
doc.tableskontrol edin. - Taranmış belge / OCR: çalışıyor; varsayılan RapidOCR, fakat büyük ölçekte yavaş.
- Çoklu format: sağlam, JSON round-trip bozulmuyor.
- HTML: sadık, ama temiz değil — ana içerik çıkarımı yok.
- Geliştirici deneyimi: missing
__version__dışında temiz, 3 satırlık API ve düzenli birDoclingDocument.
Kimin için: PDF, tarama ve Office dosyaları üzerinde RAG ya da veri pipeline’ı kuran ve çevrimdışı, yapıyı koruyan dönüştürme ile gerçek tablo + OCR anlayışı isteyen ekipler. Kimin için değil: canlı web crawling ya da temiz ana makale HTML çıkarımı isteyenler — bunun için başka araç gerekir.
Ve bu bir inceleme olduğu için, lansman metni gibi davranmayacağım; sınırlamalar da açık kalacak. Bu, TEDS ölçeğinde bir doğruluk benchmark’ı değil; tek bir CPU-only makinede yapılan, 7 sentetik tablo + 2 gerçek PDF içeren hedefli bir probe. Test etmediğim ve bir pipeline’ı Docling’e emanet etmeden önce sizlerin de test etmesi gereken birkaç konu var: isteğe bağlı VLM (GraniteDocling) yolu, gerçek docling-slim footprint’i, herhangi bir GPU koşumu, karmaşık ve düzensiz birleştirilmiş hücreler ile çok sayfalı tablolar, formülün LaTeX’e birebir dönüşüm doğruluğu ve — üretimde sizi en çok şaşırtabilecek olan — toplu kullanımda bellek büyümesi, thread/GIL ölçeklenmesi ve binlerce dönüşüm boyunca nesne yaşam döngüsü dayanıklılığı. Docling, iddia ettiği şeylerde güçlü; pazarlama değil ölçüm konuşuyor; ama güvenmeden önce haritalamanız gereken gerçek sınırları da var. Seyrek sayfa uyarısını bilin, ilk çalıştırma indirmesi için bütçe ayırın ve büyük ölçekteki davranışı kendiniz doğrulayın.
Web Veri Çekimi için Thunderbit’i Deneyin Get Started Free
SSS
Docling bir web scraper ya da crawler mı? Hayır. Docling, zaten elinizde olan belgeleri — PDF, DOCX, PPTX, XLSX, HTML, görseller — Markdown ya da JSON’a çevirir. URL çekmez, JavaScript render etmez, anti-bot mekanizmalarını işlemez. Canlı web’i crawl etmek Firecrawl veya Thunderbit’in web API’si gibi araçların işidir; Docling sizin verdiğiniz dosyadan başlar.
Docling kurulumu ve ilk indirme ne kadar büyük?
Varsayılan docling meta paketi, tam ML yığınını zorunlu bağımlılık olarak çektiği için yaklaşık 1.3 GB’lık bir venv oluşturur (yalnızca torch 536 MiB). İlk PDF dönüştürme, diske yaklaşık 506 MiB layout ve TableFormer modeli ile yaklaşık 40 MB RapidOCR ağırlığı indirir ve yaklaşık 224 saniye sürer — bunun neredeyse tamamı indirme süresidir. İkinci dönüştürme yaklaşık 0.55 saniyedir. Yalnızca hafif formatlara ihtiyacınız varsa, docling-slim (yaklaşık 50 MB çekirdek) ağır yolu atlar.
Docling OCR yapıyor mu, hangi motoru kullanıyor? Evet. Metin katmanı olmayan taranmış bir PDF’de OCR otomatik olarak devreye girer ve benim testimde metni temiz biçimde kurtardı. Varsayılan motor EasyOCR değil, RapidOCR’dir — eski yazılarda sık yapılan bir hata budur. EasyOCR artık isteğe bağlı bir eklentidir. OCR, özellikle CPU üzerinde, büyük ölçekte yavaş kalır.
Docling neden tablomı resme dönüştürdü ya da tamamen düşürdü?
Büyük olasılıkla seyrek sayfa etkisi. Docling’in RT-DETR layout modeli sayfa bağlamını kullanır ve neredeyse boş bir sayfada tek başına duran küçük bir tablo Picture olarak sınıflandırılıp hata vermeden düşebilir. Aynı tabloyu gövde metniyle çevrelediğinizde sorunsuz dönüştürülür. Çözüm, layout modeline sayfa bağlamı vermek ya da dönüştürmeden sonra doc.tables değerini kontrol edip tablo sayısı sıfır olan sayfaları işaretlemektir.
Docling mi Firecrawl mı — hangisini kullanmalıyım? Farklı işler; bu yüzden çoğu zaman ya o ya bu değildir. Firecrawl canlı web’i tarar, JavaScript render eder ve ana içeriği çıkarır. Docling ise elinizde zaten bulunan belgeleri, gerçek PDF tablo yapısı ve OCR desteğiyle, tamamen çevrimdışı dönüştürür. Kaynağınız web sayfalarıysa bir web aracı kullanın (Firecrawl ya da Thunderbit’in API/MCP/CLI’si). PDF, tarama ya da Office dosyalarıysa Docling kullanın. Gerçek pipeline’ların çoğu ikisini birlikte çalıştırır.
