自動取引システムをどうやってテストすればいいか

自動取引システムをどうやってテストしけばいいかの個人的整理メモ。 基本的に日時での取引戦略を前提にしているの+あくまで実装前の妄想なのでご注意ください。

なぜテストしたいか

• 自動取引システムが止まることで機械損が発生してしまう
• ロジックが間違っているまま放置していると誤った発注を出して実損を出してしまう
• 修正時の心理的安全性を高めたい

何が難しいか

• テストのために割と複雑なデータを準備する必要があって面倒
• 学習モデルが正しく動いているかどうかを出力された取引戦略から推測するのは殆ど不可能

簡単にリサーチ

stock trading testingとかstock traiding continuous integrationとかで調べてもバックテスト系の話しか出てこない。 調べ方を変えてMLOpsの検証周りの話が応用できそうなので、そこら編からアイディアを持ってこれそう。 S/N比が小さすぎて短いスパンでのモデルの精度検証は難しいが、データ周りの検証は参考にできることが多いのではないか。

• GoogleのMlOpsの記事
• コンセプトドリフト
• MlOpsのテスト周辺の話まとめ

どうテストしていくかの案出

ユニットテスト

基本、だけど一人でユニットテストを整備しながら開発していくのは相当モチベーションが高く無いと維持できない。 特にデータが絡み始めるとテストのしにくさが極端に上がるし、Try and Errorを繰り返す分野なので維持コストが結構高い。 ある程度ステートレスな部分と重要な部分に労力割いて整備していくのがいいかもしれない。

Dry-Run

データの書き換え無しに一通り問題なく回るか、を検証する。あたり前だがロジックが妥当かどうかまでは検証できない。 一方で簡単に実装できて、かつ機械損の回避という観点ではコスパは良さそう。

trainとpredictで同じデータが生成されるかテスト

学習処理時と予測処理時で同一の日のデータを生成してみて問題なく動くかどうか比較する。 ただこれはそもそもtrainとpredictで可能な限りデータ生成部分を共通化するような設計にするべき。 共通化するというよりも、 学習時も予測時も同一のパイプラインでデータを生成するべき。

メタデータ管理

GoogleのMlOpsの文書読んでて大事そうだったので追加。 これはテストというよりはというよりは事後的なモニタリングにあたるが、使っているデータが妥当だったかコホート検証する感じ。 何はともあれ学習・予測に使ったデータはストレージして、事後的な検証を走らせることができるようにする。

結局どうすればいいか

こんな感じで整備していく。

• dry_run実装コストが高くないので早めに実装して機械損を防ぐ。
• パイプラインの整備。既存コードを書き換える形で学習・予測時に使ったデータがすぐに参照できるようにする。
• データモニタリング機構の導入。最初は簡単に欠損や平均を確認するバッチを用意するだけでよさそう。

ユニットテストに関しては設計と密に話が結びつきそうなので、そこの整理ができ次第まとめる。