Reranking en RAG: cross-encoder vs. bi-encoder

El reranking es la segunda fase de recuperación en un pipeline RAG: un cross-encoder vuelve a evaluar los mejores candidatos que ha encontrado el bi-encoder rápido y los ordena según su relevancia real para la consulta. Según Anthropic, el reranking reduce notablemente la tasa de error de recuperación frente a la recuperación puramente vectorial, a costa de una mayor latencia. Por tanto, el reranking no es un extra opcional: en sistemas en producción es la palanca más fiable para pasar de «semánticamente similar» a «realmente relevante».

• Qué hace: el reranking reordena los candidatos de la primera recuperación antes de que lleguen al prompt del LLM.
• Por qué dos fases: el bi-encoder rápido aporta recall sobre millones de chunks; el cross-encoder preciso, precisión en el top-k final.
• Efecto concreto: Anthropic informa de una reducción de hasta el 67 % en la tasa de error de recuperación top-20 al combinar Contextual Retrieval con reranking.

Por qué no basta con una recuperación de una sola fase

La recuperación vectorial clásica trabaja con un bi-encoder. Este codifica de antemano cada chunk de documento en un vector y lo guarda en un índice ANN (normalmente HNSW). En el momento de la consulta, esta se proyecta en el mismo espacio vectorial y la similitud se calcula mediante la distancia coseno. Es extremadamente rápido y escala a millones de entradas, pero es una aproximación. La consulta y el documento nunca se «ven» juntos; el modelo solo compara dos representaciones comprimidas generadas de forma independiente.

La consecuencia es un antipatrón típico: los resultados top-k son semánticamente similares, pero no necesariamente relevantes para la pregunta concreta. Justo ahí actúa el reranking. Es una fase posterior a la recuperación que aplica un mecanismo más preciso, aunque más lento, a un pequeño conjunto de candidatos en lugar de a todo el corpus.

Bi-encoder vs. cross-encoder: la diferencia clave

El núcleo arquitectónico del reranking es el paso del bi-encoder al cross-encoder.

Un bi-encoder procesa la consulta y el documento por separado. Cada uno se codifica en un vector, y la relevancia se obtiene después a partir de la distancia entre esos vectores. Como los embeddings de los documentos se pueden calcular e indexar de antemano, el bi-encoder es la única opción viable para la recuperación inicial sobre corpus grandes.

Un cross-encoder procesa la consulta y el documento juntos en un único forward pass. El modelo ve ambos textos a la vez y puede tener en cuenta interacciones palabra por palabra, negaciones y matices de significado. El resultado es una evaluación de relevancia mucho más precisa, aunque hay que hacer el cálculo para cada par consulta-documento. Sobre millones de chunks sería prohibitivamente caro; sobre 50 a 100 candidatos prefiltrados es asumible.

En medio se sitúa el enfoque de late interaction (ColBERT): almacena embeddings a nivel de token por documento y calcula la relevancia mediante una operación MaxSim entre los tokens de la consulta y los del documento. Ofrece más precisión que un bi-encoder clásico y escala mejor que un cross-encoder completo, pero consume bastante más memoria para los vectores de tokens.

Posición en el pipeline y estrategia de top-k

El reranking es una fase bien definida dentro de la ruta de consulta. La disposición canónica es esta:

```
[Recuperación híbrida, top_k = 50-100]
-> [Cross-Encoder Reranker (Cohere Rerank / BGE / Jina)]
-> [top_k = 5-10]
-> [Prompt + citas de fuentes]
-> [LLM]
```

Lo decisivo: el reranker entra solo después del recall barato del bi-encoder. La recuperación híbrida inicial (búsqueda densa más BM25, fusionadas mediante Reciprocal Rank Fusion) entrega a propósito un conjunto generoso de 50 a 100 candidatos para maximizar el recall. Después, el cross-encoder reduce ese conjunto a los 5 a 10 chunks realmente relevantes que entran en el prompt.

Este estrechamiento no es solo una cuestión de costes. Un top-k demasiado grande enviado al LLM provoca el efecto «Lost-in-the-Middle»: la información relevante situada en mitad de un contexto largo se procesa peor y los costes de tokens aumentan. El reranking con un top-k ajustado de 5 a 10 es la contramedida estándar, con una recomendación adicional: colocar los chunks más importantes al principio del prompt.

Modelos de reranking: panorama (a octubre de 2026)

Para escenarios en Europa con requisitos de soberanía, el BGE-Reranker v2-m3 es la opción on-premise más evidente: está bajo Apache 2.0, es multilingüe y puede ejecutarse con fines comerciales en tu propio centro de datos o en una región de la UE. El anterior bge-reranker-large (licencia MIT) solo cubre chino e inglés, según su ficha de modelo. Los Jina Reranker v2, v3 y v3.5 (publicado el 27.07.2026) tienen pesos abiertos, pero están bajo CC BY-NC 4.0. Para un uso comercial on-premise necesitas una licencia de Jina AI; si no, te quedan la API de Jina, Elastic Inference Service o las ofertas en AWS, Azure y Google Cloud. Jina AI tiene su sede en Berlín, pero pertenece a Elastic desde octubre de 2025.

Si aceptas una API y necesitas calidad multilingüe, incluido el alemán, en la práctica recurrirás a Cohere Rerank. La alternativa, Voyage, pertenece a MongoDB desde febrero de 2025; sus modelos actuales son rerank-3 y rerank-3-lite. Según la publicación de lanzamiento del 30.09.2026, Voyage probó rerank-3 en 95 conjuntos de datos de 9 dominios, 51 de ellos multilingües en 31 idiomas. El enfoque LLM-as-Judge (por ejemplo, el LLMRanker de Haystack) es el más flexible, pero también el más caro por consulta, y solo debería usarse donde la calidad del reranking sea crítica y el presupuesto de latencia, holgado.

Compromiso entre latencia y calidad

El reranking es la fase más costosa de la parte de recuperación de la ruta online (antes de la generación del LLM), porque el cross-encoder hace un cálculo por cada candidato. En sistemas en producción, la latencia total de recuperación híbrida más reranking suele estar entre unos 100 y 800 milisegundos. Este margen se puede controlar directamente:

• Tamaño del conjunto de entrada: hacer reranking de 100 candidatos cuesta más que de 30. Según el corpus, a menudo basta con un conjunto más pequeño.
• Elección del modelo: los rerankers vía API como Cohere están optimizados para un alto volumen de procesamiento; un LLM-as-Judge es bastante más lento.
• Hardware: los rerankers autoalojados se benefician mucho de la inferencia en GPU; en CPU, la latencia aumenta considerablemente.

Por tanto, el compromiso no es «reranking sí o no», sino «cuántos candidatos para qué presupuesto de latencia». En la mayoría de los casos de uso empresariales, la ganancia de precisión compensa la latencia adicional.

Ejemplo numérico: aumento de la precisión

En la publicación «Introducing Contextual Retrieval» (19.09.2024), Anthropic midió cifras concretas en sus propios benchmarks (código, ficción, artículos de ArXiv, ciencia); Cohere actuó como reranker. Hay que leerlo como la evaluación de un proveedor con intereses propios, aunque metodológicamente documentada:

• Base (solo recuperación): tasa de error de recuperación top-20 del 5,7 %.
• Solo Contextual Embeddings: reducción del 35 %, hasta el 3,7 %.
• Contextual Retrieval (embeddings más BM25): reducción del 49 %, hasta el 2,9 %.
• Contextual Retrieval más reranking: reducción del 67 %, hasta el 1,9 %.

En concreto: de 1.000 documentos relevantes, al principio faltan 57 en el top-20; con el pipeline completo, solo 19. El reranking por sí solo, como paso del 2,9 al 1,9 %, elimina en esta configuración aproximadamente otro tercio de los errores restantes. En un sistema RAG en producción, cada error de recuperación evitado supone un chunk menos que lleve al LLM a una respuesta errónea o sin fundamento. Precisamente por eso, la práctica de RAG considera «sin reranking» un antipatrón claro: los top-k son entonces semánticamente similares, pero no relevantes.

Para agencias y decisores B2B

Si vas a montar un sistema RAG en producción en Europa, planifica el reranking desde el principio como una fase fija del pipeline, no como un ajuste posterior. El impacto es grande y el esfuerzo de implementación, contenido: una llamada adicional a una API (Cohere) o un reranker autoalojado con licencia abierta, como BGE v2-m3, entre la recuperación y el LLM. Para las agencias que crean asistentes de conocimiento o buscadores internos para sus clientes, el reranking ofrece la mejor relación entre ganancia de calidad y esfuerzo, y un argumento medible en el pitch, porque el aumento de precisión se puede demostrar en frameworks de evaluación como RAGAS (Context Precision). Blck Alpaca diseña este tipo de arquitecturas de recuperación en dos fases, con una selección de modelos conforme a la normativa de la UE y un presupuesto de latencia definido. Pide una revisión de tu pipeline RAG actual para comprobar si los chunks correctos llegan de verdad a las primeras posiciones.