งานตรวจสอบ preregistered 52,988 คำขอสรุปว่า "ชื่อโมเดล" ไม่ใช่เครื่องมือวัดที่นิ่ง — ส่งคำขอเดิมทุกไบต์ซ้ำวันถัดมาได้อันดับตรงกันแค่ 0.78 จากเกณฑ์ 0.99 และผู้เขียนบอกเองว่าความรุนแรงส่วนหนึ่งเขาสร้างขึ้นมาเอง

เมื่อ 3 กันยายน 2026 Haoyuan Zhu (School of Electronic and Electrical Engineering, University of Sheffield) และ Jie Zhang (Ranplan Wireless Network Design / Cambridge AI+) เผยแพร่ arXiv:2609.04198 — เปเปอร์ที่ไม่ได้รายงานผลการวิจัยที่ตั้งใจจะทำ แต่รายงานความล้มเหลวของเครื่องมือวัดที่ทำให้งานวิจัยนั้นเดินต่อไม่ได้

ทีมตั้งโครงการที่ลงทะเบียนล่วงหน้า (preregistered) เพื่อวัดว่าผู้สังเกตการณ์ LLM อ่าน “ความคืบหน้าของการแก้โจทย์” จากร่องรอยการให้เหตุผลบางส่วนได้ไหม โดยตั้งเกณฑ์ตรวจรับเครื่องมือไว้ก่อนยิงคำขอที่เสียเงินสักคำขอ ทั้งสองแคมเปญไม่ผ่านด่านตรวจรับเครื่องมือ จึงไม่เคยได้ทดสอบสมมติฐานทางวิทยาศาสตร์ของตัวเองเลย และเปเปอร์นี้คือการตีพิมพ์ความล้มเหลวนั้นทั้งก้อน

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

สองด่านที่ตั้งไว้ก่อน และตัวเลขที่ได้จริง

แคมเปญ	สิ่งที่วัด	เกณฑ์ที่แช่แข็งไว้ก่อน	ค่าที่วัดได้
I0-S	อันดับซ้ำภายในหน้าต่างเวลาเดียวกัน	Spearman ≥ 0.90	0.400
I0-R	รีเพลย์คำขอที่เหมือนกันทุกไบต์ในวันถัดมา	ตรงกัน ≥ 0.99	0.78

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

ทีมยังระบุเองว่าตัวเลข 52,988 คือ audit volume ไม่ใช่ sample size — การวิเคราะห์จริงตั้งอยู่บน 31 task group ที่ใช้ได้, คู่รีเพลย์ 100 คู่, สิบหน้าต่างต่อแขนเสริมแต่ละแขน และคำตัดสินบนข้อผิดพลาดที่สร้างขึ้น 3,060 ชิ้น การเขียนแบบนี้ตรงข้ามกับสไตล์เปเปอร์ที่เอาเลขคำขอรวมมาพาดหัวเพื่อให้ดูใหญ่

สามกลไก และการรักษาสองแบบที่ไม่ได้ผล

กลไก	คืออะไร
M1 — อคติของการแม็ปป้ายไปยังความหมาย	เมื่อโจทย์เสนอคำตอบเป็น “A” หรือ “B” ผู้สังเกตชอบป้ายหนึ่งโดยไม่เกี่ยวกับความถูกต้อง ค่าวินิจฉัยแตะ 1.391 logits ที่เปอร์เซ็นไทล์ที่ 95 ซึ่งแรงพอ ๆ กับสัญญาณที่ต้องการวัด และอันดับจากการแม็ปไปหน้ากับแม็ปกลับหลังตรงกันแค่ Spearman 0.211
M2 — ช่องว่างระหว่างผู้เข้าแข่งขันเล็กกว่าพื้นสัญญาณรบกวน	ระยะห่างของคะแนนมีค่ามัธยฐาน 3×10⁻¹⁰ ขณะที่พื้นสัญญาณรบกวนของเครื่องมืออยู่ที่ 10⁻³–10⁻² คือต่ำกว่ากันเจ็ดลำดับขนาด
M3 — ความไม่กำหนดแน่นอนของแพลตฟอร์ม	อินพุตที่เหมือนกันทุกไบต์คืนอันดับต่างกัน บนเอนด์พอยต์เดียวกันโดยเมทาดาทาคงที่ สืบไปถึงการจัดคิวเคอร์เนลที่ขึ้นกับขนาดแบตช์

ทางออกสองทางที่ทุกคนคิดถึงก่อน ถูกปิดทั้งคู่

• เปลี่ยนเมตริก — permutation ที่เพี้ยน 22 ชุดเดียวกัน อ่านได้ 0.780 (เทียบอันดับเต็ม), 0.950 (top-1) หรือ 0.986 (แบบคู่) ไม่มีเมตริกไหนหนีเกณฑ์ที่ลงทะเบียนไว้ได้
• สุ่มเพิ่ม — จำลองการออกแบบที่สุ่มแปดครั้งต่อจุดวัด ถึง M=500 รวม 748,000 คำขอ ผ่าน 0 จาก 500 รอบจำลอง เพราะการเสมอกันแบบเป๊ะ (พบใน 12 จาก 32 task group) ไม่มีขนาดตัวอย่างเท่าไรก็แก้ไม่ได้

แล้ววิธีที่วิศวกรมักแนะนำล่ะ

ทีมทดสอบทางออกยอดนิยมสามข้อแบบลงทะเบียนล่วงหน้า และผลออกมาแตกต่างจากสามัญสำนึกทั้งหมด

“รอข้ามวันแล้วค่อยวัดใหม่” — เทียบในวันเดียวกับข้ามวัน 1,000 คำขอสองวัน ได้ค่ามัธยฐาน 0.805 (วันเดียวกัน) กับ 0.800 (ข้ามวัน) ต่างกัน 0.005 ซึ่งอยู่ในแถบสมมูลที่ตั้งไว้ พูดอีกอย่างคือ ค่า 0.78 ที่ทำให้ด่านที่สองล้ม อยู่ในการกระจายของ “วันเดียวกัน” อยู่แล้ว — ปัญหาไม่ได้เกิดจากการรอ

“ย้ายไปผู้ให้บริการอื่น” — ยิงชุดตรวจ 100 โพรบเดียวกันไปที่สี่ผู้ให้บริการในสามเขตอำนาจศาล (deepseek-v4-flash, mistral-small-2603, gpt-4.1 ซึ่งคืนสแนปช็อต gpt-4.1-2025-04-14 ทุกครั้ง และ qwen3.7-plus-2026-05-26 เป็นสมอ) รวม 4,000 คำขอ ได้ค่ามัธยฐาน 0.74 ถึง 0.88 ทุกราย และที่สำคัญกว่านั้น: ฟิลด์ system_fingerprint ทำนายความเสถียรไม่ได้ โดยพบความล้มเหลวสามรูปแบบต่างกัน

“โฮสต์เอง” — โมเดลโอเพนเวตบนสแตกที่ใช้เคอร์เนลแบบ batch-invariant ได้ 0.987 ตอนเซิร์ฟเวอร์ว่าง แต่พอมีโหลดพร้อมกัน ความไม่ตรงกันเพิ่มขึ้น 8.4 เท่า ลงมาเหลือ 0.893 คือกลับมาอยู่ระดับเดียวกับเอนด์พอยต์ที่ใช้ร่วมกัน — ทีมระบุเองว่าผลนี้สนับสนุนแค่ความเพียงพอ (แรงกดดันจากแบตช์ทำให้เกิดความไม่นิ่งระดับนี้ได้) ไม่ใช่การระบุสาเหตุ ว่าพื้นของเอนด์พอยต์ร่วมเกิดจากแบตช์ ซึ่งเปเปอร์ไม่เคยอ้าง

ส่วนที่เปเปอร์ยอมรับเอง และเป็นเหตุผลที่ห้ามอ่านพาดหัวอย่างเดียว

นี่คือย่อหน้าที่ทำให้เปเปอร์นี้น่าเชื่อถือ และมันอยู่ในเปเปอร์เอง ไม่ใช่ข้อสังเกตจากภายนอก

ความเสื่อมสภาพของ M2 ถูกสร้างขึ้นโดยการออกแบบโจทย์ของทีมเอง ไม่ใช่ธรรมชาติของ LLM-as-judge ในการทดลอง ความแม่นของผู้เข้าแข่งขันอยู่ที่ 0.781 และมีเพียง 16.25% ของ task group ที่มีคำตอบถูกผิดคละกัน แปลว่าใน ราว 84% ของกลุ่ม ไม่มีอะไรให้จัดอันดับเลย — คำตอบทั้งสี่ตัวถูกหรือผิดเหมือนกันหมด ผู้เขียนเขียนตรง ๆ ว่า “ไปป์ไลน์ผู้ตัดสินที่ใช้งานจริงซึ่งมีผู้เข้าแข่งขันแยกกันชัดเจน ไม่จำเป็นต้องเกิดการล่มสลายของอันดับรุนแรงขนาดนี้”

ข้ออ้างที่พวกเขาปกป้องจึงแคบกว่าพาดหัว: “ด่านที่วัดอันดับมีความหมายก็ต่อเมื่อเทียบกับการกระจายของช่องว่างที่วัดได้จริงของสิ่งที่ถูกวัด และการศึกษาที่ยังไม่ได้วัดการกระจายนั้นย่อมไม่รู้ว่าตัวเองอยู่ในระบอบไหน” — อันตรายที่ถ่ายทอดได้คือความไม่รู้ ไม่ใช่ตัวเลข 0.400

เปเปอร์ยังจำกัดขอบเขตอีกสองชั้น: หลักฐานกลไก M1/M2 มาจากผู้สังเกตตระกูลเดียว (qwen3.7-plus) บนเอนด์พอยต์เดียว โจทย์ตระกูลเดียว (เลขคณิตจำนวนตรรกยะที่มีคำตอบมาตรฐาน) เทมเพลตพรอมป์เดียว และภาษาเดียว ส่วนผลทั้งหมด “ไม่พูดถึงกลไกภายในของโมเดล และไม่ใช่การประเมินคุณภาพบริการของผู้ให้บริการรายใด”

สิ่งที่ทีมเสนอแทนคือ บันได snapshot identity สามระดับ (L0 = รู้แค่ชื่อโมเดล, L1 = ผู้ให้บริการปักน้ำหนักให้, L2 = โฮสต์เองด้วยเคอร์เนล batch-invariant), กฎออกแบบแปดข้อ และเช็กลิสต์การรายงาน โดยข้อที่นำไปใช้ได้ทันทีคือ ทำ pilot ก่อนแช่แข็งเกณฑ์ — เปเปอร์ตีราคาไว้ว่า pilot ที่ราว 2% ของปริมาณคำขอในงานนี้ (ราวหนึ่งพันคำขอ) จะเปิดโปงว่าทั้งสองด่านเป็นไปไม่ได้ตั้งแต่แรก

มุมมอง AI Curator

เรื่องนี้ต้องอ่านคู่กับการเปลี่ยนสูตร Intelligence Index ของ Artificial Analysis เมื่อวานนี้ แล้วภาพจะครบ: ที่นั่นอันดับขยับเพราะตะกร้าเบนช์มาร์กเปลี่ยน ที่นี่อันดับขยับทั้งที่ไม่มีอะไรเปลี่ยนเลยแม้แต่ไบต์เดียว สองอย่างนี้ไม่ใช่เรื่องเดียวกัน แต่มันชี้ไปที่รากเดียวกัน — ตัวเลขที่เราใช้ตัดสินใจว่าจะใช้โมเดลไหนมีความคลาดเคลื่อนที่ไม่เคยถูกรายงานมาพร้อมกับตัวเลข

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

ข้อค้นพบที่ควรทำให้คนวางระบบสะดุ้งที่สุดคือ system_fingerprint ทำนายอะไรไม่ได้ ฟิลด์นั้นถูกใส่มาเพื่อให้ผู้ใช้ตรวจสอบความสามารถในการทำซ้ำได้ และการวัดตรงพบว่ามันทำหน้าที่นั้นไม่ได้ในสามรูปแบบต่างกัน ใครที่เขียนสมมติฐานว่า “fingerprint เหมือนเดิม = พฤติกรรมเหมือนเดิม” ลงในเอกสารการทดลองของตัวเอง ควรกลับไปลบสมมติฐานนั้นออก

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

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

แหล่งข่าว

• arXiv:2609.04198 — Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints
• ฉบับ HTML เต็ม (ตาราง กลไก M1–M3 และภาคผนวก)
• Artificial Analysis เปลี่ยนสูตร Intelligence Index เป็น v4.2 — บทความของเรา 5 ก.ย.