Definición
El reranking es un segundo paso de la búsqueda: primero recuperas muchos candidatos rápido y barato, y luego un modelo más lento y más listo los reordena por relevancia real.
Es el patrón clásico de recuperar y refinar, y existe porque hay una tensión que no se puede resolver de una sola pasada: buscar entre un millón de documentos exige ser rápido, y ser rápido exige ser aproximado.
La ganancia es de las mejores que hay en relación esfuerzo/resultado dentro de un RAG. Suele mover más el resultado final que cambiar a un modelo generador más caro.
Por qué hace falta
La búsqueda por embeddings funciona con un bi-encoder: convierte la pregunta en un vector, convierte cada documento en otro vector, y compara por similitud coseno. Rápido, porque los vectores de los documentos se calculan una vez y se guardan.
El problema es que la pregunta y el documento nunca se miran juntos. Cada uno se comprime por separado en unos cientos de números, y luego se comparan esos resúmenes. Se pierden los matices.
Un cross-encoder hace lo contrario: mete la pregunta y el documento en la misma pasada y devuelve una puntuación de relevancia. Al verlos juntos entiende cosas que el bi-encoder no puede: negaciones, condiciones, a qué se refiere un pronombre.
¿Por qué no usar solo cross-encoder? Porque no se puede precalcular nada: habría que pasar la pregunta contra el millón de documentos en cada consulta. Es inviable.
De ahí el reparto: bi-encoder para recuperar 50 candidatos de un millón, cross-encoder para ordenar esos 50 y quedarse con 5.
Ejemplo práctico
En la búsqueda semántica del diccionario de esta web, todo pasa dentro del navegador y son 85 términos: ahí no hace falta reranking, con la similitud coseno directa sobra.
Donde sí lo notamos fue en el asistente del CRM de IMDICA sobre el manual de operaciones y las fichas técnicas, con miles de fragmentos.
Pregunta real: "¿Qué hago si un cliente devuelve material que no es el que pidió?"
Sin reranking, los cinco primeros resultados hablaban todos de devoluciones, pero tres eran de devolución a proveedor, que es un procedimiento distinto. Vectorialmente se parecen muchísimo: mismo vocabulario, mismo dominio, misma forma. El bi-encoder no distingue bien la dirección.
Con un reranker por delante, recuperando 40 candidatos y quedándose con 5, los tres de proveedor bajaron y subieron los de devolución de cliente. El modelo generador recibió el contexto correcto y la respuesta dejó de mezclar procesos.
Lo que aprendimos: el reranking sirve sobre todo cuando tu corpus tiene documentos muy parecidos entre sí que dicen cosas distintas. Si tus documentos son temáticamente dispersos, aporta menos.
Cómo se monta
- Recupera más de lo que necesitas: entre 30 y 100 candidatos en vez de 5.
- Pasa los pares (pregunta, candidato) por el reranker.
- Ordena por la puntuación que devuelve.
- Quédate con los 3-8 mejores para el contexto.
- Opcional pero útil: descarta por umbral. Si ningún candidato pasa de cierta puntuación, es mejor decir "no lo encuentro" que meter contexto irrelevante y provocar una alucinación.
Opciones habituales: Cohere Rerank y Jina Reranker como servicio, o modelos abiertos tipo BGE Reranker y los cross-encoders de sentence-transformers si prefieres no salir de casa.
Errores comunes
- Recuperar 5 y rerankear 5. No sirve de nada: si lo bueno no estaba entre los 5, reordenarlos no lo trae. Recupera ancho, filtra estrecho.
- Rerankear cientos de candidatos. Cada par cuesta tiempo. Pasar de 100 raramente compensa la latencia.
- Ignorar el coste en latencia. Añade entre 100 y 500 ms. En un chat da igual; en un buscador con sugerencias mientras escribes, no.
- Usarlo para tapar un chunking malo. Si tus fragmentos están mal cortados, el reranker ordena basura mejor ordenada.
- No medir si aporta. Como todo, se comprueba con evals. En algunos corpus la mejora es de un punto y no vale la latencia.
Cuándo añadirlo
Sí cuando tienes muchos documentos parecidos entre sí, cuando la precisión importa más que los milisegundos, o cuando ves que la respuesta correcta aparece en el puesto 8 pero no en los 5 que pasas al modelo.
No cuando tu corpus es pequeño y variado, cuando la latencia es crítica, o antes de haber arreglado el chunking. El orden correcto de optimización de un RAG es: primero los fragmentos, después el reranking, y solo entonces el modelo generador.
