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.

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)