# 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 := ``` **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.*