Quy trình xây một hệ thống AI Trading #31

Nội dung này phục vụ mục đích giáo dục, không phải hướng dẫn triển khai tiền thật hoặc tín hiệu giao dịch.

Trả lời ngắn: Quy trình xây hệ thống AI Trading bắt đầu từ quyết định cần hỗ trợ và rủi ro được phép, không phải từ model. Một vòng đời tối thiểu gồm decision contract, baseline, data contract, model candidate, validation, paper/shadow test, controlled launch và monitoring có rollback. Mỗi stage chỉ đi tiếp khi artifact và acceptance gate đều đạt.

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

• Vì sao model tốt chưa đủ tạo thành hệ thống tốt.
• Mỗi stage cần đầu vào, đầu ra và gate nào.
• Cách vẽ System Design Card trước khi viết code hoặc dùng tiền thật.

1. Bắt đầu từ quyết định, không bắt đầu từ thuật toán

a. Viết decision contract

Decision contract là mô tả ngắn về quyết định hệ thống hỗ trợ: đối tượng, thời điểm, output, người nhận, giới hạn và hành động bị cấm. Ví dụ: “Mỗi 15 phút, hệ thống demo xếp trạng thái BTC thành RISK-ON, NEUTRAL hoặc RISK-OFF để phục vụ paper portfolio; không tự đặt lệnh.”

Nó khác mục tiêu mơ hồ “dùng AI kiếm lợi nhuận”. Decision contract giúp chọn label, dữ liệu, metric và latency. Nếu output chỉ phục vụ báo cáo cuối ngày, không cần hạ tầng millisecond. Nếu không biết ai dùng output và làm gì sau đó, chưa nên train model.

b. Đặt objective và risk budget

Objective là đại lượng hệ thống tối ưu. Trading không nên chỉ tối ưu accuracy; còn turnover, chi phí, drawdown, exposure và độ ổn định. Risk budget là giới hạn tổn thất hoặc hành vi được phép trong thử nghiệm, chẳng hạn paper drawdown 3%, zero live order và tối đa một candidate deploy mỗi tuần.

Google Rules of ML khuyên giữ pipeline end-to-end vững, bắt đầu bằng objective hợp lý và giải pháp đơn giản trước khi tăng complexity (Google Rules of ML). Trong trading, baseline đơn giản còn giúp phát hiện model “thông minh” nhưng không hơn quy tắc ngây thơ sau phí.

2. Bảy stage và artifact bắt buộc

Hình 1 — Monitoring không phải stage cuối rồi thôi; evidence mới quay lại decision, data và validation.

Stage 1 — Problem và decision contract

Artifact: Decision Card gồm user, action, cadence, latency, risk, non-goal và owner. Gate: người dùng nghiệp vụ giải thích được output sẽ thay đổi quyết định nào.

Stage 2 — Baseline

Baseline là mốc đơn giản để so candidate: luôn NEUTRAL, moving-average rule hoặc logistic regression ít feature. Gate: baseline chạy qua cùng data, cost và metric. Không được so model sau phí với baseline trước phí.

Stage 3 — Data contract

Data contract mô tả schema, nguồn, timestamp, timezone, độ trễ, missing value, corporate action, label horizon và quyền sử dụng. Gate: pipeline bắt được duplicate, gap, future timestamp và training-serving mismatch.

Stage 4 — Candidate model và experiment

Mỗi experiment phải version code, config, data snapshot, feature list, seed và result. Gate: reproduce được kết quả và model card ghi giới hạn. Nếu feature lúc train không tồn tại đúng thời điểm inference, đó là leakage.

Stage 5 — Validation

Tách train/validation/test theo thời gian; dùng walk-forward, stress phí/slippage, regime split và failure test. Gate: candidate vượt baseline theo metric đã chốt trước, không chỉ một đường equity đẹp. Xem walk-forward analysis và data leakage.

Stage 6 — Paper, shadow và controlled launch

Paper mô phỏng order, không gửi sàn. Shadow mode chạy cạnh hệ thống thật nhưng output không có quyền hành động. Controlled launch cấp quyền rất hẹp về account, size, venue và thời gian. Mỗi bước có promotion gate; thất bại quay lại sửa, không nới tiêu chuẩn.

Stage 7 — Monitor, incident và change

Theo dõi data freshness, schema, feature drift, prediction, signal rate, order/fill, slippage, exposure, PnL attribution và control health. Có alert owner, kill switch, rollback version và lịch review. NIST AI RMF xem risk management là hoạt động liên tục suốt lifecycle, gồm post-deployment monitoring, incident response, recovery và change management (NIST AI RMF Core).

3. Ví dụ: baseline thắng candidate sau chi phí

a. Setup giả lập

Decision contract: mỗi giờ chọn TRADE hoặc STAY_OUT cho paper strategy BTC, horizon 4 giờ. Dữ liệu 2022–2025 được chia theo thời gian. Baseline dùng rule đơn giản; candidate là gradient boosting 40 feature.

Metric đã khóa trước test:

• Net return sau phí giả 0,08% mỗi lượt.
• Max drawdown không quá 8% trong paper.
• Turnover tối đa 40 lượt/tháng.
• Không có data leakage hoặc timestamp violation.

b. Kết quả trước và sau cost

Candidate thắng gross nhưng thua net, vượt turnover và drawdown gate. Quyết định đúng là REJECT, không đổi cost assumption sau khi thấy kết quả. Đây là ví dụ vì sao pipeline và objective sở hữu quyết định; model không được tự chấm bài mình.

c. Sửa có kiểm soát

Nhóm tạo candidate v2 với threshold cao hơn và giới hạn trade. V2 phải chạy lại cùng test contract; không được xem test set rồi liên tục chỉnh tới khi đẹp. Nếu test set đã bị dùng để ra quyết định nhiều lần, nó không còn độc lập và cần holdout mới.

4. Promotion gate, sai lầm và giới hạn

Hình 2 — Quyền hành động chỉ tăng sau bằng chứng; không có đường tắt từ notebook sang live.

a. Promotion gate phải fail-closed

Mỗi gate có owner, evidence, threshold, expiry và rollback. PASS cho model version 12 không tự áp dụng version 13. Khi artifact, data hoặc config đổi, approval cũ hết hiệu lực.

Sai lầm phổ biến là để cùng người train model, chọn metric và duyệt deploy. Với đội nhỏ, có thể chưa tách người nhưng phải tách thời điểm và checklist: metric khóa trước, report sinh tự động, log không sửa tay.

b. Ba lỗi kiến trúc

Lỗi một: notebook là production. Notebook thiếu retry, version, monitoring và recovery. Lỗi hai: train/serve dùng hai cách tạo feature, gây training-serving skew — feature khi chạy thật khác lúc train. Google khuyên tái sử dụng code và log feature serving để giảm skew (Google Rules of ML).

Lỗi ba: chỉ monitor PnL. PnL trộn market regime, model, execution và risk sizing; khi PnL xấu mới điều tra thì quá chậm. Cần leading indicators như data age, missing rate, prediction distribution và rejection rate.

c. Giới hạn thực tế

Quy trình tốt không làm tương lai chắc chắn. Backtest vẫn là quá khứ; paper không tái hiện hết market impact; controlled live vẫn có venue/API risk. Hệ thống phải có điều kiện đứng ngoài và khả năng decommission — ngừng sử dụng an toàn — khi mục tiêu không còn hợp lệ.

Một giới hạn khác là chi phí vận hành. Thêm model nghĩa là thêm data job, registry, cảnh báo, người trực và quy trình review. Nếu giá trị quyết định nhỏ hơn chi phí giữ pipeline đáng tin cậy, baseline có thể là lựa chọn đúng hơn. “Không triển khai model” cũng là một kết quả hợp lệ của Stage 5, không phải thất bại của nhóm nghiên cứu.

Artifact cũng cần thời hạn. Data report tháng trước không chứng minh feed hôm nay còn đúng; approval cho model cũ không cấp quyền cho model mới. Vì vậy mỗi artifact nên có version, người sở hữu, ngày tạo và điều kiện hết hiệu lực.

5. Checklist từ paper tới controlled launch

1. Khóa decision contract, baseline, metric và risk budget.
2. Version data/code/config/model và tạo lineage.
3. Chạy unit, data, leakage, walk-forward và cost stress test.
4. Paper đủ số tình huống, gồm lỗi feed/API và market regime khác nhau.
5. Shadow so output với baseline và quyết định của operator.
6. Rehearse kill switch, rollback, revoke key và reconciliation.
7. Limited launch bằng account/scope/size nhỏ nhất; không withdrawal.
8. Đặt review date, stop condition và owner trực.

Không promote nếu metric bị đổi sau khi xem test, reconciliation lệch, alert không có owner, rollback chưa thử hoặc có order state UNKNOWN. Nếu business objective đổi, quay lại Stage 1; đừng cố sửa model để giải bài toán cũ.

6. Bắt đầu từ đâu: System Design Card 15 phút

Dùng giấy hoặc Google Sheets, chưa cần code và không dùng tiền thật. Viết chín dòng: Decision, User, Cadence, Baseline, Data, Metric, Risk Budget, Promotion Gate và Stop Condition.

Hình 3 — Card ép ý tưởng “làm bot AI” thành một quyết định, một baseline và các điều kiện có thể kiểm.

Mẫu tham khảo đã điền

Kết quả mong đợi: người khác đọc card và biết hệ thống làm gì, không làm gì, so với ai và khi nào dừng. Nếu dòng Decision vẫn là “kiếm tiền bằng AI”, hãy quay lại mục 1.

7. Tổng kết

Năm ý chính

• Bắt đầu từ decision contract và risk budget, không từ model.
• Mỗi stage phải tạo artifact cùng acceptance gate kiểm được.
• Candidate chỉ có ý nghĩa khi so với baseline dưới cùng chi phí.
• Quyền tăng dần qua paper, shadow và controlled launch.
• Monitoring, incident, rollback và decommission thuộc thiết kế ban đầu.

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

• Decision contract trả lời những gì?
• Baseline dùng để làm gì?
• Vì sao candidate trong ví dụ bị reject?
• Paper và shadow khác nhau thế nào?
• Khi nào phải quay lại Stage 1?

Gợi ý đáp án

Câu 1

Ai dùng, quyết định gì, lúc nào, output, giới hạn và non-goal. Xem lại mục 1.

Câu 2

Tạo mốc đơn giản để biết complexity có thật sự thêm giá trị. Xem lại mục 2.

Câu 3

Nó thua net return và vượt turnover/drawdown gate sau cost. Xem lại mục 3.

Câu 4

Paper mô phỏng order; shadow chạy cạnh live nhưng không có quyền action. Xem lại mục 2.

Câu 5

Khi decision, user, objective hoặc bối cảnh sử dụng đổi. Xem lại mục 5.

Thuật ngữ cần nhớ

Nguồn tham khảo

• Google — Rules of Machine Learning
• Google — ML Pipelines
• NIST AI RMF Core

Đọc tiếp: 5 lớp của hệ thống AI Trading, Risk Management và bài kế tiếp về AI Trading cho Crypto.

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

Bài này tập trung vào quy trình xây hệ thống AI Trading — quy trình từ decision contract đến controlled launch. 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à Năm lớp của một hệ thống AI Trading, Kiến trúc dữ liệu thời gian thực cho AI Trading và Risk Management trong AI Trading.

Nội dung chỉ nhằm mục đích giáo dục. Hãy dùng môi trường giả lập và review độc lập trước mọi cân nhắc triển khai thực tế.