PDF → Markdown Çıkarım Araçları

AI ULAKBIM pipeline'ının birinci adımı: tezler, makaleler ve teknik dokümanlardan oluşan PDF korpusunu LLM/RAG'e uygun, yapısal bütünlüğü korunmuş Markdown'a dönüştürmek. Bu sayfa karşılaştırma sonuçlarını ve Marker seçiminin gerekçesini özetler.

Tam rapor (uzun versiyon, gözlem detayları, OCR notları): 30_Deneyler/Marker-Detaylar/Rapor-v1.md

1. Pipeline'da Konumu

PDF dosyası
   │
   ▼
[ Marker (PDF → Markdown) ]      ← bu sayfanın konusu
   │
   ▼
Markdown dosyası
   ├──▶ [ Qwen2.5-14B (metadata extraction) ] ──▶ Editöryel Yardım
   ├──▶ [ Embedding (F2LLM, bge-m3, ...) ]    ──▶ Anlamsal Arama / Outlier
   └──▶ [ Tez metni / atıf metni çıkarımı ]   ──▶ Atıf Zekası / Bilgi Ağları

PDF→MD adımındaki kayıp / bozulma, aşağı akış tüm bileşenlere doğrudan yansır:

Tablo bozulursa → metadata extraction'da references[] ve journal alanları kaybolur.
Formül bozulursa → arama/embedding kalitesi STEM tezlerinde düşer.
Kolon akışı karışırsa → chunking yanlış sınırlardan kesim yapar, retrieval bozulur.

Bu yüzden adım, "ön işleme" değil birinci sınıf bir mimari karar olarak ele alınmıştır.

2. Değerlendirilen Araçlar

Araç	Yaklaşım	Güçlü	Zayıf
Apache Tika	PDFBox + Tesseract	Geniş format; saf metin hızlı	Tablo, formül, layout düşük; TR/AR OCR zayıf
MarkItDown	Hafif Markdown dönüştürücü	Çok formatlı, kurulumu kolay	Layout / tablo zayıf
PyMuPDF4LLM	MuPDF üzerine LLM/RAG katmanı	Dijital PDF'te çok hızlı, ek model yok	Tablo dağılır, sporadik karakter ayrışması
Docling	DocLayNet + TableFormer	Çok kolonlu okuma sırası iyi	Formül büyük oranda `formula-not-decoded`
MinerU	Layout + UniMERNet + PaddleOCR	Formül LaTeX'i tutarlı, span çıktısı	Yavaş, GPU yoğun
Marker	Layout + Surya OCR + Texify + LLM düzelti	Tablo + formül + görsel + chunk üretimi	GPU zorunlu, ~50 GB VRAM (8 worker)

Karşılaştırma Tablosu

Kriter	Tika	MarkItDown	PyMuPDF4LLM	Docling	MinerU	Marker
Düz metin doğruluğu	Yüksek	Orta	Yüksek	Yüksek	Yüksek	Yüksek
Çok kolonlu layout	Düşük	Düşük	Orta	Yüksek	Yüksek	Yüksek
Tablo yapısı	Düşük	Düşük	Düşük	Orta	Orta	Yüksek
Formül / matematik	Düşük	Düşük	Düşük	Düşük	Yüksek	Yüksek
Görsel ayrıştırma	Düşük	Düşük	Orta	Orta	Orta	Yüksek
OCR (TR + çoklu dil)	Orta	Düşük	Orta	Orta	Yüksek	Yüksek
LLM/RAG chunk	Düşük	Orta	Yüksek	Yüksek	Yüksek	Yüksek
Büyük korpus hızı	Yüksek	Yüksek	Yüksek	Orta	Düşük	Orta
Donanım esnekliği	Yüksek	Yüksek	Yüksek	Orta	Düşük	Düşük
Konfigürasyon esnekliği	Orta	Düşük	Orta	Orta	Orta	Yüksek

Marker; tablo + formül + görsel + OCR + chunk kriterlerinin tamamında "Yüksek" alan tek araçtır.

3. Karar: Marker

Neden seçildi

Yapısal bütünlük: Tablo / formül / görsel / başlık hiyerarşisi tek pipeline'da.
Doğal RAG çıktısı: Markdown + JSON + chunk; ek post-processing gerekmiyor.
Çoklu dil OCR: Surya transformer tabanlı; Tesseract'a göre TR ve AR'da daha tutarlı.
Konfigürasyon zenginliği: OCR zorlama, LLM düzelti, sadece tablo, sayfa aralığı, görsel kapatma.
Performans kabul edilebilir: H100 + 8 worker → 17 PDF / ~280 sn (bkz. Deney 06).

Kabul edilen maliyet

GPU zorunlu: CPU çıktısı pratik değil.
VRAM yoğun: 8 worker'da ortalama ~50 GB, tepe ~63 GB.
Tek seferlik işleme: Korpus bir kez Markdown'a çevrilip saklanacağı için maliyet amortize ediliyor.

4. Üretim Konfigürasyonu (Marker)

Önerilen ayarlar

Senaryo	`workers`	`OCR_ENGINE`	Görsel	Notlar
Dijital PDF + büyük korpus	8	`None`	`--disable_image_extraction`	En iyi süre/başarı dengesi (H100)
Dijital PDF + güvenli mod	6	`None`	açık / kapalı	VRAM ~37 GB; daha rahat
Taranmış PDF	4–6	`surya`	açık	Süre artar; dikkatli izlenmeli

Ortam değişkenleri

export TORCH_DEVICE=cuda
# Dijital PDF iseniz OCR'ı kapatmak büyük hız kazandırır:
export OCR_ENGINE=None
# Yüksek paralelizmde tartışmalı senaryo (10+ worker) kullanılmamalı.

Anti-pattern'ler

workers >= 10: 10'da süre düşmüyor, 12'de OOM.
OCR_ENGINE=surya + dijital PDF: gereksiz yavaşlama.
Görseli aktif tutup downstream'de hiç kullanmamak: VRAM ve disk israfı.

5. Pipeline'a Bağlı Riskler

Risk	Aşağı akıştaki etkisi	Önlem
Kaynakça başlığı kaybolması	Qwen referans recall düşer	Marker LLM düzelti modu, sonradan Qwen'in kendi recall toleransı
Tablo bozulması	Metadata extraction'da `journal`, `pages` alanları yanlış	Marker LLM destekli mod açılabilir
OCR karakter ayrışması	Embedding kalitesi düşer (özellikle TR)	OCR motor seçimi + örneklem QA
8'den fazla worker'da OOM	Eksik dosya	Üretimde `workers=8` üst sınır olsun
Disk maliyeti	Markdown + görsel	`--disable_image_extraction` görseli gerekmeyen pass'lerde

6. Hangi Aracı Ne Zaman Kullan?

Üretim pipeline'ı Marker üzerine kuruluyor. Aşağıdaki kenar durumlarda alternatif düşünülebilir:

Durum	Öneri
Hızlı kontrol / büyük dijital korpus + tablosuz	PyMuPDF4LLM ile baseline
Sadece düz metin (örn. embedding için ham giriş)	PyMuPDF4LLM yeterli olabilir
Marker bir dosyada başarısız → düşürmemek için	MinerU veya Docling'e fallback
Heterojen kurumsal format (Office, e-posta)	MarkItDown / Tika ön katmanı

7. İlgili Sayfalar

Deney Kartı 06 — Marker Performans Benchmark
Tam karşılaştırma raporu
Editöryel Yardım → Metadata Extraction — pipeline'ın bir sonraki adımı
Mimari — uçtan uca akış
Görselleştirme Araçları — operasyon kız kardeşi sayfa