Bancos de dados relacionais são ótimos para buscar por igualdade — “clientes com nome João”. Mas como buscar por significado — “documentos que falam sobre rescisão de contrato” sem usar exatamente essas palavras? É aí que entra o banco de dados vetorial, a peça de infraestrutura que habilita busca semântica e RAG em escala.
O que é um vetor (embedding)
Antes de entender o banco, é preciso entender o que ele armazena.
Um embedding é uma representação numérica de um texto (ou imagem, áudio, vídeo) na forma de um vetor de números — tipicamente centenas ou milhares de dimensões. O que torna isso poderoso é que o modelo de embedding é treinado para colocar textos com significados semelhantes próximos uns dos outros nesse espaço dimensional.
Na prática: a frase “cancelamento de contrato” e a frase “rescisão do acordo” ficam próximas no espaço vetorial — mesmo sem nenhuma palavra em comum. Uma busca por “rescisão” encontra documentos que falam em “cancelamento” porque o embedding capturou a proximidade semântica.
Isso é algo que SQL não consegue fazer. WHERE texto LIKE '%rescisão%' não encontra documentos que dizem “cancelamento”. Um vector database sim.
Por que bancos convencionais não resolvem
Bancos relacionais (PostgreSQL, MySQL): ótimos para dados estruturados e buscas por igualdade, intervalo ou padrão textual. A busca full-text (índices GIN/GiST) consegue busca por palavras-chave, mas não por significado.
Bancos NoSQL (MongoDB, Elasticsearch): Elasticsearch tem busca full-text avançada e até suporte a vetores na versão mais recente — mas a busca vetorial não é o design primário, e o desempenho em alta dimensionalidade a grande escala é limitado.
O que é diferente num vector database: é construído do zero para armazenar vetores de alta dimensão e executar busca por similaridade aproximada (ANN — Approximate Nearest Neighbor) em grandes volumes com baixa latência. Algoritmos como HNSW (Hierarchical Navigable Small World) e IVF (Inverted File Index) tornam isso possível em milissegundos mesmo com milhões de vetores.
Como um vector database funciona
O fluxo tem duas fases:
Indexação (offline):
- Cada documento é convertido em embedding pelo modelo de embeddings
- O vetor é armazenado no banco junto com os metadados (ID, fonte, texto original)
- O índice ANN é construído/atualizado para permitir busca rápida
Busca (online):
- A query do usuário é convertida em embedding
- O banco encontra os N vetores mais próximos (maior similaridade cosseno ou euclidiana)
- Os documentos correspondentes são retornados com score de similaridade
"rescisão de contrato" → [0.23, -0.87, 0.41, ...] → busca ANN → documentos sobre cancelamento, rescisão, término de acordoPrincipais opções no mercado
| Solução | Tipo | Ponto forte | Ideal para |
|---|---|---|---|
| Pinecone | SaaS gerenciado | Escala sem operação, simples de usar | Times sem ops, MVP rápido |
| Weaviate | Open source / cloud | Multimodal, GraphQL, módulos de ML | Casos complexos, dados mistos |
| Qdrant | Open source / cloud | Alta performance, filtros avançados | Produção exigente, on-premises |
| Milvus | Open source | Escala massiva, nativo Kubernetes | Grandes volumes, enterprise |
| pgvector | Extensão PostgreSQL | Integrado ao banco existente | Escala moderada, stack PostgreSQL |
| ChromaDB | Open source | Simplicidade, ideal para dev | Prototipação, RAG local |
pgvector merece atenção especial: se você já usa PostgreSQL, adicionar busca vetorial pode ser tão simples quanto instalar a extensão. Para volumes até alguns milhões de vetores, funciona bem sem precisar de infraestrutura nova. Para escala muito grande, as soluções dedicadas têm vantagem.
Casos de uso principais
RAG (Retrieval Augmented Generation): o uso mais comum hoje. O vector database armazena os chunks dos seus documentos internos; quando uma pergunta chega, ele recupera os mais relevantes para o LLM responder.
Busca semântica: o usuário digita “política de férias coletivas” e encontra o documento que usa os termos “recesso coletivo anual” — sem keyword matching.
Sistema de recomendação: “usuários que curtiram X também curtiram Y” — comparando vetores de itens e perfis de usuários no espaço semântico.
Detecção de duplicatas: documentos ou registros semanticamente similares são identificados mesmo com texto diferente — útil para deduplicação de bases de clientes ou análise de contratos similares.
Busca por imagem: com modelos multimodais, você armazena embeddings de imagens e busca por imagem similar ou por descrição textual.
Considerações de infraestrutura
Vector databases dedicados (Qdrant, Milvus, Weaviate) podem ser rodados on-premises, o que é relevante quando os dados indexados são sensíveis. Em sistemas RAG com dados confidenciais, o ideal é:
- Modelo de embedding rodando localmente (sem enviar texto para API externa)
- Vector store on-premises (dados não saem)
- LLM rodando localmente
Esse stack completo é viável com ferramentas open source e hardware adequado — e garante conformidade LGPD sem depender de APIs externas.
A Adentro pode hospedar sua stack de RAG completa — vector store, modelo de embedding e LLM — em cloud privada, sem que nenhum dado interno saia da sua infraestrutura.