Evaluations | The .NET Blog

Model router evals, pek çok ekibin atladığı adımdır

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Bu makale otomatik olarak çevrildi. Orijinal sürüm için buraya tıklayın.

Otomatik model routing kulağa harika gelir; ta ki bunun workload’unuz için doğru seçim olduğunu yine de kanıtlamanız gerektiğini fark edene kadar.

İşte bu yüzden yeni model router evaluation repo faydalıdır.

Ekiplerin gerçekten önemli olan sorulara daha somut cevaplar vermesini sağlar:

routing kaliteyi koruyor mu?
maliyeti iyileştiriyor mu?
gecikmeye etkisi ne?
model subset’i kısıtlarsam ne değişir?

Kaynak makale doğru soruları soruyor

Orijinal yazıda en sevdiğim şeylerden biri, model router’ı kendiliğinden iyi kabul etmemesi.

Bunun yerine rahatsız edici ama doğru soruları soruyor:

“Prompt’larımda, model router’ın otomatik seçtiği model, aksi halde benim seçeceğim tek modelle eşleşiyor mu ya da onu geçiyor mu?”
“Gerçekten uçtan uca para mı tasarruf ediyorum, yoksa sadece harcamayı bir yerden başka bir yere mi kaydırıyorum?”

Bu tam olarak doğru tutum.

Çünkü otomatik routing çekici olsa da bu hâlâ bir system decision. Ve system decision’lar beğenilmemeli, ölçülmelidir.

Bu repo ilk bakışta göründüğünden neden daha önemli

Bir düzeyde bu sadece bir evaluation repo’su.

Başka bir düzeyde ise olgunluk işaretidir.

Şunu söylüyor: otomatik routing’i benimsemek istiyorsanız, işte test etmek için daha disiplinli bir yol:

kalite
maliyet
gecikme
subset trade-off’ları
model dağılım davranışı

Bu, routing’i iyi markalanmış bir black box gibi ele almaktan çok daha iyidir.

Benim görüşüm

Bu, AI platform’ların daha fazlasına ihtiyaç duyduğu tooling türüne iyi bir örnek: daha fazla sihir değil, güvenmeden önce sihri doğrulamanın daha fazla yolu.

Ekiplerin test edilmemiş varsayımlar üzerinde pahalı güven inşa etmesini böyle önlersiniz.

Orijinal makale: How to run evals for the model router

AI geliştirmenin zor kısmı artık erişim değil. Doğru modeli iyi bir şekilde işletmek

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Güçlü bir model erişimine sahip olmanın tek başına yeterli olduğu dönemi çoktan geride bıraktık.

Bu yeni Foundry model, cost ve quality yönetimi rehberi tam olarak bunu doğru yakalıyor.

Asıl zorluk artık operasyonel:

her workload için doğru modeli seçmek
onu kendi verinizle doğrulamak
latency ve harcamayı yönetmek
upgrade’leri ve regression riskini yönetmek

Ciddi ekiplerin iyi olması gereken şey tam olarak bu.

Kaynak makale problemi doğru tanımlıyor

Orijinal yazıdan bir cümle bu değişimi çok iyi yakalıyor:

“Bugün AI sistemleri kurmanın en zor kısmı artık yetenekli bir modele erişmek değil. Gerçek bir uygulamanın tüm yaşam döngüsü boyunca doğru modeli nasıl seçeceğinizi, doğrulayacağınızı, optimize edeceğinizi ve işleteceğinizi bilmektir.”

Bu tam olarak doğru teşhis.

Çok fazla ekip hâlâ model selection’ın ana karar olduğunu düşünüyor.

Değil.

Asıl büyük problem model operation:

hangi workload’a hangi model gider?
quality nasıl doğrulanır?
kabul edilebilir cost şekli nedir?
yeni bir model geldiğinde ya da eski model drift ettiğinde ne olur?
gerçek workflow’ları bozmadan bir değişiklik nasıl test edilir?

Asıl engineering işi şimdi bu.

Bu Foundry parçası neden faydalı

Bu makaleyi seviyorum, çünkü AI systems hakkında deneyimli platform engineer’ların gerçekten düşünmesi gerektiği şekilde konuşuyor.

“En akıllı modeli seç ve devam et” gibi değil.

Capability, latency, cost, safety, governance ve upgrade pressure gibi trade-off’lar altında yaşayan sistemler olarak ele alıyor.

Bu, benchmark odaklı iyimserlikten çok daha faydalı.

En önemli değişim, önce kriterleri düşünmek

Orijinal yazı, model catalog’u açmadan önce başarı kriterlerini tanımlamayı öneriyor.

Bu, ekiplerin benimseyebileceği en önemli alışkanlıklardan biri.

Catalog’u önce açarsanız, itibara bağlanırsınız.

Kriterleri önce tanımlarsanız, workload gerçekliğine bağlanırsınız.

Bu daha sağlıklı bir süreç.

Çünkü benchmark’ı kazanan model, şu alanlarda kazanan model olmak zorunda değildir:

sizin prompt’larınız
sizin latency budget’ınız
sizin cost guardrail’leriniz
sizin governance gereksinimleriniz

Olgun AI engineering tam olarak bu farkta başlıyor.

Multi-model hikâyesi gerçek bir avantaja dönüşüyor

Bir başka hoşuma giden şey de model-agnostic yaklaşım.

Makale Foundry’yi tek model destinasyonu olarak değil, şu alanların üzerinde bir operating surface olarak sunuyor:

Microsoft modelleri
partner modelleri
open-source modeller
post-trained varyantlar
routing ve optimization stratejileri

Bu önemli, çünkü model esnekliği artık lüks değil. Risk yönetiminin bir parçası.

Kalite değişirse, fiyatlar oynarsa veya quota daralırsa, ekiplerin seçeneğe ihtiyacı olur.

Maliyet kontrolü ikincil bir konu değil

Makale maliyeti de mimari bir concern olarak ele almakta haklı.

Bu, “sonra optimize ederiz” problemi değil.

Eğer her görevi varsayılan olarak en ağır modele gönderirseniz, bu demo’da harika çalışabilir ve production ekonomisinde çökebilir.

Bu yüzden şu bölümler bence birçok kişinin sandığından daha önemli:

routing
batching
caching
provisioned throughput
quota management

Maliyet disiplinini sistem tasarımının bir parçası olarak gören ekipler, bunu sonradan temizlik işi gören ekiplerden çok daha iyi dayanır.

Benim görüşüm

Bu Foundry parçası faydalı, çünkü AI systems hakkında deneyimli engineer’ların gerçekten onları nasıl işletmesi gerektiği gibi konuşuyor.

Demo gibi değil. Tek seferlik prototype gibi değil. Leaderboard turizmi gibi hiç değil.

Workload’lar, kısıtlar, trade-off’lar ve sürekli değişim için operating systems gibi.

Konuşmayı bu seviyede sürdürmemiz gerekiyor.

Ve production AI systems geliştiriyorsanız, ekiplerin erken içselleştirmesi gereken mindset tam olarak bu.

Orijinal gönderi: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

Foundry'nin gözlemlenebilirlikten ROI'ye uzanan hikâyesi, ciddi ajan platformlarının ihtiyaç duyduğu şeydir

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

AI agents production’da yaşayacaksa, gözlemlenebilirlik logs ve traces’ta bitmemeli.

Bu yüzden Foundry’nin yeni observability-to-ROI hikâyesi önemli hissettiriyor.

Asıl mesaj “daha fazla dashboard ekledik” değil.

Asıl mesaj, ciddi agent platformlarının sürekli bir operasyon döngüsüne ihtiyaç duymasıdır:

ne olduğunu trace et
iyi olup olmadığını değerlendir
çalışılması gereken kısmı optimize et
sonucu business value ile bağla

Bu, alışıldık platform laf kalabalığından çok daha güçlü bir hikâye.

Kaynak makaledeki kilit cümle her şeyi söylüyor

Orijinal yazı, bence agent geliştiren her ekibin dikkat etmesi gereken bir cümleyle açılıyor:

“Bir AI agent’ı yayına almak kolay kısımdır. Onu production’da doğru, güvenli ve hesap verebilir halde tutmak ise ekiplerin takıldığı yerdir.”

Bu tam olarak doğru.

Artık ana sorunun “bir agent’a havalı bir şey yaptırabilir miyim?” olduğu aşamayı geçtik.

Daha zor ve daha değerli soru şu:

gerçek kullanıcılar, gerçek araçlar ve gerçek maliyetlerle etkileşime girmeye başladığında o sistemi işletebilir miyim?

Foundry konuşmayı tam da bu tarafa itmeye çalışıyor.

Neden bu, başka bir agent demosundan daha önemli

Birçok AI agent duyurusu hâlâ creation’a odaklanıyor: agent’ı kur, tools’u bağla, tasks’i route et, interface’i yayınla.

Bunların hepsi tamam.

Ama operasyonel sorular, çoğu ciddi sistemin ya sürdürülebilir olmasını ya da pahalı bir deneye dönüşmesini belirleyen yer:

agent production’da gerçekte ne yapıyor?
doğru şeyi yaptı mı?
zamanla kötüleşiyor mu?
yarattığı değere kıyasla çok mu pahalı?
hangi configuration değişiklikleri gerçekten quality’yi iyileştirdi?

Bu yüzden Foundry duyurusunun tipik bir feature roundup’tan daha önemli olduğunu düşünüyorum. Sadece agent creation hikâyesi değil, bir Agent DevOps loop tanımlamaya çalışıyor.

Dört parçalı döngü burada gerçek ürün

Makale platformu temelde dört capability etrafında düzenliyor:

Trace
Evaluate
Monitor
Optimize

Doğru şekil bu.

Hatta production agent workload’ları için ciddiye alınmak isteyen her platformun sonunda bu dördüne de ihtiyacı olacağını söyleyebilirim.

Tracing tek başına yetmez.

Evaluation tek başına yetmez.

Kanıt olmadan optimization sadece tahmindir.

Ve telemetry olmadan ROI konuşması çoğu zaman tiyatrodur.

Interoperability tarafı özellikle akıllıca

Duyurudaki en güçlü kararlardan biri, Foundry’nin tüm agent’ların tek bir framework’te kurulacağını varsaymaması.

Kaynak post, tracing ve evals’in şu alanlara yayıldığını açıkça söylüyor:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
OpenTelemetry üzerinden custom frameworks

Bu önemli.

Çünkü platform lock-in, başlangıçta faydalı olan bir operations hikâyesini daha az cazip hale getirmenin en hızlı yollarından biri.

Ekipler framework seçimlerini koruyup yine de production-grade telemetry ve evaluation surface elde edebiliyorsa, sürtünme ciddi biçimde azalır.

Rubric evaluation insanların beklediğinden daha önemli olabilir

Rubric evaluation kısmı da ayrıca değerli.

Bence bu, bütün post’taki en pratik eklemelerden biri.

Neden? Çünkü “iyi” bağlama bağlıdır.

Makale, rubric evaluation’ın “agent’in amaçlanan davranışından context-aware evaluation criteria ürettiğini” söylüyor. Bu sistemlerin ihtiyaç duyduğu yön tam olarak bu.

Genel kalite puanlaması faydalıdır.

Ama sonunda ekiplerin agent’ları kendi standartlarına göre puanlaması gerekir:

tone
task completion
policy adherence
latency expectations
cost sınırları
domain’e özgü business rules

Evaluation’ın akademik açıdan ilginç olmaktan çıkıp operasyona anlam kazandırdığı nokta burasıdır.

ROI en rahatsız edici kısım ve bu yüzden önemli

Duyurunun ROI kısmının önemli olduğunu düşünmemin nedeni de tam olarak bunun rahatsız edici olması.

Kaynak post doğrudan soruyor:

“bu agent maliyetine değiyor mu?”

AI konuşmalarında bu soru sık sık geçiştirilir.

Ama doğru soru budur.

Platform gerçekten cost, task completion, time saved ve production traces’ı tek yerde birleştirebiliyorsa, engineering ve leadership için çok daha iyi bir ortak dil sağlar.

Ve dürüst olmak gerekirse, böyle bir ortak dile ciddi şekilde ihtiyaç var.

Benim görüşüm

Bu batch’teki en iyi platform seviyesi duyurulardan biri, çünkü agent’ları inşa etmeye değil, işletmeye odaklanıyor.

Asıl zor iş de tam burada başlıyor.

Önümüzdeki birkaç yılın en güçlü AI platformları, sadece daha fazla model veya daha fazla demo erişimi olanlar olmayacak. Ekiplerin davranışı trace etmesine, sonuçları değerlendirmesine, güvenli biçimde optimize etmesine ve maliyeti kanıtla savunmasına yardım eden platformlar olacak.

Foundry’nin bu hikâyesi tam da o yöne gitmeye çalışıyor.

Bu yüzden ciddiye alınmayı hak ediyor.

Orijinal yazı: Build 2026: From observability to ROI for AI agents on any framework