สร้างเว็บแห่งความไว้วางใจเพื่อต่อกรกับสแปมจาก LLM

 (blog.tangled.org)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tangled รองรับฟีเจอร์ vouching ในตัว ซึ่งช่วยให้ผู้ใช้สามารถรับรองหรือประณามผู้ใช้อื่นที่ตนเคยมีปฏิสัมพันธ์ด้วย และนำมาใช้เป็นสัญญาณความน่าเชื่อถือเพื่อรับมือกับจำนวนโพสต์ส่งเข้าที่อิง LLM ที่เพิ่มขึ้น
  • ผู้ใช้ที่ได้รับการรับรองจะมี ไอคอนโล่สีเขียว แสดงข้างรูปโปรไฟล์ ส่วนผู้ใช้ที่ถูกประณามจะมี ไอคอนโล่สีแดง เป็นเบาะแสประกอบการตัดสินใจว่าจะโต้ตอบด้วยหรือไม่
  • เมื่อเครื่องมือที่อิง LLM ทำให้การส่งโค้ดเข้าโปรเจกต์มีอุปสรรคลดลง อาจทำให้มี งานส่งแบบ “uncanny valley” เพิ่มขึ้น ซึ่งดูเผินๆ เหมือนถูกต้องแต่ผิดแบบแนบเนียน และผู้ดูแลสามารถรับรองหรือประณามผู้ร่วมพัฒนาที่ใช้เครื่องมือเหล่านี้ผิดทางจนสร้างภาระได้
  • การรับรองและการประณามมี ช่องระบุเหตุผล แบบข้อความ และมีการใช้การลดทอนผลกระทบ ทำให้ผู้ใช้เห็นได้เฉพาะคำตัดสินที่ตนเองและวงเครือข่ายของตนเป็นผู้ให้ไว้
  • เมื่อรับรองหรือประณามใน Tangled ระบบจะสร้างบันทึกสาธารณะบน PDS ของผู้ใช้ และ appview จะรวบรวมข้อมูลเหล่านี้เพื่อแสดง “หมวก” การรับรองเหนือโปรไฟล์ใน issue, comment, pull request และคอมเมนต์ของ pull request

สัญญาณความน่าเชื่อถือของ Tangled

  • Tangled รองรับฟีเจอร์ vouching ในตัว ซึ่งช่วยให้ผู้ใช้สามารถรับรองหรือประณามผู้ใช้อื่นที่ตนเคยมีปฏิสัมพันธ์ด้วย
  • ผู้ใช้ที่ได้รับการรับรองจะแสดง ไอคอนโล่สีเขียว ข้างรูปโปรไฟล์ และผู้ใช้ที่ถูกประณามจะแสดง ไอคอนโล่สีแดง
  • ผู้ใช้ยังสามารถเห็นการตัดสินรับรองหรือประณามที่มาจากวงเครือข่ายของตน และใช้เป็นสัญญาณประกอบการตัดสินใจว่าจะโต้ตอบด้วยหรือไม่
  • เมื่อเครื่องมือที่อิง LLM ทำให้การส่งโค้ดเข้าโปรเจกต์มีอุปสรรคลดลง ก็อาจทำให้มีงานส่งแบบ “uncanny valley” เพิ่มขึ้น ซึ่งดูเผินๆ เหมือนถูกต้องแต่ผิดแบบแนบเนียน
  • ผู้ดูแลในเครือข่าย Tangled สามารถรับรองหรือประณามผู้ร่วมพัฒนาที่ใช้เครื่องมือเหล่านี้ผิดทางจนเพิ่มภาระการดูแลรักษาได้

วิธีการทำงานและข้อจำกัดด้านการออกแบบ

  • การออกแบบอย่างรอบคอบ

    • การรับรองและการประณามมี ช่องระบุเหตุผล แบบข้อความ
    • มีการใช้การลดทอนผลกระทบ (attenuation) ทำให้ผู้ใช้เห็นได้เฉพาะคำตัดสินที่ตนเองและวงเครือข่ายของตนเป็นผู้ให้ไว้
    • ปัจจุบันผู้ใช้ที่ถูกประณามยังไม่ถูกบล็อกจากโปรเจกต์ โดยจะแสดงเพียงป้ายเตือนสีแดงในบางส่วนของ UI

  • ฟีเจอร์ที่วางแผนจะเพิ่ม

    • เมื่อเวลาผ่านไป ผู้ดูแลและผู้ร่วมพัฒนาอาจออกจากโปรเจกต์ไปได้ ดังนั้นการรับรองจึงควรอ่อนแรงลงตามเวลาและต้องมีการต่ออายุเป็นระยะ
    • อาจมีการเพิ่มฟีเจอร์ การติดตามหลักฐาน ที่เมื่อรับรองผู้ใช้ทันทีหลัง merge PR ระบบจะเพิ่ม PR นั้นเป็นหลักฐานของบันทึกการรับรอง

  • บันทึกสาธารณะและตำแหน่งการแสดงผล

    • เมื่อรับรองหรือประณามใครบางคนใน Tangled ระบบจะสร้าง บันทึกสาธารณะ บน PDS ของผู้ใช้
    • บันทึกนี้จะมีข้อมูลว่าเป็นการรับรองหรือการประณาม พร้อมเหตุผลแบบไม่บังคับ
    • Tangled appview จะรวบรวมข้อมูลการรับรองจากทั้งเครือข่าย และแสดง “หมวก” การรับรองเหนือโปรไฟล์ที่จุดซึ่งเกิดการโต้ตอบ
    • ตำแหน่งที่แสดงได้แก่ issue, คอมเมนต์ของ issue, pull request และคอมเมนต์ของ pull request

  • การมองเห็นแบบอิงวงเครือข่าย

    • ระบบจะแสดงหมวกเหนือผู้ใช้ก็ต่อเมื่อเป็นผู้ที่ผู้ใช้รับรองหรือประณามโดยตรง หรือเป็นผู้ที่คนซึ่งผู้ใช้รับรองได้ไปรับรองหรือประณามต่ออีกทอดหนึ่ง
    • เมื่อคลิกที่หมวก ผู้ใช้จะตรวจสอบได้ว่าใครบ้างในวงเครือข่ายของตนที่รับรองหรือประณามผู้ใช้นั้น
    • ปัจจุบันผลของการประณามมีเพียงการแสดงหมวกเท่านั้น แม้อนาคตผลลัพธ์อาจเปลี่ยนไปได้ แต่ตอนนี้ถูกใช้เป็นสัญญาณช่วยในการตัดสินใจ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Lobste.rs

  • วิธีที่ดีกว่าและง่ายกว่าคือออก นโยบายต่อต้าน LLM ที่เข้มงวด และบังคับใช้อย่างจริงจัง ควรออกจากแพลตฟอร์มที่สนับสนุนการใช้ LLM หรือมีแนวโน้มโปร-AI อย่างเช่น GitHub ด้วย
    มันอาจไม่ได้ผล 100% แต่กรณีที่พยายามปกปิดการใช้ LLM ส่วนใหญ่ก็มักดูออก และตอนนั้นก็แบนได้ทันที ถ้าบริษัทไหนดัน สแปมจาก LLM มาก็ บล็อกทั้งบริษัท ไปเลย และถ้าเป็น forge ที่โฮสต์เองก็ปิดกั้นเครือข่ายของบริษัทนั้นที่ไฟร์วอลล์ได้
    ระบบครึ่งๆ กลางๆ อย่าง proof of work กลับสร้างภาระให้ผู้มีส่วนร่วมหน้าใหม่และคนที่แวะมาช่วยเป็นครั้งคราว ส่วนการรับรองความน่าเชื่อถือก็สุดท้ายก็เป็น proof of work เช่นกัน แทนที่จะไประรานคนที่อ่อนแอกว่า สู้จัดการผู้กระทำไม่ดีให้ไวจะมีประสิทธิภาพกว่า

    • เป้าหมายของ Tangled ดูจะใกล้เคียงกับการ หลบเลี่ยงสแปม มากกว่าการหลีกเลี่ยง LLM เอง
      แม้แต่ในคำอ้างอิงก็ระบุว่าเป็นการรับรองหรือประณามผู้มีส่วนร่วมที่ ใช้เครื่องมือนี้ในทางที่ผิด จนสร้างภาระการดูแลรักษา
    • ถ้าอย่างนั้นก็น่าจะต้องใช้แพลตฟอร์มใหม่ทั้งหมด และก็ดูไม่น่าจะได้ผลมากนัก หลายโปรเจ็กต์ก็รับงานที่ส่งมาจาก LLM อยู่แล้ว และนักพัฒนาจำนวนมากก็โอเคกับการปรับว่าจะใช้หรือไม่ใช้ตามแต่ละโปรเจ็กต์
      การพยายามบังคับให้คนยอมรับการแบนระดับแพลตฟอร์มเพียงเพราะมีบางคนล่าแม่มดเรื่อง LLM นั้นจะให้ผลย้อนกลับ ที่นี่หรือบน HN เองก็ยังมีการสงสัยผิดๆ เป็นครั้งคราวว่าบทความถูกเขียนด้วย LLM ถ้าต้องมาจัดการเรื่องนี้ใน PR ก็คงเหนื่อยมาก
    • เป้าหมายที่ระบุไว้อย่างชัดเจนที่นี่ไม่ใช่ “LLM” แต่คือการหลีกเลี่ยง สแปม
      ระบบนี้มีไว้หลีกเลี่ยงผู้มีส่วนร่วมที่ใช้เครื่องมือผิดทางจนสร้างภาระในการดูแลรักษา และก็ใช้ได้กับผู้มีส่วนร่วมที่สร้างภาระแบบเดิมๆ ด้วย ดูเหมือน โมเดลสิทธิ์ commit ที่พัฒนาต่อไปอีกขั้น
    • นี่ไม่ใช่เรื่องว่าละเมิดนโยบายข้อไหนโดยเฉพาะ แต่ใกล้เคียงกับคำตอบสำหรับตอนที่ใครสักคน ละเมิดนโยบายแล้ว มากกว่า
      ถ้ามีนโยบายต่อต้าน LLM ก็ใช้สิ่งนี้บังคับใช้ได้ ถ้ามีนโยบายห้ามคุกคาม ก็ใช้สิ่งนี้บังคับใช้ได้เช่นกัน

  • ถ้าไม่ได้เชื่อมตรงกับการส่ง PR ระบบนี้ต่อให้มองในแง่ดีก็ดูไม่มีประโยชน์ และในแง่ร้ายอาจกลายเป็น ระบบกลั่นกรองที่เป็นพิษ ได้ ใครสักคนอาจประณามผู้ใช้จำนวนมากที่เคยใช้ LLM และหลังจากนั้นก็อาจเกิดการรุมโจมตีเป็นกลุ่มด้วยเหตุผลอื่นต่อ
    web of trust เองเป็นแนวคิดที่ยอดเยี่ยม แต่โปรเจ็กต์นี้พูดถึงแค่ด้านเทคนิคโดยไม่แตะด้านสังคมเลย ถ้าจะสร้างระบบกลั่นกรองแต่ไม่มีส่วนใหญ่ๆ ที่ฝังผลลัพธ์ของระบบไว้ว่า “จะขยายอย่างไรโดยไม่ให้ถูกใช้ในทางที่ผิด” ก็คงมีเรื่องให้ตกใจแน่

    • การรับรองจะแสดงเฉพาะสิ่งที่ฉันทำ หรือสิ่งที่บัญชีที่ฉันรับรองเป็นคนทำเท่านั้น จึงถูกออกแบบมาให้มองไม่เห็นการ ประณามแบบถล่มใส่คนหมู่มาก ต่อผู้ใช้ที่ไม่รู้จัก
    • ผมก็เป็นห่วงว่าจะเกิดแบบนั้น แต่คงต้องรอดูจนกว่าจะมี เหตุการณ์ cancel ครั้งใหญ่ ครั้งแรกถึงจะรู้ชัด
    • การมีแนวคิดเรื่อง การลดทอน อยู่ในระบบถือเป็นก้าวไปในทิศทางที่ถูกต้อง ตอนนี้มันยังไม่ได้ควบคุมนโยบายโดยตรง
      มันเป็นการทดลองที่เอาแรงจูงใจทางสังคมมาใส่ก่อนเพื่อแก้ปัญหาทางสังคม เลยน่าสนใจทีเดียว และการออกแบบก็ดูฉลาด

  • ถ้า “ผู้ใช้ที่ถูกประณามจะไม่มีผลลัพธ์อะไรเลย แค่ได้หมวกเพิ่มมา” แล้วมันมีความหมายอะไร? สุดท้ายก็ยังต้อง จัดการ PR เหมือนเดิม

    • นี่เป็นจุดเริ่มต้นเพื่อดูว่าระบบทำงานอย่างไร และดูเหมือนว่าในภายหลังจะมีฟีเจอร์อย่าง การบล็อกตามระดับความน่าเชื่อถือ เพิ่มเข้ามา
    • อาจเพิ่มทีหลังได้ ตอนแรกอยากทดสอบสิ่งที่ @yorickpeterse พูดถึงก่อน แล้วหลังจากนั้นก็อยากให้ผู้ใช้เลือกได้ว่าจะ “ตอบสนอง” ต่อผู้ใช้ที่ถูกประณามอย่างไร
      เช่น บล็อก หรือลดลำดับความสำคัญ เป็นต้น

  • มีกลไกอะไรป้องกันไม่ให้ฉันสร้างโดเมนหลายอัน แล้วสร้างผู้ใช้ล้านคนในแต่ละอันให้มารับรองกันเองไหม? ถ้าอย่างนั้นคนอื่นก็จะสามารถซื้อ ชุดชื่อเสียง จากฉันที่แยกออกจากของจริงได้ยาก
    ถ้าอย่างนั้นโมเดลต้นไม้คำเชิญของ lobste.rs ดูดีกว่า เพราะถ้าใครเริ่มใช้ในทางที่ผิด ก็สามารถตัดทั้งกิ่งย่อยทิ้งได้ง่าย และมันโตช้ากว่าด้วย ซึ่งกลับเป็นข้อดี

    • ผมชอบโมเดล human.json: https://codeberg.org/robida/human.json โดยเฉพาะวิธีที่มันแสดงภาพผ่านส่วนขยายได้ดีมาก มันหาทางที่สั้นที่สุดไปยังไซต์ที่คุณเชื่อถือ แสดงระยะทางด้วยสี และโชว์เส้นทางให้ดูด้วย
      ใน human.json น่าจะไม่มีใครรับรองโหนดของเครือข่ายแบบนั้น หรือไม่ก็มีการเชื่อมเข้ามาน้อยเกินไปจนทำให้ระยะห่างสูงมาก ไม่ได้แปลว่าเอาไซต์เข้าเครือข่ายไม่ได้ แต่การรับรองและการไม่ไว้วางใจน่าจะช่วยผลักมันออกไปได้เร็ว ยังต้องรอดูว่าในทางปฏิบัติจะทำงานอย่างไร
    • การติดป้ายกำกับเป็นรายผู้ใช้ ถ้าฉันรับรองเฉพาะคนที่ไม่ไปรับรอง บัญชีสุ่มนับล้าน กิจกรรมแบบ การโจมตีแบบ Sybil ก็จะไม่ส่งผลต่อการรับรองของฉันเลย
      น่าจะดีถ้ามีชั้น UI คล้าย petnames ที่ให้ดูได้แบบอินไลน์หรือเมาส์โอเวอร์ว่า “X, Y, Z รับรองอยู่”
    • ถ้ามีโมเดลให้คะแนน ระดับของการรับรองที่แตกต่างกัน ก็น่าจะน่าสนใจ เช่น ใช้ต้นไม้คำเชิญแบบ lobste.rs มาช่วย โดยถ้ามี 100 คนรับรองแต่ทั้งหมดมีบรรพบุรุษเดียวกัน เทียบกับมี 5 คนรับรองจากเส้นทางที่แตกต่างกันมาก ก็ควรให้น้ำหนัก 5 คนนั้นมากกว่า
      อยากรู้ว่าวิธีแบบนี้จะกัน “การปั่นชื่อเสียง” ได้มากแค่ไหน
    • สิ่งที่บอตน่าจะทำได้ก็คือสร้าง วงรับรองกันเอง เท่านั้น ตราบใดที่เครือข่ายส่วนที่เหลือยังไม่เริ่มรับรองบัญชีบอตเหล่านั้น คนอื่นก็จะไม่เห็นการตัดสินของวงนั้น
      ท้ายที่สุดข้อมูลทั้งหมดเป็นสาธารณะอยู่แล้ว ใครสักคนอาจสร้าง tangled2.org แล้วทำกราฟรวมทั้งโลกก็ได้ แต่ใน UI ถูกออกแบบไว้โดยตั้งใจให้การรับรองอ่อนลงเมื่อออกนอกวงของตัวเอง

  • ไอเดียก็ดี แต่ก็อดคิดไม่ได้ว่าแค่ สื่อสารกันแบบเป็นธรรมชาติ จะดีกว่าไหม การสื่อสารยิบย่อยทุกอย่างดูถูกจัดระเบียบและสม่ำเสมอเกินไป
    การปล่อยให้มีคำพิมพ์ผิดติดอยู่ในข้อความบ้างก็เป็นลายนิ้วมือแบบมนุษย์จริงๆ

  • ชอบไอเดียนี้ มันทำให้นึกถึง tree of trust ที่ lobste.rs ใช้อยู่

    • หรือจะเป็น human.json ก็ได้ บนเว็บของผมกำลังคิดอยู่ว่าจะเปลี่ยนชื่อเป็น meat.json

  • มันให้ความรู้สึกเหมือนเรากำลังทำซ้ำอย่างรวดเร็วกับ งานวิจัยด้าน trust metric ที่เกิดขึ้นแทบจะพร้อมกับการถือกำเนิดของโอเพนซอร์สเลย อยากรู้ว่า @raph จะมองเรื่องนี้อย่างไร

    • ดีใจที่ได้เห็นชื่อที่คุ้นจากสมัยก่อนอีกครั้ง ระบบ meta-moderation สามชั้น ของ Slashdot ก็นับว่าน่ายกย่อง
      มันไม่สมบูรณ์แบบ แต่ก็ยังดีกว่าไม่มีอะไรเลยอย่างชัดเจน

  • เหมือนจะมีของแบบนี้อยู่แล้วสักหกอัน แล้วทำไมไม่ไปร่วมกับของที่มีอยู่ แต่กลับทำอีกอันใหม่?