Sostituire un modello di IA e verificarlo sullo stesso flusso

Quando cambia modello, esamini l’intero flusso applicativo interessato. Un nuovo identificatore nella configurazione non è una prova sufficiente. Usi un insieme di valutazione esistente e registri quale cambiamento sta effettivamente confrontando.

Registrare chiaramente le due configurazioni

Documenti identificatore del modello, versione del prompt, fonti fornite, strumenti e impostazioni di entrambe le varianti. Se input, regole ed elaborazione restano uguali, il cambio di modello si può esaminare in modo più mirato. Se deve modificare anche prompt, adattatore o valutazione, sta confrontando due configurazioni applicative; non attribuisca la differenza al solo modello.

Microsoft descrive il confronto di varianti salvate sugli stessi casi e l’esame dei singoli errori. Le decisioni attese per il Suo flusso devono essere definite prima del confronto.

Rendere visibili le differenze per ogni caso

L’esempio seguente è interamente inventato. Un’applicazione deve estrarre l’identificatore di progetto da un messaggio oppure richiedere una verifica manuale. Non concede accesso al progetto. I nomi dei campi appartengono al nostro schema interno, non a un’API di un fornitore.

La tabella contiene output ipotizzati per la spiegazione. Non è un test di modello eseguito. Le descrizioni dei casi non sostituiscono gli input originali versionati di un confronto reale.

Nel secondo caso la nuova variante sceglie un progetto nonostante l’incertezza. Nel terzo viola il contratto dei campi. Una valutazione aggregata potrebbe nascondere queste diverse cause di errore. Anche gli output formalmente validi devono essere corretti nel merito.

Gestire gli errori prima di proseguire

OWASP raccomanda di validare gli output del modello prima di passarli ai componenti a valle. Nell’esempio un campo obbligatorio mancante non deve proseguire come estrazione riuscita. L’applicazione deve rifiutare l’output o inviarlo alla verifica prevista. Un campo di progetto presente non autorizza comunque l’accesso.

Oltre ai casi di merito e formato, controlli le lingue effettivamente necessarie, le indisponibilità e i tentativi ripetuti. Una sola esecuzione non determina una frequenza d’errore stabile. Se gli errori noti servono ad adattare la nuova variante, occorrono ulteriori casi tenuti separati per un controllo indipendente.

Pianificare insieme rilascio e ritorno

Prima del rilascio, definisca quali errori impediscono il cambio e chi valuta le differenze ancora aperte. Nell’esempio vanno prima chiariti l’assegnazione affrettata del progetto da un messaggio ambiguo e il campo obbligatorio mancante.

Conservi la configurazione applicativa precedente e un percorso di ritorno verificato. Chiarisca anche se il vecchio modello rimane disponibile e se i dati conservati restano compatibili. Dopo il cambio, osservi i risultati reali del flusso interessato; tre casi illustrativi non dimostrano un’idoneità generale alla produzione.

Fonti

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling