Vai al contenuto
Systems Thinking Italia

AI e sistemi8 minuti di lettura

Il prompt perfetto non esiste

Cercare la formula magica è l'intervento più debole. Quel che cambia il risultato è la struttura attorno al prompt: dove vive, chi lo tiene, chi verifica.

Gabriele Pecchioli

Il prompt perfetto non esiste perché il prompt è il pezzo più piccolo del sistema che produce il risultato. Puoi riscrivere la stessa richiesta venti volte e guadagnare qualcosa: un po' di ordine, un formato più comodo. Sposta invece quel prompt in un posto dove vive anche per gli altri, mettigli accanto tre esempi veri, collegalo ai dati di oggi, dai a qualcuno il compito di guardare quello che esce: il risultato cambia di categoria. Nelle aziende dove l'intelligenza artificiale funziona non ho trovato prompt migliori. Ho trovato quattro cose intorno al prompt che nessuno vende in un corso, perché non si scrivono in una riga e non si copiano da uno schermo.

La caccia alla formula

Un possibile punto di partenza è un elenco di richieste accumulate senza un processo condiviso. Una cartella con duecento prompt scaricati, un documento con le frasi che "funzionano", il collega che ha trovato quella giusta e la gira agli altri in chat.

La caccia alla formula è attraente per ragioni serie. Costa poco: nessun progetto, nessuna riunione, nessuna decisione da prendere con qualcuno. È individuale: la provo io, stasera, e domani sono più bravo. Somiglia a una competenza, e quindi dà la sensazione di stare costruendo qualcosa. Qualche volta funziona davvero, la prima volta, e quella volta basta a tenere in piedi la convinzione per mesi.

Poi il prompt smette di funzionare, e il motivo non è mai nelle parole. Il caso è un po' diverso da quello di lunedì. Il listino è cambiato e il modello usa quello che gli hai incollato dentro tre mesi fa. La persona che l'aveva scritto è in ferie e nessun altro sa come era fatto. L'output esce con un errore e parte al cliente, perché non esisteva nessuno a cui toccava guardarlo.

Dove agisce davvero un prompt

linea dell'acqua: sotto, quello che non si vede01 EventiCosa è successo?L'offerta uscita stamattina ha dentro un prezzo delvecchio listino02 PatternÈ già successo?Ogni volta che il caso cambia, chi scrivericomincia la richiesta da zero03 StrutturaCosa lo produce?Il prompt vive in una chat personale,senza esempi accanto, senza nessuno cheguardi l'output prima che esca04 Modelli mentaliQuali convinzioni lo reggono?Qui si crede che il risultatodipenda dalla bravura di chiscrive la richiestasotto: quello che non si vede01 EventiL'offerta uscita stamattina ha dentro un prezzodel vecchio listino02 PatternOgni volta che il caso cambia, chi scrivericomincia la richiesta da zero03 StrutturaIl prompt vive in una chat personale, senzaesempi accanto, senza nessuno che guardil'output prima che esca04 Modelli mentaliQui si crede che il risultato dipenda dallabravura di chi scrive la richiesta
L'iceberg dell'offerta uscita maleIn cima c'è il fatto di stamattina, l'unica cosa che qualcuno ha guardato. Il prompt compare una volta sola, al terzo livello, e non per come è scritto: per dove sta e per cosa non ha accanto.

In cima c'è l'evento, e l'evento è l'unica cosa che qualcuno guarda: stamattina è partita un'offerta con un prezzo sbagliato. Sotto c'è il pattern, che si vede soltanto se tieni il conto per qualche settimana: ogni volta che il caso cambia, chi scrive ricomincia da zero, e quindi ogni offerta nasce da un prompt diverso da quello di prima.

Sotto ancora c'è la struttura, e qui si trovano tre cose contemporaneamente. Il prompt sta nella chat personale di una persona, quindi non esiste per l'azienda. Non ha accanto nessun esempio di offerta buona, quindi il modello deve indovinare lo standard. Nessuno guarda quello che esce con un criterio scritto, quindi gli errori li trova il cliente.

In fondo c'è il modello mentale che tiene insieme tutto: il risultato dipende dalla bravura di chi scrive la richiesta. Finché questa convinzione regge, ogni problema di output produce la stessa reazione, cioè qualcuno che prova a scrivere la richiesta meglio. L'intervento si ripete e non cambia niente, e la cosa viene letta come un limite della tecnologia.

La scala, dal più debole al più forte

01cambiareleparole02aggiungeregliesempi03collegareidati veri04dare unpostoe uncustode05cambiarechiverifica01cambiare leparole02aggiungere gliesempi03collegare idati veri04dare un postoe un custode05cambiare chiverifica
Cinque modi di intervenire sullo stesso risultatoIl primo passo è quello che provano tutti. Quello in rosso aggiunge una fonte concreta a cui confrontare il risultato. L'ultimo è il più forte e il più raro, perché richiede di cambiare chi decide cosa è accettabile.

Cambiare le parole è agire su un parametro. Il guadagno esiste e si esaurisce in fretta: un prompt scritto per intero invece che accennato produce un output migliore di uno scritto a metà, e questo è tutto quello che c'è da guadagnare. Resta nella testa di chi l'ha scritto e non arriva a nessun altro.

Aggiungere gli esempi è la prima mossa che cambia qualcosa per davvero. Tre offerte vere, scelte perché erano buone, incollate nella richiesta con una riga che dice perché erano buone. Il modello smette di indovinare il tuo standard e lo copia. Il miglioramento va verificato su casi reali: gli esempi riducono l’ambiguità, ma possono anche trasmettere errori o criteri ormai superati.

Collegare i dati veri sposta il problema da un altro lato. Il listino di oggi, le condizioni di pagamento che esistono adesso, i codici prodotto che il gestionale conosce: finché quei dati sono incollati a mano, invecchiano in silenzio. Quando arrivano dalla fonte, una categoria intera di errori sparisce e non serve più nessuna attenzione per evitarla.

Dare un posto e un custode è il passo che segno in rosso. Il prompt esce dalla chat personale e va in una cartella condivisa, con una data e un numero di versione. Una persona lo tiene: se qualcuno trova un modo migliore, lo scrive lì; se smette di funzionare, se ne accorge entro la giornata. Qui si cambiano le regole del sistema, e le regole valgono anche per chi arriverà dopo.

Cambiare chi verifica è il passo più forte, e non lo vedo quasi mai. Significa decidere chi guarda l'output prima che esca, con quale criterio scritto, e cosa succede quando l'output è sbagliato. Un'azienda che mette per iscritto "nessuna offerta parte senza che il responsabile commerciale abbia controllato prezzo, tempi e tre righe di condizioni" ha cambiato l'obiettivo del sistema: l'obiettivo diventa produrre quello che è disposta a firmare, e la velocità viene dopo. Tutti gli altri quattro passi diventano più facili da quel momento, perché c'è qualcuno che ha un motivo per farli.

Un prompt, nella scala di Meadows, è un parametro. Sta in fondo. Gli esempi e i dati collegati sono flussi di informazione, che stanno più in alto. Il posto condiviso e il custode sono regole. La verifica è un obiettivo. Questa scala dei cinque passi è una mia lettura applicativa della gerarchia di Meadows, non una graduatoria sperimentale dell’efficacia dei prompt.

Quello che nel prompt conta davvero

Dire che il prompt è il pezzo più debole non vuol dire che sia indifferente. Tre cose dentro la richiesta cambiano l'output in modo visibile, e vale la pena scriverle bene una volta sola.

Il compito scritto per intero. Non "fammi un'offerta per questo cliente", che lascia al modello il compito di indovinare cosa stai vendendo e a chi. Il compito completo dice chi è il cliente, cosa ha chiesto, quali sono i vincoli, cosa deve contenere l'offerta e cosa non deve contenere.

Il formato richiesto. Un elenco, una tabella con queste colonne, quattro paragrafi di questa lunghezza. Chiedere il formato toglie di mezzo metà delle correzioni, perché la maggior parte delle correzioni è rimettere in ordine.

Gli esempi dentro la richiesta. Li ho già messi al secondo passo della scala, e li ripeto qui perché tecnicamente sono parte del prompt: la differenza tra un prompt con tre esempi veri e lo stesso prompt senza è la differenza più grande che si ottiene lavorando sul testo.

Le formule di incoraggiamento e i titoli non sostituiscono dati e criteri di verifica: dichiarare al modello che è un esperto di livello mondiale, chiedergli di ragionare con calma, promettergli una mancia. Qualche volta fanno un effetto, spesso no, e in ogni caso sono la parte su cui le persone passano più tempo.

Una richiesta ben scritta non compensa un processo inutile: prima applica il test su che cosa vale la pena automatizzare. Poi definisci chi controlla quello che il modello scrive. Nel territorio AI e sistemi questi passaggi precedono la scelta della formula.

Una prova di quattro settimane sul processo

Per mettere alla prova questa lettura, si può delimitare un caso d’uso e distribuirne le verifiche in quattro settimane. È una traccia di lavoro, non la descrizione di un incarico o di un risultato già ottenuto.

Settimana uno: scelgo il caso insieme a chi lo fa e raccolgo tre esempi veri di lavoro buono, con il motivo per cui erano buoni. Questa è la parte che richiede più tempo e più discussione, perché spesso l'azienda non ha mai messo per iscritto cosa distingue un'offerta buona da una accettabile.

Settimana due: scrivo il prompt completo con gli esempi dentro, lo metto nella cartella condivisa con data e versione, e scelgo con il titolare chi lo tiene. Il custode deve essere una persona che quel lavoro lo fa, con due ore a settimana scritte nel suo ruolo.

Settimana tre: collego i dati che si possono collegare. A volte è un foglio esportato ogni mattina, a volte una vera connessione al gestionale. Il livello tecnico conta meno del fatto che nessuno li copi più a mano.

Settimana quattro: scriviamo il criterio di verifica, chi controlla, su cosa, e con che frequenza. A campione va benissimo, una su cinque, se la regola è scritta e qualcuno la applica.

Alla fine del mese il prompt che abbiamo in mano non è particolarmente brillante. Funziona il lunedì dopo, funziona con un'altra persona davanti alla tastiera, e funziona quando il listino cambia, ed è tutto quello che gli chiedevo.

Tutte le letture: AI e sistemi

Continua a leggere