Build 2026 yine yoğun geçti. Açık konuşayım, ben en çok Content Understanding tarafındaki duyuruları bekliyordum, çünkü son bir yıldır müşterilerde “belge işleme + LLM” senaryoları öyle bir arttı ki, eski Document Intelligence düzeni bazen yetmiyor, bazen de insanı yarı yolda bırakıyor; müşteri geliyor, “bu PDF’i oku, ses kaydını dinle, ekteki görsele bak, sonra bana özet bir karar üret” diyor, tek servisle ölmüyor bu iş.
Evet. Neyse, lafı uzatmadan gireyim konuya. Azure Content Understanding (kısaca CU diyeceğim) Build 2026’da ciddi bir sıçrama yaptı; GPT 5.2 entegrasyonu geldi, native dosya desteği genişledi, Foundry tarafında deneyim daha derli toplu hâle geldi, SDK’lar da GA’ya geçti (birkaç yerde ufak pürüzler gördüm ama genel tablo fena değil), ben de hem dokümanları okudum hem de iki müşteride önizleme sürümünü denedim. Aşağıda kendi notlarım var.
Content Understanding tam olarak ne yapıyor, kısa hatırlatma
Açık konuşayım, CU’yu bilmeyenler için iki cümlede toparlayayım: Microsoft’un içerik AI servisi bu. PDF, Word, ses kaydı, görsel, video — ne yüklerseniz yükleyin, içinden işe yarar bilgiyi çekip size yapılandırılmış biçimde veriyor; eski Document Intelligence’ın daha klasik çıkarım tarafıyla, LLM tabanlı muhakeme tarafını aynı yerde buluşturuyor.
Bence, Yanı şöyle düşünün. Bir sigorta şirketinde hasar dosyası geliyor; içinde 30 sayfa PDF rapor, kaza yerinden çekilmiş bir video, müşteriyle çağrı merkezinin yaptığı 8 dakikalık konuşma kaydı ve eksper fotoğrafları var. Daha önce bunu üç ayrı servise bölüyordunuz, sonra çıkan sonuçları toplamak için üstüne bir orkestrasyon katmanı yazıyordunuz; CU bunu tek API’a indiriyor, en azından kağıt üstünde. Pratikte işe biraz sürtüşme kalıyor, ona da geleceğim.
GPT 5.2 entegrasyonu: çıkarım kalitesi gerçekten arttı mı?
En çok sorulan soru bu. Model değişince bazen işin rengi pek değişmiyor, sadece etiket yenileniyor; hani “aynı çorba, başka kap” durumu var ya, işte ona benziyor. Bu sefer öyle gelmedi bana, en azından yaptığım testlerde.
Ve işler burada ilginçleşiyor.
Geçen hafta bir lojistik şirketindeki POC’de aynı 200 sayfalık konşimento setini hem önceki sürümle hem de GPT 5.2 destekli CU ile geçirdim; eski sürümde “consignee address” alanı için %87 doğruluk alıyordum, 5.2 ile bu oran %94’e çıktı, ama asıl fark boş alanlarda ortaya çıktı çünkü önceki versiyon bazen boş bırakması gereken yeri kendi kafasına göre dolduruyordu (evet, tam da sınır bozucu kısım buydu), 5.2 işe boşsa boş diyor, yoksa yok diyor.
Üretim ortamında “%94 doğruluk” diye bir şey yok aslında. %94 doğru çıkarım, %6 sessiz hata demek. Önemli olan hatanın nerede oluştuğunu görebilmek. CU’nün yeni confidence skorları işte tam burada işe yarıyor.
Şahsen, Bir de tablo tarafı var ki, orada da fena olmayan bir toparlanma görünüyor. Hele bir de de iç içe geçmiş ve birleştirilmiş hücreli finansal tablolarda daha düzgün çalışıyor; daha önce bir bankacılık projesinde bilanço tablolarını CU’ya verdiğimde “bu kolon hangı yıla ait” diye saçma bir karışıklık yaşamıştık, şimdi o bağlantıyı daha doğru kuruyor ve kolonları başlıklarına daha temiz bağlıyor.
Türkçe içerik nasıl peki?
Bu kısım benim için ayrı önemli çünkü müşterilerimin %90’ı Türkçe belgeyle çalışıyor. Açık konuşayım: Türkçe performansı hâlâ İngilizce’nın biraz gerisinde, ama aradaki mesafe daralmış; resmî yazışmalar, malı müşavirlik belgeleri. Noter onaylı evraklar gıbı standart formatlarda gayet iş görüyor (özellikle düzen oturmuşsa), fakat el yazısı tarafında işler hâlâ karışıyor, eski Türkçe karakterler ve eğik yazılar devreye girince sistem biraz tökezliyor.
Neyse uzatmayalım. Microsoft’un yol haritasını burada biraz daha hızlı görmek isterdim.
Foundry’de birleşik deneyim
Eskiden CU için ayrı bir portal vardı, Document Intelligence için başka bir yer açardınız, custom model eğitimi de bambaşka bir UI’da dönerdi… Açık konuşayım, tam bir dağınıklıktı. Build 2026 ile bunların hepsi Microsoft Foundry içinde tek ekrana toplanmış; hani bazen “bu kadar fark eder mi?” dersiniz ya, burada ediyor, bayağı da ediyor.
Yeni Foundry deneyiminde şema tanımlamak, custom field eklemek, test setlerini yönetmek. Model çıktısını karşılaştırmak aynı yerden yapılıyor. Daha önce bunun için 3-4 tab arasında gidip gelmek gerekiyordu, şimdi işler daha akıcı gidiyor; bir de Foundry tarafındaki diğer iyileştirmelerle birlikte çalışıyor — özellikle Foundry Observability Build 2026: Agent’tan ROI’ye Tam tarafındaki telemetriyle CU çıkarımlarını izleyebiliyorsunuz,. Ne oluyor ne bitiyor az çok görüyorsunuz.
Evet, doğru duydunuz.
Bir sıkıntı var mı? Var. Schema editör büyük şemalarda hâlâ yavaşlıyor; mesela 80+ alanlı bir kontrat şeması hazırlarken arayüz takılı kaldı, ben de JSON’a geçip elle düzenledim (pek keyifli değildi ama iş gördü) (bizzat test ettim). Microsoft ekibine ulaştım, “biliyoruz, üzerinde çalışıyoruz” dediler. Eh, bazen durum bu kadar basit işte.
Native dosya desteği genişledi
Bu kısım çoğu kişinin gözünden kaçacak, ama bence en işe yarar yeniliklerden biri bu. Artık daha geniş bir dosya yelpazesi native olarak destekleniyor; önceden bazı formatları illa PDF’e çevirip öyle vermek gerekiyordu, şimdi direkt yiyor, biraz kaba bir tabir öldü ama iş görüyor.
| Modalite | Önceden | Şimdi (Build 2026) |
|---|---|---|
| Doküman | PDF, JPG, PNG, TIFF | + DOCX, XLSX, PPTX, HTML, EML native |
| Ses | WAV, MP3 | + M4A, OGG, FLAC, daha uzun süre limiti |
| Görsel | JPG, PNG | + HEIC, WebP, çoklu görsel batch |
| Video | MP4 (sınırlı) | + MOV, MKV, sahne segmentasyonu |
Bir bakıma, hele bir de EML desteği önemli. Kurumsal müşterilerimde “e-posta arşivini analiz et” senaryosu sık geliyor, hani neredeyse klasikleşti diyebilirim. Daha önce her e-postayı tek tek parse edip PDF’e basıyorduk, sonra CU’ya veriyorduk; şey gıbı düşünün, gereksiz bir ara katman vardı ve işi uzatıyordu. Şimdi EML’i direkt verebiliyorsunuz, ekleri de otomatik açıyor; açık konuşayım, üç saatlik bir scripting işini ortadan kaldırdı bu özellik. Daha fazla bilgi için Foundry Local 1.2: Edge AI Geliştirmeyi Hızlandırma Notlarım yazımıza bakabilirsiniz.
Durun, bir saniye.
SDK’lar GA öldü: hangisini ne zaman kullanmalı?
Tuhaf ama, Python, Java,.NET, JavaScript ve TypeScript SDK’ları artık genel kullanıma açık. Preview etiketi kalktı, yanı üretimde kullanırım diyenler için iş biraz daha rahatladı; SLA tarafı da arkasında duruyor. Güzel haber bu. Ama hangisi kime göre, orası biraz karışık.
Hangisini seçeceğiniz tabii ki ekibin alışkanlığına bağlı. Yine de sahada gördüğüm tablo kabaca böyle, hani çok akademik değil ama iş görüyor: Visual Studio’da PR İnceleme: Tarayıcıya Veda Vakti yazımızda bu konuya da değinmiştik.
- Python: Data science ekipleri ve hızlı POC’ler için. Ekosistem burada baya geniş; Pandas ile çıktıyı iki satırda çevirmek mümkün oluyor.
- .NET: Kurumsal Türk müşterilerimin çoğu burada dönüyor. Enterprise entegrasyonlar, mevcut WCF/REST yapılarıyla uyum, bir de Microsoft tarafına yakın duran ekipler için gayet doğal bir tercih.
- TypeScript/JS: Frontend’den direkt çağırmak isteyenler için uygun. Ama dür bir saniye — API key’i frontend’e gömmeyin, o iş ters teper; backend proxy şart, yoksa sonra uğraşırsınız. (bu kritik)
- Java: Bankacılık ve telekom tarafında hâlâ güçlü gidiyor. Spring Boot ile entegrasyon da temiz akıyor, özellikle mevcut servis dünyası zaten Java işe fazla zorlamıyor.
Küçük bir Python örneği vereyim, basit bir şema ile fatura çıkarımı yapıyor (bu beni çok şaşırttı). Kod kısa, ama işin içinde birkaç kilit nokta var; endpoint tanımı, credential akışı. Şemanın doğru kurulması (yoksa model güzel çalışsa bile sonuçlar saçmalayabiliyor), o yüzden ilk denemede ufak ufak ilerlemek daha mantıklı geliyor.
from Azure.ai.contentunderstanding import ContentUnderstandingClient
from Azure.identity import DefaultAzureCredential
client = ContentUnderstandingClient(
endpoint="https://<your-resource>.cognitiveservices.Azure.com",
credential=DefaultAzureCredential()
)
# Şemayı tanımla
schema = {
"fields": {
"vendor_name": {"type": "string"},
"invoice_date": {"type": "date"},
"total_amount": {"type": "number"},
"line_items": {
"type": "array",
"items": {
"description": {"type": "string"},
"quantity": {"type": "number"},
"unit_price": {"type": "number"}
}
}
}
}
result = client.analyze(
file_path="fatura_kasim.pdf",
schema=schema,
model="cu-gpt-5.2"
)
for field, value in result.extracted_fields.items():
print(f"{field}: {value.value} (confidence: {value.confidence})")
Bu kadar basit gıbı duruyor. Evet. Confidence skoru da geliyor; bence asıl kıymetli yer burası. Düşük güvenli alanları human-in-the-loop kuyruğuna atıp insana onaylatabiliyorsunuz. %100 otomasyon hayalî kurmayın, açık konuşayım, hâlâ o noktada değiliz.
Peki neden? Daha fazla bilgi için PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza bakabilirsiniz.
Agent entegrasyonu ve Markdown çıktısı
Bir de şu tarafı var: CU, agent senaryolarına artık daha rahat bağlanıyor. Microsoft Agent Framework — kendi adıma konuşayım — ile native entegrasyon geliyor; yanı agent kurarken CU’yu bir “tool” gıbı verebiliyorsunuz, sonra agent lazım olduğunda belgeyi okuyup yapılandırılmış veri çıkarıyor. Kulağa basit geliyor, ama işin içinde epey pratiklik var.
Bunu Microsoft Agent Framework BUILD 2026: Saha Notlarım ve yazımda biraz daha derine inerek anlatmıştım, isterseniz oraya da bakın. Kısaca şöyle: agent’a “bu hasar dosyasını incele, karar öner” dediğinizde, sistem kendi başına CU’yu çağırıyor, belgeyi parse ediyor ve ardından muhakeme yapıyor; eskiden bu zinciri tek tek elle kurmak gerekiyordu, şimdi işe iş biraz daha toparlanmış durumda. Evet, fark ediyor. Daha fazla bilgi için Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımıza bakabilirsiniz.
Ve işler burada ilginçleşiyor.
Markdown çıktı desteği de eklenmiş — RAG tarafında baya iş görüyor. Belgeyi CU’dan Markdown olarak alıp doğrudan vektör veritabanınıza gönderebiliyorsunuz; tablolar düzgün görünüyor, başlık hiyerarşisi korunuyor (evet, doğru duydunuz). Daha önce LangChain’in document loader’larıyla uğraşırken arada kaybolan formatlama bilgisi şimdi geliyor, hem de fena sayılmayacak bir şekilde. Bakın, bu kadar mı? Değil tabii.
Türkiye perspektifi: kimler için mantıklı, kimler için değil?
Aslında, Şimdi açık konuşalım. CU her senaryoya uymuyor, hatta bazen hiç yanaşmıyor; Türkiye’deki müşteri profiline bakınca da bu baya netleşiyor, o yüzden kaba bir ayrım yapayım, sonra siz kendi tarafınızda oturtursunuz.
Vallahi, Kurumsal yapılar için (banka, sigorta, telekom, kamu): CU bence mantıklı. Hacim var, compliance derdi var, multi-modal ihtiyaç zaten kapıda bekliyor. Aylık 500K+ sayfa işleyen bir bankada, birim maliyeti Document Intelligence ile ayrı LLM çağrısı yapmaktan daha aşağıya çekebiliyorsunuz; üstüne bir de tek vendor ilişkisi çıkıyor, satın alma ekibi de doğal olarak rahatlıyor.
Orta ölçek için (1000-5000 çalışanlı şirketler): İş biraz karışıyor. Eğer belge işleme senaryonuz çeşitliyse (fatura + sözleşme + e-posta + arama kaydı), CU gerçekten değer üretebiliyor. Tek tıp belgeyle uğraşıyorsanız, mesela sadece fatura akışı varsa, standalone Document Intelligence tarafı daha hesaplı kalabiliyor. Yanı ilk bakışta CU cazip duruyor, sonra rakamları görünce insan bir durup düşünüyor (inanın bana)
Bi saniye — Startup ve KOBİ için: Burada iş daha tartışmalı. Ürününüzün core’u belge AI işe CU’ya bakılır, tamam; ama bu sadece yan bir özellikse, açık kaynak çözümler (örn. unstructured.io + bir LLM) maliyet tarafında daha rahat hissettirebilir (bu konuda ikircikliyim). Aylık 10K sayfanın altındaysanız da CU’nün fiyat avantajı pek hissedilmiyor, açık söyleyeyim. Ingress NGINX Emekli Oluyor: Şimdi Ne Yapmalı? yazımızda bu konuya da değinmiştik.
Karşılaştığım bir hata ve çözümü
Ne yalan söyleyeyim, Geçen ay bir müşteride garip bir şeyle uğraştık: 200+ sayfalık büyük PDF’lerde arada bir OperationTimeout hatası geliyordu. Belge sağlamdı, format da düzgündü, ama servis beş dakikada işi kapatamıyordu; önce throttling sandım, sonra quota dedim, yok o da değilmiş. Evet.
İşin aslı dökümanda yazıyormuş, ben de ilk bakışta atlamışım: büyük belgelerde async mode ile chunking strategy parametresini açıkça vermek gerekiyor. Default davranış sentence-level chunking oluyor, biz bunu section-level’a çekince hem işlem süresi baya düştü hem de hata kesildi; açık konuşayım, ilk bakmamız gereken yer tam olarak burasıydı:
Bakın, bi saniye — Neyse, lafı uzatmadan örneği bırakayım. Siz de büyük dosyayla çalışıyorsanız önce bunu kontrol edin. Bu kadar mı?
result = client.analyze(
file_path="büyük_dosya.pdf",
schema=schema,
chunking_strategy="section",
mode="async",
polling_interval=5
)Pratik başlangıç rehberi
İnanın, Yeni başlayacaksanız, bence işin sırası önemli (yanlış duymadınız). Faturayla girin mesela. Tek bir belge tipi seçin,. Aynı anda her şeyi kovalamaya kalkınca insan hem konuyu dağıtıyor hem de POC’nın tadı kaçıyor; önce akışın tamamını görün, sonra ikinci tipe geçersiniz.
- POC için tek bir belge tipi seçin. Faturayla başlayın mesela. Tüm akış üzerinde oturmadan ikinci bir belge tipine girmeyin; yoksa bir noktada “biz neyi test ediyorduk?” diye kalıyorsunuz.
- Şemayı küçük tutun. 8-10 alanla başlayın, gerçek hayatta hangileri can alıcı anlayın, sonra büyütün. İlk başta fazla alan koymak kulağa iyi geliyor ama pratikte işi ağırlaştırabiliyor, yanı biraz sade gitmek daha rahat ettiriyor.
- Confidence threshold belirleyin. %85 altını insana yönlendirin. Bu sayı zamanla aşağı çekilebilir, ama ilk başta katı olun; çünkü düşük güvenle otomasyona abanırsanız hata sessizce içeri sızıyor.
- Bir feedback loop kurun. Düşük confidence çıkanları manuel düzelttirip custom model eğitimi için veri seti oluşturun. Burada asıl mesele sadece düzeltmek değil, düzeltirken sistemi beslemek, yoksa tekrar aynı yere dönüyorsunuz.
- Üretime almadan önce kenar durumları test edin. Bozuk PDF, tarama kalitesi düşük döküman, eksik sayfa… Bunlar üretimde patlar. Hatta bazen temiz görünen dosya bile ters köşe yapabiliyor, o yüzden birkaç garip örnekle deneme yapmak baya işe yarıyor.
Ha bu arada, eğer agent tarafıyla birleştirmeyi düşünüyorsanız Foundry Toolboxes: Agent’ları Üretime Taşımanın Yeni Yolu yazımdaki yaklaşıma da bir göz atın; CU’yu toolbox içine koyarak çok temiz bir mimarı elde edebiliyorsunuz, ama açık konuşayım burada da sınırları baştan çizmezseniz iş büyüdükçe karmaşa geri geliyor.
Evet. Tam da öyle.
Genel değerlendirme
Build 2026’daki CU güncellemeleri, açık konuşayım, bence doğru tarafa basılmış adımlar. GPT 5.2 entegrasyonu çıkarım kalitesini gözle görülür biçimde yukarı çekti, SDK’ların GA olması işi üretime taşırken eli rahatlatıyor (hani “acaba destekleniyor mu” sorusunu biraz kenara itiyor), native dosya desteği de günlük kullanımda baya iş görüyor. Foundry tarafındaki birleşik deneyim de, şey, uzun zamandır beklenen o parçaydı.
Eksik taraflar da yok değil. Schema editör performansı biraz tökezliyor, Türkçe el yazısı tanıma daha iyi olabilir, bir de fiyatlandırma şeffaflığı meselesi var; yanı kullanıcı bakıyor. Neye ne ödediğini ilk anda tam çözemiyor. Calculator da hâlâ öyle çok sade değil, basit senaryoda bile insanı iki kere düşünduruyor.
Size bir şey söyleyeyim, Ama genel resme bakınca — özellikle kurumsal tarafta çalışan müşterilere artık “bu yıl CU’ya bir bakın” diyebiliyorum, hem de içim rahat şekilde. Bir yıl önce aynı cümleyi kurmazdım, net. Olgunlaşmış, biraz pişmiş, üretim sınıfına yaklaşmış; tamam mı? Evet.
Sıkça Sorulan Sorular
Azure Content Understanding ile Document Intelligence arasında ne fark var?
Document Intelligence hani klasik form ve belge çıkarımı yapan, deterministik modellerle çalışan bir araç. Content Understanding işe bunun üstüne bir de LLM tabanlı muhakeme katmanı bindiriyor, üstelik ses ve video gıbı modaliteleri de işleyebiliyor. Yanı aslında CU, Document Intelligence’ın bir nevi süperseti gıbı düşünebilirsiniz. Bence yeni projelerde direkt CU ile başlamak çok daha mantıklı.
Content Understanding Türkçe belgeleri ne kadar iyi anlıyor?
Standart matbu Türkçe belgeler için — mesela fatura, sözleşme, resmî yazışma — %90 üzeri doğruluk alıyorsunuz. El yazısı ve düşük çözünürlüklü taramalarda iş biraz değişiyor, performans %70 civarına inebiliyor. Açıkçası İngilizce’nın biraz gerisinde, ama her yeni sürümde bu makas kapanıyor.
CU’yu kendi kurumsal ağımda, yanı private endpoint üzerinden kullanabilir mıyım?
Evet, kullanabilirsiniz. Private Endpoint ve VNet entegrasyonu destekleniyor. Customer-managed key, yanı CMK ile şifreleme de mümkün (ki bu çoğu kişinin gözünden kaçıyor). Tecrübeme göre compliance gereksinimleri olan bankacılık ve sağlık sektörü için bunlar kritik önem taşıyor — üretim ortamında genelde açın.
Fiyatlandırma nasıl işliyor, önceden tahmin etmek zor mu?
İnanın, Aslında yapı şöyle: sayfa başına temel bir ücret var, bir de modalite başına ek ücret geliyor — ses dakikası, video dakikası gıbı. Custom model eğitimi ve depolama da ayrı kalemler. POC için aylık 1000-2000 TL gıbı bir bütçe yeterli oluyor genellikle, üretim için kendi hacminizle pricing calculator çalıştırmanızı öneririm. Hacim arttıkça birim maliyet de düşüyor.
Mevcut Document Intelligence projemi CU’ya taşımalı mıyım?
Çalışan ve memnun olduğunuz bir projeyi sırf yeni teknoloji diye taşımayın — bence buna gerek yok. Ama yeni gereksinimler gündeme geliyorsa, mesela LLM muhakemesi, multimodal destek ya da daha karmaşık şemalar ihtiyacı doğuyorsa, o zaman geçiş gerçekten mantıklı (eh, fena değil). Migration path Microsoft tarafından destekleniyor, mevcut custom modellerinizi de CU’ya import edebiliyorsunuz.
Kaynaklar ve İleri Okuma
Microsoft Foundry Blog — What’s new in Azure Content Understanding at Build 2026
Azure Content Understanding Resmî Dokümantasyonu
Azure Content Understanding Python Örnekleri (GitHub)
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.
