การวิเคราะห์หลังเหตุการณ์ของปัญหาคุณภาพ Claude ที่ลดลงล่าสุด 3 กรณี

 (anthropic.com)
1 คะแนน โดย GN⁺ 2025-09-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่เดือนสิงหาคมถึงต้นเดือนกันยายน เกิดอาการ คุณภาพการตอบของ Claude ลดลง จาก บั๊กด้านโครงสร้างพื้นฐาน สามกรณี
  • สาเหตุหลักของปัญหาแต่ละกรณีคือ ข้อผิดพลาดในการกำหนดเส้นทาง context window, เอาต์พุตเสียหาย, และข้อผิดพลาด XLA:TPU approximate top-k miscompile
  • บั๊กแต่ละตัว ซ้อนทับกัน บนฮาร์ดแวร์และเส้นทางการดีพลอยที่หลากหลาย ทำให้วินิจฉัยได้ยากยิ่งขึ้น
  • สาเหตุที่การ ตรวจพบและแก้ไข ล่าช้ารวมถึงช่องโหว่ในกระบวนการตรวจสอบและข้อจำกัดในการเข้าถึงตามนโยบายความเป็นส่วนตัว
  • Anthropic เดินหน้า ป้องกันเหตุลักษณะเดียวกัน ด้วยการเสริมความเข้มแข็งของ การประเมินและมอนิเตอร์ รวมถึงพัฒนาเครื่องมือดีบักที่เร็วขึ้น

ภาพรวมและภูมิหลัง

  • ตั้งแต่เดือนสิงหาคมถึงต้นเดือนกันยายน มีรายงานว่า Claude มีคุณภาพการตอบที่ลดลงเป็นช่วง ๆ
  • ในช่วงแรกถูกมองว่าเป็นความผันผวนตามปกติในฟีดแบ็กจากผู้ใช้ แต่เมื่อรายงานเพิ่มขึ้นอย่างต่อเนื่องจึงเริ่มมีการสืบสวน
  • Anthropic ระบุชัดว่าต้นเหตุของปัญหาไม่ใช่อุปสงค์หรือภาระโหลดของเซิร์ฟเวอร์ แต่เป็น บั๊กด้านโครงสร้างพื้นฐาน เท่านั้น
  • Claude ให้บริการแก่ ผู้ใช้หลายล้านคน ผ่านหลายแพลตฟอร์ม เช่น APIs, Amazon Bedrock, Google Vertex AI และมีมาตรฐานการตรวจสอบที่เข้มงวดเพื่อรับประกันผลลัพธ์ที่เท่าเทียมกันบนฮาร์ดแวร์หลากหลายอย่าง AWS Trainium, NVIDIA GPU และ Google TPU
  • การวิเคราะห์หลังเหตุการณ์ครั้งนี้อธิบายสาเหตุของบั๊ก เหตุผลที่การวินิจฉัยและแก้ไขล่าช้า และมาตรการป้องกันการเกิดซ้ำ

แนวทางการให้บริการ Claude ในระดับขนาดใหญ่

  • บริการ Claude รักษา การดีพลอยระดับโลก ผ่านฮาร์ดแวร์หลายแบบ (Trainium, GPU, TPU)
  • มีเกณฑ์ความเท่าเทียมของการใช้งานที่เข้มงวดเพื่อ รับประกันคุณภาพเดียวกัน บนแต่ละแพลตฟอร์ม
  • เมื่อมีการเปลี่ยนแปลงโครงสร้างพื้นฐาน ต้องมีกระบวนการ ตรวจสอบ อย่างละเอียดในทุกแพลตฟอร์มและทุกการตั้งค่า

ไทม์ไลน์ของการเกิดปัญหาหลัก

  • 5 สิงหาคม: บั๊กตัวแรก ส่งผลต่อคำขอ Sonnet 4 ประมาณ 0.8%
  • 25 และ 26 สิงหาคม: บั๊กตัวที่สองและสามถูกดีพลอยตามลำดับ
  • 29 สิงหาคม: การเปลี่ยนแปลง load balancing ทำให้ทราฟฟิกที่มีปัญหาเพิ่มขึ้นอย่างมาก และมีผู้ใช้ได้รับผลกระทบมากขึ้น
  • บั๊กแต่ละตัวมีอาการซ้อนกัน ทำให้การวินิจฉัยทำได้ยากมาก
โฆษณา

บั๊กที่ซ้อนทับกันทั้งสามกรณีและกระบวนการแก้ไข

1. ข้อผิดพลาดในการกำหนดเส้นทาง context window

  • วันที่ 5 สิงหาคม คำขอ Sonnet 4 บางส่วนถูกกำหนดเส้นทางผิดไปยังเซิร์ฟเวอร์สำหรับ 1M token context window
  • หลังการเปลี่ยนแปลง load balancing ส่งผลต่อคำขอ Sonnet 4 ได้มากสุด 16% และมีผลกระทบเล็กน้อยต่อ Amazon Bedrock และ Google Vertex AI ด้วย
  • วิธีการกำหนดเส้นทางเป็นแบบ "sticky" ทำให้เมื่อเชื่อมต่อไปยังเซิร์ฟเวอร์ที่ผิดครั้งหนึ่งแล้ว คำขอถัดไปก็ยังถูกส่งไปยังเซิร์ฟเวอร์เดิมต่อไป
  • การแก้ไข: ปรับปรุงลอจิกการกำหนดเส้นทาง, ใช้แพตช์กับแพลตฟอร์มของตนเองเมื่อวันที่ 4 กันยายน, ดีพลอยสู่ Google Cloud ภายในวันที่ 16 กันยายน และกำลังทยอยใช้กับ Bedrock

2. เอาต์พุตเสียหาย (bug)

  • วันที่ 25 สิงหาคม มีการใช้การตั้งค่าที่ผิดบนเซิร์ฟเวอร์ TPU ของ Claude API ทำให้เกิดข้อผิดพลาดระหว่างการสร้างโทเค็น
  • เกิดอาการเช่นมี อักขระที่ไม่เกี่ยวข้อง อย่างภาษาไทยหรือภาษาจีนปนอยู่ในคำถามภาษาอังกฤษ หรือมีข้อผิดพลาดทางไวยากรณ์ที่ชัดเจนถูกแทรกเข้าไปในโค้ด
  • ส่งผลเฉพาะกับ Opus 4.1, Opus 4 และ Sonnet 4 ส่วนแพลตฟอร์มภายนอกไม่ได้รับผลกระทบ
  • การแก้ไข: ย้อนกลับการเปลี่ยนแปลงเมื่อวันที่ 2 กันยายน และเพิ่มการทดสอบตรวจจับเอาต์พุตอักขระผิดปกติในกระบวนการดีพลอย

3. ข้อผิดพลาด approximate top-k XLA:TPU miscompile

  • วันที่ 25 สิงหาคม ระหว่างยกระดับวิธีการเลือกโทเค็น ได้เผยให้เห็นบั๊กแฝงในคอมไพเลอร์ XLA:TPU
  • ส่งผลต่อ Claude Haiku 3.5, Sonnet 4 บางส่วน และ Opus 3
  • แพลตฟอร์มภายนอกไม่ได้รับผลกระทบ
  • การแก้ไข: ย้อนกลับ Haiku 3.5 ในวันที่ 4 กันยายน และ Opus 3 ในวันที่ 12 กันยายน ส่วน Sonnet 4 แม้จะไม่สามารถทำซ้ำปัญหาได้โดยตรง แต่ก็ย้อนกลับเพื่อป้องกันไว้ก่อน
  • พร้อมกันนั้นได้ร่วมมือกับทีม XLA:TPU เพื่อแก้ไขบั๊กของคอมไพเลอร์ และเปลี่ยนไปใช้วิธี exact top-k
โฆษณา

การวิเคราะห์เชิงลึกของบั๊กคอมไพเลอร์ XLA

  • Claude จะทำการ คำนวณความน่าจะเป็น ของแต่ละตัวเลือกและการสุ่มตัวอย่างระหว่างกระบวนการสร้างโทเค็น
  • TPU ทำงานในสภาพแวดล้อมแบบกระจาย จึงต้องซิงโครไนซ์การคำนวณความน่าจะเป็นของโทเค็น ซึ่งมีความซับซ้อนตามมา
  • เดือนธันวาคม 2024 พบปัญหาที่โทเค็นที่มีความน่าจะเป็นสูงสุดถูกละทิ้งจากความคลาดเคลื่อนที่เกิดจากการใช้ bf16-32-bit mixed precision และมีการดีพลอยวิธีแก้ชั่วคราว
  • วันที่ 26 สิงหาคม ระหว่างปรับโค้ดการสุ่มตัวอย่างเพื่อแก้สาเหตุราก ระหว่างการทำงานของ approximate top-k ได้เปิดเผยบั๊กที่ลึกกว่านั้น ซึ่งทำให้ในบางกรณีเกิดผลลัพธ์ที่ผิดทั้งหมด
  • บั๊กนี้ถูกวิธีแก้ชั่วคราวก่อนหน้าบดบังไว้
  • นอกจากนี้ บั๊กของการทำงาน approximate top-k ยังแสดงอาการไม่สม่ำเสมอตามสภาพแวดล้อมการใช้งานจริงและขนาดแบตช์
  • แทนที่จะใช้ approximate top-k ล่าสุดได้เปลี่ยนไปใช้ exact top-k ซึ่งภาระด้านประสิทธิภาพลดลงมากแล้ว และปรับปรุงโอเปอเรชันหลักด้วยการ ทำให้เป็นมาตรฐาน fp32

สาเหตุของความล่าช้าในการตรวจพบ

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

การปรับปรุงและมาตรการตอบสนองในอนาคต

  • พัฒนา รายการประเมินที่มีความไวสูง และเสริมการประเมินอัตโนมัติให้แยกแยะระหว่างสภาวะเสียหายกับการทำงานปกติได้ชัดเจนยิ่งขึ้น
  • ขยายระบบการประเมินและมอนิเตอร์ไปยัง สภาพแวดล้อมการใช้งานจริง ทั้งหมด เช่น ทำการประเมินที่เน้นสภาพแวดล้อมจริงอย่างข้อผิดพลาดการกำหนดเส้นทาง context window
  • จัดทำ เครื่องมือดีบักที่เร็วและละเอียดขึ้น พร้อมพัฒนาโครงสร้างพื้นฐานและเครื่องมือแบบคัสตอมเพื่อวิเคราะห์ฟีดแบ็กจากชุมชนได้รวดเร็วโดยยังคงรักษาความเป็นส่วนตัว
  • ไม่ใช่เพียงการประเมินภายในเท่านั้น แต่ยังเน้น ความน่าเชื่อถือของการเก็บฟีดแบ็กจากผู้ใช้อย่างต่อเนื่อง: ข้อผิดพลาดหรือบั๊กที่คาดเดายากนั้น รายงานจากผู้ใช้จริงเป็นสัญญาณสำคัญ
  • สนับสนุนอย่างจริงจังให้ใช้คำสั่ง "/bug" หรือฟังก์ชัน 'thumbs down' และส่งอีเมลเพื่อแจ้งวิธีประเมินคุณภาพโมเดล

คำอธิบายเพิ่มเติม

  • XLA:TPU เป็นคอมไพเลอร์ที่แปลงโค้ดภาษาการเพิ่มประสิทธิภาพระดับสูงของ XLA ให้เป็นคำสั่งสำหรับ TPU
  • เนื่องจากโมเดลมีขนาดใหญ่ จึงต้องกระจายไปวางบนหลายชิปแทนที่จะอยู่บนชิปเดียว และโอเปอเรชันอย่าง sorting จำเป็นต้องถูกอิมพลีเมนต์ในรูปแบบเวกเตอร์ไรซ์
  • การทำงาน approximate top-k ถูกใช้เพื่อเพิ่มประสิทธิภาพ แต่สามารถแฝงปัญหาร้ายแรง เช่น การตกหล่นของโทเค็นที่มีความน่าจะเป็นสูงที่สุด
  • ปัจจุบันได้เปลี่ยนมาใช้ exact top-k แล้ว และอาจมีการเปลี่ยนแปลงเล็กน้อยในรูปแบบการรวมโทเค็นที่อยู่ใกล้ค่า threshold ของ top-p ในบางกรณี ผู้ใช้อาจต้องปรับค่า top-p

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

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

 
GN⁺ 2025-09-19
ความคิดเห็นจาก Hacker News
  • สิ่งที่น่าสังเกตมากในช่วงหลังคือการพบว่าไม่มี unit test เลย แม้แต่การทดสอบบั๊กของคอมไพเลอร์ XLA ก็อยู่ในระดับแค่พิมพ์ผลลัพธ์ออกมา ไม่ใช่ unit test จริงที่รันผ่าน test harness และติดตาม coverage มาตรการรับมือกลับกลายเป็นแนวทางให้พึ่งพา Eval มากขึ้น แม้ตอนนี้การทำ unit testing กับ LLM ทั้งระบบจะไม่สมจริงนัก แต่บั๊กที่เผยออกมาจนถึงตอนนี้ส่วนใหญ่เกิดในส่วนเล็ก ๆ ที่เป็น deterministic ของระบบ ตัวอย่างเช่น load balancing, การคำนวณความน่าจะเป็นแบบ top-k ล้วนเป็นส่วนที่ถูกวิศวกรรมขึ้นมาเหมือนซอฟต์แวร์ทั่วไป จึงสามารถทำ unit test ได้ในหลักการ ถ้าจำเป็นก็อาจมีแค่ PRNG ที่ inject ได้สักตัวก็พอ แน่นอนว่าบั๊กจากการ optimize แบบไม่ deterministic เป็นเรื่องปวดหัว แต่ในอดีตก็เคยเจอบั๊กของคอมไพเลอร์และฐานข้อมูลผ่าน test suite ของแอปทั่วไปมาแล้ว ถ้ารันเทสต์จำนวนมากซ้ำ ๆ ใน CI เหตุการณ์ที่เกิดน้อยก็อาจถูกเปิดเผยได้ ในโปรเจกต์ส่วนตัวโปรเจกต์หนึ่ง ฉันรัน unit test ทั้งหมดแบบขนานในโปรเซสเดียวกัน และด้วยวิธีนี้ก็สามารถจับปัญหา thread safety ที่โผล่มาไม่บ่อยหรือ database deadlock ได้อย่างมีประสิทธิภาพ ไม่กี่วันก่อนในเธรดเกี่ยวกับการเปิดตัว Java ฉันเคยพูดไว้ว่าเหตุผลที่ Java ถูกมองว่าเป็นภาษาแบบ 'enterprise' มากกว่า Python ก็เพราะโค้ดมักถูกเขียนโดยเน้น unit test ทำให้มี abstraction มากจากความต้องการอย่าง dependency injection ตรงกันข้าม วัฒนธรรมของ scripting language มักไม่มีเทสต์เลยหรือทำแบบผิวเผินเท่านั้น (เช่น assert แค่ type) ตอนเรียน PyTorch ก็รู้สึกคล้ายกัน เพราะแม้ tutorial จะไล่ไปถึงเรื่องที่ซับซ้อนขึ้นเรื่อย ๆ แต่แทบไม่พูดถึงเทสต์หรือโครงสร้างโค้ดเลย นี่อาจเหมาะกับงานวิจัย ML ที่เป้าหมายคือเพิ่มคะแนนประเมินผล แต่ไม่เหมาะกับการ deploy production ขนาดใหญ่ จึงอดสงสัยไม่ได้ว่าห้องแล็บ AI น่าจะต้องมีคนที่มีพื้นฐาน SRE หรือวิศวกรซอฟต์แวร์ด้าน HA มากกว่านี้หรือไม่ ส่วนตัวฉันยังสงสัยว่าการเร่งรัน Eval ใน production อย่างเดียวจะเป็นวิธีที่ดีที่สุดในการป้องกันบั๊กหรือไม่
    • ฉันเคยต้องให้พรอมป์ต์อย่างละเอียดพร้อมตัวอย่าง เพื่อให้ AI เขียน unit test ใน Python ในรูปแบบที่ฉันต้องการ และก็เห็นบ่อยว่ามันใช้แค่ assert เรื่อง type สิ่งที่ฉันต้องการคือ assert กับค่าจริง ๆ AI มีแนวโน้มจะ mocking ทุกอย่างมากเกินไป ซึ่ง mocking ก็มีประโยชน์ แต่ใน unit test ยิ่งเรียกใช้โค้ดจริงให้ครบมากเท่าไร ก็ยิ่งครอบคลุมความเสี่ยงจากปฏิสัมพันธ์ของโค้ดและอินเทอร์เฟซได้มากขึ้น ทว่า unit test ภาษา Python ที่ AI สร้างมักหมกมุ่นกับ mocking มากเกินไป จนจบลงที่ตรวจแค่โค้ดแบบ tautological ที่สมเหตุสมผลในตัวเองเท่านั้น ดังนั้นฉันจึงใส่คำเตือนให้ระวัง mocking และยกตัวอย่างเทสต์ที่รอบคอบไว้ในพรอมป์ต์อย่างชัดเจน อนึ่ง Python เองก็มีเครื่องมือยอดเยี่ยมมากมายสำหรับการเขียนโค้ดแบบมีโครงสร้าง เช่น dependency injection
  • รู้สึกแปลกใจที่บทความบอกว่า Anthropic สามารถส่งผลกระทบต่อโครงสร้างพื้นฐาน AWS Bedrock ได้โดยตรง ซึ่งขัดกับคำมั่นเดิมของ AWS น่าจะเป็นแบบเดียวกันกับ Google Vertex AI แต่ฉันยังไม่ได้ตรวจสอบด้าน compliance

ฉันเห็นด้วยกับข้อความที่ว่า ภายใต้นโยบายความเป็นส่วนตัวและความปลอดภัยภายใน วิศวกรจะเข้าถึงปฏิสัมพันธ์ของผู้ใช้ Claude ได้อย่างจำกัด และก็เห็นด้วยว่าการที่ผู้ใช้ส่ง feedback โดยตรงยังคงมีประโยชน์มากที่สุด รวมถึงคำแนะนำว่าบน Claude Code สามารถใช้คำสั่ง /bug ได้ หากรายงานผ่านคำสั่งนั้น วิศวกรคงตรวจสอบบริบทได้ แต่ในมุมผู้ใช้ อยากให้ประกาศขั้นตอนนี้ให้ชัดเจนมาก ๆ (ฉันไม่ใช่ผู้ใช้ Claude Code) ส่วนคำแนะนำให้ใช้ปุ่ม "thumbs down" ในแอป Claude ค่อนข้างน่ากังวล เพราะผู้ใช้ส่วนใหญ่คงไม่ได้มองว่าการกดปุ่มนี้มีน้ำหนักเท่ากับการสละความเป็นส่วนตัว

  • (พนักงาน Anthropic พูดในนามส่วนตัว)

ข้อความที่ว่า Anthropic บริหารโครงสร้างพื้นฐาน AWS Bedrock โดยตรงนั้นไม่เป็นความจริง ตอนนี้ AWS เป็นผู้ดำเนินการเองโดยตรง สำหรับคำแนะนำด้านความเป็นส่วนตัวของปุ่ม "thumbs down" ใน modal นั้นระบุไว้ว่า "เมื่อส่ง feedback นี้ ระบบจะส่งบทสนทนาปัจจุบันทั้งหมดไปยัง Anthropic เพื่อใช้ปรับปรุงโมเดล" อยากทราบว่ามีวิธีทำให้ข้อความนี้เข้าใจง่ายขึ้นกว่านี้หรือไม่

  • ตอนกด "thumbs down" จะมีข้อความแจ้งว่า "เมื่อส่ง feedback นี้ ระบบจะส่งบทสนทนาทั้งหมดไปยัง Anthropic" ดังนั้นฉันคิดว่าคำชี้แจงค่อนข้างชัดเจนแล้ว
  • ถ้าระดับห้องแล็บอย่าง Anthropic ยังต้องออกมาแชร์รายละเอียดโครงสร้างพื้นฐานแบบนี้ ก็ดูเหมือนว่าสถานการณ์คงยากพอสมควร บั๊กด้าน precision ของ FMA (fused multiply-add) นั้นน่าเสียดายมาก ปัญหาเชิงตัวเลขมักสร้างความสับสนได้สูงและยังเป็นพื้นที่ที่ AI แก้เองไม่ได้ ในภาวะกดดันหนักที่คู่แข่งแย่งส่วนแบ่งตลาดแบบเรียลไทม์ สุดท้ายก็ยังต้องพึ่งคน และการหาสาเหตุอาจใช้เวลาหลายสัปดาห์
  • มีคำอธิบายว่า "การเปลี่ยนแปลง load balancing ในวันที่ 29 สิงหาคม ทำให้คำขอ short context ถูกส่งไปยังเซิร์ฟเวอร์ 1M context มากขึ้นโดยบังเอิญ และในวันที่ 31 สิงหาคมเป็นเวลาหนึ่งชั่วโมง คำขอ Sonnet 4 จำนวน 16% ได้รับผลกระทบ" ซึ่งฟังดูเหมือนว่าเซิร์ฟเวอร์ 1M context กลับทำงานได้แย่กว่าสำหรับอินพุต short context อาจเป็นผลจากการใช้แนวทางเฉพาะอย่าง KV cache compression, eviction, sparse attention ฯลฯ บนเซิร์ฟเวอร์เหล่านี้หรือไม่?
    • นี่เป็นผลจากการ scale RoPE (rotary positional embedding) เฟรมเวิร์กโอเพนซอร์สชื่อดังส่วนใหญ่มัก implement static YaRN ซึ่งใช้ scaling factor คงที่ไม่ว่าความยาวอินพุตจะเป็นเท่าไร จึงอาจกระทบประสิทธิภาพเมื่อต้องจัดการข้อความสั้น แนะนำให้เพิ่มการตั้งค่า rope_scaling เฉพาะตอนที่ต้องการ long context เท่านั้น และควรปรับ factor ให้เหมาะกับความยาวอินพุตเฉลี่ยของแอปพลิเคชันด้วย เช่น ถ้าอยู่แถว ๆ 520k token การตั้ง factor เป็น 2.0 จะดีกว่า ที่มา (หน้าอธิบาย Qwen3-Next-80B)
    • ประเด็นสำคัญในรายงาน postmortem ของพวกเขาคือ จากปัญหาสามอย่าง มีสองอย่างที่ยังไม่ได้สาเหตุที่แน่ชัด เท่าที่ฉันเข้าใจ คำขอของฉันตอนนี้อาจถูกส่งไปตาม code path ที่แตกต่างกันโดยสิ้นเชิงได้สามแบบ ซึ่งแต่ละแบบมีสแตกและการจูนแยกกัน การ optimize เหล่านี้ยังอาจเปลี่ยนไปกะทันหันโดยไม่เกี่ยวกับการอัปเกรดเวอร์ชันโมเดล ดังนั้นสิ่งที่ใช้ได้ดีเมื่อวานอาจพังวันนี้ก็ได้ จนฉันยิ่งหงุดหงิดมากกว่าเดิมและไม่เข้าใจว่าทำไม postmortem แบบนี้ถึงได้รับคำชม
  • ด้วยความเคารพต่อทีม Anthropic คุณภาพของหน้า Claude status อยู่ในระดับที่ภายในควรประกาศ code red ได้แล้ว เดือนกรกฎาคมมี incident 50 ครั้ง เดือนสิงหาคม 40 ครั้ง และเดือนกันยายน 21 ครั้ง สมัยก่อนแค่ครึ่งหนึ่งของตัวเลขนี้ก็เคยทำให้ต้องหันไปโฟกัส uptime และคุณภาพกันทั้งทีม ถึงอย่างนั้น Claude ก็ยังเป็นผลิตภัณฑ์ที่ยอดเยี่ยมจนฉันยังยอมจ่ายเงิน ฉันลองใช้ API แล้วก็สมัคร Max membership ทันที ซึ่งช่วยเพิ่ม productivity อย่างมาก แต่คุณภาพที่ตกลงซ้ำ ๆ ในช่วงหลายสัปดาห์ที่ผ่านมา ทำให้เริ่มลังเลว่าจะต่อ subscription ดีไหม ขอบคุณที่ออกมาแชร์สถานการณ์อย่างตรงไปตรงมา แต่ในฐานะลูกค้า ฉันไม่พอใจมาก และยังคิดว่าปัญหาอย่างเรื่อง load balancing ยังไม่ได้ถูกตรวจจับหรือแก้ไขอย่างสมบูรณ์ โดยเฉพาะช่วงประมาณ 12:00 น. ฝั่งตะวันออก / 9:00 น. ฝั่งตะวันตก คุณภาพของ Claude Code ตกลงอย่างรู้สึกได้ หวังว่าทีมจะหาปัญหาและแก้ไขต่อไป ฉันเองเวลาไปรัน local model ที่บ้านก็เคยเจอบั๊กซับซ้อนมากมาย จึงเข้าใจว่าปัญหาเหล่านี้ไม่ง่าย ลิงก์หน้า status
    • จะบอกว่า Claude ดีกว่าหรือแย่กว่าบริษัทอื่นอย่างเด็ดขาดก็คงไม่ได้ แต่มีเรื่องหนึ่งที่แน่ชัด คือหน้า status ของหลายบริษัทโกหกกันเยอะมาก ทั้งที่ความจริงระบบล่มบ่อย แต่บนหน้า status กลับไม่แสดงให้เห็น ปัจจุบันถึงขั้นรู้สึกแปลกใจมากกว่าเมื่อมีบริษัทแจ้งปัญหาอย่างตรงไปตรงมา ส่วนตัวฉันไม่ได้เจอปัญหาร้ายแรงกับ Claude แต่อาจเป็นเพราะโชคดี จากมุมมองของฉัน Claude ดูจะรายงานเหตุขัดข้องอย่างครบถ้วนกว่าด้วยซ้ำ แน่นอนว่านี่อาจเป็นเรื่องบังเอิญก็ได้
    • สิ่งที่น่ากังวลยิ่งกว่าคือหน้า status มักตกหล่น incident เล็ก ๆ ไปจำนวนมาก ซึ่งผู้ให้บริการ AI ทุกเจ้าก็คล้ายกัน ถ้าเปิดเผยกราฟสถิติอย่าง latency ของ token แบบเรียลไทม์, คำขอที่ล้มเหลว, ความเร็วประมวลผล token ต่อวินาที ก็คงน่าตกใจไม่น้อย ดูจากข้อมูล OpenRouter ก็พอเห็นได้ว่า uptime ของ API ไม่ได้ดีนัก Claude Code เองก็มักช้าจนต้องหยุดเองแล้วลองใหม่ โดยเฉพาะช่วง 16:00-18:00 น. ตามเวลาอังกฤษที่ยุโรป ฝั่งตะวันออก และฝั่งตะวันตกของสหรัฐฯ ใช้งานพร้อมกัน วันนี้เอง Gemini AI studio ก็ขึ้น 503 จาก model overload แต่บนหน้า status ไม่มีอะไรเลย ฉันเลยคิดว่า ถ้า Claude หรือเจ้าอื่นออกแพ็กเกจราคาถูกในช่วง off-peak ก็อาจช่วยกระจายความต้องการได้ แต่อีกด้านหนึ่งแพ็กเกจแบบนั้นก็อาจดูไม่ดีในเชิงภาพลักษณ์ นอกจากนี้ ดูเหมือน GPU GB200 จะถูกนำมาใช้ช้ากว่าที่คาดมาก และยังมีทั้งข้อบกพร่องด้านฮาร์ดแวร์และซอฟต์แวร์จำนวนมาก ปัญหาระบบระบายความร้อนด้วยของเหลวก็ดูไม่ธรรมดาเช่นกัน (ถ้าล้มเหลวจะหนักมาก)
    • คำพูดที่ว่า "ถึงอย่างนั้น Claude ก็ดีมากจนยอมจ่าย" นี่เองเป็นประเด็นสำคัญ ณ ตอนนี้คุณภาพของ AI สำคัญกว่าความน่าเชื่อถือของบริการสำหรับลูกค้า (รวมถึงฉันด้วย) แน่นอนว่าผู้ให้บริการคงต้องโฟกัสเรื่องความน่าเชื่อถือในระยะยาว แต่ทำไมตอนนี้ถึงต้องให้ความสำคัญกับ reliability มากกว่าคุณภาพ?
    • ช่วงนี้คุณภาพตกฮวบทำให้รู้สึกไม่มั่นใจมาก โชคดีที่ฉันยังไม่ได้เอา AI ไปใช้ใน production แต่ในขั้นตอนพัฒนา การที่โมเดลอยู่ ๆ ก็ "โง่ลง" เป็นสิ่งที่รับมือด้วยทางอ้อมได้ยากมาก ณ จุดนี้ถึงกับสงสัยว่า vendor หลายเจ้าบน openrouter กำลังหักหลังความเชื่อใจหรือไม่ ด้วยการแอบลด context, ลดระดับ quantization, ลดจำนวน expert หรือใช้กลเม็ดลดทรัพยากรคอมพิวต์แบบเงียบ ๆ
    • ด้วยเหตุนี้จึงมีการใช้กลยุทธ์ทำให้จำนวน incident ที่แสดงบนหน้า status ต่ำที่สุด แม้คะแนนลูกค้าจะตกชั่วคราว แต่เมื่อเวลาผ่านไป ผลกระทบเชิงลบก็จะหายไป อย่างไรก็ดี ถ้าดูแลหน้า status อย่างสม่ำเสมอ มันจะทิ้ง "หลักฐาน" ของปัญหาไว้ชัดเจน สู้ปิดบังเสียยังจะดีกว่าในระยะยาว จริง ๆ แล้ว S3 ก็เคยมีเหตุขัดข้องหลายครั้งรวมถึง error ต่าง ๆ แต่ไม่ได้เปิดเผย และก็ไม่มีใครถือสา คนเราพูดกันมาก แต่ในทางปฏิบัติโครงสร้างแรงจูงใจกลับให้รางวัลกับคนที่ซ่อนปัญหา นัก growth hacker ของสตาร์ตอัปทุกคนรู้อยู่แล้ว
  • มีคำอธิบายว่าในวันที่ 25 สิงหาคม มีการ deploy การตั้งค่าที่ผิดไปยังเซิร์ฟเวอร์ TPU ของ Claude API ทำให้เกิดข้อผิดพลาดระหว่างการสร้าง token ฉันคุ้นกับบั๊กจากโค้ด แต่ LLM ไม่ได้ถูกเขียนโดยมนุษย์ทีละบรรทัด มันเกิดจากการฝึกอัตโนมัติขนาดใหญ่ เลยสงสัยว่าบั๊กแบบนี้เกิดขึ้นได้อย่างไร ตัวอย่างเช่น ถ้าโมเดลตอบคำถามภาษาอังกฤษอยู่ดี ๆ แล้วมีคำว่า 'สวัสดี' โผล่มากลางประโยค ในเชิงโครงสร้างแล้วมนุษย์ใส่บั๊กแบบนั้นเข้าไปได้อย่างไร
    • ท้ายที่สุดแล้ว LLM ก็ถูกรันด้วยโค้ดที่มนุษย์เขียน ในขั้นตอนสุดท้าย โมเดลจะสร้างการแจกแจงความน่าจะเป็นให้กับ token ทั้งหมด (vocab ราว 200k) หลังจากนั้นมนุษย์จะเป็นผู้กำหนดว่าจะเลือก token ถัดไปจริง ๆ อย่างไร เช่น เลือก token ที่มีความน่าจะเป็นสูงสุดเสมอ หรือสุ่มจาก top-k เพื่อเพิ่มความสร้างสรรค์ เพื่อให้ประมวลผลการสุ่มแบบ top-k ได้อย่างมีประสิทธิภาพ จึงมีการคอมไพล์เคอร์เนลด้วย XLA และดูเหมือนว่าเคอร์เนลนี้มีบั๊กจนทำให้บางครั้ง token ที่อยู่นอก top-k ถูกเลือกขึ้นมา
    • LLM จะปล่อยการแจกแจงความน่าจะเป็นของ token ถัดไปออกมา แล้วผลลัพธ์จริงจะขึ้นอยู่กับวิธี sampling ตัวอย่าง เช่น ถ้าเลือกแบบ 'สุ่มจาก 4 ตัวที่มีความน่าจะเป็นสูงสุด' แล้วโอเปอเรเตอร์ (เครื่องหมายเปรียบเทียบ) เขียนผิด ก็จะเกิดอาการแบบในบทความนี้ได้
    • ระหว่างผู้ใช้กับพารามิเตอร์ของโมเดล ยังมีชั้นของโค้ดที่มนุษย์เขียนซ้อนอยู่อีกหลายชั้น
    • ถ้าอธิบายแบบง่าย ๆ จะมีสองช่วงคือ training กับ inference ช่วง training ใช้เวลานานและเป็นระบบอัตโนมัติ แต่ inference เป็น software stack คนละชุดที่ถูกรันทันทีเมื่อได้รับพรอมป์ต์จากผู้ใช้ สแตกนี้ได้รับการอัปเดตเพื่อปรับปรุงประสิทธิภาพอย่างต่อเนื่อง และในกระบวนการนี้เองที่ปัญหาเกี่ยวกับ inference แบบนี้เกิดขึ้น
    • AI kernel ใช้การคำนวณแบบ floating point ดังนั้นในการคำนวณจำนวนจริง บางครั้งค่าที่ไม่ควรติดลบก็อาจกลายเป็นค่าติดลบอย่างประหลาดได้ ด้วยเหตุผลด้านประสิทธิภาพ บางระบบปิดการตรวจ overflow ไป และถ้ามีค่าติดลบโผล่มาก็อาจตีความเป็นค่าที่ใหญ่มาก (คล้ายกับการขอ array index เป็น -1 แล้วกลับได้สมาชิกตัวสุดท้าย)
  • คิดว่าการพยายามทำให้กระบวนการอนุมานของ LLM เป็น deterministic น่าจะช่วยในการตามแกะปัญหาได้ ช่วงนี้ยังมีงานวิจัยที่บอกด้วยว่า ความเชื่อเดิมที่ว่า "ต้นเหตุจริง ๆ คือแค่ลำดับการรวม floating point" นั้นไม่ใช่ประเด็นหลักทั้งหมด บทความแนะนำงานวิจัยที่เกี่ยวข้อง
    • ทราฟฟิกเครือข่ายหรือโหลดของเครื่องเป็นสิ่งที่ไม่ deterministic โดยธรรมชาติ ในระยะใกล้นี้ deterministic แบบสมบูรณ์ (เช่น เพื่อการ audit) คงเป็นจริงได้แค่ในงาน batch ที่ไม่อ่อนไหวต่อต้นทุน อันที่จริงทั้ง Google Search หรือการโหลดจำนวน recommendation บนโซเชียลมีเดียก็ไม่ได้ deterministic เลย ใน distributed system คำแนะนำหลักคือ graceful degradation หรือการรักษาบริการบางส่วนไว้ แต่ถ้าระบบ deterministic แบบสมบูรณ์ก็จะทำแบบนั้นไม่ได้
    • การออกแบบแบบ deterministic ส่งผลลบต่อประสิทธิภาพ สุดท้ายสิ่งที่เหลือคือแนวทางแบบ 'IQ test' ที่สร้างโมเดลอีกตัวขึ้นมาเพื่อติดตามคุณภาพและแจ้งเตือนเกี่ยวกับโมเดลเดิม
  • ฉันเห็นด้วยกับข้อความที่ว่า "บน Google Cloud Vertex AI การ routing ผิดระหว่างวันที่ 27 สิงหาคมถึง 16 กันยายนมีสัดส่วนน้อยกว่า 0.0004%" ในงานจริงฉันใช้ CC กับบัญชีนั้น และไม่เคยรู้สึกว่าคุณภาพลดลงเลย โดยรวมแม้บั๊กพวกนี้จะร้ายแรง แต่ฉันรู้สึกว่ามันเกิดขึ้นน้อยกว่าที่รีวิวออนไลน์พูดกันมาก ช่วงเวลาที่มีปัญหาจริง ๆ ก็ไปกระจุกอยู่แค่ประมาณ 1-2 สัปดาห์ และสัดส่วนคำขอที่ได้รับผลกระทบเมื่อเทียบกับทั้งหมดก็ค่อนข้างน้อย
    • แต่ในบทความของบริษัทเองก็เขียนว่า "ผู้ใช้ Claude Code 30% อย่างน้อยหนึ่งครั้งถูก route ไปยังเซิร์ฟเวอร์ผิดและพบว่าคุณภาพคำตอบลดลง" การ routing เป็นแบบ sticky ดังนั้นเมื่อถูกส่งไปเซิร์ฟเวอร์ผิดครั้งหนึ่งแล้ว คำขอถัด ๆ ไปก็จะถูกส่งไปที่เดิมต่อเนื่อง ถ้าผู้ใช้ Claude Code ถึง 30% เจอคุณภาพลดลง นั่นเป็นบั๊กใหญ่มาก
    • ช่วงนี้ฉันไม่ค่อยไว้ใจบริษัทนัก เพราะต่อให้เกิดเหตุขัดข้องระดับโลก ก็มักใช้ถ้อยคำอ้อม ๆ ว่า "มีข้อผิดพลาดเพิ่มขึ้นสำหรับผู้ใช้ส่วนน้อยบางส่วน" และจะปรับหน้า status ก็ต่อเมื่อ CTO อนุมัติแล้วเท่านั้น ถ้ามีบริษัทที่สื่อสารอย่างตรงไปตรงมาจริง ๆ ก็น่าจะเป็นจุดแข็งทางการตลาดได้
  • มีความเห็นว่าถ้าทำให้บริการ LLM ทำงานแบบ deterministic ได้ ก็น่าจะช่วยให้ตามปัญหาได้ง่ายขึ้น และยังอ้างถึงงานวิจัยล่าสุดที่ระบุว่า ปัจจัยที่เคยโทษกันว่าเป็นแค่ลำดับของการคำนวณ floating point นั้น จริง ๆ ยังมีสาเหตุที่ทำให้ความเป็น deterministic พังได้อีกหลายแบบ ลิงก์งานวิจัย
  • ช่วงนี้ฉันเจอปัญหารุนแรงที่ Claude ทำให้ DOM ในการออกแบบเว็บแอปแสดงข้อความมั่ว ๆ แบบสุ่ม ปัญหานี้ดูเหมือนจะเกิดเฉพาะเมื่อใช้ร่วมกับ svelte แม้ไม่แน่ใจว่าจะเกี่ยวกับอาการในบทความนี้หรือไม่ แต่ก่อนหน้านี้ฉันไม่เคยเจอคุณภาพตกหนักขนาดนี้มาก่อน
  • อยากให้ในโพสต์ใส่กรณีล้มเหลวจริง ๆ มาด้วย ฉันเจออาการใน Claude Code ที่หลังจากเรียก tool แล้วมันหยุดไปเลยบ่อยมาก จึงสงสัยว่านี่เกี่ยวกับหนึ่งในบั๊กที่พูดถึงครั้งนี้หรือไม่
    • ฉันเองก็เจอปัญหาเดียวกันนี้บ่อยขึ้นเรื่อย ๆ ในช่วงไม่กี่วันที่ผ่านมา คิดว่าอาจเป็นคนละบั๊กกับในบทความ (แต่ก็ยังเป็นบั๊กอยู่ดี) แม้ลึก ๆ จะหวังว่าฉันคาดเดาผิด ทุกวันนี้ต้องส่งข้อความอย่าง "ทำไมถึงหยุด? ช่วยทำต่อ" ซ้ำ ๆ บ่อยขึ้นอย่างเห็นได้ชัด