Busca Vetorial (Vector Search) e Embeddings

O que “Busca Vetorial e Representações Vetoriais” Significa

Representações vetoriais (embeddings) são vetores numéricos (por exemplo, 384–3072 valores de ponto flutuante) que representam o significado de um objeto — texto, uma imagem, código, um clipe de áudio — de modo que a similaridade semântica (semantic similarity) se torne uma relação geométrica. A busca vetorial (vector search) recupera os itens mais semelhantes a uma representação vetorial de consulta, encontrando seus vizinhos mais próximos (nearest neighbors) nesse espaço de representações vetoriais (embedding space).

Esse é um bloco fundamental dos sistemas modernos de recuperação (retrieval systems), especialmente na Geração Aumentada por Recuperação (RAG): você gera representações vetoriais dos seus documentos (ou trechos (chunks)), gera a representação vetorial da consulta do usuário, recupera os trechos mais próximos e os fornece a um modelo para gerar respostas fundamentadas.

O desafio central: a busca exata de vizinhos mais próximos é cara em escala, então a maioria dos sistemas usa índices de Vizinhos Mais Próximos Aproximados (Approximate Nearest Neighbor, ANN), que trocam uma pequena quantidade de revocação por grandes ganhos em latência e memória.

Espaços de Representações Vetoriais: A Visão Geométrica

De tokens a vetores

A maioria das representações vetoriais modernas vem de codificadores baseados em Transformer (transformer-based encoders) (veja Arquitetura Transformer). Um codificador mapeia uma entrada (por exemplo, um parágrafo) em um vetor de comprimento fixo, de modo que:

  • entradas semanticamente semelhantes → vetores próximos entre si
  • entradas semanticamente diferentes → vetores distantes entre si

Isso é aprendido a partir de grandes conjuntos de dados usando objetivos como aprendizado contrastivo (contrastive learning) (por exemplo, associar consultas a passagens relevantes e afastar as irrelevantes).

Por que representações vetoriais funcionam para recuperação

A busca por palavras-chave (keyword search) tradicional corresponde a formas de superfície (“carro” vs “automóvel” não casam). Representações vetoriais podem corresponder ao significado mesmo quando as palavras exatas diferem, motivo pelo qual a recuperação densa (dense retrieval) é poderosa para:

  • paráfrases
  • sinônimos
  • correspondência semântica (“política de reembolso” ↔ “prazo de devolução”)
  • recuperação cruzada entre línguas (cross-lingual retrieval) (com modelos multilíngues (multilingual models))
  • similaridade multimodal (multimodal similarity) (texto ↔ imagem), frequentemente usada em RAG Multimodal

Medidas de similaridade (e por que elas importam)

A busca vetorial precisa de uma função de distância/similaridade. Escolhas comuns:

  • Similaridade cosseno (cosine similarity):
    [ \cos(\theta) = \frac{x \cdot y}{|x||y|} ]
    Mede ângulo, não magnitude. Frequentemente usada quando as representações vetoriais são normalizadas.

  • Produto escalar (dot product; inner product):
    [ x \cdot y ]
    Sensível à magnitude; muitos modelos de representações vetoriais são treinados esperando pontuação por produto escalar.

  • Distância euclidiana (L2) (Euclidean (L2) distance):
    [ |x - y|_2 ]
    Comum em alguns índices; equivalente ao cosseno se os vetores estiverem normalizados (relação monótona).

Regra prática: siga a recomendação do modelo de representações vetoriais. Se o modelo espera similaridade cosseno, normalize as representações vetoriais no momento da ingestão e no momento da consulta.

Recuperação Densa na Prática: Um Pipeline Mínimo

Um pipeline (pipeline) típico de recuperação densa tem três etapas:

  1. Ingestão (ingest): dividir documentos em trechos (veja Ingestão e Segmentação em Trechos), gerar a representação vetorial de cada trecho, armazenar vetores + metadados (metadata).
  2. Consulta (query): gerar a representação vetorial da consulta do usuário.
  3. Busca (search): recuperar os top-k vetores mais próximos, opcionalmente filtrar por metadados, opcionalmente reordenar (reranking) (veja Reordenação).

Exemplo: Gerando representações vetoriais e buscando com FAISS (conceitual)

import numpy as np
import faiss

# Suppose you already have embeddings:
# doc_vecs: (N, d) float32 matrix for N chunks
# query_vec: (d,) float32 vector for the query
doc_vecs = np.load("doc_vecs.npy").astype("float32")   # shape (N, d)
query_vec = np.load("query_vec.npy").astype("float32") # shape (d,)

d = doc_vecs.shape[1]

# For cosine similarity, normalize vectors and use inner product
faiss.normalize_L2(doc_vecs)
faiss.normalize_L2(query_vec.reshape(1, -1))

index = faiss.IndexFlatIP(d)  # exact inner-product search (no ANN)
index.add(doc_vecs)

k = 5
scores, ids = index.search(query_vec.reshape(1, -1), k)
print(ids[0], scores[0])

Isso usa busca exata (exact search) (IndexFlatIP), que é simples, mas se torna lenta/demanda muita memória para N grande. É aí que entram os índices de Vizinhos Mais Próximos Aproximados.

k-Vizinhos Mais Próximos Exatos vs Vizinhos Mais Próximos Aproximados

Por que a busca exata não escala

Dado N vetores de dimensão d, a busca exata compara a consulta com cada vetor: O(N·d) por consulta. Para milhões de vetores, isso é lento demais.

Métodos de Vizinhos Mais Próximos Aproximados (ANN) constroem um índice (index) para que a busca visite apenas uma pequena fração dos vetores — muitas vezes oferecendo melhorias de latência de 10–100× com perda mínima na qualidade de recuperação.

Principais tradeoffs

Sistemas de Vizinhos Mais Próximos Aproximados (ANN) normalmente expõem parâmetros que controlam:

  • Revocação (recall): com que frequência os verdadeiros vizinhos mais próximos aparecem nos resultados
  • Latência (latency): tempo de resposta por consulta
  • Memória (memory): tamanho do índice (RAM costuma ser o gargalo)
  • Tempo de construção (build time): quanto tempo leva para indexar
  • Facilidade de atualização (update friendliness): quão bem o índice suporta inserções/exclusões incrementais

Famílias Comuns de Índices de Vizinhos Mais Próximos Aproximados (e Quando Usá-las)

A maioria dos sistemas em produção (FAISS, HNSWlib, ScaNN, bancos de dados vetoriais (vector databases)) usa variações dessas abordagens.

Baseados em grafo: HNSW (Mundo Pequeno Navegável Hierárquico)

HNSW (Hierarchical Navigable Small World) é um dos algoritmos de Vizinhos Mais Próximos Aproximados mais populares devido à forte relação revocação/latência e ao bom comportamento prático.

  • Ideia: construir um grafo de proximidade (proximity graph) em múltiplas camadas; buscar de forma gulosa a partir de uma camada alta e descer para refinar.
  • Prós: excelente revocação com baixa latência; amplamente suportado; relativamente fácil de ajustar.
  • Contras: consome muita memória; exclusões/atualizações podem ser difíceis dependendo da implementação.

Parâmetros importantes de ajuste (o nome varia por biblioteca):

  • M: número de vizinhos por nó (maior = melhor revocação, mais memória)
  • ef_construction: qualidade do grafo durante a construção
  • ef_search: amplitude da busca (maior = melhor revocação, mais lento)

Regra geral: se você pode pagar o custo de memória, HNSW costuma ser um ótimo padrão.

Arquivo invertido (IVF): agrupamento + busca local

Métodos de arquivo invertido (inverted file, IVF) agrupam (clustering) vetores (por exemplo, k-means), e então buscam apenas nos agrupamentos mais próximos.

  • Prós: pode ser eficiente em memória; suporta grande escala; frequentemente usado com compressão (PQ).
  • Contras: requer treinamento; a revocação depende da qualidade do agrupamento; o ajuste pode ser mais trabalhoso.

Parâmetros-chave:

  • nlist: número de agrupamentos (mais agrupamentos podem melhorar a precisão, mas aumentam a complexidade)
  • nprobe: quantos agrupamentos buscar (maior = melhor revocação, mais lento)

Quantização de Produto (PQ): comprimir vetores

Quantização de Produto (Product Quantization, PQ) comprime vetores em códigos curtos, reduzindo drasticamente a memória.

  • Prós: enorme economia de memória; pode manter bilhões de vetores em RAM/SSD.
  • Contras: a compressão reduz a acurácia; exige ajuste cuidadoso; frequentemente combinada com IVF (IVF-PQ).

Quando usar: quando o custo de memória domina e alguma perda de revocação é aceitável, muitas vezes mitigada por reordenação.

LSH e abordagens de hashing

Hashing sensível à localidade (locality-sensitive hashing) é conceitualmente simples e pode ser rápido, mas na prática frequentemente é superado por HNSW/IVF para distribuições modernas de representações vetoriais.

Qualidade de Recuperação: O que Medir e Como

Métricas offline

Métricas comuns de recuperação:

  • Revocação@k (Recall@k): fração de consultas em que um documento relevante conhecido aparece no top-k.
  • MRR (Média do Rank Recíproco) (Mean Reciprocal Rank): enfatiza colocar um item relevante perto do topo.
  • nDCG@k (ganho acumulado descontado normalizado) (normalized Discounted Cumulative Gain): suporta relevância graduada (itens mais relevantes importam mais).
  • Precisão@k (Precision@k): quantos dos top-k são relevantes (frequentemente mais difícil em cenários de domínio aberto).

Para avaliação específica de RAG, em geral você se importa com:

  • Revocação de contexto (context recall): recuperamos as passagens necessárias para responder?
  • Fidelidade/fundamentação (faithfulness/grounding) da resposta: a resposta do modelo corresponde às fontes recuperadas (veja Fundamentação e Citações)?

Métricas online

Em produção, meça:

  • taxa de cliques (click-through) / engajamento
  • “esta resposta resolveu seu problema?”
  • taxa de fallback/abandono
  • percentis de latência (p50/p95/p99)

A distinção entre “top-k” e “k usado”

Muitos sistemas de RAG recuperam top-20 ou top-50, mas só passam top-5 para o LLM (Large Language Model) devido a limites de contexto. Isso introduz duas alavancas:

  • aumentar os candidatos recuperados (k_retrieve) para melhorar revocação
  • reordenar e selecionar um subconjunto menor (k_context) para o modelo

É aqui que a Reordenação se torna um grande multiplicador de qualidade.

Tradeoffs Práticos de Qualidade de Recuperação

1) Escolha do modelo de representações vetoriais vs ajuste do índice

Um modelo de representações vetoriais melhor costuma trazer ganhos maiores do que ajustes no índice. O ajuste do índice ajuda principalmente você a recuperar o potencial do modelo, evitando perda de revocação do ANN.

  • Se seu modelo de representações vetoriais não separa conteúdo relevante do irrelevante, nenhuma configuração de ANN resolve isso.
  • Se o modelo é bom, mas seu ANN é agressivo demais, você vai perder vizinhos e culpar o modelo incorretamente.

2) Latência vs revocação: controlando o “esforço de busca”

A maioria dos métodos de Vizinhos Mais Próximos Aproximados permite aumentar o esforço de busca:

  • HNSW: aumentar ef_search
  • IVF: aumentar nprobe

Isso normalmente produz uma curva suave:

  • pequenos aumentos de esforço → grandes ganhos iniciais de revocação
  • retornos decrescentes após certo ponto

Uma abordagem comum em produção é ajustar para um SLO (Service Level Objective) de latência (por exemplo, p95 < 150 ms) e maximizar a revocação sob essa restrição.

3) Memória vs acurácia: float32 vs quantização

Armazenar vetores brutos em float32 é caro:

  • 1M vetores × 1536 dimensões × 4 bytes ≈ 6,1 GB apenas para vetores (sem contar a sobrecarga do índice)

Opções:

  • armazenamento em float16 (às vezes aceitável)
  • quantização (quantization) PQ/int8 (maior ganho de memória, mais perda de acurácia)
  • manter vetores comprimidos para busca, mas buscar vetores completos para reordenação (se armazenados separadamente)

4) Dimensionalidade e “maldição da dimensionalidade”

Alta dimensionalidade pode tornar métricas de distância menos discriminativas, mas modelos modernos de representações vetoriais são treinados para produzir uma geometria utilizável nas dimensões escolhidas. Na prática, os maiores problemas são:

  • anisotropia (anisotropy) (vetores se aglomerando em um cone estreito)
  • efeito de hubs (hubness) (alguns vetores se tornando “os mais próximos” para muitas consultas)
  • desalinhamento de domínio (domain mismatch) (modelo de representações vetoriais não treinado para seu conteúdo)

Mitigações incluem normalização, uso de modelos melhores de representações vetoriais ou ajuste fino (fine-tuning) no domínio.

Indexação, Metadados e Filtragem

A busca vetorial raramente opera apenas sobre vetores. Em geral você também precisa de:

  • isolamento por locatário/espaço de trabalho (tenant/workspace isolation)
  • listas de controle de acesso (Access Control Lists, ACLs)
  • intervalos de tempo (“últimos 30 dias”)
  • tipos de documento (“apenas PDFs”)
  • filtros de idioma

Duas abordagens comuns:

  1. Pré-filtragem (pre-filtering) (filtrar primeiro, depois busca vetorial)
    Melhor quando os filtros são seletivos e suportados com eficiência.

  2. Pós-filtragem (post-filtering) (busca vetorial primeiro, depois filtrar)
    Arriscado: você pode recuperar top-k que serão filtrados, deixando poucos resultados. Em geral exige recuperar um conjunto maior de candidatos.

Alguns bancos de dados vetoriais suportam ANN com filtragem (filtered ANN) (um híbrido das duas), mas as características de desempenho variam muito.

Busca Vetorial em Sistemas de RAG

A busca vetorial normalmente é uma etapa em um pipeline de recuperação (retrieval pipeline) em múltiplas etapas:

  1. Segmentação em trechos + metadados (Ingestão e Segmentação em Trechos)
  2. Recuperação densa (busca vetorial)
  3. Recuperação esparsa (sparse retrieval) opcional + fusão (fusion) (Busca Híbrida (Esparsa + Densa))
  4. Reordenação (Reordenação)
  5. Empacotamento de contexto (context packing) + citações (Fundamentação e Citações)
  6. Geração (Geração Aumentada por Recuperação (RAG))

Por que a busca híbrida é tão comum

Representações vetoriais densas são ótimas em semântica, mas podem falhar em:

  • identificadores exatos (códigos de erro, números de peça)
  • nomes raros
  • restrições de fraseamento precisas

Métodos esparsos (sparse methods) (tipo BM25 (BM25-like)) se destacam nesses casos. A recuperação híbrida costuma oferecer a melhor robustez.

Por que a reordenação importa

A recuperação por ANN é otimizada para velocidade, não para ordenação perfeita. Um modelo de reordenação (reranker) (frequentemente um codificador cruzado (cross-encoder)) pode:

  • considerar consulta e passagem conjuntamente
  • usar atenção mais rica ao longo dos dois textos
  • produzir uma precisão drasticamente melhor no top-5/top-10

Padrão típico:

  • recuperar 50–200 candidatos de forma barata
  • reordenar para top 5–20
  • enviar para o LLM

Aproximação Não É a Única Fonte de Erros

Quando a recuperação “falha”, às vezes o ANN é culpado incorretamente. Causas reais comuns:

Segmentação em trechos ruim ou limites de contexto ausentes

Se os trechos dividem definições de referências, você pode recuperar um trecho que menciona um termo, mas não contém a resposta.

Veja Ingestão e Segmentação em Trechos para estratégias como sobreposição, segmentação semântica e parsing sensível à estrutura.

Granularidade errada das representações vetoriais

  • representações vetoriais no nível de sentença podem perder contexto no nível de documento
  • representações vetoriais no nível de documento podem ser grosseiras demais para recuperar o trecho correto

Um compromisso comum é usar representações vetoriais por trecho, com metadados que conectam de volta ao documento completo.

Desalinhamento de domínio

Representações vetoriais de uso geral podem não representar bem domínios especializados (jurídico, biomédico, jargão interno). Opções:

  • escolher um modelo de representações vetoriais ajustado ao domínio
  • fazer ajuste fino em pares consulta–documento (se você os tiver)
  • usar recuperação híbrida como rede de segurança para falhas da recuperação densa

Deriva de distribuição e versionamento

Se você atualizar o modelo de representações vetoriais, normalmente precisa refazer as representações vetoriais e reindexar (re-embed and reindex) todos os documentos, ou armazenar múltiplos campos de representações vetoriais e lidar com a migração.

Mudanças nas representações vetoriais também podem quebrar estratégias de cache; veja Cache.

Considerações Operacionais

Upserts, exclusões e rebuilds

  • Estruturas tipo HNSW frequentemente preferem cargas de trabalho dominadas por anexação (append-heavy workloads); exclusões podem deixar marcadores de exclusão (tombstones).
  • Índices IVF podem exigir retreinamento ou rebuild periódico para melhor qualidade.

Planeje:

  • jobs de reindexação em segundo plano
  • snapshot/restauração (snapshot/restore)
  • escrita dupla (dual-write) durante migrações

Sharding e replicação

Em grande escala, você fará particionamento (sharding) de vetores entre nós. Isso adiciona complexidade:

  • latência de dispersão e agregação (scatter-gather)
  • distribuições desiguais entre shards
  • a aproximação de ANN por shard se compõe em perda de revocação total

Observabilidade

Acompanhe:

  • latência de consulta e tempos limite (timeouts)
  • número de candidatos examinados (“esforço” do ANN)
  • proxies de revocação (por exemplo, pontuações do reordenador, taxas de “nenhuma boa correspondência”)
  • tamanho do índice e pressão de memória

Fluxo Prático de Ajuste (Uma Abordagem Repetível)

  1. Estabeleça um conjunto de avaliação rotulado (labeled eval set)
    Mesmo 200–1000 consultas com passagens relevantes julgadas podem orientar o ajuste.

  2. Escolha um modelo de representações vetoriais e uma métrica de similaridade
    Normalize se estiver usando cosseno.

  3. Comece com um índice de baseline forte

    • HNSW para muitos casos de uso
    • IVF-PQ se a memória for o fator limitante

  4. Ajuste o esforço do ANN para revocação sob um SLO de latência

    • aumente ef_search / nprobe até retornos decrescentes

  5. Adicione reordenação

    • avalie a qualidade final do top-5/top-10, não apenas recuperação@50

  6. Considere recuperação híbrida se você observar falhas de correspondência exata

    • especialmente para IDs, logs, símbolos de código ou nomes próprios

  7. Reavalie após mudanças na segmentação em trechos ou no conteúdo A qualidade de recuperação geralmente é dominada por mudanças de dados/representação, não por parâmetros do índice.

Onde a Busca Vetorial É Usada Além de RAG

A busca vetorial sustenta muitos sistemas além de perguntas e respostas:

  • Busca semântica de documentos (bases de conhecimento corporativas)
  • Recomendação (“usuários semelhantes a você”, “itens semelhantes a este”)
  • Deduplicação e agrupamento (detecção de quase-duplicatas)
  • Detecção de anomalias (distância em relação a agrupamentos normais)
  • Busca multimodal (texto-para-imagem, imagem-para-imagem)
  • Busca de código (correspondência baseada em funcionalidade)

Cada aplicação tem tolerâncias diferentes para falsos positivos vs falsos negativos, o que muda como você ajusta o ANN e se é necessário reordenar.

Resumo: As Grandes Ideias para Lembrar

  • Representações vetoriais convertem significado em geometria; a busca vetorial recupera por vizinhos mais próximos.
  • Em escala, você quase sempre usa ANN (HNSW, IVF, PQ), o que introduz tradeoffs ajustáveis de revocação/latência/memória.
  • A qualidade de recuperação depende tanto (ou mais) de escolha do modelo de representações vetoriais, estratégia de segmentação em trechos e adequação ao domínio quanto do algoritmo de ANN.
  • Em RAG, a recuperação densa geralmente é combinada com busca híbrida e reordenação para maximizar robustez e precisão no top-k.
  • O sucesso em produção vem da medição: conjuntos offline de relevância + monitoramento online + versionamento cuidadoso e planos de reindexação.

Se você está construindo um pipeline completo de recuperação, as leituras mais diretas a seguir são Ingestão e Segmentação em Trechos, Busca Híbrida (Esparsa + Densa) e Reordenação.