Introduzione al problema dell’upgrade degli embedding
Le applicazioni che sfruttano la ricerca semantica o altri carichi di lavoro basati su vettori richiedono costantemente modelli di embedding aggiornati. Quando un nuovo modello diventa disponibile, le soluzioni tradizionali impongono di re‑embed i dati, ricostruire gli indici e modificare la logica di query, operazione che spesso richiede l’interruzione del servizio.
Google, tramite il servizio AlloyDB AI, ha pubblicato una guida dettagliata per eseguire questa migrazione senza downtime, mantenendo attivi i sistemi di produzione e garantendo continuità nelle risposte alle query degli utenti.
Piano di migrazione passo passo
Il processo inizia con l’aggiunta di una nuova colonna vettoriale alla tabella di produzione, dimensionata in base alle dimensioni di output del nuovo modello. Nell’esempio fornito, una tabella di recensioni di prodotto passa da text‑embedding‑005 (768 dimensioni) a gemini‑embedding‑001 (3 072 dimensioni).
Una volta creata la colonna, si attiva la funzionalità auto‑embeddings che consente al database di riempire la colonna in background. AlloyDB AI è in grado di generare fino a 3 000 embedding al secondo, tracciando le modifiche ai dati sorgente durante inserimenti e aggiornamenti.
Modalità di aggiornamento dei vettori
- Modalità transazionale: gli embedding vengono aggiornati immediatamente al momento della modifica dei dati. Garantisce coerenza perfetta, ma aggiunge latenza alle operazioni di scrittura perché l’inferenza avviene all’interno della transazione.
- Modalità manuale: le righe modificate vengono segnate e gli embedding vengono aggiornati in batch programmati. Riduce la pressione sulle scritture ed è la modalità consigliata per la migrazione dimostrata.
Durante il backfill, Google suggerisce di regolare il parametro maxparallelrequests. Un test su una tabella di 10 000 righe ha mostrato che ridurre il valore da 400 a 20 ha diminuito il tempo di attesa massimo per i writer concorrenti da 5,1 s a 0,39 s, aumentando però il tempo totale di backfill da 5,2 s a 7,6 s.
Controlli di qualità e differenze tra modelli
Prima di reindirizzare il traffico verso il nuovo modello, Google raccomanda di verificare la presenza di embedding mancanti e di validare i nuovi vettori con invocazioni fresche del modello. È fondamentale testare il comportamento dell’applicazione, poiché i pattern di recupero possono cambiare drasticamente.
Nei test interni di Google, i risultati dei 10 vicini più prossimi ottenuti con text‑embedding‑005 e gemini‑embedding‑001 si sovrapponevano solo per il 31 %. Questo indica la necessità di rivedere le assunzioni nei pipeline di ranking, filtraggio e valutazione prima di attivare il nuovo modello in produzione.
Costruzione dell’indice vettoriale
La migrazione include la creazione di un nuovo indice ScaNN sulla colonna di sostituzione, eseguita in modo concorrente per non bloccare le scritture. Google afferma che gli indici ScaNN sono fino a 10 volte più rapidi rispetto a HNSW su PostgreSQL open‑source. Su 100 000 righe, un indice ScaNN a 3 072 dimensioni è stato costruito in circa 50 s, mentre un indice HNSW con halfvec ha richiesto tra 7 e 13 minuti.
Strategie di cutover
Per lo switch finale Google descrive due pattern principali:
- Rinominazione atomica della colonna + funzione di query: le applicazioni non richiedono modifiche al codice poiché la colonna di embedding attiva viene semplicemente rinominata.
- Variabili di sessione PostgreSQL + funzione set‑returning: permette rilasci canary e suddivisione del traffico tra modello vecchio e nuovo, consentendo test A/B a livello di query.
Il primo approccio supporta il modello blue‑green ma non i test canary per singola query. Il secondo consente di dirigere una percentuale di sessioni al nuovo modello e di tornare indietro modificando un parametro di sessione.
Limiti: la rinominazione atomica non è compatibile con gli auto‑embeddings transazionali, poiché i trigger gestiti fanno riferimento a nomi di colonna fissi. Inoltre, la modalità transazionale incrementa notevolmente la latenza di scrittura quando entrambi i modelli sono attivi.
Impatto sulla latenza di scrittura
Google ha misurato le operazioni di aggiornamento su singola riga mostrando una latenza mediana di:
- ~37,5 ms con solo text‑embedding‑005
- ~191,0 ms durante la migrazione (entrambi i modelli attivi)
- ~172,0 ms dopo lo switch a gemini‑embedding‑001
Pressione sullo storage
Durante la migrazione lo storage richiesto aumenta considerevolmente, poiché i vettori vecchi e nuovi coesistono. Nei test, text‑embedding‑005 occupava circa 4,5 KB per riga, mentre gemini‑embedding‑001 ne richiedeva circa 13,3 KB.
Per una tabella di 10 milioni di righe, il nuovo campo vettoriale richiederebbe circa 133 GB e l’indice ScaNN aggiuntivo circa 6 GB, senza contare lo spazio necessario per il write‑ahead log e gli aggiornamenti di pagina.
Dopo lo switch, è possibile eliminare la configurazione di embedding legacy, droppare l’indice obsoleto e cancellare il vecchio campo vettoriale in batch, seguito da un vacuum. Nei test su 100 000 righe, l’operazione di nulling e vacuum ha recuperato 381 MB di spazio TOAST, riutilizzabile per futuri upgrade.
Considerazioni finali e raccomandazioni operative
La procedura proposta da Google consente alle organizzazioni di modernizzare i propri modelli di embedding senza interruzioni di servizio, mantenendo al contempo il controllo su latenza, consumo di storage e integrità dei risultati di ricerca.
Per un’adozione efficace è consigliabile:
- Pianificare la capacità di storage aggiuntiva in anticipo.
- Selezionare la modalità di refresh (transazionale vs manuale) in base ai requisiti di latenza delle scritture.
- Eseguire test di qualità approfonditi sui risultati di nearest‑neighbour prima del cutover.
- Utilizzare il pattern di cutover più adatto al proprio flusso di lavoro (blue‑green vs canary).
- Monitorare le metriche di latenza e di utilizzo dello storage durante e dopo la migrazione.
Seguendo queste linee guida, le imprese potranno sfruttare i nuovi modelli di embedding più potenti, come gemini‑embedding‑001, mantenendo la continuità operativa e ottimizzando le performance di ricerca semantica.