Busca Híbrida em RAG: o que é e como funciona

Busca híbrida em RAG é a combinação de dois métodos de recuperação no mesmo pipeline: a busca por palavra-chave (lexical, geralmente com o algoritmo BM25) e a busca vetorial (semântica, feita sobre [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia)). Os dois rankings são então fundidos em um único resultado, normalmente com o algoritmo Reciprocal Rank Fusion (RRF). O objetivo é resolver um problema que cada método sozinho não resolve bem: a busca vetorial encontra significado, mas erra termos exatos; a busca por palavra-chave encontra termos exatos, mas não entende sinônimos nem intenção.

O que é busca híbrida em RAG

Em um sistema de [RAG](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona), a etapa de recuperação (retrieval) busca os trechos mais relevantes em um [banco de dados vetorial](/artigo/banco-de-dados-vetorial-o-que-e-como-funciona) para montar o contexto que vai para o modelo de linguagem. Busca híbrida significa rodar duas buscas em paralelo sobre o mesmo conjunto de documentos — uma lexical (sparse) e uma vetorial (dense) — e combinar as duas listas de resultados antes de decidir o que entra no contexto final.

• Busca lexical (sparse): compara termos exatos entre a pergunta e o documento, geralmente com BM25. É forte em nomes próprios, códigos, siglas, números de processo e jargão técnico.
• Busca vetorial (dense): compara o significado da pergunta com o significado do documento usando embeddings. É forte em paráfrases, sinônimos e perguntas em linguagem natural.
• Fusão de resultados: os dois rankings são combinados em um só, tipicamente com Reciprocal Rank Fusion (RRF), sem precisar normalizar ou comparar as escalas de score diferentes de cada método.

Por que um método sozinho não é suficiente

Cada abordagem falha exatamente onde a outra é forte.

• Só BM25 (lexical): não encontra um trecho que responde à pergunta usando palavras diferentes das da pergunta. Se o documento diz 'colaborador' e a busca é por 'funcionário', a correspondência lexical pode não ocorrer.
• Só busca vetorial (dense): tende a errar quando a pergunta depende de um termo exato — um código de erro, um número de artigo de lei, uma sigla, um SKU de produto — porque embeddings foram treinados para capturar significado, não para casar caracteres.

Como a fusão funciona: Reciprocal Rank Fusion (RRF)

RRF não compara os scores das duas buscas diretamente — score de BM25 e similaridade de cosseno não estão na mesma escala e comparar os dois sem tratamento seria enganoso. Em vez disso, RRF olha só para a posição (rank) de cada documento em cada lista e soma o inverso dessa posição. A fórmula por retriever é score = peso × 1 / (k + rank), onde k é uma constante que suaviza a diferença entre as primeiras posições.

def reciprocal_rank_fusion(rankings, k=60, weights=None):
    """rankings: lista de listas de IDs de documento, já ordenadas por relevância."""
    weights = weights or [1.0] * len(rankings)
    scores = {}
    for ranking, weight in zip(rankings, weights):
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] = scores.get(doc_id, 0.0) + weight / (k + rank + 1)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

Esse mesmo princípio aparece, com nomes diferentes, nas ferramentas mais usadas para montar pipelines de RAG. Segundo a documentação do Weaviate, a busca híbrida usa um parâmetro `alpha` para definir o peso entre os dois métodos: alpha = 0 é busca puramente lexical (BM25), alpha = 1 é busca puramente vetorial, e o padrão é 0,75. Segundo a documentação do Elasticsearch, o retriever `rrf` combina múltiplos retrievers (por exemplo, um `standard` com BM25 e um `knn` vetorial) e expõe os parâmetros `rank_constant` (equivalente ao k da fórmula) e `rank_window_size` (quantos resultados de cada lista entram na fusão, com valor padrão 10). Segundo a referência da API do LangChain, o `EnsembleRetriever` combina múltiplos retrievers via RRF ponderado, recebendo uma lista de `weights` e uma constante `c` (padrão 60, equivalente ao k).

Como implementar RAG híbrido na prática

• Elasticsearch/OpenSearch: usar o retriever `rrf`, combinando uma query `standard` (BM25) com uma query `knn` (vetorial) no mesmo request.
• Weaviate: usar `hybrid` search nativo, ajustando o parâmetro `alpha` entre 0 (BM25) e 1 (vetorial).
• Qdrant: usar o modo `Fusion.RRF`, combinando uma busca esparsa e uma busca densa configuradas no mesmo collection.
• LangChain: usar `EnsembleRetriever` combinando um `BM25Retriever` com o retriever vetorial da sua vector store, definindo `weights` para cada um.

from langchain.retrievers import BM25Retriever, EnsembleRetriever

bm25_retriever = BM25Retriever.from_documents(documentos)
bm25_retriever.k = 5

vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

hybrid_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.4, 0.6],
)

resultados = hybrid_retriever.invoke("qual o prazo do artigo 5 da LGPD?")

O peso inicial (por exemplo 0,4 para BM25 e 0,6 para vetorial, ou alpha = 0,75 no padrão do Weaviate) é só um ponto de partida. Ajustar esse peso exige medir o resultado com um conjunto de perguntas reais do seu domínio — os mesmos critérios usados em [avaliação de RAG](/artigo/avaliacao-de-rag-metricas-pipeline) servem para comparar configurações de busca híbrida entre si.

Quando vale a pena usar busca híbrida

• Bases com códigos, IDs, SKUs, números de processo, siglas ou nomes próprios que precisam de correspondência exata.
• Bases jurídicas, regulatórias ou técnicas, onde citar o termo certo (artigo de lei, nome de função, parâmetro) importa tanto quanto entender a pergunta.
• Catálogos de e-commerce, onde o usuário digita parte do nome de um produto ou um código.
• Bases de conhecimento internas com jargão específico da empresa que um modelo de embeddings genérico não capturou bem.

Erros comuns

• Ajustar o peso (alpha ou weights) uma vez e nunca mais revisar, mesmo depois de mudar o modelo de embeddings ou o conteúdo indexado.
• Tratar busca híbrida como substituta de reranking: os dois resolvem problemas diferentes — a fusão melhora a lista inicial de candidatos, o reranking reordena esses candidatos com um modelo mais caro e preciso antes de montar o contexto final.
• Manter os dois índices (lexical e vetorial) atualizados de forma independente, sem garantir que os dois refletem os mesmos documentos após uma reindexação.
• Ignorar que os dois caminhos de busca herdam os mesmos riscos de segurança do pipeline — o assunto é tratado em [segurança em RAG](/artigo/seguranca-em-rag-riscos-como-proteger).

Busca híbrida não substitui a decisão entre RAG e fine-tuning nem o cuidado na divisão dos documentos em [chunks](/artigo/chunking-rag-como-dividir-documentos-corretamente) — ela melhora a etapa de recuperação depois que essas outras decisões já foram tomadas. Para saber se RAG é a abordagem certa para o seu caso, veja o comparativo em [RAG ou fine-tuning](/artigo/rag-ou-fine-tuning-como-escolher).