Model reasoning: khi nào đáng bắt khách hàng trả thêm tiền và chờ lâu hơn

Tài liệu API của OpenAI có một chi tiết rất dễ bị đọc lướt: reasoning token không hiện ra qua API nhưng vẫn chiếm chỗ trong context window. Phía Anthropic thì ghi rõ thinking token được tính tiền như output token. Nói cách khác, khách hàng trả tiền cho một phần công việc mà họ không bao giờ đọc được.

Đó là lý do câu hỏi “có nên bật reasoning không” hiếm khi là câu hỏi kỹ thuật thuần túy. Nó đụng tới ba thứ khách quan tâm nhất: hóa đơn, độ trễ và mức độ tin được vào câu trả lời. Ở site khách, người phải trả lời câu đó thường là bạn.

Bài này đi tới một kết luận cụ thể: reasoning là núm vặn cần đo riêng cho từng workload, không phải nút nâng cấp bật một lần cho tất cả. Và câu trả lời thuyết phục khách nhất không đến từ bảng xếp hạng benchmark, mà từ số liệu eval chạy trên dữ liệu của chính họ.

Lợi ích có thật, nhưng đi kèm điều kiện

Bài báo chain-of-thought công bố năm 2022 cho thấy việc sinh ra các bước suy luận trung gian cải thiện đáng kể khả năng giải bài toán phức tạp của mô hình ngôn ngữ lớn.

IBM giải thích cơ chế khá đơn giản: bài toán được chẻ thành những bước logic nhỏ hơn, và người dùng nhìn được đường model đi tới đáp án.

Bài báo gốc còn có một điều kiện ít người nhắc: khả năng này xuất hiện tự nhiên ở những mô hình đủ lớn. Vì thế, nếu khách đòi chạy model nhỏ on-premise vì lý do bảo mật, đừng mặc định rằng thêm bước suy luận sẽ cứu được chất lượng.

Điều kiện thứ hai đáng lo hơn. IBM cảnh báo model có thể sinh ra những chuỗi suy luận nghe hợp lý nhưng sai. Khi khách nhìn thấy một lập luận dài, mạch lạc, họ dễ tin câu trả lời hơn mức nó xứng đáng. Tính minh bạch mà CoT mang lại có thể biến thành sự tự tin giả nếu bạn không có bộ eval để đối chiếu.

Hóa đơn nằm ở phần không ai đọc

OpenAI mô tả reasoning model là thêm một loại token thứ ba bên cạnh input và output. IBM nói thẳng hơn: sinh và xử lý nhiều bước suy luận đòi hỏi thêm năng lực tính toán và thời gian, nên doanh nghiệp tốn kém hơn khi áp dụng.

Lấy Claude làm ví dụ, vì Anthropic ghi rõ thinking token tính như output token. Thử hình dung một request với các con số đặt ra cho dễ cộng: 500 token input và câu trả lời 200 token. Nếu model nghĩ thêm 3.000 token trước khi trả lời, phần output bị tính tiền là 3.200 token chứ không phải 200, dù người dùng chỉ thấy đúng 200 token.

Phần context cũng bị ăn mòn theo cách tương tự. Với một agent phải nhét hợp đồng dài, lịch sử hội thoại và kết quả tool vào cùng một context window, mỗi nghìn token suy nghĩ là một nghìn token tài liệu không còn chỗ chứa. Anthropic trả về trong response con số cho biết bao nhiêu output token bị tính tiền là suy luận nội bộ.

Việc đầu tiên nên làm ở dự án nào có reasoning là log field này ngay từ ngày đầu.

Núm vặn, không phải phao cứu sinh

Cả hai nhà cung cấp đều cho bạn một cái núm, nhưng gọi tên khác nhau. OpenAI có tham số reasoning effort, và tài liệu của họ khuyên coi nó là núm tinh chỉnh, không phải cách chính để lấy lại chất lượng. Effort thấp thì nhanh hơn và tốn ít token hơn, hợp với những use case nhạy cảm về độ trễ.

Anthropic thì tính bằng budget suy nghĩ đo theo token, và nói gần như cùng một điều nhưng thêm chi tiết về lợi ích giảm dần. Budget cao hơn cho phép suy luận kỹ hơn, nhưng mức lợi giảm dần tùy theo task, và cái giá là độ trễ tăng.

Lời khuyên cụ thể của Anthropic: task đơn giản thì bắt đầu gần mức tối thiểu 1.024 token rồi tăng dần, task phức tạp thì bắt đầu từ 16k trở lên.

Với FDE, câu “không phải cách chính để lấy lại chất lượng” là một chỉ dẫn vận hành. Khi khách phàn nàn câu trả lời kém, thứ tự kiểm tra hợp lý là context có đủ không, prompt có rõ không, eval có phản ánh đúng việc khách cần không. Chỉ sau đó mới tới chuyện vặn effort.

Để model tự quyết, hay giữ quyền quyết?

Các model Claude mới hơn thay budget cố định bằng adaptive thinking: model tự quyết có suy nghĩ hay không và suy nghĩ bao nhiêu cho từng request, và ở effort thấp có thể bỏ qua hẳn bước suy nghĩ với input dễ. Nghe như lời giải cho mọi bài toán chi phí, nhưng Anthropic vẫn giữ một ngoại lệ quan trọng.

Theo tài liệu của họ, chế độ thủ công vẫn hữu ích khi workload cần độ trễ dự đoán được hoặc cần kiểm soát chính xác chi phí suy nghĩ. Ở site khách, hai điều kiện đó xuất hiện thường xuyên hơn bạn nghĩ: một hệ thống có SLA phản hồi, hoặc một phòng tài chính muốn biết trước chi phí mỗi tháng.

Xếp các lựa chọn từ rẻ đến đắt, FDE có một thang năm bậc để đi lần lượt, trong đó bậc cuối là lựa chọn giữa adaptive thinking và budget thủ công. Ở bậc 3 và 4, “effort” là tham số của OpenAI, còn mức budget 1.024 hay 16k token là của Anthropic:

Bậc	Chi phí thêm	Độ trễ	Hợp khi
1. Prompt thường	Không	Thấp nhất	Task đơn giản, đã đạt eval
2. Zero-shot CoT (“Let’s think step by step”)	Thêm token output nhìn thấy được	Tăng nhẹ	Baseline rẻ trước khi đổi sang reasoning model
3. Effort thấp (OpenAI) / budget gần 1.024 (Claude)	Ít reasoning token	Tăng vừa	Use case nhạy độ trễ cần thêm chút suy luận
4. Effort cao (OpenAI) / budget từ 16k (Claude)	Nhiều reasoning token (Claude tính như output)	Cao	Task phức tạp, đã chứng minh có lợi trên eval
5a. Adaptive thinking (Claude)	Thay đổi theo từng request	Khó đoán trước	Input lẫn dễ và khó, không có SLA chặt
5b. Budget thủ công (Claude)	Có trần rõ ràng	Dự đoán được	Có SLA hoặc khách cần kiểm soát chi phí

Một buổi sáng ở site khách

Thử hình dung một công ty logistics có hai workload. Thứ nhất là chatbot trả lời khách hỏi đơn hàng đang ở đâu. Thứ hai là công cụ đối soát hóa đơn của nhà vận chuyển với hợp đồng có nhiều điều khoản phụ phí, chạy theo lô mỗi đêm.

Chatbot là task tra cứu, người dùng đang chờ trên màn hình. Bạn bắt đầu ở bậc đầu tiên của thang, và nếu chất lượng đạt thì dừng lại ở đó. Nếu cần thêm suy luận, effort thấp hoặc budget thủ công nhỏ giữ được độ trễ trong ngưỡng mà SLA cho phép.

Công cụ đối soát thì ngược lại. Đó là kiểu bài toán nhiều bước mà nghiên cứu CoT cho thấy suy luận trung gian giúp ích, và chạy ban đêm nên độ trễ ít quan trọng. Bạn có thể bắt đầu với budget lớn, nhưng vẫn nên chạy eval ở vài mức budget để tìm điểm mà chất lượng bắt đầu đi ngang.

Lợi ích giảm dần nghĩa là luôn có một ngưỡng mà sau đó khách chỉ đang trả thêm tiền.

Với cả hai workload, thứ bạn mang vào cuộc họp với khách là một bảng gồm ba cột: chất lượng trên eval, độ trễ, và số reasoning token ở mỗi cấu hình. Khách không cần hiểu chain-of-thought. Họ cần thấy bậc nào đáng tiền và vì sao.

Còn một rủi ro cần nói trước với khách: chuỗi suy luận nghe hợp lý vẫn có thể sai. Nếu khách định đưa phần suy luận vào màn hình cho nhân viên đối soát xem, hãy nói rõ đó là gợi ý cần kiểm tra lại, không phải bằng chứng.

Developer Việt nên luyện gì từ tuần này

Kỹ năng ở đây không phải thuộc lòng tham số API, vì tên tham số đã đổi từ budget cố định sang adaptive và có thể còn đổi tiếp. Thứ đáng giá là phản xạ đo: dựng bộ eval nhỏ, chạy cùng một task qua nhiều mức effort, đọc usage và đưa ra khuyến nghị bằng số liệu.

Khi đọc JD của vị trí FDE hay AI engineer, hãy để ý các cụm như “latency budget”, “cost optimization”, “evals” hay “production LLM”. Đó là dấu hiệu công ty cần người biết đánh đổi chứ không chỉ biết gọi API.

Trong CV, một dòng mô tả việc bạn so sánh nhiều cấu hình reasoning trên eval và chọn cấu hình theo SLA của khách sẽ thuyết phục hơn một dòng “có kinh nghiệm với GPT và Claude”.

Nếu chưa có dự án thật, hãy lấy một bài toán quen thuộc như đối soát sao kê hay trích xuất điều khoản hợp đồng, chạy qua từng bậc trong thang trên và viết lại kết quả thành một bài ngắn.

Nên đính kèm bảng chất lượng, độ trễ và token do chính bạn đo vào portfolio khi ứng tuyển, vì nó cho thấy bạn ra quyết định bằng số liệu chứ không bằng cảm tính.

Model sẽ còn nghĩ giỏi hơn và tự quyết nhiều hơn. Nhưng quyết định khách có nên trả tiền cho những suy nghĩ đó hay không vẫn thuộc về người đứng giữa model và hóa đơn, và vị trí đó là của FDE.