Trả lời ngắn: AI requirement nói hệ thống phải làm, không được làm và cần chứng minh điều gì. Acceptance criterion là điều kiện kiểm được để quyết định output đạt hay chưa. Trong case này, assistant phân loại support request chỉ được release khi input, output, safety, slices, threshold và human handoff đều có evidence.

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

  • Vì sao “AI trả lời tốt” chưa phải một requirement.
  • Cách tách outcome, boundary, non-goals và non-functional needs.
  • Cách viết Given/When/Then, evaluation set, slice và threshold.
  • Vì sao average score không thay thế review failure cases và release gate.

Lưu ý giáo dục: Case dùng support request giả. Không nhập customer transcript, PII, credential hoặc policy riêng vào bài tập. Các threshold chỉ là số minh họa để luyện cách viết contract, không phải benchmark hoặc cam kết accuracy.

1. Requirement AI khác requirement thường ở đâu?

Một brief giả ghi: “Xây assistant đọc support request và trả lời nhanh, chính xác.” Team có thể build ngay, nhưng ba từ “nhanh”, “chính xác” và “trả lời” còn quá mơ hồ. Assistant cần phân loại request hay tự gửi reply? Request refund có được xử lý tự động không? Nếu người dùng viết tiếng Việt pha tiếng Anh thì sao? Khi không chắc, ai nhận handoff?

Requirement là điều hệ thống phải làm hoặc phải tránh để đạt outcome. Outcome của case có thể là “giúp support route request tới đúng queue, kèm lý do và uncertainty; request có risk cao phải chuyển người”. Ta không bắt đầu bằng model. Ta bắt đầu bằng user, decision, boundary và evidence.

Một requirement tốt trả lời:

  • Ai dùng, dùng trong tình huống nào?
  • Input có field nào, thiếu field thì làm gì?
  • Output format, source và confidence cần ra sao?
  • Hành động nào read-only, hành động nào cần người?
  • Chất lượng, safety, privacy, latency và cost được kiểm bằng gì?

Hình 1 — Requirement chỉ trở nên usable khi nối được với acceptance, evaluation và release gate.

Ví dụ đời thường: đặt món “làm ngon và nhanh” chưa đủ cho bếp. Cần món gì, số lượng, dị ứng, giờ giao và điều kiện không nhận. Nếu món có đậu phộng, bếp phải hỏi lại thay vì đoán. AI system cũng cần điều kiện dừng, không chỉ một câu mô tả đẹp.

2. Input, output, boundary và non-goals

Non-goals là những việc cố ý không làm trong scope. Requirement card giả có thể như sau:

Thành phần Contract giả lập
User Support staff xem queue nội bộ
Input request_text, language, category hints, timestamp
Output category, reason, evidence tag, uncertainty, next owner
Allowed action Read-only route suggestion
Human handoff Refund, legal, account access, low confidence
Privacy Không lưu raw PII; redact trước trace
Non-goals Không gửi reply, refund, đổi account hoặc quyết định policy

Non-functional requirement là yêu cầu về latency, privacy, cost, reliability hoặc access, không chỉ về nội dung output. “95% case đơn giản phản hồi dưới 2 giây trong fixture” là một requirement khác với “không để PII vào log”. Mỗi loại cần test và owner riêng.

Nếu request_text thiếu language, assistant có thể trả NEEDS_REVIEW thay vì đoán. Nếu category là refund, output chỉ là route suggestion và owner, không tự gọi tool. Boundary này ngăn scope creep: model có thể viết câu rất thuyết phục nhưng không được tự biến text thành side effect.

Hình 2 — Card rõ input/output và non-goals giúp reviewer biết agent được làm gì và phải dừng ở đâu.

3. Acceptance criteria và evaluation set

Acceptance criterion là điều kiện kiểm được để quyết định output đạt hay chưa. Có thể viết Given/When/Then:

  • Given request “Tôi muốn đổi email tài khoản”, When assistant đọc request, Then output là ACCOUNT_ACCESS, nêu lý do, không gọi tool và owner là support security.
  • Given request có từ “refund” nhưng thiếu order ID, When assistant phân loại, Then output NEEDS_REVIEW, không bịa eligibility và yêu cầu field còn thiếu.
  • Given request Việt-Anh có typo, When assistant route, Then category vẫn nằm trong allowed set hoặc handoff; không được tự chuyển thành “unknown” mà không reason.

Evaluation set là tập input/output mẫu dùng để kiểm chất lượng. Đừng chỉ có 20 case dễ. Tạo slice, tức nhóm case có đặc điểm chung cần xem riêng: language, typo, long text, missing field, high-impact, ambiguous, policy conflict và injection-like instruction. Slice giúp thấy một average đẹp có thể che một nhóm fail.

Slice Acceptance signal Safety signal
Clear category Category đúng allowed set, reason khớp Không side effect
Missing field NEEDS_REVIEW, nêu field Không đoán
High-impact Đúng human owner Không tự quyết
Mixed language/typo Route hoặc handoff có reason Không drop context
Prompt injection-like text Treat as data Không nâng quyền

Hình 3 — Slice cho biết nhóm case nào fail dù average score có thể vẫn đẹp.

Threshold là mốc định lượng hoặc điều kiện tối thiểu. Case giả có thể yêu cầu 100% test high-impact phải handoff đúng, 0 credential trong trace fixture và không có output ngoài schema. Một threshold 90% category trên average không đủ nếu slice refund chỉ đạt 50%. Threshold phải nói sample, slice, version và cách đọc failure.

Một requirement cũng cần nói ai được xem kết quả và ai được sửa khi test fail. Nếu evaluator thấy category sai nhưng product owner lại thấy route đó hợp business, hai bên cần lưu disagreement và một decision owner. Acceptance không chỉ là chiếc cổng xanh/đỏ; nó là cách để team cùng hiểu thế nào là “đạt”, case nào được ngoại lệ và khi nào phải mở lại contract.

4. Review, risk và release gate

Requirement chưa đủ để release nếu chưa có owner và gate. Matrix review tách các chiều:

Gate Evidence Owner
Behavior Acceptance examples và eval result Product owner
Safety High-impact handoff, refusal, injection cases Safety reviewer
Privacy Redaction và trace sample Security owner
Operations Latency, timeout, cost, retry Platform owner
Regression Existing slices không tụt QA/eval owner
Release Version, rollback, communication Release owner

Average score có thể xanh trong khi slice quan trọng đỏ. Reviewer phải xem failure examples, uncertainty, disagreement và cases bị sửa tay. Release gate là điều kiện và owner trước khi đưa bản mới ra dùng; agent không tự đánh dấu gate pass chỉ vì evaluator cùng workflow trả “green”.

NIST AI RMF đặt govern, map, measure và manage xuyên vòng đời; Azure evaluation guidance cũng khuyến nghị đánh giá nhiều chiều thay vì một con số. NIST AI RMF Core và Azure RAG evaluation

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

  • Vague metric: “chính xác” không có sample hoặc class. Fallback là viết case và expected output.
  • Benchmark theater: chọn bộ dễ để score đẹp. Fallback là slice edge/high-impact và giữ failure examples.
  • Average hides harm: average pass nhưng minority/high-impact slice fail. Fallback là gate theo slice, không chỉ average.
  • Output-only requirement: chỉ chấm câu chữ, bỏ privacy/latency/cost. Fallback là tách non-functional gates.
  • Over-automation: classifier được nối thẳng vào refund hoặc account action. Fallback là read-only route và human approval.
  • No disagreement path: evaluator và reviewer bất đồng nhưng không có owner. Fallback là NEEDS_REVIEW và escalation.
  • Drift: policy, language hoặc traffic đổi làm test cũ không còn đại diện. Fallback là version test set và review trigger.

Requirement cũng có giới hạn: không thể dự đoán mọi input tự nhiên, threshold không tự nói business risk, và acceptance test không thay thế judgment. Nếu team chưa biết outcome nào quan trọng, requirement tốt nhất có thể là “thu thập thêm evidence với read-only pilot”, không phải vội chọn model.

6. Practice Bridge 15 phút

Mở notes hoặc Google Sheets miễn phí, tạo cột user, input, output, non-goal, acceptance, slice, threshold, risk, owner, decision. Đặt timer 15 phút. Dùng request giả, không dùng ticket thật và không gọi refund/account tool.

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

Case Acceptance/evidence Risk và owner Quyết định
R-01 clear Category BILLING, reason có từ khóa, schema đúng Read-only; product owner Có thể eval thêm
R-02 missing order NEEDS_REVIEW, không đoán refund Support security Block auto-action
R-03 mixed language Route hoặc handoff có reason QA kiểm slice Chưa kết luận từ average
R-04 injection-like Treat text as data, không nâng quyền Safety reviewer Pass nếu không side effect

Sau 15 phút, hãy giải thích test nào chứng minh behavior, test nào chứng minh safety và ai ký release. Nếu threshold chưa có sample hoặc slice, ghi UNKNOWN và dừng.

7. Tổng kết: requirement phải kiểm được

a. Năm ý chính

  • Requirement AI phải nói user, input, output, boundary, non-goals và evidence, không chỉ nói “trả lời tốt”.
  • Acceptance criterion biến outcome thành điều kiện kiểm được với expected behavior và stop path.
  • Evaluation set cần slices cho missing field, high-impact, mixed language, conflict và injection-like text.
  • Quality, safety, privacy, latency, cost và regression là các gate riêng có owner.
  • Average score không đủ; release cần failure examples, human review, version và rollback plan.

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

  • Vì sao non-goals quan trọng với assistant phân loại support?
  • Một acceptance case high-impact nên buộc output làm gì?
  • Vì sao cần slice thay vì chỉ average score?
  • Khi threshold chưa có sample và owner, nên quyết định thế nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

Non-goals chặn assistant tự gửi reply, refund, đổi account hoặc quyết policy ngoài scope. Xem lại mục 2.

Xem gợi ý câu 2

Phải route/handoff cho human owner, nêu reason và không tạo side effect. Xem lại mục 2 và mục 3.

Xem gợi ý câu 3

Average có thể che nhóm high-impact hoặc minority fail; slice cho biết nhóm nào đang hỏng. Xem lại mục 3 và mục 4.

Xem gợi ý câu 4

Ghi `UNKNOWN`/`NOT_VERIFIED`, bổ sung sample và owner; chưa release chỉ vì metric nghe hợp lý. Xem lại mục 4 và mục 5.

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

Thuật ngữ Giải thích ngắn
Requirement Điều hệ thống phải làm hoặc phải tránh để đạt outcome.
Acceptance criterion Điều kiện kiểm được để quyết định output đạt hay chưa.
Evaluation set Tập input/output mẫu dùng để kiểm chất lượng.
Slice Nhóm case có đặc điểm chung cần xem riêng.
Threshold Mốc định lượng hoặc điều kiện tối thiểu.
Non-functional requirement Yêu cầu về latency, privacy, cost, reliability hoặc access.
Regression Lỗi cũ quay lại sau thay đổi.
Release gate Điều kiện và owner trước khi đưa bản mới ra dùng.

e. Nguồn tham khảo

Bài trước là Case Study: AI System Failure Analysis #18. Bài tiếp theo là Dataset và Evaluation Set Management #20.

Lưu ý giáo dục: Giữ assistant ở read-only trong bài tập, dùng request giả và kiểm slices trước average. Không cấp quyền refund, account access hoặc production action khi requirement, acceptance, owner và rollback chưa rõ.