Anthropic Exam ProDomain 2: Claude Models, Prompting & Context Engineering·Task 2.4
Tối ưu context window và quản lý token
Những gì chiếm context window, chuyện gì xảy ra khi chạm giới hạn, cách đo token trước và sau khi gọi, và cách giảm token ở từng giai đoạn của một yêu cầu.
- 6 phút đọc
- Đối chiếu docs 02/11/2026
- 7 nguồn
Đọc xong bạn nắm được
- Kể được mọi thứ tính vào context window, kể cả phần đã cache và phần thinking
- Phân biệt lỗi khi đầu vào quá dài với lúc câu trả lời bị dừng vì hết chỗ
- Đo token trước khi gửi bằng token counting và sau khi gửi bằng các trường usage
- Xếp các cách giảm token vào đúng giai đoạn chuẩn bị đầu vào, dựng prompt, xử lý đầu ra
- Giảm phần context do tool chiếm, và giữ hội thoại dài trong giới hạn
Context window 1 triệu token nghe như không bao giờ hết. Nhưng mỗi token trong đó đều tốn tiền, làm chậm câu trả lời, và docs của Anthropic nói rõ: càng nhiều token thì độ chính xác và khả năng nhớ lại càng giảm. Nhồi càng nhiều càng tốt là sai.
Bài này giúp bạn trả lời: cái gì đang chiếm context, đo nó ra sao, và giảm ở chỗ nào mà không làm hỏng chất lượng?
Ví dụ xuyên suốt: trợ lý kỹ thuật của một hãng máy lạnh
Một hãng máy lạnh làm trợ lý cho kỹ thuật viên đi sửa máy tại nhà. Mỗi yêu cầu gửi kèm:
- System prompt 6.000 token: quy trình an toàn điện, cách chẩn đoán, giọng văn.
- 35 tool: tra mã lỗi, tra sơ đồ mạch, tra linh kiện tồn kho, đặt linh kiện, ghi biên bản...
- Đoạn trích từ sổ tay sửa chữa dài 300 trang, truy xuất theo câu hỏi.
- Cả lịch sử trò chuyện với kỹ thuật viên, có khi kéo dài cả buổi.
Hoá đơn API tăng nhanh, và những cuộc trò chuyện dài bắt đầu có câu trả lời lẫn lộn giữa hai máy khác nhau.
Cái gì chiếm context
Docs về context window liệt kê: mọi thứ trong yêu cầu đều tính, gồm system prompt, mọi tin nhắn trong messages (kể cả kết quả tool), và định nghĩa tool. Câu trả lời Claude sinh ra, kể cả phần thinking, cũng tính.
Ba điều hay bị hiểu sai:
| Hiểu sai | Đúng |
|---|---|
| Phần đã cache thì không chiếm chỗ | Docs nói phần prompt đã cache vẫn chiếm context window. Cache chỉ đổi giá bạn trả cho chúng |
| Context càng lớn càng tốt | Docs gọi hiện tượng độ chính xác giảm khi token tăng là context rot |
| Định nghĩa tool không đáng kể | 35 tool gửi kèm mọi yêu cầu là một khoản lớn, cả về chỗ lẫn tiền |
Các model hiện nay (Opus, Sonnet, Haiku 5.5, Fable 5.1) có context window 1 triệu token. Một số model cũ hơn vẫn là 200.000 token.
Khi chạm giới hạn
Có hai trường hợp khác nhau:
- Riêng đầu vào đã vượt context window: API trả lỗi 400
invalid_request_error("prompt is too long"), trên mọi model. Yêu cầu không chạy. - Đầu vào cộng
max_tokensvượt context window: trên các model từ Claude 4.5 trở đi, yêu cầu vẫn chạy, và nếu câu trả lời dài tới mức hết chỗ thì dừng vớistop_reasonlàmodel_context_window_exceeded.
Đo token trước và sau khi gửi
Trước khi gửi: endpoint token counting cho biết một yêu cầu có bao nhiêu token mà không phải gọi model. Docs nói dùng nó để quản lý giới hạn tốc độ và chi phí, chọn model theo độ dài, và tối ưu prompt về một độ dài nhất định. Đây là con số ước lượng, và tokenizer của các model từ Claude 4.7 trở đi cho số token nhiều hơn khoảng 30% với cùng một đoạn chữ, nên đếm lại theo đúng model sẽ dùng.
Sau khi gửi: đọc object usage trong phản hồi. Tổng token đầu vào là cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Chỉ nhìn input_tokens sẽ thấy con số nhỏ bất thường khi đang dùng cache, vì nó chỉ đếm phần sau điểm cache cuối cùng.
Giảm token ở từng giai đoạn
Câu luyện thi chia các cách quản lý token theo giai đoạn của một yêu cầu. Cách chia này dễ nhớ:
| Giai đoạn | Cách giảm | Trong ví dụ |
|---|---|---|
| Chuẩn bị đầu vào (Input Preparation) | Tóm tắt phần hội thoại cũ khi không cần đầy đủ nữa; cắt đoạn truy xuất chỉ còn phần liên quan tới câu hỏi | Bỏ chi tiết của máy đã sửa xong; chỉ lấy đoạn sổ tay về đúng mã lỗi |
| Dựng prompt (Prompt Construction) | Xếp phần ổn định lên đầu để cache được; đưa nội dung lặp lại vào prefix cache | System prompt 6.000 token và định nghĩa tool đặt đầu, bật cache |
| Xử lý đầu ra (Output Handling) | Kiểm đầu ra có cấu trúc đúng schema; lưu kết quả đã kiểm cho bước sau và cho kiểm toán | Kiểm biên bản sửa chữa trước khi ghi vào hệ thống |
Phần context do tool chiếm
Docs về quản lý context của tool nói có hai nguồn: định nghĩa tool, và các kết quả tool tích luỹ dần. Bốn cách, mỗi cách nhắm một chỗ:
| Cách | Giảm gì | Khi nào |
|---|---|---|
| Tool search | Không gửi trước mọi định nghĩa tool, Claude tìm tool khi cần | Bộ tool lớn, khoảng 20 tool trở lên; đổi lại thêm một lượt tra |
| Programmatic tool calling | Kết quả trung gian không vào lịch sử hội thoại | Chuỗi nhiều lần gọi tool nhỏ chạy được thành một đoạn code |
| Prompt caching cho định nghĩa tool | Không giảm token, chỉ giảm tiền cho phần lặp lại | Nên bật ngay từ đầu |
| Context editing | Xoá kết quả tool cũ đã dùng xong khỏi lịch sử | Hội thoại dài |
Trợ lý máy lạnh có 35 tool: bật cache cho định nghĩa tool, rồi chuyển sang tool search để chỉ những tool hay dùng (tra mã lỗi, tra sơ đồ) luôn được nạp.
Hội thoại dài
Với hội thoại và agent chạy lâu, docs nói compaction phía server là cách chính để quản lý context: thay các lượt cũ bằng một bản tóm tắt do Claude viết, để hội thoại tiếp tục được. Context editing là cách nhắm hẹp hơn: xoá kết quả tool cũ hay khối thinking cũ. Với trợ lý máy lạnh, khi kỹ thuật viên chuyển sang máy thứ hai, tóm tắt phần về máy thứ nhất là cách tránh câu trả lời lẫn lộn hai máy.