Benchmark de rerankers: comparación de los 8 mejores modelos
Comparamos 8 modelos de reranking en ~145k reseñas en inglés de Amazon para medir cuánto mejora la recuperación densa una etapa de reranking. Recuperamos los 100 candidatos principales con multilingual-e5-base, los rerankeamos con cada modelo y evaluamos los 10 mejores resultados frente a 300 consultas, cada una haciendo referencia a detalles concretos de su reseña original. El mejor reranker mejoró el Hit@1 del 62.67 % al 83.00 % (+20.33pp).
Resultados del benchmark de rerankers
Métricas explicadas:
ΔHit@1 / ΔHit@10 muestra la mejora sobre la línea base (sin reranker) en puntos porcentuales (pp). Por ejemplo, +20.33pp significa que el reranker mejoró el Hit@1 en 20.33 puntos porcentuales respecto al 62.67 % de la línea base.
Hit@K mide si alguna reseña con el product_id correcto aparece en los primeros K resultados. La verdad fundamental es el product_id de la reseña que generó la consulta. Si una reseña diferente del mismo producto entra en los primeros K, cuenta como acierto. Hit@1 es la prueba más estricta: ¿es el primer resultado del producto correcto? Hit@10 es más indulgente: ¿aparece el producto correcto en algún lugar de los primeros 10 resultados?
MRR@10 (Rango recíproco medio) promedia 1/rango del primer resultado correcto en todas las consultas. Si el primer product_id coincidente está en el rango 1, la puntuación es 1.0. En el rango 2, es 0.5. En el rango 10, es 0.1. Esto premia a los modelos que colocan el producto correcto lo más alto posible.
nDCG@10 (Ganancia acumulativa descontada normalizada) evalúa las posiciones de todas las reseñas coincidentes en los primeros 10, no solo la primera. Si el mismo producto tiene varias reseñas en el conjunto de candidatos y varias aterrizan en los primeros 10, nDCG acredita cada una según su posición. En la práctica, la mayoría de productos tienen solo 1 o 2 reseñas entre los 100 candidatos, por lo que nDCG y MRR van muy parejos.
Recall@10 mide la fracción de reseñas coincidentes (mismo product_id) en los primeros 10 respecto al total de reseñas coincidentes en el conjunto completo de candidatos (primeros 100). Si un producto tiene 3 reseñas entre los primeros 100 y el reranker coloca 2 de ellas entre los primeros 10, el Recall@10 es 2/3 para esa consulta. Como la mayoría de productos tienen pocas reseñas duplicadas en el conjunto de candidatos, Recall@10 y Hit@10 son casi idénticos en esta comparativa.
Desglose de latencia
La latencia de reranking mide el tiempo que tarda cada codificador cruzado en puntuar 100 documentos candidatos frente a la consulta. Se excluye el tiempo de búsqueda vectorial (~20ms) porque se mantiene constante en todas las ejecuciones y es independiente del reranker.
Métricas de latencia explicadas:
Rerank es el tiempo que tarda el codificador cruzado en puntuar todos los 100 documentos candidatos frente a la consulta. Aquí es donde los modelos difieren: un solo pase hacia adelante es rápido, mientras que la decodificación autorregresiva es lenta.
P95 es el percentil 95 de la latencia total. Algunas consultas tienen textos de reseña más largos, lo que aumenta el tiempo de tokenización y puntuación. P95 muestra el peor caso esperable para el 95 % de las consultas.
Hallazgos clave
Un modelo de 149M iguala a uno de 1.2B
gte-reranker-modernbert-base tiene 149M parámetros, nemotron-rerank-1b tiene 1.2B. Ambos logran un 83.00 % de Hit@1 en inglés. La arquitectura ModernBERT es 8x más pequeña y ofrece idéntica precisión en la métrica principal.
Esto no significa que el tamaño del modelo sea irrelevante. nemotron lidera ligeramente en MRR@10 (0.8514 vs 0.8483) y Hit@10 (88.33 % vs 88.00 %), lo que significa que ordena los documentos relevantes ligeramente mejor en todo el top-10. Pero para la mayoría de aplicaciones donde lo que importa es acertar en el primer resultado, el modelo de 149M es suficiente.
El modelo más grande no es el mejor
qwen3_reranker_4b tiene 4B parámetros y tarda más de un segundo por consulta. Logra un 77.67 % en Hit@1, quedando en cuarto lugar por detrás de nemotron (1.2B), gte_modernbert (149M) y jina (560M). Pagas 4.5x la latencia de nemotron por 5.3 puntos porcentuales menos de precisión.
La arquitectura de qwen3 utiliza modelado de lenguaje causal con un enfoque de logit sí/no. El modelo lee el par consulta-documento y devuelve la probabilidad de “sí, esto es relevante”. Es conceptualmente limpio, pero la inferencia es costosa debido al sobrecoste de la decodificación autorregresiva. Los modelos SequenceClassification (gte_modernbert, bge) y el enfoque de plantilla de prompt de nemotron procesan el par en un solo pase hacia adelante, lo que es fundamentalmente más rápido.
Jina ofrece el mejor equilibrio velocidad-precisión
jina_reranker_v3 alcanza un 81.33 % en Hit@1 con 188ms. nemotron logra un 83.00 % con 243ms. Si necesitas una latencia total por consulta inferior a 200ms, Jina es el único modelo de la gama alta que lo consigue. La diferencia de 1.67 puntos porcentuales puede no justificar los 55ms adicionales en un sistema en producción que atiende miles de solicitudes por segundo.
Un reranker empeora los resultados
mxbai_rerank_xsmall (70M parámetros) obtiene un 64.67 % en Hit@1. La línea base sin ningún reranker obtiene un 62.67 %. La mejora es de solo 2 puntos porcentuales, lo que está dentro del ruido para 300 consultas. Con 70M parámetros, el modelo carece de la capacidad para juzgar de forma fiable la relevancia consulta-documento en textos más largos o con más matices.
Un reranker no es beneficioso automáticamente. Pruébalo con tus datos reales antes de desplegarlo.
El recuperador establece el techo
Todos los mejores rerankers convergen alrededor del 87-88 % de Hit@10. Este techo lo impone el recuperador. Si multilingual-e5-base no coloca el documento correcto entre los 100 candidatos principales, ningún reranker puede recuperarlo. El 12 % restante de consultas en las que todos los rerankers fallan representa los casos en los que el recuperador denso simplemente no encontró el documento relevante.
Para mejorar más allá de este techo se necesita un mejor recuperador, un conjunto de candidatos más amplio o ambos. Probamos con los 250 mejores candidatos y no encontramos apenas mejora respecto a los 100 mejores, lo que significa que e5_base agota sus candidatos útiles mucho antes del rango 250.
Cómo funcionan los rerankers
Un recuperador denso (codificador dual) codifica consultas y documentos de forma independiente en vectores. La recuperación es una búsqueda de vecinos más cercanos sobre estos vectores. Es rápido porque solo se codifica la consulta en el momento de la búsqueda, pero el modelo nunca ve la consulta y el documento juntos, por lo que puede pasar por alto señales de relevancia sutiles.
Un reranker (codificador cruzado) toma un par consulta-documento como una sola entrada. El modelo atiende conjuntamente a ambos textos, captando relaciones que la codificación independiente pasa por alto. El coste es que hay que ejecutar el modelo una vez por candidato, por lo que solo puedes permitirte puntuar un grupo reducido.
Arquitecturas en este benchmark
Probamos cuatro arquitecturas diferentes de codificador cruzado:
Los modelos SequenceClassification (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) toman un par [query, document] como entrada y producen una única puntuación logit. Es el enfoque más simple y común.
Nemotron utiliza un formato de plantilla de prompt: “question:{q} passage:{p}”. La entrada se ve como texto plano en lugar de un par estructurado, pero el modelo sigue produciendo una puntuación de relevancia única mediante SequenceClassification. El preentrenamiento como LLM (basado en Llama) le proporciona una sólida comprensión del lenguaje.
Los rerankers de Qwen3 utilizan modelado de lenguaje causal. El modelo lee el par y genera un juicio sí/no. La puntuación es log P(sí) / (P(sí) + P(no)). Esto requiere toda la maquinaria autorregresiva, lo que explica la mayor latencia.
Jina v3 utiliza una API personalizada (model.rerank()) que maneja la tokenización y la puntuación internamente. La arquitectura subyacente utiliza atención cruzada, pero la interfaz abstrae los detalles.
Metodología del benchmark de rerankers
- GPU: NVIDIA H100 PCIe 80GB a través de Runpod
- Base de datos vectorial: Qdrant 1.12.0 (binario local), distancia coseno
- Recuperador: multilingual-e5-base (768-dim). Prefijo de consulta:
"query: ", prefijo de documento:"passage: " - Software: transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
- Dataset: Subconjunto en inglés de Amazon Reviews Multi (Kaggle).1 ~145k reseñas tras filtrar por un mínimo de 100 caracteres. Cada reseña tiene un product_id, texto de reseña y valoración de estrellas.
- Generación de consultas: Claude Sonnet 4.6 a través de OpenRouter. 300 consultas en inglés (5 tipos: factuales, de opinión, de uso, resolución de problemas, comparación de características). Cada consulta debe hacer referencia a detalles concretos de su reseña original; las preguntas genéricas (puntuación de especificidad < 4/5) se filtran.
- Formato del documento:
"Review Title: {title}\nReview: {body}" - Pipeline: Recuperar los 100 mejores candidatos con multilingual-e5-base, reordenar con el codificador cruzado, devolver los 10 mejores. La línea base omite el reranking y devuelve directamente los 10 mejores del recuperador.
- Verdad fundamental: solo coincidencia exacta de product_id. Sin recurrir a similitud coseno. Sin crédito parcial para productos semánticamente similares.
- Variable controlada: Solo el modelo de reranker cambia entre experimentos. El recuperador, el número de candidatos, el conjunto de consultas y los criterios de evaluación son idénticos en todas las ejecuciones.
- Sin fine-tuning: Todos los modelos evaluados en zero-shot con los pesos predeterminados de HuggingFace.
- Latencia: Reranking (puntuación del codificador cruzado de 100 candidatos). Medido por consulta en GPU.
Modelos evaluados
Añadir como fuente preferidaLimitaciones
Este benchmark utiliza un solo recuperador (multilingual-e5-base). Un recuperador diferente generaría conjuntos de candidatos distintos y podría cambiar la clasificación de los rerankers. Los resultados reflejan cómo funciona cada reranker con este recuperador concreto, no la calidad del reranker de forma aislada.
Probamos con reseñas de productos en inglés de Amazon. El rendimiento en otros dominios (artículos científicos, documentos legales, código) u otros idiomas será diferente.
El número de candidatos está fijado en 100. Algunos rerankers podrían ordenar de forma diferente con 20 o 200 candidatos. Probamos con 250 candidatos y apenas encontramos mejora, lo que sugiere que 100 son suficientes para e5_base, pero otros recuperadores pueden comportarse de manera distinta.
300 consultas es un tamaño de muestra moderado. Los tres mejores modelos (nemotron, gte_modernbert, jina) están separados por menos de 2 puntos porcentuales. Con un conjunto de consultas más grande, estas clasificaciones podrían cambiar. La diferencia entre el escalón superior y el inferior (20+ puntos porcentuales) es robusta.
Conclusión
Los rerankers funcionan. El mejor modelo en este benchmark eleva el Hit@1 del 62.67 % al 83.00 % (+20.33pp), lo que significa que 20 de cada 100 consultas que antes devolvían el documento equivocado en primer lugar ahora devuelven el correcto. Es una mejora significativa para un componente que añade menos de 250ms de latencia.
El hallazgo más útil es que el tamaño del modelo no determina la calidad del reranker. gte-reranker-modernbert-base con 149M parámetros iguala a nemotron-rerank-1b con 1.2B en Hit@1. El modelo Qwen3 de 4B parámetros queda en cuarto lugar. Si estás eligiendo un reranker para un sistema en producción, empieza con los modelos más pequeños. Puede que nunca necesites los más grandes.
Para aplicaciones sensibles a la latencia, jina-reranker-v3 es la opción más fuerte por debajo de 200ms. Para máxima precisión sin restricciones de latencia, nemotron-rerank-1b y gte-reranker-modernbert-base comparten el primer puesto. Para equipos con presupuesto de GPU, gte-modernbert es el claro ganador: misma precisión que el modelo de 1.2B con una fracción de la huella de memoria.
Un patrón se mantuvo en todos los experimentos: el recuperador establece el techo. Ningún reranker logró un Hit@10 superior al 88 %, porque el 12 % restante de documentos correctos nunca apareció entre los 100 candidatos principales. Invertir en un mejor recuperador probablemente aporte mayores ganancias que cambiar entre los tres mejores rerankers.
Lecturas adicionales
Explora otros benchmarks de RAG, como:
- Modelos de embedding: OpenAI vs Gemini vs Cohere
- Los 16 mejores modelos de embedding de código abierto para RAG
- La mejor base de datos vectorial para RAG: Qdrant vs Weaviate vs Pinecone
- Benchmark de RAG agentivo: enrutamiento multi-bases de datos y generación de consultas
- Modelos de embedding multimodal: Apple vs Meta vs OpenAI
- RAG híbrido: mejorando la precisión del RAG
- Los 10 mejores modelos de embedding multilingüe para RAG
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark de rerankers: comparación de los 8 mejores modelos}},
year = {2026},
month = feb,
howpublished = {\url{https://aimultiple.com/rerankers}},
note = {AIMultiple. Recuperado el 26 de Febrero de 2026}
}Resultados y marcas de tiempo de 17 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 2 archivos CSV y un README.
Enlaces de referencia
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.