GPT-5.5 vs GPT-5.4 vs Opus 4.7 - เปรียบเทียบเบนช์มาร์กงานเขียนโค้ดจริง 56 งาน

• เปิดเผยผลเบนช์มาร์กที่เปรียบเทียบคุณภาพแพตช์ของสามโมเดล ได้แก่ GPT-5.5, GPT-5.4 และ Opus 4.7 กับ งานเขียนโค้ดจริง 56 งาน ที่ดึงมาจากโอเพนซอร์สรีโพ 2 แห่ง (Zod, graphql-go-tools)
• GPT-5.5 ทำคะแนนสูงสุดในทุกตัวชี้วัด ได้แก่ อัตราการผ่านเทสต์, ความเทียบเท่ากับแพตช์ที่มนุษย์เขียน, และ อัตราการผ่านโค้ดรีวิว (clean pass)
• Opus 4.7 สร้างแพตช์ที่เล็กที่สุดและมี footprint risk ต่ำ แต่มีรูปแบบความล้มเหลวแบบทำงานไม่ครบจากการพลาดงานประกอบที่ต้องทำร่วมกันซ้ำ ๆ
• การผ่านเทสต์เพียงอย่างเดียวไม่เพียงพอสำหรับตัดสินคุณภาพแพตช์ และจำเป็นต้องมีการประเมินหลายชั้นที่รวมถึง การยอมรับจากผู้รีวิว
• อันดับของโมเดลเดียวกันเปลี่ยนไปตามรีโพ ดังนั้นการ รันเบนช์มาร์กบนโค้ดเบสของตัวเอง คือหัวใจสำคัญในการเลือกโมเดล

---

ภาพรวมเบนช์มาร์กและสภาพแวดล้อมการรัน

• เปรียบเทียบสามโมเดลกับ งานเขียนโค้ดจริงรวม 56 งาน: 27 งานจาก Zod และ 29 งานจาก graphql-go-tools
• แต่ละโมเดลรันด้วยค่าเริ่มต้นบน agent harness อย่างเป็นทางการของตนเอง: Opus 4.7 ใช้ Claude Code ส่วน GPT-5.4 และ GPT-5.5 ใช้ OpenAI Codex CLI
• กำหนด reasoning level ของทุกโมเดลให้เป็น high เหมือนกัน
• ใช้เฟรมเวิร์กประเมิน Stet เพื่อให้คะแนนหลายชั้นนอกเหนือจากการผ่านเทสต์ เช่น ความเทียบเท่าด้านพฤติกรรม, การยอมรับจากโค้ดรีวิว, footprint risk, และรูบริกด้าน craftsmanship และ discipline
• รันเพียง 1 ครั้งต่อ 1 งานด้วย single seed และใช้ GPT-5.4 เป็นโมเดลตัดสินความเทียบเท่าและรูบริก

สรุปผลรวมทั้งหมด

• GPT-5.5 ได้ ผ่านเทสต์ 38/56, ความเทียบเท่ากับแพตช์มนุษย์ 40/56, และ clean pass 28/56 เป็นอันดับ 1 ทุกตัวชี้วัด
• Opus 4.7 ผ่านเทสต์ 33/56, เทียบเท่า 19/56, clean pass 10/56 เป็นโมเดลที่ได้คะแนนคุณภาพต่ำสุด
  • อย่างไรก็ตาม มี ค่า footprint risk เฉลี่ย 0.20 ต่ำที่สุด จึงได้เปรียบในด้านขนาดแพตช์
• GPT-5.4 ผ่านเทสต์ 31/56, เทียบเท่า 35/56, clean pass 11/56
  • มี ต้นทุน $2.39 ต่องาน ต่ำที่สุด แต่ยังไม่เพียงพอจะชดเชยช่องว่างด้าน clean pass
• GPT-5.5 ใช้เวลาเฉลี่ยต่องาน 6 นาที 56 วินาที, ใช้อินพุตโทเคน 201.8M และเอาต์พุตโทเคน 0.72M จึงเป็น อันดับ 1 ด้านประสิทธิภาพ ด้วย

วิเคราะห์ผลตามรายรีโพ

• Zod (27 งาน): GPT-5.5 และ Opus ผ่านเทสต์เท่ากันที่ 12 งาน แต่ GPT-5.5 มี clean pass 10 งาน เทียบกับ Opus 5 งาน จึงเหนือกว่าในคุณภาพรีวิว
  • Opus เหนือกว่าในด้านขนาด diff ทำให้ใน Zod มี trade-off ที่แท้จริง
• graphql-go-tools (29 งาน): GPT-5.5 เหนือกว่าอย่างชัดเจนด้วยการผ่านเทสต์ 26 งาน และ clean pass 18 งาน
  • Opus ผ่านเทสต์ 21 งาน แต่มี clean pass เพียง 5 งาน เพราะกลยุทธ์แพตช์ขนาดเล็กนำไปสู่ การพลาดงานบูรณาการ

ตัวชี้วัดคุณภาพโดยละเอียด

• การผ่านโค้ดรีวิว: GPT-5.5 33/56, GPT-5.4 16/56, Opus 11/56
• ค่าเฉลี่ยโค้ดรีวิว (correctness + bug safety): GPT-5.5 3.08, GPT-5.4 2.59, Opus 2.33
  • correctness เพียงอย่างเดียว: GPT-5.5 3.16 vs GPT-5.4 2.60 vs Opus 2.11
  • ความปลอดภัยจากบั๊กที่เพิ่มเข้ามา: GPT-5.5 3.04 vs GPT-5.4 2.56 vs Opus 2.55
• ค่าเฉลี่ยตัวให้คะแนนแบบคัสตอม (8 รูบริก): GPT-5.5 2.62, GPT-5.4 2.40, Opus 2.33
• คะแนน craftsmanship (clarity/coherence/robustness): GPT-5.5 สูงสุดในทั้งสามหัวข้อย่อย
• คะแนน discipline (scope discipline/diff minimality): GPT-5.5 2.36 นำเล็กน้อย ขณะที่ Opus ได้ 2.20
  • แม้ Opus จะนำในด้าน raw footprint แต่เมื่อวัด discipline แบบเทียบกับงาน GPT-5.5 เหนือกว่า

การผ่านเทสต์ไม่ใช่เกณฑ์ตัดสินสุดท้าย

• ใน Zod นั้น Opus และ GPT-5.5 ผ่านเทสต์เท่ากันที่ 12 งาน แต่ clean pass คือ GPT-5.5 10 งาน vs Opus 5 งาน
• ใน graphql-go-tools รูปแบบเดียวกันยิ่งชัดขึ้น: GPT-5.5 ผ่านเทสต์ 26 งาน/clean pass 18 งาน ขณะที่ Opus ผ่านเทสต์ 21 งาน/clean pass 5 งาน
• กรณี GraphQL PR #1001: ทั้งสามโมเดลผ่านเทสต์และได้ผลตัดสินว่าเทียบเท่ากัน แต่ มีเพียง GPT-5.5 เท่านั้นที่ผ่านโค้ดรีวิว
  • อีกสองโมเดลได้รับคำเตือนเรื่องรูปแบบ API, การเปิดเผย raw HTTP object และความแข็งแรงของขอบเขต hook

ความแตกต่างเชิงรูปธรรมที่เห็นจากโค้ดรีวิว

• งาน async codec และค่าเริ่มต้นของ Zod: ทั้งสามโมเดลล้มเหลวในการผ่านเทสต์
  • Opus แก้ 8 ไฟล์ แต่พลาดความหมายหลัก เช่น การอนุญาต undefined ในค่าเริ่มต้น และยังคงนิยาม codec แบบ synchronous
  • GPT-5.4 แพตช์ 11 ไฟล์และถูกตัดสินว่าเทียบเท่าได้ แต่จำกัด API ข้างเคียงมากเกินไป (prefault)
  • GPT-5.5 ก็ไม่ผ่านเทสต์เช่นกัน แต่ ครอบคลุมพฤติกรรมของ schema/build ได้สะอาดกว่า จึงได้คะแนน correctness และ bug risk สูงสุด
• การตรวจสอบความเข้ากันได้กับ GraphQL Apollo (PR #1169): ทั้งสามโมเดลผ่านเทสต์ แต่ มีเพียง GPT-5.5 ที่ผ่านทั้งความเทียบเท่าและรีวิว
  • Opus แก้ 11 ไฟล์ แต่พลาดการตรวจสอบ enum/leaf ของ wrapped scalar
  • GPT-5.4 แก้ 12 ไฟล์ และขยายขอบเขตเกินไป เช่น เมตาดาต้าการตรวจสอบแบบไม่มีเงื่อนไข
  • GPT-5.5 แก้ 10 ไฟล์ (ไม่ใช่ไฟล์เทสต์ 6 ไฟล์) น้อยที่สุด และยังทำพฤติกรรมเป้าหมายได้ถูกต้อง

ลักษณะและข้อจำกัดของ Opus 4.7

• สร้าง แพตช์ที่อนุรักษ์นิยม แม่นยำ และมี footprint ต่ำ
• เด่นเมื่องานมีขอบเขตเฉพาะจุดและพื้นผิวการเปลี่ยนแปลงแคบ
• รูปแบบความล้มเหลวที่เกิดซ้ำ: ทำเฉพาะพฤติกรรมหลักแต่ ไม่ทำงานประกอบ (companion work) ให้ครบ
  • กรณีต้นไม้คู่ขนาน Node/Deno ของ Zod: Opus แก้ 4 ไฟล์และผ่านเทสต์ แต่ GPT-5.5 แก้ 11 ไฟล์รวมถึงพื้นผิวการปล่อยแบบคู่ขนาน จึงเทียบเท่ากับแพตช์มนุษย์
• ใน graphql-go-tools ปัญหารุนแรงกว่า: ใน PR #1155 (เปลี่ยนหลายพื้นผิวของเอนจิน เช่น repeated scalar field ของ gRPC datasource) Opus ไม่สามารถสร้างแพตช์ได้เลย ขณะที่ GPT-5.5 ผ่านทั้งเทสต์ ความเทียบเท่า และรีวิว
• จุดแยกสำคัญ: แพตช์ขนาดเล็กของ Opus เป็น discipline สำหรับงานเฉพาะจุด แต่กลายเป็น การติดตั้งที่ไม่สมบูรณ์ สำหรับงานบูรณาการ

การเปลี่ยนจาก GPT-5.4 ไปสู่ GPT-5.5

• GPT-5.4 มักหาแนวทางได้ถูก แต่ ล้มเหลวตอนลงมือทำ
  • ใน Zod มีความเทียบเท่า 18 งาน (เท่ากับ GPT-5.5) แต่ผ่านเทสต์เพียง 9 งาน
• GPT-5.5 รักษาพฤติกรรมการบูรณาการที่กว้างกว่าได้ พร้อมกับ สร้างแพตช์ที่พังน้อยลง
• ตัวอย่างเปรียบเทียบที่ชัดเจน:
  • ตัวสร้าง schema→TypeScript: Opus และ GPT-5.5 ใช้วิธี recursive visitor ส่วน GPT-5.4 กลับสร้างไฟล์แนะนำของรีโพ จัดหมวดงานผิดตั้งแต่ต้น
  • การแก้ recursive parser: ทั้งสอง GPT ใช้วิธีติดตามจำนวนครั้งที่เยี่ยมชม แต่ GPT-5.5 ลบ state ที่ไม่จำเป็น จึงกระชับกว่า
  • การตรวจสอบ CIDR: GPT-5.5 อัปเดต Deno mirror ด้วย ส่วน GPT-5.4 ไม่สะท้อนใน mirror (ปัญหาความสะอาดของรีโพ)
• ใน graphql-go-tools PR #1232 (ลบความซ้ำซ้อนของ single fetch แบบเดียวกัน + เขียนอ้างอิง dependency ใหม่): มีเพียง GPT-5.5 ที่ผ่านทั้งเทสต์ ความเทียบเท่า และรีวิว
• สรุปรูปแบบ: GPT-5.5 ทำงานบูรณาการที่น่าเบื่อแต่จำเป็นเพื่อ เปลี่ยนการแก้เฉพาะจุดที่ฉลาดให้กลายเป็นการเปลี่ยนแปลงในรีโพที่พร้อมใช้งานจริง ได้มากกว่า

Trade-off ระหว่างขนาดแพตช์กับต้นทุน

• ขนาดแพตช์เฉลี่ยของ graphql-go-tools: GPT-5.5 ประมาณ 33KB, GPT-5.4 27KB, Opus 19KB
• คะแนน footprint: Opus 0.19, GPT-5.4 0.32, GPT-5.5 0.34
• แพตช์ที่ใหญ่ขึ้นทำให้รีวิวยากขึ้น เพิ่มโอกาสเกิด conflict และเพิ่มความเสี่ยงจากการแตะเส้นทางที่อ่อนไหว
  • สำหรับเวิร์กโฟลว์ที่เน้น auditability นั้น Opus ยังมี ข้อได้เปรียบที่จับต้องได้
• อย่างไรก็ตาม หากประเมิน diff minimality แบบ เทียบกับงานที่ต้องทำจริง GPT-5.5 จะนำเล็กน้อย
  • ประเด็นสำคัญคือ แพตช์ 5KB ที่พลาดพื้นผิวที่จำเป็น ไม่ได้ minimal กว่าแพตช์ 20KB ที่ทำงานครบ
• การเปรียบเทียบต้นทุน:
  • ใน Zod ค่าใช้จ่ายของ Opus และ GPT-5.5 ใกล้เคียงกัน (Opus $45.53 vs GPT-5.5 $46.69)
  • ใน graphql-go-tools นั้น Opus ใช้อินพุตโทเคน 186.1M/เอาต์พุต 934K/เวลาเอเจนต์ 8.56h ส่วน GPT-5.5 ใช้ 151.4M/431K/4.16h ทำให้ GPT-5.5 มีประสิทธิภาพกว่ามาก

สรุปลักษณะพฤติกรรมของแต่ละโมเดล

• Opus 4.7 — under-reach: อนุรักษ์นิยม แม่นยำ footprint ต่ำ เด่นกับงานเฉพาะจุด แต่เปราะในพื้นผิวประกอบที่เทสต์ครอบคลุมไม่หมด โดยโหมดล้มเหลวคือ “ผ่านเทสต์ แต่ไม่ใช่การเปลี่ยนแปลงแบบเดียวกัน”
• GPT-5.4 — รูปแบบถูก การลงมือผิด: ทิศทางถูกแต่ไม่สม่ำเสมอ มีแพตช์ที่ใช้ mirror เก่า รีแฟกเตอร์เกินจำเป็น และมักได้คะแนนจากตัวตัดสินดีกว่าผลเทสต์อยู่บ่อยครั้ง
• GPT-5.5 — กว้างกว่า footprint ใหญ่กว่า: สมบูรณ์กว่าบนพื้นผิวการบูรณาการ อัปเดตโค้ดรอบข้างได้มากกว่า ผ่านรีวิวได้มากกว่า และแปลงพฤติกรรมที่ตั้งใจไว้เป็นโค้ดจริงได้ดีกว่า โดยความเสี่ยงคือถ้าพลาดก็อาจ พลาดครอบคลุมหลายไฟล์มากกว่า

ความต่างของพฤติกรรมเอเจนต์

• ใน graphql-go-tools นั้น Opus มีการเรียก explicit plan เฉลี่ย 3.17 ครั้งต่องาน ขณะที่ GPT-5.5 คือ 0 ครั้ง
• Opus มีการเรียก patch เฉลี่ย 10.2 ครั้งต่องาน ส่วน GPT-5.5 อยู่ที่ 9.9 ครั้ง ใกล้เคียงกัน
• GPT-5.5 มี การเรียก shell ราว 2 เท่า และเรียก search มากกว่า ขณะที่ Opus ใช้งบประมาณกับการวางแผนและเขียนแพตช์ใหม่มากกว่า
• ในรีโพนี้ การสำรวจรีโพที่กว้างกว่า มีประสิทธิภาพมากกว่าการครุ่นคิดกับแพตช์แคบ ๆ

ทำไมผลลัพธ์นี้จึงสำคัญ

• คำถามหลักไม่ใช่ “โมเดลไหนดีที่สุด” แต่คือ “บนรีโพนี้ ในฮาร์เนสนี้ และกับประเภทงานที่นำไป deploy จริง โมเดลใดให้แพตช์ที่เชื่อถือได้”
• ใน Zod ความสัมพันธ์ระหว่าง GPT-5.5 กับ Opus เป็นแบบ trade-off แต่ใน graphql-go-tools นั้น GPT-5.5 เหนือกว่าแบบชัดเจน
• เบนช์มาร์กสาธารณะมักทำให้พฤติกรรมของโมเดลแบนลงเป็นตัวเลขรวมเพียงตัวเดียว แต่ในโค้ดจริง มันกลายเป็น การตัดสินใจเวิร์กโฟลว์ตามโค้ดเบสและเกณฑ์เฉพาะ

ข้อควรระวัง

• งาน 56 งานยังถือเป็นตัวอย่างขนาดเล็ก และความต่างเพียง 1 งานก็ทำให้อัตราส่วนระดับรีโพเปลี่ยนได้หลายจุด
• ทุกโมเดลรันเพียง 1 ครั้งต่องาน ดังนั้นผลที่สูสีกันบางส่วนอาจกลับด้านได้หากรันซ้ำ
• โมเดลตัดสินความเทียบเท่าและรูบริกคือ GPT-5.4 จึงอาจมีอคติต่อโมเดลในตระกูลเดียวกัน
  • อย่างไรก็ตาม GPT-5.5 ก็ยังนำ GPT-5.4 แบบชัดเจน, ความได้เปรียบด้าน footprint ของ Opus ก็ยังคงอยู่ และความล้มเหลวด้านความเทียบเท่าของ Opus หลายกรณีเกิดจาก การขาดไฟล์ที่ควรแก้แบบชัดเจน จึงไม่อาจอธิบายผลรวมทั้งหมดได้
• ผลลัพธ์นี้ ขึ้นกับ harness: Claude Code และ Codex CLI ต่างกันทั้ง system prompt, planning loop และพื้นผิวเครื่องมือ
  • หากรัน Opus บน Codex API หรือรัน GPT-5.5 บน Claude Code ผลอาจเปลี่ยนได้
  • ตัวเลขชุดนี้สะท้อน พฤติกรรมของโมเดลภายใน harness ที่วิศวกรใช้งานจริง

บทสรุปสำคัญ

• GPT-5.5 คือ โมเดลดีฟอลต์ที่เหมาะที่สุดสำหรับการ deploy บนสองรีโพนี้
• Opus 4.7 ยังคงเป็น โมเดล footprint ต่ำ ที่อาจเหมาะกว่าเมื่อ diff แคบคือสิ่งสำคัญที่สุด
• GPT-5.4 มีต้นทุนต่องานต่ำที่สุด แต่ยังไม่พอจะชดเชยช่องว่างด้าน clean pass
• การดูแค่ผลเทสต์เพียงอย่างเดียวจะ ซ่อนผลลัพธ์ที่สำคัญที่สุด
• อันดับของโมเดลเดียวกันเปลี่ยนไปตามรีโพ และนี่คือ เหตุผลหลักที่ต้องทำเบนช์มาร์กกับรีโพของตัวเอง

[shakespeares]

บางทีก็รู้สึกเหมือนกำลังฮั้วกันอยู่เลยนะ