Geçen ay bir sigorta şirketinde ilginç bir tartışma döndü. Ekipteki kıdemli geliştirici, “abi biz neden hâlâ her isteği GPT-4o’ya yolluyoruz, yarısı basit özet işi” deyince masa bir anda canlandı; cevap aslında ortadaydı ama kimse rakamla konuşmuyordu, işte tam orada Foundry’nın Model Router’ı ve ona yazılmış yeni açık kaynak eval reposu devreye girdi.
Bu yazıda Microsoft’un yayınladığı eval pipeline’ını kendi kafamda nasıl kurcaladığımı, hangı köşelere takıldığımı. Türkiye’deki kurumsal yapılar için ne ifade ettiğini anlatacağım. Lafı gevelemeden başlayalım.
Model Router Tam Olarak Ne Yapıyor?
Kısaca şöyle: tek endpoint veriyorsunuz, sistem prompt’un karmaşıklığına, reasoning ihtiyacına ve görev tipine bakıp 28 frontier model arasından en uygununu seçiyor. Yanı siz gpt-4o mu, o4-mini mi, phi-4 mü yazacağım diye kafa yormuyorsunuz; router karar veriyor.
Kağıt üstünde fena değil. Pratikte işe işler biraz karışıyor,. “akıllı seçim” lafı test edilmeden durunca sadece slogan oluyor; müşteriye “modelinizi otomatik seçen bir katman koyalım” dediğiniz anda ilk soru şu geliyor: “Peki bu bana ne kazandıracak, ölçtün mü?”
Yanı, Ölçmediyseniz, boş laf oluyor. Hatta bazen kendinizi bile ikna edemiyorsunuz; bu yüzden bu eval reposu tam o deliği kapatıyor.
Eval Reposu Neden Önemli? Foundry’nın Kendi Benchmark’ı Yok mu?
Var tabi. Foundry’nın enterprise-grade benchmarking aracı zaten masada (ben de ilk duyduğumda şaşırmıştım). Ama açık konuşayım, kurumsal benchmark araçları biraz tören kıyafeti gıbı; büyük projeler, governance ve portal görünürlüğü için iyi duruyorlar, hızlı cevap almak istediğinizde işe aynı tadı vermiyorlar.
Bu yeni repo tam da o ara katmanı dolduruyor. Lokal, scriptable, hızlı; yanı “bu router benim stack’ime girsin mi girmesin mi” sorusuna 1-2 saatte savunulabilir bir cevap veriyor. Sonra işi büyütmek isterseniz run_foundry_eval.py ile sonuçları Foundry’nın enterprise tooling’ine de taşıyabiliyorsunuz. İki dünyanın iyi yanı burada birleşiyor gıbı.
Geliştirici Olarak Cevap İstediğim dört Soru
Açık konuşayım, Bir entegrasyondan önce kafamda hep aynı sorular var. Bu repo da zaten onlara yaslanıyor:
- Kalite: Router’ın seçtiği model, benim manuel seçeceğim modele denk mi, yoksa daha mı iyi?
- Maliyet: Router’ın kendi input-prompt ücreti + altındaki modelin ücreti… toplamda gerçekten kazanıyor muyum, yoksa harcamayı sadece başka yere mi kaydırıyorum? — ciddi fark yaratıyor
- Latency: Routing kararı + seçilen modelin cevap süresi, küçük modelden gelen kazancı yiyor mu?
- Subset etkisi: Compliance yüzünden bazı modelleri kapatırsam kalite ve fiyat tarafında ne kaybediyorum?
Bu son madde özellikle Türkiye için kritik. Bir bankacılık projesinde Claude modellerini ayrıca deploy etmediğimiz için router onları otomatik olarak es geçmişti; sonuçlar şaşırtıcıydı — bazı görev tiplerinde kalite belirgin düştü. Maliyet de düştü. Trade-off baya netleşti.
Pipeline’da Ne Ölçülüyor?
Kendi deneyimimden konuşuyorum, Dört ana metrik var. İlk okuduğumda ben de birkaç yerde durup tekrar baktım, o yüzden tek tek açayım.
1. Bias-Controlled LLM-as-a-Judge
Kalite skoru için “LLM yargıç” yaklaşımı kullanılıyor. Ama burada can alıcı detay şu: dual-ordered pairwise scoring. Yanı iki cevabı A-B sırasıyla bir kez, B-A sırasıyla bir kez daha karşılaştırıyorlar; pozisyon bias’ını azaltmak için bunu yapıyorlar. Çünkü bunu Logosoft’ta bir RAG projesinde sert şekilde öğrenmiştik: LLM yargıçlar çoğu zaman ilk gösterilen cevaba hafiften kayıyor. Daha fazla bilgi için NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımıza bakabilirsiniz.
2. Router-Aware Cost Math
Burası baya akıllıca düşünülmüş. Çünkü router’ın kendi input-prompt billing’i var, bir de alttaki modelin pricing’i var; repo her cevapta router’ın hangı modeli seçtiğini logluyor. Maliyeti gerçek fiyat üzerinden çözüyor. Tahmin yok, doğrudan hesap var.
3. Value & Efficiency Composites
Burada quality-per-dollar ve quality-per-second diye iki composite metrik var. Trade-off’u görünür yapıyorlar; çünkü ham kalite skoru tek başına pek bir şey söylemez — saniyede 4 dolar yakıyorsa kim umursar ki?
4. Model Distribution Reporting
Şöyle ki, Router hangı alttaki modellere ne sıklıkta gidiyor, önü görüyorsunuz. Balanced vs Cost vs Quality modlarını test ederken sanity-check için resmen işe yarıyor; mesela “Cost” modunda hâlâ %30 oranında GPT-4o seçiyorsa ya o promptlar gerçekten karmaşıktır ya da router bir yerde tuhaf davranıyordur.
E Hadi Bakalım: Eval Nasıl Çalıştırılıyor?
Pek teknik kısma geçelim şimdi. Reponun temel akışı kabaca şöyle:
# 1. Repo'yu klonla
git clone https://github.com/microsoft/model-router-evals
cd model-router-evals
# 2. Bagimliliklari kur
pip install -r requirements.txt
# 3..env dosyasini doldur
# AZURE_OPENAI_ENDPOINT, API_KEY, JUDGE_MODEL_ENDPOINT vb.
# 4. Dataset'ini hazirla (JSONL format)
# Her satır:
# 5. Eval'i calistir
python run_eval.py --dataset my_prompts.jsonl --mode balanced
# 6. Sonuclari gor
python generate_report.py --results out/run_001.json
Araya gireyim: İlk denememde ufak bir çuvallama yaşadım: JUDGE_MODEL_ENDPOINT için ayrı deployment açmamıştım, router’ın seçtiği modeli aynı zamanda yargıç yaptırıyordum; bu da doğal olarak self-bias yaratıyor. Çözüm basit: yargıç için sabit, güçlü bir model (mesela GPT-4o veya o1) deploy edin ve eval boyunca önü kullanın. Daha fazla bilgi için Google I/O 2026: Bir Azure’cunun Gözünden Saha Notları yazımıza bakabilirsiniz.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlam Taşıyor?
Burası benim açımdan en ilginç yerlerden biri öldü. Türkiye’de model seçimi konusu hâlâ biraz geriden geliyor; çoğu şirket “tek model, tek endpoint, ne gelirse” kafasında ilerliyor gıbı duruyor. Bunun iki sebebi var bence: Daha fazla bilgi için C++ Projelerinde PackageReference: NuGet Yeni Dönem yazımıza bakabilirsiniz.
Birinçisi: Türk geliştirici ekipleri AI kullanımında pragmatist oluyor; “Çalışıyor mu? Tamam, dokunma.” yaklaşımı ağır basıyor. Halbuki maliyet optimizasyonunda ciddi fırsatlar var. Daha fazla bilgi için Gemini 3.5 Flash GitHub Copilot’ta: Hızlı Model Dönemi yazımıza bakabilirsiniz.
İkinci sebep:, FinOps kültürü AI tarafında henüz tam oturmadı diyebilirim. Bir e-ticaret müşterimizde aylık Azure OpenAI faturası 18.000 USD’ye dayanmıştı; modelleri incelediğimizde — durun anlatayım — isteklerin %62’si aslında gpt-4o-mini‘yle rahatça çözülebilecek özet. Sınıflandırma işlerinden oluşuyordu. Router benzeri bir yapı kurduktan sonra fatura 7.200 USD’ye indi; üç ayda yatırım geri döndü gıbı öldü.
“Model Router’ın asıl değeri AI maliyetini düşürmek değil — geliştirici ekibin kafasından ‘hangı model?’ sorusunu çıkarmak. O bilişsel yük gidince ekip ürüne odaklanıyor.”
Küçük Ekip mi, Büyük Kurum mu?
Şöyle söyleyeyim, Burada net ayırmak lazım:
- Küçük ekip veya startup iseniz:
- Model Router’ı direkt production’a sokmayın.
- Önce 2-3 gün eval reposuyla kendi promptlarınızı test edin.
- Sonra Balanced moduyla başlayın ve iki hafta izleyin. (bence en önemlisi)
- Quality moduna geçmek için acele etmeyin.
- Eğer enterprise yapıdaysanız:
- Compliance subset’ını en başta kurun.
- Yanı hangı modellere routing olabilir hangilerine olamaz listesini netleştirin.
- Sonra eval reposuyla bu subset’in kalite ve maliyet etkisini ölçün.
- Yönetime savunulabilir rakamla gidin.
Maliyet Analizi: Gerçekten Tasarruf Ediyor müsünüz?
Pek sevdiğim kısma geldik şimdi — gerçek rakamlar işin rengini değiştiriyor çünkü laf değil veri konuşuyoruz. Bir müşterimiz için yaptığımız ölçümlerde tablo aşağı yukarı böyleydi: Daha fazla bilgi için Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımıza bakabilirsiniz.
| Senaryo | Ort. Maliyet (1K istek) | Puan Kalitesi | P95 Latency |
|---|---|---|---|
| Sadece GPT-4o | $8.40 | 0.91 | 2.8s |
| Router — Balanced | $3.10 | 0.88 | 2.1s |
| Router — Cost | $1.85 | 0.79 | 1.6s |
Sıkça Sorulan Sorular
Model Router kullanmak cebe ekstra maliyet bindi mi?
Evet, router’ın kendine ait bir input-prompt billing’i var. Bu, alttaki modelin maliyetine ekleniyor. Ama aslında ortalama bir workload’da daha küçük modellere yönlendirme yaptığı için net tasarruf ediyor oluyorsunuz. Eval reposu zaten bu hesabı sizin yerinize yapıyor — yanı tahmin yürütmeye gerek kalmıyor.
Mevcut OpenAI API çağrılarımı Model Router’a taşımak çok mu uğraştırır?
Bakın, Açıkçası, pratikte sadece endpoint’i ve deployment adını değiştiriyorsunuz. Kod tarafı neredeyse birebir aynı kalıyor. Ama bence production’a almadan önce muhtemelen eval yapın — çünkü prompt davranışları model değiştikçe farklılaşabiliyor, hani beklenmedik sürprizler olabiliyor.
Hangı mod (Balanced/Cost/Quality) çoğu durumda işe yarar?
Tecrübeme göre Balanced ile başlamak genellikle en sağlıklı orta yol. Sonuçlar kalite kriterinizi karşılıyorsa Cost moduna geçebilirsiniz (bizzat test ettim). Mesela sağlık veya finans karar destek gıbı kritik domainlerde Quality modundan ayrılmayın — küçük bir tasarruf için risk almaya gerçekten değmez.
Eval reposu Foundry’nın kendi benchmark aracının yerini tutar mı?
Tutmuyor, ama tamamlıyor. Yanı lokal eval hızlı ve esnek — prototip aşaması için ideal. Foundry’nın enterprise benchmarking’i işe governance, audit, portal görünürlüğü ve cloud-graded değerlendirme sunuyor. Bence ikisini birlikte kullanmak en doğrusu.
Türkiye’den hangı region’u seçmeliyim?
Şu an seçenekler East US 2 ve Sweden Central. Sweden Central latency açısından Türkiye’ye çok daha yakın — testlerimde hani 60-90ms civarında bir fark görüyorum. Data residency endişeniz varsa Data Zone Standard deployment tipini tercih etmenizi öneririm.
Kaynaklar ve İleri Okuma
Eh, Microsoft Foundry Blog: How to run evals for the model router (yanlış duymadınız)
İnanın, Azure AI Foundry Model Router Resmî Dokümantasyonu
Model Router Evals GitHub Reposu (Açık Kaynak)
Eh, Foundry Evaluation Approach for Generative AI
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.
