Blog / AI / Deep Article
Điểm benchmark AI đo được điều gì, bỏ sót điều gì? Phân tích HELM, NIST, độ chính xác, sai số, trích dẫn và cách kiểm thử chatbot trong thực tế.
Một bảng xếp hạng AI có thể trông rất thuyết phục: tên mô hình, điểm số, thứ hạng và một vài biểu đồ. Nhưng khi một doanh nghiệp cần dùng chatbot để trả lời khách hàng, tóm tắt hồ sơ hay hỗ trợ chuyên viên, câu hỏi quan trọng không phải “mô hình nào đứng đầu?”, mà là “mô hình nào thực hiện đúng công việc này, trong điều kiện thực tế, với rủi ro và chi phí chấp nhận được?”. Hai câu hỏi đó không tương đương.
Benchmark là một tập nhiệm vụ và quy tắc chấm điểm dùng để so sánh hệ thống. Nó hữu ích vì biến cảm nhận chủ quan thành phép đo có thể kiểm tra. Tuy nhiên, điểm benchmark chỉ có ý nghĩa trong phạm vi dữ liệu, cách hỏi, cách chấm và phiên bản mô hình được thử nghiệm. Đem điểm ấy suy rộng thành lời hứa rằng AI sẽ đáng tin ở mọi hoàn cảnh là một sai lầm về phương pháp.
Hãy hình dung hai chatbot cùng làm một đề gồm một nghìn câu hỏi. Chatbot A đúng 880 câu, chatbot B đúng 850 câu. Nếu câu hỏi đại diện tốt cho nghiệp vụ, việc chấm nhất quán và sai sót có chi phí gần giống nhau, kết quả này là tín hiệu có ích. Nhưng nếu đề chủ yếu là kiến thức phổ thông bằng tiếng Anh, điểm số ấy chưa cho biết hệ thống nào xử lý văn bản hành chính tiếng Việt tốt hơn.
Một phép đánh giá phải xác định ít nhất bốn thành phần: đối tượng được kiểm tra; tập tình huống; tiêu chí thành công; và điều kiện chạy. Chỉ cần thay một thành phần, ý nghĩa của điểm có thể thay đổi. Chẳng hạn, yêu cầu trả lời không có tài liệu kèm theo khác căn bản với yêu cầu chỉ được trả lời dựa trên tài liệu nội bộ. Chấm theo mức giống đáp án mẫu cũng khác chấm theo việc câu trả lời có đúng căn cứ hay không.
Nghiên cứu Holistic Evaluation of Language Models (HELM) của nhóm Stanford được xây dựng để làm rõ chính sự đa chiều này. Công trình không chỉ xem độ chính xác, mà còn nghiên cứu các mặt như hiệu chuẩn, độ bền vững, công bằng, thiên lệch, độc hại và hiệu quả. Ở nghiên cứu gốc, nhóm đánh giá 30 mô hình trong nhiều tình huống theo điều kiện chuẩn hóa. Đây là bằng chứng cho thấy đánh giá toàn diện cần nhiều thước đo, không phải lời khẳng định rằng một bảng xếp hạng có thể thay thế kiểm thử riêng.
Nguyên nhân đầu tiên là độ lệch giữa đề thi và công việc. Tập kiểm tra có thể gồm các câu hỏi ngắn, sạch và có đáp án rõ. Công việc thực tế lại chứa văn bản lỗi định dạng, nhiều phiên bản mâu thuẫn, thông tin thiếu, yêu cầu mơ hồ và ngoại lệ hiếm. Một hệ thống trả lời tốt câu hỏi trắc nghiệm chưa chắc biết khi nào cần từ chối kết luận.
Nguyên nhân thứ hai là nhiễm dữ liệu đánh giá. Nếu mô hình đã tiếp xúc với câu hỏi hoặc đáp án tương tự trong quá trình huấn luyện, điểm cao có thể phản ánh một phần khả năng ghi nhớ thay vì năng lực tổng quát. Không thể kết luận mọi điểm cao đều do học thuộc; cũng không thể chỉ nhìn kết quả cuối cùng để loại trừ nguy cơ này. Cần thiết kế tập kiểm tra độc lập, kiểm soát rò rỉ và bổ sung câu hỏi mới.
Nguyên nhân thứ ba là cách chấm chưa phản ánh hậu quả. Trong một chatbot giải trí, nhầm tên nhân vật có thể chỉ gây phiền. Trong hệ thống hỗ trợ xử lý hồ sơ, bịa một căn cứ pháp lý hoặc bỏ qua điều kiện loại trừ có thể khiến người dùng quyết định sai. Nếu mọi câu sai đều bị trừ một điểm như nhau, phép đo không phản ánh mức độ nghiêm trọng khác nhau.
Nguyên nhân thứ tư là tính bất ổn của đầu ra. Cùng một ý hỏi, thay cách diễn đạt, thứ tự tài liệu hoặc ngữ cảnh hội thoại có thể làm đáp án đổi khác. Một lượt chạy thành công không chứng minh hành vi ổn định. Đánh giá có ý nghĩa phải thử nhiều biến thể và quan sát tỷ lệ thất bại, không chỉ chọn một ví dụ đẹp.
Một hệ thống có thể trả lời đúng nhiều nhưng tự tin quá mức khi sai. Đó là lý do phải quan tâm đến *calibration* (hiệu chuẩn): mức độ tự tin được biểu đạt có tương ứng với xác suất đúng trong thực tế hay không. Với ứng dụng quan trọng, một câu “tôi chưa đủ căn cứ” có thể tốt hơn câu trả lời trôi chảy nhưng sai.
*Robustness* (độ bền vững) xem kết quả có chịu được biến đổi hợp lý của đầu vào: lỗi gõ, cách viết khác, tài liệu dài hơn hay tình huống ít gặp. *Fairness* (công bằng) và *bias* (thiên lệch) xem hiệu quả có chênh lệch bất hợp lý giữa các nhóm hay bối cảnh. *Efficiency* (hiệu quả) bao gồm độ trễ, tài nguyên và chi phí. Các tiêu chí này không tự động đi cùng nhau: mô hình trả lời tốt hơn có thể đắt hơn, chậm hơn hoặc khó vận hành hơn.
NIST, trong khung AI Risk Management Framework 1.0 công bố tháng 1/2023, nhấn mạnh quản lý rủi ro của hệ thống AI trong bối cảnh thiết kế, triển khai và sử dụng. Tài liệu được định vị là khung tự nguyện, có thể áp dụng ở nhiều ngành và trường hợp sử dụng. Vì thế, không nên hiểu việc đạt điểm benchmark là chứng nhận tuân thủ NIST, càng không phải bằng chứng hệ thống đã an toàn tuyệt đối.
Giả sử một đơn vị muốn triển khai trợ lý đọc báo cáo nhiều trang. Hai mô hình được đưa vào thử nghiệm. Mô hình X có điểm kiến thức tổng quát cao hơn; mô hình Y thấp hơn đôi chút nhưng xử lý tài liệu tiếng Việt và trích dẫn trang ổn định hơn. Không có cơ sở chọn X chỉ vì vị trí trên bảng xếp hạng.
Trước tiên, đơn vị cần xác định đầu ra chấp nhận được. Với câu hỏi “Tổng số hộ được ghi nhận là bao nhiêu?”, hệ thống phải nêu đúng số, kỳ báo cáo và trang nguồn. Nếu tài liệu có hai bảng thuộc hai thời kỳ, hệ thống phải phân biệt được. Nếu không tìm thấy dữ liệu, hệ thống cần nói rõ chưa đủ thông tin thay vì suy đoán.
Tiếp đó, xây bộ kiểm thử từ tình huống thật đã được phép sử dụng, loại bỏ dữ liệu nhạy cảm không cần thiết. Bộ thử nên có câu dễ, câu nhiều bước, câu có bảng, câu bị thiếu căn cứ và câu cố tình đưa ra tiền đề sai. Nên giữ một phần bộ thử chưa từng dùng để điều chỉnh prompt hoặc lựa chọn mô hình, nhằm giảm nguy cơ tối ưu quá mức vào đề quen.
Cuối cùng, chấm riêng các chỉ số: tỷ lệ trả lời đúng; tỷ lệ dẫn đúng nguồn; tỷ lệ bịa số liệu; tỷ lệ từ chối hợp lý khi thiếu dữ kiện; độ trễ và chi phí mỗi lượt. Ví dụ, một mô hình có tỷ lệ đúng 92% nhưng bịa căn cứ ở 6% câu hỏi có thể kém phù hợp hơn mô hình đúng 89% nhưng chỉ bịa ở 1%, nếu nghiệp vụ đặc biệt nhạy cảm với căn cứ giả. Các con số trong ví dụ này chỉ để minh họa cách quyết định, không phải kết quả thực nghiệm.
Khi chatbot kết nối công cụ tìm kiếm, cơ sở dữ liệu hoặc hệ thống quản lý công việc, chất lượng cuối cùng phụ thuộc vào nhiều thành phần. Công cụ truy xuất có tìm đúng tài liệu không? Tài liệu có còn hiệu lực không? Prompt có yêu cầu dẫn nguồn không? Có bước kiểm tra trước khi gửi kết quả không? Có quyền truy cập vượt phạm vi hay không?
Điểm benchmark của mô hình nền không trả lời các câu hỏi này. Một hệ thống dùng mô hình vừa phải nhưng có truy xuất tốt, giới hạn quyền rõ và kiểm tra kết quả chặt chẽ có thể hữu ích hơn hệ thống dùng mô hình đứng đầu nhưng dữ liệu lộn xộn. Đây là lập luận về kiến trúc và kiểm soát chất lượng, không phải bảo đảm rằng mọi hệ thống nhỏ hơn đều vượt hệ thống lớn hơn.
Cần phân biệt thêm đánh giá trước triển khai và giám sát sau triển khai. Dữ liệu thay đổi, người dùng đặt câu hỏi mới, tài liệu được cập nhật, nhà cung cấp có thể thay phiên bản mô hình. Vì vậy, một bài kiểm tra đạt điểm cao vào ngày nghiệm thu không đủ thay cho việc theo dõi lỗi và kiểm thử hồi quy định kỳ. Khi có thay đổi quan trọng, cần so sánh với bộ chuẩn cũ và thêm tình huống mới.
Quy trình thực tế nên bắt đầu bằng việc xác định công việc cụ thể và hậu quả của từng loại lỗi. Sau đó tạo bộ dữ liệu đại diện, gắn đáp án và bằng chứng có thể kiểm tra, quy định cách xử lý trường hợp nhiều đáp án hợp lệ. Nếu dùng người chấm, cần hướng dẫn tiêu chí và kiểm tra mức nhất quán giữa người chấm. Nếu dùng một mô hình khác để chấm, phải đánh giá cả sai lệch của chính bộ chấm đó.
Một bảng kết quả hữu ích không chỉ công bố điểm trung bình. Nó nên chỉ ra số lượng câu hỏi, nguồn gốc dữ liệu, ngôn ngữ, cách tính điểm, điều kiện chạy, phiên bản mô hình, khoảng biến động giữa các lần thử và các nhóm lỗi nghiêm trọng. Với bài toán cần trích dẫn, nên tách độ đúng của câu trả lời khỏi độ đúng của nguồn dẫn. Hai tiêu chí liên quan nhưng không đồng nhất.
Không nhất thiết tổ chức một cuộc thử nghiệm khổng lồ. Một bộ kiểm thử nhỏ, được thiết kế cẩn thận và cập nhật theo lỗi thật có thể giúp phát hiện vấn đề mà bảng xếp hạng tổng quát bỏ sót. Tuy nhiên, mẫu nhỏ có độ bất định cao; không nên suy ra chênh lệch một vài điểm phần trăm là ưu thế chắc chắn nếu chưa có đủ quan sát.
Không có một bộ kiểm thử cố định nào bao phủ mọi hành vi có thể xuất hiện sau triển khai. Ngay cả khi hai hệ thống dùng cùng bộ đề, khác biệt về giới hạn thời gian, công cụ, số lượt thử hay cách xử lý câu từ chối vẫn có thể khiến so sánh thiếu công bằng. Dữ liệu công khai cũng có thể trở nên quen thuộc theo thời gian, làm giảm giá trị đo năng lực trên tình huống mới.
Đánh giá an toàn càng khó rút gọn thành một con số. Một hệ thống hiếm khi mắc lỗi nhưng đôi lúc gây hậu quả nghiêm trọng cần cách quản lý khác hệ thống mắc lỗi nhỏ thường xuyên. Khung quản trị rủi ro giúp tổ chức đặt câu hỏi về trách nhiệm, bối cảnh sử dụng và biện pháp kiểm soát; nó không thay thế bằng chứng thử nghiệm cho từng ứng dụng.
Vì vậy, khi đọc tin “mô hình AI mới đứng đầu bảng xếp hạng”, hãy hỏi: đứng đầu trên bộ đề nào, ngôn ngữ nào, đo bằng thước nào, chạy với công cụ gì, và sai ở những trường hợp nào? Nếu nhà cung cấp không công bố phương pháp hoặc chỉ đưa một điểm tổng hợp, kết luận hợp lý là thông tin chưa đủ để ra quyết định triển khai.
Benchmark là công cụ cần thiết để so sánh AI, nhưng không phải giấy chứng nhận năng lực toàn diện. Nghiên cứu HELM cho thấy giá trị của cách đánh giá nhiều tình huống và nhiều chỉ số; NIST đặt việc đánh giá vào khuôn khổ quản lý rủi ro theo bối cảnh. Hai hướng tiếp cận bổ sung cho nhau: một bên giúp đo lường minh bạch hơn, bên kia giúp đặt câu hỏi về tác động và trách nhiệm khi sử dụng.
Đối với tổ chức triển khai AI, quyết định tốt không bắt đầu bằng việc mua mô hình có điểm cao nhất. Nó bắt đầu bằng mô tả rõ công việc, xây phép thử sát thực tế, đo những lỗi có hậu quả lớn và duy trì giám sát sau triển khai. Một điểm số có thể mở đầu cuộc thảo luận; nó không nên là câu trả lời cuối cùng.