Nên kiểm thử tính năng AI thế nào trước khi nhân viên dựa vào nó?

Một bản mẫu trả lời tốt một vài câu hỏi. Giờ đây có người muốn đưa nó cho nhân viên sử dụng. Trước khi đồng ý, hãy yêu cầu nhà cung cấp cho thấy tính năng xử lý những việc nhân viên thực sự sẽ giao cho nó ra sao, kể cả những câu hỏi nó không thể trả lời.

Bạn có thể trao đổi rất cụ thể. Hãy chọn một công việc, thống nhất thế nào là kết quả hữu ích, rồi cùng một người hiểu công việc xem các kết quả từ một nhóm ví dụ thực tế. Nhờ vậy, bạn có căn cứ để quyết định có nên phát hành hay chưa.

Bắt đầu từ một công việc và những giới hạn của nó

Hãy hình dung một tính năng tạo câu trả lời nháp dựa trên hướng dẫn nội bộ đã được duyệt. Nhân viên đọc từng bản nháp trước khi sử dụng. Đây là ví dụ giả định, nhưng giúp làm rõ tiêu chí chấp nhận.

Hãy ghi lại tính năng được phép dùng nguồn nào, dành cho ai và tạo ra nội dung gì. Trong ví dụ này, tính năng soạn câu trả lời dựa trên hướng dẫn mà nhân viên đó được phép xem. Gửi câu trả lời hoặc sửa một hồ sơ là những khả năng riêng cần được kiểm thử.

Sau đó, thống nhất thế nào là kết quả hữu ích. Bản nháp cần trả lời đúng câu hỏi, khớp với tài liệu đã duyệt, giữ lại những điều kiện quan trọng và cho biết nguồn nào làm căn cứ. Nếu tài liệu không có câu trả lời, tính năng cần nói rõ điều đó. Thừa nhận rõ rằng còn thiếu thông tin có thể là một kết quả đạt yêu cầu.

Một quy định bịa ra, bỏ sót điều kiện làm thay đổi câu trả lời, hoặc tự tin trả lời dựa trên hướng dẫn sai đều khiến bản nháp không thể sử dụng. Hãy thống nhất những điểm này trước khi xem kết quả. Nếu không, một câu trả lời trôi chảy có thể thuyết phục hơn mức đáng tin.

Thử những câu hỏi mọi người sẽ thực sự đặt ra

Với ví dụ tạo câu trả lời nháp, hãy đưa vào ít nhất các tình huống sau:

• Câu hỏi thông thường. Hướng dẫn có câu trả lời rõ ràng. Bản nháp có dùng chính xác nội dung đó và dẫn đúng nguồn không?
• Câu hỏi mơ hồ. Có thể áp dụng hai quy trình. Tính năng có hỏi thêm chi tiết cần thiết để chọn đúng quy trình, thay vì âm thầm tự chọn không?
• Thiếu tài liệu. Hướng dẫn đã duyệt không đề cập yêu cầu đó. Tính năng có giải thích phần còn thiếu và để người phụ trách xử lý câu trả lời không?

Đây chỉ là điểm khởi đầu. Hãy xây dựng bộ kiểm thử theo đúng loại công việc thực tế: yêu cầu phổ biến, thông tin chưa đầy đủ, cách diễn đạt khó hiểu và lỗi có hậu quả đáng kể. Dùng dữ liệu đại diện đã được cho phép hoặc ví dụ được chuẩn bị an toàn, đồng thời không đưa hồ sơ mật vào dịch vụ chưa được phê duyệt.

Hướng dẫn đánh giá của Microsoft khuyến nghị dùng các tương tác đại diện và tình huống khó. Với người quản lý, câu hỏi thiết thực là các ví dụ có bao quát những tình huống nhân viên cần được hỗ trợ hay không. Một bộ đo chuẩn chung cho mô hình không thể trả lời câu hỏi đó cho ứng dụng của bạn.

Nhờ người hiểu công việc đánh giá kết quả

Hãy nhờ người quen thuộc với công việc xem xét câu trả lời theo các tiêu chí đã thống nhất. Họ cần giải thích được vì sao câu trả lời dùng được, sai hoặc chưa chắc chắn. Nên có người thứ hai xem lại khi có ý kiến khác nhau hoặc khi sai sót có thể gây hậu quả đáng kể.

Khung Quản lý Rủi ro AI của NIST là tài liệu tự nguyện, ủng hộ việc ghi chép các bài kiểm thử, tạo điều kiện gần với lúc triển khai và có chuyên gia phù hợp tham gia. Đây là căn cứ hữu ích để hỏi đã kiểm thử những gì và ai kiểm tra. Khung này không đưa ra một điểm đạt chung cho mọi tính năng.

Hãy giữ riêng một số ví dụ đánh giá, không dùng chúng để cải thiện tính năng. Nếu nhà cung cấp liên tục điều chỉnh tính năng dựa trên mọi câu hỏi kiểm thử, bạn chỉ biết nó xử lý tốt đến đâu những câu hỏi đã quen. Những ví dụ riêng giúp kiểm tra tốt hơn cách tính năng xử lý công việc chưa được tinh chỉnh theo.

Chấm điểm tự động có thể giúp sắp xếp kết quả, nhưng cũng cần kiểm tra các đánh giá đó. Con người có thể bỏ sót lỗi, và AI dùng để chấm một AI khác cũng có thể sai. Hãy yêu cầu xem câu trả lời thực tế và lý do đằng sau điểm số.

Xem những lỗi mà điểm trung bình che khuất

Điểm tổng thể có thể giúp so sánh các phiên bản. Bên cạnh đó, hãy yêu cầu xem kết quả được nhóm theo tình huống và loại lỗi quan trọng. Câu hỏi thông thường có thể được xử lý tốt, trong khi câu hỏi không có nguồn lại liên tục nhận câu trả lời bịa. Điểm trung bình che khuất quyết định bạn cần đưa ra cho trường hợp sử dụng cụ thể đó.

Hãy ghi lại lỗi nào đã xảy ra, mức độ nghiêm trọng và điều gì vẫn chưa rõ. Xác định lỗi nào khiến tính năng chưa thể dùng đúng mục đích. Mức sai sót có thể chấp nhận phụ thuộc vào công việc và điều xảy ra sau một lỗi; không có một tỷ lệ nào phù hợp với mọi doanh nghiệp.

Nếu tính năng còn thực hiện hành động, hãy kiểm tra điều gì thực sự xảy ra trong hệ thống được kết nối. Chẳng hạn, nếu tính năng nói đã cập nhật hồ sơ, hãy xác nhận đúng hồ sơ có giá trị như dự kiến. Bài viết tháng 1 năm 2026 của Anthropic về đánh giá tác tử AI giải thích vì sao kết quả cuối cùng quan trọng khi phần mềm thực hiện hành động. Thông báo rằng công việc đã xong không chứng minh việc đó thành công.

Chất lượng đầu ra chỉ là một phần của việc chấp nhận. Bảo mật, quyền truy cập, quyền riêng tư và các bước khác trong quy trình cần được kiểm tra phù hợp riêng. Điểm câu trả lời cao không chứng minh những phần đó hoạt động đúng.

Đưa ra quyết định phát hành cụ thể

Hãy yêu cầu nhà cung cấp lập bản ghi ngắn về công việc và giới hạn của tính năng, các trường hợp kiểm thử và kết quả mong đợi, người đánh giá, lỗi quan trọng, điều còn chưa chắc chắn và phiên bản đã kiểm thử. Ghi rõ mô hình, hướng dẫn, tài liệu nguồn và phần mềm kết nối nếu chúng ảnh hưởng đến kết quả. Thống nhất những bước nào phải chạy lại khi bất kỳ yếu tố nào thay đổi.

Bằng chứng đó cần giúp bạn chọn một trong ba hướng:

• Cho phép dùng trong phạm vi giới hạn. Kết quả hỗ trợ một công việc xác định với giới hạn rõ ràng. Nhân viên biết khi nào cần xem lại, dừng hoặc quay về quy trình hiện tại.
• Sửa rồi kiểm thử lại. Cần khắc phục một số lỗi cụ thể. Hãy thống nhất trường hợp nào phải chạy lại và những ví dụ độc lập nào sẽ kiểm tra xem cách sửa có hiệu quả không.
• Tạm hoãn phát hành. Lỗi quan trọng vẫn chưa được xử lý hoặc bằng chứng còn quá ít để hỗ trợ mục đích sử dụng đề xuất.

Một đợt thử nghiệm giới hạn có thể bổ sung bằng chứng từ công việc thực tế. Hãy xác định trước người tham gia, công việc, quyền truy cập, cách xem xét kết quả và phương án quay lại quy trình cũ. Giao cho một người theo dõi vấn đề và tạm dừng thử nghiệm khi cần. Kết quả tốt trong một thử nghiệm nhỏ chỉ hỗ trợ phạm vi sử dụng đó, không chứng minh độ tin cậy trong mọi trường hợp.

Kết thúc buổi trao đổi về tiêu chí chấp nhận, bạn nên biết nhân viên có thể tin cậy điều gì, khi nào người phụ trách vẫn cần quyết định và điều gì sẽ khiến phải kiểm thử lại. Nếu bạn đang lên kế hoạch cho một tính năng AI trong ứng dụng nghiệp vụ theo yêu cầu, chúng tôi có thể trao đổi về công việc cần giải quyết và bằng chứng bạn cần trước khi chấp nhận tính năng.