Snapshot data pasaran yang dibekukan sahaja tidak cukup untuk menjadikan backtest boleh dipercayai. Ia boleh menghasilkan semula jawapan yang sama sambil menyembunyikan hakikat bahawa vendor telah mengubah input yang menghasilkannya.
Kekalkan snapshot. Kemudian simpan log perubahan yang boleh memberitahu anda perkara yang berubah, bila perubahan itu berlaku, dan sama ada strategi terjejas. Ini paling penting apabila penyelidikan anda menggunakan dagangan yang dibetulkan, data fundamental yang disemak semula, data funding yang dibina semula, atau sejarah vendor yang dikemas kini secara senyap.
Mengapa backtest yang boleh diulang masih boleh mengelirukan anda?
Katakan anda memuat turun bar setiap jam untuk lima tahun pada hari Isnin lalu menjalankan strategi. Pada hari Jumaat, vendor telah membetulkan dagangan yang salah, melaraskan tindakan korporat, atau mengisi jurang. Fail yang anda simpan masih menghasilkan keputusan hari Isnin dengan tepat. Itu boleh diulang. Tetapi jika anda menjalankan semula menggunakan sejarah semasa vendor, anda mungkin mendapat keputusan yang berbeza tanpa sebarang rekod tentang sebabnya.
Masalahnya bukan terhad kepada pembetulan besar. Perubahan pada satu nilai high boleh mencetuskan stop; close yang disemak semula boleh menggerakkan indikator merentasi ambangnya. Dalam alam aset yang luas, perubahan sejarah bagi satu simbol boleh mengubah kedudukannya dan menyingkirkan aset lain daripada portfolio. Sharpe akhir boleh berubah walaupun kod dan konfigurasi strategi serupa sepenuhnya.
Hash fail memberitahu anda bahawa dua fail berbeza. Ia tidak memberitahu anda sama ada pelarasan split mengubah harga selama 40 tahun, vendor membetulkan tiga dagangan, atau parser menukar medan kosong menjadi sifar.
Apakah yang patut dimasukkan dalam log perubahan data pasaran?
Rekodkan perubahan pada unit berguna yang paling kecil, dengan konteks yang cukup untuk memainkan semula penyelidikan yang terjejas. Untuk suapan bar, biasanya maklumat itu merangkumi instrumen, selang, masa peristiwa, nilai lama dan baharu, sumber, serta masa anda mengesan kemas kini. Simpan payload asal jika vendor menyediakannya.
| Rekodkan | Sebab menyimpannya | Contoh |
|---|---|---|
| Versi sumber atau masa pengambilan | Mengenal pasti keadaan vendor yang digunakan | Snapshot diambil pada 2026-11-02 08:15 UTC |
| Medan yang berubah serta nilai lama/baharu | Menunjukkan perkara yang benar-benar berubah | ETHUSDT 1h high: 3,412.10 → 3,418.60 |
| Pengelasan perubahan | Membezakan pembetulan daripada transformasi | Pembetulan dagangan lewat, pelarasan split, pengisian semula |
| Versi pipeline dan skema | Membezakan suntingan sumber daripada pemprosesan anda sendiri | Normalizer v7, skema bar terlaras v3 |
Untuk set data besar, simpan snapshot tidak berubah dan manifes ringkas yang merekodkan checksum, versi sumber, serta masa pengambilan. Tambahkan perbezaan pada peringkat baris bagi partition yang berubah. Ini memberikan jalan tengah yang praktikal: main semula sepenuhnya masih boleh dilakukan tanpa menulis setiap baris yang tidak berubah ke jadual audit kedua.
Bagaimanakah saya mengukur sama ada pembetulan itu penting?
Jangan berhenti selepas mengira bilangan baris yang berubah. Jalankan semula strategi yang terjejas menggunakan data lama dan baharu dengan kod, parameter, yuran, dan andaian pelaksanaan yang sama. Bandingkan keputusan dan perjalanannya hingga ke hasil.
- Kenal pasti instrumen dan masa peristiwa yang terjejas daripada diff.
- Cari ciri, isyarat, pesanan, atau wajaran portfolio yang menggunakan rekod tersebut.
- Mainkan semula tetingkap terkecil yang sah, termasuk sebarang lookback dan keadaan posisi terbuka.
- Bandingkan pesanan, fill, pendedahan, pusing ganti, drawdown, dan prestasi akhir.
Contohnya, pembetulan vendor yang mengubah nilai high 1-minute sebanyak $0.02 mungkin menyentuh sejuta baris tetapi tidak memberi kesan kepada strategi momentum harian. Satu bar yang dibetulkan pada paras stop mungkin memberi kesan yang lebih besar. Ukur kesan terhadap keputusan; bilangan rekod yang berubah ialah proksi yang lemah.
Asingkan dua soalan: “Bolehkah saya menghasilkan semula keputusan daripada data yang saya simpan?” dan “Adakah versi data ini tersedia kepada strategi pada masa itu?” Log perubahan membantu menjawab kedua-duanya, tetapi soalan kedua juga memerlukan rekod ketersediaan point-in-time.
Berapakah kosnya, dan bilakah usaha ini berbaloi?
Penjejakan perubahan menambah keperluan storan, kerja pengingesan, dan keputusan operasi. Vendor mungkin tidak menyediakan versi yang stabil, dan sesetengah suapan sejarah dibina semula secara berkala tanpa notis pembetulan yang jelas. Anda tidak dapat merekodkan perubahan yang tidak pernah anda kesan.
Mulakan dengan data yang semakannya boleh mengubah kesimpulan penyelidikan: bar yang digunakan oleh logik stop, ekuiti terlaras tindakan korporat, data fundamental point-in-time, serta siri funding atau open interest yang dibina semula. Manifes harian bersama checksum partition mungkin memadai untuk set data yang luas dan stabil. Tambahkan diff pada peringkat medan apabila kemas kini kerap berlaku atau keputusan dagangan sensitif terhadap rekod individu.
Pengkritik betul bahawa arkib lengkap dan kekal bagi setiap respons vendor boleh menjadi mahal, namun masih gagal merakam perkara yang diketahui sumber pada masa itu. Penyelesaiannya ialah mengehadkan audit kepada data dan keputusan yang penting, serta mendokumenkan jurangnya. Snapshot membolehkan anda menjalankan semula eksperimen. Log perubahan membolehkan anda menjelaskan sebab jawapan eksperimen itu berubah.
← Semua catatan
