Qualche giorno fa ho scritto un approfondimento, partendo dal post di Nicola, sul tema del Prompt Chaining. Il post ha riscosso un discreto interesse come approccio e ha generato diverse discussioni su approcci e vantaggi. Tra queste interazioni ci sono stati due commenti in cui è emerso l’interesse per diversi approcci al prompting e ai diversi contesti in cui c’è bisogno di uno o altro approccio.

Il Prompt Engineering, tema interessante ma eccessivamente abusato in termini di narrativa, non è altro che “l’arte” di formulare richieste efficaci ai modelli di intelligenza artificiale (AI) al fine di ottenere risultati utili e pertinenti. Negli ultimi tempi sono emersi diversi approcci avanzati per guidare i modelli linguistici generativi (Large Language Models, LLM) in modo più strategico, ottimizzato e finalizzato ad uno scopo preciso.

Uno di questi è il Prompt Chaining, di cui ho parlato nel mio articolo , in cui l’output di ciascun prompt diventa l’input del successivo. Questo consente di scomporre compiti complessi in passi più piccoli e gestibili, migliorando efficacia e accuratezza delle risposte del modello. Come scrivevo, il prompt chaining “non è solo una tecnica per istruire meglio l’AI, ma può diventare una vera e propria architettura cognitiva”, un modo per strutturare il pensiero delle macchine in modo simile al nostro. In altri termini, si passa da un’interazione estemporanea a una strategia conversazionale articolata in più fasi.

Il prompt chaining è parte di una più ampia famiglia di tecniche di prompt engineering sviluppate per migliorare il dialogo con i modelli AI. In questo approfondimento ho dato maggiore dettaglio alle principali tecniche – dal zero-shot e few-shot prompting, al chain-of-thought e al framework ReAct, fino a metodologie differenti come il self-consistency, Tree of Thoughts e RAG (Retrieval-Augmented Generation).

Per ognuna troverete i principi di funzionamento, i contesti di applicazione più efficaci, i vantaggi e i limiti, includendo esempi o scenari d’uso pratici quando utili. L’obiettivo è fornire una panoramica tecnica ma accessibile a un pubblico eterogeneo di utilizzatori dell’AI (su diversi tool), condividendo spunti applicativi e indicando come queste tecniche possano contribuire a un’adozione più consapevole e proficua dell’intelligenza artificiale nelle organizzazioni.

Prompt Chaining (Catena di Prompt)

Cos’è e principi di base: Il Prompt Chaining consiste nel concatenare più prompt in sequenza, in modo che ogni fase guidi la successiva. Invece di porre al modello una singola richiesta molto complessa, si suddivide il compito in sotto-obiettivi: il modello produce un risultato parziale che viene poi utilizzato in un prompt successivo, e così via. Questa tecnica si basa sul principio della decomposizione del problema: affrontare un “elefante” un pezzo alla volta (parafrasando il detto, “tagliare l’elefante a pezzi e ragionare per passi”). Ad esempio, anziché chiedere direttamente “Scrivi un rapporto completo sull’andamento del mercato AI nel 2025”, si può procedere per passi: prima chiedere una scaletta dei punti chiave, poi far approfondire ogni punto, infine richiedere una sintesi finale. Ogni prompt nella catena si concentra su un sotto-compito specifico mantenendo il contesto generale, e guida il modello passo dopo passo. In questo modo l’AI “pianifica” internamente la soluzione, similmente a un flusso di lavoro umano strutturato.

Contesti di utilizzo efficaci: il prompt chaining è efficace quando il compito richiesto al modello è complesso, lungo o richiede diverse fasi logiche. Nella progettazione di contenuti articolati (es. corsi, documentazione, white paper), questa tecnica permette di mantenere coerenza e approfondimento senza sovraccaricare il modello con un’unica richiesta monolitica. In ambito educativo o formativo, ad esempio, si può usare un approccio “a catena” per sviluppare un corso: prima generare un elenco di moduli, poi i dettagli di ciascun modulo, poi esercizi per ogni modulo, ecc. Anche per analisi strategiche o problem solving multi-step, il chaining consente all’AI di seguire un ragionamento articolato invece di tentare di dedurre tutto in un solo passaggio. Questa metodologia trova applicazione ogniqualvolta si desideri avere maggiore controllo sul processo con cui l’AI arriva a una risposta, suddividendolo in tappe verificabili.

Vantaggi: scomponendo il problema, il prompt chaining riduce l’ambiguità e distribuisce lo sforzo cognitivo del modello su più interazioni. Ne derivano output più accurati e coerenti, poiché il modello può concentrarsi su un obiettivo specifico ad ogni passo. L’approccio iterativo consente di mantenere il contesto lungo tutta la conversazione e di raffinare progressivamente la risposta. Inoltre, ogni fase intermedia offre all’utente umano l’opportunità di correggere la rotta o aggiungere istruzioni, portando a un maggiore controllo sul risultato finale. Un ulteriore beneficio è legato all’ottimizzazione delle risorse: invece di generare un lungo testo potenzialmente ridondante o fuori fuoco, l’AI produce contenuti modulari più gestibili, ottimizzando l’uso della finestra di contesto (token) e riducendo il rischio di output incoerenti dovuti a contesti troppo lunghi.

Limiti: Il prompt chaining richiede una certa pianificazione e abilità nel disegnare la sequenza di prompt. È un processo più laborioso e dispendioso in termini di tempo e di chiamate al modello rispetto a un singolo prompt: ogni passo aggiuntivo comporta un’interazione separata (con relativo costo, se si utilizza un API a pagamento, e latenza). Inoltre, l’utente deve assicurarsi che il contesto venga passato correttamente da un prompt all’altro (ad esempio riassumendo brevemente le informazioni rilevanti nel prompt successivo, se la memoria del modello è limitata). Un rischio è l’errore propagato: se un passaggio intermedio genera un’informazione errata o fuorviante, questa potrebbe propagarsi nelle fasi successive. Mitigare questo rischio richiede intervento umano (controllo degli output intermedi) o strategie per ripristinare il corretto contesto in corsa. Infine, come tutte le tecniche iterative, il chaining può portare a output eccessivamente prolissi se ogni passo non è ben focalizzato, è importante definire chiaramente gli obiettivi di ciascun sottoprompt.

Esempio pratico: Un esempio semplice di prompt chaining è la generazione di un articolo complesso. Invece di chiedere direttamente all’AI l’intero articolo, si può procedere così:

1. Prompt 1: “Elenca i principali trend del mercato AI nel 2025 di cui parlare in un articolo.” – Output: lista di trend (es. adozione di LLM nelle imprese, regolamentazione AI, nuovi modelli open-source, ecc.).

2. Prompt 2: “Per ciascun trend identificato, forniscimi un breve paragrafo di spiegazione.” – Output: paragrafi esplicativi per ogni punto della lista.

3. Prompt 3: “Scrivi un’introduzione generale all’articolo che presenti l’argomento e i trend che saranno discussi.” – Output: introduzione coesa menzionando i trend.

4. Prompt 4: “Unisci il tutto in un articolo completo, assicurandoti che i paragrafi seguano l’ordine dei trend presentati e aggiungi una conclusione.” – Output: articolo finale strutturato e approfondito.

Ad ogni step, l’utente può controllare e affinare i risultati (ad esempio, aggiungendo un trend dimenticato, o correggendo un paragrafo poco chiaro) prima di passare allo step successivo. Questo processo in catena assicura che il risultato finale sia più organico e accurato rispetto a una singola generazione “one-shot”.

Zero-Shot Prompting

Cos’è e principi di base: Lo Zero-Shot Prompting si riferisce alla capacità di un modello di linguaggio di eseguire un compito senza che gli siano forniti esempi espliciti nella richiesta. In pratica, al modello viene data solo un’istruzione o domanda, confidando nelle conoscenze generali apprese durante l’addestramento per produrre la risposta corretta. Si parla di “zero-shot” (zero esempi) perché il prompt non include alcuna dimostrazione o caso specifico. Ad esempio, se vogliamo che il modello traduca una frase, in zero-shot è sufficiente scrivere: “Traduci in inglese: Oggi piove a dirotto.” senza fornire esempi di traduzione. Il modello tenterà comunque di eseguire il compito basandosi sulle sue conoscenze pregresse della lingua. Questo approccio sfrutta la generalizzazione del modello: i grandi modelli hanno visto talmente tanti dati durante l’addestramento che spesso possono dedurre come svolgere un compito nuovo solo dalla descrizione testuale del compito stesso.

Contesti di utilizzo efficaci: Il zero-shot è la modalità più immediata di interazione e risulta efficace quando:

• Il compito è semplice o comune, ad esempio traduzione, risposta a domande di cultura generale, riassunto di un testo breve, classificazione di sentiment di una frase, ecc., per cui il modello possiede già esperienza implicita. Ad esempio, un LLM può classificare il sentimento di “Questo film è uno spreco di tempo” come negativo anche senza esempi, perché ha appreso dal corpus cosa significa esprimere un giudizio negativo.

• Si dispone di poco contesto o dati da fornire al modello. In scenari in cui l’utente non ha esempi concreti da inserire, sfruttare la conoscenza intrinseca del modello è l’unica opzione.

• Rapidità e versatilità sono prioritarie: il zero-shot permette di ottenere una risposta immediata senza preparare prompt complessi, ed è adatto in applicazioni in tempo reale o prototipazione veloce. Ad esempio, per avere una risposta rapida a “Chi era il presidente degli USA nel 1990?” un prompt zero-shot diretto può bastare.

Vantaggi: I punti di forza del zero-shot prompting includono la semplicità e l’efficienza. Non è necessario preparare esempi o dati di riferimento, il che fa risparmiare tempo e risorse, rendendo questo approccio subito applicabile in molti contesti. Inoltre, mostra la versatilità del modello: con un’unica configurazione di addestramento, l’LLM può affrontare un’ampia gamma di compiti senza ulteriori interventi. In ambito operativo ciò significa poter rispondere a richieste diverse (dalla scrittura creativa al coding) semplicemente cambiando l’istruzione, senza dover riprogrammarlo. Un altro vantaggio è che si evita di biasare il modello con esempi potenzialmente fuorvianti: talvolta fornire esempi può indurre il modello a riprodurli pedissequamente; in zero-shot il modello genera ex novo basandosi solo sull’obiettivo descritto.

Limiti: Lo zero-shot spesso soffre di minore accuratezza o specificità rispetto ad approcci con esempi. La mancanza di esempi di riferimento può portare il modello a interpretare la richiesta in modo diverso da quanto l’utente intendeva, soprattutto se il prompt non è perfettamente chiaro. C’è una forte dipendenza dalla formulazione del prompt: una leggera ambiguità può condurre l’AI fuori strada, non avendo esempi cui ancorarsi. Inoltre, in compiti più complessi o di nicchia, il modello potrebbe fornire risposte superficiali o sbagliate, poiché senza esempi non ha indicazioni su come strutturare la soluzione. In sintesi, la qualità dell’output è variabile: alcuni LLM molto avanzati (es. GPT-4) riescono sorprendentemente a fare ragionamenti zero-shot, ma modelli meno sofisticati potrebbero fallire senza qualche guida aggiuntiva.

Esempio pratico: Un utilizzo tipico del zero-shot è porre domande dirette al modello. Ad esempio: “Spiega la differenza tra energia rinnovabile ed energia non rinnovabile.”  Senza fornire esempi, il modello dovrà attingere alla sua conoscenza generale per articolare una spiegazione. Se il modello ha una buona base, risponderà elencando cosa sono le energie rinnovabili (solare, eolica, ecc.) e non rinnovabili (combustibili fossili, nucleare tradizionale), evidenziando vantaggi e svantaggi, tutto basandosi sulla singola istruzione ricevuta. Se la domanda fosse più vaga (“Parlami dell’energia.”), il rischio zero-shot è di ottenere una risposta generica o non centrata sull’aspetto desiderato. Per questo, anche in zero-shot, spesso si cerca di rendere il prompt chiaro e specifico, ad esempio aggiungendo “in modo conciso e focalizzato sugli aspetti ambientali”. In assenza di esempi, ogni parola nel prompt conta per orientare la risposta.

Few-Shot Prompting

Cos’è e principi di base: Il Few-Shot Prompting è una tecnica in cui al modello vengono forniti uno o più esempi della richiesta all’interno del prompt, per guidarlo verso la risposta desiderata. In pratica, il prompt include sia l’istruzione sia alcune coppie di input-output di esempio (tipicamente 1 a 5 esempi, da cui “few”). Ad esempio, per insegnare al modello a rispondere con un certo stile, potremmo fornire due Q&A di esempio e poi porre una nuova domanda simile. Questo approccio sfrutta la capacità del modello di apprendimento contestuale: grazie agli esempi, l’LLM può dedurre il pattern di soluzione voluto e replicarlo per l’input nuovo. Il modello, in sostanza, viene “calibrato” sul momento tramite i prompt di esempio, senza necessitare di un addestramento esterno aggiuntivo.

Contesti di utilizzo efficaci: Il few-shot è indicato quando:

• Il compito è specifico o poco comune e vogliamo mostrare al modello esattamente il formato o il ragionamento atteso. Ad esempio, per far generare titoli creativi in rima per articoli, potremmo dare 2–3 esempi di titoli in rima.

• Si dispone di esempi rappresentativi della richiesta. In scenari aziendali, spesso si hanno storici o set di dati di riferimento (es. FAQ con domande e risposte). Includendone alcune nel prompt, il modello comprenderà meglio come deve rispondere in quello stile o dominio.

• Precisione e coerenza sono critiche. Il few-shot può drasticamente migliorare la pertinenza delle risposte rispetto al zero-shot. In applicazioni come customer support automatizzato, fornire esempi di domande dei clienti e risposte appropriate può far sì che il modello risponda in modo più accurato ai nuovi quesiti dei clienti (es. mostrando il tono e il livello di dettaglio giusto).

Vantaggi: Aggiungendo pochi esempi nel prompt, il modello si adatta rapidamente al contesto specifico, producendo risposte più accurate e contestuali. Si ottiene spesso una maggiore precisione perché il modello replica la logica o lo stile mostrato negli esempi. Il few-shot permette anche una certa flessibilità: con un piccolo insieme di dati di esempio, si “sposta” l’LLM su un dominio o task desiderato senza bisogno di costosi re-training o fine-tuning esterni. È come fornire un mini-brief al modello: in base a pochi casi, capisce meglio cosa fare. Inoltre, gli esempi aiutano a ridurre ambiguità ed errori: se la domanda da risolvere può essere interpretata in modi diversi, mostrare un esempio toglie dubbi su quale interpretazione sia corretta (il modello tenderà a imitare la soluzione data nell’esempio).

Limiti: Il principale costo del few-shot è la necessità di curare esempi di qualità. Preparare gli esempi pertinenti richiede tempo e competenza sul problema. Inoltre, inserire esempi nel prompt consuma spazio nella finestra di contesto del modello, limitando la lunghezza della richiesta o della risposta possibile (soprattutto con modelli con contesto ridotto). C’è poi la questione della varietà: se gli esempi forniti non coprono sufficientemente i diversi casi, il modello potrebbe generalizzare male. In alcuni casi può addirittura overfittare sugli esempi: ad esempio, se diamo 3 esempi tutti con la stessa risposta, il modello potrebbe rispondere sempre quella (anche quando non dovrebbe). È dunque cruciale che gli esempi siano rappresentativi e diversificati. Un altro limite è che il modello potrebbe copiare parti dell’esempio nella risposta (soprattutto se l’input nuovo assomiglia molto a un esempio): questo può introdurre errori se l’output dell’esempio non si applica esattamente al nuovo caso. In sintesi, il few-shot bilancia un miglioramento di performance con un aumento di complessità nella progettazione del prompt.

Esempio pratico: Poniamo di voler usare l’AI per classificare recensioni di prodotti come positive o negative. In zero-shot potremmo dire: “Etichetta la seguente recensione come positiva o negativa: ‘Il prodotto funziona malissimo, sono molto deluso’.” Il modello potrebbe capire, ma con few-shot faremo meglio. Costruiamo il prompt con esempi:

1. Prompt: Recensione: “Questo gadget è fantastico! Ha superato le mie aspettative.” Sentiment: Positivo. Recensione: “Purtroppo il dispositivo si è rotto dopo un giorno. Che spreco di soldi.” Sentiment: Negativo. Ora etichetta la seguente recensione “Il prodotto funziona malissimo, sono molto deluso.”

Fornendo questi esempi, l’AI apprende dal contesto come svolgere il compito: vede il formato Recensione -> Sentiment e i criteri (nel primo caso entusiasmo = Positivo, nel secondo caso problema grave = Negativo). Di conseguenza risponderà molto probabilmente “Negativo” per la recensione data, con maggiore affidabilità rispetto a zero-shot. Questo paradigma few-shot simula in miniatura quello che sarebbe un addestramento supervisionato, ma avviene interamente nel prompt.

Chain-of-Thought (CoT) Prompting

Cos’è e principi di base: Il Chain-of-Thought (CoT) prompting è una tecnica avanzata in cui si induce il modello a svolgere un ragionamento passo-passo esplicito per arrivare alla soluzione. Invece di limitarsi a fornire direttamente la risposta finale, al modello viene richiesto (in modo implicito o esplicito) di “pensare a voce alta”, elencando la sequenza logica di deduzioni o calcoli che conducono alla risposta. In pratica, il prompt incoraggia il modello a suddividere il problema complesso in passaggi intermedi risolvibili individualmente. Ciò può avvenire tramite istruzioni come “mostra il ragionamento” o con esempi di soluzione in cui viene illustrato il processo (“Prima fai questo calcolo, poi quest’altro, infine…”). L’idea alla base è che i LLM, se guidati a articolare un chain of thought, possano raggiungere una comprensione più profonda del problema e quindi risposte più corrette, simili a come un umano risolverebbe mostrando i calcoli su carta.

Contesti di utilizzo efficaci: Il CoT è particolarmente potente in compiti che richiedono logica, calcoli o multi-step reasoning:

• Problemi matematici o aritmetici a più operazioni: ad esempio, risolvere problemi di testo (“se Maria ha 5 mele e ne compra altre 3, quante mele ha?”) chiedendo al modello di procedere per passaggi (conta mele iniziali, aggiungi nuove mele, ecc.).

• Puzzle o problemi di logica (indovinelli, sillogismi, deduzioni): far esplicitare al modello le informazioni date e i passi per arrivare alla conclusione aiuta ad evitare salti logici errati.

• Domande di common sense o implicazioni: es. “Un pallone bucato può rimbalzare?” – inducendo il ragionamento (“Un pallone bucato perde aria, senza aria non può rimbalzare, quindi no”) si aumenta la probabilità di correttezza su questioni non banali.

• Pianificazione e scenari complessi: ad esempio chiedere al modello di elaborare una strategia marketing strutturata: col CoT si può ottenere che elenchi prima analisi, poi obiettivi, poi tattiche in ordine logico. In generale, il chain-of-thought è ideale in qualunque contesto dove una soluzione deve emergere da più step concatenati, permettendo al modello di “concentrarsi” su un passo alla volta.

Vantaggi: Far esprimere al modello una catena di pensieri porta diversi benefici. Innanzitutto migliora la coerenza logica dell’output: le risposte risultano più strutturate e fondate, soprattutto su problemi complessi che altrimenti il modello potrebbe affrontare in modo superficiale. Il CoT aiuta il modello a comprendere meglio la natura del problema, perché nel generare il ragionamento intermedio esso stesso “riscopre” i sotto-obiettivi necessari. Ciò conduce in genere ad una maggiore accuratezza finale. Un altro vantaggio cruciale è la trasparenza: vedere il ragionamento passo-passo fornisce agli utenti umani insight sul perché il modello arriva a una certa risposta, rendendo più facile individuare eventuali errori o passi poco convincenti. Questo aumenta la fiducia e consente di intervenire, se necessario, su uno specifico passo (ad esempio correggendo un calcolo intermedio sbagliato). Inoltre, la tecnica CoT ha dimostrato di estendere le capacità dei modelli sui task di ragionamento: ricerche hanno mostrato che LLM di media dimensione, se istruiti a fare chain-of-thought, possono risolvere problemi che altrimenti sbaglierebbero, raggiungendo performance paragonabili a modelli più grandi non-CoT.

Limiti: L’uso di chain-of-thought richiede solitamente prompt più complessi e aumenta la lunghezza delle risposte, quindi può rallentare il tempo di risposta e consumare più token. C’è un overhead computazionale nel generare tutti i passi intermedi. Inoltre, la formulazione del prompt CoT deve essere accurata: non tutti i modelli seguono l’istruzione di fare ragionamenti espliciti di default. Spesso si utilizzano frasi trigger (ad es. “Reason step by step:”) o esempi formattati in modo da indurre il comportamento. Se il prompt è mal concepito, l’LLM potrebbe elencare passi poco utili o addirittura allucinare ragionamenti sbagliati. Un altro aspetto è che CoT, pur migliorando la logicità, non garantisce infallibilità: il modello potrebbe comunque compiere errori in uno step, e questi errori comprometteranno la risposta finale (garbage in, garbage out). In alcuni casi, soprattutto con modelli più piccoli, abbiamo visto ragionamenti fittizi , il modello produce un chain-of-thought che sembra coerente ma porta comunque a una risposta errata. Infine, non tutti i problemi richiedono CoT: per domande semplici, forzare un ragionamento dettagliato può essere inefficiente. Bisogna dunque decidere caso per caso se vale la pena attivare questa modalità.

Esempio pratico: Consideriamo un problema matematico a parole: “In una fattoria ci sono 3 galline e 2 mucche. Quante zampe ci sono in totale?”. Un approccio chain-of-thought potrebbe essere innescato da un prompt come: “Rispondi passo-passo: prima calcola le zampe delle galline, poi delle mucche, e somma.”. Il modello allora potrebbe produrre:

• “Ogni gallina ha 2 zampe. Ce ne sono 3, quindi 3×2 = 6 zampe di gallina. Ogni mucca ha 4 zampe. Ce ne sono 2, quindi 2×4 = 8 zampe di mucca. In totale le zampe sono 6 + 8 = 14.” – Risposta: 14.

Qui vediamo il chain-of-thought esplicito. Senza questa guida, il modello potrebbe semplicemente dare una risposta (si spera 14), ma non mostrando il calcolo sarebbe difficile capire se l’ha ottenuta per via corretta o per fortuna. Con CoT, anche se il numero finale fosse sbagliato, l’utente può vedere dove il ragionamento ha fallito (ad esempio, se avesse calcolato male 3×2). Nell’uso pratico, CoT è risultato determinante per migliorare task di matematica, logica e persino comprensione di testi complessi, al punto che è diventata una delle tecniche standard per sfruttare al meglio i LLM in scenari di reasoning avanzato.

ReAct (Reasoning + Acting)

Cos’è e principi di base: ReAct è un paradigma che unisce il ragionamento (Reasoning) tipico del chain-of-thought con la capacità di agire (Acting) nell’ambiente esterno. Proposto da Yao. nel 2022, il framework ReAct prevede che il modello generi sia tracce di ragionamento verbale sia azioni specifiche per il task in modo intercalato. In pratica, durante l’elaborazione, l’LLM alterna pensieri e azioni: i pensieri sono passi di ragionamento interni, le azioni sono operazioni compiute all’esterno, come effettuare una ricerca, interrogare una base di conoscenza, eseguire un calcolo o chiamare un’API. Questa interazione avviene ciclicamente: il modello pensa -> compie un’azione -> ottiene un’osservazione dall’ambiente -> continua a pensare in base a quella nuova informazione, e così via. L’idea chiave è che combinando ragionamento e azione, l’AI possa iterare verso la soluzione integrando conoscenze esterne e aggiornando il proprio piano man mano.

Contesti di utilizzo efficaci: ReAct si rivela potente in scenari in cui il modello da solo non ha tutte le informazioni o capacità per completare il compito e deve interagire con strumenti o dati esterni. Ad esempio:

• Question answering su conoscenze aggiornate: se chiediamo “Chi è l’attuale CEO di <una certa azienda>?”, un LLM addestrato su dati vecchi potrebbe non sapere la risposta. Un agente ReAct potrebbe eseguire un’azione di ricerca sul web, leggere la pagina trovata (osservazione), poi rispondere in base alle info aggiornate.

• Risoluzione di problemi che richiedono calcoli o simulazioni: es. chiedere “Qual è la radice quadrata di 1048576?” – invece di far affidamento sulle sue capacità matematiche (che possono essere limitate o soggette a errori), il modello ReAct potrebbe invocare una calcolatrice esterna come azione, ottenere il risultato e poi comunicarlo.

• Interazione con ambienti o database: in un contesto di assistente personale, l’AI potrebbe dover controllare il calendario, inviare email, o eseguire azioni nel mondo reale. ReAct fornisce un quadro per farlo: il modello decide un’azione (ad es. “Apri calendario”), l’ambiente restituisce l’esito (“Calendario aperto, prossimi eventi…”), il modello ragiona e decide la prossima mossa.

• Task di decision-making complessi: ad esempio nella risoluzione di un mistero o di un gioco di avventura testuale, l’agente ReAct può pianificare (ragionamento) e testare mosse (azione) esplorando attivamente il problema.

Vantaggi: Il principale vantaggio di ReAct è che supera i limiti di conoscenza chiusa del modello, permettendo accesso a informazioni aggiornate o specifiche durante la generazione. Questo riduce drasticamente il fenomeno delle allucinazioni: se il modello può verificare fatti tramite azioni (es. cercare su Wikipedia), è meno incline a inventare risposte. ReAct inoltre migliora l’accuratezza fattuale e l’affidabilità delle risposte, come dimostrato da esperimenti che hanno visto l’agente ReAct superare approcci puramente basati su ragionamento o su azione isolate. Un altro benefit è la trasparenza e controllabilità: poiché il modello elenca i suoi pensieri e azioni, un osservatore umano può seguire passo passo il processo e intervenire se necessario (ad esempio, interrompere l’esecuzione di un’azione non voluta). In ambito applicativo, ReAct apre la strada a LLM “agenti” in grado di compiere operazioni utili: molti sistemi pratici (come i plugin di ChatGPT, o framework tipo LangChain) adottano proprio questo paradigma per far sì che l’AI consulti documenti, esegua codice o chiami servizi in base alla richiesta dell’utente. In sintesi, ReAct aumenta la capacità di problem solving del modello combinando il meglio di due mondi: il ragionamento interno e l’interazione con l’esterno.

Limiti: Implementare ReAct è complesso. Richiede definire una sorta di protocollo che il modello segua nei prompt, ad esempio una sintassi per distinguere Thought (pensiero) e Action e Observation (risultato dell’azione). Non tutti i modelli seguono facilmente questo schema – in genere si usano LLM molto obbedienti e capienti, e prompt di contesto con esempi di formato ReAct. C’è poi il tema della sicurezza: dare a un modello la possibilità di agire (eseguire codice, cercare online) comporta rischi; bisogna porre limiti sulle azioni possibili onde evitare comportamenti indesiderati. Un altro limite è la dipendenza dalla qualità degli strumenti esterni: se il sistema di ricerca fornisce risultati sbagliati o se un’API chiamata fallisce, l’agente potrebbe andare in stallo o prendere decisioni errate. Inoltre, orchestrare ragionamenti e azioni iterativamente può essere costoso in termini computazionali – ogni ciclo ragionamento/azione equivale a più chiamate modello + costi delle operazioni esterne. Vi è anche una maggiore possibilità di bug logici: l’agente potrebbe entrare in loop (continuare a cercare senza mai rispondere) o tentare azioni non supportate se il prompt non lo vincola bene. Infine, leggere e interpretare le osservazioni (ad esempio il contenuto di una pagina web) è vincolato alla finestra di contesto: bisogna spesso riassumere o filtrare i dati esterni prima di reinserirli nel prompt successivo.

Esempio pratico: Un caso concreto di ReAct è un assistente QA con accesso al web. Supponiamo l’utente chieda: “Quanti astronauti sono attualmente sulla Stazione Spaziale Internazionale?”. Un semplice LLM addestrato fino al 2021 non ha questa informazione aggiornata. Un agente ReAct potrebbe operare così:

• Thought: “La domanda richiede un dato aggiornato. Devo cercarlo online.”

• Action: Search("numero astronauti attualmente ISS")

• Observation: (il sistema di ricerca restituisce un risultato: una pagina Wikipedia o news con l’informazione).

• Thought: “Ho trovato un risultato che sembra pertinente, ora lo leggo.”

• Action: Open(URL_pagina)

• Observation: (testo della pagina: “… attualmente sulla ISS ci sono 7 astronauti …”).

• Thought: “Ora ho l’informazione, posso formulare la risposta.”

• Final Answer: “Al momento attuale, ci sono 7 astronauti a bordo della ISS.”

Durante questo processo, l’AI ha ragionato sui passi necessari e utilizzato strumenti (search e open web) per colmare le sue lacune di conoscenza. Tutto ciò avviene in pochi secondi e l’utente finale vede solo la risposta corretta con eventualmente la fonte. Questo esempio illustra come ReAct renda l’AI proattiva e affidabile per domande altrimenti fuori portata per un modello statico.

Nota: poichè mi è stato chiesto in aula, anche se il processo sembra simile al comportamento di ChatGPT 4o , parliamo di cose diverse:

• ReAct = paradigma di prompting (schema per orchestrare ragionamenti + azioni).
• ChatGPT-4o = modello multimodale, che può integrare o ispirarsi a logiche ReAct ma non è basato su di esso.

Self-Consistency

Cos’è e principi di base: La Self-Consistency è una tecnica avanzata che mira a migliorare la correttezza delle risposte del modello attraverso un approccio di aggregazione statistica dei ragionamenti. Proposta da Wang (2022), nasce come metodo per sostituire il tradizionale greedy decoding usato nel chain-of-thought con qualcosa di più robusto. In pratica, invece di generare una singola catena di ragionamento (che potrebbe essere fallace), si fa in modo che il modello ne generi molteplici varianti indipendenti, quindi si osservano le diverse risposte finali e si sceglie quella più comune – presumendo che sia la più correttapromptingguide.ailearnprompting.org. È un po’ come porre la stessa domanda a tanti “cloni” del modello e poi fare una votazione di maggioranza sulle risposte. L’idea è che il modello, seguendo vie diverse di pensiero grazie alla casualità nel processo di generazione, potrebbe arrivare a risposte differenti; tuttavia, se c’è una risposta oggettivamente corretta, è probabile che molte di quelle catene di pensiero convergano su di essa, rendendola la risposta più frequente.

Contesti di utilizzo efficaci: La self-consistency si applica in particolare a compiti con una sola risposta corretta ben definita, dove piccoli errori nel ragionamento possono portare a risposte sbagliate. Ad esempio:

• Problemi di matematica e aritmetica: un LLM anche con chain-of-thought può occasionalmente errare un calcolo. Facendogli risolvere lo stesso problema più volte (con variazioni stocastiche nel generare i passaggi), possiamo mitigare l’errore scegliendo il risultato più frequente, che statisticamente sarà quello giusto nella maggioranza dei casi.

• Logica e common sense: domande vero/falso, causali o di completamento logico dove il modello potrebbe indecidersi. Esempio: “Se ieri era lunedì, che giorno sarà domani?”. Alcune catene di ragionamento difettose potrebbero dare risposte errate, ma la maggior parte convergerà su mercoledì. La self-consistency prende quel consenso.

• QA a risposta chiusa: domande di conoscenza generale con risposta univoca. Se il modello è incerto può produrre risposte diverse (soprattutto con temperature più alte), ma con self-consistency possiamo filtrare il rumore.

• Situazioni in cui si valuta la affidabilità: la tecnica permette di assegnare una sorta di “confidence” alla risposta scelta (data appunto dalla percentuale di catene di pensiero che l’hanno prodotta). Questo può essere utile per sapere quando il modello è incerto (es. se c’è spaccatura tra due risposte, forse serve intervento umano).

Vantaggi: La self-consistency ha mostrato un netto aumento delle prestazioni del chain-of-thought su molti task di ragionamento complesso. Aggregando i risultati di molteplici chain, si elimina l’influenza di ragionamenti outlier o casuali: l’effetto è simile a quello di una committee di esperti che discutono, dove l’errore di uno può essere compensato dal corretto ragionamento di altri. In pratica, si riduce la varianza delle risposte del modello, ottenendo output più stabili e corretti. Sulle domande aritmetiche e di logica, questo metodo ha portato a risolvere correttamente problemi che un singolo CoT spesso sbagliava. Un altro beneficio è che non richiede modifiche all’addestramento del modello: è una tecnica di decoding, quindi applicabile in post-processing a qualunque LLM. Inoltre, fornisce una misura di sicurezza: se tutte le 10 catene di ragionamento danno risposte diverse, chiaramente il modello non è affidabile su quella query – informazione utile per decidere di non fidarsi o di riformulare la domanda.

Limiti: La self-consistency aumenta il costo computazionale in modo lineare con il numero di ragionamenti generati: se facciamo 10 “shot” di ragionamento per ogni domanda, stiamo usando 10 volte il modello. Questo la rende onerosa in situazioni di produzione a larga scala, salvo ottimizzazioni. Inoltre, scegliere la risposta più frequente funziona bene quando effettivamente c’è una risposta dominante corretta; ma se la domanda è ambigua o aperta, il concetto di risposta “consistente” perde significato. Ad esempio, su una domanda aperta (es. “Qual è un buon titolo per un romanzo di fantascienza?”), le risposte potranno essere tutte diverse e non ce n’è una “migliore” oggettivamente – in questi casi la self-consistency non si applica (o potrebbe addirittura essere controproducente scegliendo una risposta generica). Va notato poi che la qualità delle catene di pensiero iniziali è fondamentale: se il modello ha forti bias o lacune e tende a sbagliare sistematicamente un certo tipo di problema, generare più ragionamenti non aiuterà (tutti convergeranno sulla risposta sbagliata!). Quindi la self-consistency aiuta soprattutto quando il modello ha competenza sufficiente ma può incorrere in errori casuali. Infine, tecnicamente serve poter campionare diverse risposte: ciò implica impostare una temperatura di generazione > 0 e magari usare nucleus sampling per ottenere sufficiente diversità nelle chain – parametri che vanno tarati con cura per bilanciare diversità e qualità.

Esempio pratico: Immaginiamo di sottoporre al modello un piccolo indovinello matematico: “Quando avevo 8 anni, mio fratello ne aveva la metà. Ora che ho 14 anni, quanti anni ha mio fratello?”. Molti LLM tendono a rispondere frettolosamente “7” (sbagliato) se non ragionano bene. Con self-consistency, faremmo generare al modello magari 5 diverse spiegazioni/soluzioni. Esempio di possibili catene:

1. “Fratello aveva 4 quando io 8. La differenza età è 4. Ora ho 14, fratello 10.” → Risposta: 10.

2. “Differenza di 4 anni. A 14 anni, fratello 14-4=10.” → Risposta: 10.

3. “Io 8, lui 4. Gap 4. Io 14, lui 14-4=10.” → Risposta: 10.

4. “Se fratello metà di 8, aveva 4. Ora 14 e fratello 4+ (14-8)=10.” → Risposta: 10.

5. “Fratello età attuale? Forse 7.” → Risposta: 7.

Notiamo che 4 catene su 5 danno risposta 10, una dà 7. Facendo majority voting, la risposta consistente è 10 (che è quella corretta). In questo modo abbiamo evitato l’errore della catena #5. In effetti, studi hanno osservato che la majority vote di più catene aumenta notevolmente l’accuratezza in problemi aritmetici e di logica rispetto a singola risposta CoT. Naturalmente, è importante che ogni catena sia indipendente: tipicamente si ottiene ciò ripetendo la query con un diverso seed stocastico o fondendo la richiesta in prompt diversi (variazioni nell’esposizione del problema per stimolare percorsi differenti). La self-consistency incarna un principio semplice: più voci possono essere meglio di una, quando si tratta di affidarsi a un AI per ragionare.

Tree of Thoughts (ToT)

Cos’è e principi di base: Il Tree-of-Thoughts (ToT) è un framework di prompting che generalizza l’idea del chain-of-thought espandendola in forma di albero decisionale. Invece di sviluppare un singolo percorso lineare di ragionamento, il modello esplora più possibili ramificazioni di pensiero da uno stesso stato, un po’ come valutare diverse strade per risolvere un problema. Questo simula strategie cognitive umane in cui, di fronte a un problema complesso, consideriamo varie ipotesi o sottosoluzioni parallele prima di impegnarci in una. Nel prompting ToT, ad ogni step il modello può generare diversi “pensieri” alternativi (nodi figli), costruendo così un albero di stati. Si definiscono criteri per valutare i pensieri (ad esempio tramite una funzione di valutazione o chiedendo al modello di dare un punteggio a ciascuno) e una politica per esplorare l’albero (in profondità, in ampiezza, con tagli potati dei rami meno promettenti). Questo approccio incorpora anche meccanismi come il lookahead (guardare avanti alcuni passi per stimare dove porta un certo ramo) e la già citata self-consistency per valutare l’affidabilità di un ramo tramite generazioni multiple. In breve, ToT è ispirato alle tecniche di ricerca AI classiche (come gli algoritmi di tree search) applicate all’ambito generativo: il prompt engineering diventa orchestrazione di un search tree di pensieri.

Contesti di utilizzo efficaci: Il Tree-of-Thoughts è indicato per problemi di deliberate problem solving, ovvero situazioni in cui:

• Il percorso verso la soluzione non è unico o scontato e potrebbe richiedere di provare varie strade. Ad esempio, puzzle complessi, labirinti logici, giochi tipo scacchi o enigmi di pianificazione.

• È possibile valutare parzialmente una soluzione prima di completarla. Ad esempio, nella scrittura creativa ramificata: generare diversi possibili proseguimenti di una storia e poi scegliere quello più interessante per continuare la narrazione.

• Decision making con branching: scenari in cui ad ogni decisione ne conseguono altre (tipo choose your own adventure). Un sistema ToT può esplorare diverse sequenze di decisioni e identificare l’outcome ottimale secondo un certo criterio.

• Problemi che beneficiano di tentativi ed errori: in un chain-of-thought lineare, un errore incorrerebbe e bloccherebbe il risultato; in ToT, se un ramo fallisce, se ne possono percorrere altri. Ad esempio, risolvere un rompicapo dove bisogna combinare mosse diverse: l’AI può provare un certo ordine di mosse (ramo A) e se porta a un vicolo cieco, tornare indietro e provare un ordine diverso (ramo B).

Vantaggi: Il ToT aumenta notevolmente la capacità esplorativa del modello. Invece di vincolarsi a un singolo ragionamento che potrebbe essere subottimale, l’AI può considerare molteplici alternative, aumentando la probabilità di trovare una soluzione corretta o creativa. Questo porta ad una maggiore efficacia nei compiti di problem solving generali. Inoltre, consente di implementare comportamenti di backtracking: se un certo filone di pensiero non funziona, l’agente può tornare a un nodo precedente e percorrere un altro ramo, un po’ come farebbe un programmatore nel debug di un algoritmo o una persona nel risolvere un puzzle. Il risultato finale è che il modello con ToT può risolvere problemi che richiedono tentativi multipli, laddove un CoT lineare fallirebbe se il primo tentativo è errato. Un altro beneficio è la possibilità di inserire heuristiche di valutazione: ad esempio, per ogni stato intermedio si può far valutare al modello quanto è vicino alla soluzione o se le condizioni necessarie sono ancora soddisfatte. Queste euristiche guidano la ricerca nell’albero in modo più intelligente, concentrando gli sforzi sui rami promettenti. In letteratura si è visto che ToT può combinare con successo ragionamento e ricerca strutturata, portando l’AI più vicina a un processo deliberativo umano nel risolvere problemi complessi. La possibilità di lookahead e di rivedere decisioni rende le soluzioni più ottimizzate e ponderate.

Limiti: Il rovescio della medaglia è la complessità computazionale: un’esplorazione combinatoriale di pensieri cresce esponenzialmente se non limitata. Bisogna definire attentamente il branching factor (quanti pensieri alternativi generare per step) e la depth massima dell’albero, altrimenti si rischia un’esplosione di possibilità ingestibili. Anche con euristiche, il costo può essere molto elevato per problemi appena un po’ più grandi. Un altro limite è che orchestrare un ToT richiede un controllo fine che oggi non è nativamente supportato dai modelli: tipicamente si devono scrivere script esterni che interfacciano col modello generando e valutando i nodi. Questo è più complesso di un semplice prompt singolo o di un chain-of-thought lineare. Inoltre, la qualità dipende fortemente da come viene progettata la funzione di valutazione dei rami: se la valutazione è sbagliata, il modello potrebbe scartare il ramo giusto e seguire quelli sbagliati (analogia: local minima in una ricerca). Dal punto di vista dell’usabilità, ToT rende il comportamento dell’AI meno prevedibile in termini di tempo di risposta (potrebbe finire molto presto se trova subito un ottimo ramo, oppure esplorare a lungo se indecisa). Infine, per alcuni task creativi troppo aperti, la struttura ad albero può essere eccessiva: conviene in problemi con un obiettivo chiaro da raggiungere, meno in quelli dove non c’è un “goal” definito. In sintesi, il ToT è molto potente ma va applicato con criterio a problemi che ne giustificano la complessità e laddove altre tecniche più semplici (CoT, self-consistency) non bastano.

Esempio pratico: Un esempio intuitivo può essere un gioco di labirinto testuale: il modello deve trovare l’uscita descrivendo passo a passo il percorso. Con un chain-of-thought tradizionale, l’AI potrebbe fare un tentativo lineare e se sbaglia strada arrivare a un vicolo cieco senza sapere come “tornare indietro”. Con Tree-of-Thoughts, invece, l’approccio sarebbe:

• Stato iniziale: stanza di partenza.

• Pensieri possibili: “vai a sinistra”, “vai a destra”, “vai avanti”.

  • Se “vai a sinistra” porta a un vicolo cieco (dopo qualche passo di esplorazione), quel ramo viene chiuso.

  • Si torna al nodo iniziale e si prova “vai a destra”.

• Si esplorano così diversi percorsi come rami. Magari “vai a destra” -> “poi avanti” -> “poi sinistra” porta all’uscita. Il sistema lo individua come ramo di successo.

Durante la ricerca, il modello può avere una euristica: ad esempio, ogni volta che descrive la posizione attuale, può valutare se sembra più vicina all’uscita (magari l’uscita è descritta come “luce visibile” e solo in alcuni rami appare questo dettaglio). Usando questa valutazione, l’algoritmo può potare i rami che sembrano allontanarsi dall’uscita e approfondire quelli promettenti. In ambito accademico, Yao et al. (2023) hanno dimostrato che Tree-of-Thoughts può risolvere puzzle e problemi di pianificazione che i normali LLM faticano a completare, evidenziando come questa tecnica renda l’AI più vicina a un problema solver generale deliberativo. Anche se attualmente è una frontiera sperimentale, illustra il potenziale delle future interfacce di prompt engineering: non solo chat o singole richieste, ma vere e proprie esplorazioni guidate delle capacità del modello.

Retrieval-Augmented Generation (RAG)

Cos’è e principi di base: La Retrieval-Augmented Generation (RAG) è una tecnica che combina i modelli generativi con sistemi di recupero di informazioni esterne per migliorare accuratezza e attualità delle risposte. In un flusso RAG tipico, alla domanda dell’utente l’AI effettua prima una ricerca in una base di conoscenza (database, documenti, web, ecc.) per recuperare i contenuti più pertinenti, e poi genera la risposta condizionata su quei contenuti. In altre parole, il modello non si affida solo alla conoscenza immagazzinata nei propri parametri, ma la integra con informazioni fresche o specifiche prelevate al momento. Questa tecnica può essere vista come un “open book approach” in cui il modello ha un libro aperto (la knowledge base) da cui può consultare i fatti prima di rispondere, invece di rispondere “a memoria”. RAG non è un singolo algoritmo ma un’architettura: tipicamente coinvolge un componente di retriever (spesso un motore di ricerca semantica o un indice vettoriale) e un componente di reader/generator (l’LLM) che utilizza i risultati della ricerca per formulare l’output.

Contesti di utilizzo efficaci: RAG è indicato praticamente ogni volta che:

• Si richiedono informazioni fattuali aggiornate o di dominio specifico che il modello potrebbe non conoscere di suo. Ad esempio domande su eventi accaduti dopo la data di addestramento del modello (es: “Chi ha vinto l’Oscar come miglior film nel 2024?”), o domande molto specialistiche (es: “Qual è la formula chimica del tal farmaco presente nel database X?”).

• Document QA: l’utente vuole interrogare una collezione di documenti (manuali, contratti, articoli scientifici). Un sistema RAG può cercare nei documenti rilevanti e poi rispondere citando le parti trovate.

• Chatbot aziendali su conoscenza interna: per costruire un assistente che risponde su policy aziendali, schede prodotto, dati interni, è impensabile addestrare ex-novo un modello su quei dati (troppo costoso e rischioso). RAG consente di mantenere un corpus di documenti aziendali e far sì che l’AI li consulti al volo per rispondere ai dipendenti o clienti con riferimenti precisi.

• Assistenza decisionale: in cui vogliamo che l’AI fornisca non solo un’opinione, ma anche le fonti. Esempio: “Mi consigli un investimento azionario?” – un assistente RAG potrebbe recuperare gli ultimi dati di mercato e notizie sulle aziende prima di elaborare una risposta, così da essere fondato su evidenze.

Vantaggi: Il RAG migliora significativamente l’accuratezza e l’affidabilità delle risposte, perché le ancora su fonti reali. Questo riduce le allucinazioni: invece di inventare, il modello può dire cose come “Secondo <documento X> …” riportando contenuti veritieri. Un grande vantaggio è la capacità di aggiornamento: la knowledge base può essere costantemente aggiornata (pensiamo alle notizie del giorno, o ai dati di vendita settimanali) senza dover ri-addestrare il modello AI. Ciò risolve uno dei limiti principali degli LLM statici, ossia la loro conoscenza ferma alla data di training. Inoltre, RAG consente trasparenza e verificabilità: spesso i sistemi RAG forniscono le fonti a corredo della risposta (ad esempio citazioni o link ai documenti da cui hanno tratto l’informazione). Questo è fondamentale per la fiducia: l’utente può controllare e confermare se la risposta è supportata da fonti autorevoli. Dal punto di vista pratico, RAG è efficiente: evita di dover ingurgitare nel prompt una mole enorme di contesto (si recupera solo ciò che serve) e scala meglio, perché si può aumentare il knowledge store senza appesantire il modello stesso. Infine, RAG diminuisce il bisogno di training continuo dell’LLM su nuovi dati: l’azienda può mantenere un repository delle informazioni e l’LLM rimane generale, interrogando quel repository. Ciò comporta benefici economici (meno fine-tuning) e anche di sicurezza: i dati sensibili rimangono nel database e non necessariamente dentro i pesi del modello, riducendo il rischio che l’AI li “trapeli” in output inappropriati.

Limiti: Un sistema RAG è più complesso di un modello standalone: bisogna avere un buon modulo di retrieval. Se la ricerca fallisce (ad esempio non trova i documenti giusti o recupera testi irrilevanti), la generazione sarà scadente. Quindi, la qualità delle risposte dipende fortemente dalla qualità dei dati e dell’indicizzazione. Inoltre, l’LLM deve essere capace di integrare bene le informazioni recuperate: c’è il rischio che ignori le fonti (specialmente se non opportunamente istruito) e dia comunque una risposta di fantasia, oppure che le usi male (ad esempio citando un fatto fuori contesto). Bisogna quindi affinare i prompt in modo che il modello “legga e utilizzi” effettivamente i documenti forniti. Un’altra sfida è gestire informazioni contraddittorie: se il retriever pesca documenti discordanti, il modello potrebbe confondersi o dover decidere quale è corretto – cosa non banale. Sul piano computazionale, c’è un overhead dovuto al retrieval (che può implicare ricerca full-text o vettoriale su larga scala) e alla necessità di inserire i testi trovati nel prompt di generazione (consumando token). Per knowledge base piccole è trascurabile, ma su scala web o di grandi dataset ciò richiede infrastrutture robuste (motori di ricerca interni, embedding semantici, ecc.). Dal punto di vista dell’utente, RAG introduce una dipendenza: serve mantenere aggiornata e di qualità la base di conoscenza, il che comporta un lavoro continuo (ad esempio upload di nuovi documenti, pulizia di quelli obsoleti). In sintesi, RAG sposta parte del problema dall’AI ai dati: “garbage in, garbage out” rimane vero – se i documenti sono sbagliati o mancanti, l’AI non potrà fare miracoli.

Esempio pratico: Un esempio comune è l’integrazione di GPT con Wikipedia. Immaginiamo una domanda: “Qual è la capitale più popolosa del mondo e qual è la sua popolazione?”. Un LLM standard potrebbe sapere che è Tokyo (metropoli) o Beijing a seconda di come interpreta, ma potrebbe confondersi o non avere dati precisi di popolazione. Un sistema RAG farebbe:

1. Query di ricerca: estrarre le keyword “capitale più popolosa mondo popolazione” e cercare in Wikipedia (o in un indice apposito).

2. Documenti recuperati: ad esempio la pagina “Tokyo” o una classifica di città per popolazione.

3. Prompt generativo: fornire all’LLM un contesto tipo: “Usa le seguenti informazioni per rispondere: [estratto della pagina Tokyo con dati popolazione] [estratto pagina sulle megalopoli] Domanda: Qual è la capitale…?”.

4. Risposta generata: “La capitale più popolosa del mondo è Tokyo, con una popolazione di circa 37 milioni di abitanti nella sua area metropolitana.” (L’AI include magari la citazione della fonte se configurato per farlo).

Notiamo che la risposta è ora grounded: l’AI non ha inventato il dato, l’ha preso dalla fonte. Ciò è verificabile e, salvo errore nella base, corretto. In questo caso RAG ha permesso al modello di superare un limite (i dati demografici esatti) recuperando l’informazione aggiornata. Sistemi come Bing Chat, il motore di ricerca di Bing con GPT-4, funzionano essenzialmente in questo modo: eseguono ricerche sul web e poi generano risposte combinando i risultati, citando le fonti. Anche in ambito enterprise, soluzioni di cognitive search e assistenti su documenti aziendali adottano RAG per garantire che l’AI dica cose supportate dai documenti forniti. In definitiva, RAG rappresenta un approccio pragmatico per unire la capacità generativa dei LLM con la precisione dei sistemi di ricerca, ottenendo il meglio da entrambi.

Ci sono prompt per tutto, ma non un prompt per tutti.

Le tecniche di prompt engineering, dal prompt chaining alle varianti zero-shot e few-shot, fino ai metodi di ragionamento avanzati come chain-of-thought, ReAct, self-consistency, tree-of-thoughts e all’integrazione con fonti esterne via RAG, mostrano che oggi abbiamo a disposizioen una sorta di cassetta degli attrezzi per ottenere il massimo dai modelli di intelligenza artificiale.

Ciascuna tecnica ha i propri punti di forza e i propri ambiti d’elezione, ma tutte condividono un principio fondamentale: guidare e strutturare l’interazione con l’AI in modo da allineare l’output agli obiettivi dell’utente. In un certo senso, il prompt engineering ci insegna che porre le giuste domande (e farlo nel modo giusto) è tanto importante quanto la potenza del modello stesso.

Dal punto di vista strategico, il ruolo del prompt engineering appare sempre più centrale per un’adozione consapevole dell’AI.

Senza tecniche adeguate, un modello generativo rischia di essere percepito come una “scatola magica” dalle risposte imprevedibili, il che ne limita la fiducia e l’utilità. Al contrario, approcci come il prompt chaining trasformano l’AI in un collaboratore logico, che segue processi trasparenti e verificabili, sui quali possiamo intervenire in itinere. Questo approccio aumenta la fiducia degli utenti e amplifica il valore dell’AI nell’operatività quotidiana, perché si passa da output grezzi a risultati più affidabili e raffinati.

In sostanza, il prompt engineering unisce il meglio del pensiero umano (analitico, strutturato, consapevole degli obiettivi) con la velocità e versatilità di calcolo dell’IA, offrendo il meglio di entrambi i mondi.

Per capitalizzare queste opportunità, diventa importante sviluppare nuove skill conversazionali e progettuali:

• Conversazionali perché interagire con un’AI è un po’ come dialogare in un linguaggio speciale: saper formulare richieste precise, dare il giusto contesto, suddividere i problemi e persino “pensare” in termini utili per la macchina sono abilità da coltivare.
• Progettuali perché occorre saper progettare i prompt e i flussi di prompt come si progettano soluzioni software: con logica, modularità, e attenzione all’utente finale. Figure professionali come il Prompt Engineer stanno emergendo proprio per colmare questo spazio, combinando competenze di linguistica, programmazione e design delle informazioni. Ma al di là dei ruoli dedicati (e considerato che non credo alle etichette) è auspicabile che un po’ tutti, dai manager ai creativi, sviluppino almeno in parte queste competenze.

L’adozione consapevole dell’AI significa infatti comprendere quando e come coinvolgere l’intelligenza artificiale nei processi decisionali e creativi, conoscendone i limiti (bias, allucinazioni, esigenze di contesto) e le potenzialità (velocità, capacità di sintesi, generazione di alternative). Il prompt engineering funge da interfaccia critica in questo rapporto uomo-macchina: è lo strumento che ci permette di tradurre gli obiettivi strategici in istruzioni operative per l’AI, e di incanalare l’output dell’AI in risultati di valore. Man mano che i modelli diverranno più potenti e diffusi, il prompt engineering evolverà di pari passo, potenzialmente automatizzando alcune parti (ad es. con sistemi che suggeriscono come formulare i prompt) ma richiedendo comunque una supervisione e una creatività umana nel definire problemi e interpretarne le soluzioni.

Investire del proprio tempo in sperimentazione di prompt e analisi, vuol dire investire in alfabetizzazione AI: imparare a “parlare” con le macchine intelligenti in modo efficace. Così come l’avvento dei computer ha reso importante saper programmare o utilizzare certi software, l’era dell’AI generativa renderà fondamentale saper orchestrare conversazioni e flussi con i modelli. Le aziende che svilupperanno per tempo queste capacità potranno sfruttare l’AI in modo più affidabile e innovativo, mentre gli individui che le coltiveranno diventeranno preziosi facilitatori tra tecnologia e business.

Guidare l’AI con consapevolezza e metodo è la chiave per integrarla come alleato nei nostri processi – un alleato veloce, instancabile e creativo, ma che necessita della giusta guida umana per dare il meglio di sé. In questo equilibrio di ruoli risiede il futuro di una collaborazione uomo-AI realmente efficace e fidata.