【Mới nhất 2025】Context Engineering là gì?

Giới thiệu: Vượt qua Prompt Engineering

Xin chào mọi người! Khi còn là một lập trình viên mới, tôi đã từng nhập "Hãy nói điều gì đó thú vị" vào mô hình AI và phản ứng với kết quả nhận được. Nhưng hiện nay, cuộc đối thoại với AI đã phát triển từ một "trò chơi" đơn giản thành một "phương pháp phát triển chính thức".

Sau khi Vibe Coding trở nên phổ biến, lần này Andrej Karpathy đã tạo ra một thuật ngữ mới - "Context Engineering".

Trong tiếng Việt, nó được gọi là "Kỹ thuật ngữ cảnh", và hiện đang nhận được sự chú ý nóng bỏng từ các nhà phát triển AI. Karpathy đã không ngần ngại nói rằng:

"Context Engineering là nghệ thuật và khoa học thiết kế tinh tế cửa sổ ngữ cảnh"

Karpathy được biết đến như một bậc thầy trong lĩnh vực AI, và là người có khả năng định nghĩa các xu hướng công nghệ phức tạp bằng ngôn ngữ dễ hiểu đối với trực giác của nhà phát triển. "Software 2.0", "Software 3.0", "Vibe Coding", và gần đây nhất là "Bacterial Programming" - các khái niệm do ông đề xuất hầu như luôn trở thành chủ đề thảo luận trong ngành.

Về điều này, chính Karpathy đã trả lời:

"Haha, tôi không phát minh ra thuật ngữ mới đâu. Tôi chỉ nghĩ rằng mọi người đang đơn giản hóa khái niệm 'prompt' quá mức, dẫn đến việc đánh giá thấp sự phức tạp của nó"

Thực ra, "Context Engineering" không phải là một khái niệm hoàn toàn mới. Đây là sự đồng thuận dần hình thành trong ngành cùng với làn sóng AI Agent (tác nhân AI) năm 2025.

Theo hiểu biết của tôi, đây vẫn là một khái niệm "đang thịnh hành" nhưng "định nghĩa còn mơ hồ". Tuy nhiên, rõ ràng nó sẽ trở thành một kỹ năng quan trọng không thể tránh khỏi trong phát triển AI trong tương lai.

Sự khác biệt giữa Prompt Engineering và Context Engineering

Khi nghe từ "prompt", nhiều người sẽ nghĩ đến việc đưa ra chỉ dẫn đơn giản cho ChatGPT như "Hãy giải thích cơ học lượng tử". Ngay cả với các prompt phức tạp hơn, việc thêm mô tả công việc, đưa ra ví dụ, hoặc định nghĩa quy tắc đầu ra, về cơ bản vẫn xoay quanh việc "truyền đạt yêu cầu của bạn một cách rõ ràng nhất có thể".

Tuy nhiên, khi phát triển ứng dụng chuyên nghiệp, một prompt đơn giản là không đủ. Để hoàn thành các tác vụ phức tạp và tùy chỉnh với mô hình ngôn ngữ lớn (LLM), bạn cần xây dựng ngữ cảnh một cách tinh tế.

Nói một cách đơn giản:

"Prompt Engineering" dành cho người dùng, "Context Engineering" dành cho nhà phát triển.

Có người có thể nghĩ "Đây chẳng phải chỉ là đổi tên thôi sao?", nhưng không, tên gọi rất quan trọng. Bởi vì ngôn ngữ định hình tư duy.

CEO của Shopify, Tobi Lutke, cũng đứng về phía "đặt tên đúng", cho rằng "Context Engineering" là một khái niệm vượt trội hơn "Prompt Engineering" và lập luận rằng công việc cần cung cấp tất cả thông tin nền tảng.

Tại sao Context Engineering là "nghệ thuật và khoa học"?

Tại sao là "khoa học"

Gần đây, Nikolay Savinov, đồng trưởng nhóm tiền huấn luyện ngữ cảnh dài của Google, đã nói về mối quan hệ cộng sinh sâu sắc giữa Agent (tác nhân) và Context (ngữ cảnh) trong một cuộc phỏng vấn blog. Đây là nội dung rất đáng suy ngẫm.

Theo Savinov, Agent đảm nhận "vai trò kép":

• Một mặt, Agent là người tiêu thụ ngữ cảnh. Ví dụ, một Agent thực hiện nhiệm vụ phức tạp như "lập kế hoạch du lịch 5 ngày ở Hà Nội" cần liên tục ghi nhớ thông tin trạng thái như "vé máy bay đã đặt xong", "đang so sánh giá khách sạn", "vẫn cần hoàn thiện lịch trình". Nếu không có hỗ trợ ngữ cảnh dài, Agent sẽ mất trí nhớ mỗi khi được hỏi và không thể hình thành luồng công việc nhất quán. Ngữ cảnh là "ổ cứng bộ nhớ" thiết yếu cho Agent.

• Mặt khác, Agent cũng là người tạo ra ngữ cảnh. Trong thế giới thực, người dùng không đóng gói thủ công tất cả thông tin nền (ngân sách, sở thích thời gian, lịch sử tìm kiếm trước đó, sở thích địa lý, v.v.) để cung cấp cho Agent. Đây là lúc "khả năng sử dụng công cụ" của Agent trở nên cực kỳ quan trọng. Agent chủ động gọi các công cụ như tìm kiếm, lịch, API du lịch để thu thập thông tin thô, sau đó thông qua lọc, tinh chỉnh và cấu trúc hóa, động lực lắp ráp các nguyên liệu thô này thành ngữ cảnh chất lượng cao để cung cấp cho mô hình ngôn ngữ lớn.

Nói cách khác, Agent vừa phụ thuộc vào ngữ cảnh để "tồn tại", vừa chủ động xây dựng ngữ cảnh thông qua công cụ, từ đó làm cho mô hình "thông minh hơn". Đây chính là lý do cơ bản tại sao "Context Engineering" trở thành một khoa học.

Đây không chỉ đơn thuần là viết prompt hay kết nối dữ liệu, mà là một phương pháp luận hoàn chỉnh về phát hiện động yêu cầu công việc, tổ chức cấu trúc thông tin, kiểm soát phân bổ token, và cân bằng đầu vào-đầu ra.

Nói một cách dễ hiểu hơn, định nghĩa của Context Engineering là:

Đó là môn học về thiết kế và xây dựng hệ thống động, với mục tiêu duy nhất: "cung cấp" chính xác cho mô hình ngôn ngữ lớn tất cả thông tin và công cụ cần thiết để hoàn thành nhiệm vụ, với định dạng phù hợp, vào thời điểm thích hợp.

Theo Karpathy, thiết kế ngữ cảnh nên bao gồm các yếu tố sau:

• Hướng dẫn nhiệm vụ (task instructions)
• Ví dụ minh họa (few-shot examples)
• Nội dung bổ sung từ tìm kiếm (RAG)
• Thông tin đa phương tiện
• Công cụ/hàm bên ngoài
• Ngữ cảnh trạng thái hiện tại và lịch sử
• Nén và tối ưu hóa ngữ cảnh (compacting)

Nếu xem xét quá ít, mô hình không thể hiểu nhiệm vụ. Nếu quá nhiều hoặc không liên quan, chi phí sẽ tăng và hiệu suất giảm. Đây là một công việc kỹ thuật mang tính khoa học.

Philipp Schmid, Kỹ sư quan hệ AI cấp cao tại Google DeepMind, cũng phân tách Context Engineering thành nhiều mô-đun cấu thành trong blog mới nhất của mình:

• Prompt hệ thống/Hướng dẫn hệ thống: Định nghĩa hành vi, quy tắc, ví dụ
• Prompt người dùng: Vấn đề hoặc nhiệm vụ hiện tại
• Bộ nhớ ngắn hạn/Lịch sử đối thoại: Nội dung của phiên hiện tại
• Bộ nhớ dài hạn: Sở thích người dùng, thông tin dự án xuyên suốt các phiên
• Thông tin tìm kiếm (RAG): Tìm kiếm động nội dung từ tài liệu, cơ sở dữ liệu, API
• Công cụ có sẵn: Định nghĩa hàm như search, send_email
• Đầu ra có cấu trúc: Định dạng chỉ định như JSON, bảng

Ông cũng đưa ra bốn đặc điểm chính của Context Engineering:

1. Là hệ thống động, không phải chuỗi ký tự tĩnh. Ngữ cảnh không được "cố định" như "mẫu", mà là kết quả được Agent lắp ráp động dựa trên nhu cầu thời gian thực trước khi gọi LLM. Nó có sức sống.

2. Được tạo ra theo nhu cầu, không bất biến. Trong một yêu cầu, ngữ cảnh có thể là lịch trình của bạn. Trong yêu cầu tiếp theo, có thể cần kết quả tìm kiếm web mới nhất hoặc email quan trọng. Nó "thay đổi theo người, theo thời điểm".

3. Cung cấp chính xác thông tin và công cụ, không phải bão thông tin. Điểm mấu chốt là "vừa đủ". Tránh "rác vào, rác ra". Chỉ cung cấp thông tin và khả năng mà nhiệm vụ thực sự cần, bất cứ thứ gì thêm vào đều là sự can thiệp.

4. Rất coi trọng định dạng, không phải dữ liệu "thô". Tốt hơn là cung cấp bản tóm tắt tinh chỉnh thay vì ném vào mô hình một loạt nhật ký chưa qua xử lý. Hướng dẫn gọi công cụ có cấu trúc rõ ràng vượt trội hơn nhiều so với mô tả ngôn ngữ tự nhiên mơ hồ.

Thách thức trong phát triển AI thực tế

Trong quá trình phát triển ứng dụng/Agent LLM thực tế, ngoài việc "xây dựng ngữ cảnh tinh tế", chúng ta còn phải xử lý nhiều vấn đề kỹ thuật:

• Phân tách logic công việc (problem decomposition)
• Kiểm soát luồng gọi (control flow)
• Kết hợp khả năng của các mô hình khác nhau (lập lịch mô hình)
• Xử lý tương tác người dùng (UI/UX)
• Xây dựng các bước xác thực, thêm bảo mật, đánh giá hiệu quả
• Thực hiện tối ưu hóa hiệu suất như song song hóa, prefetching...

Toàn bộ hệ thống này đã trở thành một hệ thống phần mềm phức tạp và nặng nề. Context Engineering là một phần của nó, nhưng cũng là một trong những yếu tố then chốt quyết định sự thành công của Agent.

Trong môi trường phát triển thực tế, quản lý tài liệu API cũng là một ví dụ quan trọng về Context Engineering. Ví dụ, các công cụ như Apidog cấu trúc hóa và quản lý thông tin về đặc tả API, endpoint, tham số, ví dụ phản hồi, cho phép nhà phát triển tham khảo thông tin cần thiết vào thời điểm thích hợp. Đây chính là hiện thân của các nguyên tắc Context Engineering: "lựa chọn thông tin", "cấu trúc hóa", và "cung cấp vào thời điểm thích hợp".

Đặc biệt trong các hệ thống hiện đại với nhiều microservice liên kết, việc quản lý ngữ cảnh API phù hợp thường quyết định sự thành công của dự án. Ví dụ, trong một dự án, bằng cách sử dụng Apidog để tạo dữ liệu mô phỏng API và tiến hành song song phát triển frontend và backend, thời gian phát triển đã được rút ngắn 30%. Đây là một ví dụ tốt về việc thực hành các nguyên tắc Context Engineering: "tạo ngữ cảnh động" và "cung cấp thông tin phù hợp".

Tại sao cũng là "nghệ thuật"

Đó là vì ngay cả khi bạn biết các nguyên tắc như "lựa chọn thông tin", "tạo cấu trúc", "kiểm soát độ dài", trong phát triển thực tế vẫn cần nhiều phán đoán và điều chỉnh tinh tế không thể diễn đạt bằng lời hay công thức hóa.

Ví dụ, bạn không thể biết LLM "nhìn" prompt của bạn như thế nào. Không có cú pháp cố định hay tài liệu giao diện. Hai phiên bản đầu vào mà bạn nghĩ gần như giống nhau về mặt ngữ nghĩa có thể dẫn đến hiệu suất mô hình cuối cùng khác biệt lớn.

Vì vậy, bạn phải dựa vào kinh nghiệm và "trực giác đối thoại với mô hình" để thử nghiệm lặp đi lặp lại, điều chỉnh biểu thức, sắp xếp thứ tự. Giống như đang xử lý một đối tác khó tính.

Đây là "cảm nhận prompt". Đó là lý do tại sao một số người có thể đạt hiệu quả gấp 10 lần với AI, trong khi những người khác cảm thấy nó vô dụng.

Vì vậy, trong tương lai, nói "Lại là một ứng dụng bao bọc ChatGPT" khi gặp một sản phẩm xuất sắc có thể hơi thiếu tôn trọng.

Cách thực hành Context Engineering

Trong blog do framework phát triển AI LangChain công bố, bốn chiến lược triển khai cốt lõi được tóm tắt:

Chiến lược đầu tiên: Viết (Write) — Cung cấp cho AI "bảng nháp" và "bộ nhớ dài hạn"

AI cũng cần "bản nháp" hoặc "nhật ký".

Khi xử lý các tác vụ phức tạp, cho phép AI ghi lại suy nghĩ giai đoạn trung gian vào "bảng nháp" (Scratchpads) tạm thời hoặc lưu trữ kết luận quan trọng trong mô-đun "bộ nhớ dài hạn" (Memory) xuyên suốt các phiên. Điều này giúp giữ cửa sổ đối thoại chính gọn gàng đồng thời cho phép AI có khả năng học tập liên tục và nhìn lại.

Chiến lược thứ hai: Lựa chọn (Select)

Chất lượng quan trọng hơn số lượng.

Khi AI đối mặt với một nhiệm vụ, kích hoạt "bộ điều phối" thông minh để lựa chọn chính xác thông tin liên quan nhất hiện tại từ cơ sở kiến thức rộng lớn (tài liệu, công cụ, bộ nhớ) thông qua các kỹ thuật như RAG và "cung cấp" cho mô hình. Điều này giúp tránh thông tin quá tải và cho phép mô hình tập trung vào vấn đề cốt lõi.

Chiến lược thứ ba: Nén (Compress)

Bộ nhớ ngữ cảnh có giới hạn, mỗi chút không gian đều quý giá.

Khi lịch sử đối thoại hoặc tài liệu tìm kiếm quá dài, cần học cách "đơn giản hóa". Thông qua các chiến lược như tóm tắt hoặc cắt tỉa, "tinh giản" ngữ cảnh một cách khôn ngoan, giữ lại nội dung cốt lõi nhất trong cửa sổ ngữ cảnh quý giá mà không mất thông tin quan trọng.

Chiến lược thứ tư: Cô lập (Isolate)

Chia để trị, đơn giản hóa sự phức tạp. Đây là tinh hoa của hệ thống đa tác nhân (Multi-agent). Thay vì để một Agent "vạn năng" đối phó với mọi phức tạp, phân tách nhiệm vụ lớn và phân phối cho nhiều Agent "chuyên môn" với ngữ cảnh tối ưu hóa độc lập, mỗi Agent thực hiện vai trò của mình và cuối cùng tổng hợp kết quả để đạt hiệu quả 1+1>2.

"Bệnh học" của Context Engineering

Drew Breunig, nhà phát triển của LangChain, đã đưa ra một quan điểm rất quan trọng:

Hầu hết các thất bại của tác nhân thông minh không còn là thất bại của bản thân mô hình, mà là vấn đề với "ngữ cảnh" mà chúng ta cung cấp.

Ông phân loại những vấn đề này thành bốn "bệnh lý" điển hình:

Bệnh lý 1: Ngộ độc ngữ cảnh

• Triệu chứng: AI lấy thông tin sai hoặc "ảo giác" thuần túy (URL không tồn tại, dữ liệu sai, v.v.) khi gọi công cụ, những "độc tố" này làm ô nhiễm toàn bộ ngữ cảnh, dẫn đến tất cả suy luận tiếp theo đều sai.
• Giải pháp:
  • (1) Cô lập: Chạy công cụ không ổn định trong môi trường "sandbox" và chỉ gửi lại kết quả không độc đã được xác minh cho hệ thống chính.
  • (2) Lựa chọn: Thêm quy trình "kiểm tra chất lượng" sau khi truy xuất thông tin để lọc hoặc sắp xếp lại nguồn thông tin chất lượng thấp và đáng ngờ.
  • (3) Viết: Ghi lại nguồn gốc và độ tin cậy của lệnh gọi công cụ trong "bảng nháp" để có thể theo dõi và điều tra "nguồn độc tố" bất cứ lúc nào.

Bệnh lý 2: Mất tập trung ngữ cảnh

• Triệu chứng: Cung cấp cho AI quá nhiều thông tin cùng một lúc (ngay cả khi tất cả đều liên quan). Ngữ cảnh rộng lớn làm chôn vùi hướng dẫn cốt lõi nhất, giống như học sinh có quá nhiều sách tham khảo không thể tìm thấy sách giáo khoa quan trọng nhất, khiến AI rơi vào trạng thái "không nắm bắt được trọng tâm".
• Giải pháp:
  • (1) Cô lập: Áp dụng chiến lược "đa tác nhân", mỗi Agent chỉ tập trung vào lĩnh vực chuyên môn của mình và chỉ xem thông tin hẹp liên quan nhất.
  • (2) Nén: Thường xuyên "tinh giản" ngữ cảnh, giảm đáng kể độ dài ngữ cảnh thông qua tóm tắt và cắt tỉa, đảm bảo hướng dẫn cốt lõi luôn "nổi trên mặt nước".
  • (3) Lựa chọn: Chỉ chọn kiến thức và công cụ quan trọng nhất cho nhiệm vụ phụ hiện tại, tránh bão thông tin cùng một lúc.

Bệnh lý 3: Rối loạn ngữ cảnh

• Triệu chứng: Thông tin cung cấp cho AI có định dạng lộn xộn, không được tổ chức. Ví dụ, nếu ném một đống nhật ký lộn xộn, AI có thể diễn giải theo cách không mong đợi và sai lầm, cuối cùng tạo ra kết quả "lạc đề".
• Giải pháp:
  • (1) Nén: Tận dụng khả năng tóm tắt của LLM để tinh chỉnh dữ liệu "thô" không có cấu trúc thành dữ liệu "đã xử lý" rõ ràng và ngắn gọn trước khi cung cấp cho mô hình.
  • (2) Viết: Khi thiết kế "bảng nháp" hoặc mô-đun bộ nhớ, lưu trữ các loại thông tin khác nhau (lịch sử, đầu ra công cụ, v.v.) trong các trường khác nhau, đảm bảo tính rõ ràng của cấu trúc từ gốc rễ.
  • (3) Lựa chọn: Đảm bảo định dạng thông tin được truy xuất là thống nhất và đính kèm "hướng dẫn" (metadata) giải thích ý nghĩa của nó.

Bệnh lý 4: Xung đột ngữ cảnh

• Triệu chứng: Các phần khác nhau của ngữ cảnh chứa thông tin mâu thuẫn. Ví dụ, một tài liệu nói "A là đúng" trong khi tài liệu khác nói "B là đúng", AI bị buộc phải "chọn phe" mà không có hướng dẫn rõ ràng, dễ dẫn đến sai lầm trong quyết định.
• Giải pháp:
  • (1) Lựa chọn: Cài đặt "lớp trung gian xung đột" để xử lý trước thông tin mâu thuẫn trước khi gửi đến LLM.
  • (2) Cô lập: Giao nhiệm vụ xử lý các nguồn thông tin khác nhau (và có thể xung đột) cho các Agent "người thảo luận" khác nhau, cuối cùng Agent "trọng tài" đưa ra phán quyết.
  • (3) Viết: Lưu trữ không chỉ kết quả quyết định mà còn cả lý do đưa ra quyết định đó trong "bộ nhớ dài hạn" để tham khảo khi đối mặt với xung đột tương tự trong tương lai.

Tầm quan trọng của Context Engineering trong doanh nghiệp

Thú vị là tại Shopify, khả năng sử dụng AI một cách chủ động và "cho phép AI đọc ngữ cảnh" đang trở thành kỳ vọng cơ bản đối với nhân viên, thậm chí được đưa vào đánh giá hiệu suất.

Hiện tại, trước khi đề xuất tăng nhân sự, bất kỳ nhóm nào cũng phải chứng minh với công ty: tại sao công việc này không thể được hoàn thành bởi một tác nhân thông minh AI với "ngữ cảnh được thiết kế phù hợp"?

Tóm tắt: Tương lai của Context Engineering

Việc xây dựng tác nhân AI mạnh mẽ và đáng tin cậy không còn là tìm kiếm prompt ma thuật hay cập nhật mô hình. Đó là kỹ thuật ngữ cảnh cung cấp thông tin và công cụ phù hợp, với định dạng phù hợp, vào thời điểm thích hợp.

Đây là một thách thức liên ngành đòi hỏi hiểu biết về trường hợp sử dụng kinh doanh, định nghĩa đầu ra, và cấu trúc hóa tất cả thông tin cần thiết để LLM "hoàn thành công việc". Giống như công cụ quản lý tài liệu API Apidog thực hiện việc cấu trúc hóa thông tin và cung cấp phù hợp, trong phát triển tác nhân AI, việc cấu trúc hóa thông tin và cung cấp vào thời điểm thích hợp là chìa khóa thành công.

Bản thân tôi gần đây đã áp dụng các nguyên tắc Context Engineering trong một dự án và thấy chất lượng phản hồi và tính nhất quán của AI được cải thiện đáng kể. Đặc biệt, bằng cách đầu tư thời gian vào việc lựa chọn và cấu trúc hóa thông tin, tôi đã có thể giao cho AI những nhiệm vụ phức tạp mà trước đây tôi nghĩ là không thể.

Bạn có nghĩ "Context Engineering" sẽ là xu hướng lớn tiếp theo không? Hay bạn cho rằng nó là một khái niệm được đánh giá quá cao? Hãy chia sẻ những hiểu biết của bạn trong phần bình luận!