Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Đánh giá mô hình AI là kiểm tra đầu ra hoặc hành động trên một bộ nhiệm vụ theo tiêu chí đã xác định. Một phép đánh giá hữu ích cần phản ánh công việc thực tế: kết quả có đúng không, có ổn định không, mất bao lâu và tốn bao nhiêu để hoàn thành.
Một mô hình đứng đầu bảng xếp hạng có thể không phải lựa chọn tốt nhất cho ứng dụng của bạn. Bài kiểm tra công khai và công việc thực tế có thể khác ngôn ngữ, độ dài đầu vào, định dạng và mức độ chấp nhận sai sót.
Benchmark giúp tìm ứng viên. Quyết định sử dụng cần thêm một bộ đánh giá phản ánh đúng việc bạn muốn giao.
Bắt đầu bằng định nghĩa “làm tốt”
Giả sử bạn xây công cụ trích thông tin từ email đăng ký sự kiện. Kết quả mong muốn gồm họ tên, ngày tham dự và nhu cầu hỗ trợ. “Văn phong tự nhiên” không phải tiêu chí chính; giữ đúng tên và không tự điền dữ liệu thiếu mới quan trọng.
Viết tiêu chí trước khi thử mô hình. Với từng trường thông tin, xác định thế nào là đúng, sai và không đủ dữ liệu. Nếu email có hai ngày nhưng chỉ một ngày là lựa chọn cuối cùng, đáp án chuẩn phải thể hiện điều đó.
Nghiên cứu Holistic Evaluation of Language Models, hay HELM, nhấn mạnh đánh giá theo nhiều chiều. Độ chính xác là một phần; độ vững trước biến đổi đầu vào, công bằng và hiệu quả cũng có vai trò. Bạn không nhất thiết đo mọi chỉ số, nhưng phải chọn những chiều liên quan tới sản phẩm.
Tạo bộ dữ liệu nhỏ nhưng có chủ đích
Bắt đầu với các tình huống thực tế đã được phép sử dụng và loại bỏ thông tin nhận dạng không cần thiết. Nhóm chúng theo kiểu khó: tiếng Việt không dấu, tên riêng hiếm, thông tin thiếu, nội dung mâu thuẫn và đầu vào dài.
Đừng chỉ đưa vào các ví dụ sạch và dễ. Nếu người dùng thường viết tắt, bộ kiểm tra cũng phải có viết tắt. Nếu nhiệm vụ cần từ chối khi thiếu dữ liệu, hãy có câu hỏi không thể trả lời.
Giữ riêng một tập để thử sau khi bạn đã chỉnh prompt. Liên tục sửa prompt dựa trên cùng vài ví dụ có thể khiến bạn tối ưu cho chính bộ kiểm tra đó, mà không biết kết quả có áp dụng cho đầu vào mới hay không.
Ghi phiên bản dữ liệu và lý do chọn đáp án. Khi hai người đánh giá bất đồng, xem lại quy tắc trước khi kết luận mô hình sai. Đôi khi đề bài của chính bạn chưa đủ rõ.
Đo cả hệ thống, không chỉ một câu trả lời
Với dữ liệu có cấu trúc, kiểm tra định dạng và các trường bắt buộc bằng mã. Với bản tóm tắt, dùng một bảng tiêu chí như đủ ý, giữ điều kiện và không thêm tuyên bố thiếu căn cứ. Con người nên kiểm tra các lỗi quan trọng và một mẫu đầu ra đại diện.
Bạn có thể dùng một mô hình khác hỗ trợ chấm, nhưng cần đối chiếu với đánh giá của người. Giám khảo AI cũng có thể thiên vị cách viết dài, bỏ sót chi tiết hoặc không ổn định.
Đo thêm thời gian từ lúc gửi yêu cầu tới lúc có kết quả dùng được, chi phí và tỷ lệ phải thử lại. Một mô hình rẻ hơn mỗi lượt có thể tốn hơn nếu thường phải gọi lại. Với RAG, đo riêng việc tìm đúng tài liệu; với AI agent, kiểm tra trạng thái cuối của công việc.
Đọc kết quả cùng các ví dụ thất bại
Giả sử trong một bộ thử giả định, mô hình A đúng 18/20 trường hợp còn B đúng 17/20. Chênh lệch đó chưa đủ để khẳng định A luôn tốt hơn. Hãy xem A sai trường hợp nào, thử thêm ví dụ và kiểm tra độ ổn định nếu đầu ra có tính ngẫu nhiên.
Nếu A thường viết sai tên người còn B thường vượt độ dài, mức nghiêm trọng phụ thuộc ứng dụng. Một điểm trung bình không truyền đạt hết sự khác biệt.
Chạy các mô hình trên cùng bộ thử, đọc cả điểm tổng lẫn kiểu lỗi, rồi cân nhắc tốc độ và chi phí. Một chênh lệch nhỏ chưa chứng minh mô hình nào luôn tốt hơn.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Cùng bộ thử
Dùng cùng các trường hợp và quy tắc chấm đã xác định trước cho cả hai mô hình.
02 / Đọc điểm số
Trong ví dụ giả định, A đúng 18/20, B đúng 17/20. Chênh lệch một trường hợp chưa đủ kết luận chung.
03 / Xem kiểu lỗi
Mở các trường hợp thất bại: sai tên người và vượt độ dài có mức ảnh hưởng khác nhau.
04 / Đánh giá nhiều chiều
Đo thêm tốc độ, chi phí và độ ổn định trên dữ liệu phù hợp với công việc thực tế.
A đúng 18/20 và B đúng 17/20 là số liệu giả định để giải thích cách đọc kết quả, không phải benchmark của mô hình có thật.
Lưu lại phiên bản mô hình, prompt, tham số và ngày chạy. Khi một thành phần thay đổi, chạy lại bộ kiểm tra phù hợp. Quyết định chọn mô hình sẽ đáng tin hơn khi bạn có thể nói: “Trong các tình huống này, theo những tiêu chí này, cấu hình này đáp ứng yêu cầu” — và chỉ rõ những gì vẫn chưa được kiểm tra.