Pg_vectorize: busca vetorial e RAG no Postgres

Artigo original ↗ Discussão no Hacker News ↗

O Postgres está sendo cada vez mais empurrado para o papel de um banco de dados vetorial, com projetos como o pg_vectorize construindo sobre o pgvector para adicionar APIs de alto nível para embeddings, busca vetorial e retrieval-augmented generation (RAG) diretamente dentro do banco. Os comentaristas compartilham experiências reais com o pgvector em escala, o comparam com serviços especializados como Pinecone ou Meilisearch e discutem questões práticas como estratégias de chunking, recall, desempenho e controle de custos. Há entusiasmo em consolidar busca e recuperação no Postgres, mas também preocupação em esconder chamadas complexas de LLM em extensões de banco e ceticismo sobre o quão confiavelmente o RAG melhora os resultados em comparação com simplesmente usar janelas de contexto maiores ou modelos ajustados finamente.

Reação geral ao pg_vectorize e ao Postgres para vetores

  • Muitos veem com bons olhos empurrar o Postgres como uma plataforma de vetores/RAG, por considerá-lo algo que empodera desenvolvedores em vez de produtos proprietários de “vector DB”.
  • O pg_vectorize é visto como um wrapper de alto nível conveniente em torno do pgvector, cuidando da geração de embeddings, do gerenciamento de índices e da orquestração de consultas.
  • Alguns preferem usar o pgvector diretamente para manter o controle e evitar complexidade oculta.

Custos, hospedagem e arquitetura

  • RAG pode ser caro: você paga uma vez para embutir o corpus e depois, a cada consulta, por embeddings e tokens do LLM.
  • Modelos de embedding auto-hospedados (e, eventualmente, modelos de chat) são destacados como uma forma de controlar custos e manter os dados privados, mas aumentam a complexidade operacional.
  • Há debate sobre se embedding + recuperação deveriam ficar dentro do banco; alguns gostam da arquitetura mais simples, outros preferem fortemente uma separação limpa e nenhuma chamada de rede externa a partir do Postgres.

pgvector em escala

  • Há vários relatos de o pgvector funcionar em produção, inclusive com dezenas a centenas de milhões de linhas.
  • Pontos fortes: código aberto, indexação transparente, integração com dados relacionais, boa observabilidade.
  • Pontos de dor: forte dependência de vacuum, construções de índice HNSW grandes/lentas, suporte fraco a ANN filtrado e alguma fricção de API (por exemplo, Python + numpy).

Efetividade de RAG e alternativas

  • Experiências mistas: alguns consideram RAG ingênuo “ruim” ou pouco impressionante; outros relatam resultados excelentes, especialmente para PDFs internos e grandes corpora técnicos.
  • Sistemas mais fortes combinam RAG com estrutura de domínio (por exemplo, logs de suporte técnico, grafos de conhecimento, reforço por sinais de especialistas), alcançando recall muito maior do que “RAG puramente vetorial”.
  • Alguns sugerem que o uso direto de LLM com janelas de contexto grandes pode rivalizar ou superar RAG em certos domínios, mas outros argumentam que RAG continua mais barato, rápido e escalável para grandes corpora.

Chunking e estratégias de recuperação

  • Chunking simples de tamanho fixo muitas vezes tem desempenho inferior; vários comentários enfatizam:
    • Chunking hierárquico/semântico (por títulos, seções ou clusters de contexto).
    • Uso de modelos pequenos para realizar chunking semântico e resumos sensíveis ao contexto.
    • Abordagens de “context cluster”/baseadas em árvore e resumos hierárquicos (por exemplo, ideias semelhantes a RAPTOR).
    • Seleção cuidadosa de quais chunks cabem no contexto, com otimização estilo knapsack.
  • Alguns projetos usam embeddings em nível de sentença seguidos de clustering e indexação dos centróides.

Conceitos e equívocos sobre RAG

  • Esclarecimentos de que RAG não é apenas “LLM na frente da busca”, mas geração de LLM condicionada por contexto recuperado e ranqueado por vetores.
  • Vários observam que o “R” (retrieval) é um problema difícil, e similaridade vetorial é apenas uma parte; recuperação híbrida (palavras-chave, estrutura, vetores) costuma ser necessária.

Comparações, ferramentas e alternativas

  • pg_vectorize vs PostgresML: pg_vectorize transfere os modelos para serviços externos e foca em embeddings/RAG; PostgresML executa modelos no host do banco e suporta ML mais amplo (por exemplo, treinamento supervisionado).
  • Alternativas sugeridas para casos de uso menores ou diferentes: sqlite com extensões (sqlite-vss), DuckDB, Meilisearch, Elasticsearch/OpenSearch e bancos vetoriais dedicados.
  • Alguns argumentam que o Postgres é “bom o suficiente” e atraente porque já está na stack; outros preferem mecanismos de busca especializados para cargas grandes e complexas.