Prompt Compilato: progettare output complessi senza perdere coerenza - Cefriel

Un modello linguistico, per impostazione predefinita, genera token in sequenza: legge il contesto, produce un output, attende il prossimo input. Ogni risposta è il risultato di una decisione locale, presa nel momento stesso in cui viene emessa. Questa modalità funziona bene per la maggior parte dei compiti conversazionali, ma produce incoerenza quando il task richiede che decine di output successivi rispettino simultaneamente vincoli interdipendenti.

Il Prompt Compilato è un’architettura di prompting che risolve questo problema spostando il momento decisionale. Invece di decidere output per output, il modello riceve istruzioni per pianificare l’intera sequenza di output prima di emetterne uno solo. Solo dopo che la pianificazione è completa, l’esecuzione inizia.

Il nome deriva dall’analogia con la compilazione del codice: un compilatore non esegue le istruzioni una alla volta mentre le legge, ma prima costruisce una rappresentazione interna dell’intero programma, verifica la coerenza e poi genera il codice eseguibile. Un Prompt Compilato chiede al modello di fare lo stesso: compilare il piano, validarlo internamente, poi eseguirlo passo dopo passo.

Il risultato è un comportamento che assomiglia a quello di un sistema deterministico a stati definiti, non a quello di un generatore conversazionale.

1. Gate di configurazione
Il primo componente è un blocco esplicito che impedisce qualsiasi azione prima che il contesto necessario sia raccolto. Il gate non è una lista di domande: è una regola di blocco formulata in negativo, che enumera le azioni vietate finché le variabili di configurazione non sono note.
La formulazione in negativo è intenzionale. Elencare cosa non fare è più preciso di descrivere cosa aspettarsi. Il modello sa esattamente quali azioni sono bloccate, senza doverlo inferire.
Le variabili raccolte dal gate non sono preferenze estetiche. Sono parametri che cambiano la logica di generazione e che, se assunti erroneamente, richiedono di riscrivere il piano a metà esecuzione.

2. Batch planning con scheda interna
Il secondo componente è la pianificazione anticipata di tutti gli output. Prima di produrre il primo elemento della sequenza, il modello costruisce internamente una scheda completa per ogni elemento: il contenuto, la tipologia, il livello di difficoltà, la risposta attesa, i metadati rilevanti, la presenza o assenza di componenti accessori.
La scheda interna ha una funzione precisa: separare la fase di selezione dalla fase di esecuzione. Il contenuto scelto nella fase di pianificazione è fisso. Al momento di produrre il singolo output, il modello non ri-seleziona: attinge alla scheda già compilata. Questo elimina la deriva progressiva, cioè il fenomeno per cui le scelte negli output finali della sequenza divergono rispetto ai primi per effetto dell’accumulo di contesto e delle micro-decisioni intermedie.
La regola correlata (leggere la knowledge base una sola volta) non è solo un’ottimizzazione di latenza. Garantisce che tutte le schede siano costruite a partire dalla stessa istanza della fonte di dati.

3. Vincoli gerarchici con fallback espliciti
Il terzo componente è un sistema di regole organizzato in gerarchia, con una catena di sostituzione definita per ogni punto di fallimento.
Due regole possono sembrare contraddittorie se lette isolatamente. Coesistono senza conflitto quando il prompt definisce la precedenza: la regola più forte annulla la più debole nel suo dominio di applicazione. I due domini non si sovrappongono; il prompt li delimita esplicitamente.
Per ogni regola bloccante, il Prompt Compilato definisce la catena di sostituzione: cosa fare quando il vincolo non può essere rispettato. Nel caso esemplificativo della gestione delle immagini:

1. Sostituire il segnale con uno per cui esiste un asset coerente.


2. Riformulare il contenuto senza riferimento all’elemento mancante.


3. Usare una formulazione generica non dipendente dall’asset.

L’ultimo elemento della catena è sempre una via d’uscita che non compromette la coerenza con l’utente. Il prompt specifica anche cosa questa via d’uscita non deve produrre: un output che presuppone un elemento che l’utente non vede. La lista delle formulazioni proibite è esaustiva, non esemplificativa.

4. Checklist pre-invio integrata nel flusso
Il quarto componente è una sequenza di verifica che il modello esegue prima di emettere ogni output. La checklist è numerata, a risposta binaria, e ha una regola di arresto chiara: se una sola condizione fallisce, l’output non viene inviato. Il modello rigenera, poi invia solo la versione che supera tutti i controlli.
La differenza tra una checklist integrata e un principio generale di qualità è questa: il principio generale non specifica il momento in cui verificare né cosa fare se la verifica fallisce. La checklist specifica il momento, i criteri e l’azione di fallback. Questo trasforma una linea guida in un vincolo eseguibile.

Un effetto collaterale ben progettato del Prompt Compilato è il riuso dei dati strutturali per scopi multipli.

Nel caso esemplificativo, un campo della knowledge base che descrive le zone di ambiguità di un concetto (le confusioni tipiche associate a un segnale stradale) svolge due funzioni operative distinte, entrambe obbligatorie.

La prima è generativa: costruire contenuti sfidanti. Un item falso, costruito su una confusione documentata, ha valore pedagogico; uno costruito per una grossolana inversione è trasparente e inutile.

La seconda è preventiva: prima di mostrare un asset visivo, il modello confronta il contenuto scelto con le zone di ambiguità documentate per verificare che l’immagine non risulti confondibile. Se lo è, l’asset non viene mostrato. Questi sono tutti ragionamenti che vengono forzati nel modello, ma non mostrati: dietro righe di testo come “costruisci internamente tutte le domande prima di mostrarne una” oppure “decidi in anticipo quali domande avranno immagine” si nasconde una complessità del modello davvero notevole.

Questo è un pattern generale, non specifico del dominio: un campo che descrive l’ambiguità di un concetto può essere usato sia per generare contenuto che mette alla prova quella ambiguità, sia per validare la precisione degli asset associati a quel concetto.

Nel concludere questa discussione, conviene riassumere le principali caratteristiche di un Prompt Compilato, lasciando poi il dettaglio all’appendice, che lo riporta integralmente.

Non è un prompt lungo. La lunghezza è un effetto collaterale della precisione, non una proprietà costitutiva. Un prompt di venti righe può implementare la stessa architettura se include gate, pianificazione anticipata, gerarchia dei vincoli e checklist.

Non è una catena di pensiero (chain-of-thought). Il CoT chiede al modello di ragionare ad alta voce prima di rispondere. Il Prompt Compilato chiede al modello di pianificare internamente, senza esporre il piano all’utente. Le schede di pianificazione, il bilanciamento calcolato, i segnali selezionati: nulla di questo è visibile nell’output. L’utente vede solo il risultato dell’esecuzione.

Non è un agente. Gli agenti decidono dinamicamente il passo successivo in base al risultato del passo precedente. Il Prompt Compilato pianifica l’intera sequenza prima di iniziare. Il piano può includere parametri di aggiustamento dinamico (come l’adattamento della difficoltà in base agli errori), ma questi sono variabili della pianificazione, non decisioni architetturali prese a runtime.
Inoltre, vale la pena di ricordare che con i prompt e le LLM in generale, il risultato non è del tutto deterministico. Nonostante le istruzioni scritte, l’AI può comunque decidere di intraprendere strade alternative. La bontà della “gabbia logica” impostata dal prompt consente di mantenere queste derive entro certi limiti, ma non le impedisce del tutto. Basta confrontare, ad esempio, il comportamento tra due modelli sostanzialmente differenti: ChatGPT Plus e ChatGPT gratis. Il primo è un modello ottimizzato per seguire le istruzioni e quindi adatto a contesti di prompting professionali, mentre il secondo è ottimizzato per parlare soprattutto e, di fatto, segue in modo approssimativo prompt complessi come questo. Ho scelto proprio il caso d’uso perché il livello di allucinazione risultasse evidente fin da subito, come nel caso riportato di seguito. Per risolvere questo livello residuo di allucinazioni, il prompt dovrebbe diventare ancora più complesso, oppure bisognerebbe aggiungere uno strato di controllo separato prima di mostrarlo all’utente.