Fable 5, Opus 4.8 และ Sonnet 4.6: วิธีเปรียบเทียบ LLM บนโค้ดของตัวเองอย่างซื่อตรง

เมื่อมีโมเดลใหม่ออกมา การประกาศเปิดตัวตอบคำถามว่า "มันดีขึ้นแค่ไหนบนเบนช์มาร์ก" — และไม่ตอบคำถามเดียวที่ฉันสนใจ: มันจะเปลี่ยนอะไรในการทำงานของฉัน ฉันได้ทำการทดลองแบบควบคุม: โมเดล Claude สามตัว — Fable 5, Opus 4.8 และ Sonnet 4.6 — ได้รับโจทย์เดียวกันทุกคำในการตรวจสอบโค้ดเบสของบล็อกนี้ แต่ละตัวในสำเนา repo ที่แยกจากกัน พร้อมเกณฑ์การให้คะแนนที่ตกลงไว้ล่วงหน้า บทความนี้มีทั้งระเบียบวิธีที่นำไปทำซ้ำได้บนโปรเจกต์ใดก็ได้ ผลลัพธ์ และแยกต่างหาก — การทดลองล้มเหลวสองครั้งและบทเรียนที่ได้จากมัน

ทำไมเบนช์มาร์กไม่ตอบคำถามของฉัน

เบนช์มาร์กสาธารณะมีสองปัญหา และทั้งคู่เป็นปัญหาระดับรากฐาน ปัญหาแรก — การปนเปื้อนข้อมูล: ตัวอย่างทดสอบรั่วไหลเข้าไปในชุดข้อมูลฝึก และโมเดลก็ "จำ" คำตอบได้บางส่วนแทนที่จะแก้โจทย์ นี่ไม่ใช่ข้อสงสัยชายขอบ แต่เป็นหัวข้อของสาขาการวิจัยทั้งสาขา: บทปริทัศน์ของ Xu และคณะ (2024) จัดระบบงานวิจัยเรื่องการปนเปื้อนของเบนช์มาร์ก และ บทปริทัศน์ EMNLP 2025 บันทึกการตอบสนองของอุตสาหกรรม — การเปลี่ยนจากแบบทดสอบคงที่ไปสู่แบบที่สร้างขึ้นแบบพลวัต

ปัญหาที่สองง่ายกว่า: เบนช์มาร์กไม่ได้วัดโจทย์ของฉัน ฉันไม่ต้องการโมเดลที่แก้โจทย์โอลิมปิกได้เก่งที่สุด ฉันต้องการโมเดลที่หา bug จริงในบล็อก Laravel ของฉันได้ ไม่แต่งเรื่องที่ไม่มีอยู่ และพิสูจน์ได้ว่าการแก้ของมันได้ผล

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

การออกแบบการทดลอง: พรอมป์เดียว สามโลกที่แยกจากกัน

โจทย์สำหรับทั้งสามโมเดลเหมือนกันทุกคำ — ต่างกันแค่ชื่อ branch และโฟลเดอร์ผลลัพธ์ สี่เฟส: ตรวจสอบระบบบทความสองภาษาของบล็อกพร้อมหลักฐานของแต่ละสิ่งที่พบในรูปของ файл:строка พร้อมอ้างโค้ด; เลือกแนวทางแก้สำหรับสิ่งที่พบหลักสามอย่างพร้อมอธิบายข้อแลกเปลี่ยน; ลงมือแก้หนึ่งอย่างพร้อมตรวจสอบตัวเอง; บันทึกผลลัพธ์เป็นภาษารัสเซียและอังกฤษ วงจรงานวิศวกรรมเต็มรูปแบบ ไม่ใช่ "ถาม-ตอบ" แยกส่วน — แนวทางนี้ Anthropic ก็แนะนำ: ประเมินเอเจนต์บนโจทย์จากผลิตภัณฑ์จริง ตามเกณฑ์ที่ตกลงกันก่อนเริ่ม

กฎสามข้อทำให้การเปรียบเทียบซื่อตรง:

การแยกจากกัน. แต่ละโมเดลทำงานใน git worktree แยกต่างหาก — สำเนาของไดเรกทอรีทำงานของตัวเองพร้อม branch ของตัวเอง โมเดลไม่สามารถเห็นผลของกันและกันหรือรบกวนกันได้ในทางกายภาพ

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

การตัดคำใบ้ออกจากการให้คะแนน. ใน repo มีไฟล์ CLAUDE.md ที่อธิบายกับดักที่รู้กันของโปรเจกต์ — เช่น เส้นทางสัมพัทธ์ไปยังแอสเซ็ตที่พังบน URL ที่มีคำนำหน้าภาษา ทั้งสามโมเดลอ่านไฟล์นี้ ดังนั้นสิ่งที่พบเช่นนี้จึง "ฟรี": นับเป็นความรอบคอบ แต่ไม่นับเป็นความลึก

เกณฑ์: ประเมินเฉพาะสิ่งที่ตรวจด้วยมือได้

ก่อนเริ่ม ฉันกำหนดแกนหกแกน แกนละห้าคะแนน: ความแม่นยำของการตรวจสอบ (ตรวจด้วยมือจากตัวอย่างสิ่งที่พบเทียบกับ файл:строка), ความลึก (สิ่งที่พบที่ยืนยันแล้วซึ่งไม่อยู่ในคำใบ้), คุณภาพของการให้เหตุผลเรื่องข้อแลกเปลี่ยน, โค้ดและความเป็นจริงของการตรวจสอบตัวเอง, คุณภาพของข้อความรัสเซียและอังกฤษ, วินัย (ไม่ถามคำถามกับคนเลย ไม่ละเมิดข้อจำกัดแม้แต่ข้อเดียว) หลักการเดียวกับ code review ที่ดี: ยิ่งแกนไหนพึ่งรสนิยมน้อยและพึ่งข้อเท็จจริงที่ตรวจสอบได้มากเท่าไร ก็ยิ่งเชื่อถือได้มากเท่านั้น

ทุกอย่างล้มเหลวครั้งแรกได้อย่างไร

การรันครั้งแรกฉันทำผิด — และนั่นกลายเป็นส่วนที่ถ่ายทอดได้มากที่สุดของการทดลอง ฉันเปิดเซสชันแบบโต้ตอบสามเซสชันพร้อมกันในโฟลเดอร์ repo เดียวกัน ไม่กี่นาทีต่อมาใน working tree ก็มีการแก้ไขที่ยังไม่ commit ซึ่งระบุที่มาไม่ได้: checkout ร่วมกันหมายความว่าเมื่อเซสชันหนึ่งทำ git checkout -bbranch ก็สลับให้ทั้งสาม และการแก้ไขกับ commit ของพวกมันก็ปนกัน เซสชันหนึ่งยังทำ git stash และกวาดทุกอย่างเข้าไป — รวมถึงไฟล์ของฉันเองที่ไม่เกี่ยวกับการทดลอง

“AI agent แบบขนานในโฟลเดอร์เดียวไม่ใช่การทดลองแบบขนาน มันคือความขัดแย้งใหญ่หนึ่งครั้งที่มีผู้เขียนสามคน”

– บทสรุปที่ทำให้ฉันต้องเริ่มใหม่

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

ผลลัพธ์: จุดที่โมเดลเหมือนกันและจุดที่แตกต่าง

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

จากนั้นความแตกต่างก็เริ่มต้น:

	Fable 5	Opus 4.8	Sonnet 4.6
รายการที่ยืนยันแล้ว	11	5	9
รายการที่ไม่ธรรมดาและไม่ซ้ำใคร	3	1	2
การตรวจสอบการแก้ไขด้วยตนเอง	การเรนเดอร์แบบอินทิเกรชันบนฐานข้อมูลชั่วคราว, xmllint, การระบุที่มาของเทสต์ที่ล้มเหลวของผู้อื่น	ลินเตอร์ + การเรนเดอร์; จับบั๊กของตัวเองได้	เฉพาะลินเตอร์และรายการเส้นทาง
โทเคน / เวลา	164k / 21 นาที	101k / 12 นาที	131k / 12 นาที
คะแนนตามรูบริก (จาก 30)	30	24	25.5

ความแตกต่างเชิงคุณภาพให้ข้อมูลมากกว่าคะแนน Opus 4.8 เป็นเพียงตัวเดียวที่ไม่สังเกตเห็นหัวข้อที่เสีย Content-Type ใน sitemap (อีกสองตัวพบ) และปล่อยไว้ในการแก้ไขของตัวเอง; อีกทั้งคำภาษาอังกฤษยังรั่วเข้ามาในข้อความภาษารัสเซียของมัน — «и even путь к картинке» Sonnet 4.6 แก้ไขได้ถูกต้อง แต่การตรวจสอบด้วยตนเองเป็นเพียงการประกาศ: ใช้ลินเตอร์แทนการรัน Fable 5 โดดเด่นในเรื่องการตรวจสอบด้วยตนเอง: ค้นพบว่า php บนเครื่องของผมเป็น wrapper เหนือคอนเทนเนอร์ docker ที่เมานต์ไว้บนไดเรกทอรีหลัก สร้างการตรวจสอบทั้งหมดใหม่ผ่านคอนเทนเนอร์แบบใช้ครั้งเดียว และรันการแก้ไขของตัวเองแบบอินทิเกรชันบนฐานข้อมูลชั่วคราว ความแตกต่างระหว่าง "ฉันทำแล้ว" กับ "ฉันพิสูจน์แล้วว่าทำ" นี่คือแกนที่แยกความแตกต่างได้ดีที่สุดสำหรับงานของเอเจนต์

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

ผู้ตัดสินจากในหมู่ผู้เข้าร่วม

การให้คะแนนตามรูบริกดำเนินการโดย Fable 5 ซึ่งเป็นโมเดลเดียวกับที่เข้าร่วมการเปรียบเทียบ นี่คือช่องโหว่เชิงระเบียบวิธี และต้องพูดตรงๆ: ผู้ตัดสินที่เป็น LLM มักให้คะแนนข้อความของตัวเองสูงกว่าอย่างเป็นระบบ และแนวโน้มนี้ยิ่งแรงขึ้นเมื่อโมเดลจดจำข้อความของตัวเองได้ดีขึ้น ดังที่แสดงใน งานของ Panickssery และคณะที่ NeurIPS 2024. สามารถบรรเทาอคติได้สองวิธี และผมใช้ทั้งสอง: หนึ่ง เลื่อนรูบริกให้ห่างจากแกนรสนิยมไปสู่ข้อเท็จจริงที่ตรวจสอบได้ให้มากที่สุด — ความแม่นยำของบรรทัด ความสมบูรณ์ของการแก้ไข คำภาษาต่างประเทศที่รั่วไหล ไม่ขึ้นกับความชอบของผู้ตัดสิน; สอง ประกาศความขัดแย้งอย่างชัดเจนและมอบแกนที่เป็นข้อถกเถียงให้โมเดลอื่นหรือมนุษย์ตรวจสอบข้าม แกนอัตนัยในผลสรุปของผม — คุณภาพของข้อความ คุณภาพของการให้เหตุผล — ควรอ่านโดยคำนึงถึงข้อแก้ไขนี้

ข้อจำกัดด้านความซื่อสัตย์

หนึ่งรอบต่อโมเดลคือ n=1: ความแตกต่างหนึ่งถึงสองคะแนนไม่มีความหมาย ควรเชื่อถือเฉพาะช่องว่างเชิงคุณภาพ — บั๊กที่พลาดไป ความลึกของการตรวจสอบด้วยตนเอง การทดลองวัดโมเดลสามตัวบนงานเดียวในโดเมนเดียว; «Fable 5 ดีกว่าโดยทั่วไป» ไม่ได้ตามมาจากการทดลองนี้ และควรจำเรื่องต้นทุน: โมเดลระดับท็อปใช้โทเคนมากกว่า 1.6 เท่าและเวลาเกือบสองเท่าของผู้เข้าร่วมที่ประหยัดที่สุด และ โทเคนของมันตามราคา ยังแพงกว่าโดยตัวมันเอง — สำหรับงานประจำ นี่คือข้อโต้แย้งที่มีน้ำหนัก favor โมเดลที่เรียบง่ายกว่า

สิ่งที่ผมเก็บไว้

ระเบียบวิธีสรุปเป็นเช็กลิสต์สั้นๆ ที่ใช้ได้กับทุกโปรเจกต์และทุกโมเดล:

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

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

แหล่งอ้างอิงและแนวทาง

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — การจัดระบบปัญหาการปนเปื้อนของเบนช์มาร์ก; ข้อโต้แย้งหลัก favor การทดสอบบนโค้ดของตัวเอง
• การเปรียบเทียบประสิทธิภาพ LLM ภายใต้การปนเปื้อนข้อมูล: จากการประเมินแบบคงที่สู่แบบพลวัต (EMNLP 2025) — อุตสาหกรรมกำลังก้าวจากการทดสอบแบบคงที่ไปสู่แบบพลวัตอย่างไร; การทดลองของฉันเป็นกรณีเฉพาะของการทดสอบแบบพลวัต
• การทำความเข้าใจ evals สำหรับ AI agents ให้กระจ่าง (Anthropic Engineering, 2026) — แนวปฏิบัติในการประเมิน agents: งานจากผลิตภัณฑ์จริง, rubric ที่ตรวจสอบได้, ความแตกต่างระหว่าง trajectory และผลลัพธ์
• LLM Evaluators ตระหนักและชื่นชอบผลงานที่ตนเองสร้าง (NeurIPS 2024) — ทำไมโมเดลผู้ตัดสินจึงให้คะแนนตนเองสูงเกินไป และจะจัดการกับเรื่องนี้อย่างไร
• รันเซสชันแบบขนานด้วย worktrees (Claude Code Docs) — กลไกมาตรฐานในการแยกเซสชันของ agent ที่ทำงานขนานกัน ซึ่งหากไม่มี การรันการทดลองครั้งแรกก็ล้มเหลว