Microsoft Foundry Nisan 2026: Üretimde Dikkat Çeken Yenilikler
Ne yalan söyleyeyim, Microsoft Foundry tarafında bu ay gelen güncellemeleri okuyunca ilk aklıma şu geldi: platform, sadece model koyup kenara çekilen bir yer olmaktan çıkıyor. Şimdi daha çok agent odaklı üretim hattının ortasına oturuyor gibi. Açık konuşayım, kağıt üstünde güzel duran ürün çok; ama burada asıl fark, hepsinin aynı çatı altında biraz daha düzenli çalışması. İşin içine tracing, evaluation, control plane ve lokal inference girince tablo da hâliyle değişiyor.
📋 İçindekiler
- En büyük değişim: Agent gozlemlenebilirligi nihayet ciddileşiyor
- Lokalden prod’a geçiş kolaylaşıyor mu? Foundry Local GA
- Model kataloğu genişliyor: GPT-5.5, Claude Opus 4..7 ve Gemma 4
- Ajan geliştirme araçları olgunlaşıyor mu?Microsoft Agent Framework1.0’ın GA’ya gelmesi ile Microsoft Foundry Toolkit for VS Code’un genel kullanıma açılması beraber düşünülmeli bence.Kağıt üstünde bunlar ayrı duyuru gibi dursa da sahada ikisi birbirini tamamlıyor.Biri orkestrasyonu sağlamlaştırıyor,d iğeri geliştirici deneyimini hızlandırıyor..
- Evaluation kültürü guclenmeden AI operasyonu olmaz
- Bunlar Türkiye’de ne anlama geliyor?
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Şunu fark ettim: Ben bu tip duyuruları okurken otomatik olarak “kurumsalda neyi çözer?” diye bakıyorum. Çünkü 20+ yıllık iş hayatında bunu defalarca gördüm: demo ile prod arasında bayağı mesafe var. AI tarafında bu mesafe daha da açılıyor. Bir özellik iyi olabilir, ama log yoksa, maliyet görünmüyorsa, güvenlik katmanı eksikse… geçmiş olsun.
Evet, doğru duydunuz.
Geçen yıl Şubat 2025’te bir finans müşterisinde benzer bir agent mimarisi tasarlarken tam da bunu yaşadık. Model fena çalışmıyordu, fakat ekip “kim ne yaptı, hangi tool çağrıldı, nerede yavaşladı” sorularına net cevap veremiyordu. Sonra tracing ekleyince taşlar yerine oturdu (en azından benim deneyimim böyle). Yanı mesele sadece akıllı ajan değil; izlenebilir ajan.
En büyük değişim: Agent gozlemlenebilirligi nihayet ciddileşiyor
Bu sürümde beni en çok çeken alan Microsoft Agent Framework tracing ve hosted-agent tracing öldü. Neden? Çünkü üretimde yaşayan her sistem gibi agent’lar da hata yapıyor. Hatta bazen hatayı model değil orkestrasyon çıkarıyor; tool zinciri uzuyor, gecikme artıyor ya da run step’lerden biri sessizce patlıyor. Böyle durumlarda “neden öldü?” sorusuna veriyle cevap vermek gerekiyor.
Bir bakıma, şunu fark ettim: Geçen ay Ankara’daki bir müşteride buna benzer bir problem gördük. Agent düzgün başlıyor ama bazı kullanıcı sorgularında response süresi bir anda zıplıyordu. İlk bakışta model suçlu gibi duruyordu… meğer asıl sorun dış servise giden tool çağrısındaki timeout zinciriydi. Tracing olmadan bunu yakalamak baya zor olurdu.
Hosted-agent tracing tarafı da fena değil; session seviyesinde run step. Tool call görmek pratikte ciddi rahatlık sağlıyor. Ama dürüst olayım, bu kısım hâlâ biraz — ki bu tartışılır — ham hissettiriyor. En çok da de de kurumsal operasyonlarda sadece trace görmek yetmez; alarm politikalarıyla birlikte anlam kazanması lazım.
Çok konuştum, örnekle göstereyim.
Neyi değiştiriyor?
Klasik APM mantığını alıp agent dünyasına uyarlıyor diyebilirim. Yanı “istemci kaç ms’de döndü” yerine “hangi düşünce adımı ne kadar sürdü”, “hangi araç çağrısı tıkandı”, “hangi evaluator düşük skor verdi” gibi daha ince detaylara iniyorsunuz.
Yanı, Bence bu doğru yönde atılmış bir adım ama eksik olan şey hâlâ standartlaşma. Her ekip kendi trace disiplinini kurmazsa dashboard sadece süslü ekran olarak kalır.
Agent dünyasında en pahalı hata yanlış model seçmek değil; hatayı goremeden prod’a çıkmak.
Lokalden prod’a geçiş kolaylaşıyor mu? Foundry Local GA
İtiraf edeyim, Foundry Local‘ın GA olması bence önemli bir eşik. Windows, macOS Apple Silicon. Linux x64 üzerinde lokal inference artık üretime yakın senaryolarda kullanılabiliyor deniyor; bu kötü haber değil tabiî ki iyi haber ama küçük bir not düşeyim: lokal çalışma ile kurumsal yönetişim aynı şey değil.
Bir arkadaşım Eylül 2025’te İstanbul’da küçük bir yazılım stüdyosunda Foundry Local test etmişti. Ekibin amacı basitti: müşteri verisini dışarı göndermeden hızlı prototip almak istiyorlardı. İki geliştiriciyle gayet iş gördü çünkü ortam hafifti, karar alma kısa sürdü ve latency avantajı vardı.
Bak şimdi, Kurum tarafında işe resim farklı oluyor. Mesela bankada veya telekomda yalnızca hız yetmiyor; cihaz yönetimi, versiyon sabitleme, kayıt politikaları ve onay süreçleri devreye giriyor (hani o meşhur “bir de güvenlikten onay gelsin” kısmı). O yüzden Foundry Local küçük ekiplerde çok tatlı dürüyor. Enterprise tarafta governance olmadan tek başına çözüm sayılmaz. Daha fazla bilgi için Kubernetes v1.36’da PSI GA: Sinyali Gürültüden Ayırmak yazımıza bakabilirsiniz.
Küçük ekip mi kurumsal yapı mi?
| Senaryo | Daha mantıklı yaklaşım | Neden |
|---|---|---|
| Küçük startup | Lokal inference + hızlı prototip | Düşük maliyet, hızlı iterasyon |
| Büyük enterprise | Lokal + merkezî policy + gözlemleme | Sorumluluk ayrımı ve denetim ihtiyacı |
| Düşük bütçe PoC | Lokal modelle başlayıp sonra ölçeklemek | Tahmin edilenden ucuz olabilir |
| Sert regülasyonlu sektörler | Cihaz bazlı kontrollü kullanım | Veri sınırı can alıcı olur |
Maliyet tarafını da es geçmeyelim… Azure fiyatlarını TL bazında düşününce her token insanın yüzünü biraz buruşturuyor doğrusu! Bu yüzden bazı işlerde lokal inference gerçekten nefes aldırabilir.
Ve işler burada ilginçleşiyor. Daha fazla bilgi için Azure DevOps Server Mayıs Yamaları: Neyi, Neden, Nasıl Kontrol Etmeli? yazımıza bakabilirsiniz.
Ama hayal kırıklığı yaşadığım nokta şu öldü: lokal başarıyı görünce herkes her şeyi oraya taşımaya kalkıyor (bizzat test ettim). Bu doğru değil. Bazı workload’lar bulutta daha ekonomik ve yönetilebilir kalıyor.
Model kataloğu genişliyor: GPT-5.5, Claude Opus 4..7 ve Gemma 4
İlginç olan şu ki, Nisan duyurusunda modeller tarafı baya dolu geliyor desek yeridir.GPT-5-5 default quota ile Tier 5. Tier 6 aboneliklerinde erişilebilir hâle gelmiş.Bu önemli çünkü birçok kurum yeni modeli test etmek için kota kovalamak zorunda kalmaktan hoşlanmıyor.Akışkan erişim işin psikolojisini bile değiştiriyor doğrusu..
Claude Opus4.7, Gemma4, MAI modelleri… yanı seçenek çok. Seçenek iyidir ;ama fazla seçenek bazen kararsızlık yaratır. Geçen sene Kasım2025 ‘ te Logosoft ‘ ta yürüttüğümüz bir PoC ‘ de üç farklı model ailesini yan yana kıyasladık. En iyi sonuç çıkan model çoğu zaman en popüler olan değildi ; bağlama göre değişti. Uzun doküman özetinde biri, görsel yorumlamada diğeri öne çıktı.
Küçük bir detay: Bilhassa Gemma4 ‘ ün native multimodal giriş ve256K context desteği dikkat çekici. Uzun sözleşmeler, teknik şartnameler veya kapsamlı bilgi bankalarıyla uğraşıyorsanız bu hiç küçümsenecek iş değil. Ama açık konuşayım : bağlam uzunluğu tek başına kalite demek değildir. Bazen uzun bağlam = uzun karmaşa.. önce önü kabul etmek lazım. Bu konuyla ilgili Python ile Teams SDK artık GA: Benim Sahada Gördüklerim yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili .NET 11 Preview 4: Sessiz Ama Dolu Gelen Sürüm yazımıza da göz atmanızı tavsiye ederim.
Mesele sadece benchmark değil
Ben AZ -305 hazırlanırken hep aynı şeye takılırdım : servis adı parlamak için yeterli mi, yoksa mimariyi gerçekten sadeleştiriyor mu ? Burada da durum aynı. Kurum içi seçim yaparken şu soruları sorun : latency nasıl, veri rezidansı nasıl, logging ne kadar iyi, fiyat tahmini tutarlı mı ? Bunlar cevaplanmadan modele âşık olmak biraz erken davranmak olur.
Bir de şu var : bazı ekipler ” en güçlü modeli alalım ” diye düşünüyor. Halbuki orta seviye ama stabil çalışan model çoğu zaman daha iyi toplam sonuç veriyor. Performans yarışını kazanmak başka, işi temiz bitirmek başka şey.
Ajan geliştirme araçları olgunlaşıyor mu?Microsoft Agent Framework1.0’ın GA’ya gelmesi ile Microsoft Foundry Toolkit for VS Code’un genel kullanıma açılması beraber düşünülmeli bence.Kağıt üstünde bunlar ayrı duyuru gibi dursa da sahada ikisi birbirini tamamlıyor.Biri orkestrasyonu sağlamlaştırıyor,d iğeri geliştirici deneyimini hızlandırıyor..
Haziran2025 ‘ te İzmir’deki bir SaaS ekibiyle çalışırken AI Toolkit’in eski sürümünü kullanmıştık.Her demo sonrası deploy adımı gereksiz yere uzuyordu.Gel gelelim toolkit içinde playground +agent builder + one-click deploy birleşince ekip gerçekten rahatladı.Yani eskiden üç farklı yerde yaptığınız işi tek yerden yapmak az buz fark etmiyor.. Daha fazla bilgi için Handoff Orchestration: Ajanlar Topu Nasıl Devrediyor? yazımıza bakabilirsiniz.
CodeAct with Hyperlight neden ilginç?
Python code execution için Hyperlight micro-vm yaklaşımı riskli tool zincirlerinde baya işe yarayabilir.Burada fikir şu : ajan gerektiğinde kod çalıştırıyor. Bunu sandbox içinde yapıyor.Tıpkı mutfakta keskin bıçakla çalışırken eldiven takmak gibi — neredeyse tamamen risksiz değil fakat hasarı sınırlıyorsunuz.
Yine de alpha olduğu için temkinliyim.Hyperlight fikri hoşuma gitti. Üretimde koşar adımla koşulacak yerde henüz yürüme aşamasında.Hatta ilk denediğimde beklediğim kadar stabil değildi ; birkaç edge case’te izin kontrolleri yüzünden akış bozuldu.Bu normaldir,biraz pişmesi lazım.
Evaluation kültürü guclenmeden AI operasyonu olmaz
Peki, şunu fark ettim: Continuous evaluation custom evaluators konusu özellikle hoşuma gitti.Kendi code-based veya prompt-based evaluator’ınızı sisteme taşıyabilmek gerçek hayatta büyük fark yaratır.Cünkü hazır metrikler çoğu zaman sizin domain probleminizi tam yakalamaz.Finans sektörü başka konuşur,saglık sektörü başka,e-ticaret apayrı (ben de ilk duyduğumda şaşırmıştım).
Bir müşteri projesinde geçen Mart2026’da bunu birebir yaşadık.Sentiment skoru yüksek olan cevapların aslında hukukî açıdan riskli olduğunu gördük.Hazır grader’lar gayet düzgün puan veriyordu fakat bizim özel evaluator mevzuatı ihlal eden ifadeleri yakalıyordu.işte tam burada custom evaluator hayat kurtardı.
Toksisite kontrolünü kendi dil setinizle tanımlayın
# Basit mantık örneği
if latency_ms > SLA_MS:
flag = "slow"
elif eval_score < MIN_SCORE:
flag = "quality-risk"
else:
flag = "ok"
Bunlar Türkiye’de ne anlama geliyor?
Bence, Türkiye’deki şirketlerde benim gördüğüm ortak desen şu : teknoloji ilgisi yüksek,fakat operasyon disiplini çoğu zaman geriden geliyor.Muhasebe ekibi maliyeti TL bazında görmek istiyor,g üvenlik ayrı kapıya bakıyor,yazılım ekibi işe “bir an önce canlıya alalım” diyor.Bu çatışmayı azaltan şey gösterişli demo değil,gözlemleme + değerlendirme + net ownership üçlüsü oluyor..
Büyük kurumlarda benim tavsiyem net:Lokal inference’ı pilot alanlarda kullanın,a ma merkezî kontrol düzleminden vazgeçmeyin.Küçük ekipler işe fazla bürokrasiye saplanmadan hızlı ilerleyebilir ; onların avantajı çeviklik.O yüzden aynı teknolojiyi iki farklı organizasyonda bambaşka şekilde konumlamak gerekiyor.Evdeki hesap çarşıya her zaman uymuyor,yanı..
Sıkça Sorulan Sorular
Foundry Local kime göre?
Küçük ekipler, pilot projeler. Veri hassasiyetinin yüksek olduğu durumlar için aslında çok iyi bir seçenek. Ama kurumsal tarafta, cihaz yönetimi ve policy katmanı olmadan tek başına yetmiyor — bence bunu göz ardı etmemek lazım.
GPT-5.5 herkese açık mı?
Duyuruya bakılırsa Tier beş ve Tier 6 aboneliklerinde varsayılan kotayla geliyor. Yanı ekstra bir şey yapmanıza gerek yok, hani otomatik olarak aktif oluyor. Tabiî bölgesel ya da kural bazlı kısıtlar yine de söz konusu olabilir.
Ajan tracing neden bu kadar önemli?
Hata ayıklama, maliyet analizi ve performans takibi için kritik. Açıkçası trace olmadan sorunları sezgisel olarak aramaya başlıyorsunuz — bu da hem zaman hem para kaybına yol açıyor.
Coding executor olarak Hyperlight güvenli mi?
Piyasadaki diğer sandbox yöntemleriyle kıyaslandığında umut verici görünüyor. Ama hâlâ alpha aşamasında, yanı tecrübeme göre kritik üretim ortamlarında temkinli yaklaşmak daha mantıklı.
Kaynaklar ve İleri Okuma
What’s new in Microsoft Foundry | April 2026
Azure AI Foundry resmî dokümantasyonu
Azure Architecture Center (yanlış duymadınız)
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.
4 comments