Tóm tắt:
Phần tiêu đề “Tóm tắt:”- Việc chọn model quyết định bộ trọng số (weights) cố định nào sẽ xử lý request, tức là phạm vi năng lực tổng thể của model đó. Model có thể được cấp thêm ngữ cảnh hoặc “lái” theo hướng nào đó, nhưng kiến thức nền và năng lực tổng thể của nó là cố định.
- Effort không chỉ đơn thuần là “thời gian suy nghĩ”. Nó kiểm soát tổng khối lượng công việc Claude làm cho request của bạn, bao gồm số file được đọc, số tool được dùng, và Claude đi được bao xa trước khi quay lại hỏi ý bạn.
- Chọn model nhỏ hơn cho các tác vụ thường quy, model lớn hơn cho tác vụ phức tạp hoặc mơ hồ. Bắt đầu với effort level mặc định của mỗi model, sau đó tinh chỉnh như một sở thích chung dựa trên loại công việc bạn hay làm, thay vì quyết định theo từng tác vụ riêng lẻ.
- Nếu Claude đã có đủ ngữ cảnh liên quan, rõ ràng đã cố gắng, mà vẫn làm sai - đó là tín hiệu để chọn model mạnh hơn. Nếu Claude làm sai vì bỏ qua một file, không chạy test, hoặc bỏ dở một việc refactor giữa chừng - đó là tín hiệu để chọn effort level cao hơn.
Chọn model và effort level trong Claude Code
Phần tiêu đề “Chọn model và effort level trong Claude Code”Claude Code cho bạn hai lựa chọn có vẻ đều “làm câu trả lời tốt hơn”: model và effort level. Bạn có thể nghĩ rằng model lớn hơn như Claude Fable 5 sẽ cho ra kết quả thông minh hơn Claude Sonnet, và effort level cao hơn nghĩa là Claude suy nghĩ lâu hơn trước khi trả lời.
Giả định đầu tiên là đúng. Các model lớn nhất của Anthropic có năng lực cao hơn, theo các benchmark chuẩn của ngành.
Nhưng effort không chỉ đơn thuần là “thời gian suy nghĩ”. Effort level kiểm soát tổng khối lượng công việc Claude làm cho request của bạn. Nó bao gồm cả việc model suy nghĩ bao lâu, nhưng cũng bao gồm:
- Nó đọc bao nhiêu file;
- Nó xác minh (verify) kỹ đến đâu; và
- Nó đi được bao xa trong một tác vụ nhiều bước trước khi quay lại hỏi ý bạn.
Ở effort cao hơn, Claude sẽ thực hiện nhiều hành động dạng này hơn (ví dụ: đọc file, chạy test, kiểm tra lại) trước khi quay lại với bạn. Ở effort thấp hơn, nó thà hỏi bạn thêm ngữ cảnh còn hơn tốn token để tự mày mò.
Cách chọn model hoạt động
Phần tiêu đề “Cách chọn model hoạt động”Khi bạn nhấn enter, Claude Code ghép tin nhắn của bạn cùng với system prompt, định nghĩa tool, CLAUDE.md của bạn, lịch sử hội thoại, và mọi file đang trong ngữ cảnh. Tất cả được gửi thành một request duy nhất tới API.
Tuy nhiên, model không nhìn thấy đó là văn bản thuần. Việc đầu tiên xảy ra trên server là tokenization: văn bản được cắt thành từng mẩu, và mỗi mẩu được ánh xạ vào một số nguyên trong một bộ từ vựng cố định mà model đã được huấn luyện. const có thể ánh xạ thành 1978, await có thể ánh xạ thành 4293. Từ đây trở đi, prompt của bạn là một mảng số nguyên.
Việc của model là nhận mảng đó và dự đoán token nào tiếp theo. Nó làm điều này bằng cách tính một xác suất cho từng token trong bộ từ vựng và chọn từ những token có xác suất cao nhất. Sau const x = await, một model được huấn luyện tốt sẽ gán xác suất cao cho fetch (rất có khả năng) và gần như bằng không cho banana (gần như không thể).
Thứ biến các token đầu vào của bạn thành những xác suất đó là trọng số (weights, còn gọi là tham số/parameters). Đây là hàng tỷ con số được tổ chức thành các ma trận lớn. Để dự đoán một token, model chạy đầu vào của bạn qua các ma trận đó - một chuỗi dài các phép nhân ma trận - rồi đọc xác suất ở bước cuối. Trọng số chính là nơi lưu trữ mọi thứ model “biết”.
Trọng số của mỗi model được thiết lập trong lúc huấn luyện, và đến khi bạn gửi request thì chúng chỉ đọc (read-only). Không có gì trong prompt, CLAUDE.md, hay ngữ cảnh của bạn thay đổi được chúng. (Nếu bạn từng gặp từ inference, đó chính xác là ý nghĩa của nó: sử dụng model sau khi đã huấn luyện xong, với trọng số cố định.)
Mọi thứ Claude biết về TypeScript, các framework phổ biến, Go theo lối viết chuẩn (idiomatic), hay bất kỳ kiến thức lập trình tổng quát nào khác, đều đã được mã hoá vào những trọng số đó ngay từ lúc huấn luyện.
Prompt và ngữ cảnh của bạn vẫn có thể lái (steer) dự đoán đó (đưa code thật của bạn vào trước mặt Claude chính là steering, và nó hoạt động rất tốt), nhưng chúng không thêm gì vào bản thân trọng số.
Nếu một thư viện chưa tồn tại lúc model được huấn luyện, nó sẽ không có trong trọng số. Bạn có thể đưa tài liệu của thư viện đó vào ngữ cảnh và Claude sẽ dùng được, nhưng đó là steering, không phải teaching (dạy). Phản hồi của Claude chỉ bị ảnh hưởng cho riêng request đó; bản thân model không giữ lại thông tin này về sau.
Vì vậy khi Claude tự tin gọi một API không tồn tại (hiện tượng hallucination), đó là do trọng số tạo ra một chuỗi token có vẻ hợp lý dựa theo các mẫu đã học trong lúc huấn luyện, chứ không phải một lần tra cứu thất bại.
Vậy việc đổi model thực chất làm gì? Nó hoán đổi bộ trọng số cố định nào sẽ xử lý request của bạn.
Model không tạo ra cả câu trả lời cùng một lúc. Nó dự đoán một token, gắn thêm vào chuỗi, rồi chạy lại toàn bộ phép tính để lấy token tiếp theo. Một phản hồi 200 token là 200 lượt chạy riêng biệt qua trọng số. Vòng lặp này chính là nơi tiêu tốn phần lớn thời gian chờ và chi phí đầu ra của bạn.
Vậy nên lựa chọn model quyết định bộ trọng số nào xử lý request của bạn, và nó cũng quyết định mỗi token đầu ra tốn bao nhiêu.
Điều nó không quyết định là có bao nhiêu token được tạo ra. Con số đó có thể khác nhau rất nhiều cho cùng một prompt, tuỳ vào việc Claude quyết định làm bao nhiêu việc.
Đây chính là thứ mà effort level kiểm soát: khối lượng công việc Claude quyết định làm cho mỗi lượt.
Cách effort level hoạt động trong Claude Code
Phần tiêu đề “Cách effort level hoạt động trong Claude Code”Khi Claude Code đang xử lý một tác vụ, các token nó tạo ra rơi vào một vài nhóm:
- Thinking: quá trình suy luận bạn thấy được stream ra trước và giữa các hành động.
- Tool calls: các khối có cấu trúc gọi tên một tool như Read hay Edit cùng tham số của nó, mà Claude Code sau đó sẽ phân tích và thực thi.
- Văn bản gửi cho bạn: kế hoạch, cập nhật tiến độ, bản tóm tắt ở cuối.
Đây đều là các token đầu ra thông thường từ cùng một vòng lặp, được tính giá theo cùng một mức. Ví dụ, token thinking được tạo ra hệt như các token đầu ra khác và vẫn nằm trong ngữ cảnh cho phần còn lại của lượt đó.
Khi Claude chuyển sang viết code, phần suy luận trước đó của nó trở thành một phần của đầu vào, giống như một file nó đã đọc.
Vậy effort thay đổi điều gì trong tất cả những thứ này? Effort level được gửi tới model như một phần của request, đi cùng với prompt của bạn. Model đã được huấn luyện để hiểu cách hành xử ở mỗi mức effort, và hành vi đã học đó được mã hoá sẵn trong trọng số cố định.
Khi request của bạn tới nơi, effort level là một đầu vào khác mà model phản hồi lại, giống như cách nó phản hồi văn bản prompt của bạn. Nó thiết lập hành vi của Claude về mức độ kỹ lưỡng và chắc chắn cần có trước khi Claude coi tác vụ đã hoàn tất.
Điều này được cân nhắc ở mỗi lượt và dẫn đến nhiều token hơn để tạo ra câu trả lời có độ tin cậy cao hơn.
Ở mức effort cao hơn, Claude thường bắt đầu bằng việc lập một kế hoạch, và mức effort ảnh hưởng đến độ sâu và độ rộng của kế hoạch đó. Tuy nhiên, kế hoạch không bị đóng băng tại chỗ. Khi Claude nhận được kết quả từ các hành động của nó, nó cập nhật lại tiến độ đã đạt được và mức độ chắc chắn về kết quả tích luỹ được.
Vì vậy, khi bước 1 trong một kế hoạch debug với ba giả thuyết đã tìm ra được lỗi, việc “kiểm tra giả thuyết 2 và 3” có thể không còn cần thiết nữa. Claude thường sẽ nói rõ điều này - “lần kiểm tra đầu tiên đã tìm ra rồi, nên các bước kiểm tra còn lại không cần nữa” - và bỏ qua chúng. Bạn sẽ thấy điều này xảy ra trong Claude Code khi danh sách task được cập nhật lại giữa chừng.
Claude sẽ có xu hướng kiểm tra thêm các giả thuyết khác hoặc xác minh tính đúng đắn nhiều hơn ở các mức effort cao hơn, nhưng nhìn chung nó sẽ không cố tình “thổi phồng” mức sử dụng cho các tác vụ đơn giản chỉ vì effort cao. Trên thực tế, đội ngũ Anthropic rất chú ý đến hiện tượng “overthinking” (suy nghĩ quá mức cần thiết) trong quá trình huấn luyện model, vì nó làm giảm hiệu quả.
Chọn effort level
Phần tiêu đề “Chọn effort level”Khuyến nghị của Anthropic là với hầu hết các tác vụ, bạn nên dùng effort level mặc định của model. Mức mặc định là mức mà Claude sẽ điều chỉnh lượng token sử dụng theo đúng những gì phần lớn mọi người muốn chi cho một tác vụ.
Hãy nghĩ về effort như một nút ghi đè thủ công để điều chỉnh Claude làm việc chăm chỉ và lâu đến mức nào. Chọn nó một cách có chủ đích khi bạn có ưu tiên rõ ràng về độ kỹ lưỡng hoặc tốc độ, dựa trên lĩnh vực hoặc loại công việc bạn làm. Hãy coi đây là một sở thích chung hơn là một quyết định cho từng tác vụ riêng lẻ.
Một gợi ý thực tế có thể giúp ích, theo sau lần ra mắt Claude Opus 4.8: trong quá trình thử nghiệm, Anthropic nhận thấy khi dùng effort level mặc định cho Opus 4.8, nó cho ra kết quả tốt hơn với số token gần tương đương so với việc dùng effort level mặc định của Opus 4.7 cho cùng một tác vụ.
Nên thay đổi gì khi Claude làm sai
Phần tiêu đề “Nên thay đổi gì khi Claude làm sai”Khi Claude làm sai điều gì đó, phản xạ đầu tiên của bạn không nên là vặn một cái núm chỉnh, mà nên xem lại ngữ cảnh bạn đã cung cấp. Prompt của bạn có quá mơ hồ không? Claude có được kết nối đúng tool không? Có được trang bị đúng skill không?
Nếu bạn tăng effort cho một tác vụ lẽ ra không cần tới mức đó, vấn đề thường nằm ở phía trước - trong ngữ cảnh, CLAUDE.md, hoặc cách tác vụ được định phạm vi (scope).
Nhưng giả sử bạn đã cung cấp ngữ cảnh rõ ràng và Claude vẫn làm sai điều gì đó, câu hỏi cần tự đặt ra là: nó không cố gắng đủ, hay nó không biết đủ?
Model: vấn đề quá khó
Phần tiêu đề “Model: vấn đề quá khó”Chọn model lớn hơn khi vấn đề thực sự khó. Ví dụ: các lỗi tinh vi, các lĩnh vực chưa quen thuộc, hay các quyết định kiến trúc. Model lớn hơn hữu ích cho các tình huống mà model nhỏ hơn “tự tin làm sai” dù bạn có cung cấp bao nhiêu ngữ cảnh đi nữa.
Model lớn hơn cũng giỏi xử lý sự mơ hồ hơn, trong khi các chỉ dẫn cụ thể, rõ ràng về việc thực thi lại là công thức thành công tốt hơn cho các model nhỏ hơn.
Chọn model nhỏ hơn khi công việc là thường quy. Ví dụ: những chỉnh sửa bạn có thể mô tả chính xác, các thay đổi mang tính máy móc, hoặc các câu hỏi về code đã có sẵn trong ngữ cảnh. Không có lý do gì để trả tiền cho năng lực mà tác vụ không cần đến.
Nếu Claude đã có đủ ngữ cảnh liên quan, rõ ràng đã cố gắng, mà vẫn làm sai, đó là tín hiệu để chọn model lớn hơn. Nếu bạn đang dùng model lớn và công việc đã ổn định ở mức thường quy trong một khoảng thời gian, việc hạ xuống model nhỏ hơn sẽ tăng tốc độ và thường giảm chi phí mà không ảnh hưởng đến chất lượng đầu ra.
Effort: Claude chưa cố gắng đủ
Phần tiêu đề “Effort: Claude chưa cố gắng đủ”Chọn effort level cao hơn nếu Claude làm sai vì bỏ qua một file, không chạy test, hoặc không kiểm tra lại kết quả. Điều này đặc biệt liên quan nếu bạn đã chọn một effort level thấp hơn mức mặc định của model.
Effort, model, và mức tiêu thụ token
Phần tiêu đề “Effort, model, và mức tiêu thụ token”Vậy việc chọn model, effort, và mức tiêu thụ token tương tác với nhau như thế nào? Điều đó tuỳ vào tác vụ.
Với công việc thường quy ở cùng một mức effort, cả hai model nhìn chung đều làm đúng. Model lớn hơn tiêu tốn nhiều token hơn với các bước xác minh thêm, ở mức giá mỗi token cao hơn. Đó là lý do việc hạ xuống model nhỏ hơn cho các đoạn công việc thường quy tiết kiệm được tiền thật mà không đánh đổi chất lượng.
Với công việc khó hơn, nhiều bước hơn, phương trình lại khác. Model nhỏ hơn phải cố gắng “vắt kiệt” giới hạn năng lực của nó, tiêu tốn nhiều vòng lặp, trong khi model lớn hơn đạt được cùng mức chất lượng trong ít bước hơn.
Bạn trả nhiều tiền hơn cho mỗi token với model lớn hơn, nhưng với những tác vụ thực sự vượt quá khả năng của model nhỏ, tổng chi phí cho cả tác vụ đôi khi lại thấp hơn. Quan trọng hơn nữa, model lớn hơn có thể hoàn thành những tác vụ mà model nhỏ hơn không thể làm được, ngay cả ở mức effort cao nhất.
Điều này thể hiện rõ nhất với Fable. Với công việc dài, nhiều bước, nó bứt phá xa nhất. Trong các thử nghiệm của Anthropic, nó hoàn thành được những công việc mà Opus và Sonnet không thể chạm tới ở bất kỳ mức effort nào. Nó cũng tốn chi phí trên mỗi token cao nhất, đó là lý do khác để dành nó cho những công việc thực sự cần đến nó.
Điểm mấu chốt trong các biểu đồ trên là effort level chọn Claude sẵn sàng đi xa đến đâu dọc theo đường cong, nhưng điều đó không có nghĩa Claude sẽ cần đi xa đến mức đó để hoàn thành tác vụ.
Một điểm tinh tế khác: effort định hình mức tiêu thụ token nhưng không giới hạn nó. Giới hạn cứng duy nhất trong hệ thống là max_tokens, thứ cắt ngang một phản hồi giữa chừng khi chạm tới giới hạn. Đây là một công cụ khá “thô”, chủ yếu liên quan tới các nhà phát triển dùng API. Các công cụ kiểm soát “mềm” hơn, như task budget hoặc yêu cầu Claude giữ câu trả lời ngắn gọn ngay trong prompt, là những công cụ hữu ích hơn. Chúng đóng vai trò như hướng dẫn mà model được huấn luyện để tuân theo - nó sẽ tìm cách kết thúc tác vụ khi gần chạm giới hạn - thay vì một bức tường nó đâm sầm vào.
Bắt đầu với mặc định, rồi mới chạm tới các núm chỉnh
Phần tiêu đề “Bắt đầu với mặc định, rồi mới chạm tới các núm chỉnh”Phần lớn thời gian, bạn không cần phải nghĩ đến bất kỳ thiết lập nào trong hai thứ này. Khi kết quả không như ý, hãy tự hỏi: “Claude không biết đủ, hay không cố gắng đủ?” và điều chỉnh tương ứng.
Bài viết được viết bởi Lydia Hallie, thành viên đội kỹ thuật của nhóm Claude Code.
lượt xem
