Integrated AI System Design Framework #12

Trả lời ngắn: Integrated AI System Design Framework là cách vẽ toàn bộ đường đi từ user request tới outcome: boundary, data/context, model hoặc agent, tool, state, output, evaluation, guardrail, observability và owner. Một model tốt chưa thành system tốt; system chỉ đáng tin hơn khi từng boundary có contract, evidence, quyền, fallback và cách kiểm.

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

• Vì sao model, workflow, agent và tool là các vai trò khác nhau.
• Cách nối request → context → runtime → output → control thành blueprint.
• Cách đặt evaluation, guardrail, trace và owner vào cùng một bản thiết kế.
• Cách dùng một canvas 15 phút với dữ liệu giả trước khi nghĩ tới production.

Lưu ý giáo dục: Bài dùng support, content và research case giả hoặc public docs. Không đưa credentials, API key, PII, customer data, production prompt hay dữ liệu tiền thật vào bài. Blueprint là công cụ suy nghĩ và kiểm tra; không phải certification, security approval, SLA hay lời hứa accuracy/safety.

1. Integrated AI system là gì?

AI system là toàn bộ đường đi từ request tới outcome và trách nhiệm vận hành, không chỉ là model. Integrated AI System Design Framework là một khung để nhìn các mảnh trong cùng một user journey: system đọc gì, suy luận gì, được gọi tool nào, lưu state ra sao, trả kết quả thế nào, ai kiểm và chuyện gì xảy ra khi fail.

Hãy tưởng tượng một support copilot nhận câu: “Đơn #12345 của tôi đang ở đâu?”. Model có thể viết câu trả lời nghe tự nhiên. Nhưng để thành system, còn phải hỏi: request có đủ order ID không, user thuộc tenant nào, nguồn trạng thái có mới không, tool tra cứu là read-only hay có side effect, output có được gửi ngay không, và ai nhận khi nguồn mâu thuẫn? Những câu hỏi đó nằm ngoài model.

Một framework cơ bản có các lớp sau:

1. User/problem: ai cần gì, outcome nào có ích và điều gì nằm ngoài phạm vi.
2. Boundary/input: field, format, tenant, quyền và dữ liệu system được phép nhận.
3. Context/evidence: tài liệu, record hoặc retrieval result làm căn cứ.
4. Model/runtime: model trả output; workflow chạy bước cố định; agent có thể chọn bước trong scope.
5. Tool/state: công cụ đọc hoặc ghi, trạng thái case và điều kiện chuyển bước.
6. Output/control: schema, citation, evaluation, guardrail, human approval và handoff.
7. Operations: trace, metric, incident, owner, rollback và staged rollout.

Ví dụ đời thường: model giống một nhân viên biết viết; AI system giống cả quầy dịch vụ. Quầy còn có phiếu tiếp nhận, tủ hồ sơ, quyền mở cửa, sổ ca, người duyệt và quy trình khi máy in hỏng. Nhầm model với system giống nhìn tay người viết rồi kết luận cả cửa hàng đã vận hành được.

Hình 1 — Blueprint end-to-end cho thấy một request phải đi qua boundary, context, runtime, control và owner trước khi thành outcome.

2. Chốt use case, boundary và data flow

Use case là một vấn đề và outcome cụ thể cho một nhóm người dùng xác định. Đừng bắt đầu bằng “mình muốn dùng agent”. Hãy bắt đầu bằng “ai đang mất thời gian ở bước nào, kết quả tốt trông ra sao, và rủi ro nào không được chấp nhận?”.

Bốn câu hỏi trước khi chọn component

• User là ai? Nhân viên support, content reviewer hay research analyst?
• Request có dạng nào? Ticket, brief, câu hỏi tìm tài liệu hay một action cần duyệt?
• Outcome cần là draft, recommendation, trạng thái đã xác minh hay hành động đã thực thi?
• Những gì phải nằm ngoài boundary? PII, tenant khác, write action, nguồn chưa được duyệt hay quyết định pháp lý?

System boundary là đường giới hạn system được phép đọc, làm và thay đổi. Một internal knowledge assistant có thể đọc policy nội bộ đã được index, nhưng không tự đọc mailbox riêng của nhân viên hoặc dữ liệu tenant khác. Boundary nên viết bằng động từ kiểm được: “đọc được”, “không đọc được”, “được đề xuất”, “được gửi sau approval”, “bắt buộc chuyển người”.

Input contract là điều kiện về field, format và scope mà request phải đáp ứng. Với ticket giả, contract có thể yêu cầu ticket_id, tenant_id, question, channel. Thiếu tenant_id không phải chuyện nhỏ để model tự đoán; đó là trạng thái NEEDS_REVIEW hoặc một bước bổ sung thông tin.

Data flow nên tách hai đường:

• Data plane: request, context, retrieval result, model output và tool result đi qua system.
• Control plane: policy, allowlist, permission, version, approval và stop rule quyết định data plane được làm gì.

Azure dùng component, interaction và knowledge layer như các phần cần thiết kế cùng nhau trong AI workload. Azure architecture pattern for AI workloads

Hình 2 — Boundary tách dữ liệu được đọc khỏi dữ liệu bị chặn, đồng thời nối data flow với rule và quyền.

3. Nối context, model, agent và tool thành runtime flow

Context là thông tin đưa vào để model hiểu request trong phạm vi. Retrieval là cách lấy evidence liên quan từ nguồn đã chọn; không phải cứ nạp cả database là có context tốt.

Workflow hay agent?

Workflow là chuỗi bước được định trước theo điều kiện. Nếu request support luôn đi qua kiểm field → tìm policy → tạo draft → reviewer, workflow thường dễ đọc và dễ test hơn. Agent là runtime có thể chọn bước hoặc tool trong phạm vi được phép. Nếu research case cần chọn giữa tìm policy, hỏi thêm user hoặc chuyển người dựa trên evidence, agent có thể hữu ích hơn; nhưng quyền chọn không phải quyền làm mọi thứ.

Tool contract quy định input, output, quyền và side effect của tool. Tool get_order_status có thể read-only, nhận order_id và trả status có timestamp. Tool send_email có side effect, cần allowlist recipient, approval và idempotency key. Nếu hai tool đều được gọi như hàm tự do, system khó kiểm soát chỗ rủi ro.

State là trạng thái hiện tại và lịch sử tối thiểu cần cho bước tiếp. Một case có thể đi qua RECEIVED → CONTEXT_READY → DRAFTED → NEEDS_REVIEW → SENT, hoặc dừng ở BLOCKED. Ghi state không có nghĩa lưu tất cả nội dung mãi mãi; chỉ giữ điều cần cho trace, audit và quyết định kế tiếp.

Runtime flow của support copilot có thể là:

1. Nhận ticket và kiểm tenant_id, ticket_id, ngôn ngữ.
2. Lấy policy và order record từ nguồn được phép; kiểm freshness.
3. Model tạo draft kèm evidence và uncertainty.
4. Evaluation kiểm schema, groundedness và expected behavior.
5. Guardrail kiểm PII, recipient, tool permission và trạng thái approval.
6. Nếu safe thì đưa draft vào queue; nếu cần write/send thì chờ người duyệt.

OpenAI Agents guide tổ chức agent quanh tools, guardrails, state và tracing; đó là gợi ý quan trọng: runtime, quyền và dấu vết phải được thiết kế cùng nhau, không chỉ thêm filter sau khi agent đã hành động. OpenAI Agents guide

Hình 3 — Runtime có state và contract giúp phân biệt draft, review, block, write action và handoff.

4. Gắn quality, safety và observability vào blueprint

Bài #11 đã tách evaluation khỏi guardrail. Khi đưa vào framework, hai lớp đó phải nằm đúng boundary chứ không để cuối sơ đồ. Evaluation hỏi output/process có đạt expected behavior không; guardrail hỏi system được phép nhận, trả, gọi tool và thay đổi đến đâu.

Một component phải nối được với một cách kiểm

Observability là dấu vết và tín hiệu giúp biết system đã làm gì, hỏng ở đâu. Trace có thể nối request_id với retrieval, model call, tool call, state transition và decision. Metric như latency hoặc error rate nói về vận hành; evaluation score nói về chất lượng; cả hai đều cần context và owner.

NIST AI RMF đặt govern, map, measure và manage trong vòng đời; mỗi component vì vậy cần owner và cách xem lại trước khi deploy. NIST AI RMF Core

SLO là mục tiêu theo dõi reliability, không phải guarantee. Ví dụ giả “95% request có trace hoàn chỉnh” không cho phép xóa trace hoặc hạ quality threshold để đạt tỷ lệ. Với RAG, evaluation phải xét groundedness, completeness và relevance, không chỉ câu trả lời nghe mượt. Azure RAG evaluation

Hình 4 — Quality và operations tạo vòng lặp: đo, nhận diện failure, handoff, sửa có kiểm soát rồi regression test.

5. Trade-off, failure mode và readiness gate

Framework không làm biến mất trade-off mà làm chúng lộ ra sớm hơn. Workflow dễ test nhưng ít linh hoạt; agent linh hoạt hơn nhưng tăng surface area của tool, state và trace. RAG vẫn cần freshness, permission và failure handling.

Những lỗi thường gặp

• Lắp component trước khi chốt use case: có vector database, agent và dashboard nhưng chưa biết outcome nào được chấp nhận.
• Agent hóa mọi thứ: một chuỗi bốn bước cố định bị biến thành loop khó dự đoán, trong khi workflow đã đủ.
• RAG không có boundary: retrieval lấy nhầm tenant, source cũ hoặc document chưa được duyệt.
• Tool quyền quá rộng: tool đọc và tool ghi dùng chung credential, không có approval hoặc idempotency.
• Retry vô hạn: timeout hoặc state không chắc bị gọi lại nhiều lần, tạo duplicate action.
• Demo thành production: happy path chạy được nhưng chưa có eval slice, fallback, incident contact hoặc staged rollout.

Staged rollout là mở dần theo nhóm hoặc risk thay vì bật toàn bộ. Có thể bắt đầu bằng read-only, fake tenant, reviewer bắt buộc và một slice nhỏ. Readiness gate chỉ mở khi có use case, owner, input contract, evidence policy, tool permission, eval set, guardrail, trace, fallback và kênh incident. Thiếu một ô không phải lý do để “cứ bật thử” với customer thật.

Hình 5 — Readiness gate biến failure thành điều kiện hành động: ai dừng, dừng ở đâu, fallback nào và khi nào được thử lại.

6. Practice Bridge 15 phút: vẽ một blueprint nhỏ

Bắt đầu từ đâu

Mở Google Sheets hoặc notes miễn phí. Chọn một support case giả: “Người dùng hỏi chính sách đổi gói nhưng thiếu tenant_id”. Đặt timer 15 phút. Không dùng API key, PII, customer data, production prompt hay money flow. Mục tiêu là làm rõ design decision, không dựng application.

Điền 10 ô theo thứ tự: user/problem, outcome, boundary, input contract, context/evidence, model/workflow/agent, tool/permission, state, evaluation/guardrail, owner/metric/fallback. Sau đó thêm ba biến thể: happy path có đủ field; boundary case thiếu evidence; failure case timeout hoặc tool write chưa approval.

Mẫu đối chiếu đã điền

Kết quả mong đợi không phải là một sơ đồ đẹp. Bạn cần nói được request đi đâu, evidence nào được dùng, tool nào chỉ đọc, ai có quyền duyệt, state nào được ghi, metric nào báo failure và khi nào system phải dừng. Nếu chưa biết, ghi UNKNOWN thay vì tự điền cho đủ.

Hình 6 — Practice card 15 phút nối use case với boundary, runtime, control, owner và fallback.

7. Tổng kết: blueprint trước, quyền sau

a. Năm ý chính

• AI system là toàn bộ đường đi từ request tới outcome và vận hành; model chỉ là một component.
• Blueprint tốt bắt đầu từ use case, boundary, input contract và data/context, không bắt đầu từ việc chọn agent.
• Workflow, agent, tool và state cần contract, permission, approval và handoff rõ trước side effect.
• Evaluation, guardrail và observability phải nối với metric, threshold, trace, owner và quyết định PASS/REVIEW/BLOCK.
• Readiness gate nên đi từ read-only, fake data và staged rollout; thiếu evidence, permission, owner hoặc fallback thì stop.

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

• Vì sao model trả lời hay chưa đủ để gọi là AI system tốt?
• Khi nào workflow được ưu tiên hơn agent?
• Boundary và input contract giúp tránh lỗi nào?
• Tool write cần thêm điều kiện gì so với tool read-only?
• Trace, metric và evaluation khác nhau ở đâu?

c. Gợi ý đáp án

Xem gợi ý câu 1

Model không tự có boundary, evidence policy, permission, state, owner, fallback hay incident path. Xem lại mục 1 và mục 2.

Xem gợi ý câu 2

Chọn workflow khi bước đã biết và cần dễ test; chọn agent khi cần quyết định bước trong scope rõ, kèm tool contract và guardrail. Xem lại mục 3.

Xem gợi ý câu 3

Boundary giới hạn dữ liệu và hành động; input contract biến giới hạn đó thành field, format, tenant và điều kiện kiểm được. Xem lại mục 2.

Xem gợi ý câu 4

Tool write có side effect nên cần allowlist, approval, idempotency, audit, state check và stop/fallback. Xem lại mục 3 và mục 5.

Xem gợi ý câu 5

Trace cho biết một run đã đi qua đâu; metric gom tín hiệu vận hành; evaluation so output/process với expected behavior. Xem lại mục 4.

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

e. Nguồn tham khảo

• Azure architecture pattern for AI workloads — component, interaction, governance và knowledge layer.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• NIST AI RMF Core — govern, map, measure và manage trong vòng đời.
• Azure RAG evaluation — đánh giá RAG theo nhiều chiều.
• Google Cloud RAG — retrieval và grounding cho generative AI use case.

Bài trước là Thiết kế Evaluation và Guardrails #11. Bài tiếp theo là Case Study: Research Agent #13.

Hub này cũng là bản đồ để xem lại Phase 2: Từ Business Problem đến AI Use Case #7, Chọn Workflow, Copilot hay Agent #8, Thiết kế Context, Memory và Retrieval #9 và Thiết kế Tool Layer và Human Approval #10 trước khi đi vào evaluation.

Lưu ý giáo dục: Blueprint chỉ có giá trị khi được kiểm với dữ liệu, quyền, owner và workflow thực tế. Hãy bắt đầu read-only với dữ liệu giả, ghi rõ điều chưa biết và giữ stop gate trước khi mở rộng phạm vi.