Reinforcement Fine-Tuning (RFT): GRPO, DPO ve Muhakeme Modelleri (2026)

TL;DR — Reinforcement Fine-Tuning (RFT), doğrulanabilir görevlerde doğru sonucu ödüllendirerek modelin muhakemesini güçlendiren bir ince ayar ailesidir. Sahada gördüğüm en büyük yanlış anlama şu: ekipler "modeli kendi verimizle eğitelim" deyip her şeyi ince ayara yıkıyor. Oysa 2026'da işleyen sıralama bellidir: Prompt → RAG → Fine-tune → Distill. İnce ayarı kalıcı davranış, şema ve ton için kullanın; değişen ya da gizli bilgi için RAG kullanın. En yüksek getiriyi, güçlü bir temel modelin üzerine oturttuğunuz ince bir LoRA/QLoRA adaptörünü, retrieval'ı (RAG) değiştirmeden onunla birlikte çalıştırarak alırsınız. PPO, DPO ve GRPO arasındaki farkı, doğrulanabilir ödül tasarımını, Türkçe/KVKK ve on-prem boyutunu ve pratik bir karar kontrol listesini aşağıda sahadan anlatıyorum.

Bu yazıyı bir tanım sözlüğü gibi değil, danışmanlık masasında karşımda oturan bir teknik ekibe anlatır gibi yazdım. Çünkü RFT, GRPO, DPO gibi kavramlar son bir yılda o kadar hızlı popülerleşti ki, terminoloji ile gerçek fayda arasındaki bağ çoğu projede koptu. Amacım o bağı yeniden kurmak.

Reinforcement Fine-Tuning'i en yalın haliyle şöyle tarif ediyorum: modele "şu cevap doğru, şu yanlış" demek yerine, modelin ürettiği cevabı bir ödül sinyaliyle puanlıyoruz ve modeli yüksek ödül alan davranışlara doğru itiyoruz. Klasik denetimli ince ayarda (SFT) modele "girdi buysa çıktı tam olarak budur" diye örnek gösteririz. RFT'de ise "çıktın ne kadar iyiydi" diye bir sinyal veririz. Fark ince gibi görünüyor ama sonuçları çok farklı.

Bu ayrımı bir sınav benzetmesiyle anlatmayı seviyorum. SFT, öğrenciye çözülmüş soruların cevap anahtarını ezberletmek gibidir. Öğrenci gördüğü soruları güzel taklit eder ama biraz farklı bir soruda zorlanır. RFT ise öğrenciye kendi çözümünü yaptırıp sonra "bu çözüm doğru sonuca ulaştı mı" diye kontrol etmek gibidir. Öğrenci, doğru sonuca ulaştıran muhakeme yollarını güçlendirir. İşte bu yüzden RFT özellikle muhakeme gerektiren, çok adımlı düşünme isteyen görevlerde parlıyor.

Ama burada kritik bir şart var: doğrulanabilirlik. RFT'nin gerçekten işe yaraması için, bir cevabın doğru olup olmadığını otomatik ve güvenilir biçimde ölçebilmeniz gerekir.

"

RFT'nin altın kuralı: Eğer cevabın doğruluğunu bir makineyle, tutarlı biçimde puanlayamıyorsanız, ödül sinyaliniz gürültülüdür ve model o gürültüyü öğrenir.

Doğrulanabilir görevlere sahadan örnekler:

• Matematik ve sayısal muhakeme: Sonuç ya doğrudur ya yanlış. Kontrol kolaydır.
• Kod üretimi: Test paketini geçiyor mu, geçmiyor mu? Derleniyor mu? Birim testleri yeşil mi?
• Yapılandırılmış çıktı (schema) uyumu: JSON şemasına uyuyor mu, alanlar doğru tipte mi, zorunlu alanlar dolu mu?
• Kurallı belge çıkarımı: Faturadan KDV tutarını çekme gibi görevlerde, doğru değer bilinir ve karşılaştırılabilir.
• Sınıflandırma ve etiketleme: Kesin doğru etiket varsa, ödül nettir.

Buna karşılık "müşteriye daha empatik bir e-posta yaz" gibi görevlerde doğruluk özneldir. Orada RFT'yi de kullanabilirsiniz ama ödülü bir insan tercihi veya bir yargı modeli üretmek zorunda kalırsınız; bu da işi zorlaştırır ve bizi DPO gibi yöntemlere götürür. Bunlara birazdan geleceğim.

Kısacası: RFT'yi, "doğru" kavramının objektif olarak ölçülebildiği görevlerde ilk tercihiniz yapın. Doğruluk öznelse, önce daha ucuz yolları deneyin.

Bu üç kısaltma insanların gözünü korkutuyor. Oysa temel fikirleri sürpriz derecede sezgisel. Hepsini aynı soruyu yanıtlayan üç farklı strateji gibi düşünün: "Modeli, insanların ya da bir ölçütün tercih ettiği cevaplara doğru nasıl iteriz?"

PPO — Proximal Policy Optimization

PPO, takviyeli öğrenmenin klasik ağır topudur. Mantığı şudur: model bir cevap üretir, bir ödül modeli (veya bir doğrulayıcı) bu cevaba puan verir, sonra bu puana göre modelin parametreleri güncellenir. "Proximal" (yakınsak) kısmı önemlidir: her güncellemede modelin çok fazla sapmasını engelleyen bir frene sahiptir. Böylece model, iyi cevaplara doğru yürürken tamamen dağılmaz.

PPO güçlüdür ama bedeli vardır. Genellikle ayrı bir ödül modeli eğitmeniz, sonra o ödül modeliyle ana modeli eğitmeniz gerekir. Bu, iki modeli, bir değer fonksiyonunu ve hassas hiperparametreleri aynı anda idare etmek demektir. Sahada gördüğüm kadarıyla PPO, en fazla esneklik isteyen ve elinde ciddi mühendislik kaynağı olan ekipler için mantıklı; küçük ekipler için genelde fazla ağır kaçıyor.

DPO — Direct Preference Optimization

DPO, PPO'nun karmaşasına bir tepki gibi doğdu ve sahada bayıldığım bir sadeliği var. DPO'da ayrı bir ödül modeli eğitmezsiniz. Bunun yerine elinizde tercih çiftleri olur: aynı soruya iki cevap, biri "tercih edilen", diğeri "tercih edilmeyen". DPO, modeli doğrudan tercih edilen cevaba yaklaştırıp diğerinden uzaklaştıracak biçimde optimize eder.

DPO'nun güzelliği, veri formatının insan sezgisine çok uygun olması. "Bu cevap şundan daha iyi" demek, "bu cevap tam olarak şudur" demekten çok daha kolaydır ve genellikle daha ölçeklenebilir. Bu yüzden ton, üslup, güvenlik ve stil hizalaması gibi öznel görevlerde DPO benim ilk tercihim oluyor. Doğrulanabilir bir "doğru cevap" yoksa ama "hangisi daha iyi" diyebiliyorsanız, DPO çok verimlidir.

GRPO — Group Relative Policy Optimization

GRPO, son dönemin muhakeme modellerini popülerleştiren yöntem oldu. Fikri çok zarif: PPO'daki gibi ayrı ve pahalı bir değer fonksiyonu/ödül modeli taşımak yerine, aynı soru için modelden bir grup cevap (diyelim 8 veya 16 farklı deneme) ürettirir. Sonra bu cevapları doğrulayıcıyla puanlar ve her cevabı, grubun ortalamasına göre değerlendirir. Ortalamanın üstünde kalan cevaplar ödüllendirilir, altında kalanlar cezalandırılır.

Bunu bir sınıf benzetmesiyle anlatıyorum: GRPO, öğrencinin sınav kağıdını mutlak bir barajla değil, sınıf ortalamasına göre notlar. "Bu deneme, aynı sorudaki diğer denemelerimden daha mı iyiydi?" sorusunu sorar. Bu görecelilik, ayrı bir değer fonksiyonu eğitme ihtiyacını ortadan kaldırır ve süreci hem basitleştirir hem de doğrulanabilir görevlerde çok etkili kılar.

GRPO özellikle matematik, kod ve mantık gibi otomatik doğrulanabilen alanlarda parlıyor; çünkü grup içindeki cevaplara sağlam bir puan verebiliyorsunuz. Muhakeme modellerinin son bir yıldaki sıçramasının arkasında büyük ölçüde bu yaklaşım var.

Üçünü tek cümlede özetleyeyim:

• PPO: En esnek, en güçlü, ama en ağır ve en çok mühendislik isteyen yol.
• DPO: Tercih çiftleriyle çalışan, öznel hizalama için sade ve verimli yol.
• GRPO: Doğrulanabilir görevlerde grup-göreceli ödülle muhakemeyi büyüten, değer modeli gerektirmeyen zarif yol.

Danışmanlıklarımda tekrar tekrar şunu söylüyorum: RFT projelerinin kaderi, algoritmada değil, ödül tasarımında belirlenir. GRPO'yu ya da PPO'yu doğru kurmak görece kolaydır; asıl zor olan, "iyi cevap" kavramını makinenin puanlayabileceği bir fonksiyona dönüştürmektir.

İyi bir doğrulanabilir ödül tasarımının benim için olmazsa olmazları:

1. Kesinlik. Ödül fonksiyonu, aynı cevaba her seferinde aynı puanı vermeli. Rastgelelik varsa, model gürültüyü öğrenir.

2. Manipülasyona (reward hacking) dayanıklılık. Model tembeldir; ödülü hak etmeden almanın yolunu bulursa onu bulur. Klasik örnek: "cevap doğruysa ödül ver" dediğinizde model, sadece doğru sonucu tahmin edip muhakemeyi atlamayı öğrenebilir. Ya da uzunluğu ödüllendirirseniz, model gereksiz uzun ve boş metinler üretmeye başlar.

"

Sahada bir kural edindim: Ödül fonksiyonunu tasarladığınızda, "Ben bu modelin yerinde olsam bu ödülü hak etmeden nasıl toplarım?" diye düşünün. Bulduğunuz her açığı model de bulacaktır.

3. Kademeli sinyal. Mümkünse ödül sadece 0/1 olmasın. Kısmi doğruluğu ödüllendirmek (örneğin doğru formatta ama yanlış değer, ya da 4 adımın 3'ü doğru) öğrenmeyi hızlandırır. Ama bu kademeleri de manipüle edilemeyecek biçimde tasarlamalısınız.

4. Format ve içerik ödülünü ayırmak. Muhakeme modellerinde sık kullanılan bir teknik: bir yandan cevabın doğru formatta (örneğin düşünme adımları belli bir etiket içinde, nihai cevap ayrı bir yerde) olmasını, öte yandan içeriğin doğru olmasını ayrı ayrı ödüllendirmek. Bu, modelin hem düzenli hem doğru olmasını sağlar.

Doğrulayıcı olarak sahada kullandığım araçlar: birim test koşucuları (kod için), sembolik/sayısal karşılaştırıcılar (matematik için), JSON şema doğrulayıcıları (yapılandırılmış çıktı için), düzenli ifadeler ve kural motorları (kurallı çıkarım için), ve gerektiğinde bir "yargı modeli" (LLM-as-a-judge, öznel görevler için — ama bunu dikkatli kullanın, çünkü yargı modelinin de önyargıları vardır).

Şimdi işin maliyet tarafına gelelim, çünkü çoğu ekibin ince ayardan vazgeçmesinin sebebi burada saklı. Bir modelin tüm parametrelerini yeniden eğitmek (full fine-tuning) hem devasa GPU belleği hem uzun süre hem de yüksek maliyet ister. Türkiye'deki çoğu kurumsal proje için bu tablo baştan caydırıcı.

İşte LoRA (Low-Rank Adaptation) tam bu noktada devreye giriyor ve sahada bana en çok "aslında yapılabilirmiş" dedirten yöntem. LoRA'nın fikri son derece zarif: temel modelin ağırlıklarını donduruyorsunuz, onlara hiç dokunmuyorsunuz. Bunun yerine modele, eğitilebilir küçük, düşük ranklı matrisler ekliyorsunuz. Eğitim sırasında sadece bu küçük matrisler güncelleniyor. Sonuç: minimum hesapla, güçlü bir uyarlama.

Bunu şöyle anlatıyorum: Devasa bir modeli baştan yeniden inşa etmiyorsunuz; üzerine ince bir "davranış katmanı" ekliyorsunuz. Milyarlarca parametreli bir modele karşılık, belki birkaç milyon parametre eğitiyorsunuz. Bellek ihtiyacı düşüyor, eğitim hızlanıyor, ve en güzeli: aynı temel modelin üzerine farklı görevler için farklı LoRA adaptörleri takıp çıkarabiliyorsunuz.

QLoRA ise bu fikri bir adım öteye taşıyor: temel modeli kuantize ederek (yani ağırlıkları daha düşük hassasiyette, örneğin 4-bit temsille tutarak) bellek ihtiyacını daha da düşürür, sonra LoRA adaptörlerini bunun üzerine eğitir. Böylece, aksi halde çok pahalı bir donanım gerektirecek bir modeli, çok daha mütevazı bir GPU'da ince ayarlayabilirsiniz. Türkiye'de kendi donanımıyla, sınırlı bütçeyle çalışan ekipler için QLoRA adeta bir kapı açıyor.

Benim "LoRA merdiveni" dediğim pratik yaklaşım:

1. Güçlü bir temel modelle başlayın. Zayıf bir modeli LoRA ile kurtaramazsınız; LoRA iyi bir temeli uzmanlaştırır, kötü bir temeli düzeltmez.
2. İnce bir adaptörle başlayın (düşük rank). Küçük başlayıp gerekirse büyütmek, baştan şişirmekten iyidir.
3. Adaptörü retrieval ile birlikte çalıştırın. En yüksek getiri buradadır: bilgi RAG'den gelir, davranış/şema/ton adaptörden.
4. Görev başına ayrı adaptör düşünün. Tek bir dev modeli her işe zorlamak yerine, hafif ve değiştirilebilir adaptörler bakımı kolaylaştırır.

Bu, danışmanlık masamda en çok tartışılan soru. Net cevabım şu: İkisi rakip değil, ortaktır. Ama hangisinin ne için olduğunu karıştırmak, projelerin en sık düştüğü tuzaktır.

Ayrımı şöyle koyuyorum:

• İnce ayar, "nasıl davrandığını" değiştirir. Kalıcı davranış, çıktı şeması, ton, üslup, bir alanın jargonu, belli bir formatı her seferinde tutturma — bunlar ince ayar işidir. Modelin "kişiliğini" ve "reflekslerini" şekillendirirsiniz.
• RAG, "neyi bildiğini" değiştirir. Değişen, güncellenen, gizli ya da kuruma özel bilgi — bunlar RAG işidir. Fiyat listesi, ürün kataloğu, iç politika belgeleri, dünkü mevzuat değişikliği... Bunları ince ayara gömmek büyük hatadır, çünkü bilgi değişince modeli yeniden eğitmeniz gerekir.

"

Basit turnusol testi: Bilgi altı ayda bir değişiyorsa RAG kullanın. Davranış kalıcıysa ince ayar yapın. Kararsızsanız, muhtemelen RAG'dir.

Şu tabloyu danışanlarımla sık paylaşıyorum. Hangi yöntem, ne için, ne tür veri ister ve maliyeti nedir:

Yöntem	Ne için	Gereken veri	Göreli maliyet
Prompt engineering	Hızlı davranış ayarı, ilk deneme	Sadece iyi yazılmış yönergeler	Çok düşük
RAG (retrieval)	Değişen/gizli/kuruma özel bilgi	Belge tabanı + iyi indeksleme	Düşük–orta
SFT (denetimli ince ayar)	Sabit davranış, format, temel uzmanlaşma	Girdi–çıktı örnek çiftleri	Orta
LoRA / QLoRA	Ekonomik, taşınabilir uzmanlaşma	SFT verisi + güçlü temel model	Düşük–orta
DPO	Ton, stil, güvenlik, öznel hizalama	Tercih çiftleri (iyi/kötü cevap)	Orta
GRPO / PPO (RFT)	Doğrulanabilir görevlerde muhakeme	Doğrulayıcı + bol soru havuzu	Orta–yüksek

Bu tabloyu okurken şunu aklınızda tutun: yukarıdan aşağı indikçe hem maliyet hem karmaşıklık artar. O yüzden yukarıdan başlayın.

2026'da savunduğum sıralama tam olarak bu ve neredeyse her projede işe yarıyor. Merdiveni basamak basamak çıkın; bir üst basamak yetmeden bir alt basamağa geçmeyin.

Basamak 1 — Prompt. Her şey iyi bir prompt ile başlar. Şaşırtıcı sayıda "ince ayar gerekiyor" denen problem, aslında iyi yazılmış bir sistem promptu, birkaç örnek (few-shot) ve net bir çıktı formatı ile çözülüyor. Bu en ucuz, en hızlı basamak. Buradan alacağınız her kazanç, sonraki basamaklardan tasarruf demektir.

Basamak 2 — RAG. Prompt yetmiyorsa ve sorun genellikle "model bizim bilgimizi bilmiyor" ise, retrieval ekleyin. Modelin cevaplarını kendi belgelerinizle, kataloglarınızla, politikalarınızla besleyin. Sahadaki kurumsal projelerin çok büyük kısmı bu iki basamakta çözülüyor ve hiç ince ayara gerek kalmıyor.

Basamak 3 — Fine-tune. RAG da yetmiyorsa, yani sorun bilgi değil davranış ise, işte o zaman ince ayar zamanıdır. "RAG yetmediğinde" diye özetliyorum bu eşiği. Model bilgiye erişiyor ama formatı tutturamıyor, tonu yakalayamıyor, sizin alanınızın muhakemesini yapamıyorsa — ince bir LoRA/QLoRA adaptörü devreye girer. Ve tekrar vurguluyorum: bu adaptörü RAG'in yerine değil, yanına koyun. En yüksek getirili kurgu budur.

Basamak 4 — Distill. İnce ayarlı, güçlü ama belki büyük ve pahalı modeliniz iyi çalışıyorsa, son adım onu damıtmaktır (distillation): büyük modelin davranışını daha küçük, daha hızlı, daha ucuz bir modele aktarmak. Bu, üretim maliyetini düşürmek ve gecikmeyi azaltmak için yapılır. Ama bunu ancak elinizde işleyen, kaliteli bir "öğretmen" model varken yaparsınız.

Bu merdivenin özündeki felsefe şu: Her zaman en ucuz ve en basit çözümle başla, ancak gerçekten gerektiğinde bir üst karmaşıklık seviyesine çık. Sahadaki en pahalı hataları, bu merdiveni atlayıp doğrudan üçüncü basamağa atlayan ekiplerde gördüm.

İnce ayar projelerinde parlak kısım algoritmalar sanılıyor ama işin yüzde seksenini veri oluşturuyor. Sahadan acı bir gerçek: kötü veriyle en iyi algoritma bile kötü model üretir. "Garbage in, garbage out" bu alanda acımasızca geçerli.

Kaliteli ince ayar verisinde aradıklarım:

• Temsililik. Veri, modelin gerçek dünyada karşılaşacağı girdileri yansıtmalı. Sadece kolay örneklerle eğitirseniz, model zor durumlarda çöker.
• Tutarlılık. Aynı tip girdiye çelişkili çıktılar verirseniz, model kafası karışık öğrenir. Etiketleme rehberi ve tutarlılık kontrolleri şart.
• Temizlik. Yinelenen, hatalı, sızıntılı (test verisinin eğitime karışması) örnekler modeli yanıltır. Veriyi ayıklamak sıkıcıdır ama en yüksek getirili iştir.
• Denge. Bir sınıf ya da bir davranış türü veride aşırı baskınsa, model diğerlerini ihmal eder.
• Yeterli ama abartısız hacim. LoRA'nın güzelliği, çoğu görevin binlerce iyi örnekle çözülebilmesidir. On binlerce vasat örnektense, birkaç bin özenli örnek daha iyidir.

Ödül tasarımı tarafında bir önceki bölümde konuştuklarımı tekrar hatırlatıyorum: ödülünüz, hedeflediğiniz davranışı tam olarak yansıtmalı ve manipüle edilememeli. Ödül fonksiyonu, projenin gizli sözleşmesidir; modele gerçekte ne istediğinizi orada söylersiniz. Yanlış söylerseniz, model sizin dediğinizi değil, ödülün dediğini yapar.

Bir modeli ince ayarladıktan sonra "iyi görünüyor" demek yetmez; bunu kanıtlamanız gerekir. Ve daha da önemlisi, modeli bir yerde iyileştirirken başka bir yerde bozmadığınızdan emin olmalısınız. Buna regresyon diyorum ve sahada en sinsi tuzaklardan biri.

Değerlendirme disiplinim şöyle:

1. Ayrı bir test kümesi tutun. Eğitimde asla görmediği, gerçek dünyayı yansıtan bir değerlendirme seti olmalı. Eğitim verisiyle test etmek kendini kandırmaktır.

2. Aşırı öğrenmeye (overfitting) karşı uyanık olun. Model eğitim örneklerini ezberleyip yeni örneklerde çökebilir. Eğitim başarısı artarken doğrulama başarısı düşüyorsa, alarm çalıyor demektir. LoRA burada bir avantaj sağlar çünkü daha az parametre eğitildiğinden ezberleme eğilimi görece azdır, ama yine de dikkat gerekir.

3. Regresyon testi yapın. İnce ayar öncesi modelin iyi yaptığı görevleri bir kenara not edin ve ince ayar sonrası bunları tekrar test edin. Muhakeme için ince ayar yaparken modelin genel yeteneklerini, üslubunu ya da güvenliğini bozmuş olabilirsiniz. Yeni yetenek kazandırırken eski yetenekleri kaybetmek (catastrophic forgetting) gerçek bir risktir.

4. Sadece ortalamaya değil, kuyruğa da bakın. Ortalama başarı yükselmiş ama en kritik %5'lik zor vakalarda çökmüş bir model, üretimde felaket olabilir. Hata analizini elle, örnek örnek yapın.

5. İnsan değerlendirmesini ihmal etmeyin. Otomatik metrikler yol gösterir ama özellikle öznel görevlerde, birkaç yüz örneği gerçek insanların gözden geçirmesi paha biçilmezdir.

"

Bir modeli ince ayarlamak kolaydır; onu bozmadığınızı kanıtlamak zordur. Değerlendirme altyapınıza, eğitim altyapınız kadar yatırım yapın.

Şimdi Türkiye'de çalışan biri olarak en çok karşılaştığım ve genel kaynaklarda pek konuşulmayan boyuta geleyim.

Türkçe dil uyarlaması. Küresel modeller Türkçeyi gitgide daha iyi konuşuyor ama kurumsal bir bağlamda hâlâ boşluklar var: sektöre özel Türkçe jargon, resmi yazışma üslubu, hukuki-idari dilin incelikleri, Türkçenin sondan eklemeli yapısının yarattığı ince hatalar. İşte bu, ince ayarın parladığı klasik bir "davranış" problemidir. Türkçe kurumsal üslubu ve terminolojiyi kalıcı biçimde modele yerleştirmek için ince bir LoRA adaptörü çok iş görür. Ama dikkat: kurumun güncel bilgisi (fiyatlar, mevzuat, iç prosedürler) yine RAG'de kalmalı; sadece dil ve üslup davranışı ince ayara girmeli.

KVKK ve veri mahremiyeti. Bu, Türkiye'deki kurumsal projelerin belkemiği. Kişisel veri içeren, ticari sır niteliğinde ya da regülasyona tabi veriyle çalışıyorsanız, bu veriyi bir dış API'ye göndermek çoğu zaman ya yasak ya da çok riskli. İşte burada ince ayarın ve özellikle LoRA/QLoRA'nın bir avantajı ortaya çıkıyor:

• On-prem (yerinde) eğitim. LoRA/QLoRA'nın düşük donanım ihtiyacı sayesinde, ince ayarı kurumun kendi sunucularında, veriyi dışarı çıkarmadan yapabilirsiniz. Veri hiç binadan çıkmaz. KVKK açısından bu, altın standarda çok yakındır.
• Veri yerelliği ve denetlenebilirlik. Kendi altyapınızda eğittiğinizde, hangi verinin nasıl kullanıldığını tam denetleyebilir, kayıt altına alabilir ve gerektiğinde ispatlayabilirsiniz.
• Adaptörlerin taşınabilirliği. LoRA adaptörü küçük bir dosyadır; onu kurum içinde saklamak, sürümlemek ve yönetmek kolaydır. Temel model sabit kalır, hassas davranış adaptörde durur.

KVKK bağlamında pratik bir uyarı da vereyim: eğitim verinizde kişisel veri varsa, bunu ince ayara gömmek kalıcı bir iz bırakabilir. Mümkün olduğunca anonimleştirin ve maskeleyin. Kişisel verinin bizzat kendisini değil, davranış kalıbını öğretmeye çalışın. Değişen ya da silinmesi gerekebilecek kişisel bilgi, ince ayara değil RAG katmanına ait olmalı — çünkü RAG'de bir kaydı silmek kolaydır, ince ayarlı ağırlıklardan bir bilgiyi "geri almak" ise pratikte çok zordur. Bu, "unutulma hakkı" gibi KVKK ilkeleriyle doğrudan ilgilidir.

Maliyet ve hesaplama. Türkiye'de GPU erişimi ve maliyeti hâlâ ciddi bir kısıt. QLoRA'nın en büyük armağanı burada: aksi halde erişilemez görünen bir ince ayarı, mütevazı bir donanımda mümkün kılıyor. Bütçesi sınırlı bir ekip için "en yüksek getirili ince ayar", güçlü bir açık temel modele oturtulmuş, RAG ile beslenen ince bir QLoRA adaptörüdür. Bu kurgu, hem KVKK'yı hem bütçeyi hem de kaliteyi aynı anda gözetir.

Şimdi tüm bunları, danışmanlık masamda kullandığım pratik bir kontrol listesine indirgeyeyim. Bir sonraki projenizde sırayla sorun.

Adım 1 — Problem gerçekten ince ayar mı?

• İyi bir sistem promptu ve birkaç örnekle sorunu denedim mi?
• Sorun "model bilmiyor" ise, önce RAG denedim mi?
• Sorun kalıcı bir davranış/şema/ton problemi mi? Eğer evetse, ince ayara devam.

Adım 2 — Görev doğrulanabilir mi?

• Bir cevabın doğruluğunu makineyle, tutarlı biçimde ölçebiliyor muyum?
• Evet ise → RFT (GRPO/PPO) güçlü bir aday.
• Hayır, ama "hangisi daha iyi" diyebiliyorum → DPO.
• İkisi de değil, sadece örnek çiftlerim var → SFT.

Adım 3 — Algoritma ve yöntem seçimi.

• Doğrulanabilir muhakeme, sınırlı mühendislik kaynağı → GRPO.
• En üst esneklik, güçlü ekip, karmaşık ödül → PPO.
• Öznel hizalama, tercih verisi → DPO.
• Temel uzmanlaşma → SFT, ve bunu LoRA/QLoRA ile ekonomik yap.

Adım 4 — Veri ve ödül.

• Verim temsili, tutarlı, temiz ve dengeli mi?
• Test verisi eğitime sızmadı mı?
• Ödül fonksiyonum manipülasyona (reward hacking) dayanıklı mı?
• Ödül, tam olarak istediğim davranışı mı ölçüyor?

Adım 5 — Kurgu ve altyapı.

• Adaptörü RAG ile birlikte mi kurguladım (yerine değil)?
• Güçlü bir temel modelle mi başladım?
• KVKK gereği on-prem/yerinde eğitim gerekiyor mu? QLoRA bunu mümkün kılıyor mu?
• Kişisel veriyi anonimleştirdim/maskeledim mi?

Adım 6 — Değerlendirme ve emniyet.

• Ayrı, gerçekçi bir test kümem var mı?
• Regresyon testiyle eski yetenekleri koruduğumu kanıtladım mı?
• Aşırı öğrenmeye karşı doğrulama eğrilerini izliyor muyum?
• Ortalamaya değil, zor kuyruk vakalarına da baktım mı?
• Kritik görevlerde insan gözden geçirmesi yaptım mı?

Bu listeyi bir bürokrasi olarak değil, bir emniyet kemeri olarak görün. Her maddeyi "evet" diye işaretleyerek ilerlediğinizde, ince ayar projeniz sahada gördüğüm başarısız projelerin düştüğü tuzakların neredeyse tamamından kaçınmış olur.

Son olarak somut bir eylem önerisi bırakayım: Bir sonraki toplantınızda, ekibinize tek bir soru sorun — "Çözmeye çalıştığımız şey bir bilgi problemi mi, yoksa bir davranış problemi mi?" Bu tek sorunun cevabı, size doğrudan RAG mı yoksa ince ayar mı yapacağınızı söyleyecek ve boşa harcanacak haftalarca emekten sizi kurtaracaktır. Merdiveni sırayla çıkın, doğrulanabilir olanı ölçün, ve her zaman en ince adaptörle başlayın.