Docling sık sık web kazıyıcılarla aynı sepete konuyor, ama aslında öyle değil. IBM Research’ten çıkan — şimdi LF AI & Data Foundation bünyesinde yer alan — bir belge dönüştürme araç seti; elinizde zaten bulunan dosyaları (PDF, DOCX, PPTX, XLSX, HTML, görseller) alıp Markdown ya da JSON’a çeviriyor. Kendi sloganı bile doğrudan şöyle: "Get your documents ready for gen AI."
Bu yüzden aşağıdaki çalışma bir dönüştürücü incelemesi; bir tarayıcı incelemesi değil. Buradaki her şey tek bir CPU’lu makinede ölçüldü (macOS arm64, Python 3.14.2, Docling 2.111.0), komut dosyalarıyla puanlandı ve hatalar olduğu gibi kaydedildi. Depo devasa boyutta ve her gün değişiyor — 63.069 yıldız, 4.449 fork ve metadata’yı çektiğim gün atılmış bir push — dolayısıyla burada göreceğiniz sürüm ya da hata sayıları sabit değil, yalnızca bir anlık görüntü.
Docling Tam Olarak Nedir, Nedir Değildir?
Docling’de her şeyin temel birimi DoclingDocument nesnesidir: bir dosyayı bu yapıya ayrıştırın, ardından Markdown, HTML, DocTags veya kayıpsız JSON olarak dışa aktarın. Kod MIT lisanslıdır (tek tek modellerin lisansları değişebilir), kökeni IBM Research Zurich’e dayanır ve yazı yazıldığı sırada en güncel sürüm, bu testi çalıştırmamdan iki gün önce yayımlanan v2.112.0’dır.
Başlıca yeteneği PDF ve görsel işleme yoludur. Bu yol, basit metin 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. İncelenmesi gereken asıl bölüm de burasıdır; yalnızca HTML’e bakan bir testin asla göremeyeceği kısım da yine burasıdır.
Bir ayrım, bir haftalık kafa karışıklığını önlüyor. Docling hiçbir şey çekmez. JavaScript çalıştırmaz, anti-bot duvarlarını aşmaz, crawl yapmaz. Siz dosyayı verirsiniz; o anlamlandırır. Tarama işi başka bir aracın görevidir ve bu fark, insanların ileride Docling’in Firecrawl’ın yerini alıp alamadığını sormasıyla önem kazanır (almaz — birbirini tamamlarlar, birazdan nedenini anlatacağım).
Kimsenin Sizi Uyarmadığı İlk Çalıştırma
pip install docling, Python 3.14.2 üzerinde sorunsuz tamamlanıyor. Sonra sanal ortama bakıyorsunuz ve boyutu 1,3 GB. Docling, siz yalnızca bir HTML dosyası dönüştürüyor olsanız bile tüm ML yığınını doğrudan bağımlılık olarak çekiyor:
| Bağımlılık | Diskte kapladığı alan (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) | 72.1 |
| docling_parse | 30 |
Bu, tek bir PDF bile dönüştürmeden önceki durum.
Asıl sürtünme ilk PDF dönüşümünde ortaya çıkıyor; çünkü modelleri o zaman indiriyor. Taze, izole bir HuggingFace önbelleğinde, ilk PDF dönüşümü yaklaşık 224 saniye sürdü — ve bunun neredeyse tamamı hesaplamadan değil, indirmeden kaynaklandı. Düzen + TableFormer modelleri diskte yaklaşık 506 MiB yer kaplıyor (342 MiB TableFormer + 164 MiB layout, du ile doğrulandı) ve RapidOCR de site-packages içine yaklaşık 40 MB’lık PP-OCRv4 ağırlığı indiriyor. Aynı dosyanın ikinci kez dönüştürülmesi? 0,55 saniye. Modeller önbelleğe alınıyor; bedeli bir kez ödüyorsunuz.
Göz ardı etmeniz gereken bir sayı var: coldstart betiği model_download_mb olarak 1060,2 yazdırıyor. Bunu ayak izi diye alıntılamayın. Bunun nedeni os.walk’ın symlink’leri izlemesi ve HuggingFace önbelleğinin her model dosyasını blobs/ altında bir kez saklayıp sonra snapshots/ altında symlink olarak yeniden göstermesi — dolayısıyla tarama 14 model dosyasını iki kez sayıyor. du ile uyumlu, symlink çift sayımından arındırılmış gerçek değer yaklaşık 506 MiB (yalnızca blobs: 505,4 MiB). Docling’i benchmark eden herkes için çıkarım şu: indirme baytlarını ve diskte kaplanan baytları ayrı raporlayın; çünkü aynı şey değiller.
Bir başka ayrıntı da Docling konteyneri hazırlayanları vuruyor. Ağırlıklar iki konuma, iki ayrı takvimle dağılıyor. Layout ve TableFormer modelleri HF_HOME’a uyar ve ilk PDF dönüşümünde indirilir. RapidOCR modelleri ise uymuyor — doğrudan …/site-packages/rapidocr/models/ içine gelir ve önbellek ayarınızı tamamen atlar. Eğer imajı önceden pişiriyorsanız ya da air-gap bir ortamda çalışıyorsanız, iki önbelleği de ayrıca ele almanız gerekir; HF_HOME ayarlamak ikinciyi yakalamaz.
Yine de adil tarafı söyleyelim. Docling’in önceki sürümlerinden beri proje, docling-slim paketini sundu — yaklaşık 50 MB’lık bir çekirdek; HTML için pip install docling-slim[format-html] kullanıp torch’u çekmeden ilerleyebiliyorsunuz. Yani varsayılan docling meta paketi için 1,3 GB’lık yük gerçek; ama artık zorunlu değil. Ben varsayılan paketi test ettim, çünkü pip install docling hâlâ bunu veriyor; ancak bu ağırlık çözülmemiş bir kusur değil — modüler çözüm mevcut ve #2393 numaralı issue altında izleniyor.
Kurulum sırasında küçük ama sinir bozucu bir detayla karşılaştım: import docling; docling.__version__ çalıştırınca AttributeError: module 'docling' has no attribute '__version__' hatası geliyor. Modül bu bilgiyi dışa açmıyor. Çalışan kontrol importlib.metadata.version("docling"); bu da '2.111.0' döndürüyor. Küçük bir geliştirici deneyimi pürüzü; Temmuz 2026’dan beri upstream’de açık, issue #3733.
Tablo Doğruluğu: TableFormer’ın Kendini Gösterdiği Yer
Docling’i düz PDF-to-text çıktısından ayıran şey tablolardır; bu yüzden makine tarafından okunabilir gerçek veriye sahip yedi tablo PDF’i oluşturdum ve çıktıyı hücre hücre puanladım. Burada önemli olan iki metrik aynı şey değildir: cell recall, gerçek verideki değerlerin tespit edilen tabloda herhangi bir yerde bulunma oranıdır; in-row rate ise doğru satıra yerleşenlerin oranıdır. Bu ikisini birbirine karıştırmak aracı olduğundan daha iyi gösterir; o yüzden ikisini de veriyorum:
| Tablo (stres testi) | Tespit edildi | Hücre recall | Satır içi oran | Not |
|---|---|---|---|---|
| T1 basit kenarlıklı ızgara (8 satır × 5 sütun), sayfada tek başına | Hayır | 0.0 | — | <!-- image --> olarak sınıflandı, tüm hücreler düştü |
| T2 çerçevesiz (yalnızca başlık çizgisi var) | Evet | 1.00 | 1.00 | kusursuz, birebir ızgara |
| T3 birleştirilmiş 2 seviyeli colspan başlık | 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ı |
| T5 colspan başlık + çerçevesiz | Evet | 1.00 | 0.97 | tüm değerler bulundu; T3 ile aynı başlık-satır kayması |
| T6 finansal tablo, boş sütun, sağa hizalı | Evet | 1.00 | 1.00 | boş sütun korunmuş, kaymamış |
| T7 geniş 12 sütunlu ızgara | Evet | 1.00 | 1.00 | geniş tabloda sütun kayması yok |
Docling’in tespit ettiği beş tabloda gerçek verideki her değer başarıyla geçti — hücre recall tümünde 1.00. Bu beş tablonun üçünde, her değer doğru satıra da yerleşti. Çok seviyeli başlık içeren iki vakada (T3 ve T5), bir başlık değeri orijinal satırından kayıp bir alt satıra düşüyor; böylece in-row oranı 0.97’ye iniyor — veri kaybolmuyor, yalnızca üst üste binmiş başlıklarda satır ataması biraz sallanıyor.
Zor yapısal durumlarda beklediğimden daha iyi dayandı. İki seviyeli colspan başlık GitHub tarzı Markdown’a doğru biçimde düzleştirildi ("Q1 2026" etiketi, colspan’ı GFM’e dönüştürmenin doğru yolu olarak, kapsadığı iki sütunda tekrarlandı). Sadece başlık çizgisi olan çerçevesiz ızgara (T2) birebir geçti. 12 sütunlu geniş tablo (T7) kaymadı. Ve tamamen boş bir finansal sütun (T6), atılmak ya da çökmek yerine boş hücreler halinde korundu. Bu, resmî TableFormer TEDS skorlarıyla tutarlı — basit tabloda 95.4, karmaşık tabloda 90.1, tüm tablolarda 93.6 — ve model kartı Camelot (73.0) ile EDD (88.3) değerlerinin oldukça üstünde benchmark ediyor.
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ı yanlış işlediğini bildiriyor. Benim test setimde basit colspan (T3/T5) ve rowspan değerleri doğru biçimde düzleştirildi; yalnızca yukarıda belirttiğim çok seviyeli başlık satır kayması görüldü. Ancak #3698’deki başarısız örnekler, düzensiz çok satırlı/çok sütunlu birleştirmeler ve çok sayfalı tablolar — yani en problemli uç. Benim örneklerim ise basit uçta kalıyor. Dolayısıyla doğru ifade dar olmalı: burada basit colspan ve rowspan değerleri geri kazanıldı (çok seviyeli başlıklarda bir satır kayması olabilir); karmaşık ve düzensiz birleştirmeler ise belgelenmiş açık bir sorun olmaya devam ediyor. Ne “birleştirilmiş hücreler çalışıyor” deyin, ne de “birleştirilmiş hücreler bozuk.”
Tuzak: Sayfada Tek Başına Kalan Tablo Kaybolabilir
Tabloya geri bakın — T1 ve T4 hiç tespit edilmedi. Docling <!-- image --> üretti ve hiçbir hata vermeden tüm hücreleri düşürdü. T1, son derece sıradan, kenarlıklı, 8 satır ve 5 sütunlu bir ızgara. Bunun tablo ayrıştırma zayıflığı olup olmadığını söylemeden önce asıl tetikleyiciyi izole etmek istedim; bu yüzden betikli 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üler değil, gerçekten dijital PDF’ler. OCR’ı kapatmak (do_ocr=False) yardımcı olmuyor; tablolar yine kayboluyor. Ve DoclingDocument’i doğrudan inceleyince len(doc.tables) == 0 iken len(doc.pictures) == 1 çıkıyor — düzen modeli tüm tablo bölgesini Picture olarak sınıflandırmış.
Sonra belirleyici testi yaptım. Aynı T1 ve T4 tablolarını tekrar işledim; bu kez etraflarına birkaç normal paragraf ekledim ve yeniden dönüştürdüm. İkisi de kusursuz geçti: len(doc.tables) == 1, doğru GFM tabloları üretildi ve T4b’nin rowspan etiketi "North" üç satır boyunca doğru şekilde tekrarlandı. Aynı tablo. Değişen tek şey, sayfada tek başına ve seyrek durumda mı olduğu, yoksa metin içine gömülü mü olduğuydu.
Dolayısıyla gerçek uyarı şu: TableFormer kırılgan olduğu için değil; Docling’in RT-DETR düzen modeli sayfa bağlamını kullandığı için, başka neredeyse hiçbir şeyin olmadığı bir sayfada tek başına duran küçük bir tablo Picture olarak okunup sessizce düşebiliyor. Bu pratikte kolayca karşınıza çıkar; çünkü fatura, teknik döküman ve kırpılmış dışa aktarımlar tam da böyle görünür: sayfada bir tablo, etrafta neredeyse hiç yazı yok. Çözüm sıradan ama etkili: düzen modeline sayfa bağlamı verin ya da dönüşümden sonra doc.tables sayısını kontrol edip sıfır olan sayfaları işaretleyin. Bu, #3495 issue’suna (bir tablonun hem Table hem Picture olarak algılanması) komşu bir durum; ancak sayfa seyrekliğinin tetiklediği bu özel davranış — aynı tablo yalnız bırakılınca düşüyor, metin içine gömülünce geçiyor — yayımlanmış bir yerde bulamadım. Ölçülmüş, daha önce belgelenmemiş; ama kimsenin bilmediği bir bug da 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 yerdir; bu yüzden Docling’e ölçülebilir şekilde 0 karakterlik metin katmanı olan iki gerçek tarama verdim — pypdfium2, kurtarılabilir karakter sayısını sıfır raporlayarak tüm çıktının OCR olduğunu, yanında gizli bir metin katmanı olmadığını doğruluyor.
Tek sayfalık ocr_test.pdf, CPU üzerinde 14,3 saniyede tertemiz geri döndü: "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, dört sayfanın tamamında OCR çalıştırdı ve toplam 70,1 saniyede (17,5 sn/sayfa) her sayfaya test cümlesini tekrar yazdı. Varsayılan OCR otomatik devreye girdi — ne bayrak ne konfigürasyon gerekiyordu.
Buradaki en önemli ayrıntı şu: varsayılan OCR motoru RapidOCR, EasyOCR değil. Bunu, ilk çalıştırmada PP-OCRv4 .pth ağırlıklarının indirildiğini görerek 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 isteğe bağlı bir eklenti. Geçerli kalan uyarı ise şu: OCR, ölçekte yavaş yoldur ve burada gördüğünüz her şey CPU sınırında ölçüldü — bir GPU bu süreleri ciddi biçimde düşürür.
Gerçek PDF’ler, Okuma Sırası ve Sayfa Başına Süre
Sentetik örnekler belirli davranışları kanıtlar; gerçek PDF’ler ise işin gerçekten çalıştığını gösterir. İki doğrudan dijital akademik makale üzerinde test yaptım — 9 sayfalık Docling teknik raporu ve 15 sayfalık "Attention Is All You Need"; ikisi de iki sütunlu, tablolı ve formüllüydü.
15 sayfalık Attention makalesinde, tüm beş bölüm işareti — Abstract, Introduction, Background, Conclusion, References — iki sütunlu düzene rağmen doğrusal Markdown içinde belgenin sırasına uygun şekilde görünüyor. Her içerik doğrulama noktası (Transformer, encoder, BLEU, multi-head) mevcut ve meşhur çok sütunlu sonuç tabloları dört tespit edilen tablo olarak kaydediliyor. Bu, gerçek okuma sırası ve sütun birleştirme geri kazanımıdır; RAG parçalama için temel değer önerisi de tam olarak budur — eğer doğrusal hale getirici iki sütunlu bir sayfayı iç içe geçmiş saçmalığa çeviriyorsa, belgeyi anlamlı biçimde parçalara ayıramazsınız.
Zamanlama beklenmedik bir ders veriyor. Sayfa başına süreyi belirleyen şey, sayfa sayısından çok, her sayfadaki yapı yoğunluğu. Daha yoğun 9 sayfalık rapor, sayfa başına 14,95 saniye ile 15 sayfalık makaleden daha yavaştı; 15 sayfalık makale ise sayfa başına 5,99 saniye sürdü. Çünkü yoğun rapor sayfa başına daha fazla tablo ve şekil içeriyor — 9 sayfada 3 tablo, 15 sayfada 4 tablo — ve her biri ek düzen ve TableFormer çıkarımı tetikliyor. Bu ince bir fark; mutlak olarak bakınca daha yoğun belgenin tablosu daha az, daha çok değil. Dolayısıyla CPU üzerinde “sayfa başına saniye”, uzunluğun değil yapısal yoğunluğun fonksiyonu. Bu tek CPU koşusunda elde edilen bir ölçüm; ü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 doğrulama noktaları olan bir DOCX, bir XLSX ve bir PPTX ürettim, ardından iki şeyi kontrol ettim: bu doğrulama noktaları Markdown’da görünüyor mu ve export_to_dict() üzerinden JSON’a döndürülünce kaybolmadan korunuyor mu?
| Dosya | Dönüşüm sn | Markdown’da bulunan probe’lar | MD içindeki tablo sayısı | Probe’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 probe’ları Markdown’a geçti, tablolar geri kazanıldı (DOCX’teki birleştirilmiş "Total" satırı ve her iki XLSX sayfası dahil) ve her probe export_to_dict() JSON’unda da korundu — bu da kayıpsız DoclingDocument iddiası için, en azından temiz girdilerde, anlamlı kanıt. Bu formatlar ML modelleri yerine formatın kendi arka uçlarını kullanıyor; bu yüzden milisaniyeler içinde çalışıyor ve tamamen çevrimdışı işliyorlar. Kapsam dürüst: format başına bir temiz dosya, genişliği kanıtlar; sorunlu Office dosyaları için stres testi değildir.
HTML: Sadık, Ama Temiz Değil
Bu, Docling’in RAG hattınıza girip girmeyeceğini belirleyen uyarıdır; dikkatle okuyun. Docling, tüm HTML belgesini dönüştürür. Readability tarzı ana içerik çıkarımı yapmaz. Sitenin üstbilgi/altbilgi, TOC, cookie ve benzeri kalabalığının ne kadarının korunduğunu, Docling’in kendi çıktısında bu tür satırları sayarak ölçtüm.
| Sayfa | Boş olmayan MD satırı | Şablon satırı | % şablon | Makalenin başladığı satır |
|---|---|---|---|---|
| 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 kalabalık bir sayfada Markdown satırlarının yaklaşık %13’ü nav/TOC/footer şablonundan geliyor ve gerçek makale 28. satırda başlıyor — çıktı “move to sidebar / Contents / Toggle the table of contents” ile açılıyor, “CS1 maint… / Search Wikipedia” ile kapanıyor. Temiz içerik sayfalarında (books, quotes) bu oran yaklaşık %0; yani sorun sayfa başına bir vergi değil, şablon kalabalığı problemi. Docling size temiz ana makale ayıklaması değil, sadık bir tam belge Markdown’u verir. Yukarı akışta HTML mobilyası sorunu #1865 numaralı issue’da (kapalı) ve #1930’da (açık) takip ediliyor.
Adil kalmasını sağlayan iki nokta var. Birincisi, HTML tarafında Docling hiçbir ML modeli çalıştırmaz — yalnızca basit bir pipeline üzerinde BeautifulSoup arka ucu kullanır. Sayfanızı vision modellerinin okuduğu hikâyesi sadece PDF ve görseller için geçerlidir; Docling’e HTML verirseniz layout ya da TableFormer mekanizmalarının hiçbiri devreye girmez. İkincisi, PDF yolunda header ve footer gibi şablon öğelerini sınıflandırma denemesi vardır; dolayısıyla “hiç şablon temizleme yapmıyor” demek fazla güçlü olur — özellikle HTML arka ucunun kalabalığı aynen geri verdiğini söylemek daha doğrudur.
Başka Araçlarla Karşılaştırma ve Thunderbit’in Yeri
Web Veri Çıkarmak İçin Thunderbit’i Deneyin
İnsanların Docling’i en sık kıyasladığı araç Firecrawl olduğu için burada bir konumlandırma tablosu veriyorum. Önceden bir not: bu, dokümantasyon seviyesinde bir karşılaştırmadır, aynı makinede yapılmış bir benchmark değildir. Firecrawl’ı bu örnekler üzerinde çalıştırmadım. Burada ölçülen yalnızca Docling sütunudur; Firecrawl sütunu kendi herkese açık dokümanlarından alınmıştır.
| Eksen | Firecrawl (dokümanlarına göre) | Docling (burada ölçülen) |
|---|---|---|
| Temel iş | Canlı web’i tara + kazı → Markdown | Zaten elinizde olan belgeyi → Markdown/JSON’a dönüştü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 şablon) |
| PDF tablo yapısı (ML) | sınırlı | Evet — TableFormer (resmî TEDS 93.6; tespit edilen örneklerde hücre recall 1.00, satır içi 0.97–1.00) |
| Taranmış PDF / OCR | sınırlı | Evet — varsayılan RapidOCR (0 metin katmanlı taramayı geri kazandı) |
| Format çeşitliliği | 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 yükü | API anahtarı / hafif istemci | 1,3 GB varsayılan kurulum + ~506 MiB model (veya docling-slim) |
| Lisans | ticari / kaynak erişimli | MIT |
Kısa versiyon şu: veriniz canlı web’delse 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ı — ve gerçek tablo/OCR anlayışıyla, yapıyı koruyan, çevrimdışı bir dönüşüm istiyorsanız Docling doğru araçtır. Birbirlerini tamamlarlar. Gerçekçi bir pipeline birini crawl için, diğerini belge dönüşümü için kullanır.
Sıra Thunderbit’e de dürüstçe gelmişken açık konuşayım; çünkü burada çalışıyorum ve aksi halde tarafsızmışım gibi davranırsam haklı olarak şüphelenirsiniz. Thunderbit ve Docling aynı işi yapmıyor; bunu zorla eşitlemeyeceğim. Geliştiriciler için Thunderbit, AI scraping API’si + MCP server + CLI olarak çalışır ve iş birimi canlı web sayfasıdür: POST /distill bir URL’yi, JS render, anti-bot ve CAPTCHA dahil olmak üzere, temiz ve LLM’ye hazır Markdown’a çevirir; POST /extract ise tanımladığınız JSON Schema üzerinden şemaya uygun yapılandırılmış JSON döndürür. Bu, bir RAG hattının çekme ve temizleme tarafıdır. Docling ise yerel belge tarafıdır — PDF, tarama, diskinizde zaten duran e-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 taramalarsa Docling’i kullanın. Gerçek dünyadaki çoğu hatta ikisi birlikte kullanılır; biri diğerinin yerine geçmez.
Karar: Geçici, Ama Yapılacak Ödevler Kaldı
Size 0–100 arasında tek bir puan vermeyeceğim; çünkü burada ağırlıklı toplam yapmak, Docling’in hiç iddia etmediği şeyler için de ceza yazmak anlamına gelir (örneğin crawling) ve bunları karşılaştırılabilir gibi göstermek olur. Test ettiğim örneklerde boyut bazında sonuç şu:
- Kurulum / ilk çalıştırma: ağır — 1,3 GB venv, yaklaşık 506 MiB model, ilk PDF’de yaklaşık 224 sn, sıcak çalışmada yaklaşık 0,55 sn — ama
docling-slimbu yükten kaçınmanızı sağlıyor. - Tablo doğruluğu: tablo tespit edildiğinde güçlü (5/5’te hücre recall 1.00, satır içi 0.97–1.00), bu örneklerde resmî TEDS anlatımıyla uyumlu.
- Tablo tespiti sağlamlığı: seyrek sayfa tuzağı — tek başına kalan bir tablo Picture olarak düşebilir.
doc.tableskontrol edin. - Taranmış / OCR: çalışıyor, varsayılan RapidOCR; ölçekte yavaş.
- Çoklu format: sağlam, JSON round-trip bozulmuyor.
- HTML: sadık, ama temiz değil — ana içerik ayıklaması yok.
- Geliştirici deneyimi: temiz 3 satırlık API ve düzenli bir
DoclingDocument, eksik__version__hariç.
Kimler için uygun: PDF, tarama ve Office dosyaları üzerinde, çevrimdışı, yapıyı koruyan dönüştürme ve gerçek tablo + OCR anlayışı isteyen RAG veya veri hattı ekipleri. Kimler için uygun değil: canlı web crawling ya da temiz ana makale HTML çıkarımı isteyenler — bunun için başka bir araç gerekiyor.
Ve bu bir inceleme, basın bülteni değil; sınırlamalar etiket üzerinde kalmalı. Bu, hedefli bir testtir — tek CPU’lu makinede 7 sentetik tablo + 2 gerçek PDF — TEDS ölçeğinde bir doğruluk benchmark’ı değil. Docling’e bir hat kurmadan önce sizin de test etmeniz gereken birkaç şey var: isteğe bağlı VLM (GraniteDocling) yolu, gerçek docling-slim ayak izi, herhangi bir GPU çalışması, karmaşık ve düzensiz birleştirilmiş hücreler ile çok sayfalı tablolar, formülden LaTeX’e doğruluk ve — üretimde sizi en çok şaşırtabilecek olan — batch bellek büyümesi, thread/GIL ölçeklenmesi ve binlerce dönüşüm boyunca nesne yaşam döngüsünün dayanıklılığı. Docling, iddia ettiği şeylerde güçlü; ölçülmüş, pazarlanmış değil; ama güvenmeden önce haritalamak isteyeceğiniz gerçek sınırları da var. Seyrek sayfa uyarısını bilin, ilk indirme maliyetini bütçeye ekleyin ve ölçek altındaki davranışı kendiniz doğrulayın.
Web Veri Çıkarmak İçin Thunderbit’i Deneyin Get Started Free
SSS
Docling bir web scraper ya da crawler mı? Hayır. Docling, elinizde zaten bulunan belgeleri — PDF, DOCX, PPTX, XLSX, HTML, görseller — Markdown veya JSON’a çevirir. URL çekmez, JavaScript çalıştırmaz, anti-bot ile uğraşmaz. Canlı web’i taramak, Firecrawl ya da Thunderbit’in web API’si gibi araçların işidir; Docling ise sizin verdiğiniz dosyadan başlar.
Docling kurulumu ve ilk çalıştırma indirmesi 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 (tek başına torch 536 MiB). İlk PDF dönüşümü, layout ve TableFormer modellerinden yaklaşık 506 MiB’ı diske indirir; buna ek olarak RapidOCR ağırlıkları da yaklaşık 40 MB’tır ve işlem yaklaşık 224 saniye sürer — bunun neredeyse tamamı indirme süresidir. İkinci dönüşüm yaklaşık 0,55 saniyedir. Yalnızca hafif formatlara ihtiyacınız varsa, docling-slim (~50 MB çekirdek) ağır yolu atlar.
Docling OCR yapıyor mu, hangi motoru kullanıyor? Evet. Metin katmanı olmayan taranmış bir PDF’de Docling’in OCR’ı otomatik devreye girer ve testimde metni temiz biçimde geri kazandı. Varsayılan motor RapidOCR’dir, EasyOCR değil — eski yazılarda sık yapılan bir hata. EasyOCR artık isteğe bağlı bir eklentidir. OCR, özellikle CPU üzerinde, ölçekte yavaş kısımdır.
Docling neden tablomı görsele çevirdi ya da tabloyu düşürdü?
En olası sebep seyrek sayfa etkisidir. Docling’in RT-DETR düzen 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ı tablo, etrafında gövde metni olduğunda sorunsuz dönüştürülür. Çözüm, düzen modeline sayfa bağlamı vermek ya da dönüşümden sonra doc.tables sayısını kontrol edip sıfır olan sayfaları işaretlemektir.
Docling mi Firecrawl mı — hangisini kullanmalıyım? Farklı işler oldukları için çoğu zaman ya o ya bu değil. Firecrawl canlı web’i tarar, JavaScript’i çalıştırır ve ana içeriği çıkarır. Docling ise elinizde zaten olan 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 veya Thunderbit’in API/MCP/CLI’si). PDF, tarama ya da Office dosyalarıysa Docling’i kullanın. Gerçek dünyadaki çoğu hat ikisini birlikte çalıştırır.
