Walk-forward optimization punya reputasi sebagai cara jujur untuk menyetel sebuah strategi, dan reputasi itu memang pantas — dibandingkan dengan mengoptimasi di seluruh data lalu mengagumi hasilnya. Tapi teknik ini punya mode kegagalan yang senyap, dan masing-masing menghasilkan artefak yang sama: laporan validasi bertuliskan "robust" yang distaples ke strategi yang sebenarnya tidak. Berikut tiga di antaranya yang harus kami antisipasi lewat rekayasa, disusun berdasarkan kerusakan yang mereka tinggalkan.
Kegagalan satu: window yang bocor
Cara yang salah: setel di Januari–Juni, validasi di Juli, lalu biarkan apa pun dari Juli memengaruhi putaran kedua — pengulangan setelah melihat angka out-of-sample, "sedikit penyesuaian" pada parameter grid, sebuah fitur yang dinormalisasi di seluruh rentang data. Masing-masing terlihat tidak berbahaya. Digabungkan, semuanya mengubah window out-of-sample menjadi data in-sample yang tertunda.
Kerusakannya: Sharpe out-of-sample yang secara misterius mengikuti Sharpe in-sample. Hasil out-of-sample yang sungguhan itu berisik dan mengecewakan; hubungan IS/OOS yang mencurigakan mulusnya berarti informasi mengalir mundur. Kami memantau rasio itu secara eksplisit — in-sample lebih dari 3x out-of-sample menandai run tersebut, dan out-of-sample nol atau di bawahnya langsung membatalkannya, sebagus apa pun tampilan in-sample-nya.
Kegagalan dua: metric shopping lintas window
Jalankan tiga window walk-forward, dapat tiga hasil yang berisik, lalu rangkum: rata-rata Sharpe? Median? Buang window terburuk dengan alasan "pergantian rezim"? Setiap pilihan adalah satu derajat kebebasan, dan optimizer yang gigih (manusia maupun Bayesian) akan menemukan ringkasan yang membuat strategi ini terlihat paling bagus. Tujuh puluh lima trial Optuna per window adalah tujuh puluh lima kesempatan untuk memfitting noise, dikalikan berapa pun jumlah ringkasan yang bersedia Anda pertimbangkan.
Kerusakannya: strategi yang lolos validasi lalu memberikan performa window terburuk saat live, karena window terburuk itulah satu-satunya yang jujur. Aturan kami: metode agregasi dikunci di config sebelum run dimulai, anggaran trial dikunci, dan analis membaca hasil per-window lengkap dengan dispersinya. Strategi yang butuh ringkasan bersahabat untuk lolos berarti tidak lolos.
Kegagalan tiga: holdout yang berhenti menjadi holdout
Sebuah holdout hanya berfungsi satu kali. Kedua kalinya sebuah strategi dievaluasi terhadapnya — setelah parameter digeser sedikit, sinyal diutak-atik, atau sekadar "coba cek dulu" — ia bukan holdout lagi; ia jadi validation set yang lambat. Lima belas hari yang belum tersentuh terdengar sepele untuk dijaga, sampai tekanan iterasi datang dan mengecek ulang terasa tidak berbahaya.
Kerusakannya halus: hasil holdout yang membaik di sepanjang iterasi strategi yang sama. Data out-of-sample yang segar tidak punya alasan untuk memberi hadiah pada iterasi ketiga dibanding iterasi pertama, dan ketika itu terjadi, holdout-nya sudah ditambang. Kami menegakkan aturan sekali-tembak secara mekanis: holdout dievaluasi sekali per pipeline run, hasilnya ditulis ke catatan, dan strategi yang butuh percobaan lagi harus mengulang seluruh rangkaian ujian — termasuk window yang baru. Ia wajib mempertahankan setidaknya 70% dari Sharpe out-of-sample walk-forward, dan tidak ada lemparan dadu kedua.
Tanda yang bertahan melewati ketiganya
Sebelum semua itu, kami menjalankan sensitivity sweep sederhana: geser tiap parameter ±20% dan amati metriknya. Edge yang nyata menurun secara mulus; kebetulan belaka jatuh dari tebing. Ini tes termurah di seluruh pipeline dan ia memveto strategi yang seharusnya melenggang mulus melewati semua hal di atas — karena parameter cliff adalah wujud overfitting sebelum Anda memberinya kesempatan bersembunyi di dalam mesin validasi.
Tidak satu pun dari ini membuat optimasi menjadi aman. Yang dilakukannya adalah membuat mode-mode kegagalan itu bersuara keras — dan itulah hal maksimal yang bisa Anda minta secara jujur dari sebuah proses validasi.
← Semua artikel