Claude Code cung cấp cho bạn hai cài đặt mà cả hai đều có vẻ như "làm cho câu trả lời tốt hơn": model và mức độ nỗ lực (effort level). Nhưng thực sự thì những cài đặt này tác động thế nào đến đầu ra? Và làm thế nào để bạn biết khi nào nên dùng một model khác hay chỉ cần thay đổi mức độ nỗ lực?
Thật dễ để cho rằng việc chọn một model lớn hơn như Fable sẽ cho bạn đầu ra thông minh hơn Sonnet, và mức độ nỗ lực cao hơn chỉ đơn giản 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 chúng tôi có năng lực hơn, theo các tiêu chuẩn đánh giá của ngành.
Nhưng nỗ lực có ý nghĩa nhiều hơn là "thời gian suy nghĩ". Nỗ lực kiểm soát mức độ làm việc tổng thể mà Claude dành cho yêu cầu của bạn. Điều đó bao gồm thời gian nó suy nghĩ, nhưng cũng bao gồm:
- nó đọc bao nhiêu tệp;
- nó xác minh bao nhiêu; và
- nó tiến xa đến đâu trong một tác vụ nhiều bước trước khi kiểm tra lại với bạn.
Ở mức nỗ lực cao hơn, Claude thực hiện nhiều hành động hơn (đọc tệp, chạy thử nghiệm, kiểm tra lại) trước khi quay lại với bạn. Ở mức nỗ lực thấp hơn, nó sẽ thích hỏi bạn để biết thêm ngữ cảnh hơn là dùng token để tự mình tìm ra điều gì đó.
Cách thức hoạt động của việc chọn model
Để hiểu cài đặt model thực sự kiểm soát điều gì, sẽ rất hữu ích nếu bắt đầu từ điểm khởi đầu, ngay từ lúc bạn nhấn enter.
Claude Code tập hợp tin nhắn của bạn cùng với system prompt, định nghĩa công cụ, tệp CLAUDE.md của bạn, lịch sử hội thoại và bất kỳ tệp nào trong ngữ cảnh. Tất cả những thứ này được gửi như một yêu cầu duy nhất đến API.
Mọi thứ Claude Code có đều được đóng gói vào một yêu cầu API duy nhất. Trên máy chủ, văn bản được token hóa trước khi đến được model.
Tuy nhiên, model không bao giờ nhìn thấy bất kỳ thứ nào trong số đó dưới dạng văn bản thuần túy. Điều đầu tiên xảy ra trên máy chủ là token hóa: văn bản được chia thành các phần nhỏ, và mỗi phần được ánh xạ tới một số nguyên từ một bộ từ vựng cố định mà model đã được huấn luyện. \const\ có thể ánh xạ tới 1978, \await\ có thể ánh xạ tới 4293. Từ đây, prompt của bạn là một mảng các số nguyên.
Bộ token hóa chia văn bản của bạn thành các phần nhỏ và ánh xạ mỗi phần tới một số nguyên trong một bộ từ vựng cố định. Mỗi khối ở hàng trên cùng trở thành ID token của nó (hàng dưới cùng); các ID được hiển thị chỉ mang tính minh họa.
Nhiệm vụ của model là lấy mảng đó và dự đoán token nào sẽ xuất hiện tiếp theo. Nó thực hiện điều này bằng cách tính toán xác suất cho mọi token trong bộ từ vựng của nó 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ẽ đặt xác suất cao cho "fetch" (rất có khả năng) và gần như bằng không cho "banana" (rất khó xảy ra).
Dự đoán của model là một xác suất cho mọi token trong bộ từ vựng của nó. Khoảng cách giữa dự đoán hàng đầu và một dự đoán không liên quan là rất lớn.
Thứ biến các token đầu vào của bạn thành các xác suất đó là các trọng số (còn gọi là tham số): 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) và đọc các xác suất ở cuối. Các trọng số là nơi chứa mọi thứ mà model "biết".
Trọng số của mỗi model được thiết lập trong quá trình huấn luyện và đến khi bạn gửi yêu cầu, chúng ở chế độ chỉ đọc. Không có gì trong prompt, tệp 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, đó là tất cả những gì nó có nghĩa: sử dụng model sau khi quá trình huấn luyện kết thúc, với các trọng số cố định.
Prompt của bạn đi vào, xác suất đi ra. Các trọng số ở giữa không thay đổi.
Mọi thứ Claude biết về TypeScript, các framework phổ biến, hoặc bất kỳ kiến thức lập trình chung nào khác đều được mã hóa vào các trọng số đó tại thời điểm huấn luyện.
Prompt và ngữ cảnh của bạn vẫn có thể định hướng dự đoán. Đặt mã thực tế của bạn trước Claude là một cách định hướng, và nó hoạt động rất tốt. Tuy nhiên, điều này không thêm bất cứ thứ gì vào bản thân các trọng số.
Nếu một thư viện không tồn tại khi model được huấn luyện, thì nó không có trong các trọng số. Bạn có thể đặt tài liệu vào ngữ cảnh và Claude sẽ sử dụng chúng, nhưng đó là định hướng, không phải dạy dỗ. Phản hồi của Claude chỉ bị ảnh hưởng cho yêu cầu cụ thể đó, nhưng model cơ bản không ghi nhớ được gì.
Khi Claude tự tin gọi một API không tồn tại (ảo giác), đó là các trọng số tạo ra một chuỗi token trông có vẻ hợp lý từ các mẫu huấn luyện, chứ không phải là một tra cứu thất bại.
Vậy việc thay đổi model thực sự làm gì? Nó hoán đổi bộ trọng số cố định nào xử lý yêu cầu của bạn.
Model không tạo ra toàn bộ câu trả lời cùng một lúc. Nó dự đoán một token, thêm nó vào chuỗi, và 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ần truyền riêng biệt qua các trọng số. Vòng lặp này là nơi tạo ra phần lớn thời gian chờ đợi (và chi phí đầu ra) của bạn.
Chuỗi tăng lên chính xác một token mỗi bước. Model đọc lại toàn bộ mảng mỗi lần để dự đoán điều gì sẽ xảy ra tiếp theo.
Cài đặt model quyết định trọng số nào xử lý yêu cầu của bạn, và nó cũng quyết định mỗi token đầu ra có giá 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ể thay đổi rất nhiều cho cùng một prompt, tùy thuộc vào mức độ làm việc mà Claude quyết định thực hiện.
Đó chính xác là điều mà mức độ nỗ lực kiểm soát.
Cách thức hoạt động của mức độ nỗ lực
Trong khi Claude Code đang làm việc trên một tác vụ, các token mà nó tạo ra thuộc một vài loại:
- Suy nghĩ: lý luận mà bạn thấy đang truyền trực tiếp trước và giữa các hành động.
- Lệnh gọi công cụ: các khối có cấu trúc đặt tên cho một công cụ như Read hoặc Edit và các đối số của nó, sau đó Claude Code 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 phí theo cùng một tỷ lệ. Ví dụ, các token suy nghĩ được tạo ra giống 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 đó.
Vào thời điểm Claude chuyển sang viết mã, lý luận trước đó của nó là một phần của đầu vào, giống như một tệp nó đã đọc.
Tất cả đầu ra của Claude đều là token. Suy nghĩ, lệnh gọi công cụ và văn bản gửi cho bạn đều được tạo ra từ cùng một vòng lặp.
Vậy mức độ nỗ lực thay đổi điều này như thế nào? Mức độ nỗ lực được gửi đến model như một phần của yêu cầu, 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 độ nỗ lực, và hành vi đã học đó được tích hợp vào các trọng số cố định.
Khi yêu cầu của bạn đến, mức độ nỗ lực chỉ là một đầu vào nữa mà model phản hồ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 mức độ kỹ lưỡng và mức độ chắc chắn mà Claude cần có trước khi nó coi tác vụ đã hoàn thành. Điều đó được cân nhắc trong mọi lượt, và sự tự tin cao hơn cần nhiều token hơn để đạt được.
Cùng một prompt, hai mức độ nỗ lực. Đường dẫn nỗ lực cao tạo ra lượng token gấp khoảng 7 lần để đạt được câu trả lời có độ tin cậy cao hơn.
Ở mức nỗ lực cao hơn, Claude thường bắt đầu bằng cách tạo một kế hoạch, và mức độ nỗ lực ảnh hưởng đến độ sâu và phạm vi của kế hoạch đó. Nhưng kế hoạch không bị cố định. Khi Claude nhận được kết quả từ các hành động của mình, nó cập nhật bức tranh về mức độ tiến triển đã đạt được và mức độ chắc chắn về kết quả tích lũy.
Khi bước 1 của một kế hoạch gỡ lỗi ba giả thuyết tìm ra lỗi, thì "điều 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 điều này một cách rõ ràng (ví dụ: "lần kiểm tra đầu tiên đã tìm thấy nó, vì vậy các lần kiểm tra còn lại là không cần thiết") và bỏ qua. Bạn thấy điều này xảy ra trong Claude Code khi danh sách tác vụ được sửa đổi giữa chừng.
Mức nỗ lực cao hơn làm cho Claude có nhiều khả năng kiểm tra lại hơn, như xác minh câu trả lời nó tìm thấy, hoặc vẫn xem xét các giả thuyết mà nó có thể đã bỏ qua. Tuy nhiên, nó thường sẽ không làm tăng mức sử dụng một cách giả tạo cho một tác vụ đơn giản chỉ vì mức độ nỗ lực được tăng lên. "Suy nghĩ quá mức" là điều mà nhóm của chúng tôi đặc biệt theo dõi trong quá trình huấn luyện model vì nó làm giảm hiệu quả.
Chọn mức độ nỗ lực
Đối với hầu hết các tác vụ, hãy sử dụng mức nỗ lực mặc định của model. Mức mặc định là mức mà Claude điều chỉnh mức sử dụng token của nó theo những gì hầu hết mọi người muốn chi cho một tác vụ.
Hãy coi mức độ nỗ lực như một sự ghi đè thủ công về mức độ khó và thời gian Claude làm việc. Hãy sử dụng nó một cách có chủ đích khi bạn có sở thích mạnh mẽ về sự kỹ lưỡng hoặc tốc độ dựa trên lĩnh vực của bạn hoặc loại công việc bạn làm, và coi nó như một sở thích chung, không phải là quyết định cho từng tác vụ.
Một lưu ý thực tế sau khi ra mắt Opus 4.8: trong thử nghiệm của chúng tôi, cài đặt nỗ lực mặc định trên Opus 4.8 tạo ra kết quả tốt hơn với lượng token tương đương so với cài đặt nỗ lực mặc định trên Opus 4.7 cho cùng một tác vụ.
Thay đổi gì khi Claude làm sai
Khi Claude làm sai điều gì đó, bản năng đầu tiên của bạn không nên là thay đổi cài đặt. Nó nên là xem xét ngữ cảnh bạn đã cung cấp cho nó. Prompt của bạn có quá mơ hồ không? Claude có được kết nối với các công cụ phù hợp không? Nó có các kỹ năng phù hợp không?
Nếu bạn đang tăng mức độ nỗ lực cho một tác vụ không cần đến nó, giải pháp thường nằm ở phía trước: trong ngữ cảnh của bạn, tệp CLAUDE.md của bạn, hoặc cách tác vụ được xác định phạm vi.
Nhưng giả sử bạn đã cung cấp ngữ cảnh rõ ràng và Claude vẫn làm sai. Câu hỏi bạn cần tự hỏi là: nó có cố gắng đủ không, hay nó có biết đủ không?
Model: vấn đề quá khó
Chọn một model lớn hơn khi vấn đề thực sự khó, như lỗi tinh vi, các lĩnh vực không quen thuộc, các quyết định kiến trúc. Một model lớn hơn là thứ bạn muốn khi model nhỏ hơn tự tin sai bất kể bạn cung cấp cho nó bao nhiêu ngữ cảnh.
Các model lớn hơn cũng xử lý sự mơ hồ tốt hơn. Trên các model nhỏ hơn, các hướng dẫn cụ thể để định hướng thực thi là một công thức thành công tốt hơn.
Chọn một model nhỏ hơn khi công việc là thường xuyên: các chỉnh sửa bạn có thể mô tả chính xác, các thay đổi cơ học, các câu hỏi về mã đã có trong ngữ cảnh. Không có lý do gì để trả tiền cho khả năng mà tác vụ không cần.
Nếu Claude có tất cả ngữ cảnh liên quan, đã cố gắng rõ ràng, và vẫn làm sai; đó là tín hiệu để chọn một model lớn hơn. Và nếu bạn đang ở trên model lớn hơn và công việc đã là thường xuyên trong một thời gian, việc giảm xuống 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.
Mức độ nỗ lực: Claude đã không cố gắng đủ
Chọn mức độ nỗ lực cao hơn nếu Claude làm sai vì không cố gắng đủ: bỏ qua một tệp, không chạy thử nghiệm, hoặc không kiểm tra lại công việc của nó. Điều này có liên quan nhất nếu bạn đã chọn mức độ nỗ lực thấp hơn mức mặc định của model.
Chuyên gia, chuyên viên và người đa năng
Một cách tôi thích nghĩ về hai cài đặt này là Fable là một chuyên gia có thể xử lý các vấn đề mà hầu như không ai khác có thể, Opus là chuyên viên, và Sonnet là một người đa năng thực sự giỏi. Mức độ nỗ lực quyết định bất kỳ ai trong số họ dành bao nhiêu thời gian cho tác vụ của bạn.
Opus ở mức nỗ lực thấp giống như có năm phút với một chuyên viên có kinh nghiệm sâu sắc với các vấn đề giống như của bạn. Họ mang đến kiến thức không có ở bất cứ đâu trong cơ sở mã của bạn; các mẫu họ đã thấy trước đây, các cạm bẫy họ biết cần kiểm tra, loại kinh nghiệm bạn chỉ có được khi đã giải quyết rất nhiều vấn đề tương tự. Nhưng năm phút có nghĩa là đọc nhanh mã của bạn, chứ không phải xem xét cẩn thận từng tệp.
Sonnet ở mức nỗ lực cao là người đa năng với cả buổi chiều. Họ rất giỏi viết mã, và họ sẽ đọc mọi thứ, chạy mọi thứ, kiểm tra lại công việc của họ, và cuối cùng hiểu rõ mã cụ thể của bạn.
Fable là chuyên gia bạn gọi khi mọi người khác đều bế tắc. Ngay cả ở mức nỗ lực thấp, họ sẽ phát hiện ra điều mà không ai khác có thể. Sự công nhận đó cũng là thứ bạn phải trả nhiều nhất, vì vậy thật đáng để dành nó cho những tác vụ thực sự cần nó.
Không có cái nào trong số này là "tốt hơn" một cách phổ quát. Cài đặt model đại khái là mức độ năng lực; cài đặt mức độ nỗ lực đại khái là mức độ kỹ lưỡng. Hầu hết các tác vụ thực tế cần một chút của cả hai.
Mức độ nỗ lực, model và mức tiêu thụ token
Vậy việc chọn model, mức độ nỗ lực và mức tiêu thụ token tương tác với nhau như thế nào? Nó phụ thuộc vào tác vụ.
Đối với công việc thường xuyên ở cùng một mức độ nỗ lực, cả model lớn hơn và nhỏ hơn thường đều làm đúng. Model lớn hơn tiêu thụ nhiều token hơn với các bước xác minh bổ sung, với mức giá cao hơn cho mỗi token. Đó là lý do tại sao việc giảm xuống model nhỏ hơn cho các giai đoạn thường xuyên tiết kiệm tiền thực sự mà không làm giảm chất lượng.
Các đường cong chỉ mang tính minh họa, được hiển thị cho một tác vụ duy nhất đủ đơn giản để cả hai model có thể hoàn thành nhanh chóng. Chúng không đại diện cho dữ liệu điểm chuẩn thực tế.
Đối với công việc khó hơn, nhiều bước, phương trình sẽ đảo ngược. Model nhỏ hơn phải cố gắng đến giới hạn khả năng của nó, đốt cháy các lần lặp, trong khi model lớn hơn đạt đến cùng một mức chất lượng trong ít bước hơn.
Bạn đang trả nhiều hơn cho mỗi token cho model lớn hơn, nhưng đối với các tác vụ thực sự làm khó model nhỏ hơn, tổng chi phí cho mỗi tác vụ có thể thấp hơn. Và quan trọng hơn: model lớn hơn có thể hoàn thành các tác vụ mà model nhỏ hơn không thể, ngay cả ở cài đặt nỗ lực cao nhất.
Điều này rõ rệt nhất với Fable. Trong công việc dài, nhiều bước, nó vượt trội nhất. Trong thử nghiệm của chúng tôi, nó đã hoàn thành các công việc mà Opus và Sonnet không thể đạt được ở bất kỳ mức độ nỗ lực nào. Nó cũng có chi phí cao nhất cho mỗi token, đó là lý do khác để dành nó cho công việc thực sự cần nó.
Các đường cong chỉ mang tính minh họa, được hiển thị cho một tác vụ duy nhất đủ khó để làm căng cả hai model. Chúng không đại diện cho dữ liệu điểm chuẩn thực tế.
Điểm mấu chốt trong các biểu đồ trên: mức độ nỗ lực chọn mức độ Claude sẵn sàng di chuyển dọc theo đường cong. Điều đó không có nghĩa là Claude sẽ cần phải đi xa như vậy để hoàn thành tác vụ.
Cuối cùng, mức độ nỗ lực định hình mức tiêu thụ token, nhưng nó không giới hạn nó. Giới hạn cứng duy nhất trong hệ thống là max_tokens, nó cắt ngắn một phản hồi giữa dòng khi bị chạm, nhưng nó là một công cụ thô và chủ yếu liên quan đến các nhà phát triển API. Các kiểm soát mềm hơn như task budgets hoặc yêu cầu Claude giữ cho nó ngắn gọn trong prompt của bạn sẽ hữu ích hơn. Chúng là hướng dẫn mà model được huấn luyện để tuân theo (nó sẽ cố gắng kết thúc khi đến gần giới hạn) chứ không phải là một bức tường mà nó đâm vào.
Mức độ nỗ lực thay đổi mức độ làm việc của Claude. Model thay đổi những gì Claude biết.
Khi bạn không hài lòng với một kết quả, hãy kiểm tra ngữ cảnh trước khi chạm vào bất kỳ cài đặt nào: cung cấp cho Claude một prompt rõ ràng, các công cụ và kỹ năng phù hợp, và một cách để xác minh công việc của chính nó.
Nếu Claude vẫn làm sai, hãy tự hỏi: nó có biết đủ không, hay nó có cố gắng đủ không? Không biết đủ là vấn đề của model, không cố gắng đủ là vấn đề của mức độ nỗ lực.
Bài viết này được viết bởi @lydiahallie, thành viên kỹ thuật trong nhóm Claude Code.
