LLM Fine-Tuning: LoRA, QLoRA, DPO ve Modern Hizalama Teknikleri — Kapsamlı Türkçe Rehber 2026

LLM'leri kendi kullanım amacınıza uyarlamak için üç ana strateji vardır: prompt engineering, RAG ve fine-tuning. İlk ikisi modeli değiştirmeden çalışırken, fine-tuning model ağırlıklarını ek eğitim ile günceller. Doğru durumda muazzam değer üretir; yanlış durumda boşa para harcanmıştır.

Ne Zaman Fine-Tuning?

Pratik karar çerçevesi:

Pratik kural. İhtiyaçların %70'i prompt engineering ile, %25'i prompt + RAG ile çözülür. Geri kalan %5 durumda fine-tuning gerçek değer üretir:

• Stil/format sabitleme — marka sesi, hukuki/tıbbi formatlar
• Yapılandırılmış çıktı garantili — her zaman geçerli JSON, XML, SQL üretmek
• Düşük gecikme + maliyet — küçük bir modeli büyük modelin davranışına yaklaştırmak (distillation)
• Domain-spesifik dil — Türkçe hukuki terminoloji, tıbbi raporlama
• Yeni davranış — agent görevleri, tool kullanımı, refleksiyon

Niye Önce RAG ve Prompt Engineering?

Fine-tuning beş yan-etkiye sahiptir:

1. Yüksek başlangıç maliyeti — GPU saatleri, veri hazırlama, eval setleri
2. Modelin "donması" — yeni model çıktığında fine-tune'unuzu yeniden yapmanız gerekir
3. Catastrophic forgetting — yanlış yapılan fine-tune, modelin başka yetkinliklerini bozabilir
4. Veri yönetimi karmaşıklığı — KVKK + telif + kalite kontrolleri
5. Eval zorluğu — fine-tune kalitesini ölçmek prompt eval'inden çok daha zor

Bu nedenle Anthropic, OpenAI ve Google'ın hepsi resmî dokümanlarında önce prompt + RAG, sonra fine-tuning sıralamasını öneriyor.

Modern bir LLM'in hayatında dört eğitim aşaması var. Her birinin amacı, veri seti tipi ve hesaplama maliyeti farklı.

Kurumsal fine-tuning genelde 4. aşamada gerçekleşir; bazen 2 + 3'ün eş zamanlı yapıldığı varyasyonlar da var (Constitutional AI, ORPO).

Supervised Fine-Tuning (SFT)

En temel form — talimat-cevap çiftleri üzerinde standart "next-token prediction" eğitimi. Çoğu kurumsal fine-tune SFT'tir; özellikle stil/format/domain bilgisi için.

Preference Optimization (Tercih Hizalama)

İnsan değerlendiriciler aynı prompt için iki cevap (A, B) görür ve hangisinin daha iyi olduğunu işaretler. Bu tercih çiftleri üzerinde model "iyi cevap" yönüne itilir. Üç ana yöntem:

• RLHF (PPO): Klasik. Bir reward model eğitilir, sonra PPO ile policy optimize edilir. Karmaşık, kaynak-yoğun.
• DPO: Reward model'i atlar; tercih çiftleri üzerinde doğrudan supervised loss. Basit, etkili, 2024'ten beri standart.
• ORPO/KTO/IPO: DPO'nun türevleri ve alternatifleri (aşağıda detaylı).

70 milyar parametreli bir modeli tam fine-tune etmek için tüm 70B ağırlığı güncellemek gerekir. Bu 800GB+ VRAM demek — yalnızca büyük araştırma laboratuvarları ulaşabilir. PEFT bu sorunu çözer: sadece küçük bir parametre kümesini günceller.

PEFT ailesinin üyeleri:

• LoRA (Low-Rank Adaptation) — en yaygın
• QLoRA — LoRA + quantization
• AdaLoRA — uyarlanabilir LoRA rank
• IA-3 — sadece bias terimleri
• Prefix Tuning — input embed'lerine prefix ekler
• Prompt Tuning — sadece soft prompt eğitir
• DoRA (Weight-Decomposed LoRA) — 2024 yeni
• MoRA (High-Rank Updating) — 2024 yeni

2021'de Microsoft araştırmacılarının (Hu et al.) yayınladığı LoRA, modern fine-tuning'in altın standardı haline geldi.

4.1. Matematiksel Temel (Kısa)

Tam fine-tuning'de bir weight matrisi W (örn. 4096×4096) doğrudan güncellenir: W_new = W + ΔW. LoRA varsayımı: ΔW aslında düşük-ranklı olabilir.

LoRA, ΔW'yi iki küçük matrisin çarpımı olarak ifade eder:

ΔW ≈ B × A
B: 4096 × r
A: r × 4096
r << 4096 (genelde 4, 8, 16, 32, 64)

Eğitim sırasında sadece A ve B güncellenir — orijinal W dondurulur. Inference'ta W + B × A hesaplanır (veya merge edilir).

4.2. LoRA Hiperparametreleri

Rank (r) — LoRA matrislerinin boyutu. Yaygın değerler: 8 (varsayılan), 16, 32, 64. Daha yüksek rank = daha çok parametre, daha fazla kapasite, ama overfitting riski.

Alpha (α) — scaling factor. ΔW_effective = (α/r) × B × A. Pratik tavsiye: α = 2r (örn. r=16 ise α=32).

Target modülleri — Hangi katmanlarda LoRA uygulanacak? Yaygın seçenekler:

• q_proj, v_proj — sadece attention sorgu ve değer (en minimal)
• q_proj, k_proj, v_proj, o_proj — tüm attention
• q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj — attention + MLP (en kapsamlı)

Pratik tavsiye. Tüm linear katmanlar (attention + MLP) en iyi sonucu verir. Sadece attention'da LoRA, çoğu görevde %5-10 kalite kaybına neden olur.

4.3. Tam Fine-Tuning ile Karşılaştırma

LoRA'nın küçük çıktısı (50MB-1GB) özellikle değerli — bir model üzerinde 10 farklı LoRA adapter çalıştırabilir, runtime'da hızla geçiş yapabilirsiniz.

2023'te Dettmers ve arkadaşlarının yayınladığı QLoRA, LoRA'yı quantization ile birleştirerek 70B modelleri tek bir A100 GPU'da eğitilebilir hale getirdi. Kişisel ve küçük ekip fine-tuning ekosisteminin patlamasının ana motoru.

5.1. Üç Ana Bileşen

4-bit NF4 (Normal Float 4) quantization. Model ağırlıkları 16-bit yerine 4-bit'te saklanır. NF4, standart 4-bit'ten daha doğru — normal dağılımlı verilere optimize.

Double Quantization (DQ). Quantization sabitlerini de quantize ederek ek bellek tasarrufu.

Paged Optimizers. Optimizer state'i RAM ile GPU arasında sayfa-sayfa hareket ettirir; OOM (out of memory) hatalarını azaltır.

5.2. QLoRA ile Pratik Maliyet (2026)

Bu maliyetler sadece eğitim aşaması. Veri hazırlama, eval, iterasyonlar genelde 2-5x toplam maliyete katkı yapar.

2023'te Rafailov ve arkadaşlarının yayınladığı DPO, klasik RLHF/PPO'nun yerine çok daha basit bir matematiksel formülasyon önerdi. 2024-2026 dönemi modern alignment standardı haline geldi.

6.1. PPO (Klasik RLHF) vs DPO

6.2. DPO Veri Seti Yapısı

DPO için ihtiyacınız olan: chosen/rejected çiftlerinden oluşan dataset.

{
  "prompt": "Müşteri şikayetine nasıl yanıt verirsin?",
  "chosen": "Empatik, çözüm-odaklı, kısa ve net bir yanıt...",
  "rejected": "Defansif, jenerik, çok uzun bir yanıt..."
}

Genelde 500-5.000 tercih çifti yeterli; veri kalitesi miktardan kat kat önemli.

6.3. DPO Türevleri (2024-2026)

DPO'nun yayınlanmasından sonra birçok türev önerildi:

• ORPO (Odds Ratio Preference Optimization) — SFT ve preference optimization'ı tek adımda yapar. Hong et al. (2024).
• KTO (Kahneman-Tversky Optimization) — Tercih çiftleri yerine tek-cevap ödül/ceza sinyalleri kullanır. Ethayarajh et al. (2024).
• IPO (Identity Preference Optimization) — DPO'nun aşırı uyum (overfitting) sorununa karşı regularization. Azar et al. (2023).
• CPO (Contrastive Preference Optimization) — Daha güçlü reject sinyali ile DPO. Xu et al. (2024).
• simPO (Simple Preference Optimization) — Reference model'i atlar, basitleştirir. Meng et al. (2024).

Sıfırdan başarılı bir fine-tune için 7 aşamalı pipeline:

7.1. Eğitim Framework'leri

Pratik seçim. Geliştirici/araştırmacı için Unsloth (hız + kolaylık). Üretim ekibi için LLaMA Factory (geniş kapsam). Cloud kolaylığı için Together veya Modal. Hassasiyet/uyum kritik kurumsal için Axolotl + self-hosted GPU.

7.2. Veri Hazırlama — Görünmez Başarı Faktörü

Veri kalitesi, fine-tune sonucunun %70'ini belirler. Eğitim sadece son adımdır. Pratik tavsiyeler:

• Manuel etiketleme > sentetik kalite açısından, ama maliyet 10-50x
• Sentetik veri için yaygın yöntem: GPT-5 veya Claude Opus 4.7 ile büyük bir modele "öğretici" rol vererek küçük modele örnek üretmek
• Self-Instruct — modeli kendi örneklerinden öğretme (Stanford 2022)
• DataDreamer, Distilabel, Lilac gibi modern veri-hazırlama framework'leri
• Veriyi eval setinden ayır — eğitim verisinden sızıntı olmasın
• Class balance — kategorilerin dengeli temsil edilmesi

Türkçe LLM fine-tuning'in global rehberlerde olmayan 5 kritik nüansı:

8.1. Tokenizer Verimi

Türkçe morfolojik zenginlik nedeniyle tipik tokenizer'da bir kelime 2-5 token'a parçalanır. Bu fine-tuning'de:

• Sequence length 2x kullanılır (aynı içerik için)
• Eğitim maliyeti %30-50 yüksek
• Context window'a daha az içerik sığar

Çözüm: Türkçe-özel tokenizer (BERTurk gibi) veya Türkçe vocabulary extension. Llama, Mistral gibi modeller için BPE vocab'a 3K-5K Türkçe token eklemek, Türkçe verimliliği %30-50 artırır.

8.2. Türkçe Veri Seti Kaynakları

• Belebele Turkish — Türkçe okuma anlama
• Cosmos QA TR — sosyal akıl yürütme
• xCOPA Turkish — nedensel akıl yürütme
• WMT translation pairs — Türkçe-İngilizce çiftler
• Wikipedia Turkish — genel bilgi
• MultiWOZ TR — diyalog
• Hugging Face Turkish datasets — 100+ açık veri seti
• Cezeri instruction tuning data — Türkçe instruct
• Kurumsal veri — sizin domain veriniz (en değerli)

8.3. Base Model Seçimi (Türkçe için)

Pratik tavsiye. Domain-genel Türkçe instruction-tune için Qwen 2.5 14B veya Llama 4 8B en iyi başlangıç. Türkçe NLP özel (sınıflandırma, NER) için BERTurk.

8.4. Türkçe Stil Sabitleme

Türkçe'de "siz" / "sen" ayrımı, ton (formal/samimi/resmî), Anadolu/İstanbul dialektleri, devrik vs düz cümle tercihleri — bunlar fine-tune'da kontrol edilmelidir. Eğitim verisini bir editör ile kalite kontrolden geçirmek şart.

8.5. Domain-Spesifik Türkçe Örnekleri

• Türk hukuk — TBK, TMK, KVKK metinleri + emsal davalar
• Türk vergi — VUK, KDV, GVK + örnek olaylar
• Sağlık — Türkçe tıbbi raporlar (anonim)
• E-ticaret — Trendyol, Hepsiburada gibi platformlardan ürün verisi
• Bankacılık — BDDK düzenlemeleri + müşteri etkileşim örnekleri

9.1. GPU Seçimi (2026)

9.2. Bulut Platformları

• Modal — Python-native, anlık GPU, kullandığın kadar öde. Hızlı prototip için ideal.
• RunPod — En ucuz spot fiyatları. Geliştirici dostu.
• Together AI — Managed fine-tuning + inference, kolay.
• Replicate — Hazır fine-tune template'leri.
• AWS SageMaker / GCP Vertex AI / Azure ML — Kurumsal ortam, ama daha pahalı.
• Lambda Cloud — On-demand H100/H200 erişimi.

9.3. Tipik Maliyet Senaryoları

• Türkçe stil hizalama, Llama 4 8B QLoRA, 5K örnek: ~$15-40 eğitim + ~$50-100 veri hazırlık + ~$30 eval = ~$100-200 toplam
• Domain-özel Mistral Small 3 fine-tune, 20K örnek: ~$80-200 eğitim + ~$300-800 veri + ~$100 eval = ~$500-1.200
• Llama 4 70B QLoRA, 50K örnek + DPO ekleme: ~$300-600 eğitim (2 fazda) + $1.000-3.000 veri + $200-500 eval = ~$2.000-5.000

Hatırlatma: Veri hazırlık + eval maliyetin %60-70'ini oluşturur. GPU saatleri en küçük kalemdir.

Vaka 1 — Türk Bankası: Türkçe Hukuki Belge Asistanı

Problem. Bankanın hukuk ekibi sözleşme analizinde GPT-5'i kullanıyordu ama Türk hukukunun spesifik dilini (TBK, TMK referansları, mahkeme jargonu) yeterince yakalayamıyordu.

Çözüm. Llama 4 70B üzerinde QLoRA fine-tune:

• Veri: 8.000 anonim sözleşme + 3.000 Türk yüksek mahkeme kararı + 2.000 hukuki Q&A çifti
• Yöntem: SFT + DPO (avukatlar 1.500 cevap çiftinde değerlendirme yaptı)
• Süre: 6 hafta (veri 4 hafta, eğitim + eval 2 hafta)
• Maliyet: ~$8.000 (veri etiketleme dahil)

Sonuç. Türk hukuk terminolojisinde doğruluk %72'den %91'e çıktı. Sözleşme analizi süresi avukat başına haftalık 14 saatten 5 saate düştü.

Vaka 2 — E-Ticaret: Kategori Sınıflandırma + Açıklama Üretimi

Problem. Yeni eklenen ürünler için manuel kategori seçimi + Türkçe açıklama yazımı saatler alıyordu. GPT-4o-mini ile prompt engineering yetersizdi (kategori taxonomy çok büyük: 12.000 alt-kategori).

Çözüm. Qwen 2.5 14B QLoRA fine-tune:

• Veri: 250.000 mevcut ürün (ad + açıklama → kategori + tag + SEO-uyumlu açıklama)
• Yöntem: SFT (DPO gerek görülmedi)
• Eğitim: 2 adet A100 80GB, 18 saat
• Maliyet: ~$1.200

Sonuç. Kategori sınıflandırma doğruluğu %78'den %96'ya. Yeni ürün başına ortalama insan müdahale süresi 15 dakikadan 1 dakikaya. Aylık 80K ürün işleyişinin maliyeti ChatGPT API'sine kıyasla %90 azaldı (self-hosted Qwen + LoRA).

Vaka 3 — Sağlık Teknolojisi: Tıbbi Rapor Yapılandırma

Problem. Klinik notların yapılandırılmış formata (ICD-10 kodları, tanı + tedavi + ilaç) dönüştürülmesi GPT-5'te %80 doğrulukta kalıyordu; sağlık sektörü %95+ talep ediyor.

Çözüm. Mistral Small 3 ORPO ile fine-tune:

• Veri: 15.000 anonim klinik not + uzman doktor onaylı yapılandırılmış output
• Yöntem: ORPO (SFT + DPO tek aşamada)
• KVKK önlemleri: Tüm hasta verisi anonimleştirildi; eğitim on-prem yapıldı; eval audit log'lu
• Maliyet: ~$3.500 (anonim doktor etiketleme dahil)

Sonuç. Tıbbi yapılandırma doğruluğu %97. KVKK ve sağlık regülasyonu uyumu sağlandı. Türk sigorta şirketleri ile B2B entegrasyona açıldı.

11.1. "Fine-Tune Önce, Soruları Sonra Sor"

En yaygın hata. Önce prompt + RAG eval'i yapın; fine-tune'a koşmadan önce o iki katmanın ne kadar başarılı olduğunu bilin.

11.2. Az Veri ile Eğitim

500'den az örnekle stil fine-tune yapmaya çalışmak. Genelde başarılı olmaz. Minimum 1.000 yüksek-kalite örnek; ideal 5.000-10.000.

11.3. Catastrophic Forgetting

Yanlış learning rate (çok yüksek) veya çok fazla epoch (3+) modelin temel yetkinliklerini bozar. Eğitim sırasında eval seti üzerinde genel benchmark performansını da takip edin.

11.4. Test Seti Sızıntısı

Eğitim verisinin bir kısmı eval setine geçerse, fine-tune skoru yapay olarak yüksek görünür ama üretimde başarısız olur. Veriyi temizlik aşamasında ayır, eğitim sırasında karıştırma.

11.5. KVKK Uyumsuz Veri

Müşteri/çalışan kişisel verisi içeren prompt'larla fine-tune yapmak. KVKK ihlali + öğrenilen kişisel veri model ağırlıklarına gömülür. Anonimleştirme her zaman şart.

11.6. Versiyonlama Yok

Fine-tune adapter'larını ve veri setlerini versiyonlamamak. HF Hub, W&B, MLflow ile her eğitim experiment'ini izleyin.

11.7. Eval'siz Üretim

"Loss düştü, çalışıyor" deyip canlıya almak. Loss eval değildir; gerçek görev başarısını eval setiyle ölçün.

11.8. Yanlış Base Model Seçimi

Türkçe gerektiren göreve sadece-İngilizce model fine-tune etmeye çalışmak. Base model zaten Türkçe biliyor olmalı; fine-tune onu domain'inize uyarlar, sıfırdan Türkçe öğretmez.

Distillation — büyük bir modelin (öğretmen) çıktısı ile küçük bir modeli (öğrenci) eğitme. Yaygın fine-tuning kalıbı:

1. Büyük model (Claude Opus 4.7) ile sentetik veri üret
2. Küçük modeli (Llama 4 8B) bu veriyle SFT et
3. Küçük model = ucuz + hızlı + büyük modelin %85-90 kalitesinde

Bu yaklaşım, 2025-2026'nın en pratik fine-tuning kalıbı haline geldi — verisini insan etiketlemeyle hazırlamadan kalitesi yüksek fine-tune yapmanın yolu.

• Synthetic data dominance — insan etiketlemesi yerine GPT-5/Claude/Gemini ile veri üretme
• Distillation everywhere — frontier modellerden küçüklere bilgi aktarımı
• Self-Reward modeli — modelin kendi cevaplarını değerlendirip kendine eğitim verisi üretmesi
• Verifier modeller — fine-tune sonucu otomatik kalite kontrolü
• RLAIF (RL from AI Feedback) — insan yerine başka bir AI'ın tercihleri
• Continual learning — modelin sürekli güncellenmesi (catastrophic forgetting'i önleyerek)
• PEFT yeni teknikler — DoRA, MoRA, LoftQ; LoRA'nın kalitesini artıran 2024-2025 yenilikleri

Fine-tuning yaparken kişisel veri içeren eğitim seti kullanmak özel dikkat gerektirir.

14.1. Riskler

• Veri modele gömülür — fine-tune sonrası modelden bu veriyi "silme" pratik olarak imkansızdır
• Membership inference saldırısı — model çıktısından eğitim verisi üyeliği tespit edilebilir
• Veri sızıntısı — model bazen eğitim verisini neredeyse aynen üretir

14.2. Korunma Yöntemleri

1. Anonimleştirme — TC, ad, telefon, e-posta gibi PII çıkar
2. Differential privacy — eğitime gürültü ekle (kalite vs gizlilik dengesi)
3. Federated learning — veriyi merkezîleştirmeden eğit (gelişmiş)
4. Veri yerleşimi — Türkiye veya AB-içi GPU'larla eğit
5. Audit log — hangi veri hangi eğitimde kullanıldı

14.3. EU AI Act Açısından

Fine-tune edilen model yüksek risk kategorisinde ise (kredi skoru, İK seçimi vb.):

• Teknik dokümantasyon (Annex IV)
• Eğitim verisi yönetişimi
• Risk değerlendirmesi
• İnsan denetimi
• Uyum değerlendirmesi (conformity assessment)

Detay için sitedeki KVKK + EU AI Act + ISO 42001 Uyum Rehberine bakın.

Şirketinizde LLM fine-tuning stratejisi geliştirmek veya mevcut bir fine-tune'u üretim kalitesine taşımak için:

1. Fine-Tune Use-Case Değerlendirmesi. Gerçekten fine-tune gerekli mi? RAG/prompt yeterli mi? Yatırım hesabı + 4 saatlik atölye.
2. Veri ve Pipeline Kurulumu. Türkçe veri toplama, etiketleme stratejisi, eğitim platformu seçimi, eval harness — uçtan uca pipeline tasarımı.
3. Production Fine-Tune Audit. Mevcut fine-tune'unuz varsa: kalite, KVKK uyumu, maliyet, observability açısından 360° denetim.

İletişim için site üzerindeki contact formunu kullanabilirsiniz.

Bu rehber yaşayan bir belgedir; fine-tuning ekosistemi (yeni yöntemler, framework'ler, base model'ler) her çeyrek değiştiği için çeyreklik olarak güncellenmektedir.