Vì Sao Phần Lớn Ý Tưởng Trading Của Mình Đều Bị Loại

Mình không bắt đầu xây dựng research stack vì muốn có thêm một ý tưởng trading mới. Mình bắt đầu vì đã quá mệt với những quyết định thiếu nhất quán.

Khoảng 20 năm làm kỹ sư phần mềm, khoảng 8 năm giao dịch thật bằng tiền thật, và sự kết hợp đó làm rõ một điều: nếu quy trình yếu thì kết quả cũng sẽ yếu. Vì vậy thứ mình thật sự bắt tay vào xây không phải một chiến lược, mà là một quy trình có thể nói cho mình biết một cách trung thực và lặp lại được rằng mình đang sai ở đâu. Phần lớn thứ quy trình đó tạo ra là sự loại bỏ. Và đó chính là mục đích.

Vì sao mình bắt đầu từ việc loại bỏ thay vì từ việc khám phá?

Vấn đề thật sự chưa bao giờ là tìm điểm vào lệnh. Điểm vào lệnh rất dễ tìm và cũng rất dễ khiến mình say mê. Vấn đề lớn hơn là mình có giữ được quy trình dưới áp lực hay không, đúng lúc cảm xúc lên tiếng to nhất và cám dỗ phá vỡ kế hoạch mạnh nhất.

Điều đó cho mình quan sát đầu tiên mà mình dám gọi là quan sát quant thật sự: nếu hành vi của mình thay đổi lúc căng thẳng, edge có thể yếu hơn mình tưởng. Một edge chỉ sống sót khi mình bình tĩnh thì không phải edge, nó chỉ là tâm trạng.

Sự hưng phấn không phải chiến lược. Vì vậy mình chuyển gánh nặng từ ý chí sang cấu trúc. Không phải mình muốn loại bỏ phán đoán con người, mà là không để phán đoán sai điều khiển cuộc chơi. Sự tùy nghi mà thiếu cấu trúc sẽ thành nhiễu. Cấu trúc mà thiếu kỷ luật cũng thất bại. Mình cần cả hai, và cấu trúc phải đến trước.

Điều gì khiến mình nghi ngờ chính dữ liệu của mình trước tiên?

Trước khi kiểm định được bất cứ thứ gì, mình phải trả lời một nhóm câu hỏi nghe có vẻ quá cơ bản nhưng lại quan trọng vô cùng.

Dữ liệu này thật sự đại diện cho cái gì? Quote tick là gì? Volume sàn thật là gì? Đâu chỉ là một proxy đang đứng thay cho thứ mà mình không nhìn thấy được?

Trong dữ liệu trading, chọn sai trường dữ liệu có thể tạo ra một edge giả nhưng trông cực kỳ thuyết phục. Chọn đúng trường và diễn giải đúng có thể tiết kiệm cho mình hàng tháng công sức. Đó là lý do Dquants engine mình tự phát triển làm việc trên tick data thật và tách riêng quote tick với volume sàn thật. Một proxy sẽ không bao giờ âm thầm được nâng lên thành dữ liệu thật.

Nếu dữ liệu yếu thì kết luận cũng yếu, dù lớp phân tích bên trên có tinh vi đến đâu. Sự thật trước, mọi thứ khác sau.

Một ý tưởng phải sống sót qua những gì mới được xem là bằng chứng?

Mình không muốn đưa quan điểm cá nhân vào hệ thống rồi để chúng đóng vai sự thật. Vì vậy một ý tưởng phải sống sót qua sự thay đổi trước khi mình xem nó là nghiêm túc:

• các phiên giao dịch khác nhau
• các năm khác nhau
• các giả định chi phí khác nhau
• các regime thị trường khác nhau

Đó là bộ lọc robustness đầu tiên, và nó khắc nghiệt một cách có chủ đích. Trong Dquants, mỗi ý tưởng đều phải chạy out-of-sample và walk-forward qua nhiều năm và nhiều phiên trước khi nó xứng đáng nhận được sự chú ý của mình. Nếu nó không vượt qua được, mình xem nó là yếu. Đó không phải bi quan, đó chỉ là tiêu chuẩn.

Bản thân vòng lặp không hề hào nhoáng. Test, đo, loại, chỉnh, rồi test lại. Phần lớn thời gian câu trả lời là không. Đó không phải vòng lặp thất bại, đó là vòng lặp đang làm đúng việc của nó. Mục tiêu của mình không phải đúng thật nhanh, mà là đúng vì lý do đúng.

Vì sao một backtest đẹp vẫn chưa đủ?

Backtest là một trạm kiểm tra, không phải đích đến. Có ba thứ liên tục biến những kết quả hứa hẹn thành con số không:

Nếu kết quả bỏ qua chi phí giao dịch thật, nó chỉ là tưởng tượng. Đặc biệt với hệ thống ngắn hạn, spread, trượt giá, hoa hồng và hiệu ứng phiên không phải chú thích nhỏ bên lề chiến lược, chúng là một phần của tín hiệu. Nếu một setup chỉ hoạt động trước khi trừ chi phí thì nó chưa từng thật sự hoạt động.

Nếu kết quả phụ thuộc vào một nhóm parameter hẹp, nó rất mong manh. Một đỉnh đơn độc trên heatmap thường chỉ là nhiễu đang khoác áo đẹp.

Nếu kết quả biến mất khi ra ngoài mẫu, nó chưa bao giờ đủ mạnh ngay từ đầu.

Vì vậy sức mạnh của backtest là cần thiết nhưng còn xa mới đủ. Trong Dquants, một kết quả chỉ được tính khi nó đã sống sót qua out-of-sample và walk-forward, với hoa hồng, spread và trượt giá đã bị trừ sẵn trên tick data thật.

Vì sao mình lưu lại những ý tưởng đã thất bại?

Đây là phần mình từng đánh giá thấp. Việc khó nhất trong research là loại bỏ chính ý tưởng mà mình rất muốn nó đúng, và việc khó thứ hai là giữ cho nó ở trạng thái đã bị loại.

Nếu không có ghi chép, một hypothesis đã hỏng sẽ quay lại sau sáu tháng dưới một cái tên hơi khác, và mình lại mất đúng bấy nhiêu tuần để chứng minh đúng cái điều cũ. Vì vậy engine của mình giữ một registry ghi rõ các hypothesis đã bị loại. Một ý tưởng đã hỏng sẽ ở yên đó.

Mỗi lần loại bỏ là một lớp bảo vệ nhỏ giúp mình khỏi tự lừa dối bản thân. Trong công việc quant, đó không phải bước lùi, đó là một dạng quản trị rủi ro. Mình tin một hệ thống hơn khi nó sẵn sàng nói không, và mình tin một bộ kết quả hơn khi mình nhìn thấy được những gì đã bị bỏ đi để có được nó.

Vì sao mình phải xây hạ tầng cho việc này?

Công cụ tốt không tự tạo ra edge. Chúng làm cho sự trung thực trở nên dễ dàng hơn, và đó là một điều khác biệt và hữu ích hơn nhiều.

Mình muốn một workflow có thể lưu trữ, test, so sánh và replay lại mọi ý tưởng theo cùng một cách. Nghiên cứu dễ hơn khi dữ liệu được tổ chức gọn gàng. Việc kiểm định mạnh hơn khi các metric nhất quán. Niềm tin lớn lên khi một kết quả có thể được tái lập bất cứ lúc nào.

Quan sát đã đẩy mình đến chỗ thật sự bắt tay vào xây: nếu mình không replay lại được một kết quả một cách sạch sẽ, có lẽ mình chưa hiểu nó đủ rõ. Đó là toàn bộ lý do Dquants tồn tại như một engine Python và C++ chạy trên DuckDB, thay vì một thư mục đầy script rời rạc.

Cấu trúc thị trường nằm ở đâu trong bức tranh này?

Khi làm Master Volume Profile, cách tiếp cận volume profile của riêng mình hướng đến các setup ngắn hạn trên khung M3 và M5, mình bị buộc phải đặt những câu hỏi ở tầng tốt hơn. Thay vì hỏi giá đang lên hay xuống, mình bắt đầu hỏi thị trường đã chấp nhận giá trị ở đâu, giá đang bị từ chối ở đâu, và bối cảnh đấu giá quanh một chuyển động trông như thế nào.

Cách đặt vấn đề đó hữu ích hơn việc đọc hình dạng nến, vì cấu trúc thường giải thích được vì sao một chuyển động tiếp diễn hoặc thất bại. Nhưng bản thân cách đặt vấn đề không chứng minh được điều gì. Một ý tưởng dựa trên cấu trúc vẫn phải đi qua đúng cái gauntlet như mọi ý tưởng khác, và khá nhiều trong số đó đã không đi qua nổi. Bối cảnh làm cho một hypothesis đáng được kiểm định. Nó không miễn cho hypothesis đó khỏi việc bị kiểm định.

Điều rút ra trung thực nhất là gì?

Sản phẩm của quy trình này phần lớn là chữ không, và mình đã làm hòa được với điều đó. Một phương pháp nói thật với mình có giá trị hơn một phương pháp chỉ khiến mình dễ chịu được một tuần.

Nếu bạn là một kỹ sư đang nhìn vào thị trường, kỳ vọng thành thật của mình là phần lớn ý tưởng của bạn sẽ không sống sót khi va vào dữ liệu sạch và chi phí thật. Đó không phải quy trình đang làm khó bạn. Đó là phiên bản duy nhất của quy trình đáng để bạn sở hữu.

---

Bài viết này được tổng hợp từ các post 01 đến 12 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ư. Hiệu suất trong quá khứ không đảm bảo kết quả trong tương lai.