Trả lời ngắn: Một AI professional diagnostic assessment không hỏi bạn nhớ bao nhiêu thuật ngữ. Nó kiểm tra bạn có mô tả được problem, dữ liệu, workflow, evaluation, ranh giới an toàn, bằng chứng vận hành và người chịu trách nhiệm hay chưa. Điểm chỉ có ý nghĩa khi đi cùng evidence, confidence và bước kiểm tra tiếp theo.

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

  • Vì sao diagnostic khác một bài quiz nhớ khái niệm.
  • Sáu chiều cần nhìn khi review một AI system.
  • Cách đi từ symptom đến hypothesis, evidence và quyết định.
  • Cách tự chấm một case giả mà không tự phong “production-ready”.

Lưu ý giáo dục: Đây là snapshot để chọn bài tập học tiếp, không phải chứng nhận năng lực, security audit, đánh giá tuyển dụng hoặc phê duyệt production. Chỉ dùng case, số liệu và artifact giả; không đưa secrets, PII, customer data, token hay production prompt vào bài tập.

1. Diagnostic là bản đồ năng lực, không phải điểm danh thuật ngữ

Diagnostic là bài kiểm tra có cấu trúc để tìm gap và chọn bước học tiếp theo. Nó khác quiz ở chỗ không chỉ hỏi “định nghĩa RAG là gì?” mà hỏi “nếu câu trả lời sai, bạn sẽ kiểm tra nguồn, retrieval, prompt hay policy bằng evidence nào?”.

Người đọc nhiều về agent vẫn có thể chưa biết viết tool contract; người ít dùng thuật ngữ lại có thể biết đặt scope, expected output, log và owner. Diagnostic nhìn cả việc hiểu khái niệm lẫn biến nó thành quyết định kiểm lại được.

Hãy dùng một case xuyên suốt: trợ lý support nhận ticket giả, phân loại thành billing, technical hoặc NEEDS_REVIEW, rồi đề xuất route. Nó không tự gửi email, hoàn tiền hay sửa dữ liệu. Với case này, câu hỏi không phải “model nào tốt nhất?” mà là:

  • Mục tiêu nào được xem là đúng?
  • Input nào được phép đi vào system?
  • Output nào cần người duyệt?
  • Nếu sai, ta biết sai ở bước nào không?
  • Ai sở hữu quyết định và cách dừng là gì?

Hình 1 — Diagnostic tốt nối sáu chiều của system với evidence, gap và bài test kế tiếp.

2. Sáu chiều cần kiểm tra trong một AI system

a. Problem framing và context

Problem framing là cách viết rõ vấn đề, người dùng, input, output và giới hạn. “Dùng AI để xử lý support” quá rộng; cụ thể hơn là: với ticket giả, hệ thống đề xuất một trong ba route và chuyển ticket thiếu thông tin sang NEEDS_REVIEW. Context là dữ liệu được phép dùng. Evidence tối thiểu gồm problem statement, input mẫu, expected output và dữ liệu bị cấm.

b. Workflow, tool và boundary

Workflow là chuỗi bước; tool là khả năng bên ngoài; guardrail là rào chắn giới hạn input, output, tool hoặc quyền. Support assistant có thể đọc trạng thái ticket, nhưng gửi email hoặc sửa CRM phải tách quyền và cần approval. Evidence gồm sơ đồ, tool contract, bảng quyền và test “deny”.

c. Evaluation và quality

Evaluation là cách so output hoặc process với expected behavior. Bộ test ba route nên có ticket rõ, thiếu dữ liệu, gây nhiễu và ngoài phạm vi. Tách đúng route, không bịa policy, không lộ dữ liệu và biết chuyển case đều là quality signal. Evidence tối thiểu là dataset có version, expected result, pass/fail rule và một failure case.

d. Observability và provenance

Observability là khả năng hiểu run qua log, metric, trace và tín hiệu chất lượng. Provenance là nguồn và lịch sử tạo output. Một run nên có run_id, input đã redact, policy version, route, guardrail result và reviewer status; không ghi token/PII nguyên văn. Trace giúp tách lỗi input, retrieval, model, tool hoặc handoff. Microsoft lưu ý telemetry hạ tầng không tự chứng minh chất lượng câu trả lời. Microsoft AI observability

e. Governance và owner

Governance là quy tắc, vai trò và quyết định chịu trách nhiệm. Owner là người chịu trách nhiệm cho một kiểm soát. Evidence gồm bảng owner, approval, retention và escalation. NIST AI RMF đặt risk management và accountability trong toàn vòng đời, nhưng tổ chức vẫn phải tự chỉ rõ ai duyệt và khi nào dừng. NIST AI Risk Management Framework

f. Learning loop và change control

Diagnostic không kết thúc ở điểm số. Khi prompt, model, policy, dataset hoặc tool version đổi, cần changelog, test set version và owner quyết định promote/rollback. Tỷ lệ NEEDS_REVIEW tăng là tín hiệu điều tra, không phải chỉ tiêu cần ép xuống. Tools, guardrails, state và tracing phải được nhìn cùng nhau. OpenAI Agents SDK

3. Từ symptom đến evidence và quyết định

Một symptom là điều quan sát thấy, chẳng hạn “ticket bị route sai”. Hypothesis là giả thuyết giải thích symptom, chẳng hạn “policy retrieval lấy nhầm bản cũ”. Đừng nhảy thẳng từ symptom sang sửa prompt. Dùng chuỗi:

symptom → hypothesis → evidence → risk → decision → next test

Content pipeline có draft nhiều thuật ngữ chưa giải thích: kiểm report validator và Term Audit trước khi sửa prompt. Research assistant trả lời thiếu nguồn: kiểm source list, chunk id và trace; không dựng được provenance thì dùng NEEDS_REVIEW. Coding agent test pass nhưng diff ngoài scope: kiểm tool call/path allowlist, chuyển read-only và thêm deny test.

Hình 2 — Đừng sửa theo cảm giác: mỗi symptom cần hypothesis, evidence và một bước test có giới hạn.

4. Scorecard và gap register

Dùng thang 0–3 để tạo snapshot đơn giản:

  • 0 — UNKNOWN: chưa mô tả được hoặc không có evidence.
  • 1 — CONCEPT: giải thích được ý tưởng nhưng chưa có artifact kiểm lại.
  • 2 — DESIGNED: có workflow, test, boundary hoặc owner ở mức review được.
  • 3 — OPERATED: đã chạy case kiểm soát, có telemetry, failure handling và change record.

Không cộng điểm để tuyên bố readiness. Score 3 không bù score 0 ở security boundary hoặc evaluation. Ghi confidence thấp/vừa/cao; confidence thấp khi evidence ít, cũ, lệch mẫu hoặc chưa có người review.

Mẫu gap register

Chiều Score Evidence Confidence Gap/risk Owner Next test
Problem/context 2 6 ticket giả + expected route Vừa Chưa có ticket ngoài phạm vi Product Thêm 3 case boundary
Workflow/tool 1 Sơ đồ read-only Thấp Chưa có deny test Engineering Test field và quyền
Evaluation 1 Bảng pass/fail nháp Thấp Chưa version dataset QA Khóa v0.1 và 10 case
Observability 2 run_id + log giả Vừa Chưa trace retrieval Platform Thêm trace đã redact
Governance/owner 2 Bảng owner/approval Vừa Chưa có escalation time Operations Viết stop rule
Learning loop 1 Changelog prompt Thấp Chưa test model change QA Chạy regression nhỏ

Gap register ghi khoảng trống, rủi ro, owner và hành động. Nó biến “cần cải thiện evaluation” thành “QA thêm 10 case boundary”; thiếu owner hoặc next test thì gap chưa đủ cụ thể.

5. Sai lầm, giới hạn và stop gate

Sai lầm thường gặp là demo bias và checklist theater: output đẹp hoặc nhiều ô tick không thay được failure case, quyền và artifact. Cũng đừng lẫn model quality với system quality: model phân loại tốt nhưng tool quá rộng vẫn nguy hiểm; model đôi lúc sai nhưng approval và handoff có thể giảm rủi ro. Telemetry thiếu, test set lệch hoặc dataset cũ cũng làm score quá tự tin. Google Cloud đặt production AI security ở application, data và infrastructure, gồm prompt injection và data leakage. Google Cloud production AI security

Stop gate là điều kiện buộc hệ thống dừng hoặc giảm quyền. Dùng NEEDS_REVIEW khi không có nguồn, không rõ tenant, output ngoài taxonomy, tool argument vượt allowlist hoặc không dựng được evidence. Chuyển read-only khi chưa test side effect. Không đưa vào production khi chưa có owner, expected behavior, failure handling và đường rollback phù hợp với rủi ro.

Hình 3 — Điểm diagnostic tốt phải dẫn tới boundary và stop gate, không chỉ một con số đẹp.

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes, chọn trợ lý support giả và không dùng API key. Tạo một hàng cho mỗi chiều, điền score, evidence, confidence, owner và next test; thay ít nhất hai ô bằng dữ liệu bịa của bạn, không copy customer data.

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

Chiều Score Evidence giả Confidence Owner Next test 10 phút
Problem/context 2 8 ticket, 3 route, 1 ngoài scope Vừa Product Thêm ticket thiếu ngôn ngữ
Workflow/tool 1 Sơ đồ classify → route, chưa có tool write Thấp Engineering Chạy test deny email
Evaluation 2 8 expected labels, 2 failure cases Vừa QA Thêm case prompt injection
Observability 1 Có run_id, chưa có trace Thấp Platform Ghi retrieval source giả
Governance/owner 2 Reviewer nhận NEEDS_REVIEW Vừa Operations Ghi thời gian escalation
Learning loop 1 Prompt v0.1 trong notes Thấp QA So sánh hai prompt trên cùng case

Kết quả không phải tổng điểm cao. Chọn một score thấp có next test nhỏ, làm test, cập nhật evidence và ghi: “Chưa biết điều gì, cần ai xác nhận?”.

Hình 4 — Diagnostic card biến việc tự review thành một artifact nhỏ có thể trao đổi với owner.

7. Tổng kết: điểm số chỉ mở ra bước học kế tiếp

a. Năm ý chính

  • Diagnostic đo năng lực biến khái niệm thành evidence và quyết định, không chỉ đo trí nhớ thuật ngữ.
  • Sáu chiều cần nhìn là problem/context, workflow/tool, evaluation, observability, governance/owner và learning loop.
  • Chuỗi symptom → hypothesis → evidence → risk → decision → next test giúp tránh sửa theo cảm giác.
  • Score 0–3 chỉ là snapshot; luôn ghi evidence, confidence, gap, owner và hành động kế tiếp.
  • Khi thiếu boundary, evidence hoặc owner, hãy giảm quyền, chuyển NEEDS_REVIEW và giữ dữ liệu giả trước khi mở rộng.

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

  • Vì sao một demo tốt chưa đủ để chấm system ở mức OPERATED?
  • Evidence nào giúp phân biệt symptom route sai với lỗi retrieval hoặc policy?
  • Khi nào score cao vẫn cần ghi confidence thấp?
  • Một stop gate tối thiểu cần bảo vệ những gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Demo thường không bao phủ failure case, quyền, telemetry, owner và thay đổi theo version. `OPERATED` cần bằng chứng vận hành, không chỉ một output tốt. Xem lại mục 4.

Xem gợi ý câu 2

Ghi input, expected route, source/context, policy version và trace đã redact để kiểm tra từng bước thay vì đoán từ output cuối. Xem lại mục 3.

Xem gợi ý câu 3

Score có thể dựa trên evidence ít, cũ hoặc không đại diện; confidence nói rõ mức chắc chắn của chính đánh giá đó. Xem lại mục 4.

Xem gợi ý câu 4

Boundary về dữ liệu/quyền, expected behavior, evidence có thể kiểm lại, người nhận ngoại lệ và cách dừng side effect. Xem lại mục 5.

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

Thuật ngữ Giải thích ngắn
Diagnostic Bài kiểm tra có cấu trúc để tìm gap và bước học tiếp theo.
Evidence Artifact hoặc quan sát có thể kiểm lại.
Hypothesis Giả thuyết giải thích symptom để đem đi kiểm tra.
Evaluation Cách so output/process với expected behavior.
Guardrail Rào chắn giới hạn input, output, tool hoặc quyền.
Observability Khả năng hiểu run qua telemetry và tín hiệu chất lượng.
Provenance Nguồn và lịch sử tạo ra output.
Governance Quy tắc, vai trò và quyết định chịu trách nhiệm.
Owner Người chịu trách nhiệm cho một kiểm soát hoặc quyết định.

e. Nguồn tham khảo

Bài trước là AI Infrastructure, Security và Observability Review #5. Bài tiếp theo là Từ Business Problem đến AI Use Case #7.

Lưu ý giáo dục: Một scorecard không thay thế security assessment, evaluation harness, incident playbook hoặc approval của owner. Hãy giữ diagnostic nhỏ, có evidence và read-only cho tới khi rủi ro, quyền và đường dừng được review.