คาดการณ์พฤติกรรมของโมเดลก่อนเผยแพร่ด้วยการจำลองการปรับใช้
ใช้บริบทบทสนทนาที่สมจริงเพื่อประมาณพฤติกรรมไม่พึงประสงค์ของโมเดลก่อนเผยแพร่ให้ดีขึ้น
ก่อนจะเปิดตัวโมเดลรุ่นใหม่ ห้องปฏิบัติการต่างๆ จำเป็นต้องเข้าใจว่าโมเดลนั้นทำอะไรได้บ้าง ไม่ใช่แค่เรื่องความสามารถเท่านั้น แต่ต้องรู้ด้วยว่าโมเดลมีแนวโน้มจะแสดงพฤติกรรมอย่างไรในการใช้งานจริง และจะมีส่วนไหนที่นำไปสู่ความเสี่ยงใหม่ๆ ได้บ้าง ยิ่งโมเดลมีความสามารถสูงขึ้นเท่าไร ความสำคัญของเรื่องนี้ก็ยิ่งเพิ่มขึ้นตามไปด้วย เราใช้การประเมินแบบเฉพาะเจาะจง การทดสอบเพื่อหาจุดอ่อน และมาตรการตรวจสอบอื่นๆ เป็นส่วนหนึ่งของกระบวนการรักษาความปลอดภัยก่อนเปิดตัว เพื่อทำความเข้าใจพฤติกรรมของโมเดลให้ชัดเจน ตอนนี้เราเริ่มใช้วิธีจำลองการใช้งานโมเดลก่อนปล่อยจริง ซึ่งช่วยเพิ่มข้อมูลเสริมที่สำคัญ นั่นคือการได้เห็นตัวอย่างที่คล้ายกับการใช้งานจริงเพื่อดูว่าโมเดลที่เรากำลังทดสอบอาจมีพฤติกรรมอย่างไรก่อนที่จะไปถึงมือผู้ใช้
Deployment Simulation คือวิธีการจำลองการนำโมเดลไปใช้งานจริงก่อนที่จะเกิดขึ้นจริง เราดำเนินการผ่านการนำบทสนทนาที่เคยเกิดขึ้นจริงกลับมาทดสอบกับโมเดลตัวใหม่ภายใต้แนวทางที่รักษาความเป็นส่วนตัวอย่างเคร่งครัด วิธีนี้ทำให้เราศึกษาการตอบสนองของโมเดลใหม่ในสถานการณ์เสมือนจริงก่อนเปิดตัวได้ ซึ่งรวมถึงการเฝ้าระวังว่าจะมีพฤติกรรมไม่พึงประสงค์แบบใหม่โผล่ออกมาหรือไม่ และเกิดขึ้นบ่อยแค่ไหน
ผลจากการใช้ Deployment Simulation กับโมเดลซีรีส์ GPT‑5 Thinking ในหลายรูปแบบช่วยให้เราประเมินอัตราพฤติกรรมที่ไม่พึงประสงค์ได้แม่นยำยิ่งขึ้น ช่วยตรวจพบรูปแบบการไม่สอดคล้องใหม่ๆ ก่อนถึงกำหนดเปิดตัว และลดความเสี่ยงที่โมเดลจะรู้ตัวว่ากำลังถูกทดสอบได้สำเร็จ เรายังนำวิธีการนี้ไปใช้กับการเปิดใช้งานเอเจนต์ AI ที่มีความซับซ้อนสูง ซึ่งแสดงให้เห็นว่าแนวทางดังกล่าวสามารถขยายการใช้งานได้มากกว่าการสนทนาแบบแชตทั่วไป ไปสู่สภาพแวดล้อมของเอเจนต์ที่ซับซ้อนและมีการใช้เครื่องมือต่างๆ รวมถึงสามารถนำมาใช้ประเมินความเสี่ยงก่อนการนำโมเดลไปใช้งานภายในองค์กรได้อีกด้วย
เราใช้ประโยชน์จากข้อมูลเชิงลึกที่ได้จาก Deployment Simulation ในระหว่างขั้นตอนการพัฒนาโมเดล เพื่อระบุจุดบอดที่การประเมินแบบเดิมมองข้ามไป รวมถึงนำมาใช้กำหนดแนวทางป้องกันและประกอบการตัดสินใจในการเปิดตัวโมเดล เมื่อเราปรับปรุงขั้นตอนการทำงานให้ใช้งานได้ง่ายยิ่งขึ้น เราคาดการณ์ว่ามันจะมีบทบาทสำคัญมากขึ้นในกระบวนการพัฒนาโมเดลนับจากนี้ไป
การประเมินก่อนเปิดใช้งานโมเดลที่ใช้กันโดยทั่วไปในอุตสาหกรรม มักประกอบด้วยชุดคำสั่งที่สร้างขึ้นมา คำสั่งที่มนุษย์เขียนขึ้น หรือคำสั่งจากการใช้งานจริง โดยคัดเลือกมาอย่างตั้งใจให้เป็นกรณีที่ยาก มีความรุนแรงสูง หรือเป็นคำสั่งที่มุ่งโจมตีระบบ การประเมินเหล่านี้มีเป้าหมายหลักสองประการที่เชื่อมโยงกัน คือการตรวจสอบการตอบสนองของโมเดลเมื่อถูกทดสอบอย่างหนักในสถานการณ์ที่แทบไม่มีโอกาสเกิดขึ้นจากการใช้งานจริง และการทำความเข้าใจพฤติกรรมที่ไม่พึงประสงค์ของโมเดลในภาพรวม ซึ่งครอบคลุมถึงการตรวจพบพฤติกรรมใหม่ๆ ที่ไม่ต้องการ รวมถึงการคาดการณ์โอกาสที่จะเกิดเหตุการณ์เหล่านั้นขึ้นเมื่อนำไปใช้งานจริง
แม้การประเมินแบบดั้งเดิมจะยังสำคัญสำหรับเป้าหมายแรก แต่ Deployment Simulation ถือเป็นความก้าวหน้าครั้งสำคัญสำหรับเป้าหมายที่สองในส่วนของความเสี่ยงทั่วไป (ในการทดลองของเรา วิธีการนี้ยังไม่สามารถวัดพฤติกรรมที่เกิดขึ้นด้วยความถี่ต่ำกว่า 1 ครั้งต่อ 200,000 ข้อความได้) จุดแข็งของ Deployment Simulation คือการที่วิธีนี้ช่วยให้เราหลีกเลี่ยงอุปสรรคสำคัญของการประเมินผลแบบเดิมได้
- ความครอบคลุม: การจะมั่นใจว่าชุดคำสั่งสำหรับการประเมินผลจะครอบคลุมพฤติกรรมที่ไม่พึงประสงค์ทุกรูปแบบของโมเดลได้นั้น ถือเป็นเรื่องที่ทำได้ยาก การวัดพฤติกรรมที่ไม่พึงประสงค์รูปแบบใหม่ต้องอาศัยการสร้างเกณฑ์การประเมินขึ้นมาใหม่ และต้องมีความเข้าใจว่าควรวัดผลความเสียหายในด้านใด กระบวนการนี้อาจต้องใช้ทั้งเวลาและทรัพยากรบุคคลจำนวนมาก อีกทั้งประสิทธิภาพของการประเมินก็อาจถึงจุดอิ่มตัวได้เมื่อเวลาผ่านไป
- อคติในการคัดเลือก: การประเมินผลวิธีเดิมมักสร้างขึ้นโดยเน้นพฤติกรรมไม่พึงประสงค์ที่ระบุไว้ล่วงหน้า และมักเลือกชุดข้อมูลที่เอนเอียงไปตามบริบทที่เคยเกิดขึ้นแล้วเท่านั้น สิ่งนี้อาจทำให้ผลการประเมินสะท้อนอัตราการเกิดพฤติกรรมเหล่านั้นได้ไม่ดีนัก เมื่อเทียบกับความเป็นจริงในบริบทการใช้งานทั้งหมดที่อาจเกิดขึ้นหลังการเปิดใช้งาน
- โมเดลสามารถรับรู้ได้ว่ากำลังถูกทดสอบ: โมเดลมีความสามารถมากขึ้นเรื่อยๆ ในการสังเกตว่าตนเองกำลังอยู่ระหว่างการประเมิน ซึ่งอาจทำให้พฤติกรรมของโมเดลเปลี่ยนไปจากปกติ และส่งผลให้การวัดความปลอดภัยในภายหลังคลาดเคลื่อนได้ แม้ว่าวิธีการประเมินแบบดั้งเดิมส่วนใหญ่ที่เราใช้ใน OpenAI จะดึงข้อมูลมาจากหน้างานจริงและไม่ได้รับผลกระทบจากปัญหานี้ แต่ประเด็นดังกล่าวก็ยังเป็นข้อกังวลที่พบเห็นได้บ่อยในอุตสาหกรรมส่วนใหญ่
เทคนิคสำคัญที่อยู่เบื้องหลัง Deployment Simulation นั้นทำได้ง่ายๆ โดยการนำบทสนทนาจากการใช้งานจริงเมื่อเร็วๆ นี้มาลบคำตอบเดิมของโมเดลรุ่นเก่าออก แล้วแทนที่ด้วยคำตอบใหม่จากโมเดลตัวเลือกที่เตรียมจะเปิดตัว เราประเมินคำตอบที่โมเดลสร้างขึ้นใหม่โดยมองหารูปแบบความล้มเหลวที่ไม่เคยพบมาก่อน และใช้ความถี่ที่พบในชุดข้อมูลจำลองการใช้งานจริงนี้เพื่อประมาณความถี่ของพฤติกรรมที่ไม่พึงประสงค์เมื่อมีการเปิดใช้งานจริง เราสามารถวัดผลในลักษณะเดียวกันนี้ได้อีกครั้งหลังจากปล่อยโมเดลให้ใช้งานจริง เพื่อตรวจสอบความแม่นยำของการคาดการณ์ที่เราทำไว้ก่อนหน้านี้
Deployment Simulation ช่วยลดผลกระทบจากข้อจำกัดทั้งสามประการที่กล่าวมาข้างต้นได้อย่างมาก โดยในส่วนของอคติจากการสุ่มตัวอย่างนั้นได้รับการแก้ไขผ่านการใช้ชุดพรอมต์ประเมินที่สะท้อนรูปแบบการใช้งานล่าสุดได้อย่างใกล้เคียงความเป็นจริง การใช้ Deployment Simulation ร่วมกับชุดพรอมต์ที่สะท้อนการใช้งานจริง ช่วยบรรเทาปัญหาเรื่องความครอบคลุมของการประเมินได้ เพราะเราสามารถตรวจสอบพฤติกรรมที่ไม่เหมาะสมของโมเดลได้มากขึ้นเพียงแค่จำลองสถานการณ์การใช้งานให้มากเท่าที่ต้องการ การแลกเปลี่ยนนี้ระหว่างพลังการประมวลผลและความครอบคลุมถือเป็นจุดเปลี่ยนสำคัญ เพราะคุณภาพในการประเมินความเสี่ยงจะขยับขยายได้ตามพลังประมวลผลที่เพิ่มขึ้น โดยไม่ต้องพึ่งพาแรงงานคนในการสร้างชุดการทดสอบจำนวนมาก ดูเหมือนว่าโมเดลจะไม่สามารถจำแนกความแตกต่างระหว่างบทสนทนาที่สร้างขึ้นจากการจำลองการใช้งานกับการใช้งานจริงได้
รูปที่ 1: ภาพรวมไปป์ไลน์ Deployment Simulation ของเรา
หมวด | การประเมินแบบดั้งเดิม | Deployment Simulation |
ความครอบคลุม | เหมาะกว่าสำหรับความเสี่ยงที่เกิดขึ้นน้อยแต่มีผลกระทบรุนแรง ซึ่งเราต้องการให้มั่นใจว่าได้ครอบคลุมประเด็นเหล่านั้นอย่างทั่วถึง | เหมาะกว่าสำหรับการทำความเข้าใจช่วงของความเสี่ยงที่เรามีแนวโน้มจะพบในทราฟฟิกจากการใช้งานจริง |
ความเป็นตัวแทน / อคติ | มุ่งเน้นการประเมินความเสี่ยงเฉพาะเจาะจงจากอดีตหรือที่คาดการณ์ไว้ แม้กระทั่งสำหรับพฤติกรรมที่มีความชุกต่ำมากในการใช้งานจริง | เป็นตัวแทนของความเสี่ยงที่เกิดขึ้นสูงกว่าระดับความชุกที่กำหนดในทราฟฟิกจากการใช้งานจริงในปัจจุบัน |
การรับรู้การประเมิน | สัญญาณบ่งชี้ของการทดสอบที่อาจสังเกตเห็นได้ชัด (เช่น เมื่อใช้ข้อมูลสังเคราะห์) เว้นแต่ว่าการประเมินจะถูกสร้างขึ้นด้วยข้อมูลจากการปรับใช้จริง | บริบทที่คล้ายการนำไปใช้งานจริงดูเหมือนจะช่วยลดการตระหนักรู้ว่าอยู่ในการประเมินได้อย่างมีนัยสำคัญ |
ความพยายาม | การกระจายและการตั้งค่าพรอมต์แบบกำหนดเองต้องใช้ความพยายามด้วยตนเองมากขึ้นอย่างมีนัยสำคัญ | ต้องมีการลงทุนด้านโครงสร้างพื้นฐานเพียงครั้งเดียว แล้วจึงนำส่วนนำข้อมูลตั้งต้นจากการใช้งานจริงและตัวประเมินพฤติกรรมที่ไม่พึงประสงค์ที่ทราบกันดีอยู่แล้วมาใช้งานใหม่ |
การเปรียบเทียบภาพรวมระหว่างการประเมินแบบดั้งเดิมกับ Deployment Simulation
เพื่อประเมินประสิทธิภาพของ Deployment Simulation เราได้กำหนดการคาดการณ์ล่วงหน้าเกี่ยวกับความถี่ในการเกิดพฤติกรรมที่ไม่พึงประสงค์ 20 ประเภทของ GPT‑5.4 ในการใช้งานจริง ก่อนที่จะตรวจสอบผลลัพธ์จริง Thinking นอกจากนี้เรายังได้ทำวิจัยย้อนหลังครอบคลุมถึงการนำโมเดลกลุ่ม Thinking รุ่นอื่นๆ ในตระกูล GPT‑5 ไปใช้งานจริงอีกหลายกรณี พฤติกรรมโมเดลที่เราวิเคราะห์นั้นครอบคลุมถึงทั้งปัญหาเรื่องการเบี่ยงเบนจากเป้าหมายและเนื้อหาต้องห้าม ซึ่งเราได้ระบุไว้ในรายงานการ์ดระบบมาโดยตลอด (อาทิ กรณีที่โมเดลให้ข้อมูลเท็จเกี่ยวกับเครื่องมือ หรือแสดงเนื้อหาทางเพศที่ไม่อนุญาต) แม้ว่าเราจะติดตามพฤติกรรมไม่พึงประสงค์ของโมเดลเพียง 20 ประเภทและค้นหาเฉพาะพฤติกรรมที่เบี่ยงเบนจากเป้าหมายใหม่ๆ ในผลลัพธ์เหล่านี้ แต่ Deployment Simulation ก็เป็นเทคนิคที่ยืดหยุ่น ซึ่งสามารถนำไปปรับใช้เพื่อจำลองคุณสมบัติใดก็ตามของโมเดลขณะใช้งานจริงได้
ข้อมูลการใช้งานจริงที่เราเลือกนำมาใช้เป็นผลงานมาจากโมเดลกลุ่ม Thinking ในตระกูล GPT‑5 ทั้งสิ้น ก่อนเริ่มการประเมินเราได้ทำการลบข้อมูลที่เชื่อมโยงกับบัญชีและข้อมูลที่ระบุตัวตนออกไปโดยอัตโนมัติ เพื่อให้เป็นไปตามนโยบายความเป็นส่วนตัว เราได้วิเคราะห์เฉพาะข้อมูลการใช้งาน ChatGPT จากผู้ใช้ที่ยินยอมให้ใช้ข้อมูลของตนในการปรับปรุงโมเดลเท่านั้น เรารายงานเฉพาะข้อค้นพบในภาพรวมจากการประเมินเหล่านี้ เรานำบทสนทนาที่ไม่มีข้อมูลระบุตัวตนประมาณ 1.3 ล้านรายการมาวิเคราะห์ โดยครอบคลุมตั้งแต่การใช้งาน GPT‑5 Thinking ไปจนถึง GPT‑5.4 ในช่วงเดือนสิงหาคม 2568 ถึงเดือนมีนาคม 2569
เราประเมินคุณภาพของการประเมินความเสี่ยงก่อนเปิดใช้งานจริงที่ได้จาก Deployment Simulation ผ่าน 3 แนวทางหลัก
- ความครอบคลุมของการจัดประเภทพฤติกรรม: การตรวจสอบย้อนหลังหลังเปิดใช้งานได้ค้นพบพฤติกรรมความไม่สอดคล้องที่สำคัญซึ่งตกหล่นจากระบบจัดหมวดหมู่พฤติกรรมที่ไม่พึงประสงค์เดิมของเราหรือไม่
- ความแม่นยำในการคาดการณ์ทิศทาง: การจำลองสามารถคาดการณ์ได้ถูกต้องหรือไม่ว่าความถี่ของพฤติกรรมที่รู้จักกันดีในการใช้งานจริงจะเพิ่มขึ้นหรือลดลง
- การปรับเทียบอัตราความถี่: ค่าประเมินก่อนเปิดใช้งานของเราใกล้เคียงกับอัตราที่พบจริงในระหว่างการใช้งานในภายหลังหรือไม่ การจะปรับเทียบอัตราให้ดีนั้นต้องอาศัยมากกว่าแค่ความแม่นยำเชิงทิศทาง ซึ่งทำให้สิ่งนี้กลายเป็นมาตรฐานคุณภาพที่สูงที่สุดเท่าที่จะทำได้
เรายังวัดด้วยว่าโมเดลสามารถรับรู้ได้มากน้อยเพียงใดว่ากำลังถูกประเมินผลระหว่างการทำ Deployment Simulation และทดสอบว่าวิธีการนี้มีความทนทานเพียงใดต่อรูปแบบการใช้งานจริงที่หลากหลาย รวมถึงสภาพแวดล้อมการใช้เครื่องมือที่ซับซ้อนและท้าทาย
จากการเปิดใช้งานโมเดล GPT‑5 Thinking หลายรุ่น Deployment Simulation มีประสิทธิภาพเหนือกว่าวิธีประเมินที่อาศัยพรอมต์ทดสอบที่ท้าทายในการคาดการณ์อัตราความเสี่ยงจริง สามารถตรวจพบปัญหาพฤติกรรมการโกงผ่านเครื่องคิดเลขได้ก่อนการเปิดตัว และยังทำให้โมเดลแยกไม่ออกระหว่างสภาวะการจำลองกับการใช้งานจริง
ภาพรวมของการคาดการณ์ของเรา หากต้องการเห็นภาพรวมของการคาดการณ์ทั้งหมดสำหรับการใช้งานโมเดลกลุ่ม Thinking ในตระกูล GPT‑5 สามารถดูได้ที่รูปที่ 2 ส่วนการคาดการณ์สำหรับรุ่น GPT‑5.4 Thinking ได้รับการบันทึกไว้ล่วงหน้า ส่วนการคาดการณ์อื่นๆ เป็นการคาดการณ์ย้อนหลังที่จัดทำขึ้นภายหลัง โดยรวมแล้ว ค่าการคาดการณ์ของเรามีความคลาดเคลื่อนเชิงตัวคูณอยู่ที่ค่ามัธยฐาน 1.5 เท่า (เช่น หากอัตราของพฤติกรรมไม่พึงประสงค์คือ 10 ต่อ 100,000 ข้อมูลนี้จะเทียบเท่ากับการคาดการณ์อัตราไว้ที่ 15 หรือ 6.67 ต่อ 100,000) แม้ว่าความคลาดเคลื่อนในบางกรณีอาจสูงกว่าปกติได้ราว 10 เท่า แต่เราเชื่อว่าจะสามารถลดค่าความคลาดเคลื่อนนี้ลงได้อย่างมีนัยสำคัญด้วยการปรับปรุงกระบวนการจำลองตามรายละเอียดด้านล่าง
รูปที่ 2 การคาดการณ์ความถี่ของพฤติกรรมไม่พึงประสงค์ ณ เวลาใช้งานจริงด้วยการจำลองการปรับใช้ โดยอิงจากข้อมูลการปรับใช้ก่อนหน้า สัญลักษณ์ 5.1 → 5 หมายถึงเราสุ่มซ้ำข้อมูลตั้งต้นจาก GPT‑5 ด้วยการใช้ GPT‑5.1 กล่าวคือ จำลองการปรับใช้ GPT‑5.1 โดยอิงข้อมูลจาก GPT‑5 อัตราพฤติกรรมที่ไม่สอดคล้องสูงสุดคือ “การแฮ็กเครื่องคิดเลข” ใน GPT‑5.1 ซึ่งเราเคยกล่าวถึงไว้ก่อนหน้านี้(เปิดในหน้าต่างใหม่)
การเปรียบเทียบการคาดการณ์ของ Deployment Simulation กับค่าอ้างอิงพื้นฐาน หมวดหมู่ที่สำคัญที่สุดในการประเมินความเสี่ยงก่อนการเปิดใช้งาน คือกลุ่มที่มีการเปลี่ยนแปลงของอัตราการเกิดเหตุการณ์อย่างมีนัยสำคัญหลังจากโมเดลถูกปล่อยใช้งาน (เช่น >= 1.5x) ในชุดข้อมูลย่อยนี้ Deployment Simulation มีประสิทธิภาพดีกว่าค่าอ้างอิงพื้นฐานอย่างมาก ทั้งในแง่การคาดการณ์ว่าพฤติกรรมไม่พึงประสงค์จะมีแนวโน้มเพิ่มขึ้นหรือลดลงเมื่อโมเดลเปิดใช้งานจริง (รูปที่ 3 ซ้าย) และการประเมินอัตราการเกิดเหตุการณ์จริงในช่วงเวลาใช้งาน (รูปที่ 3 ด้านขวา) เราใช้เกณฑ์อ้างอิงพื้นฐานสองอย่าง คือชุดข้อมูล Challenging Prompts ที่เราใช้ประกอบการ์ดระบบ และแนวทางพื้นฐานที่ใช้อัตราการเกิดจากการเปิดใช้งานโมเดลรุ่นก่อนหน้าเป็นค่าประมาณสำหรับโมเดลใหม่
รูปที่ 3 Deployment Simulation คาดการณ์ทั้งทิศทางของการเปลี่ยนแปลงอุบัติการณ์ (ซ้าย) และอัตราการใช้งานจริงที่แน่นอน (ขวา) ได้ดีกว่าการประเมินแบบคงที่
แหล่งที่มาของข้อผิดพลาดในการจำลองในไปป์ไลน์ของเรา นอกจากนี้เรายังได้วิเคราะห์ถึงที่มาของข้อผิดพลาดต่างๆ ในกระบวนการทำงานของเราในปัจจุบัน ความคลาดเคลื่อนขนาดใหญ่ทำให้กระบวนการนี้ขาดความน่าเชื่อถือในการตัดสินใจเปิดใช้งาน ยกตัวอย่างเช่น ระบุว่าพฤติกรรมที่ไม่พึงประสงค์บางประเภทมีแนวโน้มเพิ่มขึ้นอย่างมาก หากทราบว่าระบบมีโอกาสเกิดความคลาดเคลื่อนขนาดใหญ่เป็นครั้งคราว ย่อมทำให้เกิดข้อสงสัยว่าค่าประมาณการนี้มีความแม่นยำจริง หรือเป็นเพียงผลกระทบที่เกิดจากข้อผิดพลาดของระบบกันแน่ ปัจจัยที่เป็นสาเหตุให้เกิดข้อผิดพลาดได้มีอยู่สองประการ:
- ความคลาดเคลื่อนจากความสมจริงของสภาพแวดล้อมการสุ่มตัวอย่างใหม่: หากต้องการประมาณอัตราการเกิดในการใช้งานจริงได้อย่างแม่นยำ กระบวนการจำลองของเราจำเป็นต้องสะท้อนสภาพการใช้งานจริงให้ใกล้เคียงที่สุด เรื่องนี้ส่วนหนึ่งเป็นปัญหาทางวิศวกรรม (การสุ่มตัวอย่างจากโมเดลโดยใช้ไปป์ไลน์เดียวกับที่ใช้สำหรับทราฟฟิกการใช้งานจริง) และอีกส่วนหนึ่งเป็นความท้าทายที่น่าสนใจสำหรับเครื่องมือที่ต้องมีสิทธิ์การเข้าถึงแบบอ่าน/เขียนไปยังทรัพยากรภายนอกที่เปลี่ยนแปลงอยู่ตลอดเวลา (เช่น การค้นหาเว็บหรือการโต้ตอบกับไฟล์ในเครื่อง) เราสามารถแยกข้อผิดพลาดด้านความเที่ยงตรงของการจำลองออกมาได้ โดยเปรียบเทียบการคาดการณ์จากการปรับใช้จริงกับการจำลองของการปรับใช้นั้น (กล่าวคือ การจำลองการปรับใช้โมเดลที่ถูกปรับใช้แล้ว)
- ความคลาดเคลื่อนจากการเปลี่ยนแปลงของการกระจายตัวของพรอมต์: ข้อกังวลสำคัญประการหนึ่งของ Deployment Simulation คือการเปิดใช้งานโมเดลใหม่ย่อมทำให้รูปแบบของข้อมูลนำเข้าเปลี่ยนแปลงไป โดยเฉพาะเมื่อผู้ใช้เริ่มปรับพฤติกรรมการใช้งานให้สอดคล้องกับความสามารถใหม่ๆ ของโมเดล เราแยกข้อผิดพลาดจากการกระจายของพรอมต์โดยเปรียบเทียบค่าประมาณเมื่อจำลองการปรับใช้โดยใช้พรอมต์ล่าสุด เทียบกับพรอมต์จากการปรับใช้จริงที่เกิดขึ้น
ดังที่แสดงไว้ในรูปที่ 4 เราพบว่าข้อผิดพลาดจำนวนมากในกระบวนการของเรา โดยเฉพาะในกรณีที่ร้ายแรงที่สุดเกิดจากการที่การจำลองยังไม่สามารถสะท้อนสภาพการใช้งานจริงได้อย่างสมจริงเพียงพอ นี่ถือเป็นข่าวดี เพราะเราเชื่อว่าการปรับปรุงความสมจริงของการจำลองโดยทั่วไปทำได้ง่ายกว่าการรับมือกับการเปลี่ยนแปลงของการกระจายตัวของพรอมต์ เรายังพบว่าข้อผิดพลาดจากการเปลี่ยนแปลงการแจกแจงพรอมต์อาจลดลงได้โดยใช้ข้อมูลล่าสุดจากการปรับใช้ครั้งก่อนหน้า สามารถดูรายละเอียดเพิ่มเติมได้ในบทความวิจัย
รูปที่ 4 แสดงให้เห็นว่าความไม่เที่ยงตรงของสภาพแวดล้อมในการสุ่มตัวอย่างใหม่น่าจะเป็นสาเหตุหลักของความคลาดเคลื่อนในการประมาณการของเรา โดยเฉพาะกับกรณีที่มีข้อผิดพลาดรุนแรง
การตรวจสอบอัตโนมัติพบความไม่สอดคล้องใหม่หนึ่งรายการที่เกิดขึ้นจากการปรับใช้เหล่านี้ ในช่วงเวลาที่ศึกษา ระบบตรวจสอบอัตโนมัติที่อ้างอิงจากการจำลองการใช้งานจริงของเราสามารถตรวจพบพฤติกรรมการโกงผ่านเครื่องคิดเลขก่อนปล่อยโมเดล ซึ่งเป็นความไม่สอดคล้องใหม่เพียงจุดเดียวที่พบในข้อมูลการใช้งาน ChatGPT ที่เราวิเคราะห์ พฤติกรรมการโกงผ่านเครื่องคิดเลขเป็นรูปแบบหนึ่งของการโกงระบบให้รางวัล ซึ่งเกี่ยวข้องกับการที่โมเดลใช้เครื่องมือเบราว์เซอร์เป็นเครื่องคิดเลข ในขณะที่นำเสนอการกระทำนั้นว่าเป็นการค้นหา สิ่งนี้ไม่ได้หมายความว่าการตรวจสอบในวงกว้างจะสามารถค้นพบข้อบกพร่องใหม่ได้ทุกกรณี แต่แสดงให้เห็นว่าบริบทที่สมจริงมีความสำคัญ เพราะสามารถกระตุ้นให้เกิดพฤติกรรมบางอย่างที่ชุดการประเมินที่มีขอบเขตแคบกว่าอาจไม่สามารถตรวจพบได้เลย แม้ว่าพฤติกรรมเหล่านั้นจะไม่เคยปรากฏอยู่ในข้อมูลต้นทางที่ใช้สร้างการจำลองก็ตาม
ข้อดีอีกประการของการใช้บริบทที่ใกล้เคียงกับการใช้งานจริงคือ อาจช่วยลดความบิดเบือนของผลลัพธ์ที่เกิดขึ้นเมื่อโมเดลรับรู้ว่าตนเองกำลังถูกทดสอบ ในงานวิจัยก่อนหน้านี้ ทั้งเราและผู้อื่น(เปิดในหน้าต่างใหม่)พบว่า โมเดลมักรับรู้ได้ว่ากำลังถูกทดสอบอยู่ ยกตัวอย่างเช่น ในกระบวนการคิด โมเดลอาจวิเคราะห์ว่ามันกำลังถูกทดสอบเรื่องอะไร ผู้ประเมินน่าจะพอใจสิ่งไหน และถ้ามันกำลังทำตัวไม่เหมาะสม มันก็จะคิดด้วยว่าจะถูกจับได้หรือไม่ ประเด็นนี้ก่อให้เกิดปัญหาต่อการประเมินความสอดคล้อง หากพฤติกรรมที่ดีของโมเดลเกิดจากการที่มันรู้ตัวว่ากำลังถูกทดสอบ เราจะเชื่อมั่นได้อย่างไรว่ามันจะประพฤติตนอย่างปลอดภัยหลังจากที่ได้รับรู้ว่าถูกนำไปใช้งานจริงแล้ว
เราแสดงให้เห็นว่า Deployment Simulation ช่วยลดระดับการรับรู้ว่ากำลังถูกประเมินของโมเดลได้อย่างมีนัยสำคัญ เมื่อเทียบกับการประเมินแบบดั้งเดิมที่ไม่ได้อาศัยข้อมูลจากการใช้งานจริง เราวัดระดับการรับรู้ว่ากำลังถูกประเมินด้วย 3 วิธี ได้แก่ ให้โมเดลจำแนกว่าชุดข้อมูลมาจากสถานการณ์ใช้งานจริงหรือการทดสอบ การตรวจสอบการให้เหตุผลแบบเป็นลำดับขั้นว่ามีการพูดถึงการถูกประเมินหรือไม่ และติดตามพฤติกรรม metagaming(เปิดในหน้าต่างใหม่) หรือการให้เหตุผลที่เกี่ยวข้องกับการกำกับดูแลและการตรวจสอบ ข้อมูลทราฟฟิกในสถานการณ์จำลองมีความใกล้เคียงกับข้อมูลการใช้งานจริงมากในทั้งสามตัวชี้วัดที่เราวัดผล ยกตัวอย่างเช่น GPT‑5.2 ระบุว่าข้อมูลการใช้งานจริงมีลักษณะคล้ายการประเมินผลเพียง 5.4% ส่วนข้อมูลจากการจำลองอยู่ที่ 5.1% ในขณะที่การประเมินแบบดั้งเดิมอย่าง SWE-Bench หรือ MonorepoBench ซึ่งเน้นตัวอย่างสังเคราะห์เป็นหลักนั้น ถูกระบุว่าเป็นการประเมินผลเกือบ 100% เลยทีเดียว
รูปที่ 5: การเปรียบเทียบระดับการรับรู้ว่ากำลังถูกประเมิน ข้อมูลการใช้งานจริงและข้อมูลจากการจำลองการเปิดใช้งานมีอัตราที่ใกล้เคียงกันในการตรวจจับว่าเป็นการประเมิน การแสดงออกอย่างชัดเจนว่ารับรู้ถึงการประเมินด้าน Alignment และ Metagaming ขณะที่ชุดข้อมูลการประเมินแบบดั้งเดิมมีอัตราในตัวชี้วัดเหล่านี้สูงกว่ามาก
เพื่อทดสอบว่าวิธีการนี้สามารถขยายไปนอกเหนือจากโหมดแชทมาตรฐานได้หรือไม่ เรายังได้ศึกษาการจำลองการปรับใช้ในสภาพแวดล้อมการเขียนโค้ดแบบเอเจนต์ที่ท้าทายด้วย โดยเฉพาะอย่างยิ่งเราใช้เส้นทางการทำงานแบบเอเจนต์ของพนักงานภายในจำนวน 120,000 รายการจาก GPT‑5.4 เพื่อจำลองการปรับใช้เอเจนต์สำหรับการเขียนโค้ดภายในที่อิงตาม GPT‑5.5 สิ่งนี้มีวัตถุประสงค์สองประการคือ แสดงให้เห็นว่าการจำลองการปรับใช้สามารถนำไปใช้ในการประเมินความเสี่ยงสำหรับการปรับใช้ภายในได้เช่นกัน และแสดงให้เห็นว่าสามารถทำให้ความเที่ยงตรงของการจำลองอยู่ในระดับสูงได้ แม้ในสภาพแวดล้อมแบบเอเจนต์ผ่านการจำลองเครื่องมืออย่างรอบคอบ
ตามที่เราได้หารือกันไปก่อนหน้านี้ ความไม่เที่ยงตรงของระบบจำลองถือเป็นหนึ่งในสาเหตุหลักของความผิดพลาดในกระบวนการทำงานของเราขณะนี้ หนึ่งในความท้าทายของการทำให้การจำลองการปรับใช้มีความสมจริงคือ การจำลองดังกล่าวต้องใช้เครื่องมือที่ทำงานในลักษณะที่สมจริง แม้ว่าเครื่องมือเหล่านั้นจะต้องมีสิทธิ์ในการอ่าน/เขียนทรัพยากรภายนอกที่มีการเปลี่ยนแปลงอยู่ตลอดเวลา (เช่น การค้นหาเว็บหรือการโต้ตอบกับไฟล์ในเครื่อง)
ประเด็นนี้เป็นสิ่งที่ท้าทายมากสำหรับสภาพแวดล้อมแบบเอเจนต์ เนื่องจากเส้นทางการทำงานของเอเจนต์เพียงหนึ่งเส้นทางอาจต้องอาศัยการเรียกใช้เครื่องมือหลายร้อยครั้ง รวมถึงสถานะของ Repository การตอบสนองของเครือข่าย หรือความผิดพลาดที่เกิดขึ้นเป็นครั้งคราว การดำเนินการดังกล่าวทำให้การสุ่มตัวอย่างใหม่ด้วยการเรียกใช้เครื่องมือจริงมีความซับซ้อนและอาจนำไปสู่ความเสี่ยงได้ ด้วยเหตุนี้แทนที่จะนำการเรียกใช้เครื่องมือไปใช้กับระบบจริง เราจำลองการเรียกใช้เหล่านั้นด้วย LLM อีกตัวหนึ่ง เราแสดงให้เห็นว่าการมอบความสามารถเพิ่มเติมให้กับ LLM นี้มีความจำเป็นต่อความสมจริง และด้วยเหตุนี้จึงจำเป็นต่อคุณภาพของการประมาณค่า
เราให้โมเดลที่ทำหน้าที่จำลองเครื่องมือเข้าถึงข้อมูลการทำงานรอบสุดท้ายแบบดั้งเดิม Repository ในช่วงเวลาของการสนทนา ฐานข้อมูลที่เก็บคู่ข้อมูลการเรียกใช้เครื่องมือและผลการตอบกลับ และตัวเชื่อมต่อแบบอ่านได้อย่างเดียวเท่านั้น ในการทดสอบที่ให้ตัวจำแนกพยายามแยกแยะการทำงานจริงออกจากการทำงานจำลอง อัตราความสมจริงได้เพิ่มขึ้นจากเดิมที่ทำได้เพียง 11.6% เป็น 49.5% ซึ่งถือว่าใกล้เคียงกับระดับการสุ่มที่ 50% มาก
รูปที่ 6: เราสามารถทำให้ความสมจริงของการสุ่มตัวอย่างซ้ำแทบจะแยกไม่ออกจากการสุ่มตัวอย่างจริง แม้ในสภาพแวดล้อมที่ใช้เครื่องมือเป็นหลัก เมื่อจำลองการเรียกใช้เครื่องมือโดยเพิ่มความสามารถที่เอื้อต่อการใช้งาน
เพื่อเป็นหลักฐานสนับสนุนเพิ่มเติมในด้านความเที่ยงตรงของการจำลอง เมื่อเราทำการจำลอง GPT‑5.4 ขึ้นมา ปริมาณการคิดของ Codex ที่ใช้ GPT‑5.4 อัตราความไม่สอดคล้องกับเป้าหมายโดยประมาณแล้วอยู่ภายในช่วงแถบค่าความคลาดเคลื่อน ในทางตรงกันข้ามในการทดสอบก่อนการปรับใช้ของเรา GPT‑5.5 มีความไม่สอดคล้องมากกว่าในหมวดหมู่ส่วนใหญ่
รูปที่ 7: เมื่อใช้การจำลองเครื่องมือ อัตราพฤติกรรมสำหรับบทสนทนาที่สุ่มซ้ำด้วย GPT‑5.4 และทราฟฟิกการใช้งานจริงของ GPT‑5.4 ค่อนข้างใกล้เคียงกัน ซึ่งบ่งชี้ว่าความเที่ยงตรงของสภาพแวดล้อมการสุ่มซ้ำสูง ดูบริบทเพิ่มเติมเกี่ยวกับหมวดหมู่ได้ในการ์ดระบบ GPT‑5.5(เปิดในหน้าต่างใหม่)
ผลลัพธ์เหล่านี้ชี้ให้เห็นว่า Deployment Simulation สามารถนำไปใช้กับสภาพแวดล้อมของเอเจนต์ที่มีความซับซ้อนได้ หากสภาพแวดล้อมของเครื่องมือที่เกี่ยวข้องถูกจำลองขึ้นด้วยความสมจริงที่เพียงพอ
ข้อสงสัยที่เกิดขึ้นตามมาคือ ผู้ตรวจสอบจากภายนอกจะได้รับประโยชน์ในระดับเดียวกันหรือไม่โดยที่ไม่ต้องอาศัยการเข้าถึงข้อมูลการใช้งานจริงที่เป็นส่วนตัว เราทดสอบเรื่องนี้โดยใช้การสนทนาจาก WildChat จำนวน 100,000 รายการมาเป็นข้อมูลเริ่มต้น แม้ WildChat จะมีความแม่นยำน้อยกว่าข้อมูลการใช้งานจริงล่าสุดของ OpenAI แต่ก็ยังให้ข้อมูลที่มีประโยชน์ โดยข้อมูลการใช้งานจริงล่าสุดมีค่าความคลาดเคลื่อนเชิงตัวคูณเฉลี่ยต่ำกว่า WildChat (1.75 เท่า เทียบกับ 2.44 เท่า) ขณะที่ WildChat ยังคงสามารถประมาณอัตราการเกิดได้ใกล้เคียงกับข้อมูลจริงภายในช่วงประมาณ 3 เท่าอยู่บ่อยครั้ง และสามารถระบุได้ว่าโมเดลใดดีกว่าในอัตราที่สูงกว่าการเดาสุ่ม เรามองว่าการประเมินในรูปแบบ WildChat เป็นแนวทางเสริมที่มีศักยภาพสำหรับ Deployment Simulation ที่ดำเนินการโดยผู้พัฒนา สามารถดูผลลัพธ์เพิ่มเติมเกี่ยวกับประเด็นนี้ได้ในบทความด้าน Alignment(เปิดในหน้าต่างใหม่)ที่เผยแพร่ควบคู่กัน
Deployment Simulation ทำหน้าที่เป็นส่วนเติมเต็ม ไม่ใช่การเข้ามาแทนที่การประเมินผลเชิงต่อต้าน การทำ Red-teaming รวมถึงการวิเคราะห์ความเสี่ยงที่เกิดขึ้นได้ยากแต่ส่งผลกระทบสูง การตรวจจับพฤติกรรมที่ไม่พึงประสงค์บางประเภทของโมเดลอาศัยความสามารถในการตรวจสอบการให้เหตุผลแบบเป็นลำดับขั้น หากโมเดลในอนาคตให้เหตุผลอย่างเข้าใจได้ยากขึ้น ละเว้นขั้นตอนสำคัญ หรือเรียนรู้ที่จะปกปิดเจตนา เราอาจไม่สามารถตรวจจับพฤติกรรมที่ไม่พึงประสงค์เหล่านี้ได้ นอกจากนี้เนื่องจากข้อมูลการใช้งานจริงเป็นข้อมูลส่วนตัว ปัจจุบันนักพัฒนาจึงสามารถเข้าถึงบริบทที่สะท้อนสถานการณ์จริงได้มากกว่าผู้ตรวจสอบภายนอก ชุดข้อมูลสาธารณะที่ดีขึ้นอาจช่วยลดช่องว่างนั้นได้
Deployment Simulation มีประโยชน์มากที่สุดสำหรับพฤติกรรมที่เกิดขึ้นบ่อยพอที่จะปรากฏอยู่ในชุดข้อมูลตั้งต้นที่นำมาสุ่มตัวอย่าง ความล้มเหลวที่เกิดขึ้นเพียง 1 ครั้งในทุกๆ 10 ล้านบทสนทนา มีแนวโน้มสูงที่จะไม่ถูกค้นพบในการทดสอบที่ใช้ตัวอย่าง 1 ล้านรายการ ดังนั้นการประเมินแบบเชิงโจมตี การทำ red-teaming และการวิเคราะห์ความเสี่ยงกรณีเลวร้ายที่เกิดขึ้นได้ยากจึงยังคงเป็นสิ่งที่ขาดไม่ได้ ปัจจุบันเราเน้นการจำลองการตอบกลับของผู้ช่วยเพียงรายการเดียว เนื่องจากในการทดลองเบื้องต้น เราไม่พบว่าการจำลองหลายรอบการสนทนาช่วยปรับปรุงค่าประมาณของเราได้อย่างมีนัยสำคัญ นี่อาจเป็นด้านสำคัญสำหรับการปรับปรุงความสมจริงของการจำลองในอนาคต
วิธีการนี้ยังขึ้นอยู่กับการกระจายตัวของข้อมูลตั้งต้น หรือส่วนผสมของบทสนทนาที่ถูกนำมาสุ่มตัวอย่างใหม่ด้วย ทราฟฟิกในอดีตอาจไม่สอดคล้องกับวิธีที่ผู้ใช้โต้ตอบกับโมเดลที่มีความสามารถมากขึ้นหลังจากมีการเปลี่ยนแปลงผลิตภัณฑ์ครั้งใหญ่ การเปิดตัวเครื่องมือใหม่ เหตุการณ์ระดับโลก หรือการเปลี่ยนแปลงตามฤดูกาล การวิเคราะห์ในบทความฉบับเต็มชี้ให้เห็นว่าปัญหานี้สามารถบรรเทาได้โดยใช้ข้อมูลล่าสุดที่มีอยู่
Deployment Simulation คือวิธีการใหม่ในการประเมินความเสี่ยงก่อนการใช้งานจริง ซึ่งช่วยให้ห้องปฏิบัติการและผู้ประเมินสามารถคาดการณ์พฤติกรรมของโมเดลภาษาในโลกจริง และทำความเข้าใจความเสี่ยงที่อาจเกิดขึ้นก่อนนำโมเดลไปใช้งาน แนวทางนี้เข้ามาเสริมการประเมินความปลอดภัย การทำ Red-teaming และการวิเคราะห์แบบเจาะจงที่มีอยู่เดิม โดยเพิ่มชั้นการคาดการณ์ที่ใกล้เคียงกับการใช้งานจริง ซึ่งช่วยให้ประเมินพฤติกรรมได้แม่นยำขึ้น ลดผลกระทบจากการที่โมเดลรู้ตัวว่าถูกทดสอบ และทำให้สามารถตรวจสอบความถูกต้องของการคาดการณ์ก่อนเปิดใช้งานได้หลังจากเปิดใช้งานจริง เมื่อใช้ควบคู่กับการประเมินแบบดั้งเดิม Deployment Simulation สามารถช่วยให้การประเมินความเสี่ยงของโมเดลมีความสมจริงมากขึ้น เป็นเชิงปริมาณมากขึ้น และมีประโยชน์มากขึ้นสำหรับการตัดสินใจเกี่ยวกับการปรับใช้
ผู้เขียน
อ่านต่อ
