KenKem Journal

Nền Tảng Kỹ Sư Có Giúp Ích Gì Trong Systematic Trading Không?

· #systematic-trading #research-method #reproducibility #trading-psychology #backtesting

Nền tảng kỹ sư có giúp ích trong systematic trading, nhưng không phải theo cách nhiều người vẫn nghĩ. Nó không làm cho edge dễ tìm hơn. Nó làm cho mình nghi ngờ kết quả của chính mình nhanh hơn. Tính tái lập, cách hạch toán chi phí và thói quen test cho thất bại đều chuyển giao trực tiếp. Riêng sự tự tin vào logic của chính mình thì không chuyển giao chút nào.

Dưới đây là những thói quen đã theo mình sang được, chỗ mà chúng ngừng phát huy tác dụng, và con bug hạ tầng đã chứng minh sự khác biệt đó.

Vì sao kỹ sư thường tiếp cận systematic trading nhanh hơn?

Bởi vì họ đã biết rằng hệ thống sẽ hỏng khi giả định bị giấu đi.

Trading cũng là một hệ thống. Nó có input, output, edge case, failure mode và những bất ngờ đắt đỏ. Nếu bạn đã quen tư duy theo kiểu debug, invariant và những lần chạy tái lập được, bạn đang ở gần công việc này hơn bạn tưởng. Cùng một kỷ luật làm cho phần mềm đáng tin cậy cũng là kỷ luật giữ cho nghiên cứu trung thực, và về bản chất đó là kỷ luật của sự hoài nghi.

Mình xây Dquants engine mình tự phát triển đúng theo cách đó: như một phần mềm, với các lần chạy được đánh phiên bản và những cổng kiểm định mà một ý tưởng phải vượt qua trước khi chạm tới bất cứ thứ gì vào lệnh.

Nền tảng khoa học dữ liệu bổ sung thêm điều gì?

Một sự hoài nghi đã được hiệu chỉnh sẵn với nhiễu.

Người làm khoa học dữ liệu biết một điều mà nhiều trader vẫn kháng cự: một mẫu hình có thể là thật, và cũng hoàn toàn có thể chỉ là nhiễu. Một tín hiệu không qua kiểm định chỉ là một câu chuyện. Một mô hình không có kỷ luật out-of-sample chỉ là một cái bẫy tự tin. Lợi thế ở đây không nằm ở khả năng dự đoán. Nó nằm ở đo lường và thí nghiệm có kiểm soát, cụ thể hơn là ở sự sẵn lòng thiết kế một bài test có thể làm mình bẽ mặt.

Trader theo cảm nhận có bị bỏ lại phía sau không?

Không, và mình nghĩ câu chuyện này hay bị đóng khung sai.

Trader theo cảm nhận thường có trực giác thị trường thật sự, và trực giác không phải là vấn đề. Trực giác chỉ trở nên nguy hiểm khi nó không được viết ra, bởi vì rule không được viết ra thì không thể kiểm định và do đó không thể cải thiện. Chuyển sang systematic không phải là xóa bỏ trực giác. Đó là việc formalize phần hữu ích của nó để mình có thể tấn công nó bằng dữ liệu.

Master Volume Profile chính là như vậy: cách đọc theo kinh nghiệm quanh các mức volume profile, được viết lại thành rule tường minh mà mình có thể debug.

Sự chuyển đổi thật sự khi đi theo hướng systematic là gì?

Nó không phải là từ manual sang automated. Nó là từ cảm tính sang đo lường được.

Câu hỏi đổi từ "mình có cảm thấy đúng không" sang "quy trình có giữ được không", và chỉ một phép thay thế đó thôi đã tiết kiệm nhiều năm. Trong engine của mình, một thay đổi chỉ được tính khi mình đo được nó bằng expectancy, drawdown và độ nhạy chi phí. Một cảm giác tốt về một thay đổi không phải là kết quả. Đó là một giả thuyết mà mình chưa kiểm định.

FOMO là vấn đề tâm lý hay vấn đề quy trình?

Cả hai, và phần quy trình mới là phần mình thật sự sửa được.

Khi rule mơ hồ, sự cấp bách dâng lên. Khi kiểm định yếu, mọi setup đều trông cấp bách. Khi việc ghi log sơ sài, mình không bao giờ học được điều gì đã thật sự xảy ra. Tâm lý có vai trò của nó, nhưng rất nhiều thứ bị gọi là lỗi kỷ luật thực ra là lỗi đặc tả. Vì vậy các ràng buộc của mình nằm trong code: bộ lọc theo phiên và giới hạn khối lượng cố định lấy quyết định ra khỏi khoảnh khắc đó, đúng lúc mình kém tin cậy nhất.

Vì sao tính tái lập quan trọng hơn vẻ ngoài của nó?

Bởi vì một kết quả mình không tái hiện được thì không phải là sai, nó chỉ là chưa sẵn sàng, và "chưa sẵn sàng" đã là một câu trả lời hữu ích.

Các lần chạy kiểm định của mình đi trên từng tick được ghi lại của feed broker, vào khoảng 160 triệu tick cho cửa sổ test, chứ không đi trên bar mô phỏng hay nội suy. Cùng một chuỗi tick luôn cho ra cùng những lệnh đó và cùng một equity curve, nên không còn chỗ nào cho sự ngẫu nhiên để mình lựa chọn kết quả đẹp. Trước khi mình tin một con số, research engine và expert trên MetaTrader 5 phải xử lý đúng cùng một chuỗi tick và phải đồng ý với nhau.

Cổng đó không phải thủ tục hình thức. Nó đã bắt được một lỗi thật, và đó là phần tiếp theo.

Lợi thế kỹ sư dừng lại ở đâu?

Ở đúng điểm mình bắt đầu tin code của mình chỉ vì chính mình viết ra nó.

Ví dụ rõ nhất trong ghi chú của mình là một veto node-absorption mà mình đã test, ý tưởng bỏ qua những breakout bị hấp thụ tại một node volume. Research engine nói nó gần như trung tính, nên nó vốn đã trên đường bị loại. Trên MetaTrader 5, đúng cấu hình đó trả về âm 95 phần trăm net. Khoảng cách không nằm ở chiến lược. Nó nằm ở hạ tầng: MetaTrader gắn cờ khoảng 74 phần trăm breakout là bị hấp thụ, trong khi engine C++ của mình gắn cờ khoảng 15 phần trăm. Hai lần hiện thực của cùng một rule đã bất đồng với nhau, và chỉ có parity check mới làm điều đó lộ ra.

Đó là đối trọng trung thực cho cái gọi là lợi thế xuất phát. Trực giác kỹ sư nói với mình rằng hai bản hiện thực khớp nhau. Chỉ có bài test mới biết là chúng không khớp.

Giai đoạn đó còn khiêm tốn hóa mình theo một cách khác. Năm lever nghiên cứu liên tiếp mà mình xây đều bị loại, trong đó có một veto theo hướng dòng lệnh mà tiền đề của nó hóa ra đơn giản là sai. Một cuộc mổ xẻ không dùng mô hình trên 2.117 lệnh vào cho thấy những lệnh đi ngược dòng mà mình cho là bẫy thật ra lại là các nhịp pullback thuận lợi. Mình đã kỹ thuật hóa một giải pháp cho một vấn đề không tồn tại.

Sự tự tin trầm lặng trông như thế nào khi quy ra số?

Là biết chính xác bằng chứng của mình dừng ở đâu.

Với cấu hình vàng, mẫu đã kiểm định là 1.423 lệnh so với độ dài track record tối thiểu là 192, tức khoảng bảy lần mức sàn, và Deflated Sharpe Ratio, bài test được thiết kế riêng để bắt sự may mắn và overfitting, đạt 1.000 so với ngưỡng 0.95. Đó là những con số đẹp. Những con số không đẹp mới quan trọng hơn: cùng một cấu hình cố định đó đọc ra Sharpe khoảng 3.8 bên trong regime của riêng nó và khoảng 1.8 trên trọn chu kỳ, còn phân phối drawdown Monte Carlo nằm quanh 24 phần trăm ở trung vị và 38 phần trăm ở phân vị 95, đó là lý do ghi chú của mình nói phải tính sizing cho một đỉnh drawdown 30 đến 40 phần trăm.

Tất cả những con số đó đều là kết quả backtest và chạy xác nhận từ scorecard vàng của riêng mình. Không con số nào là track record live.

Vì sao một mô hình rõ ràng tốt hơn một mô hình thông minh?

Bởi vì mô hình rõ ràng thì kiểm toán được, còn mô hình thông minh thì chỉ có thể tin.

Bạn cần nói được mô hình đo cái gì, bỏ qua cái gì và cần điều kiện nào. Mô hình của mình gắn nhãn từng lệnh theo mode, nên phần quy kết là đọc được chứ không phải phỏng đoán: nhánh breakout mang 1.282 lệnh với profit factor 1.408, còn nhánh mean-reversion mang 51 lệnh với 1.168. Con số thứ hai rất mỏng, thấp hơn nhiều so với mức sàn 192 lệnh, nên mình coi nó là một lớp phủ nhỏ chứ không phải một nửa của engine. Một mô hình mơ hồ hơn hẳn đã cho phép mình mô tả nó như một nửa engine mà không bao giờ nhận ra là mình đang đoán.

Một mô hình rõ ràng nhưng chưa hoàn hảo vẫn hơn một mô hình mơ hồ nhưng nghe thông minh, chủ yếu vì khi kết quả xấu đi, mình gọi được tên rule nào đã hỏng.

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

Có cần biết lập trình mới trade systematic được không? Không, nhưng bạn cần những thói quen mà lập trình dạy cho mình, gồm việc quản lý phiên bản cho bộ rule, những bài test có thể đánh trượt ý tưởng, và cách hạch toán chi phí trung thực. Nhiều người xây được các thói quen đó mà không viết dòng code nào. Nút thắt hiếm khi là cú pháp, nó là sự sẵn lòng thiết kế những bài test có thể chứng minh mình sai.

Kỹ năng phần mềm nào chuyển giao tốt nhất sang nghiên cứu trading? Tính tái lập, kỹ năng debug và tư duy theo failure mode. Tính tất định là điều lớn nhất: nếu cùng một input không cho ra cùng một output, thì không kết luận nào phía sau là an toàn. Cách hạch toán chi phí cũng quan trọng, vì spread, commission và slippage mới quyết định một edge có tồn tại hay không.

Parity check trong backtest là gì? Đó là việc xác nhận hai bản hiện thực độc lập của cùng một chiến lược, trong trường hợp của mình là một research engine C++ và một expert trên MetaTrader 5, cho ra kết quả khớp nhau trên đúng cùng một chuỗi tick. Nó quan trọng vì một rule có thể được code theo hai cách trông tương đương nhưng thực chất không tương đương. Parity check của mình đã bắt đúng tình huống đó, khi một bản gắn cờ khoảng 74 phần trăm breakout còn bản kia gắn cờ khoảng 15 phần trăm.

Vì sao nên backtest trên tick thay vì trên nến? Bởi vì một engine chạy theo nến buộc phải đoán điều gì đã xảy ra bên trong cây nến đó, và phỏng đoán ấy thường làm kết quả đẹp lên. Test ở mức tick loại bỏ phỏng đoán đó. Cửa sổ kiểm định của mình chạy trên khoảng 160 triệu tick thật của broker chứ không phải trên bar mô phỏng.

Nền tảng khoa học dữ liệu có tạo ra lợi thế trong trading không? Nó tạo lợi thế ở khâu đánh giá chứ không phải ở khâu dự đoán. Biết overfitting trông như thế nào, hiểu vì sao test out-of-sample là điều không thể bỏ qua, và nắm được cách mẫu nhỏ đánh lừa mình, tất cả đều đáng giá hơn bất kỳ mô hình cụ thể nào. Điều cần cảnh giác là thói quen coi thị trường như một tập dữ liệu ngoan ngoãn, bởi vì phân phối dịch chuyển và nhãn thì nhiễu.

Trader theo cảm nhận có chuyển sang systematic được không? Được, và trực giác của họ thường là một tài sản thật một khi nó được viết ra thành rule tường minh. Phần khó không nằm ở code. Nó nằm ở việc chấp nhận rằng một phần những gì từng có vẻ là kỹ năng sẽ không sống sót qua khâu đo lường.

Master Volume Profile đã có track record live chưa? Chưa, và mình sẽ không ám chỉ điều ngược lại. Mọi thứ công bố tới lúc này đều là nghiên cứu: backtest trên tick thật của broker cùng với các lần chạy xác nhận trên MetaTrader 5. Spread được tính cho mọi lệnh trong mô hình, nhưng slippage, độ trễ và swap thì chưa được mô hình hóa, nên bạn nên kỳ vọng kết quả live mỏng hơn backtest.

Những điều này có loại bỏ rủi ro không? Không. Chúng loại bỏ một vài cách sai cụ thể, và đó là một tuyên bố nhỏ hơn nhiều. Mọi con số ở trên đều là dữ liệu lịch sử, trading có rủi ro bao gồm rủi ro thua lỗ, và không lượng kiểm định nào biến một giả thuyết thành điều chắc chắn.


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 quantitative trading một cách công khai và chia sẻ lại toàn bộ quy 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ừ các post 61 đến 72 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ư. Mọi con số được trích dẫn đều là kết quả backtest hoặc chạy xác nhận, không phải track record live. Hiệu suất trong quá khứ không đảm bảo kết quả trong tương lai.

← All journal articles

Chat