Nhiều dự án AI bắt đầu bằng một màn trình diễn thuyết phục. Mô hình trả lời nhanh, diễn đạt tự nhiên và xử lý được một số yêu cầu mẫu khiến người dùng có cảm giác rằng công nghệ đã sẵn sàng để đưa vào vận hành. Tuy nhiên, khoảng cách giữa một bản trình diễn tốt và một hệ thống đáng tin cậy trong môi trường thực tế thường rất lớn. Khi phải phục vụ nhiều nhóm người dùng, tiếp nhận dữ liệu không đồng nhất và xử lý những tình huống không được dự đoán trước, mô hình có thể bộc lộ các điểm yếu mà vài câu hỏi thử nghiệm ban đầu không thể cho thấy.
Vì vậy, đánh giá AI không chỉ là kiểm tra xem mô hình có trả lời đúng hay không. Một quy trình nghiêm túc còn phải xem xét mức độ phù hợp với mục tiêu, khả năng giải thích, tính ổn định, tốc độ phản hồi, chi phí vận hành, rủi ro về dữ liệu và cách con người can thiệp khi có sự cố. Đánh giá càng được thực hiện sớm và có cấu trúc, tổ chức càng tránh được việc triển khai một công cụ hấp dẫn nhưng không đáp ứng được yêu cầu thực tế.
Vì sao vài câu hỏi mẫu không đủ để kiểm chứng AI?
Câu hỏi mẫu thường được lựa chọn theo hướng có lợi cho mô hình. Người thử biết mình muốn chứng minh điều gì nên dễ dàng đưa ra những yêu cầu rõ ràng, ngắn gọn và nằm trong phạm vi mà hệ thống xử lý tốt. Trong khi đó, người dùng ngoài thực tế có thể viết thiếu thông tin, dùng từ địa phương, nhập sai chính tả, trộn nhiều yêu cầu hoặc đặt câu hỏi không thuộc phạm vi thiết kế. Một mô hình chỉ được thử bằng các trường hợp thuận lợi sẽ tạo ra cảm giác an toàn giả.
Ngoài độ chính xác, câu trả lời còn có thể thay đổi giữa những lần chạy khác nhau. Một hệ thống đôi khi đưa ra nội dung đúng về ý chính nhưng thiếu điều kiện quan trọng, diễn giải quá tự tin hoặc trình bày khiến người đọc hiểu sai. Với những tác vụ nhạy cảm, sai sót không nhất thiết phải là một thông tin hoàn toàn bịa đặt mới gây hậu quả. Chỉ cần bỏ sót một ngoại lệ, nhầm lẫn một khái niệm hoặc không báo rõ mức độ không chắc chắn, kết quả đã có thể không còn phù hợp để sử dụng.
Do đó, bài kiểm thử cần phản ánh những tình huống bình thường, tình huống khó và cả tình huống bất thường. Mục tiêu không phải là tìm cách làm mô hình thất bại bằng những câu hỏi mẹo, mà là hiểu rõ ranh giới năng lực của nó. Một hệ thống tốt không phải hệ thống luôn trả lời mọi câu hỏi, mà là hệ thống biết khi nào có thể trả lời, khi nào cần hỏi lại và khi nào nên chuyển yêu cầu cho con người.
Xác định đúng tiêu chí trước khi chọn mô hình
Không có một mô hình AI tốt nhất cho mọi bài toán. Mô hình phù hợp phải được xác định dựa trên nhiệm vụ cụ thể và mức độ chấp nhận rủi ro của tổ chức. Với một công cụ hỗ trợ viết bản nháp, khả năng diễn đạt và tốc độ có thể quan trọng hơn việc tạo ra câu trả lời hoàn hảo ngay từ lần đầu. Ngược lại, với hệ thống phân loại hồ sơ hoặc hỗ trợ quy trình nội bộ, tính nhất quán, khả năng truy vết và tỷ lệ xử lý đúng có thể được đặt lên hàng đầu.
Trước khi kiểm thử, nhóm triển khai nên mô tả rõ đầu ra mong muốn. Đầu ra đó cần có nội dung gì, không được chứa điều gì, được phép sai ở mức nào và ai là người chịu trách nhiệm kiểm tra? Câu hỏi này giúp phân biệt giữa lỗi có thể sửa trong bước biên tập và lỗi có thể làm ảnh hưởng đến quyết định cuối cùng. Nếu không có tiêu chí từ đầu, việc so sánh các mô hình dễ bị chi phối bởi cảm nhận chủ quan hoặc bởi một vài kết quả nổi bật.
Có thể chia tiêu chí thành nhiều nhóm. Nhóm đầu tiên là chất lượng nội dung, bao gồm độ đúng, mức đầy đủ, sự liên quan và khả năng tuân thủ yêu cầu. Nhóm thứ hai là trải nghiệm sử dụng, gồm thời gian phản hồi, cách trình bày và mức dễ hiểu. Nhóm thứ ba liên quan đến vận hành như chi phí, khả năng mở rộng, độ ổn định và khả năng tích hợp. Nhóm cuối cùng là rủi ro, trong đó có bảo mật, quyền riêng tư, thiên lệch và nguy cơ tạo ra nội dung không phù hợp.
Xây dựng bộ kiểm thử đại diện cho người dùng thật
Một bộ kiểm thử có giá trị cần được hình thành từ công việc thực tế thay vì chỉ dựa vào tưởng tượng của đội kỹ thuật. Nhóm phụ trách nên thu thập các dạng yêu cầu thường gặp, những câu hỏi gây nhầm lẫn, các trường hợp thiếu dữ liệu và những tình huống từng khiến quy trình hiện tại gặp khó khăn. Nếu dữ liệu kiểm thử chứa thông tin nhạy cảm, cần loại bỏ hoặc thay thế các chi tiết nhận dạng trước khi sử dụng.
Bộ kiểm thử nên bao gồm cả trường hợp dễ và khó. Trường hợp dễ giúp xác nhận các chức năng cơ bản. Trường hợp khó cho thấy mô hình xử lý ra sao khi yêu cầu dài, mơ hồ, có nhiều bước hoặc chứa thông tin mâu thuẫn. Một nhóm khác nên kiểm tra khả năng từ chối đúng lúc, chẳng hạn khi người dùng yêu cầu hệ thống thực hiện việc vượt quá phạm vi được cấp phép. Cách mô hình từ chối cũng cần được xem xét, bởi một lời từ chối quá chung chung có thể khiến người dùng không biết phải làm gì tiếp theo.
Nên tách dữ liệu dùng để phát triển khỏi dữ liệu dùng để đánh giá cuối cùng. Nếu cùng một tập câu hỏi được dùng lặp đi lặp lại trong quá trình điều chỉnh, nhóm phát triển có thể vô tình tối ưu mô hình cho đúng những ví dụ đó mà không cải thiện năng lực tổng quát. Một tập đánh giá được giữ riêng, chỉ mở khi cần kiểm tra, sẽ cho hình ảnh trung thực hơn về hiệu quả của phiên bản mới.
Đo lường cả chất lượng và mức độ ổn định
Độ chính xác là chỉ số quan trọng nhưng không phải chỉ số duy nhất. Một câu trả lời có thể đúng về nội dung nhưng quá dài, thiếu cấu trúc hoặc không phù hợp với ngữ cảnh sử dụng. Vì vậy, đánh giá nên kết hợp kiểm tra tự động với nhận xét của con người. Các phép đo tự động hữu ích khi cần so sánh nhiều phiên bản trên cùng một tập dữ liệu, còn người đánh giá có thể nhận ra những sắc thái mà một thước đo đơn giản bỏ qua.
Người đánh giá nên sử dụng bảng tiêu chí thống nhất thay vì chỉ cho điểm theo ấn tượng. Chẳng hạn, họ có thể xem xét riêng độ đúng, mức đầy đủ, cách diễn đạt, việc tuân thủ định dạng và khả năng nêu rõ giới hạn. Bảng tiêu chí cần có hướng dẫn cụ thể về thế nào là đạt, chưa đạt và không thể đánh giá. Khi có nhiều người tham gia, việc đối chiếu nhận xét sẽ giúp phát hiện những điểm mà tiêu chí đang quá mơ hồ.
Mức độ ổn định cũng cần được kiểm tra. Với cùng một yêu cầu, hệ thống có thể tạo ra các cách diễn đạt khác nhau. Sự khác biệt không phải lúc nào cũng là vấn đề, nhưng kết luận cốt lõi và những thông tin quan trọng không nên thay đổi tùy tiện. Nhóm triển khai nên chạy lại các trường hợp đại diện ở nhiều thời điểm, sau các lần cập nhật cấu hình hoặc sau khi thay đổi nguồn dữ liệu. Đây là cách phát hiện những thay đổi ngoài dự kiến trước khi người dùng cuối gặp phải.
Đừng bỏ qua các tình huống thất bại
Trong nhiều dự án, báo cáo đánh giá thường tập trung vào những gì mô hình làm tốt. Cách tiếp cận này có thể khiến lãnh đạo và người dùng đánh giá quá cao khả năng của hệ thống. Một báo cáo hữu ích phải mô tả cả các dạng thất bại, tần suất xuất hiện, mức độ nghiêm trọng và điều kiện dẫn đến lỗi. Hai lỗi có cùng số lần xuất hiện nhưng không nhất thiết có cùng mức rủi ro. Lỗi định dạng có thể được sửa nhanh, trong khi việc đưa ra kết luận sai trong một quy trình quan trọng cần cơ chế kiểm soát chặt chẽ hơn.
Nhóm đánh giá cũng nên kiểm tra các yêu cầu có nội dung mâu thuẫn, thông tin thiếu, ngôn ngữ không chuẩn hoặc cố tình yêu cầu mô hình bỏ qua quy tắc. Những bài kiểm tra này không nhằm khuyến khích sử dụng sai mục đích, mà để xác định liệu hệ thống có giữ được nguyên tắc vận hành khi gặp đầu vào bất thường hay không. Nếu mô hình không thể tự nhận biết giới hạn, giao diện cần hiển thị cảnh báo và quy trình phải yêu cầu người có chuyên môn xác nhận.
Mỗi loại lỗi nên gắn với một phương án xử lý. Có trường hợp chỉ cần yêu cầu người dùng bổ sung thông tin. Có trường hợp cần chuyển sang nhân viên phụ trách. Cũng có tình huống phải tạm dừng chức năng để kiểm tra nguyên nhân. Việc định nghĩa trước các bước này giúp tổ chức phản ứng nhanh hơn và tránh để người dùng tự suy đoán xem có nên tin vào kết quả hay không.
Đánh giá trong bối cảnh vận hành thực tế
Một mô hình có thể đạt kết quả tốt trong môi trường thử nghiệm nhưng hoạt động kém khi được kết nối với các hệ thống khác. Độ trễ của mạng, giới hạn tài nguyên, thay đổi định dạng dữ liệu đầu vào và số lượng yêu cầu tăng cao đều có thể ảnh hưởng đến trải nghiệm. Vì vậy, ngoài kiểm thử nội dung, cần có giai đoạn thử nghiệm gần với điều kiện vận hành thật, nhưng vẫn giới hạn phạm vi và bảo đảm khả năng kiểm soát.
Trong giai đoạn này, tổ chức nên theo dõi các chỉ số đã xác định từ trước và ghi nhận phản hồi của người dùng. Cần phân biệt giữa lỗi của mô hình, lỗi của dữ liệu, lỗi của giao diện và lỗi trong quy trình con người. Nếu chỉ nhìn vào kết quả cuối cùng, nhóm triển khai có thể sửa sai chỗ. Chẳng hạn, một câu trả lời không chính xác có thể bắt nguồn từ dữ liệu đầu vào không đầy đủ thay vì từ năng lực suy luận của mô hình.
Cơ chế ghi nhật ký cũng rất quan trọng, nhưng phải được thiết kế phù hợp với yêu cầu bảo mật. Nhật ký nên giúp truy tìm phiên bản mô hình, cấu hình, thời điểm xử lý và nguồn đầu vào liên quan mà không lưu trữ vượt quá mức cần thiết. Người có quyền truy cập nhật ký phải được phân định rõ. Đây là nền tảng để điều tra sự cố, cải thiện hệ thống và giải thích quyết định khi có tranh chấp.
AI đáng tin cậy cần sự giám sát liên tục
Đánh giá không phải một cột mốc chỉ thực hiện trước ngày ra mắt. Mô hình, dữ liệu và hành vi người dùng đều có thể thay đổi. Một hệ thống từng hoạt động tốt có thể giảm chất lượng khi phạm vi sử dụng mở rộng hoặc khi các quy trình nội bộ thay đổi. Bởi vậy, tổ chức cần lập lịch xem xét định kỳ, theo dõi các chỉ số quan trọng và tạo kênh để người dùng báo lỗi một cách thuận tiện.
Vai trò của con người cũng phải được xác định rõ. Người kiểm duyệt cần biết phần nào do AI tạo ra, phần nào đã được xác minh và trong trường hợp nào họ bắt buộc phải tự kiểm tra. Nếu trách nhiệm bị bỏ ngỏ, người dùng có thể mặc nhiên xem kết quả của mô hình như quyết định cuối cùng. Ngược lại, nếu quy trình yêu cầu con người kiểm tra mọi đầu ra mà không phân loại mức rủi ro, AI sẽ khó tạo ra hiệu quả đáng kể.
Cuối cùng, một hệ thống AI đáng tin cậy không được đo bằng mức độ ấn tượng của công nghệ, mà bằng khả năng tạo ra kết quả phù hợp trong điều kiện thực tế và có thể kiểm soát khi xảy ra sai sót. Việc xây dựng bộ kiểm thử đại diện, công bố giới hạn, theo dõi chất lượng sau triển khai và duy trì quyền can thiệp của con người sẽ giúp tổ chức đưa ra quyết định tỉnh táo hơn. AI khi đó không chỉ là công cụ tạo câu trả lời, mà trở thành một thành phần được quản lý có trách nhiệm trong toàn bộ quy trình.
