Capítulo 4 — Escolhendo o Banco de Dados Vetorial Certo

Quarto post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. A parte de um sistema RAG que cresce mais rápido, custa mais em escala e prende o time mais forte — escolhida por mérito técnico e decidida por mérito operacional.

Por que este capítulo existe

O banco de dados vetorial é a camada de armazenamento do sistema de recuperação, e a escolha é uma decisão multi-eixo — performance, residência dos dados, formato operacional do time, custo total de propriedade ao longo da vida do sistema. Uma escolha errada prende por anos, porque mover um bilhão de embeddings entre sistemas é um projeto que nenhum time encara à toa. As comparações técnicas são úteis, mas a escolha costuma ser decidida nos três eixos que as comparações técnicas escondem: onde os dados podem morar, o que o time consegue operar e quanto o sistema custa ao longo de sua vida.

4.1 Arquiteturas: dedicado versus extensão

A primeira decisão, frequentemente sem nome, é entre adotar um sistema novo construído de propósito para cargas vetoriais e estender um sistema que o time já opera. Um banco dedicado — Pinecone, Qdrant, Milvus, Weaviate, Vespa — é engenhado a partir do índice para fora. Planner de query, layout de armazenamento, modelo de replicação e API são todos desenhados para consultas de vizinhos mais próximos aproximadas sobre vetores de alta dimensão. Tetos de performance mais altos, especialmente em queries híbridas filtro-mais-vetor; outro sistema para operar.

A abordagem por extensão — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, Redis com RediSearch — adiciona busca vetorial a um banco que o time já roda. Nada de nova autenticação, procedimento de backup, rodízio de plantão ou cadência de patch. O teto de performance é fixado pela arquitetura do host e geralmente está bem acima do que aplicações abaixo da faixa de dezenas de milhões de vetores precisam. A decisão raramente é uma pergunta pura de performance. É mais comumente uma pergunta sobre onde o time está disposto a gastar seu orçamento operacional — um time rodando um Postgres não quer operar um segundo banco; um time rodando dez serviços de dados não pisca diante de um décimo primeiro.

4.2 Líderes gerenciadas: Pinecone e Vertex

Pinecone é o banco vetorial gerenciado canônico. Simplicidade operacional, latência previsível, um SDK maduro, e um tier serverless que separa storage de compute e cobra pelo uso real em vez de capacidade provisionada. O default certo para novas implantações a menos que o workload se beneficie especificamente de capacidade reservada. O preço é o lock-in arquitetural que todo sistema gerenciado proprietário carrega — embeddings são portáveis em princípio, mas o custo de exportar e reindexar é real. Vertex AI Vector Search é a oferta do Google, construída sobre a biblioteca ScaNN que move a busca de similaridade em larga escala da própria Google. Teto de escala maior, integração estreita com o resto do GCP — modelos de embedding, IAM, Cloud Monitoring — e o comprometimento estratégico correspondente com uma única nuvem. Azure AI Search ocupa a mesma posição para times comprometidos com a Microsoft. A escolha entre as três opções nativas de plataforma geralmente segue o compromisso de nuvem existente, o que é razoável desde que o time tenha verificado escala e residência.

4.3 Open-source: Qdrant, Milvus, Weaviate

A categoria open-source é para times que querem controlar a própria infraestrutura — por custo, residência ou razões estratégicas — e têm capacidade operacional para rodar sistemas distribuídos. Qdrant é o menor e mais focado: escrito em Rust, deployável como binário único, engenhado para busca vetorial de baixa latência com forte suporte a filtragem e quantização. Acessível o bastante para estar rodando em minutos; a escolha certa para a menor pegada operacional possível. Milvus é o maior e mais orientado a empresa — arquitetura cloud-native separando compute, storage e metadata, com o maior teto de escala da categoria (corpora na casa do bilhão, índices acelerados por GPU, armazenamento tiered). Complexidade operacional significativa, mitigada pelo Zilliz Cloud. Weaviate fica entre eles — mais cheio de features que o Qdrant, menos complexo que o Milvus, com módulos embutidos para embedding, reranking e multi-tenancy. Uma plataforma de busca, não só um índice de busca. Os três são Apache-licenciados no núcleo com ofertas gerenciadas pagas, e benchmarks ficam dentro de um fator constante pequeno um do outro. A decisão é fit, não performance bruta.

4.4 Embedded e Postgres: Chroma e pgvector

A maioria das implantações RAG reais serve dezenas de queries por segundo sobre algumas centenas de milhares de vetores, não milhões por segundo sobre bilhões. Para esses workloads a ferramenta certa roda no processo da aplicação ou ao lado dele. Chroma é a opção embedded — in-process por padrão, persiste em disco local, o caso mais simples não pede configuração. Certa para protótipos, ferramentas que vêm com seus próprios dados e implantações de produção que cabem numa máquina. pgvector adiciona um tipo vetor, operadores de distância e indexação HNSW/IVFFlat ao Postgres. Para corpora de até cerca de dez milhões de vetores num host bem provisionado, pgvector é uma escolha de produção crível e a opção operacionalmente mais simples para times já rodando Postgres. Busca vetorial vira uma query SQL contra uma tabela que o ORM existente entende; joins com metadados estruturados são de primeira classe. A virtude escondida dessas opções é que elas baixam o custo de mudar de ideia — a migração para um sistema distribuído, se acontecer, é limitada.

4.5 Residência, operações e custo — os eixos que de fato decidem

Os três eixos operacionais merecem nome porque é onde as decisões de produção são realmente decididas. Residência de dados estreita a lista de candidatos antes de qualquer comparação técnica fazer sentido. Proteção de dados na UE, regulação de serviços financeiros, compromissos de nuvem soberana — essas restrições não são negociáveis, e a pergunta a fazer primeiro a qualquer fornecedor é quais regiões ele suporta e quais são seus compromissos contratuais de tratamento de dados. Uma armadilha particular: embeddings são dados derivados, mas permanecem dados pessoais sob a maior parte dos frameworks regulatórios porque podem ser invertidos ou usados para recuperar o original por similaridade. Um contrato que cobre documentos brutos mas é vago sobre embeddings está incompleto.

Formato operacional é a capacidade do próprio time. Um time de três engenheiros rodando um serviço de aplicação deveria escolher a opção que adiciona a menor superfície operacional — pgvector, um Pinecone ou Qdrant Cloud gerenciado, Chroma embedded. Um time de trinta absorve a complexidade de um sistema distribuído open-source pelas vantagens de custo e capacidade. O erro é escolher um sistema descasado da capacidade real do time de operá-lo. Custo total ao longo da vida do sistema inclui provisionamento, monitoração, backup, ensaios de restore, planejamento de capacidade, trabalho de upgrade e o custo proporcional do tempo de plantão. O enquadramento honesto pergunta o custo em três cenários — workload atual, 10x, 100x — porque a inclinação da curva importa tanto quanto o ponto de partida.

O que o Capítulo 4 prepara

O banco vetorial determina o que a camada de armazenamento pode segurar, com que velocidade ela pode ser consultada e quais padrões de filtro e metadado ela suporta. Nenhuma dessas propriedades sozinha decide qualidade de recuperação — elas decidem o que é possível construir por cima. O que se constrói por cima é o pipeline de recuperação, onde os ganhos compõem: busca híbrida combinando vetores densos com BM25, reciprocal rank fusion sobre retrievers heterogêneos, reranking com cross-encoder, e a camada de entendimento de query que faz a ponte entre como o usuário pergunta e como os documentos respondem.

Próximo — Capítulo 5: Arquitetando o Pipeline de Recuperação. Como busca vetorial densa e recuperação por palavras-chave se combinam via reciprocal rank fusion, o passo de reranking com cross-encoder que fecha a maior parte do gap de qualidade restante, e a camada de entendimento de query que faz o resto.