Không thể đặt ngưỡng đạt chỉ bằng điểm trung bình: Đánh giá lặp để đo độ dao động của AI tạo sinh

Trong buổi kiểm thử, AI tạo sinh trả lời đúng câu hỏi đã chuẩn bị. Người phụ trách ghi kết quả vào bảng tính và tính tỷ lệ chính xác. Nhưng khi nhập lại đúng câu hỏi đó vào ngày hôm sau, một điều kiện quan trọng lại bị bỏ sót. Nếu chỉ lưu kết quả lần đầu, sự dao động này sẽ bị che khuất sau con số “đạt”.

Khi quyết định đưa AI tạo sinh vào vận hành, không thể chỉ nhìn điểm trung bình. Cần xem kết quả biến động thế nào khi lặp lại trong cùng điều kiện và thất bại tập trung ở điều kiện nghiệp vụ nào. Điều cần thiết không phải một benchmark học thuật để phân hạng mô hình, mà là phép đánh giá lặp nhằm xác nhận AI có bảo vệ được quyết định nghiệp vụ của doanh nghiệp hay không.

Một câu trả lời đúng chỉ là một lần quan sát, không phải năng lực

Hãy xét ví dụ giả định: phân loại 100 điều khoản hợp đồng và có 92 kết quả đúng. Chỉ với con số 92%, ta không biết chạy lại cùng 100 trường hợp có cho kết quả tương tự không, tám trường hợp khó có luôn thất bại không, hay mỗi lần lại bỏ sót một mục khác. Số lượng đánh giá và mức chấp nhận phải được quyết định theo rủi ro nghiệp vụ.

Tài liệu “AI 800-3” của NIST phân biệt độ chính xác benchmark trên một tập bài cố định với độ chính xác khái quát hóa cho toàn bộ nhóm bài tương tự. Tài liệu cũng nêu rằng độ bất định của kết quả đánh giá không chỉ đến từ cách chọn bài mà còn từ cơ chế lấy mẫu không xác định của LLM.[1] Kết quả của một lần chạy không phải chính năng lực kỳ vọng, mà chỉ là một quan sát lấy từ phân bố kết quả.

Phiên bản 2.0 của hướng dẫn mua sắm và sử dụng AI tạo sinh của Cơ quan Kỹ thuật số Nhật Bản cũng đưa ra các ví dụ kiểm tra độ bền: tính nhất quán khi nhập cùng dữ liệu kiểm thử nhiều lần, tính nhất quán với nhiều cách diễn đạt gần nghĩa, và hoạt động ổn định trước lỗi nhập liệu hoặc khác biệt ký hiệu.[2] Chính phủ Nhật Bản đang triển khai Government AI “Gennai” trên toàn bộ các bộ, hướng tới môi trường mà khoảng 180.000 công chức có thể sử dụng trong năm tài khóa 2026.[3] Khi phạm vi sử dụng mở rộng, việc một người đại diện thử một lần và thấy đạt không thể bao phủ khác biệt trong đầu vào.

Đo sự dao động theo ba nhóm

Lặp lại cùng một đầu vào

Trước hết, cố định mô hình, chỉ dẫn, dữ liệu tham chiếu, công cụ và tham số rồi chạy cùng một đầu vào nhiều lần. Không chỉ ghi tỷ lệ đúng trung bình. Hãy lưu tỷ lệ các lần có đủ mọi trường bắt buộc, số trường hợp từng chạm điều cấm và kết quả của lần tệ nhất. Nếu đúng bốn trong năm lần nhưng lần sai được tự động gửi đi, nghiệp vụ vẫn có thể phải đánh trượt.

Cần phân biệt nghiệp vụ mà một thay đổi nhỏ trong câu chữ có thể làm đổi kết luận với nghiệp vụ cho phép nhiều cách diễn đạt đúng. Nếu đánh giá bằng “khớp toàn văn”, các khác biệt câu chữ vẫn đúng nghĩa cũng bị coi là lỗi. Hãy cấu trúc trước những phần bắt buộc phải cố định như số tiền, ngày tháng, phân loại, tài liệu làm căn cứ và thao tác đã thực hiện.

Diễn đạt lại nhưng giữ nguyên ý nghĩa

Tiếp theo, giữ nguyên ý của câu hỏi nhưng thay đổi trật tự từ, mức độ kính ngữ, từ viết tắt, lỗi chính tả và độ dài đầu vào. Mục tiêu không phải kiểm tra khả năng sửa câu cho đẹp, mà là xem khác biệt cách diễn đạt giữa người dùng có làm đảo ngược quyết định nghiệp vụ hay không. Nhóm câu gốc và các biến thể lại với nhau rồi so sánh kết luận, căn cứ bắt buộc và điều kiện từ chối.

Không phải mọi cách diễn đạt lại đều cần nhận cùng một câu trả lời. Với câu hỏi ngắn thiếu thông tin, yêu cầu làm rõ thay vì suy đoán mới là phản ứng phù hợp. Hãy đánh giá “có tuân theo cùng một quy tắc quyết định hay không”, không chỉ “có đưa ra cùng kết luận hay không”.

Phân bố thất bại theo điều kiện nghiệp vụ

Cuối cùng, đừng gộp mọi kết quả thành một điểm trung bình. Hãy chia theo điều kiện nghiệp vụ: xử lý thông thường, ngoại lệ, giá trị biên, xung đột giữa nhiều quy định, thiếu dữ liệu tham chiếu và yêu cầu ngoài quyền hạn. Dù điểm tổng thể cao, nếu thất bại tập trung ở thời điểm sát hạn hủy hoặc các giao dịch giá trị lớn, không nên tự động hóa mục đích đó.

Tài liệu thực hành NIST AI RMF cho rằng việc ghi chép tập kiểm thử, chỉ số, công cụ và quy trình đánh giá/xác minh là nền tảng cho khả năng lặp lại và tính nhất quán của phép đo.[4] Cùng với số lần lặp, hãy lưu phiên bản mô hình, thời gian chạy, chỉ dẫn, phiên bản dữ liệu tham chiếu và quy tắc chấm điểm thành một bộ.

Xây tiêu chí đạt bằng mức trung bình, trường hợp tệ nhất và lỗi cấm

Phán định đạt hay không nên có ít nhất ba cổng. Cổng thứ nhất là hiệu năng trung bình trên toàn bộ nghiệp vụ mục tiêu. Cổng thứ hai là điều kiện tệ nhất: các nhóm nghiệp vụ quan trọng có vượt ngưỡng tối thiểu hay không. Cổng thứ ba là lỗi cấm: không được xuất hiện các sự cố như thao tác vượt quyền, lộ thông tin cá nhân, khẳng định không có căn cứ, sai số tiền hoặc sai người nhận.

Chỉ cần tăng số câu hỏi dễ có tần suất cao cũng có thể nâng điểm trung bình. Vì vậy, phiếu đánh giá phải ghi cả số lượng và kết quả theo từng nhóm nghiệp vụ. Với hạng mục quan trọng đủ sức thay đổi kết quả đạt/trượt, hãy kèm ví dụ đạt và không đạt thay vì để hoàn toàn cho người chấm tự quyết.

Hướng dẫn đánh giá chính thức của OpenAI đề xuất trình tự: xác định mục tiêu, lập bộ dữ liệu, chọn chỉ số, so sánh và đánh giá liên tục; đồng thời chạy lại đánh giá sau mỗi thay đổi để đưa các trường hợp không xác định mới vào bộ kiểm thử.[5] Đây là hướng dẫn triển khai của một nhà cung cấp, nhưng cách làm “không dừng ở kiểm thử chấp nhận một lần, mà đưa thay đổi và tình huống vận hành trở lại bộ đánh giá” có thể áp dụng bất kể sản phẩm.

Đánh giá lặp không phù hợp trong trường hợp đầu ra chỉ được con người đọc, lỗi có thể sửa ngay tại chỗ, kết quả không được chuyển sang xử lý bên ngoài và cũng không cần tái tạo cùng câu trả lời. Khi đó, chi phí xây nền tảng đánh giá có thể lớn hơn lợi ích. Nhưng nếu đầu ra AI nối tiếp sang phân loại, phê duyệt, thông báo hoặc đăng ký dữ liệu, không thể bỏ qua lần tệ nhất và lỗi cấm.

Hàm ý thực tiễn

Khuyến nghị 1: Không chấm một câu hỏi chỉ một lần. Hãy tách đánh giá lặp cùng đầu vào, diễn đạt lại cùng ý nghĩa và tổng hợp theo điều kiện nghiệp vụ.

Khuyến nghị 2: Bên cạnh điểm trung bình, hãy xác định ngưỡng tối thiểu cho nhóm nghiệp vụ quan trọng và lỗi cấm khiến hệ thống trượt ngay khi xảy ra một lần.

Khuyến nghị 3: Ghi cố định phiên bản mô hình, chỉ dẫn, dữ liệu tham chiếu, thời gian chạy và quy tắc chấm điểm để theo dõi chính xác phần nào đã thay đổi.

Khuyến nghị 4: Trong FDE (Forward Deployed Engineering), hãy thu thập cách diễn đạt và ngoại lệ thực tế khiến nhân viên hiện trường phân vân, rồi đưa thất bại trở lại bộ đánh giá. Phán định đưa vào vận hành không phải là hỏi “đạt bao nhiêu điểm” mà là quyết định “có thể giao cho AI ổn định đến điều kiện nào”.

Tài liệu tham khảo

1. NIST, “Expanding the AI Evaluation Toolbox with Statistical Models”
2. Cơ quan Kỹ thuật số Nhật Bản, “Hướng dẫn mua sắm và sử dụng AI tạo sinh phục vụ đổi mới hành chính (phiên bản 2.0)”
3. Cơ quan Kỹ thuật số Nhật Bản, “Government AI ‘Gennai’”
4. NIST AI RMF Playbook, “Measure”
5. OpenAI, “Evaluation best practices”

Bài viết này được thực hiện với sự hỗ trợ của AI và đã được rà soát tự động trước khi xuất bản. Ngày kiểm tra thông tin: 2026-09-27.