Una comune battuta nella community dei Large Language Model (LLM) è quella di chiedere al modello di “non commettere errori”, suggerendo che una semplice istruzione possa migliorare drasticamente il risultato finale. In questo contesto, una regola spesso citata nel prompt engineering è quella di assegnare al modello un ruolo, ad esempio: “Sei un esperto di fisica. Ora rispondi a questa domanda di fisica”. Questo approccio è noto come “persona prompting”.
Che cosa è la persona prompting?
La persona prompting può influenzare lo stile dell'output: chiedere a un LLM di comportarsi come un cavernicolo, ad esempio, riduce la lunghezza e la complessità delle risposte. Tuttavia, è comune assumere che le personas possano anche migliorare l'accuratezza fattuale delle risposte.
Qualche mese fa ho testato la teoria delle personas in un piccolo esperimento condiviso su LinkedIn. Quando i risultati hanno mostrato poco o nessun miglioramento, ho deciso di ampliare il test.
Ricerche esistenti
La letteratura accademica ha già indagato l’effetto delle personas sull'accuratezza fattuale. Nel “Prompting Science Report 4: Playing Pretend” sono stati valutati sei modelli su due benchmark scientifici a scelta multipla, concludendo che le personas esperte hanno avuto poco o nessun effetto, mentre le personas a bassa conoscenza (es. “agire come un bambino”) hanno ridotto l'accuratezza.
Nel lavoro “Scientific Agents: …” Timothy Kassis ha valutato 503 profili professionali AGENTS.md usando Gemini 3.8 flash. Su nove benchmark testuali, l'accuratezza media non ha mostrato miglioramenti statisticamente significativi rispetto al baseline, ma i modelli hanno consumato da 1,5 a 2,3 volte più token di output.
Lo studio “When ‘A Helpful Assistant’ Is Not Really Helpful” ha riportato risultati simili: 162 personas su 2 410 domande non hanno prodotto miglioramenti affidabili nelle prestazioni.
Un altro studio, “Expert Personas Improve LLM Alignment but Damage Accuracy”, ha evidenziato che le personas possono migliorare l’allineamento di sicurezza (aumentando i tassi di rifiuto), ma hanno un effetto neutro o dannoso sull'accuratezza fattuale, a seconda del modello e del posizionamento del prompt.
Infine, “Principled Personas” ha analizzato diverse dimensioni di modello, confermando che le personas esperte non migliorano le prestazioni, eccetto in casi altamente specifici, mentre le personas irrilevanti hanno un impatto negativo significativo.
Implicazioni pratiche
Nell'uso reale, dove i LLM sono impiegati per risolvere problemi concreti, gli ingegneri sono spesso consigliati di includere prompt con persona nei sistemi di produzione. Ancora più preoccupante, le personas sono talvolta incorporate nei prompt di sistema o nei valori di default di harness, così che l'utente finale potrebbe non essere nemmeno consapevole della loro presenza.
Le ricerche mostrano che, dal punto di vista dell'accuratezza, le personas non hanno alcun effetto positivo né negativo. Tuttavia, con l'aumento dell'importanza di costi e velocità nelle applicazioni LLM, è fondamentale chiedersi: come influenzano le personas i costi e la velocità? L'aggiunta di una persona aumenta il costo per risposta o il tempo di risposta?
L'esperimento
Per rispondere a queste domande, ho progettato un esperimento che misura accuratezza, costo e velocità su quattro modelli e cinque condizioni di persona. Ho selezionato casualmente 5 000 domande a scelta multipla da nove ambiti del dataset MMLU‑Pro e ho eseguito ciascun modello con ogni persona.
Le cinque condizioni nel campo del prompt di sistema sono state:
- Neutrale: “Sei un assistente utile. Sei sempre felice di aiutare con qualsiasi domanda l'utente ponga. Cerchi di essere accurato, pensi al problema con attenzione e rispondi in modo chiaro.”
- Baseline (nessun prompt): (campo vuoto)
- Esperto breve: “Sei un esperto.”
- Esperto standard: “Sei un esperto di fisica, chimica, biologia, informatica, ingegneria, matematica, economia, diritto e storia. Hai decenni di esperienza e non commetti errori.”
- Esperto lungo: “Sei un esperto di fisica, chimica, biologia, informatica, ingegneria, matematica, economia, diritto e storia. Hai decenni di esperienza accademica e industriale, hai pubblicato ampiamente e insegni al più alto livello, e non commetti errori. Approccia ogni domanda con la cura e la rigore di uno specialista senior.”
Nel messaggio dell'utente è stata aggiunta l'istruzione: “Rispondi alla seguente domanda a scelta multipla. Rispondi solo con la lettera della risposta corretta, es. ‘A’. Non includere alcuna spiegazione.”
Poiché la risposta valida è un singolo carattere (es. “B”), ho confrontato l'uso di token di ragionamento tra i modelli: più token impiegati indicano più tempo di “pensiero” e quindi maggiori costi.
I modelli provengono da OpenRouter:
- Claude Haiku 5.5 (pensiero xhigh)
- Deepseek V4 Flash 0423 (pensiero xhigh)
- Ling 3.0 Flash (pensiero abilitato)
- GLM 5.3 Flash (pensiero high)
Risultati
In totale sono state eseguite 20 corse (4 modelli × 5 condizioni) su 5 000 domande. Dopo l'esecuzione, ho tracciato accuratezza, costo totale e token di ragionamento rispetto alle personas, oltre a un grafico di accuratezza vs. costo.
Accuratezza
Le figure mostrano che per Claude e GLM l'accuratezza è rimasta stabile indipendentemente dalla persona. Ling ha registrato la migliore accuratezza con la persona neutra, diminuendo con tutte le varianti esperte. Un risultato sorprendente è stato il salto di accuratezza di Deepseek quando era presente qualsiasi prompt di sistema rispetto al baseline senza prompt.
Il grafico “accuratezza vs. costo” evidenzia i migliori rapporti costo‑accuratezza:
- Deepseek neutrale ($0,76, 83,7 %)
- GLM esperto breve ($1,22, 85,1 %)
- Claude esperto ($2,36, 88,0 %)
- Claude baseline ($2,39, 88,4 %)
Uso dei token
Il conteggio dei token di ragionamento è dove emerge la differenza più marcata. Ling e Deepseek hanno aumentato l'uso di token per tutte le varianti esperte, Claude solo per la variante esperta lunga, mentre GLM non ha mostrato variazioni significative.
Per Claude, il prompt esperto lungo ha prodotto un aumento dell'8 % dei token di ragionamento rispetto al neutro, mentre le altre varianti sono rimaste entro l'intervallo di confidenza del 95 %.
| Condizione | Token medi | Token mediani | Aumento medio vs. neutro | 95 % CI |
|---|---|---|---|---|
| neutro | 899 | 265 | - | - |
| baseline | 882 | 260 | -2 % | [-7 %, +4 %] |
| esperto_breve | 934 | 278 | +4 % | [-1 %, +9 %] |
| esperto | 863 | 258 | -4 % | [-9 %, +1 %] |
| esperto_lungo | 970 | 277 | +8 % | [+3 %, +13 %] |
Deepseek ha mostrato un aumento significativo dei token di ragionamento anche nella condizione baseline (44 % in più), con incrementi minori ma comunque presenti per le varianti esperte (5‑9 %).
| Condizione | Token medi | Token mediani | Aumento medio vs. neutro | 95 % CI |
|---|---|---|---|---|
| neutro | 4901 | 854 | - | - |
| baseline | 7047 | 1198 | +44 % | [+40 %, +48 %] |
| esperto_breve | 5162 | 910 | +5 % | [+2 %, +8 %] |
| esperto | 5080 | 900 | +4 % | [+1 %, +7 %] |
| esperto_lungo | 5343 | 948 | +9 % | [+6 %, +12 %] |
Ling ha registrato aumenti del 12 %, 23 %, 36 % e 33 % per le quattro condizioni rispetto al prompt neutro.
Interpretazione e consigli
Le evidenze sperimentali indicano chiaramente che le personas, specialmente quelle “esperte” e lunghe, non migliorano l'accuratezza e aumentano il consumo di token di ragionamento. Questo si traduce in costi più alti e tempi di risposta più lunghi, senza benefici tangibili.
Per gli sviluppatori di applicazioni LLM, le raccomandazioni sono:
- Rimuovere le personas inutili dai prompt di sistema, soprattutto se non sono strettamente necessarie per il tono o lo stile.
- Preferire prompt neutri quando la priorità è la rapidità e l'efficienza economica.
- Valutare caso per caso l'uso di personas altamente specifiche solo se vi è una comprovata necessità di allineamento di sicurezza o di contesto.
- Monitorare i token di ragionamento nei log di produzione per identificare eventuali aumenti anomali legati a prompt più lunghi.
In conclusione, sebbene la persona prompting possa sembrare una buona pratica per “personalizzare” l’interazione, nella pratica reale può introdurre inefficienze di costo e velocità senza migliorare le prestazioni fattuali. Gli ingegneri dovrebbero quindi valutare attentamente la necessità di queste aggiunte prima di adottarle nei sistemi in produzione.