นโยบายการใช้ LLM ของ NLnet Labs

• NLnet Labs จำกัดการใช้ LLMในการมีส่วนร่วมกับโปรเจ็กต์และการสื่อสาร และงานที่ส่งซึ่งฝ่าฝืนนโยบายอาจถูกปิดหรือลบโดยไม่แจ้งล่วงหน้า
• การมีส่วนร่วมด้านโค้ดและเอกสารต้องเขียนโดยมนุษย์โดยตรง และต้องไม่มีเนื้อหาที่ LLM หรือเครื่องมือเชิงความน่าจะเป็นอื่นสร้างขึ้น
• ในการรายงานช่องโหว่และบั๊ก อาจยอมรับข้อเสนอการแก้ไขที่ LLM แนะนำได้เป็นกรณียกเว้น แต่ผู้มีส่วนร่วมที่เป็นมนุษย์ต้องตรวจสอบปัญหาและระดับความร้ายแรง
• เมื่อติดต่อสื่อสารกับ NLnet Labs เช่น การเปิดอีชู รายงานช่องโหว่ หรือโพสต์ในฟอรัม จำเป็นต้องเปิดเผยการใช้ LLM และหากใช้การแปลด้วยเครื่องก็แนะนำให้เปิดเผยเช่นกันเพราะอาจมีการแปลผิด
• สามารถใช้ LLM สำหรับ linting, การวิเคราะห์, และการรีวิวได้ แต่ความรับผิดชอบในการทำความเข้าใจและตรวจสอบความถูกต้องของข้อมูลที่เผยแพร่ภายนอกยังคงเป็นของผู้มีส่วนร่วม

---

ขอบเขตของนโยบายและหน้าที่พื้นฐาน

• NLnet Labs จำกัดวิธีการใช้ Large Language Models(LLMs) ในบริบทขององค์กรและโปรเจ็กต์
• งานที่ส่งซึ่งไม่ปฏิบัติตามนโยบายนี้อาจถูกปิดหรือลบโดยไม่แจ้งล่วงหน้า
  • รวมถึง PR, อีชู, คอมเมนต์, และโพสต์ในฟอรัม
• นอกจากนโยบายนี้แล้ว ต้องปฏิบัติตาม code of conduct และ CONTRIBUTING.md ของแต่ละโปรเจ็กต์ด้วย

หลักการในการจัดทำผลงานที่มีส่วนร่วม

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

การเปิดเผยการใช้ LLM และการแปล

• เมื่อติดต่อสื่อสารกับ NLnet Labs ต้องเปิดเผยว่ามีการใช้ LLM หรือไม่
  • รวมถึงการเปิดอีชู การรายงานช่องโหว่ และการโพสต์ใน community forum
• การแปลด้วยเครื่องอาจมีประโยชน์เมื่อภาษาอังกฤษไม่ใช่ภาษาแม่
  • หากใช้การแปลด้วยเครื่อง แนะนำให้เปิดเผยเพื่อให้ทั้งสองฝ่ายรับรู้ถึงความเป็นไปได้ของปัญหาการสื่อสารจากการแปลผิด
  • หากไม่สามารถประเมินความถูกต้องของคำแปลได้ ก็สามารถเขียนเป็นภาษาแม่ได้
  • ไม่แนะนำการแปลด้วย LLM เพราะคุณสมบัติแบบเชิงสร้างสรรค์ของมันอาจทำให้การสนทนาสับสนมากกว่าช่วยให้พูดคุยกันได้ง่ายขึ้น

การใช้งานที่อนุญาตและความรับผิดชอบในการตรวจสอบ

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

การรายงานช่องโหว่

• NLnet Labs อาจรับรายงานช่องโหว่ที่ค้นพบด้วย LLM
  • สามารถใส่ข้อเสนอการแก้ไขที่ LLM แนะนำไว้ในรายงานเพื่อช่วยระบุตำแหน่งของปัญหาได้
  • ผู้มีส่วนร่วมที่เป็นมนุษย์ต้องตรวจสอบปัญหาและระดับความร้ายแรงโดยประมาณ
  • เมื่่อรายงานไปที่ [e-mail] ต้องเปิดเผยการใช้ LLM
  • ควรดูขั้นตอนการรายงานช่องโหว่ที่หน้า security report

[GN⁺]

ความเห็นจาก Lobste.rs

• อยากฟัง เหตุผลเบื้องหลัง ของกฎแบบนี้
  เช่น อยากรู้ว่าแรงจูงใจหลักคือความไม่แน่นอนทางกฎหมาย ความกังวลเรื่องคุณภาพหรือการบำรุงรักษา หรือเหตุผลอื่นกันแน่

  • อย่างที่ Alex Band แห่ง NLnet Labs อธิบายไว้ค่อนข้างอย่างยับยั้งใน toot นี้ ว่า ใครสักคนอาจเขียนพรอมป์อย่างดีเพื่อสร้าง โค้ด 10,000 บรรทัด สำหรับฟีเจอร์ที่ยอดเยี่ยมและจำเป็น ซึ่งดูเหมือนทำงานได้ตามเจตนา
    แต่ก่อนจะส่งเป็น pull request ให้ทีม NLnet Labs ประเด็นสำคัญคือ ได้ตรวจทาน เข้าใจ และรับผิดชอบได้ทุกบรรทัดที่สร้างขึ้นมาหรือไม่ จากประสบการณ์ในปีที่ผ่านมา กรณีแบบนั้นเกิดขึ้นไม่บ่อยนัก และโค้ดมักถูกวางไว้หน้าประตูราวกับของขวัญที่มาจากเจตนาดี แต่ภาระในการตรวจทาน รับผิดชอบ และ merge เข้ากิ่ง main กลับตกอยู่กับทีม เมื่อคำนึงว่าซอฟต์แวร์นี้ทำงานอยู่ใน โครงสร้างพื้นฐานสำคัญ ที่เป็นรากฐานของอินเทอร์เน็ต นี่เป็นข้อเรียกร้องที่หนักมาก ในกระบวนการรีวิว ทั้งสองฝ่ายต้องสามารถสนทนากันได้โดยเข้าใจทั้งโดเมนของปัญหาและรายละเอียดของวิธีแก้ที่เสนอร่วมกัน แต่การใช้ LLM ไม่ได้ให้ความเข้าใจแบบนั้นแก่ผู้ส่ง และยังส่งผลเสียต่อการบำรุงรักษาระยะยาวด้วย
  • เหตุผลโดยตรงที่ลงมือเขียนเอกสารนี้คือเพื่อ ปกป้องเวลาของนักพัฒนา
    แน่นอนว่าเรื่องลิขสิทธิ์ การควบคุมคุณภาพ การบำรุงรักษาระยะยาว และข้อกังวลด้านจริยธรรมก็ถูกนำมาพิจารณาทั้งหมดเช่นกัน

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

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

• นี่เป็นเพียง นโยบายของ NLnet Labs เอง และไม่ใช่นโยบายที่โปรเจกต์ที่ได้รับการสนับสนุนจาก NLnet จำเป็นต้องนำไปใช้

• เข้าใจเหตุผลเบื้องหลังการตัดสินใจแบบนี้ แต่แนวทางบังคับใช้ใกล้เคียงกับ “ห้ามทั้งหมด” จึงดู มุมมองแคบ

  • ช่วยอธิบายได้ไหมว่าการตัดสินเชิงบรรทัดฐานนั้นมาจากไหน อยากรู้ว่าทำไมคุณถึงมีส่วนได้ส่วนเสียกับการที่คนอื่นยอมรับ งานส่งที่สร้างด้วย LLM ในโปรเจกต์ของเขา และพวกเขาหรือสังคมจะได้อะไรจากเรื่องนั้น
    ผมมองว่าตรรกะนี้สอดคล้องและสมเหตุสมผล และในช่วงเวลาแบบนี้ถือเป็นมาตรการป้องกันที่ดีต่อสุขภาพด้วยซ้ำ อยากรู้ด้วยว่าคุณกังวลว่างานที่ส่งจะถูกปฏิเสธเพราะเหตุผลนี้ หรือเคยเจอมาแล้วกันแน่ การทำตามนโยบายนี้ยากขนาดนั้นเลยหรือ? คุณเองเป็นผู้ดูแลโครงสร้างพื้นฐานสำคัญระยะยาวที่ต้องจัดการเสียงรบกวนคุณภาพต่ำซึ่งถาโถมเข้ามาใน issue tracker ทุกวันหรือเปล่า? ในเวิร์กโฟลว์ที่มีมนุษย์เป็นศูนย์กลาง คุณคิดว่าควรทำอย่างไรเพื่อลดผลกระทบจาก false positive ที่ท่วมเข้ามา พร้อมกับรักษาแรงจูงใจไว้
  • ผมจะเรียกว่า รอบคอบ มากกว่ามุมมองแคบ
  • เมื่อปรากฏว่าชุมชนที่เกี่ยวข้องไม่สามารถรับมือกับกฎที่เปิดกว้างและซับซ้อน ซึ่งสะท้อนผลประโยชน์ของทุกฝ่ายได้แม่นยำกว่า การกำหนด กฎที่แคบและเรียบง่าย ก็เป็นเรื่องที่พบได้ค่อนข้างบ่อย
    นี่ไม่ใช่เรื่องแย่ นักพัฒนาโตเป็นผู้ใหญ่ขึ้นอีกหน่อยแล้วค่อยกลับมาทบทวนใหม่ก็ได้