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,660 @@
|
||||
# Sistema Co-Evolutivo Multi-Agente con Linguaggio Emergente
|
||||
|
||||
**Autore**: Adriano Dal Pastro
|
||||
**Data**: Maggio 2026
|
||||
**Status**: Design document — pre-implementazione
|
||||
**Versione**: 0.1
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Sistema di ricerca quantitativa basato su **co-evoluzione di quattro popolazioni**: tre layer cognitivi (Hypothesis / Falsification / Adversarial) e un protocollo di comunicazione che evolve insieme agli agenti. L'obiettivo non è "un trading bot più intelligente", ma un'**architettura cognitiva ecologica** capace di scoprire pattern e concetti non programmati esplicitamente.
|
||||
|
||||
L'introduzione di un **tier multi-model** (Anthropic Claude tramite API + modelli economici tipo Qwen via OpenRouter) cambia radicalmente l'economia del sistema: rende fattibili popolazioni 5-10x più grandi e numero di generazioni 3-5x più alto a parità di budget, abilitando regimi evolutivi prima irraggiungibili per progetti retail.
|
||||
|
||||
**Domini di applicazione iniziali**:
|
||||
- Trading derivati crypto (Deribit options, Hyperliquid perps) — caso primario
|
||||
- Generazione offerte commerciali Tielogic — caso secondario, ad alto ROI immediato
|
||||
- Code review e generazione documentazione — caso terziario
|
||||
|
||||
---
|
||||
|
||||
## 2. Architettura del Sistema
|
||||
|
||||
### 2.1 Visione d'insieme
|
||||
|
||||
```
|
||||
┌─────────────────────────┐
|
||||
│ PROTOCOL GENOME (PG) │
|
||||
│ - syntax (fixed) │
|
||||
│ - vocabulary (evolves) │
|
||||
│ - idioms (emerge) │
|
||||
│ - registers (specialize)│
|
||||
└────────────┬────────────┘
|
||||
│ specifies
|
||||
▼
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ HYPOTHESIS │ │ FALSIFICATION│ │ ADVERSARIAL │
|
||||
│ SWARM │◄──►│ SWARM │◄──►│ SWARM │
|
||||
│ │ │ │ │ │
|
||||
│ K_h agents │ │ K_f agents │ │ K_a agents │
|
||||
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
|
||||
│ │ │
|
||||
└───────────────────┼───────────────────┘
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ SHARED ENVIRONMENT │
|
||||
│ - market data │
|
||||
│ - backtest engine │
|
||||
│ - message bus │
|
||||
│ - audit log │
|
||||
└─────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ FITNESS COMPUTATION│
|
||||
│ - per-agent │
|
||||
│ - per-team │
|
||||
│ - per-protocol │
|
||||
└─────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 Le quattro popolazioni co-evolventi
|
||||
|
||||
#### 2.2.1 Hypothesis Swarm
|
||||
|
||||
**Ruolo**: generare ipotesi su anomalie di mercato. Alta temperatura, stili cognitivi diversi, ricerca esplorativa.
|
||||
|
||||
**Genoma**:
|
||||
```python
|
||||
@dataclass
|
||||
class HypothesisAgentGenome:
|
||||
system_prompt: str # ruolo cognitivo
|
||||
feature_access: list[str] # subset feature disponibili
|
||||
temperature: float # 0.7 - 1.3 tipico
|
||||
top_p: float
|
||||
model_tier: ModelTier # vedi sez. 4
|
||||
lookback_window: int # giorni di storico visibili
|
||||
cognitive_style: str # "physicist", "biologist", "historian"...
|
||||
protocol_dialect_bias: dict # preferenze su verbi del protocollo
|
||||
```
|
||||
|
||||
**Output atteso**: ipotesi formalizzate nel protocollo, tipo:
|
||||
```
|
||||
PROPOSE_HYPOTHESIS(
|
||||
pattern="vol_skew_pre_FOMC",
|
||||
conditions=[regime=normal, days_to_event<=7],
|
||||
predicted_effect=skew_widening,
|
||||
confidence=0.6,
|
||||
rationale_ref=#analysis_142
|
||||
)
|
||||
```
|
||||
|
||||
#### 2.2.2 Falsification Swarm
|
||||
|
||||
**Ruolo**: testare rigorosamente le ipotesi. Bassa temperatura, focus su statistica, walk-forward, multiple testing correction.
|
||||
|
||||
**Genoma**:
|
||||
```python
|
||||
@dataclass
|
||||
class FalsificationAgentGenome:
|
||||
system_prompt: str
|
||||
statistical_test_preferences: list[str] # ["bonferroni", "BH", "white_reality_check"]
|
||||
rigor_level: float # quanto è severa la soglia
|
||||
walk_forward_config: WalkForwardConfig
|
||||
temperature: float # 0.1 - 0.4 tipico
|
||||
model_tier: ModelTier
|
||||
```
|
||||
|
||||
**Caratteristica importante**: il falsification layer NON valuta soggettivamente. Esegue test deterministici e li interpreta. Questo lo rende perfetto per modelli economici.
|
||||
|
||||
#### 2.2.3 Adversarial Swarm
|
||||
|
||||
**Ruolo**: red team epistemico. Cerca data snooping, lookahead bias, regime fragility, crowding. Paranoia strutturale.
|
||||
|
||||
**Genoma**:
|
||||
```python
|
||||
@dataclass
|
||||
class AdversarialAgentGenome:
|
||||
system_prompt: str
|
||||
attack_vocabulary: list[str] # tipi di attacchi noti
|
||||
paranoia_level: float # quanto aggressivo
|
||||
historical_failure_db: str # quali falsi positivi ricordare
|
||||
temperature: float # 0.5 - 0.9 tipico
|
||||
model_tier: ModelTier
|
||||
```
|
||||
|
||||
#### 2.2.4 Protocol Genome
|
||||
|
||||
**Ruolo**: meta-popolazione. Non è un agente, è la specifica del linguaggio che gli agenti usano.
|
||||
|
||||
**Genoma**:
|
||||
```python
|
||||
@dataclass
|
||||
class ProtocolGenome:
|
||||
syntax: Grammar # FISSA: S-expr like
|
||||
vocabulary: dict[str, VerbDefinition] # EVOLVE
|
||||
idioms: list[Macro] # EMERGONO
|
||||
registers: dict[Layer, VocabSubset] # EMERGONO
|
||||
type_system: TypeSchema # EVOLVE lentamente
|
||||
confidence_grammar: ConfidenceSchema # come esprimere uncertainty
|
||||
```
|
||||
|
||||
**Sintassi base** (immutabile per garantire parsabilità):
|
||||
```
|
||||
expression := (verb arg*)
|
||||
arg := atom | expression | reference
|
||||
reference := #identifier
|
||||
atom := number | string | symbol | typed_value
|
||||
typed_value := <type:value:metadata>
|
||||
```
|
||||
|
||||
**Vocabolario iniziale** (15-20 verbi base, poi evolve):
|
||||
```
|
||||
PROPOSE_HYPOTHESIS, ASSERT_EVIDENCE, CHALLENGE,
|
||||
REFINE, CITE, COMMIT, REJECT, QUERY,
|
||||
EXPRESS_UNCERTAINTY, REGIME_CONDITION, FEATURE_DRIFT,
|
||||
SAMPLE_REQUEST, REPLAY_REQUEST, BIND_VARIABLE, REPORT_RESULT
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Meccanismi Evolutivi
|
||||
|
||||
### 3.1 Operatori genetici per agenti
|
||||
|
||||
**Mutazione del system prompt**:
|
||||
- Strategia A (LLM-as-mutator): un modello tier-medio riscrive il prompt con istruzione "modifica un aspetto cognitivo mantenendo intent". Output sempre coerente.
|
||||
- Strategia B (structured): il prompt è scomposto in sezioni (role, context, instructions, constraints, examples, output_format), mutazione opera dentro una sezione.
|
||||
- **Scelta**: ibrido B+C, per garantire validità sintattica e ricchezza semantica.
|
||||
|
||||
**Crossover di feature set**: classico, 50/50 da due parent.
|
||||
|
||||
**Mutazione di iperparametri**: gaussiana su temperature/top_p, discreta su model_tier (raramente).
|
||||
|
||||
**Mutazione di model_tier**: rara (5%), perché cambia significativamente costi e capability. Vedi sez. 4.
|
||||
|
||||
### 3.2 Operatori genetici per protocollo
|
||||
|
||||
**Mutazione di vocabolario**:
|
||||
- Add verb: il sistema propone nuovo verbo basato su pattern di uso (frasi ricorrenti che meriterebbero verbo dedicato)
|
||||
- Remove verb: verbi sotto soglia di uso vengono deprecati
|
||||
- Modify schema: aggiungi/rimuovi argomenti di un verbo esistente
|
||||
- Rename: alias semantici emergono
|
||||
|
||||
**Idiom emergence** (la parte più interessante):
|
||||
- Il sistema rileva sequenze di verbi che appaiono frequentemente insieme con alta correlazione a fitness team
|
||||
- Queste sequenze diventano "idioms" — macro che possono essere espanse o usate come unità
|
||||
- Esempio: `[CHALLENGE + REFINE + RE-CHALLENGE]` ricorrente → idiom `STRESS_TEST(target=#X, depth=3)`
|
||||
|
||||
**Register specialization**:
|
||||
- Tracking di quali verbi vengono usati prevalentemente da quale layer
|
||||
- Se un verbo è usato >80% da un layer specifico, viene marcato come "register-specific"
|
||||
- Riduce overhead cognitivo: un agente non deve imparare verbi che non userà
|
||||
|
||||
### 3.3 Selezione e riproduzione
|
||||
|
||||
**Selection method**: tournament selection (k=5), più robusto di roulette wheel su fitness rumorose.
|
||||
|
||||
**Speciation** (NEAT-style):
|
||||
- Cluster agenti per similarità semantica del prompt (embedding + cosine distance)
|
||||
- Fitness sharing dentro la specie
|
||||
- Effetto: nicchie cognitive diverse coesistono (mean-reversion, momentum, vol-arb, ecc.)
|
||||
|
||||
**Reproduction mix**:
|
||||
- 60% crossover tra parent della stessa specie
|
||||
- 25% mutazione singolo parent
|
||||
- 10% inter-species crossover (rare, può produrre breakthrough)
|
||||
- 5% immigrazione (agenti random nuovi, anti-stagnazione)
|
||||
|
||||
**Elitismo**: top 5% per popolazione sopravvive non modificato.
|
||||
|
||||
### 3.4 Co-evolution dynamics
|
||||
|
||||
Le quattro popolazioni evolvono in **frequenze diverse**:
|
||||
|
||||
| Popolazione | Frequenza evoluzione | Motivo |
|
||||
|---------------|----------------------|-------------------------------------------|
|
||||
| Hypothesis | Ogni generazione | Esplorazione massiva |
|
||||
| Falsification | Ogni generazione | Adattamento ai nuovi tipi di ipotesi |
|
||||
| Adversarial | Ogni 2 generazioni | Più stabile, paranoia richiede consistenza |
|
||||
| Protocol | Ogni 5 generazioni | Cambiamenti lenti, evita instabilità |
|
||||
|
||||
**Razionale**: il protocollo cambia lentamente perché è il "terreno comune". Cambi rapidi del protocollo destabilizzano tutte le popolazioni che ci comunicano. È analogo a come la grammatica evolve più lentamente del lessico nelle lingue umane.
|
||||
|
||||
---
|
||||
|
||||
## 4. Tier Multi-Model: l'innovazione economica
|
||||
|
||||
### 4.1 Il problema dei costi
|
||||
|
||||
Con solo Claude Sonnet/Opus, una run completa di 500 generazioni costa $30-50K. Fattibile ma limitante: non puoi sperimentare liberamente, ogni run è un evento.
|
||||
|
||||
### 4.2 La soluzione: stratificazione per ruolo cognitivo
|
||||
|
||||
Non tutti gli agenti hanno bisogno di un modello frontier. Diversi ruoli hanno diversi requisiti cognitivi.
|
||||
|
||||
**Tier definiti**:
|
||||
|
||||
| Tier | Modello esempio | Provider | Costo (in/out per Mtok) | Use case |
|
||||
|--------|-----------------------------------|-------------|-------------------------|-----------------------------------------|
|
||||
| Tier-S | Claude Opus 4.7 | Anthropic | $15 / $75 | Hypothesis creativi, ricerca breakthrough|
|
||||
| Tier-A | Claude Sonnet 4.6 | Anthropic | $3 / $15 | Adversarial sofisticati, reasoning denso |
|
||||
| Tier-B | Qwen3-Max / DeepSeek-V3 | OpenRouter | $0.5-1 / $1-3 | Falsification statistica, executors |
|
||||
| Tier-C | Qwen3-30B / Llama 3.3 70B | OpenRouter | $0.1-0.3 / $0.3-0.6 | Massa Hypothesis esplorativi, mutators |
|
||||
| Tier-D | Modelli small open-source | OpenRouter | $0.05-0.1 | Validation parsing, formatting checks |
|
||||
|
||||
**Nota sui prezzi**: i numeri sopra sono indicativi al maggio 2026, ma OpenRouter aggiorna continuamente — verificare prima di run reali. La gerarchia di costi è stabile, le cifre esatte fluttuano.
|
||||
|
||||
### 4.3 Allocazione cognitiva per layer
|
||||
|
||||
| Layer | Tier-S | Tier-A | Tier-B | Tier-C | Tier-D |
|
||||
|---------------|--------|--------|--------|--------|--------|
|
||||
| Hypothesis | 5% | 15% | 30% | 50% | 0% |
|
||||
| Falsification | 0% | 10% | 60% | 30% | 0% |
|
||||
| Adversarial | 10% | 40% | 40% | 10% | 0% |
|
||||
| Protocol mut. | 0% | 30% | 50% | 20% | 0% |
|
||||
| Validators | 0% | 0% | 0% | 0% | 100% |
|
||||
|
||||
**Razionale per layer**:
|
||||
|
||||
- **Hypothesis** beneficia di diversità cognitiva. Pochi Tier-S per breakthrough rari, massa Tier-C per esplorazione ampia. Modelli diversi hanno bias cognitivi diversi (Qwen vs Claude vs Llama producono ipotesi qualitativamente diverse — questo è feature, non bug).
|
||||
- **Falsification** è principalmente esecuzione di test statistici e interpretazione di numeri. Tier-B/C bastano. Errori qui sono più costosi però (falso negativo = strategia cattiva passa) → nessun Tier-D.
|
||||
- **Adversarial** richiede reasoning sofisticato (riconoscere lookahead bias subtle, regime dependency). Più peso su Tier-A/B.
|
||||
- **Validators**: parser, formattatori, basic checks → Tier-D è perfetto, costo trascurabile.
|
||||
|
||||
### 4.4 Cross-model diversity come risorsa
|
||||
|
||||
Punto **non ovvio ma importante**: avere modelli da provider diversi nelle popolazioni produce *diversità cognitiva intrinseca*. Claude e Qwen e Llama sono stati addestrati su corpus diversi, con RLHF diverse, con bias diversi. Per ricerca esplorativa questo è oro.
|
||||
|
||||
Esempio concreto: su ipotesi crypto, Qwen tende a privilegiare considerazioni di market microstructure che vengono dalla sua forte esposizione a contenuti tech cinesi. Claude tende a essere più cauto sulle estrapolazioni statistiche. Llama produce associazioni più libere. Mescolarli porta a portafoglio di ipotesi più ricco di quanto produrrebbe una sola famiglia di modelli, anche se tutti i modelli fossero al top tier.
|
||||
|
||||
Questo è un argomento *non economico* per il multi-tier. Vale la pena anche se Anthropic abbassasse drasticamente i prezzi.
|
||||
|
||||
### 4.5 Economia rivista
|
||||
|
||||
Con tier multi-model:
|
||||
|
||||
- Generazione singola con popolazione K=300 (vs K=180 originale): ~$15-25 (vs $50-80)
|
||||
- 500 generazioni: $7-12K (vs $25-40K)
|
||||
- Risparmio: ~3x su scala operativa
|
||||
- **Oppure** a parità di budget: K=900, 1500 generazioni → regime evolutivo qualitativamente diverso
|
||||
|
||||
A regime evolutivo "alto" (K grandi, generazioni numerose) si manifestano fenomeni che a regime basso non appaiono: speciation stabile, idiom emergence frequente, breakthrough rari ma cumulativi.
|
||||
|
||||
### 4.6 Considerazioni operative su OpenRouter
|
||||
|
||||
**Vantaggi**:
|
||||
- Singolo endpoint per N modelli, switching facile
|
||||
- Fallback automatico se un provider è giù
|
||||
- Pricing trasparente, no enterprise contracts richiesti
|
||||
- Rate limits aggregati ragionevoli
|
||||
|
||||
**Svantaggi**:
|
||||
- Latenza variabile (modelli ospitati da provider diversi)
|
||||
- Quality fluctuations (alcuni provider hanno hosting subottimo)
|
||||
- Mancanza di prompt caching per modelli non-Anthropic (Claude rimane vantaggio per long-context)
|
||||
- Privacy policy variabili per modello (verificare per dati sensibili — non un problema per dati di mercato pubblici)
|
||||
|
||||
**Configurazione consigliata**:
|
||||
```python
|
||||
class ModelRouter:
|
||||
def call(self, agent_genome, messages):
|
||||
tier = agent_genome.model_tier
|
||||
if tier == ModelTier.S:
|
||||
return anthropic_client.call("claude-opus-4-7", messages)
|
||||
elif tier == ModelTier.A:
|
||||
return anthropic_client.call("claude-sonnet-4-6", messages)
|
||||
elif tier == ModelTier.B:
|
||||
return openrouter.call("qwen/qwen3-max", messages)
|
||||
elif tier == ModelTier.C:
|
||||
return openrouter.call("qwen/qwen3-30b-instruct", messages)
|
||||
elif tier == ModelTier.D:
|
||||
return openrouter.call("meta-llama/llama-3.3-8b", messages)
|
||||
```
|
||||
|
||||
**Fallback policy**: se Tier-C fallisce 3 volte di fila (timeout, malformed output), promuovi temporaneamente a Tier-B per quell'agente. Loggato per evitare gaming evolutivo della failure rate.
|
||||
|
||||
---
|
||||
|
||||
## 5. Fitness Function (la parte critica)
|
||||
|
||||
### 5.1 Tre livelli di fitness
|
||||
|
||||
**Per agent** (selezione intra-popolazione):
|
||||
```
|
||||
agent_fitness = quality_of_contributions
|
||||
- communication_overhead
|
||||
- cost_penalty (proporzionale al tier usato)
|
||||
- genealogy_redundancy_penalty
|
||||
```
|
||||
|
||||
Il `cost_penalty` è cruciale: senza di esso, l'evoluzione tende a promuovere Tier-S su tutto. Con esso, gli agenti devono "guadagnarsi" il diritto a tier costosi mostrando contribuzioni proporzionali.
|
||||
|
||||
**Per team** (combinazioni h+f+a che funzionano insieme):
|
||||
```
|
||||
team_fitness = OOS_alpha_discovered
|
||||
+ bug_caught_rate
|
||||
- time_to_consensus
|
||||
- false_positive_rate
|
||||
- total_cost_per_episode
|
||||
```
|
||||
|
||||
**Per protocol** (vocabolario/idiomi che meritano di rimanere):
|
||||
```
|
||||
protocol_fitness = avg_team_fitness_using_this_protocol
|
||||
/ avg_message_length
|
||||
- λ * human_unreadability_score
|
||||
+ idiom_compression_ratio
|
||||
- vocabulary_bloat_penalty
|
||||
```
|
||||
|
||||
### 5.2 Human-in-the-loop calibration
|
||||
|
||||
**Non opzionale**. Ogni 20 generazioni:
|
||||
- Sample top 10 ipotesi → judgment umano (insight reale vs gameificazione)
|
||||
- Sample top 10 idiomi protocol → judgment umano (concetto sensato vs gibberish funzionale)
|
||||
- Sample top 5 attacchi adversarial → judgment umano (argument valido vs sofisma)
|
||||
|
||||
Il giudizio umano retroattivamente penalizza pattern fraudolenti. Questo è il **vincolo che impedisce divergenza creativa-ma-inutile**.
|
||||
|
||||
### 5.3 Anti-gaming measures
|
||||
|
||||
**Trappole noti e mitigazioni**:
|
||||
|
||||
| Trappola | Manifestazione | Mitigazione |
|
||||
|---------------------------|-----------------------------------------------|------------------------------------------------|
|
||||
| Communication degeneration| Messaggi minimali tipo "42" | Penalty su brevità eccessiva + parser test |
|
||||
| Layer collapse | Popolazioni convergono a strategie omogenee | Speciation forte, novelty bonus, task rotation|
|
||||
| Protocol overfitting | Idiomi specifici al task corrente | Rotation di task durante evoluzione |
|
||||
| Adversarial collusion | Layer si rinforzano in modo perverso | Fitness globale del team su PnL OOS reale |
|
||||
| Tier inflation | Tutti gli agenti migrano a Tier-S | Cost penalty proporzionale nel agent_fitness |
|
||||
| Backtest exploit | Sfruttare bug del backtest engine | Audit periodici dei top performer + adversarial test sintetici |
|
||||
|
||||
---
|
||||
|
||||
## 6. Stack Tecnico
|
||||
|
||||
### 6.1 Linguaggi e framework
|
||||
|
||||
- **Backbone Python** per orchestrazione, GA, agent management (DEAP framework)
|
||||
- **Rust** per backtest engine (performance critica, deterministica)
|
||||
- **PostgreSQL + pgvector** per genomi, embedding, audit log
|
||||
- **Redis** per message bus tra agenti durante episodio
|
||||
- **Docker Compose** per deployment locale
|
||||
- **Anthropic SDK** + **OpenRouter API** via httpx
|
||||
- **Ray** o **asyncio + aiohttp** per parallelizzazione agenti
|
||||
|
||||
### 6.2 Storage schema (essenziale)
|
||||
|
||||
```sql
|
||||
-- Genomi con genealogia completa
|
||||
CREATE TABLE agent_genomes (
|
||||
id UUID PRIMARY KEY,
|
||||
layer TEXT NOT NULL,
|
||||
generation INT NOT NULL,
|
||||
species_id UUID,
|
||||
parent_ids UUID[],
|
||||
genome_data JSONB,
|
||||
embedding VECTOR(1536),
|
||||
fitness FLOAT,
|
||||
created_at TIMESTAMPTZ
|
||||
);
|
||||
|
||||
CREATE TABLE protocol_genomes (
|
||||
id UUID PRIMARY KEY,
|
||||
generation INT,
|
||||
vocabulary JSONB,
|
||||
idioms JSONB,
|
||||
fitness FLOAT
|
||||
);
|
||||
|
||||
-- Audit log dei messaggi (cresce velocemente, considerare retention)
|
||||
CREATE TABLE message_log (
|
||||
id UUID PRIMARY KEY,
|
||||
episode_id UUID,
|
||||
timestamp TIMESTAMPTZ,
|
||||
source_agent_id UUID,
|
||||
protocol_id UUID,
|
||||
raw_message TEXT,
|
||||
parsed_ast JSONB,
|
||||
italian_render TEXT, -- per audit umano
|
||||
parse_valid BOOLEAN
|
||||
);
|
||||
|
||||
-- Episodi (run di team)
|
||||
CREATE TABLE episodes (
|
||||
id UUID PRIMARY KEY,
|
||||
generation INT,
|
||||
team_composition JSONB, -- {h: agent_id, f: agent_id, a: agent_id}
|
||||
protocol_id UUID,
|
||||
task_id UUID,
|
||||
fitness FLOAT,
|
||||
started_at TIMESTAMPTZ,
|
||||
completed_at TIMESTAMPTZ
|
||||
);
|
||||
|
||||
-- Risultati discovery (per review umana)
|
||||
CREATE TABLE discoveries (
|
||||
id UUID PRIMARY KEY,
|
||||
episode_id UUID,
|
||||
discovery_type TEXT, -- "alpha", "idiom", "attack_pattern"
|
||||
content JSONB,
|
||||
human_review_status TEXT, -- pending/valid/gaming/spurious
|
||||
human_notes TEXT
|
||||
);
|
||||
```
|
||||
|
||||
### 6.3 Esempio di message bus auditato
|
||||
|
||||
```python
|
||||
class AuditedMessageBus:
|
||||
async def send(self, source_agent: AgentGenome,
|
||||
target_layer: Layer,
|
||||
message: str,
|
||||
protocol: ProtocolGenome) -> bool:
|
||||
# 1. Parse with current protocol
|
||||
try:
|
||||
ast = protocol.parse(message)
|
||||
except ParseError as e:
|
||||
self.log_invalid(source_agent, message, e)
|
||||
return False # silent drop
|
||||
|
||||
# 2. Type check
|
||||
if not protocol.type_check(ast):
|
||||
self.log_invalid(source_agent, message, "type_error")
|
||||
return False
|
||||
|
||||
# 3. Italian rendering for audit
|
||||
italian = protocol.render_italian(ast)
|
||||
|
||||
# 4. Log
|
||||
await self.log_message(
|
||||
source=source_agent.id,
|
||||
target=target_layer,
|
||||
raw=message,
|
||||
ast=ast,
|
||||
italian=italian
|
||||
)
|
||||
|
||||
# 5. Deliver
|
||||
await self.deliver(target_layer, ast)
|
||||
return True
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Roadmap di Implementazione
|
||||
|
||||
### 7.1 Fasi
|
||||
|
||||
**Fase 0 — Validazione concettuale (1 mese)**
|
||||
- Paper review approfondito (PromptBreeder, NEAT, MAP-Elites, emergent communication literature)
|
||||
- Proof-of-concept minimo: 3 agenti hand-crafted (uno per layer), protocollo S-expr fisso, 10 ipotesi su dataset limitato
|
||||
- Decisione go/no-go basata su: il sistema produce *qualcosa* di sensato? Vale espandere?
|
||||
|
||||
**Fase 1 — Infrastruttura (2 mesi)**
|
||||
- Message bus auditato (Python + Redis)
|
||||
- Parser e validator del protocollo (Python, con grammar formale)
|
||||
- Backtest engine deterministico (Rust + PyO3 bindings)
|
||||
- Storage schema (PostgreSQL + pgvector)
|
||||
- Multi-model router (Anthropic + OpenRouter)
|
||||
- Logging, monitoring, dashboard base
|
||||
|
||||
**Fase 2 — GA single-population (1 mese)**
|
||||
- DEAP setup
|
||||
- Evoluzione di solo Hypothesis layer (Falsification e Adversarial hand-crafted)
|
||||
- Protocollo fisso
|
||||
- Verifica anti-gaming sulla fitness function
|
||||
- Calibrazione operatori genetici
|
||||
|
||||
**Fase 3 — Multi-population co-evolution (2 mesi)**
|
||||
- GA su tutte e tre le popolazioni di agenti
|
||||
- Speciation, novelty search
|
||||
- Protocol ancora fisso
|
||||
- Task rotation per evitare overfitting
|
||||
|
||||
**Fase 4 — Protocol evolution (2 mesi)**
|
||||
- Aggiunta della quarta popolazione (protocollo)
|
||||
- Idiom emergence detection
|
||||
- Register specialization
|
||||
- Sistema completo end-to-end
|
||||
|
||||
**Fase 5 — Tuning e scaling (3-4 mesi)**
|
||||
- Esperimenti su task diversi (trading, offerte commerciali, code review)
|
||||
- Ablation studies (tier multi-model davvero aiuta? Quanto?)
|
||||
- Long-run stability analysis
|
||||
- Documentazione e potenziale paper
|
||||
|
||||
**Totale realistico**: 11-12 mesi a impegno significativo (3-4 giorni/settimana). 18+ mesi a impegno part-time leggero.
|
||||
|
||||
### 7.2 Tre opzioni decisionali
|
||||
|
||||
**Opzione A — Big bet**: progetto principale per 12-18 mesi. Risultato: sistema completo, possibile paper, applicabile a multipli domini. Rischio: opportunity cost alto rispetto a Tielogic e altri progetti.
|
||||
|
||||
**Opzione B — Smart spike**: solo Fasi 0-2 in 3-4 mesi. Output: infrastruttura solida + GA single-population funzionante su Hypothesis. Da lì si decide se espandere. Rischio basso, valore concreto.
|
||||
|
||||
**Opzione C — Research dive**: solo Fase 0 in 1 mese. Decisione informata se vale la pena tutto. Rischio minimo, output principalmente conoscenza.
|
||||
|
||||
---
|
||||
|
||||
## 8. Stima Costi (con tier multi-model)
|
||||
|
||||
### 8.1 Costi LLM per fase
|
||||
|
||||
| Fase | Generazioni | Pop totale | Costo stimato |
|
||||
|------|-------------|------------|---------------|
|
||||
| Fase 0 (PoC) | 0 (no GA) | 3 hand-crafted | $50-100 |
|
||||
| Fase 2 | 50 | 100 | $400-700 |
|
||||
| Fase 3 | 200 | 200 | $3-5K |
|
||||
| Fase 4-5 | 500-1000 | 300-500 | $10-18K |
|
||||
|
||||
**Totale fasi 1-5**: **$15-25K** in costi LLM (vs $30-50K senza tier multi-model).
|
||||
|
||||
### 8.2 Altri costi
|
||||
|
||||
- **Compute (server backtest, storage)**: $200-500/mese durante run attivi
|
||||
- **Storage (TB di logs)**: $50-100/mese a regime
|
||||
- **Tooling/infra setup**: ~$500 una tantum
|
||||
|
||||
### 8.3 Costi nascosti
|
||||
|
||||
- **Tempo umano**: la voce più importante. Calibrare fitness, fare review, debuggare gaming = molte ore/settimana durante run attivi
|
||||
- **Iterazioni**: il primo run completo non funzionerà. Pianificare 2-3 run completi come parte del budget
|
||||
- **Modelli che cambiano**: durante il progetto i prezzi e le capacità dei modelli evolveranno. Il tier multi-model può solo migliorare nel tempo
|
||||
|
||||
---
|
||||
|
||||
## 9. Domini di Applicazione
|
||||
|
||||
### 9.1 Trading derivati crypto (primario)
|
||||
|
||||
- Task: identificare anomalie su Deribit options + Hyperliquid perps
|
||||
- Fitness team: PnL OOS su walk-forward, Sharpe deflated, drawdown control
|
||||
- Vantaggio: ground truth oggettivo (PnL), dataset abbondante, regime variations naturali
|
||||
- Rischio: overfitting al regime di mercato durante training
|
||||
|
||||
### 9.2 Offerte commerciali Tielogic (secondario)
|
||||
|
||||
- Task: generare offerte tipo OFF-2026-XXX a partire da requisiti cliente
|
||||
- Fitness team: qualità tecnica + commerciale + adesione template + tasso di conversione (firma cliente)
|
||||
- Vantaggio: dataset di offerte passate (20-30) come ground truth implicito
|
||||
- ROI immediato: ridurre tempo di stesura primi-draft significativamente
|
||||
- Vincolo: dataset piccolo, attenzione a overfitting
|
||||
|
||||
### 9.3 Code review e documentazione (terziario)
|
||||
|
||||
- Task: generare review utili su PR, generare documentazione Swagger di qualità
|
||||
- Fitness: bug catch rate su PR storiche, copertura/qualità docs
|
||||
- Vantaggio: integrabile nel workflow Claude Code esistente
|
||||
- Estensibilità: dopo trading, è il dominio più scalabile
|
||||
|
||||
### 9.4 Generalizzabilità del protocollo
|
||||
|
||||
Domanda di ricerca aperta: il protocollo evoluto su trading **trasferisce** ad altri domini, o ogni dominio sviluppa il suo dialetto?
|
||||
|
||||
Ipotesi: la struttura generale (PROPOSE/CHALLENGE/REFINE/COMMIT) trasferisce, il vocabolario specifico no. Un'analisi sistematica di questo è materiale da paper.
|
||||
|
||||
---
|
||||
|
||||
## 10. Risk Register
|
||||
|
||||
| Rischio | Probabilità | Impatto | Mitigazione |
|
||||
|-----------------------------|-------------|---------|----------------------------------------------|
|
||||
| Fitness gameabile | Alta | Critico | Multi-livello fitness, human-in-the-loop, audit |
|
||||
| Costi over-budget | Media | Alto | Tier multi-model, monitoring real-time, kill switch |
|
||||
| Convergenza prematura | Media | Alto | Speciation, novelty search, immigrazione |
|
||||
| Communication degeneration | Alta | Alto | Penalty leggibilità, parser strict, audit umano |
|
||||
| Time over-budget | Alta | Medio | Opzione B/C come fallback |
|
||||
| Modelli base cambiano | Certa | Medio | Re-evolution periodica, model_tier come gene |
|
||||
| Backtest engine bug exploit | Media | Critico | Adversarial test del backtest, code audit |
|
||||
| Burnout su side project | Alta | Critico | Roadmap realistica, milestone settimanali |
|
||||
|
||||
---
|
||||
|
||||
## 11. Open Questions
|
||||
|
||||
1. **Quanto è veramente diverso il sistema dal lavoro accademico esistente?** Necessario lit review serio prima di Fase 1.
|
||||
2. **Il protocollo evoluto generalizza tra domini?** Domanda empirica, pubblicabile.
|
||||
3. **Tier multi-model produce diversità cognitiva utile o solo riduce costi?** Ablation study cruciale.
|
||||
4. **Co-evoluzione 4-popolazioni è stabile o tende a oscillare?** Non scontato, esperienza empirica necessaria.
|
||||
5. **Quanto del successo dipende dal task specifico (trading) vs essere generale?** Solo applicazione multi-dominio risponde.
|
||||
6. **Quanto è il vero MVP minimo per validare il concetto?** Probabilmente Fase 0 + minima Fase 2 con singola popolazione.
|
||||
|
||||
---
|
||||
|
||||
## 12. Decisione Richiesta
|
||||
|
||||
A questo punto del design, le decisioni concrete da prendere prima di partire:
|
||||
|
||||
1. **Opzione A, B, o C?** — determina l'investimento di tempo
|
||||
2. **Dominio iniziale: trading o offerte commerciali?** — trading ha dataset migliore, offerte ROI più rapido
|
||||
3. **Hardware locale vs cloud?** — i backtest pesanti richiedono compute, decidere infrastructure
|
||||
4. **Budget LLM iniziale committed?** — anche solo Fase 0 richiede $50-100 spendibile senza ansia
|
||||
5. **Cadenza di review umana sostenibile?** — ore/settimana realisticamente disponibili
|
||||
|
||||
---
|
||||
|
||||
## Appendice A — Bibliografia di riferimento
|
||||
|
||||
**Da leggere prima di Fase 1**:
|
||||
- PromptBreeder (DeepMind 2023): meta-evolution di prompt
|
||||
- NEAT (Stanley & Miikkulainen 2002): speciation in neural evolution
|
||||
- MAP-Elites (Mouret & Clune 2015): quality-diversity
|
||||
- Novelty Search (Lehman & Stanley 2011): esplorazione vs sfruttamento
|
||||
- DSPy (Khattab et al. 2023): ottimizzazione modulare di prompt
|
||||
- TextGrad (Stanford 2024): backpropagation testuale
|
||||
- Emergent Communication in Cooperative Multi-Agent RL (Foerster et al., Lazaridou et al. 2016-2020)
|
||||
- Deflated Sharpe Ratio (Bailey & López de Prado 2014): per fitness trading
|
||||
- Multiple testing in finance literature (López de Prado various)
|
||||
|
||||
**Da consultare durante**:
|
||||
- Anthropic prompt engineering documentation (per pattern caching)
|
||||
- OpenRouter API docs (per multi-model routing)
|
||||
- DEAP documentation (framework GA Python)
|
||||
- Ray documentation (parallelizzazione)
|
||||
|
||||
---
|
||||
|
||||
*Documento da aggiornare iterativamente. Questa è v0.1, scritta prima di qualunque implementazione.*
|
||||
Reference in New Issue
Block a user