Đánh giá chất lượng ứng dụng AI tạo sinh là quy trình đo một cách có hệ thống xem ứng dụng trả lời đúng, đủ, an toàn và đúng định dạng đến đâu trên một bộ đề kiểm thử cố định, đại diện cho việc thật, với thang chấm được định nghĩa trước, và lặp lại mỗi khi đổi câu lệnh, mô hình hoặc dữ liệu. Không có bộ đề và thang chấm, mọi nhận định "bản mới tốt hơn" chỉ là cảm giác của người thử vài câu.
Khác với kiểm thử phần mềm truyền thống, đầu ra AI không có một đáp án đúng duy nhất và có thể khác nhau giữa các lần chạy. Vì vậy cần kết hợp ba cách chấm — so khớp tự động, người chấm và mô hình làm giám khảo — mỗi cách cho một loại tiêu chí. Bài viết đi qua cách xây bộ đề, thiết kế thang chấm, chọn cách chấm, đánh giá riêng hệ thống truy xuất và đặt ngưỡng phát hành có cơ sở thống kê.
Vì sao kiểm thử phần mềm thông thường không đủ
Kiểm thử phần mềm truyền thống dựa trên giả định: cùng đầu vào cho cùng đầu ra, và đầu ra đúng có thể viết thành điều kiện chính xác. Ứng dụng AI tạo sinh phá vỡ cả hai. Một câu hỏi về chính sách đổi trả có thể có hàng chục cách trả lời đúng với từ ngữ khác nhau, và cũng có thể có câu trả lời nghe rất trôi chảy nhưng sai một chi tiết then chốt như thời hạn hay điều kiện áp dụng.
Thêm vào đó, hành vi của ứng dụng thay đổi theo những thứ không nằm trong mã nguồn: phiên bản mô hình do nhà cung cấp cập nhật, tài liệu trong kho truy xuất, một dòng sửa trong câu lệnh hệ thống. Một thay đổi nhỏ nhằm sửa lỗi ở loại câu hỏi này có thể làm hỏng loại câu hỏi khác mà không ai để ý — hiện tượng mà người làm phần mềm gọi là lỗi hồi quy.
Vì vậy đánh giá AI tạo sinh cần được coi như một hạ tầng thường trực của dự án, không phải một đợt kiểm tra trước ngày ra mắt. Bộ đề, thang chấm và kết quả các lần chạy là tài sản được quản lý phiên bản như mã nguồn.
Xây bộ đề kiểm thử chuẩn
Bộ đề (golden set) là trái tim của đánh giá. Các bước xây dựng:
- Lấy câu hỏi thật: từ nhật ký yêu cầu của khách, câu hỏi nhân viên từng gửi cho bộ phận chuyên môn, ca thực tế trong thí điểm. Câu do nhóm dự án tự nghĩ thường dễ hơn thực tế.
- Phân tầng theo loại: chia theo chủ đề, độ khó, loại thao tác (tra cứu một điểm, tổng hợp nhiều nguồn, so sánh, tính toán) để mỗi loại đều có đủ đại diện.
- Cố ý thêm ca khó và ca bẫy: câu hỏi mà tài liệu không có câu trả lời (ứng dụng phải biết từ chối), câu hỏi mơ hồ, câu hỏi chứa giả định sai, câu hỏi ngoài phạm vi.
- Viết đáp án tham chiếu hoặc các điểm bắt buộc: chuyên gia nghiệp vụ ghi các ý mà câu trả lời đúng phải có, các lỗi không được mắc, kèm nguồn tài liệu.
- Cho hai chuyên gia duyệt độc lập một phần bộ đề; chỗ họ không đồng ý là chỗ định nghĩa đúng sai chưa rõ, cần sửa trước khi dùng.
- Tách tập phát triển và tập giữ lại: nhóm dự án được nhìn và tối ưu trên tập phát triển; tập giữ lại chỉ dùng để chấm trước khi phát hành, tránh "học tủ".
- Bổ sung liên tục bằng ca sai thực tế được người dùng báo cáo sau khi chạy thật.
Tiêu chí chấm và thang điểm có mô tả
Mỗi tiêu chí cần thang chấm với mô tả cụ thể cho từng mức (rubric), để hai người chấm độc lập cho cùng một điểm. Bộ tiêu chí thường dùng:
| Tiêu chí | Câu hỏi chấm | Cách chấm phù hợp |
|---|---|---|
| Đúng sự thật | Có thông tin nào sai so với đáp án tham chiếu hoặc tài liệu nguồn không? | Người chấm hoặc mô hình giám khảo có đáp án tham chiếu |
| Bám nguồn | Mọi khẳng định có được tài liệu truy xuất hỗ trợ không, hay mô hình tự thêm? | Mô hình giám khảo so câu trả lời với đoạn nguồn, người chấm kiểm mẫu |
| Đầy đủ | Có đủ các điểm bắt buộc đã liệt kê không? | Đếm điểm bắt buộc, có thể tự động một phần |
| Biết từ chối | Với câu không có câu trả lời trong tài liệu, ứng dụng có nói rõ là không biết không? | Tự động theo nhãn ca bẫy |
| Định dạng | Có đúng cấu trúc yêu cầu (trường dữ liệu, độ dài, trích dẫn) không? | So khớp tự động bằng quy tắc |
| An toàn và tuân thủ | Có lộ thông tin không được phép, có lời khuyên vượt phạm vi không? | Quy tắc tự động kết hợp người chấm |
| Hữu ích | Người dùng có làm được việc của họ với câu trả lời này không? | Người chấm nghiệp vụ |
Thang hai mức đạt – không đạt cho từng tiêu chí thường dễ chấm nhất quán hơn thang năm mức. Nếu dùng thang nhiều mức, mỗi mức phải có ví dụ mẫu. Đo mức đồng thuận giữa người chấm bằng hệ số như Cohen's kappa; đồng thuận thấp nghĩa là thang chấm mơ hồ, chưa phải người chấm kém.
Ba cách chấm và giới hạn của từng cách
So khớp tự động. Kiểm tra định dạng, trường dữ liệu bắt buộc, từ khoá cấm, độ dài, nhãn phân loại so với đáp án. Rẻ, nhanh, nhất quán, nhưng chỉ dùng được cho tiêu chí diễn đạt được thành quy tắc.
Người chấm chuyên môn. Chuẩn mực cao nhất cho tiêu chí đúng sự thật và hữu ích trong lĩnh vực chuyên sâu. Đắt và chậm, mỗi người chấm có xu hướng riêng, mệt mỏi làm giảm chất lượng khi chấm số lượng lớn. Nên dùng cho tập giữ lại, cho mẫu kiểm tra và để hiệu chỉnh các cách chấm khác.
Mô hình làm giám khảo (LLM-as-a-judge). Dùng một mô hình mạnh chấm theo thang và đáp án tham chiếu. Zheng và cộng sự (2023) cho thấy giám khảo mô hình mạnh có mức đồng thuận với người chấm tương đương mức đồng thuận giữa hai người chấm trên bộ câu hỏi họ thử, nhưng cũng ghi nhận các thiên lệch: ưu tiên câu trả lời đứng trước khi so sánh cặp, ưu tiên câu trả lời dài hơn, và có xu hướng ưu ái đầu ra giống phong cách của chính nó.
Cách dùng giám khảo mô hình an toàn. Cho giám khảo đáp án tham chiếu thay vì để nó tự biết; chấm từng tiêu chí riêng thay vì một điểm tổng; đảo thứ tự khi so sánh cặp; định kỳ so điểm giám khảo với người chấm trên một mẫu để biết nó lệch ở đâu. Giám khảo mô hình là công cụ mở rộng quy mô cho người chấm, không thay thế họ.
Đánh giá riêng từng khâu của hệ thống truy xuất
Với ứng dụng dùng truy xuất tài liệu, câu trả lời sai có thể đến từ hai chỗ rất khác nhau: hệ thống không tìm được đoạn tài liệu đúng, hoặc tìm được mà mô hình diễn giải sai. Chấm chung một điểm cuối cùng sẽ không cho biết phải sửa ở đâu. Vì vậy bộ đề nên ghi kèm đoạn tài liệu nào chứa câu trả lời, để đo riêng từng khâu.
Khâu truy xuất được đo bằng các chỉ số quen thuộc của truy hồi thông tin, chẳng hạn tỷ lệ câu hỏi mà đoạn đúng nằm trong k đoạn được lấy về đầu tiên (recall@k). Nếu chỉ số này thấp, cải tiến phải nhắm vào cách cắt đoạn, cách đánh chỉ mục, bộ lọc theo siêu dữ liệu như loại tài liệu và ngày hiệu lực, hoặc thêm bước xếp hạng lại — đổi mô hình sinh sẽ không giúp gì.
Khâu sinh được đo bằng mức bám nguồn: khi đã có đoạn đúng, câu trả lời có trung thành với đoạn đó không, có tự thêm chi tiết không có trong nguồn không. Một lỗi đặc thù trong doanh nghiệp là tài liệu nhiều phiên bản: quy định cũ và mới cùng nằm trong kho, hệ thống lấy nhầm bản cũ. Bộ đề nên có câu hỏi riêng cho các chính sách đã sửa đổi để bắt lỗi này.
Cỡ mẫu, ngưỡng phát hành và đánh giá sau khi chạy thật
Bộ đề bao nhiêu câu là đủ? Một phép tính đơn giản giúp định hướng: với 200 câu và tỷ lệ đạt quanh 50%, khoảng tin cậy 95% của tỷ lệ đạt rộng khoảng cộng trừ 7 điểm phần trăm; ở tỷ lệ đạt quanh 85%, khoảng này hẹp lại còn khoảng cộng trừ 5 điểm. Nghĩa là nếu phiên bản mới chỉ hơn phiên bản cũ 2–3 điểm trên 200 câu, bạn chưa có bằng chứng nó tốt hơn. Muốn phát hiện chênh lệch nhỏ cần bộ đề lớn hơn hoặc so sánh cặp trên cùng câu hỏi.
Ngưỡng phát hành nên đặt theo từng loại tiêu chí chứ không chỉ một điểm tổng: ví dụ tỷ lệ lỗi sai sự thật nghiêm trọng dưới một mức rất thấp, tỷ lệ từ chối đúng với ca bẫy trên một mức cao, và không loại câu hỏi quan trọng nào bị tụt so với phiên bản đang chạy. Mỗi lần thay đổi đều chạy lại toàn bộ bộ đề như kiểm thử hồi quy.
Sau khi chạy thật, đánh giá chuyển sang dữ liệu trực tuyến: tỷ lệ người dùng đánh dấu sai, tỷ lệ bản nháp bị sửa nhiều trước khi gửi, tỷ lệ yêu cầu bị chuyển lên người. Lấy mẫu ngẫu nhiên một phần nhỏ lượt dùng thật để người chấm định kỳ, và đưa ca sai vào bộ đề. Vòng lặp này là cách duy nhất để bộ đề không cũ đi so với thực tế.
Những sai lầm hay gặp khi tự đánh giá
Đánh giá bằng vài câu hỏi "thử xem". Người quản lý gõ năm câu, thấy ổn, phê duyệt. Năm câu đó thường là câu dễ, phản ánh kỳ vọng của người hỏi chứ không phản ánh phân bố câu hỏi thật. Một ca sai nghiêm trọng hiếm gặp có thể không xuất hiện trong mười câu nhưng chắc chắn xuất hiện trong mười nghìn lượt dùng.
Tối ưu trên chính bộ đề dùng để báo cáo. Sửa câu lệnh cho đến khi đạt điểm cao trên bộ đề rồi báo cáo điểm đó là tự lừa mình. Điểm trên tập giữ lại mới là điểm có ý nghĩa.
Chỉ đo câu trả lời đúng, bỏ qua ca phải từ chối. Ứng dụng trả lời mọi thứ có vẻ hữu ích hơn trong demo, nhưng trong vận hành, một câu "tài liệu hiện có không đề cập vấn đề này" đúng lúc an toàn hơn nhiều so với một câu trả lời bịa nghe hợp lý.
Một điểm tổng che mất lỗi nghiêm trọng. Điểm trung bình 90% có thể bao gồm vài lỗi sai thời hạn pháp lý hay sai giá. Lỗi phải được phân loại theo mức nghiêm trọng, và lỗi nghiêm trọng có ngưỡng riêng gần bằng không.
Không lưu phiên bản. Không ghi lại kết quả đánh giá gắn với phiên bản câu lệnh, mô hình, kho tài liệu cụ thể, thì khi chất lượng tụt sẽ không biết thay đổi nào gây ra. Mỗi lần chạy đánh giá cần lưu đủ cấu hình để tái lập.
Câu hỏi thường gặp
Có thể dùng chính mô hình đang được kiểm thử làm giám khảo không?
Nên tránh. Mô hình có xu hướng đánh giá cao đầu ra mang phong cách của chính nó, và những lỗi hiểu sai mà nó mắc khi trả lời có thể lặp lại khi chấm. Dùng một mô hình khác, mạnh hơn hoặc ít nhất khác họ, và luôn hiệu chỉnh bằng người chấm trên một mẫu.
Bộ đề có nên công khai cho nhà cung cấp giải pháp không?
Có thể chia sẻ tập phát triển để nhà cung cấp hiểu yêu cầu, nhưng giữ tập giữ lại cho riêng mình. Nếu nhà cung cấp thấy toàn bộ bộ đề, họ có thể tối ưu riêng cho các câu đó và kết quả chấm không còn phản ánh chất lượng trên câu hỏi mới.
Làm sao đánh giá khi đầu ra là văn bản dài như báo cáo hay hợp đồng nháp?
Chia văn bản thành các yêu cầu kiểm được: các điều khoản bắt buộc có mặt không, số liệu có khớp nguồn không, có điều khoản bị cấm không, cấu trúc có đúng mẫu không. Chấm từng yêu cầu riêng dễ nhất quán hơn chấm cảm nhận tổng thể. Phần văn phong để người chấm đánh giá trên mẫu nhỏ.
Tính ngẫu nhiên của đầu ra ảnh hưởng thế nào đến kết quả đánh giá?
Cùng câu hỏi có thể cho câu trả lời khác nhau giữa các lần chạy, nên một lần chạy có thể may hoặc rủi. Với câu hỏi quan trọng, chạy nhiều lần và xem tỷ lệ đạt; đặt tham số sinh ổn định hơn cho ứng dụng cần nhất quán. Khi so hai phiên bản, chạy trên cùng bộ đề với cùng thiết lập.
Ai nên chịu trách nhiệm duy trì bộ đề?
Nên có một người nghiệp vụ làm chủ nội dung đáp án và một người kỹ thuật làm chủ công cụ chạy đánh giá. Khi chính sách công ty thay đổi, người nghiệp vụ phải cập nhật đáp án tham chiếu; nếu không, bộ đề sẽ chấm sai và ứng dụng đúng lại bị đánh trượt.
Đánh giá có thay được kiểm tra an toàn và bảo mật không?
Không hoàn toàn. Bộ đề chất lượng có thể chứa một số ca kiểm tra tuân thủ, nhưng kiểm thử an toàn như thử cố tình khiến ứng dụng lộ dữ liệu hay làm việc ngoài phạm vi cần quy trình riêng do người có chuyên môn bảo mật thực hiện, theo hướng phòng thủ và trong môi trường được phép.