¿Qué es el reranking y por qué un RAG sin reranker probablemente esté dejando 30% de calidad encima de la mesa?
Segunda fase de recuperación en RAG: tras la búsqueda vectorial rápida, un modelo cross-encoder reordena los top resultados por relevancia real a la query. Mejora notable de precisión.
Actualizado mayo 2026
Reranking: reordenar candidatos por relevancia real con un modelo más caro.
El reranking es la segunda fase de un pipeline de recuperación moderno. Tras una búsqueda inicial rápida (por similitud de embeddings, BM25 o híbrida) que devuelve los top-50 o top-100 candidatos, un modelo más potente y caro (cross-encoder) los reordena por relevancia real a la query, devolviendo los top-5 o top-10 más relevantes.
La diferencia con embeddings es clave. Un modelo de embeddings (bi-encoder) procesa query y documento por separado y compara vectores; es rápido pero pierde matices contextuales. Un reranker (cross-encoder) procesa query y documento juntos en una sola pasada del modelo; es 10-100x más caro por par pero captura la relevancia real con mucha más precisión.
Por eso el patrón estándar 2026 en sistemas RAG es retrieve + rerank: vector search recupera 50-100 candidatos rápido y barato; reranker reordena solo esos 50-100 (no millones), eligiendo los 5-10 mejores para pasar al LLM. La mejora típica es 20-40% en métricas de retrieval (NDCG@10, MRR, hit rate) según benchmarks reproducibles.
Modelos de reranking principales en 2026: Cohere Rerank 3.5 (API, multilingüe, top en MTEB), Voyage rerank-2 (API, soporta 32K contexto), Jina Reranker v2 (open-source), BGE-Reranker-v2-M3 (open-source, BAAI), mxbai-rerank-large (open-source, Mixedbread). Frameworks como LangChain y LlamaIndex integran rerankers de forma transparente.
Diferencias clave bi-encoder vs cross-encoder
Lo que justifica añadir reranker al pipeline.
Bi-encoder (embeddings)
Procesa query y documento por separado. Cada uno se convierte en vector independiente. Comparación final: similitud coseno entre vectores. Permite indexar millones de docs con búsqueda kNN sub-segundo, pero pierde matices contextuales.
Cross-encoder (reranker)
Procesa query y documento juntos: ambos pasan por el transformer en una sola pasada con atención cruzada. Output: score de relevancia directo. 10-100x más caro por par, pero captura la relevancia real con mucha más precisión.
Por qué se combinan
Cross-encoder no escala a millones de docs (haría falta evaluar query × cada doc). Bi-encoder escala pero pierde precisión. La combinación: bi-encoder filtra a top-50/100 candidatos en ms; cross-encoder reordena solo esos en pocos cientos de ms. Lo mejor de ambos.
Mejora medida en retrieval
En benchmarks típicos (BEIR, MS MARCO, MTEB Retrieval) añadir reranker mejora NDCG@10 entre 15-40%, MRR 10-30%, Hit@5 5-20%. La mejora es mayor cuando la query es compleja, larga o tiene matices.
Trade-off latencia
Reranker añade 100-500ms al pipeline. Para chat con humanos es invisible; para sistemas en stream sub-segundo puede importar. Algunos modelos (Cohere Rerank, BGE-reranker-base) están optimizados para latencia baja.
Trade-off coste
Cohere Rerank: ~2 €/1000 búsquedas. Voyage: similar. Open-source self-hosted (BGE, Jina, mxbai): gratis + coste de GPU/CPU. En la mayoría de casos coste es despreciable frente al LLM downstream.
Rerankers principales y cuándo elegir cada uno
Resumen práctico para decisión.
Cohere Rerank 3.5
API. Multilingüe top (100+ idiomas, fuerte en español). Soporta hasta 4K tokens. Reranker mejor calidad como API en 2026 según benchmarks.
Voyage rerank-2
API. Soporta 32K tokens (buena opción para docs largos). Calidad competitiva con Cohere en inglés.
Jina Reranker v2
Open-source, 568M parámetros. Multilingüe. Excelente calidad/coste para self-host. CPU usable con quantization.
BGE-Reranker-v2-M3
Open-source, BAAI. Multilingüe. Mejor reranker open-source 2026 según MTEB. Hasta 8K tokens.
mxbai-rerank-large
Open-source, Mixedbread. Calidad sólida en inglés. Apache 2.0 license.
ColBERTv2 / ColBERT-X
Late-interaction retrieval: middle ground entre bi-encoder y cross-encoder. Soportado por Vespa, Qdrant. Más complejo de operar.
LLM-as-reranker
Usar un LLM small (GPT-4o-mini, Claude Haiku) como reranker custom con prompt: "ordena estos N docs por relevancia a esta query". Flexible pero más caro y más lento.
RankZephyr / RankGPT
LLMs específicamente fine-tuneados para ranking. Buenos resultados pero menos usados en producción real.
Pipeline retrieve + rerank en RAG
Cinco fases del flujo en producción.
Recuperación inicial
Vector search en <a href="/glosario/que-es-vector-database">vector database</a> (Qdrant, Pinecone, pgvector) o búsqueda híbrida (vector + BM25). Devuelve top-50 o top-100 candidatos. Latencia: 30-200ms.
Llamada al reranker
Se envían (query, doc) para cada uno de los 50-100 candidatos al reranker. API o modelo self-hosted en GPU. Latencia: 100-500ms para 50-100 candidatos.
Reordenación por score
Reranker devuelve score por par (query, doc). Se ordena descendente. Se quedan los top-5 o top-10 mejores. Resto se descarta.
Contexto al LLM
Top-K reordenados se concatenan como contexto al prompt del LLM (Claude, GPT, Gemini). El LLM genera la respuesta citando los docs.
Evaluación periódica
Métricas NDCG@10, MRR, Hit@5 sobre dataset de evaluación. Se mide impacto del reranker vs solo retrieval. Se afina top-K, modelo, prompt según resultados.
Reranking en el ecosistema RAG moderno.
El reranking es la segunda mitad del pipeline de recuperación en RAG. Va después de los embeddings y antes de la generación del LLM. Es la pieza más infravalorada del stack — añadirla suele dar mejor ROI que cambiar de modelo de embeddings o de LLM.
Frameworks como LangChain, LlamaIndex y Haystack integran rerankers nativamente: con 3-5 líneas tienes el pipeline retrieve+rerank funcionando. LLMOps debe medir el impacto del reranker en evaluación contra dataset.
Patrón habitual: retrieval híbrido (BM25 + embeddings, fusionado con Reciprocal Rank Fusion) → reranker → top-K al LLM. Esta combinación bate a embeddings solos por amplio margen en cualquier benchmark serio. Suma LLMOps con evaluación reproducible y tienes un RAG enterprise-grade.
En Magnetia añadimos reranking por defecto en cualquier sistema RAG empresarial que diseñamos. Combinable con automatización IA y consultoría. Ver sistema RAG paso a paso y observabilidad LLM.
Dudas que nos hacéis llegar
¿Tu RAG ya tiene reranking?
Si la respuesta es "no" o "no sé", probablemente estás dejando 20-40% de calidad encima de la mesa. Auditamos tu pipeline RAG y planificamos la mejora.