Bài viết này phù hợp cho những người đang bắt đầu giao dịch định lượng cũng như những người đã có một số kinh nghiệm với lĩnh vực này. bài viết thảo luận về những cạm bẫy phổ biến của backtesting, cũng như một số không phổ biến!
Nó cũng xem xét các loại cơ chế backtesting khác nhau cũng như bối cảnh phần mềm thực hiện các phương pháp này. Sau đó chúng tôi thảo luận liệu có đáng để xây dựng backtester của riêng bạn, ngay cả với sự phổ biến của các công cụ nguồn mở có sẵn ngày nay hay không.
Cuối cùng, chúng tôi thảo luận về những chi tiết chi tiết của một hệ thống backtesting dựa trên sự kiện, một chủ đề mà tôi đã đề cập thường xuyên trên QuantStart trong các bài viết trước đây.
Một backtest là việc áp dụng các quy tắc chiến lược giao dịch cho một tập hợp dữ liệu giá lịch sử. Đó là, nếu chúng ta xác định một bộ cơ chế nhập và xuất vào danh mục đầu tư tài sản, và áp dụng các quy tắc đó cho dữ liệu định giá lịch sử của các tài sản đó, chúng ta có thể cố gắng hiểu hiệu suất của "chiến lược giao dịch" này có thể đã đạt được trong quá khứ.
Một lần đã nói rằng
Các bài kiểm tra ngược cuối cùng giúp chúng ta quyết định liệu có đáng để giao dịch trực tiếp một bộ quy tắc chiến lược hay không. Nó cung cấp cho chúng ta một ý tưởng về cách một chiến lược có thể đã hoạt động trong quá khứ. Về cơ bản nó cho phép chúng ta lọc ra các quy tắc chiến lược xấu trước khi phân bổ bất kỳ vốn thực sự nào.
Thật dễ dàng để tạo ra backtests. Thật không may, kết quả backtest không phải là kết quả giao dịch trực tiếp. Thay vào đó, chúng là một mô hình thực tế. Một mô hình thường chứa nhiều giả định.
Có hai loại chủ yếu của backtest phần mềm - các hệ thống
Khi thiết kế phần mềm backtesting luôn có sự cân bằng giữa độ chính xác và độ phức tạp của việc thực hiện.
Có nhiều cạm bẫy liên quan đến backtesting. Tất cả chúng đều liên quan đến thực tế rằng backtest chỉ là một mô hình của thực tế. Một số cạm bẫy phổ biến hơn bao gồm:
Có một số vấn đề tinh tế hơn với backtesting mà không được thảo luận thường xuyên, nhưng vẫn vô cùng quan trọng để xem xét.
Rất nhiều đã được viết về các vấn đề với backtesting.
Một For-Loop Backtester là loại hệ thống backtesting đơn giản nhất và biến thể thường thấy nhất trong các bài đăng trên blog lượng tử, hoàn toàn đơn giản và minh bạch.
Về cơ bản, hệ thống For-Loop lặp đi lặp lại trong mỗi ngày giao dịch (hoặc thanh OHLC), thực hiện một số tính toán liên quan đến giá của tài sản, chẳng hạn như Mức trung bình động của đóng cửa, và sau đó mua hoặc bán một tài sản cụ thể (thường là với cùng giá đóng cửa, nhưng đôi khi là ngày sau đó).
Đây là mã giả cho một thuật toán như vậy:
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
Như bạn có thể thấy thiết kế của một hệ thống như vậy là vô cùng đơn giản. Điều này làm cho nó hấp dẫn để có được một cái nhìn đầu tiên về hiệu suất của một tập hợp quy tắc chiến lược cụ thể.
For-Loop backtesters rất đơn giản để thực hiện trong hầu hết các ngôn ngữ lập trình và rất nhanh để thực hiện.
Nhược điểm chính của các backtester For-Loop là chúng khá không thực tế. Chúng thường không có khả năng chi phí giao dịch trừ khi được thêm cụ thể. Thông thường các đơn đặt hàng được thực hiện ngay lập tức
Có tối thiểu sử dụng lại mã giữa hệ thống backtesting và hệ thống giao dịch trực tiếp. Điều này có nghĩa là mã thường cần phải được viết hai lần, giới thiệu khả năng có nhiều lỗi hơn.
For-Loop backtesters có xu hướng Look-Ahead Bias, do các lỗi với lập chỉ mục. Ví dụ, bạn nên sử dụng
For-Loop backtesters thực sự nên được sử dụng chỉ như một cơ chế lọc. Bạn có thể sử dụng chúng để loại bỏ các chiến lược rõ ràng là xấu, nhưng bạn nên vẫn hoài nghi về hiệu suất mạnh mẽ. Nghiên cứu thêm thường cần thiết. Chiến lược hiếm khi hoạt động tốt hơn trong giao dịch trực tiếp hơn là trong backtests!
Các backtester dựa trên sự kiện nằm ở đầu kia của quang phổ. Chúng tương tự như các triển khai cơ sở hạ tầng giao dịch trực tiếp.
Các hệ thống như vậy được chạy trong một vòng lặp lớn
Khi một sự kiện cụ thể được xác định, nó được định tuyến đến các mô-đun thích hợp trong cơ sở hạ tầng, xử lý sự kiện và sau đó có khả năng tạo ra các sự kiện mới trở lại hàng đợi.
Mã giả cho một hệ thống backtesting Event-Driven là như sau:
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
Như bạn có thể thấy, có một sự phụ thuộc nặng nề vào mô-đun xử lý danh mục đầu tư.
Có nhiều lợi thế khi sử dụng một Event-Driven backtester:
Trong khi những lợi thế rõ ràng, cũng có một số nhược điểm mạnh mẽ khi sử dụng một hệ thống phức tạp như vậy:
Trong phần này chúng ta sẽ xem xét phần mềm (cả nguồn mở và thương mại) tồn tại cho cả hệ thống For-Loop và hệ thống Event-Driven.
Đối với For-Loop backtesters, các ngôn ngữ / phần mềm lập trình chính được sử dụng bao gồm Python (với thư viện Pandas), R (và thư viện quantmod) và MatLab.
Thị trường cho các hệ thống Event-Driven lớn hơn nhiều, vì khách hàng / người dùng thường muốn phần mềm có khả năng kiểm tra lại và giao dịch trực tiếp trong một gói.
Các dịch vụ thương mại đắt tiền bao gồm Deltix và QuantHouse.
Các hệ thống backtesting dựa trên đám mây và giao dịch trực tiếp là tương đối mới.
Các tổ chức cũng thường xây dựng phần mềm của riêng họ. Điều này là do sự kết hợp của các hạn chế về quy định, quan hệ nhà đầu tư / báo cáo và tính kiểm toán.
Các nhà bán lẻ có thể lựa chọn giữa việc sử dụng cách tiếp cận
Về phần mềm mã nguồn mở, có nhiều thư viện có sẵn. Chúng chủ yếu được viết bằng Python (vì những lý do tôi sẽ phác thảo dưới đây) và bao gồm Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) và QSTrader (QuantStart
Tuy nhiên, một trong những khía cạnh quan trọng nhất là bất kể phần mềm nào bạn sử dụng cuối cùng, nó phải được ghép nối với một nguồn dữ liệu tài chính vững chắc như nhau.
Trong khi phần mềm chăm sóc các chi tiết cho chúng ta, nó che giấu chúng ta khỏi nhiều chi tiết thực hiện thường rất quan trọng khi chúng ta muốn mở rộng sự phức tạp của chiến lược giao dịch của chúng ta.
Mặc dù có một nền tảng như là một nhà phát triển phần mềm định lượng tôi không cá nhân quan tâm đến
Chúng ta chỉ nên quan tâm đến những gì có hiệu quả.
Python là một ngôn ngữ lập trình cực kỳ dễ học và thường là ngôn ngữ đầu tiên mà mọi người tiếp xúc khi họ quyết định học lập trình.
Nó có một số thư viện quant / khoa học dữ liệu / máy học (ML) đặc biệt trong NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 và Statsmodels.
Nó là tuyệt vời cho việc xây dựng cả For-Loop và các hệ thống backtesting dựa trên sự kiện.
Có lẽ nhược điểm lớn nhất của nó là nó khá chậm để thực thi khi so sánh với các ngôn ngữ khác như C ++. Tuy nhiên, công việc đang được thực hiện để cải thiện vấn đề này và theo thời gian Python đang trở nên nhanh hơn.
R là một môi trường lập trình thống kê, chứ không phải là một ngôn ngữ lập trình hạng nhất đầy đủ (mặc dù một số người có thể lập luận khác!). Nó được thiết kế chủ yếu để thực hiện phân tích thống kê tiên tiến cho chuỗi thời gian, thống kê cổ điển / tần số, thống kê Bayesian, học máy và phân tích dữ liệu thăm dò.
Nó được sử dụng rộng rãi để kiểm tra lại For-Loop, thường thông qua thư viện quantmod, nhưng không đặc biệt phù hợp với các hệ thống điều khiển sự kiện hoặc giao dịch trực tiếp.
C ++ có danh tiếng là cực kỳ nhanh. Hầu hết các tính toán hiệu suất cao khoa học được thực hiện bằng Fortran hoặc C ++. Đây là lợi thế chính của nó. Do đó, nếu bạn đang xem xét giao dịch tần số cao, hoặc làm việc trên các hệ thống cũ trong các tổ chức lớn, thì C ++ có thể là một điều cần thiết.
Thật không may, nó rất đau đớn để thực hiện nghiên cứu chiến lược. Do được đánh máy tĩnh, nó khá khó để tải, đọc và định dạng dữ liệu dễ dàng so với Python hoặc R.
Mặc dù tuổi tác tương đối của nó, nó gần đây đã được hiện đại hóa đáng kể với việc giới thiệu C ++ 11 / C ++ 14 và các tiêu chuẩn tinh chỉnh hơn nữa.
Bạn cũng có thể muốn xem xét Java, Scala, C #, Julia và nhiều ngôn ngữ chức năng. Tuy nhiên, khuyến nghị của tôi là gắn bó với Python, R và / hoặc C ++, vì cộng đồng giao dịch lượng lớn hơn nhiều.
Câu trả lời: Vâng!
Đó là một kinh nghiệm học tập tuyệt vời để viết hệ thống kiểm tra hậu quả của riêng bạn. Thứ nhất, nó buộc bạn phải xem xét tất cả các khía cạnh của cơ sở hạ tầng giao dịch của bạn, không chỉ dành nhiều giờ làm việc trên một chiến lược cụ thể.
Ngay cả khi bạn không sử dụng hệ thống để giao dịch trực tiếp, nó sẽ cung cấp cho bạn một số lượng lớn câu hỏi mà bạn nên hỏi các nhà cung cấp backtesting thương mại hoặc FOSS của bạn.
Ví dụ: Hệ thống trực tiếp hiện tại của bạn khác với mô phỏng backtest của bạn như thế nào về:
Trong khi các hệ thống điều khiển sự kiện không phải là nhanh chóng hoặc dễ dàng để viết, kinh nghiệm sẽ trả cổ tức giáo dục lớn sau này trong sự nghiệp giao dịch lượng tử của bạn.
Làm thế nào bạn viết một hệ thống như vậy?
Cách tốt nhất để bắt đầu là đơn giản là tải xuống Zipline, QSTrader, PyAlgoTrade, PySystemTrade vv và thử đọc thông qua tài liệu và mã. Tất cả đều được viết bằng Python (do những lý do tôi đã nêu ở trên) và may mắn là Python rất giống như đọc mã giả. nghĩa là, nó rất dễ làm theo.
Rob Carver, tại Investment Idiocy cũng đưa ra cách tiếp cận của mình để xây dựng các hệ thống như vậy để giao dịch tương lai.
Hãy nhớ rằng bạn không cần phải là một chuyên gia vào ngày # 1. Bạn có thể làm nó chậm rãi, từng ngày, mô-đun từng mô-đun. Nếu bạn cần sự giúp đỡ, bạn luôn có thể liên hệ với tôi hoặc các blogger lượng tử sẵn sàng khác. Xem cuối bài viết cho email liên hệ của tôi.
Bây giờ tôi sẽ thảo luận về các mô-đun thường được tìm thấy trong nhiều hệ thống kiểm tra hậu trường dựa trên sự kiện.
Đây là nơi tất cả các dữ liệu giá lịch sử được lưu trữ, cùng với lịch sử giao dịch của bạn, một lần trực tiếp.
Thay vào đó, chúng tôi sử dụng một cơ sở dữ liệu hoặc hệ thống tệp
Lý tưởng nhất, chúng ta muốn thu thập và lưu trữ dữ liệu ở mức điểm vì nó cho chúng ta một ý tưởng về chênh lệch giao dịch. Nó cũng có nghĩa là chúng ta có thể xây dựng thanh OHLC của riêng mình, ở tần số thấp hơn, nếu muốn.
Chúng ta nên luôn luôn nhận thức được việc xử lý các hành động của công ty (như chia cổ phiếu và cổ tức), thiên vị sinh tồn (loại bỏ cổ phiếu) cũng như theo dõi sự khác biệt múi giờ giữa các sàn giao dịch khác nhau.
Các công ty cá nhân / bán lẻ có thể cạnh tranh ở đây vì nhiều công nghệ cơ sở dữ liệu chất lượng sản xuất đã trưởng thành, miễn phí và nguồn mở.
Vẫn còn rất nhiều thị trường và chiến lược quá nhỏ để các quỹ lớn quan tâm.
Các mô-đun chiến lược giao dịch trong một hệ thống Event-Driven thường chạy một số loại cơ chế dự đoán hoặc lọc trên dữ liệu thị trường mới.
Nó nhận được dữ liệu thanh hoặc dấu chấm và sau đó sử dụng các cơ chế này để tạo ra một tín hiệu giao dịch để mua hoặc bán một tài sản.
95% cuộc thảo luận trên blog lượng thường xoay quanh các chiến lược giao dịch. Cá nhân tôi tin rằng nó nên giống như 20%. Điều này là bởi vì tôi nghĩ rằng nó dễ dàng hơn nhiều để tăng lợi nhuận mong đợi bằng cách giảm chi phí thông qua quản lý rủi ro và kích thước vị trí thích hợp, hơn là theo đuổi các chiến lược với
"Trái tim" của một backtester dựa trên sự kiện là hệ thống quản lý danh mục đầu tư và đơn đặt hàng.
Mục tiêu của hệ thống này là chuyển từ danh mục đầu tư hiện tại sang danh mục đầu tư mong muốn, đồng thời giảm thiểu rủi ro và giảm chi phí giao dịch.
Mô-đun này liên kết các khả năng chiến lược, rủi ro, kích thước vị trí và thực thi lệnh của hệ thống. Nó cũng xử lý các tính toán vị trí trong khi kiểm tra lại để bắt chước các tính toán của công ty môi giới.
Lợi thế chính của việc sử dụng một hệ thống phức tạp như vậy là nó cho phép xử lý nhiều công cụ tài chính khác nhau dưới một danh mục đầu tư duy nhất. Điều này là cần thiết cho các danh mục đầu tư theo kiểu tổ chức với phòng ngừa rủi ro. Sự phức tạp như vậy rất khó để mã hóa trong một hệ thống backtesting For-Loop.
Phân biệt quản lý rủi ro thành mô-đun riêng có thể cực kỳ thuận lợi. mô-đun có thể sửa đổi, thêm hoặc phủ quyết các lệnh được gửi từ danh mục đầu tư.
Đặc biệt, mô-đun rủi ro có thể thêm các phòng hộ để duy trì tính trung lập thị trường. Nó có thể giảm kích thước lệnh do rủi ro trong lĩnh vực hoặc giới hạn ADV. Nó có thể phủ quyết hoàn toàn giao dịch nếu chênh lệch quá rộng hoặc phí quá lớn so với kích thước giao dịch.
Một mô-đun định kích thước vị trí riêng biệt có thể thực hiện ước tính biến động và quy tắc định kích thước vị trí như đòn bẩy Kelly.
Tuy nhiên, đây có lẽ là sự khác biệt lớn nhất giữa cách các tổ chức và một số nhà giao dịch bán lẻ suy nghĩ về giao dịch của họ. Có lẽ cách đơn giản nhất để có được lợi nhuận tốt hơn là bắt đầu thực hiện quản lý rủi ro và kích thước vị trí theo cách này.
Trong cuộc sống thực chúng ta không bao giờ được đảm bảo sẽ có một thị trường đầy đủ ở giữa điểm!
Chúng ta phải xem xét các vấn đề giao dịch như dung lượng, chênh lệch, phí, trượt, tác động thị trường và các mối quan tâm thực thi thuật toán khác, nếu không lợi nhuận kiểm tra ngược của chúng tôi có thể sẽ được đánh giá quá cao.
Cách tiếp cận mô-đun của một hệ thống Event-Driven cho phép chúng tôi dễ dàng chuyển ra BacktestExecutionHandler với LiveExecutionHandler và triển khai đến máy chủ từ xa.
Chúng ta cũng có thể dễ dàng thêm nhiều công ty môi giới sử dụng khái niệm OOP của
Một vấn đề cần lưu ý là
Các quant bán lẻ có thể và nên mượn các kỹ thuật báo cáo phức tạp được sử dụng bởi các quant tổ chức. Các công cụ như vậy bao gồm các bảng điều khiển trực tiếp của danh mục đầu tư và rủi ro tương ứng, một sự khác biệt hoặc delta giữa vốn chủ sở hữu trực tiếp và vốn chủ sở hữu trực tiếp, cùng với tất cả các số liệu thông thường như chi phí cho mỗi giao dịch, phân phối lợi nhuận, mốc nước cao (HWM), thu hút tối đa, thời gian trễ giao dịch trung bình cũng như alpha / beta so với một chỉ số chuẩn.
Cần phải cải tiến liên tục cơ sở hạ tầng này. Điều này thực sự có thể làm tăng lợi nhuận trong dài hạn, chỉ bằng cách loại bỏ các lỗi và cải thiện các vấn đề như thời gian trễ giao dịch. Đừng chỉ cố gắng cải thiện chiến lược lớn nhất thế giới (WGS).
WGS cuối cùng sẽ bị xói mòn do sự suy giảm alpha. Những người khác cuối cùng sẽ phát hiện ra lợi thế và sẽ điều chỉnh lợi nhuận. Tuy nhiên, cơ sở hạ tầng giao dịch mạnh mẽ, đường ống nghiên cứu chiến lược vững chắc và học tập liên tục là những cách tuyệt vời để tránh số phận này.
Tối ưu hóa cơ sở hạ tầng có thể
Việc triển khai đến một máy chủ từ xa, cùng với việc giám sát rộng rãi hệ thống từ xa này, là hoàn toàn quan trọng đối với các hệ thống cấp tổ chức.
Một hệ thống mạnh mẽ phải được triển khai từ xa trong đám mây hoặc nằm gần một sàn giao dịch. băng thông rộng tại nhà, nguồn điện và các yếu tố khác có nghĩa là việc sử dụng máy tính để bàn / máy tính xách tay tại nhà là quá không đáng tin cậy.
Các vấn đề chính khi xem xét triển khai từ xa bao gồm; phần cứng giám sát, chẳng hạn như CPU, RAM / swap, đĩa và mạng I / O, khả năng sẵn có cao và dư thừa của hệ thống, một kế hoạch sao lưu và khôi phục được suy nghĩ kỹ lưỡng, ghi chép rộng rãi tất cả các khía cạnh của hệ thống cũng như tích hợp liên tục, kiểm tra đơn vị và kiểm soát phiên bản.
Hãy nhớ định luật của Murphy - Nếu nó có thể thất bại, nó sẽ thất bại.
Có nhiều nhà cung cấp cung cấp các triển khai đám mây tương đối đơn giản, bao gồm Amazon Web Services, Microsoft Azure, Google và Rackspace.
Thật không may, không có giải pháp nhanh chóng trong giao dịch số lượng. Nó liên quan đến rất nhiều công việc chăm chỉ và học tập để thành công.
Có lẽ một trở ngại lớn đối với người mới bắt đầu (và một số lượng trung gian!) là họ tập trung quá nhiều vào "chiến lược" tốt nhất. Những chiến lược như vậy luôn luôn cuối cùng rơi vào sự suy giảm alpha và do đó trở nên không có lợi nhuận. Do đó, cần phải liên tục nghiên cứu các chiến lược mới để thêm vào danh mục đầu tư. Về cơ bản, đường ống "chiến lược" nên luôn luôn đầy đủ.
Nó cũng đáng để đầu tư rất nhiều thời gian vào cơ sở hạ tầng giao dịch của bạn. Dành thời gian cho các vấn đề như triển khai và giám sát. Luôn cố gắng giảm chi phí giao dịch, vì lợi nhuận là về việc giảm chi phí như thu nhập giao dịch.
Tôi khuyên bạn nên viết hệ thống backtesting của riêng bạn chỉ để học. Bạn có thể sử dụng nó và liên tục cải thiện nó hoặc bạn có thể tìm một nhà cung cấp và sau đó hỏi họ tất cả các câu hỏi mà bạn đã phát hiện ra khi bạn xây dựng của riêng bạn. Nó chắc chắn sẽ làm cho bạn nhận thức được những hạn chế của các hệ thống có sẵn trên thị trường.
Cuối cùng, luôn đọc, học hỏi và cải thiện. Có rất nhiều sách giáo khoa, tạp chí thương mại, tạp chí học thuật, blog lượng, diễn đàn và tạp chí thảo luận về tất cả các khía cạnh của giao dịch. Để có những ý tưởng chiến lược tiên tiến hơn, tôi khuyên bạn nên SSRN và arXiv - Tài chính định lượng.