Initial commit: framework concettuale + design strategico PoC
Stato iniziale del progetto Multi_Swarm_Coevolutive: - 00_documento_zero.md: framework concettuale (Renaissance → swarm co-evolutivo LLM, tre layer cognitivi, decisione strategica A/B/C). - coevolutive_swarm_system.md: design Filone A (sistema completo, co-evoluzione 4 popolazioni, 12-18 mesi). - poc_trading_swarm.md: design Filone B (PoC trading focalizzato, 3-4 mesi, scope semplificato). - docs/superpowers/specs/2026-05-09-decisione-strategica-design.md: decisione strategica B3 (PoC trading incrementale a 3 fasi con gate go/no-go), prodotta tramite skill brainstorming. - .gitignore: pattern Python, editor, secrets, artefatti runtime (runs.db, series/, dataset binari) non versionati. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,831 @@
|
||||
# PoC Trading Swarm — Validazione Strategica
|
||||
|
||||
**Autore**: Adriano Dal Pastro
|
||||
**Data**: Maggio 2026
|
||||
**Status**: Design document — pre-implementazione
|
||||
**Versione**: 0.1
|
||||
**Documento correlato**: `coevolutive_swarm_system.md` (sistema completo)
|
||||
|
||||
---
|
||||
|
||||
## 1. Razionale della deviazione
|
||||
|
||||
Invece di committere 12-18 mesi al sistema co-evolutivo completo descritto nel documento principale, partiamo con un **proof-of-concept strategico** focalizzato su trading, con architettura semplificata, per validare empiricamente se l'idea di base funziona prima di investire nel sistema full.
|
||||
|
||||
**Cosa il PoC valida**:
|
||||
1. Lo swarm produce strategie che superano il null hypothesis statistico (Deflated Sharpe Ratio significativo)?
|
||||
2. Le strategie sono qualitativamente diverse o cloni leggeri?
|
||||
3. Le strategie sopravvivono al regime change out-of-sample?
|
||||
4. Quanto del successo viene da modelli costosi vs economici (ablation multi-tier)?
|
||||
5. Lo swarm batte una baseline statistica tradizionale (random forest + feature engineering)?
|
||||
|
||||
**Tempo target**: 3-4 mesi a impegno significativo.
|
||||
**Budget LLM target**: $2-4K.
|
||||
|
||||
**Decisione post-PoC**:
|
||||
- Se passa tutti i 5 test → procedere con sistema completo (documento principale)
|
||||
- Se passa parzialmente → iterare sul PoC, identificare bottleneck
|
||||
- Se non passa → riformulare. Forse l'edge degli LLM agents è in altri domini, non in pattern discovery numerico
|
||||
|
||||
---
|
||||
|
||||
## 2. Architettura semplificata
|
||||
|
||||
### 2.1 Cosa cambia rispetto al sistema completo
|
||||
|
||||
| Aspetto | Sistema completo | PoC |
|
||||
|------------------------|-----------------------------|------------------------------------|
|
||||
| Popolazioni evolventi | 4 (3 layer + protocollo) | 1 (solo Hypothesis) |
|
||||
| Hypothesis layer | Evolve via GA | Evolve via GA (K=50) |
|
||||
| Falsification layer | Evolve via GA | Hand-crafted, 1 agente fisso |
|
||||
| Adversarial layer | Evolve via GA | Hand-crafted, 1 agente fisso |
|
||||
| Protocollo | Co-evolve | Fisso, designed manualmente |
|
||||
| Domini di applicazione | Multipli | Solo trading BTC/ETH |
|
||||
| Idiom emergence | Sì | No |
|
||||
| Speciation | Sì | Versione semplificata (clustering base) |
|
||||
| Tier multi-model | Sì (S/A/B/C/D) | Sì (semplificato a B/C principalmente) |
|
||||
| Human-in-the-loop | Strutturato ogni 20 gen | Review settimanale informale |
|
||||
|
||||
**Filosofia**: massimizzare apprendimento, minimizzare complessità implementativa.
|
||||
|
||||
### 2.2 Schema architetturale
|
||||
|
||||
```
|
||||
┌───────────────────────────────────┐
|
||||
│ PROTOCOLLO FISSO (S-expression) │
|
||||
│ ~15 verbi designed manualmente │
|
||||
└─────────────┬─────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ HYPOTHESIS SWARM │ ← UNICO layer che evolve
|
||||
│ K=50 agenti │
|
||||
│ Tier mix: B/C │
|
||||
│ GA: tournament, │
|
||||
│ speciation base, │
|
||||
│ novelty bonus │
|
||||
└──────────┬───────────┘
|
||||
│ ipotesi formalizzate
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ FALSIFICATION (hand) │ ← FISSO
|
||||
│ 1 agente Tier-B │
|
||||
│ Funzione: traduce │
|
||||
│ ipotesi in regole + │
|
||||
│ chiama backtest + │
|
||||
│ valuta con DSR │
|
||||
└──────────┬───────────┘
|
||||
│ strategie validate
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ ADVERSARIAL (hand) │ ← FISSO
|
||||
│ 1 agente Tier-A │
|
||||
│ Funzione: red team │
|
||||
│ con checklist statica│
|
||||
│ (lookahead, regime, │
|
||||
│ crowding) │
|
||||
└──────────┬───────────┘
|
||||
│ strategie sopravvissute
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ FITNESS LOOP │
|
||||
│ Update agent_fitness│
|
||||
│ Selezione + GA │
|
||||
└──────────────────────┘
|
||||
│
|
||||
▼
|
||||
Generazione N+1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Le quattro trappole del backtesting su crypto
|
||||
|
||||
Queste sono le killer specifiche del dominio. Vanno mitigate by design, non come afterthought.
|
||||
|
||||
### 3.1 Look-ahead bias subdolo
|
||||
|
||||
**Problema**: molti dati "storici" su crypto sono in realtà revisionati ex-post.
|
||||
- Funding rates: spesso medie giornaliere ricalcolate, non valori real-time storici
|
||||
- On-chain metrics (MVRV, NUPL, SOPR): formule che cambiano nel tempo, applicate retroattivamente
|
||||
- Liste top-N token: survivorship bias massiccio
|
||||
- Sentiment storico: ricostruzioni post-hoc, non disponibili in tempo reale a quei momenti
|
||||
|
||||
**Mitigazione**:
|
||||
- Ogni feature deve avere un campo `availability_lag`: quante ore dopo il timestamp T la feature era effettivamente disponibile
|
||||
- Backtest engine rifiuta di usare feature prima del lag
|
||||
- Documentazione esplicita di come/quando ogni feature è stata raccolta
|
||||
- Preferire fonti che pubblicano archivi real-time (Kaiko, Tardis.dev, Amberdata) a quelle ricostruite
|
||||
|
||||
### 3.2 Multiple testing su scala industriale
|
||||
|
||||
**Problema**: con 10000 strategie testate, ~100 superano p<0.01 per puro caso. Senza correzione, il sistema produce sempre "vincitori" illusori.
|
||||
|
||||
**Mitigazione**:
|
||||
- **Deflated Sharpe Ratio (DSR)** come fitness primaria, non Sharpe naive
|
||||
- Tracking del numero totale di strategie testate fino a generazione N (impatta DSR)
|
||||
- Bonferroni-style correction quando si seleziona "top strategies" da reporting
|
||||
- Hold-out set finale **mai toccato durante evoluzione** per validation finale
|
||||
|
||||
### 3.3 Regime dependency
|
||||
|
||||
**Problema**: BTC/ETH hanno regimi macro molto diversi. Una strategia che funziona 2018-2024 può essere semplicemente "long-only momentum con leva". OOS 2026 fallisce.
|
||||
|
||||
**Periodi di regime distintivi**:
|
||||
- 2017: bull mania retail (escluso dal dataset, troppo anomalo)
|
||||
- 2018-2019: bear lungo
|
||||
- 2020-2021: DeFi summer + bull istituzionale + COVID
|
||||
- 2022: collapse cycle (LUNA, FTX, Celsius)
|
||||
- 2023-2024: ripresa + ETF spot
|
||||
- 2025-2026: post-ETF, regime nuovo
|
||||
|
||||
**Mitigazione**:
|
||||
- Walk-forward con **purged cross-validation** (López de Prado 2018)
|
||||
- Train su finestra mobile, test su successiva, **gap di purging** in mezzo per evitare leakage
|
||||
- Fitness penalizza strategie che funzionano solo su 1-2 regimi
|
||||
- OOS finale obbligatoriamente su periodo diverso dal training
|
||||
|
||||
### 3.4 Backtest ≠ live execution
|
||||
|
||||
**Problema**: anche backtest perfetto ha gap col live.
|
||||
- Slippage non lineare con size (su crypto particolarmente)
|
||||
- Fees variabili (maker/taker, volume rebates)
|
||||
- Funding rate sui perp può mangiarsi l'edge
|
||||
- Liquidità evapora nei momenti che contano
|
||||
- API outages, exchange downtime
|
||||
|
||||
**Mitigazione**:
|
||||
- Modello di slippage realistico (Almgren-Chriss o simile, non costante)
|
||||
- Fees accurate (struttura tier per exchange)
|
||||
- Funding payments simulati per posizioni perp
|
||||
- Cap su size per evitare strategie che funzionano solo a $100, non a $100K
|
||||
|
||||
---
|
||||
|
||||
## 4. Dataset Specification
|
||||
|
||||
### 4.1 Coverage
|
||||
|
||||
- **Asset**: BTC, ETH (focus iniziale)
|
||||
- **Periodo**: 2018-01-01 → 2025-12-31
|
||||
- **Train/OOS split**: train 2018-2023, OOS validation 2024, OOS final hold-out 2025
|
||||
- **Frequenza base**: 1-hour bars (compromesso tra granularità e gestibilità)
|
||||
- **Frequenze derivate**: 4h, 1d aggregate per features di lungo periodo
|
||||
|
||||
### 4.2 Feature catalog
|
||||
|
||||
**Price/Volume (sempre disponibili real-time, lag=0)**:
|
||||
- OHLCV su 1h, 4h, 1d
|
||||
- Returns log su orizzonti multipli
|
||||
- Volatility realized (Garman-Klass, Parkinson, RV)
|
||||
- Volume profile, VWAP
|
||||
|
||||
**Derivatives (lag tipicamente 5-15min)**:
|
||||
- Funding rates (Bybit, Binance, Hyperliquid, Deribit)
|
||||
- Open Interest (per exchange e aggregato)
|
||||
- Put/Call ratio (Deribit options)
|
||||
- Implied volatility surface (Deribit)
|
||||
- Skew, term structure
|
||||
- Liquidations (volume e direzione)
|
||||
|
||||
**On-chain (lag tipicamente 1-6 ore per finalization)**:
|
||||
- Active addresses
|
||||
- Transaction count + volume
|
||||
- Exchange inflows/outflows (Glassnode-style)
|
||||
- Miner flows
|
||||
- Whale transactions (>$1M)
|
||||
- MVRV, NUPL, SOPR (con cautela su revisionalità)
|
||||
|
||||
**Macro context (lag variabile)**:
|
||||
- DXY, gold, S&P 500, yield 10Y (per correlazioni)
|
||||
- Crypto-specific: BTC dominance, ETH/BTC ratio, total market cap
|
||||
- Stablecoin supply (USDT, USDC, DAI)
|
||||
|
||||
**Sentiment (lag variabile, qualità incerta)**:
|
||||
- Funding rate come proxy sentiment
|
||||
- Open Interest variations come proxy speculation
|
||||
- (Skip Twitter/social per ora — qualità storica troppo bassa)
|
||||
|
||||
### 4.3 Data sources
|
||||
|
||||
**Preferiti** (real-time archivi):
|
||||
- Tardis.dev (derivatives, order book, trades — premium)
|
||||
- Kaiko (institutional grade — premium)
|
||||
- Amberdata (multi-source)
|
||||
|
||||
**Backup gratuiti/cheap**:
|
||||
- CCXT historical (OHLCV affidabile)
|
||||
- Binance/Bybit/Deribit API direct (con cautela su gap)
|
||||
- CoinGlass (derivatives aggregati, qualità media)
|
||||
- Glassnode free tier (on-chain, limitato)
|
||||
|
||||
**Da evitare**:
|
||||
- Aggregatori che non documentano metodologia
|
||||
- Source che hanno cambiato formula nel tempo senza versioning
|
||||
|
||||
### 4.4 Storage
|
||||
|
||||
```sql
|
||||
CREATE TABLE features (
|
||||
timestamp TIMESTAMPTZ NOT NULL,
|
||||
asset TEXT NOT NULL,
|
||||
feature_name TEXT NOT NULL,
|
||||
value DOUBLE PRECISION,
|
||||
availability_lag_seconds INT NOT NULL, -- CRITICO
|
||||
source TEXT,
|
||||
version TEXT, -- per gestire cambi di metodologia
|
||||
PRIMARY KEY (timestamp, asset, feature_name)
|
||||
);
|
||||
|
||||
CREATE INDEX idx_feat_time ON features (timestamp);
|
||||
CREATE INDEX idx_feat_asset_name ON features (asset, feature_name);
|
||||
```
|
||||
|
||||
Considerare TimescaleDB se le query temporali diventano colli di bottiglia.
|
||||
|
||||
---
|
||||
|
||||
## 5. Backtest Engine
|
||||
|
||||
### 5.1 Requisiti
|
||||
|
||||
- **Determinismo**: stesso input, stesso output, sempre
|
||||
- **Velocità**: target ≥100 backtest/sec su CPU normale (per gestire 50 agenti × 10 ipotesi/gen)
|
||||
- **Anti-leakage by design**: rifiuta feature prima di availability_lag
|
||||
- **Walk-forward integrato**: non opzionale, parte del flow base
|
||||
- **Realistic execution**: slippage, fees, funding
|
||||
|
||||
### 5.2 Architettura
|
||||
|
||||
**Linguaggio**: Python+NumPy per il PoC. Rust+PyO3 solo se diventa bottleneck (probabile in fase scaling, non necessario per PoC).
|
||||
|
||||
**API base**:
|
||||
```python
|
||||
class BacktestEngine:
|
||||
def run(self,
|
||||
strategy: StrategySpec,
|
||||
features: FeatureSet,
|
||||
time_range: tuple[datetime, datetime],
|
||||
walk_forward_config: WFConfig) -> BacktestResult:
|
||||
...
|
||||
|
||||
def run_with_dsr(self,
|
||||
strategy: StrategySpec,
|
||||
...) -> tuple[BacktestResult, DSRStats]:
|
||||
...
|
||||
|
||||
@dataclass
|
||||
class StrategySpec:
|
||||
entry_rules: list[Rule] # condizioni di ingresso
|
||||
exit_rules: list[Rule] # condizioni di uscita
|
||||
sizing: SizingRule # position sizing
|
||||
instruments: list[str] # BTC, ETH, BTC-PERP, etc.
|
||||
constraints: list[Constraint] # max leverage, max DD, etc.
|
||||
|
||||
@dataclass
|
||||
class BacktestResult:
|
||||
pnl_curve: pd.Series
|
||||
sharpe: float
|
||||
sortino: float
|
||||
max_drawdown: float
|
||||
n_trades: int
|
||||
win_rate: float
|
||||
avg_holding_time: timedelta
|
||||
fees_paid: float
|
||||
funding_paid: float
|
||||
slippage_cost: float
|
||||
regime_breakdown: dict[str, float] # PnL per regime
|
||||
```
|
||||
|
||||
### 5.3 Execution model
|
||||
|
||||
**Slippage**:
|
||||
```
|
||||
slippage = base_spread + impact_factor * (size / avg_volume_5min) ^ 0.5
|
||||
```
|
||||
Calibrato su book reale per BTC/ETH. Più alto in regimi di alta volatilità.
|
||||
|
||||
**Fees**:
|
||||
- Maker: 0.02% (tipico)
|
||||
- Taker: 0.05% (tipico)
|
||||
- Tier per volume non simulato nel PoC (assume tier base)
|
||||
|
||||
**Funding** (per perp):
|
||||
- Pagato/ricevuto ogni 8 ore
|
||||
- Calcolato su mark price × position size × funding rate
|
||||
|
||||
**Constraints automatiche**:
|
||||
- Max leverage (configurabile, default 5x per il PoC)
|
||||
- Margin call simulati realisticamente
|
||||
- Liquidations forzate se margin scende sotto threshold
|
||||
|
||||
### 5.4 Walk-forward purged CV
|
||||
|
||||
```
|
||||
Time: |---------train-----------|gap|----test----|---next gap---|--next test--|
|
||||
Window 1: [2018-01 ──────── 2020-06] [2020-07 ──── 2020-12]
|
||||
Window 2: [2018-07 ──── 2021-06] [2021-07 ──── 2021-12]
|
||||
Window 3: [2019-01 ── 2022-06] [2022-07 ── 2022-12]
|
||||
...
|
||||
```
|
||||
|
||||
- Training window: 30 mesi
|
||||
- Gap (purging): 1 mese (evita leakage da event horizon)
|
||||
- Test window: 6 mesi
|
||||
- Step: 6 mesi
|
||||
- Embargo: ulteriori 2 settimane post-test prima del prossimo training (López de Prado embargo)
|
||||
|
||||
---
|
||||
|
||||
## 6. Hypothesis Swarm (l'unico layer che evolve)
|
||||
|
||||
### 6.1 Genome design
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class HypothesisAgentGenome:
|
||||
# Cognizione
|
||||
system_prompt: str
|
||||
cognitive_style: str # "physicist", "biologist", "engineer", "trader_oldschool"...
|
||||
|
||||
# Accesso a dati
|
||||
feature_access: list[str] # subset delle feature disponibili
|
||||
lookback_window_days: int # quanto storico vede
|
||||
timeframes: list[str] # ["1h", "4h", "1d"]
|
||||
|
||||
# Modello
|
||||
model_tier: ModelTier # B o C principalmente nel PoC
|
||||
temperature: float # 0.6 - 1.2
|
||||
|
||||
# Bias di output
|
||||
strategy_type_preference: list[str] # ["mean_reversion", "momentum", "vol_arb", "cross_asset"]
|
||||
timeframe_preference: str # "intraday", "swing", "position"
|
||||
|
||||
# Tracking
|
||||
parent_ids: list[UUID]
|
||||
generation: int
|
||||
species_id: UUID
|
||||
```
|
||||
|
||||
### 6.2 Output format (nel protocollo fisso)
|
||||
|
||||
```
|
||||
PROPOSE_STRATEGY(
|
||||
id=#strat_47,
|
||||
name="vol_skew_momentum",
|
||||
|
||||
entry_conditions=[
|
||||
AND(
|
||||
(deribit_skew_25d > rolling_mean(deribit_skew_25d, 30d) + 1.5*std),
|
||||
(btc_funding_8h > 0.01),
|
||||
(eth_funding_8h > btc_funding_8h)
|
||||
)
|
||||
],
|
||||
|
||||
exit_conditions=[
|
||||
OR(
|
||||
(skew normalized below mean),
|
||||
(max_holding > 7d),
|
||||
(drawdown > 0.03)
|
||||
)
|
||||
],
|
||||
|
||||
sizing=KELLY_FRACTIONAL(fraction=0.25),
|
||||
instruments=["ETH-PERP-HL"],
|
||||
side="long",
|
||||
|
||||
rationale="Skew elevato indica fear di puts, funding alto indica long crowding. Cross-section ETH/BTC funding suggerisce ETH outperformance attesa.",
|
||||
|
||||
expected_regime="normal volatility, trending",
|
||||
expected_failure_modes=["crash con depinning", "regime shift improvviso"]
|
||||
)
|
||||
```
|
||||
|
||||
### 6.3 Operatori genetici
|
||||
|
||||
**Mutazione del system prompt**:
|
||||
- LLM-as-mutator (Tier-B): "Modifica questo prompt cambiando un aspetto cognitivo, mantenendo intent"
|
||||
- Probabilità: 60% per agente selezionato
|
||||
|
||||
**Mutazione di feature_access**:
|
||||
- Add/remove 1-3 feature random
|
||||
- Probabilità: 30%
|
||||
|
||||
**Mutazione di temperature**:
|
||||
- Gaussiana, σ=0.1, clip [0.3, 1.4]
|
||||
- Probabilità: 20%
|
||||
|
||||
**Crossover**:
|
||||
- 50/50 di feature_access da due parent
|
||||
- Cognitive_style preso da parent migliore
|
||||
- System prompt: crossover sezione-by-sezione (role/context/instructions/output_format)
|
||||
- Probabilità: 50% per nuova generazione (resto è mutazione)
|
||||
|
||||
**Mutazione di model_tier**:
|
||||
- Rara (5%), perché impatta costo
|
||||
- Solo C↔B, non promozioni a A senza fitness eccezionale
|
||||
|
||||
### 6.4 Selection
|
||||
|
||||
**Tournament selection**, k=5.
|
||||
|
||||
**Speciation semplificata**:
|
||||
- Embedding del system prompt via Voyage o OpenAI ada
|
||||
- K-means con K=5-7 cluster
|
||||
- Fitness sharing dentro cluster
|
||||
|
||||
**Elitismo**: top 3 agenti per cluster sopravvivono non modificati.
|
||||
|
||||
**Immigrazione**: ogni 10 generazioni, 5 nuovi agenti random vengono inseriti (anti-stagnazione).
|
||||
|
||||
---
|
||||
|
||||
## 7. Falsification Agent (hand-crafted, fisso)
|
||||
|
||||
### 7.1 Ruolo
|
||||
|
||||
Prende ipotesi dal swarm, le esegue su backtest engine, riporta risultati con DSR e diagnostica.
|
||||
|
||||
**NON** valuta soggettivamente. Esegue test deterministici e li interpreta.
|
||||
|
||||
### 7.2 Modello
|
||||
|
||||
Tier-B (Qwen Max o equivalente). Sufficiente per:
|
||||
- Tradurre ipotesi in linguaggio naturale → StrategySpec strutturato
|
||||
- Chiamare backtest engine
|
||||
- Interpretare output numerico
|
||||
- Riportare in protocollo
|
||||
|
||||
### 7.3 System prompt template
|
||||
|
||||
```
|
||||
Sei un agente di falsification rigoroso. Il tuo ruolo è testare ipotesi
|
||||
trading senza pregiudizi e riportare risultati onesti.
|
||||
|
||||
Per ogni ipotesi ricevuta:
|
||||
1. Verifica che le entry/exit conditions siano formalizzabili in regole testabili
|
||||
2. Verifica che le feature richieste rispettino availability_lag
|
||||
3. Chiama il backtest engine con configurazione walk-forward standard
|
||||
4. Calcola Deflated Sharpe Ratio considerando il numero di test fatti finora ({total_trials})
|
||||
5. Riporta breakdown per regime (bear/bull/sideways)
|
||||
6. Identifica failure modes osservati nel backtest
|
||||
|
||||
Output strict in protocollo S-expression. Nessuna interpretazione narrativa.
|
||||
Se l'ipotesi non è formalizzabile, ritorna REJECT con motivo specifico.
|
||||
```
|
||||
|
||||
### 7.4 Output format
|
||||
|
||||
```
|
||||
REPORT_BACKTEST(
|
||||
target=#strat_47,
|
||||
|
||||
metrics=(
|
||||
sharpe=1.34,
|
||||
deflated_sharpe=0.87,
|
||||
p_value=0.04,
|
||||
max_drawdown=0.18,
|
||||
n_trades=143,
|
||||
avg_holding_h=42
|
||||
),
|
||||
|
||||
regime_performance=(
|
||||
bear_2018=0.42,
|
||||
bull_2020=2.1,
|
||||
crash_2022=-0.85,
|
||||
recovery_2023=1.1
|
||||
),
|
||||
|
||||
warnings=[
|
||||
"Performance dominated by 2020-2021 regime",
|
||||
"DSR significant but multiple testing burden high (8400 strategies tested)"
|
||||
],
|
||||
|
||||
verdict=PASS_WITH_WARNINGS // PASS / FAIL / PASS_WITH_WARNINGS
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Adversarial Agent (hand-crafted, fisso)
|
||||
|
||||
### 8.1 Ruolo
|
||||
|
||||
Per ogni strategia che passa Falsification, applica una **checklist statica** di attacchi epistemici.
|
||||
|
||||
Nel PoC NON evolve. Ha vocabolario fisso di attacchi noti dalla letteratura (López de Prado, Bailey, etc.).
|
||||
|
||||
### 8.2 Modello
|
||||
|
||||
Tier-A (Sonnet). Qui il reasoning conta — riconoscere lookahead bias subtle richiede capacità.
|
||||
|
||||
### 8.3 Checklist di attacchi
|
||||
|
||||
```
|
||||
1. Lookahead bias check
|
||||
- Tutte le feature usate rispettano availability_lag?
|
||||
- Qualche feature è "future-derived" subdolamente?
|
||||
|
||||
2. Survivorship bias check
|
||||
- La strategia usa universo di asset dinamico?
|
||||
- Filtra solo asset sopravvissuti?
|
||||
|
||||
3. Regime dependency check
|
||||
- Performance concentrata in 1-2 regimi specifici?
|
||||
- Cosa succede se rimuovi il regime migliore?
|
||||
|
||||
4. Multiple testing severity
|
||||
- DSR resta significativo dopo Bonferroni stretto?
|
||||
- Confronto con random strategy baseline
|
||||
|
||||
5. Crowding plausibility
|
||||
- La logica è "ovvia"? Probabilmente già crowded
|
||||
- Edge size ragionevole o sospettosamente alto?
|
||||
|
||||
6. Implementation friction
|
||||
- Slippage assumption realistica per la size?
|
||||
- Funding payments inclusi correttamente?
|
||||
- Trade frequency compatibile con execution reale?
|
||||
|
||||
7. Feature stability
|
||||
- Le feature critiche hanno stessa metodologia in tutto il periodo?
|
||||
- Source provider ha cambiato formula?
|
||||
|
||||
8. Statistical robustness
|
||||
- Sharpe sensibile a rimozione top 5% trade?
|
||||
- Performance robusta a perturbazioni piccole nei parametri?
|
||||
```
|
||||
|
||||
### 8.4 Output
|
||||
|
||||
```
|
||||
ADVERSARIAL_REVIEW(
|
||||
target=#strat_47,
|
||||
attacks_passed=[1, 2, 5, 6, 7],
|
||||
attacks_failed=[3, 4, 8],
|
||||
|
||||
critical_concerns=[
|
||||
CONCERN(
|
||||
type=regime_dependency,
|
||||
severity=high,
|
||||
detail="60% of PnL from 2020-2021 bull regime. Removing it gives Sharpe 0.4."
|
||||
),
|
||||
CONCERN(
|
||||
type=multiple_testing,
|
||||
severity=medium,
|
||||
detail="DSR significant but only marginally (p=0.04). With 8400 trials, expect ~336 false positives at this level."
|
||||
)
|
||||
],
|
||||
|
||||
verdict=REJECT // ACCEPT / ACCEPT_CONDITIONAL / REJECT
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Fitness Function
|
||||
|
||||
### 9.1 Agent fitness (per Hypothesis swarm)
|
||||
|
||||
```python
|
||||
def agent_fitness(agent: HypothesisAgentGenome,
|
||||
episodes: list[Episode]) -> float:
|
||||
|
||||
# Quality of contributions
|
||||
accepted_strats = [e for e in episodes
|
||||
if e.adversarial_verdict == "ACCEPT"]
|
||||
conditional_strats = [e for e in episodes
|
||||
if e.adversarial_verdict == "ACCEPT_CONDITIONAL"]
|
||||
|
||||
quality_score = (
|
||||
len(accepted_strats) * 1.0
|
||||
+ len(conditional_strats) * 0.3
|
||||
)
|
||||
|
||||
# Average DSR of accepted strategies
|
||||
avg_dsr = np.mean([e.dsr for e in accepted_strats]) if accepted_strats else 0
|
||||
|
||||
# Cost penalty (proporzionale al tier usato)
|
||||
cost_per_episode = TIER_COST[agent.model_tier] * agent.avg_tokens_per_episode
|
||||
cost_penalty = cost_per_episode * COST_PENALTY_LAMBDA
|
||||
|
||||
# Novelty bonus (semantica delle strategie prodotte)
|
||||
novelty_score = compute_novelty(agent, all_agents_in_generation)
|
||||
|
||||
# Diversity bonus (strategie diverse, non cloni)
|
||||
diversity_score = compute_internal_diversity(agent.strategies)
|
||||
|
||||
return (
|
||||
quality_score
|
||||
+ avg_dsr * DSR_WEIGHT
|
||||
+ novelty_score * NOVELTY_WEIGHT
|
||||
+ diversity_score * DIVERSITY_WEIGHT
|
||||
- cost_penalty
|
||||
)
|
||||
```
|
||||
|
||||
### 9.2 Pesi iniziali (da calibrare empiricamente)
|
||||
|
||||
```python
|
||||
DSR_WEIGHT = 2.0 # peso forte: vogliamo edge reale
|
||||
NOVELTY_WEIGHT = 0.5 # bonus moderato per esplorazione
|
||||
DIVERSITY_WEIGHT = 0.3 # leggero, evita cloni
|
||||
COST_PENALTY_LAMBDA = 0.1 # da calibrare in base a budget
|
||||
```
|
||||
|
||||
### 9.3 Anti-gaming
|
||||
|
||||
- Tracking globale del numero di test fatti per DSR correction
|
||||
- Cap su `quality_score` per evitare gaming via spam di ipotesi banali
|
||||
- Adversarial feedback va in fitness (strategie REJECTED penalizzano, non solo non bonificano)
|
||||
- Periodic audit umano: ogni 10 generazioni rivedere top 5 strategies, marcare "spurious" se gaming
|
||||
|
||||
---
|
||||
|
||||
## 10. Baseline non-LLM (anti-illusion check)
|
||||
|
||||
**Critico**: il PoC deve includere una baseline statistica tradizionale.
|
||||
|
||||
### 10.1 Specifica baseline
|
||||
|
||||
- **Metodo**: Random Forest + feature engineering manuale
|
||||
- **Features**: stesso pool del swarm
|
||||
- **Target**: returns N-bar future (predizione regression o classification)
|
||||
- **Validation**: stesso walk-forward purged CV
|
||||
- **Output**: trade signals → backtest engine identico
|
||||
|
||||
### 10.2 Confronto
|
||||
|
||||
| Metrica | Baseline RF | Swarm LLM |
|
||||
|----------------------------|-------------|-----------|
|
||||
| Best DSR found | ? | ? |
|
||||
| Avg DSR top-10 strategies | ? | ? |
|
||||
| N strategies passing adv. | ? | ? |
|
||||
| Diversity (semantic) | ? | ? |
|
||||
| Total cost | ~$50 | ~$3K |
|
||||
|
||||
**Interpretazione**:
|
||||
- Se Swarm batte significativamente Baseline → architettura LLM sta aggiungendo valore
|
||||
- Se Swarm pareggia → costo non giustificato per discovery numerica pura
|
||||
- Se Swarm perde → l'edge degli LLM agents è altrove (creatività su task non numerici, integrazione semi-strutturata)
|
||||
|
||||
**Punto importante**: anche se Swarm perde su pattern discovery numerico, NON significa che il sistema co-evolutivo completo è inutile. Significa che la value-add è in altri domini (ipotesi macro, integrazione narrative, generalizzazione cross-domain). È informazione preziosa.
|
||||
|
||||
---
|
||||
|
||||
## 11. Roadmap Implementativa (3-4 mesi)
|
||||
|
||||
### Settimane 1-3: Setup & Dataset
|
||||
|
||||
- Setup repo, environment, dependencies
|
||||
- Data sourcing: identificare provider, sottoscrivere se necessario
|
||||
- Data ingestion: pipeline dati storici BTC/ETH 2018-2025
|
||||
- Storage schema (PostgreSQL/TimescaleDB)
|
||||
- Audit di availability_lag per ogni feature
|
||||
- Sanity checks: confronto cross-source per validare integrity
|
||||
|
||||
**Deliverable**: dataset completo annotato, query-able, con feature catalog.
|
||||
|
||||
### Settimane 4-7: Backtest Engine
|
||||
|
||||
- Implementazione walk-forward purged CV
|
||||
- Slippage model (Almgren-Chriss)
|
||||
- Fees + funding
|
||||
- DSR computation
|
||||
- Test di non-leakage (deliberately inject lookahead → engine deve catcharlo)
|
||||
- Performance optimization (target ≥100 backtest/sec)
|
||||
|
||||
**Deliverable**: backtest engine standalone testato. Strategie semplici (buy & hold, 50/200 SMA crossover) producono risultati noti.
|
||||
|
||||
### Settimane 8-9: Agenti hand-crafted
|
||||
|
||||
- Falsification agent (Tier-B)
|
||||
- Adversarial agent (Tier-A)
|
||||
- Protocol fisso (S-expression parser + 15 verbi)
|
||||
- Message bus auditato semplificato
|
||||
- Test end-to-end con ipotesi hand-crafted
|
||||
|
||||
**Deliverable**: pipeline agente → falsification → adversarial → verdict, funzionante end-to-end con strategie inserite manualmente.
|
||||
|
||||
### Settimane 10-12: Hypothesis Swarm + GA
|
||||
|
||||
- Population manager (50 agenti)
|
||||
- Operatori genetici (mutazione + crossover)
|
||||
- Speciation con clustering embedding
|
||||
- Fitness computation
|
||||
- Tournament selection
|
||||
- Evoluzione per 50 generazioni baseline
|
||||
|
||||
**Deliverable**: swarm che evolve, fitness che migliora over generations, output di top strategies.
|
||||
|
||||
### Settimane 13-14: Baseline + Comparison
|
||||
|
||||
- Implementazione baseline Random Forest
|
||||
- Run baseline su stesso dataset/timeframe
|
||||
- Tabella comparison
|
||||
- Analisi qualitative delle strategie prodotte da entrambi
|
||||
|
||||
**Deliverable**: documento di confronto onesto.
|
||||
|
||||
### Settimane 15-16: Analisi & Report
|
||||
|
||||
- Run finale su hold-out set 2025
|
||||
- Analysis: ablation multi-tier, regime breakdown, diversity analysis
|
||||
- Documentazione lessons learned
|
||||
- Decision document: procedere con sistema completo, iterare PoC, o pivot
|
||||
|
||||
**Deliverable**: report finale con risposte alle 5 domande di validazione iniziali.
|
||||
|
||||
---
|
||||
|
||||
## 12. Costi PoC
|
||||
|
||||
### 12.1 LLM costs
|
||||
|
||||
| Fase | Calls stimate | Tokens stimati | Tier mix | Costo |
|
||||
|-------------------------|---------------|-----------------|--------------|--------|
|
||||
| Setup + agenti hand | ~500 | 2M | A/B | ~$50 |
|
||||
| Test pipeline | ~2000 | 8M | B/C | ~$30 |
|
||||
| GA run principale | 50 gen × 50 agent × 10 calls × 5K tok = 125M tok | mostly C, some B | ~$300-500 |
|
||||
| Repeat runs (3x) | (per ablation, tuning) | | | ~$1000-1500 |
|
||||
| Hold-out validation | ~1000 | 5M | A (judge) | ~$80 |
|
||||
| **Totale** | | | | **$1500-2500** |
|
||||
|
||||
Più conservativo se aggiungiamo iteration overhead: **budget $2-4K**.
|
||||
|
||||
### 12.2 Infrastruttura
|
||||
|
||||
- Compute (locale o cloud modesto): ~$200-400 totali
|
||||
- Storage (data + logs): ~$50/mese
|
||||
- Data subscription (Tardis o Kaiko per derivatives): variabile, $0-500/mese a seconda della qualità richiesta
|
||||
|
||||
### 12.3 Tempo
|
||||
|
||||
- Realistic estimate: **3-4 mesi** a 3-4 giorni/settimana effettivi
|
||||
- Pessimistic estimate: 5-6 mesi se data sourcing risulta più complesso del previsto
|
||||
|
||||
---
|
||||
|
||||
## 13. Rischi e Mitigazioni
|
||||
|
||||
| Rischio | Probabilità | Impatto | Mitigazione |
|
||||
|------------------------------------|-------------|---------|-----------------------------------------|
|
||||
| Data sourcing più complesso | Alta | Medio | Start con CCXT + Binance free, upgrade dopo |
|
||||
| Backtest engine ha bug subtle | Alta | Critico | Test deliberato di lookahead injection |
|
||||
| Swarm non batte baseline RF | Media | Alto | È un risultato comunque, non fallimento |
|
||||
| Costi over-budget | Media | Medio | Cap hard, monitor settimanale |
|
||||
| Time over-budget (5+ mesi) | Alta | Medio | Milestone bi-settimanali, taglio scope se necessario |
|
||||
| Convergenza prematura del swarm | Media | Alto | Speciation, novelty bonus, immigrazione |
|
||||
| OpenRouter qualità inconsistente | Media | Basso | Fallback policy, monitor success rate |
|
||||
|
||||
---
|
||||
|
||||
## 14. Decisioni Aperte
|
||||
|
||||
Da risolvere prima di Fase 1:
|
||||
|
||||
1. **Asset focus**: solo BTC, solo ETH, o entrambi? (suggerito: entrambi, per cross-asset features)
|
||||
2. **Data provider primario**: pagare Tardis/Kaiko o partire con free sources? (suggerito: free per Fase 1, upgrade se necessario)
|
||||
3. **Hardware**: locale o cloud? (suggerito: locale, dataset ~50-100GB gestibile)
|
||||
4. **Tier-A budget**: quanto reservare a Sonnet per Adversarial? (suggerito: $300-500 cap)
|
||||
5. **Frequency primaria**: 1h confermato o scendere a 15min? (suggerito: 1h, evita overfitting su microstructure)
|
||||
|
||||
---
|
||||
|
||||
## 15. Cosa il PoC NON fa (e va bene)
|
||||
|
||||
- NON evolve il protocollo (sistema completo)
|
||||
- NON co-evolve Falsification e Adversarial (sistema completo)
|
||||
- NON esplora idiom emergence (sistema completo)
|
||||
- NON applica a domini non-trading (sistema completo)
|
||||
- NON cerca breakthrough singoli, cerca **validazione architetturale**
|
||||
- NON è un trading bot pronto per capitale reale (mai dopo PoC, paper trading prima)
|
||||
|
||||
Il PoC è un **esperimento controllato**. Il sistema completo è il prodotto. Sono cose diverse, e va bene così.
|
||||
|
||||
---
|
||||
|
||||
## 16. Decision Triggers
|
||||
|
||||
Dopo PoC, queste sono le decisioni discrete:
|
||||
|
||||
**GO al sistema completo se**:
|
||||
- Swarm produce ≥5 strategie con DSR significativo dopo Adversarial
|
||||
- Swarm batte baseline RF di ≥30% in best-DSR e diversity
|
||||
- Strategie sopravvivono a OOS 2025 (regime change)
|
||||
- Multi-tier ablation conferma valore (no significant loss usando 70% Tier-C)
|
||||
|
||||
**ITERATE PoC se**:
|
||||
- Risultati borderline (alcuni indicatori sì, altri no)
|
||||
- Bug specifici identificabili (es. GA non diversifica → fix speciation)
|
||||
- Architettura sembra giusta ma implementazione perfettibile
|
||||
|
||||
**PIVOT se**:
|
||||
- Swarm decisamente perde vs baseline su discovery numerica
|
||||
- Ma: considerare pivot verso domini non-numerici (offerte commerciali, code review)
|
||||
- O: considerare uso del swarm come *generator* di ipotesi macro/strutturali, non pattern numerici
|
||||
|
||||
---
|
||||
|
||||
*Documento da aggiornare durante PoC. Questa è v0.1, scritta prima di qualunque implementazione.*
|
||||
*Documento principale (sistema completo): `coevolutive_swarm_system.md`*
|
||||
Reference in New Issue
Block a user