Cambiare modello di base AI senza perdere qualità: Evals, Canary e Rollback

Un nuovo modello di base AI promette spesso risposte migliori, costi inferiori o tempi di reazione più brevi. Per un chatbot per siti web in produzione, tuttavia, il passaggio non è come sostituire un pacchetto software qualsiasi. Anche una semplice nuova versione del modello può ponderare le istruzioni in modo diverso, formulare risposte più dettagliate, generare dati strutturati difformi o invocare tool in un ordine differente. Di conseguenza, una migrazione ha successo solo quando il chatbot svolge i suoi compiti specifici con almeno la stessa affidabilità di prima – e quando il team può ripristinare la versione precedente in pochi minuti in caso di problemi.

I fornitori dismettono regolarmente i modelli. La documentazione di OpenAI sulle dismissioni riporta le date di spegnimento e i modelli sostitutivi consigliati; Anthropic distingue nel suo ciclo di vita del modello gli stati "Active", "Legacy", "Deprecated" e "Retired". Tali scadenze rappresentano il motivo della migrazione, ma non la prova della sua qualità. Questa viene fornita solo da una procedura di test e rollout adatta al proprio chatbot.

Cosa cambia davvero nel passaggio da un modello di base all'altro

Questo processo va chiaramente distinto da una migrazione del modello di embedding . Durante il cambio di embedding, i documenti devono essere rivettorizzati e gli indici di ricerca mantenuti compatibili. Nel cambio di modello di base, l'indice di retrieval di norma rimane invariato; ad essere modificato è il modello che genera la risposta a partire dal prompt di sistema, dalla conversazione, dalle fonti trovate e dai risultati dei tool. Vengono quindi testati il comportamento di risposta, l'aderenza alle fonti, il formato, l'uso dei tool, la sicurezza, la latenza e i costi.

Anche un test generale in Shadow Mode prima del lancio sul sito web risolve solo una parte del problema. Il traffico shadow può alimentare due modelli con gli stessi input senza inviare la nuova risposta. Il cambio di modello di base qui descritto va oltre: definisce in anticipo una matrice di collaudo, instrada una piccola percentuale di traffico reale verso il candidato, monitora i segnali degli utenti e del sistema e mantiene pronta una procedura di ripristino testata.

Prima del test: stabilire un contratto di migrazione univoco

I confronti sono privi di valore se nel frattempo cambiano più elementi contemporaneamente. Mantenete quindi costanti per il primo ciclo il prompt di sistema, la configurazione di retrieval, gli schemi dei tool, la temperatura, la lunghezza massima dell'output e le regole di sicurezza, e documentate eventuali modifiche inevitabili ai parametri, come opzioni di sampling non supportate. Documentate il modello attuale come base e il nuovo modello come candidato. Se possibile, utilizzate versioni esplicite del modello anziché un alias dinamico. Un alias potrebbe in seguito puntare a uno snapshot diverso e alterare un confronto che si riteneva riproducibile.

Il contratto di migrazione definisce inoltre i gruppi di utenti e le funzionalità inizialmente esclusi. Un chatbot FAQ può ad esempio entrare presto in fase Canary, mentre gli accessi in scrittura agli ordini, le informazioni contrattuali o i casi di supporto particolarmente sensibili rimangono più a lungo sulla base. In questo modo il rischio viene limitato in base all'impatto sul business e non solo in base alla complessità tecnica.

Il set di test deve rispecchiare il traffico reale

Un Golden Set non dovrebbe contenere solo domande standard perfette. Raccogliete casi anonimizzati o sintetici ricreati dai principali intent: domande chiare, formulazioni ambigue, domande di approfondimento, documenti mancanti, fonti contraddittorie, errori dei tool e input che devono essere trasferiti a un operatore umano. Suddividete i casi per lingua, dispositivo, tipo di cliente e classe di rischio. In questo modo si evidenzia se un buon punteggio complessivo nasconde sottogruppi piccoli ma critici per il business.

La guida ufficiale di Anthropic su criteri di successo ed Evals raccomanda criteri specifici, misurabili e legati ai casi d'uso, oltre a casi limite realistici. Anche la guida di OpenAI agli Evals descrive i test come una componente fondamentale per applicazioni affidabili, in particolare durante l'upgrade o la sperimentazione di nuovi modelli. Poiché OpenAI dichiara la dismissione della precedente piattaforma Evals nella stessa pagina, è opportuno salvare il proprio Golden Set in un formato portabile e non vincolato a una singola dashboard.

Una matrice di valutazione anziché un unico valore medio

I seguenti valori soglia sono un esempio, non una regola universale. Stabiliteli a partire dalle prestazioni attuali in produzione e dal danno causato da un errore. Un candidato non deve compensare un prezzo per token inferiore con una peggiore aderenza alle fonti.

I controlli automatici sono adatti per schemi JSON, formulazioni obbligatorie, destinazioni dei link, argomenti dei tool e regole aziendali deterministiche. Per il tono, la completezza e le spiegazioni utili serve inoltre una rubrica chiara; verifiche a campione condotte da esperti aiutano a calibrare un valutatore basato su LLM. I risultati dovrebbero essere salvati per ogni intent e classe di rischio, non solo come punteggio unico. La struttura fondamentale di un set di questo tipo è illustrata anche nella nostra guida sulla qualità delle risposte con il Golden Set.

Esempio pratico: cambio di modello nel supporto B2B

Ipotizziamo che un fornitore di software B2B gestisca un chatbot per domande sui prodotti, gestione dell'account e preparazione dei ticket di supporto. Il team crea 240 casi di test: 120 domande frequenti di conoscenza, 40 domande ambigue di approfondimento, 30 casi con fonte mancante, 25 simulazioni di tool e 25 casi di sicurezza o handoff. Entrambi i modelli ricevono esattamente gli stessi prompt, i medesimi riscontri dai documenti e gli stessi risultati simulati dei tool.

Il candidato risponde alle domande standard in modo più rapido ed economico, ma in cinque domande di approfondimento perde il riferimento al messaggio precedente. Il punteggio complessivo risulterebbe comunque migliore. Tuttavia, l'analisi per segmenti mostra un chiaro calo di qualità. Anziché aggiungere un'eccezione arbitraria, il team precisa la regola di conversazione, espande il set di test con casi simili e testa nuovamente entrambi i modelli. Solo quando il candidato supera tutti i gate vincolanti inizia la fase di Canary in produzione.

Per iniziare, il due percento delle nuove conversazioni idonee viene assegnato al candidato. L'assegnazione viene ricavata all'inizio della conversazione, ad esempio dall'hash dell'ID conversazione, e mantenuta per l'intera chat; i livelli di Canary superiori si applicano solo alle nuove conversazioni. Le chiamate ai tool in scrittura e gli intent ad alto rischio rimangono inizialmente sulla base. Dopo una finestra di osservazione sufficientemente ampia seguono il 10, 25, 50 e infine il 100 percento – ma solo se ogni gate rimane verde. Gli scaglioni e i campioni minimi vengono definiti in anticipo, per evitare che la pressione del tempo finisca per ammorbidire le regole.

Segnali online che contano davvero

Nella fase Canary, gli errori HTTP e la latenza media non bastano. Monitorate il tasso di mancata risposta, gli abbandoni dopo la prima risposta, le domande ripetute, il tasso di handoff, i clic sulle fonti, gli errori di schema e le interruzioni dei tool, separatamente per la base e per il candidato. Un trace comune collega versione del modello, versione del prompt, riscontri di retrieval e passaggi dei tool senza salvare contenuti personali non necessari. Il nostro articolo sull'osservabilità dei chatbot spiega nel dettaglio questa traccia di controllo.

Confrontate inoltre i costi per caso risolto con successo anziché solo i costi per milione di token. Un modello più economico che genera più spesso ulteriori domande o interventi umani può risultare operativamente più costoso. Al contrario, un leggero aumento della latenza può essere accettabile se è accompagnato da risposte dimostrabilmente più precise in una classe di rischio importante.

Il rollback è una funzionalità, non un documento

La via di ritorno deve essere testata tecnicamente prima del primo stadio di Canary. L'ID del modello e i relativi parametri devono risiedere in una configurazione versionata o in un Feature Flag controllato. Finché il fornitore supporta ancora la versione precedente, questa rimane disponibile come destinazione di fallback durante la fase Canary; prima della sua data di spegnimento serve inoltre un fallback supportato. Le conversazioni esistenti dovrebbero rimanere coerentemente sul modello originale o passare ad altro secondo una regola espressamente testata.

Definite trigger vincolanti: ad esempio un errore di schema durante un'azione di scrittura, un peggioramento di un intent rilevante per la sicurezza, un balzo evidente del tasso di errore o il superamento del budget di latenza. In presenza di un simile segnale, il ripristino avviene automaticamente o tramite un servizio di reperibilità chiaramente individuato. Successivamente, i log, la versione del candidato e il campione interessato vengono conservati per analizzare la causa. Una procedura preparata è molto più solida di un deploy estemporaneo di codice; inoltre, un playbook completo di risposta agli incidenti offre ulteriore supporto.

Checklist per l'approvazione

• Rilevare data di spegnimento, modello sostitutivo ed endpoint interessati dalla documentazione ufficiale del fornitore.
• Fissare base e candidato mantenendo invariate le configurazioni di prompt, retrieval e tool.
• Suddividere il Golden Set per intent, lingua e classe di rischio; integrare casi limite ed errori reali riscontrati.
• Definire gate vincolanti per aderenza alle fonti, output strutturati, tool, sicurezza e handoff.
• Misurare latenza, tasso di errore, token e costi per caso risolto.
• Mantenere stabile l'assegnazione Canary per l'intera conversazione ed escludere inizialmente le funzioni sensibili.
• Documentare fasi, campione minimo, durata dell'osservazione e limiti di interruzione prima del rollout.
• Testare tecnicamente il rollback, nominare i responsabili e mantenere disponibile un fallback supportato dal fornitore.
• Continuare il monitoraggio dopo il raggiungimento del 100 percento e ampliare il Golden Set con i nuovi casi di produzione rilevati.

Conclusione: il nome del modello è solo l'inizio

Un cambio di modello di base controllato unisce qualità del prodotto e sicurezza operativa. Le indicazioni ufficiali sul ciclo di vita forniscono la scadenza, gli Evals forniscono le prove d'idoneità, il traffico Canary limita l'impatto di errori sconosciuti e un rollback testato riduce i tempi di risposta. Chi stabilisce questi quattro elementi come un processo ripetibile può sfruttare i nuovi modelli senza trasformare il chatbot del proprio sito web in un esperimento per tutti gli utenti.

Vuoi pianificare in modo strutturato la versione del modello, i gate di qualità e il rollout del tuo chatbot per siti web? ChatReact ti aiuta a configurare la base di conoscenza, il comportamento di risposta e i passaggi di consegne affinché le modifiche rimangano misurabili e controllabili.