Context engineering vs prompt engineering

Trong kiến trúc hệ thống AI hiện đại, sự khác biệt giữa context engineering vs prompt engineering chính là ranh giới giữa một bản demo ấn tượng và một hệ thống production tin cậy. Prompt engineering tập trung vào việc tinh chỉnh câu lệnh (tĩnh), trong khi context engineering là kỷ luật kỹ thuật thiết kế toàn bộ môi trường thông tin (động) mà mô hình tiếp nhận tại thời điểm suy luận (inference).

Hãy xem xét một lỗi hệ thống điển hình: bạn xây dựng một AI travel agent. Người dùng yêu cầu "Đặt khách sạn ở Paris cho hội thảo DevOps". Một prompt được thiết kế tinh xảo với kỹ thuật gán vai trò chuyên gia vẫn có thể tự tin đặt phòng tại Best Western Paris Inn ở Paris, Kentucky (Mỹ) thay vì Paris, Pháp. Đây không phải lỗi hành văn; đây là một lỗi kiến trúc (architecture failure). Hệ thống thất bại vì không nạp được dữ liệu thực tế về vị trí người dùng, lịch trình hội thảo và chính sách công ty vào cửa sổ ngữ cảnh. Để giải quyết, chúng ta không cần prompt tốt hơn, chúng ta cần context engineering.

Prompt engineering là gì?

Prompt engineering là nghệ thuật điều hướng hành vi của mô hình ngôn ngữ lớn (Large Language Model - LLM) thông qua việc tinh chỉnh script đầu vào. Nếu LLM là một diễn viên tài năng nhưng thiếu trí nhớ dài hạn, prompt chính là kịch bản bạn đưa cho họ ngay trước khi bức màn sân khấu kéo lên.

Các kỹ thuật cốt lõi bao gồm:

• Role Assignment: gán persona (ví dụ "Bạn là Senior Security Engineer") để định hướng bộ từ vựng và tư duy logic.
• Few-Shot Examples: cung cấp các cặp input/output mẫu để mô hình học định dạng (như JSON) và phong cách phản hồi.
• Chain of Thought (CoT): ép mô hình "suy nghĩ từng bước" để giải quyết các bài toán logic phức tạp, giảm thiểu lỗi nhảy vọt đến kết luận sai.
• Constraint Setting: thiết lập rào cản kỹ thuật như giới hạn số chữ hoặc bắt buộc dùng một thư viện lập trình cụ thể.

Hạn chế nằm ở chính bản chất "tĩnh" của nó. Prompt engineering hoạt động tốt trong các tác vụ single-turn (truy vấn đơn lẻ), nhưng sẽ sụp đổ trong môi trường production thực tế vì thiếu khả năng truy cập dữ liệu thời gian thực và không thể tự thích ứng khi quy trình nghiệp vụ thay đổi. Nếu muốn đào sâu lớp chỉ dẫn này, xem thêm hướng dẫn prompt engineering cho lập trình viên.

Context engineering là gì?

Context engineering là quá trình lập trình để lắp ghép "Context Package" – toàn bộ các token mà mô hình ngôn ngữ lớn (LLM) nhìn thấy tại thời điểm suy luận (inference). Theo Andrej Karpathy, hãy coi LLM là CPU và cửa sổ ngữ cảnh (context window) là RAM. Context engineering chính là nhiệm vụ của hệ điều hành: nạp đúng dữ liệu vào RAM để CPU xử lý hiệu quả nhất.

Thay vì dựa vào một kịch bản cố định, hệ thống context engineering dùng một Orchestrator Loop (vòng lặp điều phối) để thu thập dữ liệu từ nhiều nguồn: lịch sử trò chuyện, dữ liệu từ RAG, trạng thái workflow và kết quả trả về từ API. Kết quả là một Runtime Prompt được cá nhân hóa và chính xác cho từng lượt truy vấn của người dùng. Đây là bước tiến hóa tự nhiên từ context engineering ở cấp hệ thống khi bạn chuyển từ chatbot đơn giản sang agent tự vận hành.

Khác biệt cốt lõi: câu lệnh vs hệ thống

Về quan hệ tập con: prompt engineering thực chất nằm bên trong chiếc container mà context engineering xây dựng. Bạn có thể có một prompt cực hay, nhưng nếu hệ thống nạp vào 10.000 token dữ liệu nhiễu, các chỉ dẫn quan trọng nhất sẽ bị vùi lấp (hiện tượng Lost-in-the-Middle).

Bốn trụ cột của context engineering

1. Memory Management (Quản lý bộ nhớ)

Việc tống toàn bộ lịch sử trò chuyện vào ngữ cảnh là một sai lầm tốn kém.

• Short-term memory: dùng cửa sổ trượt (rolling window) để giữ lại vài lượt hội thoại gần nhất nhằm duy trì mạch lạc.
• Long-term memory: dùng cơ sở dữ liệu vector (Vector Database) để lưu trữ các sự kiện quan trọng (như sở thích khách sạn của người dùng). Tại thời điểm suy luận, hệ thống chỉ truy xuất các "fact" liên quan thay vì toàn bộ lịch sử thô.

2. RAG (Retrieval Augmented Generation)

RAG là cầu nối tới "ground truth" (dữ liệu gốc đáng tin). Một hệ thống RAG chuẩn Senior Architect không chỉ là vector search đơn thuần. Nó cần:

• Hybrid Search: kết hợp BM25 (từ khóa) và Semantic Search (ngữ nghĩa) để đảm bảo không bỏ lỡ các thuật ngữ chuyên môn.
• Reranking: sau khi lấy ra các đoạn văn bản (chunks), cần một mô hình thứ cấp xếp hạng độ liên quan trước khi nạp vào context, tránh làm loãng sự tập trung của LLM.

3. State Management (Quản lý trạng thái)

AI agent trong production là một máy trạng thái (state machine). Hệ thống phải theo dõi agent đang ở bước nào (Tìm kiếm → Đề xuất → Xác nhận → Đặt chỗ). Trạng thái này thường được truyền vào dưới dạng một JSON object trong system message để đảm bảo tính nhất quán của quy trình nghiệp vụ.

4. Tool Access (Function Calling)

Hệ thống thiết kế các JSON Schema để hướng dẫn LLM cách tương tác với thế giới thực. Ví dụ một function schema để định vị hội thảo:

{
  "name": "search_conference_location",
  "description": "Truy xuất tọa độ và thành phố chính xác của hội thảo dựa trên tên và năm",
  "parameters": {
    "type": "object",
    "properties": {
      "name": { "type": "string", "example": "DevOps Conference" },
      "year": { "type": "integer", "example": 2025 }
    },
    "required": ["name", "year"]
  }
}

Runtime Prompt: khi kiến trúc thành hình

Trong một hệ thống được thiết kế tốt, những gì LLM thực sự nhận được (Runtime Prompt) sẽ trông giống như thế này:

[System Instruction] Bạn là AI Travel Assistant. Ưu tiên khách sạn Marriott, ngân sách <200€/đêm.
[Current State] Phase: Hotel_Selection; Satisfied_Constraints: [Location_Verified, Date_Confirmed].
[RAG Context] Hội thảo DevOps 2025 diễn ra tại Paris, Pháp. Chính sách công ty: Yêu cầu wifi tốc độ cao.
[Tool Output] Kết quả từ Google Maps API: Paris, France.
[User Query] "Đặt phòng cho tôi."

Sự kết hợp này loại bỏ hoàn toàn khả năng mô hình đặt phòng nhầm tại Kentucky, nhờ dữ liệu thực tế từ Tool và RAG.

Đánh đổi: token, độ trễ và Context Rot

Mọi token nạp vào đều có giá của nó.

1. Chi phí và TTFT: ngữ cảnh càng dày, chi phí càng tăng (khoảng $10/triệu token) và độ trễ Time to First Token (TTFT) càng lớn do ảnh hưởng đến KV Cache.
2. Context Rot (sự thối rữa ngữ cảnh):
   • Context Poisoning: một ảo giác (hallucination) ở lượt chat thứ 2 có thể làm lệch hướng toàn bộ các suy luận ở lượt thứ 10.
   • Context Distraction: quá nhiều thông tin RAG không liên quan khiến mô hình mất tập trung vào chỉ dẫn cốt lõi.
3. Chiến lược ưu tiên (Pruning): khi cửa sổ ngữ cảnh đầy, bạn phải cắt bỏ dữ liệu theo thứ tự:
   • Giữ lại (Priority 1): System Instructions & Current State.
   • Trung gian (Priority 2): Tool Outputs & RAG facts quan trọng.
   • Cắt bỏ (Priority 3): Few-shot examples & lịch sử trò chuyện cũ.

Khi nào dùng prompt, khi nào cần context engineering?

Prompt engineering phù hợp cho các tác vụ sáng tạo một lần, viết lách, hoặc làm mockup nhanh (PoC). Nếu bài toán không cần dữ liệu động, đừng làm phức tạp hóa hệ thống.

Context engineering là bắt buộc cho hệ thống production, agent tự hành (Autonomous Agents), và các ứng dụng doanh nghiệp yêu cầu sự chính xác tuyệt đối cùng khả năng mở rộng. Đây là lằn ranh giữa một prototype chạy được và một sản phẩm mà lượt trả lời thứ 1.000 vẫn chính xác như lượt đầu tiên.

Các câu hỏi thường gặp

RAG có thay thế được prompt engineering không? Không. RAG cung cấp "nguyên liệu" (dữ liệu), còn prompt engineering cung cấp "công thức" (cách xử lý dữ liệu đó). Bạn cần cả hai để có một hệ thống hoàn chỉnh.

Tại sao context engineering tốn kém hơn? Nó yêu cầu chi phí hạ tầng (Vector DB, API pipeline) và chi phí token cho dữ liệu động nạp vào mỗi lần inference. Bù lại, context engineering giảm mạnh chi phí khắc phục lỗi do mô hình ảo giác.

Làm sao để xử lý hiện tượng context rot? Hãy thực hiện "Garbage Collection" cho ngữ cảnh: định kỳ tóm tắt lịch sử, xóa bỏ thông tin thừa, và chỉ giữ lại trạng thái (state) quan trọng nhất trước khi bắt đầu lượt inference mới.

Tài liệu tham khảo

• Context Engineering vs. Prompt Engineering: Smarter AI with RAG & Agents
• Context Engineering vs Prompt Engineering — Data Science in Your Pocket
• Context Engineering vs Prompt Engineering — System Design Newsletter
• Context Engineering: Bringing Engineering Discipline to Prompts — Addy Osmani
• Context engineering vs. prompt engineering — Elasticsearch Labs