Snapshot data pasar yang dibekukan saja belum cukup untuk membuat backtest tepercaya. Snapshot itu dapat menghasilkan jawaban yang sama persis setiap kali, sekaligus menyembunyikan bahwa vendor mengubah input yang menghasilkan jawaban tersebut.
Simpan snapshot-nya. Lalu buat log perubahan yang mencatat apa yang berubah, kapan perubahan terjadi, dan apakah strategi terpengaruh. Ini paling penting ketika riset Anda menggunakan transaksi yang dikoreksi, data fundamental yang direvisi, funding yang direkonstruksi, atau riwayat vendor yang diam-diam diperbarui.
Mengapa backtest yang dapat direproduksi tetap bisa menyesatkan?
Misalkan Anda mengunduh data bar per jam untuk lima tahun pada hari Senin dan menjalankan strategi. Pada hari Jumat, vendor telah memperbaiki transaksi yang keliru, menyesuaikan aksi korporasi, atau mengisi data yang hilang. File yang Anda simpan tetap menghasilkan hasil hari Senin secara persis. Itu berarti hasilnya dapat direproduksi. Namun, jika Anda menjalankan ulang strategi dengan riwayat vendor terkini, hasilnya mungkin berbeda dan Anda tidak punya catatan alasannya.
Masalahnya tidak terbatas pada koreksi besar. Perubahan pada satu nilai high saja dapat memicu stop; revisi pada nilai close dapat menggeser indikator melewati ambangnya. Dalam semesta aset yang luas, perubahan riwayat satu simbol dapat mengubah peringkatnya dan mengeluarkan aset lain dari portofolio. Sharpe akhir dapat berubah meskipun kode dan konfigurasi strategi identik.
Hash file memberi tahu Anda bahwa dua file berbeda. Namun, hash tidak memberi tahu apakah penyesuaian stock split mengubah harga selama 40 tahun, vendor mengoreksi tiga transaksi, atau parser mengubah kolom kosong menjadi nol.
Apa saja yang perlu dicatat dalam log perubahan data pasar?
Catat perubahan pada unit terkecil yang berguna, dengan konteks yang cukup untuk menjalankan ulang riset yang terdampak. Untuk feed bar, biasanya ini mencakup instrumen, interval, waktu kejadian, nilai sebelumnya dan nilai baru, sumber, serta waktu Anda mengamati pembaruan. Simpan payload asli jika vendor menyediakannya.
| Catatan | Alasan menyimpannya | Contoh |
|---|---|---|
| Versi sumber atau waktu pengambilan | Mengidentifikasi kondisi vendor yang digunakan | Snapshot diambil pada 2026-11-02 08:15 UTC |
| Kolom yang berubah serta nilai lama/baru | Menunjukkan apa yang benar-benar berubah | ETHUSDT 1h high: 3,412.10 → 3,418.60 |
| Klasifikasi perubahan | Membedakan perbaikan dari transformasi | Koreksi transaksi terlambat, penyesuaian stock split, backfill |
| Versi pipeline dan skema | Membedakan perubahan sumber dari pemrosesan Anda sendiri | Normalizer v7, skema adjusted-bar v3 |
Untuk dataset besar, simpan snapshot yang immutable beserta manifest ringkas berisi checksum, versi sumber, dan waktu pengambilan. Tambahkan diff per baris untuk partisi yang berubah. Cara ini memberi jalan tengah yang praktis: replay penuh tetap bisa dilakukan tanpa menulis setiap baris yang tidak berubah ke tabel audit kedua.
Bagaimana cara mengukur dampak suatu koreksi?
Jangan berhenti setelah menghitung jumlah baris yang berubah. Jalankan ulang strategi yang terdampak dengan data lama dan baru, menggunakan kode, parameter, biaya, dan asumsi eksekusi yang sama. Bandingkan keputusan dan proses hingga hasil akhir.
- Identifikasi instrumen dan waktu kejadian yang terdampak dari diff.
- Cari tahu fitur, sinyal, order, atau bobot portofolio mana yang menggunakan catatan tersebut.
- Jalankan ulang rentang terkecil yang valid, termasuk lookback dan status posisi terbuka.
- Bandingkan order, fill, eksposur, turnover, drawdown, dan kinerja akhir.
Contohnya, koreksi vendor yang mengubah nilai high 1 menit sebesar $0.02 mungkin menyentuh sejuta baris, tetapi tidak berdampak pada strategi momentum harian. Satu bar yang dikoreksi pada level stop bisa jauh lebih berpengaruh. Ukur dampaknya terhadap keputusan; jumlah catatan yang berubah bukanlah tolok ukur yang baik.
Pisahkan dua pertanyaan: “Bisakah saya mereproduksi hasil dari data yang saya simpan?” dan “Apakah versi data ini akan tersedia bagi strategi saat itu?” Log perubahan membantu menjawab keduanya, tetapi pertanyaan kedua juga memerlukan catatan ketersediaan point-in-time.
Berapa biayanya, dan kapan upaya ini sepadan?
Pelacakan perubahan menambah kebutuhan penyimpanan, pekerjaan ingestion, dan keputusan operasional. Vendor mungkin tidak menyediakan versi yang stabil, dan sebagian feed historis dibangun ulang secara berkala tanpa pemberitahuan koreksi yang jelas. Anda tidak bisa mencatat perubahan yang tidak pernah Anda amati.
Mulailah dari data yang revisinya dapat mengubah kesimpulan riset: bar yang digunakan oleh logika stop, ekuitas yang disesuaikan terhadap aksi korporasi, data fundamental point-in-time, serta rangkaian funding atau open interest yang direkonstruksi. Manifest harian beserta checksum partisi mungkin cukup untuk dataset luas yang stabil. Tambahkan diff tingkat kolom jika pembaruan sering terjadi atau keputusan trading sensitif terhadap catatan individual.
Para kritikus benar bahwa arsip lengkap dan permanen dari setiap respons vendor bisa menjadi mahal, tetapi tetap gagal menangkap apa yang diketahui sumber pada saat itu. Solusinya adalah membatasi audit pada data dan keputusan yang penting, lalu mendokumentasikan celahnya. Snapshot memungkinkan Anda menjalankan ulang eksperimen. Log perubahan memungkinkan Anda menjelaskan mengapa hasil eksperimen itu berubah.
← Semua artikel
