Tối ưu Context Window: Chiến lược khi token có hạn

Định nghĩa

Context Window Optimization là kỹ thuật phân bổ tài nguyên token có hạn một cách chiến lược — không chỉ để "nhét vừa" dữ liệu vào Context Window, mà để đảm bảo AI xử lý được thông tin quan trọng nhất với độ chính xác cao nhất, tránh hiện tượng "Lost in the Middle" khi thông tin bị chìm giữa biển token.

Giải thích chi tiết

Vấn đề: Hiện tượng "Lost in the Middle"

Khi bạn nhồi nhét quá nhiều thông tin vào Context Window — ví dụ đưa cả codebase 50 file hay tài liệu 200 trang vào Prompt — AI không trở nên thông minh hơn. Thay vào đó, nó mắc chứng "Lost in the Middle": thông tin ở đầu và cuối được nhớ rõ, nhưng nội dung chính giữa đoạn bị "ngộp" và bỏ quên.

Thí nghiệm thực tế với Claude 3.5 Sonnet cho thấy: khi đưa 40k token liên tục để trả lời câu hỏi nằm ở giữa đoạn văn, độ chính xác giảm 35-40% so với khi thông tin nằm ở hai đầu. Đây chính là primacy/recency bias trong thế giới LLM.

Chiến lược 1: Token Budgeting (Ngân sách token)

Đừng bao giờ dùng 100% Context Window cho dữ liệu thô. Hãy chia ngân sách như quản lý RAM:

Nếu bạn để sát cửa 128k/128k, model sẽ không còn "chỗ" để suy nghĩ (Chain of Thought) hay trả lời dài. Kết quả: câu trả lời bị cắt ngang (truncated output) hoặc suy luận nông cạn.

Chiến lược 2: Hierarchical Grounding (Phân cấp thông tin)

Thay vì dump toàn bộ 500 trang tài liệu, hãy xây dựng cấu trúc phân cấp:

Layer 1 - Metadata & Map (500 tokens):

Tài liệu: Hợp đồng dịch vụ phần mềm 2024
Cấu trúc: 12 chương, 200 trang
Mục quan trọng: Chương 5 (Bảo mật), Chương 8 (Thanh toán)
Từ khóa risk: "phạt vi phạm", "chấm dứt hợp đồng", "IP rights"

Layer 2 - Executive Summary (800 tokens): Tóm tắt 10 điểm chính của toàn bộ tài liệu.

Layer 3 - Detailed Sections (2000-4000 tokens): Chỉ đưa full-text của các section liên quan đến câu hỏi cụ thể.

Tổng: ~3-5k tokens thay vì 80k tokens. AI không đọc tất cả, nhưng AI biết tìm đâu khi cần chi tiết — giống như con người dùng mục lục để tra cứu.

Chiến lược 3: Sliding Window với Memory Snapshot

Trong conversation dài (25+ turns), đừng giữ nguyên văn bản tất cả các lượt trao đổi cũ:

• Recent Buffer: 5 turns gần nhất giữ nguyên văn (~2.5k tokens)
• Compressed Memory: Các turns 6-20 được nén thành "snapshot" mô tả những gì đã quyết định/thỏa thuận (~800 tokens)
• Archived: Turns trước đó được loại bỏ hoàn toàn nhưng đã lưu vào vector database nếu cần retrieve sau.

Tổng sử dụng: ~3.3k tokens thay vì 25k tokens cho 25 lượt trao đổi, đảm bảo conversation không bị "đơ" khi gần chạm giới hạn.

Ví dụ thực tế

Phân tích codebase 20.000 file

Before (Thiếu tối ưu): Developer paste danh sách 50 file quan trọng (30k tokens) vào Context Window. AI trả lời sai về dependency vì bỏ quên file nằm ở giữa danh sách (file thứ 25-30).

After (Tối ưu chiến lược):

1. Selection: Chọn 10 file trực tiếp liên quan đến tính năng đang debug (8k tokens)
2. Compression: 20 file liên quan gián tiếp chỉ đưa interface definition (header/function signature) thay vì full implementation (4k tokens)
3. Ordering: Sắp xếp theo dependency graph — file gốc (root) lên đầu, leaf modules xuống cuối
4. Budget: Giữ lại 10k tokens cho AI suy luận và đề xuất code fix

Kết quả: 12k tokens sử dụng, độ chính xác tìm kiếm lỗi tăng 60%, thời gian phản hồi giảm 40%.

Review hợp đồng 200 trang trong 32k Context Window

Thách thức: Tài liệu 80k tokens, window chỉ 32k.

Giải pháp Hierarchical:

• Layer 1: Tóm tắt AI-generated của 200 trang (1k tokens, compression ratio 80:1)
• Layer 2: Trích xuất 10 điều khoản rủi ro cao bằng keyword search (5k tokens)
• Layer 3: Full-text chỉ của điều khoản được yêu cầu review (ví dụ: "Kiểm tra điều 5.2 về bảo mật dữ liệu")

Khi luật sư hỏi: "Điều khoản phạt vi phạm ở đâu?" — AI tra vào Layer 2, xác định ở Chương 8, sau đó retrieve full-text từ source (nếu cần) thay vì đọc cả 200 trang.

Multi-Agent Workflow (Agent A → Agent B)

Scenario: Agent A phân tích dữ liệu sales và tạo báo cáo 10k tokens. Agent B chỉ có Context Window 16k, phải xử lý cả báo cáo này kèm lịch sử trao đổi.

Tối ưu Inter-Agent Communication:

• Agent A output không phải plain text, mà là structured JSON:

  • summary: Tóm tắt 500 tokens
  • key_metrics: Bảng số liệu 300 tokens
  • detailed_analysis: Phân tích chi tiết (9500 tokens, optional)
  • recommendations: 700 tokens

• Agent B chỉ nhận summary + key_metrics + recommendations (1.5k tokens), giữ lại 14k cho reasoning và tool use.

Lợi ích: Communication overhead giảm từ 10k xuống 1.5k, cho phép pipeline multi-agent chạy sâu hơn 6-7 lớp mà không bị "nghẹt" token.

Ứng dụng

Sinh viên nghiên cứu: Khi cần AI phân tích 10 bài báo khoa học dài (mỗi bài 20 trang), thay vì paste PDF đầy đủ, hãy tạo "Literature Map": bảng tóm tắt 500 từ/bài + chỉ đưa full-text đoạn quote cụ thể khi hỏi sâu. Tiết kiệm token, tăng độ chính xác trích dẫn.

Người đi làm (Product/Data): Phân tích log hệ thống 50.000 dòng. Đừng đưa cả file log. Hãy dùng regex extraction + sampling: đưa 200 dòng error điển hình + 100 dòng normal + statistical summary (mean, p99, error rate). Pattern recognition của AI trên sample này thường chính xác hơn đọc cả 50k dòng bị trôi nổi.

Doanh nghiệp (RAG Systems): Trong hệ thống RAG (Retrieval-Augmented Generation), đừng retrieve 10 documents đầy đủ (20k tokens). Hãy retrieve 10 documents nhưng chỉ đưa "snippet" liên quan (2-3 đoạn/document, ~3k tokens) kèm metadata. Đây là cách đơn giản nhất để tối ưu Context Window mà không cần re-ranking phức tạp.

So sánh

Kết luận: Naive truncation là anti-pattern — bạn không chỉ mất dữ liệu, mà còn mất ngữ cảnh quan trọng. Context Window Optimization đòi hỏi tư duy "allocation" như lập trình viên quản lý memory: bạn phải biết cái gì cần nằm trong RAM (context), cái gì nằm trong disk (retrieve on-demand), và cái gì bị garbage collect (loại bỏ).

Bài viết liên quan

Cùng cụm

Đọc tiếp