Gran parte dell’ingegneria dei prompt si concentra sull’accuratezza e sulla copertura delle istruzioni. In produzione, i progressi maggiori derivano dal considerare il dialogo stesso come il principale problema di progettazione.
Definire intenzioni basate su condizioni e azioni insegna al modello come decidere, anziché imporgli un copione dal quale non può uscire. La posizione in un prompt è di per sé un’istruzione. L’identità va all’inizio, le sfumature comportamentali al centro e i vincoli rigidi alla fine; tutto ciò che è davvero essenziale va inserito sia all’inizio sia alla fine.
Scrivere il prompt nella voce desiderata, invece di descriverla, è uno dei cambiamenti di maggior impatto possibili.
Gli agenti più coerenti hanno prompt che trattano i diversi momenti della conversazione come interazioni distinte, ciascuna con una forma appropriata, pur mantenendo sempre una voce riconoscibile.
In alcuni casi, separare gli agenti che pensano da quelli che parlano produce risposte più coerenti e fondate, evitando che il ragionamento interno affiori nelle risposte.
In precedenza abbiamo presentato un nuovo paradigma per la progettazione dei prompt, basato su conoscenze tratte dalla linguistica e dalla psicologia cognitiva. Abbiamo spiegato l’importanza di creare uno spazio del problema chiaro e ben delimitato entro cui l’agente possa operare, e come tale spazio debba includere il meta-compito del dialogo insito nell’IA rivolta ai clienti.
Vediamo ora alcuni modi pratici in cui i nostri prompt hanno iniziato a cambiare mentre cercavamo di applicare questi principi in produzione.
Dopo centinaia di iterazioni dei prompt in sistemi rivolti ai clienti e già operativi, i progressi maggiori non sono derivati dall’aggiunta di istruzioni o esempi, né dal rispetto delle consuete norme dell’ingegneria dei prompt. Sono derivati, invece, dal porre il dialogo al centro del problema.
L’esplorazione e i test continui hanno fatto emergere diverse tecniche efficaci. Modificavamo un prompt e osservavamo dove la conversazione riusciva o falliva, riconducendo gli insuccessi all’efficacia delle indicazioni, alla struttura del prompt e al nostro uso del linguaggio. Il risultato è una serie di schemi ripetibili che cambiano il modo in cui l’agente interpreta il proprio ruolo nella conversazione, decide la mossa successiva e mantiene una voce coerente al variare del contesto.
Quello che segue non è un metodo universale, né pretende che la progettazione dei prompt sia ormai «risolta». È la sintesi in cinque schemi di ciò che ha funzionato in produzione quando l’obiettivo non era soltanto l’accuratezza funzionale, ma un dialogo migliore: risposte coerenti, naturali e abbastanza uniformi da rappresentare un brand.
Esistono molti modi per strutturare un sistema agentico, ma i flussi di lavoro orchestrati con più agenti restano diffusi. Soprattutto in questi sistemi, il miglioramento più costante è derivato dalla separazione tra gli agenti che pensano e quelli che parlano.
L’orchestrazione degli intenti, la classificazione, l’estrazione di conoscenze e l’uso degli strumenti sono tutte operazioni di back office. Le risposte rivolte ai clienti appartengono al front office. Quando lo stesso agente svolge entrambi i compiti nello stesso turno, il ragionamento e la logica interni possono affiorare nelle risposte. Le risposte diventano esitanti, eccessivamente caute o strutturate secondo la logica del processo anziché in base alle esigenze della persona.
Quel singolo vincolo svolge una quantità sorprendente di lavoro. Mantiene le risposte ancorate alla conversazione effettiva, evita di azzerare il contesto e produce qualcosa di più simile a ciò che chiamiamo "fornire il delta". In sostanza, l’agente aggiunge solo la minima novità che permette davvero all’utente di progredire.
Conta anche la scelta del tipo di risposta da fornire. Abbiamo scoperto che chiedere all’agente incaricato di parlare di scegliere il tipo di mossa prima di scrivere — rispondere, chiarire, reindirizzare o prendere tempo — riduce sistematicamente l’errore conversazionale più comune: non una prosa scadente, ma una risposta del tutto sbagliata.
Vale la pena notare che, nelle giuste condizioni, i più recenti modelli di frontiera stanno iniziando a mettere in discussione il presupposto alla base di questo schema. Tuttavia, per vari motivi molti sviluppatori si affidano ancora a modelli più piccoli o meno recenti; in questi contesti consigliamo senz’altro di separare le attività di back office da quelle di front office.
Per i modelli privi di ragionamento, gli esempi few-shot funzionano perché sono concreti, rapidi e ben recepiti dai modelli. Il problema è l’overfitting. Quando si fornisce un esempio, il modello si aggrappa alle parole, al ritmo e alla struttura, continuando a produrre varianti molto simili della stessa risposta anche quando la situazione è cambiata.
Senza volerlo, avete scritto un copione dal quale il modello non riesce a liberarsi.
Le intenzioni di implementazione, o euristiche, sono un’alternativa più solida nel tempo. Anziché mostrare al modello cosa dire in scenari specifici*,*, forniamo una coppia più generale di condizione e azione: se accade X, fai Y.
La differenza fondamentale è che, invece di restringere progressivamente X e Y con un esempio dopo l’altro, rendendoli sempre più rigidi, tracciamo intorno a ciascuno un confine netto mediante un’istruzione tanto precisa da rendere superflui gli esempi. In questo modo l’agente resta sensibile alle reali variazioni della conversazione, anziché cercare corrispondenze con uno schema predefinito.
In pratica, l’approccio assomiglia meno a una serie di esempi e più a regole empiriche eseguibili:
Se manca un dettaglio fondamentale, poni una sola domanda di chiarimento.
Se la risposta non è supportata, dichiaralo apertamente e proponi il miglior passo successivo disponibile.
Se la richiesta incontra un vincolo di sicurezza, rifiutala brevemente e reindirizza l’utente senza formalità.
Non è un approccio affascinante, ma è molto più robusto di una raccolta di risposte campione, perché insegna al modello come decidere anziché cosa ripetere.
La posizione di un elemento nel prompt determina il peso che assume. È uno schema ricorrente che abbiamo osservato in diversi modelli e implementazioni. L’inizio e la fine di un prompt hanno una rilevanza sproporzionata. Al centro si collocano le sfumature, esattamente dove dovrebbero stare.
Strutturiamo i nostri prompt tenendo conto di questo principio. Il ruolo e la percezione di sé dell’agente vanno all’inizio, così da definirne l’identità prima di ogni altra cosa. La parte centrale contiene i dettagli comportamentali: come potrebbe evolversi la conversazione, le euristiche che guidano le risposte e l’insieme delle situazioni che l’agente deve gestire. I vincoli rigidi e gli elementi non negoziabili vanno alla fine, dove rimangono «in primo piano».
Tutto ciò che è davvero essenziale viene inserito in entrambe le posizioni. Una regola specifica sul risultato, per esempio un’istruzione tassativa sulla punteggiatura o sulla formattazione, può facilmente perdersi se compare una sola volta al centro di un prompt molto denso. Se ripetuta alla fine, viene rispettata.
A proposito dell’effetto recenza, vale la pena notare che gli eventuali risultati strutturati costituiscono di fatto l’ultimissima istruzione del prompt. I campi descrittivi dei risultati strutturati incidono qualitativamente sulle risposte, creando un contratto di output più vincolante rispetto al resto del prompt.
Abbiamo imparato a non usare esempi few-shot neppure per il tono di voce, e questo è uno dei cambiamenti di maggior impatto apportati ai nostri agenti rivolti ai clienti.
Scriviamo invece l’intero prompt nella voce desiderata. Non una descrizione della voce, né una serie di aggettivi che vi si avvicinano, ma la voce vera e propria, in una prosa completa, dalla prima all’ultima riga. Il prompt diventa la dimostrazione. Chiamiamo questo approccio «anti-copione»: guidare il modello a imitare l’input, lasciandogli però usare una gamma più ampia di parole ed espressioni che restano nello stesso «campo stilistico» del prompt.
È così che otteniamo varietà all’interno di una voce coerente. Fa parte della nostra strategia per porre il dialogo al centro del compito di qualsiasi agente, senza ricorrere a istruzioni esplicite, che cerchiamo di ridurre al minimo.
Quando usiamo esempi espliciti sul tono di voce, mostrano “cosa non fare”. Per esempio: “Niente trattini lunghi. Mai. Niente cliché. Niente elenchi di policy. Niente spiegazioni eccessive quando basta una sola frase per chiudere il discorso.” I vincoli negativi sono più precisi e meno restrittivi delle aspirazioni positive, perché identificano le modalità di errore verso cui il modello tende più facilmente.
Anche la formattazione conta e determina il tono della risposta. Un prompt pieno di elenchi puntati, titoli e istruzioni tra parentesi orienta il modello verso un risultato più organizzato e distaccato. Se il risultato deve sembrare una conversazione, l’input non dovrebbe avere l’aspetto di una specifica tecnica abbreviata.
La maggior parte dei prompt sul tono finisce per concentrarsi sulla personalità. Si fornisce una serie di aggettivi per descrivere come dovrebbe esprimersi l’agente. Caloroso. Professionale. Cordiale ma conciso. Non sono indicazioni sbagliate, ma ciò che determina davvero come una voce viene percepita nella conversazione è il registro: il modo in cui la stessa personalità si comporta in situazioni sociali diverse.
Un messaggio di attesa durante l’elaborazione di una richiesta non dovrebbe sembrare una risposta definitiva. Una risposta dettata da un vincolo di sicurezza non dovrebbe avere lo stesso tono di una chiacchierata informale. Un cliente frustrato non dovrebbe ricevere la stessa dose di simpatia o umorismo di chi sta curiosando senza fretta.
È questa la differenza tra voce del brand e progettazione conversazionale. La voce del brand descrive spesso una personalità; la progettazione conversazionale stabilisce come si comporta al cambiare delle situazioni. Fare bene questo lavoro significa non essere semplici copywriter che si occupano dei risultati dell’IA. Progettiamo il modo in cui una voce attraversa una conversazione.
Avrete notato che nessuno di questi schemi è tecnicamente complesso. Ed è proprio questo, in parte, il punto. L’architettura di un sistema agentico è importante, ma per ottenere conversazioni di qualità occorre dedicare molto tempo alla progettazione e al perfezionamento dei prompt.
Il divario tra un’IA puramente funzionale e una davvero conversazionale non si colma con la progettazione tecnica, ma comprendendo meglio il funzionamento del linguaggio e dell’attenzione nel dialogo umano e ponendo il dialogo al centro dello spazio del problema degli agenti.
Per i team di prodotto IA, gli ingegneri e i progettisti dell’esperienza, la progettazione conversazionale merita lo stesso rigore dell’eccellenza tecnica nell’IA rivolta ai clienti. Per chi si trova dall’altra parte di queste conversazioni non esistono modelli, collaborazioni multi-agente o chiamate a strumenti: esiste solo un’interazione che funziona oppure no. Un’interazione che crea fiducia oppure la erode.
In fin dei conti, nessuno vive l’architettura. Vive la conversazione.
La conversazione è il prodotto.