Foundry’de Model, Maliyet ve Kaliteyi Ben Nasıl Yönetiyorum?
Tuhaf ama, Yapay zekâ projelerinde en pahalı hata, artık yanlış model seçmek değil. Asıl mesele, doğru modeli doğru anda çalıştırmak, kaliteyi ölçmek, maliyeti zıplatmamak. Işin sonunda “bu sistem prod’da niye böyle davrandı?” sorusuna net cevap verebilmek. İşin aslı şu ki, prototipte parlak duran bir çözümün üretimde tökezlemesi bayağı normal. Hatta ben bunu 2024’te bir finans müşterisinde birebir gördüm; demo günü alkış alan akış, gerçek trafik gelince gecikme ve tool çağrısı karmaşası yüzünden ufak bir hayal kırıklığına dönüştü (inanın bana)
Bak şimdi, Microsoft Foundry’nın son dönemde verdiği mesajı ben tam burada önemli buluyorum: “Model var” demek yetmiyor. Seçim, değerlendirme, yönetişim ve operasyon tarafını tek bir disipline oturtmazsanız, bugün güzel çalışan sistem yarın bütçe canavarı olabiliyor. Bu yazıda konuyu biraz kendi gözümden anlatacağım; çünkü 20+ yıllık altyapı ve bulut tecrübemde şunu defalarca gördüm: teknoloji değişiyor ama işletme gerçeği pek değişmiyor. Bir şey çalışıyorsa tamam değildir; kalıcı değilse aslında bitmemiştir.
Bunu biraz açayım.
Asıl mesele model bulmak değil, modeli yaşatmak
Ben eskiden “en iyi model hangisi?” sorusunun çok baskın olduğunu düşünürdüm. Az-305’e hazırlanırken de mimarı kararların çoğu böyle başlar diye ezber yaparsınız ya… sonra gerçek dünya geliyor ve o soru tek başına anlamsız kalıyor. Çünkü üretimde aynı anda birkaç şeyi yönetmeniz gerekiyor: gecikme süresi, güvenlik sınırları, throughput, veri egemenliği, maliyet ve kalite.
Geçen yıl İstanbul’daki bir perakende müşterisinde RAG tabanlı destek asistanı kurarken bunu net hissettik. İlk sürümde kuvvetli bir model kullandık, sonuçlar fena değildi (yanlış duymadınız). Ama yoğun saatlerde yanıt süresi uzayınca müşteri memnuniyeti düşmeye başladı. Orada anladık ki sorun “model kötü” değil; kullanım senaryosuna göre yanlış yerde kullanılıyordu. Yanı kısaca: büyük model her zaman doğru seçim olmuyor.
Foundry’nın hoşuma giden tarafı şu: model agnostik yaklaşımı ciddiye alıyor. Microsoft modelleri, açık kaynak modelleri, partner modelleri… hepsini aynı yüzeyde ele almak bana operasyonel olarak daha sağlıklı geliyor. Hele bir de de kurumsalda vendor lock-in korkusu boş bir korku değil; bir gün fiyat politikası değişiyor, ertesi gün kapasite daralıyor. E tabi işler karışıyor.
Ve işler burada ilginçleşiyor.
Ben olsam değerlendirmeyi nasıl kurarım?
Vallahi, Bir AI uygulamasını değerlendirirken ben üç katmanlı bakıyorum: çıktı kalitesi, iş hedefi uyumu. Operasyonel dayanıklılık. Kağıt üstünde iyi görünen bir cevap ile gerçekten işe yarayan cevap arasında fark oluyor. Bayağı fark oluyor hatta! Mesela hukuk dokümanı özetleyen bir ajan için “güzel özetliyor” demek yetmez; hayatı maddeleri kaçırıyor mu, tarihleri doğru mu aktarıyor mu, halüsinasyon oranı ne durumda bunlara bakmanız lazım.
Kurumsal projelerde genelde ilk hata şu oluyor: ekipler evaluation’ı sonradan eklemeye çalışıyor. Bu bana hep ters gelir. Evaluation sonradan takılan emniyet kemeri gibi davranmamalı; tasarımın içine gömülü olmalı. 2023’te Ankara’daki bir enerji şirketinde yaptığımız PoC’de bunu zor yoldan öğrendik — kullanıcı kabul testleri geçilmişti ama gerçek saha verisine girince bazı edge-case’lerde modelin tutarlılığı dağıldı. Sonra özel test setleri hazırladık ve iş düzeldi.
Şimdi gelelim işin can alıcı noktasına.
Küçük ekip mi büyük kurum mu?
Küçük startup iseniz her şeyi mükemmel ölçmeye çalışmayın; boğulursunuz. Önce basit metriklerle başlayın: doğruluk hissi var mı, latency kabul edilebilir mi, token tüketimi uçuyor mu? Sonra yavaş yavaş genişletin.
Bakın, Büyük enterprise yapıdaysanız iş biraz daha serttir. Güvenlik onayı, audit izi, veri sınıflandırma ve rol bazlı erişim gibi konular masanın üstünde durur. Yanı “çalıştı” demek yetmez; “kim neye erişti”, “hangi versiyon ne zaman devreye girdi”, “hangi prompt değişti” gibi sorular da cevap ister.
Prod ortamında en pahalı şey GPU değil; kontrolsüz belirsizliktir.
Maliyet kontrolü: TL bazında düşününce tablo değişiyor
İtiraf edeyim, Açık konuşayım (evet, doğru duydunuz). Türk şirketlerinde AI bütçesi konuşulurken çoğu zaman dolar kuru sessizce odaya giriyor ama kimse ona bakmak istemiyor. Azure tarafında token bazlı tüketim küçük görünür; ta ki ay sonu faturası gelene kadar! O yüzden Foundry tarzı platformlarda model routing ve kullanım sınırlaması çok değerli hâle geliyor. Daha fazla bilgi için JetBrains’te Copilot Desteği Bitiyor: Sürümünüzü Şimdi Kontrol Edin yazımıza bakabilirsiniz.
Ben Logosoft’ta danışmanlık verirken özellikle FinOps perspektifini hiç kaçırmamaya çalışıyorum. Bir bankacılık projesinde geçen sene yaptığımız analizde şunu gördük: yüksek kaliteli ama pahalı modeli her sorguda kullanmak yerine sadece karmaşık işlerde devreye almak toplam maliyeti ciddi düşürdü. Basit sorguları daha hafif modele yönlendirdik; müşteri fark etmedi bile ama fatura baya rahatladı.
| Senaryo | Önerilen yaklaşım | Neden? |
|---|---|---|
| Sohbet botu / FAQ | Daha hafif model + cache | Düşük maliyet, yeterli kalite |
| Karmaşık tool calling agent | Daha sağlam model + sıkı eval | Daha az hata riski |
| Kritik kurumsal iş akışı | Routing + guardrail + rollback planı | Operasyonel güvenlik |
| Pilot çalışma | Sınırlı quota + ölçümlü deneme | Bütçe sürprizi yaşamamak için |
Ne yalan söyleyeyim, Bir de şu var: bütçe kısıtlıysa illâ en yeni modele koşmayın. Bazen orta seviye bir model ile doğru retrieval tasarımı birleşince sonuç gayet iş görüyor. Tahmin eder mısınız? SQL + AI tarafında da benzerini gördüm; veri düzgünse mucize aramıyorsunuz zaten. Daha fazla bilgi için GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı yazımıza bakabilirsiniz.
Model Router neden önemli hâle geldi?
Model Router fikri ilk duyulduğunda kulağa fazla “platform işi” gibi gelebiliyor ama pratikte oldukça faydalı. Çünkü her isteği aynı modele göndermek çoğu zaman gereksiz pahalı ya da gereksiz riskli oluyor. Basit sorgu basit modele gider, hassas veya karmaşık işlem güçlü modele gider (şaşırtıcı ama gerçek). mantık bu kadar sade aslında. Bu konuyla ilgili Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı? yazımıza da göz atmanızı tavsiye ederim.
Bunu günlük hayattan şöyle anlatıyorum müşterilere: Her soruya profesör çağırmazsınız ki! Market listesi için doktora yapmış biri gerekmez… ama stratejik karar için de rastgele cevap veren hafif sistemle idare edemezsiniz.
Garip gelecek ama, Açıkçası bu yaklaşımın biraz ham kalan tarafları da var. Routing kuralları yanlış kurulursa kaliteyi düşürebilirsiniz ya da beklenmedik şekilde latency ekleyebilirsiniz. Yanı sihir değil bu; iyi tasarlanmış karar ağacı gerekiyor.
# Basit örnek mantık
if request.is_simple_faq:
route_to = "lightweight-model"
elif request.needs_tool_calling or request.is_sensitive:
route_to = "high-capability-model"
else:
route_to = "balanced-model"Türkiye’de kurumsal benimseme neden farklı ilerliyor?
Bunu Türkiye’deki şirketler açısından değerlendirirsek (ben de ilk duyduğumda şaşırmıştım). bence ana fark veri olgunluğu ile satın alma döngüsünün uzunluğu arasında çıkıyor (kendi tecrübem). Birçok kurumda veri dağınık oluyor ama beklenti çok hızlı sonuç almak yönünde ilerliyor. AI tarafında işe hızlı sonuçla kalıcı çözüm aynı şey değil.
Büyük kurumlarda güvenlik ekipleri haklı olarak temkinli davranıyor; küçük ekiplerde işe hız baskısı yüksek oluyor çünkü rekabet sertleşmiş durumda. Kurumsal tarafta governance daha erken gelmeli diyorum ben — yoksa sonradan eklemek hem pahalı hem yorucu oluyor (bu konuda ikircikliyim). Startup tarafında işe fazla bürokrasi ürünü öldürebiliyor, yanı denge önemli! Daha fazla bilgi için PowerToys 0.98: Yeni Düzen, Daha Hızlı Akış yazımıza bakabilirsiniz.
Geçen mart ayında İzmir’de görüştüğüm orta ölçekli bir yazılım firması vardı; onlar önce en pahalı modeli alıp sonra niye bütçe patladı diye şaşırmışlardı. Çözümü birlikte sadeleştirdik:retrieval katmanını iyileştirdik, prompt’u kısalttık, evaluation set hazırladık. Ürün kalitesi düştü mü? Hayır. Maliyet düştü mü? Epey düştü. SQL + AI: Elinizdeki Veriyi Bozmadan Akıllı Uygulama Kurmak yazımızda bu konuya da değinmiştik.
Eğer yeni başlıyorsanız ne yapmalısınız?
- Önce tek use-case seçin;
- Kritik başarı metriğini belirleyin;
- Kullanıcıdan gelen gerçek örneklerle eval set oluşturun;
- Maliyeti token bazında izleyin;
- Düşük riskli işleri hafif modele yönlendirin;
Nerede hayal kırıklığı yaşanabilir?
Bazı platformlar kağıt üstünde çok düzenli görünüyor ama pratikte ekiplerin öğrenme eğrisini hafife alabiliyorlar. İşte burada küçük bir hayal kırıklığı notu düşeyim:her şeyi tek panelde toplamak güzel fikir,ama bazı takımlar için başlangıçta fazla soyut kalabiliyor. İnsanlar önce hangi metriğe bakacağını anlamakta zorlanıyor.
Bence Foundry’nın gücü buradan geliyor ama aynı zamanda zayıf noktası da bu olabilir:esneklik arttıkça karar verme yükü de artıyor. Eğer organizasyonda sahiplik net değilse,model seçimi tartışması bitmez. Birisi kalite der,birisi maliyet der,birisi latency der… sonra toplantılar uzar gider.
Sadece teknoloji değil, işletme disiplini gerekir
>
AZ-500 çalışırken öğrendiğim şeylerden biri şuydu:güvenlik kontrolleri sonradan eklenen boya değildir.AI sistemlerinde de durum aynı. Logging,policy enforcement,rate limit,rollback planı… bunların hepsi canlıya çıkmadan önce düşünülmeli.Ayrıca denetim izini seviyorum çünkü olay çıkınca kurtarıcı oluyor. Geçen yıl Temmuz ayında Antalya’daki bir SaaS müşterisinde beklenmedik kalite düşüşünü ancak eski evaluation kayıtlarına bakarak yakaladık. Yeni prompt versiyonu belli koşullarda daha kısa cevap üretiyormuş;öyle ortaya çıktı.
İyi AI operasyonu görünmez olur;kötüsü işe bütçeyi ve sabrı birlikte yer.
Sana bırakacağım pratik okuma haritası
>
<<
/*
Oops purposely not use markdown? but output HTML only should be valid enough maybe not perfect*/
>>
Şunu söyleyeyim, Eğer bugün başlayacak olsam ilk iş şu üç şeyi yaparım:use-case’i daraltırım,gerçek veriden küçük bir eval set çıkarırım,sonra da iki farklı modeli yan yana denerim. Burada amaç mükemmeli bulmak değil;işe yarayan düzeni görmek.
Sıkça Sorulan Sorular
Microsoft Foundry ile her problem çözülüyor mu?
Hayır, yanı tek başına sihir yapmıyor. Foundry size seçim, değerlendirme ve operasyon için sağlam bir çatı veriyor ama veri kalitesi, süreç disiplini ve sahiplik yine sizde kalıyor. Bence en iyi sonucu, iyi tasarlanmış kullanım senaryolarında alıyorsunuz zaten.
Model Router kullanmak maliyeti gerçekten düşürüyor mu?
Evet, çoğu senaryoda düşürüyor. Hani basit istekleri hafif modellere yönlendirmek gereksiz token harcamasını azaltıyor. Ama router kuralını kötü kurarsanız, açıkçası tam tersi etkiyi de görebilirsiniz.
Küçük ekipler nereden başlamalı?
Önce tek bir use-case seçsinler ve küçük bir evaluation set oluştursunlar. Ardından latency ve maliyet takibi yapsınlar. Tecrübeme göre başlangıçta kapsam dar tutulursa ilerleme çok daha hızlı oluyor.
Büyük kurumlarda en kritik konu nedir?
Açık konuşayım, Bence governance ile izlenebilirlik ilk sırada geliyor. Mesela kim hangi modeli kullandı, hangi veri geçti, hangi sürüm canlıda kaldı gibi sorulara net cevap vermek gerekiyor. Aksi hâlde pilot bitiyor ama prod bir türlü başlamıyor.
Kaynaklar ve İleri Okuma
İtiraf edeyim, Microsoft Build — A Developer’s Guide to Managing Models in Microsoft Foundry
Azure AI Foundry Resmî Dokümantasyonu
Azure AI uygulamalarını değerlendirme rehberi
İlgili Yazılarımdan Notlarım:
Copilot" data-glossary-term="GitHub Copilot">GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı:
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.
Yorum gönder