BM25 vs. RAG: por que a busca por palavras-chave e a busca semântica dão respostas diferentes

BM25 permanece como o mecanismo fundamental de busca no Elasticsearch e Lucene, mas possui uma limitação rígida: ele entende palavras, não significado. Diante disso, RAG com embeddings vetoriais resolve um problema diferente—encontra fragmentos relevantes mesmo quando a consulta e o documento não têm correspondência exata na formulação.

Como Funciona o BM25

BM25 classifica documentos por três sinais principais: quantas vezes os termos da consulta aparecem no texto, quão raros são esses termos em toda a coleção e se o documento é muito longo comparado à média. Esses fatores se combinam em um escore final que o sistema usa para ordenar os resultados. Essa abordagem tem sido a base da busca clássica por décadas porque é rápida, compreensível e não requer um modelo separado para interpretar o significado da consulta.

O mecanismo de saturação de frequência de termo é particularmente importante. Se uma palavra aparece cinco vezes, geralmente aumenta notavelmente a relevância; se cinquenta vezes, o ganho mal muda o quadro. O parâmetro k1 controla quão rapidamente essa saturação ocorre, e o parâmetro b controla como penalizar fortemente documentos longos. A camada IDF (frequência inversa de documento) amplifica palavras raras e enfraquece as comuns. Mas a desvantagem fundamental do BM25 não desaparece com nenhuma configuração: o algoritmo vê o texto como um conjunto de tokens e não distingue contexto, ordem de palavras e significado.

Onde RAG Vence

A busca vetorial, que normalmente fica dentro de um pipeline RAG, funciona de forma diferente. O sistema transforma tanto documentos quanto a consulta em vetores numéricos densos através de um modelo de embedding, depois os compara por similaridade de cosseno. No exemplo do artigo, usa-se o modelo text-embedding-3-small da OpenAI com dimensionalidade 1536. Isso permite que uma consulta sobre "encontrar conteúdo similar sem correspondência exata de palavras" retorne texto relevante mesmo que as palavras necessárias não apareçam no documento.

"Nenhuma das abordagens é melhor em tudo: elas falham em direções opostas."

É aqui que surge um compromisso prático. BM25 pode ser configurado localmente: tokenização, índice, aritmética—e a busca está pronta. O recuperador vetorial requer chamadas de API na fase de indexação e na de consulta, além de armazenar os embeddings. Para um conjunto pequeno isso é trivial, mas com centenas de milhares ou milhões de chunks, essa esquema se torna uma decisão de infraestrutura e financeira. Porém, ela lida melhor com sinônimos, paráfrases e consultas onde o usuário expressa significado em vez de palavras-chave exatas.

Prática e Compromissos

O artigo constrói a comparação em uma demo simples em Python com 12 fragmentos de texto abordando BM25, TF-IDF, RAG, transformers, Django, PostgreSQL e outros tópicos. Para BM25, usa-se a biblioteca rank_bm25, e para embeddings, a API da OpenAI e cálculo padrão de similaridade de cosseno. A mesma consulta é então executada através de ambos os recuperadores para ver quais fragmentos chegam aos melhores resultados. Isso mostra claramente: sistemas respondem a uma pergunta, mas chegam aos resultados através de sinais completamente diferentes.

• BM25 busca palavras exatas da consulta e facilmente explica por que um documento classificou mais alto.
• A busca vetorial busca significado e melhor captura sinônimos e paráfrases.
• BM25 não requer GPU, modelos ou chamadas externas.
• Embeddings requerem um índice separado, chamadas de modelo e espaço para armazenar vetores.
• A busca híbrida combina ambas as abordagens e se tornou o padrão para produção.

A conclusão do artigo é bem prática: argumentar o que é "melhor" não faz sentido fora do contexto da tarefa. Se você precisa de busca rápida, barata e transparente por palavras-chave explícitas, BM25 continua muito forte. Se correspondência semântica e resiliência a diferentes formulações importam mais, o dense retrieval vence. Por isso, em sistemas RAG reais hoje, ambas as saídas são cada vez mais combinadas primeiro, depois candidatos são passados para o LLM para uma resposta.

O Que Isso Significa

Para equipes construindo busca através de base de conhecimento, FAQ, PDFs ou wikis internas, esta é uma orientação útil sem magia desnecessária. BM25 não se tornou obsoleto, e RAG não substitui a busca clássica. Ao contrário, os sistemas mais confiáveis hoje são construídos de ambas as camadas: uma fornece precisão de palavras-chave, a outra fornece compreensão semântica e resiliência a paráfrases.