Tao’nun mavi takım ve kırmızı takım LLM’leri hakkındaki görüşü

 (mathstodon.xyz)
3 puan yazan GN⁺ 2025-07-29 | 1 yorum | WhatsApp'ta paylaş
  • Terence Tao, siber güvenlik alanında mavi takım ile kırmızı takım ayrımının mantıksal önemine değiniyor
  • Constructive logic (yapıcı mantık) mavi takımı, co-constructive logic (eş-yapıcı mantık) ise kırmızı takım ilkesini temsil ediyor
  • Mike Shulman, bu iki mantık temelini birleştiren yeni bir mantık üzerinde çalışıyor
  • Brouwer–Heyting–Kolmogorov (BHK) yorumu kanıt merkezli olsa da, çürütmenin önemini de vurguluyor
  • Bu araştırmanın yapay zeka güvenliği gibi çeşitli alanlarda uygulanma potansiyeli bulunuyor

Mavi takım ve kırmızı takım LLM mantığının ayrımı ve birleştirilmesi tartışması

  • Terence Tao, son dönemde güvenlik ve algoritma alanlarında mavi takım (savunma) ile kırmızı takımın (saldırı) farklılığı üzerine mantıkçıların daha derin düşündüğünü belirtiyor
  • Constructive logic (yapıcı mantık), doğrulama sürecine, yani bir önermenin nasıl kanıtlandığına odaklanıyor ve mavi takımın ilkesini tanımlıyor
  • Buna karşılık co-constructive logic (eş-yapıcı mantık), çürütme sürecine, yani itiraz veya saldırıya ilişkin mantık olarak son dönemde dikkat çekiyor ve kırmızı takımın ilkesini içeriyor

Mike Shulman’ın mantıkları birleştirme araştırması

  • Mike Shulman, bu iki mantık sistemini birleştiren bir mantık biçimi üzerinde çalışıyor
  • Makalesinde alıntılanan ifadeye göre, mevcut Brouwer–Heyting–Kolmogorov (BHK) yorumu yalnızca kanıt ölçütlerine ağırlık verme eğiliminde; ancak uygulamalı matematikçiler, bir önermenin yanlış olduğunu belirleme ölçütü olan çürütmeyi de en az bunun kadar önemli görüyor
  • Bu noktadan hareketle, mevcut mantık yorumlarında kanıt merkezli düşünme biçiminin sınırlarına işaret ediyor

Mantık yorumunun genişletilmesi gereği

  • Mantıksal bağlaçlar için kanıt ve çürütmenin ne anlama geldiğinin her iki bakış açısından da açıklanması gerektiği gündeme geliyor
  • Mike Shulman’ın sürmekte olan araştırması, böyle bir genişletilmiş yorumun pratikte nasıl bir yapıya sahip olacağını inceliyor

Çıkarımlar ve olası uygulamalar

  • Bu tür birleşik mantık araştırmaları ilerlerse, yapay zeka güvenliği tasarımı ile siber güvenlikte algoritma doğrulama ve çürütme sistemlerinin geliştirilmesinde somut biçimde kullanılma potansiyeli yüksek
  • İlgili makalenin ayrıntıları arXiv bağlantısında görülebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-29
Hacker News yorumu

  • Birkaç düşüncem var
    (a) AI hem "red" hem de "blue" takımda faydalı
    Blue team bir tür beyin fırtınası rolü görüyor
    (b) AlphaEvolve bu anlamda 'red/blue team' yaklaşımının açıkça uygulandığı bir örnek. Sadece bu terimleri kullanmıyor
    Terence Tao da o makalenin danışmanlarından biriydi
    (c) Bu bana oyun anlambilimindeki 'doğrulayıcı/çürütücü' rol dağılımını hatırlatıyor
    Tao da bizzat bu düşünme biçiminden kamuya açık şekilde söz etti, dolayısıyla aslında buna benzer bir bakış açısından görüyor gibi duruyor
    "Blue/red" ifadesi muhtemelen programcılara uygun bir paketleme
    (d) Ek olarak, bir güvenlik sisteminin her zaman yalnızca en zayıf halkası kadar güçlü olduğunu söyleyemeyiz
    Bu, güvenliğin katmanlı mı yoksa paralel yapıda mı olduğuna bağlı
    Bir koridorda art arda duran birden çok güçlü kapı ve zayıf kapı varsa, toplam dayanıklılık en güçlü kapının dayanıklılığı tarafından belirlenir
    Ve birden çok zayıf sınıflandırıcıyı birleştirip dolandırıcılık tespit algoritması yaparsanız, bu sistem en zayıf sınıflandırıcıdan çok daha güçlü olabilir
    AlphaEvolve makalesi
    Tao'nun düşünme tarzıyla ilgili Soru-Cevap

    • AlphaEvolve'daki LLM'in nasıl red team rolü oynadığını merak ediyorum
      Orada LLM'in yaptığı şey sadece örneklere dayanarak yeni kod üretmek; kodun değerlendirmesini kendisi yapmıyor

  • Red vs blue team kavramının, LLM'in uzman kullanımı için ne kadar faydalı olduğunu anlamak adına iyi bir çerçeve olduğunu düşündüm
    Test ekleme işini neredeyse hiç tereddütsüz LLM'e verirdim
    Çünkü testler genelde ucuzdur, yanlışsa silmek veya düzeltmek kolaydır, doğruysa da değer katar
    Ancak LLM çekirdek işlevleri sık sık test etmediği için, en önemli testleri güvenebilmek adına kendiniz yazmanız gerekir
    Buna karşılık, LLM ile bug düzeltmek veya özellik eklemek daha riskli
    Çünkü LLM hileye kaçabilir ya da sadece testi geçmek için özü çözmeyen kod yazabilir

    • Legacy bir kod tabanında çalışırken, "test yanlış olsa da sonra düzeltiriz" düşüncesinin ne kadar tehlikeli olduğunu içtenlikle hissettim
      Testler bazen koddan daha fazla gerçeğe yakın bir referans olur; bu yüzden yanlış testler, yanlış koddan daha yıkıcı olabilir
      Özellikle işe yaramaz veya anlamı belirsiz testler karıştığında, bunların gerçekten önemli işlevleri garanti etmeye mi çalıştığını ayırt etmek tam bir kabus oluyor

    • AI'nin hesap makinesine benzediğini düşünüyorum
      Hesap makinesi çoğu insanın yapamayacağı hesapları iyi yaptığı gibi, AI de yeni bir zeka türü olarak insanı güçlendiren yardımcı bir araç
      Birçok kişi "AI insanın yerini alır" diye düşünüyor ama gerçek değer, insan işini tamamlamasında yatıyor

    • Ben karşı taraftayım
      Testleri kendiniz yazıp tamamen anlamanız gerekir ki gerçek bir çıta koyabilesiniz; ondan sonra AI kodu istediği gibi değiştirse bile içiniz rahat olur diye düşünüyorum
      Eğer testler de LLM tarafından üretildiyse, kodun geri kalanını AI'ye bırakma konusunda daha da huzursuz olurum

    • Rust kodu için LLM ile testler oluşturdum, ama pratikte faydadan çok zarar getirdi
      Test sayısı çoktu ama önemli kapsam alanları kolayca atlanıyordu
      Kod miktarı fazla olunca hangi kısımların kapsanmadığını görmek zordu
      Gelecekte kod mantığını değiştirmem gerektiğinde, üretilmiş çok sayıdaki testin tamamına dokunmak zorunda kaldım

    • "Testleri kimse doğrulamaz, bu yüzden doğal olarak doğru kabul edilirler" diye bir söz var
      Arrange-Act-Assert kalıbı da bu yüzden ortaya çıktı
      Bugünlerde en sevdiğim birim test türü, giriş değerlerini ve beklenen çıktıyı kaydedip kod sonucunu bunlarla doğrulayan yaklaşım
      Köşe durumlarını bile kolayca doğrulayabildiği için gerçekten istenen şekilde çalışıp çalışmadığını görmek kolay oluyor

  • Benim anladığım kadarıyla RSA algoritması da bu şekilde geliştirildi
    Simon Singh'in "The Code Book" kitabına göre (bir yere koydum ama bulamıyorum), Rivest ve Shamir fikirleri üretiyor, Adleman da kusurları buluyordu
    RSA Wikipedia maddesi
    Matematikte de blue/red team işbirliğine bir örnek

    • Tanıdığım iki bilişsel bilimci de buna benziyor
      Biri fikir dolu, çok konuşan ve dağınık
      Diğeri mantıklı ve titiz; biri makale taslağını yazınca, diğeri gereksiz her şeyi temizliyor

  • Genel çerçevede katılıyorum ama infosec bakış açısından yapılan çerçeveleme biraz tuhaf geliyor
    "Güvenlik en zayıf kısmı kadar güçlüdür" bakışı fazla basit ve riskli
    Güvenlik stratejisi katmanlı kurulmalı
    Tek bir katmanda mükemmellik beklenemeyeceği için birden fazla savunma katmanı gerekir
    Saldırı ile savunma arasında büyük bir fark yoktur, ama birçok saldırgan hata yaptığında daha az sorumluluk taşır; savunmacılar ise özellikle büyük şirketlerde sonuçlardan daha çok sorumludur
    Buna rağmen savunmacıların kendi sahasında savaşma avantajı vardır. Bunu gözden kaçırmak başa iş açabilir

    • Kapıyı kapatmış olsanız bile pencere açıksa işe yaramaz örneği doğru bir benzetme
      Çok katmanlı savunma, saldırganın hedefe ulaşana kadar mutlaka geçmek zorunda olduğu öğelerin birden fazla katman halinde üst üste dizildiği durumda anlamlıdır
      Ama kapı ve pencere gibi aynı katmanda yer alan öğelerde en zayıf parça bütünü belirler
      Web örneği olarak, ana giriş kusursuz olsa ama /v1/legacy/external_backoffice gibi eski bir endpoint hiçbir kimlik doğrulama olmadan iç ağa erişim veriyorsa, tüm savunma çöker
      Yine de içeride ek engeller varsa zarar sınırlanır; sonuçta savunma katmanları önemli

    • "Savunma en zayıf halkası kadar güçlüdür" ifadesini biraz daha geniş anlamda kullandım
      Orijinal ifadenin ötesine geçip 'toplam savunma çabası' anlamını ekledim, ama aslında iki tarafın da haklı olduğu noktalar var
      Terence'ın dediği gibi en zayıf halka gerçekten delinip geçilebilir, bu yüzden birden fazla savunma katmanı gerekir
      Yakın tarihli gerçek bir örnek olarak, istemci parolalarını doğrulama olmadan sıfırlayan bir helpdesk görevlisi vakası vardı
      VPN, 2FA gibi güçlü güvenlik teknolojileri uygulansa da, 'hesap kurtarma' denen tek bir en zayıf halka her şeyi çökertti
      İçerideki ek katmanlar saldırganı tespit edip engelleyerek 3 saat içinde durdurdu, ama bu 'zararı en aza indirme'dir, 'önceden engelleme' değil
      Sonuçta hasarı önlemek için birden fazla katman gerekir
      Son dönemde infosec sektörünün odağı da "%100 önleme"den "zararı hafifletme"ye kayıyor
      Tüm riskleri önlemek zor; bunun yerine riski azaltmak, yüzeyi küçültmek ve güven seviyesini düşürmek yönünde bir stratejiye geçiliyor

    • Hiç güvenlik uzmanı değilim ama duyduğuma göre "aşırı derecede küçültülmüş saldırı yüzeyi, doğrulanmış açık kaynak protokollerin kullanımı" en iyi savunma sayılıyor
      Bunun burada tartışılanlarla hangi açıdan farklı olduğunu merak ediyorum

    • Sadece yapılan benzetme iyi seçilmemiş
      "En zayıf halka" sözü, birden fazla aşamanın art arda aşılması gerektiğinde doğru
      Aynı katmanda birden fazla katman varsa, bunların en zayıfını hedef almak doğru yaklaşım olur
      Yani endişe edildiği gibi belirsiz yoruma açık bir ifade

    • Bence saldırı da başka bir savunma katmanına karşılık gelir
      Hani derler ya, 'en iyi saldırı en iyi savunmadır'

  • Siber güvenlikte red team ve blue team eşit güce sahip iki takım ama
    yazılım geliştirmede bu benzetme biraz abartılı geliyor
    Testler de koddur ve onlarda da bug kalır
    Bu, "Who polices the police?" türü bir paradoks yaratıyor

  • John Cleese'in "açık mod vs kapalı mod" zihniyetinden söz edişini hatırladım
    Fikirleri mümkün olduğunca açık bir tavırla bol bol üretip
    sonra kapalı moda geçerek kötü fikirleri elemek, iyileri seçip geliştirmek gibi
    Her alandaki yazarların da genelde editörleri vardır
    Magic: the Gathering kart oyununun tasarımında da benzer biçimde, tasarım ekibi set taslağını hazırlayıp bunu doğrulama için tamamen ayrı bir geliştirme ekibine devrediyor
    Buna benzer başka işbirliği örnekleri duymak isterim

    • Örneğin dev team ve validation (doğrulama) team olarak ayrılan yapılar da var

  • Aslında bence durum bu yazının tersine
    LLM taslağı hızlı çıkarmakta çok iyi, iyi eğitilmiş bir insan da LLM sonucunu eleştirel biçimde gözden geçirmeye daha uygun
    Yani LLM blue team'e, insan ise red team'e daha çok uyuyor

    • En ileri düzeyde bu bakış açısı tersine de dönebilir
      Sanırım Tao da bu tür uç durumlara değiniyor

  • Son dönemde ajan tabanlı modeller ve workflow'lar kullanırken şunu hissettim
    Bu ajanlar sadece kod yazmakta değil, test, idare ve hatta management rollerinde kullanıldığında daha çok parlıyor
    Geliştirici bir tür yöneticiye, yani süpervizöre dönüşüyor
    Tüm görev planlamasını (prompt yazımı, iş kapsamını netleştirme), test yazımını ve kod yazım sürecinin tamamını denetleyen konumda oluyor
    İnceleme çok arttı ama bizzat red team rolünü üstlenip daha az kırılıp kırılmadığını kontrol ettiğim için, aksine kontrolün arttığını hissettim

  • Bu bakış açısı etkileyici
    İş dünyasında da bunu ‘blue team’ (toplumsal altyapı sektörleri: elektrik, petrol, telekom, yazılım, finans vb.) ve ‘red team’ (katma değer sektörleri: yeme-içme, özel perakende, lüks tüketim, turizm vb.) diye ayırmak mümkün olabilir
    Ekonomik olarak blue team tarafı çok daha önemlidir, çünkü bu sektörler tüm ekonominin temelini oluşturur, talep görür ve bu takımın hatayı en aza indirmesi gerekir
    Buna karşılık red team sektörleri olmasa da ekonomi döner, ama arttıkça genel kaliteyi yükseltirler
    Tao'nun örneğinde de yazılım mühendislerinin QA'den daha yüksek maaş alması, kanıt yazmanın doğrulamadan daha ekonomik değerli görülmesi aynı yapıya işaret ediyor
    Sam Altman, LLM eğitimi için fon toplarken "biz blue team gibi faydalıyız" demeyi vurgulamak zorunda; bu da tüm medya anlatısını etkiliyor
    Gerçekte red team kullanımına daha uygun olsa da, yatırımın geri dönüşünü göstermek gerektiği için şirketler LLM'i blue team kullanımına göre pazarlayacak
    Google Glasses, VR ve giyilebilir cihazlar da benzer bir örnek
    Bunlar niş sektörlerde faydalı red team teknolojileri ama devasa bir ekosistem ya da gelir üretemedikleri için sermaye tarafından görmezden geliniyor

  • (Microsoft'ta çalışıyorum)
    RAG örnekleri için azure-ai-evaluation SDK ile otomatik red team doğrulamasını bizzat yürütüyorum
    Burada raydan çıkmış adversarial LLM ile pyrit paketi birleşiyor; uygulamaya tuhaf soruları otomatik üretip yöneltiyor ve soruların kendisini de base64, Sezar şifresi, urldecode vb. yollarla dönüştürüyor
    Gerçek sonuçlar ilginç ve red team faaliyetlerinde LLM'in oldukça faydalı olduğuna katılıyorum
    YouTube demo videosu
    (Ses tonum yüksek geldiyse kusura bakmayın, videoyu alışılmadık bir mekânda çektim)