Build 2026: AI Ajanlarında Ölçümden ROI’ye Geçiş
Ne yalan söyleyeyim, Yapay zekâ ajanı çıkarmak kolay. Zor olan, önü prodüksiyonda düzgün, güvenli ve hesap verebilir tutmak. İşin aslı şu ki; demo günü parlak görünen bir ajan, iki hafta sonra model güncellendiğinde ya da tool zinciri değiştiğinde sessizce sapmaya başlayabiliyor. Ben bunu birkaç kurumsal projede birebir gördüm — özellikle de iş akışı uzun, karar sayısı çok ve ekipler farklı kıtalara yayılmışsa, küçük bir drift bile büyüyüp can sıkıcı hâle geliyor.
Yanı, Geçen yıl İstanbul’daki bir finans müşterisinde buna benzer bir tablo yaşadık (yanlış duymadınız). Ajan gayet güzel cevap veriyordu ama aynı soruya bazen üç farklı tool rotası izliyordu. İlk bakışta “idare eder” gibi görünüyordu, fakat rapor tarafında işler karıştı. Trace olmadan neyi niye yaptığını anlamak zor oluyor… Hani ne farkı var diyorsunuz, değil mi? Hani klasik log var ya, yetmiyor işte.
Hani, Bu yüzden Microsoft Foundry tarafındaki observability yaklaşımını önemli buluyorum. Sadece “kaç istek geldi” demek değil mesele; ajanın ne karar verdiğini, o kararın iyi mi kötü mü olduğunu ve zamanla iyileşip iyileşmediğini görmek gerekiyor — dürüst olayım, biraz hayal kırıklığı —. Bence Build 2026’daki mesaj da tam buraya oturuyor: gözlemle, değerlendir, düzelt ve sonunda işi paraya bağla.
Evet, doğru duydunuz.
Neden klasik izleme artık yetmiyor?
Şöyle ki, Geleneksel yazılım dünyasında mantık basitti: Aynı input, aynı output. Ajanlarda bu böyle çalışmıyor. Aynı prompt bugün başka bir tool’a gidebiliyor, yarın model sürümü değişince bambaşka bir yoldan ilerleyebiliyor. Biraz huysuz bir çalışan gibi düşünün; ona sadece vardiya giriş-çıkışını yazmak yetmez, hangi kararı neden aldığını da bilmeniz lazım.
Bakın, Ben AZ-305’e hazırlanırken mimarı tasarımda hep aynı noktaya dönüyorum: kontrol edemediğiniz şeyi ölçeklendirmeyin. Ajan tarafında da durum bu. İzleme yoksa güven yok; güven yoksa üretime alma cesareti de düşüyor. Hele kurumsal tarafta… CFO size “bu iş kaç para kazandırdı?” diye sormaya başladığında trace ekranının ötesine geçmek şart oluyor.
Bir de dürüst olayım: ilk denediğimde benim beklentim biraz yüksekti. “Eyvah” dedirten hata çıkmadı ama bazı metriklerin yorumlanması beklediğim kadar net değildi. Güzel özellik ama henüz ham; biraz daha pişmesi lazım dediğim yerler öldü. Mesela multi-turn senaryolarda rubric tasarlarken acele ederseniz sonuçlar çarpılabiliyor.
Trace, evaluate, monitör, optimize
Foundry’nın anlattığı çerçeve dört parçaya oturuyor: trace ile her adımı görüyorsunuz, evaluate ile kaliteyi ölçüyorsunuz, monitör ile canlı sorunları yakalıyorsunuz, optimize ile üretim sinyalini aksiyona çeviriyorsunuz. Bu dörtlü bana biraz mutfaktaki termometre-mikser-terazi düzenini hatırlatıyor; tek başına biri yetmez ama beraber olunca yemek kurtuluyor (ben de ilk duyduğumda şaşırmıştım)
Ajan projelerinde gerçek başarı “model seçtik” noktasında bitmiyor; asıl mücadele prodüksiyonda başlıyor.
Her framework’te görünürlük fikri neden önemli?
Build 2026’nın en hoş taraflarından biri bence şu öldü: observability’yi tek bir framework’e kilitlememeleri. LangChain kullanıyorsanız da olur, LangGraph kullanıyorsanız da olur, OpenAI SDK ile ayrı bir akışınız varsa o da olur (ilk duyduğumda inanamadım). Hatta custom framework bile olabilir. Kurumsal tarafta bu bayağı kilit çünkü çoğu şirket tek stack yaşamıyor zaten; herkes kendi köşesinde ufak çözümler üretiyor (kendi tecrübem)
Ankara’da çalıştığım bir telekom projesinde mesela orchestration katmanı Microsoft Agent Framework’tü ama retrieval tarafında başka kütüphaneler vardı. Ekibe “hepsini söküp yeniden yazalım” deseniz proje orada biterdi açık konuşayım. İşte interoperability burada değer yaratıyor: mevcut yapıyı bozmadan gözlem alabilmek.
Dürüst olmak gerekirse, Küçük startup için yaklaşım farklı tabiî. Sizde iki kişi varsa önce basit tracing yeterli olabilir; gereksiz karmaşıklığa gerek yok. Ama enterprise seviyede on takım aynı anda agent geliştiriyorsa standartlaşma şart oluyor — yoksa kimsenin trace’i kimseyle konuşmaz hâle geliyor.
| Senaryo | Daha mantıklı yaklaşım | Neden? |
|---|---|---|
| Küçük startup | Temel trace + basit evaluation | Hızlı kurulum, düşük operasyon yükü |
| Büyüyen ürün ekibi | Kural tabanlı rubric + dashboard | Sapmayı erken yakalar |
| Büyük kurum / regülasyonlu yapı | Tam lifecycle observability + Azure Monitör entegrasyonu | Denetlenebilirlik ve audit ihtiyacı yüksek |
Değerlendirme kısmı kağıt üstünde değil sahada önemli
Agenlerin değerlendirilmesi konusu kulağa akademik geliyor olabilir ama değil… Hatta baya pratik bir mesele bu (buna dikkat edin). Multi-turn görevlerde tek seferlik doğru cevabı ölçmek yetmiyor; ajanın konuşmanın sonuna kadar çizgiyi koruyup korumadığına bakmak gerekiyor (bizzat test ettim)
E tabi burada rubrik tasarımı devreye giriyor. “Doğru mu yanlış mı?” ikiliği bazen çocukça kalıyor çünkü iş kullanıcı deneyimine geliyor (mesela müşteri destek ajanı eksik bilgi verdi mi?), güvenlik sınırlarını aştı mı?, görevi tamamladı mı? Bunları birlikte görmek lazım.
Birkaç ay önce İzmir’deki perakende sektöründen bir müşteride tam bu probleme takıldık. Ürün öneri ajanı teknik olarak doğru cevap veriyordu ama tonlama yanlış olduğu için çağrı merkezî ekibi memnun değildi… Yanı sistem çalışıyordu fakat iş çözmüyordu! O gün anladım ki kalite skoru ayrı şeydir, iş değeri ayrı şey.
Kodla başlayan disiplin daha sağlam oluyor
{
"evaluation": {
"task_completion": true,
"safety": "pass",
"tool_usage": "optimal",
"multi_turn_consistency": "needs_review"
}
}
Bunu kod bloğu olarak görmek faydalı çünkü ekipler genelde soyut konuşmayı seviyor ama yönetim somut çıktı istiyor — hani grafikte yeşil-kırmızı çizgi olsun isterler ya… Burada amaç yalnızca puan vermek değil; puanın arkasındaki kanıtı toplamak.
Bir dakika — bununla bitmedi.
Maliyet ve ROI kısmını erteleyen ekipler sonradan yoruluyor
Açık konuşayım: birçok ekip observability’yi sever ama ROI kısmına gelince geriye çekilir. Halbuki CFO’nun duymak istediği şey tam orasıdır! Kaç saat kazandınız? Kaç hatayı erkenden yakaladınız? Kaç çağrıyı insan operatöre gitmeden kapattınız?
Bunu Türkiye’deki şirketler açısından değerlendirirsek maliyet hesabını döviz bazlı düşünmek zorundayız çünkü servis fiyatları TL’de sabit durmuyor gibi hissediliyor bazen (ve evet bu can sıkıyor). Bu yüzden pilot aşamada mutlaka kullanım limiti koyun, telemetry hacmini kontrol edin ve gereksiz verbose trace’i azaltın.
Eh, Eğer bütçe kısıtlıysa hemen full platforma abanmayın derim ben. Önce kritik use-case’i seçin: örneğin müşteri destek triage ya da iç bilgi asistanı gibi doğrudan etki eden alanlardan başlayın. Sonra genişletin. Kurumsalda en pahalı hata genelde teknoloji değil; yanlış kapsam seçimi oluyor.
Türkiye’den bakınca fark ne?
Şöyle ki, Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimsenme biraz daha temkinli ilerliyor çünkü herkes hem maliyeti hem regülasyonu düşünüyor hem de mevcut ERP/CRM yapısına dokunmak istemiyor.
Bir de insan kaynağı meselesi var; küçük ekiplerde aynı kişi hem DevOps hem data hem de AI işiyle uğraşıyor.
O yüzden “her şeyi sıfırdan inşa edelim” söylemi burada pek işlemiyor.
Hazır platformların güçlü yanı tam burada ortaya çıkıyor:
daha az operasyon yükü,
daha hızlı POC,
daha net governance.
Ama şunu da söyleyeyim — her hazır çözüm sihirli değnek değil.
Bazen beklediğiniz kadar esnek olmuyor.
Hayal kırıklığı yaratan nokta tam olarak bu olabiliyor.
Neyse uzatmayayım…
Peki neden?
Ben olsam nereden başlarım?
Lafı gevelemeden söyleyeyim: önce en değerli akışı bulun ve önü gözlemleyin.
Her yere eşit yatırım yapmak güzel görünür ama pratikte dağıtır sizi.
Önceliklendirme yapmadan agent ops kurarsanız üç ay sonra ortalık dashboard çöplüğüne dönebiliyor.
- Kritik agent yolculuğunu seçin.
- Trace standardını belirleyin.
- Multi-turn evaluation rubric hazırlayın. — bunu es geçmeyin
- Azure Monitör alarm eşikleri koyun.
- Pilot veriden ROI metriği çıkarın.
Bunu Logosoft’ta geçen sene Eylül ayında yaptığımız sağlık sektörü projesinde aynen uyguladık. İlk etapta yalnızca hasta yönlendirme akışını izledik. Sonra tekrar eden yanlış yönlendirmeleri tespit edip prompt’u daralttık. Netice? Çağrı merkezine giden gereksiz talepler azaldı ve ekip rahatladı. Mesele budur zaten — gösterişli demo değil, işe yarayan sistem!
Bazen hata iyileştirmenin başlangıcıdır
Dürüst olayım, ben de ilk kurulumda araç entegrasyonunda hata aldım; traced span’lar birbirine düşmüştü.
Sebep basitti aslında:
context propagation eksikti.
Çözümü bulunca her şey yerine oturdu.
Bu tarz sorunlar insanı deli eder ama öğreticidir de.
Azure Functions tabanlı yan servislerle ana agent arasında correlation id taşımıyorsanız debug süresi uzar gider…
`
Sıkça Sorulan Sorular
Ajanlarda observability neden bu kadar önemli?
Çünkü ajanlar deterministik çalışmıyor; yanı aynı girdiye farklı yollarla cevap verebiliyorlar (yanlış duymadınız). Observability olmadan neyin değiştiğini anlamanız mümkün değil. Bu ne anlama geliyor? Açıkçası prod ortamda güven ve denetlenebilirlik için bence bu kesinlikle şart.
Tüm framework’leri tek yerde izlemek mümkün mü?
Evet, hani Build 2026’daki mesajın tam da önemli kısmı bu zaten. Farklı framework’lerden gelen sinyalleri ortak bir trace ve evaluation katmanında toplayabiliyorsunuz. Böylece ekipler stack’ten bağımsız çalışabiliyor; tecrübeme göre bu çok büyük bir rahatlık sağlıyor.
Küçük ekipler için en iyi başlangıç ne?
Kritik akışı seçip temel tracing ile başlamak en doğrusu. Sonra basit bir rubric evaluator ekleyin. Her şeyi aynı anda yapmaya kalkarsanız süreç ağırlaşıyor; aslında adım adım gitmek çok daha mantıklı.
Ajan performansını nasıl ROI’ye çevirebilirim?
Zaman kazancı, insan müdahalesindeki azalma, yanlış işlem oranındaki düşüş gibi metrikleri takip edin. Bunları parasal karşılıkla ifade ettiğinizde yönetimin diliyle konuşmuş oluyorsunuz; bence bu adım çoğu zaman göz ardı ediliyor. Çok işe yarıyor.
Kaynaklar ve İleri Okuma
- Orijinal Microsoft Foundry duyurusu
- Microsoft Azure AI Foundry resmî dokümantasyonu
- Azure Monitör resmî dokümantasyonu
- Foundry değerlendirme kavramları
target=”_blank” rel=”noopener”>Foundry değerlendirme kavramları
target=”_blank” rel=”noopener”>Foundry değerlendirme kavramları resmî rehberi”>
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.
4 comments