Skip to main content
Torna al blog

Costruire in Pubblico

Ho Testato 3 Modelli AI nello Scrivere con la Voce di un Brand. Il Modello Contava Poco.

Un confronto vero: Claude, DeepSeek e GLM che scrivono con la voce di un brand, valutati da un giudice alla cieca. La sorpresa non è stato il modello vincente, ma che a contare di più era l'idraulica intorno.

Dani Pralea 5 min di lettura

Illustrazione hero che mostra il concetto di un'AI che impara la voce di scrittura di una persona - un imbuto di post social che confluiscono in un profilo vocale

Prima il setup, perché è lì che le cose sono andate di traverso. Ho preso il prompt esatto dietro la demo di brand voice della nostra landing page, quella che legge qualcuno dei tuoi post e ne scrive uno nuovo con la tua voce, e l'ho fatto girare su tre modelli: Sonnet 4.6 di Claude (quello che usiamo in produzione), DeepSeek e GLM. Sei campioni di voce diversi, ognuno due volte, ogni output anonimizzato valutato da un giudice alla cieca. La domanda aveva soldi veri dietro: un modello più economico poteva fare questo lavoro bene quanto Sonnet, o meglio?

L'ho eseguito in tre modi, e i tre giri si sono contraddetti così completamente che "quale modello" si è rivelata la domanda sbagliata. Giro per giro.

Giro 1: cambia la stringa del modello

Questo è il test che la maggior parte delle persone fa davvero. Stesse impostazioni della produzione, solo un nome di modello diverso.

ModelloJSON validoLatenzaCosto/gen
Sonnet 4.612/127,9s0,0079 $
DeepSeek4/1222,7s0,0013 $
GLM0/1226,7s0,0041 $

GLM ha prodotto zero output utilizzabili. DeepSeek ne ha prodotti quattro. Non perché siano modelli scadenti, ma perché entrambi sono reasoning-first: con il budget di token della produzione ragionano ad alta voce ("1. Analizziamo i post...") e finiscono lo spazio prima di emettere il JSON che la pagina richiede. Lo scambio ingenuo non ti consegna una demo peggiore. Te ne consegna una rotta. Se avessi deciso di fare un controllo a campione su due output, l'avrei scoperto da lì invece che dagli utenti.

Giro 2: dai loro spazio

Stessi modelli, ma con la modalità JSON attiva e un budget di token più ampio, così i modelli di ragionamento possono finire il loro pensiero.

ModelloJSON validoLatenzaVoto del giudice
Sonnet 4.612/127,7s3,37
DeepSeek11/1243s4,33
GLM12/1244s4,73

Il quadro si ribalta. Con lo spazio per finire, entrambi gli sfidanti emettono JSON valido, e il giudice valuta la loro aderenza alla voce pari o superiore a Sonnet. Quindi i modelli in sé non sono mai stati il problema; lo era il primo test. Ma guarda la latenza. Più di quaranta secondi. Nessuno aspetta 44 secondi per una demo su una landing page. Output ottimo, funzionalità inutilizzabile.

Giro 3: la versione che spediresti davvero

Modalità JSON attiva, ragionamento disattivato, DeepSeek sul suo endpoint veloce.

ModelloJSON validoLatenzaCosto/genVoto del giudice
Sonnet 4.612/128,7s0,0079 $3,17
DeepSeek (veloce)12/122,8s0,00019 $4,10
GLM (no-think)12/129,0s0,0017 $4,77

Con l'idraulica giusta, entrambi diventano davvero validi. L'endpoint veloce di DeepSeek è tornato in 2,8 secondi, più rapido di Sonnet, a circa un cinquantesimo del costo, con JSON valido ogni singola volta. GLM ha eguagliato la velocità di Sonnet a un quinto del costo e ha preso il voto più alto del giudice. I campioni confermavano i numeri. GLM ha azzeccato la chiusura di un creator ("currently romanticizing my overpriced matcha, and I will not be taking questions"), e i campioni bilingue sono tornati correttamente in italiano su tutti e tre i modelli.

Cosa ho imparato davvero

Il modello era la variabile meno interessante. Gli stessi tre modelli sono passati da rotti a migliori dell'incumbent senza cambiare il modello affatto, solo l'idraulica intorno. Il budget di token, la modalità JSON, e se il ragionamento era attivo o disattivato hanno contato più di quale laboratorio avesse addestrato la cosa. Tutto l'esercizio è stato un promemoria che "passa semplicemente al modello più economico" è una frase che nasconde tutta l'ingegneria vera.

Un'avvertenza, perché nemmeno il giudice era perfetto. Ha colto correttamente che Sonnet avvolge il suo JSON dentro fence markdown, cosa reale e il motivo per cui in produzione c'è uno strip dei fence. Ma ha anche allucinato violazioni con em dash in output che contenevano zero em dash. Quindi mi fido più dei campioni guardati a occhio che dei voti decimali esatti. La direzione è solida; la terza cifra decimale no.

La decisione pratica? Per questa singola demo la spesa è minima, quindi Sonnet resta il default sicuro e l'endpoint veloce di DeepSeek è l'upgrade a cui guarderei per primo. Comunque i veri risparmi non sono qui. Sono nelle funzionalità ad alto volume che girano migliaia di volte al giorno, dove 50 volte più economico smette di essere un errore di arrotondamento. Quello è il test che vale la pena fare dopo.

Se prendi una cosa da tutto questo: prima di cambiare un modello per risparmiare, falla girare nell'idraulica esatta in cui vivrà. Il modello che pensi di testare non è quello che ricevono i tuoi utenti.

Dani Pralea

Condivido aggiornamenti, vittorie e fallimenti su X. Se questo post ti ha colpito, vieni a salutare.