Team bạn vừa nâng lên Claude Opus 4.8 với 1M context. Quyết định đầu tiên: bỏ luôn tầng retrieval, nhét cả knowledge base 400k token vào system prompt cho "chắc ăn". Hai tuần sau, agent bắt đầu trả lời lạc đề, gọi nhầm tool, và hóa đơn API tăng gấp bốn. Model không hề yếu đi. Context bẩn đi.
Đây là cái bẫy lớn nhất của 2026. Claude Opus 4.8, Gemini 3.5, DeepSeek V4 đều đã cán mốc 1M token. Nhưng thống kê từ các team production vẫn chỉ ra: hơn 70% lỗi ứng dụng LLM đến từ context sai, thiếu, hoặc lộn xộn — không phải từ model. Tệ hơn, nghiên cứu của Anthropic cho thấy context vượt 100k token bắt đầu làm suy giảm chất lượng reasoning. Cửa sổ to hơn không có nghĩa là bạn nên lấp đầy nó.
Vì sao "nhét hết vào context" thất bại
Ba lý do, đều là vật lý chứ không phải ý kiến.
Lost-in-the-middle. Model chú ý mạnh nhất vào đầu và cuối context. Tài liệu quan trọng nằm ở token thứ 300k giữa một đống log? Xác suất bị bỏ qua rất cao. Đây là đặc tính của attention, không phải bug sẽ được vá.
Chi phí tuyến tính theo token. Mỗi turn, bạn trả tiền cho toàn bộ context — kể cả 350k token mà model không dùng đến. Agent chạy 50 turn với context 500k là một cách rất hiệu quả để đốt budget.
Reasoning suy giảm sau 100k. Model vẫn "đọc" được, nhưng khả năng suy luận nhiều bước trên đống context đó giảm rõ. Nghĩa là: retrieval vẫn cần, dù context 1M. Cửa sổ lớn để chứa lịch sử hội thoại dài và tài liệu thật sự liên quan — không phải để thay thế việc chọn lọc.
Tư duy đúng: context window là RAM, không phải ổ cứng. Không ai load cả ổ cứng vào RAM rồi hy vọng CPU tự tìm ra thứ cần thiết.
Bốn tầng của một hệ context tử tế
Context engineering không phải là viết prompt hay. Nó là kiến trúc bốn tầng quyết định cái gì được vào "RAM" tại mỗi thời điểm.
1. Knowledge retrieval. RAG chưa chết — nó đổi vai. Thay vì retrieve vì context nhỏ, giờ retrieve để giữ context sạch. Với domain có quan hệ phức tạp (sản phẩm – khách hàng – hợp đồng), GraphRAG cho kết quả tốt hơn hẳn vector search thuần; benchmark production giữa 2026 ghi nhận agentic RAG kết hợp knowledge graph giảm hallucination đáng kể, đổi lại orchestration phức tạp hơn.
2. Memory. Ngắn hạn là lịch sử phiên hiện tại. Dài hạn là những gì agent cần nhớ qua nhiều phiên: sở thích user, quyết định cũ, facts đã học. Hai loại này cần cơ chế khác nhau — trộn chung là công thức cho context phình.
3. Orchestration. Tầng quyết định cái gì vào context, thứ tự nào, định dạng nào. Cùng một dữ liệu, đưa vào dạng bảng markdown gọn thường ăn đứt việc dán nguyên JSON thô 5k token.
4. Tool loadout động. Đừng khai báo 80 tool cho mọi request. Chọn tool theo query — chỉ load 5-10 tool liên quan — cải thiện độ chính xác function-calling khoảng 44%. MCP registry giờ có cả chục nghìn server; kỷ luật chọn lọc quan trọng hơn bao giờ hết.
Kỹ thuật cắt tỉa cho agent chạy dài
Agent chạy 100+ turn sẽ tự làm bẩn context của chính nó nếu bạn không can thiệp. Ba kỹ thuật đã thành chuẩn:
Summarize-and-truncate. Giữ nguyên N turn gần nhất, nén phần cũ hơn thành summary. Điểm mấu chốt: summary phải giữ lại quyết định và ràng buộc, không phải diễn biến.
def compact_history(messages, keep_recent=10, budget=8_000):
old, recent = messages[:-keep_recent], messages[-keep_recent:]
if count_tokens(old) < budget:
return messages
summary = llm.summarize(
old,
instruction="Giữ: quyết định đã chốt, ràng buộc, ID/số liệu. Bỏ: diễn giải."
)
return [{"role": "system", "content": f"Tóm tắt trước đó:\n{summary}"}] + recent
Checkpointing state. LangGraph checkpoint toàn bộ state của graph sau mỗi bước. Agent crash ở turn 40? Resume từ checkpoint thay vì replay cả lịch sử — vừa rẻ vừa sạch.
Virtual context kiểu Letta. Ý tưởng mượn từ hệ điều hành: context window là "bộ nhớ chính", phần còn lại nằm ở "bộ nhớ ngoài" (external storage), và agent tự page in/out qua tool call khi cần. Agent tự quyết cái gì đáng giữ trong RAM — giống hệt cách OS quản lý virtual memory.
Memory dài hạn: khi nào cần framework, khi nào chỉ cần một bảng SQL
Đây là chỗ nhiều team over-engineer. So sánh nhanh:
| Giải pháp | Hợp khi | Không hợp khi |
|---|---|---|
Bảng user_preferences |
Facts có cấu trúc, ít, rõ schema (ngôn ngữ, timezone, tier) | Kiến thức phi cấu trúc, tự học |
| LangGraph checkpointing | State trong phiên, resume workflow, đã dùng LangGraph | Memory xuyên phiên, xuyên agent |
| Mem0 | Memory hội thoại xuyên phiên, tự extract facts từ chat | Cần kiểm soát chặt cái gì được nhớ |
| Letta | Agent chạy rất dài, tự quản lý memory, virtual context | Use case đơn giản, team nhỏ |
Quy tắc thô: nếu bạn liệt kê được trước những gì cần nhớ, dùng bảng SQL. Nếu agent phải tự học từ tương tác thứ nó cần nhớ, lúc đó mới đến Mem0 hay Letta. Rất nhiều "hệ thống memory" trong doanh nghiệp thực chất chỉ là 15 dòng preferences — và như thế là đủ.
Đo lường: token budget như một SLO
Cái gì không đo được thì sẽ phình. Hai metric đáng theo dõi từ ngày đầu:
- Token budget per-turn. Đặt ngưỡng (ví dụ 30k/turn) và alert khi vượt — đối xử với nó như latency SLO. Vượt budget thường là triệu chứng sớm của context rò rỉ: tool output không được cắt, history không được nén.
- Tỉ lệ context được dùng thật. Sample các response, kiểm tra bao nhiêu phần context thực sự đóng góp vào câu trả lời (LLM-as-judge làm việc này tốt). Nếu 80% context là ballast, retrieval của bạn đang hỏng — và bạn đang trả tiền cho sự hỏng đó mỗi request.
Đáng chú ý: khảo sát agent engineering 2026 cho thấy 89% team production đã có observability nhưng chỉ 52% có evals. Đo token mà không eval chất lượng thì mới đi được nửa đường.
Kết
Cuộc đua 1M token là cuộc đua của các lab. Cuộc đua của bạn khác: đưa đúng 20k token cần thiết vào đúng chỗ, đúng lúc. Model tốt nhất 2026 với context bẩn vẫn thua model thường với context sạch — và không có bản nâng cấp nào sắp tới thay đổi được điều đó, vì vấn đề không nằm ở model. Nó nằm ở kỷ luật của người đưa dữ liệu vào.
