popov/gogo2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refine design

Browse Source
This commit is contained in:
Dobromir Popov
2025-07-23 15:00:08 +03:00
parent 55ea3bce93
commit 2b3c6abdeb
2 changed files with 154 additions and 122 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
.kiro/specs/multi-modal-trading-system/design.md
View File

@ -12,9 +12,9 @@ The system follows a modular architecture with clear separation of concerns:
```mermaid ```mermaid
graph TD graph TD
A[Data Provider] --> B[Data Processor] A[Data Provider] --> B[Data Processor] (calculates pivot points)
B --> C[CNN Model] B --> C[CNN Model]
B --> D[RL Model] B --> D[RL(DQN) Model]
C --> E[Orchestrator] C --> E[Orchestrator]
D --> E D --> E
E --> F[Trading Executor] E --> F[Trading Executor]
@ -67,6 +67,13 @@ Based on the existing implementation in `core/data_provider.py`, we'll enhance i
- Enhance real-time data streaming - Enhance real-time data streaming
- Implement better error handling and fallback mechanisms - Implement better error handling and fallback mechanisms
### BASE FOR ALL MODELS ###
- ***INPUTS***: COB+OHCLV data frame as described:
- OHCLV: 300 frames of (1s, 1m, 1h, 1d) ETH + 300s of 1s BTC
- COB: for each 1s OHCLV we have +- 20 buckets of COB ammounts in USD
- 1,5,15 and 60s MA of the COB imbalance counting +- 5 COB buckets
- ***OUTPUTS***: suggested trade action (BUY/SELL)
### 2. CNN Model ### 2. CNN Model
The CNN Model is responsible for analyzing patterns in market data and predicting pivot points across multiple timeframes. The CNN Model is responsible for analyzing patterns in market data and predicting pivot points across multiple timeframes.
@ -76,6 +83,8 @@ The CNN Model is responsible for analyzing patterns in market data and predictin
- **CNNModel**: Main class for the CNN model. - **CNNModel**: Main class for the CNN model.
- **PivotPointPredictor**: Interface for predicting pivot points. - **PivotPointPredictor**: Interface for predicting pivot points.
- **CNNTrainer**: Class for training the CNN model. - **CNNTrainer**: Class for training the CNN model.
- ***INPUTS***: COB+OHCLV+Old Pivots (5 levels of pivots)
- ***OUTPUTS***: next pivot point for each level as price-time vector. (can be plotted as trend line) + suggested trade action (BUY/SELL)
#### Implementation Details #### Implementation Details
@ -111,13 +120,13 @@ The RL Model is responsible for learning optimal trading strategies based on mar
#### Implementation Details #### Implementation Details
The RL Model will: The RL Model will:
- Accept market data, CNN predictions, and CNN hidden layer states as input - Accept market data, CNN model predictions (output), and CNN hidden layer states as input
- Output trading action recommendations (buy/sell) - Output trading action recommendations (buy/sell)
- Provide confidence scores for each action - Provide confidence scores for each action
- Learn from past experiences to adapt to the current market environment - Learn from past experiences to adapt to the current market environment
Architecture: Architecture:
- State representation: Market data, CNN predictions, CNN hidden layer states - State representation: Market data, CNN model predictions (output), CNN hidden layer states
- Action space: Buy, Sell - Action space: Buy, Sell
- Reward function: PnL, risk-adjusted returns - Reward function: PnL, risk-adjusted returns
- Policy network: Deep neural network - Policy network: Deep neural network
@ -231,6 +240,11 @@ The Orchestrator coordinates training for all models by managing the prediction-
- Monitors model performance degradation and triggers retraining - Monitors model performance degradation and triggers retraining
- Maintains performance metrics for model comparison and selection - Maintains performance metrics for model comparison and selection
**Training progress and checkpoints persistance**
- it uses the checkpoint manager to store check points of each model over time as training progresses and we have improvements
- checkpoint manager has capability to ensure only top 5 to 10 best checkpoints are stored for each model deleting the least performant ones. it stores metadata along the CPs to decide the performance
- we automatically load the best CP at startup if we have stored ones
##### 5. Decision Making and Trading Actions ##### 5. Decision Making and Trading Actions
Beyond coordination, the Orchestrator makes final trading decisions: Beyond coordination, the Orchestrator makes final trading decisions:

254
.kiro/specs/multi-modal-trading-system/tasks.md
View File

@ -1,148 +1,166 @@
# Implementation Plan # Implementation Plan
## Data Provider and Processing ## Enhanced Data Provider and COB Integration
- [ ] 1. Enhance the existing DataProvider class
- [ ] 1. Enhance the existing DataProvider class with standardized model inputs
- Extend the current implementation in core/data_provider.py - Extend the current implementation in core/data_provider.py
- Ensure it supports all required timeframes (1s, 1m, 1h, 1d) - Implement standardized COB+OHLCV data frame for all models
- Implement better error handling and fallback mechanisms - Create unified input format: 300 frames OHLCV (1s, 1m, 1h, 1d) ETH + 300s of 1s BTC
- Integrate with existing multi_exchange_cob_provider.py for COB data
- _Requirements: 1.1, 1.2, 1.3, 1.6_ - _Requirements: 1.1, 1.2, 1.3, 1.6_
- [ ] 1.1. Implement Williams Market Structure pivot point calculation - [ ] 1.1. Implement standardized COB+OHLCV data frame for all models
- Create a dedicated method for identifying pivot points - Create BaseDataInput class with standardized format for all models
- Implement the recursive pivot point calculation as described - Implement OHLCV: 300 frames of (1s, 1m, 1h, 1d) ETH + 300s of 1s BTC
- Add unit tests to verify pivot point detection accuracy - Add COB: ±20 buckets of COB amounts in USD for each 1s OHLCV
- Include 1s, 5s, 15s, and 60s MA of COB imbalance counting ±5 COB buckets
- Ensure all models receive identical input format for consistency
- _Requirements: 1.2, 1.3, 8.1_
- [ ] 1.2. Implement extensible model output storage
- Create standardized ModelOutput data structure
- Support CNN, RL, LSTM, Transformer, and future model types
- Include model-specific predictions and cross-model hidden states
- Add metadata support for extensible model information
- _Requirements: 1.10, 8.2_
- [ ] 1.3. Enhance Williams Market Structure pivot point calculation
- Extend existing williams_market_structure.py implementation
- Improve recursive pivot point calculation accuracy
- Add unit tests to verify pivot point detection
- Integrate with COB data for enhanced pivot detection
- _Requirements: 1.5, 2.7_ - _Requirements: 1.5, 2.7_
- [ ] 1.2. Optimize data caching for better performance - [-] 1.4. Optimize real-time data streaming with COB integration
- Implement efficient caching strategies for different timeframes - Enhance existing WebSocket connections in enhanced_cob_websocket.py
- Add cache invalidation mechanisms - Implement 10Hz COB data streaming alongside OHLCV data
- Ensure thread safety for cache access - Add data synchronization across different refresh rates
- _Requirements: 1.6, 8.1_ - Ensure thread-safe access to multi-rate data streams
- [-] 1.3. Enhance real-time data streaming
- Improve WebSocket connection management
- Implement reconnection strategies
- Add data validation to ensure data integrity
- _Requirements: 1.6, 8.5_ - _Requirements: 1.6, 8.5_
- [ ] 1.4. Implement data normalization ## Enhanced CNN Model Implementation
- Normalize data based on the highest timeframe
- Ensure relationships between different timeframes are maintained
- Add unit tests to verify normalization correctness
- _Requirements: 1.8, 2.1_
## CNN Model Implementation - [ ] 2. Enhance the existing CNN model with standardized inputs/outputs
- Extend the current implementation in NN/models/enhanced_cnn.py
- Accept standardized COB+OHLCV data frame: 300 frames (1s,1m,1h,1d) ETH + 300s 1s BTC
- Include COB ±20 buckets and MA (1s,5s,15s,60s) of COB imbalance ±5 buckets
- Output BUY/SELL trading action with confidence scores - _Requirements: 2.1, 2.2, 2.8, 1.10_
- [ ] 2. Design and implement the CNN model architecture - [ ] 2.1. Implement CNN inference with standardized input format
- Create a CNNModel class that accepts multi-timeframe and multi-symbol data - Accept BaseDataInput with standardized COB+OHLCV format
- Implement the model using PyTorch or TensorFlow - Process 300 frames of multi-timeframe data with COB buckets
- Design the architecture with convolutional, LSTM/GRU, and attention layers - Output BUY/SELL recommendations with confidence scores
- _Requirements: 2.1, 2.2, 2.8_ - Make hidden layer states available for cross-model feeding
- Optimize inference performance for real-time processing
- _Requirements: 2.2, 2.6, 2.8, 4.3_
- [ ] 2.1. Implement pivot point prediction - [x] 2.2. Enhance CNN training pipeline with checkpoint management
- Create a PivotPointPredictor class - Integrate with checkpoint manager for training progress persistence
- Implement methods to predict pivot points for each timeframe - Store top 5-10 best checkpoints based on performance metrics
- Add confidence score calculation for predictions - Automatically load best checkpoint at startup
- _Requirements: 2.2, 2.3, 2.6_ - Implement training triggers based on orchestrator feedback
- Store metadata with checkpoints for performance tracking
- [x] 2.2. Implement CNN training pipeline with comprehensive data storage
- Create a CNNTrainer class with training data persistence
- Implement methods for training the model on historical data
- Add mechanisms to trigger training when new pivot points are detected
- Store all training inputs, outputs, gradients, and loss values for replay
- Implement training episode storage with profitability metrics
- Add capability to replay and retrain on most profitable pivot predictions
- _Requirements: 2.4, 2.5, 5.2, 5.3, 5.7_ - _Requirements: 2.4, 2.5, 5.2, 5.3, 5.7_
- [ ] 2.3. Implement CNN inference pipeline - [ ] 2.3. Implement CNN model evaluation and checkpoint optimization
- Create methods for real-time inference - Create evaluation methods using standardized input/output format
- Ensure hidden layer states are accessible for the RL model - Implement performance metrics for checkpoint ranking
- Optimize for performance to minimize latency - Add validation against historical trading outcomes
- _Requirements: 2.2, 2.6, 2.8_ - Support automatic checkpoint cleanup (keep only top performers)
- Track model improvement over time through checkpoint metadata
- _Requirements: 2.5, 5.8, 4.4_
- [ ] 2.4. Implement model evaluation and validation ## Enhanced RL Model Implementation
- Create methods to evaluate model performance
- Implement metrics for prediction accuracy
- Add validation against historical pivot points
- _Requirements: 2.5, 5.8_
## RL Model Implementation - [ ] 3. Enhance the existing RL model with standardized inputs/outputs
- Extend the current implementation in NN/models/dqn_agent.py
- Accept standardized COB+OHLCV data frame: 300 frames (1s,1m,1h,1d) ETH + 300s 1s BTC
- Include COB ±20 buckets and MA (1s,5s,15s,60s) of COB imbalance ±5 buckets
- Output BUY/SELL trading action with confidence scores
- _Requirements: 3.1, 3.2, 3.7, 1.10_
- [ ] 3. Design and implement the RL model architecture - [ ] 3.1. Implement RL inference with standardized input format
- Create an RLModel class that accepts market data and CNN outputs - Accept BaseDataInput with standardized COB+OHLCV format
- Implement the model using PyTorch or TensorFlow - Process CNN hidden states and predictions as part of state input
- Design the architecture with state representation, action space, and reward function - Output BUY/SELL recommendations with confidence scores
- _Requirements: 3.1, 3.2, 3.7_ - Include expected rewards and value estimates in output
- Optimize inference performance for real-time processing
- _Requirements: 3.2, 3.7, 4.3_
- [ ] 3.1. Implement trading action generation - [ ] 3.2. Enhance RL training pipeline with checkpoint management
- Create a TradingActionGenerator class - Integrate with checkpoint manager for training progress persistence
- Implement methods to generate buy/sell recommendations - Store top 5-10 best checkpoints based on trading performance metrics
- Add confidence score calculation for actions - Automatically load best checkpoint at startup
- Implement experience replay with profitability-based prioritization
- Store metadata with checkpoints for performance tracking
- _Requirements: 3.3, 3.5, 5.4, 5.7, 4.4_
- [ ] 3.3. Implement RL model evaluation and checkpoint optimization
- Create evaluation methods using standardized input/output format
- _Requirements: 3.2, 3.7_ - Implement trading performance metrics for checkpoint ranking
- [ ] 3.2. Implement RL training pipeline with comprehensive experience storage
- Create an RLTrainer class with advanced experience replay
- Implement methods for training the model on historical data
- Store all training episodes with state-action-reward-next_state tuples
- Implement profitability-based experience prioritization
- Add capability to replay and retrain on most profitable trading sequences
- Store gradient information and model checkpoints for each profitable episode
- Implement experience buffer with profit-weighted sampling
- _Requirements: 3.3, 3.5, 5.4, 5.7_
- [ ] 3.3. Implement RL inference pipeline
- Create methods for real-time inference
- Optimize for performance to minimize latency
- Ensure proper handling of CNN inputs
- _Requirements: 3.1, 3.2, 3.4_
- [ ] 3.4. Implement model evaluation and validation
- Create methods to evaluate model performance
- Implement metrics for trading performance
- Add validation against historical trading opportunities - Add validation against historical trading opportunities
- _Requirements: 3.3, 5.8_ - Support automatic checkpoint cleanup (keep only top performers)
- Track model improvement over time through checkpoint metadata
- _Requirements: 3.3, 5.8, 4.4_
## Orchestrator Implementation ## Enhanced Orchestrator Implementation
- [ ] 4. Design and implement the orchestrator architecture - [ ] 4. Enhance the existing orchestrator with centralized coordination
- Create an Orchestrator class that accepts inputs from CNN and RL models - Extend the current implementation in core/orchestrator.py
- Implement the Mixture of Experts (MoE) approach - Implement DataSubscriptionManager for multi-rate data streams
- Design the architecture with gating network and decision network - Add ModelInferenceCoordinator for cross-model coordination
- _Requirements: 4.1, 4.2, 4.5_ - Create ModelOutputStore for extensible model output management
- Add TrainingPipelineManager for continuous learning coordination
- _Requirements: 4.1, 4.2, 4.5, 8.1_
- [ ] 4.1. Implement decision-making logic - [ ] 4.1. Implement data subscription and management system
- Create a DecisionMaker class - Create DataSubscriptionManager class
- Implement methods to make final trading decisions - Subscribe to 10Hz COB data, OHLCV, market ticks, and technical indicators
- Add confidence-based filtering - Implement intelligent caching for "last updated" data serving
- _Requirements: 4.2, 4.3, 4.4_ - Maintain synchronized base dataframe across different refresh rates
- Add thread-safe access to multi-rate data streams
- _Requirements: 4.1, 1.6, 8.5_
- [ ] 4.2. Implement MoE gateway - [ ] 4.2. Implement model inference coordination
- Create a MoEGateway class - Create ModelInferenceCoordinator class
- Implement methods to determine which expert to trust - Trigger model inference based on data availability and requirements
- Add mechanisms for future model integration - Coordinate parallel inference execution for independent models
- _Requirements: 4.5, 8.2_ - Handle model dependencies (e.g., RL waiting for CNN hidden states)
- Assemble appropriate input data for each model type
- _Requirements: 4.2, 3.1, 2.1_
- [ ] 4.3. Implement configurable thresholds - [ ] 4.3. Implement model output storage and cross-feeding
- Add parameters for entering and exiting positions - Create ModelOutputStore class using standardized ModelOutput format
- Implement methods to adjust thresholds dynamically - Store CNN predictions, confidence scores, and hidden layer states
- Add validation to ensure thresholds are within reasonable ranges - Store RL action recommendations and value estimates
- _Requirements: 4.8, 6.7_ - Support extensible storage for LSTM, Transformer, and future models
- Implement cross-model feeding of hidden states and predictions
- Include "last predictions" from all models in base data input
- _Requirements: 4.3, 1.10, 8.2_
- [ ] 4.4. Implement model evaluation and validation - [ ] 4.4. Implement training pipeline management
- Create methods to evaluate orchestrator performance - Create TrainingPipelineManager class
- Implement metrics for decision quality - Call each model's training pipeline with prediction-result pairs
- Add validation against historical trading decisions - Manage training data collection and labeling
- _Requirements: 4.6, 5.8_ - Coordinate online learning updates based on real-time performance
- Track prediction accuracy and trigger retraining when needed
- _Requirements: 4.4, 5.2, 5.4, 5.7_
- [ ] 4.5. Implement enhanced decision-making with MoE
- Create enhanced DecisionMaker class
- Implement Mixture of Experts approach for model integration
- Apply confidence-based filtering to avoid uncertain trades
- Support configurable thresholds for buy/sell decisions
- Consider market conditions and risk parameters in decisions
- _Requirements: 4.5, 4.8, 6.7_
- [ ] 4.6. Implement extensible model integration architecture
- Create MoEGateway class supporting dynamic model addition
- Support CNN, RL, LSTM, Transformer model types without architecture changes
- Implement model versioning and rollback capabilities
- Handle model failures and fallback mechanisms
- Provide model performance monitoring and alerting
- _Requirements: 4.6, 8.2, 8.3_
## Trading Executor Implementation ## Trading Executor Implementation