Chương 60. AI Application Architecture

Từ chương này, ta bước sang một phần mới:

Các ranh giới kiến trúc hiện đại.

Những chương trước đã nói nhiều về nền tảng chung:

API.
Database.
Queue.
Cache.
Microservices.
Observability.
Testing.
Deploy an toàn.

Nhưng vài năm gần đây, một loại ứng dụng mới xuất hiện rất mạnh:

AI applications.

Không phải chỉ là:

Gọi thêm một API AI.

Một AI app tốt cần nhiều lớp thiết kế riêng:

Prompt.
Model provider.
Context.
Retrieval.
Evaluation.
Cost control.
Latency control.
Safety.
Observability.
Fallback.
Human review.

Nếu chỉ coi AI như một hàm:

input -> model -> output

ta sẽ bỏ sót rất nhiều thứ quan trọng.

Thông điệp chính của chương:

> AI app không chỉ là app truyền thống gắn thêm model. AI app là hệ thống có một thành phần không deterministic ở giữa, nên kiến trúc phải kiểm soát chất lượng, context, chi phí, độ trễ, an toàn và khả năng quan sát ngay từ đầu.

---

60.1. Một tình huống: AI Judge nhìn đơn giản nhưng không đơn giản

Hãy quay lại AI Judge.

Nhìn bề ngoài, bài toán có vẻ rất dễ:

Học sinh nộp bài.
Gửi bài cho AI.
AI trả điểm và feedback.
Lưu kết quả.
Hiển thị cho giáo viên/học sinh.

Nếu viết rất đơn giản, ta có thể tưởng kiến trúc chỉ là:

Backend -> Gemini API -> Database

Nhưng production sẽ nhanh chóng hỏi những câu khó hơn:

Prompt version nào đã chấm bài này?
Model nào đã được dùng?
Rubric nào đã được đưa vào context?
Nếu AI trả JSON hỏng thì sao?
Nếu AI chấm lệch thì phát hiện thế nào?
Nếu output mỗi lần hơi khác nhau thì test bằng gì?
Nếu bài quá dài vượt context thì sao?
Nếu provider chậm thì fallback thế nào?
Nếu cost tăng gấp đôi thì ai biết?
Nếu AI sinh feedback không phù hợp thì chặn ở đâu?
Nếu giáo viên sửa điểm thủ công thì dữ liệu nào là chính thức?

Đây là lý do AI application architecture cần một lớp tư duy riêng.

Model chỉ là một phần.

Phần quanh model mới làm ứng dụng đủ tin cậy để dùng thật.

---

60.2. AI app khác app truyền thống ở đâu?

App truyền thống thường có logic deterministic hơn.

Ví dụ:

Nếu user nhập đúng mật khẩu, đăng nhập thành công.
Nếu tài khoản không đủ tiền, giao dịch bị từ chối.
Nếu bài nộp sau deadline, đánh dấu late.

Cùng input, cùng code, thường ra cùng output.

AI app thì khác.

Với model sinh ngôn ngữ:

Cùng một bài làm.
Cùng một rubric.
Cùng một prompt.
Model có thể trả feedback hơi khác.
Điểm có thể lệch nhẹ nếu cấu hình không chặt.
Format có thể sai nếu prompt/schema không tốt.

Điều này không có nghĩa AI app không đáng tin.

Nhưng nó có nghĩa là ta không thể thiết kế nó như một hàm tính toán bình thường.

Ta phải thêm các lớp kiểm soát:

Schema output.
Validation.
Retry có kiểm soát.
Evaluation.
Human review.
Prompt versioning.
Model observability.
Cost guardrail.
Safety filtering.

AI app không chỉ cần code đúng.

Nó cần hành vi của model nằm trong vùng chấp nhận được.

---

60.3. Output không deterministic là vấn đề kiến trúc

Non-deterministic nghĩa là output không luôn giống hệt nhau.

Trong AI Judge, điều này có thể xuất hiện như:

Lần 1: score = 8.0, feedback ngắn.
Lần 2: score = 8.5, feedback dài hơn.
Lần 3: score = 8.0, nhưng thiếu một nhận xét quan trọng.

Nếu AI chỉ dùng để gợi ý, sai lệch nhỏ có thể chấp nhận được.

Nếu AI dùng để chấm điểm chính thức, sai lệch này nghiêm trọng hơn.

Vậy kiến trúc phải hỏi:

Output AI là gợi ý hay quyết định chính thức?
Có cần human review không?
Có ngưỡng confidence không?
Có kiểm tra format không?
Có kiểm tra consistency không?
Có lưu lại input/prompt/model để audit không?
Có chạy evaluation trước khi đổi prompt/model không?

Không deterministic không phải lỗi.

Nó là đặc tính.

Kiến trúc tốt không phủ nhận đặc tính đó.

Kiến trúc tốt bao quanh nó bằng cơ chế kiểm soát.

---

60.4. Đừng để model là source of truth

Một lỗi tư duy phổ biến:

AI nói gì thì hệ thống tin luôn.

Trong hệ thống thật, model không nên là source of truth tuyệt đối.

Ví dụ AI trả:

{
  "score": 11,
  "feedback": "Excellent"
}

Nếu thang điểm là 0 đến 10, hệ thống không được lưu thẳng score = 11.

Phải có validation:

Score phải nằm trong 0..10.
Feedback không được rỗng.
Output phải đúng schema.
Nếu thiếu field quan trọng, chuyển needs_review hoặc retry.

AI output là đầu vào cho hệ thống.

Không phải sự thật cuối cùng.

Source of truth có thể là:

Submission gốc.
Rubric chính thức.
Prompt/model version.
Grading result đã validate.
Giáo viên duyệt cuối cùng nếu có.
Audit log.

AI app tốt luôn có lớp biến output model thành dữ liệu nghiệp vụ có kiểm soát.

---

60.5. Kiến trúc tối thiểu của một AI app

Một AI app production thường có nhiều lớp hơn ta tưởng.

Ví dụ:

User request
-> Application service
-> Policy/permission
-> Context builder
-> Retrieval nếu cần
-> Prompt builder
-> Model gateway
-> Model provider
-> Output parser
-> Validator
-> Business decision
-> Persistence
-> Observability
-> Evaluation/feedback loop

Không phải app nào cũng cần đủ mọi lớp ngay từ ngày đầu.

Nhưng các câu hỏi nên có từ đầu:

Context lấy từ đâu?
Prompt version là gì?
Model nào được gọi?
Output được validate thế nào?
Khi model lỗi thì sao?
Cost được đo thế nào?
Ai có thể xem dữ liệu prompt/response?
Kết quả AI có cần review không?

Nếu không trả lời sớm, về sau sửa rất mệt.

Vì AI behavior thường chui vào nhiều nơi:

Business logic.
UI.
Data model.
Queue.
Monitoring.
Support.
Compliance.

---

60.6. Model provider là gì?

Model provider là bên cung cấp model.

Ví dụ:

OpenAI.
Google Gemini.
Anthropic.
Mistral.
AWS Bedrock.
Azure OpenAI.
Model self-hosted.

Provider khác nhau ở:

Model quality.
Latency.
Cost.
Context window.
Rate limit.
API format.
Safety policy.
Region/data policy.
Tool calling support.
Structured output support.
Uptime.
Enterprise features.

Với app nhỏ, gọi thẳng provider từ backend có thể ổn.

Nhưng khi AI trở thành phần quan trọng, ta thường cần một lớp riêng:

Model gateway.

Model gateway không phải vì kiến trúc cho đẹp.

Nó giúp ta quản lý nhiều provider/model một cách có kiểm soát.

---

60.7. Model gateway là gì?

Model gateway là lớp trung gian giữa ứng dụng và model providers.

Thay vì mọi service gọi trực tiếp Gemini/OpenAI/Anthropic, chúng gọi:

Internal Model Gateway

Gateway chịu trách nhiệm:

Chọn provider/model.
Gắn prompt version.
Áp rate limit.
Áp timeout.
Retry có kiểm soát.
Fallback.
Log metadata.
Ẩn API key provider.
Đo latency/cost/token.
Chuẩn hóa response.
Áp policy bảo mật.

Ví dụ:

Grading Service gọi gateway: grade_essay(task)
Gateway chọn gemini-xyz với prompt v12.
Nếu provider timeout nhiều, gateway giảm traffic hoặc fallback.
Gateway trả output chuẩn cho Grading Service.

Lợi ích là app không bị dính quá chặt với một provider.

Nếu ngày mai đổi model, ta không muốn sửa 20 chỗ trong codebase.

Ta muốn đổi ở một lớp có quan sát, có rollout, có guardrail.

---

60.8. Khi nào cần model gateway?

Không phải app nào cũng cần gateway riêng ngay.

Nếu chỉ có một tính năng AI nhỏ:

Tóm tắt nội dung phụ.
Gợi ý tiêu đề.
Sinh mô tả ngắn.

gọi provider qua một service/module nội bộ đơn giản là đủ.

Nhưng nên cân nhắc gateway khi:

Nhiều service cùng gọi model.
Có nhiều provider/model.
Cost AI lớn.
Latency quan trọng.
Cần fallback.
Cần audit prompt/response.
Cần policy chung.
Cần rate limit theo tenant/user.
Cần prompt/model versioning nghiêm túc.

Với AI Judge, model gateway đáng cân nhắc khá sớm.

Vì chấm bài là core workflow.

Nếu model chậm, sai, đắt, hoặc đổi hành vi, toàn hệ thống bị ảnh hưởng.

Gateway giúp gom các vấn đề AI vào một ranh giới rõ.

---

60.9. Prompt không phải chuỗi text vô hại

Prompt là một phần của logic hệ thống.

Trong AI app, prompt có thể quyết định:

Output format.
Tone của feedback.
Cách áp rubric.
Tiêu chí chấm.
Cách xử lý trường hợp thiếu thông tin.
Cách từ chối nội dung không phù hợp.

Vì vậy prompt nên được xem như release artifact.

Không nên sửa prompt production bằng tay mà không có:

Version.
Review.
Evaluation.
Rollout.
Rollback.
Observability.

Ví dụ:

prompt_version = essay_grading_v12
model = gemini-x
rubric_version = rubric_2026_05

Khi một giáo viên hỏi:

Vì sao bài này được 7.5?

Ta cần biết:

Bài nào.
Rubric nào.
Prompt nào.
Model nào.
Context nào.
AI response nào.
Validator nào.
Giáo viên có override không.

Prompt không được trôi nổi.

Prompt phải có lịch sử.

---

60.10. Prompt versioning

Prompt versioning là đặt version rõ cho prompt.

Ví dụ:

essay_grading_v1
essay_grading_v2
essay_grading_v3

Mỗi version nên ghi:

Nội dung prompt.
Mục đích thay đổi.
Ngày release.
Owner.
Model mục tiêu.
Evaluation result.
Known limitations.

Khi chấm bài, result nên lưu:

prompt_version.
model_version hoặc model_id.
rubric_version.
context_hash nếu cần.

Nếu không lưu, sau này rất khó debug.

Ví dụ:

Tuần trước điểm tự luận lệch cao hơn.

Nếu không biết tuần đó dùng prompt/model nào, ta chỉ đoán.

Prompt versioning biến AI behavior thành thứ có thể truy vết.

Nó cũng giúp rollback.

Nếu prompt v13 xấu, quay về v12 phải là thao tác có chủ đích.

Không phải lục lại lịch sử chat để tìm prompt cũ.

---

60.11. Prompt deployment nên giống deploy code

Prompt mới có thể gây sự cố như code mới.

Ví dụ:

Prompt dài hơn làm token cost tăng.
Prompt yêu cầu feedback chi tiết làm latency tăng.
Prompt đổi thang điểm làm score distribution lệch.
Prompt quên bắt JSON làm parser lỗi.
Prompt vô tình khuyến khích AI quá nghiêm hoặc quá dễ.

Vì vậy prompt deployment nên có:

Evaluation trước release.
Feature flag.
Canary.
Shadow run nếu cần.
Metrics sau release.
Rollback.

Với AI Judge, prompt mới không nên bật ngay cho toàn bộ bài thi quan trọng.

Cách an toàn hơn:

Chạy offline trên bộ bài mẫu.
Shadow 1% bài thật.
So sánh score/feedback/cost/latency.
Canary một nhóm nhỏ.
Mở rộng dần.

Prompt là code ở dạng ngôn ngữ.

Nó mềm hơn code, nhưng ảnh hưởng production không hề mềm.

---

60.12. Context engineering là gì?

Context engineering là thiết kế thông tin đưa vào model.

Model không tự biết tất cả dữ liệu trong hệ thống của ta.

Ta phải quyết định:

Đưa gì vào prompt?
Đưa theo thứ tự nào?
Rút gọn gì?
Loại bỏ gì?
Dữ liệu nào đáng tin?
Dữ liệu nào quá cũ?
Dữ liệu nào user không có quyền xem?

Ví dụ chấm bài tự luận cần context:

Đề bài.
Rubric.
Bài làm của học sinh.
Yêu cầu format output.
Chính sách chấm điểm.
Ví dụ nếu có.
Thông tin về deadline nếu ảnh hưởng điểm.

Không nên đưa bừa:

Toàn bộ lịch sử lớp.
Thông tin cá nhân không cần thiết.
Feedback của học sinh khác.
Rubric cũ.
Document không liên quan.

Context tốt giúp model trả lời tốt.

Context xấu làm model lạc hướng, tốn token, chậm và có thể rò dữ liệu.

---

60.13. Giới hạn context

Mỗi model có context window.

Nghĩa là nó chỉ nhận được một lượng token nhất định.

Nếu input quá dài:

Đề bài dài.
Rubric dài.
Bài làm dài.
Tài liệu tham khảo dài.
Lịch sử chat dài.

ta phải chọn.

Không thể cứ nhét tất cả.

Cách xử lý có thể là:

Chunking.
Summarization.
Retrieval.
Truncation có kiểm soát.
Ưu tiên phần quan trọng.
Nhiều bước xử lý.

Nhưng mỗi cách có rủi ro.

Truncation có thể cắt mất thông tin quan trọng.

Summarization có thể làm mất chi tiết.

Retrieval có thể lấy nhầm tài liệu.

Nhiều bước xử lý làm tăng latency/cost.

Vì vậy context engineering không phải chỉ là "đưa thêm dữ liệu".

Nó là thiết kế luồng thông tin vào model.

---

60.14. RAG là gì?

RAG là Retrieval-Augmented Generation.

Hiểu đơn giản:

Trước khi hỏi model, hệ thống tìm tài liệu liên quan.
Sau đó đưa tài liệu đó vào context để model trả lời.

Ví dụ:

User hỏi chính sách chấm điểm.
Hệ thống tìm các đoạn rubric/policy liên quan.
Đưa các đoạn đó vào prompt.
Model trả lời dựa trên các đoạn tìm được.

RAG hữu ích khi model cần kiến thức riêng của hệ thống:

Tài liệu nội bộ.
Quy định trường.
Rubric.
Knowledge base.
FAQ.
Lịch sử ticket.
Hồ sơ khách hàng.

RAG không phải phép màu.

Nếu retrieval lấy sai tài liệu, model có thể trả lời sai một cách rất tự tin.

Vì vậy RAG architecture phải quan tâm đến:

Data ingestion.
Chunking.
Embedding.
Indexing.
Retrieval.
Ranking.
Permission filtering.
Citation.
Evaluation.
Observability.

---

60.15. Embedding là gì?

Embedding là cách biểu diễn text thành vector số để so sánh ý nghĩa.

Hiểu đơn giản:

Hai đoạn text có ý nghĩa gần nhau thì vector gần nhau.

Ví dụ:

"late submission policy"

có thể gần với:

"quy định nộp bài trễ"

dù chữ khác nhau.

Trong RAG, embedding thường dùng để:

Biến tài liệu thành vectors.
Biến câu hỏi thành vector.
Tìm các đoạn tài liệu gần nhất.

Nhưng embedding có nhiều quyết định kiến trúc:

Chọn model embedding nào?
Chunk dài bao nhiêu?
Index update khi tài liệu đổi thế nào?
Metadata filter ra sao?
Tenant permission xử lý ở đâu?
Đo retrieval quality bằng gì?

Một RAG tệ thường không tệ vì model sinh câu dở.

Nó tệ vì retrieval đưa sai context.

Model trả lời theo thứ sai được đưa vào.

---

60.16. Knowledge layer

Knowledge layer là lớp quản lý tri thức mà AI được phép dùng.

Nó có thể gồm:

Document store.
Vector database.
Search index.
Metadata.
Permission model.
Versioning.
Ingestion pipeline.
Chunking strategy.
Quality checks.

Với AI Judge, knowledge layer có thể chứa:

Rubric.
Assignment instructions.
Teacher guidelines.
Examples.
School policy.
Previous feedback templates.

Điều quan trọng:

Knowledge layer không chỉ là vector database.

Vector database chỉ là một công cụ.

Knowledge layer là toàn bộ cách hệ thống đưa tri thức đúng, mới, được phép truy cập vào model.

Nếu knowledge layer sai:

AI dùng rubric cũ.
AI thấy tài liệu của lớp khác.
AI lấy policy không còn hiệu lực.
AI không biết tài liệu nào là nguồn chính.

thì model giỏi cũng trả lời sai.

---

60.17. Permission trong RAG

RAG rất dễ tạo lỗi quyền nếu không cẩn thận.

Ví dụ:

Teacher A hỏi về lớp A.
Retrieval lấy nhầm tài liệu của lớp B.
Model đưa thông tin lớp B vào câu trả lời.

Đây là lỗi nghiêm trọng.

Vì vậy retrieval phải tenant-aware và permission-aware.

Không nên làm:

Tìm top 5 document toàn hệ thống rồi mới hy vọng model không lộ gì.

Nên làm:

Filter theo tenant/user/class/permission trước hoặc trong retrieval.
Chỉ đưa vào context những document user được phép xem.

Permission phải ở tầng hệ thống.

Không thể chỉ nhờ prompt:

Đừng tiết lộ dữ liệu không được phép.

Prompt là lớp phụ.

Access control thật phải nằm trước khi dữ liệu vào model.

---

60.18. Evaluation thay cho cảm tính

Trong AI app, rất dễ đánh giá bằng cảm giác:

Prompt này có vẻ tốt hơn.
Model này trả lời nghe hay hơn.
Feedback này có vẻ ổn.

Cảm giác có thể hữu ích lúc khám phá.

Nhưng không đủ cho production.

Evaluation là cách đo chất lượng AI có hệ thống.

Ví dụ với AI Judge:

Bộ bài mẫu.
Rubric chuẩn.
Điểm/feedback kỳ vọng.
Các case khó.
Các case edge.
Các bài từng gây lỗi.

Khi đổi prompt/model, ta chạy evaluation:

Score lệch bao nhiêu?
Feedback có bám rubric không?
JSON parse success rate bao nhiêu?
Latency/cost ra sao?
Needs_review rate thay đổi thế nào?

Evaluation không làm AI hoàn hảo.

Nhưng nó giúp ta không deploy bằng linh cảm.

---

60.19. Evaluation set phải giống rủi ro thật

Một evaluation set tốt không chỉ gồm ví dụ đẹp.

Nó nên có:

Bài rất tốt.
Bài rất kém.
Bài lạc đề.
Bài thiếu phần.
Bài dài.
Bài ngắn.
Bài có ngôn ngữ mơ hồ.
Bài sát ranh giới điểm.
Bài có nội dung không phù hợp.
Bài từng bị chấm sai.

Nếu chỉ test trên 20 bài đơn giản, prompt mới có thể trông rất tốt.

Nhưng production lại đau ở case khó.

Evaluation set là tài sản của AI app.

Nó nên được chăm sóc như test suite.

Mỗi lần gặp lỗi production đáng nhớ, ta nên cân nhắc thêm case vào eval set.

Giống như bug fix nên có test regression.

AI failure cũng nên có evaluation regression.

---

60.20. Cost là một phần của kiến trúc

Với app truyền thống, mỗi request thường có cost hạ tầng tương đối nhỏ.

Với AI app, mỗi request có thể tốn tiền trực tiếp theo token/model.

Ví dụ:

Prompt dài hơn -> token nhiều hơn.
Model mạnh hơn -> giá cao hơn.
Retry nhiều -> cost nhân lên.
Shadow traffic -> cost tăng.
User spam request -> bill tăng.

Nếu không thiết kế cost control, AI app có thể gặp sự cố tài chính trước khi gặp sự cố kỹ thuật.

Cần đo:

Cost per request.
Cost per submission.
Cost per tenant.
Cost per feature.
Input tokens.
Output tokens.
Retry cost.
Shadow/evaluation cost.

Cần có guardrail:

Quota.
Rate limit.
Budget alert.
Token limit.
Model routing.
Caching nếu phù hợp.
Prompt tối ưu.

Cost không phải chuyện kế toán sau cùng.

Cost là constraint thiết kế.

---

60.21. Latency và token budget

AI call thường chậm hơn query database hoặc API nội bộ.

Ví dụ:

Database query: vài ms đến vài chục ms.
API nội bộ: vài chục đến vài trăm ms.
AI generation: vài giây đến vài chục giây.

Vì vậy AI app phải thiết kế latency ngay từ đầu.

Câu hỏi:

User có cần chờ ngay không?
Hay job nên chạy nền?
Có streaming được không?
Có partial result không?
Có timeout không?
Có queue không?
SLO là bao nhiêu?

Với AI Judge, chấm bài thường nên chạy async.

API nộp bài không nên chờ model trả kết quả.

Token budget cũng ảnh hưởng latency.

Prompt càng dài, output càng dài, latency thường càng cao.

Do đó cần giới hạn:

Context size.
Output length.
Số tài liệu retrieval.
Số lần retry.
Số bước AI pipeline.

AI architecture luôn là bài toán chất lượng, latency và cost đi cùng nhau.

---

60.22. Caching trong AI app

Caching có thể hữu ích, nhưng phải cẩn thận.

Một số thứ có thể cache:

Embedding của document.
Retrieval result cho query ổn định.
Prompt template.
Model response cho input giống hệt và không nhạy cảm.
Rubric/context đã build.

Nhưng AI response không phải lúc nào cũng nên cache.

Ví dụ:

User-specific response có permission riêng.
Context có dữ liệu mới.
Prompt/model version đổi.
Rubric đổi.
Response có thông tin nhạy cảm.

Cache key phải bao gồm các yếu tố quan trọng:

prompt_version.
model_id.
input_hash.
context_hash.
rubric_version.
tenant_id nếu liên quan.
permission scope nếu liên quan.

Cache sai trong AI app có thể tạo lỗi rất khó thấy:

User nhận câu trả lời dựa trên context cũ.
Tenant này thấy kết quả của tenant khác.
Prompt mới vẫn trả kết quả cache từ prompt cũ.

Caching là công cụ tốt.

Nhưng với AI, cache phải được thiết kế chặt.

---

60.23. Safety filtering và guardrails

AI app cần guardrails.

Guardrails là các lớp giới hạn hành vi AI.

Ví dụ:

Input filtering.
Output validation.
Policy check.
PII redaction.
Toxicity/safety check.
Schema enforcement.
Business rule validation.
Human review.
Rate limit.
Permission check.

Với AI Judge, guardrails có thể là:

Không cho score ngoài 0..10.
Không lưu feedback rỗng.
Không chấp nhận output thiếu rubric references.
Không hiển thị feedback có nội dung không phù hợp.
Không để AI quyết định quyền truy cập.
Không để AI tự ý thay đổi deadline.

Guardrails không phải vì ta không tin AI hoàn toàn.

Guardrails là cách biến AI output thành hành vi hệ thống có trách nhiệm.

Trong app truyền thống, business rule nằm trong code.

Trong AI app, business rule vẫn phải nằm trong hệ thống.

Không nên đẩy hết vào prompt.

---

60.24. Structured output

Nhiều AI app cần output có cấu trúc.

Ví dụ:

{
  "score": 8.5,
  "confidence": 0.82,
  "feedback": "Bài làm tốt...",
  "needs_review": false
}

Nếu model trả text tự do, parser dễ hỏng.

Vì vậy nên dùng structured output khi có thể:

JSON schema.
Function/tool calling.
Response format.
Parser + validator.
Retry khi format sai.

Nhưng structured output không miễn kiểm tra.

Model có thể trả đúng JSON nhưng sai nghiệp vụ:

score = 99.
confidence = 3.
needs_review = false dù thiếu dữ liệu.

Vì vậy cần hai lớp:

Schema validation: đúng hình dạng.
Business validation: đúng luật.

Nếu schema đúng mà business sai, hệ thống vẫn phải chặn.

---

60.25. Human-in-the-loop

Không phải mọi quyết định AI nên tự động hoàn toàn.

Human-in-the-loop nghĩa là có người tham gia ở điểm quan trọng.

Ví dụ:

AI chấm bài.
Nếu confidence thấp, chuyển giáo viên review.
Nếu điểm lệch mạnh so với pattern, chuyển review.
Nếu nội dung nhạy cảm, chuyển review.
Nếu bài thuộc kỳ thi quan trọng, yêu cầu duyệt trước khi công bố.

Human review có chi phí.

Nhưng nó giúp kiểm soát rủi ro.

Câu hỏi kiến trúc:

Khi nào cần review?
Review UI ở đâu?
AI output nào được hiển thị cho reviewer?
Reviewer sửa gì?
Sửa của human có ghi đè AI không?
Kết quả review có dùng để cải thiện eval set không?
Audit log lưu thế nào?

Human-in-the-loop không phải thất bại của AI.

Nó là thiết kế hợp lý khi nghiệp vụ có rủi ro cao.

---

60.26. Observability cho AI app

Observability của AI app phải nhìn thêm những thứ app thường không có.

Không chỉ:

Latency.
Error rate.
CPU.
Memory.

Mà còn:

Prompt version.
Model/provider.
Input token.
Output token.
Cost.
Retrieval documents.
Retrieval score.
Context size.
Parse error rate.
Validation failure rate.
Safety block rate.
Retry rate.
Fallback rate.
Needs_review rate.
Score distribution.
Human override rate.

Nếu không đo các thứ này, ta sẽ không biết AI app đang xấu đi theo cách nào.

Ví dụ:

Error rate không tăng.
Nhưng cost/submission tăng 80%.

Hoặc:

API vẫn 200.
Nhưng parse error được retry ngầm làm latency tăng.

Hoặc:

Model vẫn trả lời.
Nhưng score distribution lệch sau prompt mới.

AI observability phải nhìn cả kỹ thuật và chất lượng.

---

60.27. Log AI response thế nào?

Log AI rất nhạy cảm.

Ta muốn debug.

Nhưng không muốn rò dữ liệu.

Cần quyết định:

Có lưu prompt đầy đủ không?
Có lưu response đầy đủ không?
Có mask PII không?
Ai được xem?
Lưu bao lâu?
Có audit truy cập không?
Dữ liệu có dùng cho training/evaluation không?
User/tenant có consent không?

Với AI Judge, prompt có thể chứa bài làm học sinh.

Đó là dữ liệu nhạy cảm.

Không nên log bừa vào hệ thống log chung mà ai cũng đọc được.

Một cách thực dụng:

Log metadata mặc định.
Lưu full prompt/response có kiểm soát nếu cần.
Mask thông tin nhạy cảm.
Giới hạn quyền truy cập.
Retention rõ ràng.
Audit khi truy cập.

Debug AI cần dữ liệu.

Nhưng dữ liệu đó phải được quản trị đúng.

---

60.28. Fallback trong AI app

Model/provider có thể lỗi.

Fallback là phương án thay thế.

Ví dụ:

Dùng provider khác.
Dùng model nhỏ hơn.
Chỉ trả kết quả sơ bộ.
Chuyển sang queue chờ xử lý sau.
Chuyển sang human review.
Tắt feature phụ.

Nhưng fallback không phải lúc nào cũng đơn giản.

Nếu model fallback chất lượng thấp hơn, có nên dùng cho điểm chính thức không?

Nếu provider khác có policy dữ liệu khác, có được gửi dữ liệu không?

Nếu model nhỏ hơn không hiểu rubric dài, có gây sai không?

Fallback phải được thiết kế theo nghiệp vụ.

Với AI Judge:

Nếu chấm chính thức thất bại, có thể chuyển needs_review.
Nếu feedback nâng cao thất bại, vẫn có thể lưu điểm cơ bản.
Nếu provider chậm, giữ job trong queue và báo đang chờ.

Không nên fallback mù chỉ để có response.

Response sai có thể tệ hơn response chậm.

---

60.29. AI feature hay core workflow?

Một câu hỏi rất quan trọng:

AI trong app này là feature phụ hay core workflow?

Nếu AI là feature phụ:

Gợi ý tiêu đề.
Tóm tắt optional.
Gợi ý câu trả lời.
Sinh mô tả nháp.

Khi AI lỗi, app vẫn chạy được.

Ta có thể degrade:

Ẩn nút gợi ý.
Thông báo thử lại sau.
Dùng template đơn giản.

Nếu AI là core workflow:

Chấm bài.
Phân loại hồ sơ.
Phát hiện gian lận.
Tư vấn bước tiếp theo.
Routing ticket.
Sinh quyết định nghiệp vụ quan trọng.

Khi AI lỗi, nghiệp vụ chính bị ảnh hưởng.

Khi đó cần kiến trúc nghiêm túc hơn:

Queue.
SLO.
Fallback.
Human review.
Evaluation.
Audit.
Cost guardrail.
Provider strategy.
Monitoring.

Với AI Judge, AI không chỉ là feature phụ.

Nó là core workflow của chấm bài.

Vì vậy kiến trúc phải coi AI như một dependency quan trọng, không phải tiện ích trang trí.

---

60.30. AI app vẫn cần kiến trúc truyền thống

Đừng để AI làm ta quên nền tảng.

AI app vẫn cần:

Authentication.
Authorization.
Database.
Queue.
Cache.
Rate limit.
Audit log.
Observability.
Testing.
Deploy an toàn.
Backup.
Privacy.

AI không thay thế các thứ đó.

AI làm chúng quan trọng hơn.

Ví dụ:

Nếu permission sai, RAG có thể lộ dữ liệu.
Nếu queue sai, chấm bài backlog.
Nếu observability thiếu, cost tăng không ai biết.
Nếu deploy prompt không an toàn, điểm lệch hàng loạt.
Nếu backup thiếu, mất bài nộp gốc.

AI architecture không đứng riêng.

Nó nằm trên nền system architecture tốt.

Nếu nền yếu, AI sẽ làm vấn đề lộ nhanh hơn.

---

60.31. Một kiến trúc AI Judge thực dụng

Một kiến trúc AI Judge thực dụng có thể như sau.

Luồng submit:

User nộp bài.
Submission Service validate và lưu bài.
Job chấm được đưa vào queue.
API trả trạng thái queued.

Luồng chấm:

Grading Worker lấy job.
Context Builder lấy rubric, bài làm, policy cần thiết.
Retrieval lấy tài liệu liên quan nếu cần.
Prompt Builder tạo prompt theo prompt_version.
Model Gateway gọi provider/model.
Output Parser đọc structured output.
Validator kiểm tra schema và business rule.
Grading Service lưu result.
Nếu confidence thấp hoặc lỗi nghiêm trọng, chuyển needs_review.

Luồng quan sát:

Log metadata.
Metric latency/cost/token.
Trace qua queue, retrieval, model call, validation.
Dashboard theo prompt/model/provider.
Alert khi queue age, cost, error, parse failure, needs_review tăng.

Luồng cải thiện:

Human override được ghi nhận.
Case lỗi được thêm vào evaluation set.
Prompt/model mới chạy offline eval.
Release bằng feature flag/canary/shadow.

Điểm quan trọng:

AI call nằm trong một pipeline có kiểm soát.

Không phải gọi model xong lưu thẳng.

---

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

Sai lầm thứ nhất:

Coi AI như một API bình thường.

AI output không deterministic và cần validation/evaluation riêng.

Sai lầm thứ hai:

Không version prompt.

Khi chất lượng đổi, không biết vì sao.

Sai lầm thứ ba:

Không đo cost/token.

Đến khi hóa đơn tăng mới giật mình.

Sai lầm thứ tư:

Đưa quá nhiều context.

Tốn token, chậm, nhiễu, và có thể lộ dữ liệu.

Sai lầm thứ năm:

RAG không có permission filtering.

Đây là lỗi dữ liệu nghiêm trọng.

Sai lầm thứ sáu:

Deploy prompt bằng cảm tính.

Không eval, không canary, không rollback.

Sai lầm thứ bảy:

Tin output AI mà không validate.

Score sai range, JSON thiếu field, feedback không phù hợp vẫn lọt.

Sai lầm thứ tám:

Không có human review cho case rủi ro cao.

AI bị ép quyết định cả những trường hợp nên có người xem.

Sai lầm thứ chín:

Chỉ monitor API 200/500.

AI app có thể "200 OK" nhưng chất lượng, cost, hoặc safety đang xấu.

---

60.33. Checklist AI Application Architecture

Khi thiết kế một AI app, hãy hỏi:

• AI là feature phụ hay core workflow?
• Output AI là gợi ý hay quyết định chính thức?
• Prompt có version không?
• Model/provider có được ghi lại không?
• Context lấy từ đâu?
• Context có giới hạn và ưu tiên không?
• Retrieval có permission-aware không?
• RAG có evaluation không?
• Output có structured schema không?
• Output có business validation không?
• Khi model trả sai format thì sao?
• Khi model timeout thì sao?
• Khi provider lỗi thì fallback thế nào?
• Có human review cho case rủi ro cao không?
• Có đo input/output tokens không?
• Có đo cost theo feature/tenant không?
• Có latency SLO không?
• Có guardrails safety không?
• Có log prompt/response an toàn không?
• Có eval set trước khi đổi prompt/model không?
• Có canary/shadow rollout cho prompt/model mới không?
• Có quan sát score distribution, override rate, needs_review rate không?

Nếu nhiều câu trả lời là "chưa biết", AI app có thể chạy được trong demo nhưng chưa đủ chắc cho production.

---

60.34. Bảng nhìn nhanh

| Thành phần | Vai trò | |---|---| | Prompt versioning | Truy vết và release prompt có kiểm soát | | Model gateway | Quản lý provider/model, timeout, retry, cost, fallback | | Context builder | Chọn thông tin đưa vào model | | RAG | Tìm tri thức liên quan để đưa vào context | | Embedding | Biểu diễn text thành vector để tìm kiếm theo ý nghĩa | | Knowledge layer | Quản lý tài liệu, metadata, permission, version | | Evaluation | Đo chất lượng AI thay vì cảm tính | | Output parser | Biến model response thành dữ liệu có cấu trúc | | Validator | Kiểm tra schema và luật nghiệp vụ | | Guardrails | Giới hạn hành vi, lọc rủi ro, bảo vệ user/dữ liệu | | Human review | Người kiểm tra case rủi ro hoặc confidence thấp | | AI observability | Theo dõi prompt, model, context, retrieval, token, cost, quality |

---

60.35. Kết luận của chương

AI Application Architecture bắt đầu từ một nhận thức đơn giản:

Model không phải toàn bộ ứng dụng.

Model là một dependency mạnh, đắt, chậm hơn logic thường, không deterministic, và có thể thay đổi hành vi theo prompt/context/provider.

Vì vậy AI app cần các lớp quanh model:

Prompt versioning.
Model gateway.
Context engineering.
RAG và knowledge layer.
Evaluation.
Cost và latency control.
Safety guardrails.
Structured output.
Human review.
Observability.
Deploy an toàn cho prompt/model.

Nếu AI chỉ là feature phụ, kiến trúc có thể nhẹ hơn.

Nếu AI là core workflow, kiến trúc phải nghiêm túc như mọi hệ thống production quan trọng khác.

Thông điệp cần nhớ:

> Gọi model là phần dễ. Làm cho model trở thành một phần đáng tin của hệ thống mới là kiến trúc AI app.

Ở chương tiếp theo, ta sẽ nói về AI Agent App Architecture: agent khác chatbot thường ở đâu, tool calling là gì, vì sao agent cần permission/sandbox/approval, và vì sao một agent tốt không chỉ biết nói mà còn phải biết hành động trong giới hạn an toàn.