DeepSeek OCR

Tek cümlelik özet

Belge/sohbet kayıtlarını görüntüye (görsel token) dönüştürerek LLM bağlamını büyük ölçüde azaltan (≈7–20×) ve ardından metne doğru biçimde geri yükleyen (OCR) optik bağlam sıkıştırması önerilip doğrulanıyor. Yeni bir vision encoder olan DeepEncoder ile 3B MoE decoder birleştirilerek az sayıda görsel token ile bile SOTA düzeyinde belge ayrıştırma performansı gösteriliyor.

Problemin tanımı
• LLM'lerde uzunluk arttıkça quadratic maliyet büyür.
• Belge metni görüntü olarak render edildiğinde görsel token sayısı metin tokenlarından çok daha az olur → görüntüden metne geri yükleme iyi yapılabilirse yüksek verimli sıkıştırma mümkündür.
• OCR, görsel↔metin arasında doğal bir sıkıştırma/geri yükleme eşlemesi ve nicel değerlendirme sağladığı için iyi bir deney unsuru.

Yönteme genel bakış

Mimari: DeepEncoder (encoder) + DeepSeek-3B-MoE-A570M (decoder)
• DeepEncoder (çekirdek)
• İki aşamadan oluşur:
1. Pencere attention tabanlı görsel algı blokları (SAM-base ailesi, ~80M) → yüksek çözünürlükte bile etkin bellek kullanımı düşüktür
2. 16× convolution compressor ile token sayısı büyük ölçüde azaltılır, ardından
3. Global attention tabanlı görsel bilgi blokları (CLIP-large, ilk Patch embedding kaldırılmış)
• Çoklu çözünürlük desteği (modlar): Tiny (64 token, 512²), Small (100, 640²), Base (256, 1024²), Large (400,1280²) +
Gundam (n adet 640² tile + 1024² global view → token = n×100+256),
Gundam-M (1024² tile + 1280² global)
• Geçerli token (valid) kavramı: padding kaynaklı boşluklar hariç tutularak yalnızca gerçek tokenlar hesaplanır (formülle tanımlanır).
• MoE decoder: DeepSeek-3B-MoE (12 katman) kullanılarak encoder'ın ürettiği sıkıştırılmış görsel tokenlardan özgün metin geri yüklenir.

Veri motoru ve eğitim
• OCR 1.0 (geleneksel OCR):
• İnternetten toplanmış 30 milyon sayfa PDF (yaklaşık 100 dil):
• Coarse: fitz ile çıkarım (optik metin tanıma eğitimi için)
• Fine: Çince ve İngilizce için ayrı ayrı 2 milyon sayfa, gelişmiş layout/OCR ile ayrıntılı biçimde etiketlendi (kutular + metin iç içe), ek olarak 3 milyon sayfa Word belgesi
• Doğal sahne OCR: Çince/İngilizce için ayrı ayrı 10 milyon örnek (PaddleOCR etiketleri)
• OCR 2.0 (karma yapay görüntü ayrıştırma):
• Grafikler (pyecharts/matplotlib) 10 milyon görüntü → HTML tablo olarak etiket
• Kimyasal formüller: PubChem SMILES'tan RDKit render ile 5 milyon
• Düzlemsel geometri: Slow Perception yöntemiyle veri üretimi (doğru parçası sözlüğü vb.)
• Genel vision: Encoder ön eğitimi için 100 milyon LAION örneği karıştırıldı
• Eğitim altyapısı: 20 düğüm (her birinde 8×A100-40G), 4 aşamalı pipeline paralelliği (encoder 2, decoder 2), DP=40, global batch 640.
• Yalnızca metin için 90B tok/gün, multimodal için 70B tok/gün
• Prodüksiyon veri üretim kapasitesi: 20 düğümle günde 33 milyon sayfa üretilebiliyor

Deney sonuçları

1. Bağlamın optik sıkıştırılması (Compression) çalışması — Fox benchmark'ı (İngilizce 100 sayfa, 600–1300 token)
   • Small (100 görsel token) için doğruluk ve sıkıştırma oranı (metin tokenı/görsel token):
   • 600–700: 98.5%, 6.7×
   • 700–800: 97.3%, 7.5×
   • 800–900: 96.8%, 8.5×
   • 900–1000: 96.8%, 9.7×
   • 1000–1100: 91.5%, 10.6×
   • 1100–1200: 89.8%, 11.3×
   • 1200–1300: 87.1%, 12.6×

   • Özet: 9–10× sıkıştırmada %96+, 10–12× aralığında ≈%90, 20× civarında ≈%60.
   → 10× civarı neredeyse kayıpsıza yakın; bunun ötesinde layout karmaşıklığı ve düşük çözünürlük bulanıklığı nedeniyle performans kademeli olarak düşüyor.

2. Gerçek belge ayrıştırma (OmniDocBench) — edit distance (düşük olması daha iyi)
   • Yalnızca 100 token (640²) ile GOT-OCR2.0'ı (256 token) geçiyor
   • 400 token (1280²) seviyesinde en güncel SOTA ile aynı düzeyde
   • Gundam (<800 token) modunda MinerU-2.0'dan (≈6,790 token) daha iyi performans
   → Token verimliliği çok yüksek (az sayıda görsel tokenla eşdeğer/üstün performans).

3. Nitel sonuçlar (özellikler)
   • Derin ayrıştırma:
   • Grafik → HTML tablo,
   • Kimyasal formül → SMILES,
   • Geometrik şekil → sözlük yapısı (doğru parçası/koordinat/tür vb.)
   • Doğal görüntülerde de temel soru-cevap mümkün
   • Çok dilli: yaklaşık 100 dilde PDF tanıma (layout'lı/layout'sız çıktı prompt ile kontrol edilebiliyor)

Anlamı
• LLM'lerde aşırı uzun bağlamın maliyet sorununa karşı, görsel token üzerinden sıkıştırmanın güçlü bir çözüm olduğunu deneysel olarak gösteriyor.
• Yakın dönem diyalog/bağlam için yüksek çözünürlük, eski geçmiş içinse kademeli küçültme (sıkıştırma oranı↑) uygulayan bir memory decay stratejisi öneriliyor → insanın unutma eğrisine benzer kaynak tahsisi.
• Token bütçesi optimizasyonu: görev/belge türüne göre gerekli token miktarı için kılavuz sağlanıyor (gazete gibi aşırı yoğun belgelerde Gundam/M modu öneriliyor).

Sınırlar ve gelecek çalışmalar
• Şimdilik OCR tabanlı bir PoC'e daha yakın; gerçek bir dijital↔optik↔dijital pipeline içindeki kayıp analizi için ek araştırma gerekiyor.
• 10× üzerindeki aralıkta görülen keskin performans düşüşünün nedenleri (karmaşık layout, düşük çözünürlük bulanıklığı) iyileştirilmeli.
• Format/benchmark uyumluluğu sorunları var (ör. Fox değerlendirme formatı farkı nedeniyle gerçek performans olduğundan düşük ölçülmüş olabilir).

Temel noktaların özeti
• DeepEncoder: pencere attention (düşük aktivasyon) → 16× conv sıkıştırma → global attention (CLIP)
• Çoklu çözünürlük + tile+global (Gundam) ile bellek/token tasarrufu ve performans dengesi
• ≈10× sıkıştırmada ~%96 geri yükleme doğruluğu → bağlam maliyetini keskin biçimde düşürmek için güçlü bir ipucu
• OmniDocBench: 100–800 görsel token düzeyinde SOTA'ya yakın/üstün
• Grafik/kimya/geometri/çok dilliliği kapsayan pratik kullanım alanı

[m00nlygreat]

Vay canına, inanılmazmış hahaha Ama sonuçta geri yükleyince yine aynı token olmuyor mu? Sadece depolanan durumdaki token’lardan tasarruf edilebiliyor, hepsi bu değil mi? Pek anlamıyorum da ağlayasım geldi. Bunu anlaşılır şekilde açıklayabilecek biri var mı?

[luminance]

DeepSeek fikri gerçekten çok iyi.

[xguru]

DeepSeek OCR - görsel bağlam sıkıştırmasıyla ultra verimli OCR modeli
GN+ tarafından özetlenen sürüme ve Hacker News yorumlarına da birlikte göz atın.