Bancos de Dados Vetoriais

O que é um banco de dados vetorial?

Um banco de dados vetorial (vector database) é um repositório de dados otimizado para persistir, indexar e consultar incorporações vetoriais (vector embeddings) — representações numéricas densas de itens como texto, imagens, áudio, código ou comportamento do usuário. Seu principal trabalho é responder perguntas de busca por similaridade (similarity search) com eficiência:

  • “Quais documentos são semanticamente mais semelhantes a esta consulta?”
  • “Quais memórias passadas do agente são relevantes para a situação atual?”
  • “Quais produtos estão mais próximos das preferências deste usuário?”

Bancos de dados vetoriais são um componente fundamental para aplicações modernas de modelos de linguagem grandes (large language models, LLMs), especialmente:

  • Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG): recuperar contexto relevante para fundamentar a resposta de um modelo de linguagem grande (Geração Aumentada por Recuperação).
  • Memória do agente (agent memory): recuperar interações passadas relevantes, anotações, saídas de ferramentas ou observações para um agente (Agentes de Modelos de Linguagem Grandes).

Ao contrário de um banco de dados relacional tradicional, que se destaca em correspondências exatas e joins, um banco de dados vetorial é construído em torno da busca do vizinho mais próximo (nearest neighbor search) em espaço de alta dimensionalidade (high-dimensional space).

Por que as incorporações são centrais

Incorporações (Embeddings) (Incorporações) mapeiam um objeto (uma frase, um parágrafo, uma imagem) para um vetor como:

  • 384, 768, 1024… dimensões para modelos comuns de incorporação de texto
  • Cada dimensão é um número real (geralmente float32/float16), às vezes quantizado para int8

A ideia central: similaridade semântica vira proximidade geométrica. Se dois textos tratam do mesmo conceito, seus vetores de incorporação ficam “próximos” sob uma medida de distância como distância cosseno (cosine distance) ou distância euclidiana (Euclidean distance).

Isso dá suporte à busca semântica (semantic search) (recuperar por significado em vez de palavras-chave) e habilita a Geração Aumentada por Recuperação e a recuperação de memória.

O modelo de dados de um banco de dados vetorial

A maioria dos bancos de dados vetoriais armazena entradas que, conceitualmente, se parecem com:

  • id: chave única
  • vector: array de incorporações (por exemplo, comprimento 768)
  • metadata: campos estruturados usados para filtragem (por exemplo, source, tenant_id, doc_id, timestamp, tags)
  • payload opcional: o trecho de texto, ou um ponteiro para armazenamento externo (S3/GCS/Blob) que contém o conteúdo

Exemplo de registro:

{
  "id": "chunk_9f2a",
  "vector": [0.013, -0.22, 0.91, "..."],
  "metadata": {
    "tenant_id": "acme",
    "doc_id": "handbook_v3",
    "section": "benefits",
    "timestamp": 1704300000
  },
  "payload": "Employees are eligible for..."
}

O banco de dados normalmente é organizado em uma coleção/índice (collection/index) (os nomes variam: “index”, “collection”, “namespace”), muitas vezes com suporte a multilocação (multi-tenancy).

Busca por similaridade: distâncias e pontuação

A busca por similaridade vetorial ordena vetores armazenados pela distância até um vetor de consulta. Medidas comuns:

  • Similaridade cosseno (cosine similarity): compara direção; frequentemente usada para incorporações de texto
    • Muitos sistemas a implementam como produto escalar após normalização.
  • Produto escalar (dot product / inner product): comum quando as incorporações são treinadas para busca por produto interno máximo (maximum inner product search, MIPS).
  • Distância euclidiana (L2) (Euclidean distance): comum para alguns espaços de incorporação de visão e de uso geral.

Notas práticas:

  • Se você usa similaridade cosseno, frequentemente normaliza em L2 (L2-normalize) os vetores na ingestão (ingestion) e no momento da consulta.
  • Modelos de incorporação diferentes podem esperar uma métrica específica. Usar a métrica errada pode reduzir a revocação (recall) e a relevância.

Como bancos de dados vetoriais armazenam vetores

Armazenar vetores parece simples (um array de floats), mas, em escala, isso determina desempenho e custo.

Layout de dados e precisão

  • Float32: maior fidelidade; maior consumo de memória.
  • Float16 / bfloat16: metade da memória; pode ser bom para velocidade e custo com pequena perda de acurácia.
  • int8/int4 quantizados (quantized int8/int4) (via quantização de produto (product quantization) ou quantização escalar (scalar quantization)): muito menores, mais rápidos para varrer, mas podem reduzir a revocação.

Intuição aproximada:
N vectors × D dimensions × bytes_per_value pode ficar enorme rapidamente.

Exemplo: 10 milhões de vetores × 768 dims × 4 bytes (float32) ≈ 30.7 GB apenas para vetores brutos, antes da sobrecarga de indexação.

Onde fica o payload

Bancos de dados vetoriais variam quanto a:

  • armazenar payloads de texto internamente (conveniente, mas aumenta armazenamento e IO), ou
  • armazenar apenas metadados + um ponteiro para armazenamento de objetos externo (comum para grandes corpora)

Em Geração Aumentada por Recuperação, muitas equipes armazenam:

  • vetor + metadados no banco de dados vetorial
  • o texto bruto do trecho no banco de dados vetorial ou em um armazenamento externo
  • documentos e fontes versionadas em um sistema de registro (system of record) separado

Indexação: por que índices de vizinhos mais próximos aproximados importam

O “padrão-ouro” de busca do vizinho mais próximo é força bruta: calcular a distância da consulta para cada vetor e então pegar o top-k. Isso entrega revocação perfeita, mas escala mal.

Bancos de dados vetoriais dependem de índices de vizinhos mais próximos aproximados (Approximate Nearest Neighbor, ANN) (Busca Aproximada do Vizinho Mais Próximo) que trocam um pouco de acurácia por grandes ganhos de velocidade.

Famílias comuns de índices de vizinhos mais próximos aproximados

A maioria dos bancos de dados vetoriais modernos oferece um ou mais destes:

Baseados em grafos (por exemplo, HNSW)

HNSW (Hierarchical Navigable Small World) constrói um grafo em camadas em que nós (vetores) se conectam a vetores próximos.

  • Prós: excelente revocação/latência em muitos cenários, ótimo para inserções incrementais
  • Contras: pode consumir muita memória; exclusões/atualizações exigem manutenção cuidadosa; tempo de construção e RAM crescem com o tamanho do conjunto de dados

Parâmetros típicos de ajuste:

  • M: máximo de conexões por nó (maior = melhor revocação, mais memória)
  • efConstruction: acurácia no build vs tempo
  • efSearch: acurácia em consulta vs latência

Arquivo invertido (Inverted File, IVF) e baseados em clusterização

Vetores são agrupados (por exemplo, k-means), e consultas buscam apenas um subconjunto de clusters.

  • Prós: bom para conjuntos de dados grandes; pode ser eficiente em disco
  • Contras: atualizações incrementais podem ser mais complexas; precisa de treinamento; a revocação depende da qualidade dos clusters

Parâmetro de ajuste:

  • nprobe: número de clusters a pesquisar (maior = melhor revocação, mais lento)

Quantização (por exemplo, PQ, SQ)

Quantização de Produto (Product Quantization, PQ) comprime vetores em códigos compactos.

  • Prós: redução dramática de memória; permite computação rápida aproximada de distâncias
  • Contras: pode reduzir revocação; frequentemente requer calibração cuidadosa e às vezes reordenação

Muitos sistemas usam uma recuperação em dois estágios (two-stage retrieval):

  1. busca aproximada sobre códigos comprimidos para obter candidatos
  2. reordenar candidatos usando vetores em precisão total

Abordagens híbridas

Na prática, sistemas combinam:

  • quantização grossa + índice invertido + reordenação, ou
  • grafo + compressão, ou
  • recuperação “disk-first” + cache em memória

A realidade do “revocação vs latência”

A busca aproximada não é “errada”; ela é probabilística. Normalmente você escolhe pontos de operação como:

  • latência P95 abaixo de 50 ms, revocação@10 acima de 0.9
  • ou QPS máximo por nó com revocação@20 ≥ 0.95

Bancos de dados vetoriais existem em grande parte para tornar esses trade-offs gerenciáveis em produção.

Consultas: top-k, filtragem e busca híbrida

Uma consulta vetorial típica pede:

  • dado um vetor de consulta q
  • retornar os top-k vetores mais próximos
  • opcionalmente restritos por filtros de metadados

Filtragem por metadados

Filtragem por metadados é essencial para aplicações reais:

  • Isolamento multi-tenant: tenant_id = "acme"
  • Controle de acesso: apenas documentos que o usuário pode ver
  • Atualidade: timestamp >= now - 30 days
  • Escopo por documento: restringir a um projeto, pasta ou conversa
  • Restrições por tipo: apenas “policies”, não “chat logs”

Filtros podem ser aplicados de diferentes formas:

  • Pré-filtragem (pre-filtering): filtrar candidatos primeiro e então fazer a busca aproximada dentro desse subconjunto
    • Mais rápido quando o filtro reduz bastante, mas mais difícil de implementar com eficiência com índices aproximados.
  • Pós-filtragem (post-filtering): fazer a busca aproximada primeiro e então filtrar resultados
    • Mais simples, mas pode retornar poucos resultados se o filtro for restritivo.
  • Filtragem integrada (integrated filtering): estruturas de índice incorporam poda sensível a metadados (o melhor dos dois mundos, mas complexo).

Busca híbrida (vetores + palavras-chave)

Similaridade semântica pura pode deixar passar restrições exatas como números de modelo, códigos de erro ou nomes. Muitos sistemas suportam recuperação híbrida (hybrid retrieval):

  • pontuação por palavras-chave (por exemplo, BM25) + similaridade vetorial
  • combinação ponderada ou ranqueadores aprendidos

Isso é comum em busca corporativa e em Geração Aumentada por Recuperação para melhorar a precisão.

Pipelines de ingestão: colocando dados no banco de dados vetorial

Bancos de dados vetoriais frequentemente fornecem uma API simples upsert(id, vector, metadata), mas a ingestão em produção tem mais partes móveis:

Fluxo típico de ingestão para Geração Aumentada por Recuperação

  1. Coletar documentos (PDFs, HTML, tickets, páginas de wiki)
  2. Fazer parsing e dividir em trechos (chunk) o texto em passagens (por exemplo, 200–500 tokens com sobreposição)
  3. Gerar incorporações (embed) de cada trecho usando um modelo de incorporação (embedding model)
  4. Inserir/atualizar (upsert) no banco de dados vetorial com metadados
  5. (Opcional) Armazenar conteúdo bruto no payload ou em armazenamento externo

Preocupações práticas:

  • Processamento em lote (batching): modelos de incorporação e inserções no banco vetorial são mais rápidos em lotes.
  • Idempotência (idempotency): compute IDs estáveis (por exemplo, doc_id + chunk_index + embedding_model_version).
  • Reprocessamentos retroativos (backfills): quando você muda a estratégia de chunking ou o modelo de incorporação, pode precisar re-embutir e reindexar.

Versionamento das incorporações

Incorporações dependem de:

  • o nome/versão do modelo de incorporação
  • pré-processamento (lowercasing, normalização)
  • estratégia de chunking
  • configurações multilíngues etc.

Um padrão comum é armazenar:

  • embedding_model = "text-embedding-3-large"
  • embedding_version = "v2_chunk512_overlap64"

para que você consiga rodar migrações e testes A/B com segurança.

Atualizações e exclusões: o que “vetores mutáveis” realmente significa

Muitas aplicações precisam atualizar ou excluir entradas:

  • um documento é editado ou revogado
  • permissões de acesso mudam
  • memórias do agente expiram
  • deduplicação mescla trechos

Bancos de dados vetoriais implementam isso de maneiras diferentes:

  • Inserção/atualização (upsert): sobrescrever vetor + metadados para um ID existente
  • Exclusão lógica (soft delete): marcar como excluído (marcador de exclusão (tombstone)), depois limpar durante a compactação
  • Exclusão física (hard delete): remover do índice (frequentemente caro dependendo do tipo de índice aproximado)

Implicações de design:

  • Alguns índices aproximados lidam bem com inserções incrementais (incremental inserts) (por exemplo, HNSW), mas exclusões podem ser custosas.
  • Sistemas em grande escala frequentemente usam reconstrução/compactação em segundo plano (background rebuild/compaction) para manter índices saudáveis.
  • A consistência frequentemente é eventual (eventual): gravações recentes podem não ser pesquisáveis imediatamente com acurácia total até a indexação alcançar.

Capacidades essenciais que você deve esperar

Um banco de dados vetorial pronto para produção normalmente oferece:

  • Índices de vizinhos mais próximos aproximados com revocação/latência ajustáveis
  • Filtragem por metadados (incluindo faixas numéricas, lógica booleana)
  • Espaços de nomes/coleções e padrões de multilocação
  • Inserção/atualização e exclusão, idealmente com semântica previsível
  • APIs de ingestão em lote
  • Persistência e recuperação (durabilidade entre reinicializações)
  • Replicação e fragmentação (sharding) para escala e alta disponibilidade
  • Observabilidade (observability): percentis de latência, proxies de revocação, saúde do índice, uso de memória
  • Segurança: autenticação/autorização (authn/authz), criptografia em repouso/em trânsito, logs de auditoria (varia por produto)

Trade-offs de design: latência, revocação e custo

Bancos de dados vetoriais são, essencialmente, máquinas de trade-off. Eixos principais:

Latência vs revocação

  • Aumentar o esforço de busca aproximada (efSearch, nprobe, reordenar candidatos) → maior revocação, maior latência
  • Reduzir → mais rápido, mas pode perder vizinhos relevantes

Memória vs custo

  • Manter vetores em precisão total e grafos HNSW na RAM → rápido e acurado, caro
  • Usar quantização e índices baseados em disco → mais barato, às vezes mais lento e/ou menos acurado

Taxa de ingestão/atualização vs desempenho de consulta

  • Cargas pesadas de escrita podem degradar o desempenho de consulta se a indexação for síncrona.
  • Alguns sistemas oferecem indexação assíncrona (asynchronous indexing): escritas rápidas, busca um pouco desatualizada.

Complexidade de filtragem vs desempenho

  • Filtros ricos de metadados podem ser caros sem indexação cuidadosa.
  • Pré-filtragem em escala é difícil; pós-filtragem pode reduzir a revocação efetiva.

Simplicidade em nó único vs escala distribuída

  • Busca vetorial distribuída introduz:
    • estratégia de fragmentação (hash por ID vs particionar por tenant)
    • mesclar top-k entre shards
    • replicação e modelos de consistência
    • sobrecarga de latência de rede

Uma forma prática de avaliar sistemas é definir objetivos de nível de serviço (Service Level Objectives, SLOs) como:

  • latência de consulta P95 ≤ 100 ms
  • revocação@10 ≥ 0.95 em um conjunto de benchmark
  • custo por milhão de vetores dentro de um orçamento
  • propagação de atualização em até X segundos

Bancos de dados vetoriais em Geração Aumentada por Recuperação

Em Geração Aumentada por Recuperação, o banco de dados vetorial normalmente é o “recuperador” que encontra contexto candidato para um modelo de linguagem grande:

  1. Pergunta do usuário → gerar incorporação da consulta
  2. Recuperar top-k trechos por similaridade (e filtros)
  3. Opcionalmente reordenar com um codificador cruzado (cross-encoder) ou um reordenador baseado em modelo de linguagem grande
  4. Fornecer o texto recuperado ao modelo gerador (Arquitetura Transformer)

Exemplo de pseudo-código (estilo Python):

query = "What is our parental leave policy?"
q_vec = embed(query)

results = vectordb.search(
    vector=q_vec,
    top_k=8,
    filter={
        "tenant_id": "acme",
        "doc_type": "handbook",
        "access_level": {"$lte": user.access_level}
    }
)

context = "\n\n".join(r.payload for r in results)
answer = llm.generate(prompt=f"Answer using context:\n{context}\n\nQ: {query}")

Armadilhas comuns de Geração Aumentada por Recuperação que não são resolvidas apenas pelo banco de dados vetorial:

  • Chunking ruim (grande demais/pequeno demais, sem sobreposição)
  • Modelo de incorporação fraco para o domínio
  • Filtros de metadados ausentes (vazamentos ou resultados irrelevantes)
  • Sem reordenação quando alta precisão é necessária

Bancos de dados vetoriais para memória do agente

Agentes frequentemente precisam de múltiplos tipos de memória:

  • Memória de curto prazo: turnos recentes da conversa (frequentemente armazenados em um banco normal)
  • Memória semântica de longo prazo: eventos/anotações passados recuperados por busca por similaridade (banco vetorial)
  • Memória episódica: experiências com timestamp, frequentemente filtradas por tempo + similaridade

Padrão típico:

  • Armazenar “itens de memória” como incorporações com metadados:
    • timestamp, session_id, tool_name, entity_ids, importance
  • A cada passo, recuperar:
    • top-k memórias similares
    • possivelmente com viés para memórias recentes ou de alta importância via filtragem ou ajustes de pontuação

Isso habilita comportamentos como “lembrar” preferências do usuário ou resultados passados de ferramentas sem enfiar tudo no prompt.

Como bancos de dados vetoriais diferem de “busca vetorial em bancos de dados de propósito geral”

Muitos bancos de dados de propósito geral agora suportam busca vetorial (por exemplo, extensões de bancos relacionais, document stores, search engines). A diferença não é que eles não conseguem fazer busca por similaridade — é o que eles otimizam e até onde vão.

Bancos de dados vetoriais (sistemas especializados) normalmente otimizam para

  • busca aproximada de alto desempenho em escala (milhões a bilhões de vetores)
  • recursos operacionais nativos para vetores (ajuste de índice, fragmentação, replicação para cargas de trabalho de busca aproximada)
  • filtragem flexível por metadados desenhada em torno de casos de uso de recuperação
  • ingestão de alto throughput de incorporações
  • APIs e ferramentas de recuperação sob medida para padrões de Geração Aumentada por Recuperação/memória de agentes

Bancos de dados de propósito geral com suporte a vetores normalmente otimizam para

  • cargas de trabalho mais amplas: transações, joins, agregações, busca textual, OLTP/OLAP
  • consistência forte e ecossistemas operacionais maduros
  • simplicidade quando seus vetores “moram ao lado” de dados estruturados de negócio

Diretriz prática de decisão

Use um banco de dados de propósito geral com suporte a vetores quando:

  • seu conjunto de dados é pequeno a moderado
  • você precisa de garantias transacionais fortes
  • vetores precisam ser fortemente ligados via joins com dados relacionais
  • você quer menos componentes

Use um banco de dados vetorial quando:

  • você precisa de alta revocação com baixa latência em corpora grandes
  • você espera tráfego pesado de busca por similaridade (Geração Aumentada por Recuperação em escala)
  • você precisa de ajuste avançado de índices aproximados, recuperação híbrida ou filtragem especializada com alto desempenho
  • você tem múltiplos tenants/projetos e precisa de isolamento limpo de recuperação

Na prática, equipes frequentemente usam ambos:

  • banco relacional como sistema de registro
  • banco vetorial para aceleração de recuperação
  • armazenamento de objetos para documentos brutos grandes

Dicas práticas e padrões comuns

Use IDs estáveis e deduplique

Se você reindexa os mesmos documentos com frequência, IDs estáveis evitam duplicatas:

  • id = hash(doc_uri + chunk_index + embedding_version)

Armazene metadados suficientes para uma recuperação segura

No mínimo:

  • tenant_id (ou namespace de projeto)
  • doc_id e chunk_id
  • source / doc_type
  • timestamp (para atualidade)
  • campos de controle de acesso, se necessário

Considere reordenação para precisão

A recuperação aproximada é um gerador rápido de candidatos. Para respostas de alto risco:

  • recupere top 20–100
  • reordene os principais candidatos com um modelo mais forte
  • então envie apenas top 5–10 para o modelo de linguagem grande

Monitore a qualidade da recuperação, não apenas a latência

Métricas operacionais (QPS, latência P95) são necessárias, mas insuficientes. Acompanhe qualidade de recuperação via:

  • consultas rotuladas e revocação@k / ranque recíproco médio (mean reciprocal rank, MRR)
  • proxies de “fundamentação da resposta (answer groundedness)”
  • verificações de deriva (drift checks) quando incorporações/modelos mudam (Métricas de Avaliação)

Resumo

Bancos de dados vetoriais são sistemas especializados para armazenar incorporações e realizar busca por similaridade eficiente, normalmente usando índices de vizinhos mais próximos aproximados para equilibrar latência, revocação e custo. Eles são fundamentais em Geração Aumentada por Recuperação e em memória do agente, onde você precisa recuperar o contexto certo com rapidez e segurança, muitas vezes sob restrições de metadados.

Sua característica distintiva não é apenas “eles armazenam vetores”, mas sim que oferecem um conjunto orientado a vetores de capacidades de indexação, filtragem, ingestão e escalabilidade ajustadas para cargas de trabalho reais de recuperação — capacidades que bancos de dados de propósito geral às vezes conseguem aproximar, mas frequentemente não com o mesmo envelope de desempenho ou ergonomia operacional para recuperação semântica em grande escala.