Backtest yang sepenuhnya reproducible bisa jadi kurang tepercaya dibanding backtest yang hasilnya sedikit berubah. Hasil yang berulang membuktikan bahwa Anda bisa mendapatkan jawaban yang sama dua kali; hasil itu tidak menunjukkan apakah jawabannya bergantung pada satu snapshot data yang arbitrer, keunikan library, atau default tersembunyi.
Kedengarannya seperti argumen untuk menolak reproducibility, padahal bukan. Bekukan prosesnya agar Anda bisa menjelaskannya. Lalu, sengaja variasikan asumsi yang seharusnya tidak menentukan hasil. Langkah pertama membuat hasil bisa diaudit; langkah kedua menunjukkan apakah hasil itu bermakna.
Apa yang sebenarnya dibuktikan oleh backtest yang reproducible?
Jika kode, data, konfigurasi, dan random seed yang sama menghasilkan trade dan metrik yang sama, berarti Anda telah mengendalikan satu sumber kebingungan yang penting. “Peningkatan” dari sebuah agen dapat dibandingkan dengan run induknya. Perbaikan bug dapat dipisahkan dari perubahan jadwal biaya. Rekan kerja dapat memeriksa ledger yang sama dan menemukan fill yang sama.
Namun, hasil itu bergantung pada semua hal yang Anda bekukan. Bayangkan strategi kripto yang file historisnya berisi candle 1-minute. Anda menyimpan hash file, mengunci versi kode, dan mendapatkan Sharpe 1.4 setiap kali menjalankan ulang. Jika vendor kemudian mengoreksi beberapa candle, reproducibility yang rapi itu tetap hanya menggambarkan file lama. Itu tidak memberi tahu apakah sinyalnya bertahan setelah riwayat dikoreksi, atau apakah candle tersebut tersedia dalam bentuk itu pada saat kejadian.
Hash itu berguna: hash membuat ketergantungan terlihat. Namun, hash bukan bukti bahwa ketergantungan itu tidak berbahaya.
Bekukan run; uji temuannya
Saya suka memisahkan dua pertanyaan. Bisakah kita merekonstruksi run persis ini? Dan apakah kesimpulan risetnya bertahan saat ada perubahan yang wajar? Pertanyaan pertama memerlukan catatan yang tidak berubah; pertanyaan kedua memerlukan perturbasi terkendali, satu per satu.
| Yang perlu dicatat | Yang perlu divariasikan setelahnya | Hal yang dapat terungkap |
|---|---|---|
| Versi data mentah dan checksum | Revisi vendor atau sumber kedua | Ketergantungan pada nilai yang dikoreksi atau yang spesifik dari vendor |
| Commit kode dan versi package | Implementasi yang setara secara numerik | Sensitivitas terhadap urutan, pembulatan, atau library |
| Biaya, funding, dan asumsi fill | Kisaran biaya yang dapat dipertanggungjawabkan | Apakah edge yang tipis memerlukan eksekusi yang luar biasa menguntungkan |
| Universe dan keanggotaan berdasarkan waktu kejadian | Aturan pasar yang memenuhi syarat sebagai alternatif | Ketergantungan pada keputusan untuk memasukkan atau mengecualikan aset |
Misalnya, strategi futures menunjukkan excess return tahunan 8% dalam replay baseline. Jalankan ulang dengan biaya taker 25% lebih tinggi, waktu funding digeser ke settlement teramati berikutnya, lalu dua kontributor terbesar dihapus secara bergantian. Ketiganya bukan cara untuk meningkatkan model. Ketiganya adalah uji: masing-masing menanyakan apakah detail yang masuk akal menjadi penopang utama hasilnya.
Uji setiap hal secara terpisah. Jika Anda mengubah data, jadwal biaya, dan waktu eksekusi sekaligus, hasil yang lebih buruk tidak banyak membantu diagnosis. Jika suatu uji tidak masuk akal, beri label sebagai skenario stres, bukan sebagai hasil yang paling mungkin.
Jangan samakan kesamaan byte demi byte dengan kebenaran numerik
Sebagian komputasi sensitif terhadap urutan. Penjumlahan floating-point tidak bersifat asosiatif, sehingga menjumlahkan banyak nilai P&L kecil dengan urutan berbeda dapat mengubah beberapa digit terakhir. Reduksi paralel, perangkat keras, dan versi library juga dapat memengaruhi keluaran persisnya. Biasanya hal itu tidak berbahaya; terkadang perubahan numerik kecil membalik ambang batas, mengubah posisi, lalu membuat sisa simulasi menempuh alur yang berbeda.
Itulah sebabnya saya akan menyimpan artefak persisnya sekaligus toleransi untuk perbandingan. Catat ledger trade, bukan hanya Sharpe akhir. Bandingkan keputusan dan arus kas terlebih dahulu, lalu bandingkan metrik dalam batas toleransi yang dinyatakan. Jika selisih satu sen mengubah keputusan untuk mengirim order, periksa batas tersebut secara khusus.
Catatan run yang berguna mencakup identitas data dan kode, konfigurasi, random seed, lingkungan eksekusi, serta keluaran antara yang cukup untuk menelusuri metrik hingga ke fill dan arus kas. Skor akhir saja bukan artefak riset yang reproducible.
Kapan variasi hanyalah noise, dan kapan variasi menjadi temuan
Tidak setiap angka yang berubah adalah masalah besar. Sedikit pergeseran metrik akibat urutan reduksi yang berbeda mungkin tidak mengubah trade. Trade yang berubah di dekat ambang batas patut ditinjau. Strategi yang kehilangan sebagian besar hasilnya saat vendor merevisi sebagian kecil riwayat telah mengungkap sesuatu tentang kerapuhannya sendiri, meskipun run awalnya tetap sepenuhnya reproducible.
Kritik terhadap pemeriksaan robustness benar dalam satu hal: asumsi mudah terus diubah sampai strategi yang disukai terlihat tangguh, atau hasil yang valid ditolak karena gagal dalam skenario ekstrem yang sengaja dibuat. Tetapkan variasi yang masuk akal sebelumnya, laporkan seluruh rangkaiannya, dan bedakan alternatif biasa dari skenario stres. Lalu, simpan baseline agar peneliti lain dapat mereproduksi persis apa yang Anda lihat.
Reproducibility memberi Anda titik awal yang dapat diandalkan. Pertanyaan pentingnya muncul setelah itu: bagian mana dari jawaban yang tetap sama ketika dunia di sekitar run tersebut berubah dengan cara yang wajar untuk diperkirakan?
← Semua artikel
