GitHub chia sẻ kinh nghiệm thực chiến: Cách đánh giá LLM trước khi đưa vào sản xuất

Đây là những bài học chúng tôi rút ra được khi đánh giá các LLM cho việc quét bí mật (secret scanning) trong môi trường thực tế.

25 tháng 8, 2026

12 phút

Một mô hình ngôn ngữ có thể hoạt động tốt trên các bộ benchmark sạch nhưng vẫn gặp khó khăn với các trường hợp quan trọng trong môi trường production.

Các bộ benchmark và tập dữ liệu được chọn lọc rất hữu ích khi tạo mẫu (prototyping) một hệ thống dựa trên LLM. Chúng giúp các nhóm so sánh các mô hình, thử nghiệm prompt ban đầu và xác định xem một ý tưởng có khả thi về mặt kỹ thuật hay không.

Tuy nhiên, khi một hệ thống tiến gần hơn đến giai đoạn triển khai thực tế (production), vấn đề đánh giá sẽ thay đổi.

Dữ liệu đầu vào thực tế thường mơ hồ. Các nhãn có thể không nhất quán. Bối cảnh quan trọng có thể bị thiếu hoặc bị cắt bớt. Tập dữ liệu đánh giá có thể không phản ánh đúng phân phối dữ liệu trong production. Các trường hợp biên (edge cases) hiếm khi xuất hiện trong các bộ benchmark có thể trở thành nguồn gây lỗi phổ biến. Ngay cả khi các chỉ số ngoại tuyến (offline metrics) được cải thiện, những kết quả đó có thể không chuyển đổi hoàn toàn sang hành vi thực tế trong production.

Chúng tôi đã gặp phải những thách thức này khi đánh giá một hệ thống dựa trên LLM được thiết kế để giảm thiểu các cảnh báo sai (false positives) trong quá trình quét bí mật trên GitHub.

Quét bí mật giúp xác định các thông tin xác thực như token và khóa có thể đã bị đẩy (commit) lên kho lưu trữ. Vì một số chuỗi ký tự ứng viên trông giống như bí mật nhưng thực tế không phải là thông tin xác thực thật, các nhà phát triển có thể lãng phí thời gian để điều tra những cảnh báo không cần khắc phục.

Thay vì xác định xem một LLM có thể phân loại chuỗi ký tự chính xác hay không, chúng tôi cần hiểu liệu hệ thống có thể giảm bớt các cảnh báo gây nhiễu trong khi vẫn duy trì đủ độ thu hồi (recall) để đảm bảo an toàn cho quy trình bảo mật hay không.

Trong bài viết này, chúng tôi chia sẻ những phương pháp đã giúp chúng tôi chuyển từ kết quả thử nghiệm đầy hứa hẹn sang triển khai thực tế. Những bài học này có thể áp dụng rộng rãi cho các hệ thống sử dụng LLM trong phân tích mã nguồn, công cụ dành cho nhà phát triển, bảo mật, phân tích dữ liệu và các quy trình sản xuất khác.

1. Bắt đầu với quyết định về sản phẩm, không phải mô hình

Khi một hệ thống LLM không hoạt động như mong đợi, bản năng đầu tiên thường là điều chỉnh các thành phần kỹ thuật của nó.

Các nhóm có thể viết lại prompt, thêm bối cảnh, đưa thêm một bước suy luận, điều chỉnh pipeline xung quanh hoặc chuyển đổi mô hình. Trước khi thực hiện bất kỳ thay đổi nào trong số này, họ nên xác định quyết định mà việc đánh giá nhằm mục đích hỗ trợ.

Đối với công việc quét bí mật của chúng tôi, chúng tôi đã đặt câu hỏi:

Liệu hệ thống có thể giảm các cảnh báo sai trong khi vẫn duy trì đủ độ thu hồi để đảm bảo an toàn trong quy trình bảo mật thực tế hay không?

Để trả lời câu hỏi này, các nhóm phải quyết định những sai sót nào là có thể chấp nhận được, những chỉ số nào nên thúc đẩy quyết định về sản phẩm và những rào cản (guardrails) nào phải nằm trong ngưỡng xác định.

Trong việc quét bí mật, việc bỏ sót sai một thông tin xác thực thật có thể gây hậu quả nghiêm trọng hơn là yêu cầu nhà phát triển xem xét thêm một cảnh báo. Do đó, chúng tôi không coi độ chính xác (precision) và độ thu hồi (recall) là các chỉ số có thể thay thế cho nhau.

Mục tiêu chính của chúng tôi là giảm các cảnh báo sai và cải thiện độ chính xác. Độ thu hồi đóng vai trò như một ràng buộc an toàn: một thử nghiệm chỉ có thể được tiến hành nếu bất kỳ sự sụt giảm nào vẫn nằm trong phạm vi chấp nhận được đã xác định trước. Điều này cho chúng tôi một cách rõ ràng để đánh giá các sự đánh đổi (tradeoffs). Chúng tôi đã chọn cấu hình đạt được mức giảm cảnh báo sai tốt nhất trong khi vẫn đáp ứng yêu cầu về độ thu hồi và các rào cản vận hành của chúng tôi.

Chúng tôi đã tổ chức các tiêu chí đánh giá thành ba cấp độ:

Kết quả chính (Primary outcome)

Điều này đo lường lợi ích người dùng mà chúng tôi đang cố gắng cải thiện:

Ràng buộc an toàn (Safety constraint)

Điều này ngăn chặn việc một cải tiến rõ ràng gây ra rủi ro bảo mật không thể chấp nhận được:

Rào cản vận hành (Operational guardrails)

Những điều này xác định xem kết quả có thực tế để triển khai hay không:

Sự phân biệt này giúp chúng tôi không coi mọi chỉ số đều có thể thay thế cho nhau. Một thay đổi giúp giảm cảnh báo sai nhưng làm giảm đáng kể độ thu hồi không tự động được coi là một cải tiến. Tương tự, một thay đổi cải thiện chất lượng nhưng làm cho hệ thống quá chậm, đắt đỏ hoặc khó tích hợp cũng vậy.

Hãy xem xét hai kết quả thử nghiệm giả định:

Thử nghiệm A có vẻ mạnh hơn nếu chỉ nhìn vào độ chính xác. Thử nghiệm B phù hợp hơn với mục tiêu sản phẩm vì nó cải thiện trải nghiệm của nhà phát triển mà không vi phạm rào cản về độ thu hồi.

Trước khi đánh giá một hệ thống LLM, hãy quyết định thế nào là thành công đối với người dùng và những rào cản nào hệ thống phải tuân thủ. Chúng tôi muốn tạo ra bằng chứng hỗ trợ cho một quyết định về sản phẩm.

2. Đối xử với đánh giá ngoại tuyến (offline evaluation) như kiểm thử tích hợp (integration testing)

Một hệ thống dựa trên LLM tiếp tục thay đổi sau lần đánh giá thành công đầu tiên, vì vậy đánh giá không nên là một công việc chỉ thực hiện một lần. Các nhóm sửa đổi prompt, áp dụng các mô hình mới, thay đổi cách xây dựng đầu vào và bối cảnh, cũng như tinh chỉnh logic nghiệp vụ xung quanh.

Bất kỳ thay đổi nào trong số này đều có thể cải thiện hệ thống, gây ra lỗi hồi quy (regression) hoặc làm thay đổi hành vi của nó theo cách không mong muốn.

Vì lý do đó, chúng tôi coi việc đánh giá ngoại tuyến tương tự như một bài kiểm thử tích hợp toàn diện (end-to-end integration test). Chúng tôi chạy lại nó bất cứ khi nào thực hiện thay đổi đáng kể đối với prompt, mô hình, cách xây dựng đầu vào hoặc logic hệ thống rộng hơn.

Việc đánh giá cũng cần phải có khả năng lặp lại để mỗi kết quả mới có thể được so sánh với một đường cơ sở (baseline) đã biết. Đối với mỗi lần chạy, chúng tôi ghi lại prompt, mô hình, phiên bản tập dữ liệu và cấu hình hệ thống.

Điều này giúp chúng tôi có thể trả lời các câu hỏi như:

Nếu không có kỷ luật này, các nhóm có thể dễ dàng so sánh các kết quả được tạo ra trong các điều kiện khác nhau và quy nhầm sự cải thiện cho một thay đổi không chính xác.

Thay đổi từng biến số chính một tại một thời điểm.