Vector Database

Bancos de dados tradicionais são otimizados para um tipo específico de busca: encontrar registros que satisfazem condições exatas. "Clientes onde cidade = 'São Paulo' AND renda > 5000." A query é determinística — ou satisfaz ou não satisfaz. Para busca de texto, índices como B-tree e full-text search permitem encontrar documentos que contêm palavras específicas.

Esse paradigma de busca não funciona bem para a classe de problemas que define muitas aplicações de IA modernas: busca semântica. "Encontre documentos sobre gerenciamento de equipes remotas" — sem mencionar as palavras exatas que podem aparecer nesses documentos. "Encontre imagens visualmente similares a esta imagem." "Encontre músicas com mood similar a esta faixa." Essas buscas dependem de similaridade de significado, não de correspondência exata de valores.

Vector Database (banco de dados vetorial) é um sistema de armazenamento e busca otimizado para embeddings — representações numéricas densas (vetores de alta dimensão) que codificam significado semântico. Em vez de buscar por igualdade ou range, busca por similaridade: encontrar os vetores mais próximos de um vetor de consulta no espaço multidimensional.

Um embedding é a representação de um dado (texto, imagem, áudio, produto) como um vetor de números de alta dimensão — tipicamente 384 a 4096 dimensões. O vetor é gerado por um modelo de ML treinado para que dados semanticamente similares produzam vetores próximos no espaço.

"Gato" e "felino" têm vetores próximos. "Maçã" e "apple" (mesmo objeto, língua diferente, em modelos multilinguais) têm vetores próximos. Uma foto de cachorro e outra foto de cachorro de raça diferente têm vetores de imagem próximos.

Essa propriedade — similaridade semântica refletida em proximidade no espaço vetorial — é o que torna embeddings úteis para busca semântica: para encontrar documentos similares à query, calcule o embedding da query e encontre os embeddings de documentos mais próximos.

A operação central de um vector database é Approximate Nearest Neighbor search (ANN) — encontrar os K vetores mais próximos de um vetor de consulta, de forma aproximada (exata demais seria computacionalmente inviável para bilhões de vetores).

Índices ANN:

HNSW (Hierarchical Navigable Small World): o algoritmo de ANN mais adotado. Constrói um grafo hierárquico navegável onde cada nó conecta a vizinhos próximos em múltiplas camadas. Busca começa pelo nível mais alto (menor densidade) e afunila para candidatos próximos nas camadas inferiores. Excelente trade-off entre velocidade e precisão. Usado pelo Pinecone, Weaviate, Qdrant e pgvector.

IVF (Inverted File Index): divide o espaço em clusters (via k-means), e na busca filtra apenas os clusters mais próximos da query antes de busca exata dentro dos clusters. Mais eficiente em memória que HNSW, mas levemente menos preciso.

ScaNN (Google), DiskANN (Microsoft): algoritmos de ANN de alta performance otimizados para escala muito grande. Usados internamente por Google e Microsoft.

Métricas de similaridade:

• Cosine similarity: mede o ângulo entre dois vetores — independe da magnitude. O padrão para embeddings de texto.
• Euclidean distance (L2): distância direta no espaço. Melhor quando a magnitude importa.
• Dot product: produto escalar. Mais rápido de calcular; equivalente a cosine quando vetores são normalizados.

Busca puramente vetorial frequentemente precisa ser combinada com filtros de metadata para casos de uso reais. "Encontre os documentos semanticamente similares à minha query que foram criados no último mês e pertencem ao departamento financeiro."

Vector databases modernos suportam filtros de metadata (campos escalares) combinados com busca vetorial — mas a implementação varia significativamente entre produtos. Alguns filtram antes da busca vetorial (pode reduzir qualidade do ANN), outros filtram depois (pode perder resultados relevantes), e os mais sofisticados intercalam filtragem e busca para balancear precisão e performance.

Pinecone: pioneiro e líder em vector database cloud-native. Totalmente gerenciado, serverless, escalável. Excelente performance e UX de operação. Caro em volume; sem opção self-hosted.

Weaviate: open source, self-hosted ou cloud. Suporta múltiplos tipos de vetores (texto, imagem), busca híbrida (vetorial + BM25), plugins de embedding integrados. Muito flexível e rico em features.

Qdrant: open source (Rust), performance excelente, cloud gerenciado disponível. Forte em filtragem de payload combinada com busca vetorial. Boa alternativa ao Pinecone com custo menor.

Chroma: open source, in-memory ou persistido, minimalista. Ideal para prototipagem e desenvolvimento local. Não é adequado para produção em escala.

Milvus: open source, Kubernetes-native. Focado em escala massiva — bilhões de vetores. Mais complexo de operar que alternativas.

pgvector: extensão do PostgreSQL que adiciona tipo de dado vetorial e busca ANN (HNSW e IVF). A opção mais simples para times que já usam PostgreSQL — elimina um sistema a gerenciar. Adequado para escala moderada; para bilhões de vetores, Pinecone ou Milvus são mais apropriados.

Redis Vector Search: extensão do Redis para vetores. Ideal quando Redis já é usado como cache e há necessidade de busca vetorial com baixa latência.

RAG (Retrieval-Augmented Generation) é o caso de uso que popularizou vector databases, mas não é o único.

Busca semântica de produtos: em e-commerce, busca que entende intenção ("tênis para academia" encontra produtos rotulados como "calçado esportivo para treino") além de correspondência de palavras-chave.

Sistemas de recomendação: encontrar produtos, conteúdos ou usuários similares. O item que o usuário interagiu recentemente gera um embedding; o sistema encontra embeddings próximos para recomendação.

Detecção de duplicatas e near-duplicates: verificar se um documento, imagem ou produto novo é similar a um já existente na base. Útil para deduplicação de conteúdo, detecção de plágio, identificação de produtos duplicados em catálogos.

Classificação zero-shot: embeddings de classes candidatas comparados ao embedding do item a classificar — sem necessidade de modelo específico treinado para a classificação.

Análise de sentimento e clustering: agrupar documentos semanticamente similares sem labels predefinidos — descoberta de tópicos em feedback de clientes, clustering de tickets de suporte.

Vector databases são a infraestrutura que habilita RAG e busca semântica — componentes centrais das aplicações de IA mais práticas do momento. Para qualquer time construindo sistemas com LLMs que precisam acessar conhecimento específico, um vector database é componente necessário.

A recomendação prática por caso de uso: para prototipagem, Chroma ou pgvector (se já usa PostgreSQL); para produção em escala moderada, Qdrant (open source, excelente performance, cloud disponível) ou pgvector com HNSW; para produção em grande escala com simplicidade operacional prioritária, Pinecone.

O investimento em entender embeddings e vector databases hoje é investimento em capacidade de construir as aplicações de IA que vão ser padrão nos próximos anos. É tecnologia fundamental que vai aparecer em contextos cada vez mais amplos — de busca de produtos a personalização a análise de documentos.