Hybrid Search para RAG em produção: BM25, vetores e reranking

TL;DR

Em RAG de produção, a combinação mais comum é um pipeline em dois estágios: primeiro recuperar candidatos com BM25 e busca vetorial em paralelo, depois aplicar reranking para subir os trechos mais relevantes. Isso reduz o risco de perder correspondência exata e melhora a precisão final antes de enviar contexto ao LLM. Para fundir listas de origem diferente sem misturar scores incompatíveis, o padrão prático é o RRF, descrito em SIGIR’09.

Como o hybrid search funciona na prática

Hybrid search junta duas formas complementares de recuperação: BM25, que favorece correspondência lexical, e embeddings vetoriais, que capturam similaridade semântica. Em termos operacionais, você roda os dois caminhos em paralelo, gera duas listas de candidatos e depois consolida o resultado em uma lista única. A lógica de recuperação paralela e fusão aparece na documentação de hybrid search explicado pela Redis.

Esse desenho é útil porque cada técnica cobre um tipo diferente de falha. BM25 tende a ser forte quando a consulta traz nomes, siglas, códigos, IDs, termos regulatórios ou qualquer string que precise casar com exatidão. Já o vetor ajuda quando o usuário descreve a intenção com outras palavras. A Redis descreve essa distinção para RAG em full-text search for RAG, destacando a camada de precisão do full-text no contexto de recuperação para geração.

Por que não depender só de vetor

Em produção, consulta semântica pura pode deixar escapar trechos curtos, termos raros e entidades exatas. Isso é especialmente visível em bases técnicas, documentação interna e conhecimento corporativo. Se o usuário escrever um código de erro, um número de contrato ou o nome exato de um endpoint, a busca lexical costuma ser a primeira linha de defesa.

No outro extremo, depender apenas de BM25 limita a capacidade de capturar significado quando o texto da pergunta não usa a mesma redação da base. O ganho do hybrid está justamente em reduzir essa fricção entre intenção e forma textual.

RRF: a fusão que evita conflito de scores

O problema clássico ao juntar BM25 e vetor é que os scores não são comparáveis. BM25, cosine similarity e dot product operam em escalas diferentes, então tentar "misturar score com score" costuma introduzir ruído. O caminho mais estável é trabalhar com posição no ranking, e não com magnitude do score.

É aí que entra o Reciprocal Rank Fusion. A proposta fundacional do método está em Reciprocal Rank Fusion, publicado pela Google Research. Em vez de somar scores brutos, o algoritmo combina os rankings, dando peso maior aos itens que aparecem bem colocados em mais de uma lista.

Na prática, RRF é valioso porque simplifica a integração entre retrievers heterogêneos: o app para de tentar “calibrar” score de sistemas que não falam a mesma língua e passa a consolidar posição relativa.

Para times de produto, isso reduz acoplamento. Você pode alterar o modelo vetorial, trocar índice lexical ou ajustar a normalização sem precisar redefinir uma escala única de score para tudo. É um detalhe simples na teoria e muito útil na arquitetura.

Fluxo típico de produção

Um pipeline comum fica assim: recuperar top-K via BM25, recuperar top-K via vetor, unir os candidatos com RRF e, por fim, reranquear um conjunto pequeno com um modelo mais caro. O ganho econômico é direto: você usa o método mais pesado apenas sobre poucos textos, em vez de aplicar reranking em todo o corpus.

Esse desenho ajuda a manter o equilíbrio entre cobertura e precisão. Em aplicações com bases grandes, o limite não é só qualidade; é também latência e custo por consulta.

Reranking: o estágio que refina a decisão

Depois da fusão dos candidatos, entra o reranker. Em produção, o caso mais comum é um cross-encoder, que lê a consulta e o trecho em conjunto e calcula uma relevância mais fina do que o retriever inicial. O objetivo não é substituir a busca inicial, mas ordenar melhor o conjunto já reduzido.

Esse estágio é importante porque o retriever precisa ser rápido e barato, enquanto o reranker pode ser mais caro, desde que rode em pouca escala. Na prática, isso costuma ser o ponto em que o sistema deixa de trazer “trechos plausíveis” e passa a trazer “trechos realmente úteis” para o contexto do LLM.

O material da Redis sobre RAG em escala reforça a ideia de usar caminhos dualizados para recuperar rápido e com precisão em RAG at scale. Mesmo quando o vendor não impõe um cross-encoder específico, o princípio de separar recuperação ampla e refinamento final permanece o mesmo.

Quando aumentar ou reduzir o topo de candidatos

Não existe um único valor ideal para top-K. Quanto maior o conjunto inicial, maior a chance de recuperar um trecho relevante, mas maior também a latência e o custo do reranking. Em geral, o ajuste depende do tipo de consulta, do tamanho do corpus e da tolerância à demora da sua aplicação.

Para uma busca interna de documentação, por exemplo, a consulta costuma ser mais tolerante a alguns centenas de milissegundos. Já em chat assistido por conhecimento operacional, o teto precisa ser mais rígido. O ponto-chave é medir o impacto do reranker no tempo total, não apenas na qualidade isolada.

Recuperação híbrida no motor e impacto na arquitetura

Algumas plataformas passaram a embutir a recuperação híbrida no próprio mecanismo de busca. A Redis descreve essa direção em Revamping context-oriented retrieval with hybrid search in Redis 8.4, com a ideia de unificar o fluxo de recuperação no engine e reduzir a orquestração no cliente.

Para o time de engenharia, isso simplifica algumas decisões: menos chamadas separadas, menos cola no código da aplicação e menos pontos de falha entre serviços. Em compensação, você passa a depender mais das capacidades do mecanismo escolhido, então vale olhar com atenção a compatibilidade com filtro, ordenação, paginação e observabilidade.

Esse tipo de decisão é particularmente relevante em organizações brasileiras que já operam com janelas curtas de deploy e times enxutos. Se um sistema de busca vive acoplado a várias integrações internas, cada fluxo extra pode virar custo real de manutenção e suporte.

Por que importa pro dev brasileiro

No Brasil, o desenho da recuperação precisa conversar com restrições bem concretas: custo em moeda forte, latência para regiões externas e necessidade de tratamento cuidadoso de dados pessoais. Em muitos times, a infraestrutura roda em nuvem fora do país ou em regiões próximas, o que torna cada ida extra ao serviço de busca uma decisão de custo e tempo, não só de elegância arquitetural. Além disso, bases corporativas brasileiras frequentemente carregam dados sensíveis, então o uso de busca semântica e reranking precisa respeitar princípios de minimização e finalidade previstos na LGPD.

Isso muda a priorização: não basta recuperar bastante; é preciso recuperar com qualidade, registrar trilha de auditoria e evitar expor contexto desnecessário ao modelo. Em um setor como o financeiro brasileiro, por exemplo, a combinação de correspondência lexical para termos exatos e reranking para precisão ajuda a reduzir respostas erradas em tickets, documentos internos e bases normativas.

Como pensar a adoção sem complicar o stack

Uma forma pragmática de começar é tratar BM25, vetor e reranker como camadas separadas de responsabilidade. O primeiro resolve exatidão, o segundo resolve intenção, e o terceiro faz a seleção fina. Quando essa divisão fica clara, fica mais fácil debugar falhas: se o erro está na recuperação, o problema é do retriever; se o candidato certo aparece mas fica mal posicionado, o problema é do reranker; se o contexto traz o trecho certo e o LLM responde mal, o problema já é da etapa de geração.

Também vale instrumentar métricas por etapa. Observe recall@K, MRR, nDCG e latência por componente. Em RAG, medir só a resposta final costuma esconder o gargalo real. Se o índice lexical recupera bem e o vetor recupera bem, mas a fusão derruba candidatos úteis, o problema está no merge, não no modelo de embedding.

Erros comuns que valem evitar

O primeiro erro é tentar comparar scores brutos de motores diferentes. O segundo é aplicar reranking em listas grandes demais, o que mata a latência. O terceiro é ignorar o caso de consulta curta com entidade exata, justamente o cenário em que BM25 pode salvar a precisão. E o quarto é não medir o impacto do pipeline completo na experiência do usuário final.

Outro pacote de problemas aparece quando a equipe trata a busca como detalhe de infraestrutura, e não como parte do produto. Em RAG, a recuperação define o que o modelo pode responder; logo, ela precisa ser projetada com o mesmo cuidado que o prompt ou a política de segurança.

Conclusão

Se você estiver montando RAG em produção em 2026, pense em hybrid search como um sistema de cobertura + precisão: BM25 protege os casos exatos, vector search cobre a semântica e o reranking faz a ordenação fina antes do LLM. Para unificar as listas sem brigar com escalas de score, RRF segue como escolha prática e bem documentada. Em vez de buscar um único retriever “perfeito”, construa um pipeline observável, modular e medido por etapa.

Uma ação prática que cabe em menos de 1 hora: escolha uma base pequena do seu produto, rode uma consulta com BM25 e outra com embeddings, compare os dois rankings lado a lado e aplique RRF manualmente em um notebook para inspecionar os 10 primeiros candidatos. Se quiser aprofundar a base teórica, leia a publicação sobre RRF e a documentação de hybrid search.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.