Thủ thuật
Dự án Rust chính thức ban hành quy định sử dụng LLM trong đóng góp mã nguồn
(giờ Việt Nam)
Tóm tắt AI
Cộng đồng Rust vừa áp dụng bộ quy tắc mới nhằm chuẩn hóa việc sử dụng AI tạo sinh trong các PR, đánh giá mã và báo cáo lỗi, giúp giảm thiểu gánh nặng cho đội ngũ kiểm duyệt và duy trì chất lượng dự án.
Bản dịch AI

Gần đây, năm nhóm trong dự án Rust đã thông qua một chính sách do tôi khởi thảo, quy định cách thức sử dụng các Mô hình Ngôn ngữ Lớn (Large Language Models - LLM) khi đóng góp vào monorepo rust-lang/rust. Đáng chú ý, chính sách mới này không phải là lập trường chính thức về LLM và không áp dụng cho toàn bộ dự án Rust. Tôi viết nó cho một mục đích rất cụ thể, được mô tả dưới đây.
Bài viết này nói về lý do tại sao chúng tôi tạo ra chính sách đó, nội dung của nó là gì và nó sẽ ảnh hưởng như thế nào đến những người đóng góp.
Chính sách này ảnh hưởng đến các nhóm người sau:
Nếu bạn không thuộc một trong những nhóm đó, bạn không cần phải thay đổi bất cứ điều gì về cách làm việc của mình.
Tại sao chính sách này lại được tạo ra?
Mặc dù dự án Rust là một tập hợp các thành phần kỹ thuật, nhưng nó cũng là một cộng đồng gồm những con người cùng nhau làm việc để xây dựng, duy trì và mở rộng các thành phần đó. Khi chúng ta nói về việc "đóng góp cho dự án Rust", một phần chúng ta muốn nói đến công việc trên các thành phần đó, nhưng chúng ta cũng muốn nói đến việc tham gia vào cộng đồng đó và cộng tác với những người đã ở đó.
Ngay cả trước khi chính sách này được tạo ra, mọi người đã sử dụng LLM để đóng góp cho rust-lang/rust. Một số cách sử dụng trong đó tôn trọng cộng đồng của chúng ta: dịch tin nhắn sang tiếng Anh để mọi người có thể soạn thảo bằng ngôn ngữ mẹ đẻ của họ; tìm kiếm các chẩn đoán kém cho các đoạn mã mà những người đóng góp mới cho Rust có thể viết; phân tích các RFC để xem liệu chúng có bỏ sót phần thảo luận về các khía cạnh khác của ngôn ngữ có thể ảnh hưởng đến thiết kế hay không. Một số cách sử dụng khác, đôi khi không cố ý, đã không làm được điều đó.
Tôi đã thấy LLM gây ra ba vấn đề chính cho cộng đồng của chúng ta:
Theo thời gian, những vấn đề này ngày càng lớn dần, cho đến khi chúng tôi phải tạo ra các kênh chuyên biệt và chính sách kiểm duyệt để giải quyết chúng. Tuy nhiên, các kênh đó đi ngược lại mục tiêu minh bạch và chào đón của chúng ta, vì những người đóng góp mới không biết các quy tắc là gì.
Chính sách mới chính thức hóa các quy tắc đó một cách công khai, để những người đóng góp mới biết cách tham gia cộng đồng của chúng ta mà không bị đóng PR vì những lý do họ không hiểu, và để các người đánh giá (reviewer) hiện tại có thể dễ dàng chỉ ra các quy tắc như một lý do thực tế khi đóng các PR không tuân thủ chúng.
Các sản phẩm kỹ thuật không còn phản ánh nỗ lực
Trước đây, nếu một dự án mã nguồn mở nhận được một PR chỉn chu, được kiểm thử kỹ lưỡng và chi tiết, điều đó cho thấy có một người ở phía bên kia đã dành thời gian, công sức và sự hiểu biết vào PR đó. Điều đó đã ảnh hưởng đến văn hóa của Rust theo nhiều cách:
Với LLM, không có tín hiệu nào trong số này là đáng tin cậy. Các PR chỉn chu không còn cho thấy nỗ lực; tác giả của các PR chỉn chu không nhất thiết phải hiểu mã của họ—và trong trường hợp các tác nhân tự động (autonomous agents), thậm chí không còn ai ở phía bên kia nữa; và vì việc viết mã đã trở nên dễ dàng hơn nhiều, một PR chỉn chu không còn cho thấy khả năng ai đó sẽ gắn bó lâu dài.
Việc làm cho mã dễ viết hơn gây ra các vấn đề về đánh giá
Tại thời điểm viết bài này, có 1.281 PR đang mở cho rust-lang/rust. Điều này đại diện cho một lượng thời gian khổng lồ được đầu tư bởi cả tác giả và người đánh giá. Chúng ta đã có vấn đề từ lâu là có nhiều người muốn viết mã hơn là người sẵn sàng đánh giá nó. Với sự ra đời của LLM, vấn đề này chỉ trở nên tồi tệ hơn.
Hầu hết công việc đánh giá không chỉ đơn thuần là bắt lỗi. Phần lớn công việc là quyết định xem hướng đi này có phải là một cách tiếp cận tốt hay không, liệu PR đó có phải là một ý tưởng hay hay không. Nói cách khác, đánh giá được tạo thành từ các quyết định.
Việc "xả" (shotgunning) hàng loạt PR vào người đánh giá gây ra chi phí tinh thần cao cho họ. Tôi nghĩ hầu hết các tác giả của các PR từ LLM đều tin rằng họ đang thực sự giúp đỡ, nhưng từ góc độ của chúng tôi, bản thân mã nguồn là phần nhỏ nhất và theo một cách nào đó là phần ít quan trọng nhất của thay đổi. Chúng tôi quan tâm nhiều hơn đến việc tác giả hiểu mã đó làm gì, lập kế hoạch về cách nó sẽ thay đổi trong tương lai và quyết định xem nó nên trông như thế nào. Bản thân mã nguồn không thể giúp ích cho bất kỳ điều nào trong số đó.
Việc sao chép-dán máy móc đầu ra của LLM là lãng phí thời gian
Chúng tôi thường xuyên gặp những người phản hồi các bình luận đánh giá bằng cách sao chép-dán chúng vào LLM của họ, sau đó sao chép-dán phản hồi của nó trở lại GitHub. Thẳng thắn mà nói: đây là sự lãng phí thời gian của tất cả mọi người. Nếu chúng tôi muốn ý kiến của LLM, chúng tôi đã có thể tự hỏi nó. Chúng tôi muốn nghe suy nghĩ của bạn, không phải của một cỗ máy.
Hơn nữa, đây là sự vi phạm lòng tin giữa người đánh giá và tác giả. Giả định của chúng tôi khi đánh giá là chúng tôi đang nói chuyện với một người thực sự muốn làm công việc tốt nhất của họ. Việc dán văn bản từ LLM tạo ra sự nghi ngờ: liệu tác giả có thực sự quan tâm không? Có người nào ở đây không?
Vậy tại sao lại cần một chính sách?
Trước chính sách này, chúng tôi có cách tiếp cận "miền Tây hoang dã" đối với việc kiểm duyệt. Chúng tôi có hàng tá PR từ LLM; không có quy tắc công khai; mọi người cố gắng thêm các tối ưu hóa MIR rủi ro như là PR đầu tiên của họ; và mọi người đăng "Verification: git diff --check" trong mô tả PR của họ như thể điều đó có tác dụng gì đó. Mặc dù chúng tôi có thứ gì đó để người kiểm duyệt chỉ vào dưới dạng "Trao quyền cho người đánh giá từ chối các PR gây gánh nặng", nhưng việc thực thi của chúng tôi không nhất quán và các quy tắc của chúng tôi không được công bố ở bất kỳ đâu. Trên thực tế, quy tắc là "cái gì cũng được, miễn là nó không quá tệ hại". So với tình hình trước đây, chính sách mới vừa nghiêm ngặt hơn nhiều vừa rõ ràng hơn nhiều.
Bất kể quan điểm của bạn về việc LLM là tốt, xấu hay là một thứ thứ ba bí ẩn, chúng không còn có thể bị phớt lờ. Lựa chọn của chúng ta không phải là "không có chính sách" hay "có chính sách". Lựa chọn của chúng ta là liệu chính sách đó sẽ là một danh sách ghi chú kiểm duyệt không chính thức hay là thứ mà chúng ta công khai ủng hộ.
Tại sao không cấm hoàn toàn LLM, hoặc cho phép bất kỳ việc sử dụng LLM nào mà chúng ta cho là có ích cho xã hội? Bởi vì cơ chế quản trị của Rust không hoạt động theo cách đó. Chúng tôi không có một nhà độc tài nhân từ có thể nói "Không có nội dung do LLM tạo ra, dù là mã hay văn bản" hoặc "AI là một công cụ, giống như các công cụ khác mà chúng ta sử dụng".
Rust hoạt động dựa trên sự đồng thuận. Như chính sách đã nêu:
Không có sự đồng thuận trong dự án Rust—và có lẽ sẽ không bao giờ có—về việc khi nào/làm thế nào/ở đâu là chấp nhận được khi sử dụng các công cụ dựa trên AI. Nhiều thành viên của dự án và cộng đồng Rust tìm thấy giá trị trong AI; nhiều người khác cảm thấy rằng tác động tiêu cực của nó đối với xã hội và khí hậu là đủ nghiêm trọng để không có cách sử dụng nào là chấp nhận được. Những người khác vẫn đang tìm kiếm quan điểm của riêng mình.
Bất chấp những khác biệt này, có nhiều giá trị mà tất cả chúng ta đều chia sẻ:
Chúng tôi muốn có thể thay đổi chính sách trong tương lai. Chính sách có một số điều khoản giúp việc thay đổi dễ dàng hơn so với việc thông qua ban đầu. Hội đồng lãnh đạo cũng đang xem xét thành lập một nhóm phụ xử lý chính sách LLM để chúng ta có ít yêu cầu phê duyệt "ác mộng" gồm 30 người hơn.
Tôi không nghĩ mọi quy tắc trong chính sách này đều hoàn toàn tốt. Tôi thực sự nghĩ rằng việc viết các quy tắc của chúng ta ra giấy tốt hơn là không viết chúng ra, và việc có một chính sách mà mọi người đều hơi không thích sẽ thúc đẩy chúng ta cải thiện các cấu trúc quản trị của mình.
Chính sách nói gì?
Chính sách tự tóm tắt như sau:
Việc sử dụng LLM để trả lời câu hỏi, phân tích, chắt lọc, tinh chỉnh, kiểm tra, gợi ý, đánh giá là ổn. Nhưng không được dùng để tạo ra.
Các cách sử dụng trong danh mục đầu tiên được cho phép, đôi khi yêu cầu phải công khai. Các cách sử dụng trong danh mục thứ hai bị hạn chế nghiêm ngặt.
Các quy tắc chung
Không ai ngoại trừ tác giả bắt buộc phải đọc đầu ra của LLM trừ khi họ chọn làm vậy: Đầu ra của LLM không được phép xuất hiện trong tài liệu công khai, mô tả PR hoặc bình luận trên Github trừ khi được đánh dấu rõ ràng; người đánh giá không bắt buộc phải xem các PR từ LLM nếu họ không muốn.
Không ai bắt buộc phải sử dụng LLM để đóng góp cho rust-lang/rust: các chính sách phải được viết cho con người trước, và chỉ tóm tắt cho máy móc; các đánh giá từ LLM không thể thay thế cho đánh giá của con người hoặc tự đánh giá.
Bạn được phép tạo nội dung LLM mà chỉ bạn nhìn thấy, không cần công khai, miễn là bạn không đăng nó ở bất kỳ đâu mà bạn mong đợi chúng tôi đọc hoặc đánh giá.
Việc công khai là bắt buộc đối với dịch máy, các thay đổi "vụn vặt", khám phá lỗi và đánh giá công việc của người khác bằng LLM. Chúng tôi hoan nghênh các tin nhắn được đăng bằng ngôn ngữ mẹ đẻ của bạn; bản dịch tiếng Anh không bắt buộc để đóng góp.
Có những hướng dẫn rất nghiêm ngặt về các thay đổi mã do LLM tạo ra:
Bài viết được AI dịch và tổng hợp tự động từ Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung). Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.