Một trong những điểm tuyệt vời nhất của các model Claude mới nhất là cách chúng phản hồi theo mức effort (nỗ lực) mà không làm vỡ prompt cache trong Claude Code, nhưng tôi đã nhận được rất nhiều câu hỏi từ người dùng về vấn đề này. Effort thực chất là gì và khi nào thì nên dùng mức effort nào? Tại sao chúng ta lại cần đến effort?
Để trả lời, tôi quyết định đào sâu vào các bài eval và tự mình thử nghiệm effort trên những công việc thường ngày.
lưu ý: bạn có thể xem thêm các sơ đồ tương tác và phần giải thích cho bài viết này tại https://claude.dev/blog/spending-your-effort/
Nhìn chung, tôi nhận thấy effort là một cách tuyệt vời để thay đổi mức độ kiểm tra, xử lý các trường hợp biên (edge case) của Claude, cũng như mức độ tự đưa ra phán đoán của nó.
Mức effort cao hơn mang lại kết quả tốt hơn ở những lĩnh vực mà việc kiểm tra và xử lý edge case phát huy tác dụng rõ rệt, chẳng hạn như phần cứng, code review và bảo mật.
Nhưng effort thấp và trung bình lại hoàn hảo để hoàn thành công việc nhanh chóng và giúp bạn luôn sát sao cùng Claude trong suốt quá trình.
Với công việc kỹ sư phần mềm thông thường, giờ đây tôi áp dụng một vòng lặp: để model phỏng vấn tôi trước, sau đó triển khai ở mức effort thấp/trung bình, xem xét lại những gì nó vừa xây dựng, rồi chạy kiểm tra xác minh ở mức effort cao.
Effort là gì?
Về cơ bản, effort cung cấp cho model một ước lượng về lượng compute mà bạn muốn nó dành ra cho tác vụ. Điều này phần nào liên quan đến cách bạn đánh giá độ khó của tác vụ đó.
Hãy hình dung thế này: nếu ai đó yêu cầu bạn làm một việc liên tục trong 12 tiếng, bạn sẽ mặc định rằng họ chỉ muốn bạn bắt tay vào làm và cố gắng hết sức. Nhưng nếu họ yêu cầu bạn hoàn thành chính việc đó trong 1 tiếng, bạn sẽ cố đưa ra phiên bản tốt nhất đáp ứng được yêu cầu, rồi kỳ vọng sẽ tinh chỉnh dần từ đó.
Hoặc, bạn có thể phản biện lại rằng tác vụ này cần ít nhất 3 tiếng, rồi làm đúng 3 tiếng để bàn giao.
Bạn nên hiểu effort theo cách tương tự. Claude luôn cố gắng hoàn thành tác vụ của bạn một cách hợp lý, nhưng mức effort càng cao thì Claude càng chủ động hành động độc lập để phán đoán và kiểm chứng.
Đường cong effort
Đường cong effort của Fable 5.1 và Opus 5.5 là tốt nhất từ trước đến nay: ở mỗi mức, điểm benchmark và lượng token tiêu thụ đều tăng lên. Dưới đây là biểu đồ điểm Terminal Bench 3.0 theo từng mức effort, được đo trong các lượt eval tôi chạy cho bài viết này.
Nhưng điều này có ý nghĩa gì trong thực tế? Để đánh giá, tôi đã thử một số tác vụ ở các mức effort khác nhau và phân tích kỹ lưỡng các benchmark.
Xây dựng sản phẩm với effort
Cách tốt nhất để hiểu các model hoạt động ra sao là trực tiếp thử nghiệm. Tôi đã làm cùng một tác vụ ở nhiều mức effort khác nhau trên Opus 5.5 để xem nó sẽ xử lý công việc như thế nào. Tôi thử trên rất nhiều loại công việc, nhưng ở đây sẽ minh họa bằng vài ví dụ đơn giản.
Tác vụ xây dựng thiếu chi tiết
Nếu tôi yêu cầu Claude "xây dựng một ứng dụng theo dõi thể trạng và tập luyện cá nhân", effort sẽ thay đổi đáng kể độ hoàn thiện của ứng dụng, đồng thời khiến Claude phải tự đưa ra nhiều quyết định hơn trong quá trình thực hiện. Ở mức effort thấp, ứng dụng chỉ là một cuốn nhật ký kèm biểu đồ đơn giản. Ở mức effort cao hơn, ứng dụng phức tạp hơn với nhiều chi tiết bổ sung. Còn ở mức max effort, thậm chí có cả biểu đồ nhiệt (heat chart).
Nếu tôi chỉ cần một nền tảng đơn giản để phát triển thêm, effort thấp là đủ. Max effort sẽ phù hợp khi tôi muốn Claude tung ra phiên bản tốt nhất ngay từ lần đầu tiên.
Tác vụ thiết kế có mô tả sơ lược
Vậy nếu tôi có một tác vụ đã được mô tả khá rõ ràng nhưng vẫn muốn cùng Claude khám phá thêm thì sao? Ví dụ, tôi thử yêu cầu nó thiết kế lại menu /config trong Claude Code. Mỗi lượt chạy đều cho ra ý tưởng gần giống nhau: sử dụng submenu và cải thiện tính năng tìm kiếm.
Ở mức effort thấp (mất 1 phút), tôi nhận được một bản phác thảo tương tác truyền tải được ý tưởng, nhưng trông không giống Claude Code cho lắm.
Ở mức max effort (mất 28 phút), tôi nhận được một mockup trông y hệt Claude Code, kèm theo hàng loạt hướng dẫn chi tiết cho các luồng thao tác khác nhau.
Nếu mục tiêu của tôi là liên tục tinh chỉnh và đưa ra phản hồi, effort thấp sẽ giúp đi đến đích nhanh hơn nhiều. Nhưng max effort lại mang đến một sản phẩm trau chuốt hơn hẳn ngay từ đầu. Với riêng tác vụ này, tôi nghĩ mình thích dùng effort thấp hơn để hiểu được tầm nhìn của Claude.
Tác vụ xây dựng được mô tả chi tiết
Còn nếu tôi cung cấp cho Claude thật nhiều chi tiết thì sao? Tôi thử yêu cầu Claude phỏng vấn tôi thật kỹ về ứng dụng thể trạng, sau đó đưa bản mô tả đó cho các model khác nhau triển khai ở các mức effort khác nhau.
Tôi nhận thấy khi có bản mô tả chi tiết, các model hoạt động khá giống nhau. Tôi thu được những thiết kế trông tương đối đồng nhất và có cách triển khai tương tự, chỉ khác biệt ở một vài chi tiết nhỏ; ở mức max effort, Claude dành thêm chút thời gian để đơn giản hóa một số chi tiết.
Điểm mấu chốt
Đối với công việc kỹ sư phần mềm thông thường, đặc biệt là phát triển tính năng mới, mức effort phụ thuộc nhiều vào việc bạn muốn tham gia sâu đến đâu. Effort thấp cho phép Claude phản hồi nhanh để tạo ra điểm khởi đầu, còn effort cao hơn sẽ hoàn thành được nhiều việc hơn nhưng bù lại Claude cũng sẽ tự đưa ra nhiều giả định thay bạn.
Một vòng lặp cực kỳ hiệu quả cho việc phát triển tính năng mà tôi đang áp dụng là:
- Đưa cho Claude một bản mô tả và yêu cầu nó phỏng vấn bạn về bất kỳ chi tiết nào còn thiếu
- Triển khai ở mức effort thấp
- Xem xét lại để đảm bảo nó đã nắm đúng ý chính, tinh chỉnh thêm ở mức effort thấp nếu cần
- Kiểm tra và test ở mức effort cao
Các mức effort ảnh hưởng thế nào đến output trong những tác vụ khó
Tất nhiên, những ví dụ trên đều khá đơn giản và Claude dễ dàng hoàn thành. Vậy chuyện gì xảy ra khi ranh giới nằm giữa việc Claude hoàn thành hay thất bại?
Để tìm ra những bài toán khó này, bạn phải tìm đến các benchmark, nên tôi đã chọn một cái mà mình thích: Terminal Bench 3, một benchmark do cộng đồng đóng góp.
Các bài toán trong Terminal-Bench 3.0 có thể chia thành nhiều nhóm như bảo mật, phần cứng, ML, khoa học, phần mềm, vận hành và media. Bạn có thể xem toàn bộ danh sách tại đây: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0, chúng được lấy từ cộng đồng nên ai cũng có thể đóng góp.
Rất đáng để đọc qua nhằm hình dung được loại vấn đề mà các model này phải đối mặt. Cá nhân tôi khá bất ngờ trước quy mô và độ tham vọng của nhiều tác vụ trong số đó. Chúng phức tạp hơn nhiều so với những tác vụ trung bình mà tôi thường gặp.
Ví dụ, một số tác vụ bao gồm:
- Phần cứng (retro-console-soc): xây dựng một máy chơi game 8-bit bằng Verilog vừa với một FPGA nhỏ và render được một ROM test.
- Khoa học (takens-embedding-lean): chứng minh hình thức định lý nhúng Takens trong Lean 4.
- ML (mp-checkpoint-consolidation): gộp 16 shard của một checkpoint mixture-of-experts thành một file duy nhất tái tạo được logits tham chiếu.
- Vận hành (intrastat-meldung): thực hiện toàn bộ quy trình nộp báo cáo thống kê thương mại EU cuối tháng của một công ty từ đầu đến cuối.
- Media (layout-config-recreation): dựng lại một hình ảnh poster thành file layout có thể chỉnh sửa.
Effort cao hơn sẽ hữu ích khi có nhiều edge case
Bài học lớn nhất tôi rút ra khi đọc kết quả Terminal Bench 3 là effort cao phù hợp nhất với những tác vụ chứa nhiều edge case ẩn.
Một ví dụ điển hình là html-js-filter, tác vụ Terminal-Bench 3.0 yêu cầu tạo một bộ lọc HTML loại bỏ mọi cách chèn JavaScript trái phép vào trang. Fable 5.1 đã tăng từ 1/5 ở mức low lên 5/5 ở mức xhigh.
Một lượt thử ở mức effort thấp thường mất khoảng 2 phút. Mỗi lượt như vậy sẽ viết bộ lọc gần như trong một lần duy nhất, rồi test nó trên một trang HTML viết tay đơn lẻ.
Một lượt chạy effort cao mất khoảng 33 phút. Trong lượt chạy mà tôi theo dõi, model đã tự phản biện bản nháp đầu tiên của mình, sau đó đọc mã nguồn của parser đã cài đặt để dò lỗi, chạy rất nhiều test case sạch cho đến khi output khớp với input, chạy một bộ test XSS tiêu chuẩn, và cuối cùng là viết một fuzzer tài liệu ngẫu nhiên.
Với một thứ đầy edge case như bộ lọc HTML, nỗ lực bỏ ra thêm này hoàn toàn xứng đáng. Việc tiêu tốn nhiều token hơn để đảm bảo độ chặt chẽ cũng hợp lý với các tác vụ phức tạp đòi hỏi chất lượng production cao, như tối ưu hiệu suất hay review bảo mật.
Nhưng bạn không cần mức effort cao như vậy cho mọi tác vụ.
Biểu đồ dưới đây hiển thị toàn bộ kết quả Terminal-Bench 3.0 và nguyên nhân thất bại, trên các model và mức effort khác nhau. Nhìn chung, tăng effort có xu hướng giảm số lỗi do bỏ sót edge case (khối màu tím), nhưng không khắc phục được khi model chọn sai hướng tiếp cận (khối màu xanh dương).
Những mảng bài toán mà effort phát huy tác dụng
Một trong những phát hiện thú vị nhất với tôi khi đánh giá các model này trên TerminalBench là có một số mảng bài toán hưởng lợi từ effort nhiều hơn hẳn những mảng khác. Bạn có thể xem chi tiết trong biểu đồ sau:
Để minh họa, tôi chọn một vài bài toán từ các mảng khác nhau trong Terminal Bench 3.0 mà Opus 5.5 thất bại ở mức effort thấp nhưng thành công ở mức effort cao – chủ yếu nhờ việc nó đã test và lường trước được các edge case:
mvcc-lsm-compaction: một tác vụ Terminal-Bench 3.0 yêu cầu sửa lỗi storage-engine dựa trên crash report mà không làm hỏng quá trình compaction. Opus 5.5 tăng từ 0/5 ở mức low lên 4/5 ở mức xhigh.
Ở mức low (khoảng 1 phút mỗi lượt), Claude sẽ sửa code trước khi build hoặc chạy reproducer, và không kiểm tra xem test mới của nó có phát hiện được lỗi gốc hay không.
Ở mức xhigh (khoảng 11 phút), Claude tái hiện lỗi crash trước, viết một test ngẫu nhiên đối chiếu với bản tham chiếu không bao giờ compact, và kiểm tra xem test của nó có thất bại trên các bản sửa chưa hoàn chỉnh hay không.
cli-2ph-simple: là tác vụ Terminal-Bench 3.0 yêu cầu viết một CLI giải bài toán quy hoạch tuyến tính bằng Python. Opus 5.5 tăng từ 0/5 ở mức low lên 5/5 ở mức high.
Các lượt chạy mức low viết solver trong một lần duy nhất, kiểm tra bằng vài bài toán nhỏ rồi dừng lại ở khoảng 10k token. Trong tin nhắn cuối, Claude cảnh báo rằng nó có thể chậm với các bài toán lớn, nhưng không hề kiểm chứng.
Trong các lượt chạy mức high, Claude test solver của mình trên các bài toán ngẫu nhiên, đối chiếu với một solver brute-force riêng biệt, sau đó đo thời gian chạy với các bài toán lớn hơn, phát hiện những trường hợp chạy quá lâu hoặc bị crash, rồi làm lại thuật toán tìm kiếm.
gsea-proteomics: một tác vụ Terminal-Bench 3.0 yêu cầu thực hiện phân tích làm giàu tập gen (GSEA) trên dữ liệu proteomics để tìm xem phương pháp nào trong tám phương pháp điều trị giống với mô đích. Opus 5.5 tăng từ 0/5 ở mức low lên 4/5 ở mức high.
Ở mức effort thấp, Claude chọn một cách xử lý dữ liệu nghe có vẻ hợp lý, chạy phân tích theo cách đó và báo cáo kết quả.
Ở mức high, Claude thử hai cách xử lý dữ liệu, nhận thấy danh sách các phương pháp điều trị có ý nghĩa thống kê bị thay đổi, và đào sâu tìm hiểu nguyên nhân trước khi chọn ra cách đúng.
Nếu có người dùng tham gia vào vòng lặp, Claude có thể đã hỏi người dùng về cách thiết lập bài toán, nhưng khi không có người dùng, effort cao sẽ làm tốt hơn.
Khi nào nên dùng các mức effort khác nhau trong Claude Code
Đây là quy tắc chung của tôi về thời điểm sử dụng từng mức effort:
- Low: khi tôi cần phản hồi nhanh và muốn sát sao trong quá trình làm việc, ví dụ: brainstorm, phác thảo, những thay đổi đơn giản.
- Medium: cho phần lớn công việc kỹ sư phần mềm thường ngày, ví dụ: triển khai tính năng mới.
- High: cho những công việc mà khâu kiểm tra xác minh là quan trọng hoặc có nhiều edge case, ví dụ: sửa bug trong một codebase brownfield.
- Max: khi tôi muốn Claude hoạt động hoàn toàn tự chủ để giải quyết các bài toán khó, ví dụ: xây dựng và kiểm tra một ứng dụng từ đầu đến cuối, tìm lỗ hổng bảo mật trong phần mềm quan trọng.
Hãy thử thay đổi mức effort cho Opus 5.5 và Fable 5.1 tùy theo tác vụ, hoặc thậm chí ngay giữa cuộc hội thoại bằng lệnh /effort trong Claude Code, và cho tôi biết liệu điều này có khớp với trực giác của bạn không nhé.
