KwaiKAT ra mắt KAT-Coder-V2.5: Mô hình AI lập trình huấn luyện trên 100.000 kho mã nguồn thực tế

Nhóm KwaiKAT tại Kuaishou đã giới thiệu KAT-Coder-V2.5. Đây là một mô hình lập trình được huấn luyện để vận hành bên trong các kho lưu trữ (repository) thực tế, có thể thực thi, thay vì chỉ xuất ra mã nguồn trong một lượt duy nhất. Mô hình này được cung cấp thông qua StreamLake. Một biến thể mở về trọng số, KAT-Coder-V2.5-Dev, đã được phát hành riêng biệt trên Hugging Face theo giấy phép Apache-2.0.

AutoBuilder: các môi trường thực sự chạy được các bài kiểm thử dự kiến

Nghiên cứu này định hình một tác vụ có thể kiểm chứng dưới dạng một bộ ba. Nó cần một mô tả tác vụ chính xác, một môi trường kho lưu trữ có thể thực thi và một tập hợp các bài kiểm thử xác thực. Một bản vá (patch) chỉ được coi là đúng nếu nó vượt qua tất cả các bài kiểm thử đó.

Các tác vụ được khai thác từ các pull request và commit thực tế, tuân theo dòng dõi của SWE-bench. Thay đổi mã nguồn đã hợp nhất cung cấp một bản vá chuẩn (golden patch) và thay đổi kiểm thử đi kèm cung cấp một bản vá kiểm thử. Văn bản yêu cầu thô bị loại bỏ để làm đặc tả. Thay vào đó, các mô tả được tái tạo thành ba phần: tuyên bố vấn đề dựa trên bản vá chuẩn, các yêu cầu bắt nguồn từ bản vá kiểm thử và các ràng buộc giao diện được suy ra từ cả hai. Sau đó, một bước kiểm tra độ rõ ràng sẽ loại bỏ bất kỳ nội dung nào mơ hồ, không đầy đủ, thiếu đặc tả hoặc không nhất quán nội bộ.

AutoBuilder xử lý phía môi trường. Một tác nhân xây dựng (build agent) phân tích kho lưu trữ và viết một tập lệnh cấu hình để cài đặt các phụ thuộc và chạy các bài kiểm thử từ một bản checkout sạch. Một tác nhân xác thực (verification agent) thực thi tập lệnh đó trong một sandbox biệt lập.

Quy tắc chấp nhận là phần thú vị nhất. Quá trình xác thực không đọc mã thoát (exit code) hay tìm kiếm các mẫu log bằng grep. Nó phân tích cú pháp đầu ra có cấu trúc của khung kiểm thử và chỉ chấp nhận một môi trường khi hơn 90% các bài kiểm thử dự kiến được thu thập và kết quả đạt/không đạt tái lập được qua các lần chạy. Các lỗi được phản hồi dưới dạng thông tin có cấu trúc để sửa chữa lặp đi lặp lại.

Việc kết hợp một môi trường cơ sở được cấu hình sẵn, các mẫu hệ thống xây dựng và một thư viện các công thức xây dựng đã được chắt lọc đã nâng tỷ lệ xây dựng thành công từ 16,5% lên 57,2%. Kết quả là hơn 100.000 môi trường có thể kiểm chứng trải dài trên 12 ngôn ngữ. Lịch sử Git, siêu dữ liệu commit và các dấu vết có thể khai thác khác bị loại bỏ để các tác nhân không thể đọc được giải pháp tham chiếu từ kho lưu trữ.

Bánh đà mở rộng dữ liệu (Data Scaling Flywheel): lọc dựa trên quy trình

Việc lọc các quỹ đạo (trajectories) dựa trên kết quả kiểm thử cuối cùng là gây hiểu lầm. Một số lần chạy thành công dựa vào việc mã hóa cứng (hard-coding), bỏ qua cơ chế hoặc các lối tắt hướng đến bài kiểm thử. Một số lần chạy thất bại lại chứa các hành vi tìm kiếm, định vị và sửa chữa có giá trị.

KwaiKAT giải quyết cả hai hướng. Đối với các trường hợp gần đạt, các gợi ý nhắm mục tiêu ở cấp độ quy trình chỉ ra những gì cần kiểm tra hoặc xác minh mà không tiết lộ giải pháp. Chỉ riêng điều đó đã nâng tỷ lệ vượt qua của các tác vụ trước đây có tỷ lệ vượt qua bằng 0 lên khoảng 20%. Vì các quỹ đạo có gợi ý chứa thông tin không có sẵn tại thời điểm suy luận (inference), bản vá đã xác minh sau đó được sửa lại và một quỹ đạo không có gợi ý được tái tạo từ ngữ cảnh tác vụ gốc. Chỉ những mẫu vượt qua xác minh, không cho thấy sự rò rỉ gợi ý và nhất quán với bản vá mới được giữ lại.

Đối với các lần chạy thành công, các cổng dựa trên quy tắc sẽ loại bỏ các quỹ đạo không hợp lệ, không ổn định hoặc mang tính khai thác. Một giai đoạn chấm điểm sau đó sẽ đánh giá khả năng khám phá, định vị, suy luận trước khi chỉnh sửa, độ trung thực với đặc tả, các quy ước kho lưu trữ, tính tối giản của bản vá, chất lượng xác minh, hành vi phục hồi và tính trung thực.

Cơ chế thứ ba nhắm vào việc quá khớp (overfitting) với bộ khung kiểm thử (harness). Tên công cụ, quy ước đối số, định dạng đầu ra và mẫu nhắc (prompt template) được ngẫu nhiên hóa trong khi chức năng vẫn được bảo toàn. Vì việc xác minh được neo vào kết quả kiểm thử thay vì dấu vết của bộ khung, một tác vụ có thể được phục vụ lại dưới nhiều cấu hình bộ khung khác nhau. Các nhiễu loạn thực tế cũng được đưa vào: thiếu phụ thuộc, lệnh chạy thất bại tạm thời, đầu ra bị cắt ngắn và log nhiễu.

Khám phá quy trình và các con số

Lỗi cơ sở hạ tầng giới hạn phần thưởng trước cả các giới hạn thuật toán

Trong quá trình huấn luyện KAT-Coder-V2, các đường cong phần thưởng chậm ban đầu bị đổ lỗi cho thuật toán RL. Tuy nhiên, một cuộc kiểm tra cho thấy khoảng 16% quỹ đạo thất bại do các vấn đề cơ sở hạ tầng sandbox thay vì chính sách của mô hình, với việc sai lệch ranh giới đôi khi làm trống các quan sát trong khoảng 40 bước và làm hỏng phần thưởng.

Ba bản sửa lỗi cơ sở hạ tầng đã được thực hiện. Đầu tiên, chính sách loại bỏ hình ảnh (image eviction) phát hành sớm đã giảm mức sử dụng đĩa từ 95% xuống 60%, giảm các lần triển khai không hợp lệ do hết thời gian chờ từ 6–7% xuống dưới 1%. Thứ hai, việc sửa các biến môi trường trong quá trình khởi tạo sandbox từ xa đã ngăn chặn các ghi đè hệ thống làm thay đổi phần thưởng trên 6–7% mẫu, giảm lỗi xuống dưới 1%. Thứ ba, Gateway Server đã bỏ qua các điểm cuối chat chính thống—vốn gây ra sự trôi dạt token 40% ở quy mô ~200 lượt bằng cách áp dụng lại apply_chat_template và mã hóa lại token—và gọi trực tiếp /generate để đảm bảo sự căn chỉnh token khi triển khai.

Tổng hợp lại, các bản cập nhật này đã giảm tỷ lệ lỗi phản hồi của sandbox từ khoảng 16% xuống dưới 2% và giảm các sự cố huấn luyện xuống một bậc độ lớn.

PPO bất đối xứng và phần thưởng ba tầng

Nhóm nghiên cứu đã chọn PPO với GAE thay vì các phương pháp quỹ đạo không cần critic vì các bộ khung sản xuất chia các phiên thành các mẫu khác biệt về cấu trúc, gây khó khăn cho các đường cơ sở nhóm.

Sử dụng actor–critic bất đối xứng, Critic nhận được ngữ cảnh huấn luyện đặc quyền (phần thưởng, bài kiểm thử, độ bao phủ, bản vá, siêu dữ liệu, các lượt tương lai), trong khi Actor chỉ thấy trạng thái triển khai. Critic và ngữ cảnh bổ sung bị loại bỏ khi suy luận.

Phần thưởng được chia làm ba tầng: Điểm tác vụ cốt lõi yêu cầu tất cả các bài kiểm thử fail_to_pass và pass_to_pass phải vượt qua; Các ràng buộc hành vi tiêu chuẩn phạt việc trùng lặp, gọi công cụ sai và các phần mã debug còn sót lại; Các ưu đãi cho quỹ đạo thất bại chấm điểm việc truy xuất tệp qua F2 và cung cấp tín dụng kiểm thử một phần.

Năm chuyên gia được hợp nhất thông qua Multi-Teacher On-Policy Distillation sử dụng KL ngược, khởi đầu off-policy và cắt tỉa nhận thức trôi dạt từ Prune-OPD.

Kết quả

Dưới một bộ khung Claude Code thống nhất, KAT-Coder-V2.5 dẫn đầu bảng xếp hạng trên PinchBench với 94,9 điểm, đánh bại Opus 4.8 với 93,5 điểm. Nó đứng thứ hai trên SWE-Bench Pro (65,2 so với 69,2) và KAT Code Bench nội bộ (53,1 so với 57,3).

Tuy nhiên, nó tụt hậu trên Terminal-Bench 2.1, đứng cuối với 60,7 điểm sau GLM-5.1 (61,8) và Opus 4.8 (84,6). Trên SciCode, nó đạt 50,3 điểm, ngang bằng với GLM-5.2.

Đáng chú ý, KAT-Coder-V2.5-Dev mở về trọng số là một mô hình MoE 35B tổng/3B hoạt động riêng biệt, được huấn luyện hậu kỳ trên Qwen3.6-35B-A3B sử dụng 127K ví dụ SFT, sau đó là RL. Được đánh giá trên một giao thức nội bộ riêng biệt, kết quả của nó không thể so sánh với bảng xếp hạng chính.

Những điểm chính cần lưu ý

Hãy xem bài báo, trọng số mô hình trên Hugging Face và trang sản phẩm. Mọi công lao cho nghiên cứu này thuộc về các nhà nghiên cứu của dự án.

Michal Sutter là một chuyên gia khoa học dữ liệu với bằng Thạc sĩ Khoa học Dữ liệu từ Đại học Padova. Với nền tảng vững chắc về phân tích thống kê, học máy và kỹ thuật dữ liệu, Michal xuất sắc trong việc chuyển đổi các tập dữ liệu phức tạp thành những thông tin chi tiết có thể hành động.