Déclarer un indicateur, ses signaux et ce que l'on veut mesurer

Une étude est une fonction Python qui reçoit les prix, calcule ses colonnes et renvoie des signaux long et short. Trois déclarations l'accompagnent, afin que chaque choix reste explicite :

• SignalSpec indique comment un signal devient un événement : à la première bougie d'une séquence (rising_edge) ou à chaque bougie (every_true_bar), avec un cooldown éventuel ;
• ForwardEvaluationSpec fixe ce que l'on mesure ensuite : point d'entrée, horizons et unité ;
• la vue choisit les courbes, les marqueurs et les panneaux affichés sur le graphique.

Comparer chaque signal à des entrées tirées au hasard

Un signal connu à la clôture d'une bougie est évalué à partir de l'ouverture suivante. Pour chaque horizon, le mode mesure le rendement dans le sens du signal, l'excursion favorable (MFE), l'excursion défavorable (MAE) et le franchissement de barrières. En unités ATR, l'échelle utilisée est celle connue au moment du signal.

Le même calcul est appliqué à toutes les barres éligibles de la période, avec la même proportion de long et de short. L'écart entre les deux, le lift, est accompagné d'un intervalle de confiance à 95 % obtenu par bootstrap par jour. Chaque ligne reçoit enfin un diagnostic : POSITIVE, NEGATIVE, INCONCLUSIVE ou INSUFFICIENT.

Lecture de cet exemple : seul LONG à 6 barres porte le diagnostic POSITIVE (lift de 0,099697 ; IC 95 % [0,017798 ; 0,176225]). Les huit autres lignes sont INCONCLUSIVE. Ce résultat décrit le signal évalué, sans établir la rentabilité d’une stratégie après gestion et coûts.

Dans cet exemple, seul le sens LONG à 6 barres obtient un diagnostic POSITIVE (lift de 0,0997, intervalle à 95 % de 0,0178 à 0,1762). Les huit autres lignes restent INCONCLUSIVE. Le résultat porte sur le signal seul : il ne dit encore rien de la rentabilité d'une stratégie après gestion et frais.

Retrouver à chaque modification la version précédente et la référence

Chaque run est enregistré puis comparé automatiquement à la dernière version distincte et à la référence de la série, c'est-à-dire le premier run enregistré tant qu'elle n'est pas déplacée. L'utilisateur voit ainsi immédiatement si sa modification améliore le signal, et s'il s'éloigne de son point de départ.

research.run(ema_signal, params={"ema_span": 30})   # A : la référence
research.run(ema_signal, params={"ema_span": 40})   # B
research.run(ema_signal, params={"ema_span": 50})   # C
report = research.report()
report.comparisons["previous"]   # C contre B
report.comparisons["baseline"]   # C contre A

Le rapport indique quels signaux sont conservés, ajoutés ou retirés, et comment les mesures évoluent. Un changement de données, de période ou d'évaluation ouvre une nouvelle série, afin de ne jamais comparer des expériences différentes.

L'historique est conservé dans une base SQLite, accompagnée d'un journal Markdown lisible : les rapports restent consultables après un redémarrage. Renommer un notebook conserve son historique ; le copier crée une nouvelle identité qui garde la trace de sa filiation.

Reconnaître une entrée plus précoce ou plus tardive sur le même mouvement

Lorsqu'une modification avance une entrée de trois bougies, une comparaison classique voit un signal supprimé et un autre ajouté. Le juge de timing rattache plutôt chaque signal au mouvement de prix auquel il appartient, puis compare les deux versions mouvement par mouvement. Chaque entrée reçoit l'une des quatre catégories suivantes :

research.set_movement_judge(MovementJudge())
research.run(study, params=params)
m = research.report().comparisons["previous"].movements
m.summary, m.transitions, m.worst(15)

Un graphique relié au notebook, et un replay qui masque le futur

research.serve(run) ouvre un serveur local qui affiche le résultat déjà calculé : consulter le graphique ne relance pas l'étude.

Mesurer une intuition avec des campagnes à l'aveugle

Un trader discrétionnaire peut avoir le sentiment de savoir reconnaître les bons signaux. Les campagnes permettent de le vérifier : un humain ou un modèle trie des signaux (Prendre ou Rejeter) sans voir la suite, puis sa sélection est comparée à des sélections aléatoires parmi les mêmes candidats.

Quatre façons de décider sont distinguées : discrétionnaire sans assistance, discrétionnaire aidé par les valeurs connues au moment du signal, filtre quantitatif et annotation rétrospective. Une annotation faite en voyant le futur n'est jamais mélangée aux résultats à l'aveugle.

Chaque fenêtre affichée est enregistrée par date, actif et unité de temps. Le replay libre compte aussi : renommer des signaux ne rend pas une fenêtre « jamais vue ». L'export vers le machine learning exclut les phases 1 et 2, et le modèle est figé avant la phase finale.

Figer la configuration avant d'ouvrir l'échantillon réservé

La séparation entre développement (DEV) et hors échantillon (OOS) se déclare dès la création de Research. Le freeze enregistre la configuration et les conclusions avant tout accès à la partie réservée, et le contrôle s'exécute avant le calcul OOS. Les barres antérieures peuvent servir à initialiser les indicateurs, mais seules les observations autorisées sont publiées.

research.use_insample()
run_dev = research.run(study, params=params)
research.freeze_configuration(conclusions=conclusions)
research.use_oos()
run_oos = research.run(study, params=params)
cross = research.run_cross_asset(
    study, {"XAGUSD": xag_df}, params=params,
    public_settings=PUBLIC_SETTINGS,
)

Les essais sont comptés dans le même registre de validation que le mode Algo : une nouvelle décision compte, un run identique est reconnu, et regarder ou zoomer reste une simple observation. Le test sur un autre actif ne crée pas de nouvel essai, mais chaque lancement est enregistré pour que les répétitions restent visibles.

Du signal mesuré à la stratégie exécutée

Passer au mode Algo consiste à formaliser les entrées en setups, puis à ajouter la gestion des positions, les frais et le sizing. Les conclusions de Research doivent alors être vérifiées à nouveau : un signal qui précède bien les mouvements ne garantit pas une stratégie rentable.

Dans l'autre sens, @engine.research_view déclare un graphique avant le run : les bougies, les entrées et les sorties du moteur y sont ajoutées automatiquement, et engine.bind_research_view(study) peut réutiliser la vue d'une étude. Le résultat s'ouvre en lecture seule : rien n'est recalculé, aucun essai n'est compté et le freeze n'est pas modifié.