LLM Fine-Tuning Rehberi: Ne Zaman Yapmalı, Nasıl Yapmalı?

LLM'ler kutudan çıktığı haliyle inanılmaz yetenekli — kod üretimi, muhakeme, çeviri, aklınıza ne gelirse. Ama şöyle bir durum var: genel amaçlı modeller, alana özgü davranışlar, özel terminoloji veya belirli çıktı formatları gerektiğinde genelde yetersiz kalıyor. İşte fine-tuning tam burada devreye giriyor. Önceden eğitilmiş bir modeli belirli bir alanda üstün performans gösterecek şekilde uyarlıyor. Ancak her zaman doğru çözüm değil. Ne zaman fine-tuning yapacağınıza, ne zaman prompt engineering ile yetineceğinize karar vermek, LLM projelerindeki en kritik kararlardan biri.

Fine-Tuning mı, Prompt Engineering mi?

Her zaman prompt engineering ile başlayın. Ciddi söylüyorum. Eğitim altyapısı gerektirmiyor, anında geri bildirim alıyorsunuz ve dakikalar içinde iterasyon yapabiliyorsunuz. Few-shot prompting, chain-of-thought reasoning ve RAG, model ağırlıklarına dokunmadan şaşırtıcı derecede fazla görevi çözebiliyor.

Fine-tuning, prompt engineering'in duvarla karşılaştığı yerde devreye giriyor. Şu durumlarda zamanı geldi diyebilirsiniz: model, ne yaparsanız yapın istediğiniz ton veya stili tutturamıyor; çıktılarınızın karmaşık, alana özgü bir şemaya uyması gerekiyor; uzun system prompt'lar gecikmeyi öldürüyor; ya da görev, base modelin bilmediği bir bilgi gerektiriyor. Sağlık ve finans gibi düzenlenmiş sektörlerde fine-tune edilmiş modeller daha öngörülebilir ve denetlenebilir çıktılar veriyor — bu da çok önemli.

• Prompt engineering prototipleme, genel görevler ve esnekliğin önemli olduğu durumlar için biçilmiş kaftan.
• Tutarlılık, derin alan bilgisi veya sıkı çıktı formatı gerektiğinde fine-tuning öne çıkıyor.
• RAG her iki yaklaşımı da tamamlıyor — yeniden eğitim yapmadan çıktıları harici bilgiye dayandırıyor.
• En iyi sonuç genelde hibrit yaklaşımdan geliyor: stil ve yapı için fine-tuning, olgusal temel için RAG.

Dataset Hazırlığı: Fine-Tuning'in Başarısını Belirleyen Şey

Fine-tuning'i başarılı ya da başarısız kılan tek bir şey varsa, o da dataset'inizdir. Özenle hazırlanmış 500-2.000 örneklik küçük ama kaliteli bir dataset, gürültülü 50.000 girişli bir dataset'i neredeyse her zaman yener. Her örnek, production'da görmek istediğiniz girdi-çıktı davranışını tam olarak yansıtmalı.

Pratikte dataset hazırlığı birkaç aşamadan geçiyor. Önce ham veriyi alan uzmanlarından, mevcut log'lardan veya sentetik üretimden topluyorsunuz. Sonra her örneği modelin beklediği instruction-response yapısına — genellikle system, user ve assistant rolleriyle bir konuşma formatına — dönüştürüyorsunuz. Son olarak kapsamlı bir deduplication ve kalite kontrolü yaparak çelişkili, eksik veya düşük kaliteli örnekleri eliyorsunuz.

1. Veri toplamaya başlamadan önce hedef görevi net tanımlayın ve edge case'leri belirleyin.
2. Örnekleri base modelin beklediği chat template'inde formatlayın (örn. ChatML, Llama stili).
3. Embedding similarity ile yaklaşık 0,95 eşiğinde deduplication yapın.
4. Dataset'i training (%85), validation (%10) ve test (%5) olarak bölün.
5. En az 100 rastgele örneği elle inceleyin — otomatik kontrollerden neler kaçtığına şaşırırsınız.

Daha güçlü bir model (GPT-4 veya Claude gibi) kullanarak küçük bir model için sentetik eğitim verisi üretmek giderek yaygınlaşıyor ve işe yarıyor. Ama model collapse'e dikkat edin — fine-tune edilmiş modeliniz görevi öğrenmek yerine kaynak modelin alışkanlıklarını tekrarlamaya başlayabilir. Sentetik verideki çeşitlilik çok önemli.

LoRA ve QLoRA: Bütçeyi Zorlamadan Fine-Tuning

Full fine-tuning modeldeki her parametreyi güncelliyor ki bu 7B'nin üzerindeki modellerde çoğu ekip için pratik olarak imkansız. LoRA (Low-Rank Adaptation) zarif bir çözüm sunuyor: tüm ağırlıkları değiştirmek yerine, orijinal parametreleri dondurarak attention katmanlarına küçük, eğitilebilir rank-decomposition matrisleri ekliyor. Sonuç? Eğitilebilir parametre sayısı %90-99 azalıyor ama adaptasyon kalitesinin büyük bölümü korunuyor.

LoRA'nın arkasındaki temel fikir şu: fine-tuning sırasındaki ağırlık güncellemeleri düşük intrinsic rank'a sahip oluyor. Güncelleme matrisini iki küçük matrise (A ve B, A x B çarpımı tam güncellemeyi yaklaşıyor) ayrıştırarak LoRA, maliyetin çok küçük bir kısmıyla full fine-tuning'e yakın performans yakalıyor. Rank parametresi (r) adaptasyonun ifade gücünü kontrol ediyor — tipik değerler 8 ile 64 arasında değişir.

from peft import LoraConfig, get_peft_model, TaskType
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto",
)

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,                          # güncelleme matrislerinin rankı
    lora_alpha=32,                 # ölçekleme faktörü
    lora_dropout=0.05,             # düzenlileştirme için dropout
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    bias="none",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# Çıktı: trainable params: 13,631,488 || all params: 8,043,223,040 || 0.17%

QLoRA bunu bir adım öteye taşıyor: LoRA adaptörlerini uygulamadan önce base modeli NF4 (NormalFloat4) veri tipi ile 4-bit'e quantize ediyor. Bu sayede 70B parametreli bir modeli tek bir 48 GB GPU'da fine-tune edebiliyorsunuz — normalde birden fazla A100 80 GB kart gerektirecek bir iş. 4-bit quantization'dan gelen kalite kaybı çok minimal; double quantization ve eğitim sırasındaki bellek sıçramalarını yöneten paged optimizer'lar sayesinde.

from transformers import BitsAndBytesConfig
import torch

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    quantization_config=bnb_config,
    device_map="auto",
)

# Kuantize edilmiş model üzerine LoRA uygula
model = get_peft_model(model, lora_config)

Hyperparameter'ları Doğru Ayarlamak

Hyperparameter'lar fine-tuning'inizi yapabilir de yıkabilir de. Learning rate açık ara en hassas parametre — LoRA için 1e-5 ile 2e-4 arasındaki değerler iyi çalışıyor, büyük rank'lar genellikle biraz daha yüksek learning rate'leri tolere ediyor. Deneyimlerime göre kısa bir warmup (toplam adımların %3-5'i) ile cosine schedule en kararlı yakınsamayı veriyor.

Batch size'ı GPU bellek sınırları içinde mümkün olduğunca büyük tutun ve gradient accumulation ile 32-128 arası effective batch size'a ulaşın. Çoğu LoRA işi 1-3 epoch'ta yakınsıyor — bunun ötesine geçerseniz büyük ihtimalle overfit ediyorsunuzdur, özellikle küçük dataset'lerde. Gradient checkpointing'i açın; eğitim süresinde ~%20'lik mütevazı bir artış karşılığında bellek kullanımını ciddi şekilde düşürür.

• Learning rate: LoRA için 1e-4 ile 2e-4 arası (full fine-tuning'den düşük).
• Effective batch size: gradient accumulation ile 32-128.
• Epoch: çoğu görev için 1-3; validation loss'u yakından takip edin.
• Max sequence length: production'daki beklenen girdi uzunluğuyla eşleştirin — padding boşa compute harcar.
• Optimizer: bellek tasarrufu için 8-bit state'li AdamW (bitsandbytes ile).
• Weight decay: regularization için 0,01.

Eğitim Sürecini Takip Etmek

Training ve validation loss eğrilerinizi şahin gibi izleyin. Training loss düşmeye devam ederken validation loss sabitlenir veya yükselmeye başlarsa, overfit ediyorsunuzdur. Weights & Biases (wandb) ya da TensorBoard'u en baştan kurun — bir şeyler ters gidene kadar beklemeyin. Her 10-20 adımda loglama, depolamayı şişirmeden yeterli detay sağlıyor.

Fine-Tune Edilmiş Modeli Gerçekten Nasıl Değerlendirirsiniz?

Fine-tune edilmiş modelleri değerlendirmek hem otomatik metrikler hem de insan yargısı gerektiriyor. Perplexity, BLEU ve ROUGE gibi metrikler sayısal bir temel veriyor ama üretim kalitesinin inceliklerini çoğu zaman yakalayamıyor. Göreve özgü metrikler — yapılandırılmış çıktılar için exact match accuracy, extraction görevleri için F1 — gerçek performans hakkında çok daha fazla şey söylüyor.

Üretici görevlerde insan değerlendirmesi hâlâ altın standart. Değerlendiricilerin hangisinin hangisi olduğunu bilmeden fine-tune edilmiş model ve base modelin çıktılarını puanladığı kör karşılaştırmalar yapın. İstatistiksel olarak anlamlı sonuçlar için beklenen girdilerin tüm yelpazesinde en az 200 değerlendirme örneği kullanın. Ve tabii ki eval set'iniz training verisinden tamamen ayrık olmalı.

Unutmayın: amaç training accuracy'yi maksimize etmek değil. Amaç, modelin production'dan gelen gerçek, daha önce görmediği girdilerde ne kadar işe yaradığını maksimize etmek. Her değerlendirme kararı bu hedefe hizmet etmeli.

• Perplexity: eğitimi takip etmek için faydalı ama farklı boyuttaki modelleri karşılaştırmak için uygun değil.
• Göreve özgü metrikler (accuracy, F1, exact match): birincil sayısal ölçütleriniz.
• İnsan değerlendirmesi: stil, ton ve açık uçlu üretim görevleri için vazgeçilmez.
• Production'da A/B testi: gerçek dünya etkisinin nihai ölçüsü.

Modeli Production'a Taşımak

Fine-tune edilmiş bir modeli deploy etmek, maliyet, gecikme ve sürdürülebilirliği doğrudan etkileyen kararlar içeriyor. LoRA adaptörlerini basitlik için base model ağırlıklarıyla birleştirebilir ya da aynı base model üzerinde farklı fine-tune varyantları arasında anında geçiş yapabilmek için ayrı tutabilirsiniz. İkinci yaklaşım, farklı müşterilerin farklı model davranışları istediği multi-tenant yapılar için çok güçlü.

Inference zamanında quantization — GPTQ, AWQ veya GGUF formatlarıyla — minimum kalite kaybıyla bellek kullanımını 2-4 kat azaltabiliyor. vLLM, TGI ve Ollama gibi serving framework'leri, continuous batching, paged attention ve speculative decoding gibi özelliklerle optimize edilmiş inference sunuyor; naif implementasyonlara kıyasla gecikmeyi %50 veya daha fazla düşürebiliyorlar.

Versiyon Kontrolü ve Tekrarlanabilirlik

Her fine-tuning çalışması tamamen tekrarlanabilir olmalı. Bu şu anlama geliyor: training dataset'ini versiyonlayın, tüm hyperparameter'ları kaydedin, kütüphane versiyonlarını sabitleyin ve adapter ağırlıklarını Hugging Face Hub veya MLflow gibi bir model registry'de saklayın. Deploy edilen her modelle birlikte training verisini, kullanım senaryolarını, bilinen sınırlamaları ve eval sonuçlarını belgeleyen bir model card göndermeyi unutmayın.

Özet

1. Prompt engineering ve RAG ile başlayın. Ancak bu yaklaşımlar yetersiz kaldığında fine-tune yapın.
2. Enerjinizi dataset kalitesine yatırın — küçük ve temiz bir dataset, büyük ama gürültülü olanı her seferinde yener.
3. LoRA ve QLoRA, kaliteden ödün vermeden tüketici donanımında fine-tuning'i mümkün kılıyor.
4. Validation loss'u dikkatle izleyin ve overfitting başlamadan eğitimi durdurun.
5. Sadece perplexity ile değil, göreve özgü metrikler ve insan değerlendirmesiyle ölçün.
6. Deployment'ı ilk günden planlayın: quantization, serving altyapısı ve adapter yönetimi sonradan düşünülecek şeyler değil.
7. Dataset'ler, konfigürasyonlar ve model artifact'ları üzerinde titiz versiyon kontrolü tutun. Gelecekteki siz bunun için teşekkür edecek.

Fine-tuning, LLM'leri belirli alanlarda gerçekten kullanışlı hale getirmek için elimizdeki en güçlü araçlardan biri. Ama düşünceli uygulanması gerekiyor. Bu yazıda ele aldığımız teknikler — LoRA, QLoRA, dikkatli dataset hazırlığı ve sistematik değerlendirme — alanın şu anki en iyi pratiklerini temsil ediyor. Bunlara hakim olursanız, herhangi bir büyük dil modelini ihtiyaçlarınıza verimli ve güvenilir şekilde uyarlamak için iyi donanımlı olursunuz.