L'aggiornamento che non hai richiesto
Gli aggiornamenti del modello possono interrompere silenziosamente un sistema AI funzionante. Ecco come catturare la regressione prima che i clienti la segnalino.
Quando gli aggiornamenti rompono ciò che funzionava
Il sistema ha lavorato il venerdì. Il lunedì continua a fornire risposte, risponde in meno di due secondi e supera tutti i controlli sulla dashboard. Tuttavia, le risposte sono leggermente diverse - più lunghe, formulate in modo diverso, formattate in modo da confondere l'analizzatore a valle, o semplicemente sbagliate su una politica che prima era corretta.
Niente è andato storto. Il fornitore ha rilasciato un aggiornamento del modello.
Questo è il modo di guasto che sorprende di più i team dirigenziali, perché non sembra un'interruzione. Non ci sono luci rosse. Il sistema dichiara di essere in salute, mentre la qualità delle sue uscite si è spostata sotto la nostra attenzione. I clienti lo notano prima dei sistemi di monitoraggio.
Perché gli aggiornamenti rompono le cose che funzionavano
Un modello più recente è generalmente migliore in media e diverso in particolare. I fornitori ottimizzano per benchmark aggregati; tu hai implementato contro la tua stretta fetta di realtà. Quando il modello cambia, i comportamenti su cui hai regolato il sistema cambiano anche loro - la formulazione sulla quale si basava la tua richiesta, la struttura JSON che la tua integrazione si aspetta, i confini di rifiuto approvati dal tuo team di conformità, la lunghezza che si adattava alla tua interfaccia utente.
Gli aggiornamenti arrivano in tre modi: il fornitore ritira una versione del modello e ti migra, hai un alias galleggiante che risolve silenziosamente alla versione più recente, o hai deliberatamente aggiornato per ridurre i costi o la latenza e presumendo che la qualità sarebbe migliorata. Tutti e tre producono lo stesso risultato: il comportamento è cambiato e nessuno ha misurato cosa è cambiato.
Costruisci la cosa che ti dice
L'unico controllo importante è un insieme fisso di casi di test con risposte corrette - un set dorato. Duecento esempi reali tratti dal tuo traffico effettivo, coprendo i tuoi casi comuni, i tuoi casi limite e le situazioni in cui essere sbagliati è costoso. Ogni esempio ha la risposta che la tua attività considera corretta.
Esegui questo insieme contro il modello attuale e registra i risultati. Questa registrazione è la tua base di riferimento. Quando arriva un nuovo modello, esegui nuovamente lo stesso insieme e confronta. Il confronto è l'intero prodotto: ora hai delle prove invece di impressioni.
Costruire questo richiede pochi giorni e necessita dei tuoi operatori, non dei tuoi ingegneri, per definire cosa significa "corretto". La maggior parte delle organizzazioni salta questa fase perché si sente come un sovraccarico prima del lancio. È l'assicurazione più economica dell'intero sistema.
Controlla quando il cambiamento raggiunge te
Fissa versioni esplicite di modelli in ogni configurazione di produzione. Una versione fissa trasforma un attacco a sorpresa in una decisione programmata. Tratta quindi ogni aggiornamento come un piccolo progetto:
- Esegui il set dorato contro la nuova versione e confronta, caso per caso, con la base di riferimento
- Fai rivedere ogni caso in cui la risposta è cambiata, non solo quelli peggiorati - i miglioramenti possono anche rompere sistemi downstream
- Invia una piccola percentuale del traffico vivo alla nuova versione e osserva i segnali operativi: tasso di escalation, tempo medio di gestione, quante volte il personale riscrive la bozza del sistema prima di inviarla, quanti contatti ripetuti sullo stesso problema entro una settimana.
- Mantieni la vecchia versione accessibile per una finestra di rollback e conosci chi ha l'autorità per tirare la leva
- Registra la decisione, la data e le prove, in modo che il prossimo aggiornamento parta da uno stato noto
Nota cosa non è nella lista: un demo. Guardare un nuovo modello rispondere a cinque domande impressionantemente non ti dice nulla sul 20° percentile del tuo traffico, da cui provengono le tue lamentele.
Osserva i segnali che la tua attività genera già
Tra gli aggiornamenti, il drifto di qualità si manifesta nei numeri che probabilmente raccogli già. Escalazioni a un essere umano. Tempo medio di gestione. Quante volte il personale riscrive la bozza del sistema prima di inviarla. Contatti ripetuti sullo stesso problema entro una settimana. Qualsiasi di questi movimenti di tre o quattro punti in due settimane merita un'occhiata su cosa è cambiato nello strato del modello.
Affida a una persona il compito di rivedere queste cifre ogni settimana contro la versione del modello in produzione. Non un comitato, non una revisione trimestrale. Un proprietario con nome e un controllo rapido di 15 minuti.
Metti nel contratto
Chiedi al tuo fornitore una notifica scritta prima che una versione venga ritirata, una finestra minima di supporto per le versioni fissate e l'accesso alla versione precedente durante la migrazione. I fornitori che servono settori regolamentati offrono generalmente questo. I fornitori che non lo fanno ti diranno, e questa risposta è utile prima di costruire su di loro piuttosto che dopo.
La posizione onesta
Non puoi impedire al tuo fornitore di migliorare i loro modelli, e non vorresti nemmeno farlo. Ciò che puoi fare è assicurarti che il miglioramento avvenga ai tuoi termini: misurato, graduale, reversibile e gestito da qualcuno.
Questa è l'aspetto poco glamour di eseguire l'AI in produzione piuttosto che pilotarla - ed è la parte che assumiamo per i clienti che preferirebbero dedicare la loro attenzione all'attività. Comunque, costruisci il set dorato. Tutto il resto dipende da esso.