Transfer öğrenimi nedir ve neden bu kadar yaygın?

Transfer öğrenimi, önceden geniş veri üzerinde eğitilmiş bir modelin öğrendiği temsilleri (representations) yeni bir görev için yeniden kullanma yaklaşımıdır. Pratikte bu, bir ön‑eğitimli model seçip onu kendi verinize göre uyarlamanız (fine-tuning) veya daha hafif adaptasyon teknikleriyle (ör. adapter/LoRA) “üstüne ek” yapmanız anlamına gelir. Transformer tabanlı büyük dil modelleri (LLM) ve görüntü modellerinde bu yaklaşım, sıfırdan eğitim maliyetlerini ve veri ihtiyacını azaltabildiği için standart bir iş akışına dönüşmüştür.

Bu yazı “derin öğrenme” temellerini tekrar etmekten çok, entegrasyon odağında ilerler: model seçimi, veri hazırlığı, PEFT/LoRA ile fine-tuning, doğrulama ve üretimde (serving) adapter yönetimi. LoRA/PEFT uygulama ayrıntıları için Hugging Face’in pratik rehberi ve PEFT kütüphanesi dokümantasyonu; üretim/serving tarafında ise NVIDIA NIM’in PEFT sayfası iyi başlangıç noktalarıdır (Hugging Face, PEFT repo, NVIDIA NIM).

Hangi yaklaşım: prompt, PEFT (LoRA) mı, tam fine-tuning mi?

Entegrasyon kararını basitleştirmek için şu üç seçeneği bir spektrum gibi düşünebilirsiniz:

  • Prompting / RAG (fine-tuning yok): Hızlı deneme ve düşük operasyonel yük. Ancak tutarlılık, ton ve format kontrolü sınırlı kalabilir.
  • PEFT (ör. LoRA): Modelin küçük bir bölümünü (adapter katmanları gibi) eğiterek uyarlama. Eğitim ve depolama maliyeti genellikle daha düşüktür; birden çok görev/müşteri için çoklu adapter yönetimi mümkündür (Hugging Face, PEFT repo).
  • Tam fine-tuning: Daha fazla parametre güncellendiği için daha yüksek maliyet ve daha fazla risk (overfitting, geri dönüş zor) getirebilir; bazı görevlerde daha iyi sonuç verebilir ama bunu önceden garanti etmek zordur.

Pratik kural: Üretimde hızlı iterasyon, maliyet kontrolü ve çoklu varyant ihtiyacı olan ekipler genellikle PEFT ile başlar. Yine de “en iyi” seçenek görevden göreve değişir; bu nedenle küçük ölçekli karşılaştırmalı denemeler (offline eval, pilot veya A/B testi) yapmak genellikle en güvenli yaklaşımdır.

PEFT/LoRA neden bu kadar tercih ediliyor?

PEFT (Parameter‑Efficient Fine‑Tuning) yöntemleri, eğitim sırasında güncellenen parametre sayısını azaltmayı hedefler. LoRA, bu ailenin en yaygın yöntemlerinden biridir. Rehberlerde LoRA’nın, modele ve konfigürasyona bağlı olarak güncellenen parametre sayısını ciddi biçimde düşürebildiği; bunun da GPU bellek/depolama ihtiyacını azaltmaya yardımcı olabildiği anlatılır. Sizin ortamınızdaki gerçek kazanımı, seçtiğiniz model ve veri üzerinde ölçmeniz gerekir (Hugging Face, PEFT repo).

Uçtan uca entegrasyon akışı (checklist)

Aşağıdaki akış, eğitim (fine-tuning) ve üretim (serving) tarafını birlikte düşünmenizi sağlar:

  1. Hedefi netleştir: Görev (sınıflandırma, özetleme, soru-cevap, etiketleme), çıktının formatı, kabul kriterleri.
  2. Base model seç: Lisans/erişim, dil kapsamı (Türkçe/İngilizce), bağlam penceresi, gecikme ve maliyet hedefleri.
  3. Veri hazırlığı: Temizleme, PII/özel bilgi riski, etiketleme standardı, train/validation/test ayrımı.
  4. Uyarlama stratejisi: Prompt/RAG mi, PEFT (LoRA) mı, tam fine-tuning mi?
  5. Eğitim ve izleme: Deney takibi, overfitting kontrolleri, hata analizi.
  6. Değerlendirme: Otomatik metrikler + insan değerlendirmesi + “kötü durum” testleri.
  7. Dağıtım (deploy): Adapter‑tabanlı serving mi yoksa adapter merge sonrası tek model mi?
  8. Üretim izleme: Gecikme, maliyet, kalite drift’i, geri bildirim döngüsü.

1) Doğru ön‑eğitimli modeli seçme

Model seçimi, entegrasyonun en kritik adımıdır. Sadece “en büyük model” yaklaşımı genellikle iyi bir ürün kararı değildir. Aşağıdaki sorularla başlayın:

  • Görev uyumu: Modeliniz sohbet mi yapacak, yoksa yapılandırılmış çıktı mı üretecek? (JSON gibi katı formatlar ayrı test ister.)
  • Çok dilli ihtiyaç: Ürününüz Türkçe içerik üretecek/analiz edecekse base modelin Türkçe yetkinliğini örneklerle doğrulayın.
  • Lisans ve kullanım koşulları: Modeli dağıtma, türev model üretme ve ticari kullanım şartlarını ayrıca kontrol edin. Bu yazı hukuki danışmanlık değildir.
  • Operasyon hedefleri: Hedef gecikme (latency), eşzamanlı istek, GPU/CPU altyapısı, maliyet tavanı.

İpucu: Eğer aynı base model üzerinde birden fazla görev/ürün varyantı taşıyacaksanız, adapter temelli strateji (LoRA/PEFT) hem eğitim hem dağıtım açısından esneklik sağlayabilir (NVIDIA NIM).

2) Veri hazırlığı: kalitenin büyük kısmı burada kazanılır

Fine-tuning, “veriyi modele anlatma” işidir; veriniz dağınık ise modelin davranışı da dağınık olur. Uygulanabilir bir kontrol listesi:

Veri hijyeni

  • Tekrarlı örnekler: Aynı ya da çok benzer kayıtlar, modeli dar bir kalıba sıkıştırabilir.
  • Etiket tutarlılığı: Özellikle sınıflandırmada etiket şeması sabit olmalı.
  • Format standardı: Talimat (instruction), bağlam (context) ve hedef çıktı (response) alanlarını net ayırın.

Gizlilik ve hassas içerik

Eğitim/ince ayar verisine PII veya hassas bilgi karışması ciddi uyumluluk riskleri doğurabilir. Kurum içi politikalarınıza göre veri minimalizasyonu, maskeleme/anonimleştirme ve erişim kontrolü uygulayın; gerektiğinde hukuk/uyumluluk ekipleriyle değerlendirin.

3) PEFT (LoRA) ile fine-tuning: entegrasyon mantığı

LoRA/PEFT yaklaşımında temel fikir şudur: Base model sabit kalır; modele küçük “adaptasyon” ağırlıkları (adapter) eklenir ve eğitimde esas olarak bu kısım güncellenir. Böylece:

  • Daha hızlı iterasyon (çoğu senaryoda daha az eğitim maliyeti),
  • Daha küçük dağıtım artefact’ları (adapter ağırlıkları),
  • Aynı base model üzerinde çoklu görev varyantları (farklı adapter’lar) mümkün olabilir.

Hugging Face’in LoRA/PEFT rehberi ve PEFT kütüphanesi, bu iş akışını pratik örneklerle anlatır (Hugging Face, PEFT repo).

Minimal örnek iş akışı (kavramsal)

Aşağıdaki örnek, “hangi adımlar var?” sorusunu göstermek içindir; kesin API detayları için ilgili dokümanlara bakın.

1) Base modeli ve tokenizer'ı yükle
2) PEFT/LoRA konfigürasyonunu seç (hedef katmanlar, rank vb.)
3) Eğitim verisini instruction formatında hazırla
4) Eğitim: sadece adapter parametrelerini güncelle
5) Değerlendir: validation set + özel test senaryoları
6) Adapter ağırlıklarını kaydet (base model ayrı kalır)

Ne zaman LoRA yerine farklı PEFT yöntemleri?

PEFT, LoRA ile sınırlı değildir; farklı adapter stratejileri ve teknikler vardır. Hangi yöntemin daha iyi olacağı; görev, model mimarisi ve hedef altyapıya bağlıdır. Bu nedenle PEFT kütüphanesinde desteklenen yöntemleri ve sınırlamaları inceleyip küçük karşılaştırmalar yapmak daha güvenilirdir (PEFT repo).

4) Değerlendirme: “çalışıyor mu?”dan “güvenilir mi?”ye

Bir modeli entegre ederken sadece ortalama metrikler yetmez. Aşağıdaki katmanlı yaklaşım, ürün kalitesini daha iyi korur:

A) Otomatik metrikler ve görev testleri

  • Görev metrikleri: Sınıflandırmada doğruluk/F1; üretimde gecikme ve maliyet.
  • Format uyumu: Yapılandırılmış çıktı gerekiyorsa (ör. belirli alanlar), “parse edilebilirlik” testleri.

B) Hata analizi (en yüksek kaldıraç)

  • Yanlışların kümelenmesi: belirli konu, dil karışımı, uzun metinler, jargon.
  • Prompt/format hataları: veri şemanız modelin öğrenebileceği kadar net mi?

C) Dayanıklılık ve üretim senaryoları

  • Dağılım kayması: Üretim verisi eğitim verinizden farklılaşınca performans düşebilir.
  • Güvenlik ve kötüye kullanım: Modelin istemediğiniz içerik üretip üretmediğini test edin. Bu alan kurum politikasına göre ayrıca ele alınmalıdır.

Not: Her ürün için “tek bir doğru benchmark” yoktur. Genellikle en hızlı ilerleme, hedef kullanımınızı temsil eden küçük ama iyi tanımlı bir test paketi + insan değerlendirmesi + üretim pilotu ile gelir.

5) Üretimde (serving) entegrasyon: adapter yönetimi stratejileri

Önemli: Adapter cache, dinamik adapter seçimi (multi-adapter/multi-LoRA) veya adapter merge gibi yetenekler kullandığınız serving stack’ine, sürümlere ve donanımınıza bağlıdır. Üretime çıkmadan önce kendi ortamınızda ölçerek doğrulayın (NVIDIA NIM).

Fine-tuning tamamlandığında asıl soru şudur: Bu varyantı nasıl servis edeceksiniz? PEFT/LoRA kullandıysanız iki temel yaklaşım vardır:

Yaklaşım 1: Adapter‑tabanlı serving (base + adapter)

Base model tek kopya olarak tutulur; istek başına ilgili adapter yüklenir/aktif edilir. Bu yaklaşım, çoklu müşteri/çoklu görev senaryolarında esnek olabilir. Üretimde kritik konular:

  • Adapter cache: Sık kullanılan adapter’ları bellekte tutarak gecikmeyi azaltma.
  • İstek bazlı adapter seçimi: Aynı base model üzerinde farklı adapter’ları istek bazlı seçebilme. NVIDIA NIM dokümanları bu tür üretim senaryolarına yönelik yapılandırma ve pratik notlar sağlar (NVIDIA NIM).
  • Sürümleme: Adapter’lar da model artefact’ıdır; semantik sürüm ve geri alma (rollback) planı gerekir.

Yaklaşım 2: Adapter merge (tekleştirilmiş model) ve servis

Bazı durumlarda adapter ağırlıkları base model ile birleştirilerek (merge) tek bir model artefact’ı halinde dağıtılabilir. Bu, operasyonu basitleştirebilir; ancak merge sonrası davranışın değişip değişmediğini doğrulamak gerekir. Hugging Face rehberi ve PEFT repo, adapter/merge mantığı ve pratik kullanım notları sunar (Hugging Face, PEFT repo).

Hangi serving yaklaşımı ne zaman?

Durum Adapter‑tabanlı serving Merge sonrası tek model
Birden çok görev/tenant Genellikle uygun Her varyant ayrı model olur
Basit operasyon isteği Adapter yönetimi gerekir Servis daha basit olabilir
Gecikme hassasiyeti Cache ile iyi yönetilebilir Adapter yükleme yok
Rollback/sürüm Adapter değiştirmek hızlı olabilir Model redeploy gerekebilir

Üretime hazır şablonlar: sürümleme, değerlendirme, rollback

Aşağıdaki pratik şablonlar, PEFT/LoRA ile üretilen adapter’ları “ürünleşebilir” hale getirmeye yardımcı olur. Mantık, Hugging Face PEFT iş akışına ve üretimde adapter yönetimi ihtiyacına dayanır (PEFT repo, NVIDIA NIM).

A) Önerilen adapter isimlendirme ve sürümleme

  • Base model sabit kimlik: {base_model_id}@{base_model_revision}
  • Adapter kimliği: {product_or_task}/{adapter_name}:{semver}
  • Örnek: mistral-7b-instruct@revX + support/summarize-tr:1.2.0
  • Semver yorumu:
    • MAJOR: veri şeması değişti, çıktı formatı değişti, riskli davranış değişimi
    • MINOR: yeni kapsama örnekleri eklendi, kalite arttı ama sözleşme aynı
    • PATCH: temizlik, küçük bugfix, yeniden eğitim ama davranış hedefi aynı

B) Minimal değerlendirme checklist’i (kopyala-yapıştır)

  • Görev metriği: (örn. F1 / exact match / tercih testi sonucu) → eşik: ______
  • Format uyumu: parse edilebilir çıktı oranı → eşik: ______
  • Regresyon seti: “önceki sürümde iyi olan” 50–200 örnek → yeni sürümde bozulma var mı?
  • Kötü durum testleri: uzun giriş, karışık dil, boş/eksik alan, beklenmeyen karakterler
  • Operasyon metrikleri: p50/p95 latency, GPU bellek, maliyet/istek
  • İnsan değerlendirmesi: 20–100 örnek, net rubrik (doğruluk/ton/gizlilik/uyum)

C) Basit rollback iş akışı

  1. Her deploy bir “release” olsun: release kaydı = base_model_id + adapter_id + konfig + eval özeti.
  2. Canary/pilot: Trafiğin küçük bir yüzdesi yeni adapter’a yönlendirilsin.
  3. Guardrail: Hata oranı/latency/kalite sinyali eşik aşarsa otomatik geri alma tetiklensin.
  4. Rollback adımı: Sadece adapter pointer değiştir (adapter‑tabanlı serving) veya önceki model artefact’ına geri dön (merge dağıtımı).
  5. Sonrasında: Olay kaydı + örnek toplama + hedefli veri düzeltmesi.

Uygulamada sık görülen hatalar (ve nasıl kaçınılır)

  • “Veri küçük ama olsun” yaklaşımı: Küçük veriyle fine-tuning mümkün olabilir; ancak etiket/format tutarlılığı yoksa kalite dalgalanır. Önce veri şemasını sabitleyin.
  • Değerlendirmeyi tek metriğe sıkıştırmak: Üretimde kullanıcı deneyimi, format uyumu ve hata türleri daha belirleyicidir.
  • Adapter/merge sonrası test yapmamak: Merge veya serving konfigürasyonu davranışı etkileyebilir; aynı test paketini yeniden çalıştırın (Hugging Face).
  • Üretim izlemeyi sonradan eklemek: Gecikme, maliyet ve kalite drift’i için en azından temel telemetriyi ilk günden kurun.

Hızlı başlangıç: 2 haftalık örnek plan

Gün 1–3: Hedef ve veri

  • Kabul kriterleri: 10–20 örnek üzerinden “ideal cevap” tanımı.
  • Veri şeması ve temizleme kuralları.

Gün 4–7: İlk PEFT/LoRA denemesi

  • Tek base model + 1 adapter eğitimi.
  • Validation set ile ilk kalite kontrolü.

Gün 8–10: Değerlendirme paketi

  • Hata analizi ve hedefli ek veri toplama.
  • Üretim benzeri testler (uzun girişler, karışık dil, format zorlaması).

Gün 11–14: Deploy kararı ve pilot

  • Adapter‑tabanlı serving mi merge mi kararlandırma.
  • Basit izleme + sınırlı kullanıcı pilotu.

Bu plan, “hızlı öğrenme” içindir; üretim ölçeğine geçerken güvenlik, gizlilik ve uyumluluk gereksinimleri ayrıca ele alınmalıdır.

Sonuç: En iyi entegrasyon, ölçüm ve iterasyonla gelir

Transfer öğrenimi ve ön‑eğitimli modeller, doğru tasarlanmış bir iş akışıyla hem geliştirme hızını hem de ürün kalitesini artırabilir. PEFT/LoRA gibi parametre‑verimli yaklaşımlar, özellikle iterasyon ve çoklu varyant yönetimi açısından güçlü bir pratik seçenek sunar; ancak hangi yöntemin sizin görevinizde en iyi sonucu vereceğini ancak küçük, ölçülebilir denemelerle güvenle söyleyebilirsiniz. Eğitim sonrası en az eğitim kadar önemli olan kısım ise üretimde adapter/serving stratejisi, sürümleme ve izleme disiplinidir (NVIDIA NIM).

Daha ileri okuma (opsiyonel)

Transfer/PEFT yöntemlerinin akademik tarafta nasıl evrildiğini görmek için güncel bir örnek olarak şu çalışmaya göz atabilirsiniz: arXiv:2506.17671.