AI Knowledge Map: Prompt đến Production #1

Trả lời ngắn: Hệ thống AI không chỉ là prompt hay model, mà là cách ghép nhiệm vụ, context, dữ liệu, công cụ, quy trình và lớp kiểm soát để tạo kết quả có thể kiểm tra. Bản đồ từ prompt đến production cho biết từng lớp làm gì, lỗi nằm ở đâu và lúc nào cần người thật can thiệp.

Đọc xong, bạn sẽ hiểu:

• Vì sao prompt hay vẫn có thể cho kết quả sai.
• Ranh giới giữa context, retrieval, tool, workflow và agent.
• Evaluation, guardrail và observability bắt lỗi gì.
• Cách phác thảo AI system bằng bảng kiểm 15 phút.

Lưu ý giáo dục: Bài viết giúp bạn hiểu cách nhìn một hệ thống AI, không phải lời khuyên mua bán, cam kết hiệu quả hay bảo đảm hệ thống an toàn tuyệt đối. Ví dụ trong bài dùng dữ liệu giả định; không đưa dữ liệu riêng tư, API key hoặc quyền production vào bài tập.

1. AI Knowledge Map bắt đầu từ nhiệm vụ, không từ prompt

a. Vì sao prompt hay vẫn chưa đủ

Bạn yêu cầu một trợ lý viết câu trả lời cho khách hàng: “Hãy trả lời lịch sự về điều kiện hoàn tiền”. Câu lệnh khá rõ, nhưng câu trả lời vẫn có thể sai nếu trợ lý không có chính sách hoàn tiền mới nhất, không biết đơn hàng nào đang được hỏi hoặc không biết trường hợp nào phải chuyển cho nhân viên.

Đây là lỗi nhìn prompt như toàn bộ sản phẩm. Prompt chỉ dẫn mục tiêu, giới hạn và dạng kết quả; nó không tự cung cấp dữ liệu mới, quyền truy cập hay người kiểm tra.

b. Bản đồ sáu lớp từ yêu cầu đến production

Hãy bắt đầu bằng nhiệm vụ của người dùng, rồi đi qua sáu lớp:

1. Nhiệm vụ: Người dùng cần hoàn thành việc gì, với tiêu chí nào?
2. Prompt và model: Hệ thống hướng dẫn và tạo câu trả lời bằng cách nào?
3. Context và retrieval: Model được xem thông tin nào trong lần chạy này?
4. Tools và workflow: Hệ thống được đọc, tính toán hoặc thay đổi dữ liệu ở đâu?
5. Evaluation và guardrails: Output và hành động được chấm, chặn hoặc yêu cầu duyệt ra sao?
6. Observability và governance: Ai theo dõi, điều tra, chịu trách nhiệm và đưa phiên bản về trạng thái trước đó?

Bản đồ không bảo đảm kết quả đúng; nó mở rộng câu hỏi ngoài “viết prompt thế nào”. Hệ thống gửi email, hoàn tiền hoặc sửa dữ liệu cần quyền, log, approval và đường lui.

Hình 1 — Một hệ thống AI cần nhiều lớp kiểm tra nối tiếp, không chỉ một prompt hay một model.

c. Bản đồ không đồng nghĩa với tự động hóa mọi thứ

Một bản đồ tốt cũng có thể chỉ ra rằng không cần agent. Nhiệm vụ có bước cố định thường hợp với workflow tuần tự; dữ liệu thiếu hoặc hành động khó đảo ngược nên kết thúc ở “chuyển cho người thật”.

2. Prompt, model, context và retrieval làm nhiệm vụ gì?

a. Prompt nói hệ thống cần làm gì

Một prompt production thường cần nói rõ mục tiêu, đối tượng nhận output, giới hạn, format và điều kiện dừng. Ví dụ, thay vì chỉ viết “trả lời khách hàng”, có thể ghi: “Tóm tắt điều kiện trong chính sách được cung cấp, nêu phần còn thiếu và không tự hứa hoàn tiền nếu chưa đủ dữ liệu”.

Prompt giúp hành vi nhất quán hơn, nhưng câu chữ không thể thay cho nguồn dữ liệu hoặc quyền kiểm chứng. Việc thêm mười dòng tính từ như “thông minh, chính xác, chuyên nghiệp” không tự tạo ra policy mới.

b. Model tạo output nhưng không tự biết dữ liệu mới nhất

Model nhận input và tạo output theo năng lực đã huấn luyện. Model có thể viết, phân loại, tóm tắt hoặc gọi tool theo thiết kế, nhưng không phải toàn bộ ứng dụng và không mặc nhiên biết dữ liệu nội bộ mới nhất.

Ví dụ, một model có thể viết câu “đơn này được hoàn tiền trong bảy ngày”. Muốn câu đó đáng tin hơn, hệ thống phải đưa đúng chính sách, ngày hiệu lực và trạng thái đơn hàng vào context. Context là thông tin được đưa vào một lần chạy để model sử dụng khi trả lời hoặc hành động.

c. Retrieval và RAG đưa nguồn liên quan vào đúng lúc

Retrieval là bước tìm phần thông tin liên quan rồi đưa phần đó vào context. RAG là cách kết hợp retrieval với generation để model tạo câu trả lời dựa trên nguồn vừa được chọn. RAG không biến mọi nguồn trong kho thành sự thật; nếu tài liệu cũ hoặc bộ chọn sai đoạn, output vẫn có thể sai.

Trong ví dụ hoàn tiền, retrieval có thể tìm điều khoản “đơn hàng lỗi do vận chuyển”. Nên kèm tên tài liệu hoặc phiên bản để reviewer biết căn cứ. Không tìm được policy phù hợp thì chuyển fallback, không bịa điều khoản.

Hình 2 — Retrieval chỉ có ích khi nguồn phù hợp được đưa vào đúng lần chạy và còn đủ căn cứ.

d. Context tốt vẫn có giới hạn

Nhét toàn bộ thư mục vào prompt không làm context tốt hơn: thông tin thừa có thể tăng chi phí, độ trễ và che mất quy tắc. Hãy xác định nguồn cần dùng, nguồn có thể mâu thuẫn và ngày hết hiệu lực.

3. Tools, workflow và human approval biến câu trả lời thành hành động

a. Tool là cổng gọi chức năng bên ngoài

Tool là hàm hoặc dịch vụ ngoài được gọi theo schema và quyền hạn. Tool có thể đọc đơn hàng, tra tỷ giá, tạo bản nháp hoặc tính toán; được model gọi không có nghĩa là an toàn.

Trong trợ lý hoàn tiền, tool get_order chỉ đọc mã đơn và trạng thái. Một tool issue_refund có quyền thay đổi tiền cần phạm vi hẹp hơn, giới hạn số tiền, kiểm tra người dùng và có thể yêu cầu human approval. Tên tool rõ ràng, input có kiểu dữ liệu và output có lỗi có thể đọc sẽ giúp reviewer kiểm tra dễ hơn.

b. Workflow khác agent ở quyền chọn bước

Workflow là chuỗi bước, nhánh, retry và điểm dừng được thiết kế trước. Ví dụ: nhận câu hỏi → tìm policy → lấy trạng thái đơn → so điều kiện → tạo bản nháp → chờ duyệt. Người thiết kế biết bước nào chạy trước, bước nào bị bỏ qua và lỗi đi về đâu.

Agent là thành phần có thể chọn bước hoặc tool trong phạm vi policy được cấp. Agent phù hợp khi đường đi thay đổi theo tình huống, nhưng quyền tự chọn cũng làm tăng số trường hợp cần đánh giá. Workflow có bước định trước; agent có quyền chọn bước trong biên đã giới hạn. Hai cách này không phải một từ dùng thay cho nhau.

c. Human approval giữ quyền ở hành động rủi ro

Human approval là điểm người có quyền xem và xác nhận trước hành động rủi ro. Ví dụ, trợ lý được phép tạo bản nháp hoàn tiền nhưng không được tự gửi lệnh hoàn tiền nếu đơn vượt ngưỡng hoặc policy có ngoại lệ.

Điểm duyệt phải hiển thị input, nguồn, tool arguments, output, cảnh báo và lý do dừng; chỉ thấy “AI đề xuất hoàn tiền” là cú nhấp mù. OpenAI cũng tách agent, tool, orchestration, guardrail, state và approval thành các capability cần thiết kế. OpenAI Agents SDK

Hình 3 — Quyền gọi tool không đồng nghĩa với quyền tự duyệt hành động.

d. Quyền hành động phải nhỏ hơn nhu cầu tưởng tượng

Một sai lầm phổ biến là cấp cho agent quyền đọc và ghi toàn bộ hệ thống “để khỏi thiếu”. Hãy giới hạn bảng, endpoint và bản ghi cần thiết; thêm timeout, retry và idempotency khi gọi lại.

4. Evaluation, guardrails và observability bắt lỗi ở đâu?

a. Evaluation đo output bằng test case và rubric

Evaluation là cách dùng test case và rubric để đo output theo tiêu chí định trước. Rubric có thể chấm câu trả lời có bám policy không, có trích đúng nguồn không, có nhận ra thiếu dữ liệu không và có chuyển người thật đúng lúc không.

HTTP 200 hoặc chạy nhanh chưa chứng minh output đúng. Test set nên có case bình thường, thiếu dữ liệu, mâu thuẫn và chỉ dẫn nguy hiểm; artifact AI cũng cần qua Reviewer và validator trước release.

b. Guardrails giới hạn input, output và hành động

Guardrail là quy tắc hoặc bộ lọc giới hạn input, output hay hành động không được phép. Guardrail có thể chặn dữ liệu nhạy cảm trước model, kiểm output trước khi gửi, hoặc từ chối tool call thiếu quyền.

Guardrail không phải chiếc khiên tuyệt đối: có thể bỏ sót cách diễn đạt mới, bắt nhầm câu hợp lệ hoặc chặn quá nhiều. Vì thế cần test, log và cách xử lý khi bị chặn.

c. Observability giúp dựng lại một run

Observability là khả năng hiểu một lần chạy qua log, metric và trace cùng các tín hiệu chất lượng. Log là bản ghi sự kiện; metric là con số theo dõi xu hướng như độ trễ, lỗi hoặc token; trace là chuỗi liên kết request qua model, retrieval và tool.

Với AI, trace nên cho biết nguồn retrieval, tool nào đã gọi, quyền nào được dùng, output nào bị guardrail chặn và người nào đã duyệt. Microsoft Learn khuyến nghị mở rộng log, metric và trace bằng các tín hiệu AI-native, đồng thời dùng evaluation để theo dõi chất lượng và an toàn. Microsoft Learn về AI observability

Security cũng không chỉ nằm ở prompt. Google Cloud mô tả lớp bảo vệ ứng dụng, dữ liệu và hạ tầng để xử lý các rủi ro như prompt injection, rò rỉ dữ liệu và quyền hạ tầng quá rộng. Google Cloud về production AI security

Hình 4 — Đo chất lượng và dựng lại một run là hai việc liên quan nhưng khác nhau.

d. Governance trả lời câu hỏi “ai chịu trách nhiệm?”

Governance là các quy tắc về ownership, quyền, audit, dữ liệu và quyết định chịu trách nhiệm. Một hệ thống production cần biết ai duyệt thay đổi prompt, ai sở hữu test set, ai nhận cảnh báo và ai có quyền rollback.

NIST AI RMF là khung tự nguyện quản lý rủi ro trong toàn vòng đời AI. Khung biến câu hỏi “AI có an toàn không?” thành các hoạt động govern, map, measure và manage có thể xem lại. NIST AI Risk Management Framework

5. Checklist phác thảo AI system trong 15 phút

a. Bảy câu hỏi theo thứ tự

Dùng bảng dưới đây để biến ý tưởng thành bản phác thảo có thể kiểm tra:

1. Người dùng đang cố hoàn thành việc gì, kết quả đạt nghĩa là gì?
2. Prompt và model chịu trách nhiệm phần nào, giới hạn phần nào?
3. Context và retrieval lấy nguồn nào, phiên bản nào, khi nào hết hạn?
4. Tool được phép đọc hoặc ghi gì, input nào bị từ chối?
5. Bước nào là workflow cố định, bước nào mới cần quyền tự chọn của agent?
6. Evaluation, rubric và guardrail sẽ bắt lỗi nào trước khi output đi tiếp?
7. Log, metric, trace, owner, fallback và rollback nằm ở đâu?

Chưa trả lời được câu 3 chưa có nghĩa model kém; chưa trả lời được câu 4 hoặc 6 thì không cấp quyền thật. Chưa có owner và đường lui thì giữ prototype đọc-only.

b. Khi nào phải đứng lại

Hãy dừng thiết kế hoặc dừng release khi có một trong các dấu hiệu sau:

• Không xác định được nguồn nào là căn cứ và nguồn nào đã hết hiệu lực.
• Không có test case đại diện cho lỗi thường gặp và tình huống xấu.
• Agent có quyền rộng hơn nhiệm vụ, không có timeout hoặc không biết gọi lại có gây trùng hành động không.
• Reviewer không thấy được nguồn, tool arguments, cảnh báo hoặc lý do hệ thống tự tin.
• Không có người chịu trách nhiệm, audit trail, fallback hoặc rollback.

Đứng lại là tín hiệu cần sửa contract hoặc thu hẹp phạm vi.

c. Practice Bridge và mẫu đã điền

Dùng Google Sheets hoặc một ứng dụng ghi chú miễn phí. Không cần API key, không kết nối dữ liệu thật và không triển khai. Chọn tác vụ giả định: “trợ lý trả lời điều kiện hoàn tiền”. Điền bảy hàng trong 15 phút; mục tiêu là nhìn thấy lỗ hổng, không phải tạo một agent chạy thật.

Mẫu đối chiếu

Mẫu này cho thấy các lỗ hổng về acceptance criteria, freshness check và approval test. Chưa cấp quyền gửi email, hoàn tiền hay thay đổi dữ liệu; bảng chỉ là artifact giáo dục.

Hình 5 — Bảng map biến ý tưởng AI thành câu hỏi có owner, trạng thái và điểm dừng.

6. Tổng kết: map đủ lớp trước khi gọi là production

a. Năm ý chính

• Hệ thống AI ghép model, context, dữ liệu, tools, workflow và kiểm soát cho một nhiệm vụ.
• Prompt nêu việc cần làm; context và retrieval cung cấp căn cứ của lần chạy.
• Workflow có bước định trước; agent chọn bước trong giới hạn; human approval giữ quyền ở hành động rủi ro.
• Evaluation và guardrails kiểm tra; observability và governance giúp điều tra, chịu trách nhiệm, sửa phiên bản.
• Trước production, phải có nguồn, quyền, test, owner, fallback và rollback; thiếu thì thu hẹp hoặc dừng.

b. Câu hỏi tự kiểm tra

• Vì sao prompt rõ vẫn có thể sai chính sách hoàn tiền?
• Retrieval và RAG giúp gì, không tự bảo đảm điều gì?
• Workflow khác agent ở quyền chọn bước nào?
• Vì sao log, metric, trace không thay evaluation?

c. Gợi ý đáp án

Xem gợi ý câu 1

Prompt không tự cung cấp policy, trạng thái đơn hoặc quyền chuyển người thật; cần context, retrieval và điểm kiểm. Xem lại mục 1.

Xem gợi ý câu 2

Retrieval tìm nguồn để đưa vào context; RAG kết hợp bước đó với generation. Nguồn cũ hoặc chọn sai vẫn có thể sai. Xem lại mục 2.

Xem gợi ý câu 3

Workflow chạy chuỗi bước định trước; agent chọn bước hoặc tool trong policy. Xem lại mục 3.

Xem gợi ý câu 4

Log, metric, trace cho biết run; evaluation chấm output theo test case và rubric. Cần cả hai lớp. Xem lại mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• OpenAI Agents SDK — agent, tools, orchestration, guardrails, state và tracing.
• Microsoft Learn: Observability for Generative AI and agentic AI systems — AI-native logs, metrics, traces và evaluation.
• Google Cloud: Building a Production-Ready AI Security Foundation — defense-in-depth cho application, data và infrastructure.
• NIST AI Risk Management Framework — quản lý rủi ro và trustworthiness theo vòng đời.

f. Học tiếp gì?

Tiếp: #2. Thiết kế tiếp: #3 → #4 → #5 → #6.

Phase 1: #2 → #3 → #4 → #5 → #6.

Lưu ý giáo dục: Bản đồ AI không thay thế kiểm thử, review bảo mật, phê duyệt hoặc rollback. Giữ prototype nhỏ và đọc-only cho tới khi các gate có bằng chứng.