เบนช์มาร์กรายวันสำหรับติดตามการเสื่อมลงของประสิทธิภาพ Claude Code

 (marginlab.ai)
9 คะแนน โดย GN⁺ 2026-01-30 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบติดตามที่วัดประสิทธิภาพงาน SWE ของ Claude Code Opus 4.5 ทุกวัน เพื่อตรวจจับ การเสื่อมลงของประสิทธิภาพที่มีนัยสำคัญทางสถิติ
  • ใช้ชุดย่อยที่คัดเลือกแล้วของ SWE-Bench-Pro เพื่อประเมิน อินสแตนซ์ทดสอบวันละ 50 รายการ โดยผลลัพธ์สะท้อน ประสิทธิภาพจริงของโมเดลที่รันโดยตรงในสภาพแวดล้อม CLI
  • ในช่วง 30 วันที่ผ่านมา ตรวจพบ อัตราการผ่านเฉลี่ย 54% และ ลดลง 4.1% อย่างมีนัยสำคัญทางสถิติ เมื่อเทียบกับค่าฐาน 58%
  • ผลลัพธ์รายวันและรายสัปดาห์ถูกวิเคราะห์โดยอิง ช่วงความเชื่อมั่น 95% และ เกณฑ์นัยสำคัญ (±14.0%, ±5.6%) เพื่อแยกความผันผวนระยะสั้นออกจากแนวโน้มระยะยาว
  • ดำเนินการโดยองค์กรบุคคลที่สามที่เป็นอิสระ และเป็นเครื่องมือสำหรับ ตรวจจับการเสื่อมลงของประสิทธิภาพตั้งแต่เนิ่น ๆ อันเกิดจากการเปลี่ยนแปลงของโมเดลหรือสภาพแวดล้อมการรัน

ภาพรวม

  • เป้าหมายของตัวติดตามนี้คือการตรวจจับ การลดลงอย่างมีนัยสำคัญทางสถิติ ในประสิทธิภาพงาน SWE ของ Claude Code Opus 4.5
    • ทำการประเมินทุกวันโดยใช้ชุดย่อยที่ทนต่อการปนเปื้อนของ SWE-Bench-Pro
    • รันโดยตรงใน Claude Code CLI และสะท้อนสภาพแวดล้อมผู้ใช้จริงโดยไม่ใช้ harness แบบกำหนดเองเพิ่มเติม
  • เป็นองค์กรบุคคลที่สามอิสระ โดย ไม่มีความร่วมมือกับผู้ให้บริการ frontier model
  • หลัง โพสต์มอร์เท็มของ Anthropic เกี่ยวกับประสิทธิภาพเสื่อมลง ในเดือนกันยายน 2025 จึงถูกจัดทำขึ้นเป็นทรัพยากรสำหรับตรวจจับกรณีลักษณะเดียวกันได้ตั้งแต่เนิ่น ๆ ในอนาคต

สรุปประสิทธิภาพ

  • อัตราการผ่านค่าฐาน: 58%
  • อัตราการผ่านใน 30 วันล่าสุด: 54% (จากการประเมิน 655 ครั้ง)
  • อัตราการผ่านใน 7 วันล่าสุด: 53% (จากการประเมิน 250 ครั้ง)
  • อัตราการผ่านใน 1 วันล่าสุด: 50% (จากการประเมิน 50 ครั้ง)
  • การเสื่อมลงของประสิทธิภาพในช่วง 30 วัน มีนัยสำคัญทางสถิติที่ระดับ p < 0.05
    • การเปลี่ยนแปลงใน 30 วัน: -4.1%
    • เกณฑ์นัยสำคัญ: ±3.4%
  • การเปลี่ยนแปลงใน 1 วัน (-8.0%) และ 7 วัน (-4.8%) ไม่มีนัยสำคัญทางสถิติ

แนวโน้มรายวันและรายสัปดาห์

  • แนวโน้มรายวัน (Daily Trend)
    • แสดงภาพอัตราการผ่านรายวันในช่วง 30 วันที่ผ่านมา
    • ค่าฐาน 58%, ช่วงเกณฑ์นัยสำคัญ ±14.0%
    • สามารถแสดง ช่วงความเชื่อมั่น 95% ได้ โดยยิ่งขนาดตัวอย่างน้อย ช่วงก็จะยิ่งกว้าง
  • แนวโน้มรายสัปดาห์ (Weekly Trend)
    • ใช้ค่าเฉลี่ยเคลื่อนที่ 7 วันเพื่อลดความผันผวนรายวันและแสดงแนวโน้ม
    • ค่าฐาน 58%, ช่วงเกณฑ์นัยสำคัญ ±5.6%
    • สามารถแสดง ช่วงความเชื่อมั่น 95% ได้เช่นกัน

ภาพรวมการเปลี่ยนแปลง (Change Overview)

  • การเปลี่ยนแปลง 1 วัน (เทียบกับเมื่อวาน) : -8.0%, ไม่มีนัยสำคัญทางสถิติ
    • จากการประเมิน 50 ครั้ง ต้องมีการเปลี่ยนแปลง ±14.0% จึงจะถือว่ามีนัยสำคัญ (p < 0.05)
  • การเปลี่ยนแปลง 7 วัน (เทียบกับสัปดาห์ก่อน) : -4.8%, ไม่มีนัยสำคัญทางสถิติ
    • จากการประเมิน 250 ครั้ง ต้องมีการเปลี่ยนแปลง ±5.6% จึงจะถือว่ามีนัยสำคัญ (p < 0.05)
  • การเปลี่ยนแปลง 30 วัน (เทียบกับเดือนก่อน) : -4.1%, มีนัยสำคัญทางสถิติ
    • จากการประเมิน 655 ครั้ง ต้องมีการเปลี่ยนแปลง ±3.4% จึงจะถือว่ามีนัยสำคัญ (p < 0.05)

ระเบียบวิธี (Methodology)

  • จำลองแต่ละการทดสอบเป็น ตัวแปรสุ่มแบบ Bernoulli และคำนวณ ช่วงความเชื่อมั่น 95%
  • วิเคราะห์ความแตกต่างทางสถิติของอัตราการผ่านรายวัน รายสัปดาห์ และรายเดือน เพื่อรายงานว่า มีการเสื่อมลงของประสิทธิภาพอย่างมีนัยสำคัญหรือไม่
  • ทำการประเมินด้วย อินสแตนซ์ทดสอบวันละ 50 รายการ จึงมีความผันผวนระยะสั้นอยู่บ้าง
  • ผลการสรุปรายสัปดาห์และรายเดือน ให้ค่าประมาณที่เสถียรกว่า
  • สามารถตรวจจับการเสื่อมลงของประสิทธิภาพที่เกิดจากทั้ง การเปลี่ยนโมเดล หรือ การเปลี่ยน execution harness

ฟีเจอร์การแจ้งเตือน

  • หากตรวจพบการเสื่อมลงของประสิทธิภาพอย่างมีนัยสำคัญทางสถิติ จะส่งการแจ้งเตือนทางอีเมล
  • ผู้ใช้สามารถลงทะเบียนอีเมลเพื่อสมัครรับข้อมูลได้
  • หลังยืนยันการสมัครรับข้อมูลแล้วจึงจะรับการแจ้งเตือนได้ และหากเกิดข้อผิดพลาดจะมีคำแนะนำให้ลองใหม่อีกครั้ง

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

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

 
iolothebard 2026-01-31

ไม่ใช่ว่า Claude Code ฉลาดน้อยลงหรอก… แต่อาจเป็นเพราะคนใช้เริ่มใช้ Claude ได้เก่งขึ้นกว่าเดิม… ก็ได้…
 
GN⁺ 2026-01-30
ความคิดเห็นจาก Hacker News

  • ผมคือ Thariq จากทีม Claude Code
    เราได้แก้ไข ปัญหา harness ที่เกิดขึ้นเมื่อวันที่ 26 มกราคมแล้ว และได้โรลแบ็กเรียบร้อยทันทีในวันที่ 28 มกราคม จึงแนะนำให้อัปเดตเป็นเวอร์ชันล่าสุดด้วยคำสั่ง claude update

    • Claude 2.1.x ค้างบ่อยหรือใช้ CPU 100% จนแทบใช้งานไม่ได้จริง ประเด็นที่เกี่ยวข้องอยู่ใน GitHub #18532
    • Claude สิ้นเปลืองโทเค็นไปมาก เลยสงสัยว่าจะมี การชดเชย สำหรับเรื่องนี้หรือไม่
    • อยากรู้เพิ่มเติมว่า “harness issue” หมายถึงอะไรกันแน่ และมี ผลกระทบ อย่างไรบ้าง
    • ปัญหานี้มีมาก่อนวันที่ 26 มกราคมแล้ว ตั้งแต่นั้น Claude ก็เริ่มแก้แผนเองตามอำเภอใจโดยอ้างว่าเป็น “การปรับปรุง”
    • สิ่งที่อยากรู้มากกว่าตัวโมเดลคือ ระบบควบคุมคุณภาพ มีการตรวจตัวอย่างผลลัพธ์จริงเป็นระยะ หรือมีโปรเซสภายในที่ใช้เบนช์มาร์กเพื่อติดตามประสิทธิภาพถดถอยหรือไม่ เรื่องแบบนี้จำเป็นมากในแง่ความปลอดภัยของ AI

  • ผมเป็นผู้ร่วมเขียน SWE-bench
    ตอนนี้ดูเหมือนการทดสอบจะรันเพียงวันละครั้ง และใช้แค่งาน 50 งานเท่านั้น ถ้าจะให้แม่นยำขึ้น ควรทดสอบ 5~10 ครั้งต่อวันกับ 300 งานแล้วนำค่าเฉลี่ยมาใช้ เพราะ ปัจจัยสุ่ม อย่างภาระของเซิร์ฟเวอร์อาจส่งผลต่อผลลัพธ์อย่างมาก

    • การเสื่อมประสิทธิภาพจากเซิร์ฟเวอร์โอเวอร์โหลดก็ควรเป็นสิ่งที่ต้องวัดด้วยไม่ใช่หรือ? ถ้าไม่ได้ตั้งใจจะวัดแค่ model distillation เท่านั้น
    • น่าจะติดปัญหาเรื่องต้นทุนในการรันโมเดล ถ้า Anthropic ช่วยสนับสนุน เครดิต สักหน่อย หรือเปิดลิงก์รับบริจาคก็น่าจะดี
    • ประสิทธิภาพอาจต่างกันมากกว่านี้ตามช่วงเวลาของวัน
    • มีความกังวลว่าค่าใช้จ่ายในการรัน SWE-bench สูงเกินไปจนรันได้ไม่มากพอ mafia-arena.com ก็เจอปัญหาคล้ายกัน
    • คำพูดที่ว่า “เซิร์ฟเวอร์โอเวอร์โหลดเลยวัดได้ไม่แม่น” ฟังดูแปลก ถ้าอย่างนั้น Claude มี ช่วงเวลาทำงาน ที่ทำงานได้ดีจริงหรือ?

  • มีการสรุปเหตุผลว่าทำไมจึงไม่เชื่อว่า Anthropic กำลังให้โมเดลที่แย่ลงกับผู้ใช้

    1. ระดับการลดลงของความแม่นยำมีไม่มาก และขึ้นลงเป็นลักษณะ แกว่งตัว
    2. ไม่มี baseline สำหรับ Sonnet 4.5 และเมื่อ GPU มีโหลดสูง Opus ก็อาจตกลงมาอยู่ระดับ Sonnet ได้
    3. มีความเป็นไปได้สูงว่ากำลัง ทดสอบ A/B หลายเช็กพอยต์อยู่ การอัปเดตเวอร์ชัน Claude Code หรือความไม่เป็นเชิงกำหนดของการสุ่มโทเค็นก็อาจเป็นสาเหตุได้
    • แม้จะเข้าใจคำอธิบายเชิงวิทยาศาสตร์ แต่ถ้าใช้งานทุกวันก็รู้สึกได้ชัดว่า ประสิทธิภาพแย่ลง
    • ผมก็คิดว่าการทดสอบ A/B น่าจะเป็นสาเหตุหลัก อยากให้เปิดเผยอย่างโปร่งใส เช่น ข้อจำกัดของ context window หรือการเปลี่ยน system prompt วิธีที่ดีที่สุดคือให้ผู้ใช้เลือกเวอร์ชันเองและส่งฟีดแบ็กได้
    • สงสัยว่าทำไมกราฟถึงเริ่มตั้งแต่วันที่ 8 มกราคม ช่วงนั้นอาจเป็น วันที่ผิดปกติจนค่าสูงมาก ก็ได้
    • อาจเป็นโครงสร้างที่ปรับ สมดุลประสิทธิภาพ-ต้นทุน อัตโนมัติตามโหลด เริ่มต้นด้วยประสิทธิภาพสูงแล้วค่อยลดขนาดโมเดลหรือ ลดจำนวนผู้เชี่ยวชาญใน MoE ลงเพื่อประหยัดต้นทุนก็เป็นได้
    • คำกล่าวที่ว่า “ระดับการลดลงน้อยเกินไป” เป็นเพียง ความเห็นเชิงอัตวิสัย ที่มองข้ามนัยสำคัญทางสถิติ

  • วิธีการทางสถิติดูแปลก
    พวกเขาดูเพียงช่วงความเชื่อมั่นของค่าก่อนหน้า แล้วดูว่าค่าใหม่อยู่นอกช่วงนั้นหรือไม่ แต่นั่นไม่ใช่วิธีที่ถูกต้องในการทดสอบ นัยสำคัญทางสถิติของความแตกต่าง เพราะการวัดทั้งสองครั้งต่างก็มีความไม่แน่นอน จึงต้องคำนวณ ช่วงความเชื่อมั่นของค่าความต่างเอง อีกทั้งถ้าจะเทียบรายเดือน ก็ควรเปรียบเทียบข้อมูลช่วง 60~31 วันที่แล้วกับช่วง 30 วันก่อนถึงเมื่อวาน ดังนั้นกราฟควรแสดงข้อมูลอย่างน้อยสองเดือน

  • ราวหนึ่งสัปดาห์ก่อน Claude เคยล่มประมาณหนึ่งชั่วโมง หลังจากกู้ระบบกลับมาแล้วไม่รู้เพราะจำนวนผู้ใช้น้อยลงหรือไม่ แต่ ความเร็วเพิ่มขึ้นเกิน 3 เท่า ในชั่วโมงนั้นผมทำงานได้เท่ากับปกติครึ่งวัน เหมือนได้เห็นอนาคตชั่วครู่ที่ไม่มีข้อจำกัดด้านทรัพยากร

    • ช่วงวันหยุดในสหรัฐฯ ก็มีการผ่อนข้อจำกัดการใช้งาน ทำให้ ทุกอย่างทำงานลื่นขึ้นมาก
    • ผมก็เจอเหมือนกันเมื่อไม่กี่วันก่อน มันเร็วมากจนถึงขั้นไปค้นหา “claude speed boost” เลย เร็วแบบ พุ่งปรู๊ดชั่วขณะ เหมือนตอนอัปเกรดโมเด็มสมัยก่อน
    • ถ้าเร็วเกินไปกลับรู้สึกเสียดาย ตอนนี้ยังดีที่รู้สึกได้ว่าโมเดลกำลังทำงานอย่างหนัก

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

    • แต่มีวิธีสแกนพรอมป์ต์ของผู้ใช้ Claude แบบ ‘ง่ายๆ’ ด้วยหรือ?
    • มี ความสัมพันธ์ กันว่าหลังจากมีคำขอฟีดแบ็กอย่าง “How’s Claude Doing This Session?” แล้วคำหยาบจะเพิ่มขึ้น
    • ปกติผมก็ชอบสบถอยู่แล้ว ข้อมูลอาจเลยเพี้ยนได้
    • ผมก็เป็นแบบนั้น เลยสบายใจขึ้น
    • บางครั้งเวลามันตอบโง่เกินไปก็หลุดด่าออกมา เป็นปฏิกิริยาที่เกิดจากความคาดหวังสูง

  • มีความเป็นไปได้ว่าเมื่อเวลาผ่านไปจะมีการ quantization โมเดลแบบค่อยเป็นค่อยไป ซึ่งทำให้สเกลระบบและลดต้นทุนได้ง่ายขึ้น และยังทำให้เวอร์ชันใหม่ดู “ดีขึ้น” ด้วย

    • ผมใช้ทุกวันวันละ 5~10 ชั่วโมง และสัปดาห์ที่ผ่านมาให้ความรู้สึกชัดเจนว่า มันโง่ลงกว่าเดิม ต่อให้พวกเขาจะปฏิเสธ แต่จากประสบการณ์ตรงมันเปลี่ยนไปจริง
    • ต่อให้ไม่ต้อง quantization ก็ยังลดโหลดได้ด้วยการ ลดความยาวบทสนทนา หรือ ลดเวลาในการให้เหตุผล
    • โมเดลเปิดอย่าง GPT-OSS หรือ Kimi K2.x ก็ถูกฝึกด้วยเลเยอร์ 4bit เช่นกัน Opus 4.5 มีต้นทุนต่อโทเค็นแพงกว่า 8 เท่า จึงมีโอกาสเป็น โมเดลที่ใหญ่กว่า แต่เพราะโครงสร้างราคาของแพ็กเกจสมัครสมาชิก จึงเทียบตรงๆ ได้ยาก
    • Anthropic ดูไม่ใช่บริษัทที่ถูกจำกัดด้วย ต้นทุนโครงสร้างพื้นฐาน ขนาดนั้น และในสภาพการแข่งขันรุนแรงแบบนี้ การตั้งใจลดคุณภาพคงเป็นกลยุทธ์ที่ไม่ดี อาจเป็นไปได้มากกว่าว่าหลังพ้น ช่วงฮันนีมูนเอฟเฟกต์ ผู้ใช้เริ่มสังเกตเห็นข้อบกพร่องได้ดีขึ้น
    • ถึงอย่างนั้น กลยุทธ์แบบ ค่อยๆ ลดคุณภาพ ก็ยังดูเป็นไปได้อยู่ เพราะสามารถขยายภาพการปรับปรุงสัมพัทธ์ของโมเดลใหม่ให้เด่นขึ้นได้

  • ในโหมด API พอ Claude เกินจำนวนโทเค็นระดับหนึ่งก็จะ โง่ลงแบบฉับพลัน แล้วทำอะไรหลุดโลก เช่น บอกว่า “มีบั๊กอยู่บรรทัดที่ 23” แต่กลับลบฟังก์ชันทั้งก้อนทิ้ง แม้แต่การแก้ง่ายๆ ที่ ChatGPT 3.5 ก็ทำได้ยังล้มเหลว ไม่เข้าใจจริงๆ ว่าทำไมถึงเป็นแบบนี้

    • น่าจะเป็นเพราะ ข้อจำกัดด้านทรัพยากร พวกเขาอาจเลือกให้คำตอบระดับพอใช้กับผู้ใช้จำนวนมาก แทนที่จะให้คำตอบดีมากกับผู้ใช้บางคน
    • ผมก็เจอเหมือนกัน รู้สึกว่า Claude ขี้เกียจขึ้นเรื่อยๆ

  • ช่วงสัปดาห์ที่ผ่านมา คุณภาพโค้ด ของ Claude แย่ลงอย่างสังเกตได้ เช่น แนะนำให้ใช้ frozen กับ Enum หรือเสนอ urlparse ซ้ำในฟังก์ชันที่ใช้ urlparse อยู่แล้ว เมื่อก่อนมันไม่ค่อยพลาดพื้นฐานแบบนี้

  • สิ่งที่น่าหงุดหงิดมากคือ ความไม่สม่ำเสมอของความสามารถในการให้เหตุผล ของผู้ให้บริการ LLM รายต่างๆ ChatGPT ก็เป็นเหมือนกัน เมื่ออินพุตเกิน 45k โทเค็น ความฉลาดจะตกฮวบหรืออินพุตถูกตัดทิ้ง แบบนี้สู้ขึ้นข้อความ “ปฏิเสธ” ตรงๆ ยังดีกว่า การถูกลดคุณภาพแบบเงียบๆ ทำให้เสียความเชื่อถือ ความโปร่งใส สำคัญมากจริงๆ