Vì sao Opus 5 cảm giác làm việc tệ hơn?

14 tháng 8, 2026·4 phút đọc

Bài viết phân tích cảm nhận của nhiều lập trình viên khi làm việc với Opus 5 – mô hình AI mới của Anthropic – dù mạnh hơn về hiệu năng nhưng lại kém 'dễ chịu' hơn các phiên bản trước. Nguyên nhân được cho là do định hướng tối ưu benchmark khiến mô hình có xu hướng tự suy đoán, thay vì dừng lại hỏi khi gặp sự mơ hồ – điều rất quan trọng trong thực tế viết mã.

Vì sao Opus 5 cảm giác làm việc tệ hơn?

Theo cảm nhận của tác giả và nhiều đồng nghiệp, việc làm việc với Opus 5 – mô hình AI mới nhất của Anthropic – giống như một sự "tụt cấp" so với Opus 4.7, Opus 4.8 và Fable. Dù mô hình này vượt trội về khả năng kỹ thuật và thậm chí ngang ngửa Fable trong các bài benchmark, nhưng trải nghiệm thực tế lại khiến người dùng phải "giám sát" kỹ hơn. Nguyên nhân được cho là nằm ở cách mô hình được huấn luyện để đạt điểm cao, dẫn đến việc nó có xu hướng tự đưa ra giả định táo bạo thay vì dừng lại hỏi khi gặp sự mơ hồ.

Vấn đề không nằm ở hiệu năng

Tác giả khẳng định không phủ nhận sức mạnh của Opus 5 – nó thực sự là một mô hình mạnh hơn hẳn các phiên bản trước. Tuy nhiên, cảm giác "làm việc tệ hơn" đến từ cách mô hình tương tác với con người. Cụ thể, các phiên bản cũ như Opus 4.7 hay 4.8 thường:

  • Dừng lại và đặt câu hỏi khi ý định của người dùng chưa rõ ràng,
  • Kiểm tra trước khi giả định, tránh suy đoán vội vàng,
  • Không tự ý diễn giải hoặc thay đổi kế hoạch của người dùng khi chưa được phép.

Nhờ vậy, người dùng không phải liên tục "trông chừng" mô hình như khi làm việc với Opus 5. Đây là khác biệt rất lớn trong trải nghiệm thực tế, đặc biệt với các tác vụ viết mã phức tạp.

Suy đoán về nguyên nhân gốc rễ

Tác giả đưa ra giả thuyết rằng vấn đề này đến từ hai áp lực cộng hưởng tại Anthropic nói riêng và các phòng lab AI tiên tiến nói chung:

Thứ nhất, khát vọng tạo ra một AI có khả năng tự cải thiện và tự khởi động để tiến tới AGI/ASI. Điều này thúc đẩy việc thiết kế các mô hình ít phụ thuộc vào con người hơn.

Thứ hai, áp lực phải đạt điểm cao trong các bài benchmark. Dù ai cũng biết nhiều bài benchmark hiện nay có vấn đề về thiết kế, nhưng một bài tốt thường phải tự chứa đủ thông tin, không cần hỏi thêm hay dựa vào dữ kiện bên ngoài. Một bài như vậy có thể có nhiều đáp án đúng, nhưng tất cả đáp án đều phải được chấm điểm như nhau.

Chính việc chọn lọc và huấn luyện mô hình để vượt qua các bài benchmark (đặc biệt là các tác vụ RLVR) đã vô tình ưu ái những mô hình dám đưa ra giả định táo bạo và thường là đúng khi gặp sự mơ hồ. Ngược lại, các mô hình có xu hướng dừng lại hỏi người dùng sẽ bị "phạt" vì thiếu quyết đoán.

Thực tế không phải là một bài benchmark

Điểm mấu chốt mà tác giả muốn nhấn mạnh: hầu hết chúng ta đều muốn một coding agent biết dừng lại hỏi khi cần, chứ không phải một AI chỉ biết đoán. Dù cố gắng đến đâu, bạn cũng khó lòng truyền đạt hết toàn bộ bối cảnh công việc – từ ý định, yêu cầu kinh doanh, ngân sách, cho đến các ràng buộc ngầm – cho một mô hình AI.

"Cuộc sống thực không phải là một bài benchmark. Không có câu trả lời đúng được đảm bảo cho mọi câu hỏi, thậm chí không có một tập hợp câu trả lời đúng, và khi kết quả có thể ảnh hưởng trực tiếp đến công việc thực tế, tôi không muốn một agent tự ý đưa ra phán đoán tốt nhất của nó!"

Góc nhìn cho người dùng Việt Nam

Với cộng đồng lập trình viên và người dùng AI tại Việt Nam, câu chuyện này rất đáng lưu ý. Khi lựa chọn mô hình AI để hỗ trợ viết mã, đừng chỉ nhìn vào kết quả benchmark – vì những con số đó thường không phản ánh độ "hợp tác" của mô hình trong thực tế. Với các dự án phần mềm có yêu cầu nghiệp vụ phức tạp (như ngân hàng, logistics, chính phủ điện tử...), khả năng hỏi lại khi giao việc không rõ ràng quan trọng hơn nhiều so với khả năng "đoán mò" ra mã nhanh.

Nếu bạn đang cân nhắc nâng cấp lên Opus 5, hãy thử nghiệm kỹ trên các tác vụ thực tế của mình – đặc biệt là những tác vụ có nhiều sự mơ hồ, và xem liệu việc phải liên tục giám sát, sửa sai có làm mất nhiều thời gian hơn so với lợi ích về tốc độ hay không.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗