«Agisci come un esperto di sistemi distribuiti» può precedere una raccomandazione sensata, una risposta inutilmente complicata o un errore spiegato benissimo. Se devo decidere come usare una cache, mi interessa sapere cosa succede quando un aggiornamento si perde. Il vocabolario da architetto viene dopo.
Il ruolo può orientare tono, prospettiva e aspetti del problema a cui dare attenzione. Per capire quanto aiuti, però, bisogna separarlo dalle informazioni e dai criteri che aggiungiamo insieme. È il punto che voglio mettere a fuoco con un caso concreto e quattro prompt confrontabili.
Che cosa stiamo chiedendo con «comportati come»
Una persona nel prompt è una descrizione del punto di vista da adottare: revisore, insegnante, responsabile operativo, esperto di database. Può essere una scorciatoia utile. «Spiega il piano a un responsabile che deve approvare la manutenzione» dice qualcosa sul destinatario e sulla decisione da sostenere.
«Sei il miglior esperto mondiale», invece, lascia aperto quasi tutto: quale problema risolvere, quali dati usare, quali compromessi accettare. Aumentare il prestigio del personaggio aggiunge poco alla specifica.
La documentazione di Claude presenta il ruolo come un modo per concentrare comportamento e tono. La stessa guida raccomanda di esplicitare il contesto e il risultato atteso. Sono leve che conviene distinguere quando si valuta un prompt. Guida al prompting di Claude.
Il valore del ruolo dipende anche dal compito. Per spiegare una migrazione a un consiglio di amministrazione può aiutare a scegliere il registro. Per stabilire se una strategia di cache rispetti un vincolo temporale, il giudizio deve arrivare fino ai casi che possono violarlo.
Token e spazio vettoriale, senza una «zona degli esperti»
Il testo viene suddiviso in token: unità che possono corrispondere a parole, parti di parola o altri segmenti. La suddivisione dipende dal tokenizer; la stessa frase non ha necessariamente lo stesso numero di token in modelli diversi. Documentazione Hugging Face sulla tokenizzazione.
Un embedding associa a un token un vettore, cioè una sequenza di numeri che identifica un punto in uno spazio matematico. Nel Transformer queste rappresentazioni vengono elaborate tenendo conto del contesto attraverso l’attenzione. Le rappresentazioni risultanti contribuiscono alle probabilità dei token successivi. Aggiungere un ruolo cambia quindi l’input su cui si costruisce la risposta. Attention Is All You Need, sezioni 3.2 e 3.4.
La metafora «il prompt sposta il modello nella zona degli esperti» è troppo concreta per ciò che sappiamo. Suggerisce un reparto di competenze che basta raggiungere con la parola giusta. Le fonti citate non forniscono una mappa delle rappresentazioni interne di Claude o ChatGPT, né una misura che colleghi una distanza in quello spazio all’accuratezza.
Per il nostro scopo basta un’idea più utile: le parole con cui impostiamo il compito cambiano le condizioni della generazione. Una risposta più specialistica resta da giudicare sul problema.
Il ruolo nel testo e il ruolo del messaggio
La parola ruolo indica anche un elemento diverso nelle API: chi invia un messaggio e quale priorità hanno le sue istruzioni.
Nelle API OpenAI, un messaggio developer ha precedenza su uno user. Nell’API Messages di Claude è documentato il parametro system per le istruzioni di sistema. Queste sono proprietà della richiesta. La frase «agisci come un esperto» è invece il contenuto di un’istruzione. Scrivere «SYSTEM:» in una normale casella di chat non equivale a impostare quei metadati. OpenAI: ruoli dei messaggi, Claude: Messages API.
Anche la personalizzazione del prodotto va tenuta distinta. ChatGPT descrive le proprie personalità in termini di stile e tono, senza attribuire loro nuove capacità. Personalizzazione di ChatGPT.
Quando si confrontano due prompt, conviene tenerli nello stesso tipo di messaggio: spostare uno nel sistema e lasciare l’altro come richiesta utente cambierebbe anche la priorità.
Perché si trovano risposte opposte sull’efficacia dei ruoli
Lo studio di Zheng e colleghi presentato a EMNLP 2024 non rileva un miglioramento sistematico aggiungendo descrizioni di ruolo ai prompt su quesiti fattuali. Fra i modelli esaminati ci sono FLAN-T5, Llama 3, Mistral e Qwen 2.5: non è una prova sui prodotti attuali di Claude e ChatGPT. Studio EMNLP.
Un preprint del 2026 su risposte professionali aperte riporta invece differenze fra profondità specialistica e chiarezza. Usa domande sintetiche e un valutatore LLM: il suo risultato riguarda quel metodo di valutazione. Xiao e colleghi, Persona Prompting.
Chiedere la risposta corretta a una domanda fattuale e preferire una spiegazione più ricca sono obiettivi diversi. Se non scegliamo la proprietà da migliorare, due valutazioni possono sembrare in conflitto pur misurando cose differenti.
C’è poi un errore più semplice. Confrontiamo «agisci come un esperto» con un nuovo prompt che contiene anche il problema, gli errori da evitare e il formato atteso. Se il secondo funziona meglio, abbiamo cambiato troppe cose per assegnare il merito.
La demo ufficiale Prompting 101 di Anthropic è utile proprio da leggere in questo modo: l’esempio viene arricchito progressivamente con ruolo, contesto e indicazioni operative. Mostra come sviluppare una richiesta; per isolare l’effetto del ruolo occorre un confronto diverso.
Un caso: quando il prezzo in cache può restare vecchio
Prendiamo un catalogo con prezzi conservati in un database. La cache tiene una copia per servire le pagine; il checkout rilegge il prezzo dal database. Il requisito del catalogo ammette un ritardo massimo di 30 secondi dopo una modifica.
Un TTL è il tempo oltre il quale una voce della cache scade. Gli eventi di modifica potrebbero invalidarla prima, ma nel caso che stiamo esaminando possono arrivare tardi o perdersi. Anche una lettura del database può impiegare tempo o fallire.
Qui una frase come «usa invalidazione a eventi con TTL di 30 secondi» suona ragionevole. C’è però una sequenza da considerare:
- Al secondo 0 una lettura acquisisce il prezzo vecchio.
- Al secondo 1 il database registra il prezzo nuovo.
- Al secondo 5 la prima lettura termina e salva il vecchio prezzo in cache con TTL di 30 secondi.
- Se l’evento si perde, quella copia può restare disponibile fino al secondo 35.
Sono 34 secondi dalla modifica. Il TTL ha rispettato la propria durata; la strategia ha superato il limite richiesto.
Questo è il passaggio su cui voglio giudicare la risposta. Deve accorgersi che conta anche l’età del valore quando entra in cache. Potrà proporre versioni, controlli sulle letture concorrenti o una scadenza legata alla validità del dato, ma dovrà spiegare quale sequenza impediscono. In assenza di una soluzione dimostrata, deve indicare il punto ancora irrisolto.
C’è anche una decisione di prodotto: con cache scaduta e database indisponibile, il prezzo potrebbe essere ancora corretto, ma senza un’altra verifica non possiamo garantirne la freschezza. Per conservare il limite richiesto si può rinunciare temporaneamente a mostrarlo. Mostrarlo comunque significa accettare il rischio di superare quei 30 secondi.
La sequenza temporale ci dà un controllo prima di leggere una risposta del modello. È lo stesso criterio discusso nella verifica degli agenti: la prova deve riguardare la conclusione che ci interessa.
Quattro prompt per separare ruolo e criteri
La proposta seguente è un protocollo da eseguire sul proprio modello, non un confronto già misurato. Il compito e i fatti restano identici. Vario soltanto la frase di ruolo e la presenza dei criteri.
| Variante | Persona | Criteri espliciti |
|---|---|---|
| A | Assente | Assenti |
| B | Esperto di sistemi distribuiti | Assenti |
| C | Assente | Presenti |
| D | Esperto di sistemi distribuiti | Presenti |
A — Il compito
Choose a caching strategy for the prices in a product catalog.
The database is the authoritative source. A catalog price may remain stale
for at most 30 seconds after a change in the database. At checkout,
the price is read from the database again. The cache supports a TTL.
Change events may be delayed or lost.
A database read may be slow or fail.
No traffic, latency or update-frequency measurements are available.
Propose a strategy and explain your choice in no more than 250 words.B — Lo stesso compito, con un ruolo
Act as an expert in distributed systems.
Choose a caching strategy for the prices in a product catalog.
The database is the authoritative source. A catalog price may remain stale
for at most 30 seconds after a change in the database. At checkout,
the price is read from the database again. The cache supports a TTL.
Change events may be delayed or lost.
A database read may be slow or fail.
No traffic, latency or update-frequency measurements are available.
Propose a strategy and explain your choice in no more than 250 words.C — Il compito e i criteri
Choose a caching strategy for the prices in a product catalog.
The database is the authoritative source. A catalog price may remain stale
for at most 30 seconds after a change in the database. At checkout,
the price is read from the database again. The cache supports a TTL.
Change events may be delayed or lost.
A database read may be slow or fail.
No traffic, latency or update-frequency measurements are available.
Propose a strategy and explain your choice in no more than 250 words.
Evaluation criteria:
- Explain what happens when a change event is lost.
- Consider whether a read started before a change can populate
the cache after that change and exceed the 30-second limit.
- Define what to display when the cache has expired and the database is unavailable.
- Separate properties established by the requirements from assumptions to check.D — Il compito, i criteri e il ruolo
Act as an expert in distributed systems.
Choose a caching strategy for the prices in a product catalog.
The database is the authoritative source. A catalog price may remain stale
for at most 30 seconds after a change in the database. At checkout,
the price is read from the database again. The cache supports a TTL.
Change events may be delayed or lost.
A database read may be slow or fail.
No traffic, latency or update-frequency measurements are available.
Propose a strategy and explain your choice in no more than 250 words.
Evaluation criteria:
- Explain what happens when a change event is lost.
- Consider whether a read started before a change can populate
the cache after that change and exceed the 30-second limit.
- Define what to display when the cache has expired and the database is unavailable.
- Separate properties established by the requirements from assumptions to check.I criteri richiamano problemi già ricavabili dai fatti. Rendono visibile al modello come valuteremo la proposta; questa è esattamente la variabile che vogliamo osservare.
Come leggere il risultato
Prima delle esecuzioni, fisso i controlli. Per ogni vincolo distinguo tre esiti: soddisfatto, irrisolto, violato. La strategia deve gestire l’evento perso e impedire la sequenza della lettura in ritardo. Riconoscere un problema ancora aperto vale come irrisolto: è meglio di una promessa falsa, ma la proposta resta incompleta. Sul guasto del database deve esplicitare la scelta fra indisponibilità e un prezzo di cui non può garantire la freschezza.
Poi guardo se inventa caratteristiche del sistema, volumi o prestazioni, e se un collega riesce a seguire la decisione. Tengo questi giudizi separati: un testo limpido può proporre una strategia sbagliata; uno corretto può essere faticoso da usare.
Per partire, si possono fare tre esecuzioni indipendenti per variante, dodici in totale, usando conversazioni nuove e mescolando l’ordine. È una prima ricognizione, abbastanza piccola da ispezionare ogni risposta. Se le differenze sono incerte, serve ampliare il campione prima di scegliere una formula standard.
Registro modello e versione disponibili, data, interfaccia, impostazioni e istruzioni aggiuntive. Tengo costanti strumenti, posizione del messaggio e personalizzazioni. Un test dentro l’app valuta anche quel contesto; per un confronto controllato tramite API registro la richiesta completa.
Le risposte vanno mostrate a chi le valuta senza etichette A, B, C, D, per quanto possibile. La tabella di lavoro può avere queste colonne:
run | variante | evento perso | lettura tardiva | fonte indisponibile
| assunzioni non supportate | chiarezza | passaggio che motiva il giudizioConfrontando A con B osservo che cosa aggiunge il ruolo al compito di base. Confrontando C con D osservo se aggiunge qualcosa anche dopo aver esplicitato i criteri. A contro D, da solo, direbbe soltanto che il pacchetto complessivo ha avuto un effetto.
È questo il confronto che userei per decidere se conservare «comportati come un esperto» in un prompt di lavoro. Se aiuta il destinatario a capire, ha già una funzione precisa. Se voglio affidargli una decisione tecnica, gli chiedo anche di superare il caso che potrebbe smentirla.