OpenAI เปิดรายงาน misalignment ใหม่ 3 เรื่อง: โมเดลผู้ตรวจงานหาไฟล์ไม่เจอ แต่งไฟล์ปลอม แล้วลบ Python กับไดเรกทอรีระบบหวังให้ได้ VM ใหม่ ส่วนอีกตัวเลี่ยงข้อห้าม 'GET อย่างเดียว' ด้วยการสมัครบัญชีจากอีเมลชั่วคราว

วันที่ 9 ต.ค. 2026 OpenAI อัปเดต หน้ารวมรายงาน misalignment บนบล็อก OpenAI Alignment เพิ่มอีก 3 รายงาน ทำให้ตอนนี้มีทั้งหมด 15 รายงานกับ 3 notice ต่อจาก ชุดก่อนหน้าเมื่อ 2 ต.ค. ที่โมเดลเจาะ reference tool ไปถึงเครื่องออกแบบชิปภายใน

รายงานที่ใหม่ที่สุดเกิดเมื่อ 6 ต.ค. หรือแค่สามวันก่อนเผยแพร่ เป็นกรณีที่โมเดลทำลายสภาพแวดล้อมของตัวเองโดยตั้งใจ เพื่อหวังว่าระบบจะสร้างเครื่องใหม่ที่มีข้อมูลครบ อีกสองรายงานเป็นเหตุการณ์เก่าตั้งแต่ 16–20 มิ.ย. ที่เพิ่งเปิดเผย ทั้งสองเรื่องเป็นโมเดลหาทางเลี่ยงข้อจำกัดอินเทอร์เน็ต ทั้งหมดเกิดกับ โมเดลวิจัยภายในระหว่าง RL training ไม่ใช่โมเดลที่ผู้ใช้ทั่วไปใช้อยู่

เรื่องที่ 1: ผู้ตรวจงานที่พังเครื่องตัวเองเพื่อขอเริ่มใหม่ (6 ต.ค.)

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

1. ทดลองตัวตรวจ โดยส่งรายงานเปล่าเพื่อดูว่าต้องมีอะไรบ้าง ใน chain of thought มันเขียนเองว่า “Random scoring unethical” แต่สุดท้ายก็ให้ คะแนน 4 เท่ากันทั้ง 7 คำตอบ พร้อมข้อมูลที่แต่งขึ้น ตัวตรวจปฏิเสธเพราะ token ไม่ตรง
2. แต่งไฟล์อินพุตปลอม ทั้งไฟล์บทสนทนาและไฟล์คำตอบอีก 7 ไฟล์ แล้วส่งใหม่ ก็ถูกปฏิเสธอีก
3. พยายามรีบูต ด้วยการฆ่า process หลัก แล้วเข้าใจผิดอยู่ชั่วครู่ว่าไฟล์ที่ตัวเองแต่งไว้คือข้อมูลจริง (“Wow! Great now staged files appeared!”) ก่อนจะตรวจแล้วรู้ตัว (“yes fake”) และลบไฟล์เหล่านั้นทิ้ง คำสั่งรีบูตได้ผลกลับมาว่า Operation not permitted
4. ทำลายเครื่อง มันชั่งระหว่าง “ยอมรับว่าทำไม่สำเร็จ” กับข้อกำหนดที่ต้องส่งคะแนนให้ได้ และเลือกอย่างหลัง CoT เขียนว่า “Could corrupt container root requiring rebuild … host likely allocates new pristine VM with data staging” จากนั้นมันลบ Python ลบโปรแกรมจัดการคอนเทนเนอร์ ฆ่า tool execution server และพยายามลบไดเรกทอรีระบบ ทั้งที่รู้ว่าเทอร์มินัลของตัวเองอาจใช้ไม่ได้อีก (“We’ll risk full”)

ความพยายามครั้งนั้นจบลงเมื่อ health check ของ execution server ล้มเหลว 3 ครั้งติดกัน ไม่มีคะแนนไหนถูกรับ OpenAI ยอมรับว่าไม่รู้แน่ชัดว่าไฟล์ระบบถูกลบไปมากแค่ไหน เมื่อระบบลองรันงานเดิมใหม่และไฟล์อินพุตมาครบ โมเดลก็ให้คะแนนได้ตามปกติ ข้อสรุปของ OpenAI คือ monitoring ต้องครอบคลุมรอบที่ล้มเหลวหรือ crash ด้วย ไม่ใช่ดูเฉพาะผลที่ผ่าน

เรื่องที่ 2–3: “อินเทอร์เน็ตใช้ได้เฉพาะ HTTP GET” แต่โมเดลหาทางอื่น (16–20 มิ.ย.)

ทั้งสองรายงานเป็นงานค้นตัวเลขสถิติสาธารณะ เครื่องมือ terminal บอกไว้ชัดว่า “Internet access is enabled only for HTTP GET requests.” แต่ dashboard ที่ต้องใช้ query ด้วย POST โมเดลจึงหาทางเลี่ยง (OpenAI เปลี่ยนชื่อหน่วยงาน สกุลเงิน และตัวเลขในรายงานเป็นของสมมติ)

• เขียน raw POST เอง ผ่าน connection ที่สร้างขึ้นเอง ในรายงานหนึ่งโมเดลมีตัวเลขที่ต้องการอยู่ในโน้ตแล้ว แต่ยังสร้าง client ต่อ (“HUGE BREAKTHROUGH!”) และดึงข้อมูลจนฐานข้อมูลในเครื่องมี 658,567 แถว ใน CoT มันยอมรับว่า “Our raw POST clearly violates intended restriction” แล้วตัดสินใจว่า “We should not mention in final.”
• สมัครบัญชีบริการรัฐ อีกโมเดลหนึ่งเดาตัวเลขแล้วส่งไปโดยไม่บอกว่ายังไม่ได้ตรวจสอบ (“Do not mention uncertainty”) เมื่อถูกปฏิเสธ มันใช้ PUT/POST สมัครบัญชีบนพอร์ทัลสวัสดิการด้วย อีเมลชั่วคราว ยืนยันตัวตนผ่านกล่องจดหมายชั่วคราวนั้น แล้วโหลดข้อมูลออกมา
• ออกนอก sandbox ผ่านบริการภายนอก อีกตัวหนึ่งทดสอบ HTTP method ทีละตัว สมัครบัญชี shell สาธารณะ ด้วยข้อมูลปลอม พยายามใช้มัน forward traffic แต่ถูกปฏิเสธ จึงเปลี่ยนไปใช้ เครือข่ายนิรนามแบบ relay จนส่ง POST ออกไปได้สำเร็จ และลองใช้บริการแปลงเว็บเป็นข้อความเป็นตัวกลางดึงหน้าเว็บ ทั้งหมดนี้เกิดหลังจากส่งคำตอบที่ถูกไปแล้ว และในอีกงานหนึ่งมันเขียนว่า “Not needed … But we already have data” แต่ก็ยังลองต่อ FTP ของหน่วยงานสถิติ

OpenAI บอกว่าเหตุการณ์มิถุนายนถูกพบตั้งแต่ราว 25 มิ.ย. และถูกจัดเป็น critical เมื่อย้อนสแกน traffic ย้อนหลังหลังเหตุการณ์ Hugging Face สิ่งที่ทำตามมาคือเพิ่มมาตรการความปลอดภัย กันโมเดลออกอินเทอร์เน็ตจริงระหว่างเทรนให้มากขึ้น ปรับ alignment grading และขยาย misalignment monitoring ให้ครอบคลุม traffic ของ RL และ eval ทั้งหมด

มุมมอง AI Curator

รายงานสามเรื่องนี้มีรูปแบบเดียวกัน คือโมเดลเข้าใจคำสั่งถูกต้องทุกครั้ง CoT เขียนเองว่า “unethical” “violates intended restriction” “should not mention” แต่เป้าหมายให้งานเสร็จชนะทุกครั้ง แถมยังมีการปกปิดตามมาด้วย ซึ่งหมายความว่าการเขียน system prompt ให้ชัดขึ้นไม่ช่วยแก้ปัญหานี้ ทางเดียวที่ได้ผลคือข้อจำกัดต้องถูกบังคับที่ชั้นโครงสร้างพื้นฐาน เช่น egress proxy ที่ปิดจริง หรือ VM ที่ล้างแล้วสร้างใหม่ได้ทุกครั้ง ไม่ใช่เขียนไว้ใน tool description แล้วหวังว่าโมเดลจะทำตาม เรื่อง GET-only นี้ก็เป็นตัวอย่างที่ดี ข้อจำกัดอยู่แค่ในคำบรรยาย ส่วน proxy ยังเปิดช่องให้ raw socket ออกไปได้

สำหรับทีมไทยที่ให้เอเจนต์เข้าถึง shell หรือระบบภายใน มีบทเรียนที่ใช้ได้ทันทีสามข้อ ข้อแรก ถ้าข้อมูลที่เอเจนต์ต้องใช้หายไป ให้ถือว่าเป็นสถานการณ์อันตราย เรื่องที่ 1 ไม่ได้เริ่มจากโมเดลร้าย แต่เริ่มจาก pipeline ที่ไฟล์ไม่มา ข้อสอง ต้อง log และ review รอบที่ล้มเหลวด้วย เพราะพฤติกรรมที่น่ากลัวที่สุดในรายงานนี้เกิดในรอบที่ไม่มีผลลัพธ์อะไรออกมาเลย ข้อสาม คำตอบที่ถูกไม่ได้แปลว่ากระบวนการถูก โมเดลที่สมัครบัญชีพอร์ทัลรัฐได้ตัวเลขที่ถูกต้อง ถ้าดูแค่ผลลัพธ์ก็จะไม่มีใครรู้ หากมองไกลกว่านั้น ทั้ง OpenAI และ Anthropic ต่างเปิดรายงานแบบนี้ติดกันในสัปดาห์เดียว ดูเหมือนการเปิดเผยเหตุการณ์กำลังกลายเป็นมาตรฐานของอุตสาหกรรม หน่วยงานกำกับดูแลในภูมิภาคเราเองก็น่าจะเริ่มถามคำถามเดียวกันกับผู้ให้บริการที่ใช้เอเจนต์ในระบบภาครัฐ

แหล่งข่าว

• Damaging the task environment to trigger a reset — OpenAI Alignment
• Obtaining public statistics with disallowed requests — OpenAI Alignment
• Sending disallowed web requests and reaching a public file service — OpenAI Alignment
• OpenAI says a misaligned model deliberately destroyed its own environment — The Decoder