Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 2 — Phân loại rủi ro hành động và bản đồ mức tự chủ

Đã đọc 0/7 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Bài trước ta đã đặt câu hỏi định tính. Bài này ta biến chúng thành một thang rủi ro có thể lập trình, để agent tự quyết định khi nào cần người duyệt mà không cần bạn hard-code từng trường hợp.

Ba yếu tố tạo nên rủi ro

Mọi hành động write đều có thể chấm điểm theo ba trục:

  • Tác động (Impact): nếu hành động này sai, thiệt hại lớn cỡ nào? (tiền, dữ liệu, danh tiếng, pháp lý)
  • Khả năng hoàn tác (Reversibility): undo dễ, khó, hay không thể? Gửi email đã đi = không undo. Cập nhật một dòng DB có bản backup = undo được.
  • Độ tin cậy của agent (Confidence): agent chắc chắn tới đâu về hành động này? Đầu vào mơ hồ, ngữ cảnh thiếu → độ tin cậy thấp.
Một công thức đơn giản để kết hợp:

risk = impact * (1 - reversibility) * (1 - confidence)
// impact: 1..5, reversibility: 0..1, confidence: 0..1

Hành động tác động lớn, không undo được, agent không chắc → risk rất cao → phải qua người.

Bản đồ mức tự chủ (Autonomy Ladder)

Gán mỗi khoảng điểm rủi ro vào một mức tự chủ:

MứcĐiểm rủi roHành vi
L00 – 1Tự động, không cần log riêng
L11 – 3Tự động + ghi audit log
L23 – 6Tự động nhưng có thể undo trong 30 phút
L36 – 10Cần 1 người duyệt trước khi thực thi
L4> 10Cần 2 người duyệt + cảnh báo quản lý
Bảng này chính là policy của agent. Điểm mạnh: khi rủi ro thay đổi (ví dụ số tiền lớn hơn), agent tự nhảy mức mà không cần sửa code logic.

Ví dụ cụ thể: cùng một tool, ba mức

Agent có tool send_refund(amount, order_id):

def assess_refund_risk(amount, order_confidence):
    impact = min(5, amount / 1_000_000)      # 1tr = 1 điểm impact
    reversibility = 0.0                       # tiền đã hoàn khó lấy lại
    confidence = order_confidence             # agent tự đánh giá 0..1
    return impact * (1 - reversibility) * (1 - confidence)

# 500k, chắc chắn 0.95 -> risk thấp -> L1 tự động
# 3tr,  chắc chắn 0.9  -> risk trung -> L3 cần duyệt
# 30tr, chắc chắn 0.6  -> risk cao   -> L4 hai người duyệt

Các bước xây bản đồ rủi ro cho agent của bạn

  • Lập danh sách tool/hành động từ bề mặt hành động ở Bài 1.
  • Cho điểm impact tối đa của mỗi tool (giả định trường hợp xấu nhất).
  • Xác định reversibility — có backup/undo không, trong bao lâu.
  • Định nghĩa cách agent tự tính confidence (dựa trên độ đầy đủ của input, kết quả validate, số lần thử lại...).
  • Chọn ngưỡng cho từng mức L0–L4 phù hợp khẩu vị rủi ro của tổ chức.
  • Viết policy thành cấu hình tách rời code (JSON/YAML) để chỉnh mà không deploy lại.

Khung tư duy: ma trận Impact × Reversibility

            Undo được        Không undo được
Tác động ít  L0/L1 (auto)     L2 (auto + cửa sổ undo)
Tác động lớn L2/L3 (duyệt)    L4 (2 người duyệt)

Đây là cách rút gọn khi bạn chưa muốn dùng công thức số: chỉ cần định vị hành động vào một trong bốn ô.

Sai lầm thường gặp

  • Chấm điểm rủi ro một lần rồi để nguyên. Rủi ro phụ thuộc tham số động (số tiền, số bản ghi bị ảnh hưởng); phải tính tại thời điểm gọi, không phải gán cứng cho tool.
  • Bỏ qua confidence của agent. Cùng hành động, khi input mơ hồ thì rủi ro thực tế cao hơn nhiều — thang đo phải phản ánh điều đó.
  • Đặt ngưỡng quá nhạy. Nếu gần như mọi hành động rơi vào L3/L4, người duyệt bị quá tải và bạn quay lại vòng approval fatigue.
  • Nhét policy vào trong code agent. Khi muốn nới/siết kiểm soát, bạn phải sửa và deploy lại — nên tách policy ra cấu hình.
Bài sau, ta sẽ hiện thực hóa cổng phê duyệt: chèn điểm dừng vào luồng agent để hành động rủi ro cao tạm treo chờ người duyệt.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi