Outcome-Driven Learning: OpenEnv ve Foundry ile Kurumsal RL
Build 2026’dan sonra masama oturup gelen duyuruları tek tek okurken bir an durdum. Hosted agents, Toolboxes, Foundry IQ, Memory, Managed Compute, fine-tuning, Frontier Tuning, yeni bir evaluation ve optimization katmanı… Listeyi alt alta yazınca insan biraz kayboluyor açıkçası. Ama bir kahve daha içip tekrar baktığımda işin özünü gördüm: Microsoft aslında parça parça bir öğrenen sistem kitini önümüze koymuş.
İlginç olan şu ki, Chatbot değil. Bir soruya cevap verip unutan asistan da değil. Zamanla sizin işinizde ölçülebilir biçimde daha iyi olan bir ajan. Lafı dolandırmadan söyleyeyim: bu yazının konusu, o parçaları nasıl tek bir döngüye bağlayacağınız. Neden küçük, size ait bir modeli eğitmenin hâlâ — hatta her zamankinden daha çok — anlamı olduğu.
Önce şu “öğrenme döngüsü” lafının ne demek olduğunu konuşalım
Aslında, Jay Parikh’in son yazısında çok hoşuma giden bir cümle vardı: “AI tek başına işinizi değiştirmez, önü çalıştıran sistem değiştirir.” Satya da bunu biraz daha keskinleştiriyor: kalıcı varlık kiraladığınız model değil, sahibi olduğunuz öğrenme döngüsü. İkisi de aynı şeyi farklı açıdan söylüyor aslında (ben de ilk duyduğumda şaşırmıştım)
Ve işler burada ilginçleşiyor.
Şimdi bunu sahaya indirelim. Bir ajan kuruyorsunuz diyelim. Fatura mutabakatı yapıyor mesela, ya da müşteri sözleşmelerini inceliyor. İlk hafta %62 doğrulukla iş çıkarıyor. Peki ikinci ay? Üçüncü ay? Eğer cevabınız “yine %62, çünkü model bunu unutuyor” işe — işte tam burada bir learning loop eksik demektir.
Foundry’nın yaptığı şey, bu döngüyü açık, birlikte çalışabilir ve modüler şekilde kurmanıza izin vermek. Modeli değiştirebiliyorsunuz, trainer’ı değiştirebiliyorsunuz, tool’ları değiştirebiliyorsunuz —. Döngünün kendisi sizde kalıyor. Bu önemli bir nokta. Çünkü model gelir geçer (geçen ay GPT-5 vardı, bu ay başkası, önümüzdeki ay Anthropic’in yenisi), ama sizin biriktirdiğiniz öğrenme kalmalı.
Environment ve eval: Bir pilotu nasıl yetiştirirsiniz?
Bunu anlatmanın en temiz yolu uçuş simülatörü üzerinden gitmek gibi geliyor bana. Bir pilot adayını gerçek yolcu uçağına koyup “haydi öğren” demiyorsunuz; önce simülatöre sokuyorsunuz, hata yapıyor, toparlıyor, tekrar deniyor ve sonunda gerçek uçuşa geçtiğinde elinin ayağının nereye gittiğini biliyor.
Hmm, bunu nasıl anlatsamdı…
RL dünyasında environment (kısaca RLE — reinforcement learning environment) tam olarak bu. Ajanınızın pratik yapacağı alan. Sizin gerçek iş akışınızın kodlanmış hali: hangi adımlar var, hangi tool’lara izin var, hangi veriyi görüyor; yanı standart operasyon prosedürünüzü makinenin anlayacağı şekilde formüle etmiş oluyorsunuz.
Eval işe sonucu yargılayan kısım. Yanı simülatörden çıkan pilota “iyi miydin?” diye sorduğunuzda ona puan veren rubrik. Halka açık leaderboard’lar (söylemesi ayıp) değil bu — kendi outcome’unuza göre tanımlanmış net kriterler. “Faturayı sözleşmeyle eşleştirdi mi? Atıf yaptığı madde gerçekten var mı? Politika sınırları içinde mi kaldı?” Bu kadar somut.
Bir ajanın iyi mi kötü mü olduğunu söyleyemiyorsanız, o ajanı eğitemezsiniz. Bu kadar basit. Rubrik yoksa learning loop da yok; önce ölçüyü kurun sonra modele bakarsınız.
OpenEnv neden önemli?
Eh, Microsoft’un environment tarafında OpenEnv topluluğuna yanaşması bence boş hamle değil. Çünkü kurumsal tarafta ilk korku hep aynı yere çıkıyor: vendor lock-in. Bir environment’ı sıfırdan kodlamak haftalar alıyor; bunu sadece tek bir platformun formatına gömerseniz yarın başka altyapıya geçmek istediğinizde her şeyi yeniden sökmek zorunda kalırsınız.
Kısa bir not düşeyim buraya.
OpenEnv masaya standart bir arayüz koyuyor işte. Foundry’de çalıştırdığınız environment’ı yarın Tinker ile ya da başka gün başka bir trainer ile kullanabilirsiniz; kulağa sade geliyor ama pratikte baya fark ediyor açıkçası. Açık konuşayım: bu açıklık olmasaydı ben kurumsal müşterilere RL yatırımı önerirken iki kez düşünürdüm.
Hill-climbing döngüsü: Parçalar nasıl birbirine bağlanıyor?
Şunu söyleyeyim, Neyse uzatmayalım; taşları yerine dizince resim netleşiyor:
- Hosted agent: Sizin harness’ınız + Microsoft Agent Framework + değiştirilebilir bir model. Üçü beraber çalışıyor.
- ACA Sandbox: Her oturum için izole ortam; ajan burada deneme yapıyor.
- Tracing: Her adımı kaydediyor; hangi tool’u çağırdı, ne cevap aldı, ne karar verdi hepsi ortada dürüyor.
- Rubric: Sonucu yargılıyor ve puanlıyor.
- Öğrenme iki koldan: Non-parametric tarafta Agent Optimizer ve SkillOpt; parametric tarafta işe Foundry post-training, Tinker ve OpenEnv üstünde ECHO.
- Kazananı sakla: Yeni versiyon daha iyiyse Teams’e, Microsoft 365’e ya da başka kanallara dağıtın.
Doğrusu, Dikkat edin; bu döngünün altında Foundry IQ, Memory (bizzat test ettim) (eh, fena değil). Toolbox var — yanı grounding ve bağlam tarafı orada dürüyor. Discovery to Execution: Foundry’de Ajanları Toolbox ile Ölçeklemek yazımda Toolbox tarafına epey değinmiştim; oradaki dağıtım mantığı aslında bu döngünün “ajanı sahaya çıkarma” kısmına birebir oturuyor.
Non-parametric vs parametric: Ne zaman hangisi?
Peki neden insanlar burada karışıyor? Çünkü ikisi kulağa benzer geliyor ama oyun alanları farklı:
- Non-parametric öğrenme: Modelin ağırlıklarına dokunmuyorsunuz; prompt değişiyor, tool seçim stratejisi değişiyor, planlama biçimi değişiyor. Hızlı gidiyor ve çoğu zaman ilk denemeniz gereken yer burası oluyor.
- Parametric öğrenme: Modelin kendisi (ağırlıkları) eğitiliyor; daha pahalı ve daha yavaş ama belli noktadan sonra non-parametric sıkışınca atılacak adım genelde bu oluyor.
Sahada şunu sık görüyorum: ekipler hemen fine-tuning’e koşuyorlar ama bazen olay o değil ki; çoğu durumda Agent Optimizer ile baya yol alıyorsunuz zaten. Önce prompt. E peki, sonuç ne öldü? Orchestration tarafını sıkıştırın derim ben, sonra hâlâ rubrik skoru yerinde sayıyorsa ağırlıklara dokunun — para da zaman da daha az yanar böylece.
Evet… Türkiye perspektifi de ayrı hikâye
Bunu biraz yerel bağlamda anlatayım çünkü bizde tablo biraz farklı akıyor gibi hissediyorum ben de bazen hani. Türkiye’deki kurumsal müşterilerde RL ve fine-tuning konuşmaları son altı ayda ciddi şekilde arttı ama başlangıç cümlesi garip biçimde hep aynı yere geliyor: “GPT-4’ü Türkçe’ye fine-tune edelim.”
İnanın, Ama çoğu vakada sorun model değilmiş gibi dürüyor açıkçası; asıl eksik olan şey rubrik yokluğu. Geçen ay konuştuğum bir bankacılık ekibi de tam böyleydi mesela — ajanlarının yeterince iyi olmadığını söylüyorlardı ama “yeterince iyi”nın ne olduğuna dair tek satır bile yazmamışlardı; önce oturduk 25 maddelik rubriği çıkardık sonra Agent Optimizer ile non-parametric tarafa girdik ve fine-tuning bütçesi açılmadan skor %58’den %81’e yürüdü.
Anlatmak istediğim şu aslında: küçük ekipseniz parametric tarafa hiç bulaşmadan epey yol gidiyorsunuz; büyük kurumsal yapıdaysanız ve domain’ınız çok özelse (hukukta olur mesela sigortada olur tıbbi kodlamada olur) o zaman parametric eğitim mantıklı hâle geliyor — aradaki gri bölgede işe önce non-parametric’i tüketmek bence en temiz yaklaşım.
Maliyet kısmına gelince… TL bazında bakmazsanız sürpriz kaçınılmaz oluyor
Söz FinOps’a gelmişken şapkayı takıp konuşayım biraz; bu döngünün maliyet tarafını görmeden işe girişmek bence büyük hata oluyor çünkü teknik olarak doğru görünen şey bütçe yüzünden duvara toslayabiliyor.
| Bileşen | Aylık yaklaşık maliyet (orta ölçek) | Notlar |
|---|---|---|
| ACA Sandbox (per-session) | Trafik hacmine. Oturum sayısına çok bağlıdır> | |
| Tacing & telemetry> |
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.
2 comments