Die Redakteure des QuantStart-Portals haben
Material darüber geschrieben, was Sie wissen sollten, wenn Sie mit der Entwicklung Ihres eigenen Systems zum Testen von Handelsstrategien beginnen. Wir haben einige der Probleme untersucht, die in dem Artikel weiter oben im Blog angesprochen wurden. Deshalb haben wir dieses Mal eine angepasste Nacherzählung von Thesen darüber vorbereitet, mit welchen Problemen Entwickler konfrontiert sind, was der Unterschied zwischen Backtests verschiedener Typen ist und welche Vor- und Nachteile sie haben.
Was ist Backtester?
Backtest ist die Anwendung der Regeln einer Handelsstrategie auf eine Reihe historischer Daten zu den Preisen von Finanzinstrumenten. Das Wesentliche des Ansatzes ist, dass, wenn wir einen Mechanismus entwickeln, um den Zeitpunkt für den Eintritt und den Ausstieg aus einer Position (Kauf / Verkauf), beispielsweise Aktien aus einem bestimmten Portfolio, zu bestimmen und die daraus resultierenden Regeln auf historische Daten anzuwenden, dies eine Vorstellung von der Produktivität der Handelsstrategie „in der Vergangenheit“ gibt ".
Jemand hat einmal gesagt, dass "alle Modelle falsch sind, aber einige nützlich sind". Dieser Satz eignet sich hervorragend zum Backtesting. Systeme zur historischen Prüfung von Finanzstrategien helfen festzustellen, ob es sich lohnt, das bestehende Regelwerk auf den realen Handel anzuwenden. Wenn wir wissen, wie sich eine Strategie in der Vergangenheit verhalten könnte, hilft dies dabei, schlechte Strategien herauszufiltern, ohne dass echte finanzielle Verluste erforderlich sind.
Das Problem ist, dass das Backtesting-Ergebnis nichts mit den Ergebnissen des realen Handels an der Börse zu tun hat. Dies ist nur ein Modell der Realität. Ein Modell, das oft viele Annahmen enthält.
Es gibt zwei Haupttypen von Backtestern - for-loop und ereignisgesteuert.
Bei der Entwicklung solcher Systeme ist immer ein Kompromiss zwischen Genauigkeit und Komplexität der Implementierung erforderlich. Diese beiden Arten von Backtestern bieten die gesamte Bandbreite an Optionen für einen solchen Kompromiss.
Backtesting-Herausforderungen
Das Testen historischer Daten ist mit vielen Schwierigkeiten verbunden. Sie alle hängen damit zusammen, dass der gesamte Prozess nur eine Simulation der Realität ist. Hier sind nur einige davon:
- In-Sample-Tests - Ein Problem tritt auf, wenn dieselben Daten für das Training von Handelsmodellen und für deren weitere Tests verwendet werden. In diesem Fall wird die angezeigte Produktivität erheblich gemindert - da das Ergebnis auf einem bisher bekannten Datensystem erzielt wird. In der Realität unterscheiden sich die Daten meistens erheblich vom Training. In der Tat ist dies eine Form der Umschulung.
- Überlebensfehler - Aktienindizes (z. B. S & P500) sind durch einen Kotierungs- und Delisting-Prozess gekennzeichnet, wenn bestimmte Aktien und Finanzinstrumente erscheinen oder von ihnen ausgeschlossen sind. Wenn diese Änderungen beim Backtesting nicht berücksichtigt werden, kann eine Strategie, die Aktien von Unternehmen nicht berücksichtigt, die aufgrund geringer Kapitalisierung aus dem Index ausgeschlossen wurden, als erfolgreich angesehen werden. Um solche Probleme zu vermeiden, müssen Sie beim Ausführen von Backtests über einen längeren Zeitraum Daten verwenden, die nicht dem Fehler des Überlebenden unterliegen.
- Vorhersagefehler (Look-Ahead-Bias) - Daten aus der Zukunft können sich auch auf das Backtest-Ergebnis auswirken. Betrachten Sie beispielsweise den Fall, in dem ein linearer Regressionsindex in einem bestimmten Zeitintervall berechnet wird. Wenn dieser Indikator dann in derselben Stichprobe verwendet wird, stellt sich heraus, dass Daten aus der Zukunft in ihn eingedrungen sind, was bedeutet, dass die resultierende Produktivität der Strategie erheblich abgewertet wird. Ereignisorientierte Backtester helfen bei der Lösung dieses Problems.
- Änderung der Marktbedingungen - Finanzmarktparameter sind nicht stationär. Dies bedeutet, dass Prozesse, die zu Aktienkursbewegungen führen, nicht auf zeitlich konstanten Parametern beruhen. Diese Tatsache erschwert die Verallgemeinerung parametrisierter Modelle (viele Handelsstrategien sind Sonderfälle solcher Strategien), was dazu führt, dass die Wirksamkeit der Strategie auf historische Daten viel besser ist als im realen Handel.
- Transaktionskosten - Viele zyklische Backtester berücksichtigen nicht einmal die grundlegendsten Informationen zu Transaktionskosten, wie z. B. verschiedene Gebühren und Entgelte. Oft sündigen Autoren wissenschaftlicher Arbeiten, die es vorziehen, sich nicht an solche Kleinigkeiten zu bücken. Es ist sehr einfach, eine Strategie zu finden, die unter idealen Bedingungen ohne Kosten sehr profitabel ist. Das Problem ist, dass solche Strategien beim Handel unter realen Bedingungen zutiefst unrentabel sein können. Es ist äußerst wichtig, den Spread, die Marktsituation, verschiedene Gebühren und den Schlupf zu berücksichtigen (bei Transaktionen mit hochvolatilen Vermögenswerten kann der reale Preis der Transaktion geringfügig von dem abweichen, der bei der Einreichung des Antrags erwartet wurde - sowohl in günstiger als auch in negativer Richtung).
Es gibt auch andere Themen, die nicht oft diskutiert werden, aber dennoch äußerst wichtig für die Erstellung eines Qualitäts-Backtesters sind. Unter ihnen:
- OHLC-Daten sind Informationen über den Eröffnungskurs, den höchsten Preis eines Finanzinstruments während der Handelssitzung, seinen niedrigsten Wert und den Schlusskurs der Handelsperiode (Open-High-Low-Close-Chart, OHLC). Es wird normalerweise aus Quellen wie Yahoo Finance importiert. In diesem Fall kann es sich um eine Kombination verschiedener Datenfeeds handeln. Dies bedeutet, dass es schwierig sein wird, extreme Werte (einschließlich hoher und niedriger Preise) für ein Echtzeit-Handelssystem zu erhalten. Dies muss auch im Handelsmodell berücksichtigt werden.
- Kapazitive Einschränkungen - Backtesting ist verlockend, unendlich viel Geld zu verwenden. In der Realität ist die Menge der für den Handel verfügbaren Mittel immer begrenzt (ebenso wie die mögliche Menge der für den Margin-Handel geliehenen Mittel). Es ist auch wichtig, das durchschnittliche tägliche Handelsvolumenlimit (Average Daily Volume, ADV) nicht zu vergessen, insbesondere für Aktien mit geringer Liquidität, wenn das Risiko hoch ist, dass das Handelssystem zu einer echten Preisänderung führt. Dieser Markteffekt sollte ebenfalls berücksichtigt werden.
- Benchmark-Auswahl - Es muss die Frage beantwortet werden, ob der Benchmark richtig ausgewählt ist, mit dem die getestete Strategie verglichen wird. Wenn Sie beispielsweise Warentermingeschäfte handeln, die für den S & P500-Index neutral sind, lohnt es sich, diesen Index als Benchmark zu verwenden? Es ist wahrscheinlich, dass ein Korb mit anderen Rohstofffonds die geeignetere Wahl ist.
- Robustheit - Wenn Sie die Startzeit der Strategie während des Backtests ändern, wie stark wirkt sich dies auf das Ergebnis aus? Bei langfristigen Strategien sollte die Startzeit ihrer Arbeit die Produktivität nicht ernsthaft beeinträchtigen - es spielt keine Rolle, ob der Backtest am Montag oder Donnerstag begann. Wenn es zu empfindlich für die Anfangsbedingungen ist, bedeutet dies, dass es keine Möglichkeit gibt, seine mögliche Produktivität zu Beginn des realen Handels vorherzusagen.
- Umschulung und Varianz - Wir haben bereits oben auf Umschulungsprobleme eingegangen, aber dies ist ein umfassenderes Problem, das allen überwachten Methoden des maschinellen Lernens innewohnt. Dieses Problem kann nur durch sorgfältigen Einsatz von Kreuzvalidierungstechniken gelöst werden. Und selbst in diesem Fall sollte man äußerst vorsichtig sein, wenn man Strategien an Rauschen in Testdatensätzen anpasst.
- Psychologische Toleranz - Psychologie wird bei der Erstellung automatisierter Handelssysteme häufig ignoriert, da ihr Einfluss durch Algorithmen minimiert werden sollte. Menschen bleiben jedoch menschlich, auch wenn sie nicht mit Händen, sondern mit Hilfe von Robotern handeln. Dies kann sich auf die Ergebnisse auswirken. Wenn beispielsweise während eines Backtests eine Inanspruchnahme einer Einzahlung von 50% als akzeptables Risiko erscheint, stellt sich der Verlust der Hälfte des Wertes von Vermögenswerten in Wirklichkeit als viel traumatischer heraus. In einer solchen Situation ist es nicht einfach, ungeplanten Aktionen zu widerstehen.
Das ist alles mit den Problemen beim Testen der Geschichte. Nun wenden wir uns für solche Tests der Beschreibung der Systeme selbst zu.
Zwei Arten von Rückentestern
Betrachten Sie zunächst zyklische Systeme. Dies ist die einfachste Art von Backtester, die am häufigsten in verschiedenen Finanzblog-Posts beschrieben wird.
Loop Backtest
Sie funktionieren folgendermaßen: Das System durchläuft einfach jeden Handelstag (oder OHLC-Balken), führt Berechnungen in Bezug auf den Preis des gewünschten Vermögenswerts durch (berechnet beispielsweise gleitende durchschnittliche Schlusskurse) und führt dann die entsprechende Operation aus (Eingabe einer Long- oder Short-Position). Weitere Iterationen werden fortgesetzt. Dabei werden Informationen zur Performance gespeichert, um daraus ein Diagramm (Eigenkapitalkurve) zu erstellen.
So sieht der Pseudocode eines solchen Algorithmus aus:
for each trading bar: do_something_with_prices(); buy_sell_or_hold_something(); next_bar();PythonCopy
Wie Sie sehen können, ist das System äußerst einfach, was solche Backtester zu einer hervorragenden Option macht, um erste Schätzungen über die Aussichten des Handelssystems zu erhalten.
Vorteile
Der zyklische Backtester ist mit fast jeder Programmiersprache sehr einfach und schnell zu implementieren. Dies ist nützlich, wenn Sie die Wirkung vieler verschiedener Parameter testen möchten.
Nachteile
Der Hauptnachteil sind die unrealistischen Ergebnisse. In zyklischen Backtestern gibt es häufig nicht einmal eine grundlegende Funktionalität zur Abrechnung von Transaktionskosten, sondern muss separat implementiert werden. Ebenfalls häufig verwendet werden nur MARKET-Bestellungen.
Außerdem ist die Möglichkeit, Code für ein Test- und Produktivsystem wiederzuverwenden, minimal, sodass Sie ihn erneut schreiben müssen. Dies erhöht die Wahrscheinlichkeit von Softwarefehlern.
Loopback-Tester sind anfällig für Vorhersagefehler. Sie sollten ausschließlich als Filterwerkzeug verwendet werden, um offensichtlich erfolglose Strategien abzulehnen. Gleichzeitig ist es wichtig, Strategien, die gute Ergebnisse gezeigt haben, äußerst skeptisch gegenüberzustehen. Es ist wichtig, sich daran zu erinnern, dass Strategien im wirklichen Leben selten besser abschneiden als bei einem Backtest.
Ereignisorientierte Systeme
Systeme dieses Typs befinden sich auf der gegenüberliegenden Seite des Spektrums. Sie sind der Realität viel näher. Normalerweise arbeiten sie in großen while-Schleifen, in denen ständig nach „Ereignissen“ in einer speziellen „Ereigniswarteschlange“ gesucht wird, einschließlich:
- Zecken - die Entstehung neuer Marktdaten;
- Signalisierungsereignisse - das Auftreten von Handelssignalen;
- Auftragsereignis - Ein Auftrag zum Abschließen einer Transaktion kann an das Brokersystem gesendet werden.
- Transaktionsereignis - Empfang von Informationen über die Ausführung des Antrags durch den Broker.
Wenn ein bestimmtes Ereignis erkannt wird, wird es zur weiteren Verarbeitung an das entsprechende Modul in der Infrastruktur des Handelssystems übertragen und generiert möglicherweise neue Ereignisse, die erneut in die Warteschlange fallen.
Der Pseudocode eines solchen Backtesters lautet wie folgt:
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);
Wie Sie sehen, ist das System stark vom Portfolio-Verarbeitungsmodul abhängig - dies ist das eigentliche Herz in ereignisorientierten Systemen.
Vorteile
Backtester dieses Typs haben viele Vorteile:
- Verringerung der Wahrscheinlichkeit von Prognosefehlern - Aufgrund der Struktur, die eine schrittweise Übertragung von Nachrichten voraussetzt, ist es weniger wahrscheinlich, dass Prognosefehler in ereignisorientierten Systemen auftreten, zumindest auf Handelsebene. Die Wahrscheinlichkeit ihres Auftretens bleibt jedoch erhalten, da Fehler im Modell selbst enthalten sein können.
- Möglichkeit zur Wiederverwendung von Code - Um die Strategie im realen Handel zu verwenden, müssen Sie nur das Datenverarbeitungsmodul und die Order Execution Engine ersetzen. Die Beschreibung der Strategie, das Modul Risikomanagement und Positionsmanagement, ein Code zur Bewertung der Produktivität des Systems - all dies kann ohne Änderungen verwendet werden. Dies verringert die Wahrscheinlichkeit neuer Fehler.
- Portfolioebene - Ereignisgesteuerte Strategien erleichtern das Denken auf Portfolioebene. Dies erleichtert letztendlich Änderungen an der Strategie und die Entwicklung von Absicherungsmethoden.
- „Richtiges“ Risikomanagement - In solchen Systemen ist es einfacher, das Risikomanagement zu „modulieren“. Ein Trader kann problemlos Techniken wie das Kelly-Kriterium verwenden und auch verschiedene Warnungen einschließen, Grenzwerte festlegen (z. B. für die Volatilität).
- Remote-Bereitstellung und -Überwachung - Das modulare Prinzip des Schreibens von Code vereinfacht die Bereitstellung in der Cloud oder gemäß dem Austauschkollokationsschema.
Nachteile
Die Vorteile ereignisorientierter Systeme sind verständlich, es gibt jedoch gewisse Nachteile. Unter ihnen:
- Komplexer Code - Die Entwicklung eines Systems, das vollständig durch Tests abgedeckt ist, erfordert im Vollzeitmodus Wochen und Monate Arbeit.
- Objektorientierung - Der modulare Aufbau des Systems erfordert einen objektorientierten Programmieransatz. Wir brauchen also eine Sprache, die diese Prinzipien unterstützt. Unit-Tests werden nicht einfacher.
- Hohe Eintrittsschwelle - Ein Neuling in der Programmierung kann ein solches System nicht erstellen. Es sind umfangreiche technische Erfahrungen erforderlich, die es ermöglichen, Code zu schreiben, Protokollierung zu implementieren, Komponententests durchzuführen, Versionskontrolle zu implementieren und kontinuierliche Integrationspraktiken anzuwenden.
- Niedrige Geschwindigkeit - Ein Ansatz, bei dem Nachrichten innerhalb des Systems nacheinander auf verschiedenen Ebenen übertragen werden, verlangsamt die Ausführungsgeschwindigkeit von Anwendungen im Vergleich zum vektorisierten zyklischen Ansatz. Das Berechnen verschiedener Parameterkombinationen kann zeitaufwändig sein.
Sonstige finanz- und börsenbezogene Materialien von ITI Capital :