Xây dựng web lòng tin để chống lại spam từ LLM

• Tangled hỗ trợ sẵn tính năng vouching, cho phép người dùng bảo chứng hoặc lên án những người dùng khác mà họ đã tương tác, và dùng đây như một tín hiệu tin cậy để đối phó với sự gia tăng của các bài gửi dựa trên LLM
• Người dùng được bảo chứng sẽ hiển thị biểu tượng khiên màu xanh lá cạnh ảnh đại diện, còn người dùng bị lên án sẽ hiển thị biểu tượng khiên màu đỏ, trở thành manh mối để quyết định có nên tương tác hay không
• Khi các công cụ dựa trên LLM làm giảm rào cản gửi mã vào dự án, số lượng các bài gửi kiểu “thung lũng kỳ lạ” trông có vẻ đúng nhưng sai lệch một cách tinh vi có thể tăng lên, và maintainer có thể bảo chứng hoặc lên án những người đóng góp lạm dụng các công cụ này để tạo thêm gánh nặng
• Việc bảo chứng/lên án bao gồm trường lý do dạng văn bản và áp dụng cơ chế suy giảm, nên người dùng chỉ có thể thấy những đánh giá do chính họ và vòng kết nối của họ đưa ra
• Khi bảo chứng hoặc lên án trên Tangled, một bản ghi công khai sẽ được tạo trên PDS của người dùng, và appview sẽ tổng hợp dữ liệu này để hiển thị “mũ” bảo chứng phía trên hồ sơ trong issue, bình luận, pull request và bình luận pull request

---

Tín hiệu tin cậy của Tangled

• Tangled hỗ trợ sẵn tính năng vouching, cho phép người dùng bảo chứng hoặc lên án những người dùng khác mà họ đã tương tác
• Người dùng được bảo chứng sẽ hiển thị biểu tượng khiên màu xanh lá cạnh ảnh đại diện, còn người dùng bị lên án sẽ hiển thị biểu tượng khiên màu đỏ
• Người dùng cũng có thể xem các đánh giá bảo chứng/lên án do vòng kết nối của mình đưa ra và dùng chúng như tín hiệu để quyết định có nên tương tác hay không
• Khi các công cụ dựa trên LLM làm giảm rào cản gửi mã vào dự án, số lượng các bài gửi kiểu “thung lũng kỳ lạ” trông có vẻ đúng nhưng sai lệch một cách tinh vi có thể tăng lên
• Các maintainer trong mạng Tangled có thể bảo chứng hoặc lên án những người đóng góp lạm dụng các công cụ này để tạo thêm gánh nặng bảo trì

Cách hoạt động và các ràng buộc thiết kế

• Thiết kế thận trọng

  • Việc bảo chứng/lên án bao gồm trường lý do dạng văn bản
  • Cơ chế suy giảm (attenuation) được áp dụng, nên người dùng chỉ có thể thấy những đánh giá do chính họ và vòng kết nối của họ đưa ra
  • Hiện tại, người dùng bị lên án không bị chặn khỏi dự án; chỉ có một nhãn cảnh báo màu đỏ xuất hiện ở một số phần của UI

• Tính năng dự kiến bổ sung

  • Theo thời gian, maintainer và người đóng góp có thể rời dự án, vì vậy bảo chứng sẽ yếu dần theo thời gian và cần được làm mới định kỳ
  • Có thể sẽ bổ sung tính năng theo dõi bằng chứng, trong đó nếu bảo chứng một người dùng ngay sau khi hợp nhất PR thì PR đó sẽ được thêm làm bằng chứng cho bản ghi bảo chứng

• Bản ghi công khai và vị trí hiển thị

  • Khi bảo chứng hoặc lên án ai đó trên Tangled, một bản ghi công khai sẽ được tạo trên PDS của người dùng
  • Bản ghi này bao gồm đó là bảo chứng hay lên án, cùng với lý do tùy chọn
  • Tangled appview sẽ tổng hợp dữ liệu bảo chứng trên toàn mạng và hiển thị “mũ” bảo chứng phía trên hồ sơ tại các điểm tương tác
  • Các vị trí hiển thị gồm issue, bình luận issue, pull request và bình luận pull request

• Khả năng hiển thị dựa trên vòng kết nối

  • “Mũ” chỉ hiển thị phía trên một người dùng khi đó là người mà chính bạn đã bảo chứng/lên án, hoặc là người được một người mà bạn đã bảo chứng tiếp tục bảo chứng/lên án
  • Nhấp vào “mũ” để xem ai trong vòng kết nối của bạn đã bảo chứng hoặc lên án người dùng đó
  • Hiện tại, kết quả của việc lên án chỉ dừng ở việc hiển thị “mũ”; trong tương lai kết quả có thể thay đổi, nhưng lúc này nó được dùng như một tín hiệu hỗ trợ phán đoán

[GN⁺]

Ý kiến trên Lobste.rs

• Cách tốt hơn và đơn giản hơn là xây dựng chính sách chống LLM mạnh tay và thực thi nó cho đúng. Cũng nên rời khỏi các nền tảng khuyến khích dùng LLM hoặc có xu hướng thân AI như GitHub
  Không hiệu quả 100%, nhưng các trường hợp cố che giấu việc dùng LLM đa phần rồi cũng lộ ra, lúc đó cấm ngay là được. Nếu doanh nghiệp đẩy spam bằng LLM vào thì hãy chặn cả công ty, còn nếu là forge tự host thì có thể chặn mạng của công ty đó ngay từ firewall
  Những hệ thống nửa vời kiểu proof-of-work gây bất lợi cho người đóng góp lần đầu và người ghé qua đóng góp, còn bảo chứng niềm tin thì rốt cuộc cũng là một dạng proof-of-work. Đừng làm phiền người yếu thế, đánh nhanh vào kẻ xấu sẽ hiệu quả hơn

  • Mục tiêu của Tangled có vẻ gần với việc né spam hơn là né chính LLM
    Ngay trong phần trích dẫn cũng nói là đang bảo chứng hoặc chỉ trích “những người đóng góp lạm dụng công cụ này để tạo thêm gánh nặng bảo trì”
  • Muốn vậy thì có lẽ sẽ cần một nền tảng hoàn toàn mới, mà hiệu quả chắc cũng không lớn. Nhiều dự án vẫn chấp nhận các bản gửi có dùng LLM, và nhiều lập trình viên cũng thấy ổn khi thay đổi theo từng dự án
    Bắt mọi người chấp nhận lệnh cấm ở cấp nền tảng chỉ vì ai đó mở cuộc săn phù thủy LLM sẽ phản tác dụng. Ở đây hay trên HN cũng thỉnh thoảng có những nghi ngờ sai rằng bài viết do LLM tạo ra, nếu còn phải xử lý chuyện đó trong PR thì thật sự rất mệt
  • Mục tiêu được nêu rõ ở đây không phải là “LLM” mà là spam
    Hệ thống này nhằm né những người đóng góp tạo gánh nặng bảo trì bằng cách lạm dụng công cụ, và cũng có thể áp dụng với những người tạo gánh nặng bảo trì theo kiểu cũ. Nó trông giống một mô hình quyền commit được phát triển thêm
  • Đây không phải là thứ nói về việc ai đó đã vi phạm chính sách cụ thể nào, mà gần hơn với một cách phản hồi khi ai đó vi phạm chính sách
    Nếu có chính sách chống LLM thì có thể dùng cái này để thực thi, còn nếu có chính sách cấm quấy rối thì cũng có thể thực thi bằng cách này

• Nếu không gắn trực tiếp với việc có được gửi PR hay không, thì cùng lắm thứ này là vô dụng, còn tệ hơn thì sẽ trở thành một hệ thống điều phối độc hại. Sẽ có người đi chỉ trích hàng loạt các tài khoản từng dùng LLM, rồi sau đó có thể xuất hiện cả những đợt tấn công theo bầy đàn vì các lý do khác
  Web of trust tự nó rất hay, nhưng dự án này chỉ xử lý khía cạnh kỹ thuật chứ không đụng tới khía cạnh xã hội. Nếu làm một hệ thống điều phối mà không có một phần lớn nói rõ “làm sao mở rộng mà không bị lạm dụng” được phản ánh vào kết quả của hệ thống, thì sớm muộn gì cũng sẽ có chuyện bất ngờ xảy ra

  • Bảo chứng chỉ hiện những gì tôi đã làm hoặc những gì các tài khoản tôi bảo chứng đã làm, nên việc chỉ trích hàng loạt nhắm vào người dùng xa lạ được thiết kế để không hiện ra
  • Tôi cũng lo chuyện đó có thể xảy ra, nhưng chắc phải đợi đến khi có vụ hủy diệt danh tiếng nổi tiếng đầu tiên nổ ra thì mới biết chắc được
  • Việc đưa khái niệm suy giảm vào là một bước đi đúng hướng. Hiện giờ nó cũng chưa trực tiếp kiểm soát chính sách
    Đây là một thử nghiệm khá thú vị khi gắn động lực xã hội vào trước để giải quyết vấn đề xã hội, và thiết kế cũng có vẻ thông minh

• Nếu “người dùng bị chỉ trích không phải chịu hậu quả gì cả. Họ chỉ có thêm cái mũ”, thì rốt cuộc nó có ý nghĩa gì? Cuối cùng thì vẫn phải xử lý PR như cũ

  • Đây là điểm khởi đầu để xem hệ thống vận hành thế nào, và có vẻ sau này sẽ thêm những tính năng như chặn theo mức độ tin cậy
  • Có thể sẽ được thêm sau. Ban đầu tôi muốn thử điều mà @yorickpeterse nói tới, rồi sau đó muốn cho người dùng chọn cách “phản ứng” với người dùng bị chỉ trích
    Ví dụ như chặn hoặc hạ ưu tiên

• Có cơ chế nào ngăn chuyện ai đó tạo ra nhiều domain, rồi trong mỗi domain tạo cả triệu người dùng để họ bảo chứng lẫn nhau không? Như vậy những người khác có thể mua từ tôi một gói danh tiếng rất khó tách bạch
  Tôi vẫn thấy mô hình cây lời mời của lobste.rs tốt hơn. Một khi ai đó bắt đầu lạm dụng thì rất dễ cắt cả cây con bên dưới, và nó phát triển chậm hơn, mà điều đó lại là ưu điểm

  • Tôi thích mô hình human.json: https://codeberg.org/robida/human.json đặc biệt là cách nó được trực quan hóa trong phần mở rộng. Nó tìm đường đi ngắn nhất tới các site mà bạn tin, tô màu theo khoảng cách và còn hiện cả đường đi
    Trong human.json, có lẽ sẽ chẳng ai bảo chứng cho các nút trong mạng lưới kiểu đó, hoặc các liên kết đi vào quá ít nên khoảng cách sẽ rất lớn. Điều đó không có nghĩa là không thể đưa site vào mạng lưới, nhưng bảo chứng và bất tín có thể nhanh chóng đẩy nó ra ngoài. Thực tế vận hành ra sao thì vẫn còn phải xem
  • Việc gắn nhãn là theo từng người dùng. Nếu tôi chỉ bảo chứng cho những người sẽ không đi bảo chứng cho hàng triệu tài khoản ngẫu nhiên, thì hoạt động kiểu tấn công Sybil hoàn toàn không ảnh hưởng tới bảo chứng của tôi
    Sẽ hay nếu có một lớp UI giống petnames để có thể xem “X, Y, Z đã bảo chứng” theo dạng inline hoặc khi rê chuột
  • Sẽ rất thú vị nếu có một mô hình chấm điểm các mức độ bảo chứng khác nhau. Dùng cây lời mời kiểu lobste.rs, ví dụ 100 người bảo chứng nhưng đều có chung một tổ tiên, so với 5 người bảo chứng từ những đường đi rất khác nhau, thì 5 cái sau nên được tính nặng hơn
    Tôi tò mò không biết cách này có thể ngăn nuôi danh tiếng đến mức nào
  • Cùng lắm thì bot chỉ có thể tạo ra vòng tròn bảo chứng của riêng chúng. Phần còn lại của mạng lưới sẽ không nhìn thấy các quyết định của vòng tròn đó, trừ khi họ bắt đầu bảo chứng cho các tài khoản bot ấy
    Dù sao thì mọi dữ liệu đều công khai, nên ai đó hoàn toàn có thể tạo tangled2.org để dựng đồ thị toàn cục, nhưng trong UI thì chủ ý thiết kế để bảo chứng suy yếu dần khi đi ra ngoài vòng tròn của chính mình

• Ý tưởng thì hay, nhưng tôi tự hỏi sao không giao tiếp tự nhiên thôi. Mọi kiểu giao tiếp vụn vặt ở đây đều quá chỉn chu và nhất quán
  Để lại lỗi chính tả trong những gì mình gõ ra đôi khi lại tạo nên dấu vân tay rất con người

• Tôi thích ý tưởng này. Nó làm tôi nhớ tới tree of trust mà chính lobste.rs đang dùng

  • Hoặc cũng có human.json. Trên site của tôi, tôi đang nghĩ tới việc đổi tên nó thành meat.json

• Cảm giác như chúng ta đang nhanh chóng tái hiện lại nghiên cứu trust metric từng diễn ra gần như cùng thời với sự ra đời của mã nguồn mở. Tôi tò mò @raph sẽ nhìn việc này thế nào

  • Thật vui khi thấy lại một cái tên từ xưa. Hệ thống meta-moderation ba tầng của Slashdot cũng xứng đáng được ghi nhận
    Nó không hoàn hảo, nhưng chắc chắn vẫn tốt hơn rất nhiều so với không có gì

• Hình như đã có khoảng nửa tá thứ như thế này rồi, sao không tham gia cái đang tồn tại mà lại làm thêm một cái nữa?

  • https://xkcd.com/927/