Rollout controllato: feature flag, A/B test, fallback umano

Cambiare un prompt in produzione può cambiare comportamento tanto quanto modificare codice. Può aumentare costo, ridurre latenza, peggiorare un segmento di utenti, rompere output JSON, cambiare tono o introdurre falsi positivi.

Per questo i prompt vanno rilasciati con rollout controllato: flag, gruppi pilota, metriche, soglie di stop e fallback.

Perché questa lezione conta

Molti team fanno eval offline, poi sostituiscono il prompt per tutti. L’eval è necessario, ma non basta. La produzione contiene input diversi, utenti diversi, carichi diversi e casi che il dataset non copre ancora.

Un rollout controllato riduce il danno massimo e crea una finestra di osservazione. L’obiettivo non è rallentare ogni modifica, ma impedire che un cambio apparentemente piccolo diventi un incidente.

Obiettivo operativo

Alla fine della lezione devi saper progettare un piano di rilascio per prompt, modello o tool: chi lo vede, cosa misuri, quando torni indietro e quale fallback protegge l’esperienza.

Feature flag

Un feature flag per prompt può controllare:

1. versione del template;
2. modello;
3. parametri;
4. tool disponibili;
5. schema output;
6. fallback;
7. percentuale di traffico.

Esempio:

flag: classify_ticket_prompt_v2
default: off
target:
- team interno: 100%
- tenant beta: 20%
- tutti gli altri: 0%
rollback:
- tornare a v1 senza deploy

Il rollback deve essere rapido. Se per tornare indietro serve una release applicativa lenta, il flag non sta facendo il suo lavoro.

Sequenza di rollout

Una sequenza pragmatica:

1. eval offline su dataset minimo;
2. test interno con casi reali redatti;
3. shadow mode, se possibile;
4. beta limitata;
5. aumento percentuale;
6. adozione default;
7. rimozione vecchia versione dopo finestra di stabilità.

In shadow mode la nuova variante produce output ma non guida l’esperienza utente. È utile per confrontare senza rischio diretto, soprattutto su classificazioni o suggerimenti.

A/B test onesto

Un A/B test serve solo se definisci prima la decisione. Non basta guardare dashboard finché una curva sembra migliore.

Decidi:

1. metrica primaria;
2. metriche di guardrail;
3. segmento di traffico;
4. durata minima;
5. soglia di miglioramento;
6. soglia di rollback;
7. casi in cui serve review umana.

Per una classificazione ticket:

primaria:
- accuratezza su casi revisionati

guardrail:
- costo medio per ticket <= +15%
- latenza p95 <= 3s
- needs_human_review non oltre +5%
- nessun aumento su categorie security errate

La metrica primaria da sola può ingannare. I guardrail proteggono costi, UX e casi critici.

Fallback umano

Il fallback umano non deve essere una scusa per scaricare tutto al team. Deve attivarsi in condizioni precise:

1. confidence bassa;
2. output non valido;
3. categoria ad alto rischio;
4. input fuori distribuzione;
5. budget superato;
6. tool non disponibile;
7. policy violata.

L’utente o l’operatore deve vedere perché il caso è arrivato a review. Un fallback che dice solo “controllare manualmente” crea carico inutile.

Fallback deterministico

Quando il task lo permette, preferisci regole deterministiche per casi semplici:

1. validazione schema;
2. regex per pattern noti;
3. regole business;
4. template statico;
5. risposta cacheata;
6. blocco con richiesta di input aggiuntivo.

Non tutto deve passare dal modello. Un buon sistema LLM sa anche quando non chiamare l’LLM.

Soglie di rollback

Le soglie vanno scritte prima:

Rollback immediato se:
- output non parsabile > 2%;
- costo medio > +30%;
- latenza p95 > 6s;
- errore su categoria security confermato;
- fallback umano > +20% per due ore.

Senza soglie, la discussione avviene durante l’incidente, quando i dati sono incompleti e la pressione è alta.

Laboratorio guidato

Scegli un prompt già versionato. Scrivi un piano di rollout:

1. cosa cambia nella nuova versione;
2. eval offline richiesto;
3. flag e segmenti;
4. metriche primaria e guardrail;
5. soglie rollback;
6. fallback umano o deterministico;
7. durata osservazione;
8. criterio di promozione a default.

Poi simula tre scenari: costo alto, qualità migliore ma latenza peggiore, errore critico su segmento piccolo.

Output atteso

Devi produrre una checklist di rilascio:

release | prompt_version | flag | target | metriche | guardrail | fallback | rollback | owner

Questa checklist va allegata al PR o alla nota di rilascio interna.

Errori comuni

Cambiare prompt e modello insieme. A volte serve, ma rende il confronto meno leggibile.

Guardare solo la media. I casi rari e critici possono sparire nella media.

Non avere rollback rapido. Un flag senza rollback pratico è controllo solo nominale.

A/B test senza ipotesi. Se non sai cosa vuoi dimostrare, troverai sempre una metrica favorevole.

Checklist di verifica

• il rollout ha flag o meccanismo equivalente;
• esistono metriche primaria e guardrail;
• il rollback è rapido e testato;
• il fallback è definito prima del rilascio;
• la decisione di promozione è scritta.

Collegamenti

• Modulo: Prompt in produzione e governance — questa lezione è la numero 38 del corso.
• Riprende evaluation, regressioni, budget e osservabilità dei moduli precedenti.