Databricks đánh giá hiệu năng AI lập trình trên kho mã nguồn hàng triệu dòng

Tại Databricks, cách chúng tôi xây dựng phần mềm đang thay đổi nhanh chóng khi chúng tôi tích cực áp dụng AI vào kỹ thuật. Bối cảnh về các mô hình và công cụ hỗ trợ (harness) cho việc viết mã đã mở rộng nhanh chóng trong năm qua, mang đến cho các nhà phát triển nhiều lựa chọn hơn bao giờ hết. Với nhiều tùy chọn hơn, việc hiểu rõ các tác nhân lập trình (coding agents) nào mang lại hiệu suất tốt nhất cho các tác vụ lập trình thực tế, cũng như hiểu cách hiệu suất tác vụ thay đổi theo giá cả, đã trở nên quan trọng hơn bao giờ hết.

Bài viết này chia sẻ kết quả và phương pháp luận của bộ tiêu chuẩn đánh giá lập trình nội bộ mà chúng tôi đã xây dựng tại Databricks, nhằm đánh giá các công cụ dựa trên những tác vụ lập trình thực tế mà các kỹ sư của chúng tôi đã thực hiện trên cơ sở mã nguồn của Databricks. Các tác vụ bao gồm việc chỉnh sửa trên cơ sở mã nguồn hàng triệu dòng, bao phủ nhiều ngôn ngữ phổ biến (Python, Go, Typescript, Scala, v.v.) và cả tác vụ lẫn giải pháp đều được xem xét kỹ lưỡng để đảm bảo tính chính xác. Đây không phải là một đánh giá toàn diện, nhưng quá trình này đã mang lại những hiểu biết giúp đội ngũ kỹ thuật của chúng tôi làm việc hiệu quả hơn đáng kể với các tác nhân lập trình. Dưới đây, bạn có thể thấy cách các mô hình và công cụ hỗ trợ đạt điểm trên bộ tiêu chuẩn đánh giá tổng thể:

Hình 1: Chi phí so với Hiệu suất trên bộ tiêu chuẩn đánh giá của chúng tôi

Những kết luận chính từ phân tích của chúng tôi là:

Hãy cùng đi sâu hơn vào từng điểm một.

Các mô hình được phân nhóm thành các "tầng năng lực" cơ bản

Việc kết quả cụ thể chênh lệch một vài điểm thường có thể được bù trừ trong các tác vụ thực tế. Chúng tôi tập trung nhiều hơn vào các mô hình chủ đề giúp chúng tôi suy luận về việc nên sử dụng mô hình nào cho các tác vụ khác nhau. Trên thực tế, kết quả cho thấy sự phân nhóm rõ ràng của các mô hình và công cụ hỗ trợ thành 3 tầng năng lực.

Hình 2: Ba tầng năng lực riêng biệt xuất hiện trong kết quả tổng thể của chúng tôi, với sự tinh tế trong việc mô hình nào hiệu quả ở mỗi nhóm

Ở phân khúc hiệu suất cao nhất, chúng tôi thấy rằng các mô hình thông minh nhất rất hiệu quả trong việc giải quyết mọi loại vấn đề, nhưng chúng lại rất đắt đỏ. Các mô hình có trí thông minh trung bình và thấp hơn vẫn rất hiệu quả với các tác vụ thông thường, và trong nhiều trường hợp, chúng cũng rẻ hơn đáng kể.

Hàng ngày, các kỹ sư thực hiện rất nhiều công việc khác nhau với độ phức tạp chênh lệch đáng kể: các tác vụ vận hành phổ biến như bật/tắt một cờ (flag) hoặc cập nhật cấu hình không đòi hỏi các mô hình cực kỳ thông minh, nhưng các nghiên cứu thiết kế chuyên sâu thì có. Tuy nhiên, trước đây, các mô hình mặc định của chúng tôi luôn là những mô hình đắt đỏ nhất. Dựa trên phân tích này, chúng tôi xác định rằng mình nên đẩy nhiều công việc hơn sang các lớp mô hình như Haiku và GPT 5.4 Mini.

Các mô hình mở đã sẵn sàng cho lập trình

Đã có rất nhiều sự hào hứng về GLM 5.2, và kết quả của chúng tôi cho thấy bằng chứng rằng GLM có thể là mô hình sử dụng hàng ngày cho nhiều nhà phát triển của chúng tôi. Nó nằm trong tầng năng lực hàng đầu, ngang bằng về mặt thống kê với Opus 4.8 về chất lượng, nhưng có chi phí là 1,28 USD/tác vụ so với 1,94 USD của Opus.

Điểm chất lượng của GLM nhất quán với phản hồi định tính mà chúng tôi nhận được từ các nhà phát triển nội bộ, những người đã thử nghiệm GLM cho công việc phát triển hàng ngày. Nhờ hiệu suất tuyệt vời cho các tác vụ lập trình thường nhật, chúng tôi đã tập trung vào việc cung cấp GLM với hiệu suất tốt nhất, và bằng chứng cho thấy đã đến lúc bắt đầu triển khai chúng như những công cụ hỗ trợ hàng ngày cho việc lập trình.

Giá mỗi tác vụ so với giá mỗi token

Các nhà phát triển thường ước tính chi phí token để xác định mức độ đắt đỏ của một mô hình khi hoàn thành các tác vụ lập trình. Tuy nhiên, chúng tôi nhận thấy rằng chi phí token thường là một chỉ số kém hiệu quả để đánh giá chi phí tác vụ tổng thể, do sự khác biệt về hiệu quả suy luận giữa các mô hình. Điều này nhấn mạnh sự cần thiết của việc đánh giá theo cấp độ tác vụ, vì hình thái và độ phức tạp của tác vụ có thể khác nhau trong các bối cảnh khác nhau.

Ví dụ, Sonnet 5 rẻ hơn khoảng 1,7 lần mỗi token so với Opus 4.8, nhưng trên các tác vụ của chúng tôi, chúng tôi thấy rằng Sonnet tốn 2,09 USD/tác vụ so với 1,94 USD của Opus, trong khi đạt điểm thấp hơn 6 điểm về mức độ hoàn thành tác vụ (81% so với 87%). Điều này chủ yếu là do Sonnet 5 làm việc lâu hơn và đọc nhiều hơn để đạt được kết quả, tiêu tốn nhiều hơn 1,9 lần số token.

Các công cụ hỗ trợ (harness) có tác động lớn đến hiệu quả

Khi chúng tôi chạy cùng một mô hình với cùng nỗ lực tư duy thông qua hai công cụ hỗ trợ khác nhau (Claude Code/Codex so với Pi), chúng tôi quan sát thấy chi phí mỗi tác vụ chênh lệch đáng kể (hơn 2 lần trong một số trường hợp), trong khi chất lượng vẫn giữ nguyên. Sự khác biệt chính nằm ở lượng ngữ cảnh mà mỗi công cụ hỗ trợ cung cấp cho mô hình trong mỗi lượt.

Pi gửi ít ngữ cảnh hơn khoảng 3 lần mỗi lượt. Nó quản lý ngữ cảnh tốt hơn, duy trì một tập hợp làm việc chặt chẽ hơn và hoàn thành các tác vụ trong ít lượt chạy hơn.

Bài học ở đây không phải là một công cụ hỗ trợ luôn rẻ hơn hoặc các công cụ hỗ trợ gốc (native) thì tệ hơn. Thay vào đó, việc lựa chọn mô hình chỉ là một mảnh ghép của bức tranh tổng thể. Việc thiết lập sự linh hoạt này là lý do tại sao chúng tôi đầu tư vào Omnigent để giúp việc hoán đổi mô hình và công cụ hỗ trợ trở nên liền mạch.

Tại sao phải tự xây dựng bộ tiêu chuẩn đánh giá?

Các bộ tiêu chuẩn đánh giá công khai như SWE-Bench và TerminalBench rất hữu ích, nhưng chúng không thể trả lời các câu hỏi mà chúng tôi đặt ra. Có một vài lý do cho điều này:

Bằng cách xây dựng bộ tiêu chuẩn đánh giá dựa trên các PR (Pull Request) của chính mình, chúng tôi có thể đưa ra các quyết định này với sự tự tin cao hơn rằng chúng tôi sẽ không gây cản trở cho các nhà phát triển khi triển khai các tối ưu hóa.

Cách chúng tôi xây dựng bộ tiêu chuẩn đánh giá

Chúng tôi đã sử dụng Unity AI Gateway để ghi lại nhật ký của tất cả các tương tác lập trình, điều này cho phép chúng tôi phân tích độ phức tạp của các tác vụ mà các kỹ sư giải quyết bằng cách sử dụng các tác nhân lập trình. Có sự đa dạng đáng kể về độ phức tạp của tác vụ, với khoảng một phần tư được gắn nhãn là công việc có độ phức tạp thấp và khoảng 60% là độ phức tạp trung bình.

Tuy nhiên, các mô hình đắt tiền lại là các mô hình mặc định mà các kỹ sư sử dụng, vì vậy rõ ràng có một cơ hội lớn để cải thiện hiệu quả.

Xây dựng tác vụ

Các kỹ sư của chúng tôi hợp nhất hàng ngàn thay đổi mã nguồn mỗi ngày, vì vậy chúng tôi đã có một tập dữ liệu tuyệt vời để xây dựng. Một Pull Request tốt là một tài liệu phong phú, với các commit cho thấy sự lặp lại từ nhà phát triển, sự đánh giá từ con người và các bài kiểm tra giúp xác minh rằng thay đổi mã nguồn là trung thực với ý định ban đầu. Tuy nhiên, chúng tôi cần một vài bước kiểm tra chất lượng và bộ lọc để xây dựng một bộ tiêu chuẩn đánh giá chất lượng cao từ chúng:

Khi đã có các PR ứng viên, chúng tôi tập trung vào việc xây dựng các tác vụ được chỉ định rõ ràng bằng cách:

Kết quả của quá trình này là một tác vụ đơn lẻ trong bộ tiêu chuẩn đánh giá. Dưới đây là một ví dụ đơn giản hóa:

Mặc dù chúng tôi sử dụng kịch bản và AI để tạo ra các tác vụ ứng viên, chúng tôi đã đánh giá từng mẫu bằng tay. Trong một số trường hợp, chúng tôi thấy rằng các bài kiểm tra trong PR gốc cần được viết lại để cho phép một cách triển khai thay thế hoặc để khắt khe hơn, điều mà chúng tôi đã thực hiện thủ công (không dùng AI). Tương tự, chúng tôi cũng tìm thấy các trường hợp cần cải thiện mô tả tác vụ để làm cho chúng được chỉ định rõ ràng.

Hình 3: Trước và sau khi áp dụng vào bộ kiểm tra của chúng tôi: bài kiểm tra trước đó dựa trên việc xác minh khớp chuỗi chính xác, dẫn đến một số lỗi khi mô hình cố gắng giải quyết tác vụ. Đây không phải là cách tốt để kiểm tra đầu ra không xác định, vì vậy nó đã được viết lại để đánh giá hành vi thay vì kết quả.

Chúng tôi đã khởi tạo các công cụ hỗ trợ tác nhân lập trình và các mô hình bằng cách sử dụng các thiết lập tiêu chuẩn, có sẵn, với tất cả các công cụ phổ biến mà các kỹ sư Databricks có thể sử dụng.

Khi tác nhân tuyên bố rõ ràng rằng nó đã hoàn thành tác vụ, chúng tôi kiểm tra mã đó, vá các bài kiểm tra đã được giữ lại và đánh giá các bài kiểm tra để xác định xem tác vụ đó có "đạt" đối với sự kết hợp giữa mô hình + công cụ hỗ trợ đó hay không. Chúng tôi không sử dụng LLM làm giám khảo để đánh giá tính đúng đắn, vì chúng tôi nhận thấy rằng điều này khuyến khích việc "nghe có vẻ đúng" hơn là "thực sự đúng".