이 포스트는 양적 거래에 처음 시작하는 사람들뿐만 아니라 이 분야에 대한 경험이 있는 사람들에게 적합합니다. 이 포스트는 백테스팅의 일반적인 함정과 몇 가지 흔하지 않은 것을 논의합니다!
또한 다양한 종류의 백테스팅 메커니즘과 이러한 접근 방식을 구현하는 소프트웨어 풍경을 살펴보고 자신의 백테스터를 만드는 것이 가치가 있는지 논의합니다.
마지막으로, 우리는 이벤트에 기반한 백테스팅 시스템의 내부와 외부를 논의합니다.
백테스트는 역사적인 가격 데이터에 거래 전략 규칙을 적용하는 것입니다. 즉, 만약 우리가 자산 포트폴리오에 진입하고 출입하는 일련의 메커니즘을 정의하고, 그 규칙을 그 자산의 역사적 가격 데이터에 적용한다면, 우리는 과거에 달성되었을 수 있는 이 "거래 전략"의 성과를 이해하려고 시도할 수 있습니다.
"모든 모델은 틀렸지만 어떤 모델은 유용하다"는 말이 있습니다. 백테스트도 마찬가지입니다. 그렇다면 그 모델은 어떤 목적을 가지고 있을까요?
백테스트는 궁극적으로 전략 규칙의 집합을 실시간으로 거래할 가치가 있는지 결정하는 데 도움이 됩니다. 그것은 우리에게 과거에서 전략이 어떻게 수행되었을 수 있는지에 대한 아이디어를 제공합니다. 본질적으로 우리는 어떤 실제 자본을 할당하기 전에 나쁜 전략 규칙을 필터링 할 수 있습니다.
백테스트를 생성하는 것은 쉽습니다. 불행히도 백테스트 결과는 실시간 거래 결과가 아닙니다. 대신 현실의 모델입니다. 일반적으로 많은 가정이 포함되는 모델입니다.
소프트웨어 백테스트에는 두 가지 주요 유형이 있습니다.
백테스팅 소프트웨어를 설계할 때 항상 정확성과 구현 복잡성 사이의 타협이 있습니다. 위의 두 가지 백테스팅 유형은이 타협의 스펙트럼의 양쪽 끝을 나타냅니다.
백테스팅과 관련된 많은 함정들이 있다. 이들은 모두 백테스팅이 현실의 모델에 불과하다는 사실에 관한 것이다.
백테스팅에 있어서 더 미묘한 문제들이 있습니다. 그 문제들은 자주 논의되지는 않지만 여전히 고려해야 할 것이 매우 중요합니다.
백테스팅의 문제들에 대해 많은 것이 기록되어 있습니다. 타커 발치와 에니
포-루프 백테스터는 가장 간단한 백테스팅 시스템이며 양자 블로그 게시물에서 가장 자주 볼 수 있는 변종입니다. 단순성과 투명성 때문입니다.
본질적으로 포 루프 시스템은 매 거래일에 걸쳐 반복 (또는 OHLC 바) 을 수행하고, 종결의 이동 평균과 같은 자산의 가격과 관련된 계산을 수행하고, 특정 자산 (대부분은 같은 종료 가격, 때로는 다음날) 을 길게 또는 짧게합니다. 반복은 계속됩니다. 그 동안 전체 주식이 추적되고 저장되어 나중에 주식 곡선을 생성합니다.
이런 알고리즘을 위한 위조 코드는 다음과 같습니다.
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
보시다시피, 이러한 시스템의 디자인은 매우 간단합니다. 이것은 특정 전략 규칙 세트의 성능을 "첫눈"으로 볼 수 있도록 매력적입니다.
포-루프 백테스터는 거의 모든 프로그래밍 언어로 구현하기 쉽고 실행이 매우 빠르다. 후자의 장점은 거래 설정을 최적화하기 위해 많은 매개 변수 조합을 테스트 할 수 있음을 의미합니다.
포루프 백테스터의 주요 단점은 매우 비현실적이라는 것입니다. 그들은 종종 특별히 추가되지 않는 한 거래 비용 능력이 없습니다. 일반적으로 주문은 즉시 중간 가격으로 시장에서 채워집니다. 따라서 스프레드를 계산하지 않습니다.
백테스팅 시스템과 라이브 트레이딩 시스템 사이에는 최소한의 코드 재사용이 있습니다. 이것은 코드를 두 번 작성해야한다는 것을 의미합니다. 더 많은 버그가 발생할 수 있습니다.
포-루프 백테스터는 인덱싱의 버그로 인해 Look-Ahead Bias에 취약합니다. 예를 들어, 패널 인덱싱에서
For-Loop 백테스터는 필터링 메커니즘으로만 사용되어야 합니다. 분명히 나쁜 전략을 제거하기 위해 사용할 수 있지만 강한 성능에 대해 회의적이어야 합니다. 추가 연구가 종종 필요합니다. 전략은 라이브 트레이딩에서 백테스트에서보다 잘 수행합니다.
이벤트 주도 백테스터는 스펙트럼의 다른 끝에 있다. 그들은 라이브 트레이딩 인프라 구현과 훨씬 더 유사하다. 따라서, 그들은 종종 백테스트와 라이브 트레이딩 성능의 차이에서 더 현실적이다.
이러한 시스템은 큰
특정 이벤트가 확인되면 인프라에서 적절한 모듈 (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 및 Event-Driven 시스템 모두에 존재하는 소프트웨어 (오픈 소스 및 상업용) 를 고려할 것입니다.
포-루프 백테스터의 경우, 사용되는 주요 프로그래밍 언어/소프트웨어는 파이썬 (판다스 라이브러리), R (와 퀀텀 모드 라이브러리) 및 MatLab을 포함한다. 퀀텀 블로그에서 찾을 수 있는 많은 코드 스니펫이 있다. 그러한 블로그의 훌륭한 목록은 퀀텀 크라시에서 찾을 수 있다.
이벤트 기반 시스템의 시장은 훨씬 더 넓습니다. 고객/사용자는 종종 소프트웨어가 하나의 패키지에서 백테스팅과 라이브 거래를 할 수 있기를 원합니다.
비싼 상업적 제공에는 Deltix와 QuantHouse가 포함됩니다. 그들은 종종 양자 헤지 펀드, 가족 사무실 및 프로프레이드 거래 회사에서 발견됩니다.
클라우드 기반 백테스팅 및 라이브 트레이딩 시스템은 비교적 새로운 시스템이다. 퀀토피안은 백테스팅과 라이브 트레이딩을 위한 성숙한 웹 기반 설정의 예이다.
제도적 쿼트는 종종 자체 소프트웨어도 구축합니다. 이는 규제 제약, 투자자 관계/보고 및 감사 가능성의 혼합으로 인해 발생합니다.
소매 쿼트는 Quantopian의
오픈 소스 소프트웨어의 경우 많은 라이브러리가 있습니다. 그들은 대부분 파이썬으로 작성되어 있습니다 (내가 아래에 설명 할 이유) Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver/Investment Idiocy) 및 QSTrader (QuantStart
그러나 가장 중요한 측면 중 하나는 당신이 궁극적으로 사용하는 소프트웨어의 조각에 상관없이, 그것은 금융 데이터의 똑같이 탄탄한 소스와 결합되어야한다는 것입니다. 그렇지 않으면 당신은 "쓰레기, 쓰레기"의 상황에있을 것이고 라이브 거래 결과는 백테스트와 크게 다를 것입니다.
소프트웨어는 우리에게 세부 사항을 돌보지만, 우리의 거래 전략의 복잡성을 확장하고자 할 때 종종 결정적인 많은 구현 세부 사항에서 우리를 숨깁니다. 어떤 시점에서 종종 우리 자신의 시스템을 작성해야하며 발생하는 첫 번째 질문은 "내가 어떤 프로그래밍 언어를 사용해야합니까?"입니다.
양적 소프트웨어 개발자로서의 배경을 가지고 있음에도 불구하고 저는 개인적으로 "언어 전쟁"에 관심이 없습니다. 하루에는 제한된 시간만 있고, 양자로서 우리는 일을 해야 합니다. 인터넷 포럼에서 언어 디자인에 대해 논쟁하는 시간을 낭비하지 마세요!
우리는 단지 효과가 있는 것에만 관심을 가져야 합니다.
파이썬은 익히는 것이 매우 쉬운 프로그래밍 언어이며, 프로그래밍을 배우기로 결정할 때 종종 사람들이 접하는 첫 번째 언어입니다. 상상할 수 있는 거의 모든 형태의 데이터를 읽고 다른
그것은 몇 가지 예외적인 양자 / 데이터 과학 / 기계 학습 (ML) 라이브러리를 NumPy, SciPy, 판다, Scikit-Learn, Matplotlib, PyMC3 및 Statsmodels에서 가지고 있습니다. 그것은 ML 및 일반적인 데이터 과학에 훌륭하지만, 더 광범위한 고전적인 통계 방법과 시간 계열 분석에 약간의 고통을 겪습니다.
그것은 For-Loop 및 이벤트 주도 백테스팅 시스템을 구축하는 데 훌륭합니다. 사실, 그것은 아마도 끝에서 끝까지의 연구, 백테스팅, 배포, 라이브 거래, 보고 및 모니터링을 직접적으로 허용하는 유일한 언어 중 하나입니다.
아마도 가장 큰 단점은 C++와 같은 다른 언어에 비해 실행이 상당히 느린다는 것입니다. 그러나이 문제를 개선하기 위해 작업이 진행되고 있으며 시간이 지남에 따라 파이썬은 더 빨라지고 있습니다.
R는 완전한 1등급 프로그래밍 언어가 아닌 통계 프로그래밍 환경이다. 그것은 주로 시간 계열, 고전/주파수주의 통계, 베이지안 통계, 기계 학습 및 탐사 데이터 분석에 대한 고급 통계 분석을 수행하기 위해 설계되었습니다.
이는 종종 양자 모드 라이브러리를 통해 For-Loop 백테스팅에 널리 사용되지만 이벤트 구동 시스템이나 라이브 거래에 특히 적합하지 않습니다. 그러나 전략 연구에 탁월합니다.
C++는 매우 빠른 것으로 유명하다. 거의 모든 과학적 고성능 컴퓨팅은 포트랜 또는 C++에서 수행된다. 이것은 그것의 주요 장점이다. 따라서 만약 당신이 고주파 트레이딩을 고려하고 있거나, 또는 큰 조직에서 레거시 시스템에서 일하고 있다면, C++는 필수 요소일 가능성이 있다.
불행히도 전략 연구를 수행하는 데 고통스럽습니다. 정적 타입으로 인해 파이썬이나 R에 비해 데이터를 쉽게 로드, 읽기 및 포맷하는 것이 상당히 어렵습니다.
비교적 오래 되었음에도 불구하고 최근에는 C++11/C++14의 도입과 추가 표준 정제로 크게 현대화되었습니다.
당신은 또한 자바, 스칼라, C #, 줄리아와 기능 언어의 많은 것을 살펴보고 싶을 수도 있습니다. 그러나, 나의 추천은 양자 거래 커뮤니티가 훨씬 더 크기 때문에 파이썬, R 및 / 또는 C ++에 붙어있다.
대답: 그렇습니다!
자신의 이벤트 주도 백테스팅 시스템을 작성하는 것은 훌륭한 학습 경험입니다. 첫째로, 그것은 당신이 특정 전략에 수시간을 낭비하지 않고 거래 인프라의 모든 측면을 고려하도록 강요합니다.
심지어 당신이 라이브 거래를 위해 시스템을 사용하지 않는 경우에도, 그것은 당신이 당신의 상업적 또는 FOSS 백테스팅 공급자에게 물어봐야하는 수많은 질문을 제공 할 것입니다.
예를 들어: 현재 실시간 시스템은 어떻게 백테스트 시뮬레이션과 다른가?
이벤트에 기반한 시스템은 작성하기가 빠르고 쉽지 않지만, 이 경험은 나중에 양자 거래 경력에서 엄청난 교육적 배당금을 지불할 것입니다.
어떻게 그런 시스템을 만들 수 있을까요?
시작하는 가장 좋은 방법은 단순히 Zipline, QSTrader, PyAlgoTrade, PySystemTrade 등을 다운로드하고 문서와 코드를 읽고 시도하는 것입니다. 그들은 모두 파이썬으로 작성되어 있습니다.
저는 또한 이벤트 주도 백테스트 디자인에 대한 많은 기사를 썼습니다. 여기에서 찾을 수 있습니다. 시스템의 각 모듈의 개발을 안내합니다.
기억하세요, 당신은 1일 동안 전문가가 될 필요가 없습니다. 당신은 천천히, 하루가 다르게, 모듈별로 할 수 있습니다. 도움이 필요한 경우, 당신은 항상 나 또는 다른 기꺼이 양자 블로거에게 연락할 수 있습니다. 제 연락 이메일에 대한 기사의 끝을 참조하십시오.
이제 많은 이벤트 구동 백테스팅 시스템에서 자주 발견되는 모듈에 대해 논의하겠습니다. 전체적인 목록은 아니지만 그러한 시스템이 어떻게 설계되는지에 대한
이것은 모든 역사적인 가격 데이터가 저장되는 곳입니다. 당신의 거래 역사와 함께, 한 번 라이브.
대신, 우리는 PostgreSQL, MySQL, SQL Server 또는 HDF5와 같은 1등급 데이터베이스 또는 파일 시스템을 사용합니다.
이상적으로, 우리는 틱 레벨 데이터를 얻고 저장하기를 원합니다. 그것은 우리에게 거래 스프레드에 대한 아이디어를 제공합니다. 그것은 또한 우리가 원하는 경우 낮은 주파수에서 자신의 OHLC 바를 구성 할 수 있음을 의미합니다.
우리는 항상 기업 행동 (주식 분할 및 배당 등), 생존 편견 (주식 상장 삭제) 을 처리하고 다양한 거래소 간의 시간대 차이를 추적하는 것을 알아야합니다.
개인/소매 업체들은 많은 생산 품질 데이터베이스 기술이 성숙하고 무료이며 오픈 소스이기 때문에 여기에 경쟁할 수 있습니다. 데이터 자체는 Quandl 같은 사이트를 통해 더 저렴하고
여전히 많은 시장과 전략이 있습니다. 큰 펀드들이 관심을 가질 수 없을 정도로 너무 작습니다. 이것은 소매량 거래자에게 유리한 토양입니다.
이벤트 기반 시스템의 거래 전략 모듈은 일반적으로 새로운 시장 데이터에 대한 예측 또는 필터링 메커니즘을 실행합니다.
그것은 바 또는 틱 데이터를 수신하고 그 다음이 메커니즘을 사용하여 자산을 길게 또는 짧게 거래 신호를 생성합니다.이 모듈은 위치 사이징 모듈을 통해 수행되는 양을 생성하도록 설계되지 않았습니다.
양자 블로그 토론의 95%는 일반적으로 거래 전략을 중심으로 회전합니다. 개인적으로는 20% 정도가어야한다고 생각합니다. 이것은 적절한 리스크 관리와 포지션 사이징을 통해 비용을 줄임으로써 예상 수익을 높이는 것이 훨씬 더 쉽다고 생각하기 때문입니다.
이벤트 주도 백테스터의 핵심은 포트폴리오 및 주문 관리 시스템입니다. 가장 많은 개발 시간과 품질 보장 테스트를 필요로하는 영역입니다.
이 시스템의 목표는 현재의 포트폴리오에서 원하는 포트폴리오로 이동하는 것입니다. 동시에 위험을 최소화하고 거래 비용을 줄이는 것입니다.
모듈은 시스템의 전략, 위험, 포지션 사이즈 및 주문 실행 기능을 연결합니다. 또한 중개사의 자신의 계산을 모방하기 위해 백테스팅을 할 때 포지션 계산을 처리합니다.
이러한 복잡한 시스템을 사용하는 주된 장점은 단일 포트폴리오에서 다양한 금융 도구를 처리 할 수 있다는 것입니다. 이는 헤지링과 함께 기관형 포트폴리오에 필요합니다. 이러한 복잡성은 For-Loop 백테스팅 시스템에서 코딩하는 것이 매우 어렵습니다.
리스크 관리를 자체 모듈로 분리하는 것은 매우 유리할 수 있습니다. 모듈은 포트폴리오에서 전송되는 명령을 수정, 추가 또는 거부할 수 있습니다.
특히 위험 모듈은 시장 중립성을 유지하기 위해 헤지를 추가 할 수 있습니다. 부문 노출 또는 ADV 제한으로 인해 주문 크기를 줄일 수 있습니다. 스프레드가 너무 넓거나 거래 크기에 비해 수수료가 너무 크면 거래를 완전히 거부 할 수 있습니다.
별도의 포지션 사이징 모듈은 켈리 레버리지와 같은 변동성 추정 및 포지션 사이징 규칙을 구현할 수 있습니다. 실제로 모듈 방식의 접근 방식을 활용하면 전략이나 실행 코드에 영향을 미치지 않고 광범위한 사용자 정의가 가능합니다.
이러한 주제는 양자 블로그계에서 잘 표현되지 않습니다. 그러나 이것은 아마도 기관과 일부 소매 거래자가 거래에 대해 생각하는 방식의 가장 큰 차이입니다. 아마도 더 나은 수익을 얻는 가장 간단한 방법은 이러한 방식으로 위험 관리 및 위치 크기를 구현하는 것입니다.
실제 생활에서는 시장이 중간 지점에서 채워지는 것을 보장하지 않습니다!
우리는 용량, 스프레드, 수수료, 미끄러짐, 시장 영향 및 기타 알고리즘 실행 문제와 같은 거래 문제를 고려해야합니다. 그렇지 않으면 우리의 백테스팅 수익은 크게 과대평가 될 가능성이 있습니다.
이벤트 구동 시스템의 모듈 방식은 우리가 쉽게 LiveExecutionHandler와 BacktestExecutionHandler를 교체하고 원격 서버에 배포 할 수 있습니다.
우리는 또한 쉽게 OOP 개념의
인식해야 할 한 가지 문제는 제3자 라이브러리와의 신뢰입니다. 브로커와 쉽게 대화 할 수있는 많은 모듈이 있지만 자신의 테스트를 수행하는 것이 필요합니다. 광범위한 자본을 투자하기 전에 이러한 라이브러리에 완전히 만족하는지 확인하십시오. 그렇지 않으면 이러한 모듈의 버그로 인해 많은 돈을 잃을 수 있습니다.
소매 쿼트는 기관 쿼트에서 사용하는 정교한 보고 기술을 빌릴 수 있고 빌려야 합니다. 이러한 도구는 포트폴리오와 그에 따른 위험의 실시간
이 인프라에 대한 일관된 점진적 개선이 이루어져야 합니다. 이것은 버그를 제거하고 무역 지연과 같은 문제를 개선함으로써 장기적으로 수익을 높일 수 있습니다. 단순히 "세계 최고의 전략" (WGS) 을 개선하는 것에 집착하지 마십시오.
WGS는 결국 알파 붕괴로 인해 침식 될 것입니다. 다른 사람들은 결국 가장자리를 발견하고 수익을 중재 할 것입니다. 그러나 견고한 거래 인프라, 탄탄한 전략 연구 파이프 라인 및 지속적인 학습은 이러한 운명을 피하는 좋은 방법입니다.
인프라 최적화는 전략 개발보다 더 지루할 수 있지만 수익이 향상되면 훨씬 덜 지루해집니다!
원격 서버에 배포, 이 원격 시스템의 광범위한 모니터링과 함께, 기관 수준의 시스템에 절대적으로 중요합니다. 소매량 또한이 아이디어를 활용 할 수 있고해야합니다.
견고한 시스템은 원격으로 클라우드 또는 교환 근처에 배치되어야합니다. 가정 광대역, 전원 공급 및 기타 요인은 가정 데스크톱 / 노트북을 사용하는 것이 너무 신뢰할 수 없다는 것을 의미합니다. 종종 모든 것이 최악의 순간에 실패하고 상당한 손실로 이어집니다.
원격 배포를 고려할 때 주요 문제는 CPU, RAM / swap, 디스크 및 네트워크 I / O와 같은 모니터링 하드웨어, 시스템의 높은 가용성 및 과잉성, 백업 및 복원 계획을 통해 잘 생각, 시스템의 모든 측면의 광범위한 로깅뿐만 아니라 지속적인 통합, 유닛 테스트 및 버전 제어입니다.
머피의 법칙을 기억하세요. 실패할 수 있다면 실패할 것입니다.
아마존 웹 서비스, 마이크로소프트 애저, 구글 및 랙스페이스 등 비교적 간편한 클라우드 배포를 제공하는 많은 벤더가 있습니다. 소프트웨어 엔지니어링 작업의 벤더에는 Github, Bitbucket, Travis, Loggly 및 Splunk 등이 포함됩니다.
불행히도 양자 거래에는 "빠른 해결책"이 없습니다. 성공하기 위해서는 많은 노력과 학습이 필요합니다.
아마도 초보자 (그리고 일부 중간 양자!) 를위한 주요 걸림돌은 최고의 전략에 너무 집중한다는 것입니다. 그러한 전략은 항상 결국 알파 붕괴에 굴복하고 수익성이 떨어집니다. 따라서 포트폴리오에 추가 할 수있는 새로운 전략을 지속적으로 연구해야합니다. 본질적으로, 전략 파이프 라인 항상 가득해야합니다.
또한 거래 인프라에 많은 시간을 투자 할 가치가 있습니다. 배포 및 모니터링과 같은 문제에 시간을 투자하십시오. 항상 거래 비용을 줄이려고 노력하십시오. 수익성은 거래 수익을 얻는 것만큼 비용을 줄이는 것입니다.
저는 단순히 배우기 위해 자신의 백테스팅 시스템을 작성하는 것을 추천합니다. 당신은 그것을 사용하고 지속적으로 개선하거나 공급자를 찾고 자신의 구축을 할 때 발견 한 모든 질문을 할 수 있습니다. 그것은 확실히 당신이 상업적으로 사용할 수있는 시스템의 한계를 인식 할 것입니다.
마지막으로, 항상 읽고 배우고 개선하십시오. 거래의 모든 측면을 논의하는 교과서, 무역 저널, 학술 저널, 양성 블로그, 포럼 및 잡지가 풍부합니다. 더 고급 전략 아이디어를 위해 SSRN 및 arXiv - 양적 금융을 추천합니다.