この記事では,数値取引を始めてみている方や,この分野での経験のある方にも適しています.この記事では,バックテストの一般的な落とし穴や,珍しいものについて説明します!
また,バックテストのメカニズムや,これらのアプローチを実装するソフトウェアの状況も検討します.その後,今日利用可能なオープンソースツールの普及にも関わらず,自分のバックテストを作成する価値はあるかどうかを議論します.
最後に,イベント駆動バックテストシステムの内側と外側について議論します. このトピックは,私がQuantStartで前回の投稿で頻繁に取り扱ってきたものです.
バックテストは,過去の価格データに取引戦略の規則の適用です. つまり,資産のポートフォリオへの入入出のメカニズムを定義し,これらのルールを資産の歴史的な価格データに適用すると,過去に達成されたかもしれないこの"取引戦略"のパフォーマンスを理解しようとします.
"すべてのモデルが間違っているが,いくつかは有用だ" と言われてきました.バックテストも同じです.それでは,どんな目的に役立つのでしょうか?
バックテストは,戦略のルールの一連のライブトレードが価値あるかどうかを決定するのに役立ちます.それは,戦略が過去にどのように機能していたかについてのアイデアを提供します.本質的には,実際の資本を割り当てる前に悪い戦略ルールをフィルタリングすることができます.
バックテストを生成するのは簡単です.残念ながらバックテスト結果はライブ取引の結果ではありません.代わりに現実のモデルです.通常多くの仮定を含むモデルです.
ソフトウェアのバックテストには2つの主なタイプがあります. ループ型システムとイベント型システムです.
バックテストソフトウェアを設計する際には,常に正確性と実装の複雑性との間のトレードオフがあります.上記の2つのバックテストタイプは,このトレードオフのスペクトルの両端を表しています.
バックテストには多くの落とし穴があります.それらはすべてバックテストが現実のモデルにすぎないという事実に関係しています.より一般的な落とし穴には以下が含まれます:
バックテストでは,より微妙な問題もありますが,あまり議論されていませんが,それでも考えることが非常に重要です.
バックテストの問題について多くのことが書かれています.タッカー・バルチとエルニー・チャンはどちらも問題を詳細に検討しています.
For-Loop Backtesterは,最もシンプルなバックテストシステムであり,単純性と透明性のために,量子ブログ投稿で最もよく見られる変種です.
基本的には,For-Loopシステムは,すべての取引日 (またはOHLCバー) にわたって繰り返され,閉店時の移動平均値などの資産の価格 (s) に関連する計算を実行し,その後特定の資産 (しばしば同じ閉店価格,時には翌日) にロングまたはショートする.繰り返しは継続する.その間,総資本は追跡され,保存され,後に株式曲線を作成する.
このようなアルゴリズムの擬似コードです
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
戦略のルールセットのパフォーマンスの"初見"を得るのに魅力的になります.
For-Loop バックテストは,ほぼすべてのプログラミング言語で実装し,実行が非常に迅速である.後者の利点は,取引の設定を最適化するために多くのパラメータ組み合わせをテストできるということです.
For-Loop バックテストの主な欠点は,かなり非現実的であることである.特に追加しない限り,トランザクションコスト能力がないことが多い.通常,注文はすぐに市場価格で満たされる.したがって,スプレッドの説明はしばしば行われない.
バックテストシステムとライブ・トレードシステムの間には,コードの再利用が最小限である.これは,コードを2回書く必要があることを意味し,より多くのバグの可能性を導入する.
For-Loop バックテストは,インデックスでバグが発生したため,Look-Aheadバイアスになりやすい.例えば,パネルインデックスで
For-Loop バックテストは,フィルタリングメカニズムとしてのみ使用されるべきです.明らかに悪い戦略を排除するためにそれらを使用できますが,強いパフォーマンスに対して懐疑的であり続けなければなりません.さらなる研究がしばしば必要です. 戦略は,バックテストよりもライブ取引でよりよく機能することがまれです!
イベント駆動バックテストは,スペクトラムの反対側にある.彼らはライブ・トレード・インフラストラクチャの実装にはるかに近い.したがって,バックテストとライブ・トレードパフォーマンスとの違いはしばしばより現実的である.
このようなシステムは,大きな"while"ループで実行され,継続的に"event queue"で異なるタイプの"event"を探します.潜在的なイベントには以下が含まれます:
特定のイベントが特定されると,インフラストラクチャ内の適切なモジュール (s) に転送され,そのイベントを処理し,次にキューに戻る新しいイベントを生成する可能性があります.
イベント駆動バックテストシステムの偽コードは以下のとおりです
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
ポートフォリオハンドラーモジュールに大きく依存していることがわかります.このようなモジュールは,以下のとおりイベント駆動バックテストシステムの"心臓部"です.
イベント駆動バックテスターを使用する利点はいくつかあります.
利点は明らかですが,このような複雑なシステムを利用する際には,いくつかの大きな欠点もあります.
このセクションでは,For-Loopとイベント駆動システムの両方に存在するソフトウェア (オープンソースと商業の両方) を検討します.
For-Loopのバックテストでは,主に使用されているプログラミング言語/ソフトウェアは,Python (Pandasライブラリを含む),R (Quantmodライブラリを含む),MatLabなどである.量子ブログには多くのコードスニペットが掲載されている.Quantcracyではこのようなブログのリストが多数掲載されている.
イベント駆動システムの市場は,クライアント/ユーザがソフトウェアがバックテストとライブ取引の両方を1つのパッケージで実行できるようにすることを望むため,はるかに大きい.
高価な商用製品にはDeltixやQuantHouseが含まれる.それらはしばしば量子ヘッジファンド,ファミリーオフィス,プロペラ取引会社で見つけられる.
クラウドベースのバックテストとライブ取引システムは比較的新しい. Quantopianはバックテストとライブ取引の両方の成熟したウェブベースの設定の例です.
機関企業もしばしば自社ソフトウェアを構築する.これは規制の制約,投資家関係/報告,監査可能性の組み合わせによる.
小売クォントは,クォントピアンの"クラウド+データ"アプローチを使用するか,Amazon Web Services,Rackspace Cloud,Microsoft Azureなどのクラウドベンダーを使用して,DTN IQFeedやQuantQuoteなどの適切なデータベンダーを使用するか選択できます.
オープンソースソフトウェアに関しては,多くのライブラリが利用可能である.それらは主にPythonで書かれています (以下に概説する理由のために),Zipline (Quantopian),PyAlgoTrade,PySystemTrade (Rob Carver/Investment Idiocy) およびQSTrader (QuantStart
しかし,最も重要な側面の1つは,あなたが最終的に使用するソフトウェアが何であれ,それは同様に堅牢な金融データの源と組み合わせなければならないということです.そうでなければ,あなたは"ゴミを入れ,ゴミを出す"状況にあり,あなたのライブ取引結果はバックテストと大幅に異なります.
ソフトウェアは詳細を私たちのために処理しますが,私たちの取引戦略の複雑さを拡大したいときにしばしば重要な多くの実装の詳細を隠します.ある時点で,自分のシステムを書くことがしばしば必要であり,最初の質問は"どのプログラミング言語を使用すべきですか?"です.
量的なソフトウェア開発者の経歴があるにも関わらず,私は個人的に"言語戦争"に関心を持っていません. 一日に限られた時間しかありません. そして,量として,私たちは物事を成し遂げなければなりません - インターネットフォーラムで言語デザインを議論する時間を無駄にしないでください!
機能するものにのみ 興味を持つべきです
Pythonは,学習が非常に簡単で,プログラミングを学ぶときに最初に接触する言語である.考えられるほぼあらゆる形式のデータを読み,他の"サービス"と非常に簡単に通信できる標準的なツールライブラリを持っています.
NumPy,SciPy,Pandas,Scikit-Learn,Matplotlib,PyMC3およびStatsmodelsでいくつかの例外的な量子/データ科学/機械学習 (ML) ライブラリを持っています.MLと一般的なデータ科学には素晴らしいですが,より広範な古典的な統計方法とタイムシリアル分析には少し苦しんでいます.
For-Loop と Event-Driven バックテストシステムの両方を構築するのに最適です.実際は,端から端への研究,バックテスト,展開,ライブ取引,レポート,モニタリングを直接許可する唯一の言語の一つです.
おそらく最大の欠点は,C++などの他の言語と比較して実行がかなり遅い点である.しかし,この問題を改善するために作業が行われ,時間が経つにつれてPythonはより速くなりつつある.
Rは,完全な"ファーストクラスプログラミング言語"ではなく,統計プログラミング環境である.これは主に時間列,古典/周波数統計,ベイジアン統計,機械学習,探査データ分析のための高度な統計分析を実行するために設計された.
For-Loop バックテストに広く使用されているが,イベント駆動システムやライブ取引には特に適していない.しかし,戦略研究では優れている.
C++ は極めて高速であることで有名である.ほぼすべての科学的高性能コンピューティングは,Fortran または C++ で実行される.これが主な利点である.したがって,高周波取引を検討している場合,または大型組織でレガシーシステムに取り組んでいる場合,C++ は必要である可能性が高い.
ストラテジカルなタイプであるため,PythonやRと比較してデータを簡単に読み込み,読み込み,フォーマットすることがかなり難しい.
比較的古いにもかかわらず,最近はC++11/C++14の導入とさらなる標準の改良により大幅に近代化されています.
また,Java,Scala,C#,Julia,および多くの機能言語をご覧ください.しかし,私の推奨は,量子取引コミュニティがはるかに大きいため,Python,Rおよび/またはC++に固執することです.
答え: はい!
独自のイベント駆動バックテストシステムを書くことは,素晴らしい学習経験です. まず,それは特定の戦略を修飾する時間を費やすことではなく,あなたの取引インフラストラクチャのすべての側面を検討することを強制します.
商用またはFOSSバックテストのベンダーに尋ねるべき膨大な数の質問を提供します.
例えば,現在の実況システムとバックテストシミュレーションの違いは?
イベント駆動システムを書くのは 簡単でも 簡単でもありませんが この経験は 量子トレーディングのキャリアにおいて 大きく教育的な利益をもたらします
どのようにしてこのようなシステムを 作るのでしょう?
始めるための最良の方法は,Zipline,QSTrader,PyAlgoTrade,PySystemTradeなどをダウンロードし,ドキュメントとコードを読み取ってみることです.それらはすべてPythonで書かれています (上記で述べた理由のために).そして幸いにもPythonは偽コードを読むようなものです.つまり,それは非常に簡単です.
また,Event-Driven バックテストデザインに関する多くの記事を書きました.ここで,システムの各モジュールの開発を案内します.
その日の専門家である必要はないことを覚えておいてください. ゆっくりと,日々,モジュールごとに,それを行うことができます. もし助けが必要な場合は,いつでも私や他の意欲的な量子ブロガーに連絡することができます. 私の連絡先メールの記事の終わりを参照してください.
現在,多くのイベント駆動バックテストシステムでよく見られるモジュールについて説明します. リストは完全ではありませんが,そのようなシステムがどのように設計されているかについての"味"を与えるべきです.
プロフェッショナルなシステムは Yahoo金融から CSV ファイルが数個だけではありません!
その代わりに,PostgreSQL,MySQL,SQL Server,またはHDF5などの"ファーストクラスの"データベースやファイルシステムを使用します.
理想的には, 取引のスプレッドを把握できるので, チケットレベルのデータを入手し, 保存したいと考えます. また,必要に応じて, 低周波のOHLCバーを作ることもできます.
株式の分割や配当などの企業活動や 存続偏見 (株式のリスト解除) の対処や 取引所の時区間の違いを常に把握する必要があります
生産品質のデータベース技術が成熟し,フリーでオープンソースであるため,個人/小売企業はここで競争することができます. Quandlのようなサイトを通じてデータ自体は安くなり,民主化されています.
市場や戦略はまだたくさんありますが 大手ファンドが興味を持つには小さすぎるのです これは小売量取引業者にとって肥沃な土壌です
イベント駆動システムにおける取引戦略モジュールは,一般的に新しい市場データに対して何らかの予測またはフィルタリングメカニズムを実行します.
このモジュールは,ポジションサイジングモジュールを介して実行される量を生成するように設計されていません.
クワントブログの議論の95%は,通常,取引戦略を中心に回ります.私は個人的に20%くらいでなければならないと考えています.これは,より多くのアルファを持つ戦略を追いかけるよりも,適切なリスク管理とポジションサイジングを通じてコストを削減することによって期待されるリターンを増加させることがはるかに簡単だと思います.
イベント駆動バックテストの"ハート"はポートフォリオ&オーダー管理システムである.これは最も開発時間と品質保証テストを必要とする領域である.
このシステムの目的は,リスクを最小限に抑え,取引コストを削減しながら,現在のポートフォリオから望ましいポートフォリオへと移行することです.
このモジュールは,システムの戦略,リスク,ポジションサイズ,オーダー実行能力を結びつけ,また,ブローカーの独自の計算を模倣するためにバックテストしながらポジション計算を処理します.
このような複雑なシステムを使用する主な利点は,単一のポートフォリオでさまざまな金融商品を扱うことを可能にすることである.これはヘッジ付きの機関型ポートフォリオに必要である.このような複雑性はFor-Loopバックテストシステムでコードすることは非常に難しい.
リスクマネジメントを独自のモジュールに分割することは非常に有利である.モジュールはポートフォリオから送信されるオーダーを変更,追加または拒否することができます.
特に,リスクモジュールは,市場中立性を維持するためにヘッジを追加することができます. セクター露出またはADV制限によるオーダーのサイズを減らすことができます. 差幅が幅広くすぎたり,取引サイズに比べて手数料が大きすぎたりした場合,完全に取引を拒否することができます.
単一のポジションサイジングモジュールは,ケリーレバレッジなどの波動性推定およびポジションサイジングルールを実装することができます.実際には,モジュールアプローチを使用することで,戦略または実行コードに影響を与えることなく,ここで広範なカスタマイズが可能になります.
このようなトピックは量子ブログ圏ではよく表現されていない.しかし,これはおそらく機関と一部の小売トレーダーの取引について考える方法の最大の違いである.より良い収益を得るための最も簡単な方法は,この方法でリスク管理とポジションサイジングを実装し始めることです.
市場の中央に 市場が満たされる保証はありません
能力,スプレッド,手数料,スリップ,市場影響,その他のアルゴリズム実行問題など 取引上の問題を考慮する必要があります そうでなければ,バックテストの収益は 大きく過大評価される可能性があります
イベント駆動システムのモジュール的なアプローチにより,BacktestExecutionHandlerをLiveExecutionHandlerと簡単に切り替えてリモートサーバーに展開できます.
簡単に複数のブローカージーを追加できます.これは,これらのブローカージュがシンプルなアプリケーションプログラミングインターフェイス (API) を持っていることを前提に,そのシステムとインタラクションを行うためにグラフィックユーザーインターフェイス (GUI) を利用することを強制しません.
認識すべき問題の一つは,第三者のライブラリとの"信頼性"である.ブローカージーと話すことを容易にするようなモジュールがたくさんあるが,自分でテストを行う必要がある.大規模な資本を投入する前に,これらのライブラリに完全に満足していることを確認してください.そうでなければ,これらのモジュールのバグのためだけに多くのお金を失う可能性があります.
小売クォントは,機関クォントが利用する洗練された報告技術を利用できるし,するべきである.そのようなツールには,ポートフォリオとそれに対応するリスクのライブ・ダッシュボード,バックテスト・エクイティとライブ・エクイティの差またはデルタ,取引コスト,収益分布,高水印 (HWM),最大引き上げ,平均取引遅延,ベンチマークに対するアルファ/ベータなどのすべての通常のメトリックが含まれます.
このインフラストラクチャに一貫した漸進的な改善が必要である.これは,バグを排除し,貿易遅延などの問題を改善することによって,長期的に見れば収益を上げることができます.単に"世界最大の戦略" (WGS) を改善することにこだわらないでください.
WGSは最終的に
戦略開発よりも"退屈"かもしれませんが 収益が向上すると 退屈性が大幅に減ります
リモートサーバーへの展開と,このリモートシステムの広範な監視は,機関レベルのシステムにとって極めて重要です.小売業者もこれらのアイデアを活用することができます.
堅牢なシステムは,遠隔でクラウドに展開され,または交換所の近くに位置する必要があります.家庭ブロードバンド,電源,その他の要因は,家庭デスクトップ/ラップトップを使用することが信頼性が低いことを意味します.しばしば,最悪のタイミングで失敗し,かなりの損失につながる.
リモートデプロイを検討する際の主な問題は,CPU,RAM/スワップ,ディスクおよびネットワークI/Oなどの監視ハードウェア,システムの高可用性および冗長性,バックアップおよび復元計画を通じてよく考えられたシステム,システムのすべての側面の広範なログ ainsiと継続的な統合,ユニットテストおよびバージョン制御です.
マーフィーの法則を覚えてください 失敗する可能性があるなら 失敗するでしょう
Amazon Web Services,Microsoft Azure,Google,Rackspaceなど,比較的簡単なクラウドデプロイメントを提供する多くのベンダーが提供されています.ソフトウェアエンジニアリングタスクのベンダーには,Github,Bitbucket,Travis,Loggly,Splunk,その他多くのベンダーがあります.
量子トレーディングでは 簡単な解決法はありません 成功を収めるためには 努力と学習が必要です
初心者 (そして中級者) の大きな障害は,ベストな"戦略"に過剰に集中することである.そのような戦略は,必ずアルファ崩壊に屈し,利益を失ってしまう.したがって,ポートフォリオに追加するための新しい戦略を継続的に研究することが必要である.本質的には,"戦略パイプライン"は常に満タンであるべきです.
また,取引インフラストラクチャに多くの時間を投資する価値があります. 展開と監視などの問題に時間を費やしてください. 収益性は,取引収入を得ることと同じくらいコストを削減することです.
自分のバックテストシステムを書き直すのは簡単です.それを利用して継続的に改善したり,ベンダーを見つけ,自分のシステムを構築したときに発見したすべての質問を彼らに尋ねることができます.それは間違いなく商用で利用可能なシステムの限界を認識させます.
最後に,常に読み,学び,改善してください. 貿易のあらゆる側面について議論する教科書,貿易誌,学術誌,量子ブログ,フォーラム,雑誌がたくさんあります. より高度な戦略アイデアのために,SSRNとarXiv - 定量金融をお勧めします.