Agents de trading Deep RL : comment entraîner, valider et déployer des réseaux de politiques après coûts ?

L'apprentissage par renforcement financier (FinRL) applique l'apprentissage par renforcement à des tâches telles que le trading algorithmique, la gestion de portefeuille et la tarification d'options [6]. L'attrait est évident : un réseau de politique qui ingère les prix, les positions et la trésorerie et produit des actions de trading pourrait en principe s'adapter à des marchés changeants plus vite qu'une règle fixe. Mais les environnements d'apprentissage par renforcement financier sont difficiles à construire parce que les données financières ont un faible rapport signal/bruit, les données historiques peuvent contenir un biais de survie, et les modèles peuvent surapprendre [1]. Ces trois problèmes, le bruit, le biais de survie et le surapprentissage, sont exactement les biais sur lesquels porte la question de recherche, et ils sont nommés comme des difficultés structurelles du domaine, non comme des défauts d'un article en particulier.

Une enquête sur le marché des cryptomonnaies identifie un manque de cohérence dans la communauté du trading DRL comme un obstacle à la recherche et au développement [5]. Cela signifie que même lorsqu'un article rapporte un résultat positif, un lecteur ne peut souvent pas dire si le gain provient de l'algorithme, du découpage des données, de l'hypothèse de coût ou de la graine aléatoire, parce que différents articles utilisent des conventions différentes. C'est la raison pratique pour laquelle la réponse directe ci-dessus ne peut pas rapporter une recette unique gagnante : les affirmations proviennent de groupes de recherche distincts utilisant des univers d'actions, des fenêtres temporelles et des modèles de coûts distincts.

Plusieurs articles critiquent explicitement cet état de fait. Les études de trading antérieures en apprentissage automatique sont critiquées pour leurs courtes périodes de backtesting, leurs petits jeux de données, leurs caractéristiques limitées, l'absence de prise en compte des coûts de transaction et, souvent, l'absence de tests de signification statistique [12]. Cette critique vise largement la littérature et constitue une liste de contrôle utile pour tout constructeur auditant un nouvel article de trading : poser des questions sur la longueur du backtest, la taille du jeu de données, l'ensemble de caractéristiques et la question de savoir si les coûts de transaction ont été modélisés.

Compte tenu de cela, le reste de cette note traite les frameworks ouverts (FinRL, FinRL-Meta) comme une infrastructure d'ingénierie à réutiliser, et traite les articles sur les algorithmes individuels (DDPG, variantes de DQN, ensembles, agents autoencoder plus LSTM) comme des points de données séparés et non comparables. La note couvre aussi la manière dont les probabilités de prévision calibrées et les exigences de pipeline de qualité professionnelle apparaissent dans les affirmations, et se termine par un plan de construction concret et un script d'évaluation exécutable.

FinRL est une bibliothèque modulaire et en couches contenant des algorithmes DQN, DDPG, PPO, SAC, A2C et TD3 fine-tunés [3]. Elle fournit des fonctions de récompense couramment utilisées et des baselines d'évaluation standard pour réduire le travail de débogage et favoriser la reproductibilité [3]. En pratique, cela signifie qu'un constructeur n'a pas besoin de réimplémenter ces six algorithmes à partir de zéro ; la bibliothèque les empaquette derrière une interface commune destinée aux tâches de trading.

FinRL configure des environnements virtuels avec des jeux de données de marché boursier, entraîne des agents de trading à réseaux de neurones et analyse des backtests extensifs via la performance de trading [3]. Il intègre le coût de transaction, la liquidité du marché et le degré d'aversion au risque de l'investisseur comme contraintes de trading [3]. FinRL peut simuler des marchés à l'aide de données historiques et d'API de trading en direct à plusieurs granularités temporelles [4], et il fournit des tutoriels pas à pas pour le trading d'actions, l'allocation de portefeuille et le trading de cryptomonnaies [4]. Il réserve aussi des interfaces d'import utilisateur afin que les utilisateurs puissent étendre le framework [4], ce qui compte pour un constructeur qui veut brancher une source de données personnalisée ou une récompense personnalisée.

FinRL-Meta est une bibliothèque complémentaire centrée sur les données. C'est une bibliothèque ouvertement accessible, centrée sur les données, qui traite des jeux de données de marché réels et dynamiques en environnements de marché de style gym [1]. Elle suit un paradigme DataOps et utilise un pipeline automatique de curation de données pour fournir des centaines d'environnements de marché [1]. Une description séparée de FinRL-Meta indique qu'elle sépare le traitement des données financières du pipeline de conception des stratégies d'apprentissage par renforcement profond et fournit des outils open source d'ingénierie de données pour le big data financier [7], et qu'elle fournit des centaines d'environnements de marché pour différentes tâches de trading et prend en charge la simulation et l'entraînement multiprocessus utilisant des milliers de cœurs GPU [7]. Ensemble, ces éléments décrivent une séparation en deux bibliothèques : FinRL-Meta gère la curation des données et la construction d'environnements à l'échelle, tandis que FinRL fournit les algorithmes et contraintes spécifiques au trading.

FinRL-Meta fournit aussi des exemples reproduisant des articles de recherche populaires comme points de départ pour concevoir de nouvelles stratégies de trading [1], et elle déploie sa bibliothèque sur des plateformes cloud afin que les utilisateurs puissent visualiser les résultats et évaluer la performance relative via des compétitions communautaires [1].

Le mécanisme le plus concrètement spécifié dans ces affirmations est le Markov Decision Process de trading d'actions issu de la lignée de l'article FinRL original. Le processus de trading d'actions est modélisé comme un Markov Decision Process dont l'état contient les prix des actions, les positions en actions et le solde de trésorerie restant [8]. L'ensemble d'actions comprend vendre, acheter et conserver, tandis que la récompense est la variation de la valeur du portefeuille après une action [8]. La formulation initialise les positions et les estimations de valeur d'action à zéro et initialise la politique uniformément sur les actions avant l'apprentissage par interaction avec l'environnement [8]. L'environnement met à jour la trésorerie comme b_{t+1}=b_t+p_t^T a_t et contraint les actions d'achat afin que le solde de portefeuille résultant soit non négatif [8]. La fonction de valeur d'action est mise à jour en utilisant la récompense immédiate attendue plus la valeur d'action attendue actualisée dans l'état suivant selon l'équation de Bellman [8].

Au-dessus de ce MDP, l'agent de trading DDPG décrit utilise un framework actor-critic, des target networks et l'experience replay pour modéliser de grands espaces d'état et d'action, stabiliser l'entraînement et réduire la corrélation des échantillons [8]. L'approche DDPG décrite a obtenu un rendement supérieur à la fois à l'allocation de portefeuille traditionnelle min-variance et au Dow Jones Industrial Average [8]. Il s'agit d'une seule comparaison rapportée, sur la configuration propre de l'article, contre deux baselines spécifiques ; ce n'est pas une affirmation selon laquelle DDPG bat d'autres algorithmes RL ou survit à des régimes de coûts de transaction arbitraires.

Une ligne de travail distincte utilise des méthodes basées sur la valeur plutôt que actor-critic. L'entraînement Deep Q-Network stocke les états précédents, les actions, les récompenses et les états suivants dans l'experience replay, les échantillonne aléatoirement par petits lots, et utilise un target Q-network pour estimer les récompenses futures [9]. Le target Q-network est périodiquement copié depuis le Q-network principal parce que l'utilisation de réseaux séparés augmente la stabilité de l'entraînement sur des données fortement corrélées et arrivant rapidement [9]. Double DQN traite la tendance de DQN à surestimer les valeurs Q en utilisant un autre réseau de neurones pour réduire l'influence de l'erreur d'estimation accumulée [9]. Une étude indienne de trading d'actions entraîne des agents DQN, Double DQN et Dueling Double DQN pour conserver, acheter et vendre, et les valide sur des données inédites d'une période ultérieure [9] ; cela décrit le protocole d'entraînement et de validation, mais l'ensemble d'affirmations n'inclut pas les chiffres comparatifs résultants.

Une troisième architecture combine l'apprentissage de représentation avec la modélisation de séquences : l'agent de trading décrit combine des autoencodeurs débruiteurs empilés pour l'apprentissage de représentation de marché, des réseaux long short-term memory pour la dépendance des séries temporelles financières, des actions contrôlées par position et des récompenses n-step [10]. Cet agent aurait surpassé ses baselines et atteint des rendements ajustés au risque stables à la fois sur les marchés d'actions et de futures [10], là encore comme un résultat auto-déclaré dans l'ensemble de baselines propre à cet article, et non une comparaison entre articles.

Les résultats quantitatifs les plus détaillés de cet ensemble d'affirmations proviennent d'une étude de trading d'actions utilisant des données OHLCV quotidiennes pour 30 actions du Dow Jones de 2020 à 2023. Dans cette étude, PPO, SAC, DDPG et un ensemble model présentaient chacun une variance élevée des rendements cumulés de test [6]. L'étude a entraîné et testé les modèles 1 010 fois en utilisant des rolling windows avec des fenêtres d'entraînement de 30 jours et de test de 55 jours [6]. Ce protocole de rolling windows constitue lui-même une réponse partielle à la question walk-forward de l'énoncé de recherche : c'est une procédure concrète et reproductible de style walk-forward, bien que limitée à l'univers d'actions et aux longueurs de fenêtre de cet article.

L'ensemble model a moyenné les probabilités d'action de trois agents et présentait un écart-type du rendement de test d'environ la moitié de celui de ses agents composants [6]. C'est un résultat direct et quantifié de réduction de variance, mais c'est une comparaison de l'ensemble par rapport à ses propres trois agents composants, pas par rapport à un marché ou à une baseline buy-and-hold. L'étude a aussi rapporté que l'entraînement des agents composants peut encore faire face à un goulot d'étranglement d'échantillonnage malgré la réduction de l'instabilité de politique par l'ensemble [6], ce qui signifie que l'ensembling gère le symptôme (la variance de sortie) sans nécessairement corriger la cause sous-jacente (l'entraînement instable par agent).

Dans des expériences de trading d'actions et de cryptomonnaies, une simulation massivement parallèle sur un GPU avec 2 048 environnements parallèles a amélioré la vitesse d'échantillonnage jusqu'à 1 746x par rapport à un seul environnement [6]. C'est un résultat d'infrastructure concernant le débit d'entraînement, pas la performance de trading, et il compte pour quiconque budgétise du calcul pour de grands balayages d'hyperparamètres. Les ensemble models dans les expériences sur actions et cryptomonnaies ont réduit le drawdown maximal jusqu'à 4,17 % et amélioré le Sharpe ratio jusqu'à 0,21 [6]. Ce sont les seuls chiffres de métrique de risque de l'ensemble d'affirmations liés à une méthode nommée (l'ensembling) et à des métriques nommées (drawdown, Sharpe ratio), et ils proviennent du même cadre expérimental que le résultat de réduction de variance ci-dessus.

Sous-jacent à tout cela, la performance des politiques RL est sensible aux hyperparamètres, aux environnements instables et aux graines aléatoires [6]. Cette sensibilité est la raison pour laquelle l'étude a exécuté 1 010 cycles d'entraînement/test plutôt qu'un seul : le chiffre de rendement d'une seule exécution ne serait pas fiable en lui-même. Un constructeur lisant un quelconque rendement rapporté dans cette littérature devrait se demander s'il a été produit sous un protocole répété de manière similaire ou à partir d'une seule graine chanceuse.

La question de recherche demande quels résultats survivent aux coûts de transaction. Un seul ensemble d'affirmations traite directement ce point en faisant varier les hypothèses de coût. Sur des jeux de données contenant 424 actions composantes du S&P 500 et 185 actions composantes du CSI 300 de 2010 à 2017, les algorithmes traditionnels d'apprentissage automatique ont mieux performé sur la plupart des indicateurs directionnels, tandis que les modèles DNN ont mieux performé lorsque les coûts de transaction étaient pris en compte [12]. Il s'agit d'une comparaison spécifique, datée, portant sur deux marchés et couvrant deux univers d'indices actions séparés ; elle ne se généralise pas aux politiques d'apprentissage par renforcement, puisque les modèles comparés sont décrits comme des algorithmes d'apprentissage automatique et des modèles DNN, non comme des agents DRL.

La performance de trading des stratégies d'apprentissage automatique évaluées était sensible aux changements des coûts de transaction [12]. La même source note que les études antérieures utilisaient souvent des backtests courts, de petits jeux de données, des caractéristiques limitées, aucun coût de transaction et aucun test de signification statistique [12]. C'est un avertissement qui s'applique largement : tout résultat de trading cité sans indication de son hypothèse de coût de transaction devrait être traité comme provisoire, parce que le classement des méthodes peut s'inverser une fois les coûts ajoutés, comme cela s'est produit entre précision directionnelle et performance ajustée aux coûts dans cette même étude.

Aucune des affirmations spécifiques au DRL de cet ensemble (DDPG contre Dow Jones et min-variance [8], les résultats de variance et de drawdown de l'ensemble [6], l'agent autoencoder-LSTM [10]) ne rapporte de comparaison contrôlée avant/après des coûts de transaction. FinRL intègre bien le coût de transaction comme l'une de ses contraintes de trading [3], donc l'infrastructure pour réaliser une telle comparaison existe, mais l'ensemble d'affirmations ne contient pas de résultat DRL publié qui isole l'effet de coût comme le fait l'étude S&P 500 / CSI 300 pour l'apprentissage automatique traditionnel.

La conclusion pratique pour un constructeur est que la sensibilité aux coûts de transaction est documentée comme un phénomène général dans les stratégies de trading en apprentissage automatique [12], et comme une contrainte modélisée à l'intérieur de FinRL [3], mais l'ensemble d'affirmations ne permet pas de dire si un chiffre de rendement DRL publié spécifique survivrait à la modification des hypothèses de coût de son propre article. Tout contrôle de ce type doit être exécuté par le constructeur, et non supposé à partir de ces articles.

La question de recherche demande comment une politique entraînée peut intégrer des probabilités de prévision calibrées comme caractéristiques d'état ou baselines de récompense. L'ensemble d'affirmations ne contient pas de méthode qui intègre explicitement des prévisions de probabilité calibrées dans un état ou une récompense DRL pour le trading. Ce qu'il contient de plus proche de cette idée est un déploiement en direct qui combine plusieurs types de signaux. Le RL Trading Agent met en œuvre un pipeline de bout en bout couvrant l'ingestion de données, l'entraînement PPO, le backtesting et le déploiement en paper trading en direct pour six actions en utilisant des données de marché en direct, l'analyse de sentiment NLP et la détection de régime de marché [14]. Cela montre des signaux de sentiment et de régime combinés à une politique PPO dans un pipeline fonctionnel, mais l'affirmation ne décrit pas ces signaux comme des probabilités calibrées, ni comme des baselines de récompense au sens d'un terme reward-shaping ; elle les décrit comme des entrées d'un déploiement de bout en bout.

Ailleurs, la définition d'état MDP utilisée dans la lignée FinRL se limite aux prix des actions, aux positions en actions et au solde de trésorerie restant [8]. C'est la représentation d'état de base à partir de laquelle un constructeur commence ; toute caractéristique de probabilité de prévision serait un ajout à ce vecteur d'état, mais aucune affirmation de cet ensemble ne précise comment un tel ajout devrait être mis à l'échelle, normalisé ou validé pour la calibration.

Comme aucune affirmation ne répond directement à la question de l'intégration de prévisions calibrées, cette note ne peut pas rapporter de résultat ici, seulement le bloc de construction disponible le plus proche : le déploiement PPO sur six actions qui ingère déjà des signaux non liés aux prix (sentiment, régime) aux côtés des données de marché [14], et la définition d'état standard prix/positions/trésorerie qu'il étendrait [8]. Un constructeur souhaitant une intégration de prévisions calibrées devrait concevoir et valider ce mécanisme lui-même ; c'est une lacune du corpus publié actuel couvert par ces affirmations, pas une recette documentée.

Cette lacune compte parce que la direct_answer ci-dessus signale déjà un manque général de cohérence dans la littérature sur le trading DRL [5] ; l'absence de recette allant de la prévision calibrée à l'état ou de la prévision calibrée à la récompense dans cet ensemble d'affirmations est un cas spécifique de cette incohérence, pas une particularité de notre recherche.

La question de recherche demande aussi ce dont un pipeline de qualité professionnelle a besoin en matière de données, d'API et d'infrastructure. Plusieurs affirmations décrivent directement des éléments d'un tel pipeline. FinRL peut simuler des marchés à l'aide de données historiques et d'API de trading en direct à plusieurs granularités temporelles [4], ce qui couvre à la fois le backtesting et l'ingestion de données en direct d'un système de production. FinRL-Meta suit un paradigme DataOps et utilise un pipeline automatique de curation de données pour fournir des centaines d'environnements de marché [1], ce qui répond au volet ingénierie des données : transformer des données de marché brutes en environnements prêts à l'emploi à l'échelle.

Sur l'infrastructure de calcul, FinRL-Meta prend en charge la simulation et l'entraînement multiprocessus utilisant des milliers de cœurs GPU [7], et séparément, une simulation massivement parallèle sur un GPU avec 2 048 environnements parallèles a amélioré la vitesse d'échantillonnage jusqu'à 1 746x par rapport à un seul environnement [6]. Ces deux affirmations décrivent des échelles de parallélisme différentes (des milliers de cœurs GPU dans un cluster contre 2 048 environnements sur un GPU) et ne doivent pas être traitées comme la même recommandation d'infrastructure ; un constructeur devrait choisir l'échelle correspondant à son budget et noter de quelle affirmation elle provient.

Sur le déploiement de bout en bout, le RL Trading Agent met en œuvre un pipeline de bout en bout couvrant l'ingestion de données, l'entraînement PPO, le backtesting et le déploiement en paper trading en direct pour six actions en utilisant des données de marché en direct, l'analyse de sentiment NLP et la détection de régime de marché [14]. C'est la seule affirmation de l'ensemble qui nomme explicitement un déploiement en paper trading en direct, et elle le fait pour un univers de six actions. C'est un modèle utile pour la forme d'un pipeline de production (ingérer, entraîner, backtester, paper-trader) mais l'affirmation ne rapporte pas de chiffres de performance ni de coûts d'infrastructure pour ce déploiement.

Sur le protocole de validation, ce qui se rapproche le plus d'une spécification walk-forward est le protocole de rolling windows déjà décrit : entraîner et tester les modèles 1 010 fois en utilisant des rolling windows avec des fenêtres d'entraînement de 30 jours et de test de 55 jours [6]. C'est une recette walk-forward concrète et réutilisable, mais elle a été appliquée à 30 actions du Dow Jones sur 2020-2023 [6] et ne doit pas être supposée se transférer sans changement aux données crypto ou forex sans re-validation, puisque l'ensemble d'affirmations ne rapporte pas qu'elle a été exécutée sur ces marchés.

Aucune des affirmations ne rapporte d'expérience contrôlée qui isole l'effet du biais look-ahead ou du biais de survie sur le rendement d'une politique DRL ; la seule affirmation directe est que les données historiques peuvent contenir un biais de survie et que les modèles peuvent surapprendre, ce qui est listé comme une difficulté générale de construction d'environnements RL financiers [1]. Un constructeur ne peut pas encore citer un chiffre publié montrant combien de rendement une stratégie DRL perd une fois le biais de survie retiré.

Le résultat de sensibilité aux coûts de transaction est spécifique aux modèles traditionnels d'apprentissage automatique et aux modèles DNN sur deux univers d'indices actions de 2010 à 2017 [12] ; il n'inclut pas de politique DRL, donc il ne peut pas être utilisé pour affirmer qu'un rendement phare d'un algorithme DRL particulier survivrait ou ne survivrait pas à des coûts réalistes. Séparément, les contraintes de coût, de liquidité et d'aversion au risque de FinRL [3] montrent que le mécanisme existe pour exécuter un tel test, mais aucune affirmation de cet ensemble ne rapporte le résultat de son exécution.

L'intégration de probabilités de prévision calibrées, demandée explicitement dans la question de recherche, n'a aucune méthode directe décrite dans ces affirmations ; la preuve disponible la plus proche est un pipeline en direct qui ajoute des signaux de sentiment et de régime à un agent PPO [14], ce qui est un type de caractéristique différent d'une prévision de probabilité calibrée. Quiconque construit cette intégration va au-delà de ce qui est publié ici, et ne reproduit pas une recette documentée.

Enfin, la performance des politiques RL est sensible aux hyperparamètres, aux environnements instables et aux graines aléatoires [6], et le domaine dans son ensemble souffre d'un manque de cohérence qui entrave la recherche et le développement [5]. Ensemble, ces éléments signifient que tout chiffre rapporté individuel, y compris ceux cités tout au long de cette note, devrait être traité comme conditionnel à sa fenêtre de backtest, à sa graine et à son modèle de coût exacts, et re-validé avant d'être utilisé pour un nouveau marché ou une nouvelle période.

1. Choisir la couche de framework. Utiliser FinRL-Meta pour la curation des données et la construction d'environnements, puisqu'elle suit un paradigme DataOps avec un pipeline automatique de curation de données et fournit des centaines d'environnements de marché [1], et utiliser FinRL pour les algorithmes, les fonctions de récompense et les contraintes ajoutés par-dessus [3]. Garder ces deux préoccupations séparées dans votre base de code, en reflétant la séparation que FinRL-Meta fait elle-même entre traitement des données et conception de stratégie [7].
2. Choisir un algorithme dans l'ensemble pris en charge. FinRL propose DQN, DDPG, PPO, SAC, A2C et TD3 fine-tunés [3]. Commencer par celui dont la formulation de trading publiée peut être reproduite de bout en bout ; DDPG a le MDP et la règle de mise à jour les plus complètement spécifiés dans cet ensemble d'affirmations [8].
3. Définir l'état, l'action et la récompense exactement comme spécifié. Construire l'état comme les prix des actions, les positions en actions et le solde de trésorerie restant [8] ; construire les actions comme vendre, acheter, conserver [8] ; définir la récompense comme la variation de la valeur du portefeuille après une action [8]. Initialiser les positions et les estimations de valeur d'action à zéro et la politique uniformément sur les actions [8].
4. Implémenter la contrainte de trésorerie et de solde. Mettre à jour la trésorerie avec b_{t+1}=b_t+p_t^T a_t et rejeter ou écrêter les actions d'achat qui rendraient le solde résultant négatif [8]. Cette contrainte fait partie de l'environnement, pas de l'agent, donc la tester indépendamment avec des transactions synthétiques avant l'entraînement.
5. Ajouter les frictions de trading. Configurer le coût de transaction, la liquidité du marché et l'aversion au risque comme des contraintes d'environnement à la manière de FinRL [3], et faire varier délibérément le paramètre de coût de transaction, puisque la sensibilité aux coûts s'est révélée inverser les classements entre types de modèles dans au moins une étude [12].
6. Si vous utilisez un agent basé sur la valeur, ajoutez l'experience replay et un target network. Stocker les transitions et échantillonner aléatoirement des mini-lots, et utiliser un target Q-network séparé mis à jour périodiquement depuis le réseau principal pour la stabilité [9]. Si une surestimation est suspectée, passer à Double DQN, qui utilise un second réseau pour réduire l'erreur d'estimation accumulée [9].
7. Si vous utilisez DDPG, ajoutez la machinerie actor-critic et target-network. Utiliser un framework actor-critic avec des target networks et l'experience replay pour gérer de grands espaces d'état/action, stabiliser l'entraînement et réduire la corrélation des échantillons [8].
8. Entraîner avec un protocole walk-forward, pas un seul découpage. Utiliser des rolling windows, par exemple des fenêtres d'entraînement de 30 jours et de test de 55 jours répétées de nombreuses fois (l'étude de référence a utilisé 1 010 répétitions) [6], plutôt qu'un seul découpage entraînement/test, parce que la performance RL est sensible aux graines et à l'instabilité de l'environnement [6].
9. Réduire la variance avec un ensemble. Entraîner plusieurs agents (par exemple PPO, SAC, DDPG) et moyenner leurs probabilités d'action ; cela a réduit l'écart-type du rendement de test à environ la moitié de celui des agents composants dans une étude rapportée [6], et a réduit le drawdown maximal jusqu'à 4,17 % et amélioré le Sharpe ratio jusqu'à 0,21 dans des expériences sur actions et crypto [6]. Se rappeler que les agents sous-jacents peuvent encore faire face à un goulot d'étranglement d'échantillonnage même après l'ensembling [6].
10. Passer à l'échelle l'entraînement avec la simulation parallèle si vous avez besoin de nombreuses graines ou d'un grand balayage. Une simulation massivement parallèle avec 2 048 environnements sur un GPU a amélioré la vitesse d'échantillonnage jusqu'à 1 746x par rapport à un seul environnement dans un cadre rapporté [6] ; FinRL-Meta prend en charge séparément le multiprocessus sur des milliers de cœurs GPU [7]. Choisir l'échelle qui correspond à votre budget de calcul et mesurer votre propre accélération plutôt que de supposer que ces chiffres se transfèrent.
11. Backtester contre des baselines nommées, pas seulement contre vos propres exécutions passées. Comparer à l'allocation de portefeuille traditionnelle min-variance et à un indice de marché tel que le Dow Jones Industrial Average, les deux baselines utilisées dans une étude DDPG [8], et rapporter à la fois le rendement brut et un résumé variance/drawdown/Sharpe à la manière de l'étude sur l'ensemble [6].
12. Passer au paper trading seulement après que les vérifications ci-dessus réussissent. Utiliser des API de trading en direct à la granularité sur laquelle vous avez entraîné [4], et structurer le déploiement comme ingestion, entraînement, backtesting, puis paper trading en direct, la forme utilisée dans un déploiement fonctionnel sur six actions qui ajoute aussi des signaux de sentiment et de régime [14].

Le script ci-dessous implémente, sur le schéma SQLite propre à la note, les deux mécanismes qui sont entièrement spécifiés dans les affirmations et qu'un constructeur peut reproduire de bout en bout : (1) l'environnement de trading mono-action basé sur MDP avec un état prix/positions/trésorerie, des actions acheter/vendre/conserver, une récompense de variation de valeur du portefeuille et une contrainte d'achat à solde non négatif [8] ; et (2) un petit ensemble d'agents Q-learning tabulaires à graines indépendantes dont les probabilités d'action sont moyennées, en suivant l'idée d'ensembling utilisée pour réduire la variance du rendement de test [6]. La docstring de chaque fonction indique quelle affirmation elle implémente. Les entrées sont lues dans la table `bars` pour un symbole et une unité de temps ; si `data.sqlite` (ou `QOURAT_DB`) ne contient aucune ligne correspondante, des données de prix quotidiennes synthétiques sont générées afin que le script s'exécute toujours. Les sorties sont imprimées : le rendement cumulé et l'écart-type du rendement pour chaque agent individuel, pour l'ensemble et pour une baseline buy-and-hold (la baseline de style indice de marché utilisée dans [8]) ; plus une boucle walk-forward sur des rolling windows suivant l'idée de fenêtre entraînement/test de [6]. Dans l'exécution avec 600 barres réelles pour AAPL 1d issues de la table bars imprimée ci-dessous, l'écart-type du rendement de l'ensemble (0,016267) est supérieur à l'écart-type de l'agent individuel (0,014445), et le rendement de la baseline buy-and-hold (0,075819) dépasse le rendement de l'ensemble (0,021929) ; cela ne reproduit pas la direction rapportée dans [6], qui montrait une réduction de variance par l'ensemble et une amélioration de la performance ajustée au risque dans une étude beaucoup plus grande avec des agents à réseaux de neurones, 1 010 cycles entraînement/test et 30 actions du Dow Jones. L'exécution entière utilise un petit nombre d'épisodes et de fenêtres afin qu'elle se termine sur un CPU en bien moins de trois minutes.

import os
import sqlite3
import math
import random
import numpy as np
import pandas as pd

DB_PATH = os.environ.get("QOURAT_DB", "data.sqlite")
SYMBOL = "AAPL"
TF = "1d"
RNG_SEED = 0


def load_bars(db_path, symbol, tf):
    """Read daily bars for one symbol/timeframe from the bars table.
    Input: sqlite file path, symbol string, timeframe string.
    Output: pandas DataFrame sorted by ts with a 'close' column.
    If no rows are found, generate a synthetic random-walk price series
    so the script can still run end to end without network access.
    """
    closes = None
    if os.path.exists(db_path):
        try:
            con = sqlite3.connect(db_path)
            q = "SELECT ts, close FROM bars WHERE symbol=? AND tf=? ORDER BY ts"
            df = pd.read_sql_query(q, con, params=(symbol, tf))
            con.close()
            if len(df) >= 120:
                closes = df["close"].astype(float).values
        except Exception:
            closes = None
    if closes is None:
        rng = np.random.default_rng(RNG_SEED)
        n = 400
        rets = rng.normal(loc=0.0003, scale=0.012, size=n)
        price = 100.0 * np.cumprod(1.0 + rets)
        closes = price
    return closes


class TradingEnv:
    """Single-stock trading environment.
    Implements [8]: state is price, holdings, cash.
    Implements [8]: actions are sell/buy/hold, reward is change in
    portfolio value after an action.
    Implements [8]: holdings and action-value estimates start at zero.
    Implements [8]: cash update b_{t+1} = b_t + p_t^T a_t, and buying
    is only allowed if the resulting balance stays non-negative.
    """

    def __init__(self, prices, initial_cash=10000.0, trade_size=10):
        self.prices = prices
        self.n_steps = len(prices) - 1
        self.initial_cash = initial_cash
        self.trade_size = trade_size
        self.reset()

    def reset(self):
        self.t = 0
        self.cash = self.initial_cash
        self.holdings = 0.0
        self.prev_value = self._portfolio_value()
        return self._state()

    def _portfolio_value(self):
        return self.cash + self.holdings * self.prices[self.t]

    def _state(self):
        return np.array([self.prices[self.t], self.holdings, self.cash])

    def step(self, action):
        price = self.prices[self.t]
        if action == 2:
            cost = price * self.trade_size
            if self.cash - cost >= 0:
                self.cash -= cost
                self.holdings += self.trade_size
        elif action == 0:
            if self.holdings >= self.trade_size:
                self.cash += price * self.trade_size
                self.holdings -= self.trade_size
        self.t += 1
        new_value = self._portfolio_value()
        reward = new_value - self.prev_value
        self.prev_value = new_value
        done = self.t >= self.n_steps
        return self._state(), reward, done


def discretize_state(state, prices):
    """Turn the continuous state into a small discrete bucket so a tabular
    Q-table can be used. Buckets: holdings sign (none/some). This is an
    implementation choice needed to make a tabular Q-learner run in under
    three minutes on a CPU; the state variables themselves (price, holdings,
    cash) follow [8].
    """
    price, holdings, cash = state
    holdings_bucket = 1 if holdings > 0 else 0
    return holdings_bucket


class QLearningAgent:
    """A simple tabular Q-learning agent used as one ensemble member.
    Implements the action-value Bellman update from [8]:
    Q(s,a) is updated using the temporal-difference learning rule.
    Implements [8]: action-value estimates start at zero.
    """

    def __init__(self, n_states=2, n_actions=3, alpha=0.1, gamma=0.95, epsilon=0.2, seed=None):
        self.n_states = n_states
        self.n_actions = n_actions
        self.alpha = alpha
        self.gamma = gamma
        self.epsilon = epsilon
        self.rng = np.random.default_rng(seed)
        self.q_table = np.zeros((n_states, n_actions))

    def get_action(self, state, explore=True):
        if explore and self.rng.random()  len(prices):
            break

        train_prices = prices[start:train_end]
        test_prices = prices[train_end:test_end]

        train_env = TradingEnv(train_prices)
        test_env = TradingEnv(test_prices)

        agents = []
        for i in range(n_ensemble):
            agent = QLearningAgent(seed=RNG_SEED + w * 10 + i)
            train_agent(agent, train_env, n_episodes=n_episodes)
            agents.append(agent)

        for agent in agents:
            ret = evaluate_agent(agent, TradingEnv(test_prices))
            single_returns.append(ret)

        ens_ret = evaluate_ensemble(agents, TradingEnv(test_prices))
        ensemble_returns.append(ens_ret)

        bh_ret = buy_and_hold_baseline(test_prices)
        baseline_returns.append(bh_ret)

    return single_returns, ensemble_returns, baseline_returns


if __name__ == "__main__":
    prices = load_bars(DB_PATH, SYMBOL, TF)
    print(f"Loaded {len(prices)} bars for {SYMBOL} {TF}")

    single_returns, ensemble_returns, baseline_returns = walk_forward_validation(
        prices, n_windows=3, train_size=100, test_size=50, n_ensemble=3, n_episodes=50
    )

    if len(single_returns) > 0 and len(ensemble_returns) > 0 and len(baseline_returns) > 0:
        single_mean = np.mean(single_returns)
        single_std = np.std(single_returns)
        ensemble_mean = np.mean(ensemble_returns)
        ensemble_std = np.std(ensemble_returns)
        baseline_mean = np.mean(baseline_returns)
        baseline_std = np.std(baseline_returns)

        print("\nSingle agents:")
        print(f"  Cumulative return (mean): {single_mean:.6f}")
        print(f"  Return std deviation: {single_std:.6f}")
        print("\nEnsemble:")
        print(f"  Cumulative return (mean): {ensemble_mean:.6f}")
        print(f"  Return std deviation: {ensemble_std:.6f}")
        print("\nBuy-and-hold baseline:")
        print(f"  Cumulative return (mean): {baseline_mean:.6f}")
        print(f"  Return std deviation: {baseline_std:.6f}")
    else:
        print("Not enough data for walk-forward validation.")