Trả lời ngắn: AI System Design thiết kế toàn bộ sản phẩm quanh một model có thể trả lời khác nhau. Hệ còn cần dữ liệu đúng, quy tắc kiểm được, công cụ giới hạn, người duyệt và cách theo dõi hoặc hoàn tác lỗi.

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

  • Vì sao “chọn model mạnh nhất” chưa phải thiết kế hệ thống.
  • Chín lớp cần có: 1 Product Contract, 2 Evals, 3 Data/Context, 4 Model Routing, 5 Tools, 6 State, 7 Guardrails, 8 Human/Operations và 9 Feedback.
  • Một request đi qua auth, context, model, tool và validation ra sao.
  • Cách dùng eval, shadow, canary, monitor và rollback để release.

Lưu ý giáo dục: Bài chỉ thiết kế use case giả trên giấy. Không gọi API, database hay tool thật. Prompt guardrail không thay cho authentication, authorization, access control, secrets management và các lớp bảo mật phần mềm.

1. AI System Design là gì?

a. Model là component, không phải sản phẩm

Một demo có thể gồm ô nhập và câu trả lời từ model. Một hệ thống thật phải biết ai đang hỏi, dữ liệu nào được phép dùng, context còn mới không, output có đúng schema không, tool nào được gọi, side effect nào cần duyệt, lỗi được xử lý ra sao và ai chịu trách nhiệm khi có sự cố.

Cùng một model, FAQ bot có thể tốt nếu nó biết từ chối khi thiếu nguồn; cũng có thể nguy hiểm nếu tự bịa chính sách hoàn tiền. Vì vậy chất lượng hệ thống không bằng chất lượng model. Nó là kết quả của model cộng data, workflow, controls và operations.

b. Deterministic shell bao probabilistic core

Model là probabilistic core: cùng một input có thể tạo output khác; confidence trong câu chữ không phải xác suất đúng. Deterministic shell là code/rule test được: schema validation, allowlist, permission, state transition, limit, idempotency, audit và rollback.

Ví dụ model đề xuất:

{"action":"refund","amount":500000,"reason":"duplicate charge"}

Shell phải kiểm user, order, currency, max amount, policy, approval và idempotency key. Model không tự biến JSON thành hoàn tiền.

c. Bắt đầu từ outcome và eval

Trước architecture, viết Product Contract: user nào, job nào, output nào, boundary nào, tiêu chí xong, SLO và owner. Sau đó tạo eval cases đại diện cho đúng, sai, thiếu dữ liệu, prompt injection, timeout và high-risk action.

OpenAI khuyên thiết lập eval để có baseline trước khi tối ưu model theo cost/latency. Nếu chưa đo “tốt” nghĩa là gì, đổi model chỉ là thử demo bằng cảm giác.

Hình 1 — Model chỉ là lõi xác suất; các contract và control bên ngoài mới biến nó thành hệ thống.

2. Chín lớp của một AI system đáng tin

Chín lớp trong bài là: 1 Product Contract, 2 Evals, 3 Data/Context, 4 Model Routing, 5 Tools, 6 State, 7 Guardrails, 8 Human/Operations và 9 Feedback. Các đề mục bên dưới ghép những lớp liên quan để giải thích ngắn gọn, nhưng mỗi số vẫn là một lớp riêng.

a. Product Contract và Evals

Product Contract ghi intended use, user, value, non-goal, risk, SLO, owner và escalation. Evals biến contract thành case: accuracy, groundedness, refusal, safety, tool correctness, latency và cost.

Một FAQ assistant có thể đặt mục tiêu: “Trả lời từ KB đã duyệt; luôn dẫn nguồn; nếu không đủ evidence thì nói không biết; p95 dưới 4 giây; không thực hiện external write.”

b. Data + Context và Model Routing

Data layer giữ nguồn, schema, quyền, lineage, freshness, retention và privacy. Context pipeline retrieve, filter, rank, dedupe, compress rồi đóng gói đúng token budget. RAG không tự sửa nguồn kém; retrieval chính xác vẫn có thể lấy tài liệu đã hết hiệu lực.

Model routing chọn model theo task/risk. Classification đơn giản có thể dùng model nhỏ; quyết định khó dùng model mạnh hơn. Routing cần fallback rõ: model timeout thì retry giới hạn, chuyển retrieval-only hoặc human; không âm thầm trả câu bịa.

c. Tools, State và Guardrails

Tool contract có tên rõ, typed input/output, timeout, error taxonomy, permission và idempotency. Read tool và write tool nên tách. State store lưu session, workflow, business state và version; model không phải database.

Guardrails là nhiều lớp: input relevance/injection, data policy, tool allowlist, output schema/content, action risk và human approval. OpenAI lưu ý guardrails phải đi cùng authentication, authorization, strict access control và security chuẩn; một classifier không đủ làm hàng rào duy nhất.

d. Human + Operations và Feedback

Human không chỉ là nút “approve”. Cần queue, priority, payload bàn giao, SLA và quyền quyết định. Operations gồm deploy, config/model version, secrets, monitoring, incident, rollback, backup và decommission.

Feedback không phải nút thumbs-up vô nghĩa. Nó cần request ID, loại lỗi, evidence và outcome thật để tạo eval/regression mới. NIST AI RMF tổ chức công việc qua Govern, Map, Measure, Manage xuyên vòng đời, nhấn mạnh risk management là quá trình liên tục.

3. Một request đi từ input đến output và feedback ra sao?

a. Request lifecycle mười bước

  1. Request ID: tạo correlation ID và trace.
  2. Auth: xác minh identity, tenant, role.
  3. Input policy: kiểm scope, length, injection, sensitive data.
  4. Context: retrieve nguồn được phép, kiểm freshness/provenance.
  5. Route: chọn workflow/model theo intent và risk.
  6. Generate: model tạo answer hoặc tool intent có schema.
  7. Tool gate: validate permission, business rule, approval.
  8. Output gate: kiểm groundedness, citation, format, privacy.
  9. Respond/act: trả lời hoặc thực hiện side effect idempotent.
  10. Observe: lưu trace, metric, feedback và eval sample.

Hình 2 — Mỗi bước có contract và trạng thái; model không được đi tắt từ input tới side effect.

b. Ví dụ FAQ thư viện

User hỏi: “Tôi được mượn sách bao nhiêu ngày?” Auth cho phép đọc. Retriever lấy policy v3 còn hiệu lực và một policy v1 đã hết hạn. Context filter loại v1. Model trả “14 ngày” kèm citation v3. Output gate kiểm câu trả lời được nguồn hỗ trợ.

Nếu chỉ tìm thấy v1, kết quả đúng không phải đoán 14 hay 21 ngày. Hệ thống trả: “Mình chưa tìm thấy chính sách còn hiệu lực; vui lòng hỏi thủ thư”, đồng thời log fresh_source_missing.

Đây là khác biệt giữa:

  • Model failure: model dùng sai nguồn dù context đúng.
  • System failure: pipeline đưa tài liệu hết hạn hoặc validator không chạy.
  • Business failure: trả đúng policy nhưng user vẫn không giải quyết được việc.

c. Failure contract

Mỗi dependency cần timeout, retryable/non-retryable error, fallback và owner. Ví dụ:

Failure Không nên Nên
Model timeout retry vô hạn tối đa 2, rồi fallback/human
Retrieval rỗng yêu cầu model tự biết abstain và hỏi thêm
Tool response unknown gọi lại bằng ID mới query state theo idempotency key
Output sai schema parse “gần đúng” reject/repair giới hạn

Azure Well-Architected nhắc AI workload vẫn có các yêu cầu reliability như hệ thống khác và nên cô lập component để tránh cascading failure. AI không miễn trừ distributed-systems engineering.

4. Trade-off và lỗi phổ biến: model-first, demo-first, fail-open

a. Năm trade-off phải ghi ra

  1. Quality ↔ latency: reasoning/retrieval nhiều bước thường chậm hơn.
  2. Quality ↔ cost: context dài, model lớn, multi-agent tăng tiền.
  3. Personalization ↔ privacy: nhớ nhiều tạo value nhưng tăng data risk.
  4. Autonomy ↔ control: nhiều quyền giảm thao tác nhưng tăng impact lỗi.
  5. Availability ↔ safety: fallback mở giữ uptime nhưng có thể trả sai.

Không có điểm tối ưu chung. Use case y tế, thanh toán hoặc xoá dữ liệu cần control/human cao hơn FAQ read-only.

b. Tám lỗi phổ biến

  • Model-first: chọn model rồi mới tìm vấn đề.
  • Demo-first: happy path đẹp nhưng không test failure.
  • RAG-everywhere: thêm retrieval dù dữ liệu/rule đủ deterministic.
  • Shared mutable state: model và tool ghi chung không version.
  • Permission broad: một credential dùng cho mọi tool.
  • Eval cuối dự án: không có baseline để so.
  • Silent fallback: lỗi nhưng hệ thống giả vờ thành công.
  • Vanity metric: chỉ đo thumbs-up, không đo task outcome/risk.

Một model mới tăng groundedness 2% nhưng p95 từ 3 lên 10 giây và cost gấp bốn có thể không đạt Product Contract. “Thông minh hơn” không đồng nghĩa “phù hợp hơn”.

c. Checklist thiết kế và production

  • User/job/non-goal, risk tier, owner và SLO rõ?
  • Eval suite có happy, edge, adversarial và incident case?
  • Data/context có schema, permission, freshness, lineage?
  • Model route, token budget, timeout và fallback rõ?
  • Tool typed, least privilege, approval và idempotency?
  • State có version, lifecycle và retention?
  • Guardrail bao input, output, tool/action và privacy?
  • Trace có request/model/prompt/context/tool/config version?
  • Release có shadow, canary, monitor và rollback?
  • Incident, human escalation, backup và decommission đã diễn tập?

5. Bài tập 15 phút: vẽ System Card cho trợ lý FAQ

a. Chuẩn bị

Dùng Markdown hoặc Sheet. Tạo KB giả gồm 3 policy và 8 câu hỏi; một policy đánh dấu expired. Hệ thống local-only, read-only, không API.

b. Bốn bước

  1. Viết Product Contract và 3 SLO: groundedness, p95 latency, cost/request.
  2. Vẽ chín lớp; đánh dấu deterministic hay probabilistic.
  3. Viết request trace mười bước cho một câu hỏi.
  4. Tạo 5 eval: có nguồn, thiếu nguồn, nguồn cũ, injection, model timeout.

c. Mẫu đối chiếu

Input/risk Shell/model action Eval/next state
KB có nguồn mới retrieve→answer+citation grounded pass
Không có evidence abstain, hỏi lại hallucination gate pass
Chỉ có policy expired không dùng; gọi human freshness pass
Yêu cầu external write auth/approval không có blocked

d. Điểm dừng

Bạn hoàn thành khi System Card chỉ được: dữ liệu nào vào, model được quyết gì, shell chặn gì, failure đi đâu và metric nào quyết release. Không cần code. Nếu không viết được eval, quay lại Product Contract.

6. Tổng kết: thiết kế quanh uncertainty, không quanh demo

a. Năm ý chính

  • Model là probabilistic core, không phải toàn hệ thống.
  • Deterministic shell giữ schema, quyền, state và side effect.
  • Product Contract và evals phải có trước tối ưu architecture.
  • Reliability cần failure contract, observability, human và rollback.
  • Release bằng evidence: offline eval→shadow→canary→monitor.

Hình 3 — Incident không chỉ để chữa cháy; nó phải trở thành eval mới ngăn tái phát.

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

  • Vì sao prompt guardrail không thay access control?
  • Khi retrieval không có nguồn mới, nên fallback thế nào?
  • Model score tăng có đủ để promote không?
  • Incident nên quay lại bước nào?

c. Gợi ý đáp án

Xem gợi ý câu 1Prompt là input cho model và có thể bị bypass; access control phải được code/hạ tầng thực thi ngoài model. Xem mục 2.
Xem gợi ý câu 2Abstain, hỏi thêm hoặc chuyển human/retrieval-only theo contract; không yêu cầu model tự nhớ. Xem mục 3.
Xem gợi ý câu 3Chưa đủ. Cần đạt quality, latency, cost, safety và reliability SLO trên shadow/canary. Xem mục 4.
Xem gợi ý câu 4Ghi trace/evidence, sửa root cause, thêm regression eval rồi chạy lại release loop. Xem mục 6.

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

Thuật ngữ Giải thích ngắn
Product Contract User, outcome, boundary, SLO và owner.
Deterministic Shell Code/rule giữ control test được.
Probabilistic Core Model tạo output có uncertainty.
Context Pipeline Retrieve, lọc và đóng gói context.
State Store Lưu state có version/lifecycle.
Guardrail Kiểm input, output, tool và action.
Eval Bộ case đo quality và risk.
SLO Mục tiêu quality/reliability/latency/cost.
Observability Trace, log, metric để hiểu hệ thống.
Rollback Quay về version/config an toàn.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Multi-Agent Workflow #48 để hiểu task graph và handoff contract trong một subsystem. Bài cuối là Framework xây dựng AI Agent từ Zero đến Hero #50 — gom prompt, context, harness, agentic loop và system operations thành lộ trình build hoàn chỉnh.

Nhắc lại giáo dục: AI System Design không kết thúc ở câu trả lời hay. Hệ thống phải đạt outcome trong giới hạn quality, latency, cost, privacy và risk; thất bại phải quan sát được, side effect phải kiểm soát được, và luôn có owner cùng đường rollback.