BÀI VIẾT

QA Skills thực hành, phần 5: Bảo mật và đánh giá AI có bằng chứng

Xây phạm vi kiểm thử bảo mật được cấp phép, thiết kế bộ đánh giá AI, kiểm tra hội thoại nhiều lượt và quản lý giới hạn của kết quả.

Đọc cùng AI

Chọn nội dung để sao chép và dán vào trợ lý AI. Không tự gửi dữ liệu. Nội dung CMS được chuyển sang Markdown; dùng Markdown gốc nếu có.

Một API có thể trả dữ liệu đúng cấu trúc nhưng trả cho sai người. Một trợ lý AI có thể viết câu trả lời trôi chảy nhưng dựa trên thông tin không có trong tài liệu. Cả hai trường hợp đều đòi hỏi QA xác định rõ điều sản phẩm được phép làm, dữ kiện dùng để đánh giá và bằng chứng của từng lần kiểm tra.

Phần năm trong loạt QA Skills thực hành ghép hai nhóm kỹ năng này qua cùng một nguyên tắc: giới hạn quyền hạn và kiểm chứng hành vi. Các tình huống bên dưới là ví dụ học tập, dành cho hệ thống thử nghiệm mà bạn được cấp phép kiểm tra. Bài viết không mô tả một cuộc đánh giá bảo mật hay đánh giá mô hình đã diễn ra.

Bắt đầu bằng phạm vi được chấp thuận

Trước khi quét hoặc gửi các yêu cầu thử nghiệm, ghi rõ môi trường staging, tên dịch vụ, nhóm endpoint, tài khoản tổng hợp và người phụ trách. Thống nhất thời gian, giới hạn lưu lượng, điều kiện dừng, dữ liệu được sử dụng và cách báo cáo phát hiện. Chỉ dùng các thao tác nằm trong phạm vi đó; một đường dẫn công khai không tự đồng nghĩa với quyền kiểm tra chủ động.

Security Tester đề cập xác thực, phân quyền, kiểm tra dữ liệu đầu vào, cấu hình bảo mật và báo cáo khắc phục. Hãy dùng các nhóm này để đặt câu hỏi cụ thể. Việc có tên OWASP trong tài liệu hoặc chạy được một công cụ quét chưa chứng minh sản phẩm an toàn, càng không thay cho đánh giá tuân thủ pháp lý hay chứng nhận độc lập.

Đối với ứng dụng lưu sách mẫu, bài thực hành phù hợp là chuẩn bị hai tài khoản tổng hợp trong staging và xác nhận mỗi tài khoản chỉ nhìn thấy danh sách được phép. Bạn không cần dùng dữ liệu người thật để kiểm tra sự phân tách. Khi xác nhận được hiện tượng truy cập sai quyền, giữ bằng chứng tối thiểu và dừng mở rộng sang các đối tượng nằm ngoài phạm vi đã duyệt.

Tách xác thực, phân quyền và dữ liệu nhạy cảm

Xác thực trả lời người dùng là ai; phân quyền trả lời họ được làm gì với đối tượng cụ thể. Một nút bị ẩn trên giao diện chưa chứng minh API có kiểm soát truy cập. Ngược lại, API từ chối đúng không bảo đảm giao diện thông báo lỗi đủ rõ để người dùng tiếp tục công việc.

Kiểm tra vòng đời phiên cũng cần tiêu chí rõ: sau khi đăng xuất, những thao tác nào phải bị từ chối; phiên hết hạn được xử lý thế nào; người dùng có nhận hướng dẫn phù hợp không. Các yêu cầu phụ thuộc kiến trúc và chính sách của sản phẩm nên được xác nhận với nhóm kỹ thuật trước khi viết kết luận.

Log và báo cáo cần được xem như một phần của bề mặt dữ liệu. Chụp màn hình, trace hoặc response có thể chứa thông tin cá nhân và token. Loại bỏ dữ liệu nhạy cảm trước khi chia sẻ, hạn chế người được truy cập và đặt thời hạn lưu theo quy định của nhóm. Báo cáo phát hiện nên nêu điều kiện, ảnh hưởng, bằng chứng tái hiện trong staging và đề xuất xác minh sau sửa; không công bố bí mật để làm bằng chứng thuyết phục hơn.

Đánh giá AI bắt đầu từ một nhiệm vụ có thể chấm

AI Tester có tài liệu về kiểm tra prompt, rubric, an toàn và pipeline đánh giá. Một bài toán học tập rõ ràng là trợ lý trả lời câu hỏi về nội quy thư viện từ một bộ tài liệu đã cố định. Cần lưu phiên bản tài liệu, prompt hệ thống, cấu hình mô hình và bộ câu hỏi để có thể so sánh các thay đổi sau này.

Chia tập tình huống theo hành vi mong muốn:

Nhóm tình huống Điều cần đánh giá
Tài liệu có câu trả lời Trả lời đúng nội dung và dẫn đến đoạn hỗ trợ
Tài liệu không có thông tin Nêu giới hạn hoặc hỏi lại theo thiết kế
Câu hỏi thiếu điều kiện Làm rõ trước khi đưa kết luận
Nội dung truy xuất có chỉ dẫn lạ Giữ ranh giới giữa dữ liệu tham khảo và chỉ dẫn có thẩm quyền
Yêu cầu vượt quyền của trợ lý Không thực hiện hành động ngoài phạm vi được phép

Tạo đáp án chuẩn từ tài liệu gốc và ghi rõ phần nào do con người xác nhận. Với câu hỏi cần suy luận, rubric nên mô tả các điều kiện quan sát được: thông tin bắt buộc phải có, kết luận không được đưa ra khi thiếu dữ kiện và cách xử lý giới hạn nguồn. Một đáp án nghe hay nhưng thiếu căn cứ vẫn có thể thất bại ở tiêu chí chính xác.

Chọn cách chấm phù hợp với từng điều kiện

So khớp chính xác hữu ích cho đầu ra xác định như nhãn phân loại hoặc cấu trúc bắt buộc. Kiểm tra schema hữu ích khi cần JSON hợp lệ và các trường đúng kiểu. So khớp ngữ nghĩa phù hợp khi nhiều cách diễn đạt cùng đúng, nhưng không nên là bằng chứng duy nhất về độ chính xác của một chi tiết quan trọng.

Nếu dùng mô hình khác để chấm, hãy lưu rubric, phiên bản judge và nhận xét của nó. Rà soát một mẫu đầu ra bằng con người để phát hiện thiên lệch hoặc cách hiểu sai tiêu chí. Điểm do judge tạo ra là một phép đo có giới hạn; nó không tự trở thành sự thật nền. Không lấy trung bình chung để che một ca vượt quyền có ảnh hưởng nghiêm trọng.

Khi prompt hoặc model đổi, chạy lại cùng tập kiểm tra và so sánh từng nhóm. Ghi cả lỗi gọi dịch vụ, timeout và tình huống chưa được chấm. Nếu không có đầu ra vì thiếu cấu hình, đó là ca chưa đánh giá được, không phải ca đạt. Với đầu ra có tính biến thiên, cần thiết kế số lần chạy và cách tổng hợp trước khi xem kết quả, thay vì chỉ giữ lần trả lời đẹp nhất.

Hội thoại cần được kiểm tra theo chuỗi

Conversational Tester tập trung vào ý định, trích xuất thực thể, hội thoại nhiều lượt, fallback và quản lý ngữ cảnh. Giả sử người dùng hỏi giờ mở cửa của một chi nhánh, sau đó nói “Còn ngày cuối tuần thì sao?”. Đánh giá phải xem trợ lý còn giữ đúng chi nhánh hay không. Một câu hỏi được chấm riêng lẻ có thể bỏ lỡ lỗi này.

Thêm tình huống người dùng đổi chi nhánh, sửa thông tin vừa nói, hủy yêu cầu hoặc quay lại chủ đề cũ. Đáp án mong đợi nên quy định khi nào cần hỏi lại, khi nào được tiếp tục và khi nào phải chuyển cho con người. Với giọng nói, còn cần phân biệt lỗi nhận dạng âm thanh với lỗi hiểu ý định; transcript đẹp không đại diện cho mọi trải nghiệm đầu vào.

Sản phẩm của buổi thực hành

Hoàn thành một bản phạm vi bảo mật staging, một bảng phân quyền theo vai trò, một bộ câu hỏi AI có nguồn đáp án và một kịch bản hội thoại nhiều lượt. Nếu mới thiết kế, ghi là thiết kế. Nếu đã chạy, đính kèm cấu hình, kết quả thô được làm sạch và những điều chưa xác minh. Đó là cách người khác có thể xem lại và phản biện kết luận.

Chủ đề tham khảo từ bộ AI Tester Skills. Nội dung được biên soạn lại thành hướng dẫn thực hành cho người đọc.

Thảo luận

Bình luận được duyệt trước khi công khai. Email của bạn được giữ riêng tư.

← Về danh sách