DPO (Direct Preference Optimization) Nedir? RLHF'e Daha Yalın Bir Alternatif

TL;DR — DPO (Direct Preference Optimization), bir dil modelini insan tercihlerine hizalamak için ayrı bir ödül modeli ve pekiştirmeli öğrenme döngüsü kurmadan, doğrudan tercih çiftleri üzerinde bir sınıflandırma problemi çözerek çalışır. RLHF'in dört model gerektiren karmaşık boru hattına karşılık DPO yalnızca iki modelle (politika + donmuş referans) yetinir; çevrimdışı, daha stabil ve hesaplama açısından hafiftir. 2025-2026'da açık kaynak LLM'leri hizalamanın fiili standardı haline geldi. Bu yazıda DPO'nun mantığını, kayıp fonksiyonunun sezgisini, beta parametresini, tercih verisi hazırlamayı, ne zaman DPO ne zaman RLHF seçeceğinizi, tuzakları ve Türkçe bir örnek üzerinden KVKK ile EU AI Act boyutunu birlikte ele alıyorum.

Bir temel dil modelini (base model) ham metin üzerinde önceden eğittiğinizde elinizde devasa bir olasılık makinesi olur: verdiğiniz bağlama en olası devamı üretir. Ama "en olası devam" ile "insanın gerçekten istediği yanıt" aynı şey değildir. İnternetten öğrenilmiş bir model, kibar olmayı, güvenli davranmayı, talimatı takip etmeyi ya da Türkçe bir soruya Türkçe ve düzgün bir üslupla cevap vermeyi kendiliğinden bilmez. İşte bu boşluğu kapatma işine hizalama (alignment) diyoruz.

Sahada gördüğüm en yaygın yanlış anlama şu: pek çok kişi hizalamayı "biraz daha veriyle eğitmek" sanıyor. Oysa mesele modele ne söyleyeceğini değil, iki olası cevaptan hangisinin tercih edildiğini öğretmek. Denetimli ince ayar (SFT) size "şöyle cevap ver" örnekleri verir; ama insanların bir cevabı diğerine neden yeğlediğini yakalayamaz. İnsan tercihi çoğu zaman görecelidir: "Bu cevap şundan daha iyi." Hizalama tam da bu göreceli sinyali modele işlemekle ilgilidir.

"

Hizalamanın özü şudur: modele mutlak doğruları değil, insanların tercih sıralamasını öğretmek. "İyi" cevap, çoğu zaman "daha az kötü" olan cevaptır.

DPO'yu anlamak için önce onun karşısına konumlandığı yöntemi, yani RLHF'i (Reinforcement Learning from Human Feedback / İnsan Geri Bildiriminden Pekiştirmeli Öğrenme) net anlamak gerekiyor. RLHF, ChatGPT'yi ChatGPT yapan yöntem olarak popülerleşti ve klasik hâliyle üç aşamadan oluşur:

1. SFT (Denetimli İnce Ayar): Temel modeli, insanların yazdığı yüksek kaliteli talimat-cevap çiftleriyle eğitirsiniz. Çıktı, talimat takip edebilen bir başlangıç modelidir.
2. Ödül modeli eğitimi (Reward Model): İnsanlara aynı prompt için üretilmiş iki (ya da daha fazla) cevabı gösterip hangisini tercih ettiklerini işaretletirsiniz. Bu tercih verisiyle, herhangi bir cevaba bir "kalite skoru" veren ayrı bir sinir ağı eğitirsiniz.
3. RL ile optimizasyon (genellikle PPO): Politika modelini, ödül modelinden yüksek skor alacak cevaplar üretecek şekilde pekiştirmeli öğrenmeyle güncellersiniz. Aynı anda, modelin başlangıç noktasından çok uzaklaşmasını engellemek için bir KL-ceza terimi eklersiniz.

Bu boru hattının pratikte dört modeli aynı anda bellekte tutmayı gerektirdiğini fark edin: (1) eğitilen politika modeli, (2) referans/donmuş model (KL cezası için), (3) ödül modeli, (4) PPO'nun kullandığı değer/kritik (value/critic) modeli. Dört büyük modeli aynı anda GPU belleğinde döndürmek hem donanım hem de mühendislik açısından ciddi bir yüktür.

RLHF güçlüdür; iyi kurulduğunda çevrimiçi (online) örnekleme sayesinde modelin kendi ürettiği yeni cevaplar üzerinden öğrenmesini sağlar. Ama dezavantajları da nettir: kurulumu kırılgandır, PPO'nun hiperparametreleri huysuzdur, ödül modeli "hacklenebilir" (reward hacking), ve tüm sürecin stabil çalışması için ciddi bir uzmanlık gerekir. Ben bir kuruma RLHF önerirken hep şunu söylerim: "Bunu yürütecek bir MLOps olgunluğunuz yoksa, ilk denemede canınızı yakar."

2023'te ortaya çıkan DPO'nun dâhiyane sezgisi şuydu: Eğer sonunda ödül modelini politikayı eğitmek için kullanacaksak, neden ödül modelini ayrı bir adım olarak eğitelim ki? Matematiksel olarak, RLHF'in optimize etmeye çalıştığı hedef ile politikanın kendisi arasında kapalı-form bir ilişki vardır. Bu ilişkiyi kullanarak, ödül modelini tamamen ortadan kaldırıp tercih verisini doğrudan politika modelinin üzerine uygulayabiliriz.

Sonuç şaşırtıcı derecede sade: DPO, hizalamayı bir pekiştirmeli öğrenme problemi olmaktan çıkarıp bir ikili sınıflandırma problemine dönüştürür. "Bu iki cevaptan insan hangisini seçti?" sorusunu, doğrudan modelin parametreleri üzerinden bir kayıp fonksiyonuyla cevaplar.

Bu dönüşümün getirdiği pratik kazanımlar:

• İki model yeter: Eğitilen politika modeli + donmuş referans (SFT) modeli. Ödül modeli yok, kritik model yok.
• Çevrimdışı (offline): Eğitim sırasında modelden yeni cevaplar örneklemenize gerek yok. Önceden toplanmış tercih çiftleri yeter. Bu, boru hattını basitleştirir.
• Daha stabil: PPO'nun huysuz dinamikleri yerine, aşina olduğunuz denetimli öğrenme tarzı bir eğitim döngüsü.
• Hesaplama açısından hafif: Daha az model, daha az bellek, daha az kırılganlık.

"

DPO'nun en güzel tarafı, "sihirli" gelmemesidir. Bir veri bilimci ilk kez DPO eğitim döngüsünü gördüğünde "aa, bu neredeyse sıradan bir sınıflandırma eğitimi" der. İşin güzelliği tam da bu sadelikte.

DPO'nun kalbinde tek bir kayıp fonksiyonu var ve onu sezgisel olarak anlamak, formülü ezberlemekten çok daha değerli. Kabaca şöyle çalışır:

Her eğitim örneği bir üçlüden oluşur: bir prompt, insanın seçtiği (chosen) cevap ve insanın reddettiği (rejected) cevap. DPO şunu ister:

• Politika modeli, seçilen cevaba, referans modele kıyasla daha yüksek olasılık versin.
• Politika modeli, reddedilen cevaba, referans modele kıyasla daha düşük olasılık versin.

Dikkat edin: mutlak olasılık değil, referans modele göre değişim önemli. Yani "seçilen cevabın olasılığını, reddedilen cevaba kıyasla, başlangıç noktasından daha da öteye it" diyoruz. Bu göreceli çerçeve, modelin başlangıç yeteneklerinden kopmadan tercihleri öğrenmesini sağlar; referans model bir çeşit çıpa görevi görür.

Kayıp fonksiyonu, seçilen ve reddedilen cevaplar arasındaki bu "olasılık farkını" büyütmeye çalışan bir lojistik (sigmoid) kayıptır. Model seçileni reddedilenden ne kadar net ayırt ederse kayıp o kadar düşer. Bu yüzden DPO'ya "tercihler üzerinde bir sınıflandırıcı eğitmek" demek yanlış olmaz.

Beta parametresi: en kritik ayar

DPO'da ayarlayacağınız en önemli hiperparametre betadır. Beta, modelin referans modelden ne kadar uzaklaşmasına izin verildiğini kontrol eder; sezgisel olarak RLHF'teki KL-ceza katsayısının muadilidir.

Beta değeri	Ne olur	Risk
Düşük beta (ör. 0.01-0.1)	Model tercihleri agresif öğrenir, referanstan hızla uzaklaşır	Aşırı öğrenme, üslup bozulması, "unutma"
Orta beta (ör. 0.1-0.3)	Dengeli; çoğu pratik senaryonun başlangıç noktası	Genellikle güvenli aralık
Yüksek beta (ör. 0.5+)	Model referansa sıkı sıkıya bağlı kalır, temkinli öğrenir	Tercihleri yeterince öğrenememe

Sahadaki tavsiyem: beta'yı 0.1 civarında başlatın, sonra doğrulama setinizdeki tercih doğruluğuna ve modelin genel yetenek testlerine bakarak ayarlayın. Beta'yı çok düşürdüğünüzde model tercih verisine "yapışır" ve daha önce iyi yaptığı şeyleri unutmaya başlar — bunu üretimde defalarca gördüm.

DPO'nun algoritması basit; asıl zorluk veridedir. Bir DPO veri seti üç sütundan oluşur: prompt, chosen, rejected. Kulağa kolay gelir ama kaliteli tercih çiftleri üretmek bir sanattır.

Tercih çiftlerini nereden bulursunuz?

• İnsan etiketleme: En kaliteli ama en pahalı yol. Etiketleyicilere aynı prompt için iki cevap gösterip hangisini yeğlediklerini işaretletirsiniz. Türkçe içerikte iyi etiketleyici bulmak ayrı bir mesele.
• Sentetik veri (LLM-as-judge): 2025-2026'nın fiili standardı. Güçlü bir modele iki cevabı verip hangisinin daha iyi olduğunu sorarsınız; bu sıralama tercih sinyali olur. Hızlı ve ucuzdur ama yargıç modelin önyargılarını verinize taşırsınız.
• Kural tabanlı / mevcut sinyaller: Örneğin bir destek sisteminde "çözüldü" işaretlenen yanıtlar chosen, kullanıcının reddettiği yanıtlar rejected olabilir.

Kaliteli tercih verisinin altın kuralları:

• chosen ve rejected aynı prompt'a ait olmalı. Farklı prompt'lardan çift oluşturmak sinyali bozar.
• Fark anlamlı ama abartısız olsun. İki cevap arasındaki kalite farkı öğrenilebilir olmalı; ama "mükemmel cevap vs. tamamen alakasız çöp" çiftleri modele işe yaramaz kolay sinyaller verir.
• Üslup ve uzunluk yanlılığına dikkat. Etiketleyiciler (ve LLM yargıçlar) uzun cevapları körü körüne tercih etme eğilimindedir. Bunu dengelemezseniz modeliniz gereksiz uzun yazmayı öğrenir. Bu, DPO'nun en bilinen tuzaklarından biridir.
• Kapsama (coverage) önemli. Tercih verisi, üretimde göreceğiniz prompt dağılımını temsil etmeli. Aksi halde görülmemiş prompt'larda genelleme çöker.

Diyelim bir Türk bankası için müşteri hizmetleri asistanı hizalıyorsunuz. Prompt: "Kredi kartı ekstremi nasıl indiririm?" İki aday cevap düşünün:

• Seçilen (chosen): Adım adım, mobil uygulama menüsünü net tarif eden, kısa ve nazik; "başka bir konuda yardımcı olabilir miyim?" diye kapatan bir cevap.
• Reddedilen (rejected): Teknik olarak doğru ama soğuk, gereksiz jargonlu, müşteriye "ilgili sekmeye gidin" diyip bırakan bir cevap.

Bu çifti DPO'ya verdiğinizde modele "Türkçede müşteriye böyle sıcak ve yönlendirici konuşulur" sinyalini geçirmiş olursunuz. Yüzlerce böyle çiftle model, Türkçe kurumsal iletişim tonunu şaşırtıcı biçimde iyi yakalar. Ben Türkçe hizalama projelerinde en çok değeri, İngilizce ağırlıklı eğitilmiş modellere Türkçe nezaket, hitap ve resmiyet düzeyini öğretirken gördüm.

"

Türkçe hizalamada en sık atlanan nokta: "sen/siz" ayrımı, resmiyet düzeyi ve yerel bağlam. Bir model gramatik olarak doğru Türkçe kurabilir ama bir kamu kurumu chatbotunda müşteriye "sen" diye hitap ederse, teknik başarı sahada başarısızlıktır. Tercih çiftleri tam da bu inceliği öğretir.

Tercih verisi toplarken çoğu ekibin gözden kaçırdığı şey, bu verinin genellikle gerçek kullanıcı etkileşimlerinden türetilmesidir. Bir destek sohbetini, bir e-postayı ya da bir çağrı kaydını tercih çiftine dönüştürdüğünüzde, içinde kişisel veri barındıran bir eğitim seti oluşturuyorsunuz demektir. Türkiye'de bu, doğrudan KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) kapsamına girer.

Pratikte dikkat etmeniz gerekenler:

• Hukuki dayanak: Kullanıcı etkileşimlerini model eğitimi için kullanacaksanız, bunun aydınlatma metninde ve varsa açık rızada karşılığı olmalı. "Hizmet sunmak için topladım" ile "model eğitmek için kullanıyorum" farklı amaçlardır; amaçla bağlılık ilkesi devrede.
• Anonimleştirme / maskeleme: Tercih çiftlerini oluşturmadan önce ad, TCKN, telefon, IBAN, adres gibi kişisel verileri maskelemek en sağlıklısı. Anonimleştirilmiş veri KVKK kapsamı dışına çıkabilir; ama gerçek anonimleştirme (geri döndürülemezlik) ile takma adlaştırmayı (pseudonymization) karıştırmayın.
• Veri minimizasyonu: Tercih sinyali için cevabın kalitesi önemlidir, müşterinin kimliği değil. Kimlik bilgilerini eğitim setinden çıkarın.
• Saklama ve erişim: Tercih veri setine kimlerin eriştiğini loglayın; saklama süresini sınırlayın.

Avrupa Birliği Yapay Zeka Yasası (EU AI Act) aşamalı olarak yürürlüğe giriyor ve Türkiye'deki pek çok kurumu doğrudan ilgilendiriyor — çünkü AB pazarına hizmet veren ya da AB'li kullanıcılara dokunan sistemler kapsama girebiliyor. Ayrıca Türkiye'nin kendi yapay zeka düzenlemesi de bu çerçeveden besleniyor.

DPO'yu bu bağlamda salt bir performans aracı değil, aynı zamanda bir uyum kaldıracı olarak görmek gerekir:

• Yüksek riskli sistemler için AI Act, veri yönetişimi, şeffaflık ve insan gözetimi gibi yükümlülükler getiriyor. Modelinizi güvenli ve öngörülebilir davranmaya hizalamak (ör. zararlı çıktıları reddetmeyi öğretmek) bu yükümlülüklerin teknik ayağını oluşturur.
• Şeffaflık: DPO ile hangi tercih verisini kullandığınızı, hangi davranışları teşvik ettiğinizi belgelemek, denetim izini (audit trail) güçlendirir. RLHF'e göre DPO'nun sade boru hattı bu belgelemeyi kolaylaştırır.
• Genel amaçlı model (GPAM) yükümlülükleri: Bir açık modeli DPO ile hizalayıp dağıtıyorsanız, üzerine kurduğunuz katmanın davranışından siz sorumlu olursunuz.

Kurumlara hep şunu söylüyorum: hizalamayı sadece "model daha iyi cevap versin" diye değil, "model yapmaması gerekeni yapmasın" diye de tasarlayın. AI Act dünyasında ikincisi giderek daha kritik.

DPO harika ama gümüş kurşun değil. Dürüst olmak gerekirse sınırlamaları var ve bunları bilmeden üretime geçmek pişmanlık getirir:

• Sınırlı veride aşırı öğrenme (overfitting): Az sayıda tercih çiftiyle DPO, veriye yapışıp görülmemiş prompt'larda çuvallayabilir. Çevrimdışı doğası bunu şiddetlendirir; model kendi ürettiği yeni durumları görmez.
• Genelleme düşüşü: Eğitim dağılımının dışına çıkan prompt'larda DPO'nun performansı beklenenden hızlı düşebilir.
• Temsil yanlış-belirlenmesi (representation misspecification): Bazı araştırmalar, DPO'nun teorik varsayımlarının pratikte tam tutmadığını, bu yüzden belirli koşullarda PPO tabanlı RLHF'in daha güçlü kalabileceğini gösteriyor. Yani "DPO her zaman RLHF'ten iyidir" iddiası doğru değil.
• Çevrimdışı sınırı: Model eğitim sırasında kendi hatalarından öğrenemez; sadece verdiğiniz sabit çiftlerden öğrenir. Çevrimiçi RLHF bu açıdan daha zengin bir sinyal alabilir.
• Uzunluk yanlılığı: Yukarıda değindiğim gibi, dengelenmezse model gereksiz uzun cevaplar üretmeyi öğrenir.

DPO tek başına değil; onun eksiklerini kapatmak için türetilmiş bir aile var. Kısa bir yol haritası:

Yöntem	Ne getirir	Ne zaman düşünürsünüz
DPO	Tercih çiftleriyle doğrudan hizalama, iki model	Standart başlangıç noktası
IPO	DPO'nun aşırı öğrenme eğilimini regülarizasyonla dizginler	Az/gürültülü veride overfitting yaşıyorsanız
KTO	Çift yerine tekil "iyi/kötü" etiketiyle çalışır; eşleştirilmiş veri gerektirmez	Elinizde chosen/rejected çifti değil, tekil beğeni/şikayet sinyali varsa
ORPO	SFT ve tercih hizalamasını tek aşamada birleştirir; ayrı referans model bile gerektirmez	Boru hattını daha da sadeleştirmek, iki aşamayı teke indirmek istiyorsanız

Özellikle KTO Türkiye bağlamında çok işe yarar: gerçek dünyada çoğu zaman düzgün eşleştirilmiş chosen/rejected çiftiniz olmaz; elinizde sadece "bu cevap iyiydi" / "bu cevap kötüydü" gibi tekil sinyaller olur (ör. başparmak yukarı/aşağı). ORPO ise SFT + hizalamayı tek koşuda birleştirerek küçük ekiplerin işini ciddi kolaylaştırır.

En çok sorulan soru bu. Sahadaki karar çerçevem şöyle:

DPO'yu seçin, eğer:

• Elinizde (ya da üretebileceğiniz) net tercih çiftleri varsa.
• Sınırlı GPU bütçesi ve mütevazı bir ekiple çalışıyorsanız.
• Stabil, tekrarlanabilir, kolay belgelenebilir bir boru hattı istiyorsanız.
• Açık bir modeli belirli bir üsluba/göreve hizalıyorsanız (ör. Türkçe kurumsal ton).

RLHF'i (PPO) düşünün, eğer:

• Çok yüksek kaliteli, en son kırıntısına kadar optimize edilmiş bir davranış peşindeyseniz ve buna yatırım yapacak MLOps olgunluğunuz varsa.
• Çevrimiçi örneklemenin getireceği zengin sinyale ihtiyacınız varsa.
• Temsil yanlış-belirlenmesinin kritik olduğu, DPO'nun teorik varsayımlarının zayıf kaldığı bir alanda çalışıyorsanız.

Pratik tavsiyem net: Önce DPO ile başlayın. Yüzde 80 değeri, RLHF'in karmaşıklığının onda biriyle alırsınız. Ancak DPO'nun tavana vurduğunu ölçtükten sonra RLHF'e yatırım yapmayı düşünün. Ölçmeden karmaşıklığa yatırım yapmak, sahada gördüğüm en pahalı hatalardan biri.

DPO projelerinde biriktirdiğim saha notları:

• Önce iyi bir SFT modeliniz olsun. DPO, SFT'nin üzerine kurulur. Zayıf bir SFT tabanı üzerine DPO koymak, çürük temele boya çekmek gibidir.
• Referans modelinizi doğru seçin. Genelde referans = DPO'ya girdiğiniz SFT modeli. Yanlış referans, beta'nın anlamını bozar.
• Doğrulama setinizi tercih doğruluğuyla ölçün ama sadece ona bakmayın. Modelin genel yeteneklerini (özetleme, akıl yürütme, Türkçe akıcılık) ayrı test edin; hizalama bazen bu yetenekleri törpüler ("alignment tax").
• Uzunluk yanlılığını izleyin. Cevap uzunluğu dağılımını eğitim öncesi/sonrası karşılaştırın. Aniden uzadıysa alarm verin.
• beta ile learning rate'i birlikte ayarlayın. DPO learning rate'i genelde SFT'den daha düşük tutulur; agresif oranlar modeli hızla bozar.
• Sentetik tercih verisinde yargıç önyargısını denetleyin. LLM-as-judge kullanıyorsanız, yargıcın konum yanlılığı (ilk gösterilen cevabı yeğleme) gibi tuzaklarını, cevap sırasını rastgeleleştirerek dengeleyin.
• Küçük başlayın, ölçerek büyüyün. Birkaç bin kaliteli çiftle başlayıp etkiyi ölçmek, yüz binlerce gürültülü çiftle başlamaktan neredeyse her zaman daha iyidir.

Eğer bir kurumda Türkçe bir modeli hizalayacaksanız, önümüzdeki birkaç haftalık somut plan şöyle olabilir:

1. Amaç ve davranış tanımı. Modelin ne yapmasını ve ne yapmamasını istediğinizi yazılı hâle getirin. Bu, tercih verisi kriterlerinizin temeli olacak.
2. Veri kaynağı ve KVKK planı. Tercih verisini nereden alacağınıza karar verin; hukuki dayanağı, maskeleme ve saklama politikasını daha kod yazmadan netleştirin.
3. Küçük, kaliteli bir çift seti. Birkaç bin prompt/chosen/rejected üçlüsüyle başlayın. Türkçe üslup, hitap ve resmiyet düzeyini bilinçli olarak örnekleyin.
4. SFT tabanını sağlamlaştırın, sonra beta=0.1 civarında bir DPO koşusu yapın.
5. Çift eksenli değerlendirme: tercih doğruluğu + genel yetenek + güvenlik/red davranışı. Uzunluk yanlılığını ölçün.
6. Yineleyin. Zayıf kaldığı prompt tiplerini tespit edip o dağılımda yeni çiftler ekleyin. Gerekirse KTO/ORPO/IPO varyantlarını deneyin.
7. Belgeleyin. Hangi veri, hangi beta, hangi davranış hedefi — bunu AI Act ve iç denetim için kayıt altına alın.

Bu adımları izleyen ekipler, RLHF'in karmaşasına hiç girmeden, birkaç hafta içinde sahada gerçekten fark yaratan Türkçe bir asistan çıkarabiliyor. DPO'nun asıl vaadi bu: hizalamayı, seçkin araştırma laboratuvarlarının tekelinden çıkarıp, sıradan bir veri ekibinin erişebileceği bir mühendislik pratiğine dönüştürmesi.

Ekiplerle çalışırken en sık karşılaştığım itiraz şu oluyor: "Zaten SFT yaptık, cevaplar gayet güzel; DPO'ya ne gerek var?" Haklı bir soru ve cevabı hizalamanın doğasında saklı. SFT, modele taklit etmeyi öğretir: "Şu prompt geldiğinde şöyle cevap ver." Bu, modele iyi örnekler gösterir ama iki şeyi asla göremez. Birincisi, kötü örnekleri; yani "böyle cevap verme" bilgisini. SFT sadece pozitif örneklerden öğrenir, negatif sinyali yoktur. İkincisi, görecelik; iki iyi cevaptan hangisinin daha iyi olduğunu SFT ayırt edemez, çünkü ona sadece tek bir "doğru" gösterilmiştir.

DPO tam da bu iki boşluğu doldurur. Reddedilen cevabı görerek modele "bundan kaçın" der; ve seçilen ile reddedilen arasındaki farkı büyüterek göreceli tercihi işler. Sahada bunu şöyle özetliyorum: SFT modele konuşmayı öğretir, DPO ise zevk kazandırır. Bir müşteri asistanının Türkçeyi düzgün kurması SFT işidir; ama iki düzgün cümleden hangisinin müşteriyi daha rahat ettireceğini seçmesi hizalama, yani DPO işidir.

Bu yüzden pratikte ikisi birbirinin alternatifi değil, ardışık halkalarıdır: önce SFT ile temel yetkinlik, sonra DPO ile ince tercih ayarı. ORPO gibi varyantların cazibesi de buradan gelir; iki halkayı tek koşuda birleştirme vaadi.

Somutlaştırmak için tipik bir DPO koşusunu adım adım anlatayım; ilk kez kuranların kafasındaki soru işaretlerini gidermek için birebir yaşadığım akışı paylaşıyorum.

1. Veri yükleme ve biçim kontrolü. Elinizde prompt, chosen, rejected sütunlu bir veri seti var. İlk iş, sohbet şablonunu (chat template) modelinize uygun biçimde uygulamak. Türkçe projelerde en sık hatayı burada gördüm: yanlış şablon yüzünden modelin sistem mesajı ve kullanıcı mesajı karışıyor, eğitim gürültüye dönüyor.

2. Referans modelin dondurulması. SFT modelinizin bir kopyası referans olarak dondurulur; gradyan almaz, sadece olasılık hesaplar. Bellek sıkıntısı varsa, referans olasılıkları önceden hesaplayıp diske yazmak (precompute) GPU yükünü ciddi azaltır.

3. Kayıp hesabı. Her örnek için model, seçilen ve reddedilen cevaba verdiği olasılıkları, referansın verdiği olasılıklarla karşılaştırır; beta ile ölçeklenmiş fark, sigmoid kayba girer.

4. İzleme. Eğitim boyunca izlediğim üç ana metrik: seçilen cevabın ödül marjı (reward margin), seçilenin doğru sıralanma oranı (accuracy) ve seçilen/reddedilen olasılıklarının mutlak seyri. Eğer hem seçilenin hem reddedilenin olasılığı birlikte düşüyorsa, bu sağlıklı bir işarettir aslında değildir; model sadece reddedileni değil, genel akıcılığı da bozuyor olabilir. Bu incelikleri gözden kaçırmak, "eğitim düştü ama model kötüleşti" paradoksuna yol açar.

5. Erken durdurma. DPO çabuk aşırı öğrenir. Ben genelde bir-iki epok'tan fazla koşmam; doğrulama tercih doğruluğu platoya vurunca durururum.

DPO'nun en sinsi tarafı, eğitim metriklerinin iyi görünüp modelin sahada kötüleşebilmesidir. Bu yüzden çok eksenli bir değerlendirme şart. Kullandığım çerçeve:

• Tercih doğruluğu: Ayrı tutulmuş bir doğrulama setinde model seçileni reddedilenden ayırt edebiliyor mu?
• Yan-yana insan değerlendirmesi: Sınırlı sayıda gerçek promptta, DPO öncesi ve sonrası cevapları kör olarak insana kıyaslatın. Türkçe projelerde bunun yerini hiçbir otomatik metrik tutmuyor.
• Genel yetenek regresyonu: Özetleme, akıl yürütme, kod, Türkçe dilbilgisi gibi temel yetenekler hizalama sonrası düşmüş mü? Bu "alignment tax" denen bedeli ölçmezseniz farkına varmadan model körelir.
• Güvenlik ve red davranışı: Model artık zararlı taleplere hayır diyebiliyor mu, ama meşru taleplere gereksiz yere hayır demiyor mu? (Aşırı-reddetme, over-refusal, EU AI Act bağlamında da bir kalite sorunudur.)
• Uzunluk ve üslup kayması: Cevaplar aniden uzadı mı, ton değişti mi?

"Küçük bir modelde DPO işe yarar mı?" Evet, hatta küçük açık modellerde DPO'nun getirisi oransal olarak daha görünür olabilir; çünkü küçük modellerin hizalama açığı daha büyüktür. Ama küçük modelde aşırı öğrenme riski de daha yüksektir, beta'yı biraz daha yüksek tutmak isteyebilirsiniz.

"Kaç çift gerekir?" Buna kesin sayı vermek yanıltıcı olur; ama birkaç bin kaliteli çiftle anlamlı bir başlangıç yapılabilir. Kalite her zaman nicelikten önce gelir; on bin gürültülü çift, iki bin temiz çiftten daha kötü sonuç verebilir.

"Sentetik veri hile mi?" Hayır, 2025-2026 pratiğinde açık modelleri hizalamanın en yaygın yolu bu. Yeter ki yargıç modelin önyargılarını denetleyin ve nihai değerlendirmeyi insan gözüyle yapın.

"DPO'dan sonra tekrar SFT yapabilir miyim?" Teknik olarak evet ama dikkatli olun; SFT hizalamayı kısmen geri alabilir. Sıralamayı bilinçli kurgulayın.

DPO'nun en sevdiğim yanlarından biri, ekonomisinin RLHF'e kıyasla çok daha erişilebilir olması. Dört model yerine iki model tutmak, GPU bellek ihtiyacını kabaca yarıya indirir; üstelik LoRA gibi parametre-verimli yöntemlerle DPO'yu birleştirdiğinizde, orta ölçekli bir açık modeli tek bir kurumsal GPU üzerinde bile hizalamak mümkün hâle gelir. Bu, Türkiye'deki pek çok kurum için kritik bir eşik: bulut GPU maliyetleri döviz kuruna bağlı olduğu için USD bazında hızla şişer ve bütçeler zorlanır.

Bu yüzden sahada şu stratejiyi öneriyorum: tercih verinizi ve referans olasılıklarınızı önceden hesaplayıp diske yazın, eğitimi LoRA ile yapın, ve mümkünse referans modeli ayrı yükleyip bellekten tasarruf edin. Veri ikametgahı hassasiyeti olan kurumlarda (kamu, finans, sağlık) tüm bu süreci kurum içi (on-prem) donanımda yürütmek, hem KVKK'daki veri lokalizasyonu beklentileri hem de maliyet öngörülebilirliği açısından çoğu zaman en akılcı yol oluyor.

Son bir gözlem: Türkçe hizalama projelerinde asıl darboğaz nadiren GPU'dur; neredeyse her zaman kaliteli tercih verisidir. GPU'ya harcayacağınız bütçenin bir kısmını, iyi bir veri toplama ve etiketleme sürecine kaydırmak, sahada gördüğüm en yüksek getirili yatırım kararı oldu. Model mimarisiyle uğraşmak cazip gelir; ama DPO'da kazandıran şey neredeyse her zaman verinin kalitesidir.