Faux backtest IS OOS, overfitting

SQ génère une "bonne" stratégie avec de bons IS et OOS

Mais il s'avère que SQ jette un coup d'œil dans l'OOS et y ajuste une courbe.

Pourquoi l'OOS est-il si faux alors ?

Comment empêcher SQ de jeter un coup d'œil dans l'OOS ?

Essayez de construire une stratégie sur IS et n'ayez pas d'OOS. Ensuite, testez l'échantillon après la construction.

À mon avis, on ne peut jamais éviter une certaine forme d'ajustement des courbes. C'est tout ce dont nous disposons en tant que traders. Nous construisons des modèles et nous les vérifions sur la base de l'historique. Même si vous utilisez plus tard des données supplémentaires pour vérifier cette stratégie (données jamais utilisées dans SQ), vous adaptez également la stratégie à ces données. Si la stratégie ne fonctionne pas sur ces données, vous ne l'utiliserez probablement pas, mais vous le ferez si la stratégie " s'adapte " à ces données 🙂 .

c'est une mauvaise idée

travail manuel inefficace

Arrêtez simplement d'essayer de jeter un coup d'œil sur l'avenir de l'OOS et soyez honnête avec les backtests. Si l'OOS n'est pas bon, abandonnez-le et passez à autre chose.

Je me suis toujours posé la même question : Si vous sélectionnez une plage de données OOS, le SQ va-t-il activement mélanger les stratégies sur les résultats IS afin d'obtenir une meilleure adéquation sur OOS ? Ou se contentera-t-il d'écarter les stratégies qui obtiennent la meilleure adéquation sur IS mais qui n'atteignent pas les critères minimums sélectionnés sur OOS ?

Je pense que la SQ fonctionne de la première manière. Ainsi, si vous choisissez la période OOS, le processus de construction est influencé par cette période OOS parce qu'il force les stratégies à s'orienter vers la meilleure période OOS au lieu de construire sur la base de la seule période IS. C'est ce que je pense. Donc, si j'ai raison, il serait préférable de construire uniquement sur la période IS et de faire une deuxième exécution sur la plage de données qui serait votre OOS.

si vous ne faites qu'IS

Vous devrez alors effectuer un travail manuel en testant les OOS et toutes ces stratégies échoueront à 99,99%.

Quel est alors l'intérêt de l'automatisation et de ce logiciel ?

Vous pouvez toujours créer un Project personnalisé pour l'automatiser. C'est ce que j'ai fait.

Je dis bien "fait", car depuis quelques semaines, j'ai commencé à construire sans OOS. Toutes les données que j'ai vont à IS. Mes résultats jusqu'à présent ne sont pas mauvais

L'utilisation de l'IS sans tests robustes et l'utilisation de la génétique est une première façon de commencer à perdre.

J'ai testé de nombreuses approches et, oui, je peux tolérer les opinions selon lesquelles vous n'avez pas besoin de tests OOS, mais sans cette vérification sur des données jamais vues de votre modèle (flux de travail), vous n'avez aucune idée de la robustesse de votre modèle pour l'avenir.

J'ai également testé de nombreuses approches. Après des années, nous sommes arrivés à la conclusion que l'OOS n'apportait aucune valeur au processus.

Cela ne fait pas de mal non plus, donc si vous voulez l'utiliser juste au cas où, cela devrait aller, je suppose.

Le problème est le même pour moi... lorsque j'utilise OOS dans le constructeur, l'algorithme génétique semble prendre en compte l'aptitude IS+OOS pour générer de nouvelles stratégies...

Par exemple, si j'utilise OOS dans le constructeur avec des critères comme ret/DD(IS) > 2 et aucun critère pour OOS et que je le laisse générer 100 stratégies, elles ont toutes un bon OOS.

Mais si j'utilise uniquement IS avec les mêmes critères et après avoir retesté mes 100 stratégies sur OOS, 99% sont surajoutées et s'écrasent dans la zone OOS.

Donc, pour moi, OOS est absolument inutile dans le constructeur :/

hankeys a écrit :

J'ai testé de nombreuses approches et oui, je peux tolérer les opinions selon lesquelles vous n'avez pas besoin de tests OOS, mais sans cette vérification sur des données jamais vues de votre modèle (flux de travail), vous n'avez aucune idée de la robustesse de votre modèle pour l'avenir.

pourquoi n'aimez-vous pas la génétique ?

Vous ne croyez pas à l'évolution et à la sélection naturelle ?

seulement au hasard ?

Oh merde... désolé... j'ai fait une grosse erreur...

après vérification, SQX builder ne regarde que IS fitness. les résultats sont exactement les mêmes si j'utilise OOS pendant le processus de construction ou après. désolé.

D'un autre côté, il y a un gros problème.

Si vous générez des stratégies avec l'option "backtest sur un marché supplémentaire" activée, le constructeur efface l'aptitude IS et l'aptitude OOS pour ne regarder que l'aptitude IS+OOS.

Ainsi, si nous utilisons des marchés supplémentaires dans le constructeur, les OOS deviennent de faux OOS et le constructeur suradapte les stratégies.

Si, comme moi, vous utilisez la génération précédente comme population initiale, cela interrompt tout le processus et annule votre zone OOS.

Bonjour Charles,

Je pense que vous avez tort. Après vous avoir lu, j'étais inquiet car j'utilise plusieurs contrôles croisés dans mon processus de construction et je ne voudrais en aucun cas que le processus d'optimisation inclue les marchés additionnels. J'ai donc consulté le manuel de SQ. D'après le manuel, " la stratégie évolue uniquement sur la partie des données de l'échantillon ". L'évolution génétique est donc le processus d'optimisation. Elle ne fonctionnerait que sur IS - du moins je l'espère !

J'ai construit et je teste un certain nombre de portefeuilles pour M5 H1 et H4 dans MT4.

Les stratégies des portefeuilles vont des stratégies fortement testées en termes de robustesse avec WFM, MC, etc. jusqu'à l'absence totale d'OOS.

Mon portefeuille le plus performant est de loin mon portefeuille H4 composé de 96 stratégies sur 12 paires de devises et l'or (13 paires au total).

Paradoxalement, il s'agit du portefeuille que j'ai construit et qui se compose de stratégies élaborées uniquement à l'aide de la tâche de construction en utilisant l'évolution génétique sans OOS. Aucune de ces stratégies n'a été testée en termes de robustesse. Tout ce que j'ai fait, c'est de les construire en utilisant des spreads ridiculement élevés et le maximum de données disponibles.

J'ai voulu faire cette expérience parce que je me suis dit que si je pouvais obtenir une très bonne courbe d'équité pour chaque stratégie, avec des spreads que je ne verrai probablement jamais dans le trading réel, sur une très longue période de temps, sur un cadre temporel élevé où il y a probablement beaucoup moins de bruit, même si cette courbe est "ajustée", elle devra continuer à être performante dans un large éventail de conditions de marché variables pour une paire.

Il semble que cela fonctionne très bien 🙂 .

Honnêtement, c'est une approche très intéressante. Pourquoi ne pas l'accepter et rendre les choses plus difficiles ? Par ailleurs, combien de temps vous a-t-il fallu pour atteindre ce nombre de stratégies ? Juste par curiosité / comparaison ( ?)