In questo articolo si cerca di considerare il prompt engineering come nuova skill ibrida, con l\u2019obiettivo di interpretarlo come disciplina di progettazione dell\u2019interazione con modelli linguistici generativi. Viene mostrato come l\u2019efficacia di un chatbot non dipenda solo dal modello, ma anche dalla qualit\u00e0 dell\u2019input: contesto, obiettivi, vincoli e forma dell\u2019output. Vengono discussi i vincoli tecnici (token e finestra di contesto), i fondamenti comunicativi (ambiguit\u00e0, frame, tone of voice), e proposti i principali framework operativi: G.O.L. e la sua estensione G.O.L.D., tecniche avanzate di prompting (Chain-of-Thought e Tree-of-Thoughts) e il metodo SO.C.RA.T.E. per interazioni iterative basate su domande a turni. L\u2019articolo integra inoltre considerazioni su policy e privacy e una riflessione prospettica sull\u2019evoluzione verso agenti e automazioni che potrebbero ridurre il peso del prompt manuale, lasciando centrale la capacit\u00e0 di formulare correttamente i problemi.<\/p>\n\n\n\n
Negli ultimi anni i modelli linguistici generativi (Large Language Models, LLM) hanno trasformato il modo in cui utente e macchina interagiscono. Se le interfacce tradizionali richiedevano comandi formali (sintassi, menu, parametri), l\u2019interazione con un chatbot \u00e8 mediata da linguaggio naturale. Questa \u201cnaturalit\u00e0\u201d \u00e8 per\u00f2 ingannevole: l\u2019output non \u00e8 il risultato di una comprensione semantica umana, ma di una generazione probabilistica condizionata dall\u2019input e dal contesto.<\/p>\n\n\n\n
Dobbiamo capire come interagire al meglio con quei modelli e quindi incominciare a parlare di prompt engineering.<\/p>\n\n\n\n
Da qui una nuova prospettiva: il prompt non \u00e8 una semplice domanda, ma una specifica progettuale che definisce ruolo, obiettivi, vincoli e formato della risposta. Il prompt engineering deve essere quindi considerato come una competenza ibrida tra tecnica e comunicazione: richiede rigore nella definizione dei requisiti e sensibilit\u00e0 linguistica nella gestione di ambiguit\u00e0, tono e aspettative dell\u2019utente.<\/p>\n\n\n\n
Per inquadrare il prompt engineering \u00e8 utile chiarire, in modo non eccessivamente matematico, come operano i modelli linguistici. Un LLM riceve in input una sequenza di simboli e produce in output una sequenza di simboli, stimando quali token siano pi\u00f9 probabili dato il contesto. <\/p>\n\n\n\n
Attenzione per\u00f2: l\u2019idea che il modello generi testo \u201cplausibile\u201d perch\u00e9 addestrato su grandi quantit\u00e0 di contenuti digitali pu\u00f2 creare l\u2019illusione di un\u2019interlocuzione umana, ma non garantisce accuratezza.<\/p>\n\n\n\n
Dal punto di vista operativo, questo comporta due conseguenze. Primo: il chatbot pu\u00f2 essere estremamente utile in compiti di scrittura, sintesi, brainstorming e supporto decisionale, ma necessita di controlli e verifiche. Secondo: la forma dell\u2019input guida in modo determinante la forma dell\u2019output; di fatto, il prompt \u00e8 l\u2019API del modello.<\/p>\n\n\n\n
Da qui la proposta di leggere il prompt engineering come nuova skill \u201cibrida\u201d, collocata tra hard skill (conoscenza di vincoli e strumenti) e soft skill (capacit\u00e0 comunicativa, chiarezza espositiva, empatia verso il lettore\/utente).<\/p>\n\n\n\n
Uno dei concetti pi\u00f9 tecnici da introdurre \u00e8 la tokenizzazione, ovvero \u00abl\u2019unit\u00e0 di base di elaborazione in un modello di linguaggio\u00bb, che pu\u00f2 corrispondere a parola, sotto-parola o carattere.<\/p>\n\n\n\n
Il limite di token gestibili in una singola conversazione (finestra di contesto) impone vincoli pratici: un prompt troppo lungo pu\u00f2 saturare il contesto, riducendo spazio per la risposta o causando la perdita di informazioni precedenti. Il problema si amplifica quando l\u2019utente incolla documenti lunghi, log o report: in questi casi si dovrebbe ricorrere a strumenti di \u201csplitting<\/em>\u201d del testo per suddividere l\u2019input in segmenti gestibili.<\/p>\n\n\n\n Dal punto di vista ingegneristico, la finestra di contesto pu\u00f2 essere trattata come risorsa limitata. Ne deriva un principio di progettazione: la parte pi\u00f9 \u201ccostosa<\/em>\u201d del prompt \u00e8 il contenuto ridondante o poco pertinente; la parte pi\u00f9 \u201ceconomica<\/em>\u201d \u00e8 la strutturazione che riduce ambiguit\u00e0 (titoli, sezioni, liste, schemi, formati).<\/p>\n\n\n\n Un buon prompt, quindi, non \u00e8 necessariamente un prompt \u201clungo<\/em>\u201d: \u00e8 un prompt informativo, ben organizzato e orientato al compito. Questo punto, spesso trascurato in guide superficiali, \u00e8 centrale per un uso professionale dei LLM.<\/p>\n\n\n\n Proviamo a collegare il concetto di contesto alla teoria dei frame. In sociologia, i frame sono \u00abcornici\u00bb, cio\u00e8 schemi interpretativi che aiutano a dare senso alle situazioni sociali; richiamiamo questo impianto per spiegare come il prompt \u201cincornici<\/em>\u201d l\u2019output. Nel prompting la scelta di parole e impostazione del compito attiva frame diversi: chiedere \u201cun\u2019analisi tecnica<\/em>\u201d produce un output differente rispetto a chiedere \u201cuna narrazione creativa<\/em>\u201d; allo stesso modo, definire il target (ad esempio \u201cspiega come a un bambino di dieci anni<\/em>\u201d) condiziona tono, lessico e struttura.<\/p>\n\n\n\n Da qui si pu\u00f2 derivare un modello pragmatico, il prompt deve dichiarare:<\/p>\n\n\n\n In assenza di questi elementi il modello colma i vuoti con assunzioni implicite, aumentando la probabilit\u00e0 di mismatch tra aspettativa dell\u2019utente e output generato.<\/p>\n\n\n\n Nel contesto universitario e professionale, la gestione dei frame \u00e8 anche gestione del rischio: un chatbot che adotta un frame eccessivamente assertivo o \u201cautoritativo<\/em>\u201d pu\u00f2 indurre l\u2019utente a fidarsi di contenuti non verificati. Per questo l\u2019elaborazione di prompt deve includere strategie di mitigazione: richiesta esplicita di incertezze, richiesta di ipotesi e limiti, richiesta di verifiche incrociate quando possibile.<\/p>\n<\/div><\/div>\n\n\n\n Un contributo pratico \u00e8 la formalizzazione di un metodo mnemonico per scrivere prompt: G.O.L.<\/strong> ovvero \u00abper creare un buon prompt occorre avere in mente uno schema\u00bb.<\/p>\n\n\n\n Il metodo G.O.L. si articola in tre fasi:<\/p>\n\n\n\n 1) Guidare<\/strong>: assegnare un ruolo al modello (role prompting), ad esempio \u201cagisci come un consulente\u201d, \u201ccome un docente\u201d, \u201ccome un revisore\u201d, ovvero \u00abbisogna dirgli chi deve essere\u00bb (come un attore), cos\u00ec da attivare conoscenze pertinenti all\u2019ambito.<\/p>\n\n\n\n 2) Obiettivi<\/strong>: esplicitare cosa si desidera ottenere, includendo output atteso, target e criteri. Nel prompting, gli obiettivi non vanno confusi con la domanda: la domanda \u00e8 una forma superficiale, l\u2019obiettivo \u00e8 la specifica funzionale.<\/p>\n\n\n\n 3) Limiti e layout<\/strong>: definire vincoli (lunghezza, ci\u00f2 che va escluso, stile, livello di dettaglio) e, soprattutto, la struttura dell\u2019output (tabella, checklist, sezione con esempi, ecc.).<\/p>\n\n\n\n In prospettiva informatica, G.O.L. pu\u00f2 essere interpretato come un pattern di specifica: la parte \u201cG\u201d definisce il contesto di esecuzione, la parte \u201cO\u201d definisce i requisiti funzionali, la parte \u201cL\u201d definisce requisiti non funzionali e formato di output.<\/p>\n\n\n\n E\u2019 possibile poi estendere G.O.L. nella variante G.O.L.D., aggiungendo una \u201cD\u201d di ulteriori dettagli che rendono il prompt pi\u00f9 robusto e controllabile.<\/p>\n\n\n\n E\u2019 importante sottolineare inoltre un tema fondamentale: la comunicazione con un LLM beneficia degli esempi. Nel lessico tecnico, questo si traduce in zero-shot<\/em>, one-shot<\/em> e few-shot prompting<\/em>. In un prompt zero-shot<\/em> il modello lavora senza esempi; in un prompt one-shot<\/em> si fornisce un esempio di riferimento; nel few-shot<\/em> si forniscono pi\u00f9 esempi per indurre un pattern.<\/p>\n\n\n\n Dal punto di vista applicativo, gli esempi svolgono funzioni diverse:<\/p>\n\n\n\n Nel contesto professionale, la \u2018D\u2019 pu\u00f2 includere: definizioni operative, criteri di valutazione, dataset di esempio, vincoli sul vocabolario, terminologia e acronimi ammessi, nonch\u00e9 un \u2018negative prompting\u2019 (cosa non fare).<\/p>\n\n\n\n Un altro aspetto che va considerato \u00e8 il reverse prompt engineering<\/em>: risalire al prompt che potrebbe aver generato un testo desiderato, cos\u00ec da replicare lo stile e standardizzare output futuri.<\/p>\n\n\n\n Il reverse prompt engineering<\/strong> \u00e8 una tecnica avanzata che consente di generare prompt di alta qualit\u00e0 per finalit\u00e0 quali la scrittura, la ricerca, l\u2019apprendimento o la creativit\u00e0.<\/p>\n\n\n\n Ecco come funziona e come viene applicata:<\/p>\n\n\n\n Esempi pratici di applicazione:<\/strong><\/p>\n\n\n\n In sintesi, questa tecnica trasforma l\u2019IA in uno strumento capace di decodificare il \u201cDNA\u201d di un testo<\/strong> per trasformarlo in un\u2019istruzione operativa riutilizzabile.<\/p>\n\n\n\n I \u201cmodificatori di tono\u201d come strumento per rendere gli scambi pi\u00f9 naturali ed efficaci, adattandoli a contesti e pubblici diversi.<\/p>\n\n\n\n Nel contesto del prompt engineering<\/em>, la definizione del tone of voice<\/strong> (tono di voce) e dei requisiti non funzionali<\/strong> (come formato, limiti e stile) \u00e8 essenziale per trasformare un output generico in un risultato professionale e mirato.<\/p>\n\n\n\n Il tono di voce non riguarda cosa<\/em> l\u2019IA dice, ma come<\/em> lo dice. Si identificano diverse tecniche per modulare questo aspetto:<\/p>\n\n\n\n Questi requisiti definiscono i vincoli tecnici e strutturali che l\u2019IA deve rispettare, sintetizzati principalmente nella \u201cL\u201d del metodo G.O.L. (Limiti e Layout)<\/strong>.<\/p>\n\n\n\n Limiti e vincoli<\/strong><\/p>\n\n\n\n Layout e format (forma dell\u2019output)<\/strong><\/p>\n\n\n\n ChatGPT pu\u00f2 gestire una vasta gamma di formati oltre al semplice testo:<\/p>\n\n\n\n Per evitare il fenomeno \u201cgarbage in, garbage out\u201d (input scadente, output scadente), i requisiti devono essere descrittivi e dettagliati<\/strong>. Un errore comune \u00e8 la mancanza di specificit\u00e0: invece di un vago \u201cdisegna un paesaggio\u201d, un prompt efficace descrive l\u2019ora del giorno, le condizioni atmosferiche e lo stile desiderato.<\/p>\n\n\n\n Infine, l\u2019uso di esempi (one-shot o few-shot prompting)<\/strong> all\u2019interno del metodo G.O.L.D.<\/strong> permette di mostrare all\u2019IA esattamente lo schema o lo stile da seguire, garantendo che l\u2019output rispetti i requisiti non funzionali desiderati.<\/p>\n\n\n\n Il tone of voice \u00e8 un controllo pragmatico, quindi: non cambia solo la \u2018forma\u2019 del testo, ma anche la selezione delle informazioni, la loro priorit\u00e0 e la modalit\u00e0 argomentativa. Un output \u201cautorevole\u201d tende a usare definizioni e assertivit\u00e0; un output \u201cempatico\u201d tende a riconoscere emozioni e proporre azioni di supporto; un output \u201curgente e concreto\u201d privilegia passi operativi e call-to-action.<\/p>\n\n\n\n Dal punto di vista della progettazione, conviene trattare il tone of voice come requisito non funzionale al pari di performance o usabilit\u00e0 in un sistema software: non \u00e8 \u2018decorazione\u2019, ma condizione di accettazione dell\u2019output. In un contesto educativo, per esempio, il tono deve sostenere comprensione, scaffolding e gradualit\u00e0; in un contesto di incident response deve privilegiare chiarezza, priorit\u00e0 e risk awareness.<\/p>\n\n\n\n Il rischio principale \u00e8 l\u2019overfitting stilistico: un tono troppo marcato pu\u00f2 introdurre bias (ad esempio semplificazioni eccessive o eccesso di confidenza). Per mitigare, si pu\u00f2 chiedere al modello di separare il contenuto fattuale dal registro (es. \u2018prima i fatti in punti, poi la spiegazione in tono X\u2019).<\/p>\n\n\n\n Quando il compito richiede ragionamento multi-step, si potrebbe introdurre la tecnica Chain-of-Thought (CoT)<\/strong>, citando Wei et al. (2022): chiedere (o indurre) passaggi intermedi migliora la capacit\u00e0 di problem solving e riduce errori in compiti complessi.<\/p>\n\n\n\n L\u2019idea pu\u00f2 essere letta come \u201cdecomposizione del problema\u201d: si suddivide il task in sotto-problemi, ottenendo un output intermedio che rende il percorso pi\u00f9 controllabile e debuggabile, in modo simile a come si progettano funzioni e moduli in un software.<\/p>\n\n\n\n Oppure quella del Tree-of-Thoughts (ToT)<\/strong>, citando Yao et al. (2023), come generalizzazione che esplora pi\u00f9 percorsi alternativi e valuta progressi intermedi prima di convergere su una soluzione.<\/p>\n\n\n\n Operativamente, ToT \u00e8 utile in scenari decisionali e creativi: definire pi\u00f9 opzioni, confrontare pro e contro, applicare criteri di scelta. In un ambito universitario, ToT pu\u00f2 supportare la stesura di piani di progetto, la valutazione di architetture e la preparazione di discussioni argomentate.<\/p>\n\n\n\n \u00c8 importante distinguere tra: (a) chiedere al modello di ragionare, e (b) ottenere un output verificabile. In un lavoro accademico, la trasparenza del ragionamento non sostituisce la verifica delle fonti; \u00e8 piuttosto uno strumento per controllare coerenza e completezza.<\/p>\n\n\n\n Uno degli elementi pi\u00f9 originali del lavoro di Gianluigi Bonanni (cfr. bibliografia) \u00e8 il metodo SO.C.RA.T.E., pensato per ridurre lo sforzo dell\u2019utente nella costruzione del prompt: invece di scrivere subito una richiesta perfetta, si chiede al chatbot di porre domande e raccogliere requisiti, ovvero: l\u2019AI \u00abmi deve intervistare\u00bb per capire obiettivo e contesto, trasformando l\u2019interazione in un ping-pong a turni.<\/p>\n\n\n\n L\u2019acronimo SO.C.RA.T.E. viene definito come: SOllecito, Contesto, RAffinamento, Turni, Esortazione<\/strong>. Il cuore \u00e8 la gestione dei turni: una domanda alla volta, attendere risposta, e solo dopo procedere. Questo evita interrogatori \u2018a raffica\u2019 e permette un progressivo affinamento dei requisiti.<\/p>\n\n\n\n In termini di ingegneria del software, SO.C.RA.T.E. ricorda una fase di elicitation dei requisiti: si raccolgono informazioni, si disambiguano vincoli, si verifica la comprensione con domande incrementali. Questo approccio \u00e8 particolarmente utile in compiti complessi (piani editoriali, strategie di comunicazione, analisi di problemi) o quando l\u2019utente non \u00e8 in grado di formalizzare subito l\u2019obiettivo.<\/p>\n\n\n\n Il metodo SO.C.RA.T.E.<\/strong> \u00e8 un approccio strutturato ideato per ottimizzare l\u2019interazione con i modelli di linguaggio (LLM) come ChatGPT, trasformando la generazione di contenuti in un processo di indagine collaborativo. A differenza dei prompt tradizionali \u201cone-shot\u201d, questo metodo si ispira alla maieutica socratica<\/strong>, utilizzando un dialogo basato su domande e risposte per stimolare il pensiero critico e far emergere informazioni precise dall\u2019utente<\/p>\n\n\n\n Il metodo si articola in cinque passaggi fondamentali (pi\u00f9 uno di raffinamento opzionale) che guidano il chatbot nel raccogliere i dati necessari prima di produrre l\u2019output finale:<\/p>\n\n\n\n Una pratica derivata \u00e8 il \u2018prompt per creare i prompt<\/em><\/strong>\u2019: un meta-prompt che chiede al modello di fare domande fino a produrre una richiesta ottimizzata. In ambienti operativi, questa ricorsivit\u00e0 pu\u00f2 essere standardizzata in template e playbook.<\/p>\n\n\n\n Il metodo SO.C.RA.T.E. pu\u00f2 essere utilizzato in modo ricorsivo per far s\u00ec che sia l\u2019IA stessa a costruire un prompt perfetto<\/strong>. In questo scenario, l\u2019utente delega alla macchina il ruolo di \u201cgeneratore di prompt\u201d. L\u2019IA viene istruita a intervistare l\u2019utente su obiettivi, scopi ed esempi dell\u2019output desiderato, procedendo sempre una domanda alla volta fino a quando non ha raccolto tutte le informazioni necessarie per produrre l\u2019istruzione ottimizzata.<\/p>\n\n\n\n L\u2019efficacia del metodo risiede nel ribaltamento della logica di input: non \u00e8 pi\u00f9 l\u2019utente a dover indovinare tutte le variabili da inserire in un unico comando (\u201cgarbage in, garbage out\u201d1<\/a><\/sup>), ma \u00e8 l\u2019IA che si fa guidare e, al tempo stesso, guida l\u2019utente<\/strong> verso la soluzione migliore attraverso l\u2019ascolto attivo e la segmentazione del problema. Questo approccio riduce l\u2019ambiguit\u00e0 e massimizza la qualit\u00e0 dei risultati, rendendo l\u2019interazione con i chatbot un processo di miglioramento continuo<\/strong>.<\/p>\n\n\n\n Accanto alle tecniche, occorre affrontare limiti e vincoli: cosa non si pu\u00f2 chiedere a un chatbot e quali rischi emergono per privacy e governance. Fra le categorie di richieste problematiche (informazioni personali, contenuti dannosi, consigli medici\/legali specifici, violazioni di copyright) \u00e8 importante richiamare l\u2019attenzione sul tema della privacy e dei dati immessi dagli utenti.<\/p>\n\n\n\n La questione della privacy e la protezione dei dati<\/strong><\/p>\n\n\n\n La gestione dei dati personali \u00e8 uno dei temi pi\u00f9 critici. E qui \u00e8 d\u2019obbligo ricordare che nel marzo 2023 il Garante per la protezione dei dati personali ha temporaneamente bloccato ChatGPT in Italia, contestando diverse violazioni.<\/p>\n\n\n\n Affidabilit\u00e0 e limiti tecnici (le \u201callucinazioni\u201d)<\/strong><\/p>\n\n\n\n L\u2019affidabilit\u00e0 dei modelli di linguaggio (LLM) \u00e8 intrinsecamente limitata dalla loro natura tecnologica. Spesso questi sistemi sono definiti come \u201cpappagalli stocastici<\/strong>\u201d, poich\u00e9 generano testi basandosi su probabilit\u00e0 statistiche senza una reale comprensione semantica.<\/p>\n\n\n\n Responsabilit\u00e0 e policy d\u2019uso<\/strong><\/p>\n\n\n\n Esistono confini precisi su ci\u00f2 che pu\u00f2 essere chiesto o fatto con un chatbot:<\/p>\n\n\n\n L\u2019uomo al centro: il ruolo del \u201cCo-pilot\u201d<\/strong><\/p>\n\n\n\n Un concetto fondamentale da sottolineare \u00e8 che la responsabilit\u00e0 finale resta umana. Microsoft, non a caso, definisce il suo assistente AI \u201cCo-pilot<\/strong>\u201d e non \u201cpilot\u201d, sottolineando che l\u2019uomo deve rimanere al centro del processo.<\/p>\n\n\n\n In sintesi, l\u2019efficacia dello strumento dipende dalla capacit\u00e0 dell\u2019utente di formulare prompt neutri e specifici per limitare i bias, di verificare sempre l\u2019output per correggere eventuali allucinazioni e di gestire con prudenza i dati sensibili, sapendo che \u201cgarbage in, garbage out\u201d (se l\u2019input \u00e8 scadente, lo sar\u00e0 anche l\u2019output)<\/p>\n\n\n\n Quindi per uso personale e ancor pi\u00f9 per un uso universitario e aziendale, queste considerazioni si traducono in regole pratiche: evitare dati personali e sensibili nei prompt, anonimizzare dataset e log, usare ambienti controllati e prevedere sempre una fase di verifica umana dell\u2019output.<\/p>\n\n\n\n Un secondo rischio \u00e8 l\u2019affidabilit\u00e0: un output fluido pu\u00f2 mascherare errori. Per questo, in prompt tecnici conviene richiedere esplicitamente ipotesi, limiti e, quando possibile, riferimenti o procedure di validazione. In ambito software, l\u2019analogo \u00e8 la distinzione tra \u2018build\u2019 e \u2018test\u2019: il modello produce, ma la validazione rimane responsabilit\u00e0 dell\u2019utente.<\/p>\n\n\n\n L\u2019utilizzo dell\u2019intelligenza artificiale generativa, in sintesi, comporta importanti riflessioni su privacy, affidabilit\u00e0 e responsabilit\u00e0<\/strong>. Sebbene questi strumenti offrano opportunit\u00e0 rivoluzionarie, il loro impiego \u00e8 delimitato da vincoli normativi, tecnici ed etici che l\u2019utente deve conoscere per un uso consapevole.<\/p>\n\n\n\n Le prospettive future dell\u2019interazione con l\u2019intelligenza artificiale suggeriscono un\u2019evoluzione che va oltre l\u2019attuale concetto di prompt engineering, spostandosi verso l\u2019impiego di agenti autonomi e una maggiore enfatizzazione sulla formulazione del problema.<\/p>\n\n\n\n Di seguito i punti chiave:<\/p>\n\n\n\n Secondo alcuni esperti, il prompt engineering come lo conosciamo oggi potrebbe diventare presto obsoleto. Le tendenze indicano che il futuro non si baser\u00e0 solo sulla singola istruzione fornita dall\u2019utente, ma sull\u2019uso di agenti autonomi<\/strong> capaci di collaborare tra loro in processi dinamici e complessi.<\/p>\n\n\n\n Con il progredire della tecnologia, l\u2019intelligenza artificiale diventer\u00e0 sempre pi\u00f9 intuitiva nella comprensione del linguaggio naturale, riducendo la necessit\u00e0 di istruzioni tecniche estremamente dettagliate.<\/p>\n\n\n\n Nonostante l\u2019aumento dell\u2019automazione, l\u2019essere umano rimarr\u00e0 al centro del processo.<\/p>\n\n\n\n In sintesi, si ipotizza che mentre la macchina diventer\u00e0 pi\u00f9 autonoma nell\u2019esecuzione (agenti e automazioni), il valore aggiunto dell\u2019uomo si sposter\u00e0 a monte del processo, nella capacit\u00e0 critica di definire correttamente le sfide<\/strong> da sottoporre all\u2019intelligenza artificiale.<\/p>\n\n\n\n Nella possibile evoluzione \u201coltre il prompt engineering\u201d \u00e8 da citare la posizione di von Csefalvay: il futuro \u00abnon si baser\u00e0 sul prompt engineering\u00bb, ma sull\u2019uso di \u00abagenti autonomi\u00bb che collaborano in processi pi\u00f9 dinamici.<\/p>\n\n\n\n Questa tesi \u00e8 coerente con una tendenza dell\u2019ecosistema: strumenti che automatizzano template (estensioni, librerie di prompt), catene di strumenti e workflow agentici (planner, executor, critic). Tuttavia, anche in uno scenario agentico, permane un nucleo di competenza umana: formulare bene il problema e definire criteri di successo.<\/p>\n\n\n\n Da qui la conclusione teorica: il prompt engineering pu\u00f2 ridursi come \u2018mestiere artigianale\u2019 ripetitivo, ma non scompare come abilit\u00e0 concettuale. Cambia il livello di astrazione: dall\u2019istruzione puntuale al design del processo (obiettivi, guardrail, verifiche, metriche), cio\u00e8 una vera ingegneria del dialogo uomo-macchina.<\/p>\n\n\n\n Il prompt engineering \u00e8 una disciplina di progettazione dell\u2019interazione. I concetti di token e contesto ricordano che l\u2019interazione \u00e8 vincolata da risorse computazionali e da limiti di memoria conversazionale. La teoria dei frame mostra che la qualit\u00e0 dell\u2019output dipende anche da scelte linguistiche e pragmatiche.<\/p>\n\n\n\n I metodi G.O.L. e G.O.L.D. trasformano il prompting in una procedura replicabile, utile soprattutto in contesti professionali dove l\u2019obiettivo \u00e8 ridurre variabilit\u00e0 e ambiguit\u00e0. Tecniche come CoT e ToT estendono la capacit\u00e0 del modello su compiti complessi, mentre SO.C.RA.T.E. sposta l\u2019attenzione dall\u2019\u2018istruzione perfetta\u2019 alla raccolta incrementale dei requisiti.<\/p>\n\n\n\n Infine, policy e privacy ricordano che la qualit\u00e0 non \u00e8 solo tecnica: \u00e8 anche responsabilit\u00e0. Il valore dei chatbot emerge pienamente quando il loro uso \u00e8 inserito in un processo: progettazione del prompt, generazione, verifica, revisione, e solo infine integrazione nel contesto reale (studio, lavoro, decisioni).<\/p>\n\n\n\n Bonanomi, G. (2024). ChatGPT, come stai? Il prompt engineering come nuova skill ibrida. Milano: Ledizioni.<\/p>\n\n\n\n Goffman, E. (1974). Frame Analysis: An Essay on the Organization of Experience. Boston: Northeastern University Press.<\/p>\n\n\n\n Lakoff, G. (2004). Non pensare all\u2019elefante! Come riprendersi il discorso politico. Milano: Chiarelettere.<\/p>\n\n\n\n Wei, J., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.<\/p>\n\n\n\n Yao, S., et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601.<\/p>\n\n\n\n von Csefalvay, C. (s.d.). Prompt Engineering: The Art of Yesterday. (citato in Bonanomi, 2024).<\/p>\n\n\n\n Autorit\u00e0 Garante per la protezione dei dati personali (2023). Provvedimento relativo al servizio ChatGPT. (citato in Bonanomi, 2024).<\/p>\n\n\n Abstract In questo articolo si cerca di considerare il prompt engineering come nuova skill ibrida, con l\u2019obiettivo di interpretarlo come disciplina di progettazione dell\u2019interazione con modelli linguistici generativi. Viene mostrato come l\u2019efficacia di un chatbot non dipenda solo dal modello, ma anche dalla qualit\u00e0 dell\u2019input: contesto, obiettivi, vincoli e forma dell\u2019output. Vengono discussi i vincoli … Leggi tutto “PROMPT ENGINEERING: progettazione dell\u2019interazione con i modelli linguistici generativi”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":"[{\"content\":\"Garbage in, garbage out<\/strong>\u00a0(lett.\u00a0\\\"spazzatura dentro, spazzatura fuori\\\",\u00a0GIGO<\/strong>\u00a0in forma abbreviata; anche\u00a0rubbish in, rubbish out<\/em>) \u00e8 una frase utilizzata nel campo dell'informatica\u00a0e della\u00a0tecnologia dell'informazione e della comunicazione. \u00c8 utilizzata soprattutto per richiamare l'attenzione sul fatto che i\u00a0computer\u00a0elaborano in modo acritico, pertanto se viene fornito loro un insieme di\u00a0dati\u00a0in entrata palesemente erronei o insensati (garbage in<\/em>) producono un risultato erroneo o insensato (garbage out<\/em>).https:\/\/it.wikipedia.org\/wiki\/Garbage_in,_garbage_out<\/a>\",\"id\":\"61fb3632-e505-4eaa-9abd-c63041abd4c2\"}]"},"categories":[114,19,106,112],"tags":[108,124,125,121,117,118,116,119,123,115,120,122,107],"class_list":["post-5467","post","type-post","status-publish","format-standard","hentry","category-ai","category-sistemi-operativi","category-sviluppo","category-vibe-coding","tag-ai","tag-allucinazioni","tag-co-pilot","tag-cot","tag-g-o-l","tag-g-o-l-d","tag-prompt","tag-reverse-prompt-engineering","tag-so-c-ra-t-e","tag-token","tag-tone-of-voice","tag-tot","tag-vibe-coding"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/5467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=5467"}],"version-history":[{"count":43,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/5467\/revisions"}],"predecessor-version":[{"id":5559,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/5467\/revisions\/5559"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=5467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=5467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=5467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}3. Frame, ambiguit\u00e0 e pragmatica del prompt<\/h1>\n\n\n\n
\n
4. Il metodo G.O.L.: un framework di specifica per il prompting<\/h1>\n\n\n\n
5. G.O.L.D., X-shot prompting e reverse prompt engineering<\/h1>\n\n\n\n
\n
\n
\n
6. Tone of voice e requisiti non funzionali dell\u2019output<\/h1>\n\n\n\n
Il Tone of voice (tono di voce)<\/strong><\/h3>\n\n\n\n
\n
Requisiti non funzionali dell\u2019output<\/strong><\/h3>\n\n\n\n
\n
\n
Concretezza e Specificit\u00e0<\/strong><\/h3>\n\n\n\n
7. CoT e ToT: prompting per il ragionamento e il problem solving<\/h1>\n\n\n\n
8. SO.CRA.TE e prompting iterativo: dall\u2019input all\u2019elicitation dei requisiti<\/h1>\n\n\n\n
\n
9. Policy, privacy e affidabilit\u00e0: limiti e responsabilit\u00e0 d\u2019uso<\/h1>\n\n\n\n
\n
\n
\n
10. Prospettive: agenti, automazioni e formulazione del problema<\/strong><\/h1>\n\n\n\n
Agenti autonomi e automazioni complesse<\/strong><\/h3>\n\n\n\n
\n
Dalla soluzione alla formulazione del problema<\/strong><\/h3>\n\n\n\n
\n
L\u2019uomo come \u201cCo-pilota\u201d<\/strong><\/h3>\n\n\n\n
\n
Conclusioni<\/strong><\/h1>\n\n\n\n
Bibliografia<\/strong><\/h1>\n\n\n\n