Pandangan Tao tentang LLM Blue Team dan Red Team

 (mathstodon.xyz)
3 poin oleh GN⁺ 2025-07-29 | 1 komentar | Bagikan ke WhatsApp
  • Terence Tao menyebut pentingnya pembedaan logis antara blue team dan red team di bidang keamanan siber
  • Constructive logic (logika konstruktif) mewakili prinsip blue team, sementara co-constructive logic (logika ko-konstruktif) mewakili prinsip red team
  • Mike Shulman sedang meneliti logika baru yang menggabungkan kedua landasan logika tersebut
  • Interpretasi Brouwer–Heyting–Kolmogorov (BHK) berpusat pada pembuktian, tetapi juga menekankan pentingnya bantahan
  • Riset seperti ini berpotensi diterapkan di berbagai bidang, termasuk keamanan AI

Diskusi tentang pembedaan dan penggabungan logika LLM blue team dan red team

  • Terence Tao baru-baru ini menyebut bahwa para ahli logika semakin memikirkan lebih dalam perbedaan antara blue team (pertahanan) dan red team (serangan) dalam bidang keamanan dan algoritme
  • Constructive logic (logika konstruktif) berfokus pada proses verifikasi, yakni proses membuktikan suatu pernyataan, dan mendefinisikan prinsip blue team
  • Sebaliknya, co-constructive logic (logika ko-konstruktif) adalah logika tentang proses bantahan, yakni sanggahan atau serangan, yang belakangan ini mendapat perhatian dan memuat prinsip red team

Riset Mike Shulman tentang penggabungan logika

  • Mike Shulman sedang meneliti bentuk logika yang menggabungkan dua sistem logika ini
  • Menurut kutipan dalam makalahnya, interpretasi Brouwer–Heyting–Kolmogorov (BHK) yang ada cenderung hanya menitikberatkan pada standar pembuktian, tetapi matematikawan praktis menilai bahwa bantahan, yakni kriteria untuk mengidentifikasi bahwa suatu proposisi salah, sama pentingnya
  • Melalui hal ini, ia menunjukkan keterbatasan cara berpikir yang terlalu berpusat pada pembuktian dalam interpretasi logika yang ada

Perlunya perluasan interpretasi logika

  • Muncul kebutuhan untuk menjelaskan, dari kedua sisi, apa arti pembuktian dan bantahan masing-masing untuk konektor logika
  • Riset Mike Shulman yang sedang berlangsung mengeksplorasi struktur seperti apa yang mungkin dimiliki oleh interpretasi yang diperluas ini dalam praktik

Implikasi dan kemungkinan penerapan

  • Jika riset logika gabungan seperti ini terus berkembang, ada kemungkinan besar ia dapat dimanfaatkan secara nyata dalam perancangan keamanan AI maupun pengembangan sistem verifikasi dan bantahan algoritme di bidang keamanan siber
  • Rincian makalah terkait dapat dilihat melalui tautan arXiv

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-29
Opini Hacker News

  • Punya beberapa pemikiran
    (a) AI berguna baik di tim "merah" maupun tim "biru"
    Tim biru berperan semacam brainstorming
    (b) AlphaEvolve adalah contoh yang jelas menerapkan pendekatan 'tim merah/tim biru' dalam arti ini. Hanya saja mereka tidak memakai istilah itu
    Terence Tao juga menjadi penasihat untuk makalah tersebut
    (c) Ini mengingatkan pada pembagian peran 'verifier/falsifier' dalam game semantics
    Tao sendiri juga pernah menyinggung pola pikir semacam ini secara terbuka, jadi sepertinya memang melihatnya dari sudut pandang seperti ini
    Ungkapan "biru/merah" mungkin cuma kemasan yang disesuaikan untuk programmer
    (d) Tambahan lagi, tidak selalu benar bahwa sistem keamanan hanya sekuat mata rantai terlemahnya
    Itu tergantung apakah keamanannya berlapis atau paralel
    Jika ada koridor dengan banyak pintu kuat dan pintu lemah yang tersusun berderet, kekuatan keseluruhannya ditentukan oleh kekuatan pintu yang paling kuat
    Dan jika beberapa classifier yang lemah digabungkan untuk membuat algoritme deteksi penipuan, hasilnya justru bisa jauh lebih kuat daripada classifier yang paling lemah
    Makalah AlphaEvolve
    Tanya jawab terkait pola pikir Tao

    • Saya penasaran bagaimana LLM di AlphaEvolve berperan sebagai tim merah
      Di sana, yang dilakukan LLM hanyalah menghasilkan kode baru berdasarkan contoh, dan tidak mengevaluasi kodenya sendiri

  • Saya merasa konsep tim merah vs tim biru adalah kerangka yang bagus untuk memahami sejauh mana LLM berguna bagi para ahli
    Menambahkan test hampir tanpa ragu akan saya serahkan ke LLM
    Alasannya, test biasanya murah, kalau salah mudah dihapus atau diperbaiki, dan kalau benar memberi nilai tambah
    Hanya saja, LLM sering tidak menguji fungsi inti, jadi untuk test yang paling penting saya tetap harus menulisnya sendiri agar bisa dipercaya
    Sebaliknya, memperbaiki bug atau menambah fitur dengan LLM lebih berisiko
    Karena LLM bisa memakai jalan pintas, atau menulis kode yang hanya lolos test tanpa benar-benar menyelesaikan inti masalah

    • Saat bekerja dengan codebase legacy, saya benar-benar merasakan bahwa pola pikir "kalau test salah nanti bisa diperbaiki" itu berbahaya
      Test kadang menjadi bukti yang lebih dekat pada kebenaran daripada kodenya, jadi test yang salah bisa lebih fatal daripada kode yang salah
      Terutama kalau ada test yang tidak berguna atau maknanya tidak jelas, membedakan apakah itu benar-benar dimaksudkan untuk menjamin fungsi penting jadi hal yang paling menyebalkan

    • Saya menganggap AI mirip kalkulator
      Seperti kalkulator unggul dalam perhitungan yang tak bisa dilakukan kebanyakan orang, AI juga merupakan alat bantu yang memperkuat manusia sebagai jenis kecerdasan baru
      Banyak orang mengira "AI menggantikan manusia", padahal nilai nyatanya justru ada pada melengkapi pekerjaan manusia

    • Saya justru mengambil posisi sebaliknya
      Saya pikir test harus ditulis sendiri dan dipahami sepenuhnya agar benar-benar menjadi tolok ukur, lalu setelah itu kita bisa tenang membiarkan AI mengubah kode sesukanya
      Jika test itu juga dibuat oleh LLM, justru rasa tidak aman saat menyerahkan sisa kode ke AI makin besar

    • Saya pernah mencoba membuat test untuk kode Rust dengan LLM, dan kenyataannya lebih banyak mudarat daripada manfaat
      Jumlah test memang banyak, tetapi cakupan penting sering terlewat
      Karena kode yang dihasilkan terlalu banyak, sulit melihat bagian mana yang belum tercakup
      Saat nanti logika kode diubah, saya jadi harus menyentuh semua test hasil generasi itu

    • Ada ungkapan, "test dianggap benar begitu saja karena tidak ada yang memverifikasinya"
      Karena itulah muncul pola Arrange-Act-Assert
      Unit test favorit saya belakangan ini adalah cara menyimpan nilai input dan output yang diharapkan, lalu memakainya untuk memverifikasi hasil kode
      Karena bahkan corner case bisa diverifikasi dengan mudah, jadi lebih gampang memastikan apakah perilakunya benar-benar sesuai keinginan

  • Menurut pemahaman saya, algoritme RSA juga dibuat dengan cara seperti ini
    Menurut "The Code Book" karya Simon Singh (bukunya entah saya taruh di mana dan tidak ketemu), Rivest dan Shamir menghasilkan ide, sementara Adleman berperan menemukan cacatnya
    Lihat Wikipedia RSA
    Ini juga contoh kolaborasi tim biru/tim merah dalam matematika

    • Dua ilmuwan kognitif yang saya kenal juga mirip seperti itu
      Yang satu punya banyak ide, banyak bicara, dan tidak terstruktur
      Yang lain logis dan presisi, jadi kalau satu orang menulis draf makalah, yang satu lagi akan menghapus semua bagian yang tidak perlu

  • Secara garis besar saya setuju, tetapi framing dari sudut pandang infosec terasa agak aneh
    Sudut pandang "keamanan hanya sekuat bagian yang paling lemah" terlalu sederhana dan berbahaya
    Strategi keamanan harus disusun berlapis
    Karena kita tidak bisa mengharapkan kesempurnaan pada satu lapisan, dibutuhkan banyak lapisan pertahanan
    Serangan dan pertahanan sebenarnya tidak terlalu berbeda, tetapi banyak penyerang menanggung tanggung jawab lebih kecil saat membuat kesalahan, sedangkan pihak bertahan—terutama perusahaan besar—menanggung akibat yang jauh lebih besar
    Namun pihak bertahan punya keuntungan bertarung di kandang sendiri. Mengabaikan itu bisa berujung masalah besar

    • Contoh bahwa percuma menutup pintu kalau jendelanya terbuka tetap merupakan analogi yang tepat
      Yang dimaksud pertahanan berlapis adalah ketika ada banyak lapisan yang memang harus dilewati penyerang untuk mencapai target
      Tapi kalau elemennya berada pada level yang sama seperti pintu dan jendela, maka bagian terlemahlah yang menentukan keseluruhan
      Contoh di web, login utama bisa sempurna, tetapi kalau endpoint lama seperti /v1/legacy/external_backoffice bisa mengakses jaringan internal tanpa autentikasi, maka keseluruhan pertahanan runtuh
      Meski begitu, kalau di dalam masih ada mekanisme penghambat tambahan, dampaknya bisa dibatasi, jadi lapisan pertahanan tetap penting

    • Ucapan "pertahanan sekuat mata rantai terlemahnya" saya pakai dalam arti yang lebih luas
      Saya menambahkan istilah 'seluruh upaya pertahanan' melampaui ungkapan di tulisan asli, tetapi sebenarnya kedua posisi itu sama-sama masuk akal
      Seperti kata Terence, mata rantai terlemah memang bisa benar-benar ditembus, dan itulah sebabnya dibutuhkan banyak lapisan pertahanan
      Ada contoh nyata baru-baru ini: staf helpdesk yang mereset password klien tanpa verifikasi
      Walaupun teknologi keamanan kuat seperti VPN dan 2FA diterapkan, satu mata rantai terlemah berupa 'pemulihan akun' tetap merobohkan semuanya
      Lapisan tambahan di internal memang mendeteksi dan menghentikan penyusup dalam 3 jam, tetapi itu adalah 'meminimalkan dampak', bukan 'mencegah sebelumnya'
      Pada akhirnya, banyak lapisan tetap dibutuhkan untuk mencegah kerusakan
      Belakangan ini industri infosec sendiri juga bergeser fokus dari "pencegahan 100%" ke "mitigasi dampak"
      Sulit mencegah semua risiko, jadi arah strateginya berubah ke mengurangi risiko, meminimalkan permukaan serangan, dan menurunkan tingkat kepercayaan

    • Saya sama sekali bukan pakar keamanan, tetapi saya pernah mendengar bahwa "permukaan serangan yang diperkecil secara ekstrem, memakai protokol open source yang telah tervalidasi" adalah pertahanan terbaik
      Saya penasaran apa bedanya dengan yang dibahas di sini

    • Ini hanya soal analogi yang dipilih kurang tepat
      Ungkapan "mata rantai terlemah" cocok jika ada beberapa langkah yang harus ditembus secara berurutan
      Kalau ada beberapa lapisan pada tingkat yang sama, maka memang masuk akal menargetkan bagian yang paling lemah di antaranya
      Jadi memang ada ruang untuk tafsir ambigu, seperti kekhawatiran tadi

    • Saya menganggap serangan juga merupakan lapisan pertahanan yang lain
      Seperti ungkapan 'serangan terbaik adalah pertahanan terbaik'

  • Dalam cybersecurity, tim merah dan tim biru adalah dua tim dengan kekuatan yang setara
    Tetapi dalam pengembangan perangkat lunak, analogi itu terasa agak dibesar-besarkan
    Test juga adalah kode, dan bug tetap ada
    Muncul paradoks seperti "Who polices the police?" tentang siapa yang mengawasi para pengawas

  • Ini mengingatkan saya pada pembahasan mental John Cleese tentang "mode terbuka vs mode tertutup"
    Ide dikeluarkan sebanyak mungkin dengan sikap terbuka
    Lalu belakangan, dalam mode tertutup, ide buruk disaring dan hanya yang bagus yang dipilih untuk dikembangkan
    Penulis di semua bidang biasanya juga punya editor
    Desain game kartu Magic: the Gathering juga serupa: tim desain membuat draf set, lalu menyerahkannya ke tim pengembangan yang sepenuhnya terpisah untuk divalidasi
    Saya ingin mendengar lebih banyak contoh kolaborasi seperti ini

    • Pemisahan menjadi tim dev dan tim validation juga bisa jadi contoh

  • Menurut saya justru kebalikannya dari tulisan ini
    LLM unggul saat membuat draf awal dengan cepat, sedangkan manusia yang terlatih lebih cocok meninjau hasil LLM secara kritis
    Jadi, LLM lebih cocok sebagai tim biru, dan manusia sebagai tim merah

    • Pada level paling mutakhir, sudut pandang ini justru bisa terbalik
      Sepertinya Tao juga menyinggung situasi ekstrem seperti itu

  • Belakangan saya memakai model dan workflow berbasis agen, dan inilah yang saya rasakan
    Agen-agen seperti ini paling menonjol bukan hanya saat menulis kode, tetapi juga saat dipakai untuk test, pengelolaan, bahkan peran manajemen
    Developer berubah menjadi semacam manajer, yaitu supervisor
    Ia berada pada posisi mengawasi seluruh proses, mulai dari perencanaan task secara menyeluruh (menulis prompt, merapikan cakupan kerja), penulisan test, hingga penulisan kode
    Review memang jadi sangat banyak, tetapi karena saya sendiri berperan sebagai tim merah untuk memastikan hasilnya tidak gampang rusak, saya justru merasa punya kontrol yang lebih besar

  • Sudut pandang ini menarik
    Dalam bisnis pun, kita bisa membaginya menjadi ‘tim biru’ (industri infrastruktur sosial: listrik, minyak, telekomunikasi, perangkat lunak, keuangan, dll.) dan ‘tim merah’ (industri nilai tambah: restoran, ritel khusus, barang mewah, pariwisata, dll.)
    Secara ekonomi, sisi tim biru jauh lebih penting karena industri-industri ini menjadi fondasi seluruh ekonomi, permintaannya tinggi, dan tim ini harus meminimalkan kesalahan
    Sebaliknya, industri tim merah tetap membuat ekonomi berjalan meski tidak ada, tetapi semakin banyak hadir justru meningkatkan kualitas secara keseluruhan
    Dalam contoh Tao juga demikian: software engineer dibayar lebih tinggi daripada QA, dan penulisan pembuktian dianggap lebih bernilai secara ekonomi daripada verifikasi
    Saat Sam Altman menggalang dana untuk pelatihan LLM, ia harus menekankan bahwa "kami berguna seperti tim biru" agar lebih mudah mendapat investasi, dan itu memengaruhi seluruh narasi media
    Padahal kenyataannya lebih cocok untuk penggunaan ala tim merah, tetapi karena harus menunjukkan potensi pengembalian modal, perusahaan-perusahaan akan terus mendorong LLM untuk kegunaan tim biru saja
    Google Glasses, VR, dan wearable juga menunjukkan pola serupa
    Teknologi-teknologi ini berguna sebagai teknologi tim merah di industri niche, tetapi karena tidak bisa menghasilkan ekosistem atau keuntungan raksasa, dari sudut pandang modal mereka diabaikan

  • (Saya bekerja di Microsoft)
    Saya sendiri menjalankan validasi tim merah otomatis untuk sampel RAG menggunakan SDK azure-ai-evaluation
    Di sini, adversarial LLM yang keluar jalur digabungkan dengan paket pyrit, lalu secara otomatis menghasilkan pertanyaan-pertanyaan aneh untuk dilemparkan ke aplikasi, sekaligus memodifikasi pertanyaannya dengan base64, sandi Caesar, urldecode, dan sebagainya
    Hasil nyatanya menarik, dan saya setuju bahwa LLM cukup berguna untuk aktivitas tim merah
    Video demo YouTube
    (Mohon maklum kalau nada suaranya keras, videonya direkam di lokasi yang agak tidak biasa)