Chính sách sử dụng LLM của NLnet Labs
(nlnetlabs.nl)- NLnet Labs hạn chế việc sử dụng LLM trong đóng góp dự án và giao tiếp; các nội dung gửi vi phạm chính sách có thể bị đóng hoặc xóa mà không cần thông báo trước
- Đóng góp mã nguồn và tài liệu phải được con người trực tiếp viết; không được bao gồm nội dung do LLM hoặc các công cụ xác suất khác tạo ra
- Trong báo cáo lỗ hổng và lỗi, các bản sửa lỗi do LLM đề xuất có thể được chấp nhận như ngoại lệ, nhưng người đóng góp là con người phải xác minh vấn đề và mức độ nghiêm trọng
- Khi tương tác với NLnet Labs, chẳng hạn như issue, báo cáo lỗ hổng hoặc bài đăng trên diễn đàn, cần công khai việc sử dụng LLM; việc công khai bản dịch máy cũng được khuyến nghị do khả năng dịch sai
- Có thể sử dụng LLM cho linting, phân tích và review, nhưng trách nhiệm hiểu và xác minh độ chính xác của thông tin chia sẻ ra bên ngoài vẫn thuộc về người đóng góp
Phạm vi chính sách và nghĩa vụ cơ bản
- NLnet Labs hạn chế cách sử dụng Large Language Models(LLMs) trong bối cảnh tổ chức và dự án
- Các nội dung gửi không tuân thủ chính sách có thể bị đóng hoặc xóa mà không cần thông báo trước
- Đối tượng bao gồm PR, issue, bình luận, bài đăng trên diễn đàn, v.v.
- Cùng với chính sách này, cũng phải tuân thủ code of conduct và
CONTRIBUTING.mdcủa từng dự án
Nguyên tắc tạo đóng góp
- Đóng góp mã nguồn và tài liệu phải do con người viết
- Không được bao gồm nội dung do LLM hoặc các công cụ xác suất khác tạo ra
- Các bản sửa lỗi do LLM đề xuất được đưa vào báo cáo lỗ hổng hoặc lỗi được phép như một ngoại lệ
- Ngoại lệ này nhằm giúp dễ tìm nguyên nhân gốc rễ của vấn đề hơn trong quá trình xem xét ban đầu
- Khi mở PR, đóng góp do LLM tạo ra cũng không được chấp nhận
- Mã nguồn gửi lên không được là mã do LLM tạo ra
- Mô tả PR phải được viết ngắn gọn bằng lời của chính mình
- Nhìn chung, không nên mở PR cho tính năng mới nếu chưa trao đổi trước với NLnet Labs
- Ý tưởng thay đổi phần mềm có thể được chia sẻ bằng suy nghĩ của chính mình trên community forum
Công khai việc sử dụng LLM và dịch thuật
- Khi tương tác với NLnet Labs, phải công khai có sử dụng LLM hay không
- Bao gồm mở issue, báo cáo lỗ hổng và đăng bài trên diễn đàn cộng đồng
- Khi tiếng Anh không phải là tiếng mẹ đẻ, dịch máy có thể hữu ích
- Nếu đã sử dụng dịch máy, nên công khai để cả hai bên có thể nhận thức khả năng xảy ra vấn đề giao tiếp do dịch sai
- Nếu không thể đánh giá độ chính xác của bản dịch, cũng có thể viết bằng tiếng mẹ đẻ
- Dịch bằng LLM không được khuyến nghị vì đặc tính sinh nội dung của nó có nhiều khả năng gây rối hơn là giúp thảo luận dễ dàng
Cách sử dụng được phép và trách nhiệm xác minh
- Được phép sử dụng LLM cho linting, phân tích, review
- Ngay cả khi LLM đã hỗ trợ phát hiện vấn đề hoặc phân tích, người dùng vẫn có trách nhiệm hiểu và xác minh độ chính xác của thông tin mình chia sẻ
Báo cáo lỗ hổng
- NLnet Labs có thể tiếp nhận báo cáo lỗ hổng được tìm thấy bằng LLM
- Có thể đưa bản sửa lỗi do LLM đề xuất vào báo cáo để hỗ trợ xác định vị trí vấn đề
- Người đóng góp là con người phải xác minh vấn đề và mức độ nghiêm trọng ước tính
- Khi báo cáo tới
sep@nlnetlabs.nl, phải công khai việc sử dụng LLM - Quy trình báo cáo lỗ hổng nên tham khảo trang security report
1 bình luận
Ý kiến trên Lobste.rs
Muốn nghe lý do nền tảng đằng sau những quy tắc này
Chẳng hạn, tôi tò mò liệu động lực chính là sự bất định pháp lý, lo ngại về chất lượng hay bảo trì, hay một lý do nào khác
Nhưng trước khi gửi cho nhóm NLnet Labs dưới dạng pull request, điều cốt lõi là liệu họ đã rà soát, hiểu và có thể chịu trách nhiệm cho từng dòng được sinh ra hay chưa. Theo kinh nghiệm trong năm qua, những trường hợp như vậy rất hiếm; mã được đặt trước cửa như một món quà thiện chí, nhưng gánh nặng rà soát, chịu trách nhiệm và merge vào nhánh main lại chuyển sang cho nhóm. Xét việc phần mềm này chạy trong hạ tầng trọng yếu làm nền tảng cho Internet, đó là một yêu cầu lớn. Trong quá trình review, hai bên cần có thể trao đổi khi cùng hiểu cả miền vấn đề lẫn chi tiết của giải pháp được đề xuất, nhưng việc dùng LLM không đem lại cho người gửi sự hiểu biết đó và còn gây tác động xấu đến bảo trì dài hạn
Tất nhiên, bản quyền, kiểm soát chất lượng, bảo trì dài hạn và các lo ngại đạo đức cũng đều đã được cân nhắc
Tôi cũng thích việc họ tập trung vào chuyện con người viết và review patch, và việc họ đặt đề xuất patch trong báo cáo lỗ hổng làm ngoại lệ
Nếu đơn giản và đi thẳng vào trọng tâm, những đề xuất như vậy đáng để đọc qua
Tôi có thể hiểu vì sao mọi người mệt mỏi với sản phẩm do AI tạo ra, đặc biệt khi quy mô tăng lên
Ngay cả trong nhóm nhỏ nơi tôi làm việc cũng có những chuyện gây khó chịu. Khi hỏi “Tại sao lại làm như vậy?”, câu trả lời nhận được là “À, Claude làm như thế”, nhưng đó không phải là câu trả lời. Người ta đang đẩy không chỉ quá trình suy nghĩ mà cả trách nhiệm sang cho máy móc. Hiện tại, dùng theo hướng bảo thủ không hẳn là xấu; chỉ nên nới lỏng sau khi chúng ta biết cách dùng công nghệ này một cách có trách nhiệm ở quy mô lớn. Hiện giờ chưa ai biết cách đó
Đây chỉ là chính sách riêng của NLnet Labs, không phải chính sách mà các dự án được NLnet hỗ trợ bắt buộc phải áp dụng
Tôi hiểu bối cảnh dẫn tới quyết định này, nhưng cách thực thi gần như là “không được tất cả”, nên có vẻ thiển cận
Tôi thấy lập luận này nhất quán và hợp lý, và trong thời điểm như hiện nay thì đây là một biện pháp bảo vệ lành mạnh. Tôi cũng tò mò liệu bạn lo ngại đóng góp của mình sẽ bị từ chối vì lý do này, hay bạn đã từng trải qua chuyện đó rồi. Việc tuân thủ chính sách này có khó đến vậy không? Chính bạn có đang là người bảo trì dài hạn cho hạ tầng trọng yếu, ngày ngày xử lý lượng nhiễu chất lượng thấp đổ vào issue tracker không? Theo bạn, làm thế nào để duy trì động lực trong một workflow lấy con người làm trung tâm, đồng thời giảm tác động từ làn sóng false positive?
Đây không phải là điều xấu. Khi các nhà phát triển trưởng thành hơn một chút, họ có thể xem xét lại