Chia IS/OOS chưa đủ: thiết kế cửa sổ Walk-Forward

Kết luận: nếu OOS chỉ có một đoạn, đó vẫn chỉ là "một lần thi"

Tách dữ liệu thành phần dùng để tối ưu (IS) và phần dùng để kiểm định (OOS) là bước đầu hữu ích để nghi ngờ tình trạng tối ưu hóa quá mức. Tuy nhiên, nếu chỉ chia đúng một lần, kết quả OOS chỉ cho bạn biết "trong đúng một đoạn đó thì thế nào".

Kết luận của chúng tôi như sau: hãy chia OOS thành nhiều cửa sổ, kiểm định trong khi dịch dần về phía trước, và xem từng cửa sổ có lãi hay không chứ không chỉ nhìn tổng. Dù tổng có lãi, nếu lợi nhuận dồn vào một vài cửa sổ nhất định thì chúng tôi tạm chưa đánh giá.

Điểm yếu của cách chia cố định

Điểm chia quyết định kết quả

Với cách chia cố định, nhà phát triển là người chọn điểm cắt. Nếu OOS tình cờ rơi vào giai đoạn xu hướng rõ ràng, logic sẽ trông tốt hơn thực lực của nó. Nếu rơi vào giai đoạn ngược lại, bạn có thể bỏ đi một logic vẫn dùng được. Cả hai trường hợp đều phụ thuộc vào một lựa chọn duy nhất là điểm chia.

Xem OOS nhiều lần thì nó không còn là OOS

Vấn đề thứ hai nằm ở hành vi của người phát triển. Thấy kết quả OOS xấu thì chỉnh tham số, rồi lại xem OOS. Lặp lại như vậy thực chất là đang chọn thứ phù hợp với OOS. Về hình thức đó là dữ liệu chưa dùng, nhưng trên thực tế nó đã được dùng để tối ưu. Đây là sai lầm chính chúng tôi cũng có thể mắc phải, và không thể ngăn chặn nếu không ràng buộc bằng quy trình.

Cách tạo cửa sổ walk-forward

Walk-forward lấy "giai đoạn tối ưu" và "giai đoạn kiểm định ngay sau đó" làm một cửa sổ, rồi lặp lại trong khi dịch thời gian về phía trước. Đoạn kiểm định luôn nằm ở tương lai so với đoạn tối ưu, nên bạn thu được nhiều đoạn OOS.

Tiêu chí chọn độ dài cửa sổ

Độ dài cửa sổ nên quyết định theo số giao dịch thay vì số năm theo lịch thì an toàn hơn. Nếu đoạn kiểm định có quá ít giao dịch, lãi hay lỗ chỉ là chuyện ngẫu nhiên. Logic giữ lệnh càng lâu và giao dịch càng thưa thì đoạn kiểm định càng cần dài.

Quy trình kiểm tra từng cửa sổ

1. Sắp xếp các cửa sổ sao cho các đoạn kiểm định không chồng lên nhau
2. Tối ưu trong từng cửa sổ, rồi chỉ áp dụng tham số thu được cho đoạn kiểm định ngay sau nó
3. Ghi lại lãi lỗ, PF, số giao dịch và drawdown tối đa của từng đoạn kiểm định
4. Kiểm tra có bao nhiêu cửa sổ đạt PF từ 1.0 trở lên, và các cửa sổ thua lỗ nằm ở giai đoạn nào
5. Loại cửa sổ có lợi nhuận lớn nhất ra, rồi xem tổng của phần còn lại có còn lãi hay không
6. Xem tham số được chọn ở từng cửa sổ có nhảy lung tung hay không

Có ba điểm cốt lõi khi kiểm tra:

• Các cửa sổ có lãi có dồn vào một vài đoạn hay không
• Mức lỗ của các cửa sổ thua có quá lớn so với lợi nhuận của các cửa sổ thắng hay không
• Tham số tối ưu của các cửa sổ liền kề có thay đổi quá mạnh hay không

Chúng tôi cho rằng không cần mọi cửa sổ đều có lãi. Với EA theo xu hướng, việc thua ở cửa sổ rơi vào giai đoạn thị trường không có hướng là chuyện bình thường. Điều đáng coi là vấn đề là không giải thích được lý do thua, và mức thua vượt quá dự tính.

Giới hạn và lưu ý

Không đủ giao dịch thì cửa sổ không có ý nghĩa

Backtest của ATLAS có 1193 giao dịch trong 7.5 năm kiểm định, nên dù chia thành nhiều cửa sổ thì mỗi cửa sổ vẫn còn một lượng giao dịch nhất định. Ngược lại, backtest của ETHEREUM EA chỉ có 154 giao dịch trong 7.5 năm kiểm định. Nếu cắt logic tần suất thấp như vậy thành các cửa sổ nhỏ, mỗi cửa sổ chỉ còn rất ít giao dịch và việc lãi hay lỗ theo từng cửa sổ gần như không còn giá trị để đánh giá. Cách duy nhất là làm cửa sổ thô hơn, hoặc chỉ coi đánh giá theo từng cửa sổ là thông tin tham khảo.

Các con số được công bố là giá trị của toàn bộ giai đoạn

PF và tỷ lệ thắng đăng trong bảng xếp hạng thực đo là giá trị tính trên toàn bộ giai đoạn kiểm định. Đó không phải kết quả theo từng cửa sổ, nên chỉ dựa vào đó thì không thể xác định có tối ưu hóa quá mức hay không. Xin bạn đọc với sự thận trọng này.

Chính việc thiết kế cửa sổ cũng có thể bị tối ưu hóa

Nếu bạn thay đổi độ dài hoặc số lượng cửa sổ rồi chọn tổ hợp cho kết quả đẹp, đó cũng là tối ưu hóa quá mức. Tiền đề là thiết kế cửa sổ phải được quyết định trước khi chạy kiểm định và không được chỉnh lại sau đó. Từ bên ngoài, gần như không có cách nào kiểm chứng tiền đề này có được tuân thủ hay không.

Dù vậy vẫn không biết được tương lai

Có vượt qua walk-forward cũng không có nghĩa là xử lý được thị trường chưa từng xuất hiện trong quá khứ. Trong forward test trên tài khoản demo mà chúng tôi đang vận hành, vẫn có nhiều EA đang lỗ. Đó là tài khoản demo chứ không phải kết quả tài khoản thật, và thời gian kể từ khi bắt đầu còn ngắn, nên cả kết quả tốt lẫn xấu đều chưa đến giai đoạn đủ để kết luận. Phương pháp kiểm định là công cụ để giảm sai sót, không phải lời hứa sẽ trúng.

Tóm tắt

• Chia IS/OOS cố định bị ảnh hưởng bởi điểm chia và số lần xem lại OOS
• Walk-forward tạo nhiều đoạn kiểm định và kiểm tra trong khi tiến dần về phía trước
• Thứ cần xem là lãi lỗ theo từng cửa sổ chứ không phải tổng. Hãy kiểm tra mức độ dồn lợi nhuận và độ ổn định của tham số
• Logic có ít giao dịch thì càng chia nhỏ cửa sổ, việc đánh giá càng thiếu ổn định
• Thiết kế cửa sổ phải cố định từ trước. Vượt qua kiểm tra cũng không biết được kết quả tương lai

Cách tư duy về kiểm định cũng được chúng tôi tổng hợp trong bộ kiến thức.