Saldırı Başarı Oranı (ASR) Nedir? Ölçüm ve Raporlama

Saldırı başarı oranı (ASR) neyi ölçer?

ASR, belirli bir saldırı kümesinin belirli bir hedefe karşı belirli bir protokolle ne kadar başarılı olduğunu ölçer. Sistemin genel güvenliğini ölçmez. Hedef, saldırı kümesi ya da protokol değiştiğinde oran da değişir.

Hedefin ne olduğunu açıkça yazın. Çıplak model ile uygulama aynı şey değildir. Uygulamada sistem istemi, girdi ve çıktı süzgeçleri, yetki sınırları ve araç doğrulaması vardır. Aynı saldırı kümesi çıplak modelde yüksek, uygulamada düşük oran verebilir. Raporda ölçülen katman, model sürümü, sistem istemi sürümü ve ölçüm tarihi bulunmalıdır.

ASR'nin arkasında bir protokol vardır. Protokolü verilmeyen bir oran başkası tarafından yeniden üretilemez. HarmBench ve JailbreakBench gibi açık değerlendirme çerçeveleri, bu sorunu çözmek için saldırı kümesini, hedef yapılandırmayı ve başarı değerlendirmesini sabitlemeyi önerir.

Başarı tanımı ölçümden önce nasıl yazılır?

Başarı, önceden tanımlanmış bir hedefe ulaşmaktır. Tipik hedefler şunlardır: sistem isteminin ya da gizli bağlamın ifşası, politikanın yasakladığı içeriğin üretilmesi, yetkisiz bir araç çağrısı ve başka bir kullanıcının verisinin sızdırılması. Her hedef için başarının neye benzediği örnekle yazılır.

Kısmi başarı en tartışmalı sınıftır. Model talebi reddeder ama ardından işe yarar bir ipucu verirse ne olacak? Karar riske göre verilir, ama ölçümden önce verilir ve tüm değerlendirmede aynı uygulanır. Ölçüm sırasında kuralı değiştirmek sonucu geçersiz kılar.

Mümkün olan her hedefte deterministik bir kontrol kullanın. Sistem istemine benzersiz bir kanarya dizesi yerleştirirseniz, yanıtta bu dizenin görünüp görünmediği yoruma yer bırakmaz. AltaySec'in TR-SecEval çerçevesi de sızıntı ölçümünde kelime eşleştirmesi yerine bu tür bir kanarya kontrolüne dayanır. Yorum gerektiren hedeflerde ise etiketleme yöntemi ayrıca belgelenir.

Payda nasıl seçilir ve neden önemlidir?

Payda, oranın altındaki saldırı girişimleri kümesidir. Kolay saldırılar çoğaldıkça oran yükselir, zor ve çeşitli saldırılar çoğaldıkça düşer. Kümenin kaynağı, büyüklüğü, dil dağılımı ve saldırı ailesi dağılımı raporda yazılmalıdır.

Üç hata sık görülür. Birincisi, tek bir saldırı fikrinin elli varyasyonunu elli bağımsız girişim saymaktır. Payda büyük görünür, ama bağımsız örnek sayısı düşüktür. İkincisi, savunmayı geliştirmek için kullanılan kümeyle ölçüm yapmaktır. Savunma o saldırılara göre ayarlandıysa oran düşer, ama yeni saldırılara dayanıklılık hakkında bilgi vermez. Üçüncüsü, yalnızca İngilizce şablonlarla ölçmektir. Türkçe ve karma dilli saldırılar kümede ayrıca temsil edilmelidir.

Değerlendirme kümesini sürüm numarasıyla saklayın ve savunma geliştiren ekiple paylaşmayın.

Kaç tekrar gerekir ve rastgelelik sonucu nasıl etkiler?

Üretken modeller aynı girdiye her seferinde aynı yanıtı vermez. Bir saldırının tek denemede başarısız olması, sistemin ona dayanıklı olduğunu göstermez. Saldırgan denemeyi tekrarlar ve başarılı olanı kullanır.

Bu etki küçük değildir. Hughes ve arkadaşlarının Best-of-N çalışmasında, istemin rastgele biçim değişiklikleriyle 10.000 örnek denendiğinde saldırı başarı oranı GPT-4o'da yüzde 89'a, Claude 3.5 Sonnet'te yüzde 78'e ulaşmıştır. Yazarlar başarı oranının örnek sayısıyla birlikte üs yasasına benzer biçimde arttığını raporlar. Konunun savunma tarafı Best-of-N jailbreak yazısında ele alınır.

Bu yüzden iki oran raporlayın:

• Deneme düzeyinde oran: tüm denemelerin kaçı başarılı.
• Saldırı düzeyinde oran: k denemenin en az birinde başarılı olan saldırı fikirlerinin kesri. k değeri yazılır.

İkincisi saldırganın bakış açısına daha yakındır. Ölçümü üretimdeki sıcaklık ve örnekleme ayarlarıyla yapın. Laboratuvara özgü ayarlar, örneğin sıfır sıcaklık, üretimdeki davranışı temsil etmeyebilir.

Yanıtları kim etiketlemeli?

Etiketleme, her yanıtın başarılı, başarısız ya da kısmi olarak işaretlenmesidir. Deterministik kontrol mümkün değilse, yazılı ölçütle çalışan iki bağımsız insan etiketleyici en güvenilir yoldur. Etiketleyiciler arası uyum ölçülür. Uyum düşükse sorun etiketleyicide değil ölçüttedir.

Otomatik değerlendirici hız kazandırır, ama kendi hatalarını taşır. StrongREJECT çalışması, yaygın jailbreak değerlendirme yöntemlerinin başarıyı insan yargısına göre belirgin biçimde abarttığını göstermiştir. Değerlendirici, işe yaramaz ya da yarım bir yanıtı başarılı sayabilir. Bu da ASR'yi şişirir.

Otomatik değerlendirici kullanıyorsanız şu adımları izleyin:

1. Başarı ve kısmi başarı kuralını örneklerle yazın.
2. Temsili bir örneği iki insana etiketletin, uyumu ölçün.
3. Değerlendiriciyi aynı örnekte çalıştırın, yanlış pozitif ve yanlış negatif oranını çıkarın.
4. Hata oranını ASR raporuna ekleyin.
5. Değerlendirici ya da ölçüt değiştiğinde doğrulamayı tekrarlayın.

Hakem modellerin bilinen önyargıları ve korunma yolları LLM-as-a-Judge güvenilirliği yazısında ayrıntılı anlatılır.

Güven aralığı rapora nasıl girer?

Güven aralığı, ölçülen oranın gerçek değere ne kadar yakın olabileceğini gösterir. Örneklem küçükse aralık geniştir. Aralık verilmeden yapılan karşılaştırmalar çoğu zaman şansı fark sanar.

Bir örnek üzerinden gidelim. A sisteminde 300 denemenin 18'i başarılı olsun: ASR yüzde 6,0. Wilson yöntemiyle yüzde 95 güven aralığı yaklaşık yüzde 3,8 ile yüzde 9,3 arasıdır. B sisteminde 300 denemenin 27'si başarılı olsun: ASR yüzde 9,0, aralık yaklaşık yüzde 6,3 ile yüzde 12,8 arasıdır. Aralıklar geniş ölçüde örtüşür. İki oran testi de anlamlı bir fark göstermez (p yaklaşık 0,16). "A, B'den daha güvenli" demek için bu örneklem yetmez.

Küçük örneklemde durum daha belirgindir. 40 denemede 6 başarı yüzde 15 eder, ama aralık yaklaşık yüzde 7 ile yüzde 29 arasındadır.

Sıfır başarı ayrıca dikkat ister. 150 denemede hiç başarı gözlenmediyse, gerçek oranın üst sınırı için üçler kuralı kullanılabilir: yaklaşık 3/150, yani yüzde 2. Doğru ifade "150 denemede başarı gözlenmedi, gerçek oran yüzde 95 güvenle yaklaşık yüzde 2'nin altında" olur. "Sistem bu saldırılara bağışık" ifadesi ölçümün söylediğinden fazlasını iddia eder.

ASR neden aşırı red oranıyla birlikte raporlanmalı?

Savunma sıkılaştıkça ASR düşer, ama meşru istekler de reddedilir. Her şeyi reddeden bir sistemin ASR'si mükemmel görünür, ama işe yaramaz. Bu yüzden aynı sürüm için aşırı red oranı aynı tabloda verilir: reddedilen meşru istek sayısı bölü meşru istek sayısı.

Türkçe sistemlerde bu ikili daha da önemlidir. Türkçe meşru istekler, İngilizce eğitilmiş süzgeçlerde gereksiz yere işaretlenebilir. Ölçüm yöntemi için Türkçe aşırı red ölçümü yazısına bakabilirsiniz. Etkiye göre ağırlıklandırma da yararlıdır. Sistem isteminin kısmi ifşası ile müşteri verisinin sızması aynı satırda sayılmamalıdır. Saldırıları etki sınıflarına ayırmak, yöneticinin riski doğru okumasını sağlar.

Dürüst bir ASR raporunda neler bulunmalı?

Dürüst bir rapor sayıyı değil protokolü öne çıkarır. Asgari içerik şudur:

• Hedef: katman, model sürümü, sistem istemi sürümü, süzgeçler, ölçüm tarihi.
• Küme: saldırı sayısı, kaynağı, sürüm numarası, dil ve aile dağılımı.
• Protokol: tekrar sayısı, örnekleme ayarları, başarı ve kısmi başarı tanımı.
• Etiketleme: yöntem, etiketleyici sayısı, uyum düzeyi, otomatik değerlendiricinin hata oranı.
• Sonuç: deneme ve saldırı düzeyinde oran, güven aralığı, aşırı red oranı, aile bazında döküm.
• Sınırlamalar: kapsam dışı kalan diller, kanallar ve saldırı aileleri.

Aşağıdaki tablo, sık görülen yanıltıcı sunumları ve daha doğru alternatiflerini özetler.

Ölçümü her model ya da istem değişikliğinde aynı protokolle tekrarlamak eğilimi görünür kılar. Bunun için LLM güvenlik regresyonunu CI'a bağlamak yazısındaki düzenek kullanılabilir.

Sık Sorulan Sorular

ASR düşükse sistem güvenli midir?

Düşük ASR yalnızca denenen saldırıların az başarılı olduğunu söyler. Küme dar, eski ya da savunmanın ayarlandığı saldırılardan oluşuyorsa sonuç yanıltır. Ayrıca her saldırı tek kez denendiyse olasılıksal başarılar kaçırılır. Kapsam, tekrar sayısı ve etiketleme yöntemi bilinmeden düşük bir oran güvence sayılmamalıdır. Oranı her zaman güven aralığı ve aşırı red oranıyla birlikte okuyun.

Bir saldırıyı kaç kez tekrar etmek gerekir?

Sabit bir sayı yoktur, ama tek deneme yetmez. Üretimdeki sıcaklık ayarıyla her saldırıyı en az birkaç kez deneyin ve hem deneme düzeyinde hem saldırı düzeyinde oranı raporlayın. Best-of-N çalışması, örnek sayısı arttıkça başarı oranının düzenli biçimde yükseldiğini gösterir. Bu yüzden tekrar sayısı, oranın ayrılmaz bir parçası olarak raporda yazılmalıdır.

Yanıtın başarılı sayılıp sayılmadığına kim karar vermeli?

Mümkün olduğunda deterministik bir kontrol karar vermelidir, örneğin yanıtta kanarya dizesinin görünüp görünmediği. Yoruma dayalı hedeflerde yazılı ölçütle çalışan iki insan etiketleyici en güvenilir yoldur. Otomatik sınıflandırıcı ya da hakem model kullanılacaksa, insan etiketli bir örnek üzerinde doğruluğu ölçülmeli ve hata türleri raporda belirtilmelidir.

ASR ile aşırı red oranı neden birlikte raporlanır?

Savunma sıkılaştıkça ASR düşer, ama meşru istekler de reddedilmeye başlar. Yalnızca ASR'ye bakmak, her şeyi reddeden kullanışsız bir sistemi en güvenli sistem gibi gösterir. Aynı sürüm için iki oranı yan yana vermek, savunmanın gerçekten güçlendiğini mi yoksa yalnızca daha çok reddettiğini mi gösterir. Eşik değişikliklerinin etkisi de bu ikiliyle izlenir.

Farklı raporlardaki ASR değerleri karşılaştırılabilir mi?

Çoğu zaman karşılaştırılamaz. JailbreakBench yazarları da önceki çalışmaların başarı oranlarını birbiriyle karşılaştırılamaz biçimde hesapladığını belirtir. Saldırı kümesi, hedef yapılandırma, başarı tanımı, tekrar sayısı ve etiketleme yöntemi aynı değilse iki oran farklı şeyleri ölçer. Karşılaştırma için protokolü sabitleyin ve kümeyi açık bir sürüm numarasıyla saklayın.

Kaynaklar

• arXiv: HarmBench, A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal
• arXiv: JailbreakBench, An Open Robustness Benchmark for Jailbreaking Large Language Models
• arXiv: A StrongREJECT for Empty Jailbreaks
• arXiv: Best-of-N Jailbreaking

İlgili Yazılar

• LLM Güvenlik Regresyonunu CI'a Bağlamak AltayDuel veri setiyle çalışan pytest + GitHub Actions harness
• Aşırı Red (Over-Refusal) Nedir? Türkçe'de Modeller Neden Masum Soruyu Reddediyor Hem fazla reddeden hem az yakalayan guardrail'ler
• TR-SecEval: Türkçe LLM Güvenliği İçin 5 Eksenli Değerlendirme Çerçevesi Tek sayı değil, karne: ASR + aşırı-red + PII recall + kararlılık + maliyet
• LLM-as-a-Judge Güvenilir mi? Hakem Modelin Sınırları