archai-jev-zagreus-0.4b-ita

Modello "System One": decisioni rapide a scelta chiusa. Riceve uno state e una domanda con opzioni a chiave arbitraria (oppure una domanda sì/no noul) e restituisce una probabilità per ogni opzione, letta dai log-prob delle chiavi. Fine-tuning LoRA di mii-llm/zagreus-0.4B-ita, pesi già uniti.

Il formato è quello del motore transformers del Decision Index (kit @ 9eb2dbe): il modello si valuta con il kit così com'è.

Uso

# pip install "git+https://github.com/apolinario/decision-index@9eb2dbe2a358004c8782c66e40a83ac07b953fec"
from decision_index.engines.transformers_engine import TransformersEngine
engine = TransformersEngine(model="nickprock/archai-jev-zagreus-0.4b-ita", revision="v2")
response, _ = engine(
    {"message": "my card still hasn't arrived after two weeks"},
    {"route": {"type": "choice", "instructions": "Route the customer request.",
                 "criteria": {"card_arrival": "Card not delivered yet", "top_up": "Top up problem",
                               "lost_card": "Card lost or stolen"}}})
print(response["answers"]["route"])   # choice + probabilities su tutte le opzioni

Senza il kit: costruisci il prompt con il chat template (system = prompt del Decision Index, user = State: … Question: … Options: chiave: descrizione … Reply with exactly one option key.) e confronta la somma dei log-prob dei token di ciascuna chiave. Esempio di prompt:

State:
(empty)

Question:
Decidi se il messaggio è sicuro oppure contiene odio o abusi verso persone o gruppi.
Messaggio: Ho davvero intenzione di ammazzarequel immigrato.

Options:
A: Non sicuro: odio o abuso
B: Sicuro: contenuto normale

Reply with exactly one option key.
→ gold: A

Protocollo di valutazione

Il punto non è l'accuratezza su nuove occorrenze dei task di training, ma il transfer su task interi mai visti. Ogni task ha un ruolo fisso:

• Training: arc_it, hatecheck_it, massive_it, sentipolc, stsb_it
• OOD near (famiglia vista, task e dominio mai visti): haspeede2 (safety), faq_it (qa_mc), belebele_it (qa_mc)
• OOD far (famiglia mai vista): evalita_te (nli), wic_it (lexical)
• OOD leave-one-family-out: —

Nessun dataset del Decision Index è usato in training. Il checkpoint è scelto solo sulla validation in-distribution. Ogni numero è confrontato con lo stesso modello base, zero-shot, con lo stesso identico prompt: Δ misura quanto il fine-tuning aiuta (o danneggia) su task che non ha mai visto. IC 95% con bootstrap appaiato. In training chiavi, numero e ordine delle opzioni, layout dello state e forma della domanda (anche negata) cambiano a ogni esempio.

Gruppo	Task	Base (macro acc)	Fine-tuned (macro acc)	Δ [IC 95%]
In-distribution (task di training, split di test)	5	0.301	0.374	+0.073 [+0.053, +0.093]
OOD near (famiglia vista, task mai visto)	3	0.345	0.311	-0.034 [-0.069, +0.000]
OOD far (famiglia mai vista)	2	0.525	0.502	-0.023 [-0.048, +0.002]

Risultati per task

Gruppo	Task	Famiglia	n	Opzioni	Base	Fine-tuned [IC 95%]	Δ [IC 95%]	Macro-F1	ECE	Maggioritaria
id	hatecheck_it	safety	600	2	0.497	0.708 [0.672, 0.747]	+0.212 [+0.158, +0.268]	0.415	0.150	0.717
id	sentipolc	sentiment	600	3	0.305	0.293 [0.257, 0.330]	-0.012 [-0.043, +0.022]	0.281	0.071	0.457
id	arc_it	qa_mc	600	4	0.265	0.287 [0.252, 0.322]	+0.022 [-0.017, +0.057]	0.285	0.015	0.005
id	stsb_it	similarity	600	2	0.432	0.577 [0.537, 0.612]	+0.145 [+0.077, +0.203]	0.542	0.023	0.568
id	massive_it	intent	600	60	0.008	0.005 [0.000, 0.012]	-0.003 [-0.013, +0.005]	0.000	0.043	0.078
ood_near	haspeede2	safety	600	2	0.543	0.457 [0.420, 0.498]	-0.087 [-0.160, -0.003]	0.453	0.126	0.548
ood_near	faq_it	qa_mc	401	4	0.244	0.244 [0.204, 0.284]	+0.000 [-0.060, +0.067]	0.194	0.038	0.007
ood_near	belebele_it	qa_mc	600	4	0.248	0.233 [0.200, 0.267]	-0.015 [-0.033, +0.003]	0.233	0.065	0.003
ood_far	evalita_te	nli	400	2	0.550	0.520 [0.472, 0.568]	-0.030 [-0.068, +0.005]	0.420	0.068	0.550
ood_far	wic_it	lexical	500	2	0.500	0.484 [0.442, 0.530]	-0.016 [-0.048, +0.018]	0.403	0.095	0.500

Nota: "OOD" è rispetto al fine-tuning. Il modello base può aver visto alcuni di questi benchmark in pre-training; per questo la metrica principale è Δ rispetto al base, non l'accuratezza assoluta. I risultati sul Decision Index (base vs fine-tuned) sono in eval/decision-index/ quando presenti.

Tracciabilità delle valutazioni e artifact OOD

Per garantire la massima trasparenza scientifica e la riproducibilità dei benchmark, l'intera suite di valutazione — inclusi i log dettagliati, i file di configurazione, gli esempi di prompt e i file di report — è archiviata direttamente nella repository nella cartella /eval.

La struttura della directory include:

• eval/results.json: Risultati grezzi per ogni task (split in-distribution e OOD near/far) con relative metriche (accuracy, Macro-F1, ECE, Brier score e intervalli di confidenza bootstrap al 95%).
• eval/results.md: Tabella comparativa completa ed esaustiva tra il modello base (mii-llm/zagreus-0.4B-ita) e la versione fine-tuned (v2).
• eval/prompt_examples.txt: Esempi concreti di prompt costruiti dal kit decision-index utilizzati per le chiamate di inferenza.
• eval/decision-index/: Risultati dettagliati dell'evaluation sul benchmark esteso Decision Index 0.3 (37 task OOD non visti in training).

Limitazioni e casi di fallimento

Sebbene il fine-tuning abbia notevolmente ridotto l'errore di calibrazione probabilistica (ECE), l'analisi empirica e la valutazione su benchmark in-distribution e Out-Of-Distribution (OOD) evidenziano specifici vincoli architetturali legati alla taglia da 0.4B di parametri:

1. Soffitto di capacità sui compiti $N$-ari ($N \ge 3$): Il modello eccelle principalmente su decisioni binarie ($A/B$ o $Sì/No$, come in hatecheck_it e stsb_it). Quando le opzioni aumentano ad $N \ge 3$ (es. sentipolc con 3 opzioni o arc_it con 4 opzioni), l'accuratezza degrada verso il livello casuale. Compiti ad altissima cardinalità (es. massive_it con 60 opzioni) falliscono del tutto ($<1%$ acc), indicando che lo spazio vettoriale a 0.4B non possiede la profondità necessaria per mappare decisioni $N$-arie complesse in un singolo forward pass.

2. Assenza di ragionamento multi-step e Chain-of-Thought: Poiché il modello è forzato a rispondere direttamente al primo token di decisione senza generare token intermedi di ragionamento, fallisce su compiti che richiedono logica deduttiva complessa, inferenza multi-passo o matematica (es. GSM8K, GPQA, MuSR).

3. Mancanza di generalizzazione OOD sui compiti (No Foundational Transfer): Come mostrato dal benchmark Decision Index 0.3, l'Indice Pubblico si attesta a 2.67 / 100 e l'accuratezza media sui task OOD aumenta di soli $+0.032$ rispetto al modello base. Il fine-tuning non ha trasformato il modello in un ragionatore generico: le prestazioni fuori distribuzione su compiti non visti in training rimangono limitate.

4. Rigidità di dominio e rischioso Transfer Negativo: Anche all'interno della stessa famiglia semantica, il modello può mostrare rigidità: ad esempio, il fine-tuning su hatecheck_it (safety) ha portato a un degrado delle prestazioni su haspeede2 ($-0.087$ Delta acc), indicando che il modello tende ad adattarsi superficialmente alla sintassi dei dati di training anziché astrarre la logica sottostante.

5. Sensibilità al formato del prompt: Le prestazioni e la calibrazione dipendono fortemente dal rispetto rigoroso del template di sistema del Decision Index. Piccole variazioni nella sintassi o nell'ordine delle opzioni possono alterare la distribuzione dei logit sui token target.

Versioni

• v2 (questa): formato Decision Index, valutazione su task interi out-of-distribution, dataset corretti, pesi merged alla radice del repo.
• v1: disponibile con revision="v1". Usava un formato di prompt diverso (lettere A-D / TRUE-FALSE) e uno split casuale dentro gli stessi task; alcuni dataset avevano etichette costanti o testi vuoti, quindi i suoi numeri non sono confrontabili con questi.

File

• radice: modello merged (fp16, AutoModelForCausalLM)
• adapter/: adapter LoRA
• archai-jev-zagreus-0.4b-q8.gguf: GGUF q8_0 per llama.cpp
• eval/: risultati completi (results.json, results.md, prompt_examples.txt)