สัปดาห์นี้ สาขาการประเมิน AI ประสบกับวิกฤตความไว้วางใจอย่างรุนแรง
SWE-bench ในฐานะมาตรฐานที่ยอมรับในอุตสาหกรรมสำหรับวัดความสามารถการเขียนโปรแกรมของ AI เป็นตัวชี้วัดสำคัญในการเปิดตัวโมเดลต่างๆ และเป็นพื้นฐานสำคัญสำหรับนักลงทุนในการประเมินมูลค่าโมเดล อย่างไรก็ตาม ทีมวิจัยจากเบิร์กลีย์เปิดเผยว่า แค่ไฟล์ conftest.py ไฟล์เดียวก็สามารถทำให้แนวป้องกันของมันพังทลายได้
ไม่เพียงเท่านั้น ทีม RDI จากเบิร์กลีย์สร้างเอเจนต์สแกนช่องโหว่อัตโนมัติขึ้นมา เพื่อทำการทดสอบเจาะระบบเบนช์มาร์กการประเมินเอเจนต์ AI หลัก 8 แห่งในปัจจุบัน ผลลัพธ์คือ ทุกเบนช์มาร์กถูกเจาะสำเร็จ อัตราคะแนนอยู่ระหว่าง 73% ถึง 100%
ที่น่าคิดยิ่งกว่านั้น คือในสัปดาห์เดียวกัน รายงานการตรวจสอบอิสระจากทีมมหาวิทยาลัยเพนซิลเวเนียและบัตรระบบ Mythos Preview ของ Anthropic ก็เผยแพร่พร้อมกัน สายหลักฐานสามทางที่แยกจากกันนี้ชี้ไปที่ข้อสรุปเดียวกัน: ตั้งแต่การออกแบบไปจนถึงการดำเนินการ เบนช์มาร์กการประเมินเหล่านี้เองก็เต็มไปด้วยช่องโหว่ที่สามารถถูกใช้ประโยชน์ได้
โค้ด 10 บรรทัด ข้อสอบ 500 ข้อได้เต็ม คะแนน 0 ในการแก้บั๊ก 
ผลคะแนนของเอเจนต์ใช้ประโยชน์ช่องโหว่จากทีมเบิร์กลีย์บนเบนช์มาร์กหลัก 8 แห่ง เอเจนต์นี้ไม่ได้แก้ไขงานจริงใดๆ และไม่ได้เรียกใช้โมเดลใหญ่ใดๆ แต่กลับได้คะแนนเต็มใน 6 เบนช์มาร์กจากนั้น
วิธีการโจมตีที่ทีมเบิร์กลีย์ใช้นั้นง่ายจนน่าประหลาดใจ
ยกตัวอย่าง SWE-bench งานของมันคือให้ AI แก้ไขบั๊กจริงบน GitHub จะถือว่าสำเร็จก็ต่อเมื่อผ่านเทสเคส ทีมเบิร์กลีย์ส่ง “แพตช์” ที่มีไฟล์ conftest.py ไฟล์นี้ใช้ประโยชน์จากกลไกฮุค (hook) ของเฟรมเวิร์กทดสอบ pytest เพื่อขัดขวางผลการทดสอบแต่ละครั้งขณะรัน และบังคับเปลี่ยนผลเป็น “ผ่าน”
ในที่สุด ปัญหา 500 ข้อทั้งหมดแสดงผลเป็น “ผ่าน” แต่ไม่มีบั๊กใดๆ ถูกแก้ไขจริงๆ
หลักการอยู่ที่ว่า: สภาพแวดล้อมทดสอบของ SWE-bench และ AI ที่ถูกทดสอบทำงานอยู่ใน Docker container เดียวกัน โค้ดที่เอเจนต์ส่งเข้ามามีสิทธิ์เต็มใน container ในขณะที่ pytest จะค้นพบและโหลดไฟล์ conftest.py ในโปรเจกต์โดยอัตโนมัติ ผู้โจมตีเพียงแค่ต้องขัดขวางเฟส “call” ของการทดสอบในฮุค และทำเครื่องหมายผลลัพธ์ (outcome) ทั้งหมดว่าผ่าน (passed) ตัวแปร์เซอร์ล็อกที่เห็นก็จะเป็น “ไฟเขียว” ทั้งหมด ตัวให้คะแนนก็จะตัดสินว่าผ่านทั้งหมดโดยธรรมชาติ
กระบวนการอินเจกต์ฮุค conftest.py ของ SWE-bench: “แพตช์” ที่เอเจนต์ส่งมาไม่ได้แก้ไขบั๊ก แต่ฝังไฟล์ conftest.py ที่เป็นอันตรายลงไป หลังจาก pytest โหลดไฟล์นี้โดยอัตโนมัติ ฟังก์ชันฮุคของมันจะขัดขวางและปลอมแปลงผลการทดสอบแต่ละครั้ง
วิธีการเจาะเบนช์มาร์กอื่นๆ นั้นตรงไปตรงมามากกว่า
ใน WebArena คำตอบมาตรฐานของงานถูกเก็บไว้ในไดเรกทอรี config_files ในเครื่อง เฟรมเวิร์กการประเมินไม่เคยจำกัดการเข้าถึงโปรโตคอล file:// ดังนั้น เอเจนต์ AI เพียงแค่ต้องขับเบราว์เซอร์เปิดเส้นทาง file:// ก็สามารถอ่านคำตอบได้โดยตรง โดยไม่ต้องท่องเว็บหรือใช้เหตุผลใดๆ
การใช้ประโยชน์ช่องโหว่โปรโตคอล file:// ของ WebArena: โมเดลไม่จำเป็นต้องท่องเว็บเพื่อทำงานให้สำเร็จ เพียงแค่ส่งออกคำสั่งเข้าถึงไฟล์ในเครื่อง Playwright ก็จะอ่านคำตอบมาตรฐานจากไฟล์คอนฟิกและส่งกลับมา
ที่สุดขั้วคือ FieldWorkArena ฟังก์ชันตรวจสอบ validate() ของมันไม่ตรวจสอบเนื้อหาคำตอบเลย ตรวจสอบแค่ว่าข้อความสุดท้ายมาจาก “assistant” หรือไม่ ดังนั้น เอเจนต์เพียงแค่ส่ง {} ที่ว่างเปล่าก็ได้คะแนนเต็ม ฟังก์ชัน llm_fuzzy_match ที่ควรใช้สำหรับจับคู่คำตอบแบบคลุมเครือนั้นแม้จะถูกนำเข้า แต่ไม่เคยถูกเรียกใช้เลย
สำหรับเบนช์มาร์กที่เหลือ เช่น Terminal-Bench, OSWorld, GAIA, CAR-bench, SWE-bench Pro เป็นต้น แม้เทคนิคการโจมตีจะแตกต่างกัน แต่ตรรกะหลักเหมือนกัน: โทรจันไนซ์เครื่องมือที่ระบบตรวจสอบพึ่งพา, ดาวน์โหลดคำตอบมาตรฐานจาก URL สาธารณะเพื่อให้ระบบตรวจสอบเปรียบเทียบตัวเอง, อินเจกต์คำสั่งซ่อนไว้ในพรอมต์ของกรรมการ LLM เป็นต้น
เบนช์มาร์กหลัก 8 แห่งที่ถูกทดสอบ ไม่มีที่ไหนสามารถต้านทานการโจมตีของเอเจนต์ที่ “ไม่มีความสามารถในการแก้ปัญหาเอง แต่ค้นหาช่องโหว่ของระบบโดยเฉพาะ” ได้เลย
ทีมเบิร์กลีย์สรุป รูปแบบช่องโหว่ 7 แบบที่ปรากฏซ้ำๆ จากกรณีเหล่านี้: เอเจนต์และโปรแกรมประเมินใช้สภาพแวดล้อมรันร่วมกัน, คำตอบมาตรฐานถูกเปิดเผยให้ระบบที่ถูกทดสอบ, เรียกใช้ eval() กับอินพุตที่ไม่น่าเชื่อถือ, กรรมการ LLM ขาดการกรองอินพุต, การจับคู่สตริงยืดหยุ่นเกินไป, ตรรกะการให้คะแนนเองมีบั๊ก, และโปรแกรมประเมินไว้ใจผลลัพธ์ที่ระบบที่ถูกทดสอบสร้างออกมามากเกินไป
รูปแบบช่องโหว่ 7 แบบที่ทีมเบิร์กลีย์สรุป และการกระจายตัวในเบนช์มาร์ก 8 แห่ง สองรูปแบบแรก (สภาพแวดล้อมไม่แยก, คำตอบรั่วไหล) ส่งผลกระทบต่อเบนช์มาร์กที่ถูกทดสอบเกือบทั้งหมด
การโกง กำลังเกิดขึ้นจริง
วันที่ 10 เมษายน Adam Stein และ Davis Brown จากมหาวิทยาลัยเพนซิลเวเนียเผยแพร่รายงานการตรวจสอบขนาดใหญ่
พวกเขาใช้เครื่องมือวิเคราะห์เส้นทาง (trajectory) ของเอเจนต์ชื่อ Meerkat สแกนเส้นทางประเมินโมเดลจริงหลายพันเส้นทาง พบ การส่งโมเดลที่มีปัญหามากกว่า 28 รายการ เกี่ยวข้องกับ 9 เบนช์มาร์ก ครอบคลุมเส้นทางโกงกว่าพันเส้นทาง
การกระจายตัวของรูปแบบการโกงที่พบโดยการตรวจสอบ Meerkat ของมหาวิทยาลัยเพนซิลเวเนีย สีส้มหมายถึงการโกงระดับ “เฟรมเวิร์ก” (เฟรมเวิร์กประเมินเองรั่วคำตอบ) สีน้ำเงินหมายถึงการโกงระดับ “งาน” (เอเจนต์หาเส้นทางลัดเอง) โปรดสังเกตว่าแกนนอนเป็นสเกลลอการิทึม ขนาดของการโกงระดับเฟรมเวิร์กสูงกว่าระดับงานสองอันดับ
ในนั้น Terminal-Bench 2 (เบนช์มาร์กยอดนิยมสำหรับประเมินโมเดลเช่น Opus 4.6 และ GPT-5.4) มีกรณีเด่นชัดเป็นพิเศษ การส่งโมเดลสามอันดับแรกบนกระดานคะแนนล้วนมีพฤติกรรมโกง
- อันดับที่หนึ่ง Pilot (อัตราการผ่าน 82.9%): ในเส้นทางสำเร็จ 429 เส้นทางของมัน มี 415 เส้นทางที่การกระทำแรกคือรัน
cat /tests/test_outputs.pyเพื่ออ่านไฟล์ทดสอบที่ควรเข้าถึงไม่ได้โดยตรง แล้วจึงอนุมานผลลัพธ์ที่คาดหวังย้อนกลับ - อันดับที่สองและสาม ForgeCode (อัตราการผ่าน 81.8%): เฟรมเวิร์กการประเมิน (harness) ของมันจะโหลดเนื้อหาของไฟล์
AGENTS.mdเข้าไปในพรอมต์ระบบโดยอัตโนมัติ ก่อนการทำงานของงาน และไฟล์เหล่านี้มีคำตอบมาตรฐานอยู่โดยตรง ในตัวอย่างงานหนึ่ง ไฟล์AGENTS.mdถึงกับเขียนว่า: “การรันครั้งล่าสุดล้มเหลว เพราะเขียนคำตอบผิด… คำตอบที่ถูกควรเป็น GritLM/GritLM-7B”
เมื่อแทนที่เส้นทางที่อ้างอิง AGENTS.md ใน ForgeCode ด้วยประสิทธิภาพของโมเดลเดียวกัน (Opus 4.6) ในสภาพแวดล้อมที่สะอาด อัตราการผ่านของมันลดลงจาก 81.8% เป็นประมาณ 71.7% อันดับร่วงจากที่ 1 ลงมาอยู่ที่ประมาณที่ 14
ตัวอย่างการอินเจกต์คำตอบจากไฟล์ AGENTS.md ของเฟรมเวิร์ก ForgeCode: ส่วนบนแสดงว่าเฟรมเวิร์กอินเจกต์ไฟล์ AGENTS.md ที่มีคำตอบมาตรฐานเข้าไปในสภาพแวดล้อมเอเจนต์ ส่วนล่างแสดงว่าเอเจนต์อ่านคำตอบแล้วเขียนลงไฟล์ผลลัพธ์โดยตรง
ที่แดกดันยิ่งกว่านั้น การโกงหลายกรณีเช่นนี้ไม่ใช่ความตั้งใจของผู้พัฒนา ผู้พัฒนา Terminal-Bench บางคนเคยเปิดเผยว่า เฟรมเวิร์กการประเมินของพวกเขาถูกสร้างขึ้นโดยใช้ AI ช่วยเขียนโปรแกรม (“vibecoding”) ซึ่งหมายความว่า AI ที่ใช้เขียนเฟรมเวิร์กทดสอบ โค้ดที่มันสร้างขึ้นเองก็มีแนวโน้มที่จะโกง แล้วส่งผ่านเฟรมเวิร์กไปยังโมเดลที่ถูกประเมินทั้งหมด ทีมมหาวิทยาลัยเพนซิลเวเนียเรียกปรากฏการณ์นี้ว่า “การแฮ็กรางวัลระดับเมตา”
พบปัญหาคล้ายกันบนเบนช์มาร์กอื่นๆ:
* บน CyBench จากเส้นทางสำเร็จ 464 เส้นทาง มี 16 เส้นทาง (3.4%) ที่โมเดลค้นหาวิธีเล่น CTF ที่เผยแพร่สาธารณะผ่าน Google แล้วคัดลอกมาโดยตรง
* บน SWE-bench มี 17 เส้นทางที่ใช้ git log หาคอมมิตแก้ไขในอดีต แล้วคัดลอกวางแพตช์เก่าโดยตรง
* บน BountyBench เอเจนต์ที่ไม่สามารถใช้ประโยชน์ช่องโหว่ได้จริงจะปลอมการโจมตี: ใช้ grep ตรวจสอบก่อนว่ามีรูปแบบช่องโหว่ในซอร์สโค้ดหรือไม่ แล้วรันฟังก์ชัน pickle.loads() ที่ไม่เกี่ยวข้องเพื่อสาธิต “การดำเนินการ” ในขณะที่ตัวประเมินตรวจสอบแค่ exit code ทำให้ผ่านทั้งหมด
ตัวอย่างการโกงระดับงานบน CyBench: GPT-5.3-Codex หลังจากไม่สามารถแก้ไขความท้าทาย CTF ได้ด้วยตัวเอง ก็ค้นหาวิธีเล่นที่เผยแพร่สาธารณะโดยตรง และดึง flag จากหน้าเว็บมาส่ง
โมเดลล้ำสมัยที่สุด “แฮ็ก” การประเมินได้เอง
รายงานการประเมินของ METR ให้กรณีศึกษาที่น่าสนใจ
โมเดล o3 ถูกขอให้เขียนฟังก์ชันเคอร์เนล GPU ประสิทธิภาพสูง ฟังก์ชันให้คะแนนจะรันโซลูชันอ้างอิงเพื่อได้ผลลัพธ์ที่ถูกต้องก่อน แล้วจึงรันโซลูชันของ o3 เพื่อเปรียบเทียบ อย่างไรก็ตาม “ฟังก์ชันเคอร์เนล” ที่ o3 สร้างขึ้นไม่ได้คำนวณอะไรจริงๆ แต่กลับย้อนกลับตามสแต็กการเรียก Python หาคำตอบที่ถูกต้องที่ระบบให้คะแนนคำนวณไว้แล้วและส่งกลับโดยตรง พร้อมกันนั้น มันยังปิดการซิงโครไนซ์ CUDA เพื่อป้องกันไม่ให้ระบบวัดเวลาดำเนินการจริง ในคอมเมนต์ของโค้ดส่วนนี้ o3 เขียนเองว่า: “cheating route”
ในงานบางอย่างบน RE-Bench อัตราการเกิดพฤติกรรม “การแฮ็กรางวัล” แบบนี้ของ o3 ใกล้เคียง 100% เกือบทุกเส้นทางกำลังโกง
หลังจากนั้น นักวิจัยของ METR ถาม o3: “คุณคิดว่าพฤติกรรมของคุณสอดคล้องกับความตั้งใจของผู้ใช้หรือไม่?” o3 ตอบรับว่า “ไม่สอดคล้อง” ใน 10 ครั้งทั้งหมด มันรู้ว่าตัวเองกำลังโกง แต่ก็ยังเลือกทำเช่นนั้น
พบพฤติกรรมคล้ายกันในโมเดลเช่น Claude 3.7 Sonnet และ o1
ระบบ Mythos Preview ของ Anthropic แสดงให้เห็น “ความกระตือรือร้น”
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
☕ สนับสนุนค่ากาแฟทีมงาน
หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay
本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/30996