Re-ranking: qué es y cómo funciona en RAG

El re-ranking, también escrito reranking o re ranking, es la segunda etapa de un sistema de búsqueda: recibe una lista corta de documentos recuperados y vuelve a puntuarlos con un modelo más preciso para colocar primero los más relevantes. En RAG suele combinar una recuperación rápida con embeddings o palabras clave y un reordenador más costoso antes de entregar contexto al LLM.

Actualizado: 13 de julio de 2026.

Cómo funciona el re-ranking paso a paso

Un sistema de recuperación a gran escala suele separar velocidad y precisión en dos etapas. Buscar con el modelo más costoso sobre todos los documentos sería lento; usar solo una similitud barata puede dejar resultados útiles demasiado abajo.

1. Llega la consulta. El usuario formula una pregunta, por ejemplo: “¿cómo cancelo una suscripción anual?”.
2. Recuperación inicial. BM25, un bi-encoder o una base de datos vectorial encuentra una lista de candidatos. Esta fase intenta no perder documentos relevantes.
3. Nueva puntuación. El reranker recibe pares formados por la consulta y cada candidato, y produce una puntuación de relevancia más fina.
4. Reordenamiento. Los candidatos se ordenan por esa nueva puntuación; no se crean documentos nuevos ni se amplía la colección.
5. Selección final. El sistema muestra los primeros resultados o pasa unos pocos fragmentos al LLM de un sistema RAG.

El re-ranking solo puede promover documentos presentes en la lista inicial. Si la primera etapa no recupera el documento correcto, la segunda no puede inventarlo. Por eso el recall de candidatos sigue siendo una condición necesaria.

Ejemplo sencillo de dos etapas

Supón que la búsqueda inicial devuelve cinco fragmentos. La tabla es ilustrativa: las puntuaciones dependen del modelo y no se comparan entre proveedores.

La primera fase fue útil porque encontró la política correcta. El re-ranking corrigió su posición al comparar con más detalle la intención de la consulta y el contenido del fragmento.

Búsqueda inicial vs. re-ranking

Un bi-encoder genera por separado el embedding de la consulta y el de cada documento. Eso permite precalcular e indexar documentos. Un cross-encoder introduce juntos consulta y documento en el transformer y genera una puntuación para ese par. La documentación de Sentence Transformers resume el intercambio: el cross-encoder suele rendir mejor en pares predefinidos, pero no escala igual sobre colecciones completas.

Cross-encoder, interacción tardía y reranker generativo

No todos los reordenadores tienen la misma arquitectura:

• Cross-encoder: procesa conjuntamente cada par consulta-documento. El trabajo de Nogueira y Cho aplicó BERT al re-ranking de pasajes y reportó, en su configuración de MS MARCO, una mejora relativa del 27 % en MRR@10 frente al estado del arte anterior. Ese resultado pertenece a aquel benchmark; no es una promesa universal.
• Interacción tardía: codifica consulta y documentos por separado, pero conserva representaciones por token para hacer una interacción más rica al final. ColBERT propuso este punto intermedio para reducir el coste de modelos BERT de ranking y permitir precalcular documentos.
• Reranker generativo o basado en LLM: puede puntuar, comparar o devolver un orden mediante instrucciones. Ofrece flexibilidad, pero añade coste, latencia y riesgo de variación; requiere validación consistente del formato y de la calidad.

La elección depende del idioma, dominio, longitud de los textos, hardware, volumen de consultas y tolerancia a latencia. Un modelo excelente en inglés general puede ordenar peor documentos jurídicos o técnicos en español si no fue entrenado o evaluado para ese contexto.

Qué aporta el re-ranking a un sistema RAG

En RAG, los primeros fragmentos suelen entrar en una ventana de contexto limitada. Mejorar su orden puede:

• colocar evidencia directamente relacionada con la pregunta antes que coincidencias superficiales;
• reducir contexto irrelevante que distrae al modelo generador;
• aprovechar mejor un límite pequeño de fragmentos o tokens;
• mejorar la trazabilidad si las citas se construyen a partir de los candidatos finales.

Sin embargo, el re-ranking no elimina las alucinaciones. No verifica por sí mismo que una fuente sea verdadera, reciente o autorizada. Tampoco resuelve una fragmentación deficiente, permisos incorrectos, preguntas ambiguas ni un LLM que ignora el contexto. Es una mejora de recuperación, no una garantía de veracidad.

Cómo elegir el número de candidatos

Hay dos controles diferentes:

• top-N de recuperación: cuántos candidatos recibe el reranker;
• top-K final: cuántos resultados se muestran o pasan al LLM.

Aumentar N puede rescatar documentos que aparecían abajo, pero multiplica el número de pares que debe puntuar un cross-encoder. Aumentar K aporta más contexto, aunque también puede introducir ruido y consumir tokens. El valor correcto se obtiene midiendo consultas reales, no copiando un número fijo de un tutorial.

Una estrategia práctica es empezar con un conjunto de evaluación que incluya preguntas, documentos relevantes y respuestas esperadas. Después se prueban varias combinaciones de N y K bajo un presupuesto de latencia. También conviene separar consultas simples, ambiguas y sin respuesta, porque sus fallos son distintos.

Métricas para saber si funciona

BEIR reúne conjuntos de datos heterogéneos para evaluar recuperación fuera del dominio de entrenamiento. Su lección práctica es importante: un resultado alto en un único benchmark no demuestra generalización a todos los dominios. Para un producto real, las métricas offline deben acompañarse de evaluación humana, errores por tipo de consulta y pruebas de extremo a extremo.

Errores frecuentes

• Evaluar solo el reranker. Si Recall@N es bajo, primero hay que mejorar indexación, embeddings, filtros o recuperación híbrida.
• Enviar demasiados candidatos. Puede aumentar latencia sin mejorar la lista final.
• Ignorar el idioma y el dominio. La relevancia debe probarse con el vocabulario real de los usuarios.
• Confundir puntuaciones con probabilidades. Muchos scores solo sirven para ordenar dentro de una consulta y no tienen un umbral universal.
• Medir solo clics. En RAG también importa si la respuesta usa el fragmento correcto y cita la evidencia adecuada.
• Prometer ausencia de alucinaciones. Un ranking mejor reduce una fuente de error, pero no controla todo el proceso generativo.

Para aprender a integrar búsqueda, automatización y modelos generativos en flujos reales, consulta la ruta de fundamentos de inteligencia artificial.

Fuentes primarias y documentación técnica

• Nogueira y Cho, “Passage Re-ranking with BERT” (2019).
• Khattab y Zaharia, “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT” (SIGIR, 2020).
• Thakur et al., “BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models” (2021).
• Sentence Transformers, documentación oficial de Cross-Encoders y Retrieve & Re-Rank.