Haruskah Anda Membina Backtester Anda Sendiri?

Mengenai Pos Ini

Pos ini sesuai untuk mereka yang baru memulakan perdagangan kuantitatif serta mereka yang mempunyai pengalaman dengan kawasan ini.

Ia juga melihat pelbagai jenis mekanisme backtesting serta landskap perisian yang melaksanakan pendekatan ini. Kemudian kita membincangkan sama ada ia bernilai membina backtester anda sendiri, walaupun dengan kelaziman alat sumber terbuka yang tersedia hari ini.

Akhirnya, kita membincangkan ins dan outs sistem backtesting yang didorong oleh peristiwa, topik yang saya telah membincangkan dengan kerap di QuantStart dalam catatan sebelumnya.

Apakah Ujian Belakang?

Ujian belakang adalah penerapan peraturan strategi perdagangan kepada satu set data harga sejarah. Iaitu, jika kita menentukan satu set mekanisme untuk masuk dan keluar ke dalam portfolio aset, dan menerapkan peraturan tersebut kepada data harga sejarah aset tersebut, kita boleh cuba memahami prestasi ini "strategi perdagangan" yang mungkin telah dicapai pada masa lalu.

Ia pernah dikatakan bahawa Semua model adalah salah, tetapi sesetengahnya berguna. Begitu juga dengan backtest. Jadi apa tujuannya?

Backtest akhirnya membantu kita memutuskan sama ada ia bernilai hidup-dagang satu set peraturan strategi. Ia memberikan kita idea bagaimana strategi mungkin telah dilakukan pada masa lalu. Pada dasarnya ia membolehkan kita menapis peraturan strategi yang buruk sebelum kita memperuntukkan mana-mana modal sebenar.

Ia adalah mudah untuk menjana backtests. Malangnya hasil backtest tidak hasil dagangan hidup. Mereka adalah model realiti. Model yang biasanya mengandungi banyak andaian.

Terdapat dua jenis utama backtest perisian - sistem for-loop dan sistem event-driven.

Apabila merancang perisian backtesting, selalu ada pertukaran antara ketepatan dan kerumitan pelaksanaan.

Ranting Ujian Belakang

Terdapat banyak perangkap yang berkaitan dengan backtesting. Kesemuanya berkaitan dengan fakta bahawa backtesting hanyalah model realiti.

• Ujian dalam sampel - Ini berlaku apabila anda menggunakan data yang sama untuk melatih model dagangan anda serta untuk menguji ia. Ia hampir selalu membesarkan prestasi strategi di luar yang akan dilihat dalam perdagangan langsung. Ini kerana ia tidak disahkan pada data yang tidak dilihat, yang mungkin berbeza dengan ketara dari data latihan. Pada dasarnya, ini adalah satu bentuk overfit.
• Bias Survival - Untuk indeks pasaran saham seperti S & P500, proses penyenaraian dan penyingkiran berkala berlaku, mengubah komposisi dari masa ke masa. Dengan gagal mengambil kira komposisi yang berubah ini di atas backtest, strategi perdagangan secara automatik memilih pemenang kerana mengabaikan semua syarikat yang jatuh dari indeks kerana permodalan pasaran yang rendah. Oleh itu, selalu perlu menggunakan data bebas bias survival ketika melakukan backtest jangka panjang.
• Look-Ahead Bias - Data masa depan boleh menyelinap masuk ke backtest dengan cara yang sangat halus. Pertimbangkan untuk mengira nisbah regresi linear dalam jangka masa tertentu. Jika nisbah ini kemudian digunakan dalam sampel yang sama, maka kita secara tersirat telah membawa data masa depan dan dengan itu mungkin akan meningkatkan prestasi.
• Perubahan Rezim Pasaran - Ini berkaitan dengan fakta bahawa pasaran saham parameter tidak statis. iaitu, proses yang mendasari menghasilkan pergerakan saham tidak perlu mempunyai parameter yang kekal tetap dalam masa. Ini menjadikan sukar untuk menggeneralisasi model parameter (yang mana banyak strategi perdagangan adalah contoh) dan dengan itu prestasi mungkin lebih tinggi dalam backtest daripada dalam perdagangan langsung.
• Kos urus niaga - Banyak ujian balik For-Loop tidak mengambil kira kos urus niaga asas, seperti yuran atau komisen. Ini terutama berlaku dalam makalah akademik di mana ujian balik dilakukan secara besar-besaran tanpa kos urus niaga. Malangnya, terlalu mudah untuk mencari strategi yang sangat menguntungkan tanpa kos urus niaga, tetapi membuat kerugian yang besar apabila dikenakan pasaran sebenar. Kos biasa termasuk penyebaran, kesan pasaran dan slippage. Semua ini harus diperhitungkan dalam ujian balik yang realistik.

Terdapat beberapa isu yang lebih halus dengan backtesting yang tidak dibincangkan selalunya, tetapi masih sangat penting untuk dipertimbangkan.

• Data OHLC - Data OHLC, iaitu jenis data harian yang diambil dari laman web percuma seperti Yahoo Finance, sering merupakan penggabungan pelbagai suapan pertukaran. Oleh itu, tidak mungkin beberapa nilai yang lebih melampau dilihat (termasuk harga tinggi dan rendah hari itu) mungkin akan diperoleh oleh sistem perdagangan langsung.
• Kesulitan Kapasiti - Apabila backtesting adalah mudah untuk menggunakan periuk wang yang tidak terhingga. Walau bagaimanapun, dalam realiti, modal, serta margin, sangat terhad. Adalah perlu juga untuk memikirkan had Volume Harian Purata (ADV), terutamanya untuk stok modal kecil di mana mungkin perdagangan kita benar-benar dapat menggerakkan pasaran. Kesan kesan pasaran seperti itu perlu diambil kira untuk tujuan pengurusan risiko.
• Pilihan penanda aras - Adakah pilihan penanda aras yang strategi backtested diukur adalah satu yang baik? Sebagai contoh jika anda berdagang niaga hadapan komoditi dan neutral kepada indeks ekuiti S & P500 AS, adakah benar-benar masuk akal untuk menggunakan S & P500 sebagai penanda aras anda? Adakah bakul dana perdagangan komoditi lain lebih masuk akal?
• Kekuatan - Dengan membezakan masa permulaan strategi anda dalam backtest anda, adakah hasilnya berubah secara dramatik? Ia tidak perlu menjadi masalah untuk strategi jangka panjang sama ada backtest dimulakan pada hari Isnin atau Khamis. Walau bagaimanapun, jika ia sensitif kepada syarat awal bagaimana anda boleh meramalkan prestasi masa depan dengan boleh dipercayai semasa perdagangan langsung?
• Overfitting / Bias-Variance Tradeoff - Kami telah membincangkan ini sedikit di atas dalam titik Ujian In-Sample. Walau bagaimanapun, overfitting adalah masalah yang lebih luas untuk semua kaedah pembelajaran mesin (dipantau). Satu-satunya cara sebenar untuk menyelesaikan masalah ini adalah melalui penggunaan teknik pengesahan silang yang berhati-hati.
• Toleransi Psikologi - Psikologi sering diabaikan dalam kewangan kuantiti kerana (kononnya) ia dihapuskan dengan membuat sistem algoritma. Walau bagaimanapun, ia selalu merayap kerana kuant mempunyai kecenderungan untuk tinker atau override sistem sekali digunakan secara langsung. Di samping itu, apa yang mungkin kelihatan dapat diterima dalam backtest, mungkin perut berputar dalam perdagangan langsung. Jika kurva ekuiti yang diuji semula menunjukkan penurunan 50% pada satu ketika dalam sejarah dagangan, adakah anda juga boleh menunggang ini dalam senario perdagangan langsung?

Banyak telah ditulis mengenai masalah dengan backtesting. Tucker Balch dan Ernie Chan kedua-duanya membincangkan isu-isu ini secara panjang lebar.

Sistem Ujian Balik For-Loop

For-Loop Backtester adalah jenis sistem backtesting yang paling mudah dan varian yang paling sering dilihat dalam catatan blog kuant, semata-mata untuk kesederhanaan dan ketelusan.

Pada dasarnya sistem For-Loop berulang setiap hari dagangan (atau bar OHLC), melakukan beberapa pengiraan yang berkaitan dengan harga aset (s), seperti Purata Bergerak penutupan, dan kemudian pergi panjang atau pendek aset tertentu (sering pada harga penutupan yang sama, tetapi kadang-kadang sehari selepas).

Berikut adalah kod palsu untuk algoritma sedemikian:

for each trading bar:
    do_something_with_prices();
    buy_sell_or_hold_something();
    next_bar();PythonCopy

Seperti yang anda lihat reka bentuk sistem sedemikian adalah sangat mudah. ini menjadikannya menarik untuk mendapatkan perhatian pertama pada prestasi peraturan strategi tertentu.

Kelebihan

For-Loop backtesters adalah mudah dilaksanakan dalam hampir mana-mana bahasa pengaturcaraan dan sangat cepat untuk dilaksanakan.

Kelemahan

Kelemahan utama dengan backtesters For-Loop adalah bahawa mereka agak tidak realistik. Mereka sering tidak mempunyai keupayaan kos transaksi kecuali ditambahkan secara khusus. Biasanya pesanan dipenuhi dengan harga titik tengah. Oleh itu, sering tidak ada perakaunan untuk penyebaran.

Terdapat penggunaan semula kod yang minimum antara sistem backtesting dan sistem perdagangan langsung. Ini bermaksud bahawa kod sering perlu ditulis dua kali, memperkenalkan kemungkinan lebih banyak bug.

For-Loop backtesters cenderung kepada Look-Ahead Bias, kerana bug dengan pengindeksan.

For-Loop backtesters benar-benar harus digunakan semata-mata sebagai mekanisme penapisan. Anda boleh menggunakannya untuk menghapuskan strategi yang jelas buruk, tetapi anda harus tetap skeptis terhadap prestasi yang kuat. Penyelidikan lanjut sering diperlukan. Strategi jarang melakukan lebih baik dalam perdagangan langsung daripada yang mereka lakukan dalam backtests!

Sistem Backtest yang Dikendalikan Acara

Event-Driven Backtesters terletak di hujung spektrum yang lain. Mereka jauh lebih mirip dengan pelaksanaan infrastruktur perdagangan langsung. Oleh itu, mereka sering lebih realistik dalam perbezaan antara prestasi perdagangan yang diuji dan hidup.

Sistem sedemikian dijalankan dalam gelung while yang besar yang terus mencari peristiwa jenis yang berbeza dalam antrian peristiwa.

• Tick Peristiwa - menandakan kedatangan data pasaran baru
• Peristiwa Isyarat - Penjanaan isyarat perdagangan baru
• Peristiwa Perintah - Perintah bersedia untuk dihantar kepada broker pasaran
• Isi Peristiwa - Isi maklumat dari broker pasaran

Apabila peristiwa tertentu dikenal pasti, ia diarahkan ke modul yang sesuai di infrastruktur, yang mengendalikan peristiwa dan kemudian berpotensi menjana peristiwa baru yang kembali ke barisan.

Kod palsu untuk sistem backtesting Event-Driven adalah seperti 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 anda lihat terdapat ketergantungan yang besar pada modul pengendali portfolio. modul sedemikian adalah hati sistem backtesting Event-Driven seperti yang akan kita lihat di bawah.

Kelebihan

Terdapat banyak kelebihan untuk menggunakan backtester Event-Driven:

• Penghapusan Bias Look-Ahead - Oleh kerana reka bentuk menghantar mesej, sistem yang didorong oleh peristiwa biasanya bebas dari Bias Look-Ahead, sekurang-kurangnya pada tahap perdagangan.
• Penggunaan semula kod - Untuk perdagangan langsung, hanya perlu mengganti modul pengendali data dan pengendali pelaksanaan. Semua kod strategi, pengurusan risiko / kedudukan dan pengukuran prestasi adalah sama. Ini bermakna biasanya terdapat lebih sedikit bug untuk diperbaiki.
• Tahap portfolio - Dengan sistem yang didorong oleh peristiwa, lebih mudah untuk berfikir di peringkat portfolio.
• Pengurusan Risiko/Posisi yang Betul - Boleh dengan mudah memodularkan pengurusan risiko dan kedudukan. Boleh memperkenalkan leverage dan metodologi seperti Kriteria Kelly dengan mudah. Juga boleh dengan mudah merangkumi amaran pendedahan sektor, had ADV, had turun naik dan amaran illiquidity.
• Pengerahan / Pemantauan Jauh - Sifat modular kod memudahkan untuk digunakan di awan atau untuk menempatkan perisian berhampiran pertukaran pada sistem maya.

Kelemahan

Walaupun kelebihan adalah jelas, terdapat juga beberapa kelemahan yang kuat untuk menggunakan sistem yang rumit:

• Tricky to Code - Membina sistem Event-Driven yang diuji sepenuhnya mungkin akan mengambil masa berminggu-minggu atau bulan kerja sepenuh masa.
• Menghendaki Orientasi Objek - Reka bentuk modular memerlukan penggunaan prinsip pengaturcaraan berorientasikan objek (OOP), dan dengan itu bahasa yang dapat menyokong OOP dengan mudah.
• Kejuruteraan Perisian - Lebih cenderung memerlukan kepakaran dan keupayaan kejuruteraan perisian yang baik seperti logging, ujian unit, kawalan versi dan integrasi berterusan.
• Pelaksanaan perlahan - Sifat menghantar mesej kod menjadikannya jauh lebih perlahan untuk dilaksanakan berbanding pendekatan For-Loop vektor.

Landskap Perisian

Dalam bahagian ini kita akan mempertimbangkan perisian (baik sumber terbuka dan komersial) yang wujud untuk kedua-dua sistem For-Loop dan Event-Driven.

Untuk para backtester For-Loop, bahasa / perisian pengaturcaraan utama yang digunakan termasuk Python (dengan perpustakaan Pandas), R (dan perpustakaan quantmod) dan MatLab. Terdapat banyak cuplikan kod yang boleh didapati di blog kuant. Senarai besar blog tersebut boleh didapati di Quantocracy.

Pasaran untuk sistem Event-Driven jauh lebih besar, kerana pelanggan/pengguna sering mahu perisian itu mampu melakukan backtesting dan perdagangan langsung dalam satu pakej.

Penawaran komersial yang mahal termasuk Deltix dan QuantHouse. Mereka sering dijumpai di dana lindung nilai kuant, pejabat keluarga dan firma perdagangan alat peraga.

Sistem backtesting berasaskan awan dan sistem perdagangan langsung agak baru. Quantopian adalah contoh persediaan berasaskan web yang matang untuk kedua-dua backtesting dan perdagangan langsung.

Kuant institusi sering juga membina perisian sendiri di dalam rumah.Ini disebabkan oleh gabungan kekangan peraturan, hubungan pelabur / pelaporan dan audit.

Quant runcit mempunyai pilihan antara menggunakan pendekatan cloud + data Quantopian atau rolling sendiri menggunakan vendor awan seperti Amazon Web Services, Rackspace Cloud atau Microsoft Azure, bersama dengan vendor data yang sesuai seperti DTN IQFeed atau QuantQuote.

Dari segi perisian sumber terbuka, terdapat banyak perpustakaan yang tersedia. Mereka kebanyakannya ditulis dalam Python (untuk sebab-sebab yang akan saya jelaskan di bawah) dan termasuk Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) dan QSTrader (Backtester QuantStart sendiri).

Salah satu aspek yang paling penting, bagaimanapun, adalah bahawa tidak kira mana perisian yang anda gunakan akhirnya, ia mesti dipasangkan dengan sumber data kewangan yang sama kukuh.

Bahasa Pengaturcaraan

Walaupun perisian menguruskan perincian untuk kita, ia menyembunyikan kita dari banyak butiran pelaksanaan yang sering penting apabila kita ingin mengembangkan kerumitan strategi perdagangan kita.

Walaupun mempunyai latar belakang sebagai pembangun perisian kuantitatif saya tidak berminat secara peribadi dalam perang bahasa.

Kita hanya perlu berminat dengan apa yang berfungsi. Berikut adalah beberapa pesaing utama:

Python

Python adalah bahasa pengaturcaraan yang sangat mudah dipelajari dan sering bahasa pertama yang orang bersentuhan dengan apabila mereka memutuskan untuk belajar pengaturcaraan. Ia mempunyai perpustakaan alat standard yang boleh membaca dalam hampir semua bentuk data yang dapat dibayangkan dan bercakap dengan mana-mana perkhidmatan yang lain dengan sangat mudah.

Ia mempunyai beberapa perpustakaan kuantum / sains data / pembelajaran mesin (ML) yang luar biasa dalam NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 dan Statsmodels.

Ia sangat baik untuk membina kedua-dua sistem backtesting For-Loop dan Event-Driven. Malah, ia mungkin salah satu daripada bahasa yang hanya membenarkan penyelidikan hujung ke hujung, backtesting, penggunaan, perdagangan langsung, pelaporan dan pemantauan.

Mungkin kelemahan terbesarnya adalah bahawa ia agak lambat untuk dijalankan jika dibandingkan dengan bahasa lain seperti C ++. Walau bagaimanapun, kerja sedang dijalankan untuk memperbaiki masalah ini dan dari masa ke masa Python menjadi lebih cepat.

R

R adalah persekitaran pengaturcaraan statistik, dan bukannya bahasa pengaturcaraan kelas pertama (walaupun ada yang berpendapat sebaliknya!). Ia direka terutamanya untuk melakukan analisis statistik lanjutan untuk siri masa, statistik klasik / frekuensi, statistik Bayesian, pembelajaran mesin dan analisis data eksplorasi.

Ia digunakan secara meluas untuk pengujian belakang For-Loop, sering melalui perpustakaan quantmod, tetapi tidak begitu sesuai untuk sistem yang didorong oleh acara atau perdagangan langsung.

C++

C++ mempunyai reputasi untuk menjadi sangat pantas. Hampir semua pengkomputeran berprestasi tinggi saintifik dijalankan sama ada dalam Fortran atau C ++. Ini adalah kelebihan utamanya. Oleh itu jika anda mempertimbangkan perdagangan frekuensi tinggi, atau bekerja pada sistem warisan dalam organisasi besar, maka C ++ mungkin menjadi keperluan.

Malangnya, ia menyakitkan untuk menjalankan penyelidikan strategi. Oleh kerana diketik secara statik, ia agak rumit untuk memuatkan, membaca dan memformat data dengan mudah berbanding Python atau R.

Walaupun usianya yang relatif, ia baru-baru ini telah dimodenkan secara besar-besaran dengan pengenalan C ++ 11 / C ++ 14 dan penyempurnaan piawaian lanjut.

Orang lain?

Anda juga mungkin ingin melihat Java, Scala, C #, Julia dan banyak bahasa fungsional. Walau bagaimanapun, cadangan saya adalah untuk berpegang pada Python, R dan / atau C ++, kerana komuniti perdagangan kuantum jauh lebih besar.

Haruskah Anda Menulis Backtest Anda Sendiri (Dorong Kejadian)?

Jawapan: Ya!

Ia adalah pengalaman pembelajaran yang hebat untuk menulis sistem backtesting Event-Driven anda sendiri. pertama, ia memaksa anda untuk mempertimbangkan semua aspek infrastruktur perdagangan anda, bukan hanya menghabiskan jam bermain-main pada strategi tertentu.

Walaupun anda tidak berakhir menggunakan sistem untuk perdagangan langsung, ia akan menyediakan anda dengan sebilangan besar soalan yang anda harus bertanya kepada vendor backtesting komersial atau FOSS anda.

Sebagai contoh: Bagaimana sistem hidup semasa anda berbeza dari simulasi backtest anda dari segi:

• Pelaksanaan algoritma dan arahan laluan?
• Spread, bayaran, slippage dan kesan pasaran?
• Pengurusan risiko dan saiz kedudukan?

Walaupun sistem Event-Driven tidak cepat atau mudah untuk menulis, pengalaman akan membayar dividen pendidikan yang besar kemudian dalam kerjaya perdagangan kuant anda.

Reka Bentuk Backtest yang Dikendalikan Acara 101

Bagaimana anda menulis sistem seperti itu?

Cara terbaik untuk memulakan adalah dengan memuat turun Zipline, QSTrader, PyAlgoTrade, PySystemTrade dan lain-lain dan cuba membaca melalui dokumentasi dan kod. Mereka semua ditulis dalam Python (kerana sebab-sebab yang saya jelaskan di atas) dan syukurlah Python sangat seperti membaca kod palsu. iaitu, ia sangat mudah diikuti.

Saya juga telah menulis banyak artikel mengenai reka bentuk backtest Event-Driven, yang boleh anda dapati di sini, yang membimbing anda melalui pembangunan setiap modul sistem.

Ingat bahawa anda tidak perlu menjadi pakar pada hari # 1. Anda boleh mengambilnya perlahan, hari demi hari, modul demi modul. Jika anda memerlukan bantuan, anda sentiasa boleh menghubungi saya atau blogger kuant yang lain. Lihat akhir artikel untuk e-mel kenalan saya.

Saya akan membincangkan modul yang sering terdapat dalam banyak sistem backtesting yang didorong oleh peristiwa. Walaupun bukan senarai yang lengkap, ia harus memberi anda rasa bagaimana sistem tersebut direka.

Pangkalan Data Master Sekuriti

Ini adalah di mana semua data harga sejarah disimpan, bersama-sama dengan sejarah dagangan anda, sekali hidup.

Sebaliknya, kami menggunakan pangkalan data atau sistem fail kelas pertama, seperti PostgreSQL, MySQL, SQL Server atau HDF5.

Idealnya, kita mahu mendapatkan dan menyimpan data tahap tik kerana ia memberi kita idea mengenai spread perdagangan.

Kita harus sentiasa sedar tentang mengendalikan tindakan korporat (seperti pembahagian saham dan dividen), bias survival (penghapusan senarai saham) serta mengesan perbezaan zon waktu antara pelbagai bursa.

Individu / keluaran runcit boleh bersaing di sini kerana banyak teknologi pangkalan data berkualiti pengeluaran adalah matang, percuma dan sumber terbuka.

Masih ada banyak pasaran dan strategi yang terlalu kecil untuk dana besar yang berminat. Ini adalah tanah subur untuk peniaga kuantiti runcit.

Strategi Perdagangan

Modul strategi perdagangan dalam sistem yang didorong oleh peristiwa biasanya menjalankan beberapa jenis mekanisme ramalan atau penapisan pada data pasaran baru.

Ia menerima data bar atau tik dan kemudian menggunakan mekanisme ini untuk menghasilkan isyarat perdagangan untuk panjang atau pendek aset.

95% perbincangan blog kuant biasanya berputar di sekitar strategi perdagangan. Saya secara peribadi percaya ia harus lebih seperti 20%. Ini kerana saya fikir lebih mudah untuk meningkatkan pulangan yang dijangkakan dengan mengurangkan kos melalui pengurusan risiko yang betul dan saiz kedudukan, daripada mengejar strategi dengan lebih banyak alpha.

Pengurusan Portfolio & Perintah

hati dari backtester Event-Driven adalah sistem Pengurusan Portfolio & Perintah.

Matlamat sistem ini adalah untuk pergi dari portfolio semasa ke portfolio yang dikehendaki, sambil meminimumkan risiko dan mengurangkan kos transaksi.

Modul ini menghubungkan strategi, risiko, saiz kedudukan dan keupayaan pelaksanaan pesanan sistem. Ia juga mengendalikan pengiraan kedudukan semasa backtesting untuk meniru pengiraan broker sendiri.

Kelebihan utama menggunakan sistem yang kompleks adalah ia membolehkan pelbagai instrumen kewangan untuk ditangani di bawah satu portfolio. Ini diperlukan untuk portfolio gaya institusi dengan lindung nilai. Kerumitan sedemikian sangat rumit untuk dikodkan dalam sistem backtesting For-Loop.

Pengurusan Risiko & Posisi

Memisahkan pengurusan risiko ke dalam modulnya sendiri boleh menjadi sangat menguntungkan. Modul boleh mengubah suai, menambah atau membantah pesanan yang dihantar dari portfolio.

Khususnya, modul risiko boleh menambah lindung nilai untuk mengekalkan netraliti pasaran. Ia boleh mengurangkan saiz pesanan kerana pendedahan sektor atau had ADV. Ia boleh menolak sepenuhnya perdagangan jika penyebaran terlalu luas, atau yuran terlalu besar berbanding dengan saiz perdagangan.

Modul saiz kedudukan yang berasingan boleh melaksanakan anggaran turun naik dan peraturan saiz kedudukan seperti leverage Kelly.

Topik seperti itu tidak diwakili dengan baik dalam blogosfera kuant. Walau bagaimanapun, ini mungkin perbezaan terbesar antara bagaimana institusi dan beberapa peniaga runcit berfikir tentang perdagangan mereka. Mungkin cara yang paling mudah untuk mendapatkan pulangan yang lebih baik adalah dengan mula melaksanakan pengurusan risiko dan saiz kedudukan dengan cara ini.

Pengurusan Pelaksanaan

Dalam kehidupan sebenar kita tidak pernah dijamin untuk mendapatkan pasaran mengisi di titik pertengahan!

Kita mesti mempertimbangkan isu-isu transaksi seperti kapasiti, penyebaran, yuran, slippage, kesan pasaran dan masalah pelaksanaan algoritma lain, jika tidak, pulangan backtesting kita mungkin sangat berlebihan.

Pendekatan modular sistem Event-Driven membolehkan kita dengan mudah menukar BacktestExecutionHandler dengan LiveExecutionHandler dan menyebarkan ke pelayan jauh.

Kita juga boleh dengan mudah menambah beberapa broker menggunakan konsep OOP inheritance. ini sudah tentu mengandaikan bahawa broker tersebut mempunyai antara muka pengaturcaraan aplikasi (API) yang mudah dan tidak memaksa kita untuk menggunakan antara muka pengguna grafik (GUI) untuk berinteraksi dengan sistem mereka.

Satu isu yang perlu diperhatikan ialah kepercayaan dengan perpustakaan pihak ketiga. Terdapat banyak modul seperti itu yang memudahkan untuk bercakap dengan broker, tetapi perlu melakukan ujian anda sendiri. Pastikan anda benar-benar berpuas hati dengan perpustakaan ini sebelum melakukan modal yang luas, jika tidak, anda boleh kehilangan banyak wang hanya kerana bug dalam modul ini.

Prestasi & Pelaporan

Kuantiti runcit boleh dan harus meminjam teknik pelaporan canggih yang digunakan oleh kuantiti institusi. Alat-alat tersebut termasuk live dashboard portfolio dan risiko yang berkaitan, backtest equity vs live equity perbezaan atau delta, bersama dengan semua metrik biasa seperti kos setiap perdagangan, pengedaran pulangan, tanda air tinggi (HWM), pengeluaran maksimum, latensi perdagangan purata serta alfa / beta terhadap penanda aras.

Peningkatan tambahan yang konsisten harus dibuat kepada infrastruktur ini. Ini benar-benar dapat meningkatkan pulangan dalam jangka panjang, hanya dengan menghilangkan bug dan meningkatkan isu-isu seperti latensi perdagangan.

WGS akhirnya akan terkikis kerana alpha decay . Yang lain akhirnya akan menemui tepi dan akan mengarbitrase pulangan. Walau bagaimanapun, infrastruktur perdagangan yang kukuh, saluran penyelidikan strategi yang kukuh dan pembelajaran berterusan adalah cara yang baik untuk mengelakkan nasib ini.

Pengoptimuman infrastruktur mungkin lebih boring daripada pembangunan strategi tetapi ia menjadi kurang membosankan apabila pulangan anda meningkat!

Penghantaran & Pemantauan

Penyebaran ke pelayan jauh, bersama-sama dengan pemantauan sistem jauh ini, sangat penting untuk sistem peringkat institusi.

Sistem yang kukuh mesti digunakan dari jauh di awan atau terletak berhampiran pertukaran. jalur lebar rumah, bekalan kuasa dan faktor lain bermakna bahawa menggunakan desktop / komputer riba di rumah terlalu tidak boleh dipercayai.

Isu utama apabila mempertimbangkan penggunaan jarak jauh termasuk; pemantauan perkakasan, seperti CPU, RAM / swap, cakera dan I / O rangkaian, ketersediaan dan redundansi sistem yang tinggi, rancangan sandaran dan pemulihan yang difikirkan dengan baik, logging luas semua aspek sistem serta integrasi berterusan, ujian unit dan kawalan versi.

Ingat Hukum Murphy - Jika ia boleh gagal ia akan gagal.

Terdapat banyak vendor yang menawarkan penyebaran awan yang agak mudah, termasuk Amazon Web Services, Microsoft Azure, Google dan Rackspace.

Pikiran Akhir

Malangnya, tidak ada penyelesaian cepat dalam perdagangan kuantiti. Ia melibatkan banyak kerja keras dan pembelajaran untuk berjaya.

Mungkin batu sandungan utama bagi pemula (dan beberapa kuantiti pertengahan!) adalah bahawa mereka terlalu banyak menumpukan pada strategi terbaik. Strategi seperti itu selalu akhirnya menyerah kepada kerosakan alpha dan dengan itu menjadi tidak menguntungkan. Oleh itu, perlu terus-menerus meneliti strategi baru untuk menambah portfolio. Pada dasarnya, paip strategi harus selalu penuh.

Ia juga bernilai melabur banyak masa dalam infrastruktur perdagangan anda. Belanja masa pada isu-isu seperti penggunaan dan pemantauan. Sentiasa cuba dan mengurangkan kos urus niaga, kerana keuntungan adalah tentang mengurangkan kos kerana ia adalah tentang memperoleh pendapatan perdagangan.

Saya mengesyorkan menulis sistem backtesting anda sendiri hanya untuk belajar. anda boleh menggunakannya dan terus meningkatkannya atau anda boleh mencari vendor dan kemudian bertanya kepada mereka semua soalan yang anda telah menemui apabila anda membina anda sendiri. ia pasti akan membuat anda sedar tentang batasan sistem yang tersedia secara komersial.

Akhirnya, sentiasa membaca, belajar dan meningkatkan. Terdapat banyak buku teks, jurnal perdagangan, jurnal akademik, blog kuant, forum dan majalah yang membincangkan semua aspek perdagangan. Untuk idea strategi yang lebih maju, saya mengesyorkan SSRN dan arXiv - Kewangan Kuantitatif.

Lebih lanjut