Posting ini cocok untuk mereka yang baru memulai perdagangan kuantitatif serta mereka yang memiliki beberapa pengalaman dengan bidang ini. Posting ini membahas perangkap umum dari backtesting, serta beberapa yang tidak umum!
Ini juga melihat berbagai jenis mekanisme backtesting serta lanskap perangkat lunak yang menerapkan pendekatan ini. Kemudian kita membahas apakah layak membangun backtester Anda sendiri, bahkan dengan prevalensi alat open source yang tersedia saat ini.
Akhirnya, kami membahas seluk beluk sistem backtesting event-driven, topik yang sering saya bahas di QuantStart di posting sebelumnya.
Sebuah backtest adalah penerapan aturan strategi perdagangan pada seperangkat data harga historis. Artinya, jika kita mendefinisikan seperangkat mekanisme untuk masuk dan keluar ke dalam portofolio aset, dan menerapkan aturan tersebut untuk data harga historis aset tersebut, kita dapat mencoba untuk memahami kinerja ini "strategi perdagangan" yang mungkin telah dicapai di masa lalu.
Pernah dikatakan bahwa
Backtest pada akhirnya membantu kita memutuskan apakah layak untuk berdagang secara langsung seperangkat aturan strategi. Ini memberi kita gambaran tentang bagaimana strategi mungkin telah berkinerja di masa lalu. Pada dasarnya memungkinkan kita untuk menyaring aturan strategi yang buruk sebelum kita mengalokasikan modal nyata.
Hal ini mudah untuk menghasilkan backtest. sayangnya hasil backtest tidak hasil perdagangan hidup. mereka sebaliknya adalah model realitas. model yang biasanya berisi banyak asumsi.
Ada dua jenis utama backtest perangkat lunak -
Ketika merancang perangkat lunak backtesting selalu ada trade-off antara akurasi dan kompleksitas implementasi.
Ada banyak perangkap yang terkait dengan backtesting. semuanya berkaitan dengan fakta bahwa backtesting hanyalah model realitas.
Ada beberapa masalah yang lebih halus dengan backtesting yang tidak sering dibahas, tetapi masih sangat penting untuk dipertimbangkan.
Banyak yang telah ditulis tentang masalah dengan backtesting.
For-Loop Backtester adalah jenis paling mudah dari sistem backtesting dan varian yang paling sering terlihat dalam posting blog kuantum, murni untuk kesederhanaan dan transparansi.
Pada dasarnya sistem For-Loop berulang setiap hari perdagangan (atau bar OHLC), melakukan beberapa perhitungan yang terkait dengan harga aset (s), seperti Moving Average dari penutupan, dan kemudian pergi panjang atau pendek aset tertentu (sering pada harga penutupan yang sama, tetapi kadang-kadang hari berikutnya).
Berikut adalah pseudo-kode untuk algoritma tersebut:
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
Seperti yang Anda lihat, desain sistem semacam itu sangat sederhana. Hal ini membuatnya menarik untuk mendapatkan "tampilan pertama" pada kinerja aturan strategi tertentu.
For-Loop backtesters mudah diimplementasikan dalam hampir semua bahasa pemrograman dan sangat cepat untuk dieksekusi.
Kelemahan utama dengan backtesters For-Loop adalah bahwa mereka cukup tidak realistis. Mereka sering tidak memiliki kemampuan biaya transaksi kecuali ditambahkan secara khusus. Biasanya pesanan diisi segera di pasar dengan harga titik tengah.
Ada penggunaan ulang kode minimal antara sistem backtesting dan sistem perdagangan langsung. Ini berarti bahwa kode sering perlu ditulis dua kali, memperkenalkan kemungkinan lebih banyak bug.
For-Loop backtesters rentan terhadap Look-Ahead Bias, karena bug dengan pengindeksan.
For-Loop backtesters benar-benar harus digunakan semata-mata sebagai mekanisme penyaringan. Anda dapat menggunakannya untuk menghilangkan strategi yang jelas buruk, tetapi Anda harus tetap skeptis terhadap kinerja yang kuat. Penelitian lebih lanjut sering diperlukan. Strategi jarang tampil lebih baik dalam perdagangan langsung daripada di backtest!
Event-Driven Backtesters terletak di ujung lain dari spektrum. Mereka jauh lebih mirip dengan implementasi infrastruktur perdagangan langsung. Dengan demikian, mereka sering lebih realistis dalam perbedaan antara kinerja backtested dan perdagangan langsung.
Sistem semacam itu dijalankan dalam lingkaran
Ketika peristiwa tertentu diidentifikasi, hal itu diarahkan ke modul yang sesuai di infrastruktur, yang menangani peristiwa dan kemudian berpotensi menghasilkan peristiwa baru yang kembali ke antrian.
Pseudo-kode untuk sistem backtesting Event-Driven adalah sebagai berikut:
while event_queue_isnt_empty():
event = get_latest_event_from_queue();
if event.type == "tick":
strategy.calculate_trading_signals(event);
else if event.type == "signal":
portfolio.handle_signal(event);
else if event.type == "order":
portfolio.handle_order(event);
else if event.type == "fill":
portfolio.handle_fill(event)
sleep(600); # Sleep for, say, 10 minsPythonCopy
Seperti yang dapat Anda lihat ada ketergantungan berat pada modul pengelola portofolio. modul tersebut adalah
Ada banyak keuntungan untuk menggunakan backtester Event-Driven:
Sementara keuntungannya jelas, ada juga beberapa kelemahan yang kuat untuk menggunakan sistem yang kompleks:
Dalam bagian ini kita akan mempertimbangkan perangkat lunak (baik open source dan komersial) yang ada untuk sistem For-Loop dan Event-Driven.
Untuk backtesters For-Loop, bahasa pemrograman / perangkat lunak utama yang digunakan termasuk Python (dengan perpustakaan Pandas), R (dan perpustakaan quantmod) dan MatLab. Ada banyak cuplikan kode yang dapat ditemukan di blog quant.
Pasar untuk sistem Event-Driven jauh lebih besar, karena klien/pengguna sering ingin perangkat lunak mampu melakukan backtesting dan perdagangan langsung dalam satu paket.
Penawaran komersial yang mahal termasuk Deltix dan QuantHouse. Mereka sering ditemukan di dana lindung nilai kuantitatif, kantor keluarga dan perusahaan perdagangan perlengkapan.
Sistem backtesting berbasis cloud dan live trading relatif baru. Quantopian adalah contoh dari setup berbasis web yang matang untuk backtesting dan live trading.
Perusahaan-perusahaan institusional juga sering membangun perangkat lunak mereka sendiri. hal ini disebabkan oleh campuran kendala peraturan, hubungan investor / pelaporan dan auditabilitas.
Quant ritel memiliki pilihan antara menggunakan pendekatan
Dalam hal perangkat lunak sumber terbuka, ada banyak perpustakaan yang tersedia. Mereka sebagian besar ditulis dalam Python (untuk alasan yang akan saya jelaskan di bawah ini) dan termasuk Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) dan QSTrader (Backtester QuantStart
Salah satu aspek yang paling penting, bagaimanapun, adalah bahwa tidak peduli perangkat lunak mana yang Anda gunakan pada akhirnya, itu harus dipasangkan dengan sumber data keuangan yang sama kuat.
Sementara perangkat lunak mengurus detail untuk kita, ia menyembunyikan kita dari banyak detail implementasi yang seringkali penting ketika kita ingin memperluas kompleksitas strategi perdagangan kita.
Meskipun memiliki latar belakang sebagai pengembang perangkat lunak kuantitatif, saya tidak tertarik secara pribadi dengan
Kita hanya harus tertarik pada apa yang berhasil. Berikut beberapa pesaing utama:
Python adalah bahasa pemrograman yang sangat mudah dipelajari dan sering kali bahasa pertama yang dihadapi orang ketika mereka memutuskan untuk belajar pemrograman.
Ini memiliki beberapa pustaka kuantum / ilmu data / pembelajaran mesin (ML) yang luar biasa di NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 dan Statsmodels.
Ini sangat bagus untuk membangun sistem backtesting For-Loop dan Event-Driven. Bahkan, ini mungkin salah satu dari satu-satunya bahasa yang langsung memungkinkan penelitian end-to-end, backtesting, penyebaran, perdagangan langsung, pelaporan dan pemantauan.
Mungkin kelemahan terbesarnya adalah bahwa itu cukup lambat untuk dijalankan bila dibandingkan dengan bahasa lain seperti C ++. Namun, pekerjaan sedang dilakukan untuk memperbaiki masalah ini dan dari waktu ke waktu Python menjadi lebih cepat.
R adalah lingkungan pemrograman statistik, bukan
Hal ini banyak digunakan untuk backtesting For-Loop, sering melalui perpustakaan quantmod, tetapi tidak sangat cocok untuk sistem Event-Driven atau perdagangan langsung.
C++ memiliki reputasi untuk sangat cepat. Hampir semua komputasi berkinerja tinggi ilmiah dilakukan baik di Fortran atau C++. Ini adalah keuntungannya utama. Oleh karena itu jika Anda mempertimbangkan perdagangan frekuensi tinggi, atau bekerja pada sistem warisan di organisasi besar, maka C++ kemungkinan akan menjadi suatu keharusan.
Sayangnya sangat menyakitkan untuk melakukan penelitian strategi. Karena diketik secara statis, sangat sulit untuk dengan mudah memuat, membaca dan memformat data dibandingkan dengan Python atau R.
Meskipun relatif tua, baru-baru ini telah dimodernisasi secara substansial dengan pengenalan C ++ 11 / C ++ 14 dan penyempurnaan standar lebih lanjut.
Anda mungkin juga ingin melihat Java, Scala, C #, Julia dan banyak bahasa fungsional. Namun, rekomendasi saya adalah tetap dengan Python, R dan / atau C ++, karena komunitas perdagangan kuantum jauh lebih besar.
Jawaban: Ya!
Ini adalah pengalaman belajar yang hebat untuk menulis sistem backtesting Event-Driven Anda sendiri. pertama, itu memaksa Anda untuk mempertimbangkan semua aspek infrastruktur perdagangan Anda, bukan hanya menghabiskan berjam-jam bermain-main pada strategi tertentu.
Bahkan jika Anda tidak akhirnya menggunakan sistem untuk perdagangan langsung, itu akan memberikan Anda dengan sejumlah besar pertanyaan yang harus Anda tanyakan kepada Anda komersial atau FOSS backtesting vendor.
Misalnya: Bagaimana sistem hidup Anda saat ini berbeda dari simulasi backtest Anda dalam hal:
Sementara sistem Event-Driven tidak cepat atau mudah ditulis, pengalaman akan membayar dividen pendidikan besar di kemudian hari dalam karir perdagangan kuantum Anda.
Bagaimana Anda menulis sistem seperti itu?
Cara terbaik untuk memulai adalah dengan mengunduh Zipline, QSTrader, PyAlgoTrade, PySystemTrade dll dan mencoba membaca melalui dokumentasi dan kode.
Saya juga telah menulis banyak artikel tentang desain backtest Event-Driven, yang dapat Anda temukan di sini, yang memandu Anda melalui pengembangan setiap modul sistem.
Ingatlah bahwa Anda tidak perlu menjadi ahli pada hari # 1. Anda dapat mengambilnya perlahan-lahan, hari demi hari, modul demi modul. Jika Anda membutuhkan bantuan, Anda selalu dapat menghubungi saya atau blogger kuant lainnya yang bersedia. Lihat akhir artikel untuk email kontak saya.
Saya sekarang akan membahas modul yang sering ditemukan dalam banyak sistem backtesting Event-Driven. Meskipun bukan daftar yang lengkap, ini harus memberi Anda
Ini adalah tempat semua data harga historis disimpan, bersama dengan riwayat perdagangan Anda, sekali hidup.
Sebagai gantinya, kami menggunakan
Idealnya, kita ingin mendapatkan dan menyimpan data tingkat tik karena itu memberi kita gambaran tentang spread perdagangan.
Kita harus selalu sadar menangani tindakan perusahaan (seperti pembagian saham dan dividen), bias kelangsungan hidup (penghapusan daftar saham) serta melacak perbedaan zona waktu antara berbagai bursa.
Individu/retail quants dapat bersaing di sini karena banyak teknologi basis data berkualitas produksi yang matang, bebas dan open source.
Masih ada banyak pasar dan strategi yang terlalu kecil untuk dana besar yang tertarik.
Modul strategi perdagangan dalam sistem Event-Driven umumnya menjalankan beberapa jenis mekanisme prediktif atau penyaringan pada data pasar baru.
Modul ini TIDAK dirancang untuk menghasilkan kuantitas, yang dilakukan melalui modul ukuran posisi.
95% dari diskusi quant blog biasanya berkisar pada strategi trading. Saya pribadi percaya seharusnya lebih seperti 20%. Ini karena saya pikir jauh lebih mudah untuk meningkatkan pengembalian yang diharapkan dengan mengurangi biaya melalui manajemen risiko yang tepat dan ukuran posisi, daripada mengejar strategi dengan
"Jantung" dari backtester Event-Driven adalah sistem Portfolio & Order Management.
Tujuan dari sistem ini adalah untuk pergi dari portofolio saat ini ke portofolio yang diinginkan, sambil meminimalkan risiko dan mengurangi biaya transaksi.
Modul ini menghubungkan kemampuan strategi, risiko, ukuran posisi dan eksekusi order dari sistem.
Keuntungan utama menggunakan sistem yang kompleks adalah bahwa hal itu memungkinkan berbagai instrumen keuangan untuk ditangani di bawah satu portofolio. Ini diperlukan untuk portofolio gaya institusional dengan lindung nilai. Kompleksitas seperti itu sangat rumit untuk kode dalam sistem backtesting For-Loop.
Memisahkan manajemen risiko ke dalam modulnya sendiri dapat sangat menguntungkan. modul dapat memodifikasi, menambahkan atau memveto perintah yang dikirim dari portofolio.
Secara khusus, modul risiko dapat menambahkan lindung nilai untuk menjaga netralitas pasar. Ini dapat mengurangi ukuran pesanan karena eksposur sektor atau batas ADV. Ini dapat sepenuhnya memveto perdagangan jika spread terlalu luas, atau biaya terlalu besar relatif terhadap ukuran perdagangan.
Modul ukuran posisi yang terpisah dapat mengimplementasikan perkiraan volatilitas dan aturan ukuran posisi seperti leverage Kelly.
Topik-topik seperti itu tidak terwakili dengan baik di blogosfer kuantum. Namun, ini mungkin perbedaan terbesar antara bagaimana institusi dan beberapa pedagang ritel berpikir tentang perdagangan mereka. Mungkin cara termudah untuk mendapatkan pengembalian yang lebih baik adalah dengan mulai menerapkan manajemen risiko dan ukuran posisi dengan cara ini.
Dalam kehidupan nyata kita tidak pernah dijamin untuk mendapatkan isian pasar di titik tengah!
Kita harus mempertimbangkan masalah transaksi seperti kapasitas, spread, biaya, slippage, dampak pasar dan masalah eksekusi algoritmik lainnya, jika tidak, pengembalian backtesting kita kemungkinan akan sangat berlebihan.
Pendekatan modular dari sistem Event-Driven memungkinkan kita untuk dengan mudah beralih keluar BacktestExecutionHandler dengan LiveExecutionHandler dan menyebarkan ke server jarak jauh.
Kita juga dapat dengan mudah menambahkan beberapa broker menggunakan konsep OOP
Salah satu masalah yang perlu diketahui adalah
Kanta ritel dapat dan harus meminjam teknik pelaporan canggih yang digunakan oleh kanta institusional. Alat-alat tersebut termasuk live
Perbaikan bertahap yang konsisten harus dilakukan pada infrastruktur ini. Ini benar-benar dapat meningkatkan pengembalian dalam jangka panjang, hanya dengan menghilangkan bug dan meningkatkan masalah seperti latensi perdagangan. Jangan hanya menjadi terobsesi pada peningkatan strategi terbesar dunia (WGS).
WGS pada akhirnya akan terkikis karena
Optimalisasi infrastruktur mungkin lebih "membosankan" daripada pengembangan strategi tetapi menjadi jauh lebih tidak membosankan ketika pengembalian Anda meningkat!
Penyebaran ke server jarak jauh, bersama dengan pemantauan ekstensif dari sistem jarak jauh ini, sangat penting untuk sistem tingkat institusional.
Sebuah sistem yang kuat harus digunakan dari jarak jauh di
Masalah utama ketika mempertimbangkan penyebaran jarak jauh termasuk; pemantauan perangkat keras, seperti CPU, RAM / swap, disk dan jaringan I / O, ketersediaan tinggi dan redundansi sistem, yang dipikirkan dengan baik melalui cadangan DAN rencana pemulihan, log ekstensif dari semua aspek sistem serta integrasi terus menerus, pengujian unit dan kontrol versi.
Ingat Hukum Murphy - Jika itu bisa gagal itu akan gagal.
Ada banyak vendor yang menawarkan penyebaran cloud yang relatif mudah, termasuk Amazon Web Services, Microsoft Azure, Google dan Rackspace.
Sayangnya tidak ada "perbaikan cepat" dalam perdagangan kuantitatif. Ini melibatkan banyak kerja keras dan belajar untuk menjadi sukses.
Mungkin batu tersandung utama bagi pemula (dan beberapa kuantitas menengah!) adalah bahwa mereka terlalu berkonsentrasi pada
Hal ini juga layak menginvestasikan banyak waktu dalam infrastruktur perdagangan Anda. Luangkan waktu pada masalah seperti penyebaran dan pemantauan. Selalu mencoba dan mengurangi biaya transaksi, karena profitabilitas adalah tentang mengurangi biaya seperti itu tentang mendapatkan pendapatan perdagangan.
Saya merekomendasikan menulis sistem backtesting Anda sendiri hanya untuk belajar. Anda dapat menggunakannya dan terus meningkatkannya atau Anda dapat menemukan vendor dan kemudian bertanya kepada mereka semua pertanyaan yang telah Anda temukan ketika Anda membangun Anda sendiri.
Akhirnya, selalu membaca, belajar dan meningkatkan. Ada banyak buku teks, jurnal perdagangan, jurnal akademik, blog kuantitatif, forum dan majalah yang membahas semua aspek perdagangan. Untuk ide strategi yang lebih maju saya merekomendasikan SSRN dan arXiv - Keuangan Kuantitatif.