- Hướng dẫn thẩm vấn AI: Sử dụng phương pháp đặt câu hỏi có cấu trúc để phát hiện hành vi không an toàn, gây hiểu lầm hoặc làm lộ thông tin mật của mô hình.
- Quy trình chính: Xác định phạm vi rủi ro, thiết kế bài kiểm thử, thực hiện an toàn, phân loại lỗi và lặp lại quá trình đánh giá.
- Phương pháp cốt lõi: Kết hợp thăm dò prompt, đầu vào đối kháng, đặt câu hỏi kiểu Socrates và các bài tập red-team.
- Thực hành tốt nhất: Ghi lại prompt, đầu ra, ngữ cảnh và bằng chứng khắc phục để phục vụ việc đánh giá có thể truy xuất.
- Ranh giới an toàn: Kiểm thử trong môi trường được kiểm soát, sử dụng dữ liệu đã phê duyệt, kế hoạch khôi phục và phân công trách nhiệm rõ ràng.
Hướng dẫn thẩm vấn AI: Mục đích và phạm vi
Một hướng dẫn thẩm vấn AI nên bắt đầu với mục tiêu phòng thủ: tìm hiểu nơi hệ thống AI thất bại trước khi những lỗi đó trở thành sự cố ảnh hưởng đến người dùng. Thẩm vấn AI là một hoạt động rộng, bao gồm việc chủ động đặt câu hỏi, gây áp lực và phân tích hành vi của mô hình. Hoạt động này có thể phát hiện hiện tượng bịa đặt thông tin, rò rỉ quyền riêng tư, tuân theo chỉ dẫn độc hại, suy luận không nhất quán và các ranh giới an toàn yếu.
Công việc này thuộc một chương trình giám sát, an toàn và quản trị AI rộng hơn. Đây không chỉ là tập hợp các prompt khéo léo. Một chiến dịch hữu ích kết nối mục tiêu kiểm thử với tài sản, kịch bản người dùng, hồ sơ kẻ tấn công, độ nhạy cảm của dữ liệu và các nhiệm vụ khắc phục có thể đo lường.
| Khu vực rủi ro | Nội dung cần kiểm tra | Bằng chứng mẫu |
|---|---|---|
| An toàn | Phản hồi gây hại hoặc vi phạm chính sách | Prompt, phản hồi, danh mục chính sách |
| Quyền riêng tư | Tiết lộ dữ liệu cá nhân hoặc thông tin mật | Dấu vết đã ẩn danh, phân loại dữ liệu |
| Bảo mật | Prompt injection hoặc vượt qua chỉ dẫn | Con đường tấn công, quy trình bị ảnh hưởng |
| Độ tin cậy | Thông tin bịa đặt và câu trả lời không nhất quán | Các đầu ra lặp lại, kết quả kiểm tra sự thật |
| Quản trị | Thiếu người chịu trách nhiệm hoặc hồ sơ kiểm toán | ID kiểm thử, người đánh giá, trạng thái khắc phục |
Hãy bắt đầu bằng cách xác định hệ thống được phép làm gì, có thể truy cập thông tin nào và những đầu ra nào có thể gây ra tác hại không thể chấp nhận. Điều này giúp tránh việc kiểm thử thiếu trọng tâm và cung cấp cho người đánh giá một tiêu chuẩn nhất quán để xác định mức độ nghiêm trọng.
Khám phá bề mặt tấn công
Xác định cách người dùng, nội dung được truy xuất, công cụ hoặc thay đổi ngữ cảnh có thể thao túng mô hình hoặc làm lộ thông tin bị hạn chế.
Khả năng chống chịu bảo mật
Mô phỏng hành vi đối kháng thực tế để các nhóm có thể củng cố biện pháp phòng thủ trước khi điểm yếu bị khai thác trong môi trường sản xuất.
Giám sát có thể kiểm toán
Lưu giữ các trường hợp kiểm thử, dấu vết, quyết định và bản sửa lỗi để những người đánh giá sau này có thể xác minh điều gì đã thay đổi và vì sao.
Xác định tài sản, quyền hạn, lớp dữ liệu và kịch bản người dùng trước khi viết prompt đối kháng. Một mô hình mối đe dọa cụ thể sẽ tạo ra kết quả có tính hành động cao hơn so với việc thăm dò ngẫu nhiên.
Các kỹ thuật thẩm vấn AI cốt lõi
Thẩm vấn AI đạt hiệu quả tốt nhất khi kết hợp nhiều hình thức kiểm thử. Công cụ tạo tự động có thể bao quát số lượng lớn prompt, trong khi người đánh giá cung cấp ngữ cảnh, sự sáng tạo và phán đoán. Mỗi kỹ thuật cần có mục đích và định dạng ghi nhật ký rõ ràng.
| Kỹ thuật | Mục đích chính | Trọng tâm hữu ích |
|---|---|---|
| Thăm dò dựa trên prompt | Tìm đầu ra không an toàn, không chính xác hoặc chứa thông tin mật | Nhập vai, thay đổi ngữ cảnh, prompt lặp |
| Kiểm thử jailbreak | Đánh giá khả năng chống lại các nỗ lực vượt qua rào chắn | Thuyết phục, xung đột chỉ dẫn, làm rối |
| Red-teaming | Mô phỏng các mối đe dọa phối hợp trong thế giới thực | Điểm yếu của mô hình, sản phẩm, bảo mật và chính sách |
| Đầu vào đối kháng | Buộc hệ thống xử lý các trường hợp biên và hành vi bất ngờ | Văn bản bị làm rối, định dạng bất thường, ngữ cảnh bị đầu độc |
| Đặt câu hỏi kiểu Socrates | Làm lộ các giả định ẩn và mâu thuẫn | Câu hỏi tiếp nối theo lớp, kiểm tra bằng chứng, tính nhất quán |
Thăm dò dựa trên prompt sử dụng các bộ kiểm thử có thể lặp lại thay vì những câu hỏi đơn lẻ. Hãy bắt đầu với các yêu cầu thông thường, sau đó đưa vào các trường hợp biên và những biến thể đối kháng được kiểm soát. So sánh cách mô hình phản hồi khi cách diễn đạt, vai trò, ngữ cảnh hoặc lịch sử hội thoại thay đổi.
Kiểm thử jailbreak và kỹ thuật thao túng xã hội xem xét liệu sự thuyết phục hoặc cách định khung có thể khiến hệ thống bỏ qua các ràng buộc hay không. Những bài kiểm thử này phải được ủy quyền và thực hiện trong môi trường sandbox. Mục tiêu là đo lường ranh giới, không phải triển khai cơ chế vượt rào đối với người dùng thực hoặc hệ thống nhạy cảm.
Red-teaming AI mở rộng góc nhìn vượt ra ngoài cách diễn đạt prompt. Những người kiểm thử liên chức năng có thể xem xét các giả định trong quá trình huấn luyện, công cụ lúc chạy, nguồn truy xuất, quyền kiểm soát truy cập và hành vi của giao diện người dùng. Red-teaming là một phương pháp có cấu trúc trong lĩnh vực thẩm vấn AI rộng hơn.
Đặt câu hỏi kiểu Socrates đặc biệt hữu ích trong các đợt đánh giá độ tin cậy. Yêu cầu hệ thống nêu rõ các giả định, xác định bằng chứng, giải thích mức độ không chắc chắn và xem xét lại kết luận sau khi nhận thông tin mới. Cách này có thể làm lộ những mâu thuẫn mà một câu trả lời đơn lẻ sẽ che giấu.
Không chạy kiểm thử đối kháng trên hệ thống sản xuất nếu chưa có phê duyệt bằng văn bản, cơ chế giám sát và quy trình khôi phục. Không bao giờ đưa bí mật thực hoặc dữ liệu cá nhân không cần thiết vào prompt kiểm thử.
Quy trình thẩm vấn AI từng bước
Một quy trình có thể lặp lại sẽ biến các phát hiện từ hoạt động thẩm vấn thành hành động kỹ thuật và quản trị. Năm giai đoạn dưới đây phản ánh một vòng đời thực tế: xác định mối đe dọa, tạo bài kiểm thử, thu thập bằng chứng, khắc phục các vấn đề được ưu tiên và xác minh kết quả.
Xác định mô hình mối đe dọa
Liệt kê các tài sản cần bảo vệ, dữ liệu nhạy cảm, nhóm người dùng, công cụ được kết nối và hành vi có khả năng xảy ra của kẻ tấn công. Xác định thế nào là một vụ rò rỉ nghiêm trọng, câu trả lời không an toàn, lỗi bảo mật hoặc hiện tượng bịa đặt không thể chấp nhận.
Thiết kế bộ kiểm thử
Tạo prompt thông thường, prompt cho trường hợp biên và prompt đối kháng. Bổ sung các kịch bản cho việc thay đổi vai trò, chuyển dịch ngữ cảnh lặp lại, prompt injection, yêu cầu liên quan đến quyền riêng tư và các chỉ dẫn xung đột.
Thực hiện và ghi nhật ký
Chạy các bài kiểm thử trong môi trường được kiểm soát. Ghi lại toàn bộ chuỗi prompt, đầu ra của mô hình, ngữ cảnh hệ thống, cấu hình, dấu thời gian, người đánh giá và mọi hoạt động sử dụng công cụ hoặc truy xuất dữ liệu.
Phân loại và khắc phục
Phân loại mỗi lỗi theo nhóm an toàn, quyền riêng tư, bảo mật, bịa đặt thông tin hoặc quản trị. Ưu tiên các bản sửa dựa trên tác động đến người dùng, độ nhạy cảm của dữ liệu, khả năng khai thác và mức độ tái diễn.
Khép kín vòng lặp
Chạy lại các trường hợp thất bại, thêm kiểm thử hồi quy, giám sát hành vi trong môi trường sản xuất và kết nối kết quả với đánh giá phát hành, quy trình quản trị và các cổng đánh giá CI/CD.
| Giai đoạn quy trình | Đầu ra bắt buộc | Câu hỏi đánh giá |
|---|---|---|
| Phạm vi | Mô hình mối đe dọa và ranh giới kiểm thử | Hệ thống phải bảo vệ điều gì? |
| Thiết kế | Bộ prompt và kịch bản có phiên bản | Các bài kiểm thử có bao quát việc sử dụng thông thường và đối kháng không? |
| Thực hiện | Nhật ký và dấu vết có thể tái lập | Người đánh giá khác có thể tái lập kết quả không? |
| Phân loại | Phân công mức độ nghiêm trọng và trách nhiệm | Những lỗi nào cần hành động ngay lập tức? |
| Khép kín vòng lặp | Bằng chứng hồi quy và kế hoạch giám sát | Bản sửa có cải thiện hành vi mà không tạo ra rủi ro mới không? |
Giai đoạn thực hiện cần bảo toàn đủ ngữ cảnh để kết quả có ý nghĩa. Một phản hồi có thể trông an toàn khi đứng riêng lẻ nhưng lại thất bại khi mô hình nhận được văn bản được truy xuất, chỉ dẫn hệ thống đã thay đổi hoặc lịch sử hội thoại dài hơn. Vì vậy, khả năng truy xuất nguồn gốc cũng quan trọng như bản thân prompt.
Một phát hiện tốt bao gồm trường hợp kiểm thử, hành vi quan sát được, tác động, mức độ nghiêm trọng, người chịu trách nhiệm, bản sửa được đề xuất và kết quả xác minh. Điều này giúp hoạt động thẩm vấn trở nên hữu ích đối với cả nhóm kỹ thuật lẫn nhóm quản trị.
Ghi nhật ký, phân loại và khắc phục
Hoạt động thẩm vấn AI đáng tin cậy phụ thuộc vào bằng chứng. Việc ghi nhật ký cần hỗ trợ khả năng kiểm toán mà không thu thập nhiều thông tin nhạy cảm hơn mức cần thiết. Khi dữ liệu kiểm thử chứa thông tin cá nhân hoặc mật, hãy sử dụng các ví dụ tổng hợp hoặc đã ẩn danh được phê duyệt bất cứ khi nào có thể.
| Loại phát hiện | Tín hiệu ưu tiên | Phản hồi điển hình |
|---|---|---|
| Rò rỉ quyền riêng tư nghiêm trọng | Tiết lộ bí mật hoặc dữ liệu bị hạn chế | Thu hồi con đường phơi lộ, điều tra quyền truy cập, thêm kiểm thử hồi quy |
| Đầu ra độc hại | Chỉ dẫn gây hại hoặc hỗ trợ không an toàn | Xem xét các biện pháp kiểm soát chính sách, bộ lọc, hành vi mô hình và quy trình chuyển cấp |
| Vượt qua kiểm soát bảo mật | Chỉ dẫn ghi đè các biện pháp kiểm soát dự kiến | Kiểm tra thứ bậc chỉ dẫn, quyền công cụ và ranh giới truy xuất |
| Bịa đặt thông tin | Khẳng định tự tin nhưng không có bằng chứng hỗ trợ | Cải thiện khả năng dựa trên nguồn, xử lý mức độ không chắc chắn và kiểm tra sự thật |
| Không nhất quán | Câu trả lời khác biệt đáng kể cho các prompt tương đương | Thêm kiểm thử biến thể và xem xét tính ổn định của mô hình hoặc ngữ cảnh |
Việc phân loại cần xem xét nhiều yếu tố hơn là chỉ tần suất. Một lỗi hiếm gặp liên quan đến dữ liệu có độ nhạy cảm cao có thể cần được xử lý nhanh hơn một vấn đề định dạng phổ biến nhưng ít tác động. Các yếu tố hữu ích để xếp hạng gồm:
- Tác động đến người dùng: Kết quả có thể gây hại cho một cá nhân, khách hàng hoặc tổ chức không?
- Độ nhạy cảm của dữ liệu: Đầu ra có làm lộ thông tin cá nhân, mật hoặc thuộc diện quản lý không?
- Khả năng khai thác: Một người dùng thông thường có thể tái tạo hành vi này không?
- Phạm vi ảnh hưởng: Vấn đề chỉ ảnh hưởng đến một quy trình hay nhiều hệ thống triển khai?
- Tính dai dẳng: Lỗi có tồn tại sau khi thay đổi mô hình, prompt hoặc cấu hình không?
Các biện pháp khắc phục có thể bao gồm siết chặt ràng buộc prompt, lọc đầu ra, cải thiện kiểm soát truy xuất, hạn chế quyền truy cập, cập nhật mô hình, bổ sung đánh giá của con người hoặc làm rõ thông điệp sản phẩm. Không nên xem một lần kiểm thử lại thành công là bằng chứng cho thấy vấn đề đã được giải quyết. Hãy chạy lại các biến thể xung quanh lỗi ban đầu và thêm trường hợp đó vào bộ kiểm thử hồi quy lâu dài.
Ghi lại dấu vết
Thu thập toàn bộ tương tác, ngữ cảnh liên quan, cấu hình, ghi chú của người đánh giá và hoạt động của công cụ, đồng thời giảm thiểu dữ liệu nhạy cảm.
Xếp hạng rủi ro
Ưu tiên dựa trên tác động, độ nhạy cảm, khả năng khai thác, phạm vi ảnh hưởng và tính dai dẳng thay vì chỉ đếm số lỗi.
Xác minh bản sửa
Chạy lại trường hợp ban đầu và các biến thể lân cận, sau đó ghi nhận liệu biện pháp giảm thiểu có tạo ra thay đổi hành vi mới hay không.
Hướng dẫn tham khảo về Thẩm vấn AI mô tả kiểm thử liên tục, đánh giá kết hợp giữa tự động hóa và con người, ghi nhật ký mạnh mẽ và khắc phục dựa trên rủi ro là những thực hành cốt lõi. Hãy xem các thực hành này như một nhịp vận hành thường xuyên thay vì một cuộc kiểm toán chỉ diễn ra một lần.
Sử dụng ID kiểm thử ổn định, prompt có phiên bản, dấu thời gian và tên người đánh giá. Hồ sơ rõ ràng giúp các nhóm so sánh các phiên bản phát hành và chứng minh rằng các bản sửa đã thực sự được kiểm thử.
Danh sách kiểm tra chiến dịch và tiêu chuẩn thực tiễn
Hãy sử dụng danh sách kiểm tra dưới đây trước khi kết thúc một chiến dịch thẩm vấn. Danh sách này phù hợp cho cả các đợt đánh giá ban đầu và các lần xem xét phát hành định kỳ.
Danh sách kiểm tra mức độ sẵn sàng của chiến dịch:
- Xác định tài sản cần bảo vệ, dữ liệu nhạy cảm, kịch bản người dùng và hồ sơ kẻ tấn công
- Tạo các bộ prompt thông thường, trường hợp biên, đối kháng và hồi quy
- Chạy kiểm thử trong sandbox với dữ liệu đã phê duyệt và quy trình khôi phục
- Ghi lại prompt, đầu ra, ngữ cảnh, cấu hình, công cụ, dấu thời gian và người đánh giá
- Gán mức độ nghiêm trọng, người chịu trách nhiệm, biện pháp khắc phục và trạng thái xác minh cho từng phát hiện
| Tiêu chuẩn | Thực hành khuyến nghị | Dấu hiệu cảnh báo |
|---|---|---|
| Tính liên tục | Kiểm thử ở các phiên bản phát hành lớn và theo lịch định kỳ đối với hệ thống rủi ro cao | Chỉ đánh giá sau khi xảy ra sự cố |
| Độ bao phủ | Kết hợp tự động hóa, red-team do con người thực hiện và đặt câu hỏi có cấu trúc | Các bài kiểm thử chỉ dựa trên một loại prompt |
| Khả năng truy xuất | Lưu giữ bằng chứng có phiên bản và hồ sơ khắc phục | Không thể tái lập kết quả |
| Ưu tiên hóa | Xếp hạng theo tác động và độ nhạy cảm của dữ liệu | Mọi lỗi đều nhận cùng một cách xử lý |
| Tích hợp | Kết nối các phát hiện với hoạt động giám sát, quản trị và CI/CD | Các bản sửa không được kiểm tra trong những lần phát hành sau |
Một chiến dịch sẵn sàng kết thúc khi các phát hiện có mức ưu tiên cao đã được phân công người chịu trách nhiệm, các biện pháp giảm thiểu đã được xác minh và những rủi ro còn lại đã được ghi nhận. Việc giám sát liên tục vẫn rất quan trọng vì hành vi của mô hình có thể thay đổi khi prompt, dữ liệu truy xuất, công cụ, chính sách hoặc phiên bản mô hình thay đổi.
Lưu các lỗi tiêu biểu dưới dạng bài kiểm thử có thể tái sử dụng. Một thư viện hồi quy ngày càng phát triển sẽ ngăn các nhóm phải giải quyết cùng một điểm yếu nhiều lần và giúp việc so sánh các phiên bản phát hành nhanh hơn.
Câu hỏi thường gặp về Thẩm vấn AI
Q: Thẩm vấn AI là gì?
Thẩm vấn AI là hoạt động phòng thủ nhằm chủ động đặt câu hỏi, khai thác phản hồi và kiểm thử sức chịu đựng của các hệ thống AI để tìm ra những lỗi như bịa đặt thông tin, rò rỉ quyền riêng tư, đầu ra không an toàn và vượt qua chỉ dẫn.
Q: Thẩm vấn AI khác red-teaming như thế nào?
Thẩm vấn AI là lĩnh vực rộng hơn về phân tích hành vi của mô hình. Red-teaming là một phương pháp có cấu trúc trong lĩnh vực đó, thường có sự tham gia của các chuyên gia liên chức năng để mô phỏng các mối đe dọa đối kháng.
Q: Thẩm vấn có thể làm hỏng mô hình AI không?
Kiểm thử được thực hiện đúng cách trong sandbox sẽ không làm hỏng mô hình. Hãy sử dụng môi trường được kiểm soát, đầu vào đã phê duyệt, cơ chế giám sát và quy trình khôi phục để các thử nghiệm được tách biệt khỏi hành vi trong môi trường sản xuất.
Q: Các nhóm nên thực hiện những bài kiểm thử này bao lâu một lần?
Việc kiểm thử nên được duy trì liên tục trong suốt vòng đời của mô hình. Hãy lặp lại đánh giá sau các phiên bản phát hành lớn và cân nhắc xem xét định kỳ đối với các ứng dụng rủi ro cao, đặc biệt khi công cụ, prompt, chính sách hoặc nguồn dữ liệu thay đổi.
Không công bố chi tiết khai thác, dấu vết mật hoặc dữ liệu cá nhân trong các báo cáo công khai. Hãy chia sẻ phát hiện thông qua các kênh bảo mật và quản trị đã được tổ chức phê duyệt.