Files
Multi_Swarm_Coevolutive/00_documento_zero.md
T
Adriano eb6b52ff04 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>
2026-05-09 18:19:55 +02:00

17 KiB

Documento Zero — Da Renaissance a Swarm Co-Evolutivo

Autore: Adriano Dal Pastro Data: Maggio 2026 Status: Sintesi concettuale di partenza Versione: 0.1 Documenti correlati:

  • coevolutive_swarm_system.md (sistema completo)
  • poc_trading_swarm.md (proof of concept trading)

1. Scopo di questo documento

Questo è il documento zero della serie. Non descrive un'implementazione, descrive il ragionamento di partenza che ha portato all'architettura proposta negli altri due documenti.

Lo scopo è fissare il framework concettuale, così che quando riprendiamo il lavoro tra giorni o settimane il contesto non vada perso. Risponde alla domanda: perché stiamo facendo questo, e perché in questo modo specifico?


2. Il punto di partenza: Renaissance Technologies

2.1 Cosa è Renaissance

Hedge fund fondato 1978 da Jim Simons (matematico puro, ex code-breaker NSA, premio Oswald Veblen 1976 in geometria). Sede Long Island. Staff composto principalmente da PhD in fisica, matematica, statistica, signal processing — zero economisti tradizionali. Simons è morto a maggio 2024.

2.2 La filosofia opposta a LTCM

LTCM Renaissance
Parte da teoria (Black-Scholes) Parte dai dati
Cerca conferme Cerca anomalie
Modello statico Modello che si aggiorna ogni giorno
Crolla quando realtà ≠ teoria Cambia quando realtà cambia

2.3 Come opera

  • Non cerca pattern ovvi (spariscono subito quando tutti li vedono)
  • Cerca decine di anomalie sottili, ognuna con edge minuscolo ma statisticamente significativo. Sommate → edge stabile e potente.
  • Sistema 100% automatico. Nessun umano decide trade. Simons: "umano = variabile non controllabile".
  • Ingerisce terabyte di dati al giorno. Scarta pattern morti, incorpora nuovi.
  • Pattern usati negli '80 oggi non funzionano più — quando un pattern diventa noto, sparisce.

2.4 Numeri (Medallion Fund, fondo interno)

  • ~66% lordo annuo per 30+ anni consecutivi
  • ~39% netto dopo le fee mostruose (5% management + 44% performance)
  • Mai un anno in perdita. Compreso 1998 mentre LTCM bruciava 5 miliardi
  • $100 nel 1988 → $8.4 miliardi oggi (vs $2400 in S&P)
  • Confronto con Buffett: Buffett 20%/anno = "il migliore al mondo". Simons 3x più di Buffett, per 2x più anni

3. La domanda critica: cosa è replicabile?

3.1 Cosa NON è replicabile

Il 66% lordo del Medallion non viene da "matematici geniali". Viene da fattori strutturali che retail non può replicare:

  • Latency e infrastruttura: co-location, feed di mercato grezzi, esecuzione sub-millisecondo. Il 70% dell'edge sui pattern intraday è banalmente velocità.
  • Capacity cap: Medallion è chiuso a circa $10B perché l'edge non scala. Le anomalie sottili che sfruttano si saturano. Le strategie vere di Renaissance non solo non sono pubbliche — sono inutili a chi le rendesse pubbliche.
  • Dataset proprietari: decenni di tick data puliti, dati alternativi, e soprattutto un team di 100+ ricercatori che fa SOLO data cleaning. Il loro vero IP è la qualità del dato, non il modello.
  • Risk management con leva istituzionale: prime broker relationship, dimensioni di hedging fuori portata retail.

Replicare Renaissance retail è come voler replicare TSMC con una stampante 3D. Non è una questione di intelligenza, è di scala.

3.2 Cosa È replicabile (tradotto in principi operativi)

I principi filosofici di Renaissance, applicati al contesto LLM-agent + retail:

  1. "Cerca anomalie, non conferme" → il prompt non chiede all'agente di valutare se "le condizioni sono buone per X", chiede di identificare regimi in cui la struttura dei dati devia da pattern storici, e adattare la strategia.

  2. "Edge piccoli sommati" → su crypto retail un singolo edge da 50bp/trade è realistico, 500bp no. L'architettura deve permettere molte posizioni indipendenti piccole. Renaissance fa migliaia di trade/giorno proprio per questo.

  3. "Modello che si aggiorna" → per un sistema LLM questo è sottile: il modello non si aggiorna tra una chiamata e l'altra. L'aggiornamento deve essere fuori dal modello, in un layer di state/memory.

  4. "Umano = variabile non controllabile" → l'analogo è che l'LLM stesso è una variabile non controllabile (temperatura, bias di addestramento). L'LLM deve generare ipotesi, ma le decisioni execute/no-execute devono essere filtrate da regole deterministiche.

3.3 Il vero takeaway: survivorship bias

La cosa più importante che Simons ripeteva: per ogni Renaissance esistono centinaia di fondi quant chiusi silenziosamente. La differenza spesso non è il modello, è la disciplina di spegnere strategie quando l'edge svanisce. Avere metriche oggettive di "questa strategia è morta" che fanno killare il branch automaticamente, senza decisioni emotive.


4. Lo shift mentale: dagli umani agli agenti illimitati

4.1 La differenza categoriale

Renaissance ha 300 ricercatori. Con LLM agents si possono istanziare 3000 agenti in parallelo a costo marginale quasi zero. Questo non è "più della stessa cosa", è una categoria diversa di problema.

Renaissance deve essere selettiva su quali ipotesi testare perché ogni PhD è caro e lento. Con LLM agents no. Si può permettere di testare ipotesi stupide, perché 99.9% di stupide + 0.1% di geniali > 100% di "ragionevoli".

Cambia tutto il framework. Le strategie quant tradizionali partono da un'ipotesi economica/strutturale e cercano evidenza. Si può fare il contrario: brute force di ipotesi generate da LLM, filtrate da realtà.

4.2 Il salto verso l'evoluzione

Se hai migliaia di agenti che generano ipotesi, il problema diventa: come scoprire quali stili cognitivi producono ipotesi migliori? Risposta: lascia che siano evolutivamente selezionati. Non scrivi tu il prompt ottimale, lo scopri attraverso pressione selettiva.

Questo è il salto concettuale: passare da prompt engineering (artigianato umano) a prompt evolution (ricerca automatica nello spazio dei prompt).

4.3 Il salto ulteriore: linguaggio emergente

Se gli agenti devono comunicare tra loro, il linguaggio naturale umano è probabilmente subottimale. È stato ottimizzato per vincoli umani (vocal tract, memoria di lavoro limitata, ambiguità sociale utile) che non si applicano agli LLM.

Si può co-evolvere il protocollo di comunicazione insieme agli agenti. Il risultato è un sistema dove agenti e linguaggio si adattano insieme — analogo all'evoluzione del linguaggio scientifico umano (notazione vettoriale + pensiero vettoriale evolvono insieme), ma compresso in giorni invece che millenni.


5. L'architettura emergente: tre layer cognitivi

Dalla riflessione su Renaissance + LLM swarm + evoluzione, emerge un'architettura specifica con tre ruoli funzionali distinti.

5.1 Hypothesis Layer

Ruolo: generazione creativa di ipotesi su anomalie. Alta temperatura, stili cognitivi diversi, ricerca esplorativa.

Diversità cognitiva intenzionale: agenti con prompt che li fanno "pensare come un fisico", "come un biologo evolutivo", "come uno storico", "come un meteorologo". Stili diversi → ipotesi diverse.

5.2 Falsification Layer

Ruolo: testare rigorosamente. Bassa temperatura, focus su statistica deterministica.

Funzione critica: questo NON è LLM puro. È codice tradizionale (backtesting, walk-forward, multiple testing correction) orchestrato da LLM. L'LLM non deve mai valutare se una strategia funziona, deve eseguire test rigorosi e leggere risultati numerici.

5.3 Adversarial Layer

Ruolo: red team epistemico. Cerca data snooping, lookahead bias, regime fragility, crowding. Paranoia strutturale.

Per ogni strategia che sopravvive, l'agente fa l'avvocato del diavolo: "perché questa strategia deve fallire?". Solo strategie che sopravvivono al red team passano alla fase successiva.

5.4 Perché tre e non uno

I tre ruoli hanno requisiti cognitivi opposti:

  • Hypothesis vuole creatività, alto temperature
  • Falsification vuole rigore, low temperature
  • Adversarial vuole paranoia, medium temperature

Un singolo agente non può fare tutti e tre bene. Specializzarli e farli collaborare produce risultati qualitativamente migliori, e abilita evoluzione separata di ogni nicchia.


6. I tre filoni che si sono sviluppati

Dal framework concettuale base si sono sviluppati tre filoni, ognuno documentato (o da documentare) separatamente.

6.1 Filone A — Sistema completo

Co-evoluzione di quattro popolazioni: tre layer cognitivi + il protocollo di comunicazione.

Caratteristiche:

  • Co-evolution multi-species
  • Speciation (NEAT-style)
  • Idiom emergence nel protocollo
  • Register specialization per layer
  • Tier multi-model (Claude + Qwen + Llama via OpenRouter) come risorsa di diversità cognitiva
  • Human-in-the-loop calibration

Portata: 12-18 mesi a impegno significativo. Sistema generale applicabile a multipli domini (trading, offerte commerciali, code review).

Documento di riferimento: coevolutive_swarm_system.md

6.2 Filone B — PoC trading focalizzato

Versione semplificata per validare empiricamente il concetto prima di committere al sistema completo.

Caratteristiche:

  • Solo Hypothesis layer evolve (Falsification e Adversarial hand-crafted)
  • Protocollo fisso (no co-evolution del linguaggio)
  • Focus su trading BTC/ETH con storico multi-anno
  • Baseline Random Forest per anti-illusion check
  • Decision triggers oggettivi per go/iterate/pivot

Portata: 3-4 mesi. Costo ~$2-4K LLM.

Documento di riferimento: poc_trading_swarm.md

6.3 Filone C — Applicazioni non-trading

Stesso framework architetturale applicato a domini con ground truth diverso:

  • Generazione offerte commerciali Tielogic (dataset implicito: offerte passate firmate vs no)
  • Code review automatico (dataset: PR storiche con bug noti)
  • Documentazione Swagger (fitness: copertura + qualità)
  • Scrittura documentazione tecnica

Portata: parallelizzabile con Filone A. Validazione che il sistema generalizzi.

Documento di riferimento: da scrivere se si decide di approfondire.


7. Le quattro idee non-ovvie

Sintesi delle intuizioni emerse durante la riflessione, in ordine di profondità:

7.1 Diversità cognitiva via tier multi-model

Non è solo "tier economici come compromesso". È che modelli diversi (Claude, Qwen, Llama, DeepSeek) hanno bias di addestramento diversi e producono ipotesi qualitativamente diverse sullo stesso dato. Per ricerca esplorativa è oro. Manterrei il multi-tier anche se Anthropic dimezzasse i prezzi domani.

7.2 Il protocollo di comunicazione come risorsa evolvibile

Forzare gli agenti a comunicare in linguaggio naturale è una scelta arbitraria, probabilmente subottimale. Co-evolvere protocollo + agenti significa che i pattern cognitivi che il sistema scopre dipendono da quali pensieri sono cheap da esprimere. E il protocollo evolve per rendere cheap i pensieri che si rivelano utili. Loop di co-adattamento, come grammatica e pensiero scientifico nelle culture umane.

7.3 Vincolo di leggibilità non opzionale

Senza vincoli, gli agenti convergono a protocolli incomprensibili. Per safety, audit, compliance, debugging — la fitness del protocollo deve includere human_unreadability_score con λ esplicito. Il sistema vive sul Pareto front efficienza/interpretabilità, scelto consapevolmente.

7.4 Survivorship bias narrativo

Sia chiaro: Renaissance è UN risultato di una distribuzione di tentativi. Per ogni Renaissance ci sono centinaia di fondi quant morti silenziosamente. Lo stesso vale per i sistemi LLM-based: la maggior parte non funzionerà. Il PoC esiste proprio per essere un esperimento honestly designed to fail se l'idea non regge. La baseline non-LLM (Random Forest) è il guardrail anti-illusione.


8. Le quattro trappole strutturali

In ordine di gravità, le trappole che possono distruggere qualsiasi versione del sistema:

8.1 Goodhart's Law su steroidi

L'evoluzione è una macchina ottimizzatrice cieca e troverà qualunque exploit della fitness function. Mitigazione: fitness multi-livello, human-in-the-loop, audit periodici dei top performer.

8.2 Multiple testing massiccio

Con migliaia di ipotesi testate, false scoperte a valanga. Mitigazione: Deflated Sharpe Ratio (Bailey & López de Prado), Bonferroni aggressiva, hold-out set finale intoccabile.

8.3 Communication degeneration

Senza vincoli, agenti convergono a comunicazione minimale e incomprensibile. Mitigazione: penalty leggibilità, parser strict, audit umano, italian rendering automatico.

8.4 Convergenza prematura / collasso di diversità

Senza speciation e novelty bonus, dopo 50 generazioni saturi su un ottimo locale. Mitigazione: speciation, novelty search, immigrazione random periodica, island model.


9. Decisione strategica: tre opzioni

Le opzioni concrete davanti, in ordine di rischio crescente:

Opzione C — Research dive (1-2 mesi)

  • Paper review approfondito (PromptBreeder, NEAT, MAP-Elites, emergent communication)
  • Proof-of-concept minimo (1 layer, 1 popolazione, protocol semplice)
  • Output: decisione informata se vale tutto

Opzione B — Smart spike (3-4 mesi) ← scelta preferita per partire

  • PoC trading completo (poc_trading_swarm.md)
  • Infrastruttura riutilizzabile
  • Output: validazione empirica + infrastruttura per espansione

Opzione A — Big bet (12-18 mesi)

  • Sistema completo (coevolutive_swarm_system.md)
  • Co-evolution piena, applicazioni multi-dominio
  • Output: sistema di ricerca/produzione, possibile paper

Razionale per partire da B: minimizza opportunity cost rispetto agli altri progetti (Tielogic, robotics, OptionScalping), produce infrastruttura riutilizzabile, dà criteri oggettivi per decidere se procedere con A.


10. Perché questo progetto, perché ora

10.1 Posizione strategica

Adriano è in una posizione strana e fortunata:

  • Background ingegneristico solido (C, C++, C#, Python da 30 anni)
  • Use case reali multipli (trading, offerte commerciali, robotica Tielogic)
  • Motivazione applicativa (non puramente accademica)
  • Familiarità con LLM tooling (Claude Code attivo nel workflow)
  • Capacità di lavorare full-stack (dal Rust backend al frontend React)

10.2 Stato del campo

Il filone "evolved structured communication languages for LLM multi-agent systems with interpretability constraints" non è saturo. La community è bloccata su due estremi: JSON+natural language (boring), o emergent communication su small models (non scalato a LLM moderni). C'è spazio per contributi reali.

10.3 Tempistica delle infrastrutture

Maggio 2026: i prezzi dei modelli sono scesi abbastanza da rendere economicamente fattibile un GA con migliaia di chiamate. OpenRouter offre routing multi-model trasparente. Anthropic ha prompt caching aggressivo. Tooling open-source maturo (DEAP, DSPy, TextGrad). Tre anni fa questo progetto sarebbe stato troppo costoso. Tre anni avanti potrebbe essere già commoditizzato.

10.4 Honest assessment

Detto tutto questo: il progetto è ambizioso, non garantito, e in competizione di tempo con altri progetti reali (Tielogic clienti, OptionScalping, robotics). La via responsabile è l'Opzione B: validare con il PoC, decidere a posteriori se vale espandere. Big bet su sistema completo solo dopo evidenza empirica positiva.


11. Stato del lavoro al 9 maggio 2026

Completato:

  • Framework concettuale (questo documento)
  • Design completo sistema (coevolutive_swarm_system.md)
  • Design completo PoC (poc_trading_swarm.md)

Decisioni aperte prima di partire:

  1. Quale opzione (A/B/C)?
  2. Se B, quale dominio iniziale (trading vs offerte commerciali)?
  3. Hardware locale vs cloud?
  4. Budget LLM iniziale committed?
  5. Cadenza review umana sostenibile?

Prossimi passi se si decide GO sul PoC (Opzione B):

  • Settimane 1-3: setup + dataset (vedi roadmap PoC sez. 11)
  • Decisioni infrastruttura (data provider, storage, compute)
  • Cap budget chiaro e milestone bi-settimanali

12. Tracciabilità della catena di ragionamento

Per riferimento futuro, questa è la sequenza logica che ha portato all'architettura proposta:

  1. Renaissance come modello: dati > teoria, anomalie > conferme, automatico > umano
  2. Cosa è replicabile: principi filosofici sì, infrastruttura no
  3. LLM agents shift: scala diversa rende possibile brute force di ipotesi
  4. Tre layer cognitivi: Hypothesis + Falsification + Adversarial come specializzazione funzionale necessaria
  5. Evoluzione genetica: scoprire prompt ottimali invece di scriverli
  6. Co-evolution multi-popolazione: i tre layer evolvono insieme
  7. Linguaggio evolutivo: il protocollo di comunicazione è artefatto evolvibile
  8. Tier multi-model: diversità cognitiva + economia
  9. Vincoli di leggibilità: non opzionali per safety/audit
  10. PoC come deviazione strategica: validare prima di committere full

Ogni step è un pezzo del ragionamento che vale la pena ricordare. Se uno step si rivela sbagliato, gli step successivi vanno rivisti.


Documento da aggiornare se la direzione strategica cambia. Versione 0.1 — pre-implementazione.