📖 Bản tiếng Anh (English Edition)

← Chương trước: Bộ Prompt Standard tối thiểu cho team triển khai ngay (2026) | Mục lục Series | Chương tiếp theo: Phần 7 — Declarative Prompting với DSPy (2026) →

Answer-first: Context Engineering là kỹ thuật lắp ráp có hệ thống các nguồn thông tin động vào context window thay vì chỉ chỉnh sửa câu chữ tĩnh. Ba trụ cột cốt lõi gồm RAG lai phân đoạn, nạp công cụ động qua giao thức MCP và nén ngữ cảnh có kiểm soát, giải quyết triệt để suy giảm chú ý. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Bước chuyển lớn nhất 2026: Context quan trọng hơn câu chữ

Answer-first: Nếu bạn vẫn đang “chọn từ ngữ cẩn thận và hy vọng model hiểu ý”, bạn đang tối ưu ~100 token chỉ dẫn trong khi bỏ mặc ~100.000 token context quanh nó — bằng chứng đo được cho thấy chất lượng nằm ở phần còn lại. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Nếu bạn vẫn đang viết prompt bằng cách chọn từ ngữ cẩn thận và hy vọng model “hiểu ý,” bạn đang vận hành trên tư duy 2024.

Năm 2026, ngành đã thống nhất: chất lượng context bạn đưa vào quan trọng hơn nhiều so với cách diễn đạt câu lệnh. Anthropic định nghĩa chính thức: context engineering là “tập chiến lược tuyển chọn và duy trì tập token tối ưu trong quá trình suy luận của LLM” — vấn đề không phải viết hay hơn mà là curate tốt hơn.

Năm bằng chứng kết thúc tranh luận:

  1. Context rot: 18 model SOTA (GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — Chroma 7/2025) suy giảm đáng tin cậy theo độ dài input, kể cả task lặp lại một từ lặp 10.000 lần.
  2. U-shape attention: dữ liệu ở đầu và cuối context nhớ tốt hơn ở giữa — “even for explicitly long-context models” (Lost in the Middle, TACL 2023).
  3. Distractor amplification: chỉ 1 distractor đã giảm hiệu suất; 4 distractor cộng dồn và tăng theo độ dài input.
  4. Focused beats full: prompt tập trung ~300 token thắng prompt đầy ~113k token trên mọi model trong 18 model được đo (LongMemEval).
  5. Structure beats coherence: model làm bài tốt hơn trên haystack xáo trộn hơn có trật tự — cách chunk và delimiter quan trọng hơn mạch văn.

Mỗi phát hiện map về một control của context engineering: budget (rot), thứ tự (U-shape), lọc (distractor), retrieval (focused), chunking (structure).

Context Engineering là gì?

Answer-first: Context Engineering là kỹ năng thiết kế hệ thống lắp ráp đúng thông tin vào context window của model, đúng lúc — hệ thống, không phải câu chữ. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Thay vì:

"Bạn là chuyên gia tài chính. Phân tích báo cáo Q1."

hệ thống context engineering làm thế này:

[System Prompt: role, rules, output contract]
[Dữ liệu Q1 truy xuất động từ ERP API]
[So sánh quý trước từ data warehouse]
[Câu hỏi user: "Rủi ro chính trong Q1 là gì?"]   ← luôn cuối

Mỗi dấu ngoặc là một subsystem: prompt chuẩn (Part 2 của series này), retrieval, tool injection, và assembly — chứ không phải một chuỗi text dài hơn.

Đây là lý do chương này đứng sau chương kit: 8 khối của bạn không bị thay thế — nó là prefix ổn định mà mọi thứ khác lắp xung quanh.

Ba trụ cột của Context Engineering

Answer-first: RAG truy xuất đúng phần liên quan lúc query; MCP chuẩn hoá kết nối tool như “USB-C cho AI”; dynamic assembly quyết định thứ tự + ngân sách + pruning — ba trụ cột, mỗi cái giải một phía của “đúng thông tin, đúng lúc”. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

1. RAG (Retrieval-Augmented Generation)

RAG là cơ chế chính mà hệ thống production “prompt” model trong năm 2026. Thay vì nhồi kiến thức vào prompt, bạn lưu tài liệu trong vector database và chỉ truy xuất phần liên quan tại thời điểm query.

Vì sao cửa sổ 1M token không giết RAG: context rot cho thấy cửa sổ lớn giảm chi phí nạp dữ liệu nhưng không giải bài toán curation — 18 model vẫn sai theo độ dài, focused vẫn thắng full. RAG đánh cả hai pha: chất lượng (chỉ context liên quan) và chi phí (ít token input hơn).

Pipeline chuẩn 4 tầng của series: sparse+dense recall → cross-encoder rerank → AST-aware chunk selection → assembly vào Context block. Kiến trúc RAG doanh nghiệp đầy đủ nằm ở Series: Enterprise AI Data Pipeline & GraphRAG Architecture.

Và lưu ý bề mặt tấn công: tài liệu truy xuất là vector tiêm lệnh gián tiếp — RAG không có sanitization kế thừa đúng bề mặt tấn công OWASP LLM01. Corpus của bạn cần provenance: ai được ghi vào index, sanitization nào chạy lúc ingestion.

2. MCP (Model Context Protocol)

MCP là giao thức mở (Anthropic khởi xướng) chuẩn hoá cách agent kết nối với tool, database và hệ thống doanh nghiệp — USB-C cho AI agent: một giao thức, mọi công cụ. Hướng dẫn xây dựng đầy đủ tại Series: MCP Engineering In Production.

Ba con số đáng nhớ từ hệ sinh thái tool:

  • Tool schema chiếm ngân sách thật — thiết kế chuẩn xếp ~15% cửa sổ cho schemas, và schema phải lọc theo intent để không trả tiền cho tool không dùng
  • Response có enum format: 206 token (detailed) vs 72 token (concise) — “~⅓ of the tokens” mỗi call; Claude Code cap 25.000 token mặc định cho tool response
  • Ít tool semantic hơn nhiều tool wrap API: thay list_users + list_events + create_event bằng một schedule_event — “too many tools distract agents”

Từ phía bảo mật, MCP là giao thức có security model thực: confused-deputy qua static client IDs, cấm token passthrough, SSRF qua OAuth discovery trỏ vào internal IP, session hijacking qua shared queue — mỗi vector có mitigation ở mức spec. Tool Policy block của prompt chuẩn là bản mirror phía prompt của allowlist này: một policy, hai tầng thực thi.

3. Dynamic Context Assembly

Hệ thống quyết định inject gì dựa trên bốn biến runtime: query hiện tại, trạng thái agent, tool đã gọi, working memory. Assembly là compiler làm hai trụ cột còn lại trở nên rẻ: RAG cung cấp ứng viên, MCP cung cấp schema, budget cắt cả hai đúng phần query xứng đáng.

Kỷ luật ngân sách token hoạt động như phân bổ RAM của OS — một thiết kế tham khảo cho cửa sổ 128k:

+----------------------------------------------------------------------+
| Identity & Policy (static, cache)  | Tools (schema, on-demand)       |
| 5% + 10% ≈ 19.2k tokens           | 15% ≈ 19.2k tokens             |
+------------------------------------+---------------------------------+
| RAG retrieval (reranked)           | History (compacted) | Query     |
| 40% ≈ 51.2k                        | 20% ≈ 25.6k         | 10%      |
+------------------------------------+---------------------+----------+

(Phần trăm là thiết kế tham khảo của series, không phải số vendor — điều chỉnh theo workload của bạn.)

Và dòng chảy lắp ráp vận hành như sau:

graph LR
    R["RAG retrieval<br/>(reranked, provenance-tagged)"] --> B["Token Budget<br/>& Pruning"]
    M["MCP tool schemas<br/>(intent-filtered)"] --> B
    H["Working memory<br/>(compacted history)"] --> B
    Q["Query hiện tại<br/>(volatile)"] --> B
    B --> P["Prefix ổn định<br/>(identity + policy + tools)"]
    P --> C[("KV cache<br/>read 0.1× / write 1.25×")]
    P --> T["Context stream<br/>đi tới model"]

    style C fill:#e8f8e8,stroke:#2a7da0
    style T fill:#e8f4f8,stroke:#2a7da0

Điểm nhấn cache: đặt cache_control tại seam cuối của phần ổn định; mọi thứ thay đổi từng request (timestamp, user input) bắt buộc nằm sau seam. Đặt breakpoint trên block hay đổi là trả tiền write 1.25× mỗi call mà không bao giờ hit — anti-pattern được ghi chép chính thức trong docs của Anthropic.

So sánh cách làm cũ và mới

Answer-first: Bốn chiều dịch chuyển: mục tiêu (prompt hoàn hảo → hệ thống context đáng tin), nguồn context (hardcode → truy xuất động), output (tự do → schema), bảo trì (sửa tùy hứng → version + monitor) — và metrics đi theo từ “trông ổn” sang cache hit rate, token spend, retrieval precision. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Hai pipeline cạnh nhau cho thấy sự chuyển dịch là thay đổi kiến trúc, không phải thay đổi văn phong:

graph TD
    subgraph Old ["2024 — Prompt-centric"]
        A["Files / Docs thô"] --> B["Copy hết vào prompt"]
        C["Chat history đầy đủ"] --> B
        B --> D["LLM call<br/>(re-tokenize toàn bộ mỗi lượt)"]
    end

    subgraph New ["2026 — Context-engine-centric"]
        E["Intent classifier"] --> F["Chọn tool schema theo intent"]
        G["RAG hybrid<br/>(sparse+dense → rerank)"] --> H["Token budget & pruning"]
        F --> H
        I["Memory compaction<br/>(tóm lược, trượt cửa sổ)"] --> H
        J["Prefix ổn định<br/>(identity + policy)"] --> K[("KV cache<br/>read 0.1×")]
        K --> H
        H --> L["LLM call<br/>(chỉ phần volatile tokenize mới)"]
    end

    Old -. "chuyển dịch" .-> New

    style D fill:#f8e8e8,stroke:#a02a2a
    style L fill:#e8f8e8,stroke:#2a7da0
ChiềuCách cũ (2024)Cách mới (2026)
Mục tiêu chính“Viết prompt hoàn hảo”“Xây hệ thống context đáng tin”
Nguồn contextHardcode trong promptTruy xuất động (RAG/MCP)
OutputTự do / hội thoạiTuân theo schema
Bảo trìSửa tùy hứngVersion-controlled và monitor
MetricsChủ quan (“mượt hơn”)Cache hit rate, token/task, retrieval precision
Bảo mậtCầu kỳ trong văn bảnDelimiter + dual-LLM + fail-closed

Và danh sách kiểm tra của người thực hành đổi theo: 2024 hỏi “câu này nghe có thuyết phục không?”; 2026 hỏi “cái gì được truy xuất, cái gì bị cắt, theo thứ tự nào, ngân sách bao nhiêu, nguồn gốc đâu”.

Nếu bạn làm kế toán, hãy hiểu context engineering theo cách này

Answer-first: Bạn đã chạy context engineering mỗi kỳ đối soát: rút đúng hồ sơ của đúng kỳ (RAG), dùng đúng biểu mẫu chuẩn liên phòng ban (MCP), giữ bàn làm việc chỉ có tài liệu của việc đang làm (assembly) — discipline chưa có tên, giờ có. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

  • RAG = rút hồ sơ: không ai vác cả két sổ lưu trữ 10 năm lên bàn; chỉ rút hồ sơ của kỳ đang đối soát.
  • MCP = biểu mẫu liên phòng ban: không ai chép lại sổ cái vào email rồi hỏi kế toán trưởng; người ta tham chiếu mã tài khoản. MCP là hệ thống mã tham chiếu cho AI.
  • Assembly = bàn làm việc có tổ chức: đúng tài liệu, đúng lúc, đúng lượng — quản lý vốn lưu động cho token.
  • Provenance = chứng từ: tài chính đòi mỗi con số truy được về chứng từ; context engineering đòi mỗi token truy được về nguồn (provenance tags). Không truy được = fail audit ở cả hai thế giới.
  • Budget = materiality: không phải con số nào cũng vào báo cáo, chỉ con số trọng yếu — cửa sổ 128k buộc cùng một bài phân loại.

Câu dịch một dòng cho toàn bộ sự chuyển dịch: cải thiện chất lượng câu trả lời AI = cải thiện hồ sơ mà nó nhận được, không phải cầu kỳ hơn trong cách hỏi.

Production failure: “model đột nhiên ngu” sau ba tháng chạy ổn

Answer-first: Mode thất bại kinh điển của hệ context: prompt không đổi nhưng output xấu dần — vì corpus RAG mở rộng (distractor tăng), tài liệu nhúng cũ hơn schema, và prompt không có ai cache-align. Không đo là không biết: mọi triệu chứng này đều thấy được qua usage fields và retrieval precision. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Scenario: chatbot nội bộ chạy ngon 3 tháng. Rồi output bắt đầu nhại tài liệu lỗi thời, bỏ sót hồ sơ mới, và hóa đơn token tăng 40%. Prompt không đổi — nhưng ba thứ khác đã đổi: corpus tăng từ 500 lên 5.000 tài liệu (distractor amplification bắn đúng điểm yếu), index stale so với hệ nguồn, và mọi turn vẫn tokenize lại toàn bộ vì prefix hay đổi (timestamp chèn nhầm vào system).

Chẩn đoán theo ba câu hỏi:

  1. Retrieval precision có gãy không? — chạy lại eval trên corpus mới; reranker cần tune lại theo độ tương đồng của dữ liệu mới
  2. Dữ liệu có truy được nguồn không? — provenance tag cho thấy hồ sơ cũ hơn bao nhiêu so với bản gốc
  3. Cache có hit không? — cache_read_input_tokens = 0 lặp lại nghĩa là prefix đang bị invalidate mỗi call

Bài học: hệ context cần eval và giám sát như code cần test — corpus, index, và cache hit đều là bề mặt thay đổi, prompt chỉ là một trong bốn biến.

Ý chính cần nhớ

Answer-first: Cách nhanh nhất để cải thiện chất lượng agent thường không phải viết lại prompt — mà là cải thiện chất lượng và sự liên quan của context được inject; 8 khối của bạn là prefix ổn định, ba trụ cột là hệ thống quanh nó. Điều kiện tiên quyết: Hiểu rõ giới hạn context window, hiện tượng Lost in the Middle, và nguyên lý hoạt động của vector embeddings.

Cách nhanh nhất để cải thiện chất lượng agent thường không phải viết lại prompt. Mà là cải thiện chất lượng và sự liên quan của context được inject vào.

Ba đòn bẩy chi phí xếp theo cường độ (tất cả assembly-time, không cái nào wording-time): căn chỉnh cache (prefix ổn định đọc 0.1× thay vì 1.0×), cap response tool (206→72 token), pruning retrieval. Ba đòn bẩy chất lượng: đặt query cuối (+30%), grounding bằng quote trước khi trả lời, sub-agent cách ly cho task dài.

Chương này là cổng sang Track 2: ba trụ cột sẽ được đào sâu trong các bản tiếng Anh — hybrid RAG, MCP engineering, budget và cache mechanics — với code production.

Chương tiếp theo: Phần 7 — Declarative Prompting với DSPy — khi việc “chọn từ ngữ” được giao cho compiler.

🔗 Đọc thêm các chuyên đề liên quan:

❓ Câu Hỏi Thường Gặp (FAQ)

Model 2026 có context window 1 triệu token rồi — context engineering còn cần thiết gì?

Vẫn cần, và bằng chứng đo trực tiếp: nghiên cứu context rot (Chroma 7/2025) trên GPT-4.1, Claude 4, Gemini 2.5, Qwen3 cho thấy hiệu suất suy giảm phi tuyến theo độ dài input kể cả task trivial, dữ liệu giữa context bị lãng quên (Lost in the Middle, TACL 2023), và prompt tập trung ~300 token thắng prompt đầy ~113k token trên mọi model. Cửa sổ lớn giải bài toán chứa dữ liệu, không giải bài toán attention, chi phí, hay độ chính xác — ba bài context engineering tồn tại để giải.

Ba trụ cột này với team nhỏ nên bắt đầu từ đâu?

Theo thứ tự giá/độ phức tạp tăng dần: (1) assembly thủ công — sắp xếp context theo prefix ổn định → data → query cuối, không cần hạ tầng, thu ngay dividend +30% placement; (2) con trỏ JIT — context giữ path/tham chiếu thay vì copy toàn bộ tài liệu, load khi cần; (3) RAG/MCP chỉ khi corpus lớn hoặc tool thật sự tồn tại. Sai lầm phổ biến là mua hạ tầng vector DB trước khi cần — năm tài liệu không cần retrieval, chỉ cần mục lục.

Căn chỉnh KV cache có đáng công sức không, hay chỉ là tối ưu vi mô?

Đáng — vì nó là đòn bẩy chi phí lớn nhất. Cache read trả 0.1× giá input thường (write 1.25× cho lần đầu, TTL 5 phút, refresh miễn phí khi dùng); prefix ổn định tái sử dụng ~10 lần thì chi phí prefix giảm ~90% so với không cache. Hai điều kiện: prompt đủ ngưỡng cache tối thiểu (512–4.096 token tùy model) và prefix byte-identical giữa các lần gọi. Theo dõi qua usage fields: cache_creation_input_tokens và cache_read_input_tokens — hai con số này là dashboard vận hành của context stack.

📚 Nguồn nghiên cứu (verification anchors)

ClaimNguồn
Định nghĩa context engineering; attention budget; JIT loading; sub-agent; hybrid boundaryAnthropic, “Effective context engineering for AI agents” (9/2025)
18 model rot; distractor; focused-beats-full; abstentionChroma, “Context Rot” (7/2025)
U-shape đầu/cuối > giữaLiu et al., “Lost in the Middle” (TACL 2023) — arxiv.org/abs/2307.03172
Query cuối +30%; provenance tags; grounding quotes; cache 0.1×/1.25×/breakpointsAnthropic, Prompting best practices + Prompt Caching (platform.claude.com/docs)
206→72 token; 25K cap; consolidate toolsAnthropic, “Writing effective tools for agents” (9/2025)
MCP security model (confused deputy, SSRF, session)MCP Spec, Security Best Practices — modelcontextprotocol.io

Bản nghiên cứu đầy đủ 100 rounds: reports/research-prompt-standard-part-6-context-engineering-100-rounds.{md,json} (dossier nội bộ series, mirror cả 2 repo). Ghi chú grounding: 60/100 rounds có URL nguồn bên ngoài; 37/100 truy vết series-internal; 3 rounds gắn nhãn [INFERENCE]/[VERIFICATION-NOTE]. Ghi chú hiệu chỉnh: con số “tiết kiệm 70% chi phí token” ở bản cũ đã được thay bằng các số verified (0.1× cache reads, 206→72) — không có nguồn sơ cấp nào cho 70%.

← Chương trước: Bộ Prompt Standard tối thiểu cho team triển khai ngay (2026) | Mục lục Series | Chương tiếp theo: Phần 7 — Declarative Prompting với DSPy (2026) →