LLM spam’ine karşı bir güven ağı kurmak
(blog.tangled.org)- Tangled, kullanıcıların etkileşim kurdukları diğer kullanıcılar için kefil olabilmesini veya onları kınayabilmesini sağlayan vouching özelliğini yerleşik olarak destekliyor ve bunu LLM tabanlı gönderilerin artışına karşı bir güven sinyali olarak kullanıyor
- Kefil olunan kullanıcıların profil fotoğrafının yanında yeşil kalkan simgesi, kınanan kullanıcıların yanında ise kırmızı kalkan simgesi gösteriliyor; bu da onlarla etkileşime girip girmeme konusunda bir ipucu sağlıyor
- LLM tabanlı araçlarla projelere kod gönderme eşiği düştükçe, görünüşte doğru ama ince biçimde hatalı “uncanny valley” tarzı gönderiler artabiliyor ve bakımcılar bu araçları kötüye kullanarak bakım yükü oluşturan katkıcılar için kefil olabilir veya onları kınayabilir
- Kefalet ve kınama kayıtlarında metin tabanlı bir gerekçe alanı bulunuyor ve zayıflatma uygulanıyor; böylece kullanıcılar yalnızca kendilerinin ve kendi çevrelerinin verdiği kararları görebiliyor
- Tangled’da birine kefil olunca veya birini kınayınca, kullanıcının PDS üzerinde herkese açık bir kayıt oluşturuluyor; appview bunu toplayıp issue, yorum, pull request ve pull request yorumlarındaki profillerin üstünde bir kefalet “şapkası” gösteriyor
Tangled’ın güven sinyalleri
- Tangled, kullanıcıların etkileşim kurdukları diğer kullanıcılar için kefil olabilmesini veya onları kınayabilmesini sağlayan vouching özelliğini yerleşik olarak destekliyor
- Kefil olunan kullanıcıların profil fotoğrafının yanında yeşil kalkan simgesi, kınanan kullanıcıların yanında ise kırmızı kalkan simgesi gösteriliyor
- Kullanıcılar, kendi çevrelerinin verdiği kefalet ve kınama kararlarını da görebiliyor ve bunu etkileşime girip girmeme konusunda bir sinyal olarak kullanabiliyor
- LLM tabanlı araçlarla projelere kod gönderme eşiği düştükçe, görünüşte doğru ama ince biçimde hatalı “uncanny valley” tarzı gönderiler artabiliyor
- Tangled ağındaki bakımcılar, bu araçları kötüye kullanarak bakım yükü oluşturan katkıcılar için kefil olabilir veya onları kınayabilir
Nasıl çalışıyor ve tasarım kısıtları
-
Dikkatli tasarım
- Kefalet ve kınama kayıtlarında metin tabanlı bir gerekçe alanı bulunuyor
- Zayıflatma (attenuation) uygulanıyor; böylece kullanıcılar yalnızca kendilerinin ve kendi çevrelerinin verdiği kararları görebiliyor
- Şu anda kınanan kullanıcılar projeden engellenmiyor; yalnızca arayüzün bazı bölümlerinde kırmızı bir uyarı etiketi gösteriliyor
-
Planlanan ek özellikler
- Zaman içinde bakımcılar ve katkıcılar projeden ayrılabileceği için, kefalet zamanla zayıflayacak ve ara sıra yenilenmesi gerekecek
- Bir PR birleştirildikten hemen sonra kullanıcı için kefil olunursa, ilgili PR’nin kefalet kaydına kanıt olarak eklenmesini sağlayan kanıt takibi özelliği eklenebilir
-
Herkese açık kayıtlar ve gösterim yerleri
- Tangled’da birine kefil olunca veya birini kınayınca, kullanıcının PDS üzerinde herkese açık bir kayıt oluşturuluyor
- Bu kayıt, bunun bir kefalet mi yoksa kınama mı olduğunu ve isteğe bağlı gerekçeyi içeriyor
- Tangled appview, ağ genelindeki kefalet verilerini topluyor ve etkileşim noktalarındaki profillerin üstünde bir kefalet “şapkası” gösteriyor
- Gösterim yerleri issue’lar, issue yorumları, pull request’ler ve pull request yorumları
-
Çevre tabanlı görünürlük
- Yalnızca kullanıcının doğrudan kefil olduğu ya da kınadığı kişilerde veya kullanıcının kefil olduğu birinin daha sonra kefil olduğu ya da kınadığı kişilerde bu şapka gösteriliyor
- Şapkaya tıklandığında, kullanıcının kendi çevresi içinde bu kişiye kimin kefil olduğu veya onu kınadığı görülebiliyor
- Şu anda kınamanın sonucu yalnızca bu şapkanın gösterilmesi; ileride sonuçlar değişebilir, ancak şimdilik karar vermeye yardımcı olan bir sinyal olarak kullanılıyor
1 yorum
Lobste.rs görüşleri
Daha iyi ve daha basit yöntem, güçlü bir LLM karşıtı politika oluşturup bunu düzgün şekilde uygulamak. GitHub gibi LLM kullanımını teşvik eden veya AI yanlısı platformlardan da uzak durmak gerekir
%100 etkili olmaz ama LLM kullanımını gizlemeye çalışanlar da çoğu zaman ortaya çıkar; o noktada hemen yasaklamak yeterlidir. Şirketler LLM spam'ini zorlarsa şirketin tamamını engelleyin; kendi barındırdığınız forge ise güvenlik duvarında o şirketin ağını kapatın
İş ispatı gibi yarım yamalak sistemler ilk kez katkı yapanları ve yoldan geçen katkıcıları cezalandırır; güven kefaleti de sonuçta bir iş ispatıdır. Zayıf olanları hırpalamak yerine kötü aktörleri hızlıca vurmak daha etkilidir
Alıntıda da “bu aracı kötüye kullanarak bakım yükü yaratan katkıcıları” kefil göstermek ya da kınamak için kullanıldığı söyleniyor
Sırf biri LLM cadı avı yapıyor diye insanları platform düzeyinde yasağı kabullenmeye zorlamak ters teper. Burada ya da HN'de de bazen bir yazının LLM ile yazıldığına dair yanlış şüpheler görüyoruz; bunu PR'lerde yönetmek zorunda kalmak gerçekten yorucu olurdu
Bu sistem, araçları kötüye kullanıp bakım yükü oluşturan katkıcıları dışlamaya çalışıyor; eski usul yöntemlerle bakım yükü yaratan katkıcılara karşı da kullanılabilir. Daha gelişmiş bir commit yetkisi modeli gibi duruyor
LLM karşıtı bir politikanız varsa bununla uygulayabilirsiniz; taciz karşıtı politikanız varsa onu da bununla uygulayabilirsiniz
PR gönderimiyle doğrudan bağlantılı değilse bu, iyimser bakınca işe yaramaz; kötü ihtimalle ise zararlı bir moderasyon sistemi olur. Birileri geçmişte LLM kullanmış kullanıcıları topluca kınamaya başlar; sonra başka gerekçelerle de sürü halinde saldırılar gelebilir
Web of trust fikri başlı başına güzel ama bu proje teknik yönü ele alıp toplumsal yönü ele almıyor. Bir moderasyon sistemi kurarken “bunu suistimal olmadan nasıl ölçekleriz” sorusunu sistem çıktısına işleyen büyük bir bölüm yoksa sürprizlerle karşılaşılır
Toplumsal bir sorunu çözmek için önce toplumsal motivasyon eklenmiş bir deney olması açısından epey ilginç ve tasarımı da akıllıca görünüyor
“Kınanan kullanıcı için hiçbir sonuç yok. Sadece şapka alıyorlar” ise bunun anlamı ne? Sonuçta PR işleme yükü yine aynı kalıyor
Örneğin engelleme ya da önceliği düşürme gibi seçenekler mümkün olabilir
Birden fazla alan adı açıp her birinde bir milyon kullanıcı oluşturup bunların birbirine kefil olmasını engelleyen bir mekanizma var mı? O zaman başkaları benden ayırması zor itibar paketleri satın alabilir
Açıkçası lobste.rs'in davet ağacı modeli daha iyi görünüyor. Biri suistimale başlarsa tüm alt ağacı kesmek kolay olur ve daha yavaş büyümesi de aslında avantajdır
human.json'da muhtemelen kimse böyle bir ağdaki düğümlere kefil olmaz ya da içeri gelen bağlantı çok az olacağı için mesafe büyük çıkar. Bu, sitelerin ağa giremeyeceği anlamına gelmez ama kefalet ve güvensizlik onları hızla dışarı itebilir. Pratikte nasıl işleyeceğini görmek gerek
“X, Y, Z kefil oldu” bilgisini satır içinde ya da mouseover ile gösteren, petnames benzeri bir UI katmanı güzel olurdu
Bunun “itibar çiftçiliğini” ne kadar önleyebileceğini merak ediyorum
Sonuçta tüm veriler açık; biri tangled2.org kurup küresel bir grafik de oluşturabilir. Ama UI tasarımı, kişinin kendi çemberinin dışına çıkıldıkça kefaletin bilinçli olarak zayıflaması üzerine kurulu
Fikir güzel ama belki de sadece doğal biçimde iletişim kurmak yeterlidir. En ufak iletişim bile fazla derli toplu ve tutarlı
Yazarken birkaç yazım hatası bırakmak gerçek insana özgü bir parmak izi oluşturur
Bu fikir hoşuma gitti. lobste.rs'in kendi kullandığı tree of trust modelini hatırlatıyor
Açık kaynağın doğuşuyla neredeyse aynı dönemde yürütülen trust metric research çalışmalarını hızla yeniden yapıyor gibiyiz. @raph buna nasıl bakar merak ediyorum
Kusursuz değildi ama hiçbir şey olmamasından kesinlikle çok daha iyiydi
Sanki bundan zaten altı tane var gibi; neden mevcut olanlardan birine katılmak yerine bir tane daha yapılıyor?