Tối ưu walk-forward mang tiếng là cách trung thực để tinh chỉnh một chiến lược, và nó xứng đáng với tiếng đó — ít nhất là so với việc tối ưu trên toàn bộ dữ liệu rồi ngồi ngắm kết quả. Nhưng kỹ thuật này có những kiểu thất bại rất thầm lặng, và kiểu nào cũng cho ra cùng một sản phẩm: một báo cáo kiểm định ghi "vững chắc" được đóng ghim vào một chiến lược thực ra không hề vững. Dưới đây là ba kiểu mà chúng tôi đã phải thiết kế hệ thống để phòng ngừa, sắp xếp theo đống đổ nát chúng để lại.
Thất bại thứ nhất: các cửa sổ bị rò rỉ
Cách làm sai: tinh chỉnh trên tháng Một–tháng Sáu, kiểm định trên tháng Bảy, rồi để bất cứ thứ gì từ tháng Bảy ảnh hưởng đến vòng thứ hai — chạy lại sau khi đã nhìn thấy con số ngoài mẫu, một "chỉnh nhẹ" lưới tham số, một đặc trưng được chuẩn hóa trên toàn chuỗi. Từng thứ nhìn đều vô hại. Cộng lại, chúng biến cửa sổ ngoài mẫu thành dữ liệu trong mẫu, chỉ là muộn hơn một nhịp.
Đống đổ nát: Sharpe ngoài mẫu bám sát Sharpe trong mẫu một cách khó hiểu. Kết quả ngoài mẫu thật thì nhiễu và đáng thất vọng; một mối quan hệ IS/OOS mượt mà đến mức đáng ngờ nghĩa là thông tin đang chảy ngược. Chúng tôi theo dõi tỷ lệ này một cách tường minh — trong mẫu lớn hơn 3 lần ngoài mẫu là gắn cờ lần chạy đó, còn ngoài mẫu bằng hoặc dưới 0 thì loại thẳng, bất kể trong mẫu đẹp đến đâu.
Thất bại thứ hai: đi săn chỉ số qua các cửa sổ
Chạy ba cửa sổ walk-forward, thu về ba kết quả nhiễu, rồi tổng hợp: Sharpe trung bình? Trung vị? Bỏ cửa sổ tệ nhất vì "đổi chế độ thị trường"? Mỗi lựa chọn là một bậc tự do, và một bộ tối ưu đủ kiên trì (dù là con người hay Bayes) sẽ tìm ra cách tổng hợp khiến chiến lược này trông đẹp nhất. Bảy mươi lăm lượt thử Optuna mỗi cửa sổ là bảy mươi lăm cơ hội để khớp vào nhiễu, nhân với số cách tổng hợp mà bạn sẵn lòng cân nhắc.
Đống đổ nát: một chiến lược vượt qua kiểm định rồi khi vào thực chiến lại cho ra đúng hiệu suất của cửa sổ tệ nhất, bởi cửa sổ tệ nhất là cửa sổ duy nhất trung thực. Quy tắc của chúng tôi: cách tổng hợp được chốt trong config trước khi chạy, ngân sách lượt thử được chốt, và analyst đọc kết quả từng cửa sổ kèm theo độ phân tán. Chiến lược nào cần một cách tổng hợp dễ dãi mới qua được thì coi như không qua.
Thất bại thứ ba: cái holdout thôi làm holdout
Một holdout chỉ hoạt động đúng một lần. Lần thứ hai một chiến lược được đánh giá trên nó — sau khi nhích tham số, chỉnh tín hiệu, hay "kiểm tra lại phát nữa thôi" — nó không còn là holdout; nó là một tập kiểm định chạy chậm. Mười lăm ngày chưa hề đụng đến nghe có vẻ dễ giữ nguyên, cho đến khi áp lực lặp lại ập tới và việc kiểm tra thêm một lần nữa trông thật vô hại.
Đống đổ nát ở đây tinh vi hơn: kết quả holdout cứ tốt dần lên qua các vòng lặp của cùng một chiến lược. Dữ liệu ngoài mẫu mới toanh chẳng có lý do gì để ưu ái vòng lặp thứ ba hơn vòng lặp thứ nhất, và khi điều đó xảy ra, holdout đã bị đào xới. Chúng tôi cưỡng chế nguyên tắc một-lần-duy-nhất bằng cơ chế: holdout được đánh giá đúng một lần cho mỗi lần chạy pipeline, kết quả được ghi vào hồ sơ, và chiến lược nào cần thêm một lần thử phải quay lại đi hết cả chặng chông gai — với cửa sổ mới hoàn toàn. Nó phải giữ được ít nhất 70% Sharpe ngoài mẫu của walk-forward, và không có lần gieo xúc xắc thứ hai.
Dấu hiệu sống sót qua cả ba
Trước tất cả những thứ đó, chúng tôi chạy một lượt quét độ nhạy đơn giản: nhích từng tham số ±20% rồi quan sát các chỉ số. Một lợi thế thật sự sẽ suy giảm từ tốn; một sự trùng hợp ngẫu nhiên thì rơi khỏi vách đá. Đây là phép thử rẻ nhất trong pipeline và nó phủ quyết những chiến lược lẽ ra đã lướt qua mọi tầng nói trên — bởi một vách đá tham số chính là hình hài của overfitting trước khi bạn cho nó cơ hội ẩn mình trong bộ máy kiểm định.
Không điều nào trong số này khiến việc tối ưu trở nên an toàn. Chúng chỉ khiến các kiểu thất bại phát ra tiếng động lớn — và đó là điều nhiều nhất bạn có thể trung thực đòi hỏi ở một quy trình kiểm định.
← Tất cả bài viết