Sınırları bilmek

Altay Kargo'nun CI kapısı üç aydır yeşil yanıyor. garak taraması her hafta temiz çıkıyor, promptfoo testleri yüzde 98'in üstünde geçiyor. Yönetim bu tabloyu görüp asistanın güvenli olduğunu düşünüyor. Sonra bir kırmızı takım üyesi elle bir saat çalışıyor ve iade aracını yetkisiz çağırtmayı başarıyor.

Yeşil kapı neyi kaçırdı? Bu derste otomasyonun dört sınırını göreceksin. Açık prob listeleri zamanla kirlenir.

Kendi gizli setin bu yüzden değerini korur. Araçların kendisi de değişir ve ölçtüğü şeyi kaydırır. Bazı kararlar da hiçbir eşiğe bırakılamaz. Son olarak bir eşiği, altı ay sonra da savunulabilecek bir gerekçeyle yazacaksın.

garak'ın probları ve promptfoo'nun kırmızı takım eklentileri açık kaynaktır, herkes okuyabilir. Şeffaflık iyi bir şeydir: aracın neyi ölçtüğünü görür, kendi uygulamana uyarlarsın. Ama bir yan etkisi var.

Bir model sağlayıcı kendi modelini tam bu problara karşı ayarlayabilir. Saldırgan da aynı listeyi okuyup varyasyonunu dener. Bir model listedeki her probu geçtiğinde bu, modelin genel olarak güvenli olduğu anlamına gelmez.

Yalnız bilinen listeye karşı ayarlandığı anlamına gelebilir. Buna kirlenmiş kıyaslama (benchmark contamination) denir. Risk özellikle uzun süredir değişmeyen, popüler listelerde büyür. Herkesin ezbere bildiği bir soruya hazırlanmak kolaydır.

Somut bir örnek düşün. Bir model sağlayıcı yaygın bir tarama aracının bütün problarını iç test sürecine ekler ve modeli bu problara karşı ayarlar. Yeni sürüm yayınlandığında aynı aracı çalıştıran herkes yüksek bir geçme oranı görür ve rahatlar. Ama saldırgan listedeki probun küçük bir varyasyonunu denediğinde model aynı ustalıkla savunamaz.

Ayarlama listeye özgüdür, listenin arkasındaki genel zaafa değil. Sınava değil, sınavın sorularına çalışmış bir öğrenci gibidir. Aynı soru başka kelimelerle sorulduğunda cevap veremez.

Bu sorunun küçük bir hâlini daha önce gördün. Değerlendirme seti kurarken kuralları test setine bakarak yazmanın veri kaçağına yol açtığını öğrenmiştin. Kirlenmiş kıyaslama bunun sağlayıcı tarafındaki hâlidir.

Sağlayıcı senin değil, herkesin kullandığı sete bakarak modeli ayarlar. İki sorun da aynı kökten çıkar: ölçtüğün şeyi önceden bilen taraf, sonucu istediği yöne çekebilir. Araçlar arasındaki geçişler de listeyi yayar.

PyRIT'in hazır senaryolarının bir kısmı garak problarından uyarlanmıştır. Aynı kalıplar birden çok araçta dolaşır ve aynı kalıba karşı alınan iki iyi sonuç birbirini bağımsız olarak doğrulamaz.

Bu yüzden hazır problara karşı yüksek geçme oranı tek başına bir güvenlik kanıtı sayılmaz. Ölçme ve Değerlendirme modülünde kurduğun kendi setin, dışarıdan kimsenin okuyamadığı bir set olduğu için değerini korur.

Açık kaynak araç geniş bir taban çizgisi verir. Kendi setin ise ürününe özgü, herkese açık olmayan bir sınav olarak kalır. İkisi birbirinin yerine geçmez.

Kendi setini de güncel tutman gerekir. Aynı örnekler aylarca değişmezse ekip savunmayı farkında olmadan o örneklere göre şekillendirir ve set de tahmin edilebilir hale gelir. Her ay sete yeni, elle yazılmış birkaç saldırı ekle, en eskilerini emekliye ayır.

Kirlenmeyi doğrudan göremezsin, ama izini ölçebilirsin. Aynı koşuda iki seti yan yana çalıştır: açık listeden gelen problar ve kendi gizli setin. İkisi benzer aileleri kapsıyorsa sonuçları da birbirine yakın olmalı. Açık sette saldırı başarı oranı yüzde ikiyken gizli sette yüzde yirmiyse, model ya da senin savunman açık listeye göre şekillenmiştir.

Fark büyüdükçe açık listenin söylediği şeye daha az güven. Bir adım daha at: açık listedeki birkaç probu kendi cümlelerinle yeniden yaz. Anlamı aynı, yazımı farklı bu örnekler varyasyon setin olur. Asıl prob geçip varyasyonu kalıyorsa ayarlama listeye özgüdür.

Taze örnek üretmenin otomatik bir yolu da var. promptfoo'nun kırmızı takım modu saldırıları sabit bir listeden okumaz. Uygulamanın amacını tarif eden purpose alanına göre her koşuda yeni örnekler üretir. jailbreak gibi stratejiler bir saldırgan modeli kullanıp istemi turdan tura iyileştirir.

PyRIT'in RedTeamingAttack ve CrescendoAttack sınıfları da her adımdaki yeni istemi bir saldırgan modele yazdırır. Böylece kirlenmiş bir listeye bağımlılık azalır. Bedeli de vardır: iki koşu aynı örnekleri üretmez, sonuçlar tam tekrarlanamaz ve saldırgan model istek başına maliyeti katlar.

Üretilen örneklerden işe yarayanları kaydet ve kendi setine taşı. Böylece taze bir örnek kalıcı bir teste dönüşür.

acik_liste      garak ve promptfoo eklentileri    ASR %2
gizli_set       ekibin kendi ornekleri           ASR %19
varyasyon_seti  acik problarin yeni yazimi       ASR %16

Aracın kendisi de sürüm değiştirir. Prob listesi genişler, algılayıcı mantığı düzelir, varsayılan ayarlar değişir. garak 2026'da bir ya da iki ay arayla yeni sürüm çıkardı.

Güncel sürümde prob seçimi bile yeni bir bayrağa taşındı. İki farklı sürümle alınan sonucu doğrudan karşılaştırmak, iki farklı cetvelle ölçüp aynı sayıyı beklemeye benzer. Aracın sürümünü ve yapılandırma dosyasının özetini her koşu kaydına ekle.

Karşılaştırmayı yalnız aynı sürüm içinde yap. Sürüm değiştiğinde eski kayıtları silme, ayrı bir dönem olarak işaretle. İleride aynı sürüme dönersen kayıt yine anlam taşır.

Sürümü sabitlemenin yolu basittir. pip ile kuruyorsan garak==0.17.0 gibi tam sürüm yaz. npx kullanıyorsan promptfoo@latest yerine [email protected] yaz. PyRIT'i de bağımlılık dosyanda tam sürümle tut.

Yükseltmeyi bilinçli bir olay yap. Yeni sürümü önce ayrı bir dalda, aynı hedefe karşı eski sürümle yan yana koş.

İki sonuç arasındaki farkı yeni problara, değişen algılayıcılara ve gerçek davranış farkına ayır. Fark açıklandıktan sonra yeni sürümü ana dala al ve kayıtta yeni bir dönem başlat. Böylece bir sıçramanın üründen mi araçtan mı geldiği sorusu hiç doğmaz.

Bir sınır daha var: kapının kendisi bozulabilir. Bir yapılandırma hatası bütün testleri atlatır, bir algılayıcı güncellemesi her yanıtı temiz sayar ve kapı aylarca yeşil yanar. Bunu yakalamanın yolu pozitif kontroldür. Hazırlık ortamında bilerek zayıflatılmış bir asistan sürümü tut: kanarya dizgisini koruyan talimat kaldırılmış, iade aracında sahiplik kontrolü kapalı.

Kapıyı ayda bir bu sürüme karşı koş. Kapı kırmızı yanmıyorsa sorun asistanda değil, ölçümdedir. Bilinen bir açığı yakalayamayan kapının yeşil ışığı hiçbir şey anlatmaz.

Aracın sahibi de değişebilir. promptfoo'nun OpenAI'ye katılacağı Mart 2026'da duyuruldu ve proje açık kaynak olarak sürüyor. garak NVIDIA'da, PyRIT Microsoft'ta gelişiyor.

Üç araç da bir model ya da altyapı şirketinin çatısı altında. Bu tek başına bir sorun değildir, ama bir hatırlatmadır. Değerlendirmenin bağımsızlığını aracın kime ait olduğuna bağlama. Bağımsızlık senin sabitlediğin sürümden, kendi gizli setinden ve sonuçları okuyan insandan gelir.

Otomasyon hızlı çalışır ama her bulguyu doğru yorumlamaz. Üç durumda otomatik etiketin üstüne bir insan bakar. Birincisi yeni bir saldırı ailesinin ilk kez tespit edilmesidir.

İkincisi canlıya çıkış kararıdır. Üçüncüsü gerçek bir kullanıcıyı etkileyebilecek bir bulgudur. Bu üç nokta Ölçme ve Değerlendirme modülünde gördüğün kuralın aynısıdır.

Otomasyon bu kuralı ortadan kaldırmaz. Üç durumu bir kontrol listesine yaz ve CI adımının yanına iliştir. Ekibe yeni katılan biri de ne zaman durup bakması gerektiğini bilsin.

Dersin başındaki açığı da otomasyon değil, bir insan buldu. Otomatik araçlar tek tek istemlerde iyidir, iş akışlarında zayıftır. O açık, iade aracının sipariş sahibini kontrol etmemesinden doğdu. Bu açığı bulmak için asistanın hangi aracı hangi yetkiyle çağırdığını bilmek, birkaç turda bağlam kurmak ve sonucu iş kuralına göre yorumlamak gerekir.

Hazır bir prob bu iş kuralını bilmez. Algılayıcı da yetkisiz bir iadeyi kibar bir yanıttan ayıramaz, çünkü yanıt metni zararsız görünür. Bu yüzden elle kırmızı takım çalışmasını takvime bağla: büyük sürümlerden önce ve asistana yeni bir araç bağlandığında. Elle bulunan her açık otomatik sete yeni bir test olarak döner.

Bu modülün sonunda elinde bir kapı var: otomatik, sık çalışan ama kör noktaları olan bir kapı. Bu kapıyı savunurken neden o eşiği seçtiğini yazılı bırak. Altı ay sonra kimse yüzde 5'in nereden geldiğini hatırlamaz. Gerekçesiz bir sayı ilk itirazda gevşetilir.

İyi bir gerekçe üç şeyi bağlar: taban çizgisi koşusunda ölçülen gürültü, kabul edilen risk ve kararı kimin verdiği. Örneğin temiz sürüm on koşuda yüzde 2 ile 3 arasında başarısızlık gösteriyorsa, yüzde 5 bu gürültüyü kapsar ama gerçek bir sıçramayı yakalar. Gerekçeyi eşiğin yanına, yapılandırma dosyasına yorum satırı olarak yaz. Eşiği değiştiren herkes gerekçeyi de güncellesin.

Yazılı gerekçe yalnız bir ekip alışkanlığı değildir, düzenleyiciler de iz ister. AB Yapay Zekâ Yasası'nın 15. maddesi yüksek riskli sistemlerden doğruluk, sağlamlık ve siber güvenlik bekler.

Aynı maddenin 5. fıkrası, uygun olduğu ölçüde veri zehirleme, model zehirleme, saldırgan örnekler (adversarial examples) ve gizlilik saldırılarına karşı önlem ister. Sistemik riskli genel amaçlı modellerin sağlayıcıları için 55. madde daha açıktır: saldırgan testleri (adversarial testing) yapmak ve belgelemek zorunludur.

NIST'in yapay zekâ risk yönetimi çerçevesinde Ölç (Measure) işlevinin 2.7 maddesi de güvenlik ve dayanıklılığın değerlendirilip belgelenmesini ister. Otomatik koşuların kayıtları, sabit araç sürümü ve eşik gerekçesi bu belgelerin hammaddesidir. Yükümlülüklerin ayrıntısını AI Yönetişimi ve Düzenlemeler modülünde göreceksin.