O que é um banco de dados vetorial?

Bancos de dados tradicionais são ótimos para encontrar correspondências exatas: o usuário com este e-mail, o pedido com este número. Mas como encontrar documentos com significado parecido a uma pergunta, mesmo que não compartilhem nenhuma palavra? É aí que entram os bancos de dados vetoriais, a tecnologia por trás da busca semântica e de sistemas de IA com memória. Neste artigo você vai entender o que são, como funcionam e quando usá-los.

O problema que eles resolvem

Imagine um usuário que pergunta "como cancelo minha assinatura?". Na sua base de ajuda, o artigo certo se chama "Encerrando seu plano". Uma busca por palavras-chave falha: "cancelar" e "assinatura" não aparecem no título. O que essas frases têm em comum não são as palavras, e sim o significado.

Bancos de dados vetoriais foram criados para capturar exatamente isso. Em vez de comparar texto literal, eles comparam vetores — listas de números que representam o significado de um conteúdo. Conteúdos com sentido próximo viram vetores próximos no espaço, e a busca passa a ser por proximidade, não por correspondência exata.

A busca por palavra-chave tradicional (como a baseada em BM25) tem um nome técnico para sua limitação: o descasamento de vocabulário (vocabulary mismatch). Quando o usuário e o documento usam palavras diferentes para a mesma ideia, a busca léxica perde o resultado. A busca vetorial é justamente a resposta para esse problema, porque opera no nível do significado e não das letras. Isso não torna a busca por palavra-chave obsoleta — ela continua imbatível para termos exatos, códigos e nomes próprios —, mas a complementa onde ela é fraca.

Embeddings: o ingrediente fundamental

A peça central de um banco vetorial são os embeddings, representações numéricas de texto, imagens ou áudio. Um modelo de IA transforma uma frase em um vetor de centenas ou milhares de dimensões, posicionando significados parecidos próximos uns dos outros.

A intuição de que o significado pode ser capturado pela posição em um espaço vetorial vem de trabalhos como o de Mikolov et al. (2013), que mostraram que relações semânticas e até analogias emergem das coordenadas dos vetores. Mais tarde, Karpukhin et al. (2020) demonstraram, com o Dense Passage Retrieval, que recuperar passagens por similaridade de vetores densos supera buscas baseadas em palavras-chave em tarefas de perguntas e respostas.

Um embedding simplificado pode ser visto assim:

# Cada texto vira um vetor de números (aqui, reduzido para ilustrar)
"como cancelo minha assinatura" -> [0.12, -0.84, 0.33, ...]
"encerrando seu plano"          -> [0.10, -0.79, 0.36, ...]
"receita de bolo de cenoura"    -> [-0.55, 0.21, -0.90, ...]

Repare que os dois primeiros vetores são numericamente próximos, enquanto o terceiro está distante. O banco vetorial usa essa proximidade para decidir o que é relevante.

A dimensionalidade importa

Modelos de embedding modernos produzem vetores com dimensões variando tipicamente entre algumas centenas e alguns milhares. Mais dimensões podem capturar nuances mais finas de significado, mas custam mais memória e tornam a busca mais cara. Há um detalhe contraintuitivo aqui: em espaços de altíssima dimensão, todas as distâncias tendem a se parecer — fenômeno conhecido como "maldição da dimensionalidade". É por isso que os índices especializados e as medidas de similaridade certas são tão importantes; comparar vetores de alta dimensão de forma ingênua não escala. Uma decisão prática que decorre disso: mantenha sempre o mesmo modelo de embedding para indexar e para consultar. Vetores de modelos diferentes vivem em espaços incompatíveis e não podem ser comparados.

Como medir similaridade

Para dizer que dois vetores são "parecidos", o banco calcula uma medida de similaridade. As mais comuns são:

Na prática, a similaridade do cosseno é a escolha mais frequente para texto. Quanto mais próximo de 1, mais semanticamente parecidos os conteúdos são.

Um detalhe técnico útil: quando os vetores estão normalizados (todos com comprimento 1), a similaridade do cosseno e o produto interno produzem o mesmo ordenamento de resultados. Muitos modelos já entregam embeddings normalizados, e vários bancos vetoriais normalizam internamente. Isso permite usar o produto interno, que é computacionalmente mais barato, sem perder o comportamento do cosseno. Vale escolher a medida de acordo com a recomendação do modelo de embedding que você usa, pois ela costuma estar documentada.

Busca aproximada de vizinhos (ANN)

Comparar a sua consulta com todos os vetores armazenados, um a um, funciona para milhares de itens, mas não para milhões. A solução são algoritmos de busca aproximada de vizinhos mais próximos (ANN — Approximate Nearest Neighbor).

Em vez de garantir o resultado perfeito, eles encontram os vizinhos quase certos com altíssima velocidade, usando estruturas de índice especializadas:

O ponto-chave é o trade-off: você troca uma pitada de precisão por ganhos enormes de velocidade e escala. Para a maioria das aplicações, a diferença de qualidade é imperceptível.

Como o HNSW funciona, em poucas palavras

O HNSW (Malkov e Yashunin, 2018) merece uma intuição porque é o índice padrão na maioria dos bancos vetoriais modernos. Ele organiza os vetores em um grafo de várias camadas, como um mapa de metrô com linhas expressas e locais. A busca começa na camada mais alta, com poucos nós muito espalhados, e "salta" grandes distâncias rapidamente; ao se aproximar do alvo, desce para camadas mais densas e refina a busca em vizinhanças cada vez menores. O resultado é encontrar os vizinhos próximos visitando apenas uma fração minúscula dos vetores.

Esse comportamento é controlado por parâmetros que expõem o trade-off explicitamente:

Ajustar ef_search é a alavanca mais comum em produção: ela permite escolher, por consulta, entre velocidade e qualidade do recall sem reconstruir o índice.

Como é o fluxo na prática

Usar um banco vetorial envolve duas fases distintas. Primeiro, a indexação (offline):

Depois, a consulta (em tempo real):

Em pseudocódigo, a consulta fica clara:

# 1. Pergunta vira vetor
consulta = embed("como cancelo minha assinatura")

# 2. Banco devolve os 3 trechos mais parecidos
resultados = vector_db.search(consulta, top_k=3)

for r in resultados:
    print(r.texto, r.score)

Muitos bancos vetoriais permitem combinar a busca por similaridade com filtros de metadados (por exemplo, "apenas documentos do idioma pt-BR"), unindo o melhor da busca semântica com a precisão dos filtros tradicionais.

O chunking é uma decisão de projeto, não um detalhe

A etapa de quebrar documentos em pedaços (chunking) influencia diretamente a qualidade da busca, e é subestimada por quem está começando. Chunks grandes demais diluem o significado: um pedaço com muitos assuntos gera um embedding "médio" que não casa bem com nenhuma pergunta específica. Chunks pequenos demais perdem contexto: uma frase isolada pode não ter informação suficiente para ser útil. Estratégias comuns incluem dividir por parágrafos ou seções, manter uma sobreposição (overlap) entre pedaços vizinhos para não cortar ideias ao meio, e respeitar a estrutura do documento (títulos, listas). Não existe tamanho ótimo universal — ele depende do tipo de conteúdo e deve ser avaliado, como mostra a disciplina de Como avaliar aplicações de LLM (LLM evals) aplicada à etapa de recuperação.

Busca híbrida: o melhor dos dois mundos

Na prática, muitos sistemas de produção não usam só busca vetorial. Eles combinam a busca semântica (vetorial) com a busca léxica (por palavra-chave, como BM25) numa abordagem híbrida, e fundem os resultados. A busca léxica acerta termos exatos, códigos de produto e nomes próprios que a vetorial às vezes erra; a vetorial captura o significado quando o vocabulário difere. Combinar as duas, frequentemente com uma técnica de fusão de ranqueamento, costuma entregar resultados melhores que qualquer uma sozinha.

Erros comuns ao começar com bancos vetoriais

Onde isso é usado: RAG e busca semântica

A aplicação mais importante hoje é o RAG (Retrieval-Augmented Generation). A ideia é simples e poderosa: antes de o modelo de linguagem responder, você recupera os trechos mais relevantes da sua base no banco vetorial e os injeta no prompt como contexto. Assim, o modelo responde com base nos seus dados, reduzindo alucinações.

Se você quer ver isso funcionando de ponta a ponta — desde a quebra dos documentos até a montagem do prompt — vale acompanhar um guia de RAG na prática, que mostra como dar memória e contexto a um LLM usando um banco vetorial como peça central.

A outra grande aplicação é a busca semântica, em que o usuário encontra resultados por significado, não por palavras exatas. É o que melhora buscas em e-commerces, bases de conhecimento e ferramentas de suporte. Além dessas, bancos vetoriais sustentam sistemas de recomendação ("itens parecidos com este"), deduplicação (encontrar conteúdos quase idênticos), detecção de anomalias (o que está longe de tudo) e busca multimodal (encontrar imagens a partir de texto, quando os embeddings de imagem e texto vivem no mesmo espaço).

Operação na vida real: o que muda com o tempo

Um detalhe que separa o protótipo do sistema de produção é o ciclo de vida dos dados. Documentos mudam, são criados e apagados — e o índice precisa acompanhar. Alguns pontos práticos:

Tratar o banco vetorial como um sistema vivo — com monitoramento de latência, recall e custo — evita a surpresa comum de um protótipo brilhante que degrada silenciosamente quando a base e o tráfego crescem.

Banco vetorial vs banco tradicional

É importante entender que o banco vetorial não substitui o seu banco de dados relacional ou NoSQL. Eles resolvem problemas diferentes:

Na prática, eles convivem. Você guarda os dados de negócio no banco principal e mantém os embeddings no banco vetorial. Algumas opções populares são Pinecone, Weaviate, Qdrant e Milvus, além de extensões que adicionam capacidade vetorial a bancos existentes, como o pgvector no PostgreSQL — uma forma prática de começar sem adotar uma nova infraestrutura.

Banco dedicado ou extensão? Como escolher

A decisão entre um banco vetorial dedicado e uma extensão como o pgvector é, na maioria dos projetos, uma questão de escala e operação. Para volumes de milhares a poucos milhões de vetores, manter tudo no PostgreSQL com pgvector é frequentemente a melhor escolha: você reaproveita a infraestrutura, os backups, as transações e os filtros SQL que já conhece, sem mais um serviço para operar. Há um ganho subestimado aqui: como o vetor vive ao lado dos dados de negócio na mesma tabela, você combina similaridade e filtros relacionais numa única consulta transacional, sem sincronizar dois sistemas nem lidar com a inconsistência de um documento existir num lugar e não no outro. Veja como uma consulta fica natural dentro do SQL:

-- pgvector: encontra os 5 trechos mais próximos da consulta,
-- já filtrando por metadados como qualquer query normal
SELECT id, texto
FROM documentos
WHERE idioma = 'pt-BR'
ORDER BY embedding <=> '[0.12, -0.84, 0.33, ...]'
LIMIT 5;

O operador <=> calcula a distância de cosseno. Para escalas muito maiores (dezenas de milhões a bilhões de vetores), alta taxa de consultas por segundo ou necessidade de recursos avançados de indexação distribuída, um banco dedicado tende a compensar a complexidade operacional extra. A regra prática: comece simples, com a infraestrutura que já tem, e migre para um banco dedicado quando medir um gargalo real — não antes.

Perguntas frequentes

Preciso de um banco vetorial para começar com IA? Não necessariamente. Para poucos documentos, uma busca em memória ou uma extensão como pgvector resolve. O banco dedicado faz sentido quando o volume e a taxa de consultas crescem.

A busca aproximada (ANN) compromete a qualidade? Quase nunca de forma perceptível. Você troca uma fração mínima de recall por ganhos enormes de velocidade. Parâmetros como ef_search permitem ajustar esse equilíbrio caso necessário.

Posso misturar busca vetorial com filtros normais? Sim, e deve. A maioria dos bancos vetoriais e do pgvector permite combinar similaridade com filtros de metadados (idioma, data, categoria), o que melhora muito a precisão.

Qual medida de similaridade usar? Para texto, comece com a similaridade do cosseno e siga a recomendação do modelo de embedding escolhido. Se os vetores forem normalizados, o produto interno dá o mesmo resultado de forma mais barata.

Embeddings de modelos diferentes podem ser comparados? Não. Vetores de modelos distintos vivem em espaços diferentes. Use o mesmo modelo para indexar e consultar; ao trocar de modelo, reindexe toda a base.

Conclusão

Um banco de dados vetorial armazena significados na forma de embeddings e responde à pergunta "o que é parecido com isto?" usando medidas de similaridade e índices de busca aproximada como o HNSW. Sustentado por ideias de Mikolov et al. (2013) e validado em recuperação por Karpukhin et al. (2020), ele é a fundação da busca semântica e do RAG. Decisões de projeto como o tamanho dos chunks, a medida de similaridade e a opção entre banco dedicado e extensão definem a qualidade do resultado. Ao combiná-lo com seus bancos tradicionais e, muitas vezes, com a busca léxica numa abordagem híbrida, você abre as portas para aplicações de IA que entendem o conteúdo, e não apenas as palavras.

Referências