Il test di simmetria: distribuire una correzione del prompt che non puoi riprodurre

Non sempre puoi dimostrare che una correzione del prompt funzioni. Alcuni fallimenti in produzione compaiono solo con il contesto completo che li ha prodotti, e nessuna fixture offline li riproduce. In questi casi, la domanda onesta non è "la correzione funziona?" ma "la mia modifica è distinguibile dalla varianza variabile del modello tra esecuzioni successive?". Se la risposta è no, la modifica è sufficientemente sicura da distribuire anche se non l'hai mai vista correggere effettivamente il bug. Chiamiamo questo controllo test di simmetria, ed è così che una modifica al prompt che non siamo mai riusciti a far fallire ha superato il nostro controllo.

Tutto ciò che segue deriva da una valutazione interna, datata 2026-07-09, eseguita su GLM-5.2, il modello che utilizziamo per la chat: una suite di regressione A/B alla cieca sull'intera superficie della chat. Le metriche sono nostre, misurate sui nostri dati di test, in quella data.

Il bug che non si riproduceva

In una settimana abbiamo rilevato due difetti nella generazione di documenti in tedesco relativi a output di policy. Nel primo caso, l'assistente ha fornito una policy le cui sezioni di primo livello erano numerate da 2 a 6 senza alcuna sezione 1. Nel secondo caso, un allegato referenziato non è mai stato ricevuto dal modello, e invece di segnalarlo, l'assistente ha inventato una versione "revisionata" distorta che il lettore ha interpretato come una massiccia troncatura, senza mai rivelare di non aver effettivamente visto il documento.

Abbiamo scritto una regola per ciascun problema: un vincolo di numerazione (le sezioni di primo livello iniziano da 1 e non presentano lacune) e una regola anti-fabbricazione (se il documento referenziato non è presente, richiedilo, non inventarlo). Poi abbiamo provato a riprodurre i fallimenti originali con il vecchio prompt per poter osservare come le nuove regole li correggessero.

Il difetto di numerazione non si è riprodotto. Su oltre venti generazioni con il vecchio prompt, inclusa la forma del messaggio di produzione che ha scatenato il report, GLM-5.2 ha sempre iniziato da 1. Il fallimento non appariva senza il contesto più completo della sessione live: memorie utente accumulate, una lunga conversazione multi-turno e la modalità di ragionamento attivata. La nostra interpretazione è che uno o più di questi elementi siano necessari per scatenarlo. L'harness offline a singolo turno non li aveva, e il bug semplicemente non c'era.

Questo è il tranello. Avevamo una correzione per un bug che non riuscivamo a evocare. Non potevamo dimostrare che la correzione migliorasse qualcosa, perché non c'era nulla di rotto da migliorare nel nostro ambiente di test. Distribuire basandosi sulla fede non è una prova. Bloccare tutto perché non puoi riprodurre il fallimento non distribuisce nulla. Entrambe le opzioni sono sbagliate.

Cambio di prospettiva: limita il raggio d'azione, non inseguire la correzione

La regola risiede nel prompt di sistema ad ogni turno di chat, quindi il suo raggio d'azione non è limitato alla "numerazione dei documenti". Riguarda ogni comportamento dell'assistente: domande e risposte su framework, mappatura tra framework, avvertenze legali, rifiuti, output multilingue, tono. Una modifica al prompt mirata a un singolo caso di fallimento può silenziosamente danneggiarne uno non correlato. Questo è il rischio che vale la pena misurare, e, a differenza del bug originale, è misurabile offline.

Quindi abbiamo smesso di provare a dimostrare che la correzione funzionasse e abbiamo iniziato a cercare di limitare il rischio che la modifica comportava. La progettazione: una valutazione di regressione A/B alla cieca sull'intera superficie della chat, confrontando il vecchio prompt con il nuovo su input identici.

• 42 dati di test che coprono domande e risposte sulla compliance, consulenza, mappatura tra framework, reindirizzamenti di servizio, rifiuti di sicurezza, avvertenze legali, output multilingue in tedesco e francese, tono, generazione di documenti e dati dinamici che includono le sezioni di istruzioni personalizzate e i file fissati che gli utenti reali hanno.
• 252 generazioni, che formano 126 coppie vecchio-nuovo (tre campioni per dato di test), tutte su GLM-5.2, 2026-07-09.
• Cecità. Ogni coppia è scritta come A/B con un'etichetta randomizzata tramite seed. Un manifesto contiene la vera mappatura vecchio/nuovo e non viene mai mostrato ai valutatori.
• Due livelli di valutazione. Un livello deterministico verifica condizioni "deve" e "non deve" sui dati di test protetti (i reindirizzamenti al centro assistenza vengono attivati, le avvertenze legali vengono mostrate, i tentativi di estrazione del prompt vengono rifiutati, le umlaut sopravvivono, le lunghezze minime vengono rispettate). Un livello qualitativo alla cieca prevede che i valutatori leggano ogni coppia senza sapere quale braccio sia quale o cosa sia cambiato, e classifichino come equivalenti, A migliore o B migliore con un tag di materialità.

Il livello deterministico è tornato pulito: zero risposte fallite su entrambi i bracci, zero fallimenti asimmetrici. Nulla di ciò che la regola avrebbe dovuto proteggere si è rotto su entrambi i lati.

Il livello qualitativo è dove si trova il punto interessante.

Il test di simmetria

I valutatori alla cieca hanno classificato 118 delle 126 coppie come equivalenti. Dei rimanenti otto, sette presentavano una differenza materiale e una era una differenza minore, non materiale. A una lettura superficiale, sette divergenze in una valutazione di sicurezza rappresentano un fallimento.

È una lettura sbagliata, ed ecco il motivo: una differenza materiale ha un segno, cioè o il braccio nuovo era peggiore o il braccio vecchio era peggiore. Se la modifica al prompt sta causando regressioni, le differenze materiali si concentrano in una direzione, verso "nuovo peggiore". Se invece sono solo la varianza variabile del modello tra esecuzioni successive e non hanno nulla a che fare con la tua modifica, si distribuiscono approssimativamente in modo uguale tra entrambi i bracci. Quindi non limitarti a contare le differenze materiali. Svela l'assegnazione e conta la direzione.

L'abbiamo fatto. Le sette si sono suddivise in tre nuovo peggiore, quattro vecchio peggiore. Tre contro quattro è il più equilibrato possibile per sette, il pattern che ci si aspetta dalla varianza variabile del modello piuttosto che da una regressione direzionale. Nessuna delle sette aveva una connessione plausibile con una regola di numerazione dei documenti:

Differenza materiale	Braccio peggiore	Cosa abbiamo osservato
Identità della clausola ISO 27001	nuovo	A.8.2 letto come controllo di valutazione del rischio (corretto negli altri due campioni di questa fixture)
Segmentazione PCI DSS	nuovo	segmentazione sovrastimata come strettamente richiesta
Segmentazione PCI DSS	vecchio	un "Appendice A1 requisito di segmentazione" inventato
Documento tedesco (filtraggio CJK)	vecchio	un token cinese casuale nel testo di chiusura in tedesco
Documento tedesco (filtraggio CJK)	vecchio	caratteri cinesi in una sezione di riepilogo in tedesco
Istruzione di concisione	nuovo	ha rotto un'istruzione personalizzata "estremamente concisa"
Istruzione di concisione	vecchio	ha rotto un'istruzione personalizzata "estremamente concisa"

Il caso più evidente, il nostro unico esempio persistente, sono i filtraggi CJK: in due delle nostre fixture tedesche, l'output conteneva un token cinese casuale (in un caso i caratteri per "information security") in un deliverable altrimenti in tedesco. Questo comportamento di filtraggio dei token è apparso su entrambi i bracci nelle nostre esecuzioni tedesche. In questo caso, entrambe le istanze sono finite sul braccio vecchio. Se la nuova regola stesse degradando l'output in tedesco, ci aspetteremmo che finissero sul braccio nuovo; non è successo.

I casi di precisione normativa puntano nella stessa direzione. Nell'ISO/IEC 27001:2022 (pubblicato il 25 ottobre 2022), l'Allegato A controllo 8.2 è "Privileged access rights"; un campione del braccio nuovo leggeva 8.2 come controllo di valutazione del rischio e lo ha azzeccato negli altri due campioni di quella fixture. Secondo lo standard PCI DSS v4.0 (PCI Security Standards Council, marzo 2022), la segmentazione di rete non è un requisito assoluto, ma una tecnica di riduzione dell'ambito che il Consiglio descrive come un modo per escludere i sistemi dall'ambito di valutazione, non un controllo obbligatorio; un campione del braccio nuovo lo ha sovrastimato come richiesto, e un campione del braccio vecchio ha inventato che l'"Appendice A1" è un requisito di segmentazione. L'Appendice A1 è in realtà i requisiti aggiuntivi per i fornitori di servizi multi-tenant. Questi sono i tipi di oscillazioni fattuali che un modello probabilistico produce su questioni di dominio complesse, e in questa esecuzione si sono distribuiti su entrambi i bracci, non concentrati sul nostro.

Nel frattempo, i comportamenti che la modifica mirava effettivamente a correggere sono rimasti invariati su entrambi i bracci per tutta la valutazione: ogni coppia con allegato mancante ha richiesto il documento invece di inventarlo, e ogni coppia con numerazione ha prodotto una struttura senza lacune. Su tutta la valutazione, le 126 coppie alla cieca più le verifiche deterministiche sulla stessa superficie, non abbiamo trovato alcun fallimento attribuibile alla modifica.

Cosa questo dimostra e non dimostra

Sii preciso riguardo a ciò che affermi, perché è facile esagerare. La valutazione mostra nessuna regressione direzionale a questo campione, non che la correzione funzioni. Non abbiamo mai dimostrato che la regola di numerazione abbia corretto il bug di numerazione, perché il bug richiede un contesto di produzione che non siamo riusciti a ricreare. La regola viene distribuita su due pilastri: le analisi forensi di produzione che rendono il fallimento leggibile, e un segnale di non regressione che mostra che la modifica non disturba nient'altro. Questa è una tesi più debole di "abbiamo riprodotto il bug e abbiamo visto la correzione risolverlo", ed è la tesi più forte che la situazione consente.

I limiti sono reali e vale la pena di essere esplicitati una volta per tutte. Una distorsione direzionale grossolana si manifesterebbe con tre campioni per dato di test; una sottile no, dato che uno sbilanciamento 55/45 si nasconde a questo livello di campionamento, e tre campioni per 42 dati di test sono raggruppati, non 126 prove indipendenti. Non abbiamo eseguito un braccio di controllo vecchio-vecchio, quindi la suddivisione tre-quattro è la nostra migliore stima del rumore di base, non una misurazione basale, e senza un margine di equivalenza stabilito in anticipo questa è un segnale di non regressione direzionale, non un test di non inferiorità formale. I dati di test sono a singolo turno, quindi un'interazione tra la nuova regola e una lunga conversazione di produzione è fuori scope, che è esattamente il contesto di cui il bug originale aveva bisogno. Una suddivisione simmetrica è una prova che la modifica non ha spinto gli output in una direzione, non che sia inerte. Ciò che il test ti offre è una lettura concreta del raggio d'azione quando l'alternativa era un presentimento.

La checklist portatile

Quando hai una correzione del prompt per un bug di produzione che non puoi riprodurre offline, non distribuire basandoti sulla fede e non bloccare tutto. Limita invece il cambiamento:

• Separa le due domande. "La correzione funziona?" richiede il fallimento che non puoi ricreare. "Il cambiamento è sicuro?" no. Rispondi a quella che puoi.
• Valuta onestamente il raggio d'azione. Una regola in un prompt di sistema condiviso tocca ogni comportamento, non solo quello target. Costruisci dati di test su tutta la superficie, incluse le varianti di istruzioni personalizzate e di contesto fissato che gli utenti reali portano con sé.
• Esegui alla cieca e a coppie. Stessi input, vecchio contro nuovo, etichette A/B randomizzate tramite seed e un manifesto che i valutatori non vedono mai. La cecità è ciò che ti impedisce di dare un punteggio al braccio che speri vinca.
• Confronta la direzione, non solo la differenza. Svela le differenze materiali e controlla il segno. Una distorsione asimmetrica verso "nuovo peggiore" è una regressione. Una suddivisione approssimativamente equilibrata tra entrambi i bracci è il pattern che autorizza un cambiamento a questo livello di evidenza.
• Aggiungi un controllo ripetuto se il margine è stretto. Un braccio vecchio-vecchio misura direttamente la tua varianza di base, quindi stai confrontando il tuo cambiamento con un numero invece che con un'assunzione.
• Mantieni un livello deterministico minimo. Abbina la lettura qualitativa con controlli rigidi "deve" e "non deve" sui comportamenti che non devono mai rompersi, così un verdetto di rumore simmetrico non può coprire un'invariante effettivamente rotta.
• Dichiara la tesi che hai effettivamente guadagnato. Di' "nessuna regressione misurabile", non "la correzione funziona", quando la non regressione è tutto ciò che hai dimostrato.

L'istinto quando un bug non si riproduce è continuare a provare a ricrearlo finché non si rompe. A volte non ci riuscirete mai, e lo sforzo viene speso sulla domanda sbagliata. Se la correzione venga distribuita o meno dipende dal fatto che il tuo cambiamento sia più forte del rumore variabile del modello. Misura questo direttamente, e una modifica al prompt che non sei mai riuscito a vedere avere successo diventa una che puoi comunque essere fiducioso sia sicura.