SFT, DPO ve RFT: 2026'da Hangi İnce Ayar Yöntemini Seçmeli?

TL;DR — Son bir yıldır kurumsal danışmanlık masalarımda en çok karşılaştığım soru şu: "Modelimizi fine-tune mi etmeliyiz, yoksa prompt mühendisliği mi yeter?" Cevap her zaman "duruma göre" ama bu yazıda o duruma göreyi somutlaştırıyorum. Kısaca: Önce prompting ve RAG'ı zorlayın; çoğu zaman ihtiyaç orada biter. Gerçekten fine-tuning gerekiyorsa SFT (Supervised Fine-Tuning) neredeyse her zaman ilk durak olmalı — referans çıktılardan öğrenir, kurulumu görece basittir ve işin %60-75'ini tek başına halleder. Tercihe dayalı hizalama, yani modelin "bu cevap şundan daha iyi" ayrımını netleştirmesi gerekiyorsa DPO (Direct Preference Optimization) devreye girer; ayrı bir ödül modeline gerek duymadan RLHF'e hafif bir alternatif sunar — ama statik, çevrimdışı tercih çiftleriyle çalıştığı için dinamik araç-yürütme sonuçlarından öğrenmesi gereken çok adımlı ajanik görevlerde yanlış araçtır. Doğru çıktıyı elle etiketlemek zor ama üretilen bir çıktının doğruluğunu otomatik doğrulamak mümkünse (matematik, kod üretimi, araç kullanım planlaması gibi) RFT (Reinforcement Fine-Tuning) sahneye çıkar; model aday çıktılar üretir, bir doğrulayıcıdan ödül alır ve politikasını buna göre günceller — düzinelerce örnekle bile anlamlı kazanımlar sağlayabilir. Pratikte en güçlü sonuçları SFT üzerine RFT ekleyerek, demonstrasyonların kapatamadığı başarısızlık modlarına giren senaryolarda görüyorum. Türkiye'de bu tabloya bir katman daha eklemek gerekiyor: müşteri verisiyle eğitim yapacaksanız KVKK çerçevesi işin başında, sondan değil, masaya oturmalı.

Birkaç yıl önce "fine-tuning" dediğinizde karşınızdaki ekip genelde tek bir şeyi anlıyordu: elimizdeki örnek girdi-çıktı çiftlerini modele gösterip onu o davranışa alıştırmak. Bugün öyle değil. Artık üç farklı ince ayar felsefesi var, her biri farklı bir veri türü istiyor, farklı bir altyapı gerektiriyor ve farklı bir problem sınıfını çözüyor. Ben danışmanlık yaptığım kurumlarda — bankacılıktan e-ticarete, üretimden kamu kurumlarına kadar — bu üç yöntemin birbirine karıştırıldığını sık sık görüyorum. Bir ekip "DPO yapalım" diyor ama aslında ellerinde sadece iyi örnekler var, tercih çiftleri yok. Başka bir ekip "RFT deneyelim" diyor ama görevlerinin doğruluğunu otomatik olarak doğrulayacak bir mekanizmaları yok. Bu karışıklığın bedeli az değil: yanlış yöntemi seçmek hem zaman hem bütçe hem de -daha kötüsü- ekibin fine-tuning'e olan güvenini kaybetmesi anlamına geliyor.

2026'da bu soru daha sık gündeme geliyor çünkü artık üç yöntem de üretim ortamlarında olgunlaştı, çoğu büyük model sağlayıcısı bunları API üzerinden sunuyor ve ajanik sistemlerin (agent'ların) yaygınlaşmasıyla "modelim görevi %50 tamamlıyor, %50'sinde tıkanıyor" şikayeti çok daha görünür hale geldi. Bu yazıda üç yöntemi teknik detaylarıyla değil, karar verme açısından ele alacağım: hangi yöntem hangi problem için doğru, hangi veriye ihtiyacınız var, ne kadar maliyetli, ve en önemlisi — hangi sırayla ilerlemelisiniz.

Bu bölümü en başa koymamın bir nedeni var: sahada gördüğüm projelerin önemli bir kısmında fine-tuning aslında gereksizdi. Ekipler "modelimiz bizim jargonumuzu bilmiyor" ya da "cevaplar bizim tonumuzu tutturmuyor" dediklerinde ilk refleksleri fine-tuning oluyor. Oysa çoğu zaman çözüm çok daha ucuz ve çok daha hızlı iki yerde saklı:

• Prompt mühendisliği: Sistem talimatlarını netleştirmek, few-shot örnekler eklemek, çıktı formatını şablonlamak — bunlar genellikle ilk denenmesi gereken, sıfır eğitim maliyeti olan araçlardır. Bir müşteri kurumda "modelimiz asla bizim gibi yazmıyor" şikayetini üç iyi örnekli bir sistem promptuyla çözdüğümüz oldu; fine-tuning'e hiç gerek kalmadı.
• RAG (Retrieval-Augmented Generation): Model "bilgiyi bilmiyor" ise sorun genelde parametrelerin içinde değil, erişimin içindedir. Güncel ürün kataloğu, iç prosedürler, mevzuat metinleri gibi sık değişen bilgiler fine-tuning ile modele "ezberletilmez" — çünkü her güncellemede yeniden eğitmeniz gerekir. Bunun yerine bir vektör veritabanı ve iyi bir retrieval katmanı kurup modelin doğru anda doğru belgeye erişmesini sağlamak hem daha ucuz hem daha sürdürülebilir.

Fine-tuning'i şu üç durumda ciddiye almanızı öneririm: (1) model belirli bir davranış kalıbını -ton, format, karar mantığı- tutarlı biçimde tekrarlayamıyor ve bunu prompt ile üç-dört denemede düzeltemiyorsanız; (2) görev, promptun içine sığmayacak kadar çok sayıda edge-case veya kural içeriyorsa; (3) latency veya maliyet nedeniyle daha küçük, uzmanlaşmış bir modele geçmeniz gerekiyorsa (büyük bir modeli uzun promptlarla çağırmak yerine küçük bir modeli fine-tune edip aynı görevi çok daha ucuza yaptırmak). Bu üç koşuldan en az biri yoksa, fine-tuning yatırımına başlamadan önce bir kez daha düşünün.

"

Sahadan bir gözlem: "Fine-tuning yapalım" talebiyle gelen on projeden yaklaşık altısında, gerçek ihtiyaç aslında daha iyi bir prompt mimarisi veya daha güçlü bir RAG pipeline'ıydı. Fine-tuning, doğru yerde kullanıldığında güçlü bir araç; ama her sorunun çözümü değil.

Fine-tuning'e karar verdiyseniz, sıra hangi yöntemi seçeceğinize geliyor. Üçünü de aynı çerçeveden bakarak açıklayayım: model neyden öğreniyor?

SFT — Demonstrasyondan öğrenme

Supervised Fine-Tuning, en klasik ve en anlaşılır yöntem. Elinizde girdi-çıktı çiftleri var: "bu soruya bu cevap doğrudur", "bu talebe bu şekilde yanıt verilmeli". Modele bu örnekleri gösteriyorsunuz, model bu örnekleri taklit etmeyi öğreniyor. Teknik olarak, modelin bu "altın standart" çıktıları üretme olasılığını artıracak şekilde ağırlıklarını güncelliyorsunuz.

SFT'nin en pratik özelliği şu: başarılı trajektoriler üzerinde eğitim yaparsınız. Yani elinizde bir müşteri hizmetleri botu, bir kod asistanı veya bir doküman özetleyici varsa ve bu sistemin geçmişte "iyi" sonuç verdiği örnekleri toplayabiliyorsanız, bunları doğrudan SFT verisi olarak kullanabilirsiniz. Karmaşık bir ödül fonksiyonu tasarlamanıza, bir tercih çifti oluşturmanıza veya bir doğrulayıcı yazmanıza gerek yok — sadece "bu iyi bir örnek" diyebiliyor olmanız yeterli.

Deneyimlerime göre SFT, iyi kürate edilmiş birkaç yüz ile birkaç bin örnekle bile işin %60-75'ini halleder. Bu oran rastgele bir sayı değil; sahada tekrar tekrar gördüğüm bir eşik. Modelin format tutarlılığını, ton uyumunu, temel görev başarımını SFT ile büyük ölçüde çözersiniz. Kalan %25-40'lık kısım ise genelde "modelin bildiği ama tutarlı uygulamadığı" ince ayrımlar, ya da "doğru cevap birden fazla olabilir, hangisi daha iyi" gibi tercih meselelerinde saklıdır — ki bu da bizi DPO ve RFT'ye götürür.

SFT'yi ne zaman seçmelisiniz? Neredeyse her zaman ilk durak olarak. İster DPO ister RFT uygulayacak olun, altında sağlam bir SFT temeli olmadan bu yöntemler çok daha kırılgan çalışır. SFT'siz doğrudan DPO ya da RFT'ye atlamak, temeli atmadan duvar örmeye benziyor.

DPO — Tercihten öğrenme

Direct Preference Optimization, RLHF'in (İnsan Geri Bildirimiyle Pekiştirmeli Öğrenme) daha hafif bir alternatifi olarak ortaya çıktı. Klasik RLHF akışında önce ayrı bir "ödül modeli" eğitirsiniz, sonra bu ödül modelini kullanarak asıl modeli pekiştirmeli öğrenme ile güncellersiniz — iki aşamalı, hesaplama açısından pahalı, kararlılığı yönetmesi zor bir süreç. DPO bu ayrı ödül modelini tamamen ortadan kaldırıyor: elinizdeki tercih çiftlerini ("A cevabı B cevabından daha iyi") doğrudan bir kayıp fonksiyonuna dönüştürüp modeli doğrudan optimize ediyorsunuz.

Buradaki kilit kelime doğrudan. DPO, modelin tercih edilen çıktıyı reddedilen çıktıya göre daha olası hale getirecek şekilde ağırlıklarını günceller — ara katmanlarda ayrı bir ödül modeli veya pekiştirmeli öğrenme döngüsü olmadan. Bu, onu RLHF'e göre önemli ölçüde daha basit, daha ucuz ve daha stabil bir eğitim süreci yapıyor.

DPO ne zaman doğru araç? Elinizde "bu iki cevaptan hangisi daha iyi" şeklinde etiketlenmiş çift örnekleriniz varsa ve amacınız modelin hizalanmasını -yani insan tercihleriyle örtüşmesini- iyileştirmekse. Tipik senaryolar: yanıt tonunu daha nazik/daha kısa/daha güvenli hale getirmek, iki olası cevap arasında hangisinin marka sesine daha uygun olduğunu öğretmek, ya da zararlı/uygunsuz çıktıları bastırmak.

Ama burada kritik bir sınır var, ve bunu ekiplerin gözden kaçırdığını sık görüyorum: DPO, statik ve çevrimdışı bir tercih veri setiyle çalışır. Tercih çiftlerini önceden toplarsınız, eğitimi bir kere yaparsınız, model bu sabit çiftlerden öğrenir. Bu, tek adımlı ya da kısa etkileşimli görevler için gayet iyi çalışır. Ancak çok adımlı, ajanik görevlerde — modelin bir araç çağırdığı, sonucu gördüğü, bir sonraki adıma karar verdiği, belki geri adım attığı senaryolarda — DPO'nun statik yapısı yetersiz kalır. Çünkü bu tür görevlerde "doğru" olan şey, önceden belirlenmiş bir tercih çiftinden değil, dinamik araç-yürütme sonuçlarından öğrenilmesi gereken bir şeydir. Model, bir aracı çağırdığında ne olacağını, o sonucun görevi ileri mi geri mi götürdüğünü öğrenmelidir — bu, önceden hazırlanmış bir "A mı B mi daha iyi" çiftiyle yakalanabilecek bir dinamik değildir. Bu noktada DPO yanlış araçtır ve RFT devreye girer.

RFT — Ödülden öğrenme

Reinforcement Fine-Tuning, üç yöntem arasında en "aktif" olanı. SFT ve DPO'da model pasif bir öğrenci gibidir — ona gösterilen örnekleri (ya da tercihleri) öğrenir. RFT'de ise model kendi çıktılarını üretir, bu aday çıktılar bir dış değerlendirici veya doğrulayıcı tarafından puanlanır (ödül sinyali), ve model bu ödül sinyaline göre politikasını -yani karar verme stratejisini- günceller. Bu döngü tekrar tekrar işler: üret, değerlendir, güncelle.

RFT'nin gücü şurada yatıyor: bazı görevlerde "doğru cevabı" elle etiketlemek çok zor ya da çok pahalıdır, ama üretilen bir çıktının doğru olup olmadığını otomatik olarak doğrulamak mümkündür. Düşünün: bir matematik problemi için "model buraya nasıl bir çözüm yazmalı" diye bin örnek yazmak inanılmaz zahmetli olur, ama modelin ürettiği çözümün doğru sonuca ulaşıp ulaşmadığını kontrol etmek bir betikle saniyeler içinde yapılabilir. Aynı mantık şu alanlarda da geçerli:

• Matematiksel akıl yürütme: Sonucun doğruluğu programatik olarak kontrol edilebilir.
• Kod üretimi: Üretilen kod test paketinden geçiyor mu, derleniyor mu, beklenen çıktıyı veriyor mu — bunlar otomatik doğrulanabilir.
• Araç kullanım planlaması (tool-use planning): Bir ajanın doğru araç sırasını seçip seçmediği, görevi tamamlayıp tamamlamadığı bir ortam simülasyonuyla doğrulanabilir.

RFT'nin bir diğer önemli özelliği, veri verimliliği. İyi tasarlanmış bir ödül fonksiyonu veya doğrulayıcı varsa, RFT düzinelerce örnekle bile anlamlı kazanımlar sağlayabilir — çünkü model, sabit bir veri setini ezberlemek yerine, ödül sinyaline göre kendi kendine keşif yaparak öğreniyor. Bu, veri toplamanın pahalı olduğu ama doğrulamanın ucuz olduğu senaryolarda muazzam bir avantaj.

RFT'yi en etkili biçimde nasıl kullanmalı? Benim sahada gördüğüm ve önerdiğim yaklaşım şu: RFT'yi SFT'nin üzerine bir katman olarak uygulayın. Önce SFT ile modelin temel davranışını, formatını, görev anlayışını oturtun -bu size işin %60-75'ini verir- sonra RFT ile modelin demonstrasyonların kapsamadığı, yani elinizdeki örneklerde hiç görünmeyen başarısızlık modlarına girin. Bunun somut bir örneği: tau-bench veya SWE-bench gibi ajan performansı ölçen benchmarklarda, güçlü bir SFT'ye rağmen ajanların görev tamamlama oranının %40-60 bandında kaldığını görüyoruz. Yani model temel davranışı öğrenmiş, ama karmaşık, çok adımlı, gerçek dünya senaryolarında hâlâ yarı yarıya başarısız oluyor. Bu boşluk, SFT verisinin doğası gereği kapatamayacağı bir boşluktur -çünkü demonstrasyonlar sınırlı sayıda senaryoyu kapsar- ve tam burada RFT, modelin kendi denemeleri üzerinden, gerçek araç-yürütme sonuçlarından öğrenerek bu boşluğu kapatmaya başlar.

Bu noktayı ayrı bir başlıkla vurgulamak istiyorum çünkü sahada en sık yapılan hatalardan biri bu. Bir ekip elinde bir ajan sistemi var -diyelim ki bir müşteri talebini işleyen, birden fazla API'yi sırayla çağıran, ara sonuçlara göre karar veren bir sistem- ve bu sistemin performansını artırmak için DPO'ya yöneliyor. Mantık şu görünüyor: "modelin iyi ve kötü çıktılarını karşılaştırıp tercih çiftleri oluşturalım, model daha iyisini öğrensin."

Sorun şu: ajanik bir görevde "iyi" ve "kötü" olan şey, tek bir çıktının kalitesinden değil, bir dizi kararın birbirine bağlı sonucundan doğar. Model üçüncü adımda yanlış bir araç seçtiğinde, dördüncü ve beşinci adımlar da bu hatayı miras alır. DPO'nun statik tercih çiftleri bu zincirleme etkiyi yakalayamaz -çünkü DPO'ya verdiğiniz çift, önceden sabitlenmiş, "bu senaryoda A cevabı B'den iyidir" diyen dondurulmuş bir karşılaştırmadır. Ama gerçek dünyada araç çağrısının sonucu değişkendir; aynı adımda aracı çağırdığınızda bazen farklı bir sonuç dönebilir, ortam durumu değişebilir. Model bu dinamik geri bildirimden öğrenmesi gerekirken, DPO ona sadece dondurulmuş bir "şu şuna tercih edilir" bilgisi veriyor.

RFT ise tam olarak bu boşluğu dolduracak şekilde tasarlanmış: model gerçekten (ya da simüle edilmiş bir ortamda) aracı çağırır, gerçek sonucu görür, bu sonucun görevi ileri götürüp götürmediği değerlendirilir, ve model bu canlı geri bildirime göre politikasını günceller. Bu yüzden çok adımlı, araç kullanan, ortamla etkileşen sistemlerde RFT, DPO'ya göre yapısal olarak daha uygun bir araçtır.

Bunu bir akış olarak düşünmenizi öneririm. Aşağıdaki adımları sırayla kendinize sorun:

1. Sorunu prompt mühendisliği veya RAG ile çözebiliyor musunuz? Evet ise, fine-tuning'e hiç gerek yok. Hayır ise adım 2'ye geçin.
2. Elinizde "iyi" örnekler var mı (demonstrasyonlar), ama tercih çiftiniz veya doğrulayıcınız yok mu? SFT ile başlayın. Bu, hemen her senaryoda ilk fine-tuning adımı olmalı.
3. SFT sonrası model temel görevi yapıyor ama ince ayrımlarda -ton, tercih, iki doğru cevaptan hangisinin daha uygun olduğu- tutarsız mı? Elinizde ya da toplayabileceğiniz tercih çiftleri varsa ve görev tek adımlı veya kısa etkileşimli ise DPO'yu değerlendirin.
4. Görev çok adımlı, ajanik, araç kullanan bir sistem mi ve doğru/yanlış çıktıyı otomatik doğrulayabiliyor musunuz (test paketi, simülasyon ortamı, matematiksel kontrol, kural motoru)? Evet ise RFT'yi SFT üzerine ekleyin.
5. Doğrulama mekanizmanız yok ve oluşturmanız da mümkün değil mi? O zaman RFT şu an için uygun değil; SFT ve/veya DPO ile devam edin, doğrulama altyapısını paralelde inşa edin.

Bunu bir tabloya da dökebiliriz:

Durum	Önerilen yöntem	Neden
Model jargonu/tonu tutturamıyor, prompt ile düzelmiyor	SFT (önce prompt/RAG denenmiş olmalı)	Demonstrasyon örnekleri direkt çözüm
İki olası cevap var, hangisi daha iyi net değil, görev tek adımlı	DPO	Tercih çiftleri doğrudan optimize edilir
Ajan çok adımlı görev yapıyor, araç çağırıyor, sonuç dinamik	RFT (SFT üzerine)	Dinamik geri bildirimden öğrenme gerekir
Matematik/kod gibi doğrulanabilir ama etiketlenmesi zor görev	RFT	Otomatik doğrulayıcı, az örnekle güçlü sinyal verir
Bilgi güncel değil / sık değişiyor	Ne SFT ne DPO ne RFT	RAG kullanın
Görev nadiren tekrarlanan, tek seferlik bir talep	Hiçbiri	Prompt mühendisliği yeterli

Bu üç yöntemin veri ve maliyet profilleri kayda değer ölçüde farklı. Ben müşterilerime bütçe planlaması yaparken şu kabaca çerçeveyi kullanıyorum -kesin rakamlar projeye göre değişir ama oranlar genelde tutarlı:

Boyut	SFT	DPO	RFT
Veri türü	Girdi-çıktı çiftleri (demonstrasyon)	Tercih çiftleri (A > B)	Aday çıktı + ödül/doğrulama sinyali
Veri toplama zorluğu	Orta (geçmiş başarılı örnekler kullanılabilir)	Yüksek (iki seçenek üretip karşılaştırma etiketi gerekir)	Düşük-orta (doğrulayıcı varsa örnek sayısı azalır)
Tipik örnek sayısı	Yüzler-binler	Yüzler-binler	Düzinelerce-yüzlerce (doğrulayıcı kaliteliyse)
Altyapı karmaşıklığı	Düşük	Orta	Yüksek (ödül modeli/doğrulayıcı + eğitim döngüsü)
Eğitim kararlılığı	Yüksek, öngörülebilir	Orta, dikkatli hiperparametre gerekir	Değişken, doğrulayıcı kalitesine bağlı
Ana maliyet kalemi	Veri kürasyonu	Karşılaştırmalı etiketleme	Doğrulayıcı/ortam geliştirme + hesaplama

Buradan çıkan pratik sonuç şu: SFT'nin veri toplama maliyeti "elinizde zaten olan iyi örnekleri derlemek" olduğu için görece düşük bir bariyerle başlar. DPO'nun maliyeti, tercih çiftlerini üretmek için genelde iki (ya da daha fazla) çıktı üretip bunları karşılaştırmalı olarak etiketlemeniz gerektiğinden artar -bu insan değerlendirici zamanı demek. RFT'de ise asıl maliyet örnek sayısında değil, doğrulayıcıyı doğru kurmakta. İyi bir doğrulayıcı -örneğin bir test paketi, bir simülasyon ortamı, bir kural motoru- inşa etmek mühendislik yatırımı gerektirir, ama bir kez kurulduğunda çok az örnekle bile güçlü sinyal üretebilir. Bu yüzden RFT'yi "az veriyle çok iş yapan ama altyapı gerektiren" yöntem olarak konumlandırıyorum.

Hangi yöntemi (SFT, DPO ya da RFT) seçerseniz seçin, bir de "nasıl" eğiteceğinize karar vermeniz gerekiyor. Modelin tüm parametrelerini güncellemek (full fine-tuning) hem çok maliyetli hem de büyük GPU belleği gerektiriyor -çoğu kurumsal senaryoda bu, bütçeyi ve zaman çizelgesini gerçekçi olmaktan çıkarıyor. Burada devreye LoRA (Low-Rank Adaptation) ve onun daha da hafif versiyonu QLoRA (Quantized LoRA) giriyor.

LoRA'nın mantığı basit: modelin orijinal ağırlıklarını dondurup, her katmana küçük, düşük ranklı "adaptör" matrisleri ekliyorsunuz. Eğitim sırasında sadece bu küçük adaptörler güncelleniyor -modelin toplam parametrelerinin genelde yüzde birkaçı kadar bir kısmı. Bu, hem eğitim süresini hem GPU bellek ihtiyacını hem de depolama maliyetini ciddi ölçüde düşürüyor. QLoRA ise buna bir adım daha ekliyor: temel modeli 4-bit gibi düşük hassasiyette (quantized) belleğe yükleyip, adaptörleri yine tam hassasiyette eğitiyor. Bu sayede tek bir tüketici sınıfı GPU'da bile, daha önce yalnızca büyük bulut kümelerinde mümkün olan boyuttaki modelleri fine-tune edebiliyorsunuz.

Kurumsal danışmanlıklarımda LoRA/QLoRA'yı neredeyse varsayılan seçenek olarak öneriyorum, özellikle şu durumlarda:

• Bütçe ve GPU erişimi sınırlıysa,
• Birden fazla göreve/departmana özel birden fazla "uzman" model versiyonu tutmanız gerekiyorsa (her biri için ayrı küçük adaptör eğitip, aynı temel modelin üzerine takıp çıkarabilirsiniz),
• Hızlı iterasyon istiyorsanız -adaptör eğitimi tam fine-tuning'e göre çok daha hızlı tamamlanır,
• Modelin orijinal yeteneklerini büyük ölçüde korumak, sadece belirli bir davranışı ince ayarlamak istiyorsanız.

Full fine-tuning'i genelde şu durumlarda öneriyorum: modelin davranışında çok köklü bir değişiklik gerekiyorsa, çok büyük ve çeşitli bir veri setiniz varsa, ve bunun maliyetini karşılayacak bütçe ile altyapı mevcutsa. Ama gerçekçi olmak gerekirse, karşılaştığım kurumsal projelerin büyük çoğunluğunda LoRA/QLoRA, ihtiyacı fazlasıyla karşılıyor.

Fine-tuning'in en çok göz ardı edilen kısmı -ve bence en kritik kısmı- değerlendirme. Hangi yöntemi seçerseniz seçin, "modelimiz daha iyi oldu mu" sorusuna somut bir cevap veremiyorsanız, yaptığınız iş bir inanç egzersizi olur, mühendislik değil.

SFT için değerlendirme görece kolaydır: tuttuğunuz bir test setinde, modelin ürettiği çıktıları referans çıktılarla karşılaştırırsınız -otomatik metriklerle (örneğin görev bazlı doğruluk, format uyumu) ya da insan değerlendirmesiyle. DPO için değerlendirme biraz daha inceliklidir: modelin tercih edilen çıktıyı ne sıklıkla ürettiğini, ayrıca genel kalite ve güvenlik metriklerinde gerileme olup olmadığını (yani "hizalama" uğruna genel yeteneğin zayıflamadığını) kontrol etmeniz gerekir.

RFT'de ise değerlendirme, eğitimin kendisiyle iç içe geçer -çünkü zaten eğitim sürecinin merkezinde bir doğrulanabilir ödül (verifiable reward) mekanizması var. Burada kritik soru şu: doğrulayıcınız gerçekten güvenilir mi? Eğer doğrulayıcı hatalıysa ya da kolayca "kandırılabiliyorsa" (reward hacking), model doğru davranışı değil, doğrulayıcıyı kandırmayı öğrenir. Bu yüzden RFT projelerinde zamanımın önemli bir kısmını, model eğitiminden çok, doğrulayıcının sağlamlığını test etmeye ayırıyorum: doğrulayıcı gerçekten "doğru" çözümü doğru olarak işaretliyor mu, "yanlış ama şansla doğru sonuca ulaşan" çözümleri ayırt edebiliyor mu, kenar durumları (edge case) kaçırıyor mu?

Pratik bir öneri: RFT'ye başlamadan önce doğrulayıcınızı, insan değerlendirmesiyle karşılaştırarak bir "doğrulayıcı doğrulaması" (validator validation) yapın. Küçük bir örneklem üzerinde doğrulayıcının verdiği puanlarla, uzman bir insanın verdiği puanları karşılaştırın. Aralarında yüksek bir uyum yoksa, RFT'ye başlamadan önce doğrulayıcıyı iyileştirmeniz gerekir -aksi halde model, sizin istemediğiniz bir şeyi çok iyi öğrenir.

Somutlaştırmak için gerçek bir profile yakın, kompozit bir örnek paylaşayım. Orta ölçekli bir Türk bankasının veya e-ticaret şirketinin müşteri hizmetleri operasyonunu düşünün. Süreç genelde şöyle ilerliyor:

Aşama 1 - Prompt ve RAG: İlk aşamada mevcut büyük dil modelini, şirketin ürün kataloğu ve prosedür dokümanlarına bağlı bir RAG sistemiyle destekliyoruz. Bu, "iade süreci nedir", "kampanya şartları neler" gibi bilgi bazlı soruların büyük kısmını çözüyor. Fine-tuning'e hiç gerek kalmıyor.

Aşama 2 - SFT: Müşteri hizmetleri ekibinin geçmiş, yüksek puanlı (müşteri memnuniyeti anketinde iyi değerlendirilmiş) konuşma kayıtlarını -kişisel veriler anonimleştirilerek veya maskelenerek- SFT verisi olarak kullanıyoruz. Model, şirketin tonunu, standart yanıt kalıplarını, eskalasyon kurallarını bu aşamada öğreniyor. Bu, temel görev başarımının büyük kısmını halleder.

Aşama 3 - DPO (opsiyonel): Eğer belirli senaryolarda "iki farklı yanıt tarzı da doğru ama biri diğerinden daha uygun" durumu varsa (örneğin, aynı bilgiyi veren ama biri daha empatik, diğeri daha kuru olan iki yanıt), müşteri temsilcilerinden toplanan "bu yanıt şundan daha iyi" değerlendirmeleriyle bir DPO turu uygulanabilir.

Aşama 4 - RFT (ajanik senaryoda): Şirketin müşteri hizmetleri botu artık sadece soru cevaplamıyor, aynı zamanda sipariş sorgulama API'sini çağırıyor, iade sürecini başlatıyor, kargo takip sistemine erişiyor -yani çok adımlı bir ajan haline geliyor. Burada SFT sonrası ajan, benchmark testlerinde görevlerin önemli bir kısmında tıkanabiliyor: yanlış API'yi çağırıyor, ara sonucu yanlış yorumluyor, ya da doğru sırayla adım atamıyor. Bu noktada bir test/simülasyon ortamı kurup (sahte sipariş veritabanı, kontrollü API yanıtları), ajanın gerçek görev tamamlama başarısını otomatik doğrulayan bir mekanizma inşa ediyoruz ve RFT'yi SFT üzerine uyguluyoruz. Sonuç, ajanın demonstrasyon verisinde hiç görülmemiş ama simülasyonda karşılaştığı senaryolarda da doğru karar verebilmesi.

Bu aşamalı yaklaşımın en önemli faydası, her adımda ölçülebilir bir kazanım elde etmeniz ve bir sonraki, daha maliyetli adıma ancak gerçekten gerekiyorsa geçmeniz.

Türkiye'de fine-tuning projelerine baktığımda, teknik tartışmanın gölgesinde kalan ama en az onun kadar kritik bir konu var: KVKK (Kişisel Verilerin Korunması Kanunu). Müşteri konuşma kayıtlarını, destek taleplerini, satış görüşmelerini SFT, DPO veya RFT verisi olarak kullanacaksanız, bu veriler büyük ihtimalle kişisel veri -bazen de özel nitelikli kişisel veri- içeriyor.

Sahada dikkat çektiğim birkaç kritik nokta:

• Amaç sınırlaması: KVKK'nın temel ilkelerinden biri, verinin toplandığı amaç dışında kullanılmaması. Müşteri hizmetleri kaydı, "hizmet sunmak" amacıyla toplanmışsa, bunu "model eğitmek" amacıyla kullanmak için ayrı bir hukuki dayanak (açık rıza, meşru menfaat analizi vb.) gerekebilir. Bu değerlendirmeyi proje başlamadan önce hukuk ve uyum (compliance) ekibiyle netleştirin.
• Anonimleştirme ve maskeleme: Fine-tuning verisine girmeden önce ad, TC kimlik no, telefon, adres gibi doğrudan tanımlayıcıları maskelemek ya da tamamen çıkarmak standart bir uygulama olmalı. Ama dikkat: anonimleştirme her zaman göründüğü kadar basit değil -bağlamdan kişi tekrar tanımlanabilir hale gelebiliyor (re-identification riski). Bu yüzden anonimleştirme sürecini bir kerelik bir "isim sil" işlemi değil, ayrı bir risk değerlendirmesi gerektiren bir adım olarak ele almanızı öneririm.
• Veri minimizasyonu: Fine-tuning için "elimdeki tüm veriyi kullanayım" refleksi hem KVKK açısından riskli hem de teknik açıdan gereksiz -zaten SFT için birkaç yüz-bin kaliteli örnek, tüm veri tabanınızdan çok daha değerlidir. Sadece gerçekten gerekli, temsil edici bir alt küme kullanmak hem uyumu kolaylaştırır hem model kalitesini artırır.
• Üçüncü taraf model sağlayıcıları: Eğer fine-tuning'i bulut tabanlı bir API üzerinden (yurt dışında barındırılan bir sağlayıcı ile) yapıyorsanız, bu bir yurt dışına veri aktarımı anlamına gelebilir ve KVKK'nın 9. maddesi kapsamındaki ek yükümlülükleri (yeterli koruma kararı olan ülke, standart sözleşme hükümleri, açık rıza vb.) tetikleyebilir. Bu konuyu proje kapsamına başlamadan netleştirmek, projenin ortasında durup baştan başlamaktan çok daha ucuza gelir.
• Saklama ve silme: Eğitim verisinin ne kadar süre saklanacağı, model eğitildikten sonra ham verinin silinip silinmeyeceği gibi konular, KVKK'nın saklama süresi ilkesiyle doğrudan ilişkili. Bu politikaları yazılı hale getirin.

Benim müşterilere önerdiğim pratik yaklaşım şu: fine-tuning projesine başlamadan önce, teknik ekip ile uyum/hukuk ekibini aynı masaya oturtup bir "veri kullanım onayı" (data use sign-off) süreci işletin. Bu, projenin sonuna doğru bir hukuki blokaj yaşamaktan çok daha az maliyetli.

Yazıyı toparlarken, sahada kullandığım basit bir kontrol listesini paylaşmak istiyorum:

• Sorunu prompt mühendisliği veya RAG ile çözmeyi gerçekten denedim mi?
• Elimde kaliteli, temsil edici demonstrasyon örnekleri var mı (SFT için)?
• Tercih ayrımı gereken bir senaryo mu, yoksa tek doğru cevap mı var (DPO'ya mı ihtiyacım var)?
• Görev çok adımlı/ajanik mi, dinamik araç sonuçlarından öğrenmesi mi gerekiyor (RFT'ye mi ihtiyacım var)?
• Doğru/yanlış çıktıyı otomatik doğrulayabileceğim bir mekanizma (test paketi, simülasyon, kural motoru) var mı ya da kurabilir miyim?
• LoRA/QLoRA ile mi, yoksa full fine-tuning ile mi ilerlemeliyim -bütçem ve altyapım neye izin veriyor?
• Değerlendirme setimi eğitim verisinden tamamen ayrı tuttum mu?
• Doğrulayıcımı (varsa) insan değerlendirmesiyle karşılaştırıp güvenilirliğini test ettim mi?
• Müşteri verisi kullanıyorsam, KVKK açısından amaç sınırlaması, anonimleştirme, veri minimizasyonu ve yurt dışı aktarım konularını hukuk/uyum ekibiyle netleştirdim mi?
• Aşamalı bir yol izliyorum -önce SFT, gerekirse üzerine DPO ya da RFT- yoksa doğrudan en karmaşık yönteme mi atladım?

Bu son madde aslında yazının özü. Fine-tuning dünyasında en pahalı hata, doğrudan en karmaşık yöntemle başlamak. SFT'yi atlayıp doğrudan RFT'ye girmeye çalışan ekiplerin, temelsiz bir eğitim sürecinde saatlerce hiperparametre ayarlamakla uğraştığını, sonunda geri dönüp SFT'den başladığını defalarca gördüm. Doğru sıra neredeyse her zaman aynı: önce prompting ve RAG'ı zorlayın, sonra SFT ile sağlam bir temel atın, sonra ihtiyaca göre DPO ile hizalamayı inceltin ya da RFT ile demonstrasyonların ulaşamadığı, doğrulanabilir başarı kriterlerine sahip görev sınıflarına girin. Bu sıralamayı doğru kurduğunuzda, hem bütçenizi hem ekibinizin zamanını hem de -belki en önemlisi- modelinize duyduğunuz güveni koruyabilirsiniz.