AlloyDB AI: Atualize Modelos de Embedding Sem Interrupções

Imagine lançar uma nova funcionalidade de busca semântica para avaliações de produtos, que ajuda seus clientes a pesquisar itens rapidamente em seu site. Os usuários adoram. No entanto, no dia seguinte, surge um anúncio de um novo modelo de embedding vetorial, prometendo maior precisão, melhor nuance e busca multilíngue nativa. Após testá-lo em seu ambiente de desenvolvimento, você confirma que ele é perfeito. Mas, e agora? Como atualizar o modelo sem interromper seus usuários?

Atualizar modelos de embedding em produção geralmente exige a re-geração de todos os seus dados, a reconstrução de índices e a coordenação de migrações de esquema sem interromper as consultas dos usuários. Isso pode apresentar diversos desafios:

• Geração de Embeddings: Todos os dados existentes precisam ser re-gerados com o novo modelo, o que implica atualizar pipelines complexos e usar estratégias de escrita dupla enquanto os modelos antigo e novo operam em paralelo por um período.
• Incompatibilidade Matemática: Embeddings gerados por modelos diferentes residem em espaços vetoriais distintos e não podem ser comparados diretamente. Os vetores de consulta da aplicação e os vetores armazenados na coluna devem mudar de modelo em uníssono para evitar degradação severa na busca.
• Sobrecarga de Reconstrução de Índice: Índices vetoriais precisam ser construídos sobre os novos vetores para que a busca por similaridade opere eficientemente em escala.
• Experiência do Usuário Degradada: A troca de modelos de embedding requer múltiplas alterações de DDL e outras operações que adquirem locks exclusivos, podendo paralisar transações de leitura e escrita se não forem cuidadosamente gerenciadas.

Como o AlloyDB AI Simplifica o Gerenciamento do Ciclo de Vida de Vetores

Neste artigo, destacamos como o rico conjunto de recursos do AlloyDB AI possibilita atualizações de modelos de embedding com zero downtime, garantindo que seus usuários se beneficiem dos avanços mais recentes dos modelos sem manutenções programadas. O gerenciamento de endpoints de modelo oferece acesso nativo dentro do banco de dados a qualquer modelo de embedding (de terceiros, primeiro ou até mesmo auto-hospedado). Já os auto embeddings geram rapidamente novos embeddings em segundo plano (até 3000 por segundo) e os mantêm atualizados conforme os dados de origem mudam. O uso do índice ScaNN do AlloyDB também pode reduzir significativamente o tempo de upgrade com construções de índice 10x mais rápidas que o HNSW open-source. Funcionalidades nativas do PostgreSQL, como criação de índice concorrente, funções que retornam conjuntos (SRF) e renomeação atômica de colunas, permitem rollouts transparentes no estilo blue/green e canary.

Passo a Passo da Migração

Neste exemplo, demonstramos a migração da tabela de produção ecomm.product_reviews do modelo text-embedding-005 (768 dimensões) para gemini-embedding-001 (3072 dimensões), servindo tráfego em tempo real.

Passo 0: Pré-requisitos e Verificações Iniciais

Verifique se a extensão google_ml_integration está atualizada para a versão 1.5.6 ou superior (testado na 1.6.1) e confirme a conectividade com o modelo:

-- Verifica a versão da extensão
SELECT extversion 
FROM pg_extension 
WHERE extname = 'google_ml_integration';

-- Cria extensões
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS alloydb_scann;

-- Verifica o endpoint remoto e a dimensão de saída (3072-d)
SELECT vector_dims(ai.embedding('gemini-embedding-001', 'hello world')::vector);

-- Inspeciona as configurações existentes de auto-embedding
SELECT * FROM ai.embedding_settings_view;

Passo 1: Adicionar a Nova Coluna de Vetor

Adicionar uma coluna anulável sem valores padrão atualiza os metadados do catálogo sem criar novas versões de cada linha. Isso torna a operação quase instantânea. Observe que o tamanho da sua coluna de vetor (3072 neste exemplo) deve corresponder ao número de dimensões de saída do seu modelo de embedding. Definimos também o lock_timeout para 2 segundos para evitar que a operação bloqueie o tráfego de produção crítico enquanto aguarda a aquisição de um lock exclusivo. Se a operação falhar devido a uma espera mais longa por um lock exclusivo, basta tentar novamente.

SET lock_timeout = '2s';

ALTER TABLE ecomm.product_reviews 
ADD COLUMN new_embedding_col vector(3072);

Passo 2: Inicializar Auto Embeddings e Executar Backfill

Em seguida, inicializamos os embeddings na nossa nova coluna de embedding usando gemini-embedding-001.

CALL ai.initialize_embeddings(
    model_id => 'gemini-embedding-001',
    table_name => 'ecomm.product_reviews',
    content_column => 'review_text',
    embedding_column => 'new_embedding_col',
    batch_size => 50,
    incremental_refresh_mode => 'manual'
);

Observe que existem dois modos disponíveis nos auto embeddings para manter os embeddings atualizados conforme os dados de origem mudam:

• Transacional: Quando você define incremental_refresh_mode como transactional, os embeddings são atualizados imediatamente quando os dados mudam. Isso mantém seus embeddings transacionalmente consistentes com os dados de origem, mas também introduz latência de escrita adicional com uma inferência inline do modelo de embedding exigida para cada operação INSERT/UPDATE. Use o modo transacional quando desejar manter seus dados de embedding transacionalmente consistentes com os dados de origem e sua taxa de alteração for baixa.
• Manual: Quando você define incremental_refresh_mode como manual, o AlloyDB rastreia quais linhas foram alteradas, mas não atualiza imediatamente...

Recomendado pelo autor

Mãos à obra: aprendizado de máquina com Scikit-Learn, Keras & TensorFlow: conceitos, ferramentas e técnicas para a construção de sistemas inteligentes

Ver Oferta

* Link de afiliado — o preço pode variar. Ao comprar, você apoia este blog sem custo extra.

Recomendado pelo autor

Data Science do Zero - 2º Edição: Noções Fundamentais com Python

Ver Oferta

* Link de afiliado — o preço pode variar. Ao comprar, você apoia este blog sem custo extra.