Giải thích về Jailbreak LLM: Một jailbreak thay đổi điều gì và tại sao nó không phải là abliteration

Vào tháng 7 năm 2023, ba nhà nghiên cứu đã chạy 32 lời nhắc có hại nhắm vào GPT-4 và Claude 1.3 thông qua 28 cuộc tấn công khác nhau. Kỹ thuật đơn lẻ mạnh nhất — ba nhóm tấn công xếp chồng lên nhau — đã xuyên qua được 94 phần trăm bộ này đối với GPT-4 và 81 phần trăm đối với Claude 1.3. Điều làm nên kết quả trọn vẹn cho bộ này không phải một cuộc tấn công tốt hơn mà là một lựa chọn: một đối thủ được phép chọn bất kỳ cuộc tấn công nào trong 28 cuộc tấn công hiệu quả nhất cho từng lời nhắc đã đưa cả 32 lời nhắc xuyên qua trên cả hai mô hình, điều mà bài báo báo cáo là đúng 1,00. Cách diễn giải khó chịu là jailbreak không phải một khiếm khuyết biến mất khi mô hình trở nên thông minh hơn hoặc cư xử tốt hơn. Nó là một thuộc tính của lời nhắc, và lời nhắc thuộc về bất kỳ ai gửi nó. Điều xảy ra sau khi sự từ chối chấm dứt — lệnh gọi công cụ, việc đọc tệp, đầu ra rơi vào một nơi nào đó có thể hành động dựa trên nó — là phần kho lưu trữ sự cố AI được xây dựng để ghi lại.

Việc định khung đó đáng được nói cho thật chính xác, bởi "jailbreak" được dùng để chỉ nhiều thứ khác nhau, và chính những khác biệt ấy quyết định xem một biện pháp giảm thiểu có thể làm được gì. Bài viết này đề cập tới việc một jailbreak chỉnh sửa những gì, các con số đo được thực sự nói lên điều gì, vì sao không có câu trả lời riêng cho từng mô hình cho câu hỏi "nó có bị jailbreak được không", và ở đâu thì kỹ thuật này không còn là câu hỏi về an toàn mô hình nữa mà trở thành câu hỏi về an ninh hệ thống.

Jailbreak là một chỉnh sửa đối với prompt, không phải đối với mô hình.

Mô hình vẫn giữ nguyên đúng như khi xuất xưởng. Không có gì được huấn luyện lại, không trọng số nào bị động đến, không áp dụng tinh chỉnh nào. Kẻ tấn công thay đổi yêu cầu để việc tuân thủ trở thành phần tiếp nối đúng cục bộ, và hành vi an toàn đã được huấn luyện vào mô hình thua một chỉ dẫn cạnh tranh mà nó cũng được huấn luyện để tuân theo.

Câu duy nhất đó loại trừ một nhóm lớn các bản sửa được cho là khả thi. Bạn không thể vá nó ở phần trọng số — không có gì sai với trọng số cả. Bạn không thể liệt kê nó, vì không gian các prompt là mở. Và bạn không thể kiểm tra nó một lần, vì kỹ thuật thất bại hôm nay không phải là kỹ thuật sẽ được thử vào ngày mai. Điều bạn có thể làm là đo một tỷ lệ, trên một tập prompt cố định, đối với một phiên bản mô hình cố định, rồi theo dõi tỷ lệ đó thay đổi khi bất kỳ yếu tố nào trong ba yếu tố đó thay đổi.

Thí nghiệm 32 lời nhắc thực sự đã đo lường điều gì

Nghiên cứu này là Jailbroken: How Does LLM Safety Training Fail? của Alexander Wei, Nika Haghtalab và Jacob Steinhardt, được đăng lên arXiv vào tháng 7 năm 2023 với mã 2307.02483. Tập kiểm thử của nó gồm 32 lời nhắc độc hại — một nửa lấy từ một đánh giá GPT-4 đã công bố, một nửa được chuyển thể từ công trình red-teaming đã công bố về Claude — và thước đo kết quả của nó rất thẳng thắn: một trường hợp được tính là thành công khi câu trả lời vừa độc hại vừa đúng chủ đề so với yêu cầu ban đầu. Bất cứ điều gì làm trì hoãn, né tránh hoặc trả lời một câu hỏi khác đều không được tính.

Hai đặc tính của kết quả hữu ích hơn bất kỳ dòng riêng lẻ nào. Đầu tiên là mức độ không đồng đều khi các đòn tấn công chuyển giao giữa các mô hình. AIM role-play đạt 0,75 trước GPT-4 và 0,00 trước Claude 1.3. Few-shot JSON đạt 0,53 và 0,00. Trong khi đó, mã hóa Base64 là kiểu không đồng đều ngược lại — 0,34 trên GPT-4 và 0,38 trên Claude 1.3 — còn các yếu tố gây nhiễu đạt 0,44 và 0,47. Một kỹ thuật mà một nhà cung cấp đã rõ ràng huấn luyện để chống lại sẽ được thể hiện là số 0 trên mô hình đó và không cho biết gì về mô hình bên cạnh.

Điều thứ hai là điều xảy ra khi các nhóm được kết hợp. Chèn tiền tố cộng với triệt tiêu từ chối cộng với Base64 cho kết quả 0,56 đối với GPT-4 và 0,66 đối với Claude 1.3. Thêm chèn phong cách đưa nó lên 0,69 và 0,84. Thêm tạo nội dung trang web và các ràng buộc định dạng đưa nó lên 0,94 và 0,81. Xếp chồng chính là toàn bộ mẹo: mỗi lớp là một việc mô hình đã được huấn luyện để làm, và sự kết hợp không để lại vị trí token nào mà ở đó việc từ chối là phần tiếp nối tự nhiên hơn.

Các mô hình trong bảng đó đã ba năm tuổi và không còn là thứ mà bất kỳ ai đang triển khai nữa. Những con số không phải là điểm mấu chốt; hình thái mới là. Mọi cơ chế trong bảng vẫn còn hiện diện trong mọi mô hình kể từ đó, bởi vì không cái nào trong số chúng từng là lỗi trong GPT-4 hay Claude 1.3 — chúng là hệ quả của cách mà việc tuân theo chỉ dẫn và huấn luyện an toàn tương tác với nhau.

Hai cách huấn luyện an toàn thất bại

Cách lý giải của bài báo sạch một cách lạ thường, và đó chính là phần đáng để mang theo bên mình: có hai kiểu thất bại, và mọi cuộc tấn công trong bảng đều là một trường hợp của một trong hai kiểu đó.

Mục tiêu xung đột là điều xảy ra khi các năng lực của mô hình và mục tiêu an toàn của nó chỉ về những hướng khác nhau. Tuân theo chỉ dẫn là một năng lực. Khi yêu cầu được bọc theo cách mà việc từ chối sẽ vi phạm một chỉ dẫn mà mô hình được huấn luyện mạnh mẽ để tuân theo, mô hình giải quyết xung đột theo hướng ưu tiên chỉ dẫn. Tiêm tiền tố là phiên bản tối giản: hãy bảo mô hình rằng câu trả lời của nó phải bắt đầu bằng "Absolutely! Here's", và những token đầu tiên đã là một cam kết khiến việc từ chối trở nên vô lý. Tấn công triệt tiêu từ chối nhắm vào cùng điểm nối đó từ phía ngược lại, bằng cách thêm các quy tắc định dạng cấm câu mà một lời từ chối sẽ buộc phải được viết bằng.

Tổng quát hóa không khớp là điều xảy ra khi huấn luyện an toàn chỉ bao phủ một phân phối đầu vào hẹp mà năng lực tổng quát của mô hình không bao phủ. Mô hình đã học Base64 trong quá trình tiền huấn luyện và có thể tuân theo một chỉ dẫn được mã hóa hoàn toàn tốt. Huấn luyện an toàn, vốn chủ yếu thấy các yêu cầu bằng ngôn ngữ tự nhiên, chưa bao giờ dạy nó nhận ra rằng một yêu cầu được mã hóa vẫn là một yêu cầu. Cùng thất bại đó xuất hiện với việc loại bỏ nguyên âm, ROT13, leetspeak, tách payload và các tác vụ gây nhiễu: mỗi thứ là một định dạng mà năng lực tổng quát hóa tới còn hành vi an toàn thì không.

Khi bạn đã có hai loại đó, các cuộc tấn công không còn trông giống một mớ mẹo vặt hỗn tạp nữa mà bắt đầu trông giống hai nhóm có chung một nguyên nhân gốc — đó cũng là lý do chúng kết hợp với nhau tốt đến vậy. Một prompt chặn việc từ chối và che giấu ý định của nó trong một lớp mã hóa là đang khai thác đồng thời cả hai kiểu lỗi, và 0.94 chính là hình ảnh của điều đó.

Tại sao lại không có câu trả lời riêng theo từng mô hình cho câu hỏi “nó có thể bị jailbreak không?”

Dạng truy vấn phổ biến nhất trong lĩnh vực này là tên mô hình theo sau là từ jailbreak. Đó là đơn vị phân tích sai, và lý do nằm ở bảng trên. Thành công phụ thuộc vào ít nhất năm yếu tố cùng lúc: năng lực của mô hình gốc, nó đã nhận huấn luyện an toàn gì và trên phân phối nào, định dạng prompt, cài đặt lấy mẫu, và số lần thử mà kẻ tấn công sẵn sàng bỏ ra.

Điều cuối cùng đó xứng đáng có một câu riêng. Tỷ lệ được đo với một lần thử cho mỗi prompt và tỷ lệ được đo theo kiểu "best of 28" không phải là cùng một phép đo, và kết quả thích ứng của bài báo — 1.00 trên cả hai mô hình — thuộc loại thứ hai. Bất kỳ ai trích dẫn tỷ lệ jailbreak mà không nói rõ là loại nào thì đã trích dẫn một thứ không dùng được. Câu hỏi phòng thủ thực tế không phải là "liệu nó có thể bị phá không" mà là "cần bao nhiêu lần thử, và có thứ gì trong stack của tôi nhận ra những lần thử đó không".

Có hai hệ quả thực tiễn. Một mô hình hôm nay chống lại bộ prompt của bạn có thể ngừng chống lại sau khi tăng phiên bản, thay đổi lớp an toàn hoặc thay đổi cấu hình phía phục vụ — kết quả chỉ có giá trị với bản build bạn đã kiểm thử, đó là lý do vì sao một bài kiểm thử không có phiên bản và ngày tháng thì không phải là kết quả. Và cùng một bộ prompt chạy trên hai mô hình sẽ cho bạn biết stack của bạn mềm hơn với mô hình nào, chứ không phải mô hình nào an toàn.

Jailbreak không phải là gì: abliteration

Hai thứ này liên tục bị đánh đồng vì cả hai đều kết thúc bằng việc một mô hình tạo ra đầu ra mà nó được huấn luyện để không tạo ra. Chúng không phải là cùng một chỉnh sửa, và sự khác biệt chính là sự khác biệt giữa một cơ chế kiểm soát bạn có thể thêm vào và một thuộc tính bạn không thể có.

• Jailbreak — một chỉnh sửa ở tầng prompt. Trọng số không thay đổi. Hướng từ chối vẫn còn trong mô hình; chỉ là yêu cầu đã được sắp xếp để các hành vi khác lấn át nó. Hoàn nguyên prompt thì hành vi cũng hoàn nguyên theo.

• Abliteration — một chỉnh sửa ở lớp trọng số. Hướng từ chối được xác định — thường là một hướng trong không gian kích hoạt — và được chiếu ra khỏi trọng số của mô hình, để mô hình không còn tạo ra lời từ chối đối với loại yêu cầu đó nữa. Đây là một thay đổi vĩnh viễn đối với artifact, và đó là lý do vì sao một checkpoint đã trải qua abliteration lại hành xử khác với cùng mô hình nền tảng chỉ với một prompt khéo léo. Cơ chế của chỉnh sửa đó được trình bày trong hướng dẫn của chúng tôi về abliteration.

Sự khác biệt về vận hành quan trọng hơn thuật ngữ. Jailbreak là một sự kiện lúc chạy: nó đến cùng một yêu cầu và có thể được đếm, giới hạn tần suất, lọc và ghi log như bất kỳ yêu cầu nào khác. Một mô hình abliterated là một sự kiện chuỗi cung ứng: cơ chế kiểm soát đã bị loại bỏ trước khi bạn nhận được nó, và không lượng giám sát lớp prompt nào có thể khôi phục nó. Nếu mô hình mối đe dọa của bạn là “ai đó sẽ cố thuyết phục mô hình”, bạn thuộc nhóm thứ nhất. Nếu là “ai đó sẽ gửi cho tôi một mô hình đã bị gỡ bỏ cơ chế từ chối”, bạn thuộc nhóm thứ hai, và biện pháp kiểm soát thực sự duy nhất là nguồn gốc — biết endpoint thực sự đang phục vụ checkpoint nào.

Jailbreak cũng không phải là prompt injection.

Thuật ngữ thứ ba bị trộn vào là prompt injection, và câu hỏi phân biệt là kẻ tấn công là ai. Một jailbreak đến từ người dùng, người đang cố lấy nội dung mà mô hình được huấn luyện để không tiết lộ. Prompt injection đến từ nội dung — một tài liệu được truy xuất, một trang web, một kết quả công cụ — mang theo các chỉ dẫn mà nhà phát triển chưa từng viết, và nó hoạt động bất kể người dùng có thù địch hay không. Cùng một mô hình có thể miễn nhiễm với loại này và rộng mở với loại kia, vì chúng bị vô hiệu hóa ở những nơi khác nhau: jailbreak ở đầu vào và đầu ra của mô hình, injection ở ranh giới tin cậy giữa dữ liệu và chỉ dẫn.

Điều gì thực sự làm giảm tỷ lệ này

Ở đây không có gì là bảo đảm, và bất kỳ tuyên bố nào ngược lại đều là chiêu bán hàng. Phần tiếp theo là tập hợp các biện pháp kiểm soát làm thay đổi các con số, được sắp xếp theo mức độ chúng đem lại so với công sức bỏ ra.

• Giả sử lớp prompt sẽ sụp đổ.Mọi cơ chế kiểm soát dựa vào việc mô hình từ chối đều chỉ cách con số 0 đúng một kẻ tấn công thích ứng. Hãy thiết kế như thể yêu cầu rồi sẽ lọt qua, và đặt cơ chế kiểm soát tại chính nơi tác hại sẽ xảy ra.

• Hạn chế những gì một cuộc jailbreak thành công có thể tiếp cận. Bán kính ảnh hưởng của một trợ lý bị jailbreak đúng bằng phạm vi mà các công cụ, thông tin xác thực và phạm vi truy xuất của nó cho phép. Đặc quyền tối thiểu trên các công cụ và phạm vi truy xuất theo từng tenant giúp giảm giá trị của một cuộc jailbreak thành công một cách đáng tin cậy hơn nhiều so với bất kỳ bộ lọc prompt nào.

• Đánh giá đầu ra, không phải lời nhắc.Các bộ phân loại phía đầu ra bắt được những nhóm mà bạn chưa từng thấy, vì chúng xem xét thứ thực sự được tạo ra chứ không phải cách nó được yêu cầu. Chúng cũng là lớp duy nhất vẫn hoạt động khi định dạng đầu vào mới lạ — mà theo chế độ lỗi khái quát hóa không khớp, phần lớn thời gian là như vậy.

• Hãy coi lời nhắc hệ thống là một giá trị cấu hình, không phải ranh giới bảo mật. Nó là văn bản nằm trong cùng cửa sổ ngữ cảnh với cuộc tấn công. Nó làm tăng chi phí của một lần thử; nó không ngăn chặn được một lần thử.

• Hãy làm cho các nỗ lực trở nên rõ ràng. Lợi thế duy nhất mà người phòng thủ có được trước kẻ tấn công thích ứng là cuộc tấn công thường được lặp lại. Giới hạn tốc độ, phát hiện lặp lại và ghi nhật ký biến một cuộc tìm kiếm gồm 28 lần thử thành một sự kiện mà bạn có thể nhìn thấy, thay vì 28 yêu cầu mà riêng lẻ mỗi cái đều có vẻ ổn.

• Kiểm thử lại mỗi khi thay đổi mô hình. Việc ghim phiên bản cùng một bộ lời nhắc cố định chính là thứ biến "chúng tôi đã kiểm thử một lần" thành một con số bạn có thể so sánh. Nếu không có ghim phiên bản, việc so sánh trở nên vô nghĩa.

Cách tự đo mục tiêu của chính bạn

Nếu mục tiêu là một con số bạn có thể dựa vào để hành động, hãy cố định ba biến mà bài báo đã cố định: bộ lời nhắc, phiên bản mô hình và số lần thử. Hãy dùng một bộ lời nhắc bao gồm cả hai kiểu thất bại — các chỉ dẫn khiến việc từ chối trở nên khó xử, và các cách mã hóa che giấu yêu cầu — vì một bộ chỉ gồm một kiểu sẽ tô hồng một mô hình vốn yếu trước kiểu còn lại. Chấm điểm một cách thận trọng: có hại và đúng chủ đề, chứ không chỉ là lệch tông. Và báo cáo kết quả dưới dạng tỷ lệ trên một số lần thử đã nêu, không bao giờ dưới dạng có hoặc không.

Khi có nhiều mô hình ứng viên cùng tham gia, phép so sánh chỉ có ý nghĩa nếu cùng một bộ lời nhắc được chạy trên từng mô hình, và đó là điểm duy nhất mà phần kết nối hạ tầng quan trọng hơn cả phương pháp luận. Chạy một đợt đánh giá trên các mô hình mà chúng tôi định tuyến sẽ loại bỏ công việc hợp đồng và khách hàng theo từng nhà cung cấp khỏi bài toán; giá niêm yết của nhà cung cấp được chuyển thẳng qua với mức đánh dấu bằng không, nên lượt chạy chỉ tốn đúng mức nhà cung cấp thu và không hơn. Điều mà đánh giá đo lường là hành vi của mô hình, không phải của chúng tôi — định tuyến thay đổi mô hình nào trả lời, và nó không khiến bất kỳ mô hình nào từ chối nhiều hơn.

Nơi bản ghi bắt đầu

Tỷ lệ thành công đo được cho bạn biết lớp prompt khó bị đẩy đổ đến mức nào. Nó không cho bạn biết điều gì đã xảy ra khi có người đẩy đổ nó trên môi trường production, và chính câu hỏi thứ hai đó mới quyết định liệu tỷ lệ này có ý nghĩa hay không. Một jailbreak tạo ra một đoạn văn thô lỗ chỉ là vấn đề kiểm duyệt nội dung. Một jailbreak tạo ra một lệnh gọi công cụ lại là một sự cố, và sự khác biệt nằm hoàn toàn ở việc hệ thống đã để đầu ra đó chạm tới đâu.

Kho lưu trữ đó chính là hồ sơ thực địa: những gì các tác nhân thực sự đã làm, kèm nguồn cho từng mục và phán quyết về việc liệu có ai bị tổn hại hay không. Khi đọc đối chiếu với một phép đo jailbreak, nó trả lời câu hỏi mà phép đo không thể trả lời — liệu ranh giới mà một prompt đã vượt qua có phải là ranh giới mà bất kỳ thứ gì ở hạ nguồn phụ thuộc vào hay không. Nếu đúng là vậy, thì jailbreak là một phát hiện bảo mật và biện pháp kiểm soát thuộc về quyền của công cụ. Nếu không phải, thì jailbreak là một kết quả nội dung, và cách làm trung thực là ghi nhận nó đúng như vậy thay vì thổi phồng nó thành một lỗ hổng.

Lời kết là điều mà bằng chứng ủng hộ. Jailbreaking sẽ không được giải quyết bằng một mô hình tốt hơn, vì các kiểu thất bại mang tính cấu trúc: tuân theo chỉ dẫn là một năng lực còn huấn luyện an toàn là một năng lực hẹp hơn, và khoảng cách giữa hai điều đó chính là nơi mọi cuộc tấn công trong bài viết này tồn tại. Điều có thể giải quyết là hệ quả — bằng cách bảo đảm rằng một mô hình đã ngừng từ chối vẫn không thể làm được quá nhiều.