Aşırı Red (Over-Refusal) Nedir? Türkçe'de Modeller Neden Masum Soruyu Reddediyor
Hem fazla reddeden hem az yakalayan guardrail'ler
Bir dil modelinin zararlı bir talebi reddetmesi tasarım gereğidir; ama tarifsiz bir yemek sorusunu, tarihi bir olayı ya da güvenlik farkındalığı eğitimini "riskli" sayıp geri çevirmesi bir güvenlik başarısı değil, bir kullanılabilirlik arızasıdır. Türkçe'de bu arıza, İngilizce'ye kıyasla belirgin biçimde büyüyor.
Over-Refusal (Aşırı Red) Nedir?
Over-refusal (aşırı red), bir yapay zeka dil modelinin gerçekte zararsız ve meşru bir talebi, güvenlik politikasını fazla geniş uyguladığı için hatalı biçimde reddetmesidir. Teknik terimle bu, modelin güvenlik katmanının ürettiği bir yanlış pozitiftir: sistem, ortada bir tehdit yokken tehdit olduğunu varsayar ve cevabı bloke eder. Klasik örnekleri şunlardır: bir kimya öğretmeninin ders için sorduğu reaksiyon denklemi, tarihsel bir çatışmanın nedenlerini soran bir öğrenci, siber güvenlik farkındalığı için oltalama (phishing) e-postasının nasıl tanınacağını öğrenmek isteyen bir çalışan ya da bir romanda geçen gerilim sahnesini yazdırmak isteyen bir yazar.
Aşırı red, jailbreak veya prompt injection gibi bir saldırı değildir; modelin kendi savunmasının yan etkisidir. Bu yüzden çoğu kurum onu görmezden gelir: sistem "güvenli" görünür çünkü hiçbir zararlı çıktı üretmez. Oysa aşırı red, ölçülebilir bir maliyettir. Kullanıcı asistana güvenini kaybeder, meşru iş akışları tıkanır ve ekipler modeli tamamen devre dışı bırakıp gölge yapay zeka (shadow AI) kullanımına yönelir. Güvenlik mühendisliğinde doğru çerçeve, red oranını sıfıra indirmek değil, zararlıyı reddederken zararsıza izin veren dengeyi kurmaktır.
Bir Model Masum Soruyu Neden Reddeder?
Aşırı red tek bir nedenden doğmaz; birbirini besleyen birkaç mekanizmanın toplamıdır:
- Aşırı geniş güvenlik hizalaması: Modeller, eğitim sırasında zararlı çıktılardan kaçınmak için ödüllendirilir. Bu sinyal fazla agresif verildiğinde, model "emin değilsem reddet" davranışını öğrenir. Ret, cezalandırılmadığı için güvenli bir varsayılan hâline gelir.
- Anahtar kelime ve yüzey örüntüsü tetikleyicileri: Guardrail katmanları çoğu zaman anlam yerine yüzey örüntülerine bakar. "Patlama", "silah", "zehir", "virüs" gibi kelimeler bağlamdan koparılıp tek başına risk sinyali sayıldığında, bir yemek tarifi ya da bir yazılım hata ayıklama sorusu masum olmasına rağmen reddedilir.
- Bağlam körlüğü: Model, talebin ardındaki niyeti (eğitim, kurgu, savunma amaçlı analiz) çözemediğinde en temkinli yolu seçer. Meşru bir güvenlik araştırmacısı ile kötü niyetli bir aktör aynı cümleyi kurabilir; model ikisini ayırt edemeyince ikisini birden reddeder.
- Sistem promptu ve politika katmanlarının üst üste binmesi: Uygulama katmanındaki ek güvenlik talimatları, modelin kendi hizalamasıyla çakışıp toplam hassasiyeti artırır. Her katman "biraz daha temkinli" olduğunda sonuç, katlanan bir aşırı temkinliliktir.
Bu mekanizmaların ortak paydası şudur: red kararı, gerçek riskin değil, modelin belirsizlik altındaki varsayılan davranışının ürünüdür. Belirsizlik ne kadar artarsa, red o kadar olasıdır.
Türkçe'de Uçurum Neden Büyüyor?
Aşırı red her dilde görülür; ancak Türkçe'de birkaç yapısal etken sorunu derinleştirir. İngilizce over-refusal literatürü olgunlaşırken (aşağıda OR-Bench'e değineceğiz), Türkçe tarafı hem veride hem ölçümde geride kalıyor.
- Düşük kaynak dengesizliği: Modellerin güvenlik hizalaması ağırlıklı olarak İngilizce veriyle yapılır. Türkçe'de niyet-bağlam ilişkisini öğrenmek için görülen örnek sayısı çok daha azdır; model belirsizlik altında kaldığında red tarafına daha kolay kayar.
- Morfolojik zenginlik: Türkçe eklemeli bir dildir; tek bir kök çok sayıda çekimli biçime bürünür. Yüzey örüntüsüne dayanan bir filtre, aynı masum kelimenin onlarca çekimini ya kaçırır ya da fazladan riskli sayar. Bu, aynı zamanda morfolojik bypass saldırılarının da zeminidir.
- Kültürel ve deyimsel bağlam: Türkçe deyimler ve mecazlar ("kafasına silah dayamak", "birini gömmek", "bombalamak") gündelik dilde tamamen zararsız anlamlarda kullanılır. Bağlamı çözemeyen bir guardrail bunları harfi harfine yorumlayıp reddeder.
- Çeviri köprüsünün kaybı: Türkçe talep önce İngilizce'ye çevrilip işlendiğinde, hem niyet sinyali bozulur hem de çeviri sırasında oluşan tuhaflıklar ek belirsizlik yaratır. Sonuç yine temkinli varsayılana, yani redde çıkar.
Bu etkenler tek yönlü değildir: aynı körlük, modelin gerçek Türkçe saldırıları kaçırmasına da yol açar. Yani sorun "model çok katı" ya da "model çok gevşek" ikileminden ibaret değil; model Türkçe'de yanlış yerlerde katı ve gevşek oluyor.
İki Eksenli Ölçüm: Aynı Anda Hem Fazla Red Hem Az Yakalama
Aşırı red genellikle tek başına, güvenlik açığından bağımsız ölçülür. Oysa bu iki olgu aynı madalyonun iki yüzüdür. AltaySec'in guardrail-arena ölçütü, bu yüzden Türkçe ve İngilizce guardrail'leri iki eksende birden değerlendirir: (1) masum ama tetikleyici görünen talepleri ne sıklıkla reddettiği (aşırı-red ekseni) ve (2) gerçek zararlı talepleri ne oranda kaçırdığı (yetersiz-yakalama ekseni).
AltaySec'in guardrail-arena değerlendirmesinde, masum ama tetikleyici Türkçe promptlardan oluşan turkish-over-refusal-set üzerinde ölçülen aşırı-red oranı, modele göre yüzde 25 ile yüzde 70 arasında değişti. Aynı guardrail'lerin, aynı değerlendirmede Türkçe saldırıların yüzde 83'ünü kaçırdığı görüldü. Bu iki bulguyu yan yana koyduğumuzda ortaya çıkan tablo çarpıcıdır: Türkçe'de guardrail'ler eş zamanlı olarak hem fazla reddediyor hem az yakalıyor. Yani harcanan "katılık" bütçesi yanlış hedeflere gidiyor; sistem masum kullanıcıyı engellerken gerçek saldırganın önünü açık bırakıyor.
| Eksen | Ne ölçer | Sağlıklı hedef | guardrail-arena değerlendirmemizdeki Türkçe tablo |
|---|---|---|---|
| Aşırı-red (yanlış pozitif) | Masum talebin hatalı reddi | Mümkün olduğunca düşük | Yüksek: yüzde 25–70 aralığı |
| Yetersiz-yakalama (yanlış negatif) | Gerçek saldırının kaçırılması | Mümkün olduğunca düşük | Yüksek: saldırıların yüzde 83'ü kaçtı |
Not: Yukarıdaki yüzde 25–70 ve yüzde 83 değerleri AltaySec'in kendi guardrail-arena ölçümüdür; evrensel, dış bir gerçek değil, belirli bir değerlendirme kümesi üzerinde alınan sonuçtur. Yine de bilinen ölçümler arasında Türkçe aşırı-red uçurumuna iki eksenli olarak bakan az sayıda çalışmadan biridir; İngilizce tarafın yerleşik ölçütü OR-Bench iken, Türkçe için yayımlanmış eşdeğer bir benchmark henüz yok.
İngilizce'nin OR-Bench'i Var, Türkçe'nin Boşluğu
Aşırı red, akademik olarak tanımlı ve ölçülebilir bir olgudur. İngilizce tarafın yerleşik referansı OR-Bench'tir: yaklaşık 80 bin prompt ve 10 kategoriden oluşan, modellerin aşırı reddetme davranışını sistematik biçimde ölçen bir benchmark'tır (Cui ve ark., 2025). OR-Bench, "masum ama tetikleyici" prompt kavramını nicel bir zemine oturtur ve modelleri kullanılabilirlik açısından karşılaştırılabilir kılar.
Türkçe tarafta ise durum farklıdır. Yaptığımız taramada, Türkçe aşırı-red uçurumunu ölçen yayımlanmış bir benchmark bulunamadı; mevcut Türkçe kaynaklar ağırlıklı olarak yetenek ölçümüne (örneğin TR-MMLU) odaklanıyor, güvenlik-kullanılabilirlik dengesine değil. Bu boşluk, guardrail-arena ve turkish-over-refusal-set gibi Türkçe-öncelikli araçların neden önemli olduğunu gösteriyor: ölçemediğiniz bir arızayı iyileştiremezsiniz. Türkçe'de aşırı red görünmez kaldığı sürece, kurumlar sistemlerini "güvenli" sanıp aslında hem kullanıcıyı hem güvenliği kaybetmeye devam eder.
Bu veri motorunun bir parçası olan Türkçe saldırı ve niyet korpusları hakkında daha fazla ayrıntı için AltayDuel Türkçe prompt injection veri seti yazımıza bakabilirsiniz.
Kullanılabilirlik–Güvenlik Skoru: Tek Sayıya İnmemek
Aşırı red tartışmasının en yaygın hatası, tek bir sayıya (red oranı ya da bloke oranı) bakıp karar vermektir. Bir modelin red oranını sıfıra çekmek onu güvensiz, bloke oranını yükseltmek ise kullanılamaz hâle getirebilir. Doğru ölçü, iki ekseni birlikte gösteren bir kullanılabilirlik–güvenlik skorudur: sistem, zararsız talepleri ne kadar az reddederken zararlı talepleri ne kadar çok yakalıyor?
Kurumsal bir dağıtımda bu dengeyi kurmak için pratik prensipler:
- Niyet temelli değerlendirme: Kelime örüntüsü yerine talebin bağlamını ve niyetini değerlendiren katmanlar kullanın. Aynı cümlenin eğitim mi, kurgu mu, yoksa gerçek zararlı istek mi olduğunu ayırt eden bir mantık, hem aşırı reddi hem kaçırmayı azaltır.
- Türkçe'ye özel test kümesi: İngilizce test setlerini çevirip kullanmak yeterli değildir. Morfolojik çekimleri, deyimsel kullanımları ve kültürel bağlamı içeren Türkçe'ye özgü kümelerle ölçüm yapın.
- Çift eksenli izleme: Üretimde yalnız engellenen saldırıları değil, reddedilen meşru talepleri de kayda alın. Aşırı red görünmez bir maliyet olduğu için ölçülmediği sürece büyür.
- Katman sadeleştirme: Üst üste binen güvenlik talimatları hassasiyeti şişirir. Politika katmanlarını konsolide edin ve toplam katılığı tek noktadan yönetin.
Çalışma zamanı guardrail tasarımının genel ilkeleri için çalışma zamanı LLM guardrail'leri yazımız ayrıntılı bir çerçeve sunuyor.
Kurumsal Etki ve Guardian ile Dengeleme
Aşırı red, kurumsal yapay zeka dağıtımlarında sessiz bir başarısızlık modudur. Bir müşteri hizmetleri asistanının meşru bir iade talebini "riskli" sayıp reddetmesi, bir sağlık asistanının bilgilendirici bir soruyu geri çevirmesi ya da bir geliştirici aracının zararsız bir hata ayıklama sorusunu bloke etmesi doğrudan iş kaybına dönüşür. Daha kötüsü, kullanıcılar engellenen resmi araç yerine denetimsiz üçüncü taraf araçlara kayar; böylece kurum hem kullanılabilirliği hem görünürlüğü kaybeder.
Buradaki çözüm, güvenliği gevşetmek değil, doğru yere yerleştirmektir. AltaySec'in LLM güvenlik duvarı Guardian, tam da bu iki eksenli dengeyi hedefler: Türkçe bağlamı gözeterek gerçek saldırıları yakalarken masum talepleri gereksiz yere engellememeyi amaçlar. Aşırı redde bakılmayan bir guardrail, üretimde "güvenli görünen ama kullanılamayan" bir sisteme yol açar; asıl mühendislik işi, red bütçesini doğru hedeflere yöneltmektir.
Kurumunuzun Türkçe LLM dağıtımında aşırı-red ve yetersiz-yakalama dengesini ölçmek isterseniz bizimle iletişime geçebilirsiniz. Bir yapay zeka güvenlik duvarını değerlendirirken dikkat edilecek kriterler için AI firewall seçim rehberi yazımız da yol gösterici olacaktır.