Context Engineering là gì? Cách giúp AI agent hiểu đúng dữ liệu của bạn
Context Engineering là kỹ thuật thiết kế, chọn lọc và quản lý toàn bộ thông tin mà mô hình AI nhận được trước khi trả lời, gồm chỉ dẫn, dữ liệu truy xuất, lịch sử hội thoại, bộ nhớ và công cụ ở mỗi bước nó chạy [1][2].
Khi bạn giao cho một AI agent (tác tử AI, chương trình dùng LLM, tức mô hình ngôn ngữ lớn, để tự làm nhiều bước như đọc bảng, viết SQL, dựng biểu đồ) một câu hỏi về doanh thu, kết quả đúng hay sai phụ thuộc vào những gì agent được đọc trước khi bắt đầu. Nhiều người nghĩ chỉ cần viết prompt (đoạn chỉ dẫn gửi cho mô hình) dài và khéo hơn là agent sẽ đúng, nhưng nếu agent không biết "doanh thu" ở công ty bạn đã trừ đơn hoàn hay chưa thì prompt hay đến đâu nó vẫn phải đoán. Khảo sát của Mei và cộng sự đăng trên arXiv ngày 21/07/2025 đã phân tích hơn 1400 bài nghiên cứu để hệ thống hóa lĩnh vực này [1][2].
Mục lục
I. Context Engineering là gì?
Mô hình ngôn ngữ chỉ làm việc với những gì nằm trong context window (cửa sổ ngữ cảnh, lượng nội dung tối đa mô hình đọc được trong một lần chạy). Lượng nội dung này được đo bằng token (đơn vị văn bản mà mô hình dùng để đọc, bị giới hạn và tính phí theo số lượng). Context Engineering là việc quyết định cái gì được đưa vào cửa sổ đó, theo thứ tự nào, ở dạng nào và giữ lại trong bao lâu.
Khảo sát của Mei và cộng sự xem Context Engineering là một mảng kỹ thuật riêng, rộng hơn việc thiết kế prompt. Trong cách nhìn này, ngữ cảnh là tập hợp nhiều thành phần được lắp ráp lại: chỉ dẫn hệ thống, tri thức bên ngoài, công cụ, bộ nhớ và câu hỏi của người dùng [1][2].
Prompt Engineering (kỹ thuật soạn prompt) tập trung vào cách diễn đạt một chỉ dẫn. Context Engineering nhìn rộng hơn: agent được xem bảng nào, định nghĩa nào, kết quả công cụ nào ở từng bước, và thông tin nào phải bỏ đi để cửa sổ không bị đầy.
Với người làm dữ liệu, ngữ cảnh gồm những thứ rất quen: schema (cấu trúc bảng và cột), định nghĩa metric (chỉ số đo, ví dụ doanh thu thuần), quy tắc nghiệp vụ, các câu hỏi đã hỏi trước đó. LLM không có sẵn những thứ này cho công ty bạn. Khi thiếu, nó điền chỗ trống bằng phỏng đoán nghe có vẻ hợp lý, tức ảo giác (hallucination, trả lời tự tin nhưng sai).
II. Đặc điểm của Context Engineering
Khảo sát chia Context Engineering thành ba nhóm thành phần nền tảng [1][2]. Bạn có thể đọc chúng như ba câu hỏi khi thiết kế một agent phân tích dữ liệu.
1. Truy xuất và tạo ngữ cảnh
Câu hỏi ở đây là agent lấy thông tin gì và từ đâu. Nhóm này gồm việc viết chỉ dẫn và lấy tri thức từ nguồn bên ngoài [1][2]. Trong công việc BI, đó là bước tìm đúng bảng, đúng định nghĩa metric và đúng đoạn tài liệu quy tắc nghiệp vụ khi agent nhận câu hỏi. RAG (Retrieval-Augmented Generation, cách cho mô hình tra tài liệu rồi mới trả lời) là kỹ thuật điển hình của nhóm này.
2. Xử lý ngữ cảnh
Thông tin lấy về hiếm khi dùng được ngay. Nhóm xử lý gồm việc làm việc với chuỗi dài, tinh chỉnh thông tin và tích hợp dữ liệu có cấu trúc [1][2]. Với analytics, bạn rút gọn một kết quả truy vấn hàng nghìn dòng thành bảng tổng hợp, bỏ những cột agent không cần, và trình bày bảng ở dạng agent đọc dễ.
3. Quản lý ngữ cảnh
Một agent chạy nhiều bước sẽ làm đầy cửa sổ rất nhanh. Nhóm quản lý lo việc nén thông tin, tổ chức bộ nhớ và quyết định giữ gì, bỏ gì [1][2]. Ví dụ: agent nhớ định nghĩa "doanh thu thuần" đã được chốt từ đầu phiên, và tóm tắt phần hội thoại cũ thay vì đọc lại từng dòng.
Ba nhóm này được ghép thành các hệ thống hoàn chỉnh như RAG, hệ thống bộ nhớ, suy luận tích hợp công cụ và hệ thống nhiều agent [1][2].
Khảo sát cũng ghi nhận một khoảng lệch trong năng lực: mô hình được tăng cường bằng Context Engineering hiểu ngữ cảnh phức tạp khá tốt, nhưng còn hạn chế khi phải sinh ra đầu ra dài và tinh vi [1][2]. Điều này gợi ý một cách làm thiết thực: để agent đọc nhiều bảng và định nghĩa thì ổn hơn là để nó tự viết cả một báo cáo dài trong một lượt, nên bạn chia việc thành các bước nhỏ và kiểm từng bước.
III. Ví dụ thực tế: cùng câu hỏi doanh thu, có và không có ngữ cảnh
Tình huống dưới đây là giả định để minh họa, không phải số liệu thật. Một sàn thương mại điện tử Việt Nam có bảng fact_orders. Giám đốc kinh doanh hỏi agent: "Doanh thu tháng 9 của kênh sàn là bao nhiêu?"
Hạng mục | Agent không có ngữ cảnh | Agent có ngữ cảnh |
|---|---|---|
"Doanh thu" là gì | Tổng cột order_amount | Doanh thu thuần: giá trị hàng của đơn hoàn tất, sau voucher của shop, không gồm phí vận chuyển |
Trạng thái đơn | Lấy mọi đơn, kể cả đơn hủy và hoàn trả | Chỉ lấy status = 'Hoàn tất' |
Mốc thời gian | Lọc theo cột ngày đầu tiên agent tìm thấy | Lọc theo order_date, vì báo cáo tài chính của công ty chốt theo ngày đặt |
"Kênh sàn" | Không biết ứng với cột nào, tự đoán | Synonym đã khai báo: "kênh sàn", "marketplace" ứng với channel = 'Marketplace' |
Bảng được đọc | Quét toàn bộ schema | Chỉ nạp fact_orders, dim_channel, dim_date |
Cả hai agent đều trả về một con số, và cả hai câu SQL đều chạy không lỗi. Con số của agent thiếu ngữ cảnh cao hơn báo cáo đã duyệt, vì nó cộng cả đơn hủy và phí vận chuyển. Nếu chỉ nhìn kết quả, bạn khó thấy chỗ lệch. Lỗi do thiếu ngữ cảnh khó phát hiện hơn lỗi cú pháp, vì hệ thống không báo lỗi gì cả.
IV. Ứng dụng Context Engineering trong phân tích dữ liệu
Khi đưa Context Engineering vào công việc BI, bạn sẽ gặp ba khái niệm hay đi cùng nhau. Semantic layer (lớp ngữ nghĩa) là nơi lưu tên gọi, định nghĩa và quan hệ giữa các bảng để mọi công cụ dùng chung. Text-to-SQL là kỹ thuật chuyển câu hỏi viết bằng ngôn ngữ thường thành câu lệnh SQL. Data dictionary (từ điển dữ liệu) là bảng mô tả ý nghĩa từng cột. Trong hệ sinh thái Power BI và Microsoft Fabric, semantic model là chỗ tập trung phần lớn ngữ cảnh này. Vì vậy chương trình Agentic AI Analytics của MDA xây Semantic Model thành phần lõi để agent hiểu đúng nghiệp vụ.
1. Đưa định nghĩa metric và data dictionary vào agent
Cách làm gọn nhất là viết ngữ cảnh một lần, ở một chỗ, rồi để mọi agent đọc từ chỗ đó. Bạn có thể đi theo các bước sau.
Chọn các metric bị hỏi nhiều nhất, ví dụ doanh thu thuần, số đơn, giá trị đơn trung bình, tỷ lệ hoàn.
Với mỗi metric, viết định nghĩa một dòng, công thức, bộ lọc bắt buộc và mốc thời gian dùng để tính (ngày đặt hay ngày giao).
Lập data dictionary cho các bảng agent hay chạm tới: tên cột, ý nghĩa, giá trị hợp lệ, ghi chú dễ nhầm.
Khai báo synonyms cho những cách gọi khác mà đồng nghiệp hay dùng, ví dụ "DT", "net revenue", "kênh sàn".
Đặt toàn bộ vào semantic model thay vì dán vào từng prompt. Trong Power BI, bạn có thể ghi description cho bảng, cột và measure, cùng synonyms cho tên gọi khác. Agent kết nối với model thường đọc được các mô tả này.
Kiểm thử bằng một bộ câu hỏi mẫu và so kết quả với báo cáo đã được duyệt.
Một data dictionary đủ dùng cho agent không cần dài. Ví dụ với bảng fact_orders:
Cột | Ý nghĩa | Ghi chú cho agent |
|---|---|---|
order_date | Ngày khách đặt đơn | Mốc thời gian mặc định cho mọi báo cáo doanh thu |
status | Trạng thái đơn | Giá trị hợp lệ: Hoàn tất, Hủy, Hoàn trả. Doanh thu chỉ tính Hoàn tất |
item_value | Giá trị hàng trước voucher | Chưa trừ voucher của shop |
shipping_fee | Phí vận chuyển khách trả | Không cộng vào doanh thu |
2. Rủi ro khi ngữ cảnh kém: số sai, rò rỉ dữ liệu, tốn token
Ngữ cảnh kém gây ba loại sự cố mà bạn dễ gặp ngay trong công việc.
Loại đầu tiên là số sai. Hai phòng ban hỏi cùng agent về "doanh thu" nhưng nhận hai con số khác nhau, vì agent chọn cột khác nhau ở mỗi lần. Báo cáo gửi lên sếp rồi mới có người đối chiếu thì mất cả uy tín lẫn thời gian sửa.
Loại thứ hai là rò rỉ dữ liệu. Nếu bạn nạp nguyên bảng khách hàng, gồm số điện thoại, email, hay bảng lương vào ngữ cảnh, những cột đó có thể đi tới dịch vụ mô hình bên ngoài và nằm trong lịch sử hội thoại. Hãy chỉ nạp cột agent cần, che dữ liệu cá nhân trước khi đưa vào, và cho agent chạy với quyền của chính người hỏi. Cần lưu ý thêm prompt injection (chèn chỉ dẫn độc hại vào nội dung mà agent đọc): một ô ghi chú khách hàng hay một file tải về có thể chứa câu lệnh giả. Hãy coi nội dung đọc từ dữ liệu là dữ liệu, không phải chỉ dẫn.
Loại thứ ba là tốn token. Dán schema của hàng trăm bảng vào mỗi lượt chạy làm agent chậm, chi phí tăng, và ngữ cảnh càng dài, nhiễu càng nhiều thì agent càng dễ bỏ sót chi tiết quan trọng. Phát hiện năm 2025 về hạn chế khi sinh đầu ra dài [1][2] cũng là lý do để chia báo cáo lớn thành các bước nhỏ, có người kiểm tra giữa chừng.
3. Mẹo tiết kiệm token và thời gian khi làm việc với agent
Ba hướng sau đây tương ứng với nhóm xử lý và quản lý ngữ cảnh ở phần II.
Chọn lọc: chỉ nạp những bảng và định nghĩa liên quan đến câu hỏi hiện tại. Nếu có nhiều bảng, cho agent tra danh sách bảng trước rồi mới mở schema chi tiết của vài bảng cần dùng.
Nén: để câu SQL chạy ngay trên database và chỉ trả về bảng tổng hợp cho agent, thay vì đẩy hàng nghìn dòng chi tiết vào cửa sổ. Với hội thoại dài, tóm tắt phần đã xong thành vài dòng rồi bỏ nội dung gốc.
Bộ nhớ: ghi những điều đã chốt (định nghĩa metric, bảng nên dùng, lỗi đã gặp) vào một file hoặc kho lưu bên ngoài để agent đọc lại khi cần, thay vì bạn gõ lại mỗi lần.
Ngoài ra, hãy đặt những thông tin ổn định như quy tắc và định nghĩa ở phần đầu ngữ cảnh, còn câu hỏi riêng của lượt này ở cuối. Với nhiều việc khác nhau (xử lý dữ liệu, dựng dashboard, kiểm tra chất lượng), tách thành các agent chuyên biệt cũng giúp mỗi agent chỉ mang đúng ngữ cảnh của việc nó làm.
V. Context Engineering khác Prompt Engineering và RAG thế nào?
Ba khái niệm này hay bị trộn lẫn, nhưng chúng nằm ở các tầng khác nhau. Prompt Engineering là cách bạn viết chỉ dẫn. RAG là một cách lấy thông tin bên ngoài đưa vào cho mô hình. Context Engineering bao cả hai, vì khảo sát xếp RAG cùng hệ thống bộ nhớ, suy luận tích hợp công cụ và hệ thống nhiều agent vào nhóm các cách triển khai của Context Engineering [1][2].
Tiêu chí | Prompt Engineering | RAG | Context Engineering |
|---|---|---|---|
Câu hỏi chính | Viết chỉ dẫn thế nào cho rõ? | Lấy tài liệu nào cho mô hình đọc? | Toàn bộ thông tin nào nên nằm trong cửa sổ ở mỗi bước? |
Ví dụ trong analytics | Yêu cầu agent trả lời bằng bảng, nêu giả định | Tìm đoạn tài liệu định nghĩa "doanh thu thuần" | Kết hợp định nghĩa, schema, bộ nhớ phiên, kết quả truy vấn, quyền truy cập |
Phạm vi | Một lượt gọi mô hình | Bước truy xuất tri thức | Cả vòng đời của agent qua nhiều bước |
Hạn chế điển hình | Không bù được dữ liệu và định nghĩa còn thiếu | Lấy sai hoặc lấy thừa tài liệu | Cần thiết kế, kiểm thử và bảo trì |
Với agent chạy nhiều bước, ngữ cảnh thay đổi liên tục: kết quả truy vấn mới, thông báo lỗi SQL, câu trả lời của người dùng. Một prompt viết sẵn một lần không kiểm soát được những thay đổi đó, nên phần việc quyết định chất lượng thường nằm ở cách lắp ráp ngữ cảnh. Prompt tốt vẫn cần, nhưng nó chỉ là một thành phần trong ngữ cảnh [1][2].
VI. Câu hỏi thường gặp về Context Engineering
1. Context Engineering có thay thế Prompt Engineering không?
Không. Prompt là một thành phần của ngữ cảnh [1][2], nên chỉ dẫn rõ ràng vẫn cần. Điều thay đổi là bạn không dừng ở việc chỉnh câu chữ mà còn quan tâm agent được đọc những gì.
2. Người làm analytics không biết lập trình có làm được không?
Phần lớn công việc ban đầu là viết định nghĩa metric, mô tả cột, khai báo synonyms và soạn bộ câu hỏi kiểm thử. Đó đều là việc của người hiểu nghiệp vụ dữ liệu. Phần kỹ thuật như truy xuất hay bộ nhớ có thể nhờ đồng nghiệp kỹ thuật hoặc công cụ có sẵn.
3. Context window lớn rồi thì còn cần Context Engineering không?
Vẫn cần. Nhét nhiều hơn vào cửa sổ làm tăng token, tăng thời gian chờ và tăng nhiễu. Quyết định đưa gì vào, theo thứ tự nào, vẫn là việc của bạn dù cửa sổ rộng đến đâu.
4. Semantic layer có phải là Context Engineering không?
Semantic layer là một dạng ngữ cảnh có cấu trúc, do con người duyệt và dùng chung cho nhiều công cụ. Nó là một phần quan trọng của Context Engineering trong BI, nhưng chưa bao gồm các phần như bộ nhớ phiên hay quản lý quyền truy cập.
5. Làm tốt Context Engineering thì agent hết ảo giác?
Không hết hoàn toàn. Ngữ cảnh tốt giúp giảm nguy cơ agent đoán mò, nhưng nghiên cứu năm 2025 vẫn ghi nhận hạn chế khi mô hình sinh đầu ra dài và tinh vi [1][2]. Vì vậy các hệ thống nghiêm túc đều giữ Human-in-the-Loop (con người kiểm soát tại các chốt chặn) ở những bước ảnh hưởng đến con số báo cáo.
6. Tuần này tôi nên bắt đầu từ đâu?
Chọn một báo cáo bạn đang làm thủ công. Viết định nghĩa cho các metric chính của nó, lập data dictionary cho bảng nguồn, rồi soạn khoảng mười câu hỏi mà bạn đã biết đáp án đúng. Cho agent trả lời bộ câu hỏi đó và ghi lại chỗ nó sai. Mỗi chỗ sai thường chỉ ra một định nghĩa còn thiếu trong ngữ cảnh.
VII. Kết luận
Context Engineering chuyển câu hỏi từ "viết prompt thế nào" sang "agent cần biết gì để làm đúng việc này". Với người đi làm trong lĩnh vực dữ liệu, câu trả lời nằm ở những thứ bạn đã quen: định nghĩa metric, mô hình dữ liệu, quy tắc nghiệp vụ, kiểm tra kết quả. Điểm mới là bạn viết chúng ra theo cách để máy đọc được và để nhiều agent dùng chung.
Lộ trình kỹ năng có thể đi theo thứ tự này. Đầu tiên là phân tích bài toán kinh doanh và phân rã nguyên nhân theo cấu trúc rõ ràng. Tiếp theo là dựng mô hình dữ liệu và semantic model. Sau đó là viết ngữ cảnh cho agent và kiểm thử. Cuối cùng là điều phối nhiều agent với các chốt kiểm soát của con người. Chương trình Agentic AI Analytics Program của MDA đi theo đúng thứ tự này trong 20 buổi: giai đoạn đầu về tư duy và luồng kinh doanh, giai đoạn giữa (buổi 4 đến 15) về data pipeline, mô hình Star Schema và Semantic Layer, giai đoạn cuối về dashboard, data storytelling và đồ án BI Capstone. Hệ thống gồm 14 AI Agents chuyên biệt chạy trên Microsoft Fabric và Power BI qua giao thức MCP (Model Context Protocol, chuẩn để agent kết nối với công cụ và nguồn dữ liệu), với người kiểm soát ở các chốt chặn. Bạn có thể đọc thêm các bài khác tại Blog Mastering Data Analytics.
Lưu ý: phần dưới đây giới thiệu chương trình đào tạo của Mastering Data Analytics.
📚 Bắt đầu sự nghiệp Analytics vững vàng trong kỷ nguyên AI
Mastering Data Analytics (MDA) là một trong những đơn vị đào tạo phân tích dữ liệu tại Việt Nam, mang chương trình Agentic AI Analytics đến với người học. Sau hơn 6 năm đào tạo phân tích dữ liệu, MDA đã đồng hành cùng 3.000+ học viên và 250+ doanh nghiệp lớn như Heineken, Prudential, P&G, AEON, BIDV, Coca-Cola, Unilever. Điểm khác biệt của MDA không nằm ở những lời hứa kiểu '5 phút phân tích data với ChatGPT' hay 'vibe coding dashboard'. Chúng tôi rèn đúng bộ ba tạo nên lợi thế cạnh tranh thật sự thời AI: tư duy phân tích hệ thống, chuyên môn vững chắc và năng lực điều phối AI Agents.
Khám phá chương trình: Agentic AI Analytics, Finance Analytics
Tư vấn lộ trình miễn phí qua Zalo: 0961 48 66 48
Fanpage: Mastering Data Analytics
Nguồn tham khảo
[1] A Survey of Context Engineering for Large Language Models. https://arxiv.org/html/2507.13334v2
[2] A Survey of Context Engineering for Large Language Models. https://ar5iv.labs.arxiv.org/html/2507.13334
Bình luận