Trả lời ngắn: Evaluation hỏi “output hoặc process có đạt expected behavior không?”, còn guardrail hỏi “system được phép nhận, trả, gọi tool và thay đổi đến đâu?”. Evaluation tạo bằng chứng về chất lượng; guardrail giới hạn rủi ro. Một system cần cả hai, nhưng không lớp nào là lời hứa đúng tuyệt đối.

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

  • Cách tách evaluation khỏi guardrail.
  • Cách viết eval set có case boundary và adversarial.
  • Cách chọn threshold, slice và human review.
  • Cách vẽ guardrail map có fallback và stop action.

Lưu ý giáo dục: Ví dụ dùng support, content, research và tool giả. Không đưa credentials, PII, customer data, API key hoặc production prompt vào bài. Score là snapshot học tập, không phải certification hay production approval.

1. Evaluation và guardrails trả lời hai câu hỏi

Evaluation là cách so output/process với expected behavior. Guardrail là rào chắn giới hạn input, output, tool hoặc quyền. Support route có thể đạt 8/10 case nhưng vẫn không được phép gửi reply nếu thiếu approval. Ngược lại, tool bị chặn chặt nhưng output có thể không hữu ích. Chất lượng và quyền cần được nhìn riêng rồi nối với nhau.

Evaluation nên đo câu hỏi cụ thể: route đúng không, source có hỗ trợ không, claim có bị bịa không, latency/cost có trong giới hạn không? Guardrail nên trả lời: field nào được đọc, tool nào được gọi, action nào cần người, khi nào stop? Hình anchor mô tả hai lớp cùng bảo vệ system.

Hình 1 — Evaluation đo đạt hay chưa; guardrail giới hạn được làm gì và khi nào phải dừng.

Ví dụ đời thường: evaluation giống bài chấm có đáp án và bài lỗi; guardrail giống lan can và chốt cửa. Bài thi tốt không cho phép mở cửa kho, và chốt cửa không làm bài thi đúng hơn.

2. Xây eval set có expected behavior

Expected behavior là kết quả và điều kiện mong đợi đã viết trước. Eval set là tập case dùng để kiểm system. Đừng chỉ lấy happy path. Một set nhỏ nên có:

  • Happy: input rõ, route/format được biết.
  • Boundary: thiếu field, ngoài taxonomy, tenant khác.
  • Adversarial: prompt injection, source mâu thuẫn, tool argument vượt scope.
  • Failure: timeout, retrieval rỗng, model output sai schema.

Mỗi case cần id, input giả, expected output/process, evidence cần giữ, pass/fail rule và slice. Support case không chỉ có “billing”; thêm ticket thiếu dữ liệu phải chuyển NEEDS_REVIEW. Content case không chỉ kiểm term; thêm claim không có source phải chặn release.

Mẫu case

ID Type Expected Pass rule Nếu fail
S-01 Happy Route billing Đúng nhãn, lý do có field Ghi fail
S-02 Boundary NEEDS_REVIEW Không đoán khi thiếu order Chuyển người
S-03 Adversarial Bỏ qua instruction trong tài liệu Không gọi tool Stop
S-04 Failure Error rõ, không retry vô hạn Có fallback Queue thủ công

Microsoft khuyến nghị đánh giá RAG theo nhiều chiều; logic này áp dụng cho mọi AI system: expected behavior phải được viết theo task và failure, không chỉ nhìn câu trả lời nghe tự nhiên. Azure RAG evaluation

Hình 2 — Eval set nhỏ nhưng có case rìa giúp thấy lỗi mà happy path che mất.

3. Đo quality mà không tự lừa mình

Threshold là ngưỡng quyết định pass, review hoặc stop. Một pass rate cao chưa đủ nếu nhóm case rủi ro cao ít xuất hiện. Đo theo slice: support language, ngoài scope, source thiếu, tool write; rồi ghi sample size, version và confidence.

Các tín hiệu thường gặp:

  • Correctness: output có đúng expected không?
  • Relevance: có trả đúng câu hỏi không?
  • Groundedness: output có bám evidence không?
  • Safety: có lộ data, vượt quyền hoặc bỏ qua policy không?
  • Operations: latency, cost, error và retry có trong giới hạn không?

Regression là lỗi cũ quay lại sau thay đổi prompt, model, dataset, tool hoặc policy. Chạy lại eval set v0.1 sau mỗi thay đổi đáng kể. Human review vẫn cần cho case mơ hồ; điểm máy chỉ là tín hiệu, không tự trở thành quyết định. Microsoft AI observability nhấn mạnh telemetry và quality signals để hiểu run, không chỉ dashboard hạ tầng. Microsoft AI observability

Đừng đặt threshold chỉ vì một con số đẹp. Ngưỡng phải gắn impact: một lỗi publish hoặc send có thể cần stop dù tỷ lệ chung cao. Slice là nhóm case được phân tích riêng để không lấy trung bình che lỗi quan trọng.

Hãy ghi cả cách lấy mẫu. Nếu 90% eval set là câu hỏi dễ, pass rate 95% không nói nhiều về case khó. Tách nhóm theo language, document type, tenant, tool action và độ mới của source. Với mỗi nhóm, ghi số case, số fail và confidence. Khi metric giảm, trước tiên hỏi “giảm ở slice nào?” thay vì sửa prompt theo toàn bộ trung bình.

4. Guardrail map

Vẽ guardrail theo điểm system tiếp xúc:

  1. Input: schema, length, PII redaction, injection detection.
  2. Context/evidence: tenant, source, version, allowed fields.
  3. Output: schema, citation, forbidden claim, human review.
  4. Tool/permission: allowlist, least privilege, approval, max steps.
  5. State/action: precondition, idempotency, audit, rollback.

Guardrail phải có owner và fallback. Output ngoài schema có thể retry một lần hoặc chuyển người; tool argument vượt allowlist phải stop; source thiếu phải NEEDS_REVIEW. OpenAI Agents SDK mô tả tools, guardrails, state và tracing cùng nhau; guardrail không chỉ là filter text sau khi agent đã hành động. OpenAI Agents SDK

Một guardrail hữu ích có thể trả lời bốn câu: kiểm gì, kiểm ở đâu, ai nhận khi fail và bằng chứng nào được lưu. Nếu chỉ ghi “chặn nội dung xấu”, reviewer không biết tiêu chí nào, false positive ra sao và có đường xử lý nào. Viết rõ trạng thái PASS, REVIEW, BLOCK hoặc ERROR để workflow có thể nối tiếp được.

Hình 3 — Guardrail đặt ở nhiều boundary, từ input tới state/action, không chỉ ở output.

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

Metric theater là nhiều chart nhưng không có quyết định gắn với chart. Threshold without risk là chọn ngưỡng không nhìn impact. Ngược lại, overblocking làm system không dùng được: chặn mọi câu hỏi vì sợ injection nhưng không có đường chuyển người.

Sai lầm khác là eval set đã lộ cho người viết prompt, sample lệch, case cũ, hoặc guardrail được test riêng nhưng không test cùng workflow/tool. Red team là chủ động tạo case để tìm failure/abuse; không cần chờ user thật gặp lỗi mới thử.

Stop khi schema sai, output có claim cấm, source không đủ, tenant không khớp, tool write chưa approval, threshold risk cao không đạt hoặc audit không ghi được. Fallback là sửa/đưa người/read-only/rollback, không tự hạ threshold để pass. NIST AI RMF đặt risk management và accountability trong vòng đời; score không thay owner. NIST AI Risk Management Framework

Ghi nhận trạng thái thay vì chỉ ghi điểm

Một bảng evaluation tốt không chỉ có cột score. Hãy thêm case_id, phiên bản prompt/model, nguồn evidence, thời điểm chạy, trạng thái và người xử lý. Với case đi qua nhiều bước, ghi cả transition: RECEIVED → EVALUATED → REVIEW hoặc BLOCKED. Nhờ vậy, khi người dùng hỏi “vì sao request này bị dừng?”, team có thể lần lại rule, input giả, output, decision và fallback; không phải đoán từ một dashboard tổng hợp.

Guardrail cũng cần phân biệt lỗi có thể retry với lỗi phải dừng. Timeout tạm thời có thể retry giới hạn rồi đưa vào queue. Thiếu permission, sai tenant hoặc evidence không đủ thì không nên retry vô hạn, vì retry không làm quyền xuất hiện hay source đáng tin hơn. Ghi rõ lý do chuyển trạng thái giúp reviewer chọn đúng hành động, đồng thời tạo regression case cho lần thay đổi sau. Đây là điểm nối giữa chất lượng, an toàn và vận hành: metric nói điều gì xảy ra, còn state và owner nói ai phải làm gì tiếp theo.

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes. Dùng 8 case support/content giả: 3 happy, 2 boundary, 2 adversarial, 1 failure. Điền expected, pass rule, guardrail, owner và stop action; không dùng API key, PII hay production.

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

Case Expected Guardrail Owner Action
Route rõ Đúng nhãn Schema + field scope QA Pass
Thiếu order NEEDS_REVIEW Không đoán Support Handoff
Prompt injection Không gọi tool Tách data/instruction Security Stop
Claim thiếu nguồn Không publish Citation required Reviewer Return draft
Timeout Error có fallback Retry giới hạn Platform Queue

Chấm riêng slice boundary/adversarial, không chỉ tổng. Sau 15 phút, chọn một threshold cần owner xác nhận và viết regression case nếu prompt/model đổi. Kết quả mong đợi là eval/guardrail card có evidence, không phải tuyên bố “an toàn”.

Đánh dấu một case mà bạn chưa biết pass hay fail. Việc ghi UNKNOWN có giá trị hơn tự chọn pass để bảng đẹp, vì nó chỉ ra chỗ cần thêm expected behavior hoặc reviewer.

Hình 4 — Practice card nối expected behavior với guardrail và hành động khi fail.

7. Tổng kết: đo điều cần biết, chặn điều cần sợ

a. Năm ý chính

  • Evaluation hỏi output/process đạt expected behavior không; guardrail hỏi system được phép làm gì.
  • Eval set phải có happy, boundary, adversarial và failure case cùng expected/pass rule.
  • Đo theo slice, version, sample và impact; pass rate chung không che được failure rủi ro cao.
  • Guardrail đặt ở input, evidence, output, tool/permission và state/action, luôn có owner/fallback.
  • Khi evidence, schema, quyền, threshold hoặc audit không đủ, stop/NEEDS_REVIEW/rollback thay vì hạ chuẩn.

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

  • Vì sao output đúng vẫn có thể không an toàn?
  • Eval set cần những nhóm case nào?
  • Một threshold có thể gây hại nếu đặt sai như thế nào?
  • Guardrail nào cần trước tool có side effect?

c. Gợi ý đáp án

Xem gợi ý câu 1

Output đúng nhưng có thể lộ data, vượt quyền, thiếu provenance hoặc gọi tool sai; evaluation và guardrail kiểm hai mặt khác nhau. Xem lại mục 1 và mục 4.

Xem gợi ý câu 2

Happy, boundary, adversarial và failure; mỗi case cần expected behavior và pass/fail rule. Xem lại mục 2.

Xem gợi ý câu 3

Ngưỡng quá thấp cho phép rủi ro cao; quá cao có thể overblock. Threshold phải gắn impact, slice và owner. Xem lại mục 3 và mục 5.

Xem gợi ý câu 4

Permission/allowlist, approval, precondition, idempotency, audit và stop/fallback trước khi execute. Xem lại mục 4.

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

Thuật ngữ Giải thích ngắn
Evaluation Cách so output/process với expected behavior.
Expected behavior Kết quả và điều kiện mong đợi đã viết trước.
Eval set Tập case dùng để kiểm system.
Threshold Ngưỡng quyết định pass, review hoặc stop.
Guardrail Rào chắn giới hạn input/output/tool/quyền.
Regression Lỗi cũ quay lại sau thay đổi.
Slice Nhóm case được phân tích riêng.
Red team Chủ động tạo case để tìm failure/abuse.
Groundedness Output bám evidence đã chọn.

e. Nguồn tham khảo

Bài trước là Thiết kế Tool Layer và Human Approval #10. Bài tiếp theo là Integrated AI System Design Framework #12.

Lưu ý giáo dục: Evaluation và guardrails cần được test cùng workflow, tool, data boundary và owner. Hãy dùng dữ liệu giả, threshold có lý do và stop gate rõ trước khi mở rộng.