Human in the Loop #39

Trả lời ngắn: Human in the Loop là cách đặt quyền quyết định của con người vào những điểm agent không nên tự vượt qua. Agent vẫn làm phần chuẩn bị, nhưng phải pause khi chạm trigger rủi ro, đưa đủ evidence và chỉ tiếp tục khi đúng người duyệt đúng action cùng artifact version.

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

• HITL khác việc hỏi người ở mọi bước như thế nào.
• Khi nào nên tự động, review, approval hoặc escalation.
• Một Approval Packet cần gì để người duyệt quyết định được.
• Vì sao artifact đổi thì approval cũ phải hết hiệu lực.

Lưu ý giáo dục: Bài dùng workflow xuất bản giả, không publish hay sửa dữ liệu production. Con người trong loop không tự biến hệ thống thành an toàn; vẫn cần access control, validator, sandbox, audit log và quyền tối thiểu.

1. Human in the Loop là gì?

a. Không phải cứ có nút Approve là có kiểm soát

Một content agent thu thập nguồn, viết nháp rồi chuẩn bị xuất bản. Hỏi “Được chưa?” sau từng đoạn khiến người dùng dễ bấm cho xong; chỉ hỏi sau khi public lại quá muộn.

HITL giải bài toán bằng decision rights: quyền quyết định nào thuộc agent, quyền nào thuộc người và điều kiện chuyển quyền là gì. Agent có thể tự làm việc dễ hoàn tác, chi phí thấp và nằm trong policy. Trước hành động public, nhạy cảm hoặc khó hoàn tác, job chuyển sang waiting_approval.

Hình 1 — Người không đứng trong mọi bước; họ đứng tại ranh giới nơi quyền hành động thay đổi.

b. Bốn cơ chế dễ bị trộn

Feedback “viết ngắn hơn” không đồng nghĩa cho phép publish. Approval “đăng v2” cũng không cho phép agent tự sửa thành v3 rồi đăng.

c. Human không phải guardrail duy nhất

Ví dụ coding agent muốn xóa thư mục build tạm. Policy có thể cho phép nếu đường dẫn nằm trong sandbox; xóa dữ liệu production phải bị chặn ở access layer, không chỉ hiện hộp thoại. Người duyệt có thể mệt, hiểu sai hoặc bấm nhầm.

NIST AI RMF yêu cầu vai trò human–AI được phân biệt và có tài liệu cho người quyết định. NIST Appendix C lưu ý mức oversight phụ thuộc use case.

2. Chọn đúng điểm cần người quyết định

a. Dùng impact và uncertainty, không dùng cảm giác

Đặt approval gate khi một trong các trigger vượt ngưỡng:

• Impact: có thể ảnh hưởng tiền, quyền, danh tiếng, dữ liệu hoặc người khác.
• Reversibility: khó thu hồi hoặc không khôi phục nguyên trạng.
• Authority: action vượt quyền đã cấp cho agent.
• Uncertainty: evidence thiếu, mâu thuẫn hoặc dưới confidence policy.
• Failure threshold: retry/action budget đã cạn mà goal chưa đạt.

OpenAI Practical Guide to Building Agents nêu hai trigger chính cho human intervention: vượt failure threshold và action high-risk. Đây là trigger vận hành, không phải câu “hãy cẩn thận” trong prompt.

b. Approval Map cho workflow xuất bản giả

Flow gồm sáu bước:

1. Thu thập ba nguồn đã cho phép — agent tự chạy.
2. Viết article_v1 — agent tự chạy.
3. Validator kiểm link, format và disclaimer — deterministic gate.
4. Claim mâu thuẫn — escalate cho editor, không tự chọn.
5. Tạo article_v2 — review chất lượng.
6. Publish public — approval bắt buộc vì tạo external side effect.

Người duyệt không cần xem model mở file thế nào. Họ cần thấy action sắp xảy ra, artifact cuối, evidence, phần chưa chắc và lựa chọn thay thế.

c. Ba ví dụ đặt trigger

Agent có thể tự tra trạng thái đơn, nhưng hoàn tiền lớn cần người có hạn mức. Coding agent tự chạy test, nhưng đổi secret cần owner. Research agent tóm tắt nguồn, nhưng claim y tế thiếu nguồn phải chuyển chuyên gia.

Các ngưỡng phải cụ thể. “Hoàn tiền trên 2 triệu” kiểm được; “hoàn tiền lớn” phụ thuộc diễn giải. Nếu chính sách thay đổi theo khách hàng hoặc quốc gia, hệ thống phải đọc policy version tương ứng.

3. Approval Packet, pause và resume hoạt động thế nào?

a. Packet phải giúp người quyết định, không chỉ báo trạng thái

Hình 2 — Một câu “xin duyệt” thiếu object, evidence và phạm vi thì không tạo được quyết định có trách nhiệm.

Approval Packet tối thiểu gồm:

• action và target cụ thể;
• artifact ID, version và hash;
• lý do trigger, impact và reversibility;
• evidence/source cùng validator result;
• uncertainty, điểm còn mâu thuẫn;
• lựa chọn approve, reject, edit, escalate, cancel;
• decision owner, deadline và timeout policy.

Không cần phơi private chain-of-thought. Một decision summary ngắn, evidence kiểm được và diff chính xác hữu ích hơn đoạn reasoning dài.

b. Trace từ article_v2 đến publish

Agent lưu article_v2, hash demo-a91c; validator pass. Job tạo Packet “publish slug X”, owner Content Editor, expiry 30 phút rồi chuyển waiting_approval. Worker giải phóng lease thay vì đứng chờ tốn tài nguyên.

Khi biên tập viên duyệt, hệ lưu người duyệt, thời gian, phạm vi và “dấu vân tay” bản nháp. Trước khi xuất bản, hệ kiểm dấu vân tay chưa đổi và phê duyệt còn hiệu lực. Trong ví dụ này, dấu vân tay phải vẫn là demo-a91c; nếu khác, hệ không chạy bước xuất bản giả.

Nếu editor chọn Edit, approval chưa tồn tại. Agent tạo v3, chạy validator lại và tạo packet mới. Nếu Reject, job quay về repair hoặc kết thúc theo reason code. Nếu Escalate, đúng owner mới nhận quyền quyết định.

c. Version binding chặn stale approval

Approval là capability có phạm vi, không phải vé thông hành cho cả job. Nó phải gắn với action + target + artifact_hash + policy_version + expiry.

Ví dụ editor đã duyệt v2 nhưng agent sửa tiêu đề thành v3 sau đó. Hash đổi làm approval v2 stale, tức hết hiệu lực với artifact mới. Executor phải dừng. Kết quả chỉ an toàn nếu check này được enforce trước side effect; ghi hash vào log cho đẹp là chưa đủ.

4. Lỗi phổ biến, authority và điều kiện dừng

a. Bốn lỗi thiết kế

Hình 3 — Approval thuộc về một phiên bản; nội dung đổi thì quyền cũ không được đi theo.

• Approval fatigue: hỏi quá nhiều khiến người bấm theo quán tính.
• Rubber stamp: packet chỉ có nút Approve, thiếu Reject/Edit và evidence.
• Wrong owner: người nhận thông báo không có chuyên môn hoặc thẩm quyền.
• Stale approval: artifact/policy đổi nhưng executor vẫn dùng quyết định cũ.

Google PAIR khuyên nói rõ feedback sẽ ảnh hưởng điều gì và khi nào thay đổi xảy ra. Với approval cũng vậy: UI phải cho người biết họ đang cấp quyền cho action nào, không đánh tráo với feedback để “cải thiện AI”.

b. Timeout phải fail closed

Với action public, thanh toán, xóa dữ liệu hoặc đổi quyền, hết thời hạn phải giữ waiting_approval, chuyển expired hoặc cancel. Không được hiểu im lặng là đồng ý.

Action thấp rủi ro có thể dùng policy khác, nhưng policy phải được phê duyệt trước. Nếu packet gửi sai owner, evidence thiếu hoặc state mâu thuẫn, job dừng và tạo error packet; không tự hạ ngưỡng để chạy tiếp.

c. Checklist trước khi mở gate

1. Trigger có ngưỡng kiểm được chưa?
2. Decision owner có đúng authority và năng lực không?
3. Packet có action, target, evidence, uncertainty và alternatives chưa?
4. Approval có bind version/hash, policy và expiry chưa?
5. Executor có kiểm lại binding ngay trước side effect không?
6. Reject, cancel, override và escalation có đường đi rõ không?
7. Audit log có ghi ai quyết định gì và dựa trên artifact nào không?

Nếu một câu không trả lời được, đứng ngoài action nhạy cảm. HITL chậm có chủ đích còn tốt hơn approval nhanh nhưng không biết mình vừa duyệt gì.

5. Bài tập 15 phút: vẽ Approval Map

a. Bắt đầu từ đâu

Dùng giấy, Markdown hoặc bảng tính miễn phí. Vẽ workflow giả Research → Draft → Validate → Review → Publish. Không gọi API, publish hay dùng dữ liệu cá nhân thật.

b. Mẫu đối chiếu: Approval Packet đã điền

c. Mô phỏng stale approval

Đánh dấu editor đã approve v2. Sau đó đổi một chữ và đặt hash mới demo-b72f. Hỏi executor: approval còn hiệu lực không? Đáp án là không, vì artifact binding đổi. Tạo packet mới hoặc quay lại review.

d. Tự kiểm Approval Map

Khoanh vùng agent tự chạy màu teal, gate màu cam và action cấm màu đỏ. Ghi owner cạnh từng gate. Nếu hơn nửa số bước đều hỏi cùng một người, kiểm tra dấu hiệu approval fatigue. Nếu action nhạy cảm không có expiry, reject hoặc audit trail, map chưa đạt.

6. Tổng kết: đúng người, đúng bằng chứng, đúng phiên bản

a. Năm ý chính

• HITL thiết kế quyền quyết định, không đặt người vào mọi bước.
• Trigger nên dựa trên impact, reversibility, authority, uncertainty và failure threshold.
• Approval Packet phải có action, artifact, evidence, alternatives, owner và timeout.
• Approval chỉ hiệu lực với đúng version/hash, policy, phạm vi và thời hạn.
• Human oversight phải đi cùng access control, validator, audit và fail-closed policy.

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

• Review và approval khác nhau ở quyền nào?
• Vì sao timeout không được auto-approve action nhạy cảm?
• Artifact v3 có dùng approval của v2 được không?
• Khi nào agent nên escalate thay vì retry?

c. Gợi ý đáp án

Xem gợi ý câu 1

Review đánh giá chất lượng; approval cấp quyền cho một action cụ thể. → Xem mục 1.

Xem gợi ý câu 2

Im lặng không chứng minh người có thẩm quyền đã chấp nhận impact; timeout phải pause/no-op. → Xem mục 4.

Xem gợi ý câu 3

Không. Hash/version đổi làm approval cũ stale và cần review mới. → Xem mục 3.

Xem gợi ý câu 4

Khi hết failure budget, evidence mâu thuẫn, vượt authority hoặc cần chuyên môn con người. → Xem mục 2.

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

e. Nguồn tham khảo

• OpenAI — A practical guide to building AI agents
• NIST — AI RMF Core
• NIST — Appendix C: Human-AI Interaction
• Google PAIR — Feedback + Control
• Anthropic — Trustworthy agents in practice

f. Học tiếp gì?

Xem lại Long-running Agent #38 nếu chưa rõ cách pause, lưu state và resume sau approval. Bài tiếp theo là Framework Agentic Loop #40: ghép goal, plan, act, observe, recovery và human gate thành một loop hoàn chỉnh.

Nhắc lại giáo dục: Người duyệt không nên phải đoán. Khi packet thiếu evidence, owner sai, approval stale hoặc action vượt authority, kết quả đúng là dừng và làm rõ trước khi tiếp tục.