Les éditeurs du portail QuantStart ont rédigé des
informations sur ce que vous devez savoir lorsque vous commencez à développer votre propre système pour tester les stratégies de trading. Nous avons examiné certaines des questions soulevées dans l'article plus tôt dans le blog, cette fois-ci, nous avons préparé une nouvelle version adaptée des thèses sur les problèmes auxquels les développeurs sont confrontés, quelle est la différence entre les backtests de différents types et quels sont leurs avantages et inconvénients.
Qu'est-ce que Backtester
Le backtest est l'application des règles d'une stratégie de trading à un ensemble de données historiques sur les prix des instruments financiers. L'essence de l'approche est que si nous développons un mécanisme pour déterminer le moment d'entrer et de sortir d'une position (acheter / vendre), par exemple, des actions d'un certain portefeuille, et appliquer les règles résultantes aux données historiques, cela donnera une idée de la productivité de la stratégie de négociation «dans le passé ".
Quelqu'un a dit un jour que "tous les modèles sont faux, mais certains sont utiles". Cette phrase est idéale pour les backtests. Les systèmes de test historique des stratégies financières aident à déterminer s'il vaut la peine d'appliquer l'ensemble de règles existant au trading réel. Si nous savons comment une stratégie pourrait se comporter dans le passé, cela aidera à filtrer les mauvaises stratégies sans avoir besoin de pertes financières réelles.
Le problème est que le résultat du backtesting n'a rien à voir avec les résultats du vrai trading sur la bourse. Ce n'est qu'un modèle de réalité. Un modèle qui contient souvent de nombreuses hypothèses.
Il existe deux principaux types de backtesters - for-loop et event-driven.
Lors du développement de tels systèmes, il est toujours nécessaire de trouver un compromis entre précision et complexité de mise en œuvre. Ces deux types de backtesters représentent la gamme complète d'options pour un tel compromis.
Défis de backtesting
Les tests sur les données historiques posent de nombreuses difficultés. Tous sont liés au fait que l'ensemble du processus n'est qu'une simulation de la réalité. En voici quelques-unes:
- Tests dans l'échantillon - un problème survient lors de l'utilisation des mêmes données pour la formation de modèles de trading et pour leurs tests ultérieurs. Dans ce cas, la productivité affichée est considérablement dépréciée - car le résultat est obtenu sur un système de données précédemment connu. En réalité, les données différeront le plus souvent de manière significative de la formation. En fait, c'est une forme de recyclage.
- Erreur du survivant - les indices boursiers (par exemple, le S & P500) sont caractérisés par un processus de cotation et de radiation lorsque certains stocks et instruments financiers apparaissent ou en sont exclus. Si ces changements ne sont pas pris en compte lors des backtests, une stratégie qui ne prend pas en compte les actions des sociétés exclues de l'indice en raison d'une faible capitalisation peut être considérée comme réussie. Pour éviter de tels problèmes, lors de l'exécution de backtests sur de longues périodes, vous devez utiliser des données qui ne sont pas soumises à l'erreur du survivant.
- Erreurs de prédiction (biais d'anticipation) - les données du futur peuvent également affecter le résultat du backtest. Par exemple, considérons le cas où un indice de régression linéaire est calculé à un certain intervalle de temps. Si cet indicateur est ensuite utilisé dans le même échantillon, il s'avère que les données du futur y pénètrent, ce qui signifie que la productivité résultante de la stratégie est fortement dépréciée. Les backtesters orientés événements aident à résoudre ce problème.
- Changement des conditions du marché - les paramètres des marchés financiers ne sont pas stationnaires. Cela signifie que les processus entraînant des mouvements de cours des actions ne reposent pas sur des paramètres constants dans le temps. Ce fait complique la généralisation des modèles paramétrés (de nombreuses stratégies de trading sont des cas particuliers de telles stratégies), ce qui conduit au fait que l'efficacité de la stratégie sur les données historiques est bien meilleure que dans le trading réel.
- Coûts de transaction - de nombreux backtesters cycliques ne prennent pas en compte même les informations les plus élémentaires sur les coûts de transaction, tels que divers frais et charges. Souvent, les auteurs d'articles scientifiques pèchent qui préfèrent ne pas se pencher sur de telles bagatelles. Trouver une stratégie très rentable dans des conditions idéales sans frais est très simple. Le problème est que lors de transactions dans des conditions réelles, de telles stratégies peuvent être profondément non rentables. Il est extrêmement important de prendre en compte l'écart, la situation du marché, les divers frais, le glissement (dans les transactions avec des actifs très volatils, le prix réel de la transaction peut différer légèrement de celui qui était attendu lors du dépôt de la demande - à la fois dans le sens favorable et dans le négatif).
Il y a aussi d'autres questions qui ne sont pas souvent discutées, mais néanmoins extrêmement importantes pour créer un backtester de qualité. Parmi eux:
- Les données OHLC sont des informations sur le prix d'ouverture, le prix le plus élevé d'un instrument financier pendant la séance de négociation, sa valeur la plus basse et le prix de clôture de la période de négociation (graphique ouvert-haut-bas-fermé, OHLC). Il est généralement importé de sources telles que Yahoo Finance. Dans ce cas, il peut s'agir d'une combinaison de différents flux de données. Cela signifie qu'il sera difficile d'obtenir des valeurs extrêmes (y compris des prix élevés et bas) pour un système commercial en temps réel. Cela doit également être pris en compte dans le modèle commercial.
- Limitations capacitives - Le backtesting est tentant d'utiliser une offre infinie d'argent. En réalité, le montant des fonds disponibles pour le trading est toujours limité (tout comme le montant possible des fonds empruntés pour le trading sur marge). Il est également important de ne pas oublier la limite de volume de négociation quotidien moyen (Volume quotidien moyen, ADV), en particulier pour les actions à faible liquidité, lorsque le risque est élevé que le système de négociation entraîne une réelle variation des prix. Cet effet de marché doit également être pris en considération.
- Sélection du benchmark - il est nécessaire de répondre à la question de savoir si le benchmark est correctement sélectionné avec lequel la stratégie testée sera comparée. Par exemple, si vous négociez des contrats à terme sur matières premières neutres par rapport à l'indice S & P500, cela vaut-il la peine d'utiliser cet indice comme référence? Il est probable qu'un panier d'autres fonds de matières premières sera un choix plus approprié.
- Robustesse - si vous modifiez l'heure de début de la stratégie pendant le backtest, dans quelle mesure cela affecte-t-il le résultat? Pour les stratégies à long terme, l'heure de début de leur travail ne devrait pas affecter sérieusement la productivité - peu importe si le backtest a commencé lundi ou jeudi. S'il est trop sensible aux conditions initiales, cela signifie qu'il n'y a aucun moyen de prédire sa productivité possible au début du vrai trading.
- Recyclage et variance - nous avons déjà abordé les problèmes de recyclage ci-dessus, mais il s'agit d'un problème plus large inhérent à toutes les méthodes supervisées d'apprentissage automatique. Ce problème ne peut être résolu que par une utilisation prudente des techniques de validation croisée. Et même dans ce cas, il faut être extrêmement prudent lors de l'adaptation des stratégies au bruit dans les ensembles de données de test.
- Tolérance psychologique - la psychologie est souvent ignorée lors de la création de systèmes de trading automatisés, car son influence doit être minimisée par des algorithmes. Cependant, les gens restent humains, même lorsqu'ils commercent non pas avec les mains, mais avec l'aide de robots. Par conséquent, cela peut affecter les résultats. Par exemple, si lors d'un backtest un prélèvement d'un acompte de 50% peut sembler un risque acceptable, alors en réalité la perte de la moitié de la valeur des actifs s'avère être une expérience beaucoup plus traumatisante. Il n'est pas facile de résister à des actions imprévues dans une telle situation.
C’est tout avec les problèmes de tests sur l’historique, nous passons maintenant à la description des systèmes eux-mêmes pour ces tests.
Deux types de dos testeurs
Considérons d'abord les systèmes cycliques. Il s'agit du type de backtester le plus simple qui est le plus souvent décrit dans divers articles de blog de finance.
Loop Backtest
Ils fonctionnent comme ceci - le système itère simplement chaque jour de bourse (ou barre OHLC), effectue des calculs liés au prix de l'actif souhaité (par exemple, calcule les prix de clôture moyens mobiles), puis effectue l'opération correspondante (saisie d'une position longue ou courte). D'autres itérations se poursuivent. Dans le processus, des informations sur les performances sont stockées afin de construire un graphique (courbe d'équité) en conséquence.
Voici à quoi ressemble le pseudocode d'un tel algorithme:
for each trading bar: do_something_with_prices(); buy_sell_or_hold_something(); next_bar();PythonCopy
Comme vous pouvez le voir, le système est extrêmement simple, ce qui fait de ces back-testers une excellente option pour obtenir les premières estimations sur les perspectives du système commercial.
Avantages
Le backtester cyclique est très simple à implémenter en utilisant presque n'importe quel langage de programmation, et le fait rapidement. Ceci est utile lorsque vous souhaitez tester l'effet de nombreux paramètres différents.
Inconvénients
Le principal inconvénient est les résultats irréalistes. Souvent, dans les backtesters cycliques, il n'y a même pas de fonctionnalité de base pour la comptabilisation des coûts de transaction, elle doit être mise en œuvre séparément. Sont également couramment utilisés uniquement les commandes MARKET.
De plus, la possibilité de réutiliser du code pour un système de test et de production est minime, vous devez donc le réécrire. Cela augmente la probabilité d'erreurs logicielles.
Les testeurs de bouclage sont sujets à des erreurs de prédiction. Ils devraient être utilisés exclusivement comme un outil de filtrage pour rejeter les stratégies manifestement infructueuses. En même temps, il est important de rester extrêmement sceptique vis-à-vis des stratégies qui ont donné de bons résultats. Il est important de se rappeler que dans la vie réelle, les stratégies fonctionnent rarement mieux que lors d'un backtest.
Systèmes orientés événement
Les systèmes de ce type sont de l'autre côté du spectre. Ils sont beaucoup plus proches de la réalité. Habituellement, ils fonctionnent en énormes boucles while, au cours desquelles les «événements» sont constamment recherchés dans une «file d'attente d'événements» spéciale, notamment:
- tiques - l'émergence de nouvelles données de marché;
- événements de signalisation - l'apparition de signaux de trading;
- événement d'ordre - un ordre pour terminer une transaction est prêt à être envoyé au système de courtier;
- événement de transaction - réception par le courtier d'informations sur l'exécution de l'application.
Lorsqu'un certain événement est reconnu, il est transmis au module correspondant dans l'infrastructure du système d'échange pour un traitement ultérieur et génère potentiellement de nouveaux événements qui tombent à nouveau dans la file d'attente.
Le pseudocode d'un tel backtester est le suivant:
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);
Comme vous pouvez le voir, le système est extrêmement dépendant du module de traitement de portefeuille - c'est le véritable cœur des systèmes événementiels.
Avantages
Les backtesters de ce type présentent de nombreux avantages:
- Réduire la probabilité d'erreurs de prévision - en raison de la structure, qui suppose une transmission échelonnée des messages, les erreurs de prévision sont moins susceptibles de se produire dans les systèmes événementiels, au moins au niveau de l'échange. Cependant, la probabilité de leur occurrence est toujours préservée, car des erreurs peuvent être contenues dans le modèle lui-même.
- Possibilité de réutiliser le code - pour utiliser la stratégie dans le trading réel, il vous suffit de remplacer le module de traitement des données et le moteur d'exécution des ordres. La description de la stratégie, le module de gestion des risques et de gestion des positions, un code pour évaluer la productivité du système - tout cela peut être utilisé sans modifications. Cela réduit la probabilité de nouveaux bogues.
- Au niveau du portefeuille - Les stratégies événementielles facilitent la réflexion au niveau du portefeuille. En fin de compte, cela facilite la modification de la stratégie et le développement de méthodes de couverture.
- Gestion «correcte» des risques - dans de tels systèmes, il est plus facile de «moduler» la gestion des risques. Un trader peut facilement utiliser des techniques comme le critère de Kelly, et également inclure diverses alertes, fixer des limites (par exemple, sur la volatilité).
- Déploiement et surveillance à distance - le principe modulaire de l'écriture de code simplifie son déploiement dans le cloud ou selon le schéma de collocation des échanges.
Inconvénients
Les avantages des systèmes orientés événements sont compréhensibles, mais ils présentent certains inconvénients. Parmi eux:
- Code complexe - développer un système entièrement couvert par des tests prendra des semaines et des mois de travail en mode à temps plein.
- Orientation objet - la conception modulaire du système nécessite une approche orientée objet de la programmation. Nous avons donc besoin d'un langage qui soutienne ces principes. Les tests unitaires ne seront pas plus faciles.
- Seuil d'entrée élevé - un nouveau venu dans la programmation ne pourra pas créer un tel système. Une expérience significative en ingénierie sera requise, ce qui permettra de gérer l'écriture de code, la mise en œuvre de la journalisation, la réalisation de tests unitaires, la mise en œuvre du contrôle de version et des pratiques d'intégration continue.
- Basse vitesse - une approche dans laquelle les messages au sein du système sont transmis séquentiellement dans ses différents niveaux, ralentit la vitesse d'exécution des applications par rapport à l'approche cyclique vectorisée. Le calcul de diverses combinaisons de paramètres peut prendre du temps.
Autres documents financiers et boursiers d' ITI Capital :