Agent Optimizer ile Kurumsal Yapay Zekâyı Pişirmek
Açık konuşayım, Geçen ay, Şubat 2026’da İstanbul’da bir müşteride tam da şu cümle havada kaldı: “Model çalışıyor, ama üretimde bazen saçmalıyor.” İşin aslı şu ki, agent tarafında en pahalı kısım çoğu zaman modeli ayağa kaldırmak değil; önü derli toplu davranacak hâle getirmek. Foundry Agent Service üstünde hosted agent kurmak kolay. azd deploy deyip geçiyorsunuz. Ama canlıya çıkmakla üretime hazır olmak arasında epey fark var (eh, fena değil). bayağı epey.
Ben bu farkı ilk kez 2019’da kendi lab ortamımda yaşamıştım. O zamanlar Azure üstünde küçük bir destek botu deniyordum; her şeyi prompt’a yüklemiştim, sonra ufak bir değişiklikte başka senaryo bozuluyordu. Bir şey düzeliyor, iki şey kırılıyordu. Hani klasik durum. Bugün Agent Optimizer’ın anlattığı problem de biraz o: elinizde çalışan bir agent var,. Tutarlı çalışan bir agent yok.
Kısa bir not düşeyim buraya.
Bu yazıda konuya Microsoft Build duyurusu gibi bakmayacağım; daha çok kurumsal tarafta bunun neye denk geldiğini anlatacağım. Çünkü startup dünyasında “hızlıca deneyelim” demek kolaydır,. Banka, sigorta ya da perakende gibi yerlerde iş öyle yürümez. Orada kalite, maliyet ve izlenebilirlik aynı anda masaya gelir. Biri eksikse proje tökezler.
Neden bu kadar kritik?
Eh, Bakın şimdi, agent projelerinde en büyük tuzak şu: ilk demo güzel görünür. Müşteri temsilcisi botu sipariş numarasını sormadan durum bakar, iade tarihini kontrol etmeden garanti konuşur, hatta bazen elektrik tesisatı hakkında bile fikir yürütmeye kalkar… Evet, kulağa komik geliyor ama ben bunu 2025’te Ankara’daki bir saha demosunda birebir gördüm. Demo sırasında herkes gülümsedi; ertesi gün güvenlik ekibi yüzünü astı.
Kurumsal tarafta sorun prompt’u elle oynayarak çözülmeye çalışılıyor çoğu zaman. Az önce X dedim ama aslında Y daha doğru olabilir: mesele sadece prompt yazmak değil, o prompt’un farklı senaryolarda nasıl davrandığını ölçmek. AZ-305 sınavına hazırlanırken mimarı kararların tek bir servis seçmekten ibaret olmadığını öğreniyoruz ya; burada da aynı mantık var. Doğru sistem tasarımı olmadan iyi sonuç kalıcı olmuyor (inanın bana)
Hmm, bunu nasıl anlatsamdı…
Bir de maliyet kısmı var. Küçük ekipler için birkaç test koşusu idare eder gibi görünebilir. On agent’lık bir portföyde bir düşüneyim… manuel iyileştirme resmen çorap söküğü gibi uzuyor. Token tüketimi artıyor, insan zamanı gidiyor, test tekrarları bitmiyor. Açık konuşayım: işin en yorucu kısmı para değil sadece, dikkat kaybı da oluyor (evet, doğru duydunuz)
Agent Optimizer nasıl çalışıyor?
Kısaca closed-loop bir süreç var. Önce baseline ölçülüyor. Sonra optimizer başarısız örnekleri görüyor ve yeni adaylar üretiyor. Bu adaylar tekrar aynı test setinden geçiyor. En sonda skorlar karşılaştırılıyor ve sız de en iyi sonucu seçiyorsunuz. Aslında bu kadar basit… ama detayda iş büyüyor.
Durun, bir saniye.
Bence buradaki güzel taraflardan biri şeffaflık olması. Sadece “daha iyi öldü” demiyor; hangi görevde ne yaptı gösteriyor, token maliyetini de yanına koyuyor. Ben bunu özellikle seviyorum çünkü kurumsal müşteride teknik doğruluk kadar savunulabilirlik de önemli oluyor. Bu ne anlama geliyor? Yöneticiye “daha iyi hissettik” diyemezsiniz; sayı göstermeniz gerekir.
Bak şimdi, Geçen yıl İzmir’de bir finans kuruluşunda benzer yaklaşımı manuel yaptık: destek akışlarını tek tek test ettik, sorunlu soruları listeledik ve prompt revizyonlarını küçük paketler halinde uyguladık. O zaman otomasyon yoktu; açık söyleyeyim bayağı zahmetliydi. Agent Optimizer bu işi biraz makineye bırakıyor gibi düşünün — hani mutfakta tadımı sürekli yapan yardımcı şef gibi.
| Aşama | Ne yapıyor? | Neden önemli? |
|---|---|---|
| Baseline değerlendirme | Mevcut agent test edilir | Başlangıç çizgisi netleşir |
| Aday üretimi | Sistem prompt / skill / model varyantı çıkarılır | Düzeltme yönü otomatikleşir |
| Aday testi | Aynı görev seti yeniden çalışır | Kıyas adil olur |
| Sıralama ve öneri | Puanlara göre seçim yapılır | Tahmin yerine veri gelir |
| Yayınlama | Kazanan yapı canlıya alınır | Döngü kapanır |
Instruction mı, skill mi, model mi?
Burası önemli çünkü her optimize etme aynı şey değil. Instruction derseniz sistem prompt’u iyileştiriyorsunuz; skill derseniz tekrar kullanılabilir prosedürler yaratıyorsunuz; model seçimi işe kalite-maliyet dengesine dokunuyor. Enterprise tarafta ben genelde önce instruction ile başlatıyorum çünkü etkisi hızlı görülüyor. azure-functions-skills: Azure Functions İçin Yapay Zekâ Çalışma Alanı yazımızda bu konuya da değinmiştik.
Küçük startup işe daha agresif olabilir: tek ekip varsa instruction + model ikilisi yeterli olur çoğu durumda. Ama büyük kurumdaysanız (belki yanılıyorum ama) skill yaklaşımı değerli hâle geliyor; çünkü aynı davranışı farklı ekiplerin tekrar kullanması gerekiyor. Bir yerde yapılan düzeltme başka departmanda da işe yarasın istiyorsunuz. GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı yazımızda bu konuya da değinmiştik.
Benim gözümde Agent Optimizer’ın asıl gücü “tek seferlik düzeltme” değil; tekrarlanabilir iyileştirme döngüsü kurması.
Eğer bunu süreç hâline getirmezseniz araç sadece parlak bir demo olarak kalır.
Bunu birkaç projede gördüm.
Kurumsal kullanımda nerede parlıyor?
Şimdi gelelim sahaya… Kurumsal müşteri desteği senaryolarında bu araç bayağı iş görüyor çünkü çok sayıda edge case var: sipariş tarihi sorulur mu, fatura kimliği istenir mi, garanti dışı durumlarda nasıl reddedilir? Bunları elle yakalamak zorlaşıyor.
İtiraf edeyim, Bir de compliance tarafı var tabiî.
Bazı cevapların verilmemesi gerekiyor.
Agent yanlış yere kayarsa olay büyür.
Büyür yanı.
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo netleşiyor: birçok ekip hâlâ AI projesini PoC seviyesinde tutuyor çünkü kaliteyi ölçen altyapıları zayıf kalıyor.
Müşterilerimde gördüğüm kadarıyla asıl bariyer model değil;
test disiplini.
İnsanlar prompt yazmayı biliyor. Regresyon seti kurmayı ihmal ediyor.
Sonra küçük değişiklik büyük hasar veriyor… Daha fazla bilgi için Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı? yazımıza bakabilirsiniz.
E tabi bütçe konusu da hafife alınmamalı.
Azure tarafında böyle optimize eden servisleri kullanırken TL bazında düşününce,
özellikle yüksek kullanım hacminde,
token maliyeti kadar operasyon zamanı da fiyatın içine giriyor.
Yanı “servis ücretsiz olsun” diye bakıp insan emeğini unutursanız,
hesap şaşıyor.
Bir arkadaşım Kadıköy’deki SaaS girişiminde bunu yaşadı;
3 ay boyunca elle inceleme yapınca ekip neredeyse iyileştirme bütçesini personel saatinde harcadı.
Küçük ekip vs enterprise yapı
- Küçük ekip: Önce az sayıda yüksek etkili task belirleyin.
- Küçük ekip: Instruction iyileştirmeuyla başlayın.
- Büyük kurum: Skill katmanını standartlaştırın.
- Büyük kurum: Test setlerini departman bazlı ayırın.
- Büyük kurum: Maliyet raporunu aylık izleyin.
- Tümü: Canlıya almadan önce insan onayı koyun.
Sahada öğrendiğim birkaç ders
2024 sonbaharında Bursa’daki bir üretim firmasında AI destekli iç yardım masası kurarken benzer hataya düştük: test seti çok temizdi ama gerçek kullanıcı soruları kirliydi.
Optimizer olsa bile kötü task seti verirseniz kötü sonuç alırsınız.
Burada araç sizi kurtarmıyor;
aksine çıplak gerçeği gösteriyor.
Bu biraz can sıkıcı olabilir ama faydalıdır da…
hayal kırıklığı yaratan taraf bu işte tam olarak o:
veriniz kötüyse sistem önü saklamıyor. Daha fazla bilgi için yapay konusundaki yazımız yazımıza bakabilirsiniz.
Murat Bey’le yaptığımız oturumda (kendisi BT müdürüydü) şöyle dedim:
“Önce yanlış cevapları toplayın.”
Çünkü doğru cevapları toplamak kolaydır;
esas kıymet yanlışlarda yatıyor.
Bir kez hata kataloğu çıkardığınızda optimizer’a verecek malzemeniz oluyor.
Yoksa boş duvara konuşmuş oluyorsunuz. Bu konuyla ilgili Azure Cosmos DB’de Silinenleri Görmek: Change Feed’in Sessiz Gücü yazımıza da göz atmanızı tavsiye ederim.
$ azd ai agent optimize
Optimizing agent "travel-approver"...
Baseline saved to.agent_configs\baseline\metadata.yaml
Job ID: opt_999f814ed77a....
Status: pending
Portal: https://ai.azure.com/nextgen/....
completed · iteration 2 · score: 1.0
Vallahi, Dikkat edin burada sihir yok.
Komut basit görünüyor,
ama arka planda değerlendirme,
aday üretimi,
yeniden test etme ve sıralama yapılıyor.
Benim hoşuma giden şey şu:
operasyon karmaşasını gizlemiyor,
sadeleştiriyor.
Bu fark önemli!
Bence en güçlü kullanım şekli ne?
Lafı gevelemeden söyleyeyim:
ben bunu ilk etapta müşteri destek botlarında,
sonra iç bilgi asistanlarında kullanırım.
Satış öncesi demo botlarında işe dikkatli olurum;
çünkü orada marka riski daha yüksek olabilir.
Kağıt üstünde süper duran bazı iyileştirmeler pratikte beklediğim kadar iyi çıkmayabiliyor…
özellikle de görev tanımları gevşekse.
İşin aslı şu ki disiplin olmadan optimize etme sadece kozmetik kalır.
Eğer bütçeniz kısıtlıysa,
tam kapsamlı iyileştirme yerine önce dar bir alan seçin:
örneğin sadece iade politikası veya sadece sipariş takibi.
Ben olsam ilk adımı şöyle atarım:
1) En çok gelen 20 soruyu çıkarırım,
2) Başarısız örnekleri etiketlerim,
3) Baseline skorunu alırım,
4) Sonra optimizer ile yalnızca o kümeyi iyileştiririm.
Bu yaklaşım hem ucuz hem öğretici oluyor.
Neyse uzatmayayım:
küçük başlayıp ölçerek büyümek burada altın kural.
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