Progettare, confrontare e versionare i prompt

Il prompt decide il comportamento di una soluzione generativa, ed è anche l’unico pezzo di codice che spesso vive in una casella di testo del portale: senza autore, senza cronologia, senza test. Il blueprint AI-300 chiede tre mosse — progettarlo, confrontarne le varianti misurandone le prestazioni, versionarlo in Git — che sono una sola disciplina. La posta in gioco è la riproducibilità: dato un risultato di valutazione, si deve poter risalire al testo esatto che lo ha prodotto.

Progettare un prompt che si possa mantenere

Microsoft Foundry scompone un prompt in componenti ricorrenti: istruzioni, contenuto primario da trasformare, esempi, la cue che innesca la forma dell’output e il contenuto di supporto (data, nome utente, preferenze). A ciascuno corrisponde una tecnica.

Le istruzioni vanno all’inizio, prima di contesto ed esempi, e conviene ripeterle alla fine: i modelli soffrono di recency bias, cioè quello che sta in fondo pesa di più. La cue innesca il formato, per esempio chiudendo il prompt con l’inizio di un elenco puntato. La sintassi esplicita — separatori, intestazioni in maiuscolo, Markdown o XML — comunica l’intento e rende l’output più facile da parsare. Un compito complesso rende meglio se scomposto in passi; le affordance sostituiscono la memoria del modello con una fonte esterna, i cui risultati rientrano nel prompt. Il chain of thought vale per i soli modelli non di ragionamento: sugli altri, estrarre il ragionamento con metodi diversi dal parametro previsto non è supportato e può violare la policy d’uso.

Due tecniche pesano più delle altre in produzione. La prima è fornire dati di grounding ogni volta che il caso d’uso non è puramente creativo, il più vicino possibile alla forma finale della risposta. La seconda è specificare la struttura dell’output con citazioni in linea: chiedere la fonte accanto all’affermazione costringe il modello a sbagliare due volte per inventare. Conviene anche dargli una via d’uscita: rispondere che l’informazione non c’è. Su temperature e top_p, che controllano entrambi la casualità, se ne muove uno per volta. Attenzione: la documentazione dichiara che queste tecniche non sono raccomandate per i modelli di ragionamento, e il prompt resta legato alla famiglia su cui è tarato.

Confrontare le varianti in modo che il confronto dica qualcosa

Una variante è utile solo se cambia una cosa alla volta. Se modifica insieme testo di sistema, esempi few-shot e temperatura, il delta non è attribuibile. La disciplina è quella di un esperimento: si fissa il dataset di test — input, risposte attese, criteri di successo — e lo si congela, perché appena uno dei tre cambia le misure non sono comparabili. Poi si stabilisce la baseline eseguendo la variante corrente sul dataset congelato, e solo dopo si misura la candidata con gli stessi identici evaluator.

Le misure sono tre e vanno lette insieme: qualità (punteggi degli evaluator o revisione umana), latenza (tempo al primo token e throughput, isolati sulla chiamata che si cambia) e costo (token di input e output per richiesta). Un prompt che guadagna groundedness raddoppiando i token è un peggioramento travestito. Azure AI Evaluation SDK offre oltre trenta evaluator integrati — groundedness, relevance, retrieval, coherence, fluency, F1, BLEU, ROUGE, sicurezza, agent — più un LLM-as-judge personalizzabile.

Foundry offre anche un Prompt Optimizer, sotto le istruzioni di sistema nel playground degli agenti. È una bozza forte, non un verdetto: applica pratiche generali in un passaggio, non si adatta al vostro dataset e non conserva cronologia. Copiate l’originale prima di premerlo e rivalutate sul dataset congelato.

Lo strumento storico per orchestrare le varianti su Azure Machine Learning è prompt flow, che le dichiara in flow.dag.yaml insieme a input, output, nodi e tool. Va nominato perché il lessico dell’esame lo usa, con l’avvertenza di Microsoft: sarà ritirato il 20 aprile 2027, non è più raccomandato per nuovi sviluppi e le applicazioni esistenti vanno migrate a Microsoft Agent Framework.

Il prompt in Git, accanto al codice che lo usa

Versionare il prompt significa una cosa concreta: il testo sta in un file del repository, accanto al codice che lo invoca, e cambia solo con una pull request. Ne discendono la revisione sul diff, il ritorno indietro e un identificatore stabile — il commit — da allegare a ogni risultato di valutazione. Azure Machine Learning aiuta: un job sottomesso da una directory che è un repository Git locale registra repository, branch e commit fra le proprietà di sistema.

Il file del prompt contiene testo e segnaposto, mai segreti né stringhe di connessione: endpoint, nome del deployment e credenziali sono configurazione d’ambiente, risolta con Microsoft Entra ID e connessioni di progetto. È questa separazione a permettere di promuovere lo stesso prompt da dev a prod invariato.

Il passo finale è il confronto in continuous integration: nessuna variante arriva in produzione senza un numero accanto.

on:
  pull_request:
    paths: ["prompts/**", "eval/**"]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    permissions: { id-token: write, contents: read }
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: python eval/run_eval.py --baseline prompts/system_v3.md --candidate prompts/system_v4.md --dataset eval/golden.jsonl

Il workflow scatta sulle modifiche a prompts/ ed esegue baseline e candidata sullo stesso dataset: il revisore non discute di stile, legge i numeri.

Da ricordare per l esame

• Istruzioni all’inizio e ripetute alla fine per il recency bias, sintassi esplicita, compito scomposto, grounding e citazioni in linea; temperature e top_p uno alla volta.
• Le tecniche classiche di prompt engineering e il chain of thought non sono raccomandate per i modelli di ragionamento: il prompt resta legato alla famiglia su cui è tarato.
• Un confronto vale solo con una variabile alla volta, dataset e criteri congelati, baseline della variante corrente e gli stessi evaluator su entrambe; si leggono qualità, latenza e costo.
• Il Prompt Optimizer di Foundry non ha cronologia: si copia l’originale prima di usarlo e si rivaluta sul dataset congelato.
• prompt flow sarà ritirato il 20 aprile 2027 e non è raccomandato per nuovi sviluppi; la migrazione indicata è a Microsoft Agent Framework.