Thử đối kháng, tiếng Anh gọi là red teaming, là việc giao cho một nhóm người nhiệm vụ đóng vai kẻ xấu hoặc người dùng khó lường, chủ động tìm cách làm hệ thống AI cư xử sai trước khi nó tới tay người thật. Mục đích là tìm lỗi để sửa, không phải để khoe hệ thống chắc chắn đến đâu.
Hình dung một nhà máy tổ chức diễn tập phòng cháy. Người ta không chỉ kiểm bình chữa cháy còn hạn hay không; người ta giả một đám cháy ở góc kho khó tới nhất, vào giờ đổi ca, để xem mọi người phản ứng ra sao. Thử đối kháng với AI cũng vậy: đi tìm tình huống mà đội phát triển chưa nghĩ tới.
Bài này nói ở mức tổ chức và quy trình: một vòng thử gồm những bước nào, nhóm cần những ai, thử tự động bằng máy giúp được tới đâu, và những sai lầm khiến cả vòng thử thành hình thức. Bài không đi vào kỹ thuật vượt rào cụ thể.
Thử đối kháng khác kiểm thử thông thường ở đâu?
Kiểm thử thông thường kiểm những gì đã định sẵn. Một ứng dụng ngân hàng được kiểm xem chuyển khoản có đúng số tiền, đúng người nhận, có báo lỗi khi số dư không đủ. Danh sách kiểm tra viết từ yêu cầu thiết kế, và hệ thống đạt khi qua hết danh sách.
Thử đối kháng bắt đầu từ câu hỏi ngược: hệ thống này có thể bị dùng sai hoặc tự làm sai theo những cách nào mà chưa ai viết vào yêu cầu. Với một trợ lý AI của ngân hàng, câu hỏi có thể là: nếu một khách lớn tuổi đang bị kẻ lừa đảo đứng bên cạnh hướng dẫn, trợ lý có nhận ra dấu hiệu và nhắc khách dừng lại không; nếu ai đó cố moi thông tin của khách khác, trợ lý giữ được đến đâu.
Với hệ thống AI, khác biệt này càng rõ vì đầu vào là ngôn ngữ tự nhiên, gần như vô hạn cách diễn đạt. Không có danh sách kiểm tra nào phủ hết. Thứ duy nhất làm được là để những người có óc tưởng tượng, hiểu lĩnh vực, hiểu người dùng, dành thời gian thật sự đi tìm chỗ hở.
Vì vậy kết quả của thử đối kháng không phải là chữ "đạt" hay "không đạt", mà là một danh sách lỗi đã tìm thấy, mức độ nghiêm trọng của từng lỗi, và những vùng chưa kịp thử. Phần cuối cùng này hay bị bỏ qua, trong khi nó cho người ra quyết định biết mình còn mù ở đâu.
Một vòng thử đối kháng gồm những bước nào
Khoanh phạm vi. Thử hệ thống nào, phiên bản nào, có gắn công cụ gì, dành cho người dùng nào; phạm vi mơ hồ thì kết quả cũng mơ hồ.
Lập danh sách tác hại ưu tiên. Với sản phẩm cụ thể, cái gì là tệ nhất: lộ dữ liệu khách, khuyên sai về sức khoẻ, bị dụ hứa hẹn thay công ty, nói lời xúc phạm; xếp theo mức thiệt hại.
Chọn người và giao vai. Mỗi người phụ trách một nhóm tác hại hoặc một kiểu người dùng, để tránh cả nhóm cùng thử một kiểu.
Đặt quy tắc cho người thử. Được làm gì, không được làm gì, không dùng dữ liệu thật của khách, xử lý nội dung độc hại gặp phải ra sao.
Chuẩn bị môi trường tách biệt. Thử trên bản sao, không nối với hệ thống thanh toán hay dữ liệu thật, để lỗi tìm ra không gây hại thật.
Ghi nhật ký đầy đủ. Mỗi lần thử ghi lại đầu vào, đầu ra, phiên bản, thời điểm; không có nhật ký thì đội phát triển không tái hiện được lỗi để sửa.
Phân loại mức nghiêm trọng. Dùng một thang thống nhất, xét cả mức hại lẫn độ dễ xảy ra; một lỗi hiếm mà hại lớn vẫn phải được đặt lên đầu.
Báo cáo cho đúng người. Báo cáo chi tiết chỉ chuyển cho người cần sửa; bản tóm tắt cho lãnh đạo nêu rủi ro và đề xuất, không kèm cách tái hiện.
Sửa và thử lại. Sau khi đội phát triển sửa, chính nhóm thử kiểm lại đúng lỗi đó và các biến thể gần nó, vì bản sửa hay chỉ bịt được đúng một cách hỏi.
Lặp lại sau mỗi thay đổi lớn. Đổi mô hình nền, đổi câu dẫn hệ thống, thêm công cụ mới đều có thể mở lại lỗi cũ hoặc tạo lỗi mới.
Ghi rõ vùng chưa thử. Kết thúc mỗi vòng bằng danh sách những gì chưa kịp thử, để người ra quyết định biết giới hạn của kết quả.
Nhóm thử đối kháng nên có những ai
Kỹ sư hiểu hệ thống. Biết hệ thống được ghép từ những phần nào, chỗ nào dữ liệu đi vào, chỗ nào hành động đi ra.
Chuyên gia lĩnh vực. Bác sĩ cho trợ lý sức khoẻ, luật sư cho trợ lý pháp lý, kế toán cho trợ lý tài chính; họ nhận ra câu trả lời sai mà người ngoài thấy hợp lý.
Người làm chăm sóc khách hàng. Họ biết khách thật hỏi gì, nổi nóng ra sao, hiểu nhầm ở đâu, những thứ kỹ sư ít khi gặp.
Người am hiểu ngôn ngữ vùng miền. Cách nói ở Hải Phòng, ở Huế, ở miền Tây khác nhau; hệ thống hiểu sai giọng địa phương là lỗi thật với khách thật.
Người đại diện nhóm dễ tổn thương. Người lớn tuổi, người ít dùng công nghệ, người khuyết tật; họ chỉ ra những tình huống mà nhóm trẻ, rành công nghệ không nghĩ tới.
Người làm an ninh thông tin. Họ nghĩ theo hướng kẻ tấn công có chủ đích: lấy dữ liệu, chiếm quyền, lợi dụng công cụ gắn kèm.
Người ngoài tổ chức. Người trong công ty hay vô thức tránh những chỗ biết là yếu; một vài người ngoài, có ký cam kết bảo mật, giúp phá thói quen đó.
Người hiểu văn hoá và chuẩn mực xã hội. Có những câu trả lời không sai về thông tin nhưng xúc phạm, thiếu tế nhị trong bối cảnh Việt Nam.
Người điều phối. Giữ cho vòng thử bám phạm vi, chia việc, gom kết quả, không để mỗi người thử một kiểu rồi mất dấu.
Người phản biện kết quả. Đọc lại danh sách lỗi, hỏi mức nghiêm trọng có bị thổi phồng hay xem nhẹ không.
Người hỗ trợ tinh thần cho nhóm. Thử đối kháng buộc người thử tiếp xúc nội dung độc hại nhiều giờ liền; cần có giới hạn thời gian và chỗ để chia sẻ.
Thử đối kháng tự động: máy thử máy giúp được tới đâu
Vì đầu vào gần như vô hạn, nhiều nhóm dùng thêm một mô hình khác để sinh hàng loạt câu thử, rồi dùng bộ chấm tự động lọc ra những câu khiến hệ thống trả lời có vấn đề. Cách này phủ được rất nhiều biến thể trong thời gian ngắn, điều mà vài người làm tay không theo kịp.
Điểm mạnh của máy là độ rộng: nó thử được hàng nghìn cách diễn đạt khác nhau cho cùng một ý, bắt được những lỗi kiểu "đổi vài chữ là hệ thống trả lời khác hẳn". Sau mỗi lần sửa, chạy lại bộ thử tự động cũng nhanh và rẻ hơn tổ chức lại cả nhóm người.
Điểm yếu là độ sâu. Mô hình sinh câu thử có xu hướng xoay quanh những kiểu tấn công đã quen, ít khi nghĩ ra một tình huống thật sự mới. Bộ chấm tự động cũng có thể bỏ sót câu trả lời nguy hại được diễn đạt khéo, hoặc đánh dấu oan câu trả lời vô hại.
Cách làm hợp lý thường là kết hợp: người tìm ra kiểu lỗi mới, máy nhân kiểu lỗi đó thành nhiều biến thể để đo xem nó phổ biến đến đâu và bản sửa có bịt được hết không. Máy không thay được người ở khâu đầu, nhưng giúp người không phải làm lại những việc lặp đi lặp lại.
Những sai lầm khiến thử đối kháng thành hình thức
Làm một lần trước ngày ra mắt rồi thôi. Hệ thống thay đổi liên tục; một vòng thử cũ không nói gì về phiên bản đang chạy.
Để chính đội phát triển tự thử. Người làm ra hệ thống khó nhìn nó bằng con mắt của kẻ muốn phá nó.
Thời gian quá ngắn. Vài giờ chỉ đủ tìm lỗi bề mặt; lỗi nghiêm trọng thường cần nhiều ngày, nhiều vòng đào sâu.
Chỉ thử bằng tiếng Anh. Sản phẩm phục vụ người Việt mà chỉ thử bằng tiếng Anh thì bỏ ngỏ đúng ngôn ngữ khách dùng.
Bỏ qua công cụ gắn kèm. Trợ lý đọc được email, tra được đơn hàng, gửi được tin nhắn có những rủi ro mà mô hình trơn không có.
Đếm số lỗi thay vì xét mức độ. Một trăm lỗi nhỏ về giọng điệu không đáng lo bằng một lỗi làm lộ dữ liệu khách.
Sửa đúng câu bị bắt rồi đóng hồ sơ. Bản sửa phải được thử với các biến thể, nếu không lỗi chỉ đổi chỗ trú.
Không ghi nhật ký. Lỗi tìm được mà không tái hiện được thì gần như không sửa được.
Báo cáo chỉ nêu cái đã tìm thấy. Thiếu phần vùng chưa thử khiến người đọc tưởng hệ thống đã được kiểm kỹ hơn thực tế.
Phạt người tìm ra lỗi lớn. Khi tìm ra lỗi bị xem là gây phiền cho dự án, người thử sẽ ngừng đào sâu.
Để thông tin chi tiết lan rộng. Cách tái hiện lỗi nghiêm trọng là thông tin nhạy cảm; nên lưu kín cho tới khi đã sửa xong.
Câu hỏi thường gặp
Doanh nghiệp nhỏ có cần thử đối kháng không?
Cần, ở quy mô vừa sức. Trước khi đưa chatbot cho khách, vài nhân viên am hiểu khách hàng dành một buổi cố tìm cách làm nó trả lời sai, hứa bậy hoặc lộ thông tin đã giúp bắt được nhiều lỗi rẻ hơn rất nhiều so với để khách phát hiện.
Thử đối kháng có phải là hack hệ thống không?
Không. Đây là việc được chủ hệ thống giao, có phạm vi, có quy tắc, làm trên môi trường thử, và kết quả chỉ dùng để sửa. Tự ý thử phá hệ thống của người khác khi không được phép là chuyện khác hẳn và có thể vi phạm pháp luật.
Kết quả thử đối kháng có nên công bố không?
Thường công bố bản tóm tắt: đã thử những nhóm rủi ro nào, tìm thấy loại vấn đề gì, đã xử lý ra sao. Chi tiết cách tái hiện lỗi nghiêm trọng thì không nên công bố, vì có thể bị lợi dụng trước khi mọi bên kịp sửa.
Một vòng thử đối kháng mất bao lâu?
Tuỳ quy mô hệ thống và mức rủi ro. Một chatbot hỏi đáp nội bộ có thể vài ngày; một mô hình đa năng sắp phát hành rộng có thể kéo dài nhiều tuần với nhiều nhóm chuyên môn khác nhau.
Thử đối kháng có bảo đảm hệ thống an toàn không?
Không. Nó chỉ cho biết những lỗi đã tìm được và những vùng đã thử. Không tìm thấy lỗi ở một vùng không có nghĩa là vùng đó không có lỗi, nên nó phải đi cùng giám sát sau khi phát hành.
