ตลอดหนึ่งเดือนที่ผ่านมา มีรายงานต่อเนื่องจากผู้ใช้บางส่วนว่าคุณภาพการตอบของ Claude ลดลง หลังจากติดตามสาเหตุ Anthropic ยืนยันว่าต้นตอมาจากการเปลี่ยนแปลง 3 อย่างที่แยกจากกัน ซึ่งส่งผลต่อ Claude Code, Claude Agent SDK และ Claude Cowork โดย API เองไม่ได้รับผลกระทบ และระบุว่าปัญหาทั้งหมดได้รับการแก้ไขแล้ว ณ วันที่ 20 เมษายน 2025 (v2.1.116) โพสต์มอร์เทมนี้ครอบคลุมสาเหตุของปัญหา สิ่งที่แก้ไข และมาตรการป้องกันไม่ให้เกิดซ้ำ
สาเหตุและลำดับเหตุการณ์ของปัญหาทั้งสาม
- ลดค่าเริ่มต้นของ reasoning effort (4 มีนาคม): มีการเปลี่ยนระดับ reasoning effort เริ่มต้นของ Claude Code จาก
highเป็นmediumเพื่อช่วยลดเวลารอที่ยาวจนดูเหมือน UI ค้าง แต่ผู้ใช้รับรู้ได้ว่าคุณภาพคำตอบลดลง และในที่สุดได้ย้อนกลับการเปลี่ยนแปลงนี้เมื่อวันที่ 7 เมษายน ปัจจุบันตั้งค่าเริ่มต้นเป็นxhighสำหรับ Opus 4.7 และhighสำหรับโมเดลอื่น ๆ - ลบบันทึกการให้เหตุผลเพราะบั๊กในการปรับแต่งแคช (26 มีนาคม): เมื่อกลับมาใช้งานเซสชันที่ไม่มีการใช้งานนานเกิน 1 ชั่วโมง ฟีเจอร์ที่ออกแบบมาให้ล้างบันทึกการให้เหตุผลเดิม (
thinking) เพียงครั้งเดียว กลับเกิดบั๊กจนลบซ้ำในทุกเทิร์นการสนทนาหลังจากนั้น ส่งผลให้ Claude จำไม่ได้ว่าทำไมจึงทำงานบางอย่างลงไป จึงกลายเป็นสาเหตุของอาการ “ขี้ลืม” การตอบซ้ำ และการเลือกใช้เครื่องมืออย่างผิดปกติที่ผู้ใช้พบเจอ นอกจากนี้ยังมีผลข้างเคียงคือเกิด cache miss (ภาวะที่ไม่พบข้อมูลที่เก็บไว้) ซ้ำ ๆ ทำให้ใช้โควตาการใช้งานหมดเร็วกว่าที่คาด ปัญหานี้ได้รับการแก้ไขเมื่อวันที่ 10 เมษายน - คำสั่งให้ย่อเกินไปใน system prompt (16 เมษายน): เพื่อทำให้เอาต์พุตที่ยืดยาวของ Opus 4.7 สั้นลง จึงมีการเพิ่ม system prompt ว่า “ข้อความระหว่างการเรียกใช้เครื่องมือต้องไม่เกิน 25 คำ และคำตอบสุดท้ายต้องไม่เกิน 100 คำ” แม้จะไม่พบปัญหาในการทดสอบภายใน แต่ภายหลังยืนยันได้ว่าส่งผลลบต่อคุณภาพการเขียนโค้ดจริง จึงถูกนำออกเมื่อวันที่ 20 เมษายน
เหตุใดจึงพบปัญหาช้า
- การเปลี่ยนแปลงทั้งสามถูกใช้ในคนละช่วงเวลาและครอบคลุมทราฟฟิกคนละส่วน จึงดูเหมือนเป็นการลดลงของคุณภาพแบบกว้าง ๆ และไม่สม่ำเสมอ ทำให้ระบุสาเหตุรายตัวได้ยาก
- สภาพแวดล้อมทดสอบภายในแตกต่างจากสภาพแวดล้อมของผู้ใช้จริง กรณีบั๊กแคชเองก็เกิดจากการทดลองอีกชุดที่กำลังทำภายใน และความต่างของวิธีแสดงผลใน UI ทำให้การทำซ้ำปัญหาไม่ง่าย
- ชุดการประเมินเดิม (eval suite) ยังไม่ครอบคลุมพอ ผลกระทบจากการเปลี่ยน system prompt เพิ่งเห็นชัดว่าประสิทธิภาพลดลง 3% หลังจากรันการประเมินที่หลากหลายมากขึ้น
มาตรการป้องกันไม่ให้เกิดซ้ำ
- กำหนดให้พนักงานภายในใช้บิลด์ที่เผยแพร่จริง เพื่อลดช่องว่างระหว่างบิลด์ทดสอบภายในกับบิลด์ที่ผู้ใช้ใช้งานจริง
- เพิ่มความเข้มงวดในการควบคุมการเปลี่ยน system prompt ทุกการเปลี่ยนแปลงจะต้องผ่านการประเมินวงกว้างตามแต่ละโมเดล วิเคราะห์ผลกระทบของแต่ละบรรทัดแยกกัน (ablation) และใช้การทยอยปล่อยพร้อมช่วงเวลาตรวจสอบที่เพียงพอ (soak period)
- ปรับปรุงเครื่องมือ Code Review โดยอ้างอิงจากข้อเท็จจริงที่ว่า Opus 4.7 สามารถพบบั๊กแคชได้เมื่อได้รับทั้งโค้ดรีโพซิทอรีที่เกี่ยวข้องเป็นบริบท จึงจะขยายขอบเขตรีโพซิทอรีที่อ้างอิงได้ระหว่างการรีวิวโค้ด
- เปิดช่องทางสื่อสารกับผู้ใช้ (@ClaudeDevs) เพื่อแชร์เบื้องหลังของการตัดสินใจด้านผลิตภัณฑ์อย่างโปร่งใส
เกี่ยวกับประเด็น “ไม่มีการลดคุณภาพโดยเจตนา”
- Anthropic ระบุว่าไม่เคยทำให้โมเดลแย่ลงโดยเจตนา และยืนยันว่า API กับ inference layer ไม่ได้รับผลกระทบ อย่างไรก็ตาม เป็นความจริงที่การเปลี่ยนค่าตั้งต้นและบั๊กในชั้นผลิตภัณฑ์ (Claude Code) ทำงานร่วมกันจนทำให้คุณภาพที่ผู้ใช้รับรู้ลดลง และได้ประกาศรีเซ็ตโควตาการใช้งานของสมาชิกแบบสมัครสมาชิกทั้งหมดร่วมด้วย
13 ความคิดเห็น
ทำไมสาเหตุของเหตุขัดข้องทั้งสามอย่างถึงเกี่ยวข้องกับการลดต้นทุนโดยตรงทั้งหมดเลยล่ะ 55555
ดูท่าว่าทรัพยากร GPU จะขาดแคลนหนักจริง ๆ จนถึงขั้นทำให้ประสิทธิภาพลดลงแบบนี้เลยนะ.....
นี่แหละคือคำตอบที่ถูกต้อง แต่ข้อแก้ตัวมันยาวไปหน่อย 555
ดูเหมือนว่าเขาจะเขียนยาวมากว่า ที่ผ่านมาพวกเขาปล่อยขึ้นใช้งานโดยไม่แม้แต่จะทดสอบ public build และหลังจากปล่อยแล้วก็ยังไม่ทดสอบอีกด้วยนะครับ ผมเองก็เจอบั๊กนี้เข้าอย่างจังตั้งแต่วันที่ 26 มีนาคมแล้ว แต่ภายในกลับใช้เวลาตั้ง 3 สัปดาห์กว่าจะยืนยันได้ คิดว่านี่มันสมเหตุสมผลแล้วเหรอ...
ทันทีที่แพตช์ออก โควตา 5 ชั่วโมงที่ปกติต้องใช้ 3-4 ชั่วโมงกว่าจะหมด กลับเริ่มถูกใช้จนหมดภายใน 30 นาที แต่บัญชีพนักงานไม่มีโควตา 5 ชั่วโมงแบบนั้นอยู่แล้ว หรืออย่างน้อยก็ไม่ได้ขาดแคลนจนต้องคอยเปิดดู
/usageทุกครั้งระหว่างทำงาน ก็คงเลยใช้เวลานานพอสมควรกว่าจะสังเกตเห็นพอดู
claude codeใน SWE-Bench-Pro daily benchmark (ชุดที่คัดมา) แล้วจะเห็นอะไรที่น่าสนใจในช่วง 4/10~4/20 runtime ลดลงครึ่งหนึ่ง (653s→345s), tool call ลดลงครึ่งหนึ่ง (3.3K→1.8K), โทเค็นลดลง −18% แต่ pass rate กลับเพิ่มขึ้นอีก +16pp รูปแบบที่ทั้งสี่แกนขยับไปในทิศทางที่ดีพร้อมกันแบบนี้ไม่ใช่แพตเทิร์นที่เห็นกันบ่อย
postmortem วันที่ 4/23 คืออุบัติเหตุ 3 เคสที่เกิดขึ้นระหว่างกระบวนการนั้น ซึ่งพอดูแล้วทั้งหมดเกิดจาก "พยายามลดโทเค็น/latency"
ในทางกลับกัน codex(gpt-5.4-xhigh) ตัวเลขในช่วงเดียวกันแทบไม่ขยับเลย pass rate ตรึงอยู่แถว 56%, และโทเค็น/runtime/tool call ก็ยังอยู่ที่ระดับประมาณ 2 เท่าของ
claude codeเหมือนเดิมนี่ไม่ใช่โพสต์มอร์เท็มของเหตุขัดข้อง แต่เป็นโพสต์มอร์เท็มการลดต้นทุนหรือเปล่า?
บังคับให้พนักงานภายในใช้บิลด์ที่เผยแพร่จริง เพื่อลดความเหลื่อมล้ำกับบิลด์สำหรับการทดสอบภายใน
ฮ่าๆๆๆ
เหมือนว่าจะไปสอน YAGNI ให้กับ Opus 4.7 เข้าแล้วนะครับ ทุกครั้งที่ตัดสินใจเรื่องสถาปัตยกรรมก็อ้างเหตุผลว่าเป็นการค่อย ๆ ปรับแก้ตาม YAGNI เลยคิดว่าอ๋อคงเป็นแบบนั้น สุดท้ายก็เกิดเรื่องจนได้ แถมเพื่อนคนนี้ความจำก็ไม่ได้ยาวนัก ยังดันติดนิสัยผัดไปก่อนอีก เลยชวนให้ปวดหัวใหญ่เลยครับ
มีแค่ผมคนเดียวหรือเปล่าที่คิดว่า ตอนมีการชี้ปัญหาในช่วงแรกก็ยังยืนกรานว่าไม่มีปัญหา แต่พอเรื่องกลายเป็นประเด็นใหญ่จนคงปิดไม่อยู่แล้ว ถึงค่อยออกมาเปิดเผย
บนเว็บ claude.ai เองก็รู้สึกว่าการใช้งานแย่ลงแบบยิบย่อยเหมือนกัน... เพื่อประหยัดโทเค็นเลยปิดเมมโมรีไปแล้วครับ
พอเห็นประกาศนี้แล้วกลับยิ่งรู้สึกว่าเชื่อถือ Anthropic ไม่ได้มากขึ้นไปอีก
ด้านบนมีบทความที่เกี่ยวข้องอยู่ 2 ชิ้น ซึ่งเป็นบทความที่ห่างกัน 7 เดือน ปัญหาก็ยังเป็น 3 อย่างเดิมเหมือนกัน
การวิเคราะห์หลังเหตุการณ์ของ 3 ประเด็นคุณภาพของ Claude ที่ลดลงเมื่อไม่นานมานี้ 2025-09-19
อัปเดตเกี่ยวกับรายงานคุณภาพของ Claude Code ล่าสุด 2026-04-24
ฉันโกรธถึงระดับ $5 เครดิตเลย!!
พูดยืดยาวจัง..