Görüntü anlayan modelleri üretime almadan önce cevaplanması gereken iki soru var ve ikisi de teknik: bir görsel kaç token ediyor ve sağlayıcının kendi dokümanı modelin neyi yapamadığını söylüyor mu. İkisinin cevabı da yayımlanmış durumda; çoğu ekip bakmadığı için hem bütçeyi hem doğruluk beklentisini yanlış kuruyor. Bu yazı o iki cevabı, fatura ve belge okuma gibi Türkiye'deki tipik kullanım senaryolarıyla birlikte veriyor.
Maliyet: görsel token'a nasıl çevriliyor
İki sağlayıcı iki farklı yöntem kullanıyor ve fark, mimari kararınızı doğrudan etkiliyor.
Gemini tarafında hesap basit ve tahmin edilebilir (bkz. Google AI for Developers, Image understanding): her iki boyutu 384 pikselin altında olan görseller 258 token tutuyor. Daha büyük görseller 768x768 piksellik karolara bölünüyor ve her karo yine 258 token. Kırpma birimi floor(min(genişlik, yükseklik) / 1.5) formülüyle hesaplanıyor; her boyutu bu değere bölüp çarpınca karo sayısını buluyorsunuz. İstek başına 3.600 görsele kadar gönderilebiliyor.
OpenAI tarafında iki yöntem var (bkz. OpenAI, Images and vision). Yama tabanlı modellerde görüntü 32x32 piksellik yamalarla kaplanıyor, yama sayısı hesaplanıp model çarpanıyla (tipik olarak 1,2) çarpılarak faturalanacak token bulunuyor. Karo tabanlı modellerde taban token sayısına her 512x512 karo için ek token ekleniyor; detail: low verilirse görsel boyutundan bağımsız olarak yalnızca taban token ödeniyor, detail: high veya auto ise görsel önce 2048x2048'e sığacak şekilde ölçekleniyor. İstek başına sınırlar: 512 MB toplam yük, 1.500 görsel, yeniden boyutlandırma sonrası görsel başına en fazla 30.000 yama.
Buradan çıkan tek pratik kural: görselleri modele göndermeden önce siz ölçekleyin. A4 bir faturayı 300 DPI taramadan olduğu gibi göndermek, ihtiyacınız olmayan çözünürlük için karo başına token ödemek demek. Okunabilirliği koruyan en küçük çözünürlüğü deneyerek bulun; bu tek optimizasyon çoğu belge işleme hattında maliyeti kat kat düşürüyor.
Metin tarafındaki fiyatlar da denklemin parçası. Claude tarafında güncel modellerin tamamı görüntü girdisi destekliyor ve milyon token başına ücretler şöyle: Fable 5.1 için 10 $ girdi / 50 $ çıktı, Opus 5.5 için 4 $ / 20 $, Sonnet 5 için 2 $ / 10 $, Haiku 4.5 için 1 $ / 5 $ (bkz. Claude platform dokümanları, Models overview). Belge işleme gibi hacimli ve tekdüze işlerde en pahalı modeli seçmek nadiren doğru karar; önce küçük modelle ölçün.
Dokümanların kendi yazdığı sınırlamalar
OpenAI'ın vision rehberi modellerin neyi iyi yapamadığını açıkça sayıyor. Bu liste, bir proje kapsamını daraltmak için en değerli tek kaynak:
- Tıbbi görüntü yorumlama.
- Latin olmayan alfabedeki metin (Japonca, Korece örnek veriliyor).
- Küçük veya döndürülmüş metin.
- Farklı renk ve stillerdeki grafiklerin anlaşılması.
- Hassas konumlandırma gerektiren işler.
- Panoramik ve balıkgözü görüntüler.
- Doğru nesne sayımı.
- CAPTCHA çözümü (bilinçli olarak engellenmiş).
Bu listedeki iki madde Türkiye'deki tipik projeleri doğrudan vuruyor. Küçük veya döndürülmüş metin: elde tutulan telefonla çekilmiş fatura ve fiş fotoğrafları neredeyse her zaman eğik. Doğru nesne sayımı: raf denetimi, palet sayımı ve stok kontrolü senaryolarının tam merkezinde sayım var. Bu iki iş için VLM tek başına yeterli değil; ön işleme (döndürme düzeltmesi, kırpma) ve sayım için ayrı bir tespit modeli gerekiyor.
Koordinat çıktısını doğru okumak
Nesne tespiti yaptırıyorsanız çıktı biçimi sabit ve alışılmışın dışında. Gemini dokümanı sınırlayıcı kutuları [ymin, xmin, ymax, xmax] biçiminde ve 0-1000 aralığına normalize edilmiş olarak döndürüyor. Yani koordinatlar orijinal piksel değerleri değil; kendi görselinizin boyutuna göre geri ölçeklemek zorundasınız.
# Gemini'nin döndürdüğü kutu: [ymin, xmin, ymax, xmax], 0-1000 normalize.
def piksele_cevir(kutu, genislik, yukseklik):
ymin, xmin, ymax, xmax = kutu
return {
"x1": int(xmin / 1000 * genislik),
"y1": int(ymin / 1000 * yukseklik),
"x2": int(xmax / 1000 * genislik),
"y2": int(ymax / 1000 * yukseklik),
}
# Dikkat: sıra [y, x, y, x]. Alışkanlıkla [x1, y1, x2, y2] varsayan kod
# kutuları 90 derece dönmüş gibi çiziyor ve hata sessiz kalıyor.
print(piksele_cevir([120, 300, 480, 760], 1920, 1080))
# {'x1': 576, 'y1': 129, 'x2': 1459, 'y2': 518}
Segmentasyon istediğinizde poligon maskeleri de aynı 0-1000 normalizasyonuyla geliyor. Görselleştirme katmanınızı yazarken bu dönüşümü tek bir yardımcı fonksiyonda toplayın; kod tabanına dağılan dönüşümler, koordinat sırası hatasının en sık kaynağı.
Belge okumada VLM mi, klasik OCR mı?
Karar, belgenin ne kadar yapılandırılmış olduğuna bağlı.
| Senaryo | Yaklaşım | Gerekçe |
|---|---|---|
| Tek tedarikçiden gelen, hep aynı şablonda fatura | Klasik OCR + konum kuralı | Deterministik, ucuz, açıklanabilir; model çağrısına gerek yok |
| Yüzlerce farklı şablonda fatura ve fiş | VLM + şema doğrulama | Kural yazmak imkânsız; modelden yapılandırılmış JSON isteyin |
| Elle doldurulmuş form | VLM + insan onayı | El yazısı belirsizliği; otomatik onay riskli |
| Raf/stok sayımı | Ayrı tespit modeli | Doküman, doğru nesne sayımını zayıf yön olarak sayıyor |
| Sayaç endeksi okuma | VLM + iki kaynaklı doğrulama | Tek hane hatası faturaya yansıyor; önceki endeksle tutarlılık kontrolü şart |
Hangi yolu seçerseniz seçin, çıktıyı şema ile doğrulayın. Model "toplam tutar" alanına metin döndürebiliyor; tip zorlaması yapmadan veritabanına yazan hatlar, hatayı aylar sonra mutabakatta buluyor. Ayrıca her çıkarım için güven eşiği koyun ve eşiğin altındakileri insan kuyruğuna alın; tam otomasyon hedefi, hatanın maliyetini ölçmeden konulmamalı.
KVKK: görselin içinde ne var?
Belge fotoğrafları çoğu zaman düşünülenden fazla veri taşıyor. Bir fatura fotoğrafının kenarında kimlik kartı, bir form taramasının üstünde sağlık raporu bulunabiliyor. Sağlık verisi, biyometrik veri ve ceza mahkûmiyeti gibi kategoriler KVKK'nın 6. maddesi kapsamında özel nitelikli kişisel veri ve işlenmeleri ayrı şartlara bağlı.
Üç pratik önlem. Görseli modele göndermeden önce ilgisiz bölgeleri kırpın; sağlayıcıya gönderim öncesi bir sınıflandırma adımı koyup beklenmeyen belge tiplerini durdurun; ve KVKK md. 12 kapsamındaki teknik tedbirler için sağlayıcıyla olan sözleşmenizde veri saklama süresini netleştirin. Yurt dışındaki bir modele gönderim yapıyorsanız aktarım boyutunu da değerlendirin.
Pilot için ölçülecek üç şey
Elli gerçek belgeyle başlayın ve şunları ölçün: alan bazında doğruluk (toplam tutar ayrı, tarih ayrı, vergi numarası ayrı), belge başına ortalama token maliyeti, ve insan onayına düşen yüzde.
Üçüncü sayı, projenin gerçek getirisini belirleyen tek metriktir. %40'ı insana düşen bir hat, tam otomasyon vaadinden çok uzaktır ama yine de kazandırıyor olabilir; bunu bilmenin yolu ölçmekten geçiyor.
Model entegrasyonunun genel tarafı için prompt engineering, otonom akışlar için AI agent'lar, kurum içinde model çalıştırma için yerel LLM kurulumu yazılarına bakabilirsiniz. Hizmet kapsamımız yapay zekâ ve chatbot sayfasında, veri tarafı veri analitiği sayfasında; kapsam için iletişim sayfasından yazabilirsiniz.
Token hesaplama yöntemleri ve istek limitleri 25 Eylül 2026'da Google AI for Developers "Image understanding" ve OpenAI "Images and vision" dokümanlarından; model fiyatları Claude platform dokümanlarının "Models overview" sayfasından; özel nitelikli veri tanımı 6698 sayılı Kanun'un 6. maddesinden doğrulanmıştır. Türkçe belgeler üzerinde karşılaştırmalı doğruluk oranı verilmemiştir; yayımlanmış birincil ölçüm bulunamamıştır. Kod örneği bir dönüşüm iskeletidir.
