Probabilmente non ti serve il fine-tuning
Il fine-tuning è spesso il primo rimedio proposto quando una funzione AI rende poco. Quasi sempre al modello manca contesto, non capacità, e senza un set di eval non sai nemmeno se il tuning ha aiutato.
Riscritti per essere letti fuori dal feed, in tre lingue. Il canonical punta sempre qui.
Il fine-tuning è spesso il primo rimedio proposto quando una funzione AI rende poco. Quasi sempre al modello manca contesto, non capacità, e senza un set di eval non sai nemmeno se il tuning ha aiutato.
Ogni sistema on-chain in produzione dipende da poche chiavi private. Dove vivono, chi può usarle e cosa succede quando qualcuno se ne va sono decisioni di architettura, non note di passaggio di consegne.
Ancorare un hash on-chain è il lavoro di un pomeriggio. Quello che decide se serviva a qualcosa è il percorso di verifica: chi controlla, con cosa in mano, fra cinque anni.
Nei progetti con agenti AI il vincolo non è il modello, è il sistema che tiene i dati dell'azienda. Leggere è la metà facile; scrivere è dove stanno integrità, identità e preventivo.
Quasi ogni sistema multi-agente prende un compito, lo taglia a pezzi e affida il coordinamento a un modello a runtime. La colla è dove muoiono affidabilità e margine.
Coniare un token è il decimo facile del lavoro. Il legame, il riscatto e la prova delle riserve sono il prodotto — e il punto dove i progetti di tokenizzazione riescono o falliscono.
Un agente AI passa la demo sull'accuratezza. In produzione a decidere se sopravvive è il costo per pratica: token, tool call, retry e un loop che si può avvitare.
Un contratto pubblicato non si corregge: si aggiunge un proxy e una chiave di upgrade. È quella chiave, non la logica certificata dall'audit, la cosa da proteggere.
Tutto il codice ha una rete di sicurezza tranne la parte che prende le decisioni. Perché un componente non deterministico va comunque testato con un eval harness — input dorati, proprietà attese, un punteggio che fa da gate in CI — e perché per una software house .NET è la stessa disciplina degli unit test.
Un agente decide da solo il passo successivo in un loop; un workflow segue un percorso fisso e chiama il modello solo dove l'input è ambiguo. Perché di solito il workflow è più economico, più testabile e più facile da dimostrare — e quando l'agente serve davvero.