Vuoi cambiare il modello di embedding RAG? Pianifica la migrazione dei vettori prima del passaggio

Considera il cambio di embedding una migrazione dei dati

Un sistema RAG genera in genere embedding del contenuto sorgente per archiviarlo e embedding delle query per recuperare i contenuti. Se cambi modello o configurazione, non dare per scontato che i vettori già archiviati siano compatibili con il nuovo percorso di query: verifica la documentazione del sistema e convalida il comportamento prima del passaggio.

La documentazione [RAG di NVIDIA](https://docs.nvidia.com/rag/latest/change-model.html) indica che, dopo l’ingestione, se si cambia il modello di embedding o le dimensioni occorre acquisire di nuovo i documenti per ottenere un retrieval accurato. È una ragione concreta per pianificare la ricostruzione dell’indice anziché limitarsi a modificare un’impostazione.

• Registra il modello e la configurazione che hanno generato i vettori esistenti.
• Pianifica l’aggiornamento dell’indice e del percorso di embedding delle query.
• Conserva l’indice funzionante finché quello nuovo non è stato verificato.

Fai l’inventario del percorso di retrieval

Prima di ricostruire l’indice, documenta il percorso dal contenuto sorgente ai passaggi recuperati. Una chiamata al modello riuscita non dimostra da sola che il corpus previsto sia completo o che metadati e filtri siano stati conservati.

Annota in un unico posto la configurazione attuale e quella di destinazione: identificativi e parametri dei modelli, dimensioni attese, estrazione del testo, suddivisione in chunk, metadati, impostazioni di ricerca e modalità di identificazione o aggiornamento dei documenti. Segnala separatamente le modifiche alla pre-elaborazione, così da poterle distinguere dagli effetti del cambio di modello.

• Corpus: fonti, identificativi dei documenti, conteggi attesi ed esclusioni.
• Embedding: modello e configurazione attuali e di destinazione, dimensioni e percorso delle query.
• Elaborazione: estrazione, suddivisione in chunk, trasformazioni e gestione di aggiornamenti ed eliminazioni.
• Indice e retrieval: collection o indice, metadati, filtri e impostazioni di ricerca.
• Operazioni: job di ricostruzione, spazio disponibile, autorizzazioni e modalità di registrazione degli errori.

Scegli una strategia di migrazione adatta al sistema

La strategia dipende dal database vettoriale, dalla possibilità di mantenere più indici, dalla frequenza di aggiornamento del corpus e dall’interruzione che l’applicazione può tollerare. La documentazione di [Qdrant sulla migrazione a un nuovo modello di embedding](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) descrive un processo che copia i dati in una nuova collection, ricalcola gli embedding dei vettori con il nuovo modello e permette di continuare a eseguire ricerche durante la migrazione. Verifica i requisiti e il comportamento della tua configurazione prima di adottare un processo analogo.

Una ricostruzione completa può essere adatta se puoi programmare un’interruzione e conservare l’indice precedente. Gli indici paralleli permettono di verificare un nuovo percorso mantenendo disponibile quello esistente, se la piattaforma e l’architettura lo consentono. Un progetto pilota su un sottoinsieme aiuta a provare la procedura, ma non sostituisce la ricostruzione e la verifica del corpus completo.

• Scegli il metodo in base ai vincoli di disponibilità, capacità e aggiornamento dei dati.
• Verifica come gestire le scritture che avvengono durante la ricostruzione.
• Non sovrascrivere o eliminare l’unico indice funzionante prima di aver verificato la destinazione.

Ricostruisci l’indice e controlla la copertura

Crea l’indice di destinazione con la configurazione prevista e verifica che le dimensioni dei vettori generati corrispondano a quelle attese. Configura il percorso di embedding delle query per interrogare la destinazione e controlla che il formato prodotto sia accettato dall’indice.

Registra gli elementi elaborati e gli errori. Quando sono disponibili identificativi stabili, confronta il contenuto ricostruito con il corpus previsto per individuare elementi mancanti, duplicati, saltati o modificati. Il completamento del job, da solo, non dimostra che la copertura sia completa.

Se il contenuto sorgente può cambiare durante la ricostruzione, definisci come applicare gli aggiornamenti alla destinazione: per esempio, sospendendo le scritture o registrando le modifiche da elaborare. Verifica la procedura scelta e riconcilia gli aggiornamenti prima del passaggio.

• Applica la configurazione di destinazione agli embedding dei documenti e delle query del nuovo percorso.
• Controlla dimensioni e formato dei vettori.
• Monitora gli elementi completati, non riusciti, saltati, duplicati o modificati.
• Riconcilia gli aggiornamenti alle fonti e verifica che l’indice includa il corpus previsto.

Convalida il retrieval prima del passaggio

Prima della ricostruzione, prepara domande rappresentative e annota i documenti o passaggi sorgente attesi. Includi query comuni, casi che dipendono da filtri sui metadati e domande per cui la fonte corretta è meno evidente.

Esegui i test attraverso il percorso di query e retrieval previsto per l’applicazione. Esamina i passaggi recuperati e i relativi metadati, non soltanto la risposta finale: una risposta plausibile può non rivelare una fonte mancante o un filtro errato. Definisci criteri di accettazione adatti al tuo caso d’uso e registra gli esiti e le differenze da chiarire.

• Verifica la presenza dei documenti rappresentativi e la copertura del corpus.
• Esamina i passaggi recuperati per le query di test.
• Controlla filtri sui metadati e comportamenti di accesso rilevanti per l’applicazione.
• Registra risultati, casi senza esito e criteri di accettazione.

Esegui il passaggio e conserva una via di rollback

Registra quale indice e quale configurazione usa l’applicazione, quindi pianifica il cambio del percorso di query come un’unica operazione coordinata. Subito dopo, prova l’indice attivo con alcune query note.

Mantieni l’indice precedente e la relativa configurazione per il periodo di osservazione stabilito. Documenta chi può avviare il rollback, quali condizioni lo attivano e come applicare alla vecchia destinazione gli aggiornamenti intervenuti nel frattempo, se necessario. Elimina l’indice precedente solo dopo l’accettazione del nuovo percorso e dopo aver verificato i requisiti di conservazione e governance.

• Coordina il cambio dell’indice e della configurazione di embedding delle query.
• Verifica il percorso attivo subito dopo il passaggio.
• Definisci responsabili, condizioni e procedura per il rollback.
• Stabilisci quando rimuovere il vecchio indice considerando conservazione e aggiornamenti dei dati.

Assegna le responsabilità e conserva la documentazione

La migrazione richiede responsabilità chiare per la configurazione degli embedding, le operazioni sull’indice e le decisioni relative a futuri cambi di modello o dimensioni. Conserva insieme alla configurazione dell’indice il modello usato, le scelte di pre-elaborazione, i conteggi e gli errori, i risultati dei test, l’orario del passaggio e la procedura di rollback.

L’hosting e la gestione dell’infrastruttura possono ridurre il lavoro operativo, ma non decidono quali documenti includere, chi può recuperarli o quale qualità del retrieval sia accettabile. Airbip gestisce il deployment delle applicazioni a catalogo come workload Docker e offre backup configurabili; i team devono comunque pianificare la migrazione dei dati RAG, gli accessi, la convalida e il rollback per la propria configurazione.

• Assegna un responsabile della configurazione degli embedding e uno delle operazioni sull’indice.
• Conserva la configurazione e i risultati della migrazione per facilitare le verifiche future.
• Valuta accessi, conservazione e backup separatamente dalla configurazione del modello.