Banco de dados vetorial (vector database) é a peça que transforma texto, imagem, áudio e código em coordenadas matemáticas (embeddings) e permite encontrar o que é semanticamente parecido, e não só o que tem a mesma palavra. É a fundação técnica de RAG, busca semântica, recomendação inteligente, deduplicação e quase tudo o que vai além de keyword search em aplicações modernas com IA.
Este guia explica o que é embedding, como funciona um vector DB, como escolher entre Pinecone, Qdrant, Weaviate, Milvus, pgvector e Chroma, como projetar índices para escala e como evitar os erros que destroem qualidade de RAG na prática.
O que é embedding e por que importa
Um embedding é um vetor de números (tipicamente 768, 1024, 1536 ou 3072 dimensões) que representa o significado de um conteúdo. Textos que falam a mesma coisa, mesmo com palavras diferentes, ficam próximos no espaço vetorial. "Como cancelar minha assinatura" e "quero parar de pagar" terão embeddings vizinhos, ainda que não compartilhem nenhuma palavra-chave.
Embeddings são gerados por modelos específicos: OpenAI text-embedding-3, Voyage, Cohere Embed, BGE, Nomic Embed, e variantes especializadas por idioma e domínio. A escolha do modelo de embedding tem impacto enorme na qualidade do RAG, mais do que muita gente imagina.
O que um vector database faz
Três operações são o coração. 1. Ingestão: receber documento, dividir em chunks, gerar embedding de cada chunk, armazenar com metadados. 2. Busca por similaridade: dado um vetor de consulta, retornar os k vetores mais próximos segundo distância cosseno, produto interno ou euclidiana. 3. Filtro híbrido: combinar similaridade vetorial com filtros tradicionais (data, autor, categoria, ACL) para resultados úteis.
Por baixo, o motor usa algoritmos como HNSW, IVF, ScaNN ou DiskANN para indexação aproximada que escala a bilhões de vetores com latência de milissegundos. Busca exata em alta dimensão é cara; a graça do vector DB é entregar resultado quase-exato com custo viável.
Comparativo das principais opções em 2026
Pinecone: managed, simples, escala fácil, custo alto a partir de certo volume. Bom para começar rápido. Qdrant: open-source, self-host ou cloud, performance excelente, filtros poderosos, suporte a payloads ricos. Favorito da comunidade. Weaviate: open-source, multi-modal, GraphQL nativo, integração com várias fontes. Milvus: open-source, foco em escala (bilhões de vetores), comunidade chinesa forte, mais complexo de operar. pgvector: extensão do Postgres. Ganhou tração imensa em 2025 por permitir reusar Postgres como vector DB, com tudo o que isso traz (transação, ACID, ferramentas conhecidas). Chroma: leve, focado em desenvolvimento local e protótipos, simples de subir.
A escolha depende de três eixos: volume (milhares vs bilhões de vetores), operação (managed vs self-host) e requisitos (filtros complexos, multi-tenant, ACL). Para a maioria dos casos corporativos em 2026, pgvector ou Qdrant resolvem com folga.
Estratégia de chunking
A forma como você divide o documento em chunks determina a qualidade do RAG mais do que qualquer outra escolha. Chunks pequenos (256-512 tokens): precisão alta, contexto limitado, risco de perder coesão. Chunks médios (512-1024 tokens): equilíbrio bom para a maioria dos casos. Chunks grandes (1024-2048 tokens): coesão alta, custo maior, dilui o sinal.
Padrões avançados que melhoram resultados: chunking por estrutura (parágrafo, seção, código), não por contagem cega; overlap entre chunks para preservar contexto; parent-child, indexando chunks pequenos mas retornando o chunk pai maior; contextual chunks, adicionando título e breadcrumb do documento em cada chunk.
Híbrido: vetor + keyword
Busca puramente vetorial perde em queries específicas com termos exatos (nome de produto, código, sigla). Busca puramente keyword perde em queries com paráfrase. O caminho moderno é híbrido: combinar BM25 (keyword) e similaridade vetorial, com re-ranking final. Ferramentas como Qdrant, Weaviate e Elasticsearch já oferecem isso nativo.
Em RAG sério, adicionar um re-ranker (Cohere Rerank, Voyage Reranker, BGE Reranker) sobre os top-K iniciais costuma elevar precisão de forma notável, com custo aceitável.
Operação em produção
Quatro cuidados que separam protótipo de produção. 1. Métricas de retrieval: meça recall@k, precision@k, MRR em conjuntos de avaliação representativos. 2. Reindexação controlada: trocar modelo de embedding implica reindexar tudo. Tenha pipeline e versão de embedding por documento. 3. Backup e disaster recovery: vector DB é base de produto; trate como banco crítico. 4. Controle de acesso: vector DB pode vazar dados sensíveis se filtros de ACL forem mal aplicados. Aplique filtro de permissão no índice, não só na resposta.
Custo: armadilhas comuns
Custo de vector DB costuma surpreender. Os culpados frequentes: chunks pequenos demais multiplicam o número de vetores; embeddings de 3072 dimensões custam 2x armazenamento vs 1536; reindexação por troca de modelo dobra custo temporariamente; cloud managed cobra por requisição além de armazenamento. Boas práticas: monitorar custo por feature (não só total), quantização de vetores em índices grandes, tiered storage separando "hot" e "cold" data.
RAG não é só vector DB
Um erro frequente é confundir RAG com "instalar vector DB". O vector DB é uma peça. RAG bom exige pipeline de ingestão que extrai conteúdo de PDFs, sites, bases internas com fidelidade; chunking inteligente; geração de embeddings com modelo adequado; retrieval híbrido com filtros e re-ranking; prompt que injeta o contexto da forma certa; citação da fonte na resposta; avaliação contínua com dataset próprio. Pular qualquer peça quebra qualidade.
Quando vector DB não é a resposta
Para volume baixo (até alguns milhares de documentos), cache em memória ou índice simples já resolvem. Para queries com termo exato (id, código, nome), busca tradicional com inverted index vence. Para dado tabular estruturado, SQL permanece imbatível. A regra: use vector DB onde semântica importa e o conjunto é grande o suficiente para justificar a complexidade. Senão, mantenha simples.
