Estamos no pico dos bancos de dados vetoriais?

Artigo original ↗ Discussão no Hacker News ↗

Em meio a um boom de ferramentas para armazenar e pesquisar embeddings gerados por IA, muitos engenheiros questionam se “bancos de dados vetoriais” especializados são exagerados para a maioria dos usos reais, em que os volumes de dados são modestos e a busca por força bruta em RAM ou extensões do PostgreSQL como pgvector funcionam bem. Os participantes argumentam que a busca por similaridade de cosseno é apenas uma feature que os bancos de dados tradicionais provavelmente absorverão, e que os problemas mais difíceis e valiosos estão no ajuste fino de modelos, na busca híbrida lexical-vetorial e em preocupações operacionais como re-embedding e escala. Há amplo ceticismo sobre as perspectivas de longo prazo de muitas startups de bancos de dados vetoriais, junto com o consenso de que a busca vetorial em si continua importante, mas ainda não é uma tecnologia totalmente “resolvida”.

Escopo e Necessidade de Bancos de Dados Vetoriais

  • Muitos argumentam que a maioria dos casos de uso atuais de RAG e “copilot” é pequena o suficiente para que a busca por força bruta sobre vetores em memória (NumPy, PyTorch, Pandas, Parquet+FAISS) seja suficiente até cerca de ~100k–1M linhas, às vezes mais.
  • Bancos de dados vetoriais se tornam convincentes apenas em escalas maiores (milhões–bilhões de vetores), com requisitos rígidos de latência/QPS, ou quando os dados não cabem na RAM.
  • Vários observam que calcular embeddings (especialmente com modelos baseados em LLM) é ordens de magnitude mais caro do que a similaridade de cosseno, então a busca raramente é o principal gargalo nas fases iniciais.
  • Outros contrapõem que isso subestima consultas repetidas, custos de indexação e pressão de memória ao armazenar grandes números de vetores.

Postgres, Extensões e a Visão de “Feature, Não Produto”

  • Há um forte sentimento de que a busca vetorial é uma “feature” que será absorvida pelos bancos de dados mainstream (Postgres, MySQL, etc.), como aconteceu com JSON, OLAP, graph e document stores.
  • pgvector (e extensões semelhantes como Lantern, SQLite VSS) é visto como “bom o suficiente” para muitos sistemas de produção até milhões de documentos, com melhorias recentes como builds de índice multithread.
  • Bancos de dados vetoriais dedicados são vistos por alguns como sem um fosso defensável duradouro e provavelmente serão deslocados à medida que os RDBMS tradicionais expandirem as capacidades vetoriais e a busca híbrida.

Limitações Algorítmicas e de Pesquisa

  • ANN / indexação vetorial é descrita como ainda sendo uma área de pesquisa em aberto com tradeoffs insatisfatórios; ao contrário de B-trees, os métodos atuais são aproximados e frágeis em altas dimensões.
  • A busca por produto interno máximo é destacada como ainda mais difícil do que a ANN padrão devido à geometria pouco explorável e às diferentes distribuições de consultas versus índice.
  • Distância de cosseno versus distância euclidiana em altas dimensões, e o comportamento de embeddings como compressão com perdas / hashes perceptuais, também são discutidos.

Além de “Similaridade de Cosseno como Serviço”

  • Vários veem a “busca por similaridade de cosseno como serviço” como comoditizada ou supervalorizada; o trabalho mais difícil e valioso é:
    • Ajustar finamente modelos de embedding para consultas específicas de domínio.
    • Gerenciar o ciclo de vida dos embeddings: re-embedding quando os modelos mudam, armazenamento e recomputação.
    • Recuperação híbrida: combinar lexical (BM25), filtros de metadados e vetores, além de ranking.
    • Pré-processamento para RAG: chunking, adicionar fatos inferidos ou pares de perguntas e respostas, usar LLMs para enriquecer documentos antes de gerar embeddings.

Hype de Mercado e Direções Futuras

  • As opiniões divergem sobre se estamos no “pico” dos bancos de dados vetoriais ou apenas em uma fase inicial de corrida do ouro.
  • Muitos esperam consolidação: capacidades vetoriais dentro de plataformas de LLM e bancos de dados, além de alguns serviços de mais alto nível do tipo “Algolia-for-RAG” que escondem a complexidade de chunking e indexação.
  • A busca vetorial em dispositivo / na borda (por exemplo, para busca privada de fotos) é apontada como uma área emergente, mas ainda pouco atendida.