Hybrid search: BM25 + vectores + reranking

La búsqueda vectorial es en 2026 el estándar de facto para las implementaciones de RAG. La mayoría de los equipos configuran un modelo de embedding, llenan Qdrant o pgvector y despliegan en producción. Funciona — hasta que llega una consulta como «§ 271 párr. 2 del Código del Trabajo» o «HMI modelo 7NF-420-C». Un embedding denso no sabe qué hacer con eso: comprime el documento en un único vector y la cadena exacta se pierde en la norma semántica. Aquí es donde entra el hybrid search — la combinación de búsqueda por palabras clave (BM25) y búsqueda vectorial, con un reranker encima.

Este artículo profundiza más que el tema tratado en pipeline RAG — 3 ajustes de calidad, donde mencionamos el reranker solo en el contexto del pipeline. Aquí nos centramos exclusivamente en la capa de búsqueda: por qué los vectores solos no son suficientes, cómo funciona el híbrido mecánicamente, qué es la fusión RRF, cuándo el reranker realmente ayuda y cómo configurarlo todo en la práctica.

Por qué los vectores solos no son suficientes

Un modelo de embedding denso (p. ej., BGE-M3 o text-embedding-3-large) convierte el texto en un vector en un espacio de cientos o miles de dimensiones. Los vectores cercanos entre sí tienen contenido semánticamente similar. Excelente para preguntas como «¿cuáles son las condiciones de rescisión del contrato laboral?», donde lo que importa es el significado.

El problema surge con las consultas léxicamente específicas:

• Números de normas y leyes: § 63, EN ISO 12100, Reglamento UE 2016/679
• Códigos de producto y de pieza: SKF-6204-2RS, Siemens SIMATIC S7-1500
• Nombres, abreviaturas, acrónimos: BOZP, NBS, análisis FFT
• Valores exactos: 230 V AC, IP67, UL 508A

En estos casos el embedding falla por una sola razón: el modelo no fue entrenado para entender que «SKF-6204-2RS» y «SKF-6205-2RS» son artículos fundamentalmente distintos. Los vectores pueden estar cerca porque comparten el prefijo. La coincidencia exacta se pierde.

BM25 (Best Matching 25) no tiene este problema. Es un método estadístico clásico de variante TF-IDF de 1994 que pondera explícitamente la aparición de cada token en un documento frente al corpus. Para cadenas exactas, BM25 sigue siendo mejor que cualquier embedding — y esto es tan cierto en 2026 como lo era en 2014.

A partir de benchmarks orientativos sobre corpus sintéticos:

• Solo BM25: ~58 % de precisión
• Solo vectores densos: ~79 %
• Híbrido (BM25 + dense): ~85–88 %
• Híbrido + reranker cross-encoder: ~88–91 %

La mejora real depende del conjunto de datos, el idioma y el tipo de consultas. Para documentaciones industriales con códigos y normas, en la práctica observamos un salto de precision@5 del híbrido frente al denso de alrededor de 8–12 puntos porcentuales.

Cómo funciona BM25

BM25 es un modelo estadístico. Para cada documento y consulta calcula una puntuación como suma ponderada de TF-IDF (frecuencia de término — frecuencia inversa de documento) para cada token de la consulta. Parámetros:

• k1 — controla la saturación de la frecuencia de término (típicamente 1,2–2,0). Mayor valor = relación más lineal entre frecuencia y puntuación.
• b — normalización de la longitud del documento (0 = ninguna, 1 = completa). Por defecto 0,75.

BM25 no requiere GPU ni hardware especial — es determinista, rápido y funciona en CPU. La librería rank_bm25 en Python, o soporte nativo en Weaviate, OpenSearch, Elasticsearch y Qdrant (mediante vectores dispersos).

Limitación: BM25 no entiende sinónimos ni paráfrasis. La consulta «rescisión del contrato laboral» no encontrará un documento que solo hable de «despido». Para eso están precisamente los vectores.

Reciprocal Rank Fusion — cómo combinar dos resultados

Cuando tenemos dos rankings independientes (BM25 y vectores densos), hay que unirlos en uno. El enfoque más habitual en 2026 es RRF (Reciprocal Rank Fusion).

La mecánica es sencilla. Para cada documento calculamos:

RRF_score(d) = sum( 1 / (k + rank_i(d)) )

donde rank_i(d) es la posición del documento en el i-ésimo ranking y k es un parámetro de suavizado (típicamente 60). Los documentos que aparecen en posiciones altas en ambos rankings obtienen la puntuación más alta. Un documento que un sistema no conoce pero que el otro rankea en 1.ª posición sigue obteniendo una buena puntuación.

¿Por qué no la media ponderada de puntuaciones? Las puntuaciones de BM25 y la similitud coseno de los embeddings están en escalas distintas — una ponderación directa favorecería a uno de los dos sistemas. RRF trabaja únicamente con posiciones, por lo que la escala no importa.

Alternativa a RRF: DBSF (Distribution-Based Score Fusion) — normaliza las puntuaciones antes de la fusión, adecuado cuando ambos sistemas están calibrados. En la práctica, la mayoría de las implementaciones empiezan con RRF y prueban DBSF solo cuando hay problemas de distribución.

El parámetro alpha en algunos frameworks (p. ej., Weaviate) controla simplemente la proporción BM25 vs. dense — alpha=0 = BM25 puro, alpha=1 = dense puro, alpha=0.5 = contribución igual de ambos. El valor por defecto 0,5 es un buen punto de partida, pero para contenido con alta densidad de códigos y normas pruebe alpha=0,3–0,4 (mayor contribución de BM25).

Reranker — por qué el retrieval no es suficiente

El hybrid search mejora significativamente el recall — la probabilidad de que el documento correcto esté entre los top-K candidatos. Pero la precision@5 (cuántos de los primeros 5 son realmente relevantes) depende de qué tan bien estén ordenados los candidatos.

Aquí entra el reranker (modelo cross-encoder). Mecánica:

1. 1.El hybrid retrieval devuelve los top-K documentos (típicamente K = 20–50). Rápido.
2. 2.El reranker recibe cada uno de los K documentos junto con la consulta, los procesa conjuntamente y asigna una puntuación de relevancia precisa. Más lento, pero más preciso.
3. 3.Los top-N (típicamente N = 5) con la puntuación reranker más alta van al contexto del LLM.

¿Por qué es más preciso el reranker que el embedding? El embedding bi-encoder comprime el documento y la consulta cada uno por separado en un vector — la interacción entre ambos se evalúa únicamente mediante la distancia coseno. El cross-encoder ve la consulta y el documento al mismo tiempo, lo que le permite capturar interacciones sutiles a nivel de token que el bi-encoder pierde.

Incremento típico de precision@5 tras añadir un reranker: 7–12 puntos porcentuales. Latencia adicional: 50–200 ms para reranking de top-20.

Los mejores de su clase actualmente:

• Cohere Rerank 3.5 — API gestionada, excelente para contenido multilingüe incluyendo Europa central, integración sencilla
• BGE-reranker-v2-m3 — open-weight, self-hosted, multilingüe, excelente relación rendimiento/coste
• ms-marco-MiniLM-L-6-v2 — pequeño, rápido, para prototipado en inglés

Para la selección del modelo de embedding aplica un principio similar: el contenido multilingüe de la UE merece un reranker multilingüe.

Cuándo el híbrido ayuda claramente (y cuándo no)

El hybrid search ayuda claramente cuando:

• El contenido contiene códigos, cifras, abreviaturas, normas, denominaciones de producto
• El usuario hace consultas exactas (copiar y pegar desde un documento, código de pieza de un pedido)
• El idioma no es exclusivamente inglés — BM25 no necesita un modelo lingüístico, funciona igual de bien para español
• El recall es un problema — «el documento relevante no se encontró» es una queja habitual
• El corpus contiene documentos temáticamente muy similares (p. ej., 5.000 fichas técnicas con estructura similar)

El hybrid search ayuda menos cuando:

• Las consultas son exclusivamente conversacionales, basadas en paráfrasis (chatbot de FAQ, respuestas de RRHH)
• El corpus es pequeño (menos de 500 documentos) — la latencia y complejidad adicionales no compensan
• La latencia es crítica — en cada extremo se añade el scoring BM25 (típicamente +10–30 ms) y potencialmente el reranker (+50–200 ms)
• El contenido es principalmente en inglés y los embeddings son de calidad — los vectores densos se acercan a los resultados del retrieval híbrido

Vimos el caso de un cliente del sector de recambios: corpus de 18.000 fichas técnicas con códigos SKF, NSK, FAG. Retrieval dense puro, precision@5 = 0,63. Tras migrar a híbrido con alpha=0,35 y BGE-reranker-v2-m3: precision@5 = 0,84. Motivo principal — coincidencia exacta con el código de pieza de la consulta del cliente.

Configuración práctica — stack 2026

Qdrant (recomendado para implantaciones industriales B2B)

Qdrant soporta hybrid search nativo mediante vectores dispersos + densos en una sola colección. Los vectores dispersos para BM25 se generan con BM25Encoder de la librería fastembed.

# inicialización del sparse encoder
from fastembed import SparseTextEmbedding
sparse_model = SparseTextEmbedding("Qdrant/bm25")

# durante la indexación
sparse_vec = sparse_model.embed(text)
dense_vec = embedding_model.embed(text)

# query: hybrid search con fusión RRF
results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=sparse_vec, using="sparse", limit=20),
        Prefetch(query=dense_vec, using="dense", limit=20),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=5
)

Configuración de la colección: dos índices vectoriales — dense (dimensión según el modelo de embedding, coseno) y sparse (índice disperso, producto escalar). Qdrant gestiona ambos en un solo paso.

Weaviate

Weaviate tiene el hybrid search como función de primer nivel — BM25 + vectores densos + fusión RRF en una sola llamada a la API. Configuración de alpha directamente en la query:

results = collection.query.hybrid(
    query="§ 63 Zákonník práce výpoveď",
    alpha=0.4,  # mayor contribución de BM25
    limit=20
)

Después reranker con Cohere o cross-encoder local sobre los top-20 resultados.

Capa de reranking

Independientemente de la base de datos vectorial, el reranker es un paso separado. Configuración recomendada:

• K = 20–30 candidatos del hybrid retrieval
• Reranker sobre K candidatos → N = 5 resultados para el LLM
• Para self-hosted: BGE-reranker-v2-m3 en GPU; en CPU gestiona ~500 ms/query para top-20
• Para cloud: Cohere Rerank 3.5 API, endpoint EU

Añadir un reranker a un hybrid retrieval existente suele ser 20–40 líneas de código. Cuando hablamos de evaluación del pipeline RAG con RAGAS, precisamente este paso debería tener su propia métrica precision@5 antes y después.

Latencia: qué añade cada capa

Latencias típicas con 10 M de vectores, GPU RTX 4090 (orientativo):

• Scoring BM25 en CPU: 10–30 ms
• Búsqueda de vectores densos (Qdrant): 5–15 ms
• Fusión RRF: menos de 5 ms
• Reranker cross-encoder top-20 (GPU): 80–150 ms
• Reranker cross-encoder top-20 (CPU): 400–800 ms
• Cohere Rerank 3.5 API (red): 100–200 ms

Pipeline completo: hybrid retrieval + reranker GPU = típicamente 200–400 ms en la capa de búsqueda de extremo a extremo. Para chatbots interactivos suele ser aceptable. Para sistemas con requisito por debajo de 150 ms, considere usar el reranker solo cuando la latencia de red sea baja, o sustituirlo por un resorting con bi-encoder más sencillo.

Una comparación más detallada de bases de datos vectoriales y sus parámetros QPS puede encontrarse en el artículo Bases de datos vectoriales — Qdrant, Weaviate, pgvector, Milvus.

Preguntas frecuentes

¿Debo diseñar el sistema con hybrid retrieval desde el principio, o puedo añadir BM25 después?

El índice BM25 es independiente del índice de embedding y puede añadirse a un corpus existente en cualquier momento. En Qdrant basta con agregar un índice de vectores dispersos a la colección y reindexar los documentos — los índices densos permanecen intactos. Weaviate, Milvus y pgvector tienen un procedimiento similar. El tiempo de reindexación depende del tamaño del corpus, pero para una base de conocimiento B2B típica (hasta 1 M de documentos) se mide en horas, no en días.

¿Qué es mejor para contenido en español: BM25 o embedding denso?

Depende del carácter de las consultas. BM25 funciona igual de bien para el español que para el inglés — es un modelo estadístico sin dependencia lingüística. Para preguntas semánticas (paráfrasis, sinónimos) es mejor un embedding denso multilingüe como BGE-M3 o Qwen3-Embedding-8B. En la práctica, para corpus B2B en español: el híbrido con alpha=0,4–0,5 da el mejor resultado.

¿Cuándo el reranker no ayuda?

El reranker solo reordena los documentos que devolvió el retrieval. Si el documento correcto no está entre los top-K candidatos, el reranker no puede rescatarlo. Esto significa: primero hay que mejorar el recall (hybrid retrieval, K mayor) y luego añadir el reranker. Si precision@5 no mejora ni con el reranker, el problema suele estar en el recall — el documento correcto simplemente no está entre los candidatos.

¿Cuál es la diferencia entre hybrid search y agentic RAG?

El hybrid search es una técnica a nivel de capa de retrieval — mejora qué documentos llegan al contexto del LLM. Agentic RAG es un patrón arquitectónico en el que un agente decide activamente qué buscar y cómo — consultas iterativas, fuentes diversas, sub-queries. El hybrid search y el agentic RAG no son excluyentes: un buen agente usa hybrid retrieval internamente.

¿Se puede desplegar hybrid search on-prem sin dependencias cloud?

Sí. Tanto Qdrant como Weaviate son open-source y se ejecutan en self-hosted. BGE-reranker-v2-m3 es un modelo open-weight que corre localmente en GPU. BM25 no requiere ningún servicio externo. Todo el stack — hybrid retrieval + reranker — puede funcionar completamente on-prem, lo cual es importante para sectores regulados. Más sobre el tema en LLM on-prem para sectores regulados.

---

*Si su sistema RAG tropieza con que códigos exactos, normas o denominaciones de producto no se encuentran de forma fiable, el problema casi siempre está en la ausencia de la capa de palabras clave. Ayudamos a las empresas a diseñar e implantar un stack de hybrid retrieval — desde la selección de la base de datos y el modelo de embedding hasta la configuración del reranker y la medición de la mejora.*