Microsoft Build’de Görüntü Çevirisi: Artık Belgeler Sadece PDF Değil
İşin özeti: artık görsel de çevriliyor
Microsoft Build 2026 tarafında duyurulan güncellemeye ilk baktığımda aklıma şu geldi: “Nihayet.” Çünkü yıllardır kurumlarda aynı döngüyü görüyorum; belge çevirisi var, iyi güzel,. Iş resimlere, taranmış dokümanlara, ürün etiketlerine ya da ekran görüntülerine gelince ekipler başka araçlara savruluyor. Sonra kalite düşüyor, süreç uzuyor, bir yerde insan eli devreye giriyor ve otomasyonun tadı kaçıyor. Kısacası tanıdık hikâye.
Dürüst olmak gerekirse, Yeni gelen şey tam olarak bu boşluğu kapatmaya çalışıyor. Azure Translator, Foundry Tools içinde Document Translation yeteneklerini genişletiyor. Artık yalnızca klasik dokümanları değil, doğrudan görsel dosyaları da çeviriyor. Hem de bazı senaryolarda anlık, bazı senaryolarda toplu işleme ile (yanlış duymadınız). Kağıt üstünde basit dürüyor ama pratikte baya iş gören bir hamle bu.
Küçük bir detay: Benim burada en çok dikkatimi çeken nokta hız değil sadece; akışın bozulmaması. Yanı müşteri destek ekibi bir ekran görüntüsü alıp çeviri beklemiyor, pazarlama ekibi katalog görsellerini başka sisteme taşımıyor, operasyon tarafı da “bu dosya önce OCR’a gitsin, sonra çeviri motoruna gelsin” diye üç ayrı adım arasında boğulmuyor. İş biraz daha düzleşiyor. Hatta şaşırtıcı biçimde rahatlıyor bile.
Geçen yıl İstanbul’da bir perakende müşterisinde benzer bir ihtiyaç çıkmıştı. Ürün ambalajlarındaki uyarılar farklı dillere çevrilecekti ama kaynakların yarısı görseldi; JPEG’ler, PNG’ler, taranmış broşürler… O zaman kullandığımız çözüm idare ederdi ama uğraştırdı. Şimdi bu yeni yaklaşımı görsem muhtemelen daha temiz bir mimarı kurardım. Evet.
Senkron görüntü çevirisi neden önemli?
Senkron modelin olayı şu: dosyayı gönderiyorsunuz, servis işlemi yapıyor ve size çevrilmiş görseli hemen dönüyor. Bu kadar. Bilhassa canlı önizleme isteyen uygulamalarda güzel çalışır. Mesela bir destek portalında kullanıcı ekran görüntüsünü yüklüyor; sistem hem metni çıkarıyor hem çeviriyor hem de aynı kompozisyonla geri veriyor. Kullanıcı için “çalıştı mı çalışmadı mı” sorusu ortadan kalkıyor.
Bu tarz kullanım bana 2019’da Ankara’daki bir kamu projesinde yaşadığımız sıkıntıyı hatırlattı. Orada form taramaları vardı ve kullanıcılar bazen tek sayfalık belgeleri anlık görmek istiyordu (ciddiyim). Biz arka planda kuyruk sistemi kurmuştuk ama o dönemki ihtiyaç yüzünden bekleme süresi bile tartışma konusu olmuştu. Şimdi böyle senaryolarda senkron seçenek ciddi rahatlık verir; tabiî küçük dosyalarda.
İtiraf edeyim, Tabi her şey güllük gülistanlık değil. Senkron yapı küçük dosyalarda çok tatlıdır ama büyük hacimde biraz can sıkabilir. Eğer elinizde yüzlerce görsel varsa tek tek beklemek yerine batch tarafına kaymak daha mantıklı olur. Bakın şimdi burada asıl karar noktası teknik değil; operasyonel ihtiyaç (şaşırtıcı ama gerçek)
Bu güncellemenin en değerli yanı “çeviri”yi ayrı bir adım olmaktan çıkarıp doğrudan iş akışının içine koyması. Kurumlar için fark yaratan şey çoğu zaman modelin ne kadar zeki olduğu değil, sürecin ne kadar az sürttüğü.
Nerede iyi çalışır?
Tuhaf ama, Kısa cevap: müşteri destek ekranları, canlı lokalizasyon önizlemeleri, mobil uygulamalar içinde anlık içerik gösterimi ve düşük hacimli operasyonlar. En çok da kullanıcı deneyimi odaklı ekiplerde çok iş yapar.
Daha açık konuşayım; startup tarafında bunu hızlıca denersiniz ve sonuç alırsınız. Ama enterprise tarafta mesele sadece sonuç değil — loglama var mı, veri saklama politikası ne diyor, PII içeren görseller nasıl ayrıştırılıyor? İşte orada işler uzar biraz.
Batch çeviri: ölçek lazım olduğunda sahneye çıkıyor
Bir de batch/asenkron taraf var ki asıl kurumsal kaş burada belli oluyor. Görselleri Azure Blob Storage’a koyuyorsunuz, servis arkada işliyor ve sonuçları hedef konteynıra yazıyor. Bu model bana hep lojistik bandını hatırlatır; mal geliyor, ayrıştırılıyor, paketleniyor ve başka hatta aktarılıyor. İnsan eli minimumda kalıyor.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimsenme biçimi biraz farklı oluyor çünkü şirketler önce “tek tıkla olsun” istiyor ama veri büyüdükçe o romantizm bitiyor. Sonra maliyet konuşuluyor, SLA konuşuluyor, süre konuşuluyor… Tahmin eder mısınız? En sonunda batch işlem mantığına dönülüyor zaten.
Logosoft tarafında geçen sene bir finans kuruluşuyla yaptığımız çalışma vardı; rapor ekleri içinde onlarca taranmış evrak dolaşıyordu. Görsel tabanlı içeriklerin tamamını manuel kontrol etmek ciddi zaman yiyordu. Böyle durumlarda toplu işleme yaklaşımı fena hâlde kurtarıcı oluyor çünkü çalışanların önüne düzenli çıktı düşüyor ve entegrasyon tarafı sade kalıyor (evet, doğru duydunuz)
| Kullanım Senaryosu | Senkron | Batch |
|---|---|---|
| Canlı önizleme | Evet | Hayır |
| Büyük arşiv taraması | Zayıf kalır | Evet |
| Müşteri destek akışı | Çok uygun | Bazen gereksiz ağır |
| Katalog / eğitim verisi | Anlamsız olabilir | Tam isabet |
Küçük ekip mi büyük kurum mu?
Küçük ekipseniz fazla mimarı kurmayın derim; doğrudan servis çağrısı ile başlayın, kullanım örneğini görün ve sonra genişletin. Büyük kurumsal yapıdaysanız blob tabanlı batch işleme ile ilerleyip kuyruklar, retry mekanizması ve gözlemlenebilirlik katmanını en baştan düşünmek gerekir. Yoksa sonra toparlamak zorlaşıyor.
Maliyet meselesi: kağıt üstünde küçük görünen kalemler büyüyebilir
E tabi fiyat kısmı da önemli. Bu tür servislerde “bir çağrı ne olacak ki?” demek kolaydır ama binlerce görsel söz konusu olunca tablo değişir. Azure Translator fiyatlandırmasını TL bazında düşününce özellikle döviz kuru etkisi hemen hissedilir; yanı pilot aşamada hoş duran maliyet üretime geçince başka konuşulur.
Ben AZ-305 hazırlığında hep şunu tekrar ederdim: mimarı kararların %50’si teknikse kalan %50’si para yönetimiyle ilgilidir. Burada da durum aynı; yüksek çözünürlüklü ürün görsellerini sürekli çevirmek yerine hangi dosyaların gerçekten çevrilmesi gerektiğini ayıklamak ciddi tasarruf sağlar. Fazlasını açınca bütçe sessiz sessiz şişer.
Maliyet düşürmek için pratik yaklaşım
- Sadece gerekli dil çiftlerini açın.
- Düşük değerli test görüntülerini üretime sokmayın.
- Büyük arşivlerde önce örneklem alın.
- Aynı içeriği tekrar tekrar çevirmeyin; cache mantığı düşünün.
Mimaride dikkat edilmesi gereken ince noktalar
Açık söyleyeyim; bu özellik güzel. Henüz ham sayılır gibi hissettiriyor bazı yönleriyle (özellikle çok karmaşık yerleşimli görsellerde). Metin kutuları birbirine giriyorsa ya da arka plan yoğun işe kalite dalgalanabiliyor olabilir — bunu sahada görmek lazım dedirtiyor insana. Biraz öyle yanı.
Ayrıca güvenlik tarafını atlamamak gerekiyor. Görsel içinde kişisel veri varsa ne — itiraz edebilirsiniz tabi — oluyor? Hangi bölgeye gidiyor? Saklama süresi ne? Bunlar sorulmadan yapılan entegrasyon sonradan baş ağrıtır. Ben AZ-500 çalışmalarında hep aynı şeyi anlatırım: veri nereden geliyor değil sadece,nereye gidiyor önü da bilmek zorundasınız.
Bir de hata kısmı var ya hani… İlk kez buna benzer bir serviste test yaparken yanlış MIME tipi göndermiştim. Saçma bir yanıt almıştım; sorun kodda değil istek paketindeydi aslında dur bir saniye — çoğu kişi burada modeli suçluyor ama mesele genelde input formatıdır! Küçük detay gibi görünür ama tüm günü yer. Sız hiç denediniz mi? Cidden öyle.
import requests
from pathlib import Path
endpoint = "DOCUMENT_TRANSLATION_ENDPOINT"
key = "DOCUMENT_TRANSLATION_KEY"
imagefile_path = Path("./image_file.jpg")
response = requests.post(
f"{endpoint}/translator/document:translate",
params={
"api-version": "2026-03-01",
"sourceLanguage": "en",
"targetLanguage": "de",
},
headers={"Ocp-Apim-Subscription-Key": key},
files={
"document": (
imagefile_path.name,
imagefile_path.open("rb"),
"application/json",
)
},
)
response.raise_for_status()
Path("./image_file_de.jpg").write_bytes(response.content)Bence nereden başlanmalı?
Lafı gevelemeden söyleyeyim: önce tek bir kullanım senaryosu seçin. Mesela müşteri destek ekibinin yüklediği ekran görüntülerini çevirme işiyle başlayın; sonra kataloglara geçersiniz; en son eğitim materyallerine bakarsınız. İlk adım bu kadar net aslında.
İkinci adım olarak loglama kurun çünkü hata çıktısını okumadan ilerlemek kör uçuş gibi olur. İnanın buna bakmadan yürüyen ekiplerin sonu pek parlak olmuyor,sonra herkes birbirine soru sorup dürüyor.
Üçüncü adımda da maliyet takibini açın — yoksa iki hafta sonra “bu neden bu kadar tuttu?” diye bakarsınız şaşkın şaşkın. Sonrası malum,küçük görünen konu büyür gider.
Benden kısa değerlendirme: güzel haber ama ölçülü heyecan lazım
Bence Microsoft’un yaptığı şey doğru yönde atılmış sağlam bir adım. Çünkü işletmeler artık yalnızca metin değil bağlam taşıyan içerik üretiyor ve bağlam çoğu zaman resmin içinde saklı dürüyor. Bu ne anlama geliyor? Bunu yakalayamayan çeviri çözümleri eksik kalıyordu; açık konuşayım,mesele tam olarak bu.
Neyse uzatmayayım; benim kişisel kanaatim şu: küçük ekipler için hızlı kazanım sağlar, enterprise ortamda işe ancak doğru governance ile anlam kazanır. Governance yoksa her yeni özellik biraz parlak oyuncak gibi kalır,sonra rafta tozlanır. Sız ne dersiniz?
Bir arkadaşım Rotterdam’daki lojistik firmasına benzer bir şey denediğinde ilk ay oldukça memnun kaldığını anlatmıştı;. İkinci ayda kontrol mekanizması eksik olduğu için — en azından ben öyle düşünüyorum — çıktıların tutarlılığı tartışma konusu olmuştu. Yanı teknoloji tek başına yetmiyor,iş akışıyla birlikte düşünmek gerekiyor: Tam da öyle.
Sıkça Sorulan Sorular
Document Translation hangi görsel dosyaları çevirebiliyor?
Daha açık söyleyeyim, küçük bir detay: Hem senkron hem de batch senaryolarında görsel dosyalar destekleniyor. Bence en temiz sonucu, metni net olan JPEG ve PNG gibi dosyalarda alıyorsunuz. Taranmış belgelerde işe kalite, kaynak görüntünün ne kadar temiz olduğuna bağlı —. Sız hiç denediniz mi? Kaynağınız bulanıksa çıktıdan çok şey beklemeyin.
Senkron ile batch arasındaki fark ne?
Senkron yöntem anlık sonuç veriyor, batch işe çok sayıda dosyayı arka planda işliyor. Hani anlık önizleme istiyorsanız senkron daha mantıklı, arşiv veya katalog gibi toplu işlerde işe batch çok daha uygun. Tecrübeme göre ikisini karıştırmaya gerek yok, senaryonuza göre birini seçin yeter.
Bu özellik ekstra maliyet çıkarır mı?
Evet, görsel çeviri ek işlem yükü oluşturuyor. Açıkçası yüksek hacimde kullanacaksanız fiyatlandırmayı önceden hesaplamak çok önemli. Pilot ortamda küçük başlamak bence her zaman en güvenlisi.
Her senaryoda aynı kaliteyi alabilir mıyım?
Hayır, maalesef değil. Düzgün hizalanmış metinlerde sonuç oldukça iyi oluyor, ama karmaşık tasarımlarda kalite değişebiliyor. Mesela arka plan yoğunluğu veya yazı tipinin okunaksız olması sonucu doğrudan etkiliyor.
Kaynaklar ve İleri Okuma
Şunu fark ettim: Microsoft Dev Blog — Document Translation Build Duyurusu
Azure AI Translator — Document Translation Resmî Dokümantasyonu
Tuhaf ama, Azure AI Vision Resmî Dokümantasyonu
Azure AI Services Fiyatlandırma Sayfası
Bu konunun Foundry tarafındaki geniş resmini görmek isterseniz Foundry Local ile Uçta Yapay Zekâ: Bulut Dışı Hızın Gerçek Yüzü yazısına da bakabilirsiniz (inanın bana)
Model seçimiyle maliyet dengesini birlikte okumak isteyenler için Foundry’de Model, Maliyet (buna dikkat edin). Kaliteyi Ben Nasıl Yönetiyorum? yazısı faydalı olur.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder