BM25 vs. RAG: por qué la búsqueda por palabras clave y la búsqueda semántica dan respuestas diferentes

BM25 sigue siendo el mecanismo fundamental de búsqueda en Elasticsearch y Lucene, pero tiene una limitación rigurosa: entiende palabras, no significado. Ante esto, RAG con embeddings vectoriales resuelve un problema diferente—encuentra fragmentos relevantes incluso cuando la consulta y el documento no tienen coincidencia exacta en la formulación.

Cómo Funciona BM25

BM25 clasifica documentos por tres señales principales: cuántas veces aparecen los términos de la consulta en el texto, qué tan raros son esos términos en toda la colección y si el documento es demasiado largo comparado con el promedio. Estos factores se combinan en una puntuación final que el sistema utiliza para ordenar los resultados. Este enfoque ha sido la base de la búsqueda clásica durante décadas porque es rápido, comprensible y no requiere un modelo separado para interpretar el significado de la consulta.

El mecanismo de saturación de frecuencia de término es particularmente importante. Si una palabra aparece cinco veces, generalmente aumenta notablemente la relevancia; si aparece cincuenta veces, la ganancia apenas cambia el cuadro. El parámetro k1 controla qué tan rápido se activa esta saturación, y el parámetro b controla cuán fuertemente castigar documentos largos. La capa IDF (frecuencia inversa de documento) amplifica palabras raras y debilita las comunes. Pero la desventaja fundamental de BM25 no desaparece con ningún ajuste: el algoritmo ve el texto como un conjunto de tokens y no distingue contexto, orden de palabras ni significado.

Dónde RAG Gana

La búsqueda vectorial, que normalmente está dentro de un pipeline RAG, funciona de manera diferente. El sistema transforma tanto documentos como la consulta en vectores numéricos densos mediante un modelo de embedding, luego los compara por similitud de coseno. En el ejemplo del artículo se utiliza el modelo text-embedding-3-small de OpenAI con dimensionalidad 1536. Esto permite que una consulta sobre "encontrar contenido similar sin coincidencia exacta de palabras" devuelva texto relevante incluso si las palabras necesarias no aparecen en el documento.

"Ninguno de los enfoques es mejor en todo: fallan en direcciones opuestas."

Aquí es donde surge un compromiso práctico. BM25 se puede configurar localmente: tokenización, índice, aritmética—y la búsqueda está lista. El recuperador vectorial requiere llamadas de API en la fase de indexación y en la de consulta, además de almacenar los propios embeddings. Para un conjunto pequeño esto es trivial, pero con cientos de miles o millones de chunks, este esquema se convierte en una decisión de infraestructura y financiera. Sin embargo, maneja mejor sinónimos, paráfrasis y consultas donde el usuario expresa significado en lugar de palabras clave exactas.

Práctica y Compromisos

El artículo construye la comparación en una demo simple de Python con 12 fragmentos de texto cubriendo BM25, TF-IDF, RAG, transformers, Django, PostgreSQL y otros temas. Para BM25 se utiliza la biblioteca rank_bm25, y para embeddings la API de OpenAI y el cálculo estándar de similitud de coseno. Luego la misma consulta se ejecuta a través de ambos recuperadores para ver qué fragmentos llegan a los mejores resultados. Esto muestra claramente: los sistemas responden una pregunta pero llegan al resultado a través de señales completamente diferentes.

• BM25 busca palabras exactas de la consulta y fácilmente explica por qué un documento se clasificó más alto.
• La búsqueda vectorial busca significado y mejor captura sinónimos y paráfrasis.
• BM25 no requiere GPU, modelos o llamadas externas.
• Los embeddings requieren un índice separado, llamadas de modelo y espacio para almacenar vectores.
• La búsqueda híbrida combina ambos enfoques y se ha convertido en el estándar para producción.

La conclusión del artículo es bastante práctica: discutir qué es "mejor" no tiene sentido fuera del contexto de la tarea. Si necesita búsqueda rápida, barata y transparente por palabras clave explícitas, BM25 sigue siendo muy sólido. Si la coincidencia semántica y la resistencia a diferentes formulaciones importan más, gana dense retrieval. Por eso en sistemas RAG reales hoy, ambas salidas se combinan cada vez más primero, luego los candidatos se pasan al LLM para una respuesta.

Qué Significa Esto

Para equipos construyendo búsqueda sobre una base de conocimiento, FAQ, PDFs o wikis internos, esta es una buena orientación sin magia innecesaria. BM25 no se ha vuelto obsoleto, y RAG no reemplaza la búsqueda clásica. Al contrario, los sistemas más confiables hoy se construyen desde ambas capas: uno proporciona precisión de palabras clave, el otro proporciona comprensión semántica y resistencia a paráfrasis.