Perché è difficile aggiornare i modelli di embedding in produzione

Immagina di aver lanciato una funzionalità di ricerca semantica sui commenti dei prodotti e di aver ricevuto feedback entusiastico dagli utenti. Il giorno successivo scopri un nuovo modello di embedding vettoriale che promette maggiore accuratezza, capacità multilingue e una migliore gestione delle sfumature. Dopo averlo testato in ambienti di sviluppo, sei convinto che sia la scelta giusta per la tua applicazione. Tuttavia, l’aggiornamento del modello in produzione non è banale: devi rigenerare tutti gli embedding, ricostruire gli indici vettoriali e coordinare eventuali migrazioni di schema senza interrompere le query degli utenti.

Le principali difficoltà sono:

    • Generazione degli embedding: tutti i dati esistenti devono essere ri‑embedded con il nuovo modello, il che richiede aggiornamenti di pipeline complesse e strategie di scrittura duale per mantenere attivi entrambi i modelli per un certo periodo.
    • Incompatibilità matematica: gli embedding prodotti da modelli diversi vivono in spazi vettoriali distinti e non sono comparabili direttamente. Le query degli utenti e le colonne memorizzate devono cambiare modello simultaneamente, altrimenti le ricerche degradano drasticamente.
    • Ricostruzione degli indici: gli indici vettoriali devono essere creati sui nuovi vettori prima che la ricerca per similarità possa funzionare in modo efficiente su larga scala.
    • Esperienza utente degradata: le operazioni DDL necessarie (creazione di colonne, rinomi, ecc.) acquisiscono lock esclusivi che possono bloccare le transazioni di lettura e scrittura se non gestite con attenzione.

Come AlloyDB AI semplifica la gestione del ciclo di vita dei vettori

AlloyDB AI combina diverse funzionalità native per consentire aggiornamenti di modello senza tempi di inattività. Tra queste:

    • Model endpoint management: fornisce accesso in‑database a qualsiasi modello di embedding, sia di prima parte, di terze parti o auto‑hostato.
    • Auto embeddings: genera automaticamente nuovi embedding in background (fino a 3000 al secondo) e li mantiene aggiornati quando i dati sorgente cambiano.
    • Indice ScaNN: riduce drasticamente il tempo di costruzione degli indici, risultando fino a 10 volte più veloce rispetto a soluzioni open‑source basate su HNSW.
    • Funzionalità PostgreSQL native: creazione concorrente di indici, funzioni set‑returning (SRF) e rinomi atomici di colonne, che permettono rollout blue/green e canary senza lock prolungati.

Scenario di migrazione: da text‑embedding‑005 (768‑d) a gemini‑embedding‑001 (3072‑d)

Di seguito trovi una guida passo‑passo per migrare la tabella di produzione ecomm.product_reviews dal modello text‑embedding‑005 al nuovo modello gemini‑embedding‑001, mantenendo il traffico live.

Passo 0 – Prerequisiti e controlli preliminari

Assicurati che l’estensione googlemlintegration sia aggiornata almeno alla versione 1.5.6 (i test sono stati eseguiti su 1.6.1). Verifica la connettività al modello remoto e la dimensione dell’output (3072 dimensioni):

-- Controllo versione estensione

SELECT extversion


FROM pg_extension


WHERE extname = 'googlemlintegration';



-- Creazione estensioni necessarie


CREATE EXTENSION IF NOT EXISTS vector;


CREATE EXTENSION IF NOT EXISTS alloydb_scann;



-- Verifica endpoint remoto e dimensione


SELECT vector_dims(ai.embedding('gemini-embedding-001', 'hello world')::vector);



-- Visualizza impostazioni auto‑embedding esistenti


SELECT * FROM ai.embeddingsettingsview;

Passo 1 – Aggiungere la nuova colonna vettoriale

Creare una colonna nullable senza valore di default aggiorna solo il catalogo, evitando la riscrittura di ogni riga e rendendo l’operazione quasi istantanea. Imposta lock_timeout a 2 secondi per non bloccare il traffico di produzione. Se il lock non è ottenuto entro il limite, basta ritentare.

SET lock_timeout = '2s';


ALTER TABLE ecomm.product_reviews


ADD COLUMN newembeddingcol vector(3072);

Passo 2 – Inizializzare gli auto‑embedding e avviare il backfill

Chiama la procedura ai.initialize_embeddings per associare il nuovo modello alla colonna appena creata. Nella chiamata specifichiamo il modello, la tabella, la colonna di testo di origine, la colonna di destinazione, la dimensione del batch e la modalità di aggiornamento incrementale.

CALL ai.initialize_embeddings(

model_id => 'gemini-embedding-001',


tablename => 'ecomm.productreviews',


contentcolumn => 'reviewtext',


embeddingcolumn => 'newembedding_col',


batch_size => 50,


incrementalrefreshmode => 'manual'


);

Auto embeddings supporta due modalità:

    • Transactional: gli embedding vengono aggiornati immediatamente ad ogni INSERT/UPDATE. Garantisce coerenza transazionale ma aggiunge latenza di scrittura a causa dell’inferenza inline.
    • Manual: AlloyDB traccia le righe modificate senza aggiornare subito l’embedding. Consente di rigenerare solo le righe cambiate su un programma definito con ai.refresh_embeddings(). Ideale quando il tasso di cambiamento è alto e si può tollerare un breve “drift”.

In questo esempio usiamo la modalità manual per mantenere le scritture rapide sulla tabella di base, mantenendo comunque il controllo sul ritmo di aggiornamento degli embedding.

Gestione dei tempi di attesa dei writer concorrenti

Durante il backfill, Auto Embeddings elabora le righe in gruppi paralleli definiti da batchsize × maxparallelrequests. Per ridurre il tempo di attesa dei writer su tabelle molto attive, è possibile diminuire maxparallel_requests:

SET googlemlintegration.maxparallelrequests = 20;

Questa riduzione migliora il tempo di commit di ogni micro‑batch, ma allunga la durata complessiva del backfill. Nei test su una tabella di 10 000 righe, i risultati sono:

maxparallelrequestsTempo di attesa massimo per writerDurata totale backfill
400 (default)5.1 s5.2 s
200.39 s7.6 s (+46 %)

Monitorare l’avanzamento del backfill

AlloyDB espone la vista ai.embeddingprogressview per controllare stato, percentuale completata, righe elaborate, errori e tempo stimato rimanente. Esegui la query da una sessione separata per non interferire con il processo di backfill:

SELECT status, percentprogress, rowsprocessed, errorcount, estimatedtime_remaining

FROM ai.embeddingprogressview


WHERE embeddingcolumn = 'newembedding_col';

Passo 3 – Aggiornare le righe modificate durante il backfill

Al termine del backfill iniziale, è probabile che alcune righe siano state inserite o aggiornate. Con la modalità manual, Auto Embeddings ha già tracciato queste modifiche. Basta eseguire una refresh veloce:

CALL ai.refresh_embeddings(

tablename => 'ecomm.productreviews',


embeddingcolumn => 'newembedding_col'


);

Programma questa chiamata periodicamente (ad esempio con pg_cron o uno scheduler esterno) per mantenere gli embedding sempre sincronizzati con i dati più recenti.

Passo 4 – Creare l’indice ScaNN sul nuovo embedding

Una volta che la colonna newembeddingcol è popolata e le righe recenti sono state aggiornate, crea l’indice vettoriale usando ScaNN. Grazie al supporto di PostgreSQL per la creazione concorrente di indici, l’operazione non bloccherà le letture:

CREATE INDEX CONCURRENTLY idxproductreviewsnewembedding

ON ecomm.productreviews USING scann (newembedding_col);

L’indice ScaNN è tipicamente 10 volte più veloce nella fase di costruzione rispetto a HNSW open‑source, riducendo il “wall‑clock time” dell’intera migrazione.

Passo 5 – Switch blue/green e rinomina atomica della colonna

Con l’indice pronto, è possibile effettuare lo switch finale in modo atomico. Utilizza il comando ALTER TABLE … RENAME COLUMN per sostituire la vecchia colonna di embedding con la nuova. Poiché il rename è un’operazione DDL atomica, non richiede lock esclusivi prolungati e le query continuano a funzionare con la colonna corretta.

BEGIN;


-- Rinomina temporaneamente la vecchia colonna


ALTER TABLE ecomm.product_reviews


RENAME COLUMN oldembeddingcol TO oldembeddingcol_backup;



-- Rinomina la nuova colonna al nome originale


ALTER TABLE ecomm.product_reviews


RENAME COLUMN newembeddingcol TO oldembeddingcol;



COMMIT;

Se desideri mantenere la vecchia colonna per un periodo di verifica, puoi lasciarla come backup e rimuoverla successivamente con DROP COLUMN in un’operazione di manutenzione a bassa attività.

Passo 6 – Pulizia e de‑provisioning del modello precedente

Dopo aver verificato che le query restituiscano risultati corretti con il nuovo modello, puoi disattivare le impostazioni di auto‑embedding per il modello precedente e, se necessario, rimuovere le credenziali o gli endpoint non più in uso.

CALL ai.disable_embeddings(

model_id => 'text-embedding-005',


tablename => 'ecomm.productreviews'


);



-- Eventuale rimozione della colonna di backup


ALTER TABLE ecomm.product_reviews


DROP COLUMN oldembeddingcol_backup;

Best practice per upgrade senza downtime

    • Testa l’intero flusso di migrazione in un ambiente di staging con dati di volume simile a quello di produzione.
    • Monitora costantemente le metriche di latenza delle query e i tassi di errore durante le fasi di backfill e indice.
    • Imposta lock_timeout a valori conservativi (2‑5 s) per evitare blocchi prolungati.
    • Utilizza la modalità manual quando il tasso di aggiornamento dei dati è elevato; passa a transactional solo se la coerenza immediata è imprescindibile.
    • Sfrutta le funzioni di monitoraggio integrate (view ai.embeddingprogressview e statistiche ScaNN) per anticipare eventuali colli di bottiglia.

Conclusioni

Grazie alle capacità di modello endpoint management, auto‑embeddings, indice ScaNN e alle operazioni DDL concorrenti di PostgreSQL, AlloyDB AI consente di aggiornare i modelli di embedding senza interrompere il servizio. Seguendo la procedura dettagliata – dai controlli preliminari, all’aggiunta di una colonna vettoriale, al backfill controllato, alla creazione di un indice ScaNN, fino allo switch atomico – è possibile sfruttare le più recenti innovazioni di modello mantenendo un’esperienza utente fluida e senza downtime programmato.