Cách đánh giá LLM trước khi đưa vào sản xuất: Bài học từ GitHub

Việc đưa một mô hình ngôn ngữ lớn (LLM) vào môi trường sản xuất không đơn giản như chạy thử trên notebook hay demo. Khi ứng dụng vào các tác vụ thực tế — như quét bí mật (secret scanning) trong kho mã nguồn — các kỹ sư phải đối mặt với hàng loạt câu hỏi về độ chính xác, độ trễ, chi phí và khả năng mở rộng. Bài viết này tổng hợp những bài học từ Mariko, Principal Applied Scientist tại Microsoft, người đang dẫn dắt các quy trình AI tác nhân (agentic AI) cho vận hành an ninh mạng, để giúp bạn xây dựng quy trình đánh giá LLM một cách bài bản trước khi "lên sóng".

Vì sao đánh giá LLM trong sản xuất lại khác biệt?

Trong môi trường nghiên cứu, bạn thường đánh giá mô hình trên các bộ dữ liệu chuẩn (benchmark) như MMLU hay HumanEval. Nhưng khi bước vào sản xuất, dữ liệu thực tế luôn "bẩn" hơn: có nhiễu, thiếu ngữ cảnh, và đôi khi chứa những trường hợp ngoại lệ mà benchmark không bao giờ đề cập đến.

Đặc biệt với tác vụ quét bí mật — phát hiện API key, token, mật khẩu bị lộ trong mã nguồn — độ chính xác là yếu tố sống còn. Một false positive (báo động giả) có thể làm phiền hà hàng nghìn nhà phát triển, trong khi một false negative (bỏ sót) có thể dẫn đến rò rỉ dữ liệu nghiêm trọng. Vì vậy, quy trình đánh giá cần được thiết kế riêng cho bối cảnh sử dụng cụ thể.

Xây dựng bộ dữ liệu đánh giá thực tế

Bài học đầu tiên và quan trọng nhất: đừng chỉ dựa vào benchmark công khai. Bạn cần xây dựng bộ dữ liệu đánh giá (evaluation set) từ chính dữ liệu thực tế của hệ thống.

Mariko khuyến nghị các bước sau:

• Thu thập mẫu từ lịch sử sản xuất: Lấy các mẫu mã nguồn, log, hoặc phản hồi người dùng thực tế để tạo bộ dữ liệu phản ánh đúng phân bố dữ liệu bạn sẽ gặp.
• Dán nhãn thủ công với chuyên gia: Không thể tự động hóa hoàn toàn khâu gán nhãn. Cần có ít nhất 2-3 chuyên gia trong lĩnh vực (ví dụ: kỹ sư bảo mật) để dán nhãn và kiểm tra chéo, đảm bảo tính nhất quán.
• Bao gồm các trường hợp ranh giới (edge cases): Ví dụ, một chuỗi ký tự giống API key nhưng thực ra chỉ là placeholder, hay một token hết hạn nhưng vẫn còn trong mã nguồn. Đây là những tình huống khiến mô hình dễ nhầm lẫn nhất.

Lựa chọn chỉ số đánh giá phù hợp với mục tiêu kinh doanh

Không có một chỉ số duy nhất nào đủ tốt để đánh giá LLM. Tùy thuộc vào bài toán, bạn cần kết hợp nhiều thước đo:

• Precision (độ chính xác): Tỷ lệ các cảnh báo đúng trên tổng số cảnh báo. Trong secret scanning, precision thấp sẽ gây nhiễu và làm mất niềm tin của người dùng.
• Recall (độ phủ): Tỷ lệ các bí mật thực sự được phát hiện. Recall thấp đồng nghĩa với việc bỏ sót rủi ro bảo mật.
• F1-score: Cân bằng giữa precision và recall, hữu ích khi bạn cần một con số tổng hợp.

Ngoài ra, đối với các hệ thống có tương tác người dùng, hãy xem xét thêm tỷ lệ chấp nhận của người dùng (user acceptance rate) — tức là người dùng có đồng ý với kết quả của mô hình hay không. Điều này đặc biệt quan trọng vì một mô hình có điểm số cao trên lý thuyết nhưng gây khó chịu cho người dùng cuối sẽ thất bại trong sản xuất.

Xây dựng quy trình thử nghiệm có hệ thống

Một sai lầm phổ biến là chỉ chạy thử nghiệm một lần rồi kết luận. Thay vào đó, Mariko nhấn mạnh cần thiết lập một quy trình đánh giá lặp lại và có thể tái tạo:

"Bạn cần có một pipeline đánh giá tự động hóa càng nhiều càng tốt, nhưng vẫn giữ con người trong vòng lặp để xử lý các trường hợp ngoại lệ."

Các bước cụ thể bao gồm:

• Tạo các phiên bản dữ liệu cố định: Chia bộ dữ liệu thành tập huấn luyện, tập kiểm tra và tập xác thực riêng biệt. Không bao giờ để lẫn lộn giữa các tập này.
• Chạy thử nghiệm trên nhiều cấu hình mô hình: So sánh giữa các phiên bản model khác nhau, các tham số temperature, top-p, hay prompt khác nhau để tìm ra cấu hình tối ưu.
• Đánh giá liên tục thay vì một lần: Khi dữ liệu sản xuất thay đổi, bạn cần định kỳ chạy lại đánh giá để phát hiện sự suy giảm chất lượng (model drift).

Những cạm bẫy thường gặp khi đánh giá LLM

Dựa trên kinh nghiệm thực tế, Mariko liệt kê một số lỗi phổ biến:

• Đánh giá trên dữ liệu "sạch" giả tạo: Dữ liệu từ benchmark thường quá chuẩn, không phản ánh độ nhiễu của thực tế. Kết quả đánh giá có thể đạt 99% nhưng khi triển khai thực tế chỉ đạt 60%.
• Chỉ nhìn vào điểm trung bình: Hãy phân tích kết quả theo từng nhóm dữ liệu (ví dụ: theo ngôn ngữ lập trình, theo loại bí mật) để phát hiện những điểm yếu cụ thể của mô hình.
• Bỏ qua yếu tố chi phí và độ trễ: Một mô hình chính xác hơn nhưng chậm gấp đôi và tốn gấp ba chi phí có thể không phù hợp với hệ thống xử lý hàng triệu request mỗi ngày. Luôn đặt đánh giá chất lượng trong bối cảnh ràng buộc về infrastructure.

Kết luận: Đánh giá là một quá trình, không phải một điểm đến

Việc đánh giá LLM trước khi đưa vào sản xuất không nên được coi là một bước một lần (one-time step), mà là một vòng lặp liên tục song hành với vòng đời phát triển sản phẩm. Khi dữ liệu thay đổi, khi mô hình mới ra mắt, khi yêu cầu người dùng thay đổi — bạn cần quay lại đánh giá và cập nhật.

Dù bạn đang xây dựng hệ thống quét bí mật, chatbot hỗ trợ khách hàng, hay công cụ sinh mã tự động, nguyên tắc vàng vẫn là: hiểu rõ dữ liệu thực tế, chọn chỉ số gắn với mục tiêu kinh doanh, và thiết lập quy trình đánh giá có thể lặp lại. Chỉ khi đó, bạn mới có thể tự tin đưa LLM vào sản xuất một cách an toàn và hiệu quả.