Frontier Tuning: AI’ı Şirketinizin Diline Öğretmek
Build 2026 sahnesinde Microsoft’un duyurduğu şeyleri tek tek not alıyordum, açık konuşayım, bir kısmı bana “yeni ambalaja sokulmuş eski şarap” gibi geldi. Ama Frontier Tuning ayrı yerde dürüyor. Lafı gevelemeden söyleyeyim: (belki yanılıyorum ama) Bu duyuru, kurumsal AI tarafında yıllardır dönen “model bizim işi öğrensin. Sız hiç denediniz mi? Veri dışarı çıkmasın” meselesine baya somut bir karşılık veriyor.
Şu an private preview’da, üstelik sadece Forward Deployed Engineer’lar üzerinden erişilebiliyor. Yakında Microsoft Copilot Studio — ki bu tartışılır — ve Microsoft Foundry içinden de açılacak, yanı kapı biraz daha aralanacak; ama işin aslı şu ki, ben bu noktada sadece erişim modeline değil, kurumların bunu nasıl konumlandıracağına da bakıyorum (çünkü teknik taraf kadar organizasyon tarafı da can sıkabiliyor). Ben de oturup bu işin altında ne var, gerçek hayatta iş görür mü, Türkiye’deki kurumlar buna nasıl yaklaşmalı, hepsini kendi kafamda tartıp yazmak istedim.
İşte tam da bu noktada devreye giriyor.
Frontier Tuning Tam Olarak Ne Yapıyor?
Önce kavramı yerine koyalım. Klasik fine-tuning’i biliyorsunuz; base model alırsınız, kendi verinizle eğitirsiniz, sonra çıktıyı kullanırsınız. Ama iş orada bitmiyor, çünkü veri değişiyor, süreçler kayıyor, model de bir süre sonra eskiyor; yeniden eğitim, yeniden deployment, yeniden değerlendirme derken insanın başı dönüyor.
Frontier Tuning tam burada devreye giriyor. Modeli “kitap okuyarak” değil, iş yaparken gelen geri bildirimle öğretiyor diyebiliriz; yanı reinforcement learning tarafını öne çıkarıyor (yanlış duymadınız). Bunu sizin compliance sınırınızın içinde kalan yönetilen bir Reinforcement Learning Environment (RLE) içinde dönduruyor. Şey, kulağa sade geliyor ama arka tarafta baya iş var.
Bence kilit nokta şu: RLE hem post-training için hem de inference için kullanılıyor. Yanı “eğittik bitti” diye bir dünya (söylemesi ayıp) yok; her etkileşim yeni bir sinyal oluyor ve sistem buna göre cevap kalitesini toparlıyor. Hatta inference sırasında bile birden fazla frontier ve fine-tuned modeli (Microsoft AI ve OpenAI taraflı) yan yana koyup en iyi yolu arıyorlar, biraz zahmetli görünüyor ama mantık olarak oturuyor.
Bunu biraz açayım.
Burada, peki neden? Çünkü kurumsal tarafta asıl dert model kurmak değil, modeli ayakta tutmak. Bir gün çalışan şeyin üç ay sonra tökezlemesi hiç sürpriz olmuyor; bu yüzden eğitim ile kullanım arasındaki çizgiyi yumuşatmak fena fikir değil.
“Eğitim ve çıkarımın aynı çevrede yaşaması” lafta basit dürüyor ama mühendislik olarak çok ciddi bir taahhüt. Eğer söylendiği gibi çalışırsa, kurumsal AI’da bakım maliyetlerini kökten değiştirebilir.
Bi saniye — Evet.
Üç Parçalı Yapı: Ortam, Girdi, Çıktı
Microsoft’un anlattığı yapı üç parçaya ayrılıyor. Ben de bunu böyle okuyorum, çünkü işin içinde hem ortam var hem veri var hem de çıkan sonuç var; hani hepsini aynı sepete atınca kafa karışıyor.
1) Sürekli Evrilen Ortam (RLE)
RLE, eğitimle inference’ın aynı yerde yaşadığı yönetilen bir çevre. Model burada gerçek workflow’lardan, tool kullanımından. Eval sinyallerinden öğreniyor, ama production sistemlerine dokunmadan ilerliyor; yanı prod veritabanına uzanıp “bir bakalım ne çıkacak” demiyor. Tool’lar virtualize edilmiş, mesele de zaten burada başlıyor (kendi tecrübem)
Kendi deneyimimden konuşuyorum, Bu nokta önemli. Sahada en çok gördüğüm hata şu: Ekip AI agent kuruyor, agent öğrenirken yanlışlıkla production’da kayıt siliyor, e-posta gönderiyor ya da bir Jira ticket kapatıyor; sonra herkes dönüp “bu niye öldü?” diye bakıyor (bu konuda ikircikliyim). İşin aslı, virtualize tool yaklaşımı bu sıkıntıyı mimarı seviyede kesmeye çalışıyor.
Çok konuştum, örnekle göstereyim.
2) Şirketinizin Verisi, Bilgisi, Süreçleri
Sisteme içerik veriyorsunuz, süreç veriyorsunuz, kurum içi terminoloji veriyorsunuz, workflow’ları da ekliyorsunuz. Microsoft burada “veri bilimi diploması gerekmiyor” diyor. Açık konuşayım, bu cümleye biraz temkinli yaklaşıyorum; çünkü her “kolay AI” vaadinin arkasında çoğu zaman “başlangıç kolay, production zor” gerçeği dürüyor. Yine de Copilot Studio entegrasyonu düşünülünce, makers ve power users tarafında baya iş gören bir deneyim çıkabilir.
3) Tunelenmiş Modeller, Skill’ler, Harness
İtiraf edeyim, Çıktı tarafında tuned modelleri görüyorsunuz, embedding’ler geliyor, skill’ler geliyor, orchestration logic geliyor ve bir runtime harness devreye giriyor. Hepsi sizin verinizin üstünde çalışıyor; üstelik kontrol sizde kalıyor ve compliance çizgisinin dışına taşmıyor. En sevdiğim detay da şu: modeller access control’ü miras alıyor. Yanı veriyi göremeyen biri, o veriden türetilmiş modele de erişemiyor.
Bir dakika — bununla bitmedi.
Klasik Fine-Tuning ile Karşılaştırma
Pek çok ekibin kafasında şu soru dönüp dürüyor: Zaten Azure OpenAI’da fine-tuning yapıyoruz, RAG kuruyoruz, sistem de bir şekilde çalışıyor (ben de ilk duyduğumda şaşırmıştım). Peki neden bir de bunu kuralım? Kısa cevap: çünkü mesele sadece modeli eğitmek değil, iş akışının kendisini modele yedirmek (ve evet, bu biraz kafa karıştırıyor).
| Boyut | Klasik Fine-Tuning / RAG | Frontier Tuning |
|---|---|---|
| Öğrenme Sinyali | Statik veri seti | Gerçek workflow + eval geri bildirimi |
| Güncelleme Döngüsü | Manuel re-training | Sürekli, etkileşimden öğrenen |
| Tool Kullanımı | Production tool’lara doğrudan | Virtualize edilmiş, izole |
| Erişim Kontrolü | Ayrı yönetilir | Veriden modele otomatik miras |
| Inference | Tek model | Çoklu model keşfi (frontier + tuned) |
Bu tabloya bakınca “tamam ya, daha gelişmiş bir şey işte” diyebilirsiniz — itiraf edeyim, beklentimin üstündeydi —. Haklısınız gibi dürüyor. Ama dur bir saniye — burada gizli maliyet tarafı var; inference sırasında birden fazla model üzerinden path keşfi yapmak token tüketimini artırabiliyor, üstelik bunu ilk bakışta fark etmiyorsunuz. Henüz net fiyatlandırma yok. Bence enterprise tarafta FinOps ekipleri bu işi yakından izleyecek, çünkü faturanın nereden şiştiğini sonradan aramak pek keyifli olmaz. Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor? yazımda Copilot tarafındaki kredi takibini detaylandırmıştım; açık konuşayım, benzer disiplin Frontier Tuning için de lazım olacak gibi görünüyor.
Copilot Studio ve Foundry Entegrasyonu
Bir şey dikkatimi çekti: Microsoft bu işi iki ayrı kanaldan açıyor, yanı herkesin eline aynı şeyleri vermiyor; bir tarafta maker tarafı var, öbür tarafta developer tarafı,. Açık konuşayım bu ayrım bence boşuna yapılmamış. Copilot Studio tarafında makers, transcript’leri, knowledge base’leri ve Microsoft 365 artifact’larını RLE’ye besleyip mevcut agent’larını biraz daha toparlayabilecek; Microsoft Foundry tarafında işe RL environment kurma, custom reward fonksiyonları tanımlama ve harness’ı kontrol etme gibi daha teknik işler geliyor. Kısacası biri “hazır agent’ımı iyileştireyim” diyor, diğeri “ben bunun içini de kurcalarım” diyor.
Foundry tarafı bana daha ilginç geliyor. Peki neden? Çünkü custom reward tanımlayabilmek, “model işimi gerçekten yapıyor mu” sorusuna laf kalabalığı olmadan cevap verebilmek demek; üstelik bunu ölçebiliyorsun (ve ölçünce bazen insanın hevesi de biraz kırılıyor, önü da söyleyeyim) (bizzat test ettim). Outcome-Driven Learning: OpenEnv ve Foundry ile Kurumsal RL yazımda OpenEnv tarafını anlatmıştım — şimdi gelen Frontier Tuning yaklaşımı da onun yönetilen, compliance-ready hali gibi dürüyor. Bakın, tam da öyle.
Şimdi gelelim işin can alıcı noktasına.
Türkiye’deki Kurumlar İçin Anlamı Ne?
Küçük bir detay: Burada biraz durmak lazım. Çünkü işin teknik tarafı bir yana, Türkiye’de kurumsal AI meselesi biraz başka akıyor; KVKK, veri ikametgâhı, bir de üstüne kurum içi çekinceler eklenince, çoğu bankacılık ve kamu projesinde “compliance boundary” lafı bir anda merkezde kalıyor.
Frontier Tuning’in “veriniz dışarı çıkmıyor” vaadi, kağıt üstünde KVKK uyumu açısından iyi bir sinyal veriyor. Ama açık konuşayım, ben bunu sadece duyuru metninden değil, gerçek deployment’ları görünce ciddiye alırım. Çünkü compliance boundary dediğimiz şey her yerde aynı değil; region seçimi ayrı konu, encryption key ownership ayrı konu, log retention politikaları işe bambaşka bir kapı açıyor, hani bazen insan “bu kadar detay mı varmış?” diye kalıyor.
Tuhaf ama, Pratikte ne yapmalı? Eğer bankacılıkta, sigortada, kamuda ya da sağlıkta çalışıyorsanız, private preview’a başvurmadan önce iç hukuk. Uyum ekibiyle oturup “data residency, log retention, model artefact ownership” üçlüsünü netleştirin. Yoksa POC güzel gider, ekip heyecanlanır (hatta biraz fazla bile), sonra bir compliance raporu gelir. “bunu prod’a alamayız” cümlesi masaya düşer. Evet, can sıkıcı.
Enterprise vs Startup Perspektifi
Küçük bir ekipseniz ya da startup tarafındaysanız, Frontier Tuning ilk gün için şart değil (evet, doğru duydunuz). Hatta çoğu durumda fazla bile gelebilir. RAG ile iyi bir prompt engineering yaklaşımı ve Azure OpenAI fine-tuning birleşimi, pek çok use case için iş görüyor; maliyet tarafı da genelde daha öngörülebilir oluyor. Ama şimdi küçük bir kıvrım yapayım: Frontier Tuning’in anlam kazandığı yer tam da bu basitliğin yetmediği anlar.
- Yüzlerce iç süreciniz vardır, ama bunların çoğu düzgün belgelenmemiştir; kurumsal tribal knowledge resmen ortalıkta dolaşıyordur.
- Agent’larınız production’da çalışıyordur ve sürekli yeni feedback geliyordur ama sız bunu modele düzenli şekilde yansıtamıyorsunuzdur. — bunu es geçmeyin
- Compliance kısıtlarınız ağırdır; veriyi dışarı çıkarmadan model iyileştirmesi yapmanız gerekir, başka yolu yoktur.
- Birden fazla domain’de (HR, finans, müşteri hizmetleri) aynı anda agent stratejisi yürütüyorsanız, işler zaten biraz karışmıştır.
Tuhaf ama, Bu dört maddeden en az ikisi sizde varsa, private preview’a başvurmak bence mantıklı. Az önce “ilk gün şart değil” dedim ama burada küçük bir düzeltme yapayım: eğer süreçleriniz karmaşıksa. Veri sınırları yüzünden eliniz kolunuz bağlanıyorsa, erken bakmak baya iş görebilir. Yoksa acele etmeyin; GA çıktığında fiyatı ve performansı daha net görürsünüz. Sız ne dersiniz?
Tam da öyle.
Mimarı Tarafta Dikkat Çeken Detaylar
İlginç olan şu ki, Duyuruda çok göze çarpmayan, ama benim mühendis kafamı kurcalayan birkaç nokta var. Hani ilk bakışta “tamam güzel” deyip geçiyorsunuz ya, sonra bir cümle takılıyor aklınıza ve olayın asıl yükü orada çıkıyor; işte burada da öyle bir durum var.
Virtualize Tool Katmanı
Agent’ın production’a dokunmadan öğrenmesi için tool’ların virtualize edilmesi gerekiyor. Bu, sandbox bir Microsoft Graph, sandbox bir SharePoint, sandbox bir SQL gibi parçaların RLE içinde simüle edilmesi demek; kulağa basit geliyor ama pratikte iş biraz uzuyor, çünkü Microsoft bunu nasıl kurgulayacak henüz net değil.
Eğer her tool için ayrı ayrı mock layer yazmamız gerekecekse, iş bayağı uzar. Evet. Bir de şöyle düşünün: sadece API döndürmek yetmez, davranışı da gerçek hayata yakın tutmanız lazım, yoksa agent öğreniyor gibi yapar ama sahaya çıkınca tökezler.
Çoklu Model Inference Stratejisi
Inference sırasında birden fazla modelin denenmesi, klasik “tek model çağır, cevap al” düzeninden epey farklı dürüyor. Peki, açık konuşayım, bu yaklaşım latency’yi artırabilir; özellikle real-time müşteri etkileşimlerinde (mesela canlı çağrı merkezî asistanı) bu durum can sıkabilir.
İşin garibi, Asenkron iş yüklerinde işe mesele daha rahat çözülüyor. Orada zaman baskısı daha düşük olduğu için sistem biraz nefes alabiliyor; yanı aynı mimarı her senaryoda aynı sonucu vermiyor, bazen hızlı olmak yerine doğru sırayı bulmak daha kritik oluyor (evet, doğru duydunuz)
Harness Kavramı
Peki, bir şey dikkatimi çekti: “Runtime harness” Microsoft’un kullandığı terimlerden biri. Aslında — hayır dur, daha doğrusu agent’ın çalışma zamanı sözleşmesini taşıyan katman gibi dürüyor; hangi modelin hangi durumda çağrılacağı, hangi tool’a hangi sırayla gidileceği gibi kararlar burada toplanıyor. Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazımda anlattığım katmanlı yapının üst seviyesi gibi düşünebilirsiniz.
İşin garibi, Neyse, çok dağıtmadan söyleyeyim: bu kavram aslında orkestrasyon tarafını sade tutma çabası gibi okunuyor. Hmm, belki de en değerli kısmı bu. Agent dünyasında asıl karmaşa modelde değil, modelin ne zaman konuşacağına karar veren o görünmez ara katta çıkıyor.
Pratik Başlangıç Rehberi
Private preview’a girdiğinizde ya da GA bekliyorsanız bile, şu adımları şimdiden hazırlamanız işinize yarar. Evet, biraz erken gibi dürüyor. Ama tam da burada kazanıyorsunuz; çünkü veri, uyum ve pilot tarafı sonradan toparlanınca iş çoğu zaman uzuyor, ekip de bir anda “nereden başlamıştık biz?” noktasına geliyor.
# 1. Veri envanteri çıkarın
- Hangi knowledge base'ler agent'ı eğitebilir?
- Hangi transcript'ler eval sinyali sağlayabilir?
- Hangi süreçler workflow olarak modellenmiş?
# 2. Compliance haritası yapın
- Data residency: hangi region?
- Access inheritance: hangi RBAC kaynak?
- Log retention: ne kadar tutulacak?
# 3. Reward fonksiyonu taslağı
- Başarı neye benziyor? (resolved ticket, doğru cevap, kısa süre?)
- Negative reward sinyalleri neler? (yanlış yönlendirme, escalation?)
# 4. Pilot agent seçimi
- En çok feedback alan agent hangisi?
- En az risk taşıyan ama en çok değer üreten use case?Bu liste ilk bakışta baya sıradan görünebilir, hatta “bunu zaten herkes biliyor” diye geçebilirsiniz; ama işin aslı öyle değil, çünkü ben defalarca gördüm, “AI yapacağız” deyip aylar harcayan ekiplerin %80’i bu dört maddeyi düzgün oturtamadığı için duvara tosluyor (buna dikkat edin). Agents League Hackathon 2026: Enterprise Agents Kategorisi Rehberi yazımda da benzer bir hazırlık disiplinini özellikle önermiştim (evet, doğru duydunuz)
Benim Açımdan Genel Değerlendirme
Kısacası, bir şey dikkatimi çekti: Frontier Tuning, kâğıt üstünde baya iyi dürüyor. Compliance içinde RL, sürekli öğrenen sistem, access inheritance, virtualize tool katmanı… Hepsi enterprise AI tarafında can sıkan yerlere dokunuyor. Açık konuşayım, son birkaç Build’de duyduğum şeyler arasında en elle tutulur olanı buydu benim için.
Ama işin bir de öbür yüzü var: fiyatlandırma ve gerçek production performansı. Private preview’dan çıkıp GA’ya geçene kadar, “vaat edilen sürekli öğrenme” gerçekten gözle görülür kalite artışı sağlıyor mu, yoksa model sadece bir kere tunelenip sonra kendi halinde mi gidiyor — bunu ancak sahada anlayacağız — bence çok yerinde bir karar —. Bence biraz daha pişmesi lazım. Yine de yön fena değil.
Araya gireyim: Şimdilik benim tavsiyem şu: Eğer kurumunuzda zaten Copilot Studio veya Foundry kullanıyorsanız, IT liderinizle ya da AI strateji ekibinizle kısa bir oturum yapın, “biz buna ne zaman ve nasıl gireriz” sorusunu masaya koyun. Geç kalan değil, hazırlıklı giren kazanacak.
Sıkça Sorulan Sorular
Frontier Tuning klasik fine-tuning’in yerini alacak mı?
Vallahi, Kısa vadede hayır. Klasik fine-tuning hani daha sade, daha tahmin edilebilir ve açıkçası daha ucuz. Frontier Tuning aslında sürekli öğrenme ve compliance-aware RL gerektiren durumlar için düşünülmüş. Bence çoğu kurum bir süre ikisini yan yana kullanmaya devam edecek.
Verim Microsoft’un eğitim setine karışır mı?
Duyuruya göre hayır — model artefaktları sizin compliance boundary’nizin içinde kalıyor ve access control’leri miras alıyor. Ama şunu da söyleyeyim: “boundary” tanımı her kurumda farklı yorumlanabiliyor. Yanı sözleşme detaylarını kendi hukuk ekibinizle netleştirmenizi öneririm.
KVKK uyumu açısından kullanabilir mıyım?
Teorik olarak evet. Veri dışarı çıkmıyor, bu iyi bir başlangıç. Ama pratikte Azure region seçimi, anahtar yönetimi ve log retention politikalarına dikkatle bakmanız lazım — bunlar atlanan detaylar oluyor çoğu zaman. Bankacılık ve kamu tarafındaysanız ayrıca ek iç onay süreçleri de gündeme gelebilir.
Ne zaman GA olacak?
Microsoft net bir tarih vermedi. Bir bakıma, şu an private preview aşamasında, Forward Deployed Engineer üzerinden erişilebiliyor. Copilot Studio ve Foundry entegrasyonu “upcoming” olarak duyuruldu. Tecrübeme göre bu tür duyurularda tahminim 2026’nın ikinci yarısında public preview görürüz, ama garantisi yok tabiî.
Maliyeti yüksek mi olacak?
Henüz fiyatlandırma açıklanmadı. Ama inference sırasında çoklu model keşfi yapıldığı için token tüketimi klasik tek-model inference’a kıyasla daha yüksek olacak gibi görünüyor. Yanı FinOps tarafında dikkatli bütçeleme şart — bunu hafife almayın.
Kaynaklar ve İleri Okuma
Microsoft 365 Developer Blog: Frontier Tuning Resmî Duyurusu
Microsoft Copilot Studio Resmî Dokümantasyonu
Microsoft Foundry Resmî Dokümantasyonu
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.
3 comments