Busca vetorial barata só interessa se a consulta real couber no índice

A Tiger Data lançou em alpha o pg_vectorsearch, extensão aberta para PostgreSQL cujo índice PRISM usa particionamento e compressão em vez do grafo de vizinhança do HNSW.[7] A proposta é reduzir custo de busca de similaridade dentro do banco, com suporte a colunas existentes do pgvector mediante instalação da extensão e criação do novo índice.[7] Não é uma aceleração automática dos índices já instalados.

O que muda para quem desenvolve

Nos benchmarks do fornecedor com 100 milhões de vetores, PRISM construiu o índice em uma hora e quarenta minutos com 128 GB de memória, enquanto HNSW levou 42 horas com 512 GB.[7] Os números não tinham validação independente e o teste usou halfvec de 16 bits no HNSW.[7] Eles justificam investigar, não migrar por reflexo.

A extensão exige PostgreSQL 18 ou posterior, admite até 1.968 dimensões e ainda não oferece busca filtrada combinando WHERE e ORDER BY antes da disponibilidade geral.[7] Para uma aplicação que exige segregação por cliente, a ausência de filtragem é uma condição de arquitetura, não um detalhe a resolver depois do benchmark.

Como aplicar

Desenhe a prova de conceito a partir da consulta real. Separe uma amostra representativa de embeddings, perguntas e resultados esperados. Use busca exata como referência para medir recuperação e registre latência, memória, tempo de construção e espaço ocupado.

Depois acrescente o ciclo de vida dos dados: inserções, mudanças e exclusões na proporção esperada da aplicação. Compare o índice novo com a solução atual usando a mesma definição de qualidade. Um resultado rápido que deixa de recuperar documentos relevantes não é uma otimização equivalente.

Para aplicações com autorização por cliente, primeiro determine se o produto suporta a semântica necessária. Não substitua isolamento obrigatório por um filtro improvisado depois da recuperação. Se os requisitos não couberem no estágio atual, mantenha o experimento isolado e registre o impedimento.

Cuidados e limites

O rebalanceamento incremental ainda é incompleto, com operações gerais de fusão e realocação ausentes; mudanças frequentes podem degradar a organização e exigir reconstruções.[7] Inclua esse custo na conta, em vez de considerar apenas a construção inicial.

Minha leitura é que manter vetores e metadados no PostgreSQL pode simplificar uma arquitetura, mas simplicidade operacional não pode ser presumida a partir de um gráfico. Ela precisa incluir manutenção, recuperação e compatibilidade com as consultas.

O estágio alpha é uma ressalva concreta do lançamento.[7] A decisão prudente é avaliar a tecnologia como candidata para um requisito definido, não como substituta universal de HNSW ou de um serviço vetorial separado.

Fonte

[7] Fonte: InfoQ