Context engineering là gì? Bốn chiến lược quản lý cửa sổ ngữ cảnh

Thay vì chỉ viết prompt, bạn đang thiết kế toàn bộ hệ sinh thái dữ liệu nạp vào RAM cho mỗi bước xử lý. Nghiên cứu của Chroma (2025) trên 18 mô hình cho thấy hiệu suất giảm mạnh từ 95% xuống 60% khi vượt ngưỡng context nhất định — nạp thêm dữ liệu có thể khiến AI kém thông minh đi.

Context engineering là gì, và khác prompt engineering ra sao?

Context engineering là bước tiến hóa tất yếu khi bạn chuyển từ chatbot đơn giản sang các agent tự vận hành. Prompt engineering lo việc "hỏi thế nào", còn context engineering giải bài toán hệ thống: mô hình cần biết thông tin gì, ở định dạng nào và tại thời điểm nào để hành động chính xác. Mỗi token rác bạn nạp vào là một "khoản nợ" trừ thẳng vào khả năng suy luận của mô hình.

Nói gọn lại, prompt engineering chỉ là một tập con bên trong context engineering, lo riêng lớp chỉ thị đầu vào.

Context của một LLM gồm những thành phần nào?

Một cửa sổ ngữ cảnh hiện đại là cấu trúc phức hợp gồm bảy thành phần chính tranh nhau không gian:

• System instructions: luật chơi, persona và hướng dẫn kiểm soát luồng.
• User input: truy vấn trực tiếp từ người dùng.
• Conversation history: bộ nhớ ngắn hạn của phiên làm việc.
• Retrieved knowledge: dữ liệu lấy về từ RAG (tài liệu, API, cơ sở dữ liệu).
• Tool descriptions: định nghĩa schema của các công cụ mà agent được phép gọi.
• Tool outputs: kết quả trả về từ các công cụ đã thực thi.
• Agent state: kế hoạch, to-do list và ghi chú tạm thời.

Mọi thành phần này đều tiêu tốn "attention budget" (ngân sách chú ý). Vì mô hình có tài nguyên chú ý hữu hạn, nhồi quá nhiều thông tin không liên quan sẽ làm loãng sự tập trung vào các token quan trọng.

Vì sao context là tài nguyên hữu hạn, không phải càng nhiều càng tốt?

Hầu hết LLM hiện nay dựa trên kiến trúc Transformer với cơ chế attention có độ phức tạp n². Context tăng gấp đôi thì khối lượng tính toán tăng gấp bốn. Quan trọng hơn, sự chú ý không phân bổ đều, do cơ chế Rotary Position Embedding (RoPE) tạo ra hiệu ứng suy giảm (decay) khiến các token nằm xa điểm đầu và điểm cuối rơi vào "vùng chú ý thấp".

Hiện tượng "Lost in the Middle" cho thấy độ chính xác giảm hơn 30% khi thông tin quan trọng nằm ở giữa input. Bên cạnh đó là "context rot" (ngữ cảnh suy giảm): hiệu suất sụt giảm đột ngột và khó dự đoán khi input chạm một ngưỡng nhất định, dù vẫn nằm trong giới hạn lý thuyết. Bạn phải phân biệt "cửa sổ ngữ cảnh lý thuyết" (quảng cáo cả triệu token) với "cửa sổ ngữ cảnh hiệu dụng" (thường chỉ đạt 40–60% dung lượng lý thuyết) để agent hoạt động ổn định.

Những kiểu lỗi context thường gặp là gì?

Dựa trên nghiên cứu của Drew Breunig, có bốn chế độ lỗi (failure modes) chính:

Context poisoning (nhiễm độc)

Thông tin sai lệch hoặc lỗi suy luận (hallucination) lọt vào context rồi bị mô hình lặp lại, lấy làm căn cứ cho các bước sau, tạo ra sai lệch dây chuyền.

Context distraction (xao nhãng)

Thông tin thừa hoặc dữ liệu nhiễu kéo sự chú ý khỏi nhiệm vụ chính, khiến agent phản hồi hời hợt hoặc đi chệch mục tiêu.

Context confusion (nhầm lẫn)

Xảy ra khi có quá nhiều lựa chọn. Llama 3.1 8B chạy tốt với 19 công cụ nhưng thất bại hoàn toàn khi phải chọn giữa 46 công cụ, dù tổng token vẫn trong giới hạn.

Context clash (xung đột)

Thông tin mới mâu thuẫn với chỉ thị hệ thống hoặc dữ liệu cũ. Thiếu phân cấp ưu tiên (kiểu System Prompt đứng trên Knowledge), mô hình sẽ hành động không nhất quán.

Bốn chiến lược cốt lõi: Write, Select, Compress, Isolate

Khung chiến lược từ LangChain và Anthropic giúp bạn quản lý context một cách bài bản:

Write (ghi)

Lưu thông tin ra ngoài cửa sổ ngữ cảnh qua "scratchpads" hoặc file bền vững như CLAUDE.md. Ghi lại các kế hoạch trung gian là bắt buộc để khỏi mất mát khi context bị cắt cụt (truncation) ở ngưỡng 200k token.

Select (chọn)

Chỉ nạp những gì cần thiết. Dùng RAG không chỉ cho dữ liệu mà cho cả công cụ (RAG-MCP). Sau khi truy xuất, hãy áp dụng bước reranking (tái xếp hạng) để chỉ nạp các đoạn dữ liệu liên quan nhất vào context, giảm thiểu nhiễu.

Compress (nén)

Tóm tắt lịch sử hội thoại và cắt tỉa (trimming) các output công cụ dài dòng. Kỹ thuật "auto-compact" của Anthropic tự kích hoạt khi đạt 95% dung lượng để tóm tắt tiến trình, giữ lại các kết quả then chốt cùng vài file gần nhất.

Isolate (cô lập)

Chia nhỏ nhiệm vụ cho các sub-agent. Mỗi agent phụ làm việc trong một context sạch và chỉ trả kết quả cô đọng về cho agent chính. Chiến lược này tăng tới 90.2% hiệu suất trên các tác vụ nghiên cứu phức tạp so với việc dùng một agent duy nhất xử lý tất cả.

Làm sao đưa đúng thông tin vào đúng thời điểm?

Vì context là tài nguyên hữu hạn, bạn không nên nạp sẵn mọi thứ ngay từ đầu. Thay vì "loading upfront" (nạp trước toàn bộ tài liệu phòng khi cần), hãy dùng chiến lược "just-in-time" (chỉ nạp đúng thứ cần cho bước hiện tại). Cách triển khai cụ thể là "progressive disclosure" (tiết lộ dần dần): thay vì đọc trọn cả tài liệu, agent chỉ đọc lướt tiêu đề và tóm tắt trước, rồi mới quyết định gọi công cụ để đọc chi tiết đúng phần nó thực sự cần. Nhờ vậy, context luôn gọn và chỉ chứa thông tin liên quan đến việc đang làm.

Cốt lõi của just-in-time là agent không ôm sẵn toàn bộ dữ liệu trong context, mà chỉ giữ các tham chiếu nhẹ — đường dẫn file, câu truy vấn đã lưu, hay đường link — rồi dùng công cụ (tool) để nạp dữ liệu thật vào đúng lúc cần. Cách này phản chiếu đúng cách con người làm việc: ta không thuộc lòng cả kho tài liệu, mà dựa vào hệ thống file, hộp thư hay bookmark để lấy thông tin khi cần. Ngay cả siêu dữ liệu (metadata) cũng là tín hiệu để agent quyết định nên đọc gì: tên file gợi ý nội dung, kích thước gợi ý độ phức tạp, thời gian sửa đổi gợi ý mức độ liên quan, và cấu trúc thư mục cho biết vai trò — ví dụ test_utils.py nằm trong tests/ mang ý nghĩa khác hẳn khi cùng tên file đó nằm trong src/core_logic/.

Trên thực tế, chiến lược tốt nhất thường là kết hợp (hybrid): nạp sẵn phần cốt yếu để có tốc độ, rồi để phần còn lại nạp khi cần. Claude Code là ví dụ điển hình — nó nạp thẳng file CLAUDE.md vào context ngay từ đầu (vì đây là chỉ dẫn lúc nào cũng cần), nhưng lại dùng các công cụ như glob và grep để dò tìm và đọc các file khác đúng lúc, thay vì lập chỉ mục (index) sẵn cả dự án — vốn dễ lỗi thời và cồng kềnh.

Đổi lại, just-in-time không miễn phí: dò tìm lúc chạy (runtime) chậm hơn so với truy xuất dữ liệu đã chuẩn bị sẵn, và nó đòi hỏi bạn thiết kế công cụ cùng chỉ dẫn điều hướng đủ tốt. Thiếu điều đó, agent dễ lãng phí context vì dùng sai công cụ, đi vào ngõ cụt hoặc bỏ sót thông tin quan trọng. Vì vậy, hãy chọn điểm cân bằng theo đặc thù tác vụ: dữ liệu biến động liên tục thì nghiêng về just-in-time, còn dữ liệu ổn định thì nạp sẵn lại nhanh và đơn giản hơn.

Bên cạnh "khi nào" nạp, "cách trình bày" cũng quan trọng không kém. Định dạng có cấu trúc rõ ràng như XML tags (ví dụ <rules>, <context>) hoặc Markdown header giúp LLM phân biệt đâu là chỉ thị, đâu là dữ liệu tham khảo và đâu là lịch sử hội thoại. Ranh giới rõ ràng giúp mô hình dồn "vùng chú ý" vào đúng thành phần quan trọng, thay vì phải tự đoán mọi thứ nằm lẫn trong một khối văn bản.

Quản lý context cho tác vụ dài hơi như thế nào?

Với agent chạy nhiều giờ, bạn cần các kỹ thuật quản lý trạng thái bền vững:

• Agentic memory: yêu cầu agent liên tục cập nhật nhật ký tiến độ (progress.md) để theo dõi trạng thái nhiệm vụ.
• Frequent intentional compaction: chia quy trình thành các giai đoạn (Research → Planning → Implementation). Mỗi lần chuyển giai đoạn, reset context và chỉ mang theo tóm tắt (artifact) của giai đoạn trước.
• Tối ưu KV-cache: đặt các phần cố định — System instructions và Tool descriptions — ở ngay đầu context và giữ nguyên qua mỗi lượt gọi. Mô hình xử lý context tuần tự từ trái sang phải, nên nó có thể lưu lại (cache) kết quả tính toán cho đoạn đầu không đổi và tái sử dụng ở lượt sau thay vì tính lại từ đầu — đó là cơ chế prefix caching. Nhờ vậy, chi phí token đầu vào giảm tới 10 lần (ví dụ với Claude Sonnet) và phản hồi nhanh hơn hẳn. Ngược lại, chỉ cần một token ở đầu thay đổi là toàn bộ cache phía sau bị vô hiệu — nên hãy để những phần hay biến động ở cuối context.

Áp dụng vào thực tế: mô hình ACE và năm nguyên tắc khởi đầu

Mô hình ACE (Agentic Context Engineering) từ Stanford là điểm tham chiếu tốt nhất hiện nay. Nó chạy vòng lặp ba vai trò: Generator (thực hiện), Reflector (đánh giá) và Curator (tinh chỉnh playbook). Playbook tự tiến hóa sau mỗi lần thực thi, giúp tăng 10.6% hiệu suất benchmark agent và 8.6% trên các tác vụ tài chính mà không cần đổi mô hình.

Năm nguyên tắc cho Product Builder:

1. Ưu tiên tinh lọc hơn tích lũy: loại bỏ thông tin thừa còn quan trọng hơn nạp thêm dữ liệu.
2. Giữ context dưới 40% dung lượng lý thuyết để duy trì độ minh mẫn cao nhất.
3. Dùng agent nhỏ và chuyên biệt để cô lập ngữ cảnh.
4. Coi context là một sản phẩm: cần có SLA (Service Level Agreement — cam kết mức chất lượng) về độ tươi (freshness) và độ chính xác.
5. Luôn đặt chỉ thị quan trọng nhất ở đầu hoặc cuối input để tận dụng cấu trúc U-shape của attention.

Tài liệu tham khảo

• A Guide to Context Engineering for LLMs — ByteByteGo
• Context Engineering Clearly Explained (YouTube)
• Context Engineering for Agents (YouTube)
• Context Engineering for Product Builders: The 2026 Operating Manual — Karo Zieminski
• Context Is the New Code — Patrick Debois, Tessl (YouTube)
• Effective Context Engineering for AI Agents — Anthropic
• What Is Context Engineering? — IBM
• What Is Context Engineering? — System Design Newsletter