Um banco de dados vetorial armazena embeddings densos e esparsos de alta dimensão junto com metadados, oferecendo busca de similaridade por vizinhos mais próximos aproximados (ANN) em milissegundos como camada base de recuperação e memória para RAG, busca semântica e agentes de IA.
| Carga de trabalho / Restrição | Categoria recomendada | Soluções representativas | Por que escolher |
|---|---|---|---|
| Stack PostgreSQL existente, até ~10M de vetores | Extensão de BD relacional | pgvector (+ halfvec / HNSW) | Reaproveita transações ACID, JOINs SQL e operação atual sem nova infraestrutura |
| Busca híbrida texto completo BM25 + vetores | Extensão de motor de busca | Elasticsearch / OpenSearch / Vespa | Ecossistema maduro de índices invertidos e ranqueamento híbrido em múltiplas etapas |
| Serviço dedicado de alto QPS com filtros complexos | BD vetorial distribuído dedicado | Qdrant / Milvus / Weaviate | Motor de armazenamento especializado, filtragem rápida de payload e escala horizontal |
| Desenvolvimento local, apps edge/desktop ou leitura em data lake | BD embarcado / colunar | LanceDB / Chroma / FAISS | Execução em processo com integração zero-copy para Apache Arrow / Parquet |
| Volumes massivos frios/mornos com custo mínimo | SaaS nativo em object storage | Turbopuffer | Object Storage (S3/GCS) como fonte da verdade + cache local NVMe/RAM |
| Serverless sem operação integrado à nuvem pública | Serviço gerenciado em nuvem | Pinecone / Vertex AI Vector Search / Azure AI Search | Escala elástica serverless e integração nativa com IAM e monitoramento |
🔗 Folhas de consulta relacionadas: Conceitos de LLM e Agentes IA · Algoritmos modernos de IA · Comandos PostgreSQL · Comandos Redis · Comandos MongoDB
1. Conceitos centrais e métricas de distância
1.1 Terminologia essencial
| Termo | Definição | Pontos de engenharia |
|---|---|---|
| Embedding | Vetor de ponto flutuante de tamanho fixo codificando semântica de texto, imagem ou áudio | Dimensões comuns: 384 / 768 / 1024 / 1536 / 3072; RAM e cálculo crescem linearmente |
| ANN (Approximate Nearest Neighbor) | Busca indexada que troca mínimo recall (95%–99%) por aceleração de 100×–1000× | Trade-off central latência vs recall, em contraste com a varredura exata k-NN |
| Metadata Filtering | Restrição da busca vetorial por atributos escalares (tenant, data, ACL, categoria) | Distinguir Pre-filtering, Single-stage / Inline e Post-filtering |
| Hybrid Search | Combinação de vetores densos (semântica) e vetores esparsos / BM25 (correspondência léxica) | Resolve falhas da busca semântica pura em códigos SKU, erros e siglas |
| Sparse Vector | Vetor de alta dimensão com maioria de zeros (ex.: SPLADE, pesos BM25) | Armazena apenas índices e pesos não nulos; complementa a busca densa |
1.2 Três métricas fundamentais de distância
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Métrica | Significado | Equivalência matemática | Uso típico |
|---|---|---|---|
| Similaridade do cosseno (Cosine) | Mede apenas o ângulo ignorando a norma (−1 a 1; distância = 1 - cos) |
Ranqueamento idêntico ao produto interno para vetores normalizados em L₂ | Busca semântica de texto, RAG, embeddings de sentenças (padrão) |
| Produto interno (IP / Dot) | Considera ângulo e magnitude; menor custo computacional | Em vetores unitários substitui Cosine evitando raiz e divisão | Recomendação two-tower, embeddings normalizados (ex.: OpenAI) |
| Distância euclidiana (L₂) | Distância geométrica em linha reta; menor = mais próximo | Para vetores unitários: L₂² = 2 − 2 · cos(u, v) |
Embeddings de imagem/face, clustering espacial, sinais sensíveis à norma |
2. Algoritmos de índice ANN e quantização
2.1 Comparativo de índices vetoriais
| Tipo de índice | Mecanismo | Uso de RAM | Latência e Recall | Escala e motores típicos |
|---|---|---|---|---|
| Flat (Varredura exata) | Cálculo exaustivo contra todos os vetores | Moderado (apenas vetores brutos/quantizados) | 100% recall; latência dispara acima de ~100k linhas | Conjuntos pequenos (<100k) e benchmarks de referência |
| IVF-Flat (Arquivo invertido) | Agrupamento K-Means em nlist baldes; varre os nprobe mais próximos |
Baixo (sem sobrecarga de grafo) | Ajustável via nprobe; recall médio a alto |
1M–10M linhas sob orçamento restrito de RAM (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Partição em baldes mais compressão por subespaços e codebooks | Muito baixo (16×–64× menor) | Ultrarrápido; menor recall inicial (exige rescoring) | 100M+ em memória (FAISS / Milvus / LanceDB) |
| HNSW (Grafo hierárquico) | Grafo multicamadas tipo skip-list (topo grosso, base fina) | Alto (vetores + arestas em RAM ou mmap quente) | Milissegundos + 95%–99% recall; padrão da indústria | 1M–100M+ baixa latência em tempo real (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Grafo Vamana) | Grafo para SSD: vetores comprimidos na RAM, grafo completo em NVMe | Baixo (5×–10× menos RAM) | 100M+ por nó em ms; depende de IOPS NVMe rápidos | 100M–1B+ com memória limitada (Milvus / LanceDB / Azure) |
| ScaNN | Quantização vetorial anisotrópica + particionamento em árvore | Baixo–Moderado | Melhor curva recall/latência em produto interno | Recomendação e busca massiva (Vertex AI Vector Search / OSS) |
Parâmetros essenciais do HNSW:
M(máx. ligações bidirecionais por nó, típico16–64): maiorMeleva o recall em alta dimensão, mas consome mais RAM e tempo de construção.efConstruction(tamanho da lista de candidatos na criação, típico100–400): afeta só a indexação e melhora a qualidade do grafo.efSearch(largura da busca na consulta, ≥top_k): único parâmetro ajustável por consulta; aumentar eleva o recall e reduz o QPS.
2.2 Quantização e estimativa de memória
Referência para 10 milhões de vetores × 1536 dimensões (FP32 bruto):
Tamanho bruto ≈ N × D × 4 Bytes (estrutura de grafo HNSW adiciona ~1,2×–1,5× de RAM)
| Quantização | Bits / dim | Compressão | Tamanho 10M × 1536-dim | Trade-off e uso |
|---|---|---|---|---|
| FP32 (Sem compressão) | 32 bits (4 B) | 1× | ~57,2 GB | Precisão base; caro manter residente em RAM |
| FP16 / BF16 (Meia precisão) | 16 bits (2 B) | 2× | ~28,6 GB | Praticamente sem perda de recall (ex.: pgvector halfvec), ótimo ROI |
| SQ8 (Quantização escalar Int8) | 8 bits (1 B) | 4× | ~14,3 GB | Costuma preservar 97%+ de recall; padrão em produção |
| PQ (Product Quantization) | Subespaços | 16×–64× | ~1–4 GB | Exige treino de codebook; usar com oversampling + rescore |
| BQ (Quantização binária 1 bit) | 1 bit | 32× | ~1,79 GB | Varredura Hamming ultrarrápida; recomenda-se rescore 3×–5× (≥1024 dim) |
3. Comparação em camadas dos sistemas
3.1 Bancos de dados vetoriais nativos dedicados
| Produto | Licença / Implantação | Linguagem e Armazenamento | Índices e diferenciais | Indicação |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; em memória, mmap em disco e quantização em disco | HNSW + SQ8/BQ; vetores esparsos nativos e índice rápido de payload | Serviço standalone alto QPS, multi-tenant, filtros complexos |
| Milvus | Apache 2.0 / Distribuído & Zilliz Cloud | Control plane Go + execução C++; object storage + MQ desacoplados | IVF, HNSW, DiskANN, GPU CAGRA; partições multi-tenant | Plataformas corporativas na escala de bilhões |
| Weaviate | BSD-3-Clause (recursos enterprise fechados) | Go; object storage + índice invertido integrados | HNSW + quantização dinâmica/PQ/BQ; GraphQL/REST, módulos vetorizadores | Apps RAG com pipeline de embeddings integrado |
| Chroma | Apache 2.0 / Embarcado & Client-Server | Núcleo Python / Rust; SQLite + local ou distribuído | HNSW; API enxuta e forte integração LangChain / LlamaIndex | Prototipagem rápida e RAG Python pequeno/médio |
| LanceDB | Apache 2.0 / Embarcado & Enterprise | Rust; formato colunar Lance & Apache Arrow | IVF-PQ, HNSW, DiskANN; I/O zero-copy, multimodal nativo (áudio/vídeo/tabelas) | Apps locais embarcados, leitura serverless S3, data lakes |
| Pinecone | SaaS Serverless proprietário | Motor distribuído gerenciado (de Pods para Serverless) | Índice proprietário desacoplado; híbrido sparse-dense, isolamento por Namespace | Times cloud zero-ops focados em serviço gerenciado |
| Turbopuffer | SaaS proprietário / BYOC | Rust; object storage (S3/GCS) como fonte única + cache NVMe/RAM | Índice por centroides (estilo SPFresh) evitando saltos aleatórios em disco; texto + vetor | Grandes volumes frios/mornos (ex.: indexação de código) a baixo custo |
3.2 Bibliotecas de busca vetorial (não são BDs completos)
| Produto | Licença | Escopo e limites | Casos de uso |
|---|---|---|---|
| FAISS (Meta) | MIT | Biblioteca de similaridade C++ / Python (sem persistência de metadados, transações distribuídas ou servidor auth); CPU SIMD & multi-GPU | Processamento batch offline, pesquisa em ML, núcleo embarcado em motores próprios |
3.3 Extensões de BDs tradicionais e motores de busca
| Produto | Base | Capacidades vetoriais | Pontos fortes e limites |
|---|---|---|---|
| pgvector | Extensão PostgreSQL (incl. Supabase) | Tipos vector / halfvec / sparsevec / bit; HNSW e IVFFlat |
Prós: ACID, JOIN SQL, zero nova operação; Contras: amplificação de escrita e RAM >10M–50M linhas |
| Elasticsearch / OpenSearch | Índice invertido Lucene + HNSW | Híbrido nativo Dense Vector + BM25, fusão RRF, filtros aninhados | Prós: reaproveita times de busca; Contras: alto uso de RAM off-heap JVM e merges de segmentos |
| Redis (Query Engine) | KV em memória | Flat & HNSW, latência submilissegundo, streaming em tempo real | Prós: ideal para cache semântico e feature stores; Contras: alto custo de RAM em escala |
| MongoDB Atlas Search | BD documental (Atlas / Local CLI) | HNSW baseado em Lucene junto aos documentos BSON | Prós: elimina escrita dupla doc/vetor; Contras: recursos principais presos ao Atlas |
| SingleStore | BD SQL HTAP distribuído | SQL + operações vetoriais nativas (dot / L₂), colunas + linhas | Cargas corporativas combinando analytics em tempo real e transações |
| Vespa | Motor big-data Apache 2.0 | HNSW + híbrido exato/aproximado, ranqueamento ML multifase (Tensor/XGBoost/ONNX) | Plataformas massivas de busca e recomendação; curva operacional maior |
3.4 Serviços gerenciados em nuvem pública
| Serviço | Provedor | Arquitetura e destaques |
|---|---|---|
| Vertex AI Vector Search (ex-Matching Engine) | Google Cloud (GCP) | Baseado em ScaNN; atualizações streaming na casa dos bilhões e híbrido sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Clusters serverless gerenciados e extensões RDS/Aurora integradas ao Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Semantic Ranker nativo, pipelines de vetorização e controle de acesso RBAC corporativo |
4. Estratégias de filtragem e busca híbrida
4.1 Modos de execução da filtragem de metadados
| Estratégia | Ordem de execução | Falha típica e mitigação |
|---|---|---|
| Pre-filtering | Avalia o índice escalar para gerar bitmap de IDs e depois busca vetores | Com filtros muito seletivos (<1%), o grafo desconecta; Mitigação: fallback automático para scan exato |
| Post-filtering | Recupera Top-K global e descarta itens fora do filtro | Pode retornar menos de K resultados (ou zero); Mitigação: nunca usar isolado sem grande oversampling |
| Single-stage / Inline | Checa dinamicamente o bitmap de filtro a cada salto no grafo HNSW | Padrão atual (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan), equilibrando recall e latência |
4.2 Reciprocal Rank Fusion (RRF)
Como pontuações densas e BM25 têm escalas incompatíveis, a RRF combina os rankings diretamente sem calibração:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (constante padrão de suavização k = 60)
5. Trechos prontos para produção
5.1 Esquema pgvector, índice HNSW e varredura iterativa (SQL)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id INT NOT NULL,
content TEXT NOT NULL,
embedding halfvec(1536), -- float16 economiza 50% de RAM vs float32
fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);
CREATE INDEX idx_docs_emb_hnsw ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 128);
CREATE INDEX idx_docs_fts ON documents USING gin (fts);
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;
SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;
Operadores de distância pgvector:
<->Euclidiana (L₂) ·<=>Distância cosseno (1 - cos) ·<#>Produto interno negativo ·<+>Manhattan (L₁).
5.2 Qdrant: quantização binária e filtro por Payload (Python)
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="knowledge_base",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
on_disk=True,
),
quantization_config=models.BinaryQuantization(
binary=models.BinaryQuantizationConfig(always_ram=True)
),
)
client.create_payload_index(
collection_name="knowledge_base",
field_name="tenant_id",
field_schema=models.PayloadSchemaType.KEYWORD,
)
hits = client.query_points(
collection_name="knowledge_base",
query=[0.012, -0.045, ...],
query_filter=models.Filter(
must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
),
search_params=models.SearchParams(
quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
),
limit=10,
).points