- "Metni görüntü olarak ifade ederseniz, aynı bilgiyi çok daha az token ile taşıyabilirsiniz" içgörüsünden yola çıkıyor
- Metin bilgisini 2D görsel gösterime sıkıştıran yeni bir yaklaşım öneren bu model, uzun bağlamı verimli biçimde işlemek için görme tabanlı sıkıştırma (Optical Compression) kavramını deneysel olarak doğruluyor
- Model, DeepEncoder (encoder) ve DeepSeek3B-MoE-A570M (decoder) bileşenlerinden oluşuyor; yüksek çözünürlüklü girdilerde bile düşük aktif bellek kullanımı ve 10~20 kat düzeyinde token sıkıştırma oranı sağlıyor
- 10 kat sıkıştırmada %97 OCR doğruluğu, 20 kat sıkıştırmada da %60'ın üzerinde doğruluk koruyor; bu da uzun metin bağlamı sıkıştırma ve bellek unutma mekanizmaları araştırmaları için pratik bir potansiyel sunuyor
- OmniDocBench'te GOT-OCR2.0'a (sayfa başına 256 token) kıyasla yalnızca 100 görsel token ile daha iyi performans, MinerU2.0'a (ortalama sayfa başına 6000+ token) kıyasla ise 800 token'ın altında üstün performans gösteriyor
- Tek bir A100-40G GPU ile günde 200 binden fazla sayfa veri üretimi mümkün; bu da onu LLM/VLM için büyük ölçekli eğitim veri motoru olarak oldukça değerli kılıyor
1. Araştırma arka planı
- Mevcut LLM'ler, dizi uzunluğu arttıkça hesaplama maliyetinin karesel olarak artması gibi yapısal bir sınıra sahip
- Makale, "Metni görüntü olarak ifade ederseniz, aynı bilgiyi çok daha az token ile taşıyabilirsiniz" içgörüsünden hareket ediyor
- Bunu görsel token tabanlı uzun bağlam sıkıştırması (Context Optical Compression) olarak tanımlıyor ve OCR'ı bunun deneysel sahnesi olarak konumluyor
- Sonuç olarak, görsel gösterimin LLM'lerin bağlam işleme verimliliğini iyileştirebilecek yeni bir yol sunduğunu gösteriyor
2. Model mimarisi
- DeepSeek-OCR = DeepEncoder + DeepSeek3B-MoE decoder
- DeepEncoder: SAM (Window Attention) + CLIP (Global Attention) + 16 kat token sıkıştırıcı
- DeepSeek3B-MoE: 64 uzmandan 6'sı etkin, toplam 570M aktif parametre
- Çoklu çözünürlük modu desteği (Tiny~Gundam)
- 512~1280 çözünürlük girdilerini destekliyor ve en fazla 9 tile'ı birleştirerek işleyebiliyor
- Gundam modu, gazete gibi ultra yüksek çözünürlüklü belgeleri hedefliyor ve en fazla 800 görsel token kullanıyor
3. Veri motoru
- Toplam 3 tür veri bileşimi:
- OCR 1.0 verisi: 30M sayfa (100 dil) belge tabanlı, ayrıntılı yerleşim ve metin açıklamaları içeriyor
- OCR 2.0 verisi: grafikler, kimyasal formüller (SMILES), geometrik şekiller gibi karmaşık tanıma görevleri için 16M veri
- Genel görsel veri: CLIP tabanlı görsel anlama yetisini korumak için toplamın %20'si
- Yalnızca metin verisi: dil yeteneklerini desteklemek için %10 pay
- Toplam eğitim veri oranı
- OCR %70 / görsel %20 / metin %10
4. Eğitim hattı
- Eğitim iki aşamada yapılıyor: DeepEncoder → DeepSeek-OCR
- Toplam 20 düğümde (8×A100 GPU) veri paralelliği DP=40, global batch 640
- Eğitim hızı: metin verisinde günde 90B token, çok modlu veride günde 70B token
5. Değerlendirme sonuçları
(1) Sıkıştırma deneyi (Fox benchmark)
- 10 kat sıkıştırmada %97 doğruluk, 20 kat sıkıştırmada bile %60'ın üzerinde koruma
- Belge uzadıkça veya karmaşıklaştıkça performans düşüşü görülüyor; ancak bu, "unutma mekanizması" simülasyonu olasılığı olarak yorumlanıyor
- 10× ve altındaki sıkıştırma oranlarında neredeyse kayıpsız bağlam geri kazanımı mümkün
(2) Gerçek belge tanıma (OmniDocBench)
- Tiny (64 token) ~ Gundam (800 token) modları karşılaştırıldı
- GOT-OCR2.0'a (256 token) kıyasla Small (100 token) modunda daha iyi
- MinerU2.0'a (7.000 token) kıyasla Gundam (800 token) ile daha yüksek performans
- Gerekli token sayısı belge türüne göre değişiyor
- Sunumlar, raporlar: 64~100 token yeterli
- Gazeteler, akademik makaleler: 400~800 token gerekli
6. Nitel analiz (Qualitative Study)
- Deep Parsing modu
- Grafikler, şekiller, kimyasal formüller ve doğal görüntüler için tek bir prompt ile yapısal çıkarım yapılabiliyor
- Çok dilli tanıma
- Yaklaşık 100 dilde PDF desteği, Arapça ve Sinhala gibi az kullanılan diller dahil
- Genel görsel anlama
- Görüntü açıklama, nesne tespiti ve grounding yapabiliyor
- LLM ile birlikte kullanıldığında görsel-dil birleşik akıl yürütme için temel model olarak değerlendirilebilir
7. Tartışma ve çıkarımlar
- DeepSeek-OCR, görsel token tabanlı uzun bağlam sıkıştırmasının sınırlarını araştıran ilk deney olarak,
"Bir görüntü bin kelime taşır" fikrini nicel hale getiriyor
- 10× sıkıştırmada bile neredeyse kayıpsız geri kazanım mümkün → sohbet geçmişi sıkıştırma, uzun süreli bellek optimizasyonu gibi alanlara genişletilebilir
- "Zaman geçtikçe görüntü çözünürlüğünü düşürme" yaklaşımıyla biyolojik unutma eğrisine benzer token zayıflaması simülasyonu öneriliyor
8. Sonuç
- DeepSeek-OCR, metin-görsel arasında 10~20 kat sıkıştırma eşlemesini deneysel olarak gösteren bir model olarak,
LLM'lerin uzun bağlam işleme sınırlarını aşmak için yeni bir paradigma sunuyor
- OCR'ın ötesinde, gelecekte dijital-optik hibrit pretraining ve
'Optical Context Memory' tabanlı ultra uzun bağlam modellerine genişlemesi bekleniyor
- Kod açık durumda ve hem araştırma hem de ticari veri motoru olarak kullanılabiliyor
- DeepSeek-OCR, mevcut açık kaynak OCR projelerine kıyasla, görsel bilgiyi etkili biçimde encode eden büyük dil modeli (LLM) tabanlı yapısıyla öne çıkıyor
- Çeşitli çözünürlük desteği (512×512~1280×1280) ve dinamik çözünürlük için Gundam modu sayesinde farklı ortamlara güçlü uyum sağlıyor
- Net prompt tasarımı ile genel görüntü açıklama, Markdown dönüşümü, yerleşimi yok sayan OCR, tablo ayrıştırma gibi çeşitli çalışma modlarını destekliyor
- Fox, OminiDocBench gibi sektör benchmark'larıyla performansı doğrulanmış, gerçek belge işleme deneyleriyle test edilmiş
- GOT-OCR2.0, PaddleOCR gibi diğer popüler projelerin güçlü yönleri ve fikirleri de uygulanarak sisteme dahil edilmiş
- Desteklenen çözünürlükler
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): serbest çözünürlük (n×640×640 + 1×1024×1024)
- PDF ve görüntüler için paralel inference ve yüksek işleme hızı
- A100 GPU'da PDF işleme hızının ~2.500 token/s düzeyine çıkabildiği belirtiliyor
- Teknik arka plan ve ekosistem bağlantıları
- %100 Python ile uygulanmış
- vLLM ve Transformers olmak üzere iki ana inference ortamını da destekliyor
- OpenChart, Fox, OminiDocBench gibi başlıca benchmark ve değerlendirme framework'lerinden yararlanıyor
- GOT-OCR2.0, PaddleOCR, Vary gibi önceki modellerle entegrasyon, fikir devralma ve performans güçlendirme sağlanmış
1 yorum
Hacker News yorumu
Bu makale, yalnızca OCR için bir başka VLM olmanın ötesine geçip sıkıştırma gibi daha ilginç konulara uzanıyor
Örneğin şu alıntı var: "Görsel-metin sıkıştırmasının sınırlarını keşfetmek için öncü bir çalışma yürüttük; metin tokenlarını çözmek için kaç görsel token gerektiğini inceledik. Ön sonuçlara göre DeepSeek-OCR, yaklaşık 10x oranında neredeyse kayıpsız OCR sıkıştırması sağladı ve 20x sıkıştırmada bile %60 doğruluğu korudu"
Sezgisel olarak bu, bir görsel tokenın 10 metin tokenı kadar bilgi taşıdığı anlamına geliyor
Bunun neden böyle çıktığını, bilgi kuramı açısından yeni başlayanların anlayabileceği şekilde açıklayabilecek biri var mı?
Acaba bunun nedeni metin tokenlarının hâlâ fazla parçalı olması mı (ya da fazlalık içermesi ve entropi kodlamasına yeterince yaklaşamaması mı), yoksa görsel token yaklaşımına geçince “kelime birimi” sınırını aşıp entropiye daha çok yaklaşabilmek mi söz konusu (aritmetik kodlama ile Huffman kodları arasındaki fark gibi)?
Makalede ayrıca büyük bağlamlarla çalışırken görüntülerin gerçekten downscale edilmesinden ve metin alanındaki bilgi kaybıyla görüntü alanındaki bilgi kaybı arasındaki eşleşmeden de söz ediliyor
Metin tokenları nicemlenmiş alt birimlerdir (subword), görsel tokenlar ise yalnızca embedding uzayında bulunur
LLM’lerde metin tokenizasyonu, (küçük) token ID’leri ile (büyük) vektör embedding’lerinden oluşan bir lookup table yapısıdır
Metni LLM’e verirken önce dize token sınırlarından bölünür, token ID’lerine dönüştürülür, sonra lookup table’dan vektörler çekilip bir matris (context matrix) oluşturulur
Gerçek metin token dizisini iletmek verimlidir; çünkü yalnızca bir sayı dizisi (ID’ler) göndermeniz yeterlidir (genelde yaklaşık 100 bin benzersiz token ID’si)
Buna karşılık embedding matrisinin kendisini iletmek verimsizdir; çünkü embedding’ler binlerce float sayıdan oluşur
Görseller farklı biçimde kodlanır. Görüntü verisi ön işlenir ve doğrudan sinir ağı tabanlı bir görüntü kodlayıcısına verilerek vektörlere dönüştürülür; bu vektörler de bağlama eklenir
Yani görüntü tokenlarında token ID de yoktur, lookup table da yoktur; veriden doğrudan embedding’e geçilir
Sonuç olarak görüntü tokenlarını iletmek için embedding’in kendisini göndermek gerekir ve bu verimsizdir
Görüntü daha az tokenla kodlansa bile her tokenın kapasitesi çok daha büyüktür
Özetle, metin tokenları tam olarak vektörlere eşlenen tamsayılardır (0~n), dolayısıyla ‘n’ adet seçenek vardır
Görüntü tokenları ise m boyutlu float dizileridir (vektörler), bu yüzden token uzayı çok daha büyüktür
Desenler açısından da metin tokenları ardışık UTF-8 baytlarına doğrudan karşılık gelir ve çoğu zaman kelime sınırlarının ötesine geçmez; bu yüzden küresel desenler (“bu replik Hamlet’ten”, “bu bölüm İspanyolca” gibi) tek bir tokenla ifade edilemez
Çok kipli LLM’lerde görüntü girdisinin nasıl embedding’e dönüştürüldüğünü tam olarak bilmiyorum ama temelde görüntünün bir ızgaraya bölünüp her bölgenin kodlandığını anlıyorum
DeepSeek’in deneylerinde bilgi kuramsal bir özellikten çok, çözünürlüğü ne kadar düşürebileceğiniz ya da ızgara (patch) boyutunu ne kadar küçültebileceğiniz ve buna rağmen doğru OCR için yeterli ayrıntıyı hâlâ koruyup koruyamadığınız belirleyici gibi görünüyor
Keşke Karpathy, NanoChat’i multimodal hâle getirip bu tür kodlama süreci bilgilerini paylaşsa
Uygun sıkıştırma oranı sonuçta bir karakterin çözünürlüğü ile her görsel token patch’inin göreli boyutuna bağlı olmak zorunda
Ancak bu şekilde OCR ile çıkarılan metin tokenlarının sayısı görüntü çözünürlüğünden bağımsız kalabilir
Her metin tokenı çoğunlukla subword düzeyindeyken, VLM’nin görsel tokenları anlamsal uzayda (semantic space) yer alır
Anlamsal uzay, subword bölmeye kıyasla bilgiyi çok daha güçlü biçimde sıkıştırabilir
Not: Uzman değilim, aklıma geleni yazdım
LLM’lerde hesaplama maliyeti token sayısına göre karesel artar
Bu yüzden VLM’lerde metin tokenlarını görsel tokenlara sıkıştırmaya çalışıyorlar
Muhtemelen metni önce görüntü olarak render edip sonra tokenize ederek hesaplama maliyetini düşürmeyi deniyorlar
NVIDIA Spark’ta (ARM64) PyTorch biraz uğraştırıcıydı ama Claude Code’u root yetkisiyle yeni bir Docker konteynerinde çalıştırınca bunu çalıştırabildim
Ayrıntılı notlar burada
Gerçek çıktıyı bu bağlantıda görebilirsiniz; test için OCR görselinin aslı da burada
OCR çıktısı genel olarak oldukça sağlam
Ama alıntının hemen altındaki paragrafta gereksiz şeyler ekleyerek halüsinasyon üretmiş ve bunu bir sonraki sütunla birleştirmiş
Hızlı testi yaptığın için teşekkürler
Metnin başındaki "A" harfini kaçırmasını anlayabiliyorum (muhtemelen veri kümesinde haber makaleleri çok fazla değildi)
Ama "Hallucination is a risk and..." kısmının tamamını, yazarın yanındaki konu başlığını ("theme") ve en sondaki e-posta bölümünü de tamamen atlaması daha ilginç geldi
Bu deney tek başına ayrı bir gönderi olmayı hak ediyor bence
"Claude Code’u yeni bir Docker konteynerinde root olarak çalıştırmak"
Bunu root yetkisiyle çalıştıracak şekilde tam olarak nasıl ayarladığını merak ediyorum
(Eğer açıklanmışsa yazının içinde bakarım)
Makalede Anna’s Archive’tan hiç söz edilmiyor
DeepSeek’in, OCR araştırmacılarına 7,5 milyon kitaplık (350 TB) Çince kurgu dışı koleksiyon erişimi sağlama yönündeki Anna teklifini gerçekten kullanmış olabileceğini düşünüyorum
Bu hacim Library Genesis’ten bile büyük
İlgili blog yazısı
DeepSeek’in önceki makalelerinde Anna’s Archive doğrudan anılıyor
"Anna’s Archive’tan 860 bin İngilizce, 180 bin Çince e-kitap ve K-12 eğitim sınav sorularından milyonlarcası ayıklandı"
Bkz. DeepSeek-VL makalesi
Başkalarının kitaplarını barındırıyor diye neden özellikle erişim izni almak gereksin ki diye düşünüyorum
Benim de aklıma hemen Anna’s Archive geldi; OCR ile işlenmiş veri kümesinin ne zaman yayınlanacağını merak ediyorum
Bu aynı zamanda veri kümesinin hiç yayınlanmayacağı anlamına da gelebilir
Böyle giderse Anna’s Archive da sonunda LLM şirketleri tarafından kötüye kullanılıp yok mu olacak diye endişeleniyorum
META’nın Library Genesis’ten 70 TB veriyi torrent ile çekmiş olması yetmiyormuş gibi
Mevcut ve farklı benchmark’ların gerçek düzeyiyle ilgili deneyim paylaşımı
OmniAI benchmark’ı pek iyi değil
Onun yerine OmniDocBench öneririm
Mistral OCR, açık kaynak OCR modellerine ve Gemini’ye kıyasla belirgin şekilde geride
Uçtan uca OCR hâlâ çok zor
Pipeline yaklaşımı (yerleşim algılama → okuma sırası belirleme → her öğe için OCR) daha iyi çalışıyor
Karmaşık tablo ayrıştırma hâlâ büyük bir sorun
Apple Vision Framework’ün de bu modellerle benchmark karşılaştırmalarını merak ediyorum
Neredeyse tüm Apple cihazlarında yerleşik geliyor ve pratikte yüksek kaliteli, hızlı OCR veriyor (özellikle PDF dönüştürmede) ama insanların bundan pek haberi yok gibi
Benchmark’larda nereye düştüğünü gerçekten merak ediyorum
OmniAI benchmark’ına göre en iyi performansı Omni OCR gösteriyor
İnsanların bu tür sonuçları hiç sorgulamaması muhtemel
LLM tabanlı OCR’ın Azure AI Document Intelligence(bağlantı), Google Vision API(bağlantı) gibi servislerle karşılaştırıldığında ne gibi avantajları ve farkları olduğunu merak ediyorum
OmniAI’da kendi LLM’lerini ve bulut OCR’ı karşılaştırmalı benchmark’a sokuyorlar
OmniAI blog benchmark’ı (Şubat 2025 itibarıyla)
O tarihten sonra LLM’ler çok hızlı gelişti
Son dönemde en iyi sonuçlar Qwen3-VL ailesinden, özellikle Qwen3-VL-235B-A22B-Instruct’tan geliyor
Benim tahminim, ticari/kapalı OCR modelleri gerçek belgelerde üstünlüğünü koruyacaktır
Çünkü ellerinde çok sayıda kaliteli özel eğitim veri kümesi var
Kamusal LLM’ler arXiv, e-kitap vb. akademik odaklı verilerle eğitildiği için gerçek iş belgelerinde geri kalmaları kaçınılmaz
LLM yaklaşımı karakter ikame hatalarını (yazım hataları, varyasyonlar) azaltıyor ama tüm sayfa düzeyindeki tutarlılık bazen daha da kötü olabiliyor
OCR olmayan LLM’ler gibi tamamen alakasız şeyler de üretebiliyor
CJK karakterlerinde geleneksel OCR hâlâ çok sayıda uygunsuz ikame üretiyor
Birbirine çok benzeyen çok fazla karakter var; bazıları ancak mikroskop düzeyinde ya da ikili seviyede ayırt edilebiliyor
LLM’ler olası karakter dizilerine daha fazla kısıt getirdiği için daha doğru sonuçlar beklenebilir
En azından bu kaygı bile LLM tabanlı OCR’a yönelmek için bir motivasyon yaratıyor
Diğer modelleri bilmiyorum ama bizim şirket özgeçmiş ayrıştırma sistemini Azure AI Document Intelligence ile çalıştırıyor ve oldukça memnunuz
Başta biraz ayar yapmak gerekiyor, sonra son 1 yıldır neredeyse hiç dokunmadık
Birçok VLM’i denedim (Granite, Qwen gibi küçük modellerden büyük modellere kadar) ve klasik OCR’ın tam yerine geçme konusunda hayal kırıklığı yarattıkları sonucuna vardım
Bizim sistem müşterilerden belgeler alıyor ve istenildiği şekilde işaretlenmiş standart belgeler döndürüyor (raster tarzı çok sayfalı bitmap’ler)
Bizim için veriden tekil karakter veya kelime düzeyine kadar koordinat çıkarma hassasiyeti önemli; fakat VLM’lerin konum bilgisi pratikte aşırı tutarsız, tamamen uydurma (hallucinated) ya da istenen doğruluk/ayrıntı düzeyini garanti edemeyecek kadar belirsiz oluyor
Şimdilik Tesseract tabanlı çözüme ve sonuç temizleme rutinlerine devam ediyoruz; yalnızca yapılandırılmış veri kümesi olmadığında bazen VLM’nin metin çıktısını yardımcı olarak kullanıyoruz
Bizim kullanım durumu çok niş olabilir; çoğu insan için yalnızca metin dökümü ya da Markdown/HTML dönüşümü yeterliyse sorun olmayacaktır
Ama bu modellerin “OCR’ı tamamen çözdüğü” iddialarıyla gerçek deneyim arasında bence ciddi bir fark var
moondream 3 preview modelini denemeyi öneririm
Blog yazısına göre birçok VLM’in performansını geçiyor ve hafif bir model
Bkz. ana sayfa, model, blog
Müşteri belgelerinde el yazısı metin olmuyor mu diye merak ettim
Önce CNN ile metin bounding box’larını bulup sonra her kutu için ayrı ayrı VLM çalıştırmak da mümkün olabilir
Benim kişisel izlenimim OCR’ın büyük ölçüde çözülmüş bir problem olduğu yönünde
OmniAI benchmark’ı da en yeni modellerle güncellenmedi; bence bunun nedeni genel amaçlı LLM’lerin ilgili benchmark’taki özel OCR’dan daha iyi hâle gelmiş olması
Gerçekten de her sayfa görselini Gemini 2.5 Flash Lite’a verip Markdown olarak çıkarmasını istediğimde, yaklaşık 1000 sayfa başına 20 sent maliyetle oldukça iyi sonuçlar aldım
Bugünlerde OCR’ın zor tarafı tam olarak ne?
Çoğu OCR/LLM (özellikle Gemini Pro 2.5 bile) karmaşık tabloları Markdown/HTML’e dönüştürmede hâlâ zorlanıyor
Çoklu başlıklar, birleşik hücreler, onay kutusu içeren sütunlar gibi sorunlar sık çıkıyor; birden fazla sayfaya yayılan tabloları da düzgün anlayamıyorlar
Llamaindex de aynı şekilde çok kötü başarısız oluyor
Bu tür sorunlarda hangi OCR/LLM’in daha iyi olduğunu merak ediyorum
Örnek karmaşık tablo,
Tam ICAO kontrol listesi örneği
Aslında mesele OCR değil, HTR (el yazısı transkripsiyonu/tanıma) hâlâ zor
LLM’ler sayesinde doğruluk çok arttı ama hataları insanların yakalaması da çok zorlaştı (okuyamadığı yeri tamamen uyduruyor)
Tanıyamadığı kısım için “bilmiyorum” demeyip onun yerine kafasına göre bir şeyler doldurmasını kabul ediyorsanız, evet çözülmüş sayılır
(Bunu alay etmek için söylemiyorum; bazı durumlarda gerçekten kabul edilebilir)
OmniAI benchmark’ının yazarı benim
Yeni modellerle güncellenmemesinin nedeni, ürün tarafında OCR API’sini küçültmüş olmamız
İçeride hâlâ kullanıyoruz ama benchmark’ı güncellemeye üşendik
Gemini OCR konusunda en iyisi
Ancak eğitim verisine fazla benzeyen sonuçlarda çıktının yaklaşık %10’unda bir anda kesilme yaratan ‘recitation’ hatası sık oluyor
PDF karışımlarında boş sayfa girerse komik halüsinasyonlarla bambaşka içerikler de uydurabiliyor
OpenAI da kötü değil ama GPT5’in GPT-4o ya da 4.1’e karşı belirgin bir üstünlüğü yok
Header/footer gibi bazı içerikler sık sık kayboluyor ve sayfa yana dönükse model tamamen saçmalayabiliyor
Kimlikler, tıbbi belgeler, PII riski yüksek içerikler gibi şeyleri kendi kendine reddetmesi de sık görülüyor
Bunun kesinlikle çözülmüş bir problem olduğunu düşünmüyorum
Alışılmadık yerleşime sahip dergileri OCR’dan geçirmeyi deneyin; imkânsız oluyor
Eski dergiler biriktiriyorum ve sürekli en yeni teknolojiyle OCR deniyorum ama sonuç her zaman çok ciddi insan emeği gerektiriyor
Daha küçük bir ‘OCR modeli’ var mı diye merak ediyorum
Üretim sahasındaki fotoğraflardan yalnızca seri numaralarını çıkarmam gerekiyor; tüm belgeyi ayrıştırmama gerek yok
3 milyar parametreli bir modeli bunun için kullanmak fazla ağır kaçıyor
DeepSeek-OCR’ın Tesseract(bağlantı) ile karşılaştırıldığında nasıl olduğunu merak ediyorum
Ben
ocrmypdf(bağlantı) kullanmayı seviyorum ve yerelde bana çok iyi hizmet ediyorGerçekte Tesseract %80 iş görüyorsa ve yeni model %95’e çıkıyorsa bile
bunun karşılığında 100 kat disk, Kubernetes/Docker, GPU üzerinde 16 GB VRAM gibi altyapı gereksinimleri geliyorsa, bunu ayrıca değerlendirmek gerekir
En güncel araştırmaları takip etmeyen biri olarak bunun ne olduğunu ve neden önemli olduğunu ELI5 (5 yaşındaki bir çocuğa anlatır gibi) düzeyinde açıklayabilecek biri var mı?
GitHub’da ya da makale başlığında OCR yazıyor ama özet ve readme.md bağlam sıkıştırmasından söz ediyor; bu yüzden kafam karıştı
Bu ikisinin nasıl bağlandığını, daha üst düzey bağlamda açıklayabilecek birini arıyorum
Görüntü “1000 token”lık bilgi taşıyor demektir
Gerçekte görüntüyü feature/embedding’e dönüştürmeniz gerekir (decode etmeniz gerekir)
Eğer görüntü 100 “görüntü tokenı” olarak işleniyor ve bu görüntü tokenları 1000 “metin tokenı”na dönüştürülüyorsa
sırf decode açısından bakıldığında, çıktıyı 10 kat sıkıştırılmış biçimde iletmiş oluyorsunuz
LLM açısından bu, eğer 10 kat daha küçük bir latent gösterimle önceden sıkıştırma yapabiliyorsanız, 1000 token/embedding olmadan da aynı ya da daha iyi sonucu üretebileceğiniz anlamına gelir