Backtest đẹp mà chạy thật thua: chín nguyên nhân chênh lệch, ba mức kiểm chứng và năm bước đo
Có một trải nghiệm gần như phổ quát với người chạy bot: đường vốn backtest đẹp, và kết quả chạy thật tệ. Không phải tệ một chút — tệ tới mức bạn nghi ngờ chính chiến lược, hoặc nghi ngờ rằng thị trường đã thay đổi.
Trong phần lớn trường hợp, cả hai nghi ngờ đó đều sai. Chiến lược không hỏng và thị trường không đổi. Điều xảy ra là: backtest của bạn đang đo một thứ khác với thứ bạn đang chạy thật.
Khoảng cách đó có chín nguồn chính, chia thành ba nhóm. Ba nhóm này khác nhau ở mức độ khó phát hiện, và nhóm khó nhất là nhóm không để lại dấu vết nào trong báo cáo.
Bài này đi qua chín nguyên nhân, ba mức kiểm chứng trước khi tăng khối lượng, và một quy trình năm bước để đo chênh lệch giữa mô phỏng và thực tế.
Một nguyên tắc xuyên suốt: backtest là công cụ để loại bỏ chiến lược, không phải công cụ để xác nhận chiến lược. Nếu bạn dùng nó theo hướng thứ hai, bạn đang tìm lý do để tin vào thứ mình muốn tin.
1. Ba nhóm nguyên nhân
Nhóm 1 — Lỗi dữ liệu. Ba nguyên nhân, và chúng gây ra chênh lệch lớn nhất. Vấn đề: bạn thường không thể tự phát hiện chúng, vì dữ liệu bạn có chính là dữ liệu gây ra lỗi.
Nhóm 2 — Lỗi cách mô phỏng. Ba nguyên nhân. Nhóm này dễ sửa hơn vì bạn kiểm soát được cấu hình của backtest.
Nhóm 3 — Lỗi phương pháp của người làm. Ba nguyên nhân. Đây là nhóm khó thấy nhất, vì nó không để lại dấu vết nào trong báo cáo — báo cáo chỉ trình bày kết quả, không trình bày cách bạn chọn tham số.
Điều đáng chú ý về ba nhóm: nhóm 3 là nhóm phổ biến nhất, và cũng là nhóm ít được nhắc tới nhất trong các tài liệu về backtest. Lý do rất con người: nhóm 3 đòi hỏi bạn nhìn vào cách chính mình làm việc, không phải vào công cụ.
2. Nhóm 1 — Ba lỗi dữ liệu
2.1. Dữ liệu thiếu tick thật
Backtest tốt nhất dùng dữ liệu tick thật — chuỗi giá thật sự đã diễn ra, từng thay đổi một. Backtest kém nhất dùng dữ liệu nến — bốn điểm dữ liệu cho mỗi nến (mở, cao, thấp, đóng).
Vấn đề khi dùng dữ liệu nến: trình backtest phải suy đoán đường đi của giá bên trong nến. Nếu cả stop-loss và mục tiêu nằm trong phạm vi một nến, trình backtest phải chọn cái nào được chạm trước — và nó có thể chọn sai.
Hệ quả cụ thể: một chiến lược dùng stop-loss chặt có thể trông tốt trên dữ liệu nến và tệ trên thực tế, hoặc ngược lại. Và bạn không biết mình đang ở trường hợp nào.
Cách kiểm chứng: chạy cùng một chiến lược với hai loại dữ liệu — nến M1 và tick thật. Nếu kết quả khác nhau nhiều, bạn đang bị ảnh hưởng bởi chất lượng dữ liệu, và kết quả dùng nến không đáng tin.
2.2. Chỉ dùng dữ liệu nến M1
Đây là biến thể của lỗi trên, nhưng đáng nói riêng vì nó là mức "khá tốt" mà nhiều người cho là đủ.
Dữ liệu nến M1 tốt hơn dữ liệu nến H1 nhiều. Nhưng nó vẫn không thấy được đỉnh và đáy bên trong một phút. Với bot scalping có stop-loss vài pip, một phút có thể chứa toàn bộ câu chuyện của lệnh đó.
Cách kiểm chứng: nếu chiến lược của bạn có stop-loss hoặc mục tiêu nhỏ hơn phạm vi biến động trung bình của một nến M1, bạn cần dữ liệu tick thật. Không có cách nào khác.
2.3. Spread giả định cố định
Phần lớn backtest cho phép đặt một giá trị spread cố định, và hầu hết người dùng đặt một giá trị như 1,0 pip.
Vấn đề: spread thật không cố định. Nó thay đổi theo phiên, theo tin, và theo thanh khoản. Nếu chiến lược của bạn vào lệnh trong những khung giờ spread cao, backtest với spread 1,0 pip sẽ thổi phồng kết quả.
Hệ quả đặc biệt nghiêm trọng với chiến lược nhiều lệnh: sai số spread nhân với số lệnh. Với 200 lệnh một tháng, sai số 0,5 pip mỗi lệnh là khoảng 100 USD một tháng — đủ để đảo dấu kết quả.
Cách kiểm chứng: nạp spread theo giờ nếu công cụ cho phép. Nếu không, chạy lại backtest với spread cao hơn — ví dụ 2,0 pip thay vì 1,0. Nếu chiến lược vẫn có lãi ở mức spread cao, bạn có khoảng đệm. Nếu không, bạn đang phụ thuộc vào giả định lạc quan.
Đây là phép kiểm tra đơn giản nhất và hữu ích nhất trong cả bài: chạy lại với chi phí cao hơn mức bạn tin. Chiến lược sống được qua phép thử này đáng để chạy thật.
3. Nhóm 2 — Ba lỗi cách mô phỏng
3.1. Không tính hoa hồng và swap
Đây là lỗi đơn giản nhất và phổ biến nhất trong nhóm này. Backtest có lãi, nhưng khi trừ hoa hồng và swap, hết lãi.
Với bot giữ lệnh qua đêm, swap có thể là khoản lớn hơn cả spread. Và với một số chiến lược, chi phí cố định của backtest — như hoa hồng — bị bỏ qua hoàn toàn.
Cách kiểm chứng: chạy lại backtest với đủ bốn loại chi phí (spread, hoa hồng, swap, phí cuối tuần). Nếu công cụ không hỗ trợ swap, hãy trừ thủ công: số lệnh nhân số ngày giữ trung bình nhân swap trung bình.
Một mẹo: nếu bạn không chắc swap, hãy trừ ở hai mức — một mức bạn tin, và một mức gấp ba. Chiến lược phải sống được ở mức thứ hai.
3.2. Khớp lệnh ở giá đóng nến
Đây là lỗi tinh vi nhất trong nhóm, và nó liên quan trực tiếp tới một câu hỏi kỹ thuật bạn cần trả lời rõ ràng: khi điều kiện vào lệnh được thỏa ở nến N, giá khớp là giá nào?
Ba khả năng:
- Giá đóng của nến N. Đây là giả định lạc quan nhất: bạn vào lệnh ở giá đóng nến mà điều kiện vừa được đánh giá. Trong thực tế, ở thời điểm bạn biết điều kiện đã thỏa, giá đó đã là quá khứ.
- Giá mở của nến N+1. Đây là giả định thực tế hơn nhiều: bạn đánh giá nến N đã hoàn thành, và gửi lệnh ở lệnh tiếp theo mở.
- Giá mở của nến N. Đây là giả định rất lạc quan (đánh giá và khớp cùng lúc) và hầu như không thực tế với bot.
Phần lớn công cụ backtest mặc định dùng cách thứ nhất. Đó là nguồn chênh lệch hệ thống — và nó lệch theo hướng có lợi, nên nó không tự lộ ra.
Cách kiểm chứng: chuyển cấu hình khớp lệnh sang "giá mở nến tiếp theo" và chạy lại. Chênh lệch giữa hai lần chạy là số tiền bạn đang tự cho mình trong backtest.
3.3. Không mô phỏng trượt giá
Trượt giá là chênh lệch giữa giá bạn muốn và giá bạn được khớp. Nó xảy ra ở cả hai đầu của một vòng giao dịch, và nó lớn hơn khi thị trường biến động.
Nếu backtest của bạn giả định khớp ở giá chính xác, nó cho bạn một kết quả mà bạn không bao giờ đạt được.
Cách kiểm chứng: thêm một mức trượt giá vào cấu hình — bắt đầu với 0,5 pip mỗi lần vào lệnh. Nếu công cụ không hỗ trợ, hãy trừ thủ công: số lệnh nhân 1,0 pip (0,5 khi vào, 0,5 khi ra).
Và cách kiểm chứng tốt nhất là đo trượt giá thật của bot bạn đang chạy. Con số đó luôn thuyết phục hơn mọi giả định — xem quy trình ở mục 5.
4. Nhóm 3 — Ba lỗi phương pháp
Đây là nhóm khó thấy nhất, vì nó không để lại dấu vết nào trong báo cáo. Báo cáo trình bày kết quả; nó không trình bày việc bạn đã thử bao nhiêu bộ tham số trước khi chọn bộ này.
4.1. Tối ưu quá nhiều tham số
Đây là nguyên nhân phổ biến nhất của "backtest đẹp".
Cơ chế: nếu bạn thử đủ nhiều bộ tham số khác nhau trên cùng một tập dữ liệu, sẽ có một bộ trông rất tốt chỉ nhờ may mắn. Không phải vì nó phát hiện quy luật thật, mà vì bạn đã thử đủ nhiều.
Với 10 tham số, mỗi tham số 5 giá trị, bạn có gần 10 triệu tổ hợp. Thử một phần nhỏ trong số đó cũng đủ để tìm ra một bộ khớp hoàn hảo với quá khứ — và vô nghĩa với tương lai.
Cách kiểm chứng: kiểm chứng ngoài mẫu. Chia dữ liệu thành hai phần: 70% để tối ưu, 30% để kiểm chứng. Tối ưu trên phần đầu, rồi chạy bộ tham số đã chọn trên phần sau mà không sửa gì thêm.
Điểm cần cẩn thận: nếu kết quả ngoài mẫu kém, bạn không được quay lại sửa tham số rồi thử lại. Mỗi lần bạn làm vậy, phần "ngoài mẫu" của bạn không còn là ngoài mẫu nữa.
4.2. Chọn đúng giai đoạn đẹp
Đây là lỗi về thời gian. Nếu bạn chọn khoảng thời gian để tối ưu, và chọn khoảng mà chiến lược hoạt động tốt, bạn đã loại bỏ thông tin quan trọng nhất: chiến lược này xử lý giai đoạn xấu thế nào?
Cách phòng: chạy trên một khoảng dài liên tục, không chia nhỏ chọn lọc. Với thị trường ngoại hối, khoảng 5 năm trở lên, và phải bao gồm ít nhất một giai đoạn biến động mạnh.
Nếu bạn chỉ có dữ liệu của một giai đoạn thị trường yên ả, hãy biết rằng: bạn chưa kiểm chứng chiến lược của mình trong điều kiện khó. Đó là thông tin quan trọng hơn mọi chỉ số khác.
4.3. Khối lượng và đòn bẩy sai
Đây là lỗi ít được nói tới nhất, và nó làm đường vốn trở nên vô nghĩa.
Cơ chế: nếu bạn backtest với khối lượng cố định, đường vốn của bạn phản ánh một chiến lược tính bằng pip. Nhưng nếu bạn chạy thật với khối lượng theo tỉ lệ vốn (ví dụ 1% rủi ro mỗi lệnh), thì khi tài khoản giảm, khối lượng cũng giảm, và chiến lược có thể không phục hồi được — hoặc ngược lại, khi tài khoản tăng, khối lượng tăng và rủi ro tăng.
Hai điều này cho hai đường vốn khác nhau, đôi khi rất khác. Và điều tệ nhất là: với khối lượng theo tỉ lệ vốn, một chuỗi thua ngắn có thể xoá tài khoản, trong khi backtest với khối lượng cố định cho thấy một đợt giảm bình thường.
Cách phòng: dùng cùng cách tính khối lượng trong backtest và trong chạy thật. Nếu bạn chạy thật với 1% rủi ro mỗi lệnh, hãy backtest cũng vậy. Nếu công cụ của bạn không hỗ trợ, hãy tự viết phần tính khối lượng vào chiến lược.
Đây là điểm nhiều người bỏ qua vì việc cấu hình khối lượng động trong backtest tốn thời gian. Nhưng một đường vốn không phản ánh cách bạn chạy thật là một đường vốn vô nghĩa.
5. Ba mức kiểm chứng trước khi tăng khối lượng
Ba mức này trả lời ba câu hỏi khác nhau, và bạn nên làm theo thứ tự.
Mức 1 — Kiểm chứng ngoài mẫu
Câu hỏi: kết quả có phải do khớp dữ liệu, hay do chiến lược thật sự có lợi thế?
Cách làm: tối ưu trên 70% dữ liệu, kiểm chứng trên 30%. Không sửa gì sau khi thấy kết quả ngoài mẫu.
Tiêu chí: kết quả ngoài mẫu phải cùng dấu với kết quả trong mẫu, và không kém hơn quá nhiều. Nếu ngoài mẫu lỗ trong khi trong mẫu lãi rõ ràng, bạn đang có vấn đề khớp dữ liệu — và ở mức này, bạn chưa cần chạy thật.
Mức 2 — Chạy demo 30 ngày
Câu hỏi: hệ thống thật (VPS, mạng, broker, giờ giao dịch) có tạo ra kết quả giống mô phỏng không?
Cách làm: chạy trên tài khoản demo ít nhất 30 ngày, và đo cùng một bộ chỉ số cho cả hai bên:
- Số lệnh
- Giờ vào lệnh
- Trượt giá mỗi lệnh
- Chi phí mỗi lệnh
- Thời gian giữ lệnh trung bình
Tiêu chí: các chỉ số này phải gần nhau. Nếu số lệnh chênh nhiều, vấn đề nằm ở logic hoặc ở dữ liệu giá thật. Nếu trượt giá cao hơn nhiều so với giả định, vấn đề nằm ở hạ tầng hoặc ở thời điểm vào lệnh.
Dòng cuối là điều quan trọng nhất: mức 2 không nói gì về lợi nhuận kỳ vọng — nó nói về việc hệ thống của bạn có hoạt động như thiết kế hay không. Đó là một câu hỏi khác, và nó rẻ hơn nhiều để trả lời.
Mức 3 — Tiền thật, khối lượng nhỏ, 30 ngày
Câu hỏi: khi có tiền thật, bạn có giữ được quy trình không?
Cách làm: khối lượng nhỏ nhất, 30 ngày, và giữ nguyên toàn bộ quy trình — cảnh báo, nhật ký, kiểm tra hằng ngày.
Tiêu chí: không phải lợi nhuận. 30 ngày với khối lượng nhỏ không đủ để nói gì về lợi nhuận. Tiêu chí là: bạn có thực hiện đúng quy trình vận hành không, và hệ thống có cần can thiệp tay bao nhiêu lần.
Mức 3 là mức đa số người chạy bot bỏ qua — họ chuyển từ demo thẳng sang khối lượng thật. Đó là cách đắt nhất để học rằng quy trình của mình chưa sẵn sàng.
Điều quan trọng nhất về ba mức này
Ba mức trả lời ba câu hỏi khác nhau, và không mức nào thay thế được mức khác:
- Mức 1 nói về chiến lược.
- Mức 2 nói về hệ thống.
- Mức 3 nói về chính bạn.
Một chiến lược tốt với hệ thống chưa sẵn sàng vẫn thua. Một hệ thống tốt với người vận hành chưa quen vẫn thua. Vì vậy cả ba mức đều cần — và thứ tự quan trọng, vì việc bạn học ở mức rẻ hơn sẽ không lặp lại ở mức đắt hơn.
6. Quy trình năm bước đo chênh lệch
Bước 1 — Chốt bộ chỉ số so sánh
Trước khi chạy thật, quyết định bạn sẽ so cái gì. Bộ chỉ số tối thiểu:
- Số lệnh trong kỳ.
- Giờ vào lệnh — phân bố theo giờ, không chỉ trung bình.
- Trượt giá mỗi lệnh.
- Chi phí mỗi lệnh.
- Thời gian giữ lệnh trung bình.
Chốt trước là điều quan trọng. Sau khi biết kết quả, bạn sẽ có xu hướng tự nhiên là chọn chỉ số có lợi cho mình — và bạn sẽ không nhận ra mình đang làm vậy.
Bước 2 — Ghi lại kỳ vọng từ mô phỏng
Đây là bước khó nhất về mặt tâm lý, và cũng là bước quan trọng nhất.
Viết ra, thành con số, những gì bạn kỳ vọng: số lệnh, trượt giá trung bình, chi phí mỗi lệnh. Viết ra trước khi chạy thật.
Lý do rất con người: ký ức của bạn tự điều chỉnh. Sau khi thấy kết quả thật là 180 lệnh trong khi bạn nghĩ là 200, bạn sẽ nhớ rằng "chắc khoảng 190". Một con số được viết ra trước thì không tự điều chỉnh.
Bước 3 — Đo trên chạy thật, cùng kỳ hạn
Chạy thật 30 ngày, và đo đúng năm chỉ số ở bước 1.
Điều kiện: cùng kỳ hạn và cùng khối lượng. Nếu bạn chạy thật 60 ngày trong khi mô phỏng 30 ngày, bạn không so được. Nếu bạn chạy thật với khối lượng khác, bạn không so được.
Bước 4 — Tìm chỉ số lệch nhiều nhất
So sánh và xếp hạng theo mức lệch. Hai chỉ số thường lệch nhất:
- Trượt giá — nếu lệch nhiều, vấn đề nằm ở hạ tầng hoặc thời điểm vào lệnh.
- Số lệnh — nếu lệch nhiều, vấn đề nằm ở logic hoặc ở dữ liệu giá thật khác dữ liệu backtest.
Nguyên tắc quan trọng: mỗi lần chỉ sửa một chỉ số. Nếu bạn sửa cả trượt giá lẫn số lệnh cùng lúc rồi chạy lại, bạn sẽ không biết thay đổi nào có tác dụng — và lần sau gặp vấn đề, bạn vẫn phải bắt đầu lại từ đầu.
Bước 5 — Ghi vào nhật ký và lặp lại sau 30 ngày
Ghi lại: ngày, năm chỉ số dự kiến, năm chỉ số thật, chỉ số đã sửa, kết quả sau khi sửa. Một bảng đơn giản.
Sau 30 ngày, làm lại bước 3 và 4.
Giá trị của việc lặp lại lớn hơn giá trị của một lần đo. Một lần đo cho bạn một con số; ba lần đo cho bạn một xu hướng. Và xu hướng là thứ giúp bạn phân biệt "chiến lược này không hoạt động" với "tháng này thị trường bất lợi".
7. Một phép thử mà tôi cho là hữu ích nhất
Nếu bạn chỉ làm được một việc sau khi đọc bài này, hãy làm việc này: chạy lại backtest với chi phí cao hơn mức bạn tin.
Cách làm cụ thể — ba lần chạy:
- Chạy hiện tại — với bộ chi phí bạn đang dùng.
- Chạy với chi phí gấp đôi — spread gấp đôi, hoa hồng gấp đôi, thêm trượt giá 1,0 pip mỗi vòng.
- Chạy với khớp lệnh ở giá mở nến tiếp theo thay vì giá đóng nến.
Ba lần chạy này mất khoảng 30 phút. Và kết quả trả lời được ba câu hỏi quan trọng:
- Chiến lược có sống được khi chi phí tệ hơn dự kiến không?
- Kết quả phụ thuộc bao nhiêu vào giả định khớp lệnh?
- Nếu cả hai đều làm kết quả âm, tôi có nên chạy thật không?
Câu hỏi thứ ba là câu hỏi bạn nên trả lời trước khi chạy tiền thật, không phải sau.
Và đây là giá trị thật của phép thử: nó chuyển câu hỏi từ "chiến lược này có lãi không?" — câu hỏi bạn không thể trả lời chắc chắn — sang "chiến lược này có chịu được điều kiện xấu hơn không?" — câu hỏi bạn trả lời được. Nếu chiến lược chịu được điều kiện xấu hơn và vẫn có lãi, khoảng đệm của bạn là thật. Nếu nó chỉ có lãi ở điều kiện tốt nhất, bạn đang phụ thuộc vào may mắn.
8. Câu hỏi thường gặp
Hỏi: Kết quả thật kém hơn backtest thì bao nhiêu là bình thường?
Kém 20–30% là bình thường, và phần lớn đến từ chi phí (spread thật cao hơn, trượt giá, swap). Kém hơn 50% là dấu hiệu có vấn đề cụ thể cần tìm. Kém tới mức lỗ trong khi backtest lãi là dấu hiệu của lỗi nhóm 1 hoặc nhóm 3, không phải của chi phí.
Hỏi: Cần bao nhiêu dữ liệu để backtest đáng tin?
Về chất lượng: càng nhiều tick thật càng tốt. Về độ dài: càng dài càng tốt, nhưng phải bao gồm ít nhất một giai đoạn biến động mạnh. Một chiến lược kiểm chứng trên 10 năm thị trường yên ả có thể ít thông tin hơn một chiến lược kiểm chứng trên 3 năm có cả giai đoạn bất thường.
Hỏi: Làm sao biết mình đã tối ưu quá nhiều tham số?
Ba dấu hiệu. (1) Bộ tham số đẹp nhất nằm ở rìa miền tối ưu — quanh nó kết quả tệ hẳn. (2) Kết quả thay đổi rất nhiều khi bạn đổi tham số đi một chút. (3) Kết quả ngoài mẫu kém hơn hẳn kết quả trong mẫu. Cả ba đều chỉ về cùng một kết luận: chiến lược đang khớp dữ liệu, không phải khớp quy luật.
Hỏi: Chạy demo 30 ngày có đủ không?
Đủ để trả lời câu hỏi của mức 2 (hệ thống có hoạt động như thiết kế không), không đủ để trả lời câu hỏi về lợi nhuận. Nếu bạn muốn nói gì về lợi nhuận, bạn cần nhiều tháng hơn — nhưng lúc đó bạn nên dùng tiền thật với khối lượng nhỏ, vì demo không tái hiện được trượt giá thật và tâm lý.
Hỏi: Chiến lược của tôi backtest tốt trên nhiều symbol. Có nên chạy tất cả không?
Không ngay. Hãy chọn symbol bạn hiểu rõ nhất, và kiểm chứng qua cả ba mức với symbol đó. Chạy nhiều symbol cùng lúc là cách nhanh nhất để không biết mình đang sai ở đâu — vì mỗi symbol thêm một biến số.
Hỏi: Tôi có nên tin vào kết quả backtest của EA mua sẵn không?
Kết quả backtest do người bán cung cấp là thông tin tiếp thị, không phải bằng chứng. Bạn không biết họ dùng dữ liệu gì, tối ưu bao nhiêu lần, và chọn giai đoạn nào. Hãy tự chạy lại phép thử ở mục 7 với chính dữ liệu của bạn, rồi đưa ra kết luận.
Hỏi: Làm sao biết vấn đề là ở chiến lược hay ở hệ thống?
So sánh số lệnh và giờ vào lệnh giữa mô phỏng và chạy thật. Nếu hai chỉ số này khớp nhưng kết quả lệch, vấn đề nằm ở chi phí hoặc ở chiến lược. Nếu hai chỉ số này lệch, vấn đề nằm ở hệ thống — logic, dữ liệu, hoặc môi trường chạy. Đây là cách chia đôi không gian vấn đề nhanh nhất.
9. Checklist và tóm lại
Trước khi chạy tiền thật:
- [ ] Kiểm chứng ngoài mẫu (mức 1) — và không sửa gì sau khi thấy kết quả
- [ ] Chạy lại backtest với chi phí gấp đôi mức bạn tin
- [ ] Chạy lại với khớp lệnh ở giá mở nến tiếp theo
- [ ] Xác nhận cách tính khối lượng trong backtest giống cách chạy thật
- [ ] Kiểm tra dữ liệu: dùng tick thật nếu stop-loss nhỏ hơn biến động một nến M1
- [ ] Kiểm tra khoảng thời gian backtest có bao gồm giai đoạn biến động mạnh
Trước khi tăng khối lượng:
- [ ] Hoàn thành mức 2 — demo 30 ngày, đo cùng bộ chỉ số
- [ ] Hoàn thành mức 3 — tiền thật khối lượng nhỏ, 30 ngày, giữ nguyên quy trình
- [ ] Chốt bộ năm chỉ số so sánh và ghi lại kỳ vọng trước khi chạy
- [ ] Xác nhận chi phí tăng bao nhiêu khi tăng khối lượng (chi phí tăng nhanh hơn khối lượng)
Duy trì:
- [ ] Đo năm chỉ số mỗi 30 ngày và ghi vào nhật ký
- [ ] Mỗi lần chỉ sửa một chỉ số, rồi đo lại
- [ ] So trung bình ba lần đo — xu hướng quan trọng hơn một con số
Bốn nguyên tắc để nhớ:
- Backtest dùng để loại bỏ chiến lược, không phải để xác nhận. Nếu bạn dùng nó theo hướng thứ hai, bạn đang tìm lý do để tin.
- Lỗi phương pháp (nhóm 3) là nhóm phổ biến nhất và khó thấy nhất. Nó không để lại dấu vết nào trong báo cáo.
- Phép thử hữu ích nhất là chạy lại với chi phí cao hơn mức bạn tin. Chiến lược sống được qua phép thử đó đáng để chạy thật.
- Ba mức kiểm chứng trả lời ba câu hỏi khác nhau: chiến lược, hệ thống, và chính bạn. Không mức nào thay thế được mức khác.
Và nếu bạn chỉ làm được một việc sau khi đọc bài này: hãy ghi ra, thành con số, những gì bạn kỳ vọng — số lệnh, trượt giá, chi phí mỗi lệnh — trước khi chạy thật. Ký ức của bạn tự điều chỉnh sau khi biết kết quả. Một con số được viết ra trước thì không.