Pular para conteúdo

Capítulo 2.7 — Hybrid search, reranking e metadata filtering

🎯 Objetivo

Mostrar por que vector search puro raramente é suficiente em produção corporativa e como hybrid search + reranking + metadata filtering, juntos, formam o pipeline de retrieval defensável que aparece em quase todo RAG maduro.

Vector search captura similaridade semântica ("contrato com cláusula de rescisão antecipada" se aproxima de "como cancelar o contrato"), mas costuma falhar quando a query depende de strings literais: nomes de produto, códigos de erro, SKUs, siglas internas, números de versão.

BM25 e variantes lexicais resolvem exatamente esse caso: alta precisão em correspondência de termos.

Hybrid search combina os dois e funde o ranking. As estratégias mais comuns:

  • Linear combination. score = α · score_vec + (1−α) · score_bm25, com α calibrado em golden set.
  • Reciprocal Rank Fusion (RRF). Combina rankings, não scores: insensível a escalas distintas, é o default sensato na maior parte dos casos.
  • Late fusion com reranker. Buscas separadas, união dos top-k de cada uma, e um reranker cross-encoder decide.
Quando hybrid ajuda Quando hybrid é desperdício
Corpus com muito jargão técnico, siglas, códigos Texto livre uniforme em um único idioma
Queries que misturam linguagem natural com termos literais Queries puramente semânticas
Domínios regulados onde o termo exato importa Corpus pequeno e homogêneo
Multi-idioma com glossário compartilhado Domínios onde BM25 sozinho já satura

🧠 Reranking

Reranking reordena os top-k iniciais usando um modelo mais caro e mais preciso do que o retriever. O padrão dominante é o cross-encoder: o modelo lê a query e o documento juntos, em vez de comparar embeddings independentes.

Pipeline típico em produção:

query -> retrieval top 50–100 -> metadata filter (obrigatório) ->
reranker top 5–10 -> context builder -> LLM

Notas operacionais:

  • Reranker fraco é pior do que não ter reranker. Mede e compara com e sem o reranker em golden set antes de promover.
  • Latência e custo crescem. O reranker roda em todos os candidatos, não só nos vencedores; um top-50 com reranker cross-encoder é tipicamente o maior consumidor de latência no RAG.
  • Reranker compensa parte da fraqueza do embedding, mas não resolve filtros ausentes nem chunking ruim. É a última cápsula da pilha, não a primeira.

🧠 Metadata filtering

Filtros obrigatórios em RAG enterprise:

  • tenant_id.
  • language.
  • jurisdiction / region.
  • confidentiality_level.
  • product / version.
  • valid_from / valid_until (freshness).

Princípios:

  • Filtros são aplicados no storage, antes do reranker, antes do prompt. Quando o vector DB ou search engine recebe a query, ele já sabe que existe um conjunto de filtros não-negociáveis.
  • Falha do filtro deve ser explícita. Query sem tenant_id deveria ser rejeitada, não tratada como "todos os tenants".
  • Filtros não substituem isolamento. Em tenants muito sensíveis, índices separados ou collections distintas são preferíveis a filtros sobre um índice compartilhado.

🚨 Modos de falha clássicos

  • Hybrid search sem calibração: peso lexical alto degrada queries semânticas e vice-versa.
  • Reranker treinado em outro domínio: prioriza padrões irrelevantes.
  • Metadata aplicado depois do retriever: o top-k vem contaminado por outros tenants e o filtro só limpa o resíduo.
  • Filtros baseados em campos texto sem normalização: pt-BR e pt_br viram tenants diferentes.

📌 Checklist

  • [ ] BM25 + vetorial são combinados via RRF ou linear calibrado?
  • [ ] Reranker foi avaliado contra "sem reranker" em golden set?
  • [ ] Filtros por tenant/idioma/jurisdição rodam no storage, não no prompt?
  • [ ] Query sem filtros obrigatórios é rejeitada explicitamente?
  • [ ] Latência e custo do reranker são monitorados em p95?

📚 Referências