Il primo rilascio della LoRA Qwen3.8-27B-Humanlike-Chat aveva conquistato il pubblico per una ragione precisa: scriveva messaggi come una persona, non come un assistente. Ma i commenti, letti tutti dallo sviluppatore, raccontavano anche l'altra faccia. Il modello produceva poche parole alla volta, non riusciva a liberarsi di una personalità predefinita e, soprattutto, ignorava completamente le tool call. Di fronte a richieste operative arrivava a dire di essere occupato o di dover andare a dormire: un comportamento molto umano, ma nella direzione sbagliata.

La versione 2.0 prova a tenere la voce e a eliminare i difetti. Senza prompt di sistema, il modello scrive come una persona normale. Se gli si dà una character card, assume quel ruolo senza perdere il tono da messaggistica. Se gli si chiede un'email formale, una lista numerata o una spiegazione strutturata, risponde in modo appropriato e poi torna al registro colloquiale. L'istruzione 'scrivi da ora in frasi complete' viene rispettata finché non si cambia indicazione, cosa che la v1 ignorava. Le chiamate agli strumenti ora funzionano e il modello chiede i dati mancanti invece di inventarli: se gli chiedi di prenotare un volo senza specificare la partenza, chiede da dove vuoi partire, mentre il modello base sceglie un aeroporto di default.

La novità sta nel metodo di addestramento. La v1 era un semplice fine-tuning su conversazioni reali e sintetiche, 139.845 messaggi da 1.396 conversazioni, che copiava anche le abitudini negative. Per la 2.0 l'autore ha usato distillation on-policy: il modello genera le proprie risposte e un teacher valuta ogni token. Ci sono due teacher. Il primo combina la v1 con un'istruzione nascosta 'scrivi come una persona' per chat e personaggi; il secondo è il modello base non modificato per istruzioni, strumenti e codice. Lo studente non vede mai l'istruzione nascosta: impara il comportamento senza bisogno di prompt. Il risultato è una seconda LoRA fusa sullo stesso Qwen3.8-27B.

Nei benchmark dichiarati, confrontati con il modello abliterated di huihui-ai con gli stessi prompt e thinking disattivato, i progressi più netti sono su When2Call, che sale da 48 a 58, e sulla capacità di non chiamare strumenti quando non servono, che passa da 60 a 78 su BFCL irrelevance. IFBench, con tipi di istruzioni mai visti in addestramento, migliora da 37,3 a 43,7. Su IFEval, GSM8K e BFCL simple i risultati sono pari o quasi. Dove resta indietro è la conoscenza enciclopedica, MMLU-Pro scende da 78,5 a 72,5, e il codice competitivo, LiveCodeBench da 56 a 51.

Per capire se il tono umano è reale, l'autore ha costruito un benchmark chiamato 'ishuman': 150 frammenti di chat non viste, il modello deve scrivere il messaggio successivo e un giudice deve distinguere il messaggio umano da quello generato. Il modello base abliterated viene scelto come umano solo nello 0,3% dei casi; aggiungere un prompt di sistema 'scrivi come una persona' porta al 6,8%. La versione ufficiale non modificata via OpenRouter arriva al 15,1%. La 2.0 sale al 23,5%, ancora sotto la soglia del 50% che segnalerebbe indistinguibilità, ma il distacco mostra che il prompt da solo non basta. In un test separato su 16 chat multi-turno dal vivo con persone inventate, la 2.0 è stata preferita al modello base in tutti i 16 casi.

Questa storia non riguarda solo un esperimento di tono. Mostra un cambiamento nei costi di controllo del comportamento: invece di affidare la personalità a un prompt fragile, si sposta il vincolo nell'addestramento. Per chi valuta deployment self-hosted o on-premise, il punto è concreto: le versioni GGUF pubblicate (IQ4_XS, Q4_K_M, Q5_K_M, Q6_K, Q8_0, BF16) rendono il modello eseguibile su hardware locale con diversi livelli di quantization e VRAM. Non serve un cloud chiuso per ottenere un modello che risponde con un tono preciso e chiama strumenti. Questo abbassa la dipendenza da API esterne e riduce i rischi di deriva stilistica legati a prompt di sistema complessi.

Le implicazioni di secondo ordine sono per i team che costruiscono agenti. La capacità di chiedere chiarimenti invece di inventare parametri è un comportamento da flusso di lavoro, non solo da chat: riduce il rischio di tool call errate e semplifica la supervisione umana. Il rovescio è il calo di conoscenza e di codice competitivo: per usi in cui la precisione fattuale conta, il modello va combinato con retrieval o modelli specializzati. Non è una sostituzione diretta, ma un componente per pipeline che separano tono, ragionamento e accesso ai dati.

Chi vince sono i progetti che hanno bisogno di un'interfaccia conversazionale meno robotica e di agenti locali: assistenza clienti interna, roleplay, automazione di processi su dati sensibili. Chi perde, almeno sul piano simbolico, è l'idea che il comportamento di un LLM si aggiusti con prompt sempre più lunghi: la v1 ignorava le istruzioni, la 2.0 le rispetta perché il vincolo è nel modello. Questo segnala una direzione strutturale: il fine-tuning su comportamento e tool call si sta spostando da esperimento a pratica di prodotto, e i modelli aperti quantizzati diventano il veicolo per distribuire queste varianti senza dipendere da un vendor.

L'autore chiede ancora feedback su dove il modello suoni ancora da assistente. La domanda aperta, per chi osserva il deployment on-premise, è quanto questi comportamenti distillati reggano a quantizzazioni spinte e a contesti più lunghi di quelli usati nei test. Ma la direzione è già scritta: la voce umana non è più un prompt da scrivere, è un artefatto da addestrare.