Cambiare il modello di embedding RAG: migrare il chatbot AI senza lacune di conoscenza

Un modello di embedding lavora solitamente in modo invisibile nello sfondo di un chatbot RAG. Traduce domande e moduli di conoscenza in vettori numerici per consentire di individuare i contenuti semanticamente pertinenti. Proprio perché questa componente appare raramente su un'interfaccia utente, un cambio di modello può sembrare un semplice adeguamento della configurazione. Dal punto di vista tecnico, tuttavia, si viene a creare un nuovo spazio di ricerca. I vettori dei documenti esistenti, i vettori delle nuove domande e la definizione dell'indice devono tornare a coincidere.

Chi desidera cambiare gli embedding RAG non dovrebbe quindi limitarsi a sostituire il nome del modello nella pipeline di query. Una migrazione sicura tratta il nuovo indice come una versione autonoma: creato in modo riproducibile, verificato con le stesse domande di test, utilizzato inizialmente in parallelo e attivato solo dopo una decisione formale di rilascio. In questo modo il chatbot per il sito web rimane accessibile, mentre il team mantiene sotto controllo qualità, tempi di esecuzione, costi e opzioni di ripristino.

Perché gli embedding non sono intercambiabili a piacimento

Un vettore ha senso solo all'interno dello spazio in cui è stato generato. La documentazione ufficiale di Azure AI Search per la creazione di un indice vettoriale descrive l'indice come uno spazio di embedding composto da vettori del medesimo modello. Inoltre, evidenzia come la dimensione di ciascun vettore debba corrispondere alla definizione del campo. Un nuovo modello può presentare una dimensione diversa, differenti punti di forza linguistici o un'altra distribuzione delle distanze semantiche.

Alrettanto importante è il lato query. Secondo la documentazione Microsoft sulla configurazione del vectorizer, l'indicizzazione e la query devono utilizzare lo stesso modello di embedding. Se un team mescola vecchi vettori di documenti con domande originate da un nuovo modello, i punteggi di similarità non sono più interpretabili in modo affidabile. Anche se la dimensione dovesse coincidere per puro caso, ciò non dimostra alcuna compatibilità semantica.

Definire un obiettivo misurabile prima della migrazione

"Più recente" non rappresenta un criterio di accettazione sufficiente. Prima della prima ri-indicizzazione, il team necessita di una ragione concreta per la migrazione. Si desidera migliorare la qualità dei risultati nel linguaggio tecnico? Sono necessarie lingue aggiuntive? Il modello attuale è deprecato, troppo lento o troppo costoso? Oppure si intende ridurre la dimensione dei vettori per risparmiare memoria? È dall'obiettivo che nascono le metriche di confronto.

• Qualità: fonti rilevanti nei primi top-k risultati, quota di domande con risposta e qualità della risposta finale.
• Operatività: latenza di recupero (retrieval), tasso di errore, durata dell'indicizzazione e comportamento in caso di errori parziali.
• Costi: generazione di embedding dell'intero archivio, modifiche in corso, memoria e query.
• Copertura: documenti, lingue, versioni di prodotto e ambiti di autorizzazione nel nuovo indice.

I valori di partenza vanno inclusi nello stesso report di test dei risultati del candidato. Se per questo scopo è già presente un Golden Set, è possibile utilizzare come base la guida esistente sulla misurazione della qualità delle risposte del chatbot AI. L'importante è non limitarsi a confrontare un punteggio medio: le domande di supporto critiche, i termini tecnici rari e i casi senza risultato meritano valutazioni dedicate.

Due indici anziché modifiche sul sistema in produzione

Lo standard più solido è rappresentato da un indice parallelo. L'indice attuale rimane invariato e gestisce il traffico in tempo reale. Parallelamente, viene creata una nuova collection o un nuovo indice con il proprio identificativo di modello, dimensione, metrica di distanza e numero di versione. Entrambi vengono generati a partire dalla stessa versione sorgente approvata. In questo modo è possibile attribuire le differenze al modello o alla configurazione dell'indice, anziché mettere a confronto contenuti in continuo cambiamento.

La guida ufficiale Weaviate per il cambio di un vectorizer mostra a questo scopo collection separate e un alias come punto di commutazione reversibile. Il prodotto specifico è intercambiabile; il principio rimane fondamentale: isolare nettamente i vecchi e i nuovi embedding, gestire l'accesso tramite un router controllato o un alias e mantenere lo stato precedente per un periodo limitato per consentire un eventuale rollback.

Identità stabili per ogni modulo di conoscenza

Ogni chunk richiede un ID funzionale stabile, indipendente dal vettore. È opportuno utilizzare una combinazione di ID fonte, versione sorgente, sezione e versione del chunk. Inoltre, ciascun record dovrebbe contenere il nome del modello, la versione del modello, la dimensione, la data di creazione e l'hash del testo convertito in embedding. In questo modo la pipeline è in grado di identificare esattamente ciò che è già stato elaborato, ciò che deve essere convertito di nuovo e quali errori risultano ancora aperti.

Fissare la nuova pipeline in modo riproducibile

Prima di procedere al backfill completo, un piccolo sottoinsieme rappresentativo dovrebbe passare attraverso la nuova pipeline. In questa fase, l'estrazione, la pulizia e il chunking RAG devono inizialmente rimanere invariati. Se il team modifica contemporaneamente modello, limiti del chunk, metadati e ranking, risulterà quasi impossibile spiegare una successiva differenza di qualità.

La configurazione deve essere inserita nell'esecuzione sotto forma di manifesto con versione: modello e provider, dimensione, normalizzazione, metrica di distanza, dimensione del batch, regole di retry, versione del chunker, lingue consentite e metadati necessari. Le credenziali di accesso sono tassativamente escluse. Per ogni batch vengono salvati unicamente ID, contatori, stato e un codice di errore sicuro. In questo modo è possibile riprendere un'esecuzione interrotta senza dover ripetere costosi processi di embedding già completati con successo.

Rigenerare gli embedding in modo controllato e dimostrare la completezza

Una ri-indicizzazione è completa solo quando l'archivio teorico e quello effettivo coincidono. Un numero elevato di documenti non è sufficiente. La pipeline deve verificare per ciascuna fonte che tutti i chunk previsti siano presenti, che i relativi hash di testo corrispondano alla versione sorgente approvata e che tutti i metadati obbligatori siano stati trasferiti. I record non riusciti confluiscono in una coda di riprova limitata; gli errori permanenti rimangono visibili con il loro ID e non devono scomparire dietro uno stato generale positivo.

1. Bloccare o contrassegnare in modo univoco l'archivio sorgente e la data di riferimento della versione.
2. Creare la nuova struttura dell'indice con la dimensione e la metrica appropriate.
3. Generare e salvare gli embedding dei chunk in batch limitati e idempotenti.
4. Verificare i conteggi dei documenti, dei chunk e dei metadati rispetto all'archivio previsto.
5. Controllare un campione sulla base dell'hash del testo, dell'ID fonte e del contenuto recuperabile.

Confrontare il recupero con domande identiche

A questo punto, le medesime domande di test vengono eseguite su entrambi gli indici. Oltre alla percentuale di successo e alla posizione in classifica, il team dovrebbe confrontare le fonti effettivamente restituite. Il nuovo indice ha per caso promosso sezioni semanticamente simili ma errate dal punto di vista tecnico? Perde codici di prodotto esatti? Riscontra con maggiore precisione termini composti o query multilingue? Un concetto di hybrid search e reranking già presente deve essere configurato in modo identico per entrambi i candidati, al fine di garantire un confronto equo.

La documentazione Azure sulla rilevanza vettoriale e il ranking cita la ricerca k-nearest-neighbor esaustiva come possibilità per costruire un dataset ground truth per la valutazione del recall di una procedura ANN approssimativa. Non si tratta di una soglia universale, ma di un utile test di controllo: prima la ricerca esatta di riferimento, poi la ricerca di produzione più rapida. Per il chatbot conta inoltre se le fonti individuate consentano di formulare una risposta corretta e documentata.

Verificare non solo i risultati, ma la risposta finale

Una posizione di retrieval migliore non garantisce ancora una risposta migliore da parte del chatbot. Pertanto, il confronto dovrebbe includere anche il riferimento alle fonti, la completezza, l'incertezza ammissibile e l'interruzione sicura in caso di prove insufficienti. Durante questo processo, il modello di risposta, le istruzioni di sistema e la temperatura devono rimanere il più possibile costanti. Altrimenti, il test misurerebbe più modifiche contemporaneamente.

Shadow read prima del cutover effettivo

Dopo il test offline, una piccola percentuale di query di ricerca reali, gestite garantendo la minimizzazione dei dati, può essere eseguita in via secondaria sul nuovo indice, senza mostrare il risultato agli utenti. Questo shadow read misura il linguaggio reale, la latenza e il comportamento nei casi senza risultato. I contenuti privati, i dati personali e le cronologie complete delle conversazioni non devono finire nei log di confronto senza prima essere stati verificati. Spesso è sufficiente utilizzare classi di query pseudonimizzate, ID dei risultati e metriche tecniche.

Il cutover in sé consiste in una modifica minima e chiaramente monitorabile: l'alias, la destinazione del router o il feature flag passa dall'indice A all'indice B. Durante la prima fase si applicano soglie di allarme più stringenti per fonti mancanti, errori di recupero, latenza e tasso di escalation a operatore umano. Un passaggio graduale è consigliabile se l'architettura lo supporta senza generare stati di sessione promiscui.

Testare operativamente il rollback prima del passaggio

Un piano di rollback è affidabile solo se il vecchio indice rimane sufficientemente aggiornato e la procedura di ripristino è stata testata. Durante la fase parallela, le fonti nuove o modificate devono quindi confluire in modo controllato in entrambe le pipeline. In alternativa, il team può documentare un breve blocco delle modifiche seguito da un allineamento controllato. La guida esistente su incident response e rollback aiuta a definire i fattori scatenanti e le responsabilità.

I segnali d'allarme tipici per un ripristino non sono solo gli errori tecnici. Anche un calo significativo nei risultati top-k rilevanti, nuove lacune linguistiche, un numero insolitamente elevato di domande senza risposta o filtri di accesso applicati in modo errato giustificano il ritorno al sistema precedente. Il vecchio indice verrà rimosso solo al termine del periodo di monitoraggio, a valle di un'approvazione documentata e in assenza di differenze di qualità non chiarite.

Errori frequenti durante la migrazione degli embedding

• Cambiare solo il lato query: i nuovi vettori di domanda vengono confrontati con un vecchio spazio di documenti.
• Confondere la stessa dimensione con la compatibilità: la lunghezza dei numeri e lo spazio semantico non sono la stessa cosa.
• Modificare più variabili contemporaneamente: cambio contestuale di modello, chunking e ranking; la causa di un effetto rimane incerta.
• Valutare solo i valori medi: le domande rare, critiche per il business o multilingue scompaiono all'interno della media.
• Eliminare troppo presto: il vecchio indice viene rimosso prima che il carico reale e i dati di qualità mostrino un'operatività stabile.
• Dimenticare i filtri: la lingua, la versione e gli accessi non si applicano al nuovo indice esattamente come al vecchio.

Checklist pratica per i team web

• Obiettivo, baseline, criteri di accettazione, responsabile dell'approvazione e segnale di rollback sono documentati.
• Il vecchio e il nuovo indice rimangono separati; modello, dimensione e metrica hanno versioni univoche.
• Entrambi gli indici derivano dalla medesima versione approvata di fonti e chunk.
• Il backfill è idempotente, riprendibile e verificato rispetto all'archivio previsto.
• Golden Set, domande critiche, lingue, casi senza risultato e filtri di accesso superano il confronto.
• Gli shadow read registrano solo i dati tecnici strettamente necessari.
• Cutover e ripristino sono modifiche circoscritte, monitorabili e testate sul campo.
• L'archivio precedente viene eliminato solo dopo il periodo di monitoraggio e la relativa approvazione documentata.

Conclusione: il nuovo spazio vettoriale richiede un proprio processo di release

Sostituire gli embedding RAG è una vera e propria migrazione di dati e qualità, non un semplice interruttore di modello. Costruire il nuovo spazio di ricerca in modo separato, rigenerare gli embedding in maniera completa, confrontarli con domande identiche e attivare il sistema tramite un punto di commutazione reversibile riduce notevolmente i rischi di disservizio e di perdita di qualità. Per i team che gestiscono siti web è fondamentale adottare un breve processo di runbook riutilizzabile: consolidare la baseline, creare l'indice parallelo, verificare retrieval e risposte, monitorare i dati shadow, effettuare il cutover in modo controllato e mantenere aperta la via di ripristino.

Se il vostro chatbot AI utilizza già una knowledge base RAG, non iniziate la migrazione dal modello, ma dal dataset di test. Da dieci a venti classi di domande particolarmente rilevanti, integrate da casi complessi su lingue, prodotti e autorizzazioni, fanno la differenza tra un cambio di modello apparente e una release verificabile e sicura.

Fonti

• Microsoft Learn: Create a vector index in Azure AI Search
• Microsoft Learn: Configure a vectorizer in Azure AI Search
• Microsoft Learn: Relevance in vector search
• Weaviate Documentation: Switching vectorizers