Vì Sao Trader Lại Phá Vỡ Chính Hệ Thống Mình Đã Xây?

Vì quy tắc được viết bởi một người đang bình tĩnh, còn quyết định phá quy tắc lại được đưa ra bởi một người đang sợ, và một quy trình thủ công không có gì để tách hai người đó ra. Mỗi bước mình để lại giữa quyết định và lệnh gửi đi là một cánh cửa để nỗi sợ, lòng tham hoặc sự chán nản đi qua. Tự động hóa phần thực thi, về bản chất, là công việc đóng bớt những cánh cửa đó.

Là một quant tự học, đây là phần mình thấy khó thừa nhận nhất. Mình không mất tiền vì phân tích sai. Mình mất tiền vì đúng vào thời điểm quan trọng, mình đã làm một việc khác với điều mình đã quyết định từ trước, rồi sau đó tự giải thích lại cho bản thân nghe cho hợp lý.

Thế nào mới là một quy tắc mà máy có thể chạy được?

Đó là quy tắc mình viết ra đủ rõ để một chương trình chạy nó giống hệt nhau vào ngày mình tỉnh táo nhất và cả ngày mình tệ nhất.

Người ta hay tranh luận chart hay fundamentals, và mình nghĩ đó không phải ranh giới quan trọng. Ranh giới thật sự là quy tắc đó có sống sót khi bị viết ra thành lời hay không. "Trông như đang breakout" không phải là một quy tắc. Hai người nhìn cùng một chart sẽ đọc ra hai điều khác nhau, và khi áp lực đè lên, mình sẽ đọc theo đúng cách mà nỗi sợ của mình muốn. "Vào lệnh khi điều kiện này đúng và thoát ở điều kiện kia" mới là quy tắc, vì nó chỉ có một cách hiểu duy nhất.

Đó là tiêu chuẩn mà mỗi setup phải vượt qua trước khi đi vào quy trình nghiên cứu của mình. Trong DQuants engine mình tự phát triển, một ý tưởng chỉ trở thành ứng viên tính năng khi mình viết được nó thành điều kiện rõ ràng để code chạy giống nhau ở từng bar. Thứ mình mô tả được bằng lời nhưng không encode được thì ở lại dạng ghi chú. Ghi chú không có gì sai. Nó chỉ chưa phải là hệ thống.

Nếu mình chưa encode được nó, mình chưa có hệ thống. Mình mới chỉ có một linh cảm, và linh cảm đúng là thứ mình sẽ bỏ rơi vào đúng thời điểm tệ nhất.

Vì sao bớt một bước thủ công lại bớt được một cảm xúc?

Vì cảm xúc cần một chỗ để hành động, và một bước thủ công chính là chỗ đó.

Điểm chính của việc tự động hóa thực thi không nằm ở tốc độ. Điểm chính là code không biết sợ, không biết tham, và code không tự nhủ rằng lần này thôi, kế hoạch không áp dụng. Một Expert Advisor đã được cấu hình sẽ đọc dữ liệu, chạy theo đúng setting mà người dùng chọn, rồi gửi lệnh. Quyết định thật ra đã được đưa ra một cách bình tĩnh từ lúc mình viết quy tắc. Phần thực thi live chỉ làm đúng việc đó.

Ở chỗ này mình muốn nói thật rõ về sản phẩm. Master Volume Sniper trên chợ MQL5 là phần Expert Advisor, và nó thực thi đúng những quy tắc mà người dùng tự cấu hình, bao gồm rủi ro mỗi lệnh, giới hạn rủi ro trong ngày, phiên giao dịch và mức chặn khối lượng. Master Volume Profiler indicator, chạy trên TradingView và trên MetaTrader 5, hiển thị đúng phần đọc chart đó và để quyết định đặt lệnh lại cho người dùng. Cả hai đều không phải dịch vụ tín hiệu, và cả hai đều không thay người dùng suy nghĩ. Chúng chỉ khác nhau ở một điểm: có bao nhiêu bước thủ công nằm giữa phần đọc chart và lệnh khớp.

Mình không tự động hóa lòng tham hay nỗi sợ. Mình loại bỏ những chỗ để chúng hoạt động.

Vì sao giữ tay mình ra ngoài lại khó hơn là xây hệ thống?

Vì xây hệ thống là một dự án có điểm kết thúc, còn không phá nó là một quyết định mình phải đưa ra lại mỗi ngày.

Đây là điều mà cả những người nhiều kinh nghiệm cũng phải thừa nhận. Hệ thống tự chạy gần như cả phiên, nhưng cám dỗ mạnh nhất vẫn là ngồi nhìn con số trong ngày rồi can thiệp khi có một cú biến động lớn. Can thiệp thủ công phần lớn làm mọi thứ tệ hơn, vì cú swing khiến mình muốn chỉnh một chút thường chỉ là nhiễu bình thường mà bài test đã tính tới.

Mình có thể nói rõ mức độ bình thường đó bằng con số. Trên walk-forward theo tháng của chiến lược vàng mà mình đã đi xa nhất, mười một trong mười hai tháng cho kết quả dương, và tháng thứ mười hai thì không: tháng 8 năm 2025 kết thúc với profit factor dưới một và mức lỗ 21.6%. Đó là kết quả backtest trên dữ liệu tick thật của broker, không phải hồ sơ giao dịch live. Một tháng thua lỗ bên trong một hệ thống đã được kiểm định không phải là hỏng hóc. Đó là một sự kiện chắc chắn xảy ra nhưng chưa biết ngày, và nếu mình can thiệp mỗi lần nó tới thì mình không còn chạy hệ thống mình đã test nữa, mình đang chạy một hệ thống khác và chưa được kiểm định.

Xây được hệ thống mới là bước một. Không phá nó giữa chừng mới là phần việc cảm xúc thật sự.

Làm sao phân biệt hỏng hóc thật với sự khó chịu thông thường?

Bằng cách quyết định từ trước rằng hỏng hóc trông như thế nào, viết ra thành chữ, khi mình còn đang bình tĩnh.

Có khác biệt thật giữa một hệ thống đang có tuần xấu và một hệ thống gặp điều kiện mà nó chưa từng được xây cho. Cách duy nhất để phân biệt hai thứ đó khi đang chịu áp lực là định nghĩa chúng trước khi áp lực xuất hiện. Các điều kiện tắt của mình được viết sẵn: vượt trần drawdown, profit factor không giữ được ngoài mẫu, và đường equity live tách khỏi đường đã test. Không điều kiện nào trong đó là "mình thấy bất an với lệnh này".

Mình biết nhóm thứ hai trông ra sao vì mình đã đo được nó. Năm 2024, trên fill thật của MT5, cũng chiến lược vàng đó lỗ 67.1% với drawdown 74.2%. Đó không phải nhiễu, và không lượng kỷ luật nào cứu được, vì spread năm đó chiếm khoảng gấp đôi tỷ trọng bình thường so với phần lợi nhuận một lệnh có thể mang lại. Cách đọc thành thật là edge này có môi trường sống của nó, chứ không phải một sự bảo đảm.

Thứ sửa được vấn đề là kiến trúc, không phải ý chí. Việc thêm một quy tắc đứng ngoài vào những ngày chi phí đo được là quá đắt, cộng với việc tự động giảm khối lượng khi tài khoản đang nằm dưới đỉnh equity của chính nó, đã kéo mức lỗ đỉnh xuống đáy 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. Bài học chung vẫn đúng: khi mình thấy bản thân muốn can thiệp bằng tay, cách sửa thành thật là xây bớt nút override đi, không phải cố muốn can thiệp ít hơn.

Đối xử với một chiến lược như phần mềm production nghĩa là gì?

Nghĩa là test nó, stage nó, monitor nó trên production, và giữ sẵn đường rollback, vì một con bug ở đây tốn tiền thật.

Trong phần mềm, mình không ship cho người dùng rồi ngồi hy vọng. Mình có test suite, có môi trường staging, có monitoring, và có cách quay lui. Trading xứng đáng được đối xử nghiêm túc ít nhất là như vậy. Deploy gate, bước kiểm tra parity giữa phần logic đã test và phần được ship, cùng việc monitor live công khai, tất cả không phải nghi thức. Đó là kỷ luật kỹ thuật phần mềm bình thường được hướng vào thị trường.

Đó cũng là lý do các lần chạy kiểm định lớn như vậy. Nghiên cứu vàng chính bao phủ 1,423 lệnh mô phỏng trên dữ liệu tick thật của Exness, chạy từng tick chứ không phải bar mô hình hóa. Chỉ số độ dài track record tối thiểu cho phân phối lợi nhuận đó ra kết quả 192 lệnh, nên mẫu của mình lớn khoảng bảy lần mức cần thiết để kết quả bắt đầu có ý nghĩa. Cả hai con số đều là backtest, và mô hình chi phí của mình mới tính spread, còn slippage, độ trễ và swap thì chưa được mô hình hóa, nên mình coi điều kiện live là mỏng hơn bài test chứ không phải dày hơn.

Mình mất khá nhiều thời gian để xây DQuants framework nhằm chạy nhanh vòng lặp này, từ khâu kiểm định giả thuyết cho tới lúc deploy. Tốc độ không quan trọng bằng việc mỗi bước đều để lại một bản ghi mà sau này mình không thể lặng lẽ sửa lại.

Vì sao lại công khai tài khoản thay vì công khai một lời tuyên bố?

Vì một đường equity được nhìn thấy là chỗ cuối cùng mà một xung động còn có thể trốn.

Toàn bộ dự án này bắt đầu vì trading thủ công cứ để cảm xúc thắng logic quá nhiều lần. Việc công khai là lớp ngăn chặn cuối cùng cho con bug đó. Khi các quy tắc được nhìn thấy và đường equity chạy live, một lần override lặng lẽ gần như không còn chỗ nào để tồn tại mà không bị ghi lại.

Một track record live gần như không nói lên điều gì sau một tuần, và bắt đầu có ý nghĩa sau một năm, nên mình không xây cho bài đăng kế tiếp. Mình xây một đường equity mà tới năm 2028 mình vẫn sẵn sàng đưa ra cho người khác xem, và mình thà chậm rãi có được niềm tin của một người hoài nghi còn hơn gây ấn tượng thật nhanh với một người vốn đã tin sẵn. Nếu bạn từng bị các chiêu hype trong trading làm cho tổn thương, sự hoài nghi đó chính là công cụ phù hợp nhất để mang tới đây.

Và nếu tài khoản live thất bại, mình sẽ nói đúng như vậy, ghi lại lý do, rồi mang bài toán quay về engine. Một quy trình không thể thất bại một cách thành thật thì cũng không thể thành công một cách thành thật. Mình lạc quan về quy trình và khiêm tốn về kết quả, và mình đã sẵn sàng với cả hai.

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

Vì sao trader lại phá vỡ chính quy tắc của mình? Vì quy tắc và hành động phá quy tắc được tạo ra bởi hai trạng thái tâm lý khác nhau, và một quy trình thủ công không làm gì để tách chúng ra. Quy tắc được viết khi chưa có gì đặt cược, còn việc phá quy tắc xảy ra khi một lệnh đang mở và một con số đang chạy. Cách sửa nằm ở cấu trúc chứ không nằm ở động lực: mình bỏ bớt những bước thủ công nơi việc phá quy tắc có thể xảy ra về mặt vật lý.

Tự động hóa thực thi có nghĩa là mình không cần suy nghĩ nữa? Không, nó chỉ đẩy phần suy nghĩ lên sớm hơn. Toàn bộ phán đoán được dồn vào việc định nghĩa điều kiện, chọn thiết lập rủi ro, và quyết định điều gì sẽ khiến mình tắt hệ thống. Phần còn lại trong phiên là theo dõi xem có hỏng hóc thật hay không, và đó là công việc hẹp hơn nhiều so với việc nghi ngờ từng lệnh. Người muốn ngừng suy nghĩ thì không nên tự động hóa bất cứ thứ gì.

Làm sao biết một chuỗi thua là bình thường chứ không phải hệ thống đã hỏng? Bằng cách viết điều kiện tắt trước khi chuỗi thua bắt đầu. Với mình, đó là trần drawdown, profit factor không giữ được ngoài mẫu, và sự tách rời giữa đường equity live với đường đã test. Để hình dung về quy mô, một tháng trong walk-forward vàng kết thúc dưới profit factor một với mức lỗ 21.6%, và bài test đã tính tới điều đó từ trước.

Điều gì làm cho một quy tắc trở nên code được? Nó chỉ có một cách hiểu. Nếu hai người có chuyên môn nhìn cùng một chart mà bất đồng về việc quy tắc đã kích hoạt hay chưa, thì đó là một mô tả chứ không phải một quy tắc. Bài kiểm tra thực tế mình dùng là mình có viết được nó thành điều kiện để code đánh giá giống hệt nhau ở từng bar hay không, và nếu không viết được, nó ở lại dạng ghi chú nghiên cứu thay vì trở thành tính năng.

Chiến lược bạn mô tả đã từng thất bại nặng chưa? Rồi, và trường hợp tệ nhất đã được ghi lại. Năm 2024, trên fill thật của MT5, nó lỗ 67.1% với drawdown 74.2%, trong một năm mà spread chiếm khoảng gấp đôi tỷ trọng bình thường so với phần một lệnh có thể kiếm được. Năm đó chính là lý do phần kiến trúc rủi ro tồn tại, và việc thêm cơ chế đứng ngoài vào ngày chi phí quá đắt cùng với giảm khối lượng theo drawdown đã kéo mức lỗ đỉnh xuống đáy tệ nhất trên cửa sổ đó từ 56.7% xuống 22.2%.

Có phải cứ nhiều ý chí hơn là giải quyết được việc overtrading và phá quy tắc? Với mình thì chưa bao giờ hiệu quả được lâu. Ý chí là một nguồn lực cạn đi đúng vào lúc biến động lên cao nhất, và đó là mối tương quan tệ nhất có thể. Mọi guardrail mình dựa vào bây giờ đều được code, gồm giới hạn phiên, giới hạn rủi ro trong ngày và mức chặn khối lượng, chính vì phiên bản của mình phải tự thực thi chúng bằng tay lại là phiên bản ít có khả năng làm được nhất.

Đây có phải kết quả giao dịch live không? Không. Mọi con số ở đây đến từ backtest và các lần chạy kiểm định trên dữ liệu tick thật của broker, không phải từ hồ sơ giao dịch live. Mình có chạy một bài test live và theo dõi nó, mình sẽ công bố những gì nó cho thấy, nhưng trích dẫn kết quả nghiên cứu như hiệu suất thật thì không thành thật và mình sẽ không làm vậy.

Sản phẩm nào của KenKem làm việc gì? Master Volume Profiler là indicator, có 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 những quy tắc cùng thiết lập rủi ro 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ề tự động hóa và trách nhiệm công khai 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.