1,600 tín hiệu một tuần: vì sao tôi không được phép biết chiến lược của mình đúng hay sai trước 29/11/2026

Con số

Chân chiến lược M2-FVG của tôi — thứ duy nhất còn bật trên live sau khi hai chân khác bị tắt — ra 1,600 tín hiệu mỗi tuần.

Không phải 1.600. Một phẩy sáu trăm. Một tín hiệu rưỡi một tuần.

Khoảng tin cậy 95 % bootstrap theo tuần: [1,339 ; 1,869]. Kiểm chéo bằng Poisson exact: [1,390 ; 1,833]. Hai phương pháp độc lập, cùng một câu trả lời.

Mẫu: 517 lệnh ES/NQ (train 280 + khoá 237), từ 01/03/2024 đến 18/08/2026 — 899 ngày = 29,5 tháng = 130 tuần lịch.

Điều con số đó làm với quyền phát biểu của tôi

Muốn nói "chiến lược này có edge" ở mức có nghĩa thống kê tối thiểu, tôi cần khoảng 15 lệnh sạch. Với λ = 1,600/tuần:

Tính từ 26/09/2026, ngày đủ 15 lệnh là ~29/11/2026 — nhanh nhất 21/11, chậm nhất 13/12.

Đó là toàn bộ nội dung của bài này, và nó là một câu bất lợi cho tôi: từ hôm nay đến hết tháng 11, tôi không có quyền nói chiến lược của mình đúng. Cũng không có quyền nói nó sai. Tôi chỉ có quyền nói tôi chưa biết.

Vì sao "trung bình 1,6/tuần" là con số dễ bị đọc sai nhất trong hồ sơ

Trung bình trơn 1,6 nghe như "gần hai lệnh mỗi tuần, tuần nào cũng có". Phân bố thực tế không như vậy:

• 25,4 % số tuần RỖNG — một phần tư số tuần không có lệnh nào.
• Chuỗi rỗng dài nhất: 4 tuần liên tiếp.
• Chỉ 40 % số tuần đạt ≥ 2 lệnh.
• Tuần đỉnh: 7 lệnh.

Nghĩa là trải nghiệm thật của người chạy chiến lược này không phải "mỗi tuần hơn một lệnh", mà là cụm rồi im, cụm rồi im, có lúc im cả tháng. Ai không biết phân bố sẽ kết luận "hệ thống hỏng" vào đúng tuần thứ hai của một chuỗi rỗng bình thường.

Kiểm cụm: dedup 30 phút cho ra 1,508/tuần — gần như không đổi. Tức con số 1,600 không bị thổi bởi mấy tín hiệu dính chùm trong cùng một nhịp giá. (Chân CONT-DISP thì ngược lại: shadow ghi 13 tín hiệu thô, dedup còn 6.)

Bài kiểm tôi tự làm rồi tự trượt

Tuần 19–25/09, hệ thống canh live ra 0 tín hiệu M2-FVG. Phản xạ đầu tiên của tôi là "detector hỏng". Tôi đã sắp viết task sửa SH.detect().

Rồi tôi tính xác suất. Với λ = 1,600/tuần:

P(X = 0 trong 1 tuần) = 20,2 %.

Và backtest đo được 25,4 % tuần rỗng. Hai con số khớp nhau.

Một tuần rỗng là biến cố 1-trên-4. Nó không là bằng chứng của bất cứ điều gì. Muốn kết luận detector hỏng cần ≥ 3 tuần rỗng liên tiếp (P ≈ 0,8 %). Hiện tôi mới có 1.

Kiểm thêm regime để chắc không phải thị trường vừa đổi: 12 tuần cuối 1,50/tuần · 24 tuần cuối 1,25/tuần · 52 tuần cuối 1,67/tuần. Không suy giảm.

Nếu tôi tin phản xạ thay vì tin số, tôi đã tiêu vài ngày sửa một thứ không hỏng — và tệ hơn, đã ghi vào hồ sơ một chẩn đoán sai mà sáu tháng sau chính tôi sẽ đọc lại như dữ kiện.

Con số thứ hai, xấu hơn con số thứ nhất

Tần suất chỉ là một nửa bài toán. Nửa còn lại: cần bao nhiêu lệnh để edge tách được khỏi nhiễu. Công thức cho mốc t = 2:

n_can_cho_t2 = (2 · sd_R / expR)²

Áp vào từng cặp setup × sàn bằng số quan sát thật:

Luật tôi tự đặt trước khi chạy: so_thang_can > 18 ⇒ gỡ khỏi lộ trình vốn.

Cả 5 cặp đều trượt. Cặp tốt nhất cần 18,1 tháng — vượt ngưỡng đúng 0,1. Cặp tệ nhất cần 101,2 tháng = 8,4 năm.

Đây không phải kết luận "chiến lược tồi". expR dương trên cả 5 cặp, WR 43–55 %. Đây là kết luận nặng hơn: với tần suất này, tôi không thể chứng minh nó trong khung thời gian mà một quỹ nhỏ còn tồn tại. Edge có thể thật. Nhưng "có thể thật" và "chứng minh được" là hai thứ khác nhau, và chỉ thứ thứ hai được phép cấp vốn.

Cột tôi suýt không in

Bảng trên có một cột tên he_so_hut — tỉ số giữa cơ hội backtest đếm được và cơ hội hệ thống live thật sự bắt được.

Cột này nói: với M2-FVG/NQ, backtest thấy 3,8 cơ hội/tháng còn hệ thống live thấy không cái nào. he_so_hut = ∞ không phải phát hiện về thị trường — nó là phát hiện về hạ tầng của tôi. Một đường ống đâu đó đang bỏ tín hiệu.

Tôi in cột này ra vì nếu bỏ nó, bảng trên sẽ đọc như một kết luận chiến lược ("tần suất thấp là bản chất setup") trong khi sự thật có thể là một lỗi kỹ thuật của tôi. Luật tôi ghi vào chính file kết quả: he_so_hut > 2,0 ⇒ đó là lỗi hạ tầng, chặn mọi kết luận chiến lược cho cặp đó.

Nói thẳng: bảng "số tháng cần" phía trên có thể đang bi quan quá vì hạ tầng tôi rò, chứ không phải vì setup kém. Tôi chưa biết. Ghi lại để không ai — kể cả tôi — dùng nó như bằng chứng cuối.

Điều đáng lấy đi khỏi bài này

1. Tần suất là trần cứng của tri thức. Chiến lược ra ít lệnh thì không chỉ lãi

chậm — nó không thể được kiểm định. Hai chuyện đó bị gộp làm một trong hầu hết nội dung trading tôi đọc.

1. Trung bình che phân bố. 1,6/tuần với 25,4 % tuần rỗng và chuỗi rỗng 4 tuần là

một trải nghiệm hoàn toàn khác với "1,6/tuần".

1. Tính P(X=0) trước khi gọi thợ. Một tuần rỗng ở λ = 1,6 xảy ra 20,2 % thời

gian. Sửa thứ không hỏng tốn hơn là chờ.

1. Luôn đo khoảng cách backtest ↔ live. Nếu he_so_hut lệch quá 2×, mọi kết luận

chiến lược của bạn đang nói về đường ống, không về thị trường.

Tự kiểm chứng

Số trong bài đến từ những file này, không từ ký ức tôi:

# tần suất + KTC + phân bố tuần rỗng
cat ~/Documents/trading/ES-NQ/m2fvg_tansuat_tomtat.csv

# bảng số-tháng-cần và he_so_hut
column -s, -t < ~/Documents/trading/ES-NQ/tan_suat_kha_thi.csv | less -S

# mẫu gốc 517 lệnh
python3 -c "import pickle;d=pickle.load(open('$HOME/Documents/trading/ES-NQ/setup_gate3.pkl','rb'));print(type(d))"

Nếu bạn chạy lại và ra số khác, đó là thứ tôi muốn biết nhất.

Cảnh báo rủi ro

Bài này là phân tích giáo dục về cỡ mẫu và giới hạn suy luận thống kê, không phải lời khuyên đầu tư. Hiệu suất quá khứ không bảo đảm kết quả tương lai. Giao dịch đòn bẩy có rủi ro mất toàn bộ vốn. Số liệu lấy từ tài khoản demo (demo.ctrader.5885753) và backtest; tôi không nhận góp vốn, không bán tín hiệu.