Đo lường độ 'ẩu' trong code do LLM tạo ra: Chỉ số Verbosity và Erosion

Các mô hình ngôn ngữ lớn (LLM) đã trở nên gần như hoàn hảo trong việc tạo mã nguồn, nhưng đó chưa phải là tất cả. Chỉ vì mã nguồn đúng về mặt hình thức không có nghĩa là nó không tạo ra các lớp trừu tượng không cần thiết, gây trùng lặp hoặc đưa ra những quyết định tồi tệ xét trên tổng thể. Đây không phải là một quan sát đột phá gì; hầu hết những người từng thực hiện các dự án theo kiểu "vibe-coded" (lập trình dựa trên cảm tính) đều nhận ra rằng mỗi tính năng bổ sung đôi khi có thể dẫn đến sự bùng nổ về số dòng mã (LOC).

Điều này dẫn đến sự mất quyền kiểm soát của con người, bởi trong các dự án đang thêm hàng triệu dòng mã mỗi tháng, con người rất khó để theo kịp. Một số người có thể nói rằng đó hoàn toàn không phải là vấn đề vì họ tin tưởng vào các tác nhân (agent) của mình để xử lý nó. Tôi có tin xấu cho bạn đây: các tác nhân thực sự cũng không thể giải quyết được đống mã hỗn độn (slop) đó.

Xuất thân từ nền tảng vật lý, tôi luôn có cách tiếp cận thực nghiệm/định lượng để giải quyết vấn đề. Khi bắt đầu làm việc tại Earendil với nhiệm vụ tìm cách đo lường sự cẩu thả trong mã nguồn, bản năng tự nhiên của tôi là trước tiên phải tìm hiểu sâu các tài liệu, sau đó kiểm tra xem các công ty khác đang làm gì.

Thành thật mà nói, ngoại trừ một vài bài nghiên cứu sâu sắc, tôi cảm thấy thất vọng vì ngành này hiện tại dường như đang vận hành dựa trên "cảm tính" (vibes). Trong quá trình nghiên cứu và trên X, tôi liên tục bị tấn công bởi các thông điệp như "Tác nhân lập trình đầu-cuối" (End-to-end coding agents), "AI không chỉ gợi ý mã—nó còn triển khai mã" hoặc "Đánh giá cấp độ con người mà không tốn chi phí cấp độ con người". Những điều này, giống như mọi câu chuyện hay khác, đều có một phần sự thật trong đó.

Các LLM có khả năng viết mã gần như hoàn hảo. Điều này là nhờ vào khả năng mở rộng và khả năng kiểm chứng của mã nguồn. Việc để LLM tạo mã rồi kiểm tra bằng các bài kiểm tra ẩn (hidden tests) để tạo ra tín hiệu phần thưởng rõ ràng là khá đơn giản. Trái ngược hoàn toàn với điều đó, việc kiểm tra sự "cẩu thả" của mã nguồn thường đòi hỏi trực giác và gu thẩm mỹ của con người, và đây là một nhiệm vụ cực kỳ khó khăn nói chung. Tôi nghĩ cách tốt nhất để minh họa lý do tại sao lại như vậy là đi qua các phương pháp khả thi để đo lường sự cẩu thả (slop).

AI đóng vai trò giám khảo: Đây có lẽ là cách phổ biến nhất để đánh giá chất lượng mã trong ngành và theo quan sát của tôi, nó hiếm khi hiệu quả. Cách làm ngây thơ nhất là yêu cầu các mô hình đánh giá mã tốt đến mức nào trên thang điểm từ 1-10, về cơ bản chẳng khác gì một trình tạo số ngẫu nhiên. Cách tiếp cận tinh vi hơn, đó là đưa cho mô hình giám khảo hai giải pháp A và B rồi để nó quyết định giải pháp nào tốt hơn, lại có nhược điểm là mô hình sẽ thay đổi lựa chọn nếu bạn đổi tên các giải pháp. Tôi hơi châm biếm một chút ở đây và hiệu ứng này không quá rõ rệt với các mô hình lớn hơn, nhưng quan điểm chính vẫn giữ nguyên. Yêu cầu LLM đánh giá mã do chính chúng viết ra không thể thay thế cho một quy trình đánh giá đúng đắn. Mặc dù có một số cách tiếp cận thú vị với các tiêu chí (rubrics) hoặc để LLM tự viết bài kiểm tra, chúng vẫn còn rất xa mới thực sự loại bỏ được sự cẩu thả.

Con người đánh giá AI: Nếu chúng ta bỏ qua thực tế rằng có sự khác biệt rất lớn về trình độ giữa các kỹ sư phần mềm, thì đây sẽ là giải pháp tốt nhất để đảm bảo mã nguồn vẫn dễ đọc đối với con người. Nhược điểm là phương pháp này không thể mở rộng để huấn luyện AI hoặc thực hiện các bộ benchmark lớn với nhiều nhà cung cấp mô hình và hệ thống kiểm thử khác nhau.

Phương pháp đơn giản nhất: Trong nghiên cứu và các thử nghiệm của tôi, việc chỉ đơn giản lấy sự thay đổi trong số lượng LOC đã trở thành một thước đo hiệu quả đến bất ngờ cho sự cẩu thả, với một lưu ý trớ trêu rằng nếu chúng ta bắt đầu tối ưu hóa cho nó, nó sẽ không còn là một thước đo có ý nghĩa nữa.

Hai thước đo tiếp theo được giới thiệu với tôi qua bài báo SlopCodeBench, và có vẻ đầy hứa hẹn vì chúng có khả năng phân tách khá tốt giữa các cơ sở mã cũ (legacy code bases) và sự cẩu thả từ LLM.

Độ dài dòng (Verbosity): Cố gắng đo lường số lượng các dòng mã bị trùng lặp và dài dòng không cần thiết.

Verbosity=∣Các dòng được gắn cờ bởi AST-Grep ∪ các dòng nhân bản∣LOC

Sự xói mòn (Erosion): Cố gắng đo lường mức độ tập trung khối lượng của một cơ sở mã vào một vài hàm lớn và phức tạp.

mass(f)=CC(f)√SLOC(f)

Ở đây f là hàm, SLOC là số dòng mã nguồn và CC(f) là độ phức tạp cyclomatic của hàm đó.

Erosion=∑f: CC(f)>10mass(f)∑fmass(f)

Sự xói mòn sau đó đơn giản là tỷ lệ giữa khối lượng của các hàm có độ phức tạp cyclomatic lớn hơn 10 trên tổng khối lượng của tất cả các hàm.

Nếu chúng ta xem xét độ dài dòng và sự xói mòn trung bình của mã được tạo ra trong quá trình đánh giá SlopCodeBench và so sánh với một tập hợp các kho lưu trữ (repo) đã được thiết lập, sẽ thấy sự khác biệt rõ rệt. Trung bình, độ dài dòng trong các repo là 0.15 ± 0.06 và trong mã của các tác nhân là 0.33 ± 0.10. Đối với sự xói mòn, các repo đạt 0.31 ± 0.17 còn các tác nhân là 0.68 ± 0.20. Mã của tác nhân trung bình dài dòng và bị xói mòn gấp đôi so với mã của con người. Sau đó, tôi đã điều tra một số dự án "vibe coded" của riêng mình và rất nhiều trong số đó có độ dài dòng lên tới 0.4 và sự xói mòn cao tới 0.75, vì vậy những kết quả này có lẽ không chỉ là một sản phẩm phụ của quá trình đánh giá.

Quay lại vấn đề tại sao các tác nhân không thể (thực sự) tự xử lý sự cẩu thả, chúng ta cần xem xét đánh giá của SlopCodeBench. Trái ngược với các benchmark lập trình khác, vốn cung cấp cho tác nhân danh sách hướng dẫn đầy đủ ngay từ đầu và sau đó có một bộ các bài kiểm tra ẩn mà chương trình cần vượt qua, họ làm điều ngược lại. Họ tạo ra nhiều vòng lặp hướng dẫn và kiểm tra, trong đó ngữ cảnh của các mô hình bị xóa giữa các điểm kiểm tra (checkpoints). Qua đó mô phỏng gần hơn một quy trình lặp, giống như cách các tác nhân lập trình thực sự được con người sử dụng. Kết quả là các quyết định lập trình tồi tệ tích tụ theo thời gian và đối với tỷ lệ giải quyết nghiêm ngặt, nơi tất cả các bài kiểm tra phải được vượt qua tại mọi điểm kiểm tra, ngay cả các mô hình hiện đại nhất cũng đạt tỷ lệ vượt qua 0%. Điều này nên là một tín hiệu cảnh báo cho bất kỳ ai đang vui vẻ thêm hàng chục nghìn hoặc thậm chí hàng trăm nghìn dòng mã mỗi ngày. Tất nhiên, vẫn có những lưu ý thông thường về các bài kiểm tra quá khắt khe hoặc một vài tuyên bố vấn đề hơi mơ hồ, nhưng xu hướng chung vẫn giữ nguyên.

Khi khám phá các thước đo này, tôi hy vọng bạn đã có cái nhìn rõ ràng hơn về lý do tại sao việc đánh giá sự cẩu thả trong mã nguồn lại đầy thách thức và tại sao trực giác cũng như gu thẩm mỹ của con người vẫn được đưa vào quá trình đánh giá một cách ngầm định hoặc tường minh.

Có một số hướng đi đầy hứa hẹn khác mà tôi muốn khám phá, chẳng hạn như tính liên kết (coupledness) của các hàm, sự thay đổi mã (code churn), tính gắn kết (cohesion), v.v. Nếu bạn đang làm việc về đánh giá (evals) và muốn thảo luận, tôi rất sẵn lòng: [email protected]

Điều này làm tôi nhớ đến câu nói: "Đo lường tiến độ lập trình bằng số dòng mã cũng giống như đo lường tiến độ chế tạo máy bay bằng trọng lượng."

Tôi sẽ không muốn ép buộc bất kỳ ai phải xem xét hàng triệu dòng mã chỉ để có được một bảng xếp hạng các nhà cung cấp mô hình luôn thay đổi.

Các quy tắc cho việc này là một tập hợp các heuristic thủ công được triển khai thông qua AST-Grep, điều này một lần nữa cho thấy khía cạnh con người trong tất cả những việc đó.

Mặc dù một dự án mở nổi tiếng là "vibe-y" không đạt điểm quá cao ở cả hai thước đo, có lẽ là do tính liên kết cực cao của các hàm và/hoặc khối lượng khổng lồ của các hàm không liên quan làm giảm các giá trị trung bình.

Chưa được thử nghiệm trên Fable 5.1 hoặc Astra, nhưng đã thử trên GPT 5.6 sol xhigh, v.v.