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)
📋 İçindekiler
-
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.
💡 Bilgi: Kültürünüz hazır değilse en iyi platform bile tek başına çözüm olmaz.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.
- Kritik metriklerini yazılı hâle getir.
- Maliyeti haftalık takip et.
- Kullanıcı geri bildirimini prompt iyileştirmesine bağla.
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:
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
İlginizi Çekebilir
Selin N.
Maliyet kısmı gerçekten kritik, özellikle production’a geçince token hesapları patlamaya başlıyor. Foundry’de kalite ölçümünü nasıl yapıyorsunuz, kendi metriklerinizi mi kuruyorsunuz yoksa hazır bir şey mi kullanıyorsunuz?
Hakan G.
Kalite ölçümü kısmı çok kritik, çoğu zaman model seçimine odaklanıp bunu atlıyoruz. Acaba farklı modeller arasında A/B testi yapıyor musunuz Foundry üzerinde? Bu arada Kubernetes tarafıyla ilgilenenler için şu yazı da değerliydi: https://www.askinkilic.com.tr/kubernetes-dashboarddan-headlampa-neden-gecis-mantikli/
İrem B.
Özellikle “doğru anda çalıştırmak” kısmı çok yerinde bir nokta, bunu genelde atlıyoruz. Peki siz kalite ölçümünde hangi metrikleri kullanıyorsunuz, sadece maliyet-performans dengesiyle mi karar veriyorsunuz?
3 comments