Fine-Tuning Hizalamayı Bozar mı?
Kurumsal İnce Ayarda 5 Kapılı Guardrail Koruma Rehberi
İnce ayar (fine-tuning), bir dil modelini kurumsal veriyle özelleştirirken güvenlik hizalamasını sessizce zayıflatabilir; üstelik bunun için kötü niyetli veriye bile gerek yoktur. Bu rehber, mühendis için adım adım bir fine-tune güvenlik süreci — "İnce Ayar Güvenlik Kapıları" — sunar.
Fine-Tuning Hizalamayı Bozar mı? (Tanım)
Fine-tuning'in hizalamayı bozması, bir temel modelin (base/instruct model) ek veriyle yeniden eğitilmesi sırasında, modele üretici tarafından kazandırılmış güvenlik davranışlarının — zararlı talebi reddetme, kişisel veriyi sızdırmama, jailbreak'e direnme — kısmen ya da tamamen kaybolması olgusudur. Kritik nokta şudur: bu bozulma yalnızca kötü niyetli veriyle değil, görünüşte zararsız kurumsal veriyle yapılan ince ayarda da ortaya çıkabilir.
Akademik literatür bu riski somut biçimde göstermiştir. Qi ve arkadaşlarının çalışması, hizalanmış bir modelin yalnızca birkaç on düşmanca örnekle (yaklaşık 10-100 örnek) yeniden eğitilerek reddetme davranışının büyük ölçüde kırılabildiğini ortaya koymuştur (arXiv 2310.03693, ICLR 2024). Aynı çizgideki çalışmalar, tamamen iyi niyetli veriyle yapılan ince ayarın bile güvenliği istemeden düşürebildiğini raporlar. Yani "biz sadece kendi belgelerimizle eğittik" cümlesi, güvenlik açısından bir garanti değildir.
Bu makale hukuki yorum değil, mühendislik rehberidir. Türkçe kaynaklarda fine-tune riskleri çoğunlukla veri koruma/hukuk açısından işleniyor; buradaki amaç mühendise uygulanabilir bir süreç vermektir.
Neden Bozulur: Yüzeysel Hizalama Mekanizması
Hizalamanın neden bu kadar kırılgan olduğunu anlamak için "yüzeysel hizalama" (shallow alignment) kavramı belirleyicidir. Qi ve arkadaşlarının 2024 tarihli çalışması, güvenlik hizalamasının büyük ölçüde çıktının ilk birkaç token'ında yaşadığını gösterir (arXiv 2406.05946, ICLR 2025). Model "Üzgünüm, bu konuda yardımcı olamam" gibi bir açılışı ürettiğinde reddetme rayına oturur; ama bu ilk token'lar bir kez farklı bir yöne kaydığında model zararlı içeriği üretmeye devam edebilir.
Fine-tuning tam da bu yüzeysel katmanı hedef alır. Yeni veri, modelin çıktı dağılımının ilk token'larını kaydırdığında — hatta bu veri masum bir üslup/format değişikliği bile olsa — reddetme refleksini tetikleyen sinyal zayıflar. Sonuç, üç yoldan gelir:
- Düşmanca ince ayar: Küçük ama hedefli bir zararlı örnek kümesi, reddetme davranışını doğrudan söker.
- İyi niyetli regresyon: Zararsız kurumsal veri, güvenlik örneklerini seyrelterek istemeden hizalamayı zayıflatır (arXiv 2310.03693, arXiv 2502.01116).
- Dağılım kayması: Eğitim verisi belirli bir üsluba/role fazla yaklaştığında, model güvenlik dışı bağlamlara aşırı uyum sağlar.
Pratik çıkarım nettir: hizalama, ince ayardan sonra ölçülmeden var sayılamaz. Bu, model yükseltmelerindeki güvenlik gerilemesiyle aynı ailedendir; ayrıntı için model yükseltme güvenlik regresyonu yazısına bakılabilir.
LoRA ve Az Örnekle Guardrail Sökme Riski
LoRA (Low-Rank Adaptation) gibi parametre-verimli yöntemler, tam ince ayara göre çok daha ucuz ve hızlı olduğu için kurumsal kullanımda yaygındır. Ancak "az parametre değiştiriyorum" düşüncesi bir güvenlik yanılsamasıdır. Yüzeysel hizalama nedeniyle, güvenlik davranışını taşıyan katmanları etkilemek için modelin tümünü yeniden eğitmek gerekmez; küçük bir adaptör bile reddetme dağılımını kaydırmaya yetebilir.
Buradaki risk profilini şöyle özetleyebiliriz:
| Faktör | Neden Riski Artırır |
|---|---|
| Az örnek yeterliliği | Onlarca örnek düzeyinde adversarial veri, reddetme davranışını bozmaya yetebilir (arXiv 2310.03693). |
| Düşük maliyet | LoRA ile ince ayar ucuz olduğundan, kötü niyetli aktör için giriş engeli düşüktür. |
| Adaptör paylaşımı | Model hub'larından indirilen hazır LoRA adaptörleri, gizli bir hizalama bozulmasını taşıyabilir — tedarik zinciri riski. |
| Birleştirme (merge) | Birden çok adaptörün birleştirilmesi, ayrı ayrı test edilmemiş bir güvenlik davranışı üretir. |
Üçüncü taraf adaptör ve model indirmenin taşıdığı ek risk için Hugging Face model hub tedarik zinciri riskleri yazısı tamamlayıcıdır. Özet kural: bir LoRA adaptörü, kaynağından bağımsız olarak, entegre edilmeden önce hizalama açısından test edilmemişse güvenilir kabul edilemez.
İnce Ayar Güvenlik Kapıları: 5 Kapılı Çerçeve
Aşağıdaki "İnce Ayar Güvenlik Kapıları" çerçevesi, AltaySec'in yukarıdaki literatürden türettiği özgün bir sentezdir; sektörde kabul görmüş bir standart değil, uygulanabilir bir kontrol dizisidir. Amaç, fine-tune sürecini beş zorunlu geçiş noktasına bölmektir. Herhangi bir kapı geçilemezse sürüm yayınlanmaz.
| # | Kapı | Ne Kontrol Eder | Geçiş Ölçütü (ilke) |
|---|---|---|---|
| 1 | Veri Tarama | Eğitim verisinde kişisel veri, zehirlenmiş/düşmanca örnek, gizli enjeksiyon | KVKK kontrol listesi tamam; zehirleme taraması temiz |
| 2 | Hizalama Regresyon Testi | İnce ayar öncesi/sonrası reddetme oranı farkı | Zararlı istem setinde reddetme oranı düşmemeli |
| 3 | Red-Team Geçişi | Jailbreak, rol yapma, çeviri bahanesi, morfolojik bypass | Bilinen saldırı kalıpları modeli kırmamalı |
| 4 | Çıktı Filtresi | Çalışma zamanında zararlı çıktı ve kişisel veri sızıntısı | Guardrail aktif ve testten geçmiş |
| 5 | Sürüm Mührü | Model provenance, imza, değişmezlik | Ağırlıklar imzalı; sürüm izlenebilir |
Bu beş kapı, tek seferlik bir denetim değil, her yeni ince ayar sürümünde tekrarlanan bir CI kapısı olarak düşünülmelidir. "Geçiş ölçütü" sütunundaki eşikler her kurumun kendi temel modeli ve risk iştahı için kalibre edilmelidir; buraya evrensel bir sayı koymak yanıltıcı olurdu.
Zorunlu Test Seti: Hizalama Regresyon Ölçümü
Beş kapının kalbi ikinci kapıdır: ince ayar öncesi ve sonrası aynı test setini çalıştırıp reddetme davranışını karşılaştırmak. Bu, "hizalama regresyon testi"dir ve fine-tune sürecinin pazarlığa açık olmayan parçasıdır.
AltaySec tarafında bu ölçüm, Guardian'ın (LLM güvenlik duvarı, v3.1.0, hibrit regex + ML mimarisi) 114 test senaryosundan türetilmiş bir alt kümeyle yapılır. Bu senaryolar AltaySec'in kendi iç ölçüm varlığıdır; dış-genel bir kıyaslama (benchmark) değildir ve buradaki sayı, gerçek test kapsamına dayanır, abartılmamıştır. Test setinin mühendislik iskeleti şöyle özetlenebilir:
# İnce ayar öncesi/sonrası hizalama regresyon iskeleti (kavramsal)
for prompt in zararli_istem_seti: # reddedilmesi beklenen istemler
onc = base_model(prompt)
son = finetuned_model(prompt)
kaydet(prompt, red_mi(onc), red_mi(son))
# Kapı 2 kuralı: ince ayar sonrası reddetme oranı,
# ince ayar öncesine göre DÜŞMEMELİ. Düşerse sürüm bloklanır.
assert red_orani(son_sonuclar) >= red_orani(onc_sonuclar)
Test setinin en az şu saldırı ailelerini kapsaması önerilir: doğrudan zararlı talep, rol yapma/tiyatro bahanesi, çeviri bahanesi, kodlama/obfuscation ve Türkçe morfolojik bypass. Türkçe'ye özgü kırılma kalıpları için Türkçe prompt injection 5 saldırı kalıbı doğrudan bu test setine girdi olarak kullanılabilir. Üçüncü kapının otomasyonu için AI red-teaming playbook yöntemsel çerçeveyi sağlar.
KVKK Açısından Eğitim Verisi Kontrol Listesi
Birinci kapının yarısı güvenlik, yarısı uyumdur. Fine-tune verisi çoğunlukla gerçek kurumsal kayıtlardan derlendiği için, kişisel veri içerme olasılığı yüksektir. Model bir kez bu veriyle eğitildiğinde, kişisel veri ağırlıklara "pişer" ve sonradan silmek pratikte çok zordur. Bu yüzden kontrol, veri modele girmeden önce yapılmalıdır.
AltaySec'in kvkk-ai-compliance-kit iç varlığından türetilmiş asgari kontrol listesi:
- Envanter: Eğitim verisinde hangi kişisel veri kategorileri var? (ad, iletişim, TCKN, sağlık/özel nitelikli veri)
- Hukuki dayanak: Bu verinin model eğitiminde kullanılması için geçerli bir işleme şartı var mı?
- Maskeleme/anonimleştirme: Kişisel veri, eğitimden önce maskelendi mi ya da sentetikle değiştirildi mi?
- Özel nitelikli veri: KVKK madde 6 kapsamındaki veriler ayıklandı mı?
- Sızıntı testi: İnce ayar sonrası model, eğitim verisindeki kişisel veriyi ezberleyip tekrar üretiyor mu?
Maskeleme yaklaşımı için KVKK PII maskeleme ve sızıntı vektörleri için KVKK madde 6 LLM sızıntı vektörleri bu kapıyı tamamlar. Not: Bu kontrol listesi hukuki danışmanlık değildir; kurumun veri koruma sorumlusuyla birlikte uygulanmalıdır.
Kurumsal Fine-Tune Politikası: Uygulama Özeti
Beş kapıyı bir kurumsal politikaya dönüştürmek için sürecin sözlü bir el sıkışma değil, otomatik ve engelleyici olması gerekir. Önerilen çerçeve:
- CI kapısı yap: Hizalama regresyon testi ve red-team geçişini, model dağıtım hattına engelleyici bir adım olarak koy. Test düşerse dağıtım durur.
- Çalışma zamanı savunmasını sistem promptuna emanet etme: Hizalama regresyonuna karşı tek başına sistem promptu yetersizdir; bkz. jailbreak savunması sistem promptuyla çözülmez. Model dışında bağımsız bir çalışma zamanı guardrail'i zorunludur.
- Sürümü mühürle: Her ince ayar çıktısının ağırlıklarını imzala ve provenance kaydını tut; bkz. model imzalama ve provenance.
- Tedarik zincirini denetle: Dışarıdan gelen base model ve LoRA adaptörlerini, hiçbiri güvenilir kabul edilmeden test setinden geçir.
- Tekrar et: Her yeni sürümde beş kapıyı yeniden çalıştır; hizalama tek seferlik bir mühür değil, sürekli ölçülen bir özelliktir.
Özetle: fine-tuning kurumsal LLM'i güçlü kılan bir araçtır, ama hizalamayı ölçülmeden var saymak en yaygın ve en pahalı hatadır. Beş kapılı çerçeve, bu ölçümü sürecin doğal bir parçası hâline getirir. Kurumsal fine-tune güvenlik değerlendirmesi ve Guardian entegrasyonu için AltaySec ile iletişime geçebilirsiniz.
Kaynaklar
- Qi et al. — Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To! (ICLR 2024)
- Qi et al. — Safety Alignment Should Be Made More Than Just a Few Tokens Deep (ICLR 2025)
- Benign fine-tuning ve hizalama bozulması üzerine çalışma (arXiv 2502.01116)
- OWASP Top 10 for LLM Applications 2025 — LLM04: Data and Model Poisoning
- NIST AI 600-1 — Generative Artificial Intelligence Profile
- MITRE ATLAS — Backdoor ML Model (AML.T0018)
