เมื่อโมเดลในเครื่องแก้สคริปต์ที่เสีย การมีโมเดลตัวที่สอง — ที่โต้แย้งกับตัวแรกแทนที่จะเห็นด้วย — ทำให้คำตอบดีขึ้นจริงไหม? เราสร้างชุดทดสอบเล็ก ๆ ขึ้นมาวัดผลกับบั๊กจากเซิร์ฟเวอร์ในบ้านจริง และผลลัพธ์ชัดพอจะเปลี่ยนมุมมองของเราต่อความแม่นยำของโมเดลขนาดเล็ก
ทุกอย่างที่นี่รันบนฮาร์ดแวร์ของเราเอง โมเดลจึงเป็นตัวที่พอดีกับการ์ดจอระดับผู้บริโภคคู่หนึ่ง ไม่ใช่โมเดลระดับแนวหน้าหลัง API สิ่งที่น่ากังวลกับโมเดลพวกนี้คือความแม่นยำ: การแก้ที่ดูน่าเชื่อ และผ่านการตรวจแบบเร็ว ๆ ได้ด้วยซ้ำ ก็ยังอาจผิดได้ แนวคิดที่เราอยากทดสอบเป็นแนวคิดเก่า — ให้โมเดลสองตัวจากคนละตระกูลต่างเสนอวิธีแก้ แล้วผลัดกันหาจุดบกพร่องในของอีกฝ่ายจนเห็นพ้อง — และคำถามก็เพียงว่ามันช่วยได้มากพอจะคุ้มกับเวลาที่เพิ่มขึ้นหรือไม่
ชุดทดสอบมี 44 เคส แต่ละเคสคือบั๊กจริงจากบ้านหลังนี้: ออโตเมชัน Home Assistant ที่ทำงานตอนที่ไม่ควร สคริปต์เชลล์ที่ล้มเมื่อเจอ set -u ไฟล์ compose ที่มีอัญประกาศโค้ง และการสำรองข้อมูลที่ลบตัวเองเงียบ ๆ เมื่อไดรฟ์หาย ทุกเคสมาพร้อมเวอร์ชันที่เสีย การตรวจที่มองเห็นได้ ที่โมเดลได้รับอนุญาตให้เห็นผลลัพธ์ และ การทดสอบที่ซ่อนไว้ ที่โมเดลไม่เคยเห็นและเป็นตัวตัดสินจริงว่าการแก้นั้นถูกหรือไม่
ช่องว่างระหว่างสองอย่างนี้คือหัวใจทั้งหมด การเปลี่ยนแปลงที่ทำให้การตรวจที่มองเห็นได้ผ่านแต่การทดสอบที่ซ่อนไว้ไม่ผ่านคือ การผ่านแบบหลอก — ชนิดที่อันตราย เพราะมันดูเหมือนเสร็จแล้ว บางเคสเป็นกับดักที่คำตอบที่ถูกคือไม่ต้องแก้อะไรเลยและบอกว่าต้นเหตุอยู่ที่อื่น
มันรันบนเซิร์ฟเวอร์ประมวลผล: การ์ดจอสองใบ โดยมีโมเดลภาษาหนึ่งตระกูลค้างอยู่บนแต่ละใบ จึงไม่ต้องโหลดใหม่ระหว่างรอบ ในรอบศูนย์ โมเดลทั้งสองต่างเสนอวิธีแก้ด้วยตัวเอง และการตรวจที่มองเห็นได้จะรันกับแต่ละข้อเสนอ จากนั้นผลัดกัน — แต่ละตัวอ่านข้อเสนอทั้งสองและสิ่งที่การตรวจบอกเกี่ยวกับมัน ระบุจุดบกพร่องที่เป็นรูปธรรมในของอีกฝ่าย ตอบข้อโต้แย้งต่อของตัวเอง แล้วคงจุดยืนเดิม รับของอีกฝ่าย แก้ไข หรืองดออกเสียง ดำเนินไปถึงห้ารอบหรือจนกว่าจะลงเอยที่การเปลี่ยนแปลงเดียวกัน พรอมต์ถูกเขียนให้ต้านความโอนอ่อนอย่างหนัก เพราะความล้มเหลวที่เห็นชัดคือการที่โมเดลสองตัวสุภาพต่อกันแล้วเห็นพ้องกันในเรื่องไร้สาระ
แต่ละโมเดลตอบทั้ง 44 เคสด้วยตัวเอง พรอมต์เดียวกัน การตั้งค่าเดียวกัน “ถูกต้อง” หมายถึงการทดสอบที่ซ่อนไว้ผ่าน หรือปฏิเสธอย่างถูกต้องในเคสกับดัก ส่วนการผ่านแบบหลอกคือการแก้ที่ผ่านการตรวจที่มองเห็นได้แต่ไม่ผ่านการทดสอบที่ซ่อนไว้
| รุ่น | ขนาด | ถูกต้อง | ผ่านแบบหลอก |
|---|---|---|---|
| Gemma 4 31B | 31B แบบ dense | 33 | 5 |
| Qwen3.8 27B | 27B แบบ dense | 32 | 5 |
| Qwen3.8-Flash-Next 125B | 125B แบบ mixture-of-experts | 31 | 6 |
| Qwen3.8 27B, quant ที่เล็กกว่า | 27B แบบ dense, 3-bit | 30 | 6 |
| Nemotron 3.5 Super VL 120B | 120B แบบ mixture-of-experts | 30 | 6 |
| Nemotron 3.5 Bolt 74B | 74B แบบ mixture-of-experts | 28 | 5 |
| Liquid LFM2.5 24B | 24B แบบ mixture-of-experts | 18 | 7 |
จุดที่น่าทึ่ง: โมเดลใหญ่ไม่ได้นำหน้า ทั้งตัว 120B, 74B และ 125B ต่างได้คะแนนเท่ากับหรือต่ำกว่าโมเดลขนาดกลางสองตัวที่ใส่ลงการ์ดได้พร้อมกัน — และยิ่งใหญ่ก็ยิ่งช้า
คู่ที่เราเลือกไปต่อคือ Qwen3.8 27B และ Gemma 4 31B — สองโมเดลขนาดเล็กที่แข็งแกร่งที่สุดในตาราง — ใบละตัว เลือกจากคนละตระกูลเพื่อไม่ให้มีจุดบอดเดียวกัน เมื่อถกเถียงกัน พวกมันทำได้ ถูกต้อง 38 เคส โดยผ่านแบบหลอก 5 เคส: แซงทุกโมเดลเดี่ยวข้างบน รวมถึงตัวที่ใหญ่กว่าสามถึงสี่เท่า และดีกว่าที่แต่ละตัวทำได้ลำพังอย่างน้อยห้าเคส
ส่วนที่ได้มาจากจุดที่ชัดเจน: ราวหกเคสต่อรอบที่ไม่มีโมเดลไหนแก้ได้ลำพังแต่การถกเถียงทำได้ถูก ขณะที่การถกเถียงแทบไม่เคยพูดให้โมเดลทิ้งคำตอบที่ถูกซึ่งมันมีอยู่แล้ว เรายังลองให้ทั้งสองแบ่งปันเหตุผลภายในฉบับเต็มแทนที่จะเป็นแค่ข้อเสนอ และมันไม่ได้สร้างความต่างที่วัดได้ ต้นทุนอยู่ที่ราวหกครั้งของการเรียกโมเดลและเวลา GPU ห้านาทีต่อเคส
จุดอ่อนที่ต้องยอมรับคือการผ่านแบบหลอกเหล่านั้น ซึ่งแทบไม่ขยับ เมื่อโมเดลทั้งสองลงเอยที่การแก้ที่ผ่านการตรวจแบบตื้น การถกเถียงก็ไม่มีอะไรเป็นรูปธรรมให้โต้แย้งและมักจะยุติลง ขั้นต่อไปจึงคือทำให้การถกเถียงโต้จากหลักฐานแทนถ้อยคำ: การเห็นพ้องในการเปลี่ยนแปลงที่การตรวจไม่ผ่านจะไม่นับ โมเดลจะยอมเฉย ๆ โดยไม่มีอะไรมาสนับสนุนไม่ได้ และ — ส่วนที่น่าสนใจ — แต่ละโมเดลอาจเสนอการทดสอบเล็ก ๆ ของตัวเองที่ harness จะรันจริงกับการแก้ทั้งสอง เพื่อให้ข้ออ้างเกี่ยวกับการแก้ของอีกฝ่ายถูกตรวจสอบแทนที่จะเป็นเพียงคำกล่าวอ้าง เวอร์ชันนั้นกำลังรันอยู่ขณะที่หน้านี้เผยแพร่