Khi Nào Một Chiến Lược Giao Dịch Mới Đủ Điều Kiện Chạy Thật?

Khi nó đã vượt qua một bộ kiểm tra mà mình viết ra trước khi chạy. Trong công việc của mình, điều đó có nghĩa là một ngưỡng được cố định từ trước, kết quả trên dữ liệu hệ thống chưa từng học, chi phí được tính cho mọi lệnh mô phỏng, sự khớp nhau giữa phần logic đã test và phần được deploy, cùng một danh sách viết sẵn những điều sẽ khiến mình tắt nó đi.

Không phần nào trong đó là một kết quả. Đó chỉ là quyền được thử tiếp. Là một quant tự học, thói quen hữu ích nhất mà mình xây được chính là phân biệt hai thứ đó, vì gần như mọi sai lầm đắt giá của mình đều bắt đầu từ việc xem một backtest như phiếu lương thay vì như tấm giấy phép.

Deploy gate là gì?

Đó là một bộ kiểm tra cố định đứng giữa một ý tưởng đẹp và tiền thật, và một ứng viên chưa được chạy live cho tới khi nó vượt qua toàn bộ.

Bộ kiểm tra của mình cố tình nhàm chán. Validation dữ liệu. Mô hình chi phí. Một ngưỡng được đăng ký trước. Walk-forward trên các lát cắt chưa từng thấy. Parity giữa phần logic đã test và phần được ship. Một danh sách điều kiện tắt viết sẵn. Không hạng mục nào trong đó hào nhoáng, và đó chính là điểm mấu chốt: phần hào nhoáng của trading rất dễ làm giả, còn phần nhàm chán thì gần như không thể giả được lâu.

Cái cổng này không phải thủ tục hành chính. Nó là thứ duy nhất đứng giữa sự hào hứng của mình và vốn của mình. Hiện tại vài ứng viên của mình vẫn chưa vượt qua, nên chúng chưa được deploy. Với mình, chưa deploy là một tính năng bảo vệ, không phải một sự chậm trễ.

Vì sao mình đặt ngưỡng trước khi chạy test?

Vì một ngưỡng đặt sau khi đã nhìn kết quả thì không còn là ngưỡng, nó chỉ là lời mô tả cho đúng chỗ quả bóng vừa rơi.

Mình xác định con số cần vượt trước khi chạy, cùng với kết quả nào sẽ khiến mình từ bỏ ý tưởng. Kỷ luật nhỏ đó chiếm phần lớn khác biệt giữa nghiên cứu và tự lừa mình. Nếu mình không nói trước được điều gì sẽ làm mình đổi ý, thì bài test đó chưa thật sự là một bài test.

Logic tương tự áp dụng cho chính quá trình tìm kiếm. Mỗi cấu hình mình thử đều làm tăng khả năng có một cấu hình trông đẹp thuần túy nhờ may mắn, nên số lần thử phải được ghi lại và phải trả giá cho nó. Trong phần nghiên cứu MasterVP trên vàng, bối cảnh tìm kiếm là 36 cấu hình, và các thống kê chống overfitting được nạp đúng con số đó chứ không phải một tập con dễ chịu hơn. Việc khấu trừ kết quả theo đúng độ rộng tìm kiếm thật rất khó chịu, và đó cũng là cách đọc trung thực duy nhất.

Walk-forward thật sự chứng minh được điều gì?

Nó chứng minh hệ thống làm được điều gì đó trên dữ liệu chưa từng thấy, và đó là thứ gần nhất với sự thành thật về tương lai mà mình có.

Walk-forward xây trên một lát cắt lịch sử, test trên lát cắt kế tiếp mà hệ thống chưa từng được fit vào, rồi cuộn tới và lặp lại. Nó loại bỏ thói quen dễ chịu là fit toàn bộ quá khứ một lần, và nó khắc nghiệt theo hướng có ích. Trong DQuants engine mình tự phát triển, walk-forward là cách chấm điểm mặc định cho mọi ứng viên, và bản tổng kết chỉ báo cáo những lát cắt mà hệ thống chưa từng train trên đó.

Đây là kết quả trên chiến lược vàng mà mình đã đẩy đi xa nhất, và toàn bộ đều là backtest trên tick thật của sàn chứ không phải hồ sơ giao dịch live. Với walk-forward theo tháng, 11 trên 12 tháng cho kết quả dương. Tháng còn lại thì không: tháng 8 năm 2025 kết thúc với profit factor dưới 1 và mức lỗ 21.6%. Với cách chia fold đều nhau, 7 trên 8 fold dương và fold tệ nhất cũng kết thúc dưới 1. Hai lát cắt thua đó lại là phần mình tin nhất trong kết quả, vì một mô hình curve fit thường không để lại chúng.

Còn một so sánh nữa từ cùng bộ chạy đó, và nó làm mình bất ngờ. Cấu hình đóng băng trụ được qua nhiều fold hơn so với cách tối ưu lại trên từng fold. Việc tối ưu lại mỗi fold nghe có vẻ linh hoạt hơn, nhưng phần lớn thứ mình mua được chỉ là một bản fit khít hơn vào nhiễu.

Chuyện gì xảy ra khi chính thước đo bị sai?

Mọi bảng xếp hạng mà nó từng tạo ra đều trở nên đáng nghi, kể cả những bảng mình thích.

Mình từng hạ cấp một variant vì engine nói phiên bản khác tốt hơn. Chính engine đó có lỗi hạch toán lệnh thoát, và lỗi này thiên vị về mặt cấu trúc cho phiên bản có trailing runner lớn hơn, nên cuộc so sánh đã bị lệch bởi công cụ của chính mình mà mình không hề biết. Kết luận cũ không sống sót sau khi mình sửa lỗi. Mình đang chạy lại cuộc so sánh đó trên engine đã sửa, và phán quyết trước đây không còn được tính.

Đó là lý do parity nằm bên trong cái cổng chứ không nằm cạnh nó. Trước khi bất kỳ thứ gì chạy live, phần expert đã deploy và phần logic đã test phải tạo ra cùng những lệnh trên cùng bộ dữ liệu. Trên bản build vàng hiện tại, phép kiểm tra đó tái tạo lại đúng bài chạy tham chiếu, khớp từng lệnh một. Nếu hai bên không khớp, thì thứ mình validate không phải thứ đang thật sự chạy, và phần validation của mình không bảo vệ được gì cả.

Vì sao mình chọn kết quả bền thay vì kết quả rực rỡ?

Vì phiên bản rực rỡ thường chỉ fit rất khít vào một khoảnh khắc sẽ không quay lại.

Mình thà có một chiến lược chỉ ở mức khá ổn qua nhiều điều kiện thị trường, còn hơn một chiến lược xuất sắc trong đúng một điều kiện. Vì vậy mỗi ứng viên được chấm điểm qua nhiều volatility regime khác nhau, không chỉ qua cửa sổ nơi nó được sinh ra, và đường equity còn bị stress test bằng cách resample và đảo thứ tự các lệnh. Với chiến lược vàng, 20.000 vòng lặp Monte Carlo cho ra mức drawdown tệ nhất khi đảo thứ tự là 54.8%. Con số đó không phải một dự báo. Nó nhắc mình rằng cùng một edge có thể tạo cảm giác thế nào khi thứ tự lệnh không thuận lợi.

Bền vững cũng có nghĩa là nói ra chỗ nó đã gãy. Năm 2024, trên fill thật của MT5, chiến lược đó lỗ 67.1% với mức drawdown 74.2%. Năm đó spread chiếm khoảng gấp đôi tỷ trọng bình thường so với biến động, và không có mức sizing nào mình dám ship mà sống sót qua một năm kiểu 2024. Điều này được ghi rõ trong ghi chú nghiên cứu của mình như đính chính quan trọng nhất của cả quá trình, và cũng là lý do mình mô tả edge này là có môi trường sống của nó, chứ không phải một lời bảo đảm.

Thứ đã thay đổi là kiến trúc rủi ro. Việc thêm một quy tắc đứng ngoài trong những ngày có chi phí đo được là quá cao, cùng với việc giảm khối lượng vị thế khi tài khoản đang nằm dưới đỉnh equity, đã kéo mức drawdown tệ nhất trên cửa sổ khắc nghiệt đó từ 56.7% xuống 22.2%. Mình sẽ mô tả các cơ chế đó làm gì. Mình sẽ không công bố các ngưỡng kích hoạt chúng, vì ngưỡng chính là phần người khác có thể cấu hình sai.

Điều gì sẽ khiến mình tắt nó đi?

Với mỗi ứng viên, mình giữ một danh sách viết sẵn: vượt trần drawdown, profit factor không giữ được trên dữ liệu out-of-sample, hoặc đường equity live lệch khỏi đường đã test.

Nếu mình không nói được điều gì sẽ chứng minh chiến lược của mình là sai, thì mình chưa có một chiến lược. Mình mới chỉ có một niềm tin. Ứng viên mình thích nhất, cái có câu chuyện hình thành sạch nhất và logic hợp lý nhất, vẫn đang trong giai đoạn thử thách đúng vì lý do đó. Việc mình thích một chiến lược không phải bằng chứng về chiến lược đó, và tình cảm mình dành cho một ý tưởng chính là loại bias mà cái cổng này sinh ra để trung hòa.

Cũng không có luật nào bắt mình phải launch ngay trong quý này. Thị trường vẫn sẽ ở đó. Chi phí của việc chờ đợi rất nhỏ, còn chi phí của việc deploy một thứ chưa được chứng minh là uy tín của mình và vốn của người khác, nên chính phần validation chậm rãi và không hào nhoáng mới làm cho một lần go-live sau này có ý nghĩa.

Câu hỏi thường gặp

Deploy gate trong systematic trading là gì? Đó là một chuỗi kiểm tra cố định mà một chiến lược phải vượt qua trước khi giao dịch bằng tiền thật, được định nghĩa từ trước để mình không thể nới lỏng nó sau khi đã gắn bó với một kết quả. Bộ của mình gồm validation dữ liệu, mô hình chi phí, ngưỡng đăng ký trước, walk-forward trên dữ liệu chưa từng thấy, parity giữa logic đã test và logic được deploy, cùng một danh sách điều kiện tắt. Một ứng viên trượt bất kỳ bước nào sẽ không được deploy, bất kể nó làm tốt đến đâu ở các bước còn lại.

Vượt qua backtest có nghĩa là chiến lược đó có lãi không? Không. Backtest là câu chuyện về quá khứ, và thị trường không nợ tương lai bất kỳ sự giống nhau nào. Một backtest sạch chỉ giúp chiến lược giành được quyền được kiểm tra tiếp, và điều đó khác hẳn với bằng chứng rằng nó sẽ kiếm được tiền. Mình xem backtest là tấm giấy phép, không phải phiếu lương.

Một backtest cần bao nhiêu lệnh thì mới đáng tin? Con số đó phụ thuộc vào phân phối lợi nhuận chứ không phải một số tròn, và có hẳn một thống kê cho việc này. Minimum track record length của chiến lược vàng của mình rơi vào 192 lệnh, còn bài validation phủ 1.423 lệnh mô phỏng trên tick thật, tức khoảng bảy lần mức tối thiểu. Đây là số liệu backtest, không phải hồ sơ giao dịch live.

Walk-forward là gì và vì sao nó quan trọng? Mình fit trên một lát cắt lịch sử, test trên lát cắt kế tiếp mà hệ thống chưa từng thấy, rồi cuộn cửa sổ tới và lặp lại. Nó quan trọng vì một mô hình curve fit luôn thắng trong mẫu và sụp đổ ngoài mẫu, nên nếu chỉ test trên dữ liệu đã dùng để tinh chỉnh thì mình không thể phân biệt hai trường hợp đó. Những fold nó thua cũng nhiều thông tin đúng bằng những fold nó thắng.

Có nên tối ưu lại tham số trên mỗi fold walk-forward không? Cách đó nghe linh hoạt hơn thực tế. Trong các bài chạy trên vàng của mình, cấu hình đóng băng trụ được qua nhiều fold hơn so với việc tối ưu lại từng fold, điều này gợi ý rằng phần fit thêm chủ yếu bám theo nhiễu. Đó là một chiến lược trên một sản phẩm, nên bạn hãy xem nó là lý do để tự kiểm chứng câu hỏi này, không phải một quy tắc chung.

Vì sao parity giữa engine và EA lại quan trọng trước khi deploy? Vì nếu chương trình đã deploy và phần logic đã test không khớp nhau, thì thứ bạn validate không phải thứ đang chạy. Phép kiểm tra rất đơn giản: nạp cùng một bộ dữ liệu cho cả hai và yêu cầu chúng tạo ra cùng những lệnh. Trên bản build vàng hiện tại, phép kiểm tra này tái tạo đúng bài chạy tham chiếu. Mình từng trả giá vì đúng khoảng cách đó, nên bây giờ nó là một cổng bắt buộc chứ không phải một lựa chọn.

Bạn có công bố cả phần thua chứ không chỉ phần thắng không? Có, và phần thua mới là phần hữu ích hơn. Chiến lược vàng lỗ 67.1% trong năm 2024 trên fill thật với drawdown 74.2%, một tháng walk-forward kết thúc dưới profit factor 1 với mức lỗ 21.6%, và một danh sách dài các ý tưởng đã bị loại thẳng, gồm cắt lỗ theo ngày, dừng cứng theo drawdown, hạ mục tiêu lợi nhuận, và một bộ lọc vào lệnh theo efficiency ratio không cho thấy cải thiện ngoài mẫu. Chính các lần loại bỏ đó mới làm cho những gì sống sót có giá trị.

Những con số này có phải hồ sơ giao dịch live không? Không. Mọi con số ở đây đến từ backtest và các bài validation trên tick thật của sàn, và mô hình chi phí của mình mới tính spread cho từng lệnh, còn slippage, độ trễ và swap thì chưa được mô hình hóa. Vì vậy mình luôn coi điều kiện live là mỏng hơn bài test chứ không phải dày hơn, và mình sẽ không mô tả kết quả nghiên cứu như thành tích giao dịch.

Sản phẩm nào của KenKem làm việc gì? Master Volume Profiler là indicator, chạy trên TradingView và trên MetaTrader 5. Nó hiển thị phần đọc chart và để quyết định đặt lệnh lại cho bạn, và nó không phải dịch vụ tín hiệu. Master Volume Sniper trên chợ MQL5 là phần Expert Advisor, và nó chỉ thực thi đúng những quy tắc mà người dùng tự cấu hình.

---

Được viết bởi KenKem, một kỹ sư phần mềm và nhà sáng lập với hai mươi năm kinh nghiệm, đang học giao dịch định lượng một cách công khai và chia sẻ lại toàn bộ quá trình, bao gồm cả những lần bị loại.

Bài viết này được tổng hợp từ nhóm bài về deploy gate trong chuỗi build-log của KenKem. Chỉ nhằm mục đích giáo dục. Không phải lời khuyên đầu tư. Các con số được trích dẫn là kết quả backtest và validation trên dữ liệu tick thật, không phải hồ sơ giao dịch live. Hiệu suất trong quá khứ không đảm bảo kết quả trong tương lai.