BM25 vs Embeddings vs Rerankers: stack de búsqueda en 2026
Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Un buen stack de búsqueda funciona como un embudo. Primero, los métodos baratos recopilan un conjunto amplio de candidatos; después, los métodos más costosos refinan un conjunto mucho más pequeño. Los problemas suelen empezar cuando los equipos sustituyen la búsqueda de texto exacto por embeddings en lugar de combinar ambos enfoques.
Empieza con filtros y BM25, un método sólido de ranking de texto exacto. Añade recuperación densa para encontrar coincidencias semánticas y, después, combina ambas listas de resultados con Reciprocal Rank Fusion (RRF) o un método similar. Aplica reranking a la shortlist con un cross-encoder. Usa un LLM únicamente para un conjunto final muy pequeño, cuando la mejora de calidad justifique la latencia y el coste adicionales.
Última revisión: 2026-08-10. El stack se evalúa según recall, mejora del ranking, corrección de las políticas, latencia p95 y coste en segmentos de consultas reales, no según un único número universal de candidatos.
Stack recomendado
| Etapa | Valor predeterminado | Función |
|---|---|---|
| Filtrado | Filtros estructurados | Aplicar restricciones de tenant, permisos, producto, idioma, tiempo y disponibilidad. |
| Recuperación léxica | BM25 | Nombres exactos, IDs, códigos de error, términos legales y tokens de alta precisión. |
| Recuperación densa | Embeddings | Sinónimos, paráfrasis, intención difusa y recall semántico. |
| Fusión | Reciprocal Rank Fusion o composición ponderada de retrievers | Combinar candidatos sparse y densos sin asumir que sus scores son comparables. |
| Reranking | Cross-encoder | Reordenar una shortlist con latencia acotada mediante la interacción entre consulta y documento. |
| Precisión final | LLM reranker o modelo de respuesta | Resolver la relevancia matizada solo cuando la lista sea pequeña. |
| Evaluación | Recall@k, nDCG, MRR, etiquetas de clics y etiquetas humanas | Demostrar que cada etapa mejora la anterior. |
Valores predeterminados por caso de uso
| Superficie de producto | Valor predeterminado recomendado | Motivo |
|---|---|---|
| Búsqueda en documentación | BM25 más embeddings más cross-encoder | Importan tanto los nombres exactos de las API como las preguntas semánticas. |
| Recuperación para RAG | Recuperación híbrida más reranker más comprobaciones de citas | La falta de evidencia suele ser peor que una generación lenta. |
| Búsqueda de productos | Filtros léxicos más recuperación híbrida más features de negocio | Importan la disponibilidad, el precio, la popularidad y las facetas exactas. |
| Búsqueda de soporte | Recuperación híbrida más freshness y metadatos de tickets | Importan tanto la redacción similar como la política vigente. |
| Base de conocimiento interna | Baseline con BM25 y, después, recuperación densa a partir de logs de consultas | Empieza con métricas antes de añadir coste de modelo. |
| Búsqueda legal o de compliance | Baseline léxico más filtros estrictos y, después, expansión semántica cuidadosa | Tanto los falsos positivos como los falsos negativos tienen un coste elevado. |
Por qué BM25 sigue formando parte del stack
Los embeddings encuentran textos con un significado similar, pero no sustituyen de forma fiable la coincidencia exacta. Los códigos de error, nombres de funciones, SKUs de productos, expresiones legales y nombres de personas suelen transmitir la intención mediante su escritura exacta. BM25 sigue siendo un baseline sólido porque da más peso a los términos que el usuario ha escrito realmente.
La recuperación densa aumenta el recall cuando los usuarios no conocen el vocabulario exacto. La decisión no es elegir entre BM25 y embeddings. Usa BM25 para el recall léxico, embeddings para el recall semántico y la fusión para combinar ambos.
Cuándo añadir un reranker
Añade un cross-encoder cuando los documentos relevantes entren en el conjunto de candidatos, pero queden demasiado abajo en el ranking. Elige el número de candidatos a partir del recall y la latencia medidos; top 50 es un experimento útil, no un umbral universal.
No añadas un LLM reranker antes de un cross-encoder, salvo que el conjunto de candidatos sea diminuto. El criterio de relevancia también debe ser lo bastante sutil como para justificar el coste. El reranking con LLM puede ayudar, pero es más caro y lento. Compáralo mediante métricas con un reranker más barato.
Secuencia de evaluación
- Etiqueta consultas reales que cubran intenciones importantes, idiomas, permisos y costes de fallo. Empieza con un conjunto pequeño y amplíalo hasta que los segmentos y la incertidumbre permitan respaldar la decisión.
- Mide BM25 por sí solo.
- Añade recuperación densa y mide la variación del recall.
- Añade la fusión y mide nDCG y Recall@k.
- Añade reranking con cross-encoder y mide Precision@1 y nDCG.
- Añade reranking con LLM solo si mejora la calidad después de incluir el coste y la latencia.
- Supervisa las métricas en producción: tasa de resultados cero, tasa de reformulación, click-through, correcciones de respuestas, latencia p95 y coste.
Lecturas recomendadas
- Search Ranking Stack ofrece el walkthrough completo de implementación.
- Métricas de evaluación de RAG explica la evaluación de la recuperación y de las citas.