Reasoning
Cấu hình mức suy luận cho tác vụ phức tạp và đọc đúng kết quả, tóm tắt cùng Usage.
Reasoning phù hợp với tác vụ cần phân tích nhiều bước, ràng buộc phức tạp, suy diễn toán học, lập kế hoạch mã hoặc phối hợp công cụ. Mô hình suy luận thường cho phép ứng dụng kiểm soát mức suy luận và có thể trả về tóm tắt suy luận, Thinking Block hoặc Usage liên quan; hình thức cụ thể phụ thuộc vào mô hình và giao thức.
Với phân loại đơn giản, chuyển đổi định dạng hoặc hỏi đáp ngắn, mức suy luận cao hơn không nhất thiết cải thiện kết quả nghiệp vụ và có thể làm tăng thời gian phản hồi cùng lượng Token sử dụng.
Khả năng suy luận không được biểu diễn bằng một trường chung cho mọi giao thức
Chat, Responses, Anthropic Messages và Gemini biểu diễn cấu hình suy luận, kết quả công khai và trạng thái nhiều lượt theo cách khác nhau. Không sao chép trực tiếp trường của giao thức này sang giao thức khác.
Khi nào nên sử dụng
| Tác vụ | Khuyến nghị sử dụng |
|---|---|
| Lập kế hoạch với nhiều ràng buộc, phân tích phức tạp | Chọn mô hình hỗ trợ suy luận và bắt đầu đánh giá với mức thấp hoặc mặc định |
| Bài toán toán học, mã và logic | Đồng thời xác minh câu trả lời cuối cùng; không coi mức suy luận là bảo đảm kết quả đúng |
| Quy trình gọi công cụ | Giữ cấu trúc lời gọi, kết quả và trạng thái theo giao thức; đặt số vòng lặp tối đa |
| Viết lại ngắn, trích xuất và phân loại | Ưu tiên thử mô hình thông thường hoặc mức suy luận thấp để tránh chi phí không cần thiết |
Trước tiên, kiểm tra mô hình, giao thức và nhãn khả năng khả dụng cho tài khoản trong Danh mục mô hình. Thay MODEL_ID trong ví dụ bằng mô hình mà tài khoản có quyền dùng và hỗ trợ cấu hình suy luận tương ứng.
Cấu hình mức suy luận bằng Responses
Responses đặt cấu hình suy luận trong đối tượng reasoning:
curl 'https://api.agtcloud.cn/v1/responses' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer your-api-key' \
--data '{
"model": "MODEL_ID",
"input": "So sánh hai phương án di chuyển cơ sở dữ liệu và giải thích cơ sở lựa chọn.",
"reasoning": {
"effort": "medium",
"summary": "auto"
}
}'effort kiểm soát mức suy luận, còn summary yêu cầu tóm tắt suy luận mà giao thức cho phép công khai. Giá trị khả dụng và hiệu lực phụ thuộc vào mô hình; xem định nghĩa đầy đủ trong Responses Reference.
Cách các giao thức biểu diễn suy luận
Chat có thể yêu cầu mức suy luận khác nhau bằng reasoning_effort. Khi phản hồi cung cấp Token suy luận, chúng thường được ghi trong chi tiết completion của Usage; câu trả lời cuối cùng vẫn được đọc từ Assistant Message.
{
"model": "MODEL_ID",
"messages": [
{"role": "user", "content": "Phân tích các rủi ro chính của phương án triển khai này."}
],
"reasoning_effort": "medium"
}Các giá trị ví dụ chỉ minh họa vị trí trường, không có nghĩa mọi mô hình đều chấp nhận cùng mức hoặc ngân sách. Xem Reference của Chat Completions, Anthropic Messages và Gemini Generate Content.
Đọc câu trả lời cuối cùng và thông tin suy luận công khai
Ứng dụng thường cần xử lý riêng các nội dung sau:
- Câu trả lời cuối cùng: Nội dung thực sự hiển thị cho người dùng hoặc chuyển đến nghiệp vụ phía sau.
- Tóm tắt suy luận hoặc Thinking Block: Chỉ đọc khi giao thức và mô hình thực sự trả về; không giả định đây là toàn bộ quá trình suy nghĩ nội bộ của mô hình.
- Usage: Ghi nhận Token đầu vào, đầu ra cuối cùng và suy luận; vị trí trường thay đổi theo giao thức.
- Trạng thái dừng hoặc chưa hoàn chỉnh: Xác định câu trả lời có bị bỏ dở do ngân sách đầu ra, chính sách nội dung, hủy hoặc lỗi hay không.
Nếu nghiệp vụ chỉ cần kết luận cuối cùng, không cần lưu lâu dài nội dung suy luận công khai. Trước khi lưu loại nội dung này, cần đánh giá quyền riêng tư, phạm vi nhật ký và chính sách lưu giữ dữ liệu.
Streaming và gọi công cụ
- Phản hồi theo luồng có thể trả riêng phần tăng dần của suy luận và văn bản cuối cùng; ứng dụng cần dùng bộ đệm riêng.
- Trạng thái giao thức hoặc Thinking Block có thể xuất hiện trước và sau lời gọi công cụ; không chỉ giữ văn bản cuối cùng.
- Việc thực thi công cụ vẫn tuân theo yêu cầu kiểm tra tính hợp lệ tham số, quyền và idempotency của Tool Calling.
- Khi tiếp tục tạo nội dung, chỉ gửi lại cấu trúc lịch sử mà giao thức yêu cầu; không tự sửa chữ ký, ID lời gọi hoặc trạng thái opaque.
Xem cách xử lý luồng đầy đủ trong Streaming.
Thiết kế ngân sách đầu ra
Token suy luận và câu trả lời hiển thị có thể cùng sử dụng ngân sách đầu ra. Nếu ngân sách quá nhỏ, mô hình có thể hoàn tất phân tích nhưng không còn đủ dung lượng để đưa ra câu trả lời cuối cùng đầy đủ.
Ứng dụng production cần theo dõi đồng thời:
- Câu trả lời cuối cùng có đầy đủ không;
- Lý do dừng hoặc chưa hoàn chỉnh;
- Usage của suy luận và đầu ra hiển thị;
- Chất lượng, độ trễ và chi phí ở các mức suy luận khác nhau;
- Chu trình công cụ có kết thúc trong giới hạn số lần và tổng thời gian cho phép hay không.
Kiểm tra trước khi đưa vào production
- Tài khoản hiện tại có quyền dùng mô hình mục tiêu, và API suy luận cùng các trường yêu cầu đã được kiểm tra.
- Ứng dụng chỉ gửi các trường suy luận mà giao thức mục tiêu chấp nhận.
- Câu trả lời cuối cùng, thông tin suy luận công khai và Usage được xử lý riêng.
- Luồng, hội thoại nhiều lượt và gọi công cụ giữ các trạng thái giao thức cần thiết.
- Thiếu ngân sách đầu ra, từ chối, hết thời gian chờ và phản hồi chưa hoàn chỉnh đều có nhánh xử lý rõ ràng.
- Không mô tả mức suy luận, tóm tắt hoặc Thinking công khai như một bảo đảm tính đúng đắn.
Khi yêu cầu thất bại, xem Lỗi và khắc phục sự cố; trước khi đổi mô hình hoặc giao thức, xem Lựa chọn giao thức.