BM25 na busca híbrida: combine vetores e avalie o recall

Documentação verificada em 24 de outubro de 2026. As orientações de implementação abaixo seguem a documentação atual de Elasticsearch, Weaviate e Pinecone. As configurações de avaliação são uma proposta de protocolo inicial, não ganhos medidos nem benchmarks dos fornecedores.

O que é busca híbrida e onde entra o BM25?

A busca híbrida, ou hybrid search, permite que tanto os termos literais quanto o significado influenciem a recuperação de conteúdo. Na arquitetura deste guia, a busca por palavras-chave gera uma lista ordenada, a busca vetorial gera outra e um método de fusão combina as duas. A explicação do Weaviate descreve os dois caminhos e como eles se encontram.

Imagine dois pesquisadores respondendo à mesma pergunta de suporte. Um consulta nomes e mensagens de erro exatos em um índice. O outro procura ideias relacionadas, inclusive respostas escritas de outra forma. Você reúne as seleções dos dois, em vez de pedir que apenas um faça todo o trabalho.

O BM25 é uma função de ranqueamento lexical que atribui uma pontuação aos documentos com base nos termos da consulta que eles contêm. A frequência dos termos e o tamanho do documento influenciam essa pontuação; o resultado é mais útil do que uma simples contagem de palavras coincidentes. O Elasticsearch usa BM25 como medida padrão de similaridade textual. A referência de similaridade da Elastic detalha esses fatores.

A busca vetorial compara embeddings, representações numéricas do conteúdo, para encontrar significados semelhantes. Ela pode associar “Sou desconectado toda hora” a um documento sobre expiração de sessão, mesmo com palavras diferentes. Nosso guia de busca semântica explica esse caminho de recuperação.

Em uma consulta ilustrativa como ERR_SESSION_EXPIRED after login, o caminho lexical permite que a mensagem de erro literal apareça nos resultados. O caminho semântico pode trazer orientações sobre sessões de autenticação e renovação. A fusão define a ordem final. O exemplo descreve o comportamento pretendido; não afirma que um sistema sem configuração específica produzirá determinado ranking.

Busca híbrida com vetores ainda exige uma política para termos exatos

Ter um caminho de busca por palavras-chave não garante a correspondência exata de identificadores. A análise de texto, processo que transforma strings em tokens pesquisáveis, pode alterar o que entra no índice. O analisador padrão da Elastic, por exemplo, separa uma expressão com hífen no exemplo da documentação. Confira como o analisador configurado trata seus próprios SKUs e códigos de erro. Documentação do analisador padrão.

Mantenha os identificadores em um campo dedicado à correspondência exata quando a grafia definir o item solicitado. A Elastic documenta o campo keyword para esse tipo de valor estruturado. Uma consulta pelo SKU fictício AX-BLUE não deveria virar, silenciosamente, uma recomendação de AX-GREEN só porque as descrições são parecidas. Referência do campo keyword.

Regra de decisão: encaminhe um identificador reconhecido e único para uma consulta exata quando esse for o comportamento prometido pelo produto. Use o ranqueamento híbrido em perguntas que combinem um identificador com uma necessidade mais ampla, como encontrar orientações para resolver um problema naquele item.

RRF ou pontuações ponderadas: como combinar os resultados

Comece pela fusão por classificação recíproca quando precisar de uma referência inicial que dispense a calibração de escalas de pontuação distintas. Considere pontuações ponderadas quando houver rótulos para ajustar o equilíbrio e um motivo para preservar as diferenças entre as pontuações.

A fusão por classificação recíproca usa as posições

A fusão por classificação recíproca, ou RRF, soma uma contribuição de cada lista em que o documento aparece:

RRF(documento) = soma de 1 / (c + posição) nas listas de resultados recuperados.

As posições são contadas a partir da primeira. Um documento ausente não recebe contribuição daquela lista. Gordon V. Cormack, Charles L. A. Clarke e Stefan Büttcher apresentaram o RRF em seu artigo da SIGIR 2009. Nos experimentos, fixaram a constante em 60. O artigo a chama de k; aqui usamos c para não confundi-la com a quantidade de resultados em recall@k.

O RRF é prático porque uma pontuação alta de BM25 e uma pontuação alta de busca vetorial não precisam significar a mesma coisa. Só as posições importam. A implementação de RRF do Pinecone explicita tanto a contagem de posições a partir da primeira quanto o tratamento de documentos ausentes.

Há uma consequência que merece atenção. Em um exemplo construído, o documento A aparece em primeiro na lista de palavras-chave e não aparece na lista vetorial. O documento B fica em segundo nas duas. Com c = 60, A recebe 1/61; B recebe 2/62. B vence. Esse é um cálculo nosso a partir da fórmula, não um benchmark de busca.

Pontuações ponderadas preservam as diferenças entre os resultados

A fusão por pontuações ponderadas combina os escores de relevância depois de tornar suas escalas comparáveis. Uma forma comum é:

pontuação = alpha × pontuação vetorial normalizada + (1 − alpha) × pontuação lexical normalizada.

O peso alpha controla o equilíbrio. Um valor inicial de 0.5 atribui coeficientes iguais; não significa que os dois caminhos tenham a mesma utilidade nem que essa seja a configuração ideal. Documente a normalização junto com os pesos, pois alterar qualquer um deles pode mudar o ranking.

O recuperador linear do Elasticsearch permite uma soma ponderada com normalizadores como minmax. A fusão por pontuações relativas do Weaviate preserva as diferenças relativas dentro de cada conjunto de resultados, enquanto a fusão por posições descarta essas diferenças.

Use RRF na primeira comparação; só mantenha a fusão ponderada se as consultas reservadas para avaliação justificarem a escolha. Não some pontuações brutas de BM25 às de similaridade vetorial presumindo que o resultado faça sentido. Registre também a quantidade de candidatos recuperados: mudar quais resultados entram em uma lista normalizada pode alterar o intervalo de suas pontuações.

Quando a busca híbrida supera a busca apenas vetorial

A busca híbrida ajuda quando o caminho lexical recupera material relevante que o caminho vetorial deixou passar, e a fusão mantém esse material em uma posição útil. É uma condição que pode ser inspecionada, não uma promessa universal de precisão.

Os cenários mais promissores para um teste são:

• Busca em suporte: mensagens de erro literais, nomes de funções e termos de conta misturados a descrições de sintomas.
• Busca em catálogo: nomes exatos de produtos ou SKUs combinados com necessidades como compatibilidade ou peças de reposição.
• Busca no conhecimento interno: nomes de projetos e abreviações junto a perguntas em linguagem natural.

A visão geral de busca híbrida do Pinecone cita especificamente códigos de produtos, mensagens de erro e nomes como sinais lexicais, ao lado da recuperação densa voltada ao significado.

Para consultas exclusivamente por identificador, comece com uma busca exata confiável. Se a busca vetorial já atende bem ao conjunto de documentos e consultas, espere por evidências de um problema de recuperação antes de adicionar outro caminho.

O limite prático está na cobertura dos candidatos. A fusão só consegue ordenar a união dos documentos recuperados pelos dois caminhos. Se nenhum deles encontrar o trecho relevante, trocar o método de fusão não vai recuperá-lo. Se o trecho estiver presente antes da fusão, mas sumir dos resultados finais, investigue o ranqueamento e o corte da lista.

Como adicionar busca híbrida ao sistema que você já usa

Mantenha o sistema atual se ele oferecer os recursos de recuperação necessários. Trocar o banco de dados e a estratégia de busca ao mesmo tempo dificulta identificar o que trouxe melhora.

A distinção abaixo mostra onde a combinação acontece; não é um ranking de fornecedores.

Busca híbrida no Elasticsearch

O Elasticsearch, mecanismo de busca com recuperação textual e vetorial, pode colocar um recuperador textual standard e um recuperador vetorial knn sob um recuperador rrf. A referência oficial do recuperador RRF documenta essa organização e sua janela de candidatos.

Em um índice existente, mantenha o texto pesquisável e seu embedding no mesmo ID de documento. Execute os dois caminhos sobre o mesmo conteúdo elegível e, depois, aplique a fusão. Mantenha as restrições de tenant, permissões e versão do produto consistentes entre os caminhos.

A requisição abaixo pode ser executada depois de definir ES_URL e ES_API_KEY. Ela pressupõe um índice existente chamado docs, um campo de texto chamado text, um campo de vetor denso chamado embedding e um arquivo query-vector.json com o array real do embedding da consulta. Gere esse array com o mesmo modelo usado nos documentos indexados. O comando exige jq e curl.

jq -n --slurpfile v query-vector.json \
  --arg q 'ERR_SESSION_EXPIRED after login' \
  '{
    size: 10,
    retriever: {
      rrf: {
        retrievers: [
          {standard: {query: {match: {text: $q}}}},
          {knn: {
            field: "embedding",
            query_vector: $v[0],
            k: 50,
            num_candidates: 100
          }}
        ],
        rank_window_size: 50,
        rank_constant: 60
      }
    }
  }' > hybrid-request.json

curl --fail-with-body "$ES_URL/docs/_search" \
  -H "Authorization: ApiKey $ES_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @hybrid-request.json

Essas configurações são exemplos para avaliação. size define a quantidade final de resultados; rank_window_size controla quantos resultados de cada recuperador filho podem participar da fusão. Antes de copiar este exemplo sem filtros para uma aplicação com controle de permissões, adicione as restrições que definem quais conteúdos podem ser recuperados. A Elastic documenta um filter no recuperador pai que se aplica aos recuperadores filhos conforme suas especificações.

O limite: uma janela estreita no recuperador filho pode descartar justamente o resultado que você esperava resgatar com a busca híbrida. Compare os candidatos de cada caminho com os resultados finais antes de ajustar a fusão. Se mudar para o recuperador linear, configure a normalização junto com os pesos.

Busca híbrida no Weaviate

O Weaviate, banco de dados com recuperação textual e vetorial, oferece busca híbrida por meio de collection.query.hybrid. Seu componente lexical é o BM25F, variante que aceita múltiplos campos. A documentação de consultas híbridas cobre propriedades pesquisáveis, escolha da fusão e explicações das pontuações.

Direcione query_properties para os campos que trazem evidências lexicais úteis, como títulos, textos de erro e nomes de produtos. Forneça o vetor da consulta quando sua aplicação gerar os embeddings ou use a vetorização configurada na coleção. Defina fusion_type explicitamente ao comparar métodos de fusão e solicite explain_score para diagnosticar por que um resultado mudou de posição.

Defina também alpha explicitamente: 0 seleciona a busca por palavras-chave e 1 seleciona a busca vetorial. A documentação atual alerta que, quando esse parâmetro é omitido, a ponderação efetiva depende do cliente. relativeScoreFusion é o método padrão; rankedFusion também está disponível. Referência de fusão do Weaviate.

O limite: um peso não corrige a ausência de um campo pesquisável nem um token de identificador alterado indevidamente. Inspecione a contribuição lexical antes de concluir que é preciso trocar o modelo de embeddings. Use os extremos do intervalo de pesos — só vetores e só palavras-chave — como referências de diagnóstico e, depois, avalie a configuração combinada.

Busca híbrida no Pinecone

O Pinecone, banco de dados para recuperação de conteúdo, documenta padrões distintos de busca híbrida. Escolha o padrão antes de copiar um exemplo: a combinação de vetores densos e esparsos no servidor e o RRF no cliente são implementações diferentes. Visão geral de busca híbrida do Pinecone.

Para BM25 com recuperação densa, o caminho da Documents API executa uma busca de texto completo e uma busca por vetores densos, depois combina os IDs ordenados dos documentos com RRF na sua aplicação. O guia de RRF do Pinecone inclui essa implementação no cliente.

Para a combinação nativa de vetores densos e esparsos, a Vectors API pode armazenar as duas representações em cada registro e combiná-las em uma única consulta. Seu guia de índice único exige vector_type="dense" e metric="dotproduct"; o cliente ajusta a escala dos vetores da consulta para definir a influência relativa de cada um.

Um vetor esparso é uma representação, não uma prova de que foi gerado por BM25. Deixe explícito, nas notas de arquitetura, qual é o modelo lexical ou a função de pontuação de texto completo.

O limite: aplicar um filtro por palavra-chave e depois ranquear por vetores densos não equivale a deixar os dois sinais influenciarem o ranking. Um filtro remove candidatos; ele não consegue resgatar uma correspondência por sinônimo que já excluiu. Use filtros para condições obrigatórias e fusão quando qualquer um dos caminhos de recuperação puder contribuir com um resultado.

Como a busca híbrida funciona em RAG?

A busca híbrida altera a etapa de recuperação da geração aumentada por recuperação, ou RAG, em que uma aplicação fornece fontes recuperadas a um modelo de linguagem antes que ele responda. Ela não substitui a etapa de geração nem garante que a resposta esteja correta.

Mantenha a mesma unidade de recuperação. Se o caminho lexical retornar documentos inteiros e o vetorial retornar trechos, defina como relacionar seus IDs antes de combiná-los. Caso contrário, vários trechos da mesma fonte podem ocupar a seleção enquanto outras fontes relevantes ficam de fora. Nosso guia sobre bancos de dados vetoriais explica os fundamentos de armazenamento e recuperação.

O RAG agêntico acrescenta decisões sobre qual ação de recuperação executar ou se é preciso buscar novamente. Um recuperador híbrido pode ser uma dessas ações. Se um bot de suporte não encontra um código de erro literal, corrija e avalie esse recuperador antes de adicionar mais orquestração.

Mantenha o gerador e o prompt fixos durante a comparação dos métodos de recuperação. Se o grupo de consultas com termos exatos melhorar, mas a recuperação de paráfrases continuar fraca, use as mesmas consultas rotuladas para comparar modelos de embeddings. Mudar embeddings, divisão em trechos e fusão ao mesmo tempo impede identificar a causa do resultado.

Como medir o recall@k antes e depois

Use um conjunto pequeno de consultas rotuladas e compare a recuperação só por palavras-chave, só por vetores e híbrida com base nas mesmas respostas esperadas. Uma resposta gerada com fluência não é uma métrica de recuperação.

Recall@k = IDs relevantes recuperados nos primeiros k resultados ÷ todos os IDs rotulados como relevantes para aquela consulta. Calcule a média dos valores por consulta para obter o recall@k macro. Se os rótulos estiverem incompletos, apresente o resultado como recall em relação aos julgamentos de relevância conhecidos; ele não comprova a recuperação de todos os itens relevantes do conjunto de documentos.

Execute o avaliador local de recall

Salve o código abaixo como evaluate_recall.py. Ele usa apenas a biblioteca padrão do Python 3. O arquivo qrels.jsonl contém um objeto JSON por consulta, com os campos qid, slice e relevant. Cada arquivo de resultados associa o ID de uma consulta à sua lista ordenada de IDs retornados.

Por exemplo, um registro de rótulo poderia ser {"qid":"q-exact","slice":"exact","relevant":["guide-login"]}. Um arquivo de resultados poderia conter {"q-exact":["guide-reset","guide-login"]}. São exemplos de formato, não resultados de busca de um sistema testado. Inclua todas as consultas rotuladas em todos os arquivos de resultados, com uma lista vazia quando a recuperação não retornar nada.

import json
import sys
from collections import defaultdict
from statistics import mean

qrels_path, bm25_path, vector_path, hybrid_path, cutoff = sys.argv[1:]
k = int(cutoff)
if k < 1:
    raise ValueError("k must be positive")

with open(qrels_path, encoding="utf-8") as f:
    labels = [json.loads(line) for line in f if line.strip()]
if not labels or len({r["qid"] for r in labels}) != len(labels):
    raise ValueError("Labels must be nonempty with unique query IDs")

runs = {}
for name, path in (("bm25", bm25_path), ("vector", vector_path),
                   ("hybrid", hybrid_path)):
    with open(path, encoding="utf-8") as f:
        runs[name] = json.load(f)
    missing = {r["qid"] for r in labels} - runs[name].keys()
    if missing:
        raise ValueError(f"{name} is missing query IDs: {sorted(missing)}")

groups = defaultdict(list)
skipped = 0
for row in labels:
    relevant = set(row["relevant"])
    if not relevant:
        skipped += 1
        continue
    scores = {}
    for name, run in runs.items():
        unique_ids = list(dict.fromkeys(run[row["qid"]]))
        scores[name] = len(relevant & set(unique_ids[:k])) / len(relevant)
    groups["overall"].append(scores)
    groups["slice:" + row["slice"]].append(scores)

if not groups:
    raise ValueError("No answerable queries to score")
for group, rows in sorted(groups.items()):
    values = {name: mean(r[name] for r in rows) for name in runs}
    delta = values["hybrid"] - values["vector"]
    report = " ".join(f"{name}={v:.3f}" for name, v in values.items())
    print(f"{group} n={len(rows)} recall@{k} {report} delta={delta:+.3f}")
print(f"Excluded no-answer queries: {skipped}")

Execute-o com os rótulos e resultados exportados do conjunto reservado para avaliação:

python3 evaluate_recall.py qrels.jsonl bm25.json vector.json hybrid.json 10

O script remove IDs duplicados antes de aplicar o corte. Use a mesma política de remoção de duplicatas nos resultados da aplicação. Ele informa a variação da busca híbrida em relação à vetorial e também mostra a referência lexical, para que um bom desempenho por palavras-chave não fique fora da comparação.

Coloque em produção quando os grupos de consultas relevantes melhorarem e as regressões forem aceitáveis segundo os requisitos do produto. Se os candidatos melhorarem, mas o recall final não, ajuste a fusão ou o corte dos resultados. Se o recall final melhorar, avalie separadamente a ordem dos resultados, a correção das respostas geradas e a latência de ponta a ponta. O recall não mede nenhum desses aspectos.

O que é exagero e qual deve ser o próximo passo

“A busca híbrida oferece o melhor dos dois mundos” esconde a decisão de engenharia. Ela pode ampliar a cobertura útil, mas também dá a outro caminho de recuperação influência sobre a lista final. O RRF pode rebaixar uma correspondência exata; a fusão ponderada pode favorecer o caminho cuja escala de pontuação ou normalização se comporta de forma diferente; nenhum dos dois corrige a falta de conteúdo nas fontes.

Quem desenvolve deve agir agora quando a inspeção mostrar que documentos relevantes com termos exatos não aparecem entre os candidatos vetoriais. Adicione o caminho lexical, mantenha a identidade dos documentos e as permissões consistentes e execute a comparação com consultas rotuladas.

Quem opera deve adiar a implantação quando o problema atual for conteúdo desatualizado, falta de permissões ou ausência de rótulos de relevância. Resolva esses pré-requisitos e só então compare as estratégias de recuperação.

Equipes com uma busca confiável por identificadores não precisam mudar nada até surgir a necessidade de uma descoberta mais ampla. Preserve o caminho de consulta exata que já funciona e avalie a busca híbrida separadamente para perguntas em linguagem natural.

Para começar na segunda-feira: reúna as buscas que falham, rotule as fontes esperadas e execute o recuperador vetorial atual lado a lado com uma referência de busca por palavras-chave. Adicione a fusão depois de enxergar o que cada caminho contribui. Mantenha a configuração que justificar seu uso nas consultas reservadas para avaliação.

Perguntas frequentes

Receba guias práticos de desenvolvimento na newsletter.