GitHub Copilot tối ưu chi phí vận hành AI mà không làm giảm chất lượng code

Tại sao các kết quả đầu ra ngắn hơn lại có thể tốn kém hơn, và cách GitHub Copilot giảm thiểu công việc lãng phí trong toàn bộ quá trình lập trình.

Ngày 2 tháng 9 năm 2026

11 phút

Chất lượng đầu ra rất quan trọng khi làm việc với các tác nhân lập trình AI (AI coding agents), nhưng hiệu quả thực sự đến từ việc hoàn thành công việc một cách nhanh chóng, hiệu quả và với đúng ngữ cảnh.

Đó là lý do tại sao chỉ tính số lượng token của các tương tác riêng lẻ không phải là thước đo hiệu quả có ý nghĩa. Mục tiêu không nên là sử dụng ít token hơn, mà là khai thác đúng lượng ngữ cảnh cần thiết để thúc đẩy công việc tiến triển. Một phản hồi ngắn gọn từ công cụ đôi khi có thể đòi hỏi thêm các lệnh gọi hoặc công việc bổ sung nếu nó bỏ sót thông tin mà tác nhân cần, cuối cùng khiến tác vụ trở nên chậm hơn và tốn kém hơn.

Đó là lý do tại sao chúng tôi muốn tối ưu hóa cho kết quả đầu ra thay vì việc gọi công cụ. Bài viết này xem xét bốn thay đổi trong GitHub Copilot nhằm hiện thực hóa nguyên tắc đó:

Các thay đổi khả thi đã được đánh giá ngoại tuyến (offline) bằng cách sử dụng các bộ tiêu chuẩn đánh giá lập trình tác nhân (agentic coding benchmarks). Những thay đổi hứa hẹn nhất sau đó được xác thực thông qua các thử nghiệm trực tuyến (online) có kiểm soát trước khi triển khai. Các ví dụ trong bài viết này đến từ GitHub Copilot CLI. Nhiều sản phẩm Copilot khác, chẳng hạn như ứng dụng GitHub Copilot và Copilot code review, cũng sử dụng cùng một hệ thống nền tảng và trở nên hiệu quả hơn nhờ những cải tiến này.

Cái bẫy của số liệu cục bộ

Việc rút ngắn đầu ra từ mỗi lần gọi công cụ là cách phổ biến để giảm chi phí cho tác nhân. RTK (Rust Token Killer) là một tiện ích giúp rút ngắn đầu ra của shell trước khi tác nhân đọc nó. Chúng tôi đã đánh giá hiệu quả của nó trên GitHub Copilot bằng cách sử dụng các bộ tiêu chuẩn đánh giá lập trình tác nhân của mình.

Trong cấu hình hệ thống và tiêu chuẩn đánh giá của chúng tôi, RTK đã rút ngắn một số phản hồi, nhưng khi phần văn bản bị lược bỏ trở nên quan trọng, mô hình đôi khi phải mở lại đầu ra gốc hoặc chạy lại lệnh để khôi phục những gì nó cần.

Những bước khôi phục đó làm tăng số lượt tương tác và kéo theo nhiều ngữ cảnh hơn. Phản hồi của công cụ riêng lẻ thì ngắn hơn, nhưng tính trung bình, tác vụ lại sử dụng nhiều token hơn và mất nhiều thời gian hơn. Chúng tôi tiết kiệm được token ở quy mô cục bộ nhưng lại tiêu tốn nhiều hơn ở quy mô tổng thể.

Kết quả này áp dụng cho các tích hợp và khối lượng công việc mà chúng tôi đã thử nghiệm, không áp dụng cho mọi cấu hình RTK hoặc việc nén đầu ra nói chung. Điều này có nghĩa là số lượng token trên mỗi lần gọi công cụ là mục tiêu sai lầm. Một thay đổi về hiệu quả phải được đánh giá trên toàn bộ tác vụ, từ yêu cầu của người dùng cho đến kết quả cuối cùng.

Hữu ích hơn là xem xét những gì chúng ta có thể loại bỏ mà không khiến mô hình phải lặp lại công việc.

Nén nhiễu, bảo toàn thông tin hữu ích

Mục tiêu là rút ngắn đầu ra lặp đi lặp lại trong khi vẫn bảo toàn ngữ cảnh mà một tác nhân cần để hoàn thành công việc mà không phải thực hiện lại các bước trước đó.

Phân tích các lần chạy tiêu chuẩn đánh giá cho thấy đầu ra của quá trình cài đặt, xây dựng (build), kiểm thử (test) và kiểm tra lỗi (lint) thường chứa nhiễu lặp lại, trong khi đầu ra dạng mã nguồn và kết quả của các lệnh tùy ý có nhiều khả năng chứa thông tin mà tác nhân cần. Phân tích đó đã định hình nên một bộ nén đầu ra có chọn lọc, một phần dựa trên RTK và các phương pháp tương tự.

Nguyên mẫu đã được đánh giá trên các bộ tiêu chuẩn đánh giá lập trình tác nhân và một loạt các kho lưu trữ mã nguồn mở, vận hành các hệ thống xây dựng, kiểm thử và kiểm tra lỗi của chúng.

Các phiên bản đầu tiên quá mạnh tay. Chúng khiến mô hình phải lặp lại công việc hoặc đọc toàn bộ đầu ra đã lưu, làm tăng chi phí từ đầu đến cuối và giảm tỷ lệ thành công của tác vụ. Ví dụ, ban đầu chúng tôi nén git diff nhưng đã loại bỏ bộ lọc đó sau khi các tác vụ đánh giá cho thấy các tác nhân phải mở lại đầu ra gốc để khôi phục thông tin bị thiếu.

Những thất bại ban đầu đó dẫn đến chính sách ba phần:

Phiên bản được phát hành đã hình thành thông qua quá trình đánh giá và tinh chỉnh lặp đi lặp lại. Nó mang tính bảo thủ không phải vì mục tiêu là xây dựng một bộ nén bảo thủ, mà vì đó là những gì các đánh giá đã chứng minh.

Khi đầu ra được nén, tác nhân vẫn có thể truy xuất bản gốc hoàn chỉnh thông qua đường dẫn khôi phục trực tiếp.

Đường dẫn khôi phục đó vừa là cơ chế an toàn vừa là tín hiệu đánh giá. Chúng tôi theo dõi xem liệu tác nhân có mở bản gốc đã lưu, chạy lại các lệnh, lặp lại quá trình khám phá, thu hẹp phạm vi tìm kiếm hay thực hiện thêm các lượt tương tác hay không. Việc khôi phục thường xuyên sẽ cho thấy bộ nén đã loại bỏ thứ gì đó có giá trị.

Trên các tác vụ ngoại tuyến nơi quá trình nén đầu ra được kích hoạt, không có sự suy giảm đáng kể nào về tỷ lệ thành công của tác vụ được phát hiện, và các tác nhân cực kỳ hiếm khi mở lại bản gốc đã lưu. Trong thử nghiệm trực tuyến, chi phí trung bình giảm nhẹ mà không phát hiện sự suy giảm đáng kể nào trong các chỉ số chất lượng được theo dõi.

Loại bỏ định dạng trước khi loại bỏ thông tin

Một tối ưu hóa token sạch đến từ công cụ view, thứ mà các tác nhân sử dụng để đọc nội dung tệp vào ngữ cảnh.

Trước đây, view thêm tiền tố là một con số vào mỗi dòng trước khi hiển thị nội dung cho mô hình. Các công cụ chỉnh sửa tệp cũ hơn đã sử dụng những con số đó để nhắm mục tiêu thay đổi, nhưng các công cụ hiện tại thay vào đó lại khớp với mã xung quanh và không sử dụng số dòng. Các tiền tố số dòng vẫn tồn tại mặc dù quy trình làm việc thông thường không còn sử dụng chúng nữa.

Mỗi tiền tố đều nhỏ. Tuy nhiên, khi lặp lại trên mỗi dòng và mỗi tệp được đọc, định dạng không sử dụng đó đã tích tụ trong suốt phiên làm việc. Vì vậy, chúng tôi đã loại bỏ nó.

Số dòng vẫn hữu ích trong các bản diff và các đoạn mã ngắn. Chúng gây lãng phí ở đây vì chúng được gắn vào mọi tệp được đọc mà không phục vụ quy trình chỉnh sửa hiện tại.

Việc loại bỏ chúng khiến chi phí suy luận của mô hình giảm khoảng 5% trong các bộ tiêu chuẩn đánh giá lập trình tác nhân ngoại tuyến. Tỷ lệ thành công vẫn nằm trong phạm vi biến thiên dự kiến giữa các lần chạy, và các lỗi chỉnh sửa không tăng lên.

Sau đó, chúng tôi đã thử nghiệm thay đổi này với người dùng Copilot CLI. Thử nghiệm trực tuyến đã giảm chi phí suy luận mô hình trung bình hàng ngày cho mỗi người dùng khoảng 3%, mà không phát hiện sự suy giảm đáng kể nào trong các chỉ số chất lượng hoặc mức độ hài lòng mà chúng tôi theo dõi.

Đối với các nhà phát triển, điều đó có nghĩa là cửa sổ ngữ cảnh có nhiều không gian hơn cho chính công việc thay vì các định dạng mà tác nhân không sử dụng.

Đây là thay đổi lý tưởng: không có hướng dẫn mới cho mô hình, không có nguồn thông tin nào cần khôi phục và không có quyết định bổ sung nào cần đưa ra. Nội dung tệp đến được với mô hình mà không bị thay đổi.

Nén các câu lệnh (prompt) mà không nén ý định

Các câu lệnh mang theo những hướng dẫn định hình cách thức hoạt động của một tác nhân, và chúng được gửi đến mô hình trong mỗi lượt tương tác. Việc rút ngắn chúng chỉ cải thiện hiệu quả nếu tác nhân vẫn giữ được các hành vi mà các nhà phát triển phụ thuộc vào.

Trong GitHub Copilot, công cụ task khởi chạy các tác nhân chuyên biệt cho công việc song song. Hướng dẫn của nó đã tích tụ qua các mô tả công cụ, lược đồ, định nghĩa tác nhân, hướng dẫn hệ thống và các công cụ đi kèm.

Một vòng lặp meta-prompting, trong đó Copilot lặp đi lặp lại việc tự viết câu lệnh của chính mình, đã giảm câu lệnh đó xuống còn khoảng một nửa. Copilot đã tạo ra và tinh chỉnh các ứng viên nhỏ hơn, và các bài kiểm tra hành vi có mục tiêu đã kiểm tra các yêu cầu mà chúng tôi muốn bảo toàn.