Đánh giá hiệu quả của AI Agents trong việc sửa lỗi trên Kubernetes

Brandon Foley gần đây đã công bố một nghiên cứu đo lường chi tiết trên blog của Cloud Native Computing Foundation (CNCF), tập trung vào khả năng của các tác nhân AI lập trình (AI coding agents) trong việc xử lý lỗi thực tế trên hệ thống Kubernetes. Nghiên cứu này đưa ra những góc nhìn thú vị về tiềm năng cũng như những hạn chế hiện tại của AI trong quy trình phát triển phần mềm.

Cấu hình AI Agents trong bài kiểm tra

Phương pháp thử nghiệm

Để đánh giá thực tế, tác giả đã tích hợp các tác nhân AI vào quy trình làm việc hàng ngày và sử dụng các pull request (PR) từ kho lưu trữ Kubernetes làm chuẩn mực. Các lỗi này là những lỗi thực tế đã được các đóng góp viên sửa chữa. Mỗi tác nhân AI chỉ nhận được mô tả của vấn đề (issue description), không có bất kỳ gợi ý nào từ PR hay diff mã nguồn.

Nghiên cứu đã thử nghiệm ba cấu hình tác nhân khác nhau trên chín báo cáo lỗi của Kubernetes, bao gồm các subsystem như kubelet, scheduler, networking, storage và apps. Ba cấu hình bao gồm:

• RAG-only: Chỉ sử dụng truy xuất thông tin (Retrieval-Augmented Generation) thông qua KAITO RAG Engine (sử dụng Qdrant), kết hợp khớp từ khóa BM25 và tìm kiếm ngữ nghĩa.
• Hybrid: Tiếp cận kết hợp, yêu cầu khám phá qua RAG trước rồi mới truy cập hệ thống tệp cục bộ.
• Local-only: Hoàn toàn dựa vào bản sao kho lưu trữ cục bộ mà không có chỉ mục truy xuất.

Tất cả các phiên bản đều sử dụng cùng một mô hình (Claude Opus 4.6), giới hạn thời gian 5 phút và định dạng đầu ra giống nhau; biến số duy nhất là cách thức tác nhân tiếp cận mã nguồn.

Tốc độ và Chi phí

Về mặt tốc độ và chi phí, kết quả cho thấy sự khác biệt rõ rệt. Cách tiếp cận RAG-only luôn nhanh nhất với thời gian trung bình 76 giây, do nó bỏ qua việc điều hướng hệ thống tệp và chỉ tạo mã từ các đoạn trích xuất. Ngược lại, cách tiếp cận Hybrid chậm nhất, trung bình khoảng hai phút rưỡi, do giai đoạn RAG bắt buộc tạo ra chi phí phụ trước khi bắt đầu khám phá cục bộ.

Về kinh tế token, Hybrid tốn kém nhất không phải vì đọc nhiều mã hơn, mà vì thực hiện nhiều lần gọi mô hình nhất. Do API không trạng thái (stateless), mọi cuộc gọi đều phải phát lại toàn bộ lịch sử trò chuyện. Số lượng cuộc gọi là yếu tố lớn nhất ảnh hưởng đến cả chi phí độ trễ.

Tính chính xác và Thách thức về Phạm vi

Tuy nhiên, bức tranh về tính chính xác lại phức tạp hơn. Chế độ thất bại chủ yếu không phải là các bản sửa lỗi sai, mà là bản sửa lỗi chưa hoàn thiện. Các tác nhân thường giải quyết được "lỗi chính", nhưng bỏ qua các thay đổi liền kề, sửa một phần triển khai nhưng bỏ quên phần thứ hai, hoặc vá vấn đề cốt lõi nhưng lại bỏ qua các điều chỉnh cần thiết trong logic tích hợp phụ thuộc.

Mô hình chung là các tác nhân không tự đặt câu hỏi: "Còn cái gì khác cần thay đổi nữa không?". Chúng dừng lại ngay khi vấn đề trực tiếp dường như đã được giải quyết.

Một mô hình thứ yếu xuất hiện liên quan đến các lựa chọn kiến trúc. Khi có sự lựa chọn, các tác nhân có xu hướng giới thiệu các khái niệm trừu tượng mới thay vì tái sử dụng các khái niệm hiện có. Trong một trường hợp thử nghiệm, bản sửa lỗi đúng sử dụng trường RestartCount hiện có; tất cả các tác nhân lại giới thiệu trường Attempt mới. Mặc dù đúng về mặt chức năng, nhưng về mặt kiến trúc thì nó nặng nề hơn.

Chất lượng mô tả vấn đề quan trọng hơn Công cụ

Nghiên cứu chỉ ra rằng chiến lược truy xuất ảnh hưởng đến việc khám phá mã nguồn, nhưng không ảnh hưởng đến chất lượng suy luận. Việc bắt buộc sử dụng RAG đôi khi cải thiện kết quả bằng cách ép buộc tác nhân xác định lớp đánh giá chính sách liên quan trước khi thực hiện sửa chữa. Tuy nhiên, khi mã nguồn liên quan đã được xác định, tác nhân vẫn suy luận cục bộ; truy xuất giúp điều hướng nhưng không hỗ trợ việc hiểu các tác động toàn hệ thống.

Có lẽ phát hiện khả thi nhất là về chất lượng vấn đề (issue quality). Các báo cáo lỗi được mô tả kỹ lưỡng, nêu rõ tên tệp, hàm và hành vi mong đợi, khiến cả ba cách tiếp cận đều đạt điểm cao, san phẳng sự khác biệt về hiệu suất giữa các chiến lược truy xuất. Điều này ngụ ý rằng chất lượng mô tả vấn đề do con người viết ra là một yếu tố quan trọng hơn việc lựa chọn kiến trúc truy xuất.

Kết luận

Nghiên cứu kết luận rằng việc khám phá phạm vi (scope discovery) là thách thức chính đối với các tác nhân AI. Điều này có nghĩa là xác định tất cả các phần cần thay đổi, không chỉ là phần có vẻ bị hỏng. Vấn đề này vẫn là rào cản lớn đối với các hoạt động AI ở quy mô lớn. Các kỹ năng tác nhân có cấu trúc hoặc các playbook được biên tập có thể cải thiện suy luận cấp hệ thống, nhưng đối với các cơ sở mã lớn, những kỹ năng này yêu cầu bảo trì liên tục để đồng bộ với kho lưu trữ, tạo ra một hệ thống bổ sung cần quản lý thay vì một giải pháp sửa chữa một lần.