Hướng dẫn ngữ cảnh dài Kimi K3: nuôi cả cuốn sách và cả repository trong 1 triệu token

Ngữ cảnh dài là năng lực đặc trưng của dòng sản phẩm Kimi, và kimi-k3 đẩy cửa sổ lên 1,000,000 token dùng chung giữa input và output. Để hình dung quy mô: một request duy nhất có thể chứa trọn một cuốn sách kỹ thuật, toàn bộ file lõi của một codebase nhỏ, hoặc ghi chú họp của cả năm. Nhưng "chứa được" và "dùng tốt" là hai chuyện — cửa sổ càng lớn, bạn càng phải quản lý chất lượng đầu vào và chi phí một cách có chủ đích.

1 triệu token thực sự chứa được gì

Tham chiếu: một cuốn sách kỹ thuật 500 trang chạy khoảng 250,000–400,000 từ tiếng Anh; code lõi của một dự án web cỡ trung thường chỉ vài chục nghìn dòng; một năm biên bản họp hiếm khi vượt 300,000 ký tự Trung. Tất cả nằm gọn trong cửa sổ 1 triệu token — đó là ý nghĩa thực của "context cỡ cả cuốn sách".

Loại công việc nào xứng đáng dùng hết cửa sổ

Hiểu toàn văn có phụ thuộc chéo chương. Hợp đồng, bản cáo bạch, báo cáo nghiên cứu dài — kết luận trải khắp các chương, các điều khoản tham chiếu lẫn nhau. Chia nhỏ làm mất liên kết chéo; đọc trọn trong một lần mới dựng được bức tranh hoàn chỉnh.

Hỏi đáp cấp repository. Đưa mọi file lõi của dự án nhỏ–trung vào ngữ cảnh và mô hình trả lời được các câu hỏi xuyên file như "ai gọi hàm này" hoặc "thay đổi interface này ảnh hưởng module nào" mà không cần xây pipeline retrieval. Với repo lớn hơn cửa sổ, chọn lọc file lõi trước rồi đưa cả khối.

Ngữ cảnh tích luỹ qua hội thoại hoặc pipeline. Trong dự án dài hạn, các quyết định và kết luận trước đó cần luôn hiện diện. 1 triệu token chứa cả chuỗi quyết định của nhiều tháng, loại bỏ nhu cầu nén tóm tắt thường xuyên.

Mô hình hai bước: định vị, rồi đọc

Đổ tất cả vào cửa sổ là đắt và nhiều nhiễu. Mẫu hình rẻ hơn có hai giai đoạn:

Giai đoạn một: thu hẹp. Dùng mô hình nhỏ hoặc tìm theo từ khoá để chọn phần liên quan. Mục tiêu không phải trả lời câu hỏi — mà là thu hẹp tư liệu từ "tất cả" xuống "liên quan".

Giai đoạn hai: đọc sâu. Đưa tư liệu đã chọn toàn khối cho kimi-k3 để nó phân tích với ngữ cảnh đầy đủ.

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["EXAIV_API_KEY"],
    base_url="https://exaiv.com/api/ai/v1",
)

# Stage two: hand the filtered full text to kimi-k3
resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You are a contract review assistant. Answer only from the given text."},
        {"role": "user", "content": "Below is the full agreement. List every clause unfavorable to party B:\n\n" + contract_text},
    ],
)
print(resp.choices[0].message.content)

Lợi ích của mẫu hình này là độ chính xác: giai đoạn đọc sâu không chứa tư liệu ngoài lề nên sự chú ý của mô hình không bị pha loãng — câu trả lời ổn định hơn cách "đổ tất cả vào".

Kiểm soát chi phí

Cấu trúc chi phí của ngữ cảnh dài rõ ràng: input token chiếm phần lớn. Bốn đòn bẩy giữ hoá đơn thấp:

Cấp theo nhu cầu. Hỏi một hàm làm gì không cần cả repository — gửi file liên quan. Ngữ cảnh dài là trần năng lực, không phải mặc định.

Dùng lại prefix ổn định. Giữ system prompt và phần cố định của tài liệu ở đầu messages và không đổi, để prefix cache trúng. kimi-k3 hỗ trợ tự động prefix caching; các request lặp trên cùng tài liệu dài tốn ít hơn đáng kể khi trúng cache.

Cắt nhiễu. Log, thẻ HTML, ảnh base64 là token-dense và thông tin-light — làm sạch trước khi cấp. Nếu 30% trong 1 triệu token là nhiễu log, bạn đã đốt 30% ngân sách không cần thiết.

Giới hạn độ dài output. Output chiếm cùng cửa sổ. Đặt trần max_tokens hợp lý để mô hình không viết dài dòng bạn phải trả tiền.

Các bẫy thường gặp

Mất thông tin ở giữa. Trong ngữ cảnh rất dài, thông tin gần giữa cửa sổ đôi khi được sử dụng kém hơn phần đầu và cuối. Giảm nhẹ bằng cách đặt hướng dẫn quan trọng nhất trong system prompt và cuối message người dùng, và đặt tư liệu trọng yếu gần rìa.

Giữ toàn bộ lịch sử hội thoại. Các message tích luỹ sẽ ăn hết cửa sổ. Nén thành bản tóm tắt định kỳ — giữ kết luận và quyết định, loại chi tiết quy trình.

Coi context là bộ nhớ. Mô hình không có trí nhớ qua các request — mỗi request bắt đầu mới. Cho bộ nhớ bền vững, hoặc gắn tư liệu nền cần thiết mỗi lần, hoặc duy trì file tóm tắt bạn chèn theo request.

Bỏ qua khác biệt tokenizer. Văn bản Trung-Anh trộn, code, ký hiệu đặc biệt biến động rất mạnh về mật độ token; ước lượng từ số ký tự không đáng tin. Đo một lần bằng dữ liệu thật trước khi đặt ngân sách.

Minh họa hỏi đáp trên repository

Hỏi đáp cấp repository cho thấy mẫu hình này vận hành từ đầu đến cuối. Chọn lọc file lõi trước, rồi hỏi với ngữ cảnh đầy đủ:

core_files = ["src/app.ts", "src/routes.ts", "src/services/payment.ts"]
repo_text = "\n\n".join(
    f"// ===== {p} =====\n{open(p).read()}" for p in core_files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You answer questions about this repository. Cite file names."},
        {"role": "user", "content": f"{repo_text}\n\nQuestion: where is the refund policy enforced, and what breaks if we change it?"},
    ],
)

Hai thói quen làm cho cách này đáng tin. Một, giữ danh sách file ổn định giữa các câu hỏi để prefix cache trúng — câu hỏi thứ hai chỉ tốn một phần nhỏ so với câu đầu. Hai, yêu cầu mô hình trích dẫn tên file trong câu trả lời; việc trích dẫn giúp xem lại nhanh và phát hiện ngay khi mô hình bịa ra.

Theo dõi mức tiêu thụ token

Khối lượng công việc ngữ cảnh dài xứng đáng có giám sát rõ ràng. Mọi phản hồi đều mang đối tượng usage:

print(resp.usage.prompt_tokens)      # chi phí của phần input
print(resp.usage.completion_tokens)  # chi phí của phần output
print(resp.usage.total_tokens)

Ghi nhật ký theo từng request và tổng hợp theo khối lượng công việc. Ba tín hiệu đáng chú ý: tỉ lệ prompt-so-với-completion (cho biết việc cắt input có phải đòn bẩy đúng không), token mỗi câu hỏi (cho biết giai đoạn chọn lọc có quá hào phóng không), và hành vi cache-hit giữa các câu hỏi lặp (cho biết prefix của bạn có thực sự ổn định không). Toàn bộ cẩm nang giám sát nằm trong hướng dẫn theo dõi token.

FAQ

Bài viết này trả lời những gì

• 1 triệu token ngữ cảnh chứa được gì
• phân tích tài liệu dài thế nào
• kiểm soát chi phí ngữ cảnh dài thế nào

Sơ đồ tình huống nhanh

Nhìn về phía trước

Catalog và trọng số tiếp tục thay đổi; các quy ước tích hợp và gọi ở đây theo tài liệu chính thức tại thời điểm xuất bản.

Nguồn và xác minh

Các sự kiện chính trong bài viết này lấy từ model card chính thức của Kimi K3 (thông số ngữ cảnh) và phép đo tokenizer của nền tảng và được xác minh vào 2026-11-09. Model ID, giá và khả dụng theo catalog trực tiếp của nền tảng — cố tình không ghi số cố định dễ lỗi thời. Code mẫu theo hợp đồng API tại thời điểm xuất bản; kiểm tra tài liệu chính thức trước khi đưa vào production.

Phạm vi và đối tượng

Đối tượng: developer xử lý tài liệu dài hoặc repository lớn. Phạm vi: mẫu sử dụng ngữ cảnh dài, kiểm soát chi phí và giới hạn. Không bao gồm: thiết kế kiến trúc RAG hoặc chọn vector store.

Ghi chú biên tập và chính tả

Viết bởi đội nội dung EXAIV từ các sự kiện kiểm chứng được, kiểm tra nguồn và code trước khi xuất bản. Nếu có nội dung lỗi thời hoặc sai, trang phát hành chính thức và catalog trực tiếp là chuẩn — hãy báo qua kênh phản hồi của trang để chúng tôi cập nhật.

Đọc tiếp

• Hướng dẫn kết nối Kimi K3
• Hướng dẫn RAG Knowledge Base
• Qwen KV Cache và ngữ cảnh dài
• Theo dõi token và chi phí
• Hướng dẫn structured output