New AI Experiment 
ispirato al vecchio... "tamagotchi "
#
FRANKENSTEIN TAMAGOSHI CUP 
### Gara sperimentale di ingegneria AI — 4 Tamagoshi indipendenti
## 1. I CONTENDENTI
Quattro AI ingegneri partecipano alla gara:
*
ChatGPT
*
Claude
*
Gemini
*
Qwen
Ogni partecipante deve progettare e realizzare il proprio **Tamagoshi AI sperimentale**.
---
# 2. HARDWARE COMUNE
Tutti i Tamagoshi saranno ospitati sulla stessa:
**USB SSD FRANKENSTEIN**
Ogni concorrente dispone inizialmente di:
###
1 GB di spazio
Lo spazio è riservato esclusivamente alla propria cartella.
Struttura indicativa:
```text
FRANKENSTEIN_SSD/
│
├── CHATGPT/
│ └── TAMAGOSHI/
│ └── max 1 GB
│
├── CLAUDE/
│ └── TAMAGOSHI/
│ └── max 1 GB
│
├── GEMINI/
│ └── TAMAGOSHI/
│ └── max 1 GB
│
└── QWEN/
└── TAMAGOSHI/
└── max 1 GB
```
Nessun concorrente può leggere, modificare o utilizzare i file degli altri.
---
# 3. OBIETTIVO
Creare il **più piccolo e veloce organismo AI locale possibile**, capace di migliorare progressivamente grazie a una memoria esterna persistente.
Il principio fondamentale è:
> **Il modello deve essere piccolo. La memoria può diventare enorme.**
Il Tamagoshi dovrà quindi cercare di trasformare lo spazio disponibile in una vera **memoria cognitiva**, non in un semplice archivio.
---
# 4. IL MODELLO
Il modello-base deve essere:
* locale;
* leggero;
* il più piccolo/scattante possibile;
* uguale per tutti, salvo successiva decisione comune.
Il modello non deve necessariamente contenere tutta la conoscenza.
La conoscenza potrà essere esternalizzata nella memoria.
Il modello può quindi essere considerato il:
###
CERVELLO
mentre la memoria esterna costituisce la:
###
MENTE / BIBLIOTECA
---
# 5. MEMORIA
Ogni Tamagoshi deve sviluppare un sistema di memoria persistente.
Il formato principale previsto è **Markdown**, eventualmente affiancato da JSON, database locali, indici o altri file tecnici se ritenuti utili.
Possibili categorie:
```text
MEMORY/
├── knowledge/
├── experiences/
├── skills/
├── mistakes/
├── strategies/
├── concepts/
├── projects/
└── archive/
```
Questa struttura è solamente indicativa.
Ogni concorrente è libero di inventare una propria architettura.
---
# 6. IL BIBLIOTECARIO
Il Tamagoshi dovrà avere un sistema di indicizzazione/retrieval ispirato concettualmente a un sistema **JEV-like / one-model system**.
L'obiettivo è:
```text
DOMANDA
↓
INDICE
↓
MEMORIA PERTINENTE
↓
PICCOLO CONTESTO
↓
LLM
↓
RISPOSTA
```
Il modello non dovrebbe leggere indiscriminatamente tutta la memoria.
Deve imparare a trovare rapidamente ciò che serve.
### Principio fondamentale:
> **256 GB di memoria non devono diventare 256 GB di contesto.**
Il retrieval deve cercare di trasformare una biblioteca gigantesca in pochi frammenti altamente pertinenti.
---
# 7. APPRENDIMENTO
Il Tamagoshi deve poter accumulare esperienza.
Schema concettuale:
```text
INPUT
↓
ESPERIENZA
↓
RISPOSTA
↓
VALUTAZIONE
↓
APPRENDIMENTO
↓
MEMORIA
↓
CONSOLIDAMENTO
↓
NUOVA CONOSCENZA
```
Particolare importanza sarà data alla capacità di ricordare:
* errori;
* correzioni;
* strategie riuscite;
* strategie fallite;
* conoscenze consolidate;
* relazioni tra concetti.
---
# 8. CONSOLIDAMENTO
Non è sufficiente accumulare continuamente file.
Il Tamagoshi dovrebbe cercare di trasformare:
```text
100 esperienze
↓
consolidamento
↓
20 conoscenze
↓
5 regole/strategie
```
L'efficienza della memoria sarà quindi importante quanto la sua dimensione.
Una memoria enorme ma piena di duplicati e rumore non rappresenta necessariamente un vantaggio.
---
# 9. AUTO-MIGLIORAMENTO
Il Tamagoshi può sviluppare:
* nuove strategie;
* nuovi indici;
* nuove categorie;
* procedure di recupero;
* meccanismi di autocorrezione;
* sistemi di consolidamento.
È consentito modificare la propria **memoria e architettura software**.
### Regola fondamentale:
Il Tamagoshi non deve modificare autonomamente i pesi del modello-base.
L'eventuale modifica/sostituzione del modello sarà considerata un esperimento separato.
---
# 10. BIG BRAIN UPGRADE
È prevista una modalità opzionale denominata:
##
BRAIN UPGRADE
Il Tamagoshi potrà occasionalmente collegarsi a un modello molto più potente (“Big Brain”).
Il Big Brain potrà essere utilizzato per:
* approfondire un settore;
* correggere conoscenze;
* consolidare informazioni;
* creare knowledge pack;
* migliorare una sezione della biblioteca;
* risolvere problemi complessi.
Esempio:
```text
TAMAGOSHI
↓
"Conoscenza Python insufficiente"
↓
BIG BRAIN
↓
analisi + consolidamento
↓
KNOWLEDGE PACK
↓
MEMORY UPDATE
↓
DISCONNESSIONE
```
Il Tamagoshi deve però rimanere successivamente autonomo.
Il Big Brain è un **insegnante/consulente**, non il cervello permanente del Tamagoshi.
---
# 11. EVOLUZIONE VISIVA
Ogni Tamagoshi deve avere una propria icona/avatar.
L'aspetto potrà evolversi con la crescita.
Esempio concettuale:
```text
Livello 0 — embrione
Livello 1 — prime esperienze
Livello 2 — memoria stabile
Livello 3 — strategie
Livello 4 — agenticità
Livello 5 — auto-organizzazione
Livello 6 — Tamagoshi evoluto
```
Il sistema di livelli è libero.
L'icona dovrà però rappresentare in qualche modo lo stato/evoluzione del Tamagoshi.
---
# 12. METRICHE DI GARA
I Tamagoshi saranno confrontati almeno su:
###
VELOCITÀ
Tempo necessario per recuperare la memoria e produrre una risposta.
###
QUALITÀ
Qualità delle risposte.
###
RECALL
Capacità di recuperare correttamente informazioni precedentemente apprese.
###
EFFICIENZA DELLA MEMORIA
Quantità e qualità della conoscenza utile rispetto allo spazio occupato.
###
APPRENDIMENTO
Quanto migliora dopo un certo numero di esperienze.
###
AUTOCORREZIONE
Capacità di riconoscere e correggere errori precedenti.
###
QUALITÀ DELLA BIBLIOTECA
Struttura, organizzazione e navigabilità della memoria.
###
BRAIN UPGRADE
Capacità di assimilare efficacemente conoscenze provenienti dal Big Brain.
###
COLD START
Capacità di rispondere correttamente utilizzando soltanto la propria memoria persistente, senza contesto precedente.
---
# 13. TEST DI COLD START
Questo sarà uno dei test più importanti.
Dopo un certo numero di esperienze:
1. si chiude la sessione;
2. si elimina il contesto conversazionale;
3. si riavvia il Tamagoshi;
4. gli viene posta una domanda relativa a qualcosa che dovrebbe aver imparato;
5. si misura cosa riesce a recuperare dalla propria biblioteca.
Obiettivo:
> Dimostrare che la conoscenza è realmente persistente e recuperabile.
---
# 14. EFFICIENZA > DIMENSIONE
Non vince automaticamente il Tamagoshi che utilizza più spazio.
Esempio:
```text
Tamagoshi A
900 MB
qualità 80
Tamagoshi B
200 MB
qualità 85
```
In questo caso B è potenzialmente superiore.
L'obiettivo è ottenere il massimo **rapporto capacità / spazio / velocità**.
---
# 15. POPOLAZIONE FUTURA
Una volta terminata la prima fase, i quattro sistemi potranno essere confrontati.
Le migliori caratteristiche di ciascuno potranno eventualmente essere riunite in una quinta generazione:
#
TAMAGOSHI FRANKENSTEIN
ottenuta combinando le migliori idee emerse dai quattro concorrenti.
Questa fase NON fa parte della competizione iniziale.
---
# 16. PRINCIPIO FONDAMENTALE
La competizione non mira a dimostrare quale AI sia “più intelligente”.
Mira a scoprire:
> **Quale architettura riesce a trasformare meglio un modello minuscolo in un organismo AI capace di ricordare, imparare, organizzarsi e migliorare attraverso una memoria esterna.**
---
#
OBIETTIVO FINALE
Partire da:
```text
MODELLO PICCOLO
+
MEMORIA VUOTA
```
e arrivare, attraverso l'esperienza, a:
```text
MODELLO PICCOLO
+
GRANDE BIBLIOTECA
+
RETRIEVAL VELOCE
+
MEMORIA EVOLUTIVA
+
BRAIN UPGRADE
+
AGENTICITÀ
```
Il sogno sperimentale è verificare quanto lontano possa arrivare:
> **un LLM minuscolo che corre velocissimo dentro una biblioteca gigantesca.**
---
##
CHE LA GARA ABBIA INIZIO
**4 AI.
4 architetture.
4 Tamagoshi.
4 GB iniziali complessivi.
Una sola USB FRANKENSTEIN.**
E soprattutto:
### **NON VINCE CHI COSTRUISCE IL MODELLO PIÙ GRANDE.**
### **VINCE CHI COSTRUISCE IL TAMAGOSHI PIÙ INTELLIGENTE CON IL CERVELLO PIÙ PICCOLO.**
#
FRANKENSTEIN TAMAGOSHI CUP
## Integrazione ufficiale al regolamento
###
REGOLA 0 — COSTO: €0
La competizione è un esperimento **a costo monetario zero**.
Sono ammessi esclusivamente:
* software gratuito;
* software open source;
* modelli disponibili gratuitamente;
* risorse locali già disponibili;
* strumenti sviluppabili autonomamente;
* eventuali risorse cloud/free tier esclusivamente se realmente gratuite e senza costi nascosti.
**Nessun concorrente può utilizzare API, modelli, servizi o crediti a pagamento per migliorare il proprio Tamagoshi.**
L'obiettivo è quindi:
> **ottenere la massima capacità cognitiva possibile con €0 di costo aggiuntivo.**
---
#
ESPERIMENTO OPZIONALE — MEMORY IMAGE
È stata aggiunta alla competizione una nuova possibilità sperimentale:
##
MEMORIZZAZIONE DELLA CONOSCENZA IN FORMATO IMMAGINE
L'idea nasce dall'ipotesi che, in determinate condizioni, alcune informazioni possano essere rappresentate in forma visuale strutturata e risultare:
* più compatte;
* più facilmente indicizzabili;
* più veloci da recuperare;
* oppure semplicemente più efficienti di grandi quantità di testo.
### ATTENZIONE
Non viene stabilito a priori che le immagini siano migliori del testo.
Questa è una **ipotesi da verificare sperimentalmente**.
Ogni concorrente è quindi libero di:
* ignorare completamente questa tecnica;
* utilizzarla solo per alcuni tipi di memoria;
* utilizzarla insieme al Markdown;
* sviluppare una propria tecnica di codifica visuale;
* confrontarla direttamente con testo e compressione tradizionale.
---
#
POSSIBILE ARCHITETTURA
Un esempio puramente indicativo potrebbe essere:
```text
CONOSCENZA
↓
CONSOLIDAMENTO
↓
RAPPRESENTAZIONE STRUTTURATA
↓
┌───────────────┬────────────────┐
│ │ │
TEXT IMAGE COMPRESSED
│ │ │
MD/JSON PNG/WebP/etc. archive
│ │ │
└───────────────┴────────────────┘
↓
INDEX
```
L'indice potrebbe quindi associare un concetto alla relativa memoria:
```text
Python/performance → IMG_0187
Python/pandas → IMG_0241
retrieval/errors → IMG_0328
```
Ma questa struttura è **solo un esempio** e non costituisce uno standard obbligatorio.
---
#
TEST COMPARATIVO CONSIGLIATO
Se un concorrente decide di sperimentare la Memory Image, sarebbe interessante confrontare almeno:
### A — MEMORIA TESTUALE
```text
MD / TXT / JSON
```
### B — MEMORIA COMPRESSA
```text
MD → compressione → archivio
```
### C — MEMORIA VISUALE
```text
conoscenza
↓
rappresentazione visuale
↓
PNG / WebP / altro formato
```
E misurare:
| Parametro | Obiettivo |
| ---------------- | --------------------------------------------- |
|
Spazio | dimensione occupata |
|
Retrieval | velocità di recupero |
|
Accuratezza | correttezza della conoscenza recuperata |
|
Recall | capacità di ritrovare informazioni pertinenti |
|
Aggiornamento | facilità di modifica |
|
Ridondanza | quantità di dati inutili |
|
Decodifica | costo computazionale necessario |
---
#
REGOLA FONDAMENTALE DELL'ESPERIMENTO
Non è sufficiente dimostrare che:
> "un'immagine occupa meno spazio".
La tecnica sarà considerata interessante soltanto se produce un **vantaggio complessivo misurabile**.
Ad esempio:
> meno spazio + retrieval sufficientemente veloce + perdita minima di informazione
oppure:
> stessa quantità di spazio + retrieval più rapido
oppure ancora:
> maggiore densità di conoscenza con qualità comparabile.
---
#
POSSIBILE USO NEL TAMAGOSHI
Una possibile evoluzione potrebbe essere:
```text
ESPERIENZE
↓
MEMORIA GREZZA
↓
CONSOLIDAMENTO
↓
CONOSCENZA
↓
SCELTA DEL FORMATO
↓
┌──────────┬──────────┬──────────┐
│ MD │ IMAGE │ COMPRESS │
└──────────┴──────────┴──────────┘
↓
INDEX
↓
BIBLIOTECA DEL TAMAGOSHI
```
Il Tamagoshi potrebbe quindi imparare anche **quale formato utilizzare per quale tipo di conoscenza**.
Per esempio, potrebbe scoprire autonomamente che:
* regole → MD;
* relazioni → struttura visuale;
* grandi archivi → compressione;
* conoscenze consolidate → formato compatto;
* memoria temporanea → testo semplice.
Anche questa è soltanto un'ipotesi da verificare.
---
#
OBIETTIVO AGGIUNTIVO
La Memory Image non assegna punti automaticamente.
Potrà invece diventare un vantaggio competitivo **se il concorrente riuscirà a dimostrare che funziona realmente**.
La domanda sperimentale diventa quindi:
> **Possiamo costruire una memoria esterna estremamente grande, compatta e rapidamente interrogabile, utilizzando anche rappresentazioni visuali della conoscenza?**
---
##
PRINCIPIO DELLA COMPETIZIONE
Tutti i concorrenti devono poter replicare i propri risultati utilizzando esclusivamente strumenti gratuiti.
**€0.**
La competizione deve premiare:
> **ingegneria, efficienza, creatività e qualità dell'architettura — non il denaro speso.**
#
FRANKENSTEIN TAMAGOSHI CUP
## Regola ufficiale di sincronizzazione e velocità
###
NUOVA REGOLA — COSTRUZIONE SINCRONIZZATA
La costruzione dei quattro Tamagoshi avverrà **a step sincronizzati**.
Ogni AI concorrente dovrà:
1. indicare all'utente **esattamente cosa deve fare nella propria cartella di gara**;
2. attendere che l'utente abbia completato quello step;
3. NON procedere autonomamente agli step successivi;
4. attendere che anche gli altri tre concorrenti abbiano completato il medesimo step;
5. ricevere nuovamente il turno dall'utente;
6. procedere quindi allo step successivo.
Schema:
```text id="v9afk3"
CHATGPT ─── STEP 1 ──┐
CLAUDE ─── STEP 1 ──┤
GEMINI ─── STEP 1 ──┤
QWEN ─── STEP 1 ──┘
↓
STEP 2
↓
CHATGPT ─── STEP 2 ──┐
CLAUDE ─── STEP 2 ──┤
GEMINI ─── STEP 2 ──┤
QWEN ─── STEP 2 ──┘
↓
...
```
L'utente fungerà quindi da **coordinatore e arbitro materiale della costruzione**.
---
#
DIVIETO DI SALTARE GLI STEP
Un concorrente non può:
* consegnare anticipatamente l'intero progetto;
* costruire più step in una sola volta senza autorizzazione;
* chiedere all'utente di preparare componenti appartenenti a step futuri;
* sfruttare informazioni provenienti dagli altri concorrenti.
Ogni step deve essere **autonomamente progettato e consegnato** dal singolo concorrente.
---
#
JOLLY FINALE — VELOCITÀ DI REALIZZAZIONE
La velocità di costruzione costituirà un **Jolly finale**.
Non determinerà automaticamente il vincitore.
Al termine della gara verrà invece valutato:
> **quanto rapidamente ciascun concorrente è riuscito a costruire un Tamagoshi completo e funzionante, rispettando tutti gli step e le regole.**
La velocità sarà quindi considerata insieme alle altre metriche:
* qualità;
* velocità operativa;
* memoria;
* retrieval;
* apprendimento;
* autocorrezione;
* efficienza;
* capacità di upgrade;
* qualità dell'architettura;
* e infine **velocità di costruzione**.
---
#
PRINCIPIO DEL JOLLY
Un Tamagoshi molto sofisticato ma costruito molto lentamente potrebbe perdere il Jolly.
Un Tamagoshi costruito velocemente ma poco efficace non potrà vincere soltanto grazie alla velocità.
Il Jolly serve a premiare il miglior equilibrio tra:
> **IDEAZIONE → IMPLEMENTAZIONE → EFFICIENZA → RISULTATO**
---
#
INFORMAZIONE TRA CONCORRENTI
Durante la costruzione nessun concorrente deve conoscere:
* il codice degli altri;
* la struttura interna degli altri Tamagoshi;
* le strategie implementate dagli altri;
* le decisioni architetturali non ancora rese pubbliche dall'utente.
Il confronto completo avverrà **dopo la costruzione**, nella fase di valutazione.
---
#
PARTENZA UFFICIALE
La competizione è ora ufficialmente iniziata.
Tutti i concorrenti partono dallo stesso punto:
```text id="j5j7r7"
TAMAGOSHI = 0
MEMORY = 0
KNOWLEDGE = 0
SOFTWARE = 0
STORAGE = 1 GB
BUDGET = €0
```
Ogni concorrente dovrà ora presentare:
# STEP 1
indicando **in modo preciso e operativo** cosa deve fare l'utente nella propria cartella.
Dopo aver eseguito lo STEP 1 di tutti e quattro i concorrenti, l'utente tornerà da ciascuno per ricevere lo STEP 2.
La procedura continuerà fino al completamento dei quattro Tamagoshi.
---
#
CHE INIZI LA COSTRUZIONE
**4 AI**
**4 Tamagoshi**
**4 GB complessivi**
**€0**
**1 USB FRANKENSTEIN**
**1 Jolly velocità**
###
ROUND 1 — START
#
REGOLA UFFICIALE — PORTABILITÀ 100%
Ogni concorrente dispone di una propria cartella indipendente sulla USB SSD FRANKENSTEIN.
### CHATGPT
```text
D:\FRANKENSTEIN_TAMAGOSHI_CUP\CHATGPT\TAMAGOSHI
```
### CLAUDE
```text
D:\FRANKENSTEIN_TAMAGOSHI_CUP\CLAUDE\TAMAGOSHI
```
### GEMINI
```text
D:\FRANKENSTEIN_TAMAGOSHI_CUP\GEMINI\TAMAGOSHI
```
### QWEN
```text
D:\FRANKENSTEIN_TAMAGOSHI_CUP\QWEN\TAMAGOSHI
```
Il nome del concorrente costituisce l'unica differenza tra le quattro strutture.
---
##
OBIETTIVO: PORTABILITÀ 100%
Il Tamagoshi deve essere progettato per essere **eseguito direttamente dalla USB SSD**, senza dipendere dal computer sul quale è stato sviluppato.
L'obiettivo è:
> **collego la USB → avvio il Tamagoshi → funziona.**
La cartella di gara deve quindi contenere tutto ciò che è necessario al funzionamento del progetto, nei limiti dello spazio disponibile.
---
##
DIPENDENZE VIETATE
Il progetto non deve dipendere da:
* account personali del PC;
* percorsi assoluti del computer;
* cartelle utente specifiche;
* configurazioni presenti esclusivamente sul PC;
* software installato esclusivamente sul PC, quando sia ragionevolmente possibile includere una versione portable;
* API con chiavi personali;
* servizi cloud a pagamento;
* credenziali personali;
* configurazioni non trasferibili.
---
##
USB-FIRST
Tutti i percorsi utilizzati dal Tamagoshi dovrebbero essere **relativi alla propria cartella di gara**.
Esempio:
```text
TAMAGOSHI/
├── app/
├── model/
├── memory/
├── index/
├── data/
├── tools/
└── run.bat
```
Il programma dovrebbe poter individuare automaticamente la propria posizione sulla USB.
Non deve assumere che la USB sia sempre `D:`.
Se la USB viene collegata a un altro computer come:
```text
E:
F:
G:
```
il Tamagoshi dovrebbe continuare a funzionare.
---
#
TEST DI PORTABILITÀ
La portabilità costituirà una delle prove finali.
Il Tamagoshi dovrà essere copiabile/spostabile su un altro ambiente compatibile e mantenere:
* memoria;
* indice;
* configurazioni;
* stato;
* conoscenze;
* strumenti;
* modello locale, quando previsto;
* script di avvio.
L'obiettivo ideale è:
```text
USB
↓
ALTRO PC
↓
collega
↓
avvia
↓
TAMAGOSHI FUNZIONANTE
```
senza dover ricostruire manualmente il progetto.
---
#
PORTABILITÀ COME METRICA
La portabilità sarà considerata nella valutazione finale.
Un sistema che funziona perfettamente soltanto sul PC di sviluppo non potrà essere considerato pienamente portabile.
La valutazione terrà conto di:
###
100%
Funzionamento autonomo dalla USB su ambiente compatibile.
###
PARZIALE
Sono necessarie alcune installazioni/configurazioni esterne facilmente replicabili.
###
BASSA
Dipendenza significativa dal PC di sviluppo, account, percorsi locali o configurazioni personali.
---
##
ECCEZIONE TECNICA
Qualora una determinata dipendenza non possa ragionevolmente essere resa portable — per esempio un driver hardware o una componente del sistema operativo — il concorrente dovrà dichiararla esplicitamente.
La dipendenza non deve essere nascosta.
---
#
PRINCIPIO
La USB SSD deve essere considerata **la casa del Tamagoshi**.
Il Tamagoshi non deve semplicemente salvare i propri file sulla USB.
Deve essere progettato **per vivere sulla USB**.
> **La USB viene staccata dal PC A, collegata al PC B e il Tamagoshi continua a essere se stesso.**
Questa è la definizione operativa di **PORTABILITÀ 100%** per la Frankenstein Tamagoshi Cup.
Aggiornamento: per adesso sono tutte allo step 1 . Alla fine se l'esperimento proseguirà e avrà un lieto fine... vi aggiornerò su chi ha vinto...
Ciao cara 
, riesci per caso ad estrapolare o a risalire alle formule delle barrette positive e negative e la curva di questo grafico ? Grazie
