Quant Research Framework

La référence Python est le framework que n’importe qui peut installer dès aujourd’hui et utiliser pour générer des stratégies, à base de règles ou de ML, sous un pipeline de qualité recherche. Vous écrivez une fonction qui prend (df, lb) et renvoie des signaux int8 dans {−1, 0, +1} ; le framework s’occupe de l’optimisation, de l’orchestration walk-forward, de la rotation de régime, de la suite d’overlays de robustesse à 5 scénarios, et du calcul des métriques. La boucle interne JIT numba applique frais, slippage, funding (crypto-seulement), SL/TP intrabar, fenêtres de session, et logique de clôture forcée sur un registre de trades typé, de sorte que le PnL simulé est ce qu’une couche d’exécution déployable verrait réellement.

Sept sous-systèmes majeurs sont livrés d’emblée, chargeur de données, cœur d’indicateurs, contrat de stratégie, cœur d’exécution, optimiseur, orchestrateur walk-forward, moteur de régime, plus les blocs de diagnostics Monte Carlo et Deflated-Sharpe. La version v0.4.0 a démêlé Config des globales, ce qui permet à deux backtests de coexister dans le même interpréteur et a aussi débloqué le protocole de parité inter-langages en aval.

• ▪Installer : pip install quant-research-framework. DOI : 10.5281/zenodo.19798594. Sous licence Apache-2.0.
• ▪Le contrat de stratégie est délibérément minimal : (df, lb) → int8[] dans {−1, 0, +1}. Même surface pour les règles écrites à la main et pour les modèles de ML.
• ▪CSV fournis pour faire du premier backtest une seule ligne : SOLUSDT 1h (48 094 barres) et EURUSD 1h (53 160 barres).

Le port Rust vous donne le même moteur, même WFO, même segmenteur de régime, même suite de robustesse, même sémantique de stratégie, dans un binaire que vous pouvez déposer dans un déploiement de production sans interpréteur Python. C’est une implémentation séparée de la même spécification, pas une translittération : disposition mémoire différente, régime d’arrondi différent (LLVM-via-rustc vs LLVM-via-numba), RNG différent. Le but est d’exercer la spécification algorithmique avec deux moteurs dont la seule lignée partagée est la spécification elle-même.

Le contrat de stratégie reflète Python exactement : fn(&[Bar], usize) → Vec<i8>. La couche de détection de bascule traduit les niveaux de signal bruts en codes d’entrée/sortie ; cette séparation permet aux auteurs de stratégie de spécifier l’état désiré (long/short/flat) plutôt que les transitions, ce qui est bien plus facile à garder correct vis-à-vis du no-look-ahead.

• ▪DOI : 10.5281/zenodo.19798592. crates.io : cargo add quant-research-framework-rs.
• ▪Les dépendances sont délibérément minuscules et épinglées : rand =0.9 (exact), chrono 0.4, chrono-tz 0.10. L’épinglage exact de rand est documenté parce que rand 0.10 fait de random_range une méthode de trait, cassant les sites d’appel.
• ▪Le binaire Rust n’a besoin d’aucune mise en chauffe ; Python paie un coût unique de cache JIT numba avant la première exécution mesurée.

La parité est le protocole qui nous permet d’affirmer que Python et Rust exécutent le même backtester plutôt que deux backtesters qui se ressemblent par hasard. Trois surfaces de configuration déterministes sont vérifiées de bout en bout à chaque PR : config par défaut (56 points de métrique · WFO déclenché par bougie + lookback smart-optimisé + auto-RRR), régime + WFO (98 points de métrique · optimisation de LB par régime + rotation de LB OOS + warmup de 200 barres + 4 fenêtres WFO), et mode forex (56 points de métrique · dimensionnement de position à l’échelle des pips + plafonnement de PnL en mode forex).

La tolérance est de 10⁻³ relatif ; la pire déviation observée sur les 210 points de métrique est 5×10⁻⁵, vingt fois plus serrée que déclarée, ce que nous prenons comme preuve que c’est l’équivalence algorithmique, pas l’accumulation numérique, qui est contraignante. La réplication à 210 points au moment de l’article a correspondu bit à bit à la précision d’arrondi d’impression \%.4f.

• ▪Ré-exécuter la parité est une commande par surface, durée totale ≈ 5–10 min sur un ordinateur portable récent.
• ▪Désactivés par conception : les percentiles Monte Carlo (implémentations de RNG différentes entre moteurs) et l’overlay INDICATOR_VARIANCE — un décalage de lookback de ±1 dont la graine n’est pas fixée, aléatoire par intention, de sorte que ces lignes varient d’une exécution à l’autre dans chaque moteur et restent hors de la surface de parité.
• ▪Périmètre non vérifié honnêtement divulgué : Windows MSVC. La combinaison à quatre voies régime+WFO+forex+session est désormais byte-exacte et contrôlée en CI (Phase 08), et la parité inter-architectures sur aarch64 est vérifiée par CI (Phase 06).

L’intérêt de la phase de perf est que le moteur Rust est opérationnellement utilisable dans un déploiement de production, pas que la référence Python soit lente. Sur le bench fourni le port Rust tourne 23.8–57× plus vite de bout en bout avec 33–65× moins de RSS de pic de processus complet, le delta de mémoire attribuable au moteur n’est plausiblement que de 3–5× une fois soustraite la baseline de l’interpréteur pandas/numpy/numba de Python, et l’article lit la une avec cette réserve.

La comparaison d’accélération est significative précisément parce que la parité tient : sans parité, une ré-implémentation plus rapide pourrait simplement faire moins de travail ; avec parité, vous chronométrez deux implémentations du même algorithme.

• ▪Les benchmarks tournent sur des tranches SOLUSDT 1h fournies à 15k / 25k / 35k / 48k barres, trois exécutions à chaud (avec une mise en chauffe écartée pour le cache JIT numba).
• ▪Le pipeline par défaut complet tourne de bout en bout : baseline IS/OOS, recherche de lookback smart-optimisée avec auto-RRR, walk-forward déclenché par bougie, diagnostics Monte Carlo, et les quatre overlays de robustesse v0.1.x.

L’article d’accompagnement documente l’architecture, le pipeline WFO + régime + robustesse, la méthodologie de parité, la comparaison de performance, et un plan de reproductibilité adapté à une publication académique. Il positionne le framework contre six backtesters open-source largement utilisés et la littérature statistique pertinente ; la contribution est la combinaison plus le protocole de parité, pas une nouvelle machinerie statistique.

Douze tours de relecture interne ont fait passer l’article d’un score moyen de relecteur de 7,0 à une trajectoire finale de 8/8/9. Le dépôt de l’article livre requirements-paper.txt avec des dépendances Python épinglées, un Makefile qui exécute make verify contre des SHA de clones jumeaux épinglés, et un parity_residuals.csv généré qui sous-tend chaque figure.

• ▪Source complète : github.com/DaruFinance, dépôt de l’article + dépôt python + dépôt rust en jumeaux.
• ▪Les deux artefacts ont des DOI Zenodo séparés ; le dépôt de l’article recevra son propre DOI lorsqu’il sera archivé sur Zenodo au moment de la publication.

Le port Rust a été cross-compilé vers aarch64-unknown-linux-gnu et exécuté sous l’émulation en mode utilisateur QEMU contre les mêmes entrées que le binaire x86_64. Après avoir semé l’overlay de variance-d’indicateur précédemment non semé (un oubli découvert et corrigé pendant la préparation de l’article), chaque métrique déterministe imprimée est byte-identique entre les deux architectures sur les six jeux de données, 1 176 lignes de métrique, zéro différence. Seuls les temps de chargement et de temps mur total diffèrent, tous deux gonflés par le surcoût d’émulation de QEMU.

La comparaison est une égalité de chaîne exacte du bloc de métriques imprimé, strictement plus forte que la vérification par tolérance relative utilisée pour la parité inter-langage, et elle tient parce que le hot path n’utilise que des opérations IEEE-754 correctement arrondies, sans fast-math ni codegen de fused-multiply-add. Un job ARM natif sur un runner ARM public gratuit exécute la même assertion de byte-identité sur silicium réel aux côtés du job QEMU, de sorte que les deux architectures sont vérifiées à chaque changement et que le résultat QEMU sert de filet de sécurité reproductible.

Le cœur d’exécution, à la version épinglée par l’article, opérait sur une seule série OHLC à la fois. Le substrat multi-actifs qui lève cette limite a été livré en v0.5.0 dans les deux moteurs : une couche panel (détection de régime inter-actifs, paniers long/short, dimensionnement par equal-risk-contribution, neutralisations bêta / dollar / sigma, contraintes de portefeuille) plus des primitives de paires et de carry, sur un registre de trades par-jambe repensé qui porte un id de jambe, un id de groupe de trade et une décomposition complète des coûts (frais, slippage, funding, brut et net) satisfaisant brut − coûts = net à la tolérance flottante.

Chaque primitive est mise en miroir Python ↔ Rust et contrôlée par sa propre porte de parité en CI, avec la même discipline que les surfaces d’origine, huit surfaces concordent désormais à 1e-3 près (nombre de trades exact). La sortie mono-actif est byte-inchangée par rapport à la version précédente. La recherche de stratégies propriétaire qui repose sur ce substrat reste privée ; la publication publique est la capacité du moteur, pas les stratégies.

Le registre de parité publié couvrait trois surfaces ; la combinaison à quatre voies, régime + WFO + forex + session, était celle qui restait, et elle est désormais close. L’investigation a révélé deux causes. La dominante était un décalage dans le harnais, et non un bug du moteur : le pilote du combo alimentait les deux moteurs avec des réglages de sélection différents (le minimum de trades et l’optimisation du risk-to-reward sont des constantes de compilation côté Rust mais étaient surchargés côté Python), si bien que la phase in-sample choisissait un lookback différent.

Le résidu était trois divergences de barre de fin de session dans le cœur Rust : sur la dernière barre en-session du jour, il laissait un signal de flip opposé ouvrir une position, ne bloquait jamais une nouvelle entrée, et exécutait la vérification intrabar de stop/cible, alors que le moteur de référence force la clôture inconditionnellement et saute la vérification stop/cible. Aligner les trois (entièrement protégé par le drapeau de session, donc les surfaces à fonctionnalité unique restent byte-inchangées) rend le combo byte-exact à chaque étage. Il s’exécute désormais comme une quatrième surface de parité contrôlée en CI, rétrécissant l’empreinte non-vérifiée honnêtement divulguée à Windows MSVC.

L’utilitaire DSR (Bailey & López de Prado 2014) était Python-seulement parce qu’il dépend de la distribution normale de scipy et est invoqué une fois par trajectoire d’optimisation plutôt que par barre. Il est désormais mis en miroir en Rust derrière un drapeau de fonctionnalité léger, avec la même discipline de parité appliquée à sa sortie scalaire : un harnais dédié alimente des fixtures identiques de (Sharpe, Sharpes d’essai, rendements), y compris les cas asymétriques, à queue épaisse et tous les cas-garde dégénérés, aux deux implémentations et confirme la concordance sur le Sharpe-maximum-attendu et le Sharpe déflaté dans la tolérance standard, et en fait en deçà de 1e-9 sur tous les cas finis puisque les deux sont en forme close.

La CDF normale et son inverse proviennent d’un crate de statistiques éprouvé qui concorde avec scipy à environ 1e-12 ; l’approximation grossière de la fonction d’erreur utilisée ailleurs dans le port n’est délibérément pas réutilisée, car son erreur de queue corromprait le terme de Sharpe-maximum-attendu au quantile pertinent. Le bénéfice est un déploiement Rust-seulement qui calcule des diagnostics de Sharpe déflaté sur ses propres trajectoires d’optimiseur sans aller-retour par Python.