21 Çok Modlu Modeller

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 21. bölüm. Ölçümler yerel bir GPU’da ollama 0.24.0 üzerinden gemma3:27b kullanıyor ve sayfalar WMT16/17/18 tr-en test kümelerinden Pillow 12.3.0 ile üretildi — Bölüm 15 ve Bölüm 16’nın kullandığı hizalı derlemin aynısı; böylece Türkçe ve İngilizce sayfalar aynı şeyi söylüyor ve aralarındaki bir fark içerik farkı olamaz. Puanlama Python 3.14.5 üzerinde NumPy 2.5.2 ile yapıldı.

Öğrenme hedefleri. Bu bölümün sonunda:

bir görüntünün nasıl token’a dönüştüğünü açıklayabilir ve bunun faturalandığınız birimlerde neye mal olduğunu söyleyebilirsiniz;
karşıtsal görme-dil ön eğitimini ve neyi kazandırdığını tarif edebilirsiniz (Radford vd. 2021);
bir görme-dil modelinin (vision-language model, VLM) belgelerde nerede bozulacağını ve çözünürlüğün neden buna karar veren değişken olduğunu öngörebilirsiniz;
bir modelin görüntüyü okumasıyla makul cevap vermesini ayıran kontrolü tasarlayabilirsiniz;
bir belge görevi için VLM’in mi yoksa özel bir optik karakter tanıma (OCR) hattının mı doğru araç olduğuna karar verebilirsiniz.

Kapsam, belge görüntüleri ve görme-dil modelleri; ses ve video bu bölümün dışında. Video için tek bir not: çoğu VLM videoyu belli bir hızda örneklenmiş kareler dizisi olarak okur ve her kare bir görüntü gibi token’a dönüşür; dolayısıyla maliyet, örneklenen kare sayısıyla, yani süre ve örnekleme hızıyla büyür. Konuşma için de kısa bir not, çünkü aynı kalıbı izliyor: Whisper gibi bir konuşma tanıyıcı sesi bir spektrograma (her an hangi frekansların güçlü olduğunu gösteren, her 10 ms’de bir sütun eklenen bir resim) çevirir ve bunu bir transformer encoder’a (kodlayıcı) verir; ardından bir decoder (kod çözücü) transkripti yazar. Ses 30 saniyelik pencerelerle işlenir, kısa kalanlar dolgu (padding) ile tamamlanır; dolayısıyla encoder her pencere için hep 1.500 vektör üretir — aşağıdaki görüntü kodlayıcıdaki sabit bütçeyle aynı fikir.

21.1 Bir görüntü sabit sayıda token’dır

Bir transformer bir vektör dizisi alır. Bölüm 7 o vektörlerin nereden geldiğiyle hiç ilgilenmedi; işin bütün püf noktası da bu. Bir görüntüyü yamalara (patch; görüntünün küçük kare parçaları) bölün. Her yamayı modelin hidden size’ına (içeride kullandığı vektör boyutuna) izdüşürün (yama gömmesi). Böylece aynı makinenin okuyabileceği bir diziniz olur (Dosovitskiy vd. 2021). O makalenin modeli Vision Transformer (ViT), bu bölümdeki görme kodlayıcıların şablonudur. Her yamaya ayrıca, Bölüm 7’deki kelimelerde olduğu gibi bir konum embedding’i (konum gömmesi) eklenir; böylece model bir yamanın görüntünün neresinden geldiğini bilir.

patch embedding (yama gömmesi) — bir görüntünün sabit karelere bölünüp her birinin modelin hidden size’ına (iç vektör boyutuna) izdüşürülmesi; böylece bir resim, bir transformer’ın metnin yanında okuyabileceği bir vektör dizisine dönüşür. ↩︎

Metin token’ları ve görüntü yamaları tek bir akışta durur ve attention (dikkat mekanizması) ikisinin üzerinde de çalışır. Olağan nedensel maske yine geçerlidir: bir metin token’ı kendinden önceki her görüntü vektörüne dikkat edebilir, ama bir görüntü vektörü sonra gelen metne ileriye doğru bakamaz. (Bu bölümün modeli olan Gemma 3 ayrıca, aynı görüntüye ait vektörlerin birbirine iki yönde de dikkat etmesine izin verir.)

Bir sayfa soruyla aynı diziye nasıl katılır

Bu tasarımda decoder’ın içinde ayrı bir cross-attention (çapraz dikkat) yolu yok — Bölüm 21.2 alternatifi anlatıyor: orada donmuş bir dil modeli görüntüye cross-attention ile bakıyor. Yamalar vektöre, soru vektöre dönüşüyor ve tek bir dizi aynı yığına giriyor — metin okuyabilen bir modele mimarisi değiştirilmeden sayfa okumanın öğretilebilmesinin nedeni bu.

Çoğu kişinin gözden kaçırdığı sonuç, bunun faturanıza etkisidir ve bu etki tek satırda ölçülebilir. Bu bölümün transkripsiyon deneyindeki her görüntü — toplam 320 (40 cümle × 4 punto × 2 dil) — aynı 290 prompt token’ına mal oldu. (Bu bölümde “punto”, piksel cinsinden yazı boyutu demek.) Aşağıdaki çıktıda sütunlar sırasıyla punto (px), prompt token sayısı ve sayfanın bu boyutta alabileceği satır sayısı:

  font size  prompt tokens   lines the page can hold at this size
       34 px           290   ~5, comfortable
       22 px           290   ~7
       15 px           290   ~10
       11 px           290   ~14, tight

Bu çözünürlük merdivenindeki (aynı içeriğin dört farklı boyutta üretildiği basamaklar) her sayfa aynı cümleyi taşıyor; son sütun sayfanın içeriği değil kapasitesi. İçeriği sabit tutmak tasarımın amacı; böylece değişen tek şey her karakterin kaç kodlayıcı pikseli aldığı.

Bu bölümde iki token sayısı geçiyor ve farklı şeyleri ölçüyorlar.

290, sunucunun transkripsiyon sayfaları için raporladığı hâliyle prompt’un tamamı — görüntü artı talimat.
260 ise aşağıdaki metin–görüntü karşılaştırmasında görüntünün eklediği miktar. Orada talimat iki kolda da aynı olduğu için sadeleşiyor.

Bu bölüm “görüntü olarak 260” dediğinde, resmi eklemenin bu marjinal maliyetini kastediyor. Sayı, Gemma 3’ün yayımlanmış prompt biçimiyle örtüşüyor: 256 görüntü vektörü artı çevrelerindeki dört işaret token’ı (ayraçlar — birer satır sonuyla birlikte bir görüntü-başı ve bir görüntü-sonu token’ı). Her sayı, kendi ölçümünün raporladığı değerdir.

290’ı parçalardan yeniden kurmaya çalışmayın: 260 artı 34 token’lık talimat 290 değil 294 eder. İki ölçüm ayraçları ya da talimatı farklı sayıyor ve bu koşu hangisi olduğunu söyleyecek ham tokenizer çıktısını saklamadı.

Bu model için bir görüntü sabit ücretlidir. Görme kodlayıcı her görüntüyü 896×896 piksele yeniden boyutlandırıp 14×14 piksellik yamalara kesiyor: kenar başına 896 / 14 = 64 yama, yani 64 × 64 = 4.096 yama. Ardından her 4×4’lük yama bloğu üzerinde ortalama havuzlama (average pooling) bu 64×64 ızgarayı 16×16 = 256 vektöre indiriyor. Bunlar soft token’lar (sözlükten gelmeyen, sürekli değerli girdi vektörleri): dil modeline doğrudan veriliyorlar, ama dizide yer kaplıyor ve token gibi ücretlendiriliyorlar. Dolayısıyla sayfa ister bir cümle ister bir hesap tablosu tutsun ödediğiniz şey 256 görüntü token’ı artı prompt — yeter ki görüntü kabaca kare biçimli olsun ve modelin kırp-ve-döşe yolu (Gemma 3 raporunda Pan & Scan; yalnızca çıkarım anında çalışan, kapatılabilen bir seçenek) devreye girmesin. Bu koşuda devrede değildi — bütün görüntüler aynı token sayısına mal oldu. Kırpımlara bölünen geniş bir ekran görüntüsü her kırpımı kodlayıcıdan ayrı geçirir ve bunun birkaç katı tutar.

Sabit ücreti genelleştirmeyin. Bu, görme-dil modellerinin değil tek bir kodlayıcı tasarımının özelliği. 2025–2026’nın hâkim aileleri tersini yapıyor: dinamik çözünürlüklü kodlayıcılar doğal çözünürlüklü bir görüntüyü değişken uzunlukta bir token dizisine eşliyor, döşemeli tasarımlar ise sayfayı sabit kırpımlara bölüp kırpım sayısını girdiyle ölçekliyor; yani görüntü maliyeti megapikselle büyüyor ve bütçeleme dersi tersine dönüyor. Örneğin Qwen2.5-VL’de her görüntü token’ı kabaca 28×28 piksellik bir alana karşılık gelir: 896×896’lık bir görüntü (896 / 28)² = 1.024 token tutarken 1.792×896’lık bir sayfa iki katını, 2.048 token’ı tutar (ayraç token’ları hariç). InternVL ve LLaVA-NeXT gibi döşemeli modeller ise sayfayı sabit boyutlu kırpımlara bölüp her kırpım için ayrıca ödeme yaptırır. Bütçenizi bu iki davranıştan birine göre planlamadan önce kendi modelinizi tek bir görüntüyle iki çözünürlükte ölçün.

Bundan iki şey çıkıyor; ikincisi bölümün geri kalanının habercisi.

Pikseller metin göndermenin pahalı bir yoludur. Aynı cümleler iki biçimde de gönderilerek ölçüldü. Sütunlar: karakter sayısı, metin olarak token, görüntü olarak token ve görüntünün metne göre primi (kat):

                chars   as text   as image   premium
  English         222      46.6        260     5.57x
  Turkish         233      62.4        260     4.17x

Metin zaten elinizdeyse onu fotoğraflamak aynı içerik için dört ila beş kat pahalıya gelir — zaten ayrıştırdığı bir sayfanın ekran görüntüsünü alan her hattın ödediği bir prim.

Yine de iki satıra birlikte bakın, çünkü daha az bariz bir şey söylüyorlar. Görüntü ücreti sabit, dolayısıyla prim Türkçe için daha küçük — pikseller orada daha ucuz olduğu için değil, Bölüm 16’nın tokenizer cezası metni pahalılaştırdığı için: aynı cümle için İngilizcenin 46,6’sına karşı 62,4 token; o bölümün eşleştirilmiş içerik için tahmin ettiği 1,2–1,6 kat aralığına düşen 1,34 katlık bir oran.

Sabit ücretli bir kodlayıcı, sondan eklemeli bir dilin token vergisini kısmen emiyor. Bu düşünceyi Bölüm 21.3’e kadar aklınızda tutun; orada onu toplamak için neyden vazgeçtiğiniz ölçülüyor.

Küçük punto, karakter başına daha az kodlayıcı pikseli demek. Merdivenin dört basamağında da sayfa içeriği aynı — aynı cümle, yalnızca daha küçük çizilmiş — yani sayfadaki bilgi hakkında hiçbir şey değişmiyor. Değişen şey örnekleme. Kodlayıcı her sayfayı 896×896’ya yeniden boyutlandırıp yamalara kesiyor ve belli bir glif yüksekliğinin altında bir karakter, komşularından ayırt edilmeye yetecek pikselle o yeniden boyutlandırmadan sağ çıkmıyor. Yani transkripsiyon doğruluğu puntoyla düşüyorsa bu, modelin kafasının karışması değil; tuval boyutunuzdan ve kodlayıcının giriş çözünürlüğünden önceden hesaplayabileceğiniz bir örnekleme sınırıdır. Bir örnek: 1.792 piksel genişliğindeki bir sayfa 896’ya sığmak için yarıya küçültülür; dolayısıyla 11 piksellik yazı kodlayıcıya yaklaşık 5,5 piksel yüksekliğinde ulaşır — tek bir 14 piksellik yamanın yarısından da az.

Sabit token bütçesi bunu ikinci ve ayrı bir biçimde kötüleştiriyor: kodlayıcı ne olursa olsun görüntü başına hep 256 vektör ürettiği için, tek bir görüntünün içinden daha fazla ayrıntı isteyemezsiniz. Elinizdeki seçenekler şunlar: sayfayı parçalara kırpıp her parçayı ayrı bir görüntü olarak göndermek (her biri için 256 vektör ödeyerek) ya da sayfayı daha büyük boyutta üretmek (render) veya taramak — bölümün geri kalanının dönüp dolaşıp vardığı çözüm.

Neye bakacağız. Önce hizalamanın nereden geldiğine bakacağız: iki uzayı birbiriyle uyumlu hâle getiren bir şey olmadıkça, izdüşürülmüş bir yama dil modeline hiçbir şey ifade etmez. Yol üstünde, sabit boyutlu ve havuzlanmış çıktısıyla görüntü maliyetini sabit kılan kodlayıcı türüyle de tanışacağız. Sonra bölümün asıl deneyi geliyor: aynı cümleler iki dilde, dört puntoda üretiliyor. Bu deney o darboğazı bir eşiğe dönüştürüyor ve Türkçe için eşiği İngilizceden farklı bir yere koyuyor. Ardından modelin görüntüyü gerçekten okuyup okumadığını soran bir kontrol geliyor. Bu kontrolün cevabı, bölümün kapandığı pratik soruyu — görme-dil modeli mi yoksa bir OCR motoru mu istediğinizi — çözecek kadar net.

21.2 Hizalama nereden geliyor

Yamalar size bir dizi verir. Vektörleri bir dil modeli için bir şey ifade eden bir dizi vermez — izdüşürülmüş bir yama, yeni bir tabanda ifade edilmiş piksellerden ibarettir. İki uzayı birbiriyle uyumlu hâle getirecek bir şey gerekir; bunu sağlayan ve sonraki her şeyi mümkün kılan cevap karşıtsal ön eğitim oldu.

CLIP (Radford vd. 2021), karşıtsal ön eğitimin kanonik örneğidir ve fikir tek cümleye sığar: caption’larıyla (resim altı yazılarıyla, yani görüntüyü betimleyen kısa açıklama metinleriyle) birlikte büyük bir görüntü koleksiyonu alın, her görüntüyü ve her caption’ı kodlayın ve eşleşen çiftler birbirine yakın, eşleşmeyenler uzağa düşecek şekilde eğitin. Görüntüde ne olduğunu kimse etiketlemiyor. Denetim sinyali caption’ın kendisi ve internet iki yarıyı da bedavaya sağlıyor.

contrastive pretraining (karşıtsal ön eğitim) — bir görüntü kodlayıcıyla bir metin kodlayıcıyı, bir resim ve caption’ı tek bir uzayda birbirine yakın, eşleşmeyen çiftler uzağa düşecek şekilde birlikte eğitmek. Denetimi caption’lar sağladığı için kimsenin bir şey etiketlemesi gerekmez. ↩︎

Bu, Bölüm 8’in metin için anlattığı pazarlığın aynısı: caption’lar zaten ortalıkta duruyordu; püf nokta, bu kendiliğinden oluşmuş metnin denetim sinyali olarak kullanılabileceğini fark etmekti. Bu kitaptaki her ölçekleme hikâyesi bu kalıba uyar.

“Yakın” ve “uzak” nasıl bir kayba dönüşür. N görüntü–caption çiftinden oluşan bir batch (yığın) alın. Hepsini kodlayın, vektörleri normalleştirin ve her görüntünün her caption’la kosinüs benzerliğini hesaplayın: köşegeninde gerçek çiftlerin, geri kalan N² − N hücresinde eşleşmeyenlerin durduğu N × N’lik bir tablo. CLIP her satırı bir sınıflandırma problemi olarak ele alır — “bu N caption’dan hangisi bu görüntüye ait?” — ve köşegen hücresini doğru cevap sayarak softmax çapraz entropi uygular; aynısını her sütun için de yapar: “bu caption’a hangi görüntü ait?”. Öğrenilen bir sıcaklık (temperature) parametresi, benzerlikleri softmax’tan önce ölçekler. Bu, Bölüm 19’un yoğun erişim modellerini eğitmek için kullandığı, batch içi negatiflerle (in-batch negatives) çalışan InfoNCE kaybının ta kendisi; yalnızca sorguların yerinde görüntüler var. Bu bölümün modelinin dayandığı çeşit olan SigLIP (Zhai vd. 2023), softmax’ın yerine tablonun her hücresi için bağımsız bir evet/hayır (sigmoid) kararı koyar; böylece hiçbir hücrenin bütün batch’e göre normalleştirilmesi gerekmez.

İleri taşımaya değer iki sonuç var.

Zero-shot (sıfır atışlı) sınıflandırmayı mümkün kılar. Caption’lar metin olduğu için etiket uzayı açıktır: bu kaynak dikişi kusurlu mu diye sormak isterseniz her aday cevap için bir caption kodlarsınız — “kusurlu bir kaynak dikişinin fotoğrafı”, “sağlam bir kaynak dikişinin fotoğrafı” — ve görüntüye en yakın olanı seçersiniz. Artık eğitim anında birinin saydığı kategorilerle sınırlı değilsiniz; görme modellerini kimsenin veri kümesi etiketlemediği yerlerde kullanışlı kılan da buydu.

VLM’lerin üzerine kurulduğu ortak bir uzay kazandırır. Ortak bir uzay, anlaşılırlıkla aynı şey değil: CLIP’in geometrisinde, herhangi bir dil modelinin o vektörleri okuyabilmesini sağlayan hiçbir şey yok. Verdiği şey, pikseller yerine anlam etrafında düzenlenmiş görsel bir temsil — öğrenilecek bir köprü için iyi bir başlangıç noktası; aşağıdaki her tasarım da o köprüyü eğitiyor. Böyle bir köprüyle iki mimari mümkün hâle geliyor. İkisini ayırmakta fayda var, çünkü mimari olarak birbirinin tersi ve bedelleri farklı yerlerde çıkıyor.

Cross-attention. Flamingo (Alayrac vd. 2022) dil modelini tümüyle donduruyor, değişken sayıdaki yamayı bir resampler (yeniden örnekleyici) ile sabit sayıda gizil vektöre (latent) indiriyor ve donmuş katmanların arasına kapılı (gated) cross-attention blokları yerleştiriyor. Görüntü metin dizisine hiç girmiyor; metnin cross-attention ile içine baktığı ikinci bir yol oluyor. Dil modelinin ağırlıkları hiç değişmediği için bu tasarım, bütün modeli güncellemekten daha ucuza eğitilir ve dil modelinin metin davranışına dokunmaz.

Tek diziye izdüşürme. LLaVA (Liu vd. 2023) daha basit olanı yapıyor: küçük bir izdüşüm katmanı — ilk LLaVA’da tek bir doğrusal katman, ardılı LLaVA-1.5’te iki katmanlı bir MLP — her yama vektörünü dil modelinin hidden size’ına izdüşürüyor ve o vektörler metin token’larıyla birleştiriliyor. Eğitim iki aşamalı: önce yalnızca izdüşüm katmanı hizalama için eğitiliyor, ardından izdüşüm katmanı ve dil modeli talimat–cevap çiftleri üzerinde fine-tuning’den (ince ayar) geçiriliyor; görme kodlayıcı iki aşamada da donmuş kalıyor. İkinci aşamaya instruction tuning (talimat ayarı) deniyor. Tek akış, tek attention, yeni modül yok — yukarıdaki şekildeki tasarım ve bugün açık VLM’lerin çoğunun izlediği tasarım bu.

Önünüzdekinin hangisi olduğunu bilmek neyi değiştirebileceğinizi söylüyor. “Donmuş” sözcüğünün neyi dışarıda bıraktığını netleştirelim: gradyanlar donmuş bir dil modelinin içinden akmaya devam eder — resampler ile kapılar zaten böyle eğitilir. Donmuş olan, dil modelinin kendi ağırlıkları; yani modelin yalnızca metinle karşılaştığında gösterdiği davranış kaymaz. Sistem ise görüntü yolundan öğrenmeye devam eder: resampler ile kapılar eğitilir ve bir görüntü olduğunda donmuş modelin ne yaptığını değiştirirler. Tek akışlı bir modelde ise decoder’ın içinde müdahale edilecek ayrı bir cross-attention yolu yoktur — oradaki ayrı modüller, önündeki görme kodlayıcı ve izdüşüm katmanıdır.

Bu bölümün modelindeki görme kodlayıcı, yukarıda anlatılan sigmoid kaybıyla eğitilmiş bir CLIP torunudur (Zhai vd. 2023); sabit boyutlu, havuzlanmış çıktısı da burada bir görüntünün sabit ücretli olmasının nedenidir.

Karşıtsal ön eğitimin kazandırmadığı şey, ayrıntı hakkında herhangi bir garantidir. Eğitim amacı (objective), bir görüntüyü caption’ıyla eşleştirmeyi ödüllendirir; bir caption ise bir fotoğrafın ne hakkında olduğunu tarif eder, her bölgesinde ne olduğunu değil. Bu bölümün sonra ölçtüğü kusurun kökü budur ve mevcut model kuşağından önce de belgelenmişti: görüntü betimleme (captioning) modelleri görüntüde olmayan nesnelerden söz ediyor (Rohrbach vd. 2018).

21.3 Belge okuma, ölçülmüş hâliyle

Ayrıntı konusundaki bu garanti eksikliğinin en kolay yakalandığı yer belgelerdir, çünkü doğru cevap sayfanın üzerinde yazılıdır. Belgeler aynı zamanda en bariz endüstriyel kullanım alanı — taranmış faturalar, formlar, sözleşmeler, gösterge paneli ekran görüntüleri. Yani asıl soru okuyabiliyor mu değil — okuyabiliyor — nerede okuyamaz hâle geldiği ve o sınırın her dil için aynı yerde olup olmadığıdır.

Bölüm 16’nın yöntemi buraya olduğu gibi taşınabiliyor; onu burada kullanmamızın nedeni de bu. WMT16/17/18 Türkçe–İngilizce test kümelerini alın; bunlar profesyonel çeviriler, dolayısıyla iki dil aynı şeyi söylüyor. Her cümleyi aynı yazı tipiyle, dört farklı puntoda sayfa görüntüsü olarak üretin: rahat okunan bir taramadan kötü bir telefon fotoğrafına kadar. İki dil arasındaki herhangi bir fark içerik farkı olamaz.

Bu tasarımın cevaplaması gereken ve cevaplamadığı bir itiraz. WMT test kümeleri aşağı yukarı on yıllık ve herkese açık, dolayısıyla model bu cümlelerin bir kısmını ezberlemiş olabilir — ezberlenmiş bir cümle okunmadan da “transkribe edilebilir” ve bu, aşağıda tanımlanan hata oranını (CER) aşağı çeker. Yanlılığın simetrik olması da beklenmez: WMT’nin İngilizce tarafı web’de Türkçe tarafından muhtemelen çok daha sık kopyalanmıştır; yani veri bulaşması (contamination) tam da bu kesimin raporladığı oranı şişirir. Gereken kontrol, modelin eğitim verisinin kesim tarihinden sonra yayımlanmış cümlelerle kurulacak bir merdiven; bu koşu yapılmadı. Yapılana kadar aşağıda raporlanan yaklaşık 5 katlık farkı bir üst sınır olarak okuyun.

İki puan kullanıyoruz. Genel hasar için karakter hata oranı (character error rate, CER): modelin çıktısıyla referans arasındaki düzenleme mesafesi (birini ötekine çeviren en az sayıda karakter ekleme, silme ve değiştirme), referans uzunluğuna bölünmüş hâliyle. Türkçeye özgü hasar için de aksan korunumu (diacritic retention): sayfada olması gereken ç ğ ı ö ş ü İ karakterlerinin kaçının sağ çıktığı. İkincisi gerekli, çünkü Türkçeyi sessizce aksansızlaştıran bir model (Bölüm 16’nın anlattığı deasciification işleminin, yani Türkçe karakter geri kazanımının tersi) sistematik bir hata yapıyordur ve tek başına CER bunu genel bir hata oranının içinde gizlerdi.

Aşağıdaki çıktıda diacritics kept sütunu aksan korunumu, prompt tokens ise prompt token sayısıdır (İngilizcede korunacak aksan olmadığı için o sütun boş):

gemma3:27b, 40 aligned sentence pairs, one font, four sizes

 language   font px    CER    diacritics kept  prompt tokens
  English       34   0.04%                  —            290
  English       22   0.05%                  —            290
  English       15   0.22%                  —            290
  English       11   1.33%                  —            290
  Turkish       34   0.26%              99.8%            290
  Turkish       22   0.25%              99.6%            290
  Turkish       15   1.30%              99.3%            290
  Turkish       11   6.67%              95.1%            290

vlmData = [
  {lang: "İngilizce", size: 34, cer: 0.04, diac: null},
  {lang: "İngilizce", size: 22, cer: 0.05, diac: null},
  {lang: "İngilizce", size: 15, cer: 0.22, diac: null},
  {lang: "İngilizce", size: 11, cer: 1.33, diac: null},
  {lang: "Türkçe", size: 34, cer: 0.26, diac: 99.8},
  {lang: "Türkçe", size: 22, cer: 0.25, diac: 99.6},
  {lang: "Türkçe", size: 15, cer: 1.30, diac: 99.3},
  {lang: "Türkçe", size: 11, cer: 6.67, diac: 95.1}
]

viewof vlmScale = Inputs.radio(new Map([["doğrusal", "linear"], ["logaritmik", "log"]]),
  {value: "log", label: "hata ekseni"})

Plot.plot({
  width: 700, height: 360, marginLeft: 62, marginBottom: 46,
  x: {label: "punto (px) — büyük olan daha kolay", domain: [10, 36],
      ticks: [11, 15, 22, 34], grid: true, reverse: true},
  y: {type: vlmScale, label: "karakter hata oranı (%)", grid: true,
      domain: vlmScale === "log" ? [0.03, 10] : [0, 7]},
  color: {legend: true, domain: ["İngilizce", "Türkçe"],
          range: ["#0E7C7B", "#C1666B"]},
  marks: [
    Plot.line(vlmData, {x: "size", y: "cer", stroke: "lang", strokeWidth: 2}),
    Plot.dot(vlmData, {x: "size", y: "cer", fill: "lang", r: 5}),
    Plot.text(vlmData, {x: "size", y: "cer", dy: -14, fontSize: 11,
      fill: "lang", text: d => d.cer.toFixed(2) + "%"})
  ]
})

md`Logaritmik eksende iki çizgi neredeyse paralel — Türkçe her çözünürlükte
İngilizcenin kabaca **5 katı** düzeyinde duruyor, yani oran kabaca sabit
*görünüyor*; ama üst basamaklardaki hata sayıları çok küçük (aşağıya bakın).
Doğrusal eksene geçtiğinizde aynı veri bir uçurum gibi görünür, çünkü fark
34 pikselde yalnızca 0,2 yüzde puanıyken 11 pikselde 5,3 yüzde puanına çıkıyor.
İki okuma da doğru; hangisini gösterdiğiniz, okuyanın harekete geçip
geçmeyeceğini belirliyor.`

21.3.1 Ne söylüyor

Birebir aynı içerikte Türkçenin hata oranı, 11 pikselde sağlam biçimde ölçüldüğü hâliyle İngilizcenin yaklaşık beş katı; üst basamaklar da bununla uyumlu. 34 pikselde 6,5 kat, 22’de 5,0, 15’te 5,9, 11’de 5,0.

Bunu dört ayrı doğrulama diye okumadan önce yüzdeleri tek tek hata sayılarına geri çevirin. Kırk cümle yaklaşık 8.880 İngilizce ve 9.320 Türkçe karakter eder; yani üstteki iki İngilizce basamağın her birinde yaklaşık dört yanlış karakter var (ortalama 3,6 ve 4,4), Türkçe basamaklarda ise yaklaşık yirmi dört ve yirmi üç. Bu kadar küçük iki sayımın oranının güven aralığı çok geniştir — 34 pikseldeki 6,5 kat, 3,6’ya karşı 24 düzenleme demek — dolayısıyla bu oranlara “dikkat çekici biçimde kararlı” demek yanlış olur. İstatistiksel olarak sağlam olan basamak en alttaki: orada sayılar 118’e karşı 622. Doğru okuma şu: 11 pikselde sağlam biçimde ölçülmüş ve üstteki basamakların hiçbirinde çürütülmemiş tek bir oran. Merdiven boyunca değişen şey mutlak hasar ve bu hasar 11 pikselde gerçek bir sayıya dönüşüyor: karakterlerin %6,67’si yanlış, İngilizcede ise %1,33’ü.

Bu, Bölüm 16’daki örüntünün bu kez beklenmedik bir yerden, girdi tarafında tokenizer olmadan ortaya çıkması. Girdi tarafında tokenizer yok, gövdeleyici yok, küçük harfe çevirme yok — yalnızca pikseller ve bir görme kodlayıcı. Araç yine de Türkçede ölçülebilir biçimde daha kötü çalışıyor. Bunu yaparken de kayıtlarda yakalayabileceğiniz hiçbir hata ya da uyarı vermiyor. Çıktı tarafı ise başka: transkripti yine aynı dil modeli, aynı tokenizer üzerinden token token yazıyor ve bir sonraki alt bölüm, hataların dil modelinin tahminlerine benzediğini gösteriyor. Yani fark “dilsiz görme” değil; Türkçede kendisi de daha zayıf olabilecek bir dil modelini besleyen bir görme girdisi — ve bu deney farkın ne kadarının hangi taraftan geldiğini söyleyemez.

Uçurumun nerede olduğuna da dikkat edin. 22 pikselle 15 piksel arasında İngilizcenin hata oranı zaten çok küçük bir değerden dört katına çıkıyor; Türkçeninki beş katına çıkarak fark edeceğiniz bir düzeye varıyor. 15 pikselle 11 piksel arasında ikisi de yeniden kötüleşiyor — İngilizcenin hatası altı, Türkçeninki beş katına çıkıyor.

Yani iki eğrinin biçimi aynı; Türkçe eğrisi, İngilizce eğrisinin kabaca sabit bir katsayıyla yukarı kaydırılmış hâli. Bu kaymanın pratikteki etkisi eşiği taşımak. Katlanabileceğiniz herhangi bir hata oranı seçin — diyelim karakterlerin %1’i — Türkçe onu İngilizceden daha büyük bir puntoda aşıyor (burada 22 ile 15 piksel arasında; İngilizce ise 15 ile 11 piksel arasında). Punto küçüldükçe bozulma hızlanıyor (her basamakta katlanarak artıyor); sabit bir tolerans için bu, pratikte yavaş yavaş çevrilen bir ayar düğmesi gibi değil bir eşik gibi davranır ve bu eşik iki dilde farklı bir yerde duruyor. Yani İngilizce belgelerde doğrulanmış bir tarama ayarı Türkçe belgeler için doğrulanmış değildir.

21.3.2 Kusur, öngöreceğiniz kusur değil

Hataların aksanlarda çıkmasını bekliyordum: ş yerine s, ğ yerine g okunmasını. Bunun bir kısmı oluyor — aksan korunumu 11 pikselde %95,1’e düşüyor, dolayısıyla Türkçeye özgü her yirmi karakterden kabaca biri yok oluyor. Ama bu, hasarın küçük bir kısmı; büyük kısmı daha ilginç. Aşağıda REF referans metni, HYP modelin çıktısını (hipotez) gösteriyor:

REF  ... ailesinin Mississippi, Greenville banliyölerinde bulunan evine ...
HYP  ... ailesinin Mississippi, Greenville'de bulunan evine ...

Model bir aksan düşürmedi ya da bir harfi bozmadı. Çözemediği bir kelimeyi daha kısa, dilbilgisel ve makul bir alternatifle değiştirdi. Bu, OCR’ın başarısız olması değil; bir dil modelinin, dil modellerinin hep yaptığı şeyi yapması: belirsiz bir bölgeyi olası bir şeyle doldurmak. Bir VLM’in risk profilinin klasik bir OCR motorundan farklı olmasının asıl nedeni de bu.

Özel bir OCR sistemi, çözemediği bir karakterde bozulduğunda gözle görülür biçimde yanlış bir şey üretme eğilimindedir. Bir VLM ise sayfada hiç olmamış akıcı Türkçe üretir. Bunu temiz bir kural değil, bir derece farkı sayın: modern OCR motorları da dil modeli ve sözlük kullanır ve makul bir rakamı ya da kelimeyi bir başka makul olanla seve seve değiştirirler. VLM ile değişen şey, çıktının ne kadarının önsellerden yeniden kurulabileceği ve ne kadar azının kendini tahmin diye ilan ettiği.

Bu bulgu somut bir karar kuralı veriyor: aşağı akıştaki bir adım transkripsiyonu kesin doğru (ground truth) kabul edecekse, kusurları kusur gibi görünen bir aracı tercih edin. Bölüm 21.8 özel OCR motorlarını adlandırıyor. VLM’i görevin transkripsiyon değil anlama olduğu yerde — bu belge ne hakkında, hangi alan toplam — ve yanlış bir cevabın kendi akıcılığından başka bir şeyle kontrol edildiği yerde kullanın.

21.4 Görüntüyü mü okuyor, yoksa makul bir cevap mı veriyor?

Transkripsiyon sonucu daha keskin bir soru doğuruyor. Model okunamayan bölgeleri olası metinle dolduruyorsa, bir görüntü hakkında verdiği herhangi bir cevabın ne kadarı gerçekten piksellerden geliyor?

Bu soru, kitabın sürekli geri döndüğü kontrolle cevaplanabilir. Türkçe şehir adlarının karşısına hiçbir modelin bilemeyeceği ya da tahmin edemeyeceği sayılar yazılmış uydurma tablolar üretin ve her tablo hakkında iki tür soru sorun:

mevcut: tabloda olan bir satır. Tam eşleşmeyle puanlanır.
yok: tabloda olmayan, makul bir Türkçe şehir. Modelin şehrin tabloda olmadığını söyleyip söylemediğiyle puanlanır.

Deneyin asıl kısmı ikincisi. Her şeyi kendinden emin cevaplayan bir model, ona görüntüde olmayan bir şey sorana dek iyi okuyan bir modelden ayırt edilemez.

Aşağıdaki çıktının ilk satırı tabloda olan değerleri (read correctly: doğru okundu), ikincisi tabloda olmayanları (refused: reddetti) sayıyor:

gemma3:27b, 30 tables of 8 invented rows, 180 questions

  value present in the table   read correctly   89/90  =  98.9%
  value NOT in the table       refused          90/90  = 100.0%

Her seferinde reddetti. Makul bir şehir için makul bir sayı uydurmak üzere doksan fırsatı vardı ve hiçbirini kullanmadı. Mevcut değerlerdeki tek hata da yanlış okunmuş bir rakamdı, bir uydurma değil.

Bu karşıtlığın gerektirdiği ama henüz yapılmamış kontrol. Bu tablolar modelin rahatça okuyabildiği bir puntoda üretildi; karşılaştırıldığı transkripsiyon hatası ise sayfanın zar zor okunduğu 11 pikselde oluyor. Yani bölümün manşetini oluşturan iki yarı iki farklı çözünürlük rejiminde ölçülmüş durumda ve asıl soru şu: reddetme okunaksızlıktan sağ çıkıyor mu? Aynı 30 tabloyu 11 pikselde yeniden üretip aynı 180 soruyu sorun: reddetme oranı korunuyorsa asimetri sorunun türüyle ilgili; çöküyorsa asimetrinin kaynağı sorunun türü değil, görüntünün kolay ya da zor olmasıymış demektir ve iddia tersine döner. Bu koşu bir öğleden sonra sürer ve ekleyeceğimiz ilk şey odur.

Bu kesimin size borçlu olduğu iki açıklama daha var ve ikisi de %100’ün nasıl okunacağını değiştiriyor. Birincisi: bir ret oranı en az model kadar prompt’un da bir özelliğidir. “Değeri yazın ya da tabloda olmadığını söyleyin” ifadesi, “Trabzon’un değeri nedir?” sorusunun yapmadığı biçimde modeli reddetmeye davet eder ve prompt’lar burada verilmiyor. İkincisi: kod çözme (decoding) ayarları da verilmiyor. Bütün argüman modelin hangi dağılımı ürettiğiyle ilgili; dolayısıyla kod çözmenin greedy (açgözlü) mi yoksa örneklemeli mi yapıldığı bir ayrıntı değil. Deneyi kendiniz çalıştırdığınızda ikisini de kaydedin.

21.4.1 Asıl bulgu, iki sonucun birlikte okunmasında

Tek başına okunduğunda o tablo modelin görüntüler konusunda güvenilir olduğunu söylüyor. Bölüm 21.3’ün yanında okunduğunda çok daha özgül ve çok daha kullanışlı bir şey söylüyor. Aşağıdaki iki satır: görüntüde olmayan bir şey sorulduğunda model %100 reddediyor; çözemediği bir şeyi transkribe etmesi istendiğinde akıcı Türkçe uyduruyor:

  asked for something that is NOT in the image     refuses, 100%
  asked to transcribe something it CANNOT resolve  invents fluent Turkish

Bu testte model olmayan her değeri reddetti. Neyi okuyamadığını bilmiyordu.

Ayrım bir tuhaflık değil; iki sorunun sorulma biçiminden çıkıyor. Trabzon bu tabloda mı, modelin gerçekten mevcut olan kanıttan verebileceği kategorik bir yargıdır — sekiz satırı görebiliyor ve Trabzon aralarında değil. Bu leke ne diyor sorusunun ise karşılaştırılabileceği böyle bir kanıt yok: bölge belirsiz, modelin her adımdaki işi olası bir devam üretmek ve ürettiği de tam da bu: olası bir devam.

“Bunu okudum” ile “bunu çıkarsadım”ı güvenilir biçimde ayıran içsel bir sinyal yok, çünkü ikisi de aynı ileri geçişten çıkıyor. Her çıktı token’ının bir olasılığı vardır, ama dil modelinin olası bulduğu bir tahmin, net basılmış bir kelime kadar yüksek puan alabilir; yani yüksek olasılık, token’ı piksellerin desteklediği anlamına gelmez.

Bölüm 18’in log olasılık sonucuyla karşılaştırın: token olasılıkları cevapları iyi sıraladı ama kötü kalibre edilmişti ve en çok, ayrık bir soruda çekimser kalmak için işe yaradı. Çekimserlik, çekimser kalınacak bir soru olduğunda işler. Üretilen uzun bir metnin içinde ise hiçbir token kendini tahmin diye ilan etmediği için çekimserliğin tutunacağı bir şey yoktur.

İki soruyu yan yana koyun; asimetri modelde değil kanıtta:

Yokluk neden kontrol edilebilir, okunamazlık neden değil

Soldaki soru modelin görebildiği bir şeye karşı çözülebilir; sağdaki çözülemez. Model solda daha dürüst değil; yalnızca solda elinde kanıt var, sağda ise sadece bir olasılık dağılımı. İki cevap da aynı üretim adımından çıkıyor.

Bu size tutunabileceğiniz bir kural veriyor. Bir VLM’e soru sorun. Ondan OCR motoru olmasını isteyip çıktısına transkript olarak güvenmeyin, çünkü kusur biçimi akıcıdır. Alternatifin gürültülü biçimde bozulacağını da varsaymayın: özel bir motor size güven puanları (confidence scores; motora göre karakter, kelime ya da satır başına) verir. Bunlarla bir güven eşiği uygulayabilirsiniz (confidence gating): eşiğin altında kalan parçaları işaretleyip insan incelemesine gönderirsiniz. Bu yardımcı olur, ama o motor da makul bir kelimeyi ya da rakamı makul bir başkasına çevirebilir. Transkripti hangi araç üretirse üretsin, aşağı akıştaki sistemlerin olgu kabul edeceği alanları doğrulayın.

21.5 VLM mi OCR mı?

O kural aslında modeller hakkında değil araçlar hakkında bir iddiadır. İkisi tek bir şeyin rakip uygulamaları değil; kusur biçimleri farklı ve aracı, kusur biçimine göre seçmek gerekir.

Bir görme-dil modeli (VLM) ile bir optik karakter tanıma (OCR) motoru farklı işler için kurulmuştur; bu fark en çok, yanıldıklarında ne yaptıklarında görünür.

vision-language model (VLM) (görme-dil modeli) — görme kodlayıcı takılmış bir dil modeli; böylece görüntüler ve metin tek bir dizide durur. Sayfaları, grafikleri ve fotoğrafları okur ve onlar hakkındaki soruları cevaplar. ↩︎

optical character recognition (OCR) (optik karakter tanıma) — bir metin görüntüsünü metne çevirmek. Özel bir motor, eşik uygulayabileceğiniz güven puanları (motora göre karakter, kelime ya da satır başına) sunar; böyle bir sinyali olmayan bir modele karşı başlıca üstünlüğü budur. İkisi de makul hatalar yapabilir. ↩︎

İki araç, iki kusur biçimi
	Özel OCR	Görme-dil modeli
Emin olduğunda çıktı	metin, kelime ya da satır başına güven puanlarıyla (bazı motorlarda karakter başına)	metin; token olasılıkları var ama token’ı piksellerin destekleyip desteklemediğini söylemiyor
Bozulduğunda çıktı	çoğu zaman görünür biçimde yanlış, eşik uygulanabilir güven puanlarıyla — makul değiştirmeler de olur	akıcı, makul, yanlış
Düzen ve okuma sırası	kendi modelini ya da sezgisel kurallarını ister	halledilir, çoğu zaman iyi
Bir belge hakkında cevap vermek	onun işi değil — üstüne siz kurarsınız	tam da bunun için var
Grafikler ve diyagramlar	işe yarar hiçbir şey yok	okur, yukarıdaki çekinceyle
Sayfa başına maliyet	ucuz, yerel; klasik motorlar (Tesseract) CPU’da rahat çalışır, derin öğrenme tabanlı motorlar GPU’dan fayda görür	bu modelin sabit ızgaralı kodlayıcısı için sabit 256+ token artı üretim; döşemeli kodlayıcılar kırpım başına ücretlendirir
Türkçe özelinde	tümüyle motorun dil paketlerine bağlı	yukarıda ölçüldü: 11 px’te İngilizce hata oranının ~5 katı

2026’da belge işi için pratik mimari genellikle ikisi birden: özel bir motor transkripti üretir ve VLM hem transkript hem görüntü üzerinden soruları cevaplar. Böylece indekslediğiniz metin, eşik uygulayabileceğiniz güven puanlarıyla gelir ve model yalnızca özellikle iyi olduğu işler için kullanılır: düzeni okumak, alanı bulmak, grafiği anlamak.

Belge okuyan bir VLM’de görüntünün içindeki metin de modele giden girdinin parçasıdır; dolayısıyla bir sayfaya gömülmüş talimatlar bir prompt enjeksiyonu (prompt injection) yolu olabilir. Model araç çağırabiliyorsa bu risk büyür; ayrıntılar Bölüm 36’da.

21.6 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. Altısı da bu bölümün tartışmayla değil ölçümle çözdüğü sorular.

1. Bir görüntü göndermek metni göndermekten ucuz mu?

Hayır ve yakın bile değil. Aynı cümle iki biçimde de ölçüldü: İngilizce metin olarak 46,6 token, görüntü olarak 260 — 5,57 katlık bir prim, Türkçede 4,17 kat. Bu kodlayıcı için görüntü ücreti sabittir ve insanları şaşırtan kısım da bu: kodlayıcı hep 256 vektör ürettiği için bir satır tutan bir sayfayla on dört satır tutan bir sayfa aynı tutara mal olur — ve bu bölümde 34 ile 11 piksel arasındaki 320 sayfanın her biri aynı 290 prompt token’ına mal oldu. Yani elinizde zaten olan metni fotoğraflamak saf israftır ve sayfa ne kadar az şey içeriyorsa israf o kadar büyüktür.

2. Model değişmiyorsa transkripsiyon doğruluğu punto küçüldükçe neden düşüyor?

Çünkü kodlayıcının girdi çözünürlüğü (896×896) ve token bütçesi sabit; yazı küçüldükçe karakter başına daha az piksel düşüyor. Neyin sabit tutulduğunu netleştirelim: içerik merdivenin her basamağında aynı cümle, yani yeni hiçbir şey eklenmiyor — değişen şey, karakterlerin daha az piksel kaplaması. Daha küçük punto, aynı darboğazdan karakter başına daha az kodlayıcı pikseli geçmesi demek. Bu etkinin yönünü hiçbir şey çalıştırmadan öngörebilirsiniz; bu da çözümün promptlamada değil, çözünürlükte ve kırpmada olduğu anlamına gelir.

3. VLM’iniz İngilizce belgeleri %0,2 karakter hatasıyla okuyor. Türkçede ne yapar?

Daha kötü okur; ne kadar kötü olduğunu da varsaymak yerine ölçmeniz gerekir. Burada aynı koşullarda üretilmiş, anlamca eşleştirilmiş İngilizce ve Türkçe metinlerde fark en küçük boyutta sağlam biçimde yaklaşık 5 kat çıktı — %1,33’e karşı %6,67; üst basamaklardaki oranlar da bununla uyumlu, ama tek başına kanıt olamayacak kadar az hataya dayanıyor. Kontrolün “içerik aynı” demekten öteye gitmediğine dikkat edin: ikisi de Latin alfabesiyle yazılıyor ve Türkçe yalnızca harfleriyle değil, aksanları, kelime biçimleri ve biçimbilimiyle de farklı; yani deney dili yalıtıyor, dilin tek bir özelliğini değil. Genel ders Bölüm 16’daki derstir; bu kez girdi tarafında hiç tokenizer olmadan karşımıza çıkıyor: İngilizcede doğrulanmış bir hat, girdisi metin değil piksel olsa bile başka bir dil için doğrulanmış değildir.

4. Bir VLM bir sayfayı transkribe etti ve çıktı kusursuz okunuyor. Doğru mu?

Şart değil: akıcılık, transkripsiyon doğruluğunun kanıtı değildir. Ölçülen kusur biçimi bozuk karakterler değil; modelin çözemediği bir kelimenin daha kısa, dilbilgisel ve makul biriyle değiştirilmesi — göze batan bir kusurdan daha iyi görünen bir çıktı. Klasik bir motor en azından ürettiğine güven puanları iliştirir, ama o da makul değiştirmeler yapabilir. Aşağı akıştaki bir adım transkripti doğru kabul edecekse, iki aracın hata oranlarını kendi belgeleriniz üzerinde karşılaştırın ve önemli alanları doğrulayın.

5. VLM’ler görüntüler hakkında halüsinasyon görür mü?

Sınaması kolay olan durumda, haklarındaki ünün düşündürdüğünden daha az: tabloda olmayan bir değer 90 kez soruldu ve bu model 90 kez reddetti. Yaptığı şey, ürettiği şeylerin içinde uydurmaktır; okunamayan bir bölgenin transkripti gibi. Yokluğu saptayabilir; okunamazlığı saptayamaz, çünkü bir ileri geçişte hiçbir şey okumayı çıkarsamadan güvenilir biçimde ayırmaz.

6. OCR hattınızı bir VLM ile değiştirmeli misiniz?

Genellikle ikisini birden çalıştırmalısınız. Transkript için özel motoru kullanın; böylece kusurlar göze batar ve güven eşiğiyle işaretlenebilir. VLM’i ise özellikle iyi olduğu işlerde kullanın: düzeni okumak, bir alanı bulmak, bir grafiği okumak, sayfa hakkındaki soruları cevaplamak. Güven eşiğiyle işaretlenebilen bir kusur biçimini sessiz biriyle değiştirmek, ortalama doğruluk artsa bile bir gerilemedir.

21.7 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Bu sorular, kitabın kullandığı iki güvenilir açık kaynakta tekrar tekrar karşımıza çıkıyor; bunlara bu bölümün kendi ölçümleriyle cevaplanabilen sorular eklendi.

21.7.1 Mekanizmayı anlayıp anlamadığınızı sınayanlar

S: Bir görüntü bir dil modeline nasıl girer?

Yamalara bölünür, her yama bir görme kodlayıcıyla modelin hidden size’ına izdüşürülür ve ortaya çıkan vektörler metin token’larıyla tek bir dizide birleştirilir. Sonra attention bu dizi üzerinde her zamanki gibi çalışır; nedensel maske metnin kendinden önceki görüntü vektörlerine dikkat etmesine izin verir. Bir sonucu da ekleyin, çünkü böyle bir modeli gerçekten kullandığınızı gösterir: bu kodlayıcı sabit sayıda vektör üretir, dolayısıyla görüntü maliyeti sayfada ne olduğuyla ölçeklenmez — burada 34 pikselden 11 piksele her sayfa için sabit 290 prompt token’ı olarak ölçüldü ve bunun 260’ı görüntünün kendisi. Ardından döşemeli ve dinamik çözünürlüklü kodlayıcıların görüntüyle ölçeklendiğini ekleyin.

S: Bir model testte belgelerinizi iyi, üretimde kötü okuyor. Nereye bakarsınız?

Önce çözünürlüğe, çünkü eğimi değil uçurumu olan değişken odur. Daha küçük puntoda aynı içerik karakter başına daha az kodlayıcı pikseli alır ve bozulma her basamakta hızlanır; sabit bir tolerans için pratikte bir eşik gibi davranır — burada İngilizce merdiven boyunca %0,04’ten %1,33’e, Türkçe %0,26’dan %6,67’ye gitti. Sonra üretim sayfalarının test sayfalarından dilde ayrışıp ayrışmadığına bakın, çünkü uçurum farklı diller ve glif dağılımları için farklı bir yerde durur.

21.7.2 Bir tane yayına alıp almadığınızı sınayanlar

S: Bir VLM’i belgeden bilgi çıkarma işinde nasıl değerlendirirsiniz?

İki kontrolle ve her birinin neden var olduğunu söyleyerek. Birincisi, elle yazılmış referans metinlere karşı karakter hata oranı; gerçekten karşılaştığınız her çözünürlük ve dil için ayrı ayrı raporlanmış — toplam değer uçurumu gizler. İkincisi bir yokluk kontrolü: cevapları sayfada olmayan sorular, modelin reddedip reddetmediğine göre puanlanır. İkincisi olmadan okuyan bir modelle makul cevap veren bir modeli ayırt edemezsiniz. Ayrıca en kötü durumdaki transkriptleri elle okuyup dilbilgisel olarak doğru ama içerik olarak yanlış pasajları arayın, çünkü o hata sınıfı çalıştırmanız muhtemel her otomatik kontrolden sağ çıkar.

S: Bir VLM’i ne zaman kullanmazsınız?

Aşağı akıştaki bir sistemin güveneceği bir transkripte ihtiyacınız olduğunda. Kusur biçimi akıcıdır ve çıktının kendisine bakarak saptanması zordur; dolayısıyla sessiz bir hata indekslediğiniz ya da hesapladığınız her şeye yayılır. Orada özel bir OCR motoru kullanın, VLM’i transkripsiyon için değil anlama için saklayın ve ikisi de gerekiyorsa ikisini de çalıştırın — ek maliyet, kimsenin fark etmediği yanlış bir sayının bedeli yanında küçük kalır.

21.8 2026 alet çantası

Bu bölümdeki her şey aşağıdaki sürümlerle tek bir yerel GPU’da çalıştı.

Bu sayıların çıktığı yığın
kütüphane	kullanılan sürüm	burada ne işe yarıyor
`ollama`	0.24.0	`gemma3:27b`’yi görüntü desteğiyle yerelde sunmak
`Pillow`	12.3.0	hizalı sayfaları ve uydurma tabloları üretmek
`numpy`	2.5.2	puanlama

Bilmeye değer ama yukarıda kullanılmayan araçlar:

Daha geniş ekosistem, yazıldığı andaki sürümler
kütüphane	güncel sürüm	ne zaman kullanılır
`paddleocr`	3.7.0	düzen çözümlemeli güçlü bir özel OCR motoru; eşik uygulanabilir güven puanlarıyla gelen bir transkript istediğinizde varsayılan ilk deneme
`surya-ocr`	0.22.1	modern OCR artı okuma sırası ve tablo saptama, çok dilli
`easyocr` / `pytesseract`	1.7.2 / 0.3.13	daha basit seçenekler; `easyocr` PyTorch üzerinde çalışır, `pytesseract` ise Tesseract’ı sarar — eski, CPU’da hızlı ve bozulduğu belli olan bir motor
`docling`	2.123.0	uçtan uca belge dönüştürme, Bölüm 20’nin 1. aşama problemi
`pdf2image`	1.17.0	metin katmanı yerine piksel gerektiğinde PDF sayfalarını görüntüye
`transformers`	5.16.1	yerel bir sunucu yetmediğinde açık görme-dil modellerini kendiniz çalıştırmak

21.9 Lab: kendi çözünürlük uçurumunuzu bulun

Aradığınız sayı, kendi belgelerinizin okunamaz hâle geldiği çözünürlüktür. Bu sayı sayfalarınıza, yazı tiplerinize ve dilinize özgüdür; dolayısıyla kimse onu size hazır veremez.

21.9.1 Adım 1 — yirmi gerçek sayfa, temiz olanlar değil

Gerçek hattınızdan yirmi belge alın; kötü taramalar dâhil. Çözünürlük sorunlarının üretime kadar sızmasının nedeni temiz test verisidir.

21.9.2 Adım 2 — merdiveni kurun

Her sayfayı rahat okunandan sınırdakine uzanan dört çözünürlükte üretin ya da küçültün. Bir eşik arıyorsunuz, dolayısıyla eşiğin iki yanında da ölçüm noktalarına ihtiyacınız var.

21.9.3 Adım 3 — transkribe edin ve düzenleme mesafesiyle puanlayın

Yirmi sayfa için referans metne ihtiyacınız var. Yazın. İki saat sürer ve bu labın atlanamayacak tek parçasıdır, çünkü sonrasındaki her sayı ona bağlıdır.

21.9.4 Adım 4 — dile özgü karakterleri ayrı puanlayın

Dilinizin aksanlarından kaçının sağ çıktığını sayın. Genel bir hata oranı bunu ortalamanın içinde kaybeder; oysa aşağı akıştaki eşleştirmeyi bozan kısım tam da budur.

21.9.5 Adım 5 — yokluk kontrolünü çalıştırın

Cevapları sayfada olmayan on soru sorun. Kendinden emin cevapları sayın. Aynı şeyi cevabı sayfada olan on soru için de yapın.

21.9.6 Adım 6 — akıcı uydurmaların nerede başladığını bulun

En kötü çözünürlüğünüzdeki transkripsiyonları elle okuyun; dilbilgisel olarak doğru ama içerik olarak yanlış her pasajı işaretleyin. Çıktının indekslenmesinin güvenli olup olmadığını size karakter hata oranı değil, bu sayı söyler.

21.9.7 Teslim edilecekler

Uçurumun işaretlendiği hata oranı merdiveni, her basamaktaki aksan korunumu, iki kontrolün sayımları ve üretimde kabul edeceğiniz asgari çözünürlüğü belirten tek bir cümle.

21.10 Alıştırmalar

Önce öngörün, sonra kontrol edin. Kendi işinizden üç görüntü toplayın — bir tablo taraması, bir grafik, bir fotoğraf. Sınamadan önce modelin hangisini ve nasıl yanlış okuyacağını yazılı olarak öngörün. Sonra kontrol edin. Bu alıştırmanın bütün değeri, öngörüyü yazıya dökmüş olmanızdan gelir.
Uçurumunuzu bulun. Bir sayfa alın ve sekiz çözünürlükte üretin. Karakter hata oranını çözünürlüğe karşı çizin. Eğim mi basamak mı? Asgari olarak ayarlayacağınız çözünürlüğü işaretleyin ve onu garanti etmenin neye mal olduğunu söyleyin.
Yokluk kontrolü. Elinizdeki bir belgede cevapları olmayan on soru yazın. Sorun. Kendinden emin cevapları sayın. Sayı sıfırsa soruları zorlaştırın — benzer bir belgede bulunacak türden makul alanlar sorun — ve tekrar deneyin.
Akıcı ve yanlış. En kötü gerçekçi çözünürlüğünüzde beş sayfa transkribe edin ve dilbilgisel olup sayfada olmayan her pasajı işaretleyin. O sayıyı karakter hata oranıyla karşılaştırın. Hangisi sizi uyarırdı?
İki dil, tek içerik. Birden fazla dilde çalışıyorsanız hizalı bir çift bulun ya da yapın ve merdiveni ikisinde de çalıştırın. Oranı raporlayın. 1’e yakınsa hattınızın öteki dile de genellendiğine dair kanıtınız var; 5 ise tarama politikasını belirleyen kişiye götürecek bir sayınız var.
Fiyatlandırın. Belge hacminizin görüntü olarak ve metin olarak neye mal olduğunu, kendi modeliniz için ölçtüğünüz sabit görüntü ücretiyle hesaplayın. Sonra hattınızda, metni zaten elinde olduğu hâlde sayfanın görüntüsünü gönderen yeri bulun.
Melez. Bölüm 21.5’teki iki araçlı mimariyi on belgede kurun: transkript için özel OCR, sorular için VLM. Bileşimin görevinizde ikisinden birini tek başına yenip yenmediğini ölçün ve neye mal olduğunu söyleyin.

21.11 Daha derine

Zaten metin olarak elinizde olan bir sayfayı fotoğraflayıp iki biçimde de token’ları sayarak başlayın. Bu oran, bilinmesi gereken ilk şeydir ve ölçmesi iki dakikanızı alır.

Makalelerin ötesi
kaynak	ne olduğu
Vision language models explained — Hugging Face	parçaların nasıl birleştirildiğine dair en net kısa genel bakış, güncel tutuluyor
`open_clip`	karşıtsal ön eğitimin açık yeniden uygulamaları, yeniden üretilebilir eğitim tarifleriyle
OpenAI CLIP	özgün yayın; baştan sona okunacak kadar küçük
PaddleOCR / Surya	Bölüm 21.5’teki özel motorlar — çıktısı eşik uygulanabilir güven puanlarıyla gelen araçlar
LLaVA	çalıştırılabilir kod hâlinde görsel talimat ayarı; açık VLM’lerin çoğunun hâlâ izlediği tasarım
3Blue1Brown	transformer ve attention bölümleri görüntü yarısına aynen uygulanır; görme kodlayıcı farklı yamalar üzerinde aynı makinedir

Birincil kaynaklar
konu	kaynak
yama dizisi olarak bir görüntü	Dosovitskiy vd. (2021)
karşıtsal görme-dil ön eğitimi	Radford vd. (2021)
mevcut kuşağın kullandığı kayıp	Zhai vd. (2023)
görmeyi donmuş bir dil modeline takmak	Alayrac vd. (2022)
görüntüler için talimat ayarı	Liu vd. (2023)
resimde hiç olmayan nesnelerin iddia edilmesi	Rohrbach vd. (2018)
buradaki tüm ölçümlerin koştuğu model	Gemma Team, Google DeepMind (2025)

21.12 Akılda kalması gerekenler

Bir görüntü sabit ücretlidir — bu kodlayıcı için. Bu bölümdeki 320 sayfanın her biri, punto ya da içerik ne olursa olsun aynı 290 prompt token’ına mal oldu — 256 görüntü vektörü, birkaç işaret token’ı ve prompt — çünkü bu model sabit bir ızgaraya yeniden boyutlandırıp sabit 256 vektöre havuzluyor. 2025–2026 ailelerinin çoğunun kullandığı dinamik çözünürlüklü ve döşemeli kodlayıcılar bunun yerine değişken sayıda ücretlendirir. Bütçelemeden önce kendi kodlayıcınızın kuralına bakın; yararlı olan, böyle bir kuralın var olduğunu bilmek.
Elinizde zaten olan metni fotoğraflamak yaklaşık 4,2–5,6 kat pahalıdır. Aynı cümle: İngilizce metin olarak 46,6 token, Türkçe metin olarak 62,4, görüntü olarak 260. Prim Türkçe için yalnızca Bölüm 16’nın tokenizer cezası metni zaten pahalılaştırdığı için daha küçük.
Çözünürlük bir eğim değil uçurumdur ve uçurum dile özgüdür. Daha küçük puntoda aynı içerik karakter başına daha az piksel kaplar ve bozulma her basamakta hızlanır; deney kaynak bilginin miktarını değil okunabilirliği değiştiriyor. İngilizce merdiven boyunca %0,04 → %1,33 karakter hatasına gitti; Türkçe %0,26 → %6,67.
Türkçenin hata oranı 11 pikselde İngilizcenin yaklaşık 5 katı oldu (sağlam ölçüm; üst basamaklar bununla uyumlu ama tek başına kanıt değil) — hem de içeriğin birebir aynı olduğu, profesyonel olarak çevrilmiş çiftlerde. Girdi tarafında tokenizer, gövdeleyici ya da lower() yok — yalnızca pikseller var; araç yine de Türkçede ölçülebilir biçimde daha kötü çalıştı. Bölüm 16’daki örüntünün ortaya çıkması için metin girdisi gerekmiyor; çıktıyı yine bir dil modeli yazıyor.
Kusur biçimi çöp değil akıcılıktır. Aksan kaybı hasarın küçük bir kısmıydı (en kötü ayarda %95,1 korundu). Büyük kısmı, modelin çözemediği bir kelimenin daha kısa, dilbilgisel ve makul biriyle değiştirilmesiydi. Bir VLM kusursuz bir Türkçeyle yanılır; klasik bir motorun böyle yanılmayacağını da varsaymayın.
Bu testte model olmayan her değeri reddetti; neyi okuyamadığını bilmiyordu. Bir tabloda olmayan bir değer 90 kez soruldu ve 90 kez reddetti. Sıfır ıskalama, sorular bağımsız olsa bile yaklaşık %3,3’e kadar bir ıskalama oranıyla uyumludur (istatistikteki rule of three: sıfır başarısızlıkta %95 güven üst sınırı ≈ 3/n = 3/90); 30 tablodan çekilen 90 soru ise tümüyle bağımsız da değildir. Mevcut değerleri %98,9 doğrulukla okudu. Yokluk kanıta karşı kontrol edilebilir; okunamazlık edilemez, çünkü bir ileri geçişte hiçbir şey okumayı çıkarsamadan güvenilir biçimde ayırmaz.
Yani iki aracı da kullanın. Transkript için özel OCR; kusurları eşik uygulanabilir güven puanlarıyla gelir. VLM ise düzen, alan bulma, grafikler ve sayfa hakkındaki sorular için. Güven eşiğiyle işaretlenebilen bir kusur biçimini sessiz biriyle değiştirmek, ortalama doğruluk artsa bile bir gerilemedir.