Context Engineering: Vì sao dữ liệu đúng quan trọng hơn một prompt dài?

Nhiều dự án AI trong doanh nghiệp bắt đầu bằng một cuộc thi viết prompt: nhóm nào đặt câu hỏi dài hơn, mô tả vai trò chi tiết hơn hoặc thêm nhiều quy tắc hơn thì được kỳ vọng sẽ có câu trả lời tốt hơn. Cách tiếp cận này hữu ích ở giai đoạn thử nghiệm, nhưng nhanh chóng chạm trần khi AI phải làm việc với giá bán thay đổi mỗi ngày, hợp đồng có nhiều phiên bản hoặc dữ liệu khách hàng nằm ở nhiều hệ thống.

Context Engineering, có thể hiểu là kỹ thuật thiết kế ngữ cảnh, là công việc chuẩn bị toàn bộ thông tin mà AI cần trước khi trả lời hoặc hành động. Ngữ cảnh không chỉ gồm câu lệnh. Nó còn gồm dữ liệu được lấy từ đâu, phiên bản nào đang có hiệu lực, định nghĩa nghiệp vụ, quyền của người dùng, lịch sử công việc và tiêu chí buộc hệ thống phải chuyển cho con người.

Google Cloud mô tả context engineering như việc xây dựng môi trường dữ liệu và bộ nhớ có cấu trúc cho AI, thay vì chỉ tối ưu câu chữ trong một ô chat. Tài liệu của hãng nhấn mạnh hệ thống hiện đại phải tự thu thập, lọc và sắp xếp dữ liệu trước khi mô hình nhận yêu cầu. Điều này phản ánh một thay đổi quan trọng: chất lượng AI ngày càng phụ thuộc vào kiến trúc dữ liệu xung quanh mô hình.

Ví dụ, một nhân viên hỏi “khách hàng A còn hạn mức tín dụng không?”. Prompt có thể rất rõ, nhưng AI vẫn trả lời sai nếu lấy công nợ của hôm qua, nhầm hai pháp nhân cùng tên hoặc không biết đơn hàng mới vừa được ghi nhận trong ERP. Vấn đề lúc này không nằm ở khả năng viết tiếng Việt của mô hình mà ở nguồn dữ liệu, định danh và thời điểm cập nhật.

Context Engineering vì thế không đồng nghĩa với việc đưa thật nhiều tài liệu vào cửa sổ hội thoại. Dữ liệu thừa có thể che mất thông tin quan trọng, tăng chi phí xử lý và khiến mô hình bám vào một phiên bản cũ. Mục tiêu là đưa đúng phần thông tin, cho đúng nhiệm vụ, đúng người và đúng thời điểm.

AI trong bài toán này cũng không chỉ là chatbot. Một AI Agent có thể tìm hồ sơ khách hàng, kiểm tra chính sách bán chịu, tính phần hạn mức còn lại và tạo đề xuất giữ hoặc giải phóng đơn hàng. Khi hệ thống có khả năng đi qua nhiều bước như vậy, lỗi ngữ cảnh có thể trở thành lỗi vận hành thật.

Doanh nghiệp vì thế cần nhìn prompt như phần giao diện của một hệ thống lớn hơn. Phía sau câu hỏi phải có dữ liệu đáng tin, quy trình truy xuất, kiểm soát quyền, nhật ký và cơ chế đánh giá. Nếu thiếu các lớp này, một câu trả lời trôi chảy chỉ làm sai lệch trở nên khó nhận ra hơn.

Trong doanh nghiệp, một prompt hay chỉ giúp diễn đạt yêu cầu; ngữ cảnh đúng mới quyết định AI đang dựa vào sự thật nào, được phép làm gì và phải dừng ở đâu.

MỤC LỤC

PHẦN I — HIỂU ĐÚNG NỀN TẢNG

1. Context Engineering thực chất là gì
2. Prompt dài thường thất bại ở đâu
3. Ngữ cảnh đúng gồm những lớp nào
4. AI có thể giúp ở đâu và không nên làm gì
5. Con người có bị thay thế không

PHẦN II — NHỮNG ỨNG DỤNG THỰC TẾ

6. Tìm đúng chính sách đang có hiệu lực
7. Trả lời chỉ số kinh doanh theo một định nghĩa
8. Chuẩn bị hồ sơ khách hàng trước cuộc gọi
9. Kiểm tra tồn kho có tính đến độ trễ
10. Soát hợp đồng theo playbook nội bộ
11. Hỗ trợ kỹ thuật theo đúng phiên bản sản phẩm
12. Phân tích nguyên nhân biến động
13. Tạo đề xuất bổ sung hàng
14. Cá nhân hóa nhưng giữ đúng sự đồng ý
15. Duy trì bộ nhớ công việc của Agent
16. Phát hiện xung đột giữa các nguồn
17. Giảm ngữ cảnh để giảm chi phí và nhiễu

PHẦN III — AI AGENT, DỮ LIỆU VÀ KIỂM SOÁT

AI Assistant và AI Agent khác nhau thế nào
Dữ liệu nào cần được đưa vào ngữ cảnh
Vai trò của ERP, CRM, Data Warehouse và Data Platform
Data Quality, quyền truy cập và bảo mật
Đánh giá chất lượng ngữ cảnh trước khi vận hành

PHẦN IV — TRIỂN KHAI TRONG DOANH NGHIỆP

Bắt đầu từ một quyết định có giá trị
Ba use case đầu tiên ít rủi ro
Roadmap triển khai 90 ngày
KPI cần đo
Những sai lầm phổ biến
Điều kiện để mở rộng

PHẦN V — TÌNH HUỐNG TỔNG THỂ VÀ TƯƠNG LAI

Tình huống doanh nghiệp tổng thể
Trước và sau khi triển khai
Công việc sẽ thay đổi ra sao
Kết luận

PHẦN I — HIỂU ĐÚNG NỀN TẢNG

1. Context Engineering thực chất là gì?

Context Engineering là cách thiết kế “bộ hồ sơ làm việc” mà AI được nhận cho mỗi nhiệm vụ. Bộ hồ sơ có thể gồm câu hỏi, dữ liệu giao dịch mới nhất, chính sách nội bộ, định nghĩa chỉ số, lịch sử xử lý và danh sách công cụ được phép dùng. Việc thiết kế phải trả lời bốn câu hỏi: lấy gì, lấy từ đâu, sắp xếp thế nào và khi nào phải loại bỏ.

Hãy hình dung giao việc cho một nhân viên mới. Một lời dặn dài không thể thay thế bảng giá hiện hành, hồ sơ khách hàng đúng và quy trình phê duyệt. AI cũng vậy: prompt mô tả công việc, còn ngữ cảnh cung cấp bằng chứng để công việc được thực hiện đúng.

2. Prompt dài thường thất bại ở đâu?

Prompt dài có thể chứa nhiều hướng dẫn nhưng không tự làm dữ liệu mới hơn hoặc chính xác hơn. Khi quy định thay đổi, người viết phải nhớ sửa mọi prompt đang sử dụng. Khi hai nguồn mâu thuẫn, prompt cũng không biết nguồn nào có thẩm quyền nếu doanh nghiệp chưa quy định rõ.

Một prompt chứa toàn bộ sổ tay bán hàng còn gây thêm ba vấn đề: tốn chi phí đầu vào, kéo dài thời gian phản hồi và làm tín hiệu quan trọng bị lẫn trong thông tin không liên quan. Thiết kế tốt chỉ chọn những đoạn cần cho câu hỏi hiện tại, kèm ngày hiệu lực và nguồn.

Bốn lớp ngữ cảnh đúng cho AI trong doanh nghiệp

3. Ngữ cảnh đúng gồm những lớp nào?

Lớp đầu là ngữ cảnh nghiệp vụ: mục tiêu, thuật ngữ và quy tắc. Lớp thứ hai là ngữ cảnh dữ liệu: bản ghi, thời gian cập nhật và quan hệ giữa các đối tượng. Lớp thứ ba là ngữ cảnh vận hành: bước đã hoàn thành, công cụ có thể gọi và giới hạn hành động. Lớp cuối là ngữ cảnh kiểm soát: danh tính người dùng, quyền truy cập và yêu cầu phê duyệt.

Bốn lớp không nhất thiết nằm trong một hệ thống. Chính sách có thể ở kho tài liệu, giao dịch ở ERP, hồ sơ ở CRM và quyền ở hệ thống quản lý danh tính. Data Platform phải kết nối chúng theo cách có thể truy vết thay vì sao chép tùy tiện vào prompt.

4. AI có thể giúp ở đâu và không nên làm gì?

AI có thể phân loại yêu cầu, chọn nguồn liên quan, tìm đoạn tài liệu, tóm tắt lịch sử và phát hiện thông tin mâu thuẫn. Nó cũng có thể nêu rõ dữ liệu còn thiếu trước khi chuẩn bị đề xuất. Đây là phần xử lý khối lượng lớn mà con người thường mất thời gian tìm kiếm.

AI không nên tự quyết định nguồn nào là chính thức, tự mở rộng quyền hay bỏ qua bước duyệt vì câu trả lời có vẻ chắc chắn. Những quy tắc này phải do doanh nghiệp xác lập và được thực thi ngoài mô hình. Khi không có đủ bằng chứng, hành vi đúng là dừng hoặc hỏi thêm.

5. Con người có bị thay thế không?

Context Engineering làm giảm công việc tìm và chép thông tin thủ công, nhưng tăng nhu cầu về người hiểu dữ liệu và quy trình. Người nghiệp vụ phải định nghĩa doanh thu, khách hàng hoạt động hoặc hợp đồng có hiệu lực; đội dữ liệu phải bảo đảm nguồn và thời điểm; đội an toàn phải quyết định quyền.

Con người vẫn chịu trách nhiệm với quyết định tín dụng, pháp lý, nhân sự và tài chính. AI có thể rút ngắn thời gian chuẩn bị, chỉ ra ngoại lệ và lưu bằng chứng. Trách nhiệm cuối cùng không thể được chuyển cho một mô hình không hiểu đầy đủ mục tiêu và hậu quả của doanh nghiệp.

PHẦN II — NHỮNG ỨNG DỤNG THỰC TẾ

6. Tìm đúng chính sách đang có hiệu lực

Bài toán. Doanh nghiệp thường lưu nhiều phiên bản quy chế, phụ lục và email giải thích. Nhân viên dễ đọc nhầm bản cũ. AI xử lý thế nào. Hệ thống lọc theo loại tài liệu, đơn vị, ngày hiệu lực và trạng thái phê duyệt trước khi đưa đoạn liên quan cho AI.

Ví dụ. Nhân viên mua hàng hỏi ngưỡng phải đấu thầu; AI chỉ dùng quy chế đã ký và hiển thị ngày hiệu lực. Giá trị và giới hạn. Thời gian tra cứu giảm và câu trả lời có thể kiểm chứng. Nếu metadata về phiên bản sai, AI vẫn dẫn nguồn nhưng dẫn nhầm; chủ sở hữu chính sách phải xác nhận bản chuẩn.

7. Trả lời chỉ số kinh doanh theo một định nghĩa

Bài toán. Cùng cụm từ “doanh thu thuần” có thể được tính khác nhau giữa tài chính và bán hàng. AI xử lý thế nào. AI truy vấn lớp chỉ số đã được phê duyệt, kèm công thức, thời gian dữ liệu và bộ lọc áp dụng.

Ví dụ. Giám đốc vùng hỏi doanh thu tuần; hệ thống dùng số đã loại hoàn trả và ghi rõ chưa bao gồm hóa đơn điều chỉnh cuối kỳ. Giá trị và giới hạn. Giảm tranh luận về con số và tránh tạo SQL tùy ý. Lớp định nghĩa không được cập nhật sẽ chuẩn hóa một cách tính đã lỗi thời.

8. Chuẩn bị hồ sơ khách hàng trước cuộc gọi

Bài toán. Nhân viên phải mở CRM, đơn hàng, công nợ và khiếu nại ở nhiều màn hình. AI xử lý thế nào. AI nhận dạng đúng khách hàng, lấy các sự kiện liên quan trong khoảng thời gian phù hợp và tóm tắt theo mục tiêu cuộc gọi.

Ví dụ. Trước khi gọi gia hạn, nhân viên thấy hợp đồng sắp hết, hai ticket chưa đóng và xu hướng sử dụng giảm. Giá trị và giới hạn. Giảm thời gian chuẩn bị và tăng chất lượng trao đổi. Ghép nhầm định danh hoặc đưa dữ liệu nhạy cảm cho người không có quyền có thể gây hậu quả lớn.

9. Kiểm tra tồn kho có tính đến độ trễ

Bài toán. Số tồn trong báo cáo có thể chưa phản ánh giao dịch vài phút gần nhất. AI xử lý thế nào. Ngữ cảnh phải có thời điểm chụp dữ liệu, lượng đã giữ cho đơn khác và trạng thái đồng bộ từ cửa hàng.

Ví dụ. AI không trả lời “còn 20 sản phẩm” đơn thuần mà nêu 20 khả dụng lúc 10:05, trong đó 6 đang chờ xác nhận. Giá trị và giới hạn. Quyết định hứa giao hàng thực tế hơn. Không có quy tắc về độ tươi dữ liệu sẽ khiến một số chính xác về hình thức trở thành sai trong vận hành.

10. Soát hợp đồng theo playbook nội bộ

Bài toán. Luật sư phải so từng điều khoản với mẫu chuẩn và lịch sử đàm phán. AI xử lý thế nào. AI lấy đúng mẫu theo loại hợp đồng, khu vực và mức giá trị, sau đó đánh dấu điểm lệch thay vì tự đưa kết luận pháp lý.

Ví dụ. Điều khoản giới hạn trách nhiệm bị so với playbook dành cho nhà cung cấp công nghệ có dữ liệu cá nhân. Giá trị và giới hạn. Rút ngắn vòng rà soát và tập trung chuyên gia vào ngoại lệ. Không được dùng playbook của đơn vị khác hoặc coi đề xuất của AI là ý kiến pháp lý cuối cùng.

11. Hỗ trợ kỹ thuật theo đúng phiên bản sản phẩm

Bài toán. Tài liệu của nhiều phiên bản khiến câu trả lời chung chung hoặc chỉ dẫn sai thao tác. AI xử lý thế nào. Hệ thống lấy model thiết bị, phiên bản firmware, lịch sử lỗi và các hướng dẫn tương ứng trước khi AI đề xuất bước kiểm tra.

Ví dụ. Kỹ thuật viên nhận quy trình dành riêng cho máy đang vận hành thay vì hướng dẫn mới nhất nhưng không tương thích. Giá trị và giới hạn. Giảm thời gian chẩn đoán và số lần thử sai. Thông tin cấu hình không cập nhật có thể khiến hướng dẫn chính xác trên giấy nhưng nguy hiểm ngoài hiện trường.

12. Phân tích nguyên nhân biến động

Bài toán. AI dễ nêu tương quan như nguyên nhân khi không có bối cảnh về chương trình giá, mùa vụ và thay đổi kênh. AI xử lý thế nào. Context pipeline bổ sung lịch sự kiện, định nghĩa chỉ số, tập so sánh và giới hạn suy luận.

Ví dụ. Doanh thu tăng được tách thành tác động của giá, sản lượng và mở thêm cửa hàng; AI ghi rõ phần nào chỉ là giả thuyết. Giá trị và giới hạn. Lãnh đạo có điểm bắt đầu tốt hơn cho điều tra. Không nên để mô hình khẳng định quan hệ nhân quả nếu chỉ có dữ liệu quan sát.

13. Tạo đề xuất bổ sung hàng

Bài toán. Cùng một mức tồn nhưng quyết định đặt hàng phụ thuộc tốc độ bán, lead time và cam kết khuyến mãi. AI xử lý thế nào. Agent lấy nhu cầu dự báo, đơn mở, tồn khả dụng, lô đang về và chính sách tồn an toàn, rồi chuẩn bị lệnh đề xuất.

Ví dụ. SKU bán nhanh được đề nghị bổ sung sớm nhưng hệ thống dừng vì nhà cung cấp đang bị khóa chất lượng. Giá trị và giới hạn. Giảm thiếu hàng và công việc tổng hợp thủ công. Đơn mua vẫn cần người có thẩm quyền duyệt, đặc biệt khi vượt ngân sách hoặc có nhà cung cấp mới.

14. Cá nhân hóa nhưng giữ đúng sự đồng ý

Bài toán. Dữ liệu hành vi phong phú không đồng nghĩa doanh nghiệp được phép dùng cho mọi chiến dịch. AI xử lý thế nào. AI chỉ nhận thuộc tính đã được phép theo mục đích, kênh và thời hạn đồng ý của khách hàng.

Ví dụ. Hệ thống gợi ý ưu đãi từ lịch sử mua nhưng loại thông tin nhạy cảm và không gửi tới người đã từ chối tiếp thị. Giá trị và giới hạn. Cá nhân hóa có kiểm soát thay vì khai thác dữ liệu tùy tiện. Quyền đồng ý phải được kiểm tra tại thời điểm hành động, không sao chép một lần rồi dùng mãi.

15. Duy trì bộ nhớ công việc của Agent

Bài toán. Quy trình nhiều bước dễ mất dấu việc nào đã làm, kết quả nào đã được người duyệt và giả định nào đã thay đổi. AI xử lý thế nào. Hệ thống lưu trạng thái có cấu trúc, tách sự kiện thực tế khỏi ghi chú do mô hình tạo và đặt thời hạn cho thông tin tạm thời.

Ví dụ. Agent xử lý khiếu nại biết khách đã xác nhận số đơn, nhưng phải lấy lại trạng thái giao hàng mới thay vì dùng kết quả của hôm trước. Giá trị và giới hạn. Giảm lặp việc và giữ mạch xử lý. Bộ nhớ không được làm sạch sẽ khiến thông tin cũ tiếp tục chi phối quyết định mới.

16. Phát hiện xung đột giữa các nguồn

Bài toán. ERP, CRM và bảng tính có thể ghi khác nhau về cùng khách hàng hoặc đơn hàng. AI xử lý thế nào. AI so giá trị, thời gian và quyền sở hữu nguồn; xung đột được chuyển thành một trường hợp cần giải quyết thay vì tự chọn tùy ý.

Ví dụ. CRM ghi khách đang hoạt động nhưng hệ thống công nợ đã khóa; đơn hàng được giữ để nhân viên tín dụng xem xét. Giá trị và giới hạn. Sai lệch được phát hiện trước khi thành hành động. Doanh nghiệp phải quy định nguồn nào có thẩm quyền theo từng thuộc tính, không thể giao hoàn toàn cho mô hình.

17. Giảm ngữ cảnh để giảm chi phí và nhiễu

Bài toán. Đưa hàng trăm trang tài liệu vào mọi yêu cầu làm phản hồi chậm và đắt mà chưa chắc chính xác hơn. AI xử lý thế nào. Hệ thống truy xuất theo bước: tìm tài liệu ứng viên, lọc theo quyền và thời gian, xếp hạng đoạn liên quan rồi chỉ đưa phần cần thiết cho mô hình.

Ví dụ. Câu hỏi về chính sách hoàn hàng chỉ nhận ba điều khoản và dữ liệu đơn, không nhận toàn bộ sổ tay vận hành. Giá trị và giới hạn. Giảm token, tăng tốc độ và dễ kiểm chứng nguồn. Bộ lọc quá chặt có thể bỏ sót ngoại lệ; test set phải có trường hợp cần kết hợp nhiều tài liệu.

PHẦN III — AI AGENT, DỮ LIỆU VÀ KIỂM SOÁT

So sánh AI Assistant và AI Agent trong doanh nghiệp

18. AI Assistant và AI Agent khác nhau thế nào?

AI Assistant là trợ lý: nhận câu hỏi, tìm thông tin và chuẩn bị câu trả lời để một người sử dụng. AI Agent là hệ thống có thể theo đuổi một mục tiêu qua nhiều bước, chẳng hạn xác định dữ liệu cần lấy, gọi công cụ tìm kiếm nội bộ, kiểm tra quyền, so sánh kết quả rồi tạo một đề xuất trong phần mềm vận hành. Khác biệt quan trọng không nằm ở cách trò chuyện mà ở quyền hành động và khả năng duy trì trạng thái của công việc.

Trong bài toán Context Engineering, Agent có thể tự nhận diện loại yêu cầu, lấy dữ liệu được phép, kiểm tra phiên bản và chuẩn bị một phương án có dẫn nguồn. Agent có thể tự làm các bước dễ đảo ngược như tạo bản nháp hoặc mở ticket. Các hành động như phê duyệt tín dụng, gửi báo giá cam kết, sửa hồ sơ gốc hoặc đặt đơn mua phải có Human Approval, tức phê duyệt của con người.

19. Dữ liệu nào cần được đưa vào ngữ cảnh?

Ngữ cảnh tốt cần ba nhóm dữ liệu. Dữ liệu giao dịch trả lời điều gì vừa xảy ra; dữ liệu chủ như mã khách hàng, sản phẩm và tổ chức giúp ghép đúng đối tượng; dữ liệu chính sách cho biết điều gì được phép và tiêu chuẩn nào phải áp dụng. Ngoài ra còn có metadata, tức thông tin mô tả nguồn, chủ sở hữu, ngày hiệu lực và mức nhạy cảm.

Không phải dữ liệu nào cũng nên đưa vào mô hình. Hệ thống cần chọn theo mục đích, độ mới, quyền và mức liên quan. Một kiến trúc phổ biến là truy xuất theo yêu cầu: AI nhận câu hỏi, dịch thành nhu cầu dữ liệu, hệ thống quyền lọc nguồn, bộ tìm kiếm trả về các đoạn có bằng chứng, rồi mô hình mới tổng hợp câu trả lời kèm trích dẫn.

20. Vai trò của ERP, CRM, Data Warehouse và Data Platform

ERP, tức hệ thống hoạch định nguồn lực doanh nghiệp, giữ giao dịch như đơn hàng, tồn kho, hóa đơn và sổ cái. CRM, tức hệ thống quản lý quan hệ khách hàng, giữ lịch sử tương tác và cơ hội bán hàng. Data Warehouse là kho dữ liệu được tổ chức cho báo cáo và phân tích; Data Platform là tập hợp rộng hơn gồm kết nối, lưu trữ, xử lý, danh mục dữ liệu, kiểm tra chất lượng, bảo mật và các giao diện phục vụ AI.

Data Platform tạo lớp kết nối và quản trị để Agent không phải tự lần mò từng hệ thống. Nó cung cấp pipeline cập nhật, catalog để tìm tài sản, lineage để truy nguồn, lớp chỉ số dùng chung và API có kiểm soát. Nếu chỉ nối mô hình trực tiếp vào cơ sở dữ liệu, doanh nghiệp có thể có bản demo nhanh nhưng khó kiểm soát định nghĩa, tải hệ thống và quyền truy cập khi mở rộng.

21. Data Quality, quyền truy cập và bảo mật

Data Quality nghĩa là chất lượng dữ liệu. Dữ liệu phải đủ, đúng, nhất quán, hợp lệ và đến đúng lúc. Một bảng doanh thu chính xác vào cuối tháng vẫn có thể vô dụng cho quyết định giao hàng cần đưa ra trong mười phút. Mỗi trường dữ liệu đưa cho AI phải có nguồn, thời điểm cập nhật và chủ sở hữu; trường nhạy cảm cần được che hoặc loại bỏ nếu nhiệm vụ không cần đến.

Quyền của Agent phải theo nguyên tắc tối thiểu: chỉ đọc đúng nguồn cần thiết, chỉ ghi vào đúng hệ thống và chỉ trong phạm vi nhiệm vụ. Nhật ký cần ghi dữ liệu nào đã được truy cập, công cụ nào đã được gọi, kết quả trung gian và ai phê duyệt. Prompt không phải hàng rào bảo mật; quyền phải được kiểm soát bằng tài khoản dịch vụ, chính sách truy cập và bước phê duyệt trong hệ thống.

22. Đánh giá chất lượng ngữ cảnh trước khi vận hành

Bộ đánh giá phải được lấy từ công việc thật: câu hỏi bình thường, câu hỏi thiếu dữ liệu, tài liệu hết hiệu lực, hai nguồn mâu thuẫn và yêu cầu vượt quyền. Với mỗi trường hợp, doanh nghiệp ghi nguồn đúng, hành động được phép, câu trả lời tối thiểu phải có và điều kiện phải từ chối.

Không chỉ chấm câu chữ. Cần chấm độ chính xác của nguồn, độ mới, khả năng trích dẫn, tuân thủ quyền, tỷ lệ biết dừng và chi phí cho mỗi nhiệm vụ. Mỗi khi thay đổi mô hình, bộ truy xuất hoặc chính sách, bộ test phải được chạy lại để tránh sửa một lỗi nhưng tạo lỗi khác.

PHẦN IV — TRIỂN KHAI TRONG DOANH NGHIỆP

23. Bắt đầu từ một quyết định có giá trị

Nên bắt đầu từ một quyết định bị chậm vì người dùng phải tìm thông tin ở ba đến năm nguồn, nhưng hậu quả sai vẫn có thể kiểm soát bằng bước duyệt. Ví dụ phù hợp là chuẩn bị hồ sơ khách hàng, giải thích một KPI hoặc kiểm tra phiên bản chính sách.

Đề bài một trang nên nêu hiện trạng, người ra quyết định, dữ liệu đang có, dữ liệu còn thiếu, rủi ro nếu sai và tiêu chuẩn thành công. Cách làm này buộc nhóm dự án giải quyết bài toán kinh doanh trước khi chọn công cụ.

24. Ba use case đầu tiên ít rủi ro

Ba use case đầu tiên có thể là hỏi đáp chính sách có dẫn nguồn, tóm tắt hồ sơ khách hàng cho nhân viên phụ trách và phát hiện xung đột giữa hai hệ thống. Chúng đo được thời gian tìm kiếm, độ chính xác nguồn và tỷ lệ ngoại lệ, nhưng chưa cho AI quyền tự tạo cam kết với khách hàng.

Cả ba nên chạy ở chế độ đề xuất, chưa tự thực hiện hành động khó đảo ngược. Người duyệt cần ghi lý do chấp nhận hoặc từ chối; chính dữ liệu phản hồi này giúp cải thiện hệ thống và phát hiện những ngoại lệ mà nhóm kỹ thuật chưa biết.

Roadmap triển khai Context Engineering trong 90 ngày

25. Roadmap triển khai 90 ngày

Ngày 1–30 dành cho việc chốt một quy trình, đo đường cơ sở, lập bản đồ dữ liệu và quyền, đồng thời thu thập các tình huống bình thường lẫn tình huống xấu. Ngày 31–60 xây phiên bản tối thiểu, kết nối một số nguồn có kiểm soát và chạy lại các tình huống lịch sử. Mỗi lỗi phải được phân loại: thiếu dữ liệu, sai định nghĩa, lấy nhầm nguồn, suy luận sai hay hành động sai.

Ngày 61–90 hệ thống chạy song song với cách cũ trong một đơn vị đại diện. Nhóm dự án theo dõi chất lượng, thời gian xử lý, chi phí và số lần con người phải sửa. Kết thúc 90 ngày phải có quyết định mở rộng, điều chỉnh hoặc dừng; pilot không đạt vẫn có giá trị nếu giúp doanh nghiệp tránh mở rộng một thiết kế sai.

26. KPI cần đo

Nhóm KPI trọng tâm gồm tỷ lệ câu trả lời dùng đúng nguồn và đúng phiên bản; độ bao phủ trích dẫn; tỷ lệ xung đột được phát hiện; tỷ lệ từ chối đúng khi thiếu dữ liệu; thời gian hoàn thành nhiệm vụ; token và chi phí cho mỗi nhiệm vụ; số lần người dùng phải tìm lại từ đầu; và số sự cố liên quan đến quyền.

KPI phải có đường cơ sở trước triển khai và được chia theo loại nhiệm vụ, mức rủi ro, bộ phận và phiên bản hệ thống. Tổng số câu trả lời hoặc số lượt dùng không đủ chứng minh giá trị nếu người dùng vẫn phải kiểm tra lại từ đầu.

27. Những sai lầm phổ biến

Các lỗi phổ biến gồm coi vector database là toàn bộ Context Engineering, đưa mọi tài liệu vào một kho nhưng không quản lý phiên bản, không có định danh chung, cho mô hình tự viết truy vấn tùy ý và lưu lịch sử hội thoại như một nguồn sự thật. Một lỗi khác là chỉ kiểm thử câu hỏi đã biết câu trả lời mà không thử dữ liệu chậm, nguồn mâu thuẫn và yêu cầu vượt quyền.

Sai lầm chung là đánh giá bằng một buổi trình diễn đẹp, dùng dữ liệu mẫu sạch và bỏ qua trường hợp ngoại lệ. Một hệ thống đáng tin phải biết nói “không đủ dữ liệu”, biết dừng và chuyển cho đúng người thay vì luôn tạo ra câu trả lời trôi chảy.

28. Điều kiện để mở rộng

Có thể mở rộng khi nguồn quan trọng có chủ sở hữu, tỷ lệ truy xuất đúng ổn định qua nhiều tuần, chi phí trên nhiệm vụ nằm trong ngân sách và đội vận hành xử lý được lỗi. Trước khi tăng quyền Agent, doanh nghiệp cần có nhật ký đầy đủ, cảnh báo và cách thu hồi quyền ngay lập tức.

Mỗi lần chỉ nên mở rộng một chiều: thêm người dùng, thêm miền dữ liệu hoặc tăng quyền hành động. Tăng cả ba cùng lúc khiến đội vận hành không thể xác định nguyên nhân khi chất lượng giảm.

PHẦN V — TÌNH HUỐNG TỔNG THỂ VÀ TƯƠNG LAI

29. Tình huống doanh nghiệp tổng thể

Giả sử một nhà phân phối có 30.000 khách hàng doanh nghiệp. Nhân viên bán hàng muốn biết có thể nhận thêm đơn của khách A hay không, nhưng phải mở CRM, ERP, bảng công nợ và thư mục hợp đồng. Mỗi nguồn dùng một mã khác nhau; chính sách tín dụng lại có hai phiên bản đang lưu chung.

Nhóm dự án tạo mã khách hàng chuẩn, xác định ERP là nguồn công nợ, hợp đồng đã ký là nguồn điều khoản và kho chính sách chỉ công nhận bản có ngày hiệu lực. Agent lấy dữ liệu theo quyền của nhân viên, tính hạn mức còn lại, nêu rõ số liệu cập nhật lúc nào và tạo đề xuất. Nếu công nợ chậm đồng bộ, tên pháp nhân không khớp hoặc đơn vượt ngưỡng, hệ thống dừng để chuyên viên tín dụng duyệt.

30. Trước và sau khi triển khai

Trước triển khai, một yêu cầu mất 20 phút và câu trả lời phụ thuộc kinh nghiệm người xử lý. Sai lệch thường chỉ được phát hiện khi đơn đã giữ hoặc giao hàng đã cam kết. Không ai biết chính xác tài liệu nào đã được dùng trong một quyết định cũ.

Sau triển khai, phần thu thập và đối chiếu cơ bản diễn ra trong vài chục giây, nhưng kết quả luôn kèm nguồn, thời gian và điều kiện giới hạn. Nhân viên vẫn quyết định với trường hợp rủi ro; hệ thống lưu lại dữ liệu và quy tắc đã dùng để doanh nghiệp có thể kiểm tra.

31. Công việc sẽ thay đổi ra sao?

Công việc viết prompt đơn lẻ sẽ thu hẹp khi doanh nghiệp chuẩn hóa các pipeline ngữ cảnh. Nhu cầu tăng ở các vai trò hiểu giao điểm giữa nghiệp vụ, dữ liệu và kiểm soát: data steward, product owner cho dữ liệu, kỹ sư tích hợp và người thiết kế bộ đánh giá.

AI sẽ tự động hóa nhiều bước tìm kiếm, ghép hồ sơ, tóm tắt và kiểm tra quy tắc. Con người vẫn định nghĩa nguồn sự thật, phê duyệt ngoại lệ và chịu trách nhiệm với quyết định có hậu quả. Tương lai gần không phải AI biết mọi thứ, mà là AI biết chính xác mình được phép dựa vào điều gì.

32. Kết luận

Context Engineering chuyển trọng tâm từ “viết câu lệnh hay” sang “thiết kế môi trường làm việc đúng” cho AI. Prompt vẫn quan trọng, nhưng chỉ là một lớp. Dữ liệu đúng, định nghĩa rõ, quyền tối thiểu, bộ nhớ có kiểm soát và khả năng truy vết mới tạo ra hệ thống có thể dùng lâu dài.

Câu hỏi chiến lược không nên là doanh nghiệp cần prompt dài bao nhiêu, mà là: với một quyết định cụ thể, AI phải nhìn thấy nguồn nào, nguồn nào tuyệt đối không được nhìn thấy và khi nào bắt buộc phải dừng? Data cung cấp sự thật, workflow đưa sự thật vào công việc, AI xử lý ở quy mô lớn; trách nhiệm cuối cùng vẫn thuộc về con người.

Bài viết liên quan

Để mở rộng chủ đề, có thể đọc thêm bộ dữ liệu đánh giá AI Agent, cách giám sát AI Agent và cách xây dựng một nguồn số liệu thống nhất.

Tài liệu tham khảo

TechData.AI - Leading the Future.

Tham khảo các khoá học theo link: https://techdata.ai/techdata-ai-course/

Hoàng Minh.