AI Architecture cho hệ thống production #20

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: AI Architecture là bản thiết kế chia hệ thống AI thành các lớp có trách nhiệm, quyền hạn, dữ liệu vào-ra và bằng chứng rõ ràng. Nó quy định request đi đâu, policy nằm ở đâu, model được phép làm gì, lỗi bị chặn tại đâu và khi nào cần con người can thiệp.

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

• Vì sao sơ đồ app → model chưa phải kiến trúc production.
• Cách ghép chín lớp mà không giao policy, secret hay quyền thực thi cho model.
• Cách dùng một request trace, ADR và failure budget để kiểm tra bản thiết kế trước khi viết code.

1. AI Architecture là gì, và vì sao nối model vào app chưa đủ?

Một prototype có thể chỉ cần ô nhập liệu, API key và model. Người dùng hỏi, model trả lời. Khi đưa cho người dùng thật, hệ thống phải biết người này thuộc tổ chức nào, được đọc tài liệu nào, câu trả lời dựa trên phiên bản dữ liệu nào, một lần gọi tốn bao nhiêu, và nếu model timeout thì request đang ở trạng thái gì.

Đó là lúc production bắt đầu: môi trường có người dùng, dữ liệu, chi phí và sự cố thật. AI Architecture là cách ta chia trách nhiệm và nối các thành phần để hệ thống vẫn kiểm soát được khi model trả lời sai, nguồn dữ liệu cũ, tool lỗi hoặc request bị gửi lại.

Khái niệm quan trọng đầu tiên là ranh giới tin cậy. Đây là điểm dữ liệu hoặc quyền đi từ vùng tin cậy này sang vùng khác và cần được kiểm tra. Ví dụ, nội dung lấy từ internet đi vào prompt phải được coi là dữ liệu không tin cậy. Việc retrieval tìm thấy một tài liệu cũng chưa chứng minh người dùng có quyền đọc tài liệu đó.

Có thể hình dung một tòa nhà: sảnh công cộng, cửa kiểm soát, khu làm việc và phòng kỹ thuật không dùng chung chìa khóa. Phép so sánh này chỉ giúp hiểu việc chia ranh giới; nó không mô tả tính xác suất của model. Trong hệ thống thật, cùng input vẫn có thể tạo output khác, nên kiểm tra đầu ra và trace vẫn cần thiết.

Hình 1 — Production bắt đầu khi trách nhiệm được tách thành các lớp có chủ sở hữu.

Kiến trúc không phải danh sách dịch vụ cloud. Quyết định cốt lõi vẫn là: ai sở hữu policy, credential nằm đâu, state được ghi thế nào, tiêu chí pass là gì và lỗi được phép lan tới đâu. Azure Architecture Center cũng tổ chức hướng dẫn quanh workload và yêu cầu vận hành.

Ba hiểu nhầm cần bỏ: model không tự quyết định quyền; có tài liệu truy xuất chưa đồng nghĩa câu trả lời đúng; nhiều log rời rạc chưa tạo thành trace xuyên suốt.

2. Bản đồ chín lớp và các ranh giới tin cậy

Chín lớp giúp hệ thống dễ kiểm tra; một service có thể giữ nhiều lớp.

1. Experience và API edge

Đây là UI, API, xác thực, giới hạn tần suất và nơi xác định tenant. Tenant là phạm vi của một khách hàng hoặc tổ chức. Edge gắn định danh vào request đã xác thực; nó không nhờ model đoán danh tính từ câu chữ.

2. Policy và control plane

Control plane là lớp giữ policy, quyền, ngân sách, approval và quyết định cho phép. Nó trả lời: intent này có được chạy không, dữ liệu nào được truy cập, còn bao nhiêu budget, hành động nào bắt buộc người duyệt. Model không sở hữu lớp này.

3. Orchestration

Orchestration là logic điều phối thứ tự bước, state, timeout, retry và điều kiện dừng. Đoạn nào có quy tắc rõ thì dùng workflow xác định. Đoạn nào cần suy luận linh hoạt mới dùng agent loop, nhưng loop phải có giới hạn. Bài Workflow Design #19 trình bày chi tiết state, guard và evidence; bài Agent Planning #13 giải thích cách giới hạn một kế hoạch động.

4. Model gateway

Model gateway là cửa vào chung để quản lý route, model version, quota, fallback, latency và cost. App gọi gateway thay vì rải API key. Azure API Management minh họa cách tập trung policy và routing; đó là một kiến trúc tham khảo, không phải lựa chọn duy nhất.

5. Data và knowledge plane

Lớp này nạp, đánh version, lọc quyền và truy xuất dữ liệu. ACL là danh sách quyền đọc hoặc ghi. ACL phải chạy trước khi nội dung vào context. Độ mới và nguồn gốc cũng thuộc vòng đời dữ liệu. Các kiến trúc RAG tham khảo của Google Cloud cho thấy retrieval có nhiều cấu hình; không phải use case nào cũng cần RAG.

6. Tool execution plane

Execution plane gọi tool từ danh sách cho phép bằng credential có phạm vi nhỏ. Model chỉ tạo proposal; executor kiểm input, kiểm quyền và mới chạy. Tác dụng phụ là thay đổi như gửi email hoặc ghi database. Hành động này cần idempotency key, tức mã chống thực thi hai lần.

7. State và memory

Lớp state giữ run status, artifact version, checkpoint, budget và pending approval. Memory chỉ lưu dữ liệu được policy cho phép. Bài Memory Architecture #8 phân biệt run state, short-term memory và long-term memory.

8. Quality plane

Lớp chất lượng chứa schema validator, citation checker, evaluator, test set và human review. Verifier kiểm tra output theo tiêu chí đã định; nó cần nhánh unknown khi evidence không đủ.

9. Observability và operations

Lớp này theo dõi trace, latency, cost, quality result và incident. Trace là chuỗi record có cùng ID cho toàn request, gồm version, gate decision và side-effect receipt; không chứa secret.

Hình 2 — Model nằm trong kiến trúc; model không sở hữu policy, secret hay quyền thực thi.

Bảo mật, riêng tư và governance chạy ngang cả chín lớp: authentication ở edge, ACL ở retrieval, scoped credential ở executor và retention ở trace.

3. Một request đi qua hệ thống như thế nào?

Giả sử nhân viên hỏi: “Chính sách hoàn tiền hiện hành cho gói A là gì?” Request không nên nhảy thẳng tới model.

1. Edge xác thực người dùng, gắn tenant_id = DEMO-TENANT và trace_id = ARCH-20.
2. Policy phân loại đây là truy vấn read-only; write action và external action đều disabled.
3. Orchestrator tạo state RECEIVED, rồi chuyển sang RETRIEVING khi auth và budget pass.
4. Knowledge plane tìm D1, D2, D3; ACL và freshness gate chạy trước khi tạo evidence pack.
5. Model gateway chọn route primary với model version đã pin. Gateway chỉ fallback theo error class cho phép.
6. Generator nhận instruction tin cậy và evidence pack không tin cậy. Nội dung tài liệu không được nâng thành system instruction.
7. Verifier tách claim, kiểm citation và đánh trạng thái supported, unsupported hoặc unknown.
8. Nếu pass, response layer trả answer cùng source link. Nếu không, workflow repair có giới hạn hoặc chuyển human review.
9. Trace ghi gate result, version, latency, cost, error và terminal state; credential không xuất hiện trong log.

Mỗi bước nhận một contract và tạo một artifact, tức output có tên và version. Retrieval nhận tenant_id, query, as_of và trả evidence_pack@v1. Generator tạo answer@v1; verifier tạo verification@v1; orchestration mới quyết định repair hay dừng.

Hình 3 — Mỗi bước nhận một contract, tạo một artifact và để lại bằng chứng.

Checkpoint là ảnh chụp state, artifact versions, hành động đã xong, budget và pending approval. Khi worker restart, orchestration đọc checkpoint, không hỏi model đoán lại lịch sử.

AWS Generative AI Lens đặt observability, security, reliability, performance và cost trong cùng bài toán vận hành. AWS Agentic AI Lens còn nhấn mạnh quyền tự chủ có giới hạn, truy vết đầu cuối và human oversight theo rủi ro.

4. Case ARCH-20 và các failure domain cần khóa

ARCH-20 là case demo tự xây, không phải benchmark. Mục tiêu là trả lời câu hỏi chính sách bằng hai nguồn còn hiệu lực, trong budget 12 giây, tối đa một model fallback, tối đa một repair và không có external action.

Input:

Knowledge plane trả ba tài liệu. D1 còn hiệu lực và đúng ACL. D2 đúng chủ đề nhưng valid_until đã qua. D3 còn hiệu lực và đúng ACL. Freshness gate loại D2 trước khi tạo evidence_pack@v1; model chỉ thấy D1 và D3.

Route primary timeout ở giây thứ 3. Gateway kiểm error class transient_timeout, dùng cùng trace ID và fallback đúng một lần. Không retry primary vô hạn, không chạy hai route song song sau khi một route đã có kết quả.

Fallback tạo answer@v1 gồm bốn claim. Câu đoán chắc là “ngoại lệ C4 luôn áp dụng”. Câu có điều kiện đúng hơn là “C4 chỉ áp dụng khi D1 hoặc D3 hỗ trợ; nếu không, trả unknown”. Verifier gắn C4 là unsupported; repair 1/1 bỏ claim này. answer@v2 còn ba claim và hai citation hợp lệ.

Terminal record:

trace: ARCH-20
documents: D1 pass, D2 stale_excluded, D3 pass
model: primary timeout, fallback 1/1 success
quality: C4 unsupported, repair 1/1, citations 2/2
external_actions: 0
final_state: answer_ready_grounded

Hình 4 — Kiến trúc tốt không hứa hết lỗi; nó giới hạn nơi lỗi được phép lan.

Failure domain là phạm vi một lỗi có thể lan tới. D2 stale thuộc data domain và bị chặn trước model. Timeout thuộc model route domain và bị gateway hấp thụ. C4 unsupported thuộc quality domain và bị verifier chặn trước response. Ba lỗi không hợp lại thành một câu trả lời sai quyền hay một hành động ngoài ý muốn.

Fail closed nghĩa là thiếu bằng chứng hoặc quyền thì trả “chưa đủ dữ liệu”, chờ approval hoặc dừng. NIST AI RMF 1.0 là khung quản trị rủi ro xuyên vòng đời, không quy định sơ đồ chín lớp. OWASP AI Agent Security Cheat Sheet khuyến nghị least privilege, tool allowlist và input/output validation.

5. Đánh đổi production, checklist kiến trúc và bài tập ADR

Kiến trúc tốt không tối đa mọi chỉ số. Thêm verifier có thể tăng chất lượng nhưng cũng tăng độ trễ và chi phí. Chạy hai model song song giảm độ trễ nhưng có thể nhân đôi cost. Human approval giảm rủi ro cho hành động lớn nhưng không phù hợp với từng câu hỏi chỉ đọc.

Hãy viết mục tiêu đo được: claim có evidence và task success cho chất lượng; thời gian request điển hình và nhóm chậm cho độ trễ; cost/request cho chi phí; completion và recovery time cho độ tin cậy; denied access và unauthorized side effect cho bảo mật; trace coverage cho vận hành.

SLO là mục tiêu đo được cho mức phục vụ, ví dụ “95% request read-only hoàn tất dưới 8 giây trong cửa sổ 28 ngày”. Con số này chỉ là ví dụ; đội sản phẩm phải chọn từ nhu cầu và dữ liệu thật.

a. Bắt đầu từ đâu?

• Use case có terminal state và điều không được làm chưa?
• Authentication, tenant và ACL được kiểm ở ranh giới nào?
• Policy nằm trong code/control plane hay đang bị nhét vào prompt?
• Model chỉ đề xuất hay đang giữ credential và tự thực thi?
• Dữ liệu có provenance, version, freshness và deletion policy chưa?
• Workflow có timeout, retry budget, checkpoint và idempotency chưa?
• Claim quan trọng có verifier và nhánh unknown chưa?
• Side effect nào cần approval hoặc reconciliation?
• Trace có nối được input version, model, tool, gate và receipt không?
• Mỗi alert, budget và gate có owner cụ thể không?

Khi chưa trả lời được authentication, ACL hoặc side effect, nên đứng ngoài phần tích hợp tool thật. Dùng mock và dữ liệu demo trước. Bài Tool Agent #17 giúp tách proposal, policy và executor; bài Hybrid RAG #11 đi sâu vào retrieval và evidence.

b. Mẫu đối chiếu

Dùng Excalidraw hoặc Google Sheets miễn phí trong 15 phút. Vẽ chín lớp cho ARCH-20, rồi điền một ADR: bản ghi ngắn về quyết định kiến trúc, lý do và đánh đổi.

Sau đó lập run card:

Kết quả mẫu phải ghi rõ external actions 0. Chưa nối credential thật, chưa ghi production và chưa gửi dữ liệu ra ngoài. Nếu kiến trúc không thể giải thích vì sao một request được phép đi qua từng gate, sơ đồ chưa sẵn sàng để triển khai.

Hình 5 — ARCH-20 kết thúc bằng câu trả lời có hai nguồn, không tạo tác dụng phụ.

6. Tổng kết và đường học tiếp

a. Năm ý chính

• AI Architecture là bản thiết kế trách nhiệm, ranh giới, contract và evidence; không phải danh sách dịch vụ.
• Model nằm sau control plane; nó không sở hữu policy, secret hay quyền thực thi.
• Data, tool, state, quality và observability là các lớp production ngang hàng với model.
• Failure budget, checkpoint và trace giúp lỗi bị giới hạn, có thể điều tra và resume.
• ADR biến một sơ đồ đẹp thành quyết định có lý do, rủi ro, metric và owner.

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

• Vì sao ACL phải chạy trước khi tài liệu được đưa vào context?
• Model gateway khác orchestration ở trách nhiệm nào?
• Case ARCH-20 đã ngăn ba lỗi lan sang người dùng bằng các gate nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

Nếu kiểm ACL sau generation, model đã thấy dữ liệu sai quyền. Knowledge plane phải lọc tenant và ACL trước khi tạo evidence pack. Xem mục 2.

Xem gợi ý câu 2

Gateway quản lý route, model version, quota và fallback; orchestration quản lý state, thứ tự bước, retry budget và điều kiện dừng của toàn request. Xem mục 2–3.

Xem gợi ý câu 3

Freshness gate loại D2, gateway giới hạn fallback 1/1, verifier phát hiện C4 và repair gate giới hạn 1/1 trước response. Xem mục 4.

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

e. Nguồn tham khảo

• Microsoft Azure Architecture Center
• Azure — GenAI gateway reference architecture
• Google Cloud — RAG reference architectures
• AWS — Generative AI Lens
• AWS — Agentic AI Lens design principles
• NIST — AI Risk Management Framework 1.0
• OWASP — AI Agent Security Cheat Sheet

Bài trước, Workflow Design #19, tập trung vào state và transition. Bài tiếp theo, AI Automation #21, sẽ dùng kiến trúc này để tự động hóa có kiểm soát, thay vì chỉ nối thêm nhiều bước.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.