PROMPT ENGINEERING: progettazione dell’interazione con i modelli linguistici generativi

Abstract

In questo articolo si cerca di considerare il prompt engineering come nuova skill ibrida, con l’obiettivo di interpretarlo come disciplina di progettazione dell’interazione con modelli linguistici generativi. Viene mostrato come l’efficacia di un chatbot non dipenda solo dal modello, ma anche dalla qualità dell’input: contesto, obiettivi, vincoli e forma dell’output. Vengono discussi i vincoli tecnici (token e finestra di contesto), i fondamenti comunicativi (ambiguità, 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’articolo integra inoltre considerazioni su policy e privacy e una riflessione prospettica sull’evoluzione verso agenti e automazioni che potrebbero ridurre il peso del prompt manuale, lasciando centrale la capacità di formulare correttamente i problemi.

Introduzione

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’interazione con un chatbot è mediata da linguaggio naturale. Questa “naturalità” è però ingannevole: l’output non è il risultato di una comprensione semantica umana, ma di una generazione probabilistica condizionata dall’input e dal contesto.

Dobbiamo capire come interagire al meglio con quei modelli e quindi incominciare a parlare di prompt engineering.

Da qui una nuova prospettiva: il prompt non è 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à linguistica nella gestione di ambiguità, tono e aspettative dell’utente.

1. Modelli linguistici e natura dell’output generativo

Per inquadrare il prompt engineering è 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ù probabili dato il contesto.

Attenzione però: l’idea che il modello generi testo “plausibile” perché addestrato su grandi quantità di contenuti digitali può creare l’illusione di un’interlocuzione umana, ma non garantisce accuratezza.

Dal punto di vista operativo, questo comporta due conseguenze. Primo: il chatbot può essere estremamente utile in compiti di scrittura, sintesi, brainstorming e supporto decisionale, ma necessita di controlli e verifiche. Secondo: la forma dell’input guida in modo determinante la forma dell’output; di fatto, il prompt è l’API del modello.

Da qui la proposta di leggere il prompt engineering come nuova skill “ibrida”, collocata tra hard skill (conoscenza di vincoli e strumenti) e soft skill (capacità comunicativa, chiarezza espositiva, empatia verso il lettore/utente).

2. Token, contesto e vincoli di memoria conversazionale

Uno dei concetti più tecnici da introdurre è la tokenizzazione, ovvero «l’unità di base di elaborazione in un modello di linguaggio», che può corrispondere a parola, sotto-parola o carattere.

Il limite di token gestibili in una singola conversazione (finestra di contesto) impone vincoli pratici: un prompt troppo lungo può saturare il contesto, riducendo spazio per la risposta o causando la perdita di informazioni precedenti. Il problema si amplifica quando l’utente incolla documenti lunghi, log o report: in questi casi si dovrebbe ricorrere a strumenti di “splitting” del testo per suddividere l’input in segmenti gestibili.

Dal punto di vista ingegneristico, la finestra di contesto può essere trattata come risorsa limitata. Ne deriva un principio di progettazione: la parte più “costosa” del prompt è il contenuto ridondante o poco pertinente; la parte più “economica” è la strutturazione che riduce ambiguità (titoli, sezioni, liste, schemi, formati).

Un buon prompt, quindi, non è necessariamente un prompt “lungo”: è un prompt informativo, ben organizzato e orientato al compito. Questo punto, spesso trascurato in guide superficiali, è centrale per un uso professionale dei LLM.

3. Frame, ambiguità e pragmatica del prompt

Proviamo a collegare il concetto di contesto alla teoria dei frame. In sociologia, i frame sono «cornici», cioè schemi interpretativi che aiutano a dare senso alle situazioni sociali; richiamiamo questo impianto per spiegare come il prompt “incornici” l’output. Nel prompting la scelta di parole e impostazione del compito attiva frame diversi: chiedere “un’analisi tecnica” produce un output differente rispetto a chiedere “una narrazione creativa”; allo stesso modo, definire il target (ad esempio “spiega come a un bambino di dieci anni”) condiziona tono, lessico e struttura.

Da qui si può derivare un modello pragmatico, il prompt deve dichiarare:

  • (a) dominio e livello di competenza atteso;
  • (b) scopo dell’output (informare, convincere, addestrare, documentare);
  • (c) vincoli e criterio di successo.

In assenza di questi elementi il modello colma i vuoti con assunzioni implicite, aumentando la probabilità di mismatch tra aspettativa dell’utente e output generato.

Nel contesto universitario e professionale, la gestione dei frame è anche gestione del rischio: un chatbot che adotta un frame eccessivamente assertivo o “autoritativo” può indurre l’utente a fidarsi di contenuti non verificati. Per questo l’elaborazione di prompt deve includere strategie di mitigazione: richiesta esplicita di incertezze, richiesta di ipotesi e limiti, richiesta di verifiche incrociate quando possibile.

4. Il metodo G.O.L.: un framework di specifica per il prompting

Un contributo pratico è la formalizzazione di un metodo mnemonico per scrivere prompt: G.O.L. ovvero «per creare un buon prompt occorre avere in mente uno schema».

Il metodo G.O.L. si articola in tre fasi:

1) Guidare: assegnare un ruolo al modello (role prompting), ad esempio “agisci come un consulente”, “come un docente”, “come un revisore”, ovvero «bisogna dirgli chi deve essere» (come un attore), così da attivare conoscenze pertinenti all’ambito.

2) Obiettivi: esplicitare cosa si desidera ottenere, includendo output atteso, target e criteri. Nel prompting, gli obiettivi non vanno confusi con la domanda: la domanda è una forma superficiale, l’obiettivo è la specifica funzionale.

3) Limiti e layout: definire vincoli (lunghezza, ciò che va escluso, stile, livello di dettaglio) e, soprattutto, la struttura dell’output (tabella, checklist, sezione con esempi, ecc.).

In prospettiva informatica, G.O.L. può essere interpretato come un pattern di specifica: la parte “G” definisce il contesto di esecuzione, la parte “O” definisce i requisiti funzionali, la parte “L” definisce requisiti non funzionali e formato di output.

5. G.O.L.D., X-shot prompting e reverse prompt engineering

E’ possibile poi estendere G.O.L. nella variante G.O.L.D., aggiungendo una “D” di ulteriori dettagli che rendono il prompt più robusto e controllabile.

E’ importante sottolineare inoltre un tema fondamentale: la comunicazione con un LLM beneficia degli esempi. Nel lessico tecnico, questo si traduce in zero-shot, one-shot e few-shot prompting. In un prompt zero-shot il modello lavora senza esempi; in un prompt one-shot si fornisce un esempio di riferimento; nel few-shot si forniscono più esempi per indurre un pattern.

Dal punto di vista applicativo, gli esempi svolgono funzioni diverse:

  • (a) chiariscono il formato (ad es. input-output);
  • (b) chiariscono lo stile (registro, tono, lunghezza);
  • (c) riducono l’ambiguità nei compiti di classificazione o trasformazione (ad es. estrarre campi da testo).

Nel contesto professionale, la ‘D’ può includere: definizioni operative, criteri di valutazione, dataset di esempio, vincoli sul vocabolario, terminologia e acronimi ammessi, nonché un ‘negative prompting’ (cosa non fare).

Un altro aspetto che va considerato è il reverse prompt engineering: risalire al prompt che potrebbe aver generato un testo desiderato, così da replicare lo stile e standardizzare output futuri.

Il reverse prompt engineering è una tecnica avanzata che consente di generare prompt di alta qualità per finalità quali la scrittura, la ricerca, l’apprendimento o la creatività.

Ecco come funziona e come viene applicata:

  • Logica di base: questo approccio si basa sulla ricostruzione di un prompt che potrebbe aver generato un testo specifico già esistente. Invece di partire da zero, l’utente fornisce all’intelligenza artificiale un output desiderato affinché la macchina ne deduca le istruzioni.
  • Analisi dello stile e del tono: inserendo esempi di testi che l’utente apprezza o che ha scritto personalmente, ChatGPT può analizzare il linguaggio utilizzato e generare nuovi prompt che siano perfettamente allineati a quello stile e a quel tono.

Esempi pratici di applicazione:

  • Analisi di citazioni: esempio di una citazione di Warren Buffett, inserendola nel chatbot, si può chiedere all’IA di generare un prompt che rifletta la filosofia e l’approccio cautamente lungimirante tipico di Buffett.
  • Completamento di testi: è possibile fornire un proprio brano e chiedere a ChatGPT di continuare a scrivere seguendo la stessa falsariga stilistica, mantenendo la coerenza con quanto già prodotto dall’autore umano.
  • Utilizzo di moduli: un uso più pragmatico consiste nel copiare e incollare lo “scheletro” di un modulo o di una lettera formale (come una disdetta) per obbligare il chatbot a seguire la sequenza e lo schema corretto delle parole.
  • Reverse engineering delle immagini: il concetto si estende anche al campo visivo (sintografie). Attraverso strumenti specifici (come img2prompt.io), è possibile caricare una foto per ottenere il prompt testuale necessario per ricrearla o generarne di simili.

In sintesi, questa tecnica trasforma l’IA in uno strumento capace di decodificare il “DNA” di un testo per trasformarlo in un’istruzione operativa riutilizzabile.

6. Tone of voice e requisiti non funzionali dell’output

I “modificatori di tono” come strumento per rendere gli scambi più naturali ed efficaci, adattandoli a contesti e pubblici diversi.

Nel contesto del prompt engineering, la definizione del tone of voice (tono di voce) e dei requisiti non funzionali (come formato, limiti e stile) è essenziale per trasformare un output generico in un risultato professionale e mirato.

Il Tone of voice (tono di voce)

Il tono di voce non riguarda cosa l’IA dice, ma come lo dice. Si identificano diverse tecniche per modulare questo aspetto:

  • Modificatori di tono: sono strumenti per rendere la comunicazione più naturale e meno meccanica. Attraverso parole specifiche, variazioni di ritmo e tonalità emotive (ironia, empatia, autorità), è possibile adattare l’IA a diversi pubblici.
  • Esempi di combinazioni: è possibile richiedere toni complessi come “Amichevole + Professionale” (per panoramiche informative ma accessibili), “Autorevole + Informale” (per pareri esperti ma diretti), o “Urgente + Concreto” (per spingere all’azione).
  • Teoria dei frame (cornici): applicando la teoria di Goffman, il tono viene influenzato dalla “cornice” interpretativa fornita. Ad esempio, lo stesso argomento verrà spiegato con linguaggi e toni radicalmente diversi se il target è un bambino di dieci anni (usando metafore) o un ingegnere informatico (usando termini tecnici).
  • Sentiment: l’utente può definire l’obiettivo emotivo dell’output, chiedendo varianti basate sul “sentiment”, come un messaggio “dispiaciuto” rispetto a uno “propositivo”.

Requisiti non funzionali dell’output

Questi requisiti definiscono i vincoli tecnici e strutturali che l’IA deve rispettare, sintetizzati principalmente nella “L” del metodo G.O.L. (Limiti e Layout).

Limiti e vincoli

  • Lunghezza: è fondamentale imporre paletti sulla produzione di testo, specificando il numero di caratteri o parole desiderate.
  • Token: la lunghezza è condizionata dai “token” (unità di base di circa 4 caratteri). Modelli come GPT-4 hanno limiti di contesto molto ampi (fino a 128.000 token), ma per testi estremamente lunghi è necessario usare strumenti come i “GPT splitter”.
  • Temperatura: è un parametro tecnico (0-1) che regola la casualità. Una temperatura bassa produce output precisi e ripetitivi; una alta favorisce la creatività e il brainstorming.

Layout e format (forma dell’output)

ChatGPT può gestire una vasta gamma di formati oltre al semplice testo:

  • Strutture tabellari e grafiche: tabelle comparative, checklist, schede valutative e persino grafici a torta.
  • Diagrammi complessi: diagrammi di Gantt o mappe mentali utilizzando la sintassi Markdown Mermaid.
  • Formati dati e codice: file CSV (valori separati da virgola), XML/YAML, codice di programmazione (HTML, CSS, Python) e persino file SVG per grafica vettoriale o codici QR.

Concretezza e Specificità

Per evitare il fenomeno “garbage in, garbage out” (input scadente, output scadente), i requisiti devono essere descrittivi e dettagliati. Un errore comune è la mancanza di specificità: invece di un vago “disegna un paesaggio”, un prompt efficace descrive l’ora del giorno, le condizioni atmosferiche e lo stile desiderato.

Infine, l’uso di esempi (one-shot o few-shot prompting) all’interno del metodo G.O.L.D. permette di mostrare all’IA esattamente lo schema o lo stile da seguire, garantendo che l’output rispetti i requisiti non funzionali desiderati.

Il tone of voice è un controllo pragmatico, quindi: non cambia solo la ‘forma’ del testo, ma anche la selezione delle informazioni, la loro priorità e la modalità argomentativa. Un output “autorevole” tende a usare definizioni e assertività; un output “empatico” tende a riconoscere emozioni e proporre azioni di supporto; un output “urgente e concreto” privilegia passi operativi e call-to-action.

Dal punto di vista della progettazione, conviene trattare il tone of voice come requisito non funzionale al pari di performance o usabilità in un sistema software: non è ‘decorazione’, ma condizione di accettazione dell’output. In un contesto educativo, per esempio, il tono deve sostenere comprensione, scaffolding e gradualità; in un contesto di incident response deve privilegiare chiarezza, priorità e risk awareness.

Il rischio principale è l’overfitting stilistico: un tono troppo marcato può introdurre bias (ad esempio semplificazioni eccessive o eccesso di confidenza). Per mitigare, si può chiedere al modello di separare il contenuto fattuale dal registro (es. ‘prima i fatti in punti, poi la spiegazione in tono X’).

7. CoT e ToT: prompting per il ragionamento e il problem solving

Quando il compito richiede ragionamento multi-step, si potrebbe introdurre la tecnica Chain-of-Thought (CoT), citando Wei et al. (2022): chiedere (o indurre) passaggi intermedi migliora la capacità di problem solving e riduce errori in compiti complessi.

L’idea può essere letta come “decomposizione del problema”: si suddivide il task in sotto-problemi, ottenendo un output intermedio che rende il percorso più controllabile e debuggabile, in modo simile a come si progettano funzioni e moduli in un software.

Oppure quella del Tree-of-Thoughts (ToT), citando Yao et al. (2023), come generalizzazione che esplora più percorsi alternativi e valuta progressi intermedi prima di convergere su una soluzione.

Operativamente, ToT è utile in scenari decisionali e creativi: definire più opzioni, confrontare pro e contro, applicare criteri di scelta. In un ambito universitario, ToT può supportare la stesura di piani di progetto, la valutazione di architetture e la preparazione di discussioni argomentate.

È 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; è piuttosto uno strumento per controllare coerenza e completezza.

8. SO.CRA.TE e prompting iterativo: dall’input all’elicitation dei requisiti

Uno degli elementi più originali del lavoro di Gianluigi Bonanni (cfr. bibliografia) è il metodo SO.C.RA.T.E., pensato per ridurre lo sforzo dell’utente nella costruzione del prompt: invece di scrivere subito una richiesta perfetta, si chiede al chatbot di porre domande e raccogliere requisiti, ovvero: l’AI «mi deve intervistare» per capire obiettivo e contesto, trasformando l’interazione in un ping-pong a turni.

L’acronimo SO.C.RA.T.E. viene definito come: SOllecito, Contesto, RAffinamento, Turni, Esortazione. Il cuore è la gestione dei turni: una domanda alla volta, attendere risposta, e solo dopo procedere. Questo evita interrogatori ‘a raffica’ e permette un progressivo affinamento dei requisiti.

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 è particolarmente utile in compiti complessi (piani editoriali, strategie di comunicazione, analisi di problemi) o quando l’utente non è in grado di formalizzare subito l’obiettivo.

Il metodo SO.C.RA.T.E. è un approccio strutturato ideato per ottimizzare l’interazione con i modelli di linguaggio (LLM) come ChatGPT, trasformando la generazione di contenuti in un processo di indagine collaborativo. A differenza dei prompt tradizionali “one-shot”, questo metodo si ispira alla maieutica socratica, utilizzando un dialogo basato su domande e risposte per stimolare il pensiero critico e far emergere informazioni precise dall’utente

Il metodo si articola in cinque passaggi fondamentali (più uno di raffinamento opzionale) che guidano il chatbot nel raccogliere i dati necessari prima di produrre l’output finale:

  • SO (Sollecito): consiste nel formulare una richiesta chiara e diretta. La precisione è fondamentale: una domanda vaga produce risposte generiche, mentre una specifica (es. “tendenze del marketing B2C” invece di un generico “parlami di marketing”) orienta correttamente la macchina.
  • C (Contesto): in questa fase si forniscono informazioni aggiuntive per inquadrare la richiesta. È utile specificare dettagli come il livello di complessità desiderato (es. tecnico o divulgativo) o le sfumature del compito da svolgere.
  • RA (Raffinamento): fase dedicata all’inserimento di dettagli estremi, come link a offerte di lavoro o documenti specifici, per rendere l’interazione ancora più mirata.
  • T (Turni): rappresenta il cuore del metodo. Si richiede esplicitamente al chatbot di organizzare una conversazione a turni, innescando un “ping-pong” comunicativo in cui ogni risposta dell’utente diventa la base per la domanda successiva dell’IA.
  • E (Esortazione): è l’istruzione critica per evitare che il chatbot ponga tutte le domande contemporaneamente. Bisogna ordinare all’IA di aspettare la risposta dell’utente prima di procedere con il quesito successivo.

Una pratica derivata è il ‘prompt per creare i prompt’: un meta-prompt che chiede al modello di fare domande fino a produrre una richiesta ottimizzata. In ambienti operativi, questa ricorsività può essere standardizzata in template e playbook.

Il metodo SO.C.RA.T.E. può essere utilizzato in modo ricorsivo per far sì che sia l’IA stessa a costruire un prompt perfetto. In questo scenario, l’utente delega alla macchina il ruolo di “generatore di prompt”. L’IA viene istruita a intervistare l’utente su obiettivi, scopi ed esempi dell’output desiderato, procedendo sempre una domanda alla volta fino a quando non ha raccolto tutte le informazioni necessarie per produrre l’istruzione ottimizzata.

L’efficacia del metodo risiede nel ribaltamento della logica di input: non è più l’utente a dover indovinare tutte le variabili da inserire in un unico comando (“garbage in, garbage out”1), ma è l’IA che si fa guidare e, al tempo stesso, guida l’utente verso la soluzione migliore attraverso l’ascolto attivo e la segmentazione del problema. Questo approccio riduce l’ambiguità e massimizza la qualità dei risultati, rendendo l’interazione con i chatbot un processo di miglioramento continuo.

9. Policy, privacy e affidabilità: limiti e responsabilità d’uso

Accanto alle tecniche, occorre affrontare limiti e vincoli: cosa non si può 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) è importante richiamare l’attenzione sul tema della privacy e dei dati immessi dagli utenti.

  • Data breach e raccolta dati: tra le criticità sollevate figuravano un perduto controllo dei dati (data breach) avvenuto nel marzo 2023 e l’assenza di una base giuridica per la raccolta massiva di dati finalizzata all’addestramento degli algoritmi.
  • L’utente come “produttore”: viene evidenziato che, specialmente nelle versioni gratuite, l’utente non è il prodotto ma il “produttore non pagato” di valore attraverso i propri dati, che vengono fagocitati dal sistema per migliorarsi.
  • Strumenti di tutela: per ovviare a questi problemi, OpenAI ha introdotto una modalità “in incognito” che permette di disattivare la cronologia. Quando questa opzione è attiva, le conversazioni non vengono utilizzate per addestrare i modelli.

Affidabilità e limiti tecnici (le “allucinazioni”)

L’affidabilità dei modelli di linguaggio (LLM) è intrinsecamente limitata dalla loro natura tecnologica. Spesso questi sistemi sono definiti come “pappagalli stocastici”, poiché generano testi basandosi su probabilità statistiche senza una reale comprensione semantica.

  • Allucinazioni: i modelli possono inventare fatti o dati inesistenti, fenomeno noto come “allucinazioni”, rendendo le risposte occasionalmente inesatte o inappropriate.
  • Bias e pregiudizi: poiché l’IA apprende da miliardi di pagine web, può ereditare e propagare pregiudizi ideologici, politici o sociali presenti nei dati di addestramento (ad esempio, stereotipi di genere o discriminazioni).
  • Lacune scientifiche: ChatGPT mostra spesso pecche in matematica e logica, sebbene strumenti come il plugin Wolfram possano mitigare queste carenze. Inoltre, le conoscenze sono limitate alla data dell’ultimo addestramento, a meno che non si utilizzi la navigazione web in tempo reale.

Responsabilità e policy d’uso

Esistono confini precisi su ciò che può essere chiesto o fatto con un chatbot:

  • Contenuti proibiti: l’IA non elabora richieste legate a contenuti offensivi, discriminatori, fraudolenti o atti di hacking. È inoltre vietato tentare di far rivelare al sistema i propri dati di addestramento tramite tecniche di “jailbreaking”.
  • Consulenza professionale: ChatGPT non è qualificato per fornire consigli medici o legali specifici; in questi casi, il sistema è istruito per suggerire sempre il consulto con un professionista umano.
  • Copyright: i modelli sono progettati per rispettare le leggi sul diritto d’autore e non dovrebbero assistere nella distribuzione di materiali protetti senza autorizzazione. Tuttavia, la tutela legale del “prompt” stesso come opera dell’ingegno è ancora oggetto di dibattito giuridico.

L’uomo al centro: il ruolo del “Co-pilot”

Un concetto fondamentale da sottolineare è che la responsabilità finale resta umana. Microsoft, non a caso, definisce il suo assistente AI “Co-pilot” e non “pilot”, sottolineando che l’uomo deve rimanere al centro del processo.

In sintesi, l’efficacia dello strumento dipende dalla capacità dell’utente di formulare prompt neutri e specifici per limitare i bias, di verificare sempre l’output per correggere eventuali allucinazioni e di gestire con prudenza i dati sensibili, sapendo che “garbage in, garbage out” (se l’input è scadente, lo sarà anche l’output)

Quindi per uso personale e ancor più 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’output.

Un secondo rischio è l’affidabilità: un output fluido può mascherare errori. Per questo, in prompt tecnici conviene richiedere esplicitamente ipotesi, limiti e, quando possibile, riferimenti o procedure di validazione. In ambito software, l’analogo è la distinzione tra ‘build’ e ‘test’: il modello produce, ma la validazione rimane responsabilità dell’utente.

L’utilizzo dell’intelligenza artificiale generativa, in sintesi, comporta importanti riflessioni su privacy, affidabilità e responsabilità. Sebbene questi strumenti offrano opportunità rivoluzionarie, il loro impiego è delimitato da vincoli normativi, tecnici ed etici che l’utente deve conoscere per un uso consapevole.

10. Prospettive: agenti, automazioni e formulazione del problema

Le prospettive future dell’interazione con l’intelligenza artificiale suggeriscono un’evoluzione che va oltre l’attuale concetto di prompt engineering, spostandosi verso l’impiego di agenti autonomi e una maggiore enfatizzazione sulla formulazione del problema.

Di seguito i punti chiave:

Agenti autonomi e automazioni complesse

Secondo alcuni esperti, il prompt engineering come lo conosciamo oggi potrebbe diventare presto obsoleto. Le tendenze indicano che il futuro non si baserà solo sulla singola istruzione fornita dall’utente, ma sull’uso di agenti autonomi capaci di collaborare tra loro in processi dinamici e complessi.

  • Collaborazione tra macchine: si prospetta uno scenario in cui i chatbot si scambiano richieste e risposte autonomamente per risolvere compiti articolati.
  • Esempi di strumenti: strumenti come AgentGPT rappresentano i primi passi verso questa direzione, in cui l’intervento umano è ridotto rispetto alla fase di esecuzione.
  • Assistenti intelligenti: motori come Perplexity utilizzano già sistemi (come Copilot) che guidano l’utente a interrogare meglio la macchina, agendo da ponte verso un’automazione più fluida.

Dalla soluzione alla formulazione del problema

Con il progredire della tecnologia, l’intelligenza artificiale diventerà sempre più intuitiva nella comprensione del linguaggio naturale, riducendo la necessità di istruzioni tecniche estremamente dettagliate.

  • La nuova abilità chiave: l’abilità fondamentale da acquisire non sarà più il “sussurrare” comandi specifici, ma la formulazione del problema.
  • Il ruolo dell’utente: l’uomo dovrà concentrarsi sull’identificare, analizzare e delineare correttamente i problemi; al problem solving effettivo penserà l’IA.

L’uomo come “Co-pilota”

Nonostante l’aumento dell’automazione, l’essere umano rimarrà al centro del processo.

  • Concetto di Co-pilot: Microsoft, ad esempio, definisce il suo assistente AI come un “Co-pilot” e non un “pilot”, proprio per sottolineare che la responsabilità e la guida finale restano umane.
  • Evoluzione delle professioni: emergeranno nuove figure come lo “Specialista delle interfacce umane”, che richiederanno un mix di hard skill informatiche e soft skill psicologiche e sociali per gestire l’interazione uomo-macchina in contesti sempre più integrati, come il settore automotive.

In sintesi, si ipotizza che mentre la macchina diventerà più autonoma nell’esecuzione (agenti e automazioni), il valore aggiunto dell’uomo si sposterà a monte del processo, nella capacità critica di definire correttamente le sfide da sottoporre all’intelligenza artificiale.

Questa tesi è coerente con una tendenza dell’ecosistema: 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.

Da qui la conclusione teorica: il prompt engineering può ridursi come ‘mestiere artigianale’ ripetitivo, ma non scompare come abilità concettuale. Cambia il livello di astrazione: dall’istruzione puntuale al design del processo (obiettivi, guardrail, verifiche, metriche), cioè una vera ingegneria del dialogo uomo-macchina.

Conclusioni

Il prompt engineering è una disciplina di progettazione dell’interazione. I concetti di token e contesto ricordano che l’interazione è vincolata da risorse computazionali e da limiti di memoria conversazionale. La teoria dei frame mostra che la qualità dell’output dipende anche da scelte linguistiche e pragmatiche.

I metodi G.O.L. e G.O.L.D. trasformano il prompting in una procedura replicabile, utile soprattutto in contesti professionali dove l’obiettivo è ridurre variabilità e ambiguità. Tecniche come CoT e ToT estendono la capacità del modello su compiti complessi, mentre SO.C.RA.T.E. sposta l’attenzione dall’‘istruzione perfetta’ alla raccolta incrementale dei requisiti.

Infine, policy e privacy ricordano che la qualità non è solo tecnica: è anche responsabilità. Il valore dei chatbot emerge pienamente quando il loro uso è inserito in un processo: progettazione del prompt, generazione, verifica, revisione, e solo infine integrazione nel contesto reale (studio, lavoro, decisioni).

Bibliografia

Bonanomi, G. (2024). ChatGPT, come stai? Il prompt engineering come nuova skill ibrida. Milano: Ledizioni.

Goffman, E. (1974). Frame Analysis: An Essay on the Organization of Experience. Boston: Northeastern University Press.

Lakoff, G. (2004). Non pensare all’elefante! Come riprendersi il discorso politico. Milano: Chiarelettere.

Wei, J., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.

Yao, S., et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601.

von Csefalvay, C. (s.d.). Prompt Engineering: The Art of Yesterday. (citato in Bonanomi, 2024).

Autorità Garante per la protezione dei dati personali (2023). Provvedimento relativo al servizio ChatGPT. (citato in Bonanomi, 2024).

  1. Garbage in, garbage out (lett. “spazzatura dentro, spazzatura fuori”, GIGO in forma abbreviata; anche rubbish in, rubbish out) è una frase utilizzata nel campo dell’informatica e della tecnologia dell’informazione e della comunicazione. È utilizzata soprattutto per richiamare l’attenzione sul fatto che i computer elaborano in modo acritico, pertanto se viene fornito loro un insieme di dati in entrata palesemente erronei o insensati (garbage in) producono un risultato erroneo o insensato (garbage out).https://it.wikipedia.org/wiki/Garbage_in,_garbage_out ↩︎