Context Window: Giới hạn bộ nhớ của AI

Định nghĩa

Context Window là số lượng token tối đa mà một LLM có thể xử lý trong một lần inference — bao gồm cả input (prompt, system message, conversation history) và output (completion). Nó giống như RAM của AI: chỉ dữ liệu nằm trong "cửa sổ" này mới được model nhìn thấy và sử dụng, mọi thứ ngoài đó hoàn toàn vô hình.

Giải thích chi tiết

Context Window không phải bộ nhớ dài hạn

Đây là misconception phổ biến nhất. Context window không phải "trí nhớ" của AI mà là bộ nhớ tạm thời (working memory) — giống như RAM máy tính của bạn. Khi bạn tắt máy (kết thúc session), RAM xóa trắng. Tương tự, khi conversation vượt quá giới hạn window, model bắt đầu "quên" những gì ở đầu cuộc trò chuyện.

Cơ chế thực tế: các model hiện đại dùng KV cache để lưu trạng thái attention của token đã xử lý. Khi cache đầy, model phải bỏ bớt token đầu tiên (FIFO) hoặc dùng kỹ thuật summarization để nén lại. Kết quả: bạn mất context.

Cơ chế "trượt" và hiện tượng "lost in the middle"

Khi chat dài vượt quá window limit (thường từ 4k-128k token tùy model), model thực hiện sliding window — cắt bỏ phần đầu để nhường chỗ cho phần cuối. Nghiên cứu từ Stanford chỉ ra hiện tượng "lost in the middle": model tập trung vào đầu và cuối context, nhưng thông tin ở giữa dễ bị bỏ sót nhất.

Điều này ảnh hưởng trực tiếp đến cách bạn cấu trúc dữ liệu: thông tin quan trọng nên đặt ở đầu (system prompt) hoặc cuối (few-shot examples gần nhất), tránh chôn giữa đống tài liệu dài.

Token economics trong Context Window

Context window ảnh hưởng trực tiếp đến chi phí API. Công thức thực tế:

$\text{Total Tokens} = \text{Input Tokens} + \text{Output Tokens} \leq \text{Context Window Limit}$

Ví dụ với GPT-4 Turbo (128k context window):

• Bạn gửi 100k token tài liệu tham khảo
• Chỉ còn 28k token cho cả prompt instruction và output
• Nếu output cần 10k token, bạn chỉ có 18k token cho instruction và history

Và chi phí tính theo: bạn trả tiền cho tất cả input token (đã xử lý trong window) cộng output token. Context window lớn đồng nghĩa chi phí cao, không chỉ do giá token mà do tính toán attention phức tạp hơn (quadratic complexity với sequence length).

Các mức Context Window thực tế

Hiện tại (2024):

• Claude 3.5 Sonnet: 200k token (khoảng 500 trang PDF)
• GPT-4 Turbo/GPT-4o: 128k token
• Gemini 1.5 Pro: 1M-2M token (nhưng latency cao với context lớn)
• Llama 3: 8k-128k tùy fine-tune

Lưu ý: Window lớn không đồng nghĩa với hiệu suất tốt. Các thử nghiệm cho thấy model thường "lướt" qua context dài thay vì đọc kỹ, và thời gian phản hồi tăng đáng kể với input dài.

Ví dụ thực tế

Review code với context khác nhau

Cùng một prompt: "Tìm lỗi bảo mật trong đoạn code sau:"

Trường hợp A — Context ngắn (500 token): Chỉ gửi function đơn lẻ. AI trả lời: "Không thấy lỗi rõ ràng, nên thêm validation input."

Trường hợp B — Context đầy đủ (3k token): Gửi thêm file config, database schema, và middleware authentication. AI phát hiện: "Function này bypass middleware vì được gọi trực tiếp từ route /debug không được bảo vệ trong routes.config mà bạn gửi ở đầu context."

→ Kết quả khác biệt hoàn toàn chỉ vì context window chứa đúng thông tin liên quan.

Tóm tắt tài liệu dài và "lost in the middle"

Bạn cần tóm tắt hợp đồng 100 trang (khoảng 30k token) bằng GPT-4.

Thử nghiệm:

• Cho vào toàn bộ 30k token (trong giới hạn 128k)
• Yêu cầu: "Liệt kê các điều khoản phạt vi phạm"

Kết quả: Model tìm được 2/3 điều khoản ở đầu và cuối hợp đồng, nhưng bỏ sót điều khoản quan trọng ở trang 45-55 (chính giữa context).

Giải pháp Context Engineering: Chia thành 3 chunk, tóm tắt từng phần, rồi gom lại. Điều này dẫn đến kỹ thuật RAG và chunking mà chúng ta sẽ đề cập ở các bài sau.

Chatbot quên lệnh hệ thống sau 50 lượt hội thoại

System prompt ban đầu: "Bạn là trợ lý y tế, chỉ trả lời về thuốc men, từ chối các câu hỏi ngoài lề."

Sau 50 lượt trao đổi (mỗi lượt trung bình 200 token), tổng cộng 10k token. Nếu dùng model 4k context window (GPT-3.5 cũ), model bắt đầu cắt bỏ token đầu tiên — chính là system prompt của bạn.

Kết quả: Ở lượt 51, user hỏi "Viết poem về mùa xuân", AI tuân lệnh viết poem thay vì từ chối. Context window đã "đẩy" system prompt ra ngoài.

→ Bài học: Với conversation dài, phải dùng model có window đủ lớn, hoặc dùng kỹ thuật re-summarization để "nén" lịch sử chat mà vẫn giữ system instruction.

Ứng dụng

Developer xây dựng AI-native apps

• Chọn model theo codebase: Nếu repo của bạn 50k token (khoảng 150 file), GPT-4 8k không đủ. Phải dùng Claude 200k hoặc chia nhỏ module.
• Thiết kế RAG: Khi dữ liệu vượt quá window (1000 tài liệu PDF), không thể "nhét" hết vào prompt. Đây là lúc cần Retrieval để chỉ lấy top-5 relevant chunks vừa window.
• Streaming vs Batch: Window lớn cho phép batch processing nhiều examples cùng lúc, nhưng tăng latency.

Data Analyst xử lý dữ liệu lớn

• Chunking CSV: File 100k dòng (khoảng 500k token) không thể nhét vào GPT-4. Phải chia thành từng batch 10k dòng, xử lý tuần tự, rồi aggregate kết quả.
• Multi-turn analysis: Khi phân tích tài liệu dài qua nhiều lượt hỏi đáp, phải tự động "refresh" context bằng cách inject lại key facts vào mỗi turn mới.

Content Creator viết long-form

• Consistency check: Viết tiểu thuyết 20 chương. Sau 5 chương (vượt window), AI quên tên nhân vật phụ. Giải pháp: Maintain "character sheet" ngay trong context mỗi lượt chat, hoặc dùng model 200k+ window.
• Outline-first approach: Đưa outline chi tiết vào đầu context (survive lâu nhất), rồi yêu cầu viết từng phần.

Doanh nghiệp tối ưu chi phí

• Cost-latency trade-off: Window 1M token của Gemini rất hấp dẫn cho legal review hợp đồng dài, nhưng giá input cao và chậm. Đôi khi chia nhỏ bằng workflow automation rẻ và nhanh hơn.
• Caching strategy: Các token đầu (system prompt, context cố định) có thể dùng prompt caching (của Anthropic/DeepSeek) để giảm 90% chi phí khi context window lớn.

So sánh

Kết luận: Context Window là giới hạn phần cứng (constraint), Context Engineering là cách bạn tối ưu trong giới hạn đó (optimization), còn RAG là cách vượt giới hạn (escape hatch). Ba cái này đi cùng nhau trong mọi ứng dụng AI thực tế.

Bài viết liên quan

Cùng cụm: Nền tảng Context

Đọc tiếp