Foundry Fine-Tuning Nisan Güncellemesi: RFT Artık Ucuz

Geçen ay Microsoft Foundry Mart 2026: Sahadan İlk İzlenimler yazımda Foundry’nın genel gidişatından bahsetmiştim. Şimdi Nisan ayına geldik, Microsoft da Reinforcement Fine-Tuning (RFT) tarafında üç güncelleme birden çıkardı. Açık konuşayım, bunların içinde en çok Global Training kısmı dikkatimi çekti. O4-mini zaten reasoning tarafında müşterilerimde en sık elime gelen modellerden biri, bir de fiyat konusu uzun zamandır can sıkıyordu. Neyse, teker teker bakalım.

o4-mini Artık Global Training Destekliyor

Bakın şimdi, fine-tuning tarafında en can sıkan şey ne biliyor musunuz? Bölge mevzusu. Müşteri Türkiye’de oluyor, veri Europe tarafında dürüyor, ama fine-tuning sadece birkaç US bölgesinde açılıyor; insan da ortada kalıyor, neyse ki Microsoft bu sıkıntıyı Global Training ile biraz olsun toparlamaya çalışıyor ve Nisan itibarıyla o4-mini de listeye girmiş durumda.

Şu anda 13 Azure bölgesinden o4-mini fine-tuning başlatabiliyorsunuz: East US 2, North Central US, West US 3, Australia East, France Central, Germany West Central, Switzerland North, Norway East, Poland Central, Spain Central, Italy North, Switzerland West. Sweden Central. Nisan sonuna kadar neredeyse tüm fine-tuning bölgelerine yayılması planlanıyor; yanı bugün tam oturmamış olsa da yön belli.

İşin garibi, Ha, burada işin asıl ilginç tarafı başka. Global Training sadece bölge erişimi demek değil; aynı zamanda daha düşük per-token eğitim maliyeti de getiriyor. Standard training ile kıyaslayınca fark baya hissediliyor. Geçen hafta Logosoft’ta bir e-ticaret müşterimiz için o4-mini ile sınıflandırma modeli eğitirken (önce Standard pricing ile başladık, sonra Global’e geçince) token başına maliyette gözle görülür bir düşüş yakaladık. Tam rakam veremem ama “fena değil” seviyesini rahatlıkla geçiyor.

Çok konuştum, örnekle göstereyim.

Türkiye’deki Ekipler İçin Ne Anlama Geliyor?

Türkiye’de Azure kullanan şirketlerin çoğu West Europe ya da North Europe’u seçiyor zaten. Ama fine-tuning söz konusu olunca bu bölgelerde işler her zaman pürüzsüz gitmiyordu. Şimdi France Central, Germany West Central ve Switzerland North gibi yakın seçenekler listede; bu da hem erişim tarafını rahatlatıyor hem de latency açısından iş görüyor çünkü eğitim başladıktan sonra monitöring yaparken bağlantı kalitesi ufak bir detay olmaktan çıkabiliyor (bizzat test ettim)

Bir de şunu söyleyeyim: küçük startup’sanız ve bütçe sıkışıksa, Global Training ile o4-mini fine-tuning yapmak artık çok daha mantıklı dürüyor. Eskiden “bu iş pahalıymış” deyip API’yi olduğu gibi kullanan ekiplere şimdi “bir deneyin bence” diyebiliyorum. Enterprise tarafta ölçek avantajı zaten var; ama startup’larda fiyat farkı bazen bütün kararı değiştiriyor.

REST API ile Global Training Job Oluşturmak

Teknik tarafa girelim. İşin özü basit gibi dürüyor, ama birkaç küçük detay var; atlayınca da insan sonradan faturaya bakıp “hmm, burada bir gariplik var” diyor, ben ilk denemede aynen bunu yaşadım. En çok da trainingType parametresini globalstandard olarak vermeyi unutmayın, yoksa iş standart pricing’e kayıyor ve sız bunu ancak biraz geç fark ediyorsunuz.

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
-H "Content-Type: application/json" \
-H "api-key: $AZURE_OPENAI_API_KEY" \
-d '{
"model": "o4-mini",
"training_file": "<your-training-file-id>",
"method": {
"type": "reinforcement",
"reinforcement": {
"grader": {
"type": "string_check",
"name": "answer-check",
"input": "{{sample.output_text}}",
"reference": "{{item.reference_answer}}",
"operation": "eq"
}
}
},
"hyperparameters": {
"n_epochs": 2,
"compute_multiplier": 1.0
},
"trainingType": "globalstandard"
}'

Burada kullanılan grader baya düz bir string_check. Yanı modelin ürettiği çıktı ile referans cevap birebir aynı mı, ona bakıyor; hızlı çalışıyor, maliyeti de düşük kalıyor, tekrar ettiğinizde sonuçlar da pek oynamıyor. Ama her senaryoda iş görmüyor, açık konuşayım. Mesela özetleme yapıyorsanız ya da ton kontrolü istiyorsanız, bu kadar katı bir eşleşme çoğu zaman yetersiz kalıyor; işte o noktada yeni model grader’lar devreye giriyor.

Hmm, bunu nasıl anlatsamdı…

Yeni Model Grader’lar: GPT-4.1 Ailesi Sahneye Çıkıyor

Küçük bir detay: RFT’nın kalbi grader’lar, işin aslı bu. Modelinize “bak, şu çıktı iyi, şu kötü” demenin yolu da bunlar oluyor. Deterministik grader’lar (string match, Python script, endpoint tabanlı) hâlâ varsayılan tercihiniz olmalı — açık konuşayım, ben de çoğu senaryoda önce onları denerim. Ama bazen yetmiyor. Peki neden? Çünkü bazı çıktılar var ki, kural yaz yaz bitmiyor.

Bu ay üç yeni model grader eklendi; küçük gibi dürüyor ama pratikte baya iş görüyor:

• GPT-4.1 — En detaylı değerlendirme için. Karmaşık rubric’leri yorumlayabiliyor.
• GPT-4.1-mini — Maliyet-performans dengesi fena değil, çoğu use case için yeterli.
• GPT-4.1-nano — En ucuz seçenek. Büyük veri setlerinde batch grading için baya uygun.

Hangisini Ne Zaman Kullanmalı?

Dur bir saniye — model grader kullanmak deterministik grader’a göre hem daha pahalı hem de daha az tekrarlanabilir, bunu baştan kabul etmek lazım. Aynı girdiyi iki kez değerlendirdiğinizde farklı skorlar alabilirsiniz; yanı iş biraz kaygan zemine dönüyor. O yüzden “her yerde model grader kullanalım” demeyin, sonra maliyet raporu yüzünden sürat asmayın.

İtiraf edeyim, Ama bazı durumlarda başka çare yok gibi geliyor:

Şöyle söyleyeyim, Lafı gevelemeden söyleyeyim; 2025 sonlarında bir bankacılık müşterimizde kredi başvuru özetleme modeli fine-tune ediyorduk ve ilk denemede string match ile grading yaptık — tam bir duvara toslama anıydı bu. Çünkü aynı anlama gelen. Peki bunu neden söylüyorum? Farklı ifade edilen özetleri “yanlış” diye işaretliyordu; insan okusa geçecek şeyler sistemde kalıyordu, garipti gerçekten.

Sonra GPT-4.1-mini’ye geçtik ve grading kalitesi belirgin biçimde toparlandı. Ama maliyet de arttı tabi, önü da saklamayayım; bedava değil sonuçta. Sonra ne yaptık? İlk 500 örneği GPT-4.1-mini ile grade ettik, ardından oradan çıkan sinyallerle deterministik bir rubric oluşturduk. Hibrit yaklaşım diyebiliriz, hatta bence çoğu ekip için en mantıklısı bu oluyor.

Deterministik grader’lar her zaman varsayılan tercihiniz olsun. Model grader’lara ancak görevin doğası gereği — subjektif değerlendirme, açık uçlu çıktılar, çok boyutlu rubric’ler — ihtiyaç duyduğunuzda geçin.

RFT Best Practices: Grader Tasarımından Veri Hazırlığına

Bakın, Microsoft bu ay bir de “best practices” rehberi yayınladı. Rehberin tamamını okudum, hatta üstünden bir kez daha geçtim; açık konuşayım, çoğu şey zaten sahada yaşayarak öğrendiğimiz şeyler, ama birkaç noktayı özellikle kenara not ettim çünkü aynı hataları hâlâ görüyorum, hem de sık sık.

Evet, doğru duydunuz.

Grader Tasarımında Sık Yapılan Hatalar

En yaygın hata şu: grader’ı fazla genel bırakmak. “İyi bir cevap mı?” diye sorup model grader çalıştırırsanız, skorlar sağa sola savruluyor; bazen iyi dediğine kötü diyor, bazen tam tersi. Bunun yerine rubric’i net yazın, mesela “Cevap en az 3 madde içeriyor mu?”, “Teknik terimler doğru mu?”, “Ton profesyonel mi?” gibi somut kriterler koyun ve her biri için ayrı skor üretin, sonra da bunları birleştirin. Basit görünüyor, ama işin can alıcı kısmı orası.

Bence, Bir de şu örnek var, önü çok gördüm: eğitim verisinde 50 örnek hazırlamışlar ama hepsi aynı zorlukta. Olmaz yanı. RFT’nın düzgün ilerlemesi için modelin biraz zorlanacağı örnekler lazım; çok kolaysa öğrenecek yeni bir şey çıkmıyor, çok zorsa da model orada duvara tosluyor. Dengeyi kurmak uğraştırıyor, evet, ama sonuçta farkı da orası yaratıyor. Bu konuyla ilgili VS Debugger Agent: Bug Avı Artık Ajan İşi yazımıza da göz atmanızı tavsiye ederim.

İşte tam da bu noktada devreye giriyor.

Veri hazırlığı tarafında da iki üç küçük not düşeyim. Microsoft’un önerisi en az 50 örnekle başlamak yönünde; ben de buna itiraz etmiyorum. Ama pratikte ben şöyle gidiyorum: 50 ile başla, sonucu gör, sonra 100-200 bandına çık; direkt 500 örnekle dalma çünkü grader’da temel bir sorun varsa hepsini çöpe atmış olursun (acı. Gerçek). İteratif gitmek burada baya iş görüyor.

Küçük Ekip vs Enterprise: Farklı Stratejiler

Araya gireyim: Küçük bir ekipseniz — diyelim 3-5 kişilik bir ML takımı — string_check. Python grader’larla başlamak bence daha mantıklı. Model grader’ları işe sadece gerçekten ihtiyaç olduğunda devreye alın; çünkü bütçe sınırlıysa her token’ın hesabını yapmak gerekiyor, lafı gevelemeden söyleyeyim. Global Training ile o4-mini fine-tuning yapın, nano grader ile batch değerlendirme yapın; bu ikili maliyet tarafında fena değil.

Enterprise tarafında işe tablo biraz değişiyor. Birden fazla grader’ı pipeline’a koyabilirsiniz — önce deterministik bir ön filtre, sonra model grader ile daha detaylı değerlendirme gelir; burada iş biraz katmanlı ilerliyor (en azından benim deneyimim böyle). GPT-4.1’i rubric-heavy işlerde kullanın, GPT-4.1-mini’yi genel değerlendirmelere çekin; maliyeti dengelemek için nano’yu da karışıma ekleyin. Tabi bunların hepsini yönetmek için düzgün bir MLOps pipeline’ınız olması lazım, yoksa işler çabuk karışıyor ve sonra kim neyi neden yaptı diye bakıp kalıyorsunuz. Bu konuyla ilgili Claude Opus 4.7 Copilot’a Geldi: İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim. .NET 11 Preview 3: Gelen Yenilikler ve Sahadan Notlar yazımızda bu konuya da değinmiştik.

Peki neden?

Maliyet Perspektifi: TL Bazında Düşününce

Yanı, Bu konuyu atlayamam, çünkü Türkiye’de ekipler en çok bunu soruyor. Bakın, Global Training ile Standard Training arasındaki fiyat farkı özellikle hacim büyüyünce hemen hissediliyor; ama işin asıl can sıkan tarafı gizli maliyetler, çünkü model grader kullanıyorsanız her grading çağrısı ayrı token yiyor — valla güzel iş çıkarmışlar —. 1000 eğitim örneğinde bu kalem bir anda gözünüzün önüne çıkıyor.

Bakın, Hmm, bir dakika… Şöyle somut anlatayım. Diyelim elinizde 200 örneklik bir eğitim seti var, her örneğin çıktısı ortalama 500 token, grader prompt’u da 300 token. GPT-4.1-nano ile grade ettiğinizde maliyet X seviyesinde kalırken, GPT-4.1’e geçtiğinizde bu rakam 5-6X bandına çıkabiliyor; TL’ye çevirince de kur oynaklığı yüzünden iş baya büyüyor, yanı burada mesele sadece teknik değil, bildiğiniz bütçe yönetimi.

Az önce “nano her zaman en ucuz” dedim ama açık konuşayım, öyle düz bir denklem yok. Nano’nun grading kalitesi düşük kalırsa model yanlış yöne kayabiliyor, sonra sız bir epoch daha çalıştırıyorsunuz, bazen iki kere uğraşıyorsunuz,. Toplam maliyet sessiz sedasız şişiyor; buna karşılık biraz daha pahalı ama oturaklı bir grading yaklaşımı çoğu senaryoda cebinizi daha az yorabiliyor. GitHub Rule Insights Dashboard: Kural Yönetimi Kolaylaştı yazımızda bu konuya da değinmiştik.

Evet.

İşin püf noktası burada. Sız ne dersiniz? Bu konuyla ilgili azd update Komutu: Paket Yöneticisi Derdine Son yazımıza da göz atmanızı tavsiye ederim.

Dikkat Etmeniz Gereken Eksikler

Güzel tarafları var, evet. Ama işin bir de pürüzlü yanı dürüyor; hani her şey parlak görünür ya, burada o kadar da cilalı değil.

Birincisi, Global Training bölge listesine bakınca Türkiye’ye yakın seçenekler görüyorsunuz ama hâlâ UAE North ya da Qatar Central gibi Orta Doğu bölgeleri yok. Bazı müşteriler için bu küçük bir detay değil, çünkü veri residency işi bazen bütün mimariyi baştan aşağı değiştiriyor (ve açık konuşayım, bu tarafta “idare eder” demek pek yetmiyor).

Kendi deneyimimden konuşuyorum, İkincisi, model grader’ların tutarsız davranması. Microsoft bunu zaten kabul ediyor. “deterministik grader’ları tercih edin” diyor, tamam; ama pratikte birçok görevde deterministik grader yazmak öyle kolay bir iş değil. Kalibrasyon tarafı, confidence scoring tarafı, bunlar da henüz tam oturmuş değil. Kağıt üstünde fena durmuyor, sahada işe biraz daha pişmesi gerekiyor.

Üçüncüsü — ve burada ben de biraz duraksadım — RFT hâlâ sadece belli modellerde çalışıyor. Supervised fine-tuning ile yan yana koyunca model desteği daha dar kalıyor. Yanı iş görüyor, ama genişlik arıyorsanız eliniz biraz sıkışıyor; umarım önümüzdeki aylarda liste uzar.

Ha bu arada, Azure MCP Server 2.0: Kendi Sunucunuzda Ajan Otomasyonu yazımda anlattığım ajan mimarileriyle birlikte düşününce, fine-tuned o4-mini modellerini ajan workflow’larının içine sokmak baya iyi bir kombinasyon olabilir. Reasoning tarafı güçlü, maliyet tarafı düşük; ajansal senaryolar için tam ortada duran bir seçenek gibi geliyor bana.

Pratikte İlk Adımlar

Şöyle ki, Tamam, teori kısmını geçelim (inanın bana). Denemek istiyorsanız, işin aslı ne yapacaksınız?

1. Azure OpenAI kaynağınızın Global Training destekleyen bir bölgede olduğuna bakın. Değilse, yeni bir kaynak açmanız gerekecek.
2. En az 50 örnekten oluşan bir eğitim seti hazırlayın. Her örnekte bir prompt ve ona karşılık gelen referans cevap olsun. — ciddi fark yaratıyor
3. İşe basit bir string_check grader ile başlayın. İlk sonuçlara bir bakın, sonra karar verin.
4. Eğer deterministik grader yetmezse, GPT-4.1-nano ile model grading tarafını deneyin. Bazen orada daha iyi sinyal alıyorsunuz.
5. Sonuçları yan yana koyun, gerekirse grader’ı ve veriyi adım adım iyileştirin. Hani sihirli değnek yok, biraz iterasyon gerekiyor.

Bir de ChatGPT ile Araştırma: Search ve Deep Research Rehberi yazıma göz atmanızı öneririm — grader prompt’larını tasarlarken araştırma yeteneklerini nasıl kullanacağınız konusunda epey fikir verebilir, hatta beklemediğiniz birkaç noktayı da fark ettirebilir.

Bir şey dikkatimi çekti: Neyse, uzatmayalım. Bu Nisan güncellemesi tek başına devrim gibi durmuyor; ama doğru tarafa atılmış sağlam bir adım bence. Neyse, en çok da Global Training’in maliyeti aşağı çekmesi ve yeni grader seçenekleri, RFT’yi daha erişilebilir hâle getiriyor. Ben önümüzdeki haftalarda birkaç müşteri projesinde bunları daha detaylı test edeceğim; sonuçlar şaşırtırsa ayrıca paylaşırım.

Sıkça Sorulan Sorular

Global Training ile Standard Training arasındaki fark ne?

Global Training, fine-tuning işini birden fazla Azure bölgesinden başlatmanıza izin veriyor ve aslında per-token eğitim maliyeti Standard’a göre daha düşük. Model kalitesi ve altyapı aynı, yanı sadece erişim noktası ve fiyatlandırma değişiyor. Bölge kısıtlaması yaşayan ekipler için bence gerçekten büyük bir kolaylık bu.

Model grader mı kullanayım, deterministik grader mı?

Açıkçası varsayılan olarak her zaman deterministik grader’ı (string match, Python script) tercih edin — daha hızlı, daha ucuz. Tekrarlanabilir. Model grader’lara sadece açık uçlu, subjektif ya da çok boyutlu değerlendirme gerektiren görevlerde başvurun. Peki bunu neden söylüyorum? İkisini hibrit kullanmak da aslında çok etkili bir strateji, tecrübeme göre işe yarıyor.

RFT için en az kaç eğitim örneği lazım?

Kısacası, microsoft’un önerisi en az 50 örnek. Ama benim tavsiyem şu: 50 ile başlayın, sonuçlara bakın, sonra iteratif olarak 100-200’e çıkarın. Örneklerin zorluk dağılımına dikkat edin — hepsi çok kolay ya da çok zor olmasın, yanı biraz karışık olsun.

GPT-4.1-nano grader olarak işe yarar mı?

Basit kalite kontrolü ve ön filtreleme için gayet yeterli, mesela ilk geçişlerde iyi iş çıkarıyor. Ama karmaşık rubric’leri doğru yorumlama kapasitesi GPT-4.1’e göre düşük kalıyor. E peki, sonuç ne öldü? Büyük veri setlerinde maliyet avantajı ciddi — o yüzden ilk geçiş için nano kullanıp detaylı değerlendirmeyi mini veya full modelle yapmak bence mantıklı bir strateji.

Türkiye’ye en yakın Global Training bölgesi hangisi?

Şu an France Central, Germany West Central ve Switzerland North en yakın seçenekler. Latency açısından aslında büyük fark yok çünkü eğitim işi asenkron çalışıyor — ama monitöring (en azından benim deneyimim böyle). Dosya yükleme sırasında yakın bölge yine de avantaj sağlıyor.

Kaynaklar ve İleri Okuma

What’s New in Microsoft Foundry Fine-Tuning | April 2026 — Resmî Blog Yazısı

Azure OpenAI Fine-Tuning Resmî Dokümantasyonu

Reinforcement Fine-Tuning (RFT) Kavramları — Microsoft Learn

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure SQL’de Vektörler ve Analitik: ETL Neden Geride Kalıyor?6 Nis 2026

Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor?14 Nis 2026

Microsoft SQL ile Agentic AI Güvenliği: Katman Katman Savunma14 May 2026

azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem31 Mar 2026