- ตั้งแต่เดือนสิงหาคมถึงต้นเดือนกันยายน เกิดอาการ คุณภาพการตอบของ 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
ยังไม่มีความคิดเห็น