Human-in-the-loop và Kill Switch trong AI Trading #29

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư, tư vấn pháp lý hoặc tín hiệu giao dịch.

Trả lời ngắn: Human-in-the-loop trong AI Trading là cách phân quyền để con người quyết định tại điểm rủi ro cao, không phải bấm mọi lệnh. Kill Switch là kiểm soát độc lập chặn lệnh mới, xử lý lệnh đang mở theo phạm vi định trước và giữ hệ thống đóng tới khi đối chiếu xong.

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

• Khi nào cần người duyệt, khi nào chỉ cần người giám sát.
• Một kill switch thật khác nút “tắt bot” trên màn hình thế nào.
• Cách thiết kế trigger, phạm vi dừng và điều kiện mở lại.

1. Con người nên đứng ở đâu trong vòng lặp?

a. Human-in-the-loop không có nghĩa duyệt mọi lệnh

Human-in-the-loop (HITL) là cơ chế yêu cầu người có thẩm quyền quyết định trước một hành động đã được phân loại là quan trọng. Ví dụ, hệ thống có thể tự thu thập dữ liệu và tính tín hiệu, nhưng lần bật giao dịch thật đầu tiên phải được người vận hành phê duyệt.

Nếu phải bấm “Approve” liên tục, người duyệt dễ bị approval fatigue — mệt vì xác nhận quá nhiều — rồi bấm theo phản xạ. Khi đó có người trong quy trình nhưng kiểm soát rất yếu.

Approval gate là điểm dừng trước action cụ thể. Người duyệt cần thấy bằng chứng, rủi ro, phiên bản và lựa chọn từ chối.

b. Human-on-the-loop là giám sát, không duyệt trước

Human-on-the-loop (HOTL) nghĩa hệ thống được tự chạy trong hàng rào đã đặt, còn con người theo dõi cảnh báo và có quyền override. Override là quyết định của người thay thế hoặc dừng hành vi tự động đang diễn ra.

Ví dụ: bot chỉ được hoạt động với exposure giả lập tối đa 1.000 USD và drawdown phiên 2%. Deterministic risk engine — luật chạy bằng code, không dựa vào lời giải thích của model — kiểm mọi order. Nếu vượt giới hạn, máy trip kill switch; không chờ người nhìn điện thoại.

c. Ba chế độ nên phối hợp

Hình 1 — Không phải chỗ nào cũng cần người bấm; phản ứng nhanh thuộc guardrail, quyết định tăng quyền thuộc con người.

NIST AI RMF đề cập vai trò human–AI, giám sát sau triển khai, override, incident response và recovery (NIST AI RMF Core). Tức là vai trò phải có tên và trách nhiệm.

2. Kill Switch thật sự phải làm gì?

a. Stop process chưa chắc đã stop trading

Kill Switch là cơ chế dừng khẩn cấp được thực thi ngoài model. Nó không hỏi model có đồng ý dừng không. Khi trigger hợp lệ xuất hiện, lớp kiểm soát phải chặn đường order trước khi hành động tiếp theo chạm sàn.

Đóng cửa sổ bot chỉ tắt process local; limit order cũ vẫn có thể nằm trên sàn và API key còn quyền. Nút đổi nhãn “Running” thành “Stopped” chưa phải kill switch.

CME mô tả kill switch là chặn order mới và hủy working orders trong phạm vi đã chọn (CME Enforcing Kill Switch). Ví dụ này cho thấy “ngừng gửi mới” và “xử lý lệnh chờ” là hai việc riêng.

b. Chuỗi sáu bước fail-closed

Fail-closed nghĩa khi trạng thái chưa rõ, hệ thống giữ quyền giao dịch ở trạng thái đóng. Chuỗi tối thiểu:

1. Detect: risk engine phát hiện trigger từ dữ liệu đo được.
2. Trip: ghi sự kiện bất biến, timestamp, nguồn và phạm vi.
3. Block new: chặn mọi ý định/order mới thuộc phạm vi.
4. Cancel open: yêu cầu hủy working orders nếu policy quy định.
5. Reconcile: đối chiếu order, fill, balance và exposure thật.
6. Human reset: người có quyền xem evidence rồi mở lại có kiểm soát.

Hình 2 — Reset đứng sau reconciliation; tắt cảnh báo không đồng nghĩa hệ thống đã an toàn để giao dịch lại.

c. Phạm vi dừng phải được chỉ rõ

Kill có thể áp dụng cho strategy, account, API key, venue hoặc toàn hệ thống. Quá hẹp thì lệnh lọt đường khác; quá rộng thì gián đoạn không cần thiết.

Ghi scope_id vào order intent. Khi strategy A bị kill, gateway từ chối intent mới. Cancel order và close position là hai action khác nhau; đóng vị thế cần policy riêng.

3. Ví dụ: từ breach tới reset có kiểm soát

a. Tình huống giả lập

Một hệ thống demo có giới hạn:

• Exposure tối đa: 1.000 USD.
• Drawdown trong phiên: 2,0%.
• Slippage cảnh báo: 0,20%; trip tại 0,35% trong ba fill liên tiếp.
• Heartbeat dữ liệu tối đa: 5 giây.

Exposure là giá trị đang chịu biến động. Drawdown là mức giảm từ đỉnh. Heartbeat là tín hiệu định kỳ chứng minh nguồn dữ liệu còn sống; kết nối còn mở không có nghĩa dữ liệu còn mới.

Lúc 10:12:00, ba fill giả có slippage 0,18%, 0,39% và 0,41%. Chưa đủ ba lần vượt 0,35%. Đến 10:12:08, feed không có heartbeat trong 7 giây. Trigger stale feed độc lập được kích hoạt ngay, không cần chờ slippage thứ ba.

b. Điều gì xảy ra sau trigger?

Risk gateway chuyển strategy_demo_01 sang KILLED. Intent mới bị từ chối trước API. Hệ thống yêu cầu hủy hai working orders nhưng chưa ghi “đã hủy” khi venue chưa xác nhận. Một order fill thêm 120 USD trước khi cancel tới nơi.

Reconciliation — đối chiếu local state với order, fill và balance — cho exposure thật 720 USD, không phải 600 USD trên cache. Incident log ghi:

c. Reset không phải bật nút lại ngay

Reset là khôi phục quyền hoạt động sau khi nguyên nhân đã được xử lý và hậu điều kiện đã đạt. Với ví dụ này, checklist reset gồm: feed mới liên tục 5 phút, order/fill/balance khớp, không còn working order ngoài dự kiến, incident owner ký nhận và chạy thử paper mode.

Người duyệt gửi reset request có danh tính, lý do và phạm vi; không sửa thẳng cờ database. Control plane kiểm hậu điều kiện rồi mới mở gateway.

4. Những sai lầm hay gặp và giới hạn thật

a. Đặt kill switch trong cùng process với bot

Nếu bot treo hoặc mất mạng, nút dừng trong cùng process có thể vô dụng. Control plane và order gateway nên độc lập với model worker, có đường dừng ngoài worker.

Sai lầm thứ hai là cho model đổi threshold hoặc tự reset. Model có thể đề xuất; kiểm soát xác định phải xác minh và người có quyền phê duyệt. SEC Market Access FAQ yêu cầu automated pre-trade control tại điểm order được điện tử hóa và direct, exclusive control với công cụ đó (SEC FAQ). Đây là tham chiếu thiết kế, không phải tư vấn pháp lý.

b. Cảnh báo nhưng không có owner

Alert gửi cho 20 người thường là việc của không ai. Mỗi sự cố cần incident owner, decision owner có quyền reset và đường escalation.

Audit trail ghi ai làm gì, lúc nào, với scope và evidence nào; gồm cả request bị chặn, reset thất bại và thay đổi threshold. Nó phục vụ điều tra, không tự ngăn sự cố.

c. Con người cũng có giới hạn

Người vận hành có thể nhìn nhầm, ngủ quên hoặc bị overload. HITL không thay giới hạn tự động; sự kiện dưới một giây không thể chờ người.

Kill switch không hoàn tác fill, không bảo đảm cancel tới mọi venue và không sửa dữ liệu sai. Phải có incident plan và bằng chứng đo “kill thành công”.

5. Checklist thiết kế và vận hành an toàn

a. Trước khi bật hệ thống

1. Liệt kê action tự động, action cần approval và action bị cấm.
2. Đặt threshold bằng code/config được version hóa; không dùng câu prompt mơ hồ.
3. Gắn scope cho mọi intent, order, fill và alert.
4. Tách model worker khỏi risk gateway và kill control.
5. Chỉ định incident owner, decision owner và escalation backup.
6. Định nghĩa chính xác kill làm gì với order mới, working order và position.
7. Viết điều kiện reset có thể kiểm bằng dữ liệu.
8. Chạy paper drill cho từng trigger trước khi cân nhắc tiền thật.

b. Khi kill switch đã trip

Đừng mở lại chỉ vì metric bình thường. Hãy freeze, lưu evidence, query venue, reconcile exposure, xử lý nguyên nhân, kiểm hậu điều kiện rồi xin reset. Còn UNKNOWN, feed chưa ổn hoặc thiếu log thì tiếp tục đứng ngoài.

Xem thêm rủi ro API và thực thi: timeout không chứng minh cancel thành công hay thất bại. Bài model drift giải thích trigger đến từ hành vi model thay đổi.

c. Kiểm thử định kỳ

Sau thay đổi quan trọng, thử: worker treo, stale feed, venue timeout, breach limit và reset sai quyền. Đo thời gian block, order lọt sau trip, thời gian reconcile và audit log.

Không chứng minh được gateway đã chặn thì drill thất bại. Screenshot nút đỏ chưa phải bằng chứng.

6. Bắt đầu từ đâu: Kill Switch Drill 15 phút

Dùng Google Sheets hoặc giấy, không kết nối sàn và không dùng tiền thật. Tạo Kill Switch Card gồm Trigger, Evidence, Scope, Owner, Action, Reconcile và Reset Condition.

Hình 3 — Card buộc người thiết kế nói rõ bằng chứng, phạm vi và điều kiện reset thay vì chỉ viết “có nút dừng”.

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

Tự trả lời: cancel API timeout thì trạng thái gì; working order fill sau trip thì lấy exposure ở đâu; owner im lặng thì ai xử lý? Kết quả đúng là FREEZE, giữ UNKNOWN, reconcile từ fill/balance và gọi escalation backup.

7. Tổng kết

Năm ý chính

• HITL là phân quyền tại điểm rủi ro, không phải duyệt mọi lệnh.
• Phản ứng tức thời cần deterministic guardrail; con người quyết định tăng quyền/reset.
• Kill switch phải chặn order mới và nêu cách xử lý working order.
• Reset chỉ diễn ra sau reconciliation và hậu điều kiện có bằng chứng.
• Drill phải đo đường dừng thật; nút giao diện và alert không đủ.

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

• HITL khác HOTL ở đâu?
• Vì sao tắt process chưa chắc dừng trading?
• Khi nào được reset?
• Kill switch có mặc định đóng position không?
• Metric nào chứng minh drill đạt?

Gợi ý đáp án

Tự kiểm tra 1: HITL khác HOTL ở đâu?

HITL yêu cầu người quyết định trước action; HOTL cho máy chạy trong hàng rào và người giám sát. Xem lại mục 1.

Tự kiểm tra 2: Vì sao tắt process chưa chắc dừng trading?

Working order có thể vẫn nằm trên venue và gateway vẫn hoạt động. Xem lại mục 2.

Tự kiểm tra 3: Khi nào được reset?

Sau khi reconcile, xử lý nguyên nhân, đạt hậu điều kiện và đúng owner duyệt. Xem lại mục 3.

Tự kiểm tra 4: Kill switch có đóng position không?

Không. Cancel order và close position là hai action khác nhau. Xem lại mục 2.

Tự kiểm tra 5: Metric nào chứng minh drill đạt?

Đo thời gian block, order lọt sau trip và độ đầy đủ reconciliation/log. Xem lại mục 5.

Thuật ngữ cần nhớ

Nguồn tham khảo

• NIST AI RMF Core
• SEC Market Access Rule FAQ
• CME Enforcing Kill Switch

Đọc tiếp: Risk Management trong AI Trading, Black-box AI và khả năng giải thích và bài kế tiếp về cách đánh giá một nền tảng AI Trading.

Chọn đúng bài trong lộ trình

Bài này tập trung vào human-in-the-loop AI Trading — điểm can thiệp, giám sát và dừng khẩn cấp. Nếu bạn cần bức tranh chung trước khi đi sâu, hãy bắt đầu từ AI Trading là gì? Hướng dẫn từ nền tảng đến kiểm định. Các bước liên quan trực tiếp là AI Agent và Agentic Trading, Risk Management trong AI Trading và Rủi ro API, sàn và lỗi thực thi.

Nội dung chỉ nhằm mục đích giáo dục. Hãy kiểm tra yêu cầu pháp lý, điều khoản sàn và năng lực kiểm soát độc lập trước bất kỳ triển khai thực tế nào.