อธิบาย Jailbreak ใน LLM: Jailbreak เปลี่ยนแปลงอะไร และเหตุใดจึงไม่ใช่ Abliteration

ในเดือนกรกฎาคม 2023 นักวิจัยสามคนได้รันพรอมป์ต์อันตราย 32 รายการกับ GPT-4 และ Claude 1.3 ผ่านการโจมตีที่แตกต่างกัน 28 รูปแบบ เทคนิคเดี่ยวที่แข็งแกร่งที่สุด — การนำตระกูลการโจมตีสามตระกูลมาซ้อนกัน — ทะลุผ่านได้ใน 94 เปอร์เซ็นต์ของชุดเมื่อโจมตี GPT-4 และ 81 เปอร์เซ็นต์เมื่อโจมตี Claude 1.3 สิ่งที่ทำให้ได้ครบทั้งชุดไม่ใช่การโจมตีที่ดีกว่า แต่เป็นการเลือก: ผู้โจมตีที่ได้รับอนุญาตให้เลือกวิธีใดจาก 28 วิธีที่ได้ผลดีที่สุดสำหรับแต่ละพรอมป์ต์ ทำให้ทั้ง 32 รายการผ่านได้บนทั้งสองโมเดล ซึ่งบทความวิจัยรายงานว่าเป็น 1.00 อย่างสมบูรณ์ การตีความที่น่าอึดอัดคือ การ jailbreak ไม่ใช่ข้อบกพร่องที่หายไปเมื่อโมเดลฉลาดขึ้นหรือมีพฤติกรรมดีขึ้น มันเป็นคุณสมบัติของพรอมป์ต์ และพรอมป์ต์เป็นของใครก็ตามที่ส่งมันมา สิ่งที่เกิดขึ้นหลังจากคำปฏิเสธสิ้นสุดลง — การเรียกใช้เครื่องมือ การอ่านไฟล์ เอาต์พุตที่ไปตกอยู่ที่ใดที่หนึ่งซึ่งมีการลงมือกับมัน — คือส่วนที่ คลังเหตุการณ์ AIถูกสร้างขึ้นเพื่อบันทึก

กรอบความคิดนั้นควรค่าแก่การอธิบายให้ชัดเจน เพราะคำว่า "jailbreak" ถูกใช้กับหลายสิ่งที่แตกต่างกัน และความแตกต่างเหล่านี้เป็นตัวกำหนดว่ามาตรการบรรเทาใด ๆ จะทำอะไรได้บ้าง บทความนี้ครอบคลุมว่า jailbreak เข้าไปแก้ไขอะไร ตัวเลขที่วัดได้จริง ๆ บอกอะไร ทำไมจึงไม่มีคำตอบแยกรายโมเดลสำหรับคำถามที่ว่า "โมเดลนี้ถูก jailbreak ได้หรือไม่" และจุดที่เทคนิคนี้พ้นจากการเป็นคำถามด้านความปลอดภัยของโมเดลไปเป็นคำถามด้านความปลอดภัยของระบบ

การ jailbreak คือการแก้ไขพรอมต์ ไม่ใช่การแก้ไขโมเดล

โมเดลยังคงเหมือนตอนจัดส่งทุกประการ ไม่มีการฝึกใหม่ ไม่มีการแตะต้องค่าน้ำหนัก และไม่มีการปรับแต่งละเอียด ผู้โจมตีเปลี่ยนคำขอ เพื่อให้การปฏิบัติตามกลายเป็นการต่อเนื่องที่ถูกต้องในบริบทเฉพาะจุด และพฤติกรรมด้านความปลอดภัยที่ถูกฝึกฝนไว้ในโมเดลจะแพ้ให้กับคำสั่งที่ขัดแย้งซึ่งโมเดลก็ถูกฝึกให้ปฏิบัติตามเช่นกัน

ประโยคเดียวนั้นตัดหมวดหมู่ใหญ่ของสิ่งที่ถูกมองว่าเป็นทางแก้ไขออกไปได้เลย คุณไม่สามารถแพตช์มันที่ระดับค่าน้ำหนักได้ — เพราะค่าน้ำหนักไม่ได้มีอะไรผิดปกติ คุณไม่สามารถแจกแจงมันได้ เพราะพื้นที่ของพรอมต์นั้นเปิดกว้าง และคุณไม่สามารถตรวจสอบมันเพียงครั้งเดียวได้ เพราะเทคนิคที่ล้มเหลวในวันนี้ไม่ใช่เทคนิคที่จะถูกนำมาลองในวันพรุ่งนี้ สิ่งที่คุณทำได้คือวัดอัตราหนึ่ง บนชุดพรอมต์ที่กำหนด กับเวอร์ชันโมเดลที่กำหนด แล้วเฝ้าดูอัตรานั้นเคลื่อนไหวเมื่อหนึ่งในสามสิ่งนั้นเปลี่ยนไป

สิ่งที่การทดลอง 32 พรอมต์วัดได้จริง

การศึกษานี้คือ Jailbroken: การฝึกความปลอดภัยของ LLM ล้มเหลวได้อย่างไร? โดย Alexander Wei, Nika Haghtalab และ Jacob Steinhardt เผยแพร่บน arXiv ในเดือนกรกฎาคม 2023 ในชื่อ 2307.02483 ชุดทดสอบของงานนี้มี 32 พรอมต์ที่เป็นอันตราย — ครึ่งหนึ่งมาจากการประเมิน GPT-4 ที่เผยแพร่แล้ว อีกครึ่งดัดแปลงจากงาน red-teaming เกี่ยวกับ Claude ที่เผยแพร่แล้ว — และเกณฑ์วัดผลลัพธ์ก็ตรงไปตรงมา: เคสจะถูกให้คะแนนว่าประสบความสำเร็จเมื่อคำตอบทั้งเป็นอันตรายและตรงประเด็นกับคำขอเดิม สิ่งใดก็ตามที่ชะงัก เบี่ยงเบน หรือตอบคำถามอื่นไม่นับ

ผลลัพธ์มีสองลักษณะที่มีประโยชน์กว่าข้อมูลในแถวใดแถวหนึ่ง ลักษณะแรกคือการที่การโจมตีถ่ายทอดข้ามโมเดลกันได้ไม่สม่ำเสมอเพียงใด AIM role-play ได้ 0.75 เมื่อทดสอบกับ GPT-4 และ 0.00 กับ Claude 1.3 Few-shot JSON ได้ 0.53 และ 0.00 ขณะที่การเข้ารหัส Base64 มีความไม่สม่ำเสมอแบบกลับด้าน — 0.34 บน GPT-4 และ 0.38 บน Claude 1.3 — ส่วนตัวลวงอยู่ที่ 0.44 และ 0.47 เทคนิคที่ผู้ให้บริการได้ฝึกโมเดลให้ต้านทานไว้อย่างชัดเจนจะกลายเป็นศูนย์บนโมเดลนั้น และไม่ได้บอกอะไรเกี่ยวกับโมเดลข้างเคียง

ประการที่สองคือสิ่งที่เกิดขึ้นเมื่อนำกลุ่มเทคนิคต่าง ๆ มารวมกัน การฉีดคำนำหน้ารวมกับการระงับการปฏิเสธรวมกับ Base64 ให้ค่า 0.56 เมื่อทดสอบกับ GPT-4 และ 0.66 เมื่อทดสอบกับ Claude 1.3 การเพิ่มการฉีดสไตล์ทำให้ค่าขึ้นเป็น 0.69 และ 0.84 การเพิ่มการสร้างเนื้อหาเว็บไซต์และข้อจำกัดด้านการจัดรูปแบบทำให้ค่าขึ้นเป็น 0.94 และ 0.81 การซ้อนชั้นคือกลเม็ดทั้งหมด: แต่ละชั้นเป็นสิ่งที่โมเดลถูกฝึกให้ทำ และการรวมกันทำให้ไม่มีตำแหน่งโทเค็นใดที่การปฏิเสธจะเป็นความต่อเนื่องที่เป็นธรรมชาติกว่า

โมเดลในตารางนั้นมีอายุสามปีแล้ว และไม่ใช่สิ่งที่ใคร ๆ กำลังนำไปใช้งานอีกต่อไป ตัวเลขไม่ใช่ประเด็น ประเด็นอยู่ที่รูปแบบ กลไกทุกข้อในตารางยังคงอยู่จริงในโมเดลทุกตัวนับจากนั้นมา เพราะไม่มีกลไกใดเลยเคยเป็นบั๊กใน GPT-4 หรือ Claude 1.3 — กลไกเหล่านี้เป็นผลสืบเนื่องจากการที่การทำตามคำสั่งและการฝึกด้านความปลอดภัยมีปฏิสัมพันธ์กัน

สองวิธีที่การฝึกอบรมด้านความปลอดภัยล้มเหลว

คำอธิบายในเปเปอร์นั้นชัดเจนเรียบง่ายอย่างผิดปกติ และเป็นส่วนที่ควรค่าแก่การจดจำเอาไว้ใช้: มีโหมดความล้มเหลวอยู่สองแบบ และทุกการโจมตีในตารางล้วนเป็นตัวอย่างของแบบใดแบบหนึ่งในสองแบบนั้น

วัตถุประสงค์ที่แข่งขันกันคือสิ่งที่เกิดขึ้นเมื่อความสามารถของโมเดลกับเป้าหมายด้านความปลอดภัยของมันชี้ไปคนละทิศทาง การทำตามคำสั่งเป็นความสามารถอย่างหนึ่ง เมื่อคำขอถูกห่อหุ้มในลักษณะที่การปฏิเสธจะละเมิดคำสั่งที่โมเดลได้รับการฝึกมาอย่างหนักให้เชื่อฟัง โมเดลจะคลี่คลายความขัดแย้งโดยเลือกทำตามคำสั่งนั้น การแทรกคำนำหน้าเป็นรูปแบบขั้นต่ำสุด: บอกโมเดลว่าคำตอบต้องขึ้นต้นด้วย “Absolutely! Here's” และโทเคนแรก ๆ ก็เป็นคำมั่นที่ทำให้การปฏิเสธไม่สอดคล้องกัน การระงับการปฏิเสธโจมตีรอยต่อเดียวกันจากอีกด้าน โดยเพิ่มกฎการจัดรูปแบบที่ห้ามใช้ประโยคซึ่งการปฏิเสธจำเป็นต้องเขียนขึ้นมา

การวางนัยทั่วไปที่ไม่สอดคล้องกัน คือสิ่งที่คุณจะได้เมื่อการฝึกด้านความปลอดภัยครอบคลุมการกระจายอินพุตแบบแคบที่ความสามารถทั่วไปของโมเดลไม่ได้ครอบคลุม โมเดลเรียนรู้ Base64 ระหว่างการฝึกก่อนใช้งาน และสามารถทำตามคำสั่งที่เข้ารหัสได้อย่างสมบูรณ์ การฝึกด้านความปลอดภัยซึ่งส่วนใหญ่พบคำขอในภาษาธรรมชาติ ไม่เคยสอนให้โมเดลตระหนักว่าคำขอที่เข้ารหัสก็ยังคงเป็นคำขอ ความล้มเหลวแบบเดียวกันนี้ปรากฏขึ้นกับการตัดสระออก (disemvowelment), ROT13, leetspeak, การแยกส่วนเพย์โหลด และงานรบกวน: แต่ละอย่างเป็นรูปแบบที่ความสามารถของโมเดลวางนัยทั่วไปไปถึง แต่พฤติกรรมด้านความปลอดภัยไม่ได้วางนัยทั่วไปตามไปด้วย

เมื่อคุณมีสองหมวดหมู่นั้นแล้ว การโจมตีก็เลิกดูเหมือนถุงรวมกลเม็ดสารพัด และเริ่มดูเหมือนสองตระกูลที่มีสาเหตุรากเดียวกัน — ซึ่งก็เป็นเหตุผลว่าทำไมพวกมันจึงประกอบกันได้ดีนัก พรอมต์ที่ยับยั้งการปฏิเสธ และซ่อนเจตนาไว้ในการเข้ารหัส กำลังใช้ประโยชน์จากโหมดความล้มเหลวทั้งสองพร้อมกัน และ 0.94 คือหน้าตาของสิ่งนั้น

ทำไมจึงไม่มีคำตอบแยกตามแต่ละโมเดลสำหรับคำถามที่ว่า “มันถูก jailbreak ได้หรือไม่”

รูปแบบคำค้นหาที่พบบ่อยที่สุดในพื้นที่นี้คือชื่อโมเดลตามด้วยคำว่า jailbreak ซึ่งเป็นหน่วยวิเคราะห์ที่ไม่ถูกต้อง และเหตุผลก็คือตารางด้านบน ความสำเร็จขึ้นอยู่กับอย่างน้อยห้าปัจจัยพร้อมกัน ได้แก่ ความสามารถของโมเดลฐาน การฝึกด้านความปลอดภัยที่โมเดลได้รับและบนการกระจายแบบใด รูปแบบพรอมต์ การตั้งค่าการสุ่มตัวอย่าง และจำนวนครั้งที่ผู้โจมตียินดีจะลงทุน

ประเด็นสุดท้ายนั้นควรได้รับการอธิบายเป็นประโยคแยกต่างหาก อัตราที่วัดจากการลองหนึ่งครั้งต่อพรอมต์กับอัตราที่วัดจาก "best of 28" ไม่ใช่การวัดแบบเดียวกัน และผลลัพธ์เชิงปรับตัวของงานวิจัย — 1.00 บนทั้งสองโมเดล — คือแบบที่สอง ใครก็ตามที่อ้างอัตราการ jailbreak โดยไม่บอกว่าหมายถึงแบบไหน ก็ไม่ได้อ้างอะไรที่ใช้งานได้เลย คำถามเชิงป้องกันที่สมจริงไม่ใช่ "มันถูกเจาะได้ไหม" แต่คือ "ต้องลองกี่ครั้ง และมีอะไรในสแต็กของฉันที่สังเกตเห็นความพยายามเหล่านั้นหรือไม่"

ผลในทางปฏิบัติสองประการมีดังนี้ โมเดลที่ต้านทานชุดพรอมต์ของคุณได้ในวันนี้อาจหยุดต้านทานได้หลังจากการอัปเดตเวอร์ชัน การเปลี่ยนแปลงชั้นความปลอดภัย หรือการเปลี่ยนแปลงการกำหนดค่าฝั่งให้บริการ — ผลลัพธ์จะใช้ได้เฉพาะกับบิลด์ที่คุณทดสอบเท่านั้น ซึ่งเป็นเหตุผลว่าทำไมการทดสอบที่ไม่มีเวอร์ชันและวันที่จึงไม่ถือเป็นผลลัพธ์ และชุดพรอมต์เดียวกันเมื่อรันกับสองโมเดลจะบอกคุณว่าสแต็กของคุณอ่อนแอต่อตัวไหนมากกว่า ไม่ใช่ตัวไหนที่ปลอดภัย

สิ่งที่การ jailbreak ไม่ใช่ คือ abliteration

สองสิ่งนี้มักถูกทำให้ปะปนกันอยู่ตลอด เพราะทั้งคู่จบลงด้วยโมเดลที่สร้างผลลัพธ์ซึ่งมันถูกฝึกมาไม่ให้สร้าง ทั้งสองไม่ใช่การแก้ไขแบบเดียวกัน และความแตกต่างนี้คือความแตกต่างระหว่างกลไกควบคุมที่คุณเพิ่มเข้าไปได้ กับคุณสมบัติที่คุณเพิ่มเข้าไปไม่ได้

• Jailbreak — เป็นการแก้ไขในชั้นพรอมต์ น้ำหนักไม่เปลี่ยนแปลง ทิศทางการปฏิเสธยังคงอยู่ในโมเดล คำขอเพียงถูกจัดเรียงใหม่ให้พฤติกรรมอื่นมีลำดับความสำคัญเหนือกว่า หากย้อนพรอมต์กลับ พฤติกรรมก็จะย้อนกลับไปด้วย

• Abliteration — การแก้ไขที่ชั้นน้ำหนัก ทิศทางการปฏิเสธถูกระบุ — โดยปกติเป็นทิศทางในปริภูมิแอ็กติเวชัน — และฉายออกจากน้ำหนักของโมเดล เพื่อให้โมเดลไม่สร้างการปฏิเสธต่อคำขอประเภทนั้นอีกเลย เป็นการเปลี่ยนแปลงถาวรต่ออาร์ติแฟกต์ และเป็นเหตุผลว่าทำไมเช็กพอยต์ที่ผ่าน abliteration จึงทำงานแตกต่างจากโมเดลฐานเดียวกันเมื่อใช้พรอมป์ต์ที่ชาญฉลาด กลไกของการแก้ไขนั้นอธิบายไว้ในคู่มือของเราเกี่ยวกับ abliteration.

ความแตกต่างเชิงปฏิบัติการสำคัญกว่าคำศัพท์มาก jailbreak คือเหตุการณ์ขณะรันไทม์: มันมาพร้อมกับคำขอ และสามารถนับ จำกัดอัตรา กรอง และบันทึกได้เหมือนคำขออื่น ๆ โมเดลแบบ abliterated คือเหตุการณ์ในห่วงโซ่อุปทาน: การควบคุมถูกลบออกไปแล้วก่อนที่คุณจะได้รับมัน และการเฝ้าติดตามในชั้นพรอมป์ต์ไม่ว่าจะมากเพียงใดก็ไม่สามารถนำมันกลับมาได้ หากแบบจำลองภัยคุกคามของคุณคือ “มีคนจะพยายามโน้มน้าวโมเดล” คุณอยู่ในประเภทแรก หากเป็น “มีคนจะส่งโมเดลที่ลบการปฏิเสธออกแล้วมาให้ฉัน” คุณอยู่ในประเภทที่สอง และการควบคุมที่แท้จริงเพียงอย่างเดียวคือการตรวจสอบแหล่งที่มา — การรู้ว่าปลายทางกำลังให้บริการเช็กพอยต์ใดอยู่จริง

การเจลเบรกก็ไม่ใช่พรอมต์อินเจกชันเช่นกัน

คำที่สามที่มักถูกนำมาปะปนด้วยคือพรอมต์อินเจกชัน และคำถามที่ใช้แยกแยะคือผู้โจมตีคือใคร การเจลเบรกมาจากผู้ใช้ ซึ่งพยายามทำให้ได้เนื้อหาที่โมเดลถูกฝึกให้ไม่เปิดเผย พรอมต์อินเจกชันมาจาก เนื้อหา — เอกสารที่ถูกดึงมา หน้าเว็บ หรือผลลัพธ์จากเครื่องมือ — ที่มีคำสั่งซึ่งนักพัฒนาไม่ได้เขียนไว้ และมันได้ผลไม่ว่าผู้ใช้จะเป็นศัตรูหรือไม่ โมเดลเดียวกันอาจต้านทานอย่างหนึ่งได้และเปิดกว้างสุดขีดต่ออีกอย่างหนึ่ง เพราะทั้งสองถูกสกัดกั้นในจุดที่ต่างกัน: เจลเบรกที่อินพุตและเอาต์พุตของโมเดล ส่วนอินเจกชันที่ขอบเขตความไว้วางใจระหว่างข้อมูลกับคำสั่ง

อะไรที่ลดอัตราได้จริง

ไม่มีสิ่งใดในที่นี้เป็นการรับประกัน และข้อกล่าวอ้างใด ๆ ที่บอกเป็นอย่างอื่นก็เป็นเพียงการขายของ สิ่งที่ตามมาคือชุดมาตรการควบคุมที่เปลี่ยนตัวเลข โดยเรียงตามผลตอบแทนที่ได้เมื่อเทียบกับความพยายามที่ลงไป

• สมมติว่าชั้นพรอมป์ตพังทลายลง การควบคุมใด ๆ ที่อาศัยการที่โมเดลจะปฏิเสธคำขอนั้น อยู่ห่างจากศูนย์เพียงผู้โจมตีที่ปรับตัวได้หนึ่งราย ออกแบบเสมือนว่าคำขอจะผ่านเข้ามาได้ในที่สุด และวางการควบคุมไว้ตรงจุดที่ความเสียหายจะเกิดขึ้น

• จำกัดสิ่งที่การเจลเบรกที่สำเร็จสามารถเข้าถึงได้ ขอบเขตความเสียหายของแอสซิสแทนที่ถูกเจลเบรกนั้นคือสิ่งที่เครื่องมือ ข้อมูลรับรอง และขอบเขตการดึงข้อมูลของมันอนุญาต หลักสิทธิ์น้อยที่สุด (least privilege) สำหรับเครื่องมือ และการกำหนดขอบเขตตามผู้เช่า (per-tenant scoping) สำหรับการดึงข้อมูล ช่วยลดคุณค่าของการเจลเบรกที่สำเร็จได้อย่างน่าเชื่อถือกว่าตัวกรองพรอมต์ใด ๆ มาก

• ตัดสินที่ผลลัพธ์ ไม่ใช่ที่พรอมต์ตัวจำแนกฝั่งเอาต์พุตจับกลุ่มที่คุณไม่เคยเห็นได้ เพราะมันดูที่สิ่งที่ถูกผลิตออกมาจริง ๆ แทนที่จะดูว่าถูกขอมาอย่างไร ทั้งยังเป็นชั้นเดียวที่ยังทำงานได้เมื่อรูปแบบอินพุตเป็นของใหม่ ซึ่งตามโหมดความล้มเหลวแบบการวางนัยทั่วไปที่คลาดเคลื่อนแล้ว นั่นก็คือเกือบตลอดเวลา

• ให้ถือว่า system prompt เป็นค่าคอนฟิกูเรชัน ไม่ใช่ขอบเขตความปลอดภัย มันเป็นข้อความในหน้าต่างบริบทเดียวกับการโจมตี มันเพิ่มต้นทุนของความพยายามโจมตี แต่ไม่ได้หยุดการโจมตี

• ทำให้ความพยายามเหล่านั้นมองเห็นได้ ข้อได้เปรียบเพียงอย่างเดียวที่ผู้ป้องกันมีเหนือผู้โจมตีแบบปรับตัวได้ คือการโจมตีมักถูกทำซ้ำ การจำกัดอัตรา การตรวจจับการทำซ้ำ และการบันทึกข้อมูล ทำให้การค้นหาที่มีความพยายาม 28 ครั้งกลายเป็นเหตุการณ์ที่คุณมองเห็นได้ แทนที่จะเป็น 28 คำขอที่แต่ละรายการดูเหมือนไม่มีปัญหาเมื่อพิจารณาแยกกัน

• ทดสอบซ้ำทุกครั้งที่มีการเปลี่ยนแปลงโมเดล การปักหมุดเวอร์ชันพร้อมชุดพรอมป์ต์แบบคงที่คือสิ่งที่เปลี่ยน "เราเคยทดสอบมันครั้งหนึ่ง" ให้เป็นตัวเลขที่คุณสามารถนำไปเปรียบเทียบได้ หากไม่มีการปักหมุด การเปรียบเทียบก็ไม่มีความหมาย

วิธีวัดเป้าหมายของคุณเอง

หากเป้าหมายคือตัวเลขที่คุณนำไปใช้ดำเนินการได้ ให้กำหนดตัวแปรสามตัวที่บทความวิจัยกำหนดไว้ให้คงที่ ได้แก่ ชุดพรอมต์ เวอร์ชันของโมเดล และจำนวนครั้งที่ลอง ใช้ชุดพรอมต์ที่ครอบคลุมโหมดความล้มเหลวทั้งสองแบบ — คำสั่งที่ทำให้การปฏิเสธเป็นเรื่องน่าอึดอัด และการเข้ารหัสที่ซ่อนคำขอ — เพราะชุดที่สร้างจากแบบเดียวจะทำให้โมเดลที่อ่อนต่ออีกแบบดูดีเกินจริง ให้คะแนนแบบอนุรักษ์นิยม: เป็นอันตราย และตรงประเด็น ไม่ใช่แค่น้ำเสียงไม่ตรง และรายงานผลลัพธ์เป็นอัตราเทียบกับจำนวนครั้งที่ระบุไว้ ไม่ใช่คำตอบใช่หรือไม่ใช่

เมื่อมีโมเดลตัวเลือกหลายตัวอยู่ในเกม การเปรียบเทียบจะได้ผลก็ต่อเมื่อมีชุดพรอมป์เดียวกันรันกับโมเดลแต่ละตัว และนั่นคือจุดเดียวที่ระบบเบื้องหลังสำคัญกว่าระเบียบวิธี การรันการประเมินหนึ่งครั้งกับโมเดลที่เรากำหนดเส้นทางให้ช่วยตัดงานทำสัญญากับผู้ขายแต่ละรายและงานฝั่งไคลเอนต์ออกจากการทดลองนี้ ราคาตามรายการของผู้ให้บริการถูกส่งผ่านโดยไม่บวกกำไรเพิ่ม ดังนั้นการรันจึงมีค่าใช้จ่ายเท่าที่ผู้ให้บริการเรียกเก็บและไม่มีมากกว่านั้น สิ่งที่การประเมินวัดคือพฤติกรรมของโมเดล ไม่ใช่ของเรา — การกำหนดเส้นทางเปลี่ยนว่าโมเดลใดตอบ และไม่ได้ทำให้โมเดลใดปฏิเสธมากขึ้น

จุดที่บันทึกกลับมาดำเนินต่อ

อัตราความสำเร็จที่วัดได้บอกคุณว่าชั้นพรอมป์ต์ถูกผลักให้ล้มได้ยากเพียงใด แต่มันไม่ได้บอกคุณว่าเกิดอะไรขึ้นเมื่อมีคนผลักมันจนล้มในการใช้งานจริง และคำถามข้อที่สองนี่เองที่ตัดสินว่าอัตรานั้นสำคัญหรือไม่ jailbreak ที่สร้างย่อหน้าหยาบคายเป็นปัญหาด้านการกลั่นกรองเนื้อหา jailbreak ที่สร้างการเรียกเครื่องมือ (tool call) คือเหตุการณ์ผิดปกติ และความแตกต่างนั้นอยู่ที่ระบบปล่อยให้เอาต์พุตไปถึงอะไรได้ทั้งหมด

คลังข้อมูลนั้นคือบันทึกภาคสนาม: เอเจนต์ทำอะไรจริงบ้าง โดยมีแหล่งอ้างอิงสำหรับแต่ละรายการ และคำตัดสินว่ามีใครได้รับอันตรายหรือไม่ เมื่ออ่านเทียบกับการวัด jailbreak มันตอบคำถามที่การวัดนั้นตอบไม่ได้ — ว่าขอบเขตที่พรอมป์ต์ข้ามไปนั้นเป็นขอบเขตที่สิ่งใดปลายน้ำต้องพึ่งพาหรือไม่ หากใช่ jailbreak นั้นก็เป็นข้อค้นพบด้านความปลอดภัย และการควบคุมนั้นควรอยู่ในสิทธิ์ของเครื่องมือ หากไม่ใช่ jailbreak นั้นก็เป็นผลลัพธ์ด้านเนื้อหา และสิ่งที่ซื่อสัตย์คือการจัดประเภทมันเป็นเช่นนั้น แทนที่จะพองมันให้กลายเป็นช่องโหว่

บันทึกส่งท้ายคือข้อที่หลักฐานสนับสนุน การเจาะข้อจำกัด (jailbreaking) จะไม่ถูกแก้ให้หมดไปด้วยโมเดลที่ดีกว่า เพราะรูปแบบความล้มเหลวเหล่านั้นเป็นเชิงโครงสร้าง: การทำตามคำสั่งเป็นความสามารถอย่างหนึ่ง และการฝึกด้านความปลอดภัยเป็นความสามารถที่แคบกว่า และช่องว่างระหว่างสองสิ่งนี้คือที่ที่ทุกการโจมตีในบทความนี้อยู่อาศัย สิ่งที่แก้ได้คือผลลัพธ์ — ด้วยการทำให้แน่ใจว่าโมเดลที่เลิกปฏิเสธแล้วก็ยังทำอะไรได้ไม่มากนัก