Context Window: Bộ Nhớ Ngắn Hạn Của AI Và Cách Tối Ưu

Context window là giới hạn cứng mà mọi AI đều phải đối mặt. Nó quyết định mô hình ngôn ngữ lớn có thể “nhớ” bao nhiêu trong một lượt - từ lịch sử trò chuyện đến tài liệu bạn đưa vào. Vượt quá? AI sẽ quên phần đầu, trả lời lung tung, hoặc đơn giản báo lỗi. Hiểu rõ context window giúp bạn khai thác AI đúng cách: tiết kiệm tiền, tăng độ chính xác, và tránh những lỗi khó hiểu.

Context window là gì?

Context window là lượng văn bản tối đa mà AI có thể xử lý trong một lần. Đơn vị đo? Token - mảnh nhỏ nhất mà mô hình hiểu được (một token khoảng 0.75 từ tiếng Anh, hoặc 0.5-1 từ tiếng Việt).

Ví dụ:

• GPT-4 Turbo: 128,000 token (~96,000 từ) - đủ chứa một cuốn sách nhỏ
• Claude 3.5 Sonnet: 200,000 token (~150,000 từ) - gấp đôi sách vừa
• Gemini 1.5 Pro: 2,000,000 token (~1.5 triệu từ) - hàng chục cuốn sách

Context window bao gồm tất cả thông tin trong một lượt xử lý:

1. System prompt (hướng dẫn ban đầu cho AI)
2. Lịch sử hội thoại (tin nhắn của bạn + câu trả lời AI)
3. Tài liệu đầu vào (file, code, dữ liệu bạn cung cấp)
4. Câu trả lời AI tạo ra (output cũng chiếm chỗ!)

Khi tổng số token vượt quá giới hạn, điều gì xảy ra?

Hậu quả khi vượt context window

Các mô hình xử lý khác nhau:

1. Cắt bỏ phần đầu (sliding window):

   • AI tự động “quên” tin nhắn cũ nhất để nhường chỗ cho thông tin mới
   • Hậu quả: Mấtmạch lạc, câu trả lời không nhất quán với phần đầu cuộc hội thoại

2. Báo lỗi và từ chối:

   • Trả về lỗi context_length_exceeded - buộc bạn phải rút ngắn đầu vào
   • Hậu quả: Phải tóm tắt hoặc chia nhỏ tác vụ

3. Tăng giá hoặc throttling:

   • Một số API tính phí cao hơn hoặc giảm tốc độ khi context lớn
   • Hậu quả: Chi phí tăng mạnh, thời gian chờ lâu hơn

Hiện tượng “lost in the middle”:

LLM nhớ rõ thông tin ở đầu và cuối context, nhưng hay quên phần giữa. Ngay cả khi chưa đạt giới hạn tối đa. Nghiên cứu năm 2023 của Stanford chứng minh: độ chính xác giảm 20-30% khi thông tin quan trọng nằm ở giữa văn bản dài. Context lớn không tự động nghĩa là AI dùng hết.

Tại sao context window quan trọng?

1. Quyết định khả năng xử lý tài liệu dài

Trường hợp thực tế:

• Phân tích báo cáo 50 trang → cần ≥30,000 token
• Review code một repository lớn → cần 100,000+ token
• Tóm tắt cuốn sách → cần ≥200,000 token

Mô hình context nhỏ buộc bạn phải:

• Chia nhỏ tài liệu → mấtmạch lạc liên kết giữa các phần
• Tóm tắt trước khi đưa vào → mất thông tin chi tiết
• Chấp nhận câu trả lời thiếu chính xác

2. Ảnh hưởng trực tiếp đến chi phí

Các API tính phí theo token xử lý. Context window càng lớn, chi phí càng cao - ngay cả khi bạn không dùng hết.

So sánh chi phí (ước tính 2026):

• Claude 3.5 Sonnet (200K context): ~$3/triệu token input
• GPT-4 (8K context): ~$30/triệu token input (model cũ)
• Gemini 1.5 Pro (2M context): ~$1.25/triệu token input

→ Context lớn không đồng nghĩa đắt hơn - nhưng dùng không hiệu quả sẽ lãng phí tiền.

3. Tốc độ xử lý giảm theo context

Context càng dài, thời gian xử lý (latency) càng tăng:

• 8K token: ~1-2 giây
• 128K token: ~5-10 giây
• 1M+ token: ~30-60 giây

Ứng dụng real-time (chatbot, coding assistant) cần response nhanh → context lớn thành bottleneck.

4. Stateless vs stateful conversation

LLM là stateless - chúng không có “bộ nhớ thật” giữa các lần gọi API. Mỗi request phải gửi lại toàn bộ lịch sử hội thoại.

Ví dụ cuộc trò chuyện 10 lượt:

• Lượt 1: 100 token
• Lượt 5: 100 + 500 + 300 + 400 + 250 = 1,550 token (cộng dồn)
• Lượt 10: ≥3,000 token (phải gửi lại 9 lượt trước)

→ Càng nói lâu, càng tốn token và tiền. Quản lý context là quản lý chi phí.

Cách đo và theo dõi context window

Đếm token chính xác

Không phải mọi ký tự = 1 token. Token hóa (tokenization) phụ thuộc mô hình:

Tiếng Anh:

• “Hello world” ≈ 2 token
• “I’m running out of context!” ≈ 7 token

Tiếng Việt (Unicode):

• “Xin chào” ≈ 4-6 token (tùy mô hình)
• Chữ có dấu thường tốn nhiều token hơn

Công cụ đếm token:

• OpenAI Tokenizer: https://platform.openai.com/tokenizer
• Anthropic Console: tích hợp sẵn
• Thư viện: tiktoken (Python), gpt-tokenizer (JavaScript)

Ví dụ code Python:

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4")
text = "Context window là bộ nhớ ngắn hạn của AI"
tokens = enc.encode(text)
print(f"Số token: {len(tokens)}")  # Output: ~12-15 token

Theo dõi usage trong API response

Hầu hết API trả về usage metadata:

{
  "usage": {
    "prompt_tokens": 1250,
    "completion_tokens": 380,
    "total_tokens": 1630
  }
}

Ý nghĩa:

• prompt_tokens: Input bạn gửi (system prompt + lịch sử + câu hỏi hiện tại)
• completion_tokens: Output AI tạo ra
• total_tokens: Tổng = prompt + completion

→ Khi total_tokens tiến gần giới hạn model (ví dụ 120K/128K), cần can thiệp.

Warning signs cần chú ý

1. Response chậm bất thường - thời gian xử lý tăng đột ngột
2. Câu trả lời lặp lại - AI quênmạch lạc, bắt đầu lặp thông tin
3. “Tôi không tìm thấy trong tài liệu” - trong khi info có trong đầu vào (nhưng bị chôn vùi giữa context dài)
4. Lỗi context_length_exceeded - đã vượt hard limit

Kỹ thuật tối ưu context window

1. Tóm tắt thông minh (summarization)

Khi nào dùng: Lịch sử hội thoại dài, tài liệu report nhiều trang

Cách làm:

• Sau mỗi 5-10 lượt hội thoại, tóm tắt phần cũ thành vài câu
• Thay thế lịch sử đầy đủ = summary + 2-3 lượt gần nhất
• Dùng AI tóm tắt chính nó: "Summarize our conversation so far in 3 bullet points"

Ví dụ:

# Trước (800 token):
User: [câu hỏi 1 dài 200 token]
AI: [trả lời 300 token]
User: [câu hỏi 2 150 token]
AI: [trả lời 150 token]

# Sau tóm tắt (150 token):
Summary: Discussed [topic A] - concluded [X]. Asked about [topic B] - answer was [Y].
User: [câu hỏi mới]

→ Tiết kiệm 650 token (~81%).

2. Pruning - cắt bỏ thông tin không cần

Nguyên tắc: Loại bỏ những gì AI không cần để trả lời câu hỏi hiện tại.

Cắt gì:

• Metadata, header/footer tài liệu
• Code comments dài (giữ logic chính)
• Ví dụ trùng lặp
• Formatting không cần thiết (nhiều dòng trống, ký tự đặc biệt…)

Ví dụ code:

# Trước (200 token):
"""
File: utils.py
Author: John Doe
Created: 2024-01-15
Purpose: Utility functions for data processing
...
"""

def process_data(data):
    # This function processes the input data
    # Returns cleaned data
    # Raises ValueError if data is invalid
    ...

# Sau pruning (50 token):
def process_data(data):
    # Process and clean input data
    ...

3. Chunking - chia nhỏ tác vụ

Khi nào dùng: Tài liệu quá dài (>100 trang), cần phân tích sâu nhiều góc độ

Cách làm:

• Chia tài liệu thành các chunk 5,000-10,000 token
• Xử lý tuần tự: chunk 1 → tóm tắt → chunk 2 → tóm tắt…
• Tổng hợp tất cả summary cuối cùng

Ví dụ workflow:

1. Tách 200-page report → 20 chunks (mỗi chunk 10 trang)
2. Xử lý chunk 1: "Summarize key points from pages 1-10"
3. Lưu summary 1 (200 token)
4. Xử lý chunk 2 + summary 1: "Based on [summary 1], analyze pages 11-20"
5. Lặp lại...
6. Cuối cùng: "Given these 20 summaries, answer [câu hỏi tổng quan]"

Nhược điểm: Mấtmạch lạc liên kết giữa các chunk - phù hợp câu hỏi cục bộ, không phù hợp phân tích toàn cục.

4. Prompt compression

Kỹ thuật: Viết lại prompt ngắn gọn hơn mà vẫn giữ đủ ý

Ví dụ:

# Trước (80 token):
You are an expert software engineer with 10 years of experience in Python development. Please carefully review the following code and identify any potential bugs, security vulnerabilities, or performance issues. Provide detailed explanations for each issue found.

# Sau (30 token):
Expert Python engineer: Review code for bugs, security issues, performance problems. Explain each.

Các công cụ auto-compression:

• LLMLingua (Microsoft Research): nén prompt giữ nguyên semantic
• Gist tokens (experimental): AI học “ghi nhớ” context thành token đặc biệt

5. Sử dụng external memory (RAG)

RAG (Retrieval-Augmented Generation): Thay vì nhồi toàn bộ tài liệu vào context, chỉ truy xuất phần liên quan.

Workflow:

1. Chia tài liệu thành chunks nhỏ
2. Tạo embedding vector cho mỗi chunk (dùng embedding model)
3. Lưu vào vector database (Pinecone, Weaviate, Chroma…)
4. Khi user hỏi → tìm top 3-5 chunks liên quan nhất
5. Chỉ đưa 3-5 chunks đó vào context (thay vì cả tài liệu)

Ví dụ:

• Tài liệu 500 trang = 200,000 token
• User hỏi về “chương 3”
• RAG tìm 5 chunks từ chương 3 = 3,000 token
• Tiết kiệm 197,000 token (~98.5%)

→ Chi tiết RAG: Retrieval-Augmented Generation: Kỹ Thuật Nền Tảng AI Chatbot

6. Streaming và early stopping

Streaming: Nhận từng phần output thay vì chờ toàn bộ → giảm perceived latency

Early stopping: Dừng generation khi đã đủ thông tin → tiết kiệm completion tokens

Ví dụ:

# Streaming
for chunk in openai.ChatCompletion.create(
    model="gpt-4",
    messages=[...],
    stream=True
):
    print(chunk['choices'][0]['delta'].get('content', ''), end='')

# Early stopping
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[...],
    max_tokens=300,  # Giới hạn output
    stop=["\n\n"]    # Dừng khi gặp double newline
)

So sánh context window các mô hình phổ biến (2026)

Mô hình	Context Window	Use Case Phù Hợp	Chi Phí Input
GPT-4o	128K token	Balanced - phù hợp hầu hết task	~$2.50/1M token
GPT-4 Turbo	128K token	Code generation, long conversation	~$10/1M token
Claude 3.5 Sonnet	200K token	Coding, document analysis	~$3/1M token
Claude 3 Opus	200K token	Complex reasoning, deep analysis	~$15/1M token
Gemini 1.5 Pro	2M token	Extreme long document, video analysis	~$1.25/1M token
Gemini 1.5 Flash	1M token	Fast processing, high volume	~$0.075/1M token
GPT-3.5 Turbo	16K token	Simple tasks, cost-sensitive	~$0.50/1M token

Lựa chọn theo bài toán:

• Chat assistant, Q&A ngắn: 16K-32K đủ → GPT-3.5 Turbo (rẻ, nhanh)
• Code review, technical writing: 128K → GPT-4o, Claude 3.5 Sonnet
• Phân tích sách, long report: 200K-1M → Claude 3 Opus, Gemini 1.5 Flash
• Video analysis, multi-doc comparison: 1M-2M → Gemini 1.5 Pro (duy nhất)

Sai lầm thường gặp khi làm việc với context window

1. Nghĩ rằng context lớn = không cần tối ưu

Thực tế: Gemini 1.5 Pro có 2M token, nhưng:

• Xử lý 2M token tốn ~$2.50/request
• Latency 30-60 giây
• “Lost in the middle” - AI vẫn bỏ sót thông tin quan trọng ở giữa

→ Nguyên tắc: Chỉ đưa vào context những gì thực sự cần để trả lời câu hỏi.

2. Không theo dõi token usage

Nhiều người phát hiện vượt context khi đã nhận lỗi hoặc hóa đơn tăng đột ngột.

Thực hành tốt:

• Log usage sau mỗi request
• Set alert khi prompt_tokens > 80% giới hạn
• Tính toán chi phí trước khi scale

3. Gửi lại toàn bộ lịch sử mỗi lượt

Anti-pattern:

# Cứ mỗi lượt lại append thêm, không bao giờ dọn dẹp
messages.append({"role": "user", "content": user_input})
messages.append({"role": "assistant", "content": ai_response})
# → Sau 50 lượt, messages có 100 items, >50K token

Best practice:

• Giữ tối đa 10-20 lượt gần nhất
• Tóm tắt phần cũ hơn
• Hoặc dùng session storage (database) + chỉ load context liên quan

4. Bỏ qua system prompt

System prompt chiếm context nhưng không đổi mỗi lượt → nếu quá dài, lãng phí.

Ví dụ system prompt 1,000 token:

• 50 lượt hội thoại = 50,000 token wasted (vì gửi lại mỗi lần)

Tối ưu:

• Rút ngắn system prompt xuống <200 token
• Hoặc cache system prompt (một số provider hỗ trợ caching)

5. Không test với context thực tế

Nhiều ứng dụng test với input ngắn, khi production có user gửi file dài 50MB → crash.

Best practice:

• Load test với context ~80% giới hạn
• Handle lỗi context_length_exceeded gracefully (không để app crash)
• Hiển thị warning khi user sắp vượt quá

Tương lai của context window

Xu hướng 2026-2027

1. Context window càng lớn:

• Gemini 1.5 Pro đã đạt 2M token (2026)
• Nghiên cứu hướng tới 10M-100M token trong vài năm tới
• Infinite context? Có thể, nhưng chi phí và latency vẫn là rào cản

2. Sparse attention và efficient transformers:

• Longformer, BigBird: Chỉ attend vào một phần token, không phải toàn bộ
• Ring Attention: Chia context thành vòng, xử lý song song
• FlashAttention: Tối ưu memory và speed cho context dài

→ Context 1M token xử lý nhanh như 10K token hiện tại.

3. Hybrid memory architecture:

• Short-term (context window): Lưu conversation hiện tại
• Long-term (vector DB): Lưu kiến thức lâu dài, truy xuất khi cần
• Episodic memory: Ghi nhớ các sự kiện quan trọng trong lịch sử

→ AI có “bộ nhớ giống người” hơn.

4. Context caching:

• OpenAI, Anthropic đang test caching system prompt + static context
• User chỉ trả phí cho phần context thay đổi
• Giảm 50-70% chi phí cho use case lặp lại (chatbot, coding assistant)

Giới hạn vật lý

Memory wall: Ngay cả với breakthrough thuật toán, hardware vẫn giới hạn:

• GPU VRAM: A100 có 80GB, H100 có 80-141GB
• Context 10M token ≈ 40-80GB memory
• Xử lý 100M token cần cluster GPU → chi phí khổng lồ

→ Context lớn vô hạn không khả thi trong ngắn hạn. Tối ưu hiệu quả vẫn cần thiết.

Tóm lại

Context window là giới hạn cứng của mọi LLM - quyết định AI có thể “nhớ” bao nhiêu thông tin. Hiểu rõ nó giúp bạn:

1. Chọn model phù hợp - không cần 2M token cho task chỉ cần 10K
2. Tối ưu chi phí - tiết kiệm 50-90% bằng pruning, summarization, RAG
3. Tăng tốc độ - giảm latency, cải thiện UX
4. Tránh lỗi - handle gracefully thay vì crash

Các kỹ thuật cốt lõi:

• Summarization - tóm tắt lịch sử cũ
• Pruning - cắt bỏ thông tin thừa
• Chunking - chia nhỏ tài liệu dài
• RAG - chỉ truy xuất phần liên quan
• Prompt compression - viết ngắn gọn hơn

Context window sẽ tiếp tục tăng, nhưng hiệu quả > kích thước. Một prompt 5K token được thiết kế tốt thắng 50K token lộn xộn.

Đọc thêm:

• Prompt Engineering Nâng Cao: Kỹ Thuật Tối Ưu Giao Tiếp Với AI - Các kỹ thuật viết prompt hiệu quả giúp tiết kiệm context và tăng độ chính xác.
• RAG - Retrieval-Augmented Generation: Kỹ Thuật Nền Tảng AI Chatbot - Giải pháp thay thế context window lớn bằng cách truy xuất thông tin liên quan từ external knowledge base.
• LLM Evaluation: Đánh Giá Chất Lượng Mô Hình Ngôn Ngữ Lớn - Cách đo lường performance thực tế của LLM với các context window khác nhau trong production.