Phân tích hậu sự cố về ba vấn đề suy giảm chất lượng gần đây của Claude

• Từ tháng 8 đến đầu tháng 9, hiện tượng suy giảm chất lượng phản hồi của Claude xảy ra do ba lỗi hạ tầng
• Nguyên nhân chính của từng vấn đề lần lượt là lỗi định tuyến cửa sổ ngữ cảnh, hỏng đầu ra, và lỗi XLA:TPU approximate top-k không được biên dịch
• Mỗi lỗi xuất hiện chồng lấp trên nhiều phần cứng và đường triển khai khác nhau, khiến việc chẩn đoán càng khó hơn
• Các nguyên nhân làm chậm phát hiện và khắc phục bao gồm lỗ hổng trong quy trình xác minh và các hạn chế truy cập do chính sách quyền riêng tư
• Anthropic đang triển khai tăng cường đánh giá và giám sát, cùng phát triển công cụ gỡ lỗi nhanh hơn để ngăn ngừa các sự cố tương tự

---

Tổng quan và bối cảnh

• Từ tháng 8 đến đầu tháng 9, đã có báo cáo về hiện tượng chất lượng phản hồi của Claude giảm sút không liên tục
• Ban đầu, điều này được xem là biến động bình thường trong phản hồi từ người dùng, nhưng khi số lượng báo cáo tiếp tục tăng, cuộc điều tra đã bắt đầu
• Anthropic khẳng định rõ rằng nguyên nhân của vấn đề không phải do nhu cầu hay tải máy chủ, mà hoàn toàn là do lỗi hạ tầng
• Claude được cung cấp cho hàng triệu người dùng qua nhiều nền tảng (APIs, Amazon Bedrock, Google Vertex AI, v.v.), và có các tiêu chuẩn xác minh nghiêm ngặt để đảm bảo kết quả tương đương trên nhiều phần cứng như AWS Trainium, NVIDIA GPU và Google TPU
• Bài phân tích hậu sự cố này giải thích nguyên nhân lỗi, lý do việc chẩn đoán và khắc phục bị chậm trễ, cũng như các biện pháp phòng ngừa tái diễn

Cách Claude được vận hành ở quy mô lớn

• Dịch vụ Claude duy trì triển khai toàn cầu trên nhiều phần cứng khác nhau (Trainium, GPU, TPU)
• Tiêu chuẩn tương đương trong triển khai để đảm bảo chất lượng đồng nhất trên từng nền tảng là rất nghiêm ngặt
• Khi có thay đổi hạ tầng, cần một quy trình xác minh chặt chẽ trên mọi nền tảng và cấu hình

Dòng thời gian các sự cố chính

• 5/8: lỗi đầu tiên, ảnh hưởng đến khoảng 0,8% yêu cầu Sonnet 4
• 25 và 26/8: lỗi thứ hai và thứ ba lần lượt được triển khai
• 29/8: thay đổi cân bằng tải khiến lưu lượng gặp vấn đề tăng vọt, làm nhiều người dùng bị ảnh hưởng hơn
• Các triệu chứng của từng lỗi chồng lấp nhau, khiến độ khó chẩn đoán tăng rất cao

Ba lỗi chồng lấp và quá trình khắc phục

1. Lỗi định tuyến cửa sổ ngữ cảnh

• Ngày 5/8, một số yêu cầu Sonnet 4 đã bị định tuyến nhầm tới các máy chủ dành cho cửa sổ ngữ cảnh 1M token
• Sau thay đổi cân bằng tải, mức ảnh hưởng tăng lên tối đa 16% yêu cầu Sonnet 4; Amazon Bedrock và Google Vertex AI cũng bị ảnh hưởng nhẹ
• Do phương thức định tuyến là "sticky", một khi đã kết nối nhầm tới máy chủ sai thì các kết nối sau đó tiếp tục bị giữ ở cùng máy chủ đó
• Khắc phục: cải thiện logic định tuyến; bản vá được áp dụng trên nền tảng riêng ngày 4/9, triển khai lên Google Cloud đến ngày 16/9, còn Bedrock đang được áp dụng dần

2. Hỏng đầu ra (bug)

• Ngày 25/8, một cấu hình sai đã được áp dụng lên các máy chủ TPU của Claude API, gây lỗi khi sinh token
• Xuất hiện hiện tượng trộn ký tự lạ như tiếng Thái hoặc tiếng Trung trong câu trả lời tiếng Anh, cũng như chèn các lỗi cú pháp rõ ràng vào mã
• Chỉ ảnh hưởng đến Opus 4.1, Opus 4 và Sonnet 4; các nền tảng bên thứ ba không bị ảnh hưởng
• Khắc phục: hoàn tác thay đổi vào ngày 2/9 và bổ sung kiểm thử phát hiện đầu ra có ký tự bất thường vào quy trình triển khai

3. Lỗi approximate top-k XLA:TPU không được biên dịch

• Ngày 25/8, trong quá trình nâng cấp phương thức chọn token, một lỗi tiềm ẩn trong trình biên dịch XLA:TPU đã bị bộc lộ
• Ảnh hưởng đến Claude Haiku 3.5, một phần Sonnet 4 và Opus 3
• Các nền tảng bên thứ ba không bị ảnh hưởng
• Khắc phục: Haiku 3.5 được hoàn tác ngày 4/9, Opus 3 ngày 12/9; Sonnet 4 không được tái hiện trực tiếp nhưng cũng được hoàn tác như một biện pháp phòng ngừa
• Đồng thời, Anthropic đang phối hợp với đội ngũ XLA:TPU để sửa lỗi trình biên dịch và chuyển sang dùng phương thức top-k chính xác

Phân tích chi tiết lỗi trình biên dịch XLA

• Trong quá trình sinh token, Claude thực hiện tính toán xác suất cho từng ứng viên và lấy mẫu
• TPU hoạt động trong môi trường phân tán, nên việc đồng bộ tính toán xác suất token là cần thiết và khá phức tạp
• Tháng 12/2024, Anthropic phát hiện vấn đề khiến token có xác suất cao nhất bị bỏ sót do sai số phát sinh từ độ chính xác hỗn hợp bf16-32 bit, và đã triển khai một bản sửa tạm thời
• Ngày 26/8, trong quá trình cải tổ mã lấy mẫu để xử lý tận gốc nguyên nhân, một lỗi sâu hơn khiến phép toán approximate top-k cho ra kết quả hoàn toàn sai trong một số trường hợp đã bị lộ ra
• Lỗi này trước đó đã bị bản sửa tạm thời che khuất
• Ngoài ra, lỗi trong phép toán approximate top-k còn biểu hiện không đều tùy theo môi trường vận hành và kích thước batch
• Thay vì approximate top-k, gần đây họ đã chuyển sang exact top-k, vốn hiện nay có chi phí hiệu năng thấp hơn đáng kể, đồng thời cải thiện các phép toán chính bằng cách chuẩn hóa sang fp32

Nguyên nhân chậm phát hiện

• Anthropic đang sử dụng các quy trình như đánh giá tự động định kỳ và triển khai trước cho một nhóm giới hạn
• Những sự cố lần này đã bộc lộ lỗ hổng của quy trình đánh giá. Ví dụ, có những hạng mục đánh giá không phát hiện tốt tình huống lỗi, và các chính sách bảo vệ quyền riêng tư nội bộ (kỹ sư không thể truy cập trực tiếp các yêu cầu cụ thể của người dùng) khiến việc phân tích nhanh trở nên khó khăn
• Do triệu chứng biểu hiện khác nhau theo nền tảng và phiên bản, rất khó xác định một nguyên nhân duy nhất
• Ngay cả khi báo cáo trực tuyến tăng mạnh, mối liên hệ với thay đổi cân bằng tải tiêu chuẩn cũng không được nhận ra ngay lập tức

Cải tiến và biện pháp ứng phó sắp tới

• Phát triển các hạng mục đánh giá có độ nhạy cao, tăng cường đánh giá tự động có thể phân biệt rõ hơn giữa trạng thái hỏng và triển khai bình thường
• Mở rộng hệ thống đánh giá và giám sát ra toàn bộ môi trường vận hành thực tế, chẳng hạn thực hiện các đánh giá tập trung vào vận hành như lỗi định tuyến cửa sổ ngữ cảnh
• Xây dựng công cụ gỡ lỗi nhanh hơn và tinh vi hơn, đồng thời phát triển hạ tầng và công cụ tùy chỉnh để có thể phân tích nhanh phản hồi cộng đồng mà vẫn giữ quyền riêng tư
• Không chỉ đánh giá nội bộ, Anthropic còn nhấn mạnh độ tin cậy của việc liên tục thu thập phản hồi từ người dùng: với các lỗi hoặc bug khó dự đoán, báo cáo từ người dùng thực tế là tín hiệu rất quan trọng
• Họ cũng tích cực khuyến khích sử dụng lệnh "/bug" hoặc tính năng 'thumbs down', cũng như gửi email để chia sẻ các phương pháp đánh giá chất lượng mô hình

Giải thích tham khảo

• XLA:TPU là trình biên dịch chuyển mã ngôn ngữ tối ưu hóa cấp cao XLA thành lệnh TPU
• Do kích thước mô hình lớn, mô hình được phân chia để triển khai trên nhiều chip thay vì một chip duy nhất; các phép toán như sorting cần được hiện thực theo dạng vector hóa
• Phép toán approximate top-k được dùng để cải thiện hiệu năng, nhưng có thể tiềm ẩn các vấn đề nghiêm trọng như bỏ sót token có xác suất cao nhất
• Hiện tại, phương thức exact top-k đã được áp dụng, và có thể có những thay đổi rất nhỏ trong cách bao gồm các token nằm gần ngưỡng top-p. Trong một số trường hợp, người dùng có thể cần điều chỉnh giá trị top-p

[GN⁺]

Ý kiến trên Hacker News

• Điều đáng chú ý gần đây là người ta phát hiện ra sự thiếu vắng của unit test. Ngay cả test cho lỗi của trình biên dịch XLA cũng chỉ ở mức in output ra, chứ còn xa mới là unit test thực thụ được chạy trong test harness để theo dõi coverage. Cách xử lý dường như là dựa nhiều hơn vào Eval. Hiện tại, unit test cho toàn bộ LLM là điều phi thực tế, nhưng phần lớn các lỗi lộ ra đến nay đều nằm ở những thành phần nhỏ có tính quyết định của hệ thống. Ví dụ, load balancing hay tính toán xác suất top-k đều là những phần được engineering giống như phần mềm khác, nên về nguyên tắc có thể unit test. Nếu cần thì chỉ cần một PRNG có thể inject vào là đủ. Các lỗi tối ưu hóa phi quyết định đúng là rất đau đầu, nhưng ngay cả test suite của ứng dụng truyền thống trước đây cũng từng phát hiện lỗi compiler và database. Nếu chạy lặp lại nhiều test trong CI, những sự kiện hiếm vẫn có thể lộ ra. Trong một dự án cá nhân, tôi chạy song song toàn bộ unit test trong cùng một process, và bằng cách này đã phát hiện hiệu quả các vấn đề thread safety hiếm gặp hoặc deadlock database. Vài ngày trước, trong một thread về việc ra mắt Java, tôi cũng từng nói rằng một lý do Java được xem là “enterprise” hơn Python là vì mã của nó được viết với trọng tâm là unit test. Vì nhu cầu như dependency injection nên có rất nhiều abstraction được tạo ra. Ngược lại, trong văn hóa ngôn ngữ scripting, nhiều trường hợp либо không có test, либо chỉ test cho có lệ trên bề mặt thôi (ví dụ: chỉ assertion về type). Khi học PyTorch tôi cũng có cảm giác tương tự; tutorial thì dần đi đến những thứ phức tạp hơn, nhưng hầu như không nói gì về test hay cấu trúc code. Cách tiếp cận đó phù hợp với nghiên cứu ML, nơi mục tiêu là nâng điểm đánh giá, nhưng không phù hợp với triển khai production quy mô lớn. Tôi tự hỏi liệu các lab AI có cần thêm người có nền tảng SRE hoặc kỹ sư phần mềm HA hay không. Cá nhân tôi khá hoài nghi việc chỉ aggressively chạy Eval trong production có phải là cách tốt nhất để ngăn lỗi hay không
  • Tôi từng phải cung cấp prompt rất chi tiết và ví dụ cụ thể thì AI mới viết được unit test Python theo đúng kiểu tôi muốn. Tôi cũng thường thấy nó chỉ dùng assertion về type. Điều tôi muốn là assertion về chính giá trị. AI có xu hướng mock mọi thứ quá mức; mocking cũng hữu ích, nhưng trong unit test, càng gọi được nhiều code thật thì càng bao phủ được rủi ro từ tương tác code và interface. Thế nhưng unit test Python do AI tạo ra thường quá ám ảnh với mocking, đến mức chỉ kiểm tra những đoạn code tự chứng minh chính nó là xong. Vì vậy tôi chủ động đưa cả cảnh báo về việc cẩn trọng với mocking lẫn các ví dụ test kỹ lưỡng vào prompt. Nhân tiện, Python cũng có rất nhiều công cụ tuyệt vời để viết code có cấu trúc kiểu dependency injection
• Tôi ngạc nhiên khi bài viết nói rằng Anthropic có thể ảnh hưởng trực tiếp đến hạ tầng AWS Bedrock. Điều này cũng đi ngược lại lời hứa ban đầu của AWS. Tôi nghĩ Google Vertex AI cũng tương tự, nhưng tôi chưa xác minh về mặt compliance. <br> > Tôi đồng ý với ý rằng theo chính sách riêng tư và bảo mật nội bộ, kỹ sư bị hạn chế trong việc truy cập tương tác của người dùng với Claude. <br> > Tôi cũng đồng ý rằng người dùng chủ động gửi feedback vẫn là hữu ích nhất, và rằng trong Claude Code có thể dùng lệnh /bug. Nếu báo cáo bằng lệnh đó thì kỹ sư có thể xem được ngữ cảnh, nhưng từ góc độ người dùng, tôi muốn quy trình này được thông báo thật rõ ràng (tôi không phải người dùng Claude Code). <br> > Hướng dẫn dùng nút "thumbs down" trong app Claude thì hơi đáng lo. Phần lớn người dùng sẽ không nghĩ rằng bấm nút này mang sức nặng tương đương với việc từ bỏ quyền riêng tư
  • (Nhân viên Anthropic, phát biểu với tư cách cá nhân) <br> > Việc nói Anthropic trực tiếp quản lý hạ tầng AWS Bedrock là không đúng sự thật. Hiện tại AWS trực tiếp vận hành. <br> > Về hướng dẫn quyền riêng tư cho nút "thumbs down", modal đó có ghi rõ: "Khi gửi phản hồi này, toàn bộ cuộc trò chuyện hiện tại sẽ được gửi tới Anthropic và được dùng để cải thiện mô hình." Tôi muốn biết liệu có cách nào làm câu hướng dẫn này dễ hiểu hơn nữa không
  • Khi bấm "thumbs down", có thông báo rằng "Khi gửi phản hồi này, toàn bộ cuộc trò chuyện sẽ được gửi tới Anthropic", nên tôi nghĩ thông báo này đã khá rõ ràng
• Nếu một lab cỡ Anthropic mà còn chia sẻ chi tiết hạ tầng như vậy, có lẽ tình hình khá khó khăn. Lỗi độ chính xác phía FMA (fused multiply-add) thật sự đáng tiếc; các vấn đề số học thường rất rối rắm và vẫn là lĩnh vực AI chưa giải quyết được. Trong bối cảnh áp lực cực lớn khi đối thủ đang giành thị phần theo thời gian thực, sự can thiệp của con người cuối cùng vẫn là bắt buộc, và việc tìm ra nguyên nhân có thể mất hàng tuần
• Có đoạn nói rằng “thay đổi load balancing ngày 29 tháng 8 đã vô tình gửi nhiều request context ngắn hơn tới các server context 1M hơn, và trong một giờ ngày 31 tháng 8, 16% request Sonnet 4 bị ảnh hưởng”. Điều này nghe như các server context 1M lại cho hiệu năng kém hơn với input context ngắn. Có lẽ đây là hệ quả của việc trên các server này áp dụng các biện pháp riêng như nén KV cache, eviction, sparse attention, v.v.?
  • Đây là do RoPE (rotary positional embeddings) scaling. Hầu hết framework open source nổi tiếng đều triển khai static YaRN, tức là scaling factor cố định bất kể độ dài input, nên có thể ảnh hưởng hiệu năng khi xử lý văn bản ngắn. Chỉ nên thêm thiết lập rope_scaling khi thực sự cần context dài, và cũng nên điều chỉnh factor theo độ dài input trung bình của ứng dụng. Ví dụ, nếu khoảng 520 nghìn token thì đặt factor 2.0 sẽ tốt hơn <br> Nguồn (trang mô tả Qwen3-Next-80B)
  • Điểm cốt lõi trong báo cáo postmortem của họ là với hai trong ba vấn đề, vẫn chưa có nguyên nhân chính xác. Theo hiểu biết của tôi, request của tôi hiện có thể bị gửi vào bất kỳ một trong ba code path hoàn toàn khác nhau, mỗi cái có stack và tuning riêng. Những tối ưu hóa này có thể đột ngột thay đổi dù không có nâng cấp version mô hình, nên thứ hôm qua còn chạy tốt hôm nay có thể hỏng. Tôi còn thấy bức bối hơn đến mức không hiểu sao lại có lời khen cho những postmortem kiểu này
• Với tất cả sự tôn trọng dành cho đội Anthropic, chất lượng trang status của Claude ở mức nội bộ đáng phải báo động đỏ. Có 50 incident trong tháng 7, 40 trong tháng 8 và 21 trong tháng 9. Trước đây, chỉ cần bằng một nửa con số này thôi là tôi đã từng thấy mọi người bị xoay hướng rất mạnh sang tập trung vào uptime và chất lượng. Dù vậy Claude vẫn là một sản phẩm tuyệt vời nên tôi vẫn tiếp tục trả tiền. Tôi thử API rồi đăng ký Max membership ngay. Nhờ đó năng suất của tôi tăng vọt. Nhưng vì chất lượng suy giảm lặp đi lặp lại trong vài tuần gần đây, tôi bắt đầu cân nhắc có nên tiếp tục subscription hay không. Tôi cảm ơn vì họ đã chia sẻ thẳng thắn tình hình, nhưng từ phía khách hàng thì vẫn rất bực bội. Tôi cho rằng các vấn đề như load balancing vẫn chưa được phát hiện hay xử lý hoàn toàn. Cụ thể là khoảng 12 giờ trưa (miền Đông)/9 giờ sáng (miền Tây), chất lượng Claude Code giảm thấy rõ theo cảm nhận. Tôi hy vọng đội ngũ tiếp tục tìm và sửa vấn đề. Tôi cũng từng chạy model local ở nhà và gặp nhiều bug phức tạp, nên hiểu những vấn đề này không dễ. <br> Link trang status
  • Tôi không thể khẳng định Claude tốt hơn hay tệ hơn các công ty khác, nhưng có một điều chắc chắn là rất nhiều trang status của công ty toàn nói dối. Trên thực tế sự cố xảy ra thường xuyên nhưng lại không được hiển thị trên status page là chuyện rất phổ biến. Giờ đây đến mức khi họ thông báo vấn đề một cách trung thực thì tôi còn thấy ngạc nhiên hơn. Cá nhân tôi chưa gặp sự cố nghiêm trọng nào với Claude, nhưng có thể là do tôi may mắn. Từ góc nhìn của tôi, có vẻ Claude còn báo cáo sự cố đầy đủ hơn. Tất nhiên cũng có thể chỉ là ngẫu nhiên
  • Điều còn đáng lo hơn là status page bỏ sót rất nhiều sự cố nhỏ. Mọi nhà cung cấp AI đều vậy. Nếu họ công khai các biểu đồ thống kê như độ trễ token thời gian thực, request thất bại, tốc độ xử lý token mỗi giây, thì chắc hẳn sẽ rất gây sốc. Nhìn vào dữ liệu OpenRouter có thể thấy uptime của API hoàn toàn không tốt. Claude Code cũng thường chậm đến mức phải dừng thủ công rồi thử lại. Đặc biệt là từ 4–6 giờ chiều (giờ Anh) thì chậm rất nặng, đúng khung giờ chồng tải của châu Âu, bờ Đông và bờ Tây Mỹ. Hôm nay ngay cả Gemini AI studio cũng trả lỗi 503 do model quá tải, nhưng status page chẳng hiện gì cả. Tôi tự hỏi nếu Claude v.v. đưa ra gói giá rẻ hơn vào giờ thấp điểm thì có thể phân bố đều nhu cầu hơn không. Tuy vậy, các gói như vậy có thể nhìn bề ngoài khá tiêu cực. Ngoài ra, có vẻ việc đưa GPU GB200 vào vận hành chậm hơn nhiều so với kỳ vọng và cũng có không ít lỗi phần cứng/phần mềm. Vấn đề làm mát bằng chất lỏng dường như cũng không đơn giản chút nào (nếu hỏng thì rất nghiêm trọng)
  • Câu “dù vậy Claude quá tốt nên tôi vẫn trả tiền” tự nó đã là một hàm ý quan trọng. Ở thời điểm hiện tại, chất lượng AI còn quan trọng với khách hàng (trong đó có tôi) hơn cả độ tin cậy của dịch vụ. Tất nhiên các nhà cung cấp rồi sẽ tập trung vào độ tin cậy, nhưng tại sao bây giờ lại phải ưu tiên nó hơn chất lượng?
  • Hiện tượng chất lượng lao dốc gần đây khiến tôi khá bất an. May là tôi chưa dùng AI cho dịch vụ production, nhưng trong quá trình phát triển, việc model đột nhiên “ngu đi” là thứ rất khó lách qua. Ở thời điểm này, tôi còn nghi ngờ liệu các vendor trên openrouter có đang âm thầm cắt bớt context, hạ mức quantization, giảm số expert, hay dùng các chiêu lén lút khác để bớt tài nguyên compute hay không
  • Đây cũng là lý do người ta dùng chiến lược giảm thiểu số incident được ghi trên status page. Đánh giá của khách hàng có thể xấu đi tạm thời, nhưng theo thời gian thì ảnh hưởng tiêu cực sẽ biến mất. Còn nếu duy trì status page một cách nhất quán thì “bằng chứng” về vấn đề sẽ bị lưu lại rõ ràng. Thà đánh lừa còn có lợi hơn về dài hạn. Trên thực tế S3 đã có nhiều lần lỗi và sự cố nhưng không công khai, và cũng chẳng ai làm lớn chuyện. Mọi người nói rất nhiều, nhưng hành vi thực tế lại thưởng cho bên giấu nhẹm. Tất cả growth hacker ở startup đều hiểu rõ điều này
• Có giải thích rằng ngày 25 tháng 8, một cấu hình sai đã được triển khai lên các server TPU của Claude API, gây lỗi trong quá trình sinh token. Tôi quen với lỗi code, nhưng LLM không phải thứ con người trực tiếp viết ra mà là kết quả của quá trình huấn luyện tự động quy mô lớn, nên tôi tò mò không hiểu loại bug như vậy phát sinh thế nào. Ví dụ, nếu model đang trả lời truy vấn tiếng Anh mà đột nhiên chen vào giữa bằng “สวัสดี” (tiếng Thái), thì về mặt cấu trúc chuyện đó được “tiêm” bug vào bằng cách nào?
  • Xét cho cùng, LLM vẫn được chạy bằng code do con người viết. Ở bước cuối, model tạo ra phân phối xác suất trên toàn bộ token (vocab khoảng 200 nghìn token). Sau đó, con người quyết định chọn token tiếp theo theo cách nào. Ví dụ, luôn chọn token có xác suất cao nhất, hoặc chọn ngẫu nhiên trong top-k để tăng tính sáng tạo. Để xử lý top-k sampling hiệu quả, họ biên dịch kernel bằng XLA, và có vẻ bug trong kernel này khiến thỉnh thoảng token ngoài top-k vẫn bị chọn
  • LLM đưa ra phân phối xác suất cho token tiếp theo, còn kết quả thực tế thay đổi theo cách sampling ví dụ. Ví dụ, nếu logic là “chọn ngẫu nhiên trong 4 token có xác suất cao nhất” mà toán tử so sánh bị viết sai, thì sẽ xảy ra hiện tượng như trong bài
  • Giữa người dùng và tham số của model có nhiều lớp code do con người viết
  • Giải thích đơn giản thì có hai giai đoạn: training và inference. Training được tự động hóa trong thời gian dài, còn inference là một software stack riêng chạy ngay khi nhận prompt của người dùng. Stack này liên tục được cập nhật để cải thiện hiệu năng, và trong quá trình đó có thể phát sinh các vấn đề liên quan đến inference như thế này
  • AI kernel dùng phép toán dấu phẩy động, nên trong một số trường hợp lẽ ra không âm thì lại xuất hiện giá trị âm kỳ lạ. Vì lý do hiệu năng, đôi khi người ta tắt kiểm tra overflow, rồi nếu giá trị âm xuất hiện thì lại xử lý nó như một số rất lớn (giống kiểu yêu cầu chỉ số mảng -1 mà lại trả về phần tử cuối cùng)
• Tôi nghĩ nếu người ta cố làm quá trình suy luận LLM mang tính quyết định hơn thì có thể giúp truy vết vấn đề. Gần đây cũng có một bài báo cho rằng “quan niệm phổ biến rằng nguyên nhân là do thứ tự kết hợp số dấu phẩy động thực ra không hẳn là cốt lõi” <br> Giới thiệu bài báo liên quan
  • Lưu lượng mạng hay tải máy vốn dĩ là phi quyết định. Trong tương lai gần, tính quyết định hoàn toàn (ví dụ để audit) có lẽ chỉ thực tế với các công việc batch không nhạy cảm chi phí. Trên thực tế, ngay cả tìm kiếm Google hay việc tải số lượng gợi ý trên mạng xã hội cũng hoàn toàn không mang tính quyết định. Trong hệ phân tán, lời khuyên cốt lõi là graceful degradation, tức vẫn duy trì được một phần dịch vụ; còn trong hệ thống hoàn toàn quyết định thì không thể ứng phó như vậy
  • Thiết kế mang tính quyết định sẽ ảnh hưởng xấu đến hiệu năng. Cuối cùng có lẽ chỉ còn cách tạo thêm một model nữa để theo dõi chất lượng và cảnh báo cho model hiện tại, kiểu như một bài “kiểm tra IQ”
• Tôi đồng cảm với chỗ nói rằng “trên Google Cloud Vertex AI, định tuyến sai từ 27 tháng 8 đến 16 tháng 9 là dưới 0.0004%”. Trong công việc, tôi thực sự dùng CC trên tài khoản đó và không hề cảm nhận có suy giảm chất lượng. Nhìn chung, dù các bug này nghiêm trọng, tôi vẫn thấy chúng hiếm hơn nhiều so với những gì các bài review online đề cập. Giai đoạn phát sinh vấn đề thực ra cũng chủ yếu tập trung trong 1–2 tuần. Tỷ lệ request bị ảnh hưởng trên tổng thể cũng tương đối nhỏ
  • Nhưng ngay trong bài của công ty cũng có câu rằng “30% người dùng Claude Code ít nhất một lần bị định tuyến nhầm sang server sai và gặp suy giảm chất lượng phản hồi”. Định tuyến lại là kiểu “sticky”, nên một khi đã bị gán nhầm server thì các request tiếp theo liên tục bị gửi về cùng server đó. Nếu 30% người dùng Claude Code gặp suy giảm chất lượng thì đây là một bug rất lớn
  • Gần đây, ngay cả khi xảy ra sự cố toàn cầu, các công ty vẫn thường chỉ dùng cách diễn đạt giảm nhẹ như “một số ít người dùng gặp lỗi tăng lên”, rồi chỉ sửa status page sau khi CTO phê duyệt, nên tôi không dễ tin các công ty. Nếu có công ty nào giao tiếp thực sự trung thực thì đó sẽ là lợi thế trên thị trường
• Có ý kiến cho rằng nếu làm cho dịch vụ LLM hoạt động theo kiểu deterministic thì sẽ giúp truy vết vấn đề. Gần đây cũng có nhắc đến một bài báo nói rằng thay vì chỉ quy nguyên nhân cho thứ tự kết hợp của phép toán floating point, thực ra còn có nhiều yếu tố khác làm sụp đổ tính quyết định. Link bài báo
• Gần đây tôi gặp hiện tượng khá nghiêm trọng khi Claude trong thiết kế webapp làm xuất hiện ngẫu nhiên đủ loại text trong DOM. Có vẻ điều này xảy ra đặc biệt khi dùng cùng với svelte; tôi không chắc nó có liên quan tới các hiện tượng trong bài hay không, nhưng trước đây tôi chưa từng gặp mức suy giảm chất lượng nghiêm trọng như vậy
• Tôi ước gì bài viết có kèm các case thất bại thực tế là gì. Tôi thường xuyên gặp hiện tượng Claude Code dừng hẳn sau khi gọi tool, nên muốn biết liệu đó có phải do một trong các bug được nhắc lần này hay không
  • Tôi cũng ngày càng gặp nhiều hơn đúng vấn đề này trong vài ngày gần đây. Tôi nghĩ có thể nó tách biệt với bug trong bài (dù vẫn là bug), nhưng hy vọng phỏng đoán của tôi là sai. Tần suất tôi phải gửi lại các yêu cầu như “Tại sao bạn dừng lại? Hãy tiếp tục đi” đã tăng lên rõ rệt