- Claude Code đã chạy A/B test mà không có sự đồng ý của người dùng, khiến cách hoạt động của plan mode thay đổi mà không báo trước và làm giảm hiệu suất công việc
- Với một công cụ chuyên nghiệp giá 200 USD/tháng, việc các tính năng cốt lõi thay đổi mà không thông báo trước là vấn đề về tính minh bạch và quyền kiểm soát của người dùng
- Một trong các thử nghiệm là biến thể rất mạnh tay: giới hạn plan ở 40 dòng, cấm phần ngữ cảnh, và yêu cầu xóa văn xuôi, chỉ để lại đường dẫn tệp
- Kỹ sư Anthropic thực hiện thử nghiệm cho biết mục tiêu là giảm tải rate-limit, nhưng do kết quả ban đầu không cho thấy tác động lớn nên đã dừng thí nghiệm
- Bài viết nhấn mạnh rằng để AI được triển khai một cách đáng tin cậy và có trách nhiệm, quyền kiểm soát của người dùng và việc quản lý thử nghiệm minh bạch là điều thiết yếu
Trải nghiệm người dùng suy giảm do A/B test trong Claude Code
- Với tư cách là một người dùng rất nhiệt thành, xem Claude Code là công cụ đã thay đổi hoàn toàn cách mình làm việc, tác giả cho biết trong tuần qua đã trải qua cảm giác quy trình làm việc bị xuống cấp
- Anthropic đang chạy A/B test trong Claude Code, và điều này đang trực tiếp làm suy giảm quy trình làm việc của người dùng
- Bản thân A/B test không phải là điều sai, và Anthropic cũng không cố tình làm trải nghiệm tệ đi, nhưng thiết kế thử nghiệm mới là điều quan trọng; vấn đề nằm ở việc thay đổi cảm nhận vận hành của một tính năng cốt lõi như plan mode mà không giải thích lý do
Yêu cầu minh bạch đối với công cụ trả phí
- Vì đây là một công cụ làm việc chuyên nghiệp có giá 200 USD/tháng, người dùng cần có tính minh bạch và khả năng cấu hình đối với cách nó vận hành
- Việc tính năng cốt lõi thay đổi mà không báo trước, hoặc bị đưa vào các thử nghiệm mang tính phá vỡ mà không có sự đồng ý, là điều khó chấp nhận
- Để có thể điều hướng (steer) công cụ AI một cách có trách nhiệm, tính minh bạch và khả năng thiết lập là yếu tố cốt lõi, và người dùng phải được hỗ trợ để làm điều đó
- Mỗi ngày đều có các kỹ sư phàn nàn về regression của Claude Code, và có những người thậm chí còn không biết mình có đang nằm trong nhóm A/B test hay không
Nội dung thử nghiệm và bằng chứng
- Các plan được tạo ra bắt đầu chỉ còn là danh sách gạch đầu dòng ngắn gọn, không có ngữ cảnh
- Khi hỏi Claude vì sao lại viết plan tệ như vậy, tác giả nhận được câu trả lời rằng nó đang làm theo chỉ thị hệ thống cụ thể: hard cap plan ở 40 dòng, cấm phần ngữ cảnh, và “xóa văn xuôi, chỉ để lại đường dẫn tệp”
- Về phương pháp bằng chứng cụ thể, tác giả nói rằng vì chủ đề này đang được chú ý trên Hacker News nên đã xóa bớt chi tiết để tránh người khác lặp lại thử nghiệm tương tự
- Tác giả chỉ ra rằng cách làm này đi ngược lại tính minh bạch và việc triển khai/sử dụng AI có trách nhiệm
Phản ứng trên Hacker News và góc nhìn chi phí
- Một bình luận trên Hacker News chỉ ra rằng Anthropic phải đưa ra lựa chọn về thông lượng ở từng bước trong Claude Code; nếu đẩy mọi thứ lên mức tối đa thì mức lỗ trên mỗi người dùng sẽ tăng hoặc lợi nhuận sẽ giảm
- Có quan điểm cho rằng 200 USD/tháng trên thực tế có thể tương đương với chi phí 400 USD/tháng, và việc dùng A/B test ở từng phần của quy trình để tìm baseline có thể tốt hơn so với việc đặt giới hạn một cách tùy tiện
Phản hồi từ kỹ sư Anthropic
- Kỹ sư Claude Code đã thực hiện thử nghiệm này trực tiếp phản hồi trong luồng thảo luận trên Hacker News
- Prompt của plan mode hầu như không thay đổi đáng kể kể từ dòng mô hình 3.x, và mô hình 4.x có thể hoạt động thành công chỉ với ít chỉ thị hơn nhiều
- Giả thuyết là nếu rút ngắn plan thì có thể đạt được kết quả tương tự trong khi giảm số lần chạm rate-limit
- Họ đã chạy nhiều biến thể, và tác giả bài viết này (cùng hàng nghìn người dùng khác) được phân vào biến thể mạnh tay nhất là giới hạn plan ở 40 dòng
- Do kết quả ban đầu không cho thấy ảnh hưởng lớn đến rate limit nên thử nghiệm đã bị dừng
- Việc lập kế hoạch (planning) có hai mục đích: giúp mô hình đi đúng hướng, và giúp người dùng có niềm tin vào hành động tiếp theo của mô hình; cả hai đều là những vùng mơ hồ, phức tạp và không hiển nhiên
Kết luận: Trách nhiệm trong thử nghiệm công cụ AI và niềm tin của người dùng
- Tác giả cho rằng trường hợp Claude Code cho thấy các thử nghiệm trên công cụ AI có thể tác động trực tiếp đến trải nghiệm người dùng
- Bài viết nhấn mạnh rằng quản lý thử nghiệm minh bạch và bảo đảm quyền lựa chọn của người dùng là điều thiết yếu để duy trì niềm tin vào công cụ chuyên nghiệp
- Dù các hệ thống AI tiếp tục phát triển, vẫn cần tái khẳng định rằng phải duy trì một cấu trúc mà con người có thể kiểm soát được
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ việc mô tả A/B testing là “một thử nghiệm âm thầm trên người dùng” rồi nhắc đến Meta là hơi quá
Bản thân A/B testing không xấu, mà thiết kế thử nghiệm mới là điều quan trọng
Tuy vậy, những thử nghiệm làm suy giảm nghiêm trọng hiệu năng của LLM thì không thể chấp nhận được
Vấn đề về khả năng tái lập và độ tin cậy vốn đã rất nghiêm trọng, mà các công ty lại đang đẩy gánh nặng đó sang cho người dùng
Trong tình huống như vậy, nếu công ty âm thầm làm thí nghiệm thì độ tin cậy của nghiên cứu sẽ sụp đổ hoàn toàn
Với trường hợp như Claude Code, ngay cả khi A/B testing gây ra kết quả tiêu cực thì cũng có thể bị bỏ qua với lý do “có thể đó là nhóm thử nghiệm”
Đặc biệt nếu những thử nghiệm như vậy diễn ra trong các lĩnh vực nhạy cảm như tuyển dụng thì vấn đề đạo đức và pháp lý sẽ trở nên nghiêm trọng
Tự nhiên UI hay tính năng thay đổi, hỏi đồng nghiệp thì không ai biết chuyện gì đang xảy ra
Thường thì những thay đổi kiểu này còn tệ hơn, vậy mà vẫn bị ép triển khai nhân danh “dữ liệu khách quan”
Dù chỉ là chi tiết nhỏ như màu nút bấm thì cuối cùng nó vẫn là một thử nghiệm, mà đa số người dùng còn không hề được thông báo là mình đang bị thử nghiệm
Đó là bài test do chính tôi thực hiện
Tôi đã thử xem liệu có thể đơn giản hóa prompt plan-mode vốn được duy trì từ dòng 3.x trên model 4.x mà vẫn cho ra kết quả tương tự hay không
Tôi giả định rằng nếu rút ngắn kế hoạch thì sẽ ít đụng rate-limit hơn, nhưng vì không có khác biệt lớn nên tôi đã dừng thử nghiệm
Chế độ kế hoạch có hai mục đích: giúp model định hướng và giúp người dùng tin tưởng kết quả hơn
Chi phí không phát sinh từ phần văn bản plan mà từ giai đoạn khám phá (subagent)
Plan mode luôn khởi chạy 3 agent khám phá và không xét đến trạng thái phiên làm việc
Ngay cả khi đã có sẵn các file được nạp, nó vẫn đọc lại nên gây lãng phí token
Khi session đang ấm, logic điều kiện để bỏ qua bước khám phá sẽ hiệu quả hơn
Chỉ một hành vi ngoài dự kiến cũng có thể khiến tôi tê liệt trong nhiều ngày
Không cân nhắc đến tác động như vậy là vô trách nhiệm và mang tính công kích
Những hành vi lạ gần đây có thể cũng là do thử nghiệm nên rất khó chịu
Thay vì kênh beta, cần chuyển sang opt-in rõ ràng
Cá nhân tôi cho rằng điều quan trọng hơn số dòng là độ rõ ràng về mặt tường thuật của kế hoạch
Cần có một kế hoạch cho thấy có thể hiểu được đang làm gì và vì sao làm vậy
LLM hoàn hảo về mặt ngữ pháp nhưng lại trộn vào ảo giác (hallucination) khiến người dùng bối rối
Dù vậy, nó vẫn hữu ích cho các tác vụ boilerplate hoặc nối nhanh các ý tưởng
Nhưng để dùng đúng thì kiến thức nền tảng là bắt buộc
Lý do bài viết kết thúc đột ngột là vì tác giả đang đề cập đến việc decompile binary Claude Code rồi xóa phần đó do có khả năng vi phạm ToS
Có thể xem thảo luận liên quan ở bình luận này
Tôi có hai suy nghĩ
Vì không thể cải tiến dựa trên dữ liệu thu được từ A/B testing quy mô lớn
Ví dụ như những thay đổi khó đoán kiểu easter egg ‘after midnight’ của man-db
Lại còn nhiều dependency, nên gần như chẳng có ai thực sự audit code
Nó cũng có thể là thử nghiệm kiếm tiền (enshittification) — YouTube là ví dụ tiêu biểu
Bản thân A/B testing không có vấn đề gì, nhưng plan mode thì không ổn
Trong đa số trường hợp kết quả đều tệ
Tuy vậy, khả năng giữ thông tin qua các lần compaction của nó lại tốt
Nếu ghi lại nội dung hội thoại vào file Markdown rồi để nó tham chiếu mỗi lần compaction thì có thể cho kết quả tốt hơn nhiều
plan mode hiệu quả hơn hẳn nên tôi dùng trước gần như mọi công việc
Ưu điểm là có thể xem lại và thảo luận kế hoạch trước khi model thực thi
Hiện tại plan mode khi hoàn tất sẽ khởi tạo lại context để có thể lập kế hoạch tiếp theo một cách gọn gàng, điều này rất tốt
Thật đáng tiếc khi trên blog, chi tiết decompile đã bị xóa vì vấn đề ToS
Claude được cho là đã làm theo chỉ thị hệ thống kiểu “giới hạn kế hoạch trong 40 dòng, cấm các mục ngữ cảnh, và xóa phần văn xuôi”
Sẽ rất tốt nếu có thể trực tiếp xem và chỉnh sửa các thiết lập như vậy
Công cụ chuyên nghiệp phải mang lại độ tin cậy và khả năng tái lập, nhưng LLM thì không như vậy
A/B testing chỉ là bằng chứng cho điều đó
Những thử nghiệm như Photoshop tự ý đổi nhẹ sắc độ, hay Word đổi kiểu tiêu đề cũng là cùng một vấn đề
Vấn đề nằm ở chính việc A/B testing không có cảnh báo
Hạn mức quota và chất lượng model đều bất ổn, và trước khi model mới ra mắt thường có giai đoạn model cũ bị xuống cấp
Thử nghiệm lần này cũng có vẻ là thử nghiệm cắt giảm chi phí hơn là để cải thiện trải nghiệm người dùng
Nếu là công cụ cho doanh nghiệp thì cần tính nhất quán và độ tin cậy
Người làm chuyên môn phải hiểu điểm mạnh và điểm yếu của công cụ rồi sử dụng cho phù hợp
Mù quáng chấp nhận đầu ra của LLM là không chuyên nghiệp, nhưng điều đó cũng không có nghĩa là chuyên gia không thể dùng LLM
Nếu có hệ thống đánh giá đủ tốt và kiểm soát prompt phù hợp thì có thể khiến nó khá mang tính quyết định
Nhìn vào việc các model bất ổn trong ngành tài chính vẫn đang được vận hành thì có thể thấy tính khó đoán không phải là rào cản tuyệt đối
Tôi vẫn sẽ kiểm chứng đầu ra của model như đang review code của đồng nghiệp
Kiểu tình huống này từ lâu đã được gọi là vendor lock-in
Khi phụ thuộc vào một công cụ cụ thể, nếu công cụ đó thay đổi hoặc biến mất thì sẽ không thể làm việc được nữa
Tôi đã chuyển từ CC sang opencode
CC quá khép kín và prompt thì quá mang tính áp đặt quan điểm (opinionated) nên rất khó chịu
Tôi cũng không thể kiểm soát đường đi của web search
Giờ tôi chỉ dùng cho sở thích nên chọn mã nguồn mở, nhưng nếu là vì công việc thì có lẽ tôi đã quyết định khác
Nó chỉ dùng được cho các project nhỏ
Nếu có cấu hình nào ổn thì mong bạn chia sẻ