Banco de dados vetorial: o que é e como funciona

Banco de dados vetorial é um sistema de armazenamento otimizado para guardar embeddings — representações numéricas de texto, imagem, áudio ou vídeo — e buscar por similaridade entre eles em vez de por igualdade exata. É a peça de infraestrutura que torna prática a busca semântica e o retrieval de sistemas de RAG (Retrieval-Augmented Generation): sem ele, comparar um vetor de consulta com milhões de vetores armazenados, um por um, seria lento demais para qualquer aplicação real.

O que é um banco de dados vetorial

Um banco de dados vetorial é um banco especializado em armazenar vetores — arrays de números de ponto flutuante, normalmente com centenas ou milhares de posições — e em encontrar rapidamente quais vetores estão mais próximos de um vetor de consulta. Segundo a documentação do Pinecone e do Google Cloud, cada vetor é gerado por um modelo de embedding a partir de um dado original (uma frase, uma imagem, um trecho de código) e captura o significado desse dado: itens semanticamente parecidos ficam com vetores próximos no espaço, e itens diferentes ficam distantes.

Se você ainda não sabe como esses vetores são gerados, vale ler antes [o que são embeddings e como funcionam na IA](/artigo/embeddings-o-que-sao-como-funcionam-ia) — o banco de dados vetorial é literalmente onde esses embeddings moram depois de criados.

É por isso que todo pipeline de RAG depende de um banco vetorial: depois de transformar a base de conhecimento em embeddings, o sistema usa o banco para recuperar os trechos mais relevantes antes de enviar a pergunta ao modelo de linguagem. Para entender o pipeline completo, veja [o que é RAG (Retrieval-Augmented Generation)](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona).

Como funciona na prática

Na prática, um banco de dados vetorial resolve três problemas em sequência:

• Vetorização: cada item inserido passa por um modelo de embedding, que devolve um vetor de tamanho fixo. O modelo text-embedding-3-small da OpenAI, por exemplo, gera vetores de 1536 dimensões, segundo a documentação oficial da OpenAI.
• Indexação: em vez de guardar os vetores soltos, o banco constrói uma estrutura de índice pensada para busca por proximidade — as mais comuns são HNSW, IVF e PQ, segundo a documentação de fornecedores como Pinecone, Weaviate e Zilliz.
• Busca por similaridade: ao receber uma consulta, o banco transforma essa consulta no mesmo espaço vetorial e devolve os k vetores mais próximos, normalmente em milissegundos, mesmo com milhões de itens armazenados.

Esse último passo raramente é exato. Bancos vetoriais em produção usam busca aproximada de vizinhos mais próximos (Approximate Nearest Neighbor, ANN): trocam uma fração de precisão por um ganho grande de velocidade, varrendo apenas uma parte do espaço de vetores em vez de compará-los todos. É uma troca deliberada — e ela tem consequências que aparecem mais adiante neste texto.

HNSW e outros tipos de índice

O índice mais usado hoje é o HNSW (Hierarchical Navigable Small World). Segundo explicações técnicas da Zilliz e da TiDB (PingCAP), o HNSW organiza os vetores em um grafo de múltiplas camadas: as camadas superiores funcionam como atalhos que cobrem grandes distâncias rapidamente, e as camadas inferiores refinam a busca localmente até encontrar os vizinhos mais próximos. O resultado é uma busca rápida e com boa taxa de acerto (recall), ao custo de mais memória e mais tempo de construção do índice.

Duas alternativas mais antigas ainda aparecem em bancos como o pgvector: IVF (Inverted File Index), que agrupa vetores em clusters e busca só dentro dos clusters mais promissores, e PQ (Product Quantization), que comprime vetores para economizar memória às custas de alguma precisão.

Como a similaridade é medida

Depois de decidir qual índice usar, o banco ainda precisa de uma métrica de distância para comparar vetores. As três mais comuns são:

• Similaridade de cosseno — mede o ângulo entre dois vetores, ignorando magnitude; é a métrica padrão para embeddings de texto.
• Distância euclidiana (L2) — mede a distância em linha reta entre dois pontos no espaço vetorial.
• Produto interno — usada quando os vetores já vêm normalizados e a intenção é maximizar a proximidade bruta.

O pgvector, extensão de banco vetorial para PostgreSQL, expõe essas três métricas diretamente como operadores SQL: <=> para cosseno, <-> para distância euclidiana e <#> para produto interno negativo, segundo o repositório oficial do pgvector no GitHub.

Exemplo prático com Python

O trecho abaixo usa o Chroma, um banco vetorial open-source pensado para prototipagem, para guardar três frases e buscar a mais parecida com uma pergunta. Não exige servidor externo — roda em memória, o que o torna um bom ponto de partida para entender o conceito antes de migrar para um banco gerenciado.

import chromadb

client = chromadb.Client()
colecao = client.create_collection(name="artigos_bytezine")

colecao.add(
    documents=[
        "RAG combina busca com geração de texto por um LLM.",
        "Embeddings transformam texto em vetores numéricos.",
        "Kubernetes orquestra contêineres em produção.",
    ],
    ids=["doc1", "doc2", "doc3"],
)

resultado = colecao.query(
    query_texts=["Como um LLM busca informação antes de responder?"],
    n_results=1,
)

print(resultado["documents"])
# [['RAG combina busca com geração de texto por um LLM.']]

O Chroma cuida da vetorização e da indexação por baixo dos panos: ao chamar query_texts, ele gera o embedding da pergunta e devolve o documento cujo vetor está mais próximo — nesse caso, o texto sobre RAG, mesmo sem nenhuma palavra em comum com a pergunta. Essa é a diferença central entre busca vetorial e busca por palavra-chave.

Banco vetorial dedicado ou extensão dentro do banco que você já tem

Existem hoje dois caminhos para adicionar busca vetorial a uma aplicação: um banco de dados vetorial dedicado (Pinecone, Weaviate, Qdrant, Milvus, Chroma) ou uma extensão de busca vetorial dentro de um banco relacional que você já usa — o pgvector no PostgreSQL é o exemplo mais adotado.

A diferença não é de capacidade, mas de trade-off operacional: bancos relacionais foram desenhados para integridade e consultas estruturadas com SQL, segundo comparações técnicas da IBM e da Instaclustr; bancos vetoriais dedicados foram desenhados para busca por proximidade em baixa latência sobre grandes volumes. Rodar tudo em cima de um banco relacional com extensão elimina a necessidade de sincronizar dois sistemas — mas escala pior que uma solução nativa quando o volume de vetores passa da casa dos milhões.

Quando você não precisa de um banco de dados vetorial dedicado

Nem todo projeto com IA precisa de infraestrutura vetorial dedicada. Se a base tem poucos milhares de itens, comparar o vetor de consulta com todos eles por força bruta — sem índice algum — já é rápido o suficiente e devolve resultado exato, sem o custo de recall da busca aproximada. Vale começar assim, medir se a latência incomoda, e só então migrar para um índice ANN ou um banco dedicado.

Principais opções em 2026

Um retrato não exaustivo das opções mais citadas hoje:

• Pinecone — serviço totalmente gerenciado, focado em simplicidade e zero manutenção de infraestrutura.
• Weaviate — open-source, com busca híbrida nativa (vetorial + busca por palavra-chave BM25).
• Qdrant — open-source, escrito em Rust, citado por benchmarks de baixa latência.
• Milvus — voltado para escala muito grande, na casa de bilhões de vetores.
• Chroma — open-source, leve, voltado para prototipagem e projetos pequenos a médios.
• pgvector — extensão para PostgreSQL, boa opção quando os dados já vivem em um banco relacional.

Cada uma dessas ferramentas evolui rápido, com preços e limites que mudam com frequência — por isso vale conferir a documentação oficial antes de decidir, em vez de se basear só em comparativos de terceiros.

Erros comuns e limitações

• Misturar vetores de modelos de embedding diferentes no mesmo índice: como cada modelo desenha seu próprio espaço vetorial, comparar vetores de origens distintas não produz resultado confiável.
• Ignorar filtros de metadata: buscar só por similaridade, sem filtrar por categoria, data ou permissão de acesso, costuma devolver resultados relevantes semanticamente mas errados no contexto do produto.
• Não monitorar recall: como índices ANN trocam precisão por velocidade, vale medir periodicamente se a busca ainda encontra os resultados certos, especialmente depois de mudar parâmetros do índice.
• Tratar o banco vetorial como solução para dados desorganizados: se o conteúdo de origem for ruim ou mal segmentado, a busca vetorial devolve vetores próximos de um conteúdo ruim — o problema está antes do banco, na qualidade dos dados e na forma como eles foram divididos.

Banco de dados vetorial não substitui um pipeline de RAG bem desenhado — é uma peça dele. Para entender o restante do pipeline, veja [o que é RAG](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona) e [como funcionam embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia). Para entender por que o tamanho do contexto recuperado impacta o custo de cada chamada ao modelo, veja [tokens e janela de contexto em LLMs](/artigo/tokens-janela-de-contexto-llm).