GPT-5.5 low vs medium vs high vs xhigh: เส้นโค้งการให้เหตุผลจากงานจริง 26 งานในรีโพซิทอรีโอเพนซอร์ส

 (reddit.com)
5 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อนำ GPT-5.5 Codex ไปรันกับงานจริง 26 งานของ GraphQL-go-tools โดยตั้งค่า low, medium, high, xhigh จะพบว่าความแตกต่างของระดับความพยายามในการให้เหตุผลสะท้อนชัดกว่าในด้านความเทียบเท่าทางความหมายกับแพตช์ที่มนุษย์เขียนและอัตราการผ่านโค้ดรีวิว มากกว่าการดูแค่ว่าผ่านการทดสอบหรือไม่
  • การผ่านการทดสอบอยู่ที่ low 21/26, medium 21/26, high 25/26, xhigh 24/26 แต่ ความเทียบเท่าทางความหมาย เพิ่มจาก 4/26 → 11/26 → 18/26 → 23/26 และการผ่านโค้ดรีวิวก็เพิ่มจาก 3/26 → 5/26 → 10/26 → 18/26
  • high ปรับปรุงทั้งการผ่านการทดสอบ ความเทียบเท่า และการผ่านรีวิวเมื่อเทียบกับ medium โดยมีต้นทุนเฉลี่ยเพิ่มจาก $3.13 เป็น $4.49 หรือ 1.43 เท่า จึงดูเป็นค่าตั้งต้นที่ใช้งานได้จริงที่สุดในชุดข้อมูลนี้
  • xhigh ยกระดับความเทียบเท่าและคุณภาพสำหรับการรีวิวได้มากกว่า high แต่ต้นทุนเฉลี่ยเพิ่มเป็น $9.77 และเวลาในการรันเฉลี่ยเป็น 753.3 วินาที อีกทั้งยังสร้างการแก้ไขเพิ่มในส่วนของ test, fixture และ expected-output มากขึ้น ทำให้ความเสี่ยงด้าน footprint สูงขึ้นด้วย
  • ผลของความพยายามในการให้เหตุผลไม่ได้เพิ่มขึ้นแบบเป็นเส้นตรงในทุกงานเสมอไป โดยบางงาน high ทำได้ดีกว่า xhigh หรือค่าที่สูงกว่ากลับสร้าง implementation ที่ดูน่าเชื่อแต่ผิดพลาดได้ ดังนั้นทีมควรวัดผลบน harness ของตนเองและงานของตนเอง แทนการอิง benchmark กลางเพียงอย่างเดียว

เป้าหมายของการทดลองและวิธีประเมิน

  • รัน GPT-5.5 Codex กับงาน 26 งานในรีโพซิทอรีโอเพนซอร์สเดียวกัน โดยแยกเป็นระดับความพยายามในการให้เหตุผล low, medium, high, xhigh เพื่อเปรียบเทียบไม่เพียงแค่การผ่านการทดสอบ แต่รวมถึงความเทียบเท่าทางความหมายกับ PR ที่มนุษย์ merge แล้วและความสามารถในการผ่านรีวิว
  • รีโพซิทอรีเป้าหมายคือ GraphQL-go-tools ที่พัฒนาด้วย Go และแต่ละงานมาจาก PR หรือคอมมิตที่ถูก merge จริง
  • แต่ละงานประกอบด้วย snapshot ของรีโพซิทอรีที่ตรึงไว้, พรอมป์ตคำขอแก้ไข, และความพยายามหนึ่งครั้งในการสร้างแพตช์ภายใน Docker container
  • Stet จะนำแพตช์ที่สร้างขึ้นไป apply แล้วรันการทดสอบเฉพาะงานใน container ที่แยกออกมาเพื่อตรวจสอบว่าผ่านหรือไม่
  • หลังการทดสอบ ยังมีการประเมินเพิ่มเติมตามเกณฑ์ต่อไปนี้
    • ความเทียบเท่า: แพตช์ที่ผู้สมัครสร้างขึ้นทำให้เกิดการเปลี่ยนแปลงพฤติกรรมแบบเดียวกับแพตช์ต้นฉบับที่มนุษย์ทำไว้หรือไม่
    • ผ่านโค้ดรีวิว: หากพิจารณาความถูกต้อง ความเสี่ยงในการเพิ่มบั๊ก ความสามารถในการบำรุงรักษา และ edge case แล้ว ผู้รีวิวจะยอมรับแพตช์นี้หรือไม่
    • ความเสี่ยงด้าน footprint: เมื่อเทียบกับแพตช์ที่มนุษย์ทำ เอเจนต์ไปแตะโค้ดเพิ่มเติมมากน้อยเพียงใด
    • รูบริกด้าน craftsmanship/discipline: ประเมินความชัดเจน ความเรียบง่าย ความสอดคล้อง ความมีเจตนาชัดเจน ความทนทาน การทำตามคำสั่ง วินัยด้านขอบเขต และการทำ diff ให้น้อยที่สุด
  • โมเดลทั้งหมดถูกรันหนึ่งครั้งต่อหนึ่งงาน ด้วย seed เดียว
  • โมเดล LLM ที่ใช้ตัดสินคือ GPT-5.4 และตัวตัดสินจะเห็นเฉพาะแพตช์กับงาน โดยไม่เห็นว่าแพตช์นั้นมาจากโมเดลหรือระดับการให้เหตุผลใด
  • ตัวอย่างสำคัญมีการตรวจสอบด้วยมือด้วยเช่นกัน แต่ไม่มีการปรับเทียบกับมนุษย์เพิ่มเติมสำหรับชุดงานนี้ จึงควรเชื่อถือ ทิศทางของการเพิ่มขึ้นหรือลดลง มากกว่าคะแนนสัมบูรณ์ค่าเดียว
  • รายละเอียดการรัน
    • โมเดล: GPT-5.5
    • harness: Codex 0.128.0
    • ชุดข้อมูล: งานจริง 26 งานของ GraphQL-go-tools
    • ตัวชี้วัดหลัก: การผ่านการทดสอบ, ความเทียบเท่าทางความหมาย, การผ่านโค้ดรีวิว, ความเสี่ยงด้าน footprint, การประเมินแบบกำหนดเองด้าน craftsmanship/discipline, ต้นทุน และเวลาในการรัน
  • มีกราฟแบบโต้ตอบและการวิเคราะห์เชิงลึกรายงานแยกตามงานที่ https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • ใช้การประเมินแบบเดียวกันนี้กับวงจรวิจัยอัตโนมัติที่ปรับปรุง AGENTS.md ด้วย
    • เอเจนต์จะสร้างข้อเสนอปรับปรุง AGENTS.md สำหรับรีโพซิทอรี จากนั้นรันงานย้อนหลังด้วย Stet แล้ววนซ้ำโดยตรวจหาว่าตรงไหนดีขึ้นหรือแย่ลง

ตัวชี้วัดรวมและการตีความ

  • ตัวชี้วัดโดยรวมแสดงให้เห็นว่าเมื่อเพิ่มความพยายามในการให้เหตุผล ความต่างที่เด่นชัดจะอยู่ที่ ความเทียบเท่าทางความหมาย และ อัตราการผ่านรีวิว มากกว่าการผ่านการทดสอบ
  • ผลลัพธ์สำคัญ
    • การผ่านการทดสอบ: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • เทียบเท่ากับแพตช์ของมนุษย์: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • ผ่านโค้ดรีวิว: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • ค่าเฉลี่ย craftsmanship/discipline: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • ต้นทุนเฉลี่ยต่องาน: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • เวลาในการรันของเอเจนต์เฉลี่ย: low 286.9 วินาที, medium 411.0 วินาที, high 579.0 วินาที, xhigh 753.3 วินาที
  • low และ medium มีผลการผ่านการทดสอบเท่ากันที่ 21/26 แต่ความเทียบเท่าเพิ่มจาก 4/26 เป็น 11/26 และการผ่านรีวิวเพิ่มจาก 3/26 เป็น 5/26
  • เทียบกับ medium แล้ว high ทำให้การผ่านการทดสอบเพิ่มขึ้น +15.4%p, ความเทียบเท่าเพิ่มขึ้น +26.9%p และการผ่านรีวิวเพิ่มขึ้น +19.2%p จึงเป็นช่วงที่เห็นการปรับปรุงเชิงปฏิบัติได้ชัดที่สุด
  • เทียบกับ high แล้ว xhigh มีการผ่านการทดสอบลดลง -3.8%p แต่ความเทียบเท่าเพิ่มขึ้น +19.2%p และการผ่านรีวิวเพิ่มขึ้น +30.8%p
  • สิ่งที่พบคือความพยายามในการให้เหตุผลไม่ได้แค่เปลี่ยนอัตราการผ่านการทดสอบเท่านั้น แต่ยังเปลี่ยน ประเภทของแพตช์ ที่ Codex สร้างขึ้นด้วย
  • benchmark สาธารณะมักตอบเพียงว่าทำงานสำเร็จหรือไม่ในเชิงไบนารี แต่ในการทำวิศวกรรมซอฟต์แวร์จริง ความสามารถในการ merge แพตช์และดูแลรักษาต่อหลังจากนั้นก็สำคัญเช่นกัน
  • Terminal-Bench เน้นปัญหาการเขียนโค้ดที่ยากเป็นหลัก, SWE-bench verified อาจมีความเป็นไปได้ว่าโมเดลเคยเห็นคำตอบแล้ว, และ SWE-bench Pro แม้มีประโยชน์แต่ก็ยังมีลักษณะกว้างทั่วไป
  • สิ่งที่การทดลองนี้สนใจคือ “เอเจนต์ได้ทำการเปลี่ยนแปลงในแบบเดียวกับที่มนุษย์ merge บนโค้ดเบสของฉันหรือไม่” และ “ฉันอยากเป็นเจ้าของแพตช์นี้ต่อไปหลังจากนี้หรือไม่”

จาก low ไป medium: ขยับจาก heuristic ไปสู่การสร้างแบบจำลองโดเมน

  • low และ medium ผ่านการทดสอบเท่ากันที่ 21/26 ดังนั้นถ้าดูแค่ผลทดสอบจะเหมือนสูสีกัน
  • แต่ medium ทำให้ความเทียบเท่าเพิ่มจาก 4/26 เป็น 11/26 และค่าเฉลี่ย craftsmanship/discipline เพิ่มจาก 2.311 เป็น 2.604
  • ในช่วงนี้ หาก วัดแค่การทดสอบ จะพลาดความแตกต่างของระดับความพยายามในการให้เหตุผลไปเกือบทั้งหมด
  • แม้ในแพตช์ที่ผ่าน low ก็มักหยุดอยู่ที่ heuristic หรือ implementation บางส่วน ขณะที่ medium เริ่มขยับไปสู่การจำลองรีโพซิทอรีและความหมายของโดเมนได้ดีขึ้น
  • ตัวอย่าง PR #1297
    • เป็นงานตรวจสอบ nullable external @requires dependency ใน GraphQL Federation
    • หาก required field ที่เป็น nullable กลับมาเป็น null พร้อมกับ error ก็ไม่ควรส่ง entity ที่ปนเปื้อนนั้นต่อไปยัง downstream fetch ที่พึ่งพามัน
    • แก่นของงานนี้ไม่ใช่แค่การเพิ่มเงื่อนไข validation แต่คือการสร้างแบบจำลองกฎ dependency data ของ federation ที่มีความละเอียดอ่อน
    • low ผ่านการทดสอบได้ แต่จัดการการจับคู่ required-field/error แบบ heuristic และพลาด metadata แบบ structured ของ nullable @requires ทำให้ไม่เทียบเท่าและไม่ผ่านรีวิว
    • medium ติดตามออบเจ็กต์ที่ปนเปื้อนและกรอง input ของ downstream fetch จึงผ่านทั้งความเทียบเท่าและรีวิว โดยคุณภาพด้าน craftsmanship/discipline เพิ่มจาก 1.350 เป็น 3.225
    • ส่วน high และ xhigh อยู่ในระดับคุณภาพใกล้เคียงกัน ดังนั้นงานนี้จึงแสดงให้เห็นการปรับปรุงหลักที่เกิดขึ้นเมื่่อขยับจาก low ไป medium

high: จุดที่ใกล้เคียงค่าเริ่มต้นเชิงปฏิบัติ

  • high ปรับปรุงทั้งการผ่านการทดสอบ ความเท่าเทียมกันเชิงความหมาย และการผ่านการรีวิว เมื่อเทียบกับ medium โดยต้นทุนเพิ่มขึ้นมากแต่ยังไม่ถึงขั้นมากเกินไป
  • เปรียบเทียบ high กับ medium
    • ผ่านการทดสอบ: เพิ่มจาก 21/26 เป็น 25/26
    • ความเท่าเทียมกัน: เพิ่มจาก 11/26 เป็น 18/26
    • ผ่านการรีวิวโค้ด: เพิ่มจาก 5/26 เป็น 10/26
    • ความเสี่ยงด้าน footprint เฉลี่ย: เพิ่มจาก 0.268 เป็น 0.314
    • ค่าเฉลี่ยด้านการสร้าง/วินัย: เพิ่มจาก 2.604 เป็น 2.736
    • ต้นทุนงานเฉลี่ย: เพิ่มจาก $3.13 เป็น $4.49 หรือ 1.43 เท่า
    • เวลาในการรันเฉลี่ย: เพิ่มจาก 411.0 วินาที เป็น 579.0 วินาที
  • high ดูเหมือนเป็นจุดที่โทเค็นเพิ่มเติมแปลงเป็นประโยชน์จริงได้ โดยมีสัดส่วนการเก็บรายละเอียดการผสานรวมได้ถูกต้องสูงขึ้น
  • ตัวอย่าง PR #1209
    • เป็นงานที่ต้องให้ gRPC datasource เคารพ GraphQL alias ใน response JSON, ตรวจสอบ referenced protobuf message type ล่วงหน้า และอัปเดต mapping coverage ของเส้นทาง mutation แบบ union/interface
    • low และ medium ผ่านการทดสอบทั้งคู่ แต่ไม่เท่าเทียมกันและไม่ผ่านการรีวิว
    • medium จัดการเรื่องการ serialize alias และการตรวจสอบ message ที่หายไปได้เป็นส่วนใหญ่ แต่พลาดการอัปเดต mapping ของ mutation createUser และใส่ความหมายของ response-key มากเกินไปไว้ใน JSONPath
    • high เพิ่มการจัดการ response-key/alias แบบชัดเจน และส่งต่อ alias ตลอดทั้ง planning และ JSON marshaling จนกลายเป็นการผ่านแบบเข้มงวดครั้งแรก
    • คุณภาพแบบกำหนดเองของ high เพิ่มเป็น 3.625 และไม่ได้แค่เพิ่มโค้ดมากขึ้น แต่ทำภาระผูกพันด้านการผสานรวมได้ตรงจุด
    • xhigh ก็ผ่านเช่นกัน แต่ไม่ได้ปรับปรุงการตีความในระดับงาน และเวลารันของเอเจนต์ตามเกณฑ์สรุปที่สร้างใหม่ยาวกว่า high ที่ 314.0s คือ 790.7s
  • ตัวอย่าง PR #1155
    • เป็นงาน hardening ของ gRPC datasource ที่รวมถึงการรองรับ repeated scalar field, การหลีกเลี่ยง panic จาก null/invalid message, การส่งต่อ gRPC status code, การปิดใช้งาน datasource และการรองรับ dynamic client
    • low และ medium ผ่านการทดสอบ แต่ไม่เท่าเทียมกัน
    • medium ปรับปรุงความทนทานขึ้น แต่ serialize invalid repeated field เป็น empty array, พลาดพฤติกรรมการ planning ของ aliased-root และยังเหลือความเสี่ยงด้านวงจรชีวิตของ dynamic-client
    • high ผ่านทั้งความเท่าเทียมกันและการรีวิวด้วยการจัดการ nil/invalid ที่ปลอดภัยกว่า การส่งต่อ status-code พฤติกรรมของ disabled-datasource และ coverage ของ dynamic client-provider
    • ในงานนี้ xhigh เกิดการพลิกกลับ โดยแม้จะผ่านการทดสอบ แต่จัดการความหมายของ disabled datasource และพฤติกรรม invalid-list ผิด ทำให้ไม่เท่าเทียมกันและไม่ผ่านการรีวิว

xhigh: ใกล้เคียงโหมดคุณภาพมากกว่าค่าเริ่มต้น

  • xhigh ยกระดับคุณภาพเชิงความหมายและคุณภาพจากการรีวิวเหนือกว่า high แต่ไม่ได้เป็นรูปแบบที่แค่ปรับค่าขึ้นแล้วทุกอย่างจะดีขึ้นเสมอไป
  • เปรียบเทียบ xhigh กับ high
    • ผ่านการทดสอบ: ลดจาก 25/26 เป็น 24/26
    • ความเท่าเทียมกัน: เพิ่มจาก 18/26 เป็น 23/26
    • ผ่านการรีวิวโค้ด: เพิ่มจาก 10/26 เป็น 18/26
    • ความเสี่ยงด้าน footprint เฉลี่ย: เพิ่มจาก 0.314 เป็น 0.365
    • ค่าเฉลี่ยด้านการสร้าง/วินัย: เพิ่มจาก 2.736 เป็น 3.071
    • ต้นทุนงานเฉลี่ย: เพิ่มจาก $4.49 เป็น $9.77 หรือ 2.18 เท่า
    • เวลาในการรันเฉลี่ย: เพิ่มจาก 579.0 วินาที เป็น 753.3 วินาที
  • xhigh มีแนวโน้มครอบคลุมพื้นฐานได้มากกว่า สอดคล้องกับเจตนาของมนุษย์ได้ดีกว่า และสร้างการเปลี่ยนแปลงที่ครบถ้วนกว่า แต่ใช้โทเค็นมากกว่ามาก
  • rubric การรีวิวของ xhigh มีค่าเฉลี่ย 3.365 มัธยฐาน 3.500 สูงกว่า high ที่มีค่าเฉลี่ย 2.817 และมัธยฐาน 2.750
  • มัธยฐานก็สูงกว่าค่าเฉลี่ยเช่นกัน จึงดูไม่ใช่ว่าการปรับปรุงของ xhigh เกิดจากแพตช์ที่โดดเด่นเพียงหนึ่งหรือสองชิ้นมาดันค่าเฉลี่ยขึ้น
  • xhigh สมบูรณ์เชิงความหมายมากกว่า แต่ก็แตะโค้ดมากกว่าแพตช์ที่มนุษย์เขียน ทำให้ ความเสี่ยงด้าน footprint เพิ่มขึ้นด้วย
  • บรรทัดที่ xhigh เพิ่มใน 26 งานรวมกันคือ 13,144 บรรทัด แบ่งเป็นโค้ด implementation 5,918 บรรทัด และ test·fixture·expected-output 7,226 บรรทัด
  • เมื่อเทียบกับ high, xhigh เพิ่มอีก 2,631 บรรทัด และในจำนวนนั้น 2,436 บรรทัดอยู่ในไฟล์ test·fixture·expected-output
  • footprint ที่เพิ่มขึ้นไม่ได้มาจากการเขียน production code จำนวนมหาศาลเท่านั้น แต่ยังมาจากการที่ xhigh สร้างการตรวจสอบและ coverage ของ fixture มากขึ้นด้วย
  • แต่การเปลี่ยนแปลงใน test, fixture และ expected-output ก็เป็นพื้นที่จริงที่ต้องรีวิวและบำรุงรักษาเช่นกัน
  • ตัวอย่าง PR #1076
    • เป็นงานปรับโครงสร้างการจัดการ subscription เพื่อหลีกเลี่ยง shared mutex race condition
    • ข้อกำหนดรวมถึงการ write แบบ serialize ต่อ subscription, การควบคุม heartbeat ต่อ subscription, coverage ของ race detector และการแก้ไข WebSocket close semantics
    • medium ผ่านการทดสอบ แต่ไม่เท่าเทียมกันและไม่ผ่านการรีวิว
    • high บรรลุทั้งความเท่าเทียมกันและการทำตามคำสั่ง แต่ worker queue ใหม่อาจบล็อก global subscription event loop, การ shutdown อาจค้างอยู่หลัง stuck worker, hung update อาจค้างได้ไม่จำกัด และการ unsubscribe ระดับ client ยังข้าม internal subscription อยู่ จึงไม่ผ่านการรีวิว
    • xhigh เป็นการผ่านแบบเข้มงวดครั้งแรก และยกระดับคุณภาพแบบกำหนดเองเป็น 3.475
    • งานนี้เป็นตัวอย่างที่ดีที่สุดว่าบนงานที่มี concurrency หนัก xhigh ทำหน้าที่เป็นโหมดคุณภาพที่ยอมจ่ายเพื่อเคลียร์ความเสี่ยงจากการรีวิว
  • ตัวอย่าง PR #1308
    • เป็นงาน implement GraphQL @oneOf input object
    • ต้องเพิ่ม built-in directive, การเปิดเผยผ่าน introspection, การตรวจสอบ operation literal และ runtime variable และการปรับปรุง source location ของ undefined-variable
    • medium และ high ผ่านการทดสอบ แต่ไม่เท่าเทียมกันและไม่ผ่านการรีวิว เพราะพลาดความหมายสำคัญของ @oneOf ที่เกี่ยวกับ runtime variable, nullable variable, provided-null payload และ introspection shape
    • xhigh เป็นการผ่านแบบเข้มงวดครั้งแรก และได้คะแนนความทนทาน 3.7, การทำตามคำสั่ง 4.0, คุณภาพแบบกำหนดเอง 3.525
    • ความต่างไม่ได้อยู่ที่ polish ผิวเผิน แต่คือ coverage ของ edge case ที่พาดผ่านหลายส่วนของระบบ
  • ตัวอย่าง PR #1240
    • เป็นงานรวม GraphQL AST field-selection merging และ inline-fragment selection merging เข้าเป็น normalization walk เดียว
    • low และ high ผ่านแบบเข้มงวด
    • xhigh เท่าเทียมกันตามเกณฑ์ประเมินเชิงความหมาย แต่ยังคง prioritized subpass ไว้ เปลี่ยนลำดับของ AbstractFieldNormalizer และทิ้ง field-merge registration แบบเก่าไว้ ทำให้ไม่ผ่านการรีวิว
    • แม้ตั้งค่าการให้เหตุผลสูงขึ้น ก็ยังอาจสร้างการรีแฟกเตอร์ที่ซับซ้อนและดูน่าเชื่อถือมากขึ้น พร้อมกับพลาดพฤติกรรมการทำงานที่แม่นยำซึ่งการทดสอบและผู้รีวิวให้ความสำคัญ

คุณภาพงานสร้าง·วินัย, ต้นทุน, ข้อจำกัด และบทสรุป

  • การประเมินแบบปรับแต่งเองด้านคุณภาพงานสร้าง·วินัยก็เพิ่มขึ้นโดยรวมเช่นกันเมื่อเพิ่มความพยายามในการให้เหตุผล คล้ายกับ rubric สำหรับรีวิว
  • คะแนน all-custom ของ xhigh มีค่าเฉลี่ย 3.071 และค่ามัธยฐาน 3.087 สูงกว่า high ที่มีค่าเฉลี่ย 2.736 และค่ามัธยฐาน 2.688
  • ทั้งด้านคุณภาพงานสร้างและวินัยมีค่ามัธยฐานสูงขึ้นด้วย จึงตีความได้ว่า xhigh ไม่ได้สร้างเพียงตัวอย่างที่โดดเด่นบางส่วน แต่ยกระดับคุณภาพของแพตช์โดยรวม
  • ตัวชี้วัดค่าเฉลี่ย/ค่ามัธยฐาน
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • การตีความรายละเอียด
    • low ยังอ่อนในด้านความแข็งแรงทนทานและการทำตามคำสั่ง
    • medium ปรับปรุงส่วนนี้ได้อย่างมีนัยสำคัญโดยไม่เพิ่มปริมาณรวมของการผ่านการทดสอบ
    • high ปรับปรุงทั้งความถูกต้องและความแข็งแรงทนทานอย่างเป็นรูปธรรม
    • xhigh ปรับปรุงแทบทุกมิติ รวมถึงขอบเขตและวินัยของ diff
  • ต้นทุนและเวลา
    • low: ต้นทุนเฉลี่ย $2.65, ค่ามัธยฐาน $1.91, เวลาในการรันเฉลี่ย 286.9s, ค่ามัธยฐาน 294.6s
    • medium: ต้นทุนเฉลี่ย $3.13, ค่ามัธยฐาน $2.87, เวลาในการรันเฉลี่ย 411.0s, ค่ามัธยฐาน 371.8s
    • high: ต้นทุนเฉลี่ย $4.49, ค่ามัธยฐาน $3.99, เวลาในการรันเฉลี่ย 579.0s, ค่ามัธยฐาน 572.9s
    • xhigh: ต้นทุนเฉลี่ย $9.77, ค่ามัธยฐาน $6.39, เวลาในการรันเฉลี่ย 753.3s, ค่ามัธยฐาน 732.7s
  • ต้นทุนมีการกระจุกตัวเอนเอียงใน low และโดยเฉพาะ xhigh โดยต้นทุนเฉลี่ยของ xhigh ได้รับอิทธิพลจากงานราคาแพงบางงาน
  • เมื่อดูจากค่ามัธยฐาน xhigh ก็ยังแพงกว่าและช้ากว่า high
  • high มีต้นทุนต่องานประมาณ 1.43 เท่าของ medium และ xhigh มีต้นทุนประมาณ 2.18 เท่าของ high
  • ข้อจำกัด
    • ใช้เพียง single seed ต่อหนึ่งงาน
    • รวมเฉพาะงานจริง 26 งานของ GraphQL-go-tools
    • ผู้ตัดสินแบบ LLM คือ GPT-5.4 และเห็นแพตช์·งาน แต่ไม่เห็น label
    • ไม่มีการทำ grader calibration สำหรับชุดงานนี้
    • ไม่อาจมองว่าเป็นผลลัพธ์ทั่วไปที่มีนัยสำคัญทางสถิติ หรือเป็นผลที่ย้ายไปใช้กับรีโพซิทอรีอื่นได้ตรง ๆ
  • การเปรียบเทียบที่เกี่ยวข้อง
    • leaderboard งานจริงของ Voratiq แม้จะใช้วิธีวิทยาต่างกัน แต่ก็แสดงทิศทางคล้ายกัน
    • ใน Voratiq นั้น GPT-5.5 xhigh ได้ 1994, GPT-5.5 high ได้ 1807 เพิ่มขึ้น +187 คะแนน หรือ +10.3%
    • ต้นทุนคือ $4.23 เทียบกับ $2.52 หรือ +67.9% ส่วนเวลาคือ 11.9m เทียบกับ 7.8m หรือ +52.6%
    • ในการทดลองของ Stet การขยับจาก high → xhigh ให้ผลเพิ่มมากกว่า โดยมี equivalence +19.2%p, สัมพัทธ์ +27.8%, การผ่าน code review +30.8%p, สัมพัทธ์ +80.0% และค่า aggregate ด้านคุณภาพงานสร้าง/วินัย +12.2% ซึ่งใกล้เคียงกัน
    • Voratiq เป็นลีดเดอร์บอร์ดแบบ preference/selection สำหรับ ongoing work ส่วนการทดลองนี้เป็นเพียง slice ของรีโพซิทอรีหนึ่งที่มี 26 งาน จึงเปรียบเทียบกันโดยตรงไม่ได้
  • บทสรุปเชิงปฏิบัติ
    • xhigh เหมาะกับงานที่กำกวม คร่อมหลายด้าน เน้น concurrency หรือมีความเสี่ยงสูงในการรีวิว
    • high ดูเป็นการตั้งค่าที่ใช้งานได้จริงที่สุดในฐานะค่าเริ่มต้น daily driver สำหรับชุดข้อมูลนี้
    • การตั้งค่าระดับ medium หรือต่ำกว่าเหมาะเมื่อให้ความสำคัญกับต้นทุนมากกว่า และงานเป็นงานประจำหรือมีการนิยามชัดเจน
    • ผลของความพยายามในการให้เหตุผลไม่ได้ราบเรียบหรือเป็นไปในทิศทางเดียวกันทุกงาน โดยมีทั้งกรณีที่ high ชนะ xhigh หรือกรณีที่การตั้งค่าสูงกว่าดูเหมือนดีแต่กลับสร้าง implementation ที่น่าเชื่อถือแต่ผิด
    • แทนที่จะคัดลอกค่าเริ่มต้นจาก benchmark กลาง ทีมควรวัดผลด้วย harness ของตัวเองและบนงานของตัวเอง
  • การเปิดเผยข้อมูล
    • ผู้เขียนกำลังสร้าง Stet.sh และใช้เครื่องมือประเมินผลแบบโลคัลนี้ในการรันการทดลอง
    • ในเวอร์ชันผลิตภัณฑ์ coding agent จะสร้าง candidate change อย่างการปรับปรุง AGENTS.md แล้วประเมินกับงานเก่าในรีโพซิทอรีผ่าน Stet
    • หากทีมที่ใช้ coding agent อย่างมากกำลังต้องตัดสินใจเชิงรูปธรรม เช่น high vs xhigh, Codex vs Claude Code, การอัปเดต AGENTS.md หรือการตัดสินว่างานใดปล่อยให้มอบหมายได้อย่างปลอดภัย ก็มีการมองหาทีมที่จะมารันการทดสอบรายรีโพซิทอรีร่วมกัน
    • Stet รันแบบโลคัลทั้งหมดโดยใช้การสมัครสมาชิก LLM และมีรายชื่อรอที่ https://www.stet.sh/private

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 8 시간 전
ความคิดเห็นจาก Hacker News
  • ชอบการเปรียบเทียบนี้ และก็อยากเห็น การเปรียบเทียบกับ 5.4 ด้วย
    จากที่ลองใช้มาจนถึงตอนนี้ รู้สึกว่า 5.5 ยังไม่คุ้มกับค่าใช้จ่ายที่เพิ่มขึ้น 5.4-high ทำได้ดีกว่าขั้นการให้เหตุผลส่วนใหญ่ของ 5.5 ค่าตัวก็ครึ่งเดียว และเวลาใช้งานจริงก็สั้นกว่ามาก 5.5-medium ทำงานไม่จบจนเสร็จ ส่วน 5.5-high ออกแบบเกินจำเป็นจนสร้างบั๊กและ regression
    • สัปดาห์ที่แล้วผมโพสต์เปรียบเทียบ 5.4 high กับ 5.5 high ไว้: https://www.reddit.com/r/codex/comments/1t0xt5m/gpt55_vs_gpt54_vs_opus_47_on_56_real_coding_tasks/
      สรุปคือ 5.5 ดีขึ้นจาก 5.4 เล็กน้อย และราคาก็เพิ่มขึ้นนิดหน่อย ดูเหมือนว่าประสิทธิภาพต่อโทเคนจะดีขึ้นบ้าง เลยช่วยชดเชยต้นทุนอินพุตที่เพิ่มขึ้นได้บางส่วน
    • ตอนนี้ใช้ medium เป็นค่าเริ่มต้น
  • สำหรับงานจริงจังส่วนใหญ่ high ดูจะเหมาะสม
    ถ้าสูงกว่านั้น การปรับปรุงที่ได้เริ่มเข้าใกล้ภาวะ ผลตอบแทนลดลง เมื่อเทียบกับต้นทุน
  • บนบัญชี Pro ผมรัน 5.5 xHigh Codex Terminal CLI เป็นตัวนำหลัก และ Codex Desktop App 5.5 xhigh เป็นตัวนำรอง
    ทั้งคู่ได้สิทธิ์เข้าถึงแบบเต็มระบบที่ค่อนข้างเสี่ยง และทำงานบนโปรเจกต์เดียวกัน โดยเฉลี่ยแต่ละตัวพ่วง 5.5 sub-agent ประมาณ 6 ตัว ส่วน CLI หรือแอปจะเป็นคนตัดสินใจเองว่าจะใช้ sub-agent ระดับไหน ปนกันไป แต่ CLI มักจะใช้ 5.5 Medium เป็นหลัก
    CLI มีสิทธิ์ระดับแอดมิน และงานอย่าง GitHub, Supabase, Vercel, Clerk, Linear, Symphony รวมถึง push, merge, PR, deploy จะให้ CLI จัดการทั้งหมด ผมไม่ได้ลงมือเองเลย 0 งาน และ P0/P1/P2 issue ก็เป็น 0 เช่นกัน GitHub, Vercel, Supabase เป็นสีเขียวหมด ไม่มี issue โค้ดกับโปรดักต์ก็เรียบร้อย และแค่มีภาพอ้างอิงภาพเดียวก็ได้ frontend ออกมาน่าทึ่งมาก
    ข้อเสียคือมันสามารถเผาโควตารายสัปดาห์ไปได้ 30% ภายในวันเดียว
    • พอเห็นการทดลองนี้ ผมเลยลองใช้ xhigh กับบางงาน และมันได้ผลดีพอสมควร แต่กินโทเคนบ้าคลั่งมาก
      ตอนนี้เลยกลับไปใช้ high อีกครั้ง
  • ข้อร้องเรียนใหญ่ที่สุดเกี่ยวกับ 5.5 xhigh คือมัน ลงมือทำเองต่อเลย โดยไม่ถามก่อน
    แต่ก็ทำให้รู้สึกเหมือนช่วยประหยัดอายุขัยไปได้หลายปีและประหยัดโทเคนไปมาก
    • ปกติผมใช้ high เป็นหลัก และมันก็ทำแบบเดียวกัน
      ผมยังพยายามหาว่าควรใส่ข้อความแบบไหนใน agents.md เพื่อไม่ให้มันตั้งสมมติฐานเองมั่ว ๆ บางครั้งเวลาผมถามเพราะต้องการรู้อะไรเพิ่มก่อนจะสั่งให้มันเขียนโค้ด มันกลับเริ่มเขียนโค้ดแทนที่จะตอบคำถาม พอทำเสร็จมันก็จะใส่คำตอบของคำถามนั้นมาในข้อความตอบกลับด้วย เหมือนมันตั้งใจฟังสิ่งที่ผมพูด แต่ยังไม่เข้าใจว่าถ้ามีคำถามอยู่ นั่นหมายความว่ายังไม่ควรเริ่มเขียนโค้ด
  • สงสัยว่าคุณเคย รันหลายรอบ กับ PR เดียวกันหรือเปล่า
    อยากรู้ว่าความแปรปรวนระหว่างแต่ละรันของโมเดลมีมากแค่ไหน ในกรณีข้างต้น ถึงแม้ high จะเขียนโค้ดได้ดีกว่า แต่ถ้าความแปรปรวนระหว่างรันสูงมาก การใช้ xhigh อาจจะดีกว่าก็ได้
    อีกการทดลองหนึ่งคือ หลังรันเสร็จให้ feedback กับผลลัพธ์ แล้วให้มันอัปเดต AGENTS.md, skills, rules ฯลฯ โดยเทียบกับสิ่งที่มนุษย์แก้ จากนั้นค่อยรันใหม่ใน fresh session ด้วย high/xhigh น่าจะดี ถ้าทำซ้ำจนดีขึ้นหลายรอบแล้วค่อยทดลองใหม่ในทุกระดับ effort ก็อาจช่วยยกระดับคุณภาพเอาต์พุตโดยรวมได้ ถ้าปรับ AGENTS.md และ skills/rules ได้ลงตัวจริง ๆ
    • ผมยังไม่ได้ลองรันแต่ละแบบหลายรอบ สาเหตุหลักคือ ข้อจำกัดด้านค่าใช้จ่ายและโทเคน กระเป๋าผมไม่ได้ไม่มีที่สิ้นสุด แต่เป็นไอเดียที่ดีมากสำหรับงานวิจัยต่อยอด
      การปรับ AGENTS.md ให้เหมาะสมเป็นแนวคิดที่ผมชอบมาก และจริง ๆ ก็ให้ Stet ที่ผมสร้างไว้เพื่อรันการทดลองมาลองทำสิ่งนี้แล้ว โดยให้มันรัน Codex กับงานบางชุด ดูคะแนนและรูปแบบความล้มเหลว แล้วให้มันแก้ AGENTS.md ก่อนรันใหม่ ทำทั้งหมดแบบอัตโนมัติ มันทำงานคล้ายงานวิจัยอัตโนมัติสำหรับ AGENTS.md และค่อนข้างน่าสนใจมากที่ได้เห็นมันนำข้อเสนอการปรับปรุงที่อิงข้อมูลกลับมาใส่ใน AGENTS.md
  • ตอนนี้เรายังต้องมี ดัชนี CPI สำหรับเงินเฟ้อด้านราคาด้วย รู้สึกเหมือน CPI รายเดือนเกือบ 100% เลย