อธิบาย AI Red Teaming: Red Team ทดสอบอะไร และมีอะไรเหลืออยู่เบื้องหลัง

โครงการ red teaming ด้าน AI ส่วนใหญ่ถูกตัดสินด้วยสิ่งส่งมอบที่ผิด การทำงานหนึ่งสัปดาห์สร้างสไลด์ชุดหนึ่ง สไลด์นั้นบอกว่าผู้ช่วยสามารถถูกโน้มน้าวให้เขียนอีเมลฟิชชิงได้ และหลังจากนั้นก็ไม่มีใครบอกได้ว่าพฤติกรรมนั้นทำซ้ำได้หรือไม่ ร้ายแรงแค่ไหน หรือการควบคุมใดจะหยุดมันไว้ได้ สาขานี้มีผลลัพธ์ที่แท้จริง และผลลัพธ์นั้นไม่ใช่สไลด์: แต่เป็นชุดข้อค้นพบที่ยังคงอยู่เมื่อรันซ้ำ โดยแต่ละข้อผูกกับขอบเขตที่ถูกข้ามและหลักฐานที่ข้ามขอบเขตนั้น นั่นก็เป็นรูปแบบของบันทึกที่the AI incident archiveเก็บไว้เช่นกัน — 400 รายการ ครอบคลุมตั้งแต่ธันวาคม 2024 ถึงตุลาคม 2026 ดึงมาจากแหล่งที่แตกต่างกัน 743 แหล่ง และมีคำตัดสินสำหรับแต่ละรายการว่ามีใครได้รับอันตรายจริงหรือไม่

ความสับสนนี้เป็นเรื่องที่เข้าใจได้ เพราะ "red teaming" ถูกใช้กับงานสองประเภทที่แทบไม่มีอะไรเหมือนกันนอกจากคำศัพท์ นี่คือคู่มือสำหรับทั้งสองงาน สำหรับหลักฐานที่แต่ละงานควรสร้างขึ้น และสำหรับสี่จุดที่ AI red teaming แตกต่างอย่างแท้จริงจากเวอร์ชันที่ใช้กับเครือข่าย ซึ่งทีมความปลอดภัยส่วนใหญ่รู้วิธีดำเนินการอยู่แล้ว

คำถามเชิงกรอบโครง: ใครเป็นเจ้าของการทดสอบ

ก่อนจะถึงขอบเขต คำถามคือใครเป็นผู้ดำเนินการฝึกซ้อม และดำเนินการกับอะไร Microsoft เผยแพร่หนึ่งในจุดยืนสาธารณะที่สมบูรณ์กว่าของตนในเรื่องนี้ และคุ้มค่าที่จะอ่านในฐานะแผนที่มากกว่าหน้าผลิตภัณฑ์ ศูนย์ AI Red Team ของบริษัทแยก แนวคิดของการทำ red teaming ด้าน AI ออกจาก วิธีปฏิบัติ แล้วจัดเรียงเนื้อหาการปฏิบัติตามลำดับซึ่งตัวมันเองก็เป็นข้อโต้แย้ง: ภาพรวม ตามด้วยคู่มือสำหรับการสร้างทีม red team ของ LLM จากนั้นเป็นเอกสารอ้างอิง — เกณฑ์บั๊กสำหรับการคัดแยกการโจมตีระบบแมชชีนเลิร์นนิง อนุกรมวิธานความล้มเหลวของแมชชีนเลิร์นนิง โมเดลความรับผิดชอบร่วม และแนวทางแบบจำลองภัยคุกคามสำหรับนักพัฒนา

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

{{1}}กรอบงานระบบอัตโนมัติแบบเปิดของ Microsoft อย่าง PyRIT ถูกจัดไว้บนชั้นเดียวกัน{{/1}} และการวางตำแหน่งนั้นแหละคือส่วนที่มีประโยชน์ {{2}}ชุดเครื่องมือสำหรับการประสานงานไม่ใช่วิธีวิทยา มันคือสิ่งที่คุณเล็งไปที่เป้าหมายเมื่ออนุกรมวิธานและเกณฑ์บั๊กมีอยู่แล้ว{{/2}} ทีมที่เริ่มต้นด้วยกรอบงานมักจบลงด้วยคลังพรอมป์ต์จำนวนมหาศาลและไม่มีวิธีจัดอันดับผลลัพธ์

เรดทีมสองทีม สองคำถามที่แตกต่างกัน

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

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

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

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

สิ่งที่พื้นผิวการโจมตีจะกลายเป็นเมื่อโมเดลมีเครื่องมือ

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

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

การประเมินที่ทดสอบเฉพาะพรอมต์จะรายงานผลลัพธ์ที่ดูเรียบร้อยและถูกต้องในเรื่องที่ผิด

ทำไมบันทึกการถอดความจึงไม่ใช่ข้อค้นพบ

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

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

สี่จุดที่การทำ red teaming สำหรับ AI แตกต่างจากการทำ red teaming สำหรับเครือข่าย

ทีมที่มาจากฝ่ายความปลอดภัยเครือข่ายหรือความปลอดภัยของแอปพลิเคชันมีสัญชาตญาณที่ดีและสมมติฐานที่ผิดสี่ประการ

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

• เป้าหมายไม่มีความแน่นอน อินพุตเดียวกันอาจสำเร็จในวันอังคารและล้มเหลวในวันพุธ สิ่งนี้ทำลายมาตรฐานหลักฐานแบบ "การทำซ้ำที่สะอาดเพียงครั้งเดียว" และบังคับให้คุณรายงานอัตรา

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

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

วิธีกำหนดขอบเขตงานสำหรับการร่วมงานครั้งแรก

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

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

สิ่งที่บันทึกเหตุการณ์เพิ่มเติม

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

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

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