ข้ามไปยังเนื้อหาหลัก
OpenAI

20 กรกฎาคม 2569

ความปลอดภัย

ความปลอดภัยและการจัดแนวพฤติกรรมในยุคของโมเดลที่รองรับงานระยะยาว

สิ่งที่เราเรียนรู้เกี่ยวกับความปลอดภัยจากการใช้งานโมเดลที่ทำงานต่อเนื่องเป็นเวลานานภายในองค์กร

กำลังโหลด…

สรุป

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

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

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

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

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

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

ในหัวข้อต่อไปนี้ เราจะแชร์ตัวอย่างที่เป็นรูปธรรมของสิ่งที่เราสังเกตพบ วิธีที่เราแก้ไขปัญหา และวิธีที่ประสบการณ์ครั้งนี้จะหล่อหลอมการเปิดตัวในอนาคต

ความสามารถในการทำงานต่อเนื่องของโมเดลอาจเปิดเผยช่องโหว่ด้านความปลอดภัย

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

ตัวอย่างของกรณีนี้เกิดขึ้นระหว่างการประเมินภายในเกี่ยวกับ NanoGPT speedrun⁠(เปิดในหน้าต่างใหม่) ซึ่งเป็นเกณฑ์มาตรฐานสาธารณะสำหรับการฝึกโมเดลภาษาขนาดเล็กโดยใช้จำนวนขั้นตอนให้น้อยที่สุดเท่าที่เป็นไปได้ โมเดลของเราได้พัฒนาวิธีลดอัตราการเรียนรู้ตามกฎกำลัง (power-law learning-rate cooldown) ที่มีชื่อว่า PowerCool และส่งผลให้ประสิทธิภาพดีขึ้นอย่างมีนัยสำคัญ โมเดลได้รับคำสั่งให้โพสต์ผลลัพธ์เฉพาะไปยัง Slack เท่านั้น แต่คำสั่งของ NanoGPT ระบุให้โพสต์ผลลัพธ์เป็น PR ไปยัง GitHub และโมเดลได้ทำตามคำสั่งชุดหลังเพื่อเปิด PR 287 บน GitHub Repository สาธารณะ โมเดลหลีกเลี่ยงข้อจำกัดของแซนด์บ็อกซ์ที่ออกแบบมาเพื่อปิดกั้นการเข้าถึงจากภายนอก และดำเนินการอัปโหลดไปยัง GitHub ต่อ โมเดลของเราใช้เวลาหนึ่งชั่วโมงในการค้นหาช่องโหว่ในแซนด์บ็อกซ์เพื่อสร้าง PR ขณะที่โมเดลรุ่นก่อนๆ มีความสามารถในการพยายามต่อเนื่องน้อยกว่า จึงไม่สามารถค้นพบช่องโหว่ได้ และยุติการพยายามในขั้นตอนการสร้าง PR1

จากการพิจารณาการกระทำแต่ละอย่าง สู่การพิจารณาเส้นทางการดำเนินการทั้งหมด

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

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

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

การสร้างมาตรการป้องกันสำหรับโมเดลที่ทำงานเป็นเวลานาน

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

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

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

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

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

การปรับใช้ใหม่

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

ตัวอย่างบางส่วนของเหตุการณ์ที่มีความรุนแรงต่ำเหล่านี้ ได้แก่ กรณีต่อไปนี้:

  • เพื่อเข้าถึงเครื่องมือบรรทัดคำสั่งของ Linear โมเดลได้เปิดเซสชัน codex --yolo แบบซ้อนกัน ทั้งที่จริงแล้วสามารถทำได้โดยไม่ต้องใช้แฟล็ก --yolo

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

  • โมเดลมีโปรเซส find จำนวนมากที่ค้างอยู่ ส่งผลให้ทุกคำสั่งเชลล์หยุดค้าง จากนั้นโมเดลจึงรัน kill -9 -1 ซึ่งหากคำสั่งถูกดำเนินการ จะส่งสัญญาณ SIGKILL ไปยังทุกโปรเซสบนพ็อดนั้นที่โมเดลมีสิทธิ์ยุติได้ อย่างไรก็ตามคำสั่งหมดเวลาก่อน จึงไม่ได้ถูกดำเนินการ

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

ข้อคิดเห็นส่งท้าย

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

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

ผู้เขียน

OpenAI

เชิงอรรถ

  1. 1

    แม้ว่าเราจะปิด PR ดังกล่าวอย่างรวดเร็ว แต่ผู้เข้าร่วมกิจกรรม Speedrun หลายคนได้เห็นและนำแนวทางนี้ไปใช้ในการส่งงานของตนเองแล้ว โดยการส่งงานที่ทำลายสถิติโลกในลำดับต่อมาที่จำนวน 3030⁠(เปิดในหน้าต่างใหม่), 2990⁠(เปิดในหน้าต่างใหม่), 2930⁠(เปิดในหน้าต่างใหม่), 2925⁠(เปิดในหน้าต่างใหม่), 2900⁠(เปิดในหน้าต่างใหม่) และ 2890⁠(เปิดในหน้าต่างใหม่) ขั้น ล้วนอ้างอิงถึง PR 287 ในบรรดา PR เหล่านี้ PR 300⁠(เปิดในหน้าต่างใหม่) น่าสนใจเป็นพิเศษ เนื่องจากเป็น PR ที่ Opus 4.7 ส่งเมื่อ Prime Intellect⁠(เปิดในหน้าต่างใหม่) นำไปประเมินบน NanoGPT speedrun Opus ได้เห็น PR ที่โมเดลของเราส่ง จากนั้นนำข้อค้นพบไปใช้ และอ้างอิง PR ของเราในผลลัพธ์สุดท้าย

  2.  การดำเนินงานของโมเดลในการจำลองเหตุการณ์ซ้ำ (Replay) ไม่รับประกันว่าจะแสดงพฤติกรรมที่ไม่สอดคล้องกับเป้าหมายเดิมทุกครั้ง เนื่องจากความสุ่มและการไม่สมบูรณ์แบบในการจำลองสภาพแวดล้อมขึ้นมาใหม่