Açık konuşayım: GPT-5 ailesini takıp etmek son aylarda biraz kafa ütüler hâle geldi. 5.0 derken 5.4 çıktı, daha önü tam sindiremeden şimdi de 5.5 kapıda. Yarın itibarıyla Microsoft Foundry üzerinde genel kullanıma açılıyor —. Evet, “Pro” varyantı da geliyor.
Bir Azure danışmanı olarak bu tıp duyurulara eskisi gıbı hoplayıp zıplamıyorum. Neden? Çünkü model çıkıyor, müşteri “hemen geçelim” diyor, sonra iki hafta sonra production’da tuhaf token faturalarıyla boğuşuyoruz. Işin romantizmi kısa sürüyor. O yüzden bu yazıyı parlak bir lansman metni gıbı değil, sahadan gelen bir ön değerlendirme gıbı okuyun istedim.
GPT-5 Serisinin Geldiği Nokta
Şöyle bir geri saralım. GPT-5.0 çıktığında en büyük vaadi “tek modelde hem reasoning hem hız” idi. Daha önce o1, o3 gıbı reasoning modelleriyle GPT-4o tipi hızlı modeller arasında gidip gelirken, artık tek bir sisteme bağlanıp işi ona havale ediyorduk; kulağa basit geliyor. Pratikte baya iş görüyor.
Bence, 5.4 işe ajansal (agentic) tarafa yüklenmişti — yanı çok adımlı görevleri kendi başına yürütme tarafına — dürüst olayım, biraz hayal kırıklığı —. Burada AZ-400 hazırlanırken kendi test ortamımda gördüğüm bir şey vardı: 5.4, uzun pipeline’larda bağlamı tutmakta ara sıra tökezliyordu; özellikle 80K token üstü konuşmalarda son birkaç adımda hedeften kayıyordu, bazen de insanın canını sıkan şekilde ufak ufak dağılıyordu.
5.5’in iddiası tam burada devreye giriyor: daha derin uzun-bağlam akıl yürütme, daha güvenilir ajan yürütmesi. — bence en kritik tarafı — daha iyi token verimliliği. Naomi Moneypenny’nın duyurusunda geçen “fewer tokens, fewer retries” lafı ilk bakışta pazarlama kokuyor olabilir. Bu ne anlama geliyor? Foundry’deki erken testlerde bunu destekleyen rakamlar var, hani öyle boş lafta kalmamış gıbı duruyor.
Foundry Neden Sadece “Model Marketplace” Değil?
Burada küçük bir parantez açayım. Pek çok kişi Microsoft Foundry’yi hâlâ “Azure’un OpenAI modellerine eriştiğin yer” diye görüyor. Şey… işin aslı biraz daha geniş.
Foundry; model seçimi, ajan framework’leri (MAF dahil), kurumsal sistem entegrasyonları, güvenlik politikaları. Governance katmanını tek çatı altında topluyor. Yanı GPT-5.5 çıktığında siz sadece endpoint değiştirmiyorsunuz — aynı RBAC çalışıyor, aynı Private Endpoint duruyor, aynı içerik filtreleme devam ediyor, aynı maliyet etiketleri de yerinde kalıyor; yanı göç işi sandığınız kadar dağılmıyor.
Logosoft’taki bir bankacılık projesinde geçen ay tam bunu yaşadık. Müşteri 5.4’ten 5.5 preview’a geçmek istedi; klasik senaryoda bu en az iki hafta sürerdi çünkü compliance ayrı konuşur, security review ayrı uzar, herkes kendi notunu düşer falan filan… Foundry’de yaptığımız şey işe mevcut policy’leri yeni modele bağlayıp bir deployment oluşturmak öldü. Üç saat sürdü. Abartmıyorum.
Evet, doğru duydunuz.
“Güçlü model tek başına ajan AI’ı ölçeklendirmez.” Naomi bu cümleyi yazmış; ben de altına imzamı atarım. Sahada gördüğüm en büyük başarısızlık sebebi model seçimi değil, platform katmanının eksik olmasıydı.
GPT-5.5’te Gerçekten Yeni Olan Ne?
Ajansal Kodlama ve Computer-Use
Microsoft’un anlattığına göre 5.5, büyük kod tabanlarında çok adımlı engineering görevlerini uçtan uca yürütebiliyor. Yanı bug raporunu alıyor, mimarı seviyede kök sebebi arıyor, fix’in kod tabanının başka nerelerini dürteceğini düşünüyor, sonra hareket ediyor; teoride güzel duruyor, pratikteyse ölçmeden konuşmak istemem açıkçası.
Bu kulağa hoş geliyor ama dür bir saniye — bunun benzerini Claude Sonnet 4.5 ve hatta 5.4 de yapıyordu zaten. Peki fark ne?
Şunu fark ettim: Erken testlerde benim gördüğüm şu: 5.5 beklenmedik hatalarla karşılaştığında daha az panikliyor diyeyim ben ona. 5.4’te bir test fail olduğunda model bazen tüm yaklaşımı çöpe atıp yeniden başlıyordu; biraz dramatikti yanı. 5.5 işe hatanın lokal mi yoksa sistemik mi olduğunu daha iyi ayırıyor gıbı duruyor. Bu küçük nüans production’da ciddi fark yaratabiliyor.
Otonom Yürütme ve Araştırma Derinliği
Bence en az konuşulan ama asıl önemli kısım burasıdır belki de… 5.5 sadece kod yazmıyor; belge, tablo. Sunum gıbı “iş çıktıları” üretmek için de optimize edilmiş görünüyor.
Araştırma yoğun iş akışlarında pasif cevap veren bir makine gıbı değil de aktif bir iş arkadaşı gıbı davranmaya çalışıyor — taslakları birkaç tür iyileştiriyor, analitik akıl yürütmeyi zorlayıp sınava söküyor (bak şimdi burada pazarlama dili var ama sonuç fena değil). Daha fazla bilgi için .NET 11 Preview 4: Sahadan İlk İzlenimler ve Notlar yazımıza bakabilirsiniz.
Bunun Türkiye’deki şirketler açısından anlamını ayrıca düşünmek lazım. Bizde “AI ajan” denince akla çoğu zaman yazılım geliştirme geliyor; halbuki finans, hukuk. Denetim gıbı belge yoğun sektörlerde gerçek kazanç çoğu zaman burada çıkıyor.
Bir denetim firmasında 5.4 ile yaptığımız POC’de 200 sayfalık sözleşme setinin risk analizini yaklaşık 40 dakikaya indirmiştik; bu küçümsenecek iş değil.
Ama esas mesele süre değil aslında: çıktı kalitesi insan denetçinin “az düzeltme” yapacağı seviyeye yaklaşırsa değer oluşuyor.
Önü test edip göreceğiz. Bu konuyla ilgili CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımıza da göz atmanızı tavsiye ederim.
Uzun Bağlam ve Token Verimliliği
Bence gözden kaçan nokta tam olarak bu.
Herkes “kaç token bağlam destekliyor” sorusuna takılıyor ama asıl mesele bağlamı verimli kullanıp kullanmadığı.
Şöyle düşünün: 200K token desteklediğini söyleyen bir model aynı görevi yapmak için iki kat token harcıyorsa size faydadan çok yük bindiriyor demektir.
İşte 5-55’in token verimliliği iddiası burada anlam kazanıyor; sayıdan çok davranışa bakmak gerekiyor.
Maliyet Tarafı: TL Bazında Konuşalım
Şimdi biraz somutlaşalım.
Çünkü blog yazılarında bu bölüm hep havada kalıyor ya da herkes nazikçe üzerinden atlıyor.
| Senaryo | GPT-5.4 (tahmini) | GPT-55 (tahmini) | Fark |
|---|---|---|---|
| Aylık 10M token (Input) | ~$25 | ~$28 | +%12 birim |
| Aynı görev için token sayısı | %100% | %75-80 civarı | – %20-25 efektif |
| Retry oranı | %15-20 | %8-12 | Net kazanç |
| Baz | %10-15 ucuz civarı | 👍 |
Not: Bu rakamlar erken testlere dayalı tahminlerdir; kesin fiyatlar yarın Foundry portal’da yayınlanacak şekilde görünüyor.Pro varyantı için ayrıca fiyatlandırma bekliyorum. Daha fazla bilgi için Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımıza bakabilirsiniz.
Pekâlâ.Model çıktı,kafamızı kaldırdık ve “ben de geçeyim” dedik.Sonra ne olacak?Sahada uyguladığım sırayı paylaşayım:
- Eval suite’ınızı hazırlayın.SIDE-by-side deploy edin.Daha doğrusu şöyle:TOKEN kullanımını ölçün.
Sadece kalite değil,maliyet/kalite oranı kritik.Aynı işi daha az tokenla yapabiliyor mu?
yazısında detaylandırmıştım — ajan kalitesini ölçmek için bu araç gerçekten işe yarıyor.
az cognitiveservices account deployment create \
--name my-foundry-resource \
--resource-group rg-ai-prod \
--deployment-name gpt -55-canary \
--model-name gpt -55 \
--model-version "202-five11-preview"
--model-format OpenAI \
--sku-capacity fifty \
--sku-name "Standard"
# Sonra alias üzerinden trafik yönlendirme
az cognitiveservices account deployment update \
--name my-foundry-resource \
--resource-group rg-ai-prod \
--deployment-name production-alias \
--traffic-split "gpt -54=90,gpt -55-canary=10"
Startup mı,Enterprise mı?Farklı Yaklaşımlar
Burada önemli bir ayrım var.Bence herkes five point five’e koşmak zorunda değil.
Eğer küçük bir startup’sanız:
Doğrudan five point five’e geçin.Çünkü zaten esnek mimariniz var,retry’lardan kaçındığınız her token cebinizden çıkıyor.Hızlı iterate edin,ölçün,devam edin.
Eğer kurumsal yapıdaysanız:
Acele etmeyin.Önce compliance ekibinizle konuşun.Yeni modelin data residency,content filtering,audit log davranışı önceki modelle aynı mı?Çoğu zaman aynıdır ama bunu varsaymak yerine doğrulamak gerek.Ben bir kamu projesinde bunu varsayıp acı çekmiştim—geri dönmek zorunda kaldık.Acılı ders öldü.
Eğer regulated bir sektördeyseniz(finans,sağlık,savunma):four-six hafta bekleyin.Erken benimseyici olmanın getirisi yok,getirebileceği risk büyük.Bırakın başkaları
early adopter battle scars”
toplasın.
Ajan Mimarisinde Ne Değişecek?
five point five’in ajansal yetenekleri arttıkça,bizim de ajan mimarilerimizi gözden geçirmemiz gerekecek.Çünkü daha güçlü model bazen fazla yetenekli oluyor,yanı sizin ona vermediğiniz işleri de yapmaya kalkabiliyor.
Bu konudaHandoff Orchestration:Ajanlar Birbirine Topu Atınca Neyazımdaki yaklaşımı yeniden düşünmek lazım.Five point five ile belki bazı senaryolarda iki ayrı ajan yerine tek ajana daha fazla yetki vermek mantıklı olabilir.Belki de değildir;bunu test etmek gerekir.
Bir de production tarafı var.Foundry Hosted Agents:MAF Ajanını Production’a Almak writingsindeki deployment pattern’ları five point five ile birebir geçerli,sadece tool calling davranışı biraz daha atak olacak gıbı görünüyor.Tool timeout’larınıza yeniden bakın derim.
Benim Çekincelerim
Tamam,şimdiye kadar genel olarak olumlu konuştum.Ama dengeli olmak istiyorum;çünkü her yeni model duyurusunda olmayan şey gerçek kullanıcı verisi.
İlk endişem:“Agentic execution”
iddiaları bana biraz fazla iddialı geliyor.Bunu sahada doğrulayana kadar şüpheciyim.Geçmişte benzer vaatlerle çıkan modellerin bir kısmı kontrollü demo dışında yalpaladı.
İkincisi:Pro varyantının fiyatı
henüz net değil.Eğer abartılı fiyatlandırma gelirse çoğu Türk kurumsal müşteri için cazibesini kaybeder.USD bazlı fiyatlandırma bizim için çoğu zaman dezavantaj.
Üçüncüsü:
Computer-use yetenekleri kulağa süper geliyor ama Türkçe arayüzlerle ne kadar iyi çalışacağı belirsiz.Ingilizce screenshot’larla yapılan demolar Türkçe SAP ekranlarında aynı performansı verecek mi?Şüpheliyim.Bu konuda en az bir POC yapmadan müşteriye söz vermem.
>
Sıkça Sorulan Sorular
5.5’e geçmek için 5.4 deployment’ımı silmem gerekiyor mu?
Hayır, hiç gerek yok. Foundry’de aynı resource altında birden fazla deployment aynı anda çalışabiliyor. Hatta bence en mantıklı yaklaşım şu: 5.4’ü en az 2-3 hafta daha production’da tutarken 5.5’i yavaş yavaş devreye almak. Trafik yönlendirme için de deployment alias kullanın, çok işe yarıyor. SPFx 1.23 Geldi: Yeoman’a Veda, CLI Dönemi Başlıyor yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
GPT-5.5 Türkçe destekte 5.4’e göre daha mı iyi?
Resmî duyuruda dil bazında ayrı bir karşılaştırma yok açıkçası. Erken testlerimde Türkçe doğal dil görevlerinde küçük iyileşmeler gördüm,. Bu kadar erken net bir şey söylemek yanlış ölür. Önümüzdeki 2-3 haftada daha sağlıklı veriler çıkar zaten.
Mevcut prompt’larımı 5.5 için yeniden yazmam gerekir mi?
Aslında, Çoğu durumda hayır. Yanı ajan tabanlı senaryolarda tool-calling instruction’larınızı biraz sadeleştirebilirsiniz, 5.5 daha az “el tutma” istiyor. Ama tecrübeme göre en güvenli yol, eski prompt’larla başlayıp evals üzerinden adım adım iyileştirmek.
Azure OpenAI Service ile Microsoft Foundry aynı şey mi?
Tam olarak değil. Aslında Azure OpenAI Service, Foundry’nın bir bileşeni. Foundry daha üst bir çatı; hani model seçimi, ajan framework’leri, eval araçları ve governance katmanını da kapsıyor. Yeni projelerde doğrudan Foundry üzerinden gitmek bence çok daha mantıklı.
GPT-5.5 Pro ne zaman işe yarıyor?
Kendi deneyimimden konuşuyorum, Mesela çok uzun bağlamlarda (150K+ token), 10 adımı geçen karmaşık ajan görevlerinde veya yüksek doğruluk isteyen araştırma iş akışlarında Pro gerçekten fark yaratıyor (bizzat test ettim). Ama sıradan bir chatbot ya da orta düzey kod yardımı için standart 5.5 fazlasıyla yeterli, Pro’ya gerek yok.
Ve işler burada ilginçleşiyor.
Kaynaklar ve İleri Okuma
Microsoft Azure Blog: OpenAI’s GPT-5.5 in Microsoft Foundry (Naomi Moneypenny)
Microsoft Foundry Resmî Dokümantasyonu
Bunu yaşayan biri olarak söyleyeyim, Azure OpenAI Models Reference
Tuhaf ama, Azure AI Samples GitHub Repository
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



