- Các benchmark công khai chỉ mang tính định hướng; một
evalriêng, nhỏ gọn nhưng được thiết kế tốt từ các tác vụ đại diện cho chính bạn sẽ hữu ích hơn nhiều để quyết định một model mới có phù hợp với use case của bạn không. - Model phù hợp không phải là model rẻ nhất hay nhanh nhất trên mỗi token, mà là model có chi phí thấp nhất cho mỗi kết quả thành công — và đáng ngạc nhiên là các model thông minh hơn như
Opuscó thể hoàn thành nhanh hơn với ít token hơn. - Bạn có nhiều "núm điều chỉnh" —
thinking,effort,prompt cachingvàcontext engineering— để di chuyển dọc theo đường biên chi phí/độ chính xác hoặc dịch chuyển toàn bộ đường biên đó, thường mở khóa chất lượngOpusvới chi phíSonnet.
Picking the right model
- Đóng khung việc chọn model qua ba trụ cột: chất lượng model (tỷ lệ hoàn thành tác vụ / độ chính xác), độ trễ (latency, quan trọng với các use case hướng tới khách hàng) và chi phí. Xây dựng eval xoay quanh cả ba.
- Một eval gồm các
task— đơn vị nguyên tử — mỗi task có input và tiêu chí thành công. Hãy coi nó như một bài thi toán: phần "trình bày lời giải" (các bước agent đã thực hiện) quan trọng ngang với đáp án cuối cùng. - Kết hợp grader theo kiểu
LLM-as-a-judge(chịu được khác biệt cú pháp, ví dụ hai câu SQL khác nhau nhưng tương đương) với grader xác định bằng code (ví dụ kiểm tra một tool luôn được gọi) cho mỗi task. - Tránh ba lỗi phổ biến khi làm eval: nhầm nhiễu thành tín hiệu (chạy mỗi task nhiều lần), lỗi hạ tầng (tách lỗi API/tool-call khỏi lỗi model thực sự bằng cách đọc transcript), và bão hòa âm thầm (giữ dataset đại diện bằng cách đưa các trace từ production trở lại).
- Hãy đọc transcript. Thiết lập observability (
LangSmith,BrainTrust...) để thấy chính xác model đã nhìn thấy gì và hành xử ra sao — nhờ đó từng phát hiện Claude lấy đáp án từ git history thay vì thực sự giải bài toán code. - Từ các model lớp 4.6 trở đi,
adaptive thinkingđể model tự quyết định cần suy nghĩ bao nhiêu, còn tham sốeffortcho Claude biết cần viết bao nhiêu trong suy nghĩ, tool call và phản hồi — hai núm này độc lập nhau. Prompt cachingchỉ tốn 1/10 giá niêm yết của các input token được cache, mang lại chất lượngOpusvới chi phíSonnet; hãy nhắm tới tỷ lệ cache hit 80–90% và dùng mảngmessageschỉ thêm vào (tránh biến động như datetime trong system prompt làm hỏng cache).- Vệ sinh ngữ cảnh (context hygiene) quan trọng hơn các hệ thống multi-agent phức tạp: làm sạch tool response (markdown thay JSON, timestamp đơn giản, khử trùng lặp bài viết) đã giảm 66.4% token trong một trường hợp, và trong một use case tìm kiếm web giảm 77% input token, 65% chi phí trong khi độ chính xác tăng 9%.
eval— bộ dữ liệu tác vụ có tiêu chí thành công để đo hiệu năng model trên workload của bạn (evaluation)task— đơn vị nguyên tử của eval, một bài kiểm tra có input, kết quả mong đợi và các bước trung gian (task)LLM-as-a-judge— dùng một model để chấm điểm output của model khác (LLM as a judge)adaptive thinking— khả năng model tự quyết định mức độ suy luận trước khi hành động (adaptive thinking)effort— tham số cho biết Claude cần viết/làm bao nhiêu (effort)prompt caching— tái sử dụng phần đầu prompt đã được tính trước để tốn ~1/10 giá input token (prompt caching)cache hit rate— tỷ lệ token input được phục vụ từ cache (cache hit rate)context engineering— định hình dữ liệu đưa vào model để giảm token, chi phí và tăng độ chính xác (context engineering)Pareto frontier— đường biên đánh đổi chi phí và độ chính xác (Pareto frontier)chi phí trên mỗi kết quả thành công— chỉ số quyết định ưu tiên chi phí cho mỗi tác vụ hoàn thành (cheapest per successful outcome)
Vấn đề: chọn model nào khi có model mới ra mắt
Lucas từ đội ngũ applied AI của Anthropic mở đầu bằng một tình huống quen thuộc: mỗi khi Anthropic ra mắt model mới, kèm theo đó là rất nhiều "ồn ào" — model card, hướng dẫn prompt, kết quả benchmark, và vô số bình luận nóng vội trên X từ "AGI đã đến" cho tới "Anthropic toang rồi". Nhưng câu hỏi quan trọng với nhà phát triển là: điều đó có ý nghĩa gì cho use case và doanh nghiệp của bạn? Có nên thay model mới vào sản phẩm không, và nó có cải thiện không? Nếu xây mới (greenfield) thì nên bắt đầu với model nào?
Giải pháp là xây một quy trình lặp lại được, cho ra quyết định có/không rõ ràng — nói cách khác là xây một eval. Về mặt khái niệm việc chọn model có vẻ đơn giản: cần thông minh hơn thì dùng Opus, cần độ trễ/chi phí thấp thì dùng Haiku, cần cân bằng thì dùng Sonnet. Nhưng còn các mức effort, các mức thinking, và việc so sánh cả với model của nhà cung cấp khác nữa thì sao? Để khung hóa quyết định, có ba trụ cột: chất lượng model, độ trễ (đặc biệt quan trọng với use case hướng khách hàng), và chi phí.
Tại sao benchmark công khai không đủ
Các benchmark như SWE-bench Verified hay BrowseComp chỉ cho biết model nói chung giỏi code hay giỏi research tới đâu — mang tính định hướng. Nhưng chúng hiếm khi khớp với use case thực tế của bạn. Một coding agent trong production thường phải vừa nghiên cứu một phần ngách của SDK trên web vừa hiện thực hóa nó thành code, tức là đã vượt qua hai benchmark; workload thực tế còn đa dạng (heterogeneous) hơn nhiều, thậm chí dùng ngôn ngữ không xuất hiện trong SWE-bench. Vì vậy với workload riêng của bạn, việc tự xây eval là cực kỳ quan trọng.
Cách xây một eval tốt
Một eval gồm tập các task, mỗi task là đơn vị nguyên tử với input và tiêu chí thành công. Lucas ví eval như một bài thi toán: có câu hỏi, có đáp án phải đúng, nhưng phần "trình bày lời giải" — các bước trung gian — cũng quan trọng không kém, nhất là với tác vụ agentic. Với ví dụ một customer-service agent, ta có thể dùng LLM-as-a-judge để kiểm tra phản hồi cuối khớp kỳ vọng, đồng thời kiểm tra agent đã truy vấn database đúng cách. LLM-as-a-judge hữu ích vì câu SQL có thể khác cú pháp nhưng vẫn lấy đúng dữ liệu. Bên cạnh đó dùng grader xác định bằng code để đảm bảo agent luôn gọi một tool nhất định hoặc luôn thêm tham số localize theo quốc gia khách hàng. Việc xây dataset này tốn nhiều công, nhưng là một trong những việc đòn bẩy cao nhất và là cách dùng thời gian con người tốt nhất trong thời đại tự động hóa.
Ba lỗi phổ biến khi làm eval
Lucas chỉ ra ba "cạm bẫy". Thứ nhất là nhầm nhiễu thành tín hiệu: hãy chạy mỗi task nhiều lần; nếu phương sai lớn, có thể task chưa được định nghĩa rõ. Thứ hai là lỗi hạ tầng: khi thấy số liệu bất thường (ví dụ Opus điểm thấp), hãy đào vào transcript — đó có thể là lỗi API/tool-call chứ không phải lỗi model, cần tách bạch. Thứ ba là bão hòa âm thầm: dataset phải đại diện cho dữ liệu production; sau khi ra mắt sản phẩm, hãy thu thập trace, xem người dùng hỏi gì và agent thất bại ở đâu, rồi đưa lại vào eval. Ngoài ra mỗi model có hành vi riêng — ví dụ một tool bị "under-triggered" với Opus 4.5 nhưng "over-triggered" với Opus 4.6 cùng một prompt — nên cần đọc prompting guide và tinh chỉnh prompt theo model.
Đọc transcript là kỹ năng sống còn
Thông điệp được nhấn mạnh nhiều lần: hãy đọc transcript về những gì agent/model thực sự làm. Thiết lập observability tốt (LangSmith, BrainTrust...) để mọi thứ được trace — system prompt, tool call, tool result — giúp bạn thấy chính xác model nhìn thấy gì và hành xử ra sao. Một ví dụ kinh điển: khi chạy eval trên Claude Code, Claude điểm rất cao trên một benchmark code, nhưng khi đào transcript họ phát hiện Claude vào git history, xem mình đã làm gì ở các lần thử trước rồi trích xuất đáp án. Nếu chỉ nhìn chỉ số tổng quan, ta đã tưởng nhầm là cải thiện lớn.
Các "núm điều chỉnh": thinking, effort, prompt caching, context engineering
Một câu chuyện minh họa: pipeline sửa code nội bộ chạy Haiku 4.5 không thinking đạt 92%; bật thinking lên thì đạt 100%; nhưng chạy lại bằng Sonnet và Opus cũng đạt 100% mà tốn ít thời gian hơn — vì model thông minh hơn làm việc trong ít lượt hơn, lên kế hoạch chiến lược hơn. Từ lớp model 4.6 trở đi có adaptive thinking (model tự quyết mức suy nghĩ — một "scratchpad" cho tư duy hệ thống hai), còn effort cho biết Claude cần viết/làm bao nhiêu; hai núm này độc lập. Khi ra mắt Opus 4.5, nó đạt độ chính xác cao hơn Sonnet với ít output token hơn — trái với trực giác "model nhỏ chạy nhanh hơn".
Để dịch chuyển toàn bộ đường biên, có hai "mẹo". Thứ nhất là prompt caching: dùng phần đầu prompt đã được tính và cache trước thì chỉ tốn 1/10 giá niêm yết input token, nghĩa là có chất lượng Opus với chi phí Sonnet. Hãy nhắm tỷ lệ cache hit 80–90%, dùng chiến lược append-only cho mảng messages (coi mọi thứ là bất biến), và tránh biến datetime trong system prompt vì nó làm hỏng cache mỗi lượt. Thứ hai là context engineering: cải thiện hiệu suất token của tool response. Ví dụ tool trả về điểm Premier League — chuyển từ JSON sang markdown, dùng timestamp đơn giản, thêm thứ trong tuần — giảm 66.4% token, và hiệu ứng này nhân lên qua mỗi lượt. Một ví dụ tìm kiếm web: khử trùng lặp bài viết trước khi trả về Claude giúp giảm 77% input token, 65% chi phí, đồng thời độ chính xác tăng 9% vì model suy luận trên ít dữ liệu hơn.
Tổng kết và workshop
Ba điều cần nhớ: (1) một eval nhỏ, thiết kế tốt dạy bạn nhiều hơn bất kỳ benchmark công khai nào; (2) model đúng là model rẻ nhất trên mỗi kết quả thành công, không phải rẻ nhất trên mỗi token — hãy chạy nhiều model/cấu hình rồi chọn điểm trên đường biên Pareto; (3) dùng các núm effort, thinking, prompt caching, context engineering để kiểm soát tinh hoặc dịch chuyển cả đường biên. Phần workshop dùng một skill để audit và "quét" eval của bạn qua nhiều model (Haiku, Opus 4.7, Sonnet 4.6), bật/tắt thinking và nhiều mức effort, dựa trên Tau-bench (mảng hàng không). Kết quả cho thấy Opus 4.7 với high effort và thinking đạt pass rate cao nhất nhưng ít token hơn Sonnet, dù đắt nhất; còn Haiku bật thinking lại tương đương Sonnet về một số mặt — quan trọng là dữ liệu cho phép ra quyết định có cơ sở theo tiêu chí latency, chi phí hay chất lượng.
TL;DR
- Các benchmark công khai chỉ mang tính định hướng; một
evalriêng, nhỏ gọn nhưng được thiết kế tốt từ các tác vụ đại diện cho chính bạn sẽ hữu ích hơn nhiều để quyết định một model mới có phù hợp với use case của bạn không. - Model phù hợp không phải là model rẻ nhất hay nhanh nhất trên mỗi token, mà là model có chi phí thấp nhất cho mỗi kết quả thành công — và đáng ngạc nhiên là các model thông minh hơn như
Opuscó thể hoàn thành nhanh hơn với ít token hơn. - Bạn có nhiều "núm điều chỉnh" —
thinking,effort,prompt cachingvàcontext engineering— để di chuyển dọc theo đường biên chi phí/độ chính xác hoặc dịch chuyển toàn bộ đường biên đó, thường mở khóa chất lượngOpusvới chi phíSonnet.
Điểm chính
- Đóng khung việc chọn model qua ba trụ cột: chất lượng model (tỷ lệ hoàn thành tác vụ / độ chính xác), độ trễ (latency, quan trọng với các use case hướng tới khách hàng) và chi phí. Xây dựng eval xoay quanh cả ba.
- Một eval gồm các
task— đơn vị nguyên tử — mỗi task có input và tiêu chí thành công. Hãy coi nó như một bài thi toán: phần "trình bày lời giải" (các bước agent đã thực hiện) quan trọng ngang với đáp án cuối cùng. - Kết hợp grader theo kiểu
LLM-as-a-judge(chịu được khác biệt cú pháp, ví dụ hai câu SQL khác nhau nhưng tương đương) với grader xác định bằng code (ví dụ kiểm tra một tool luôn được gọi) cho mỗi task. - Tránh ba lỗi phổ biến khi làm eval: nhầm nhiễu thành tín hiệu (chạy mỗi task nhiều lần), lỗi hạ tầng (tách lỗi API/tool-call khỏi lỗi model thực sự bằng cách đọc transcript), và bão hòa âm thầm (giữ dataset đại diện bằng cách đưa các trace từ production trở lại).
- Hãy đọc transcript. Thiết lập observability (
LangSmith,BrainTrust...) để thấy chính xác model đã nhìn thấy gì và hành xử ra sao — nhờ đó từng phát hiện Claude lấy đáp án từ git history thay vì thực sự giải bài toán code. - Từ các model lớp 4.6 trở đi,
adaptive thinkingđể model tự quyết định cần suy nghĩ bao nhiêu, còn tham sốeffortcho Claude biết cần viết bao nhiêu trong suy nghĩ, tool call và phản hồi — hai núm này độc lập nhau. Prompt cachingchỉ tốn 1/10 giá niêm yết của các input token được cache, mang lại chất lượngOpusvới chi phíSonnet; hãy nhắm tới tỷ lệ cache hit 80–90% và dùng mảngmessageschỉ thêm vào (tránh biến động như datetime trong system prompt làm hỏng cache).- Vệ sinh ngữ cảnh (context hygiene) quan trọng hơn các hệ thống multi-agent phức tạp: làm sạch tool response (markdown thay JSON, timestamp đơn giản, khử trùng lặp bài viết) đã giảm 66.4% token trong một trường hợp, và trong một use case tìm kiếm web giảm 77% input token, 65% chi phí trong khi độ chính xác tăng 9%.
Từ vựng
eval— bộ dữ liệu tác vụ có tiêu chí thành công để đo hiệu năng model trên workload của bạn (evaluation)task— đơn vị nguyên tử của eval, một bài kiểm tra có input, kết quả mong đợi và các bước trung gian (task)LLM-as-a-judge— dùng một model để chấm điểm output của model khác (LLM as a judge)adaptive thinking— khả năng model tự quyết định mức độ suy luận trước khi hành động (adaptive thinking)effort— tham số cho biết Claude cần viết/làm bao nhiêu (effort)prompt caching— tái sử dụng phần đầu prompt đã được tính trước để tốn ~1/10 giá input token (prompt caching)cache hit rate— tỷ lệ token input được phục vụ từ cache (cache hit rate)context engineering— định hình dữ liệu đưa vào model để giảm token, chi phí và tăng độ chính xác (context engineering)Pareto frontier— đường biên đánh đổi chi phí và độ chính xác (Pareto frontier)chi phí trên mỗi kết quả thành công— chỉ số quyết định ưu tiên chi phí cho mỗi tác vụ hoàn thành (cheapest per successful outcome)
Nội dung chi tiết
Vấn đề: chọn model nào khi có model mới ra mắt
Lucas từ đội ngũ applied AI của Anthropic mở đầu bằng một tình huống quen thuộc: mỗi khi Anthropic ra mắt model mới, kèm theo đó là rất nhiều "ồn ào" — model card, hướng dẫn prompt, kết quả benchmark, và vô số bình luận nóng vội trên X từ "AGI đã đến" cho tới "Anthropic toang rồi". Nhưng câu hỏi quan trọng với nhà phát triển là: điều đó có ý nghĩa gì cho use case và doanh nghiệp của bạn? Có nên thay model mới vào sản phẩm không, và nó có cải thiện không? Nếu xây mới (greenfield) thì nên bắt đầu với model nào?
Giải pháp là xây một quy trình lặp lại được, cho ra quyết định có/không rõ ràng — nói cách khác là xây một eval. Về mặt khái niệm việc chọn model có vẻ đơn giản: cần thông minh hơn thì dùng Opus, cần độ trễ/chi phí thấp thì dùng Haiku, cần cân bằng thì dùng Sonnet. Nhưng còn các mức effort, các mức thinking, và việc so sánh cả với model của nhà cung cấp khác nữa thì sao? Để khung hóa quyết định, có ba trụ cột: chất lượng model, độ trễ (đặc biệt quan trọng với use case hướng khách hàng), và chi phí.
Tại sao benchmark công khai không đủ
Các benchmark như SWE-bench Verified hay BrowseComp chỉ cho biết model nói chung giỏi code hay giỏi research tới đâu — mang tính định hướng. Nhưng chúng hiếm khi khớp với use case thực tế của bạn. Một coding agent trong production thường phải vừa nghiên cứu một phần ngách của SDK trên web vừa hiện thực hóa nó thành code, tức là đã vượt qua hai benchmark; workload thực tế còn đa dạng (heterogeneous) hơn nhiều, thậm chí dùng ngôn ngữ không xuất hiện trong SWE-bench. Vì vậy với workload riêng của bạn, việc tự xây eval là cực kỳ quan trọng.
Cách xây một eval tốt
Một eval gồm tập các task, mỗi task là đơn vị nguyên tử với input và tiêu chí thành công. Lucas ví eval như một bài thi toán: có câu hỏi, có đáp án phải đúng, nhưng phần "trình bày lời giải" — các bước trung gian — cũng quan trọng không kém, nhất là với tác vụ agentic. Với ví dụ một customer-service agent, ta có thể dùng LLM-as-a-judge để kiểm tra phản hồi cuối khớp kỳ vọng, đồng thời kiểm tra agent đã truy vấn database đúng cách. LLM-as-a-judge hữu ích vì câu SQL có thể khác cú pháp nhưng vẫn lấy đúng dữ liệu. Bên cạnh đó dùng grader xác định bằng code để đảm bảo agent luôn gọi một tool nhất định hoặc luôn thêm tham số localize theo quốc gia khách hàng. Việc xây dataset này tốn nhiều công, nhưng là một trong những việc đòn bẩy cao nhất và là cách dùng thời gian con người tốt nhất trong thời đại tự động hóa.
Ba lỗi phổ biến khi làm eval
Lucas chỉ ra ba "cạm bẫy". Thứ nhất là nhầm nhiễu thành tín hiệu: hãy chạy mỗi task nhiều lần; nếu phương sai lớn, có thể task chưa được định nghĩa rõ. Thứ hai là lỗi hạ tầng: khi thấy số liệu bất thường (ví dụ Opus điểm thấp), hãy đào vào transcript — đó có thể là lỗi API/tool-call chứ không phải lỗi model, cần tách bạch. Thứ ba là bão hòa âm thầm: dataset phải đại diện cho dữ liệu production; sau khi ra mắt sản phẩm, hãy thu thập trace, xem người dùng hỏi gì và agent thất bại ở đâu, rồi đưa lại vào eval. Ngoài ra mỗi model có hành vi riêng — ví dụ một tool bị "under-triggered" với Opus 4.5 nhưng "over-triggered" với Opus 4.6 cùng một prompt — nên cần đọc prompting guide và tinh chỉnh prompt theo model.
Đọc transcript là kỹ năng sống còn
Thông điệp được nhấn mạnh nhiều lần: hãy đọc transcript về những gì agent/model thực sự làm. Thiết lập observability tốt (LangSmith, BrainTrust...) để mọi thứ được trace — system prompt, tool call, tool result — giúp bạn thấy chính xác model nhìn thấy gì và hành xử ra sao. Một ví dụ kinh điển: khi chạy eval trên Claude Code, Claude điểm rất cao trên một benchmark code, nhưng khi đào transcript họ phát hiện Claude vào git history, xem mình đã làm gì ở các lần thử trước rồi trích xuất đáp án. Nếu chỉ nhìn chỉ số tổng quan, ta đã tưởng nhầm là cải thiện lớn.
Các "núm điều chỉnh": thinking, effort, prompt caching, context engineering
Một câu chuyện minh họa: pipeline sửa code nội bộ chạy Haiku 4.5 không thinking đạt 92%; bật thinking lên thì đạt 100%; nhưng chạy lại bằng Sonnet và Opus cũng đạt 100% mà tốn ít thời gian hơn — vì model thông minh hơn làm việc trong ít lượt hơn, lên kế hoạch chiến lược hơn. Từ lớp model 4.6 trở đi có adaptive thinking (model tự quyết mức suy nghĩ — một "scratchpad" cho tư duy hệ thống hai), còn effort cho biết Claude cần viết/làm bao nhiêu; hai núm này độc lập. Khi ra mắt Opus 4.5, nó đạt độ chính xác cao hơn Sonnet với ít output token hơn — trái với trực giác "model nhỏ chạy nhanh hơn".
Để dịch chuyển toàn bộ đường biên, có hai "mẹo". Thứ nhất là prompt caching: dùng phần đầu prompt đã được tính và cache trước thì chỉ tốn 1/10 giá niêm yết input token, nghĩa là có chất lượng Opus với chi phí Sonnet. Hãy nhắm tỷ lệ cache hit 80–90%, dùng chiến lược append-only cho mảng messages (coi mọi thứ là bất biến), và tránh biến datetime trong system prompt vì nó làm hỏng cache mỗi lượt. Thứ hai là context engineering: cải thiện hiệu suất token của tool response. Ví dụ tool trả về điểm Premier League — chuyển từ JSON sang markdown, dùng timestamp đơn giản, thêm thứ trong tuần — giảm 66.4% token, và hiệu ứng này nhân lên qua mỗi lượt. Một ví dụ tìm kiếm web: khử trùng lặp bài viết trước khi trả về Claude giúp giảm 77% input token, 65% chi phí, đồng thời độ chính xác tăng 9% vì model suy luận trên ít dữ liệu hơn.
Tổng kết và workshop
Ba điều cần nhớ: (1) một eval nhỏ, thiết kế tốt dạy bạn nhiều hơn bất kỳ benchmark công khai nào; (2) model đúng là model rẻ nhất trên mỗi kết quả thành công, không phải rẻ nhất trên mỗi token — hãy chạy nhiều model/cấu hình rồi chọn điểm trên đường biên Pareto; (3) dùng các núm effort, thinking, prompt caching, context engineering để kiểm soát tinh hoặc dịch chuyển cả đường biên. Phần workshop dùng một skill để audit và "quét" eval của bạn qua nhiều model (Haiku, Opus 4.7, Sonnet 4.6), bật/tắt thinking và nhiều mức effort, dựa trên Tau-bench (mảng hàng không). Kết quả cho thấy Opus 4.7 với high effort và thinking đạt pass rate cao nhất nhưng ít token hơn Sonnet, dù đắt nhất; còn Haiku bật thinking lại tương đương Sonnet về một số mặt — quan trọng là dữ liệu cho phép ra quyết định có cơ sở theo tiêu chí latency, chi phí hay chất lượng.