Modelos de reranking: Cohere Rerank, BGE-reranker y cross-encoders

Última entrega del bloque de modelos, y de nivel avanzado. En la entrega 16 vimos qué es el reranking y por qué mejora la precisión de los resultados. Aquí toca la decisión concreta: qué modelo poner, cuánta latencia añade, cuánto cuesta y en qué momento deja de compensar.

Recordemos el mecanismo en una frase, porque toda la comparativa depende de él. La búsqueda vectorial usa un bi-encoder: codifica los documentos por separado en el momento de indexar y la consulta en el momento de preguntar, y compara vectores. Es rapidísimo porque el trabajo pesado está hecho de antemano, y es impreciso porque el modelo nunca vio la consulta y el documento juntos. Un cross-encoder hace justo lo contrario: mete el par consulta-documento en la misma entrada y emite una puntuación de relevancia. Es mucho más preciso y no admite precálculo, porque la puntuación depende de la consulta.

De ahí sale el patrón de dos fases: recuperar muchos candidatos rápido con el bi-encoder, reordenarlos despacio con el cross-encoder y quedarse con los mejores. Todo el diseño consiste en elegir bien ese «muchos» y ese «despacio».

Las opciones disponibles

Rerankers comerciales

Cohere Rerank es el más conocido y el que definió la categoría como servicio: le envías la consulta y una lista de documentos, y te devuelve la lista reordenada con puntuaciones. Tiene versiones multilingües, admite documentos largos y no exige infraestructura. Voyage y Jina ofrecen rerankers equivalentes, con el mismo modelo de consumo y de precio.

La estructura de precios de estos servicios no es por token sino por búsqueda, con un número de documentos incluido y un recargo por encima. Es una diferencia importante respecto a los embeddings: el coste no crece con la longitud de tus fragmentos, sino con cuántos candidatos le pases. Eso convierte el tamaño del conjunto de candidatos en la variable económica principal.

Rerankers abiertos

La familia BGE-reranker es la referencia: hay versiones base y large, y variantes multilingües pensadas explícitamente para consultas y documentos en idiomas distintos. Se descargan, se ejecutan en tu GPU y funcionan con la misma interfaz que cualquier cross-encoder de sentence-transformers.

Junto a ellas está el catálogo clásico de cross-encoders entrenados sobre conjuntos de recuperación, que son modelos pequeños, muy rápidos y de calidad razonable, aunque la mayoría orientados al inglés. Y hay una tercera vía, más reciente y más cara: usar un modelo de lenguaje generalista como juez de relevancia, pidiéndole que puntúe cada par. Da buenos resultados y multiplica la latencia y el coste por un factor grande; sólo tiene sentido en escenarios de bajo volumen y alta exigencia.

La tabla de compromisos

Las cifras de latencia son órdenes de magnitud para un conjunto de candidatos de tamaño medio, y dependen mucho del hardware, del tamaño de los fragmentos y de si el lote se procesa junto o en serie.

La aritmética del número de candidatos

Esta es la parte que hay que entender bien, porque es donde se decide todo.

Un cross-encoder puntúa un par cada vez. Si recuperas 100 candidatos, el modelo hace 100 pasadas completas, no una. El coste y la latencia del reranking son por tanto lineales en el número de candidatos, mientras que el coste de la búsqueda vectorial es prácticamente insensible a si pides 20 o 200: el índice ya está construido y devolver más vecinos apenas cambia nada.

La consecuencia es una asimetría útil. Ampliar el conjunto de candidatos es casi gratis en la primera fase y caro en la segunda. Todo el ajuste consiste en encontrar el número a partir del cual ampliar deja de aportar documentos relevantes nuevos.

Y ese número se puede calcular con datos propios en lugar de adivinarlo. Con el conjunto de evaluación de la entrega 25 —preguntas con el fragmento correcto marcado a mano— se mide el recall del recuperador base para distintos valores de k: en qué proporción de preguntas el fragmento correcto aparece entre los k primeros. Si el recall a 50 candidatos es prácticamente el mismo que a 200, recuperar 200 sólo multiplica por cuatro el coste del reranking sin ninguna ganancia posible: el reranker no puede colocar arriba un documento que la primera fase nunca trajo. Ese punto donde la curva de recall se aplana es el tamaño correcto del conjunto de candidatos, y en la mayoría de corpus está bastante por debajo de lo que la gente usa por defecto.

El segundo parámetro es cuántos documentos pasan al generador después de reordenar. Aquí manda el efecto de «perdido en el medio»: pasar más fragmentos de los necesarios no sólo encarece la generación, sino que puede empeorar la respuesta. Un reranker bueno permite reducir ese número, y ahí está buena parte de su rentabilidad: si reordenando puedes pasar cinco fragmentos en vez de diez sin perder calidad, el ahorro en la generación puede compensar el gasto del reranking.

Rerankers multilingües

Todo lo dicho en la entrega 25 sobre embeddings vale igual aquí, con un matiz a favor. Un cross-encoder ve la consulta y el documento juntos, lo que le da más información para juzgar la correspondencia entre idiomas que la que tiene un bi-encoder comparando vectores calculados por separado. En corpus mezclados, un reranker multilingüe compensa parcialmente un recuperador base con alineamiento mediocre.

Parcialmente, y conviene subrayarlo: sigue sin poder rescatar lo que la primera fase no recuperó. Si el recuperador base no trae el documento inglés relevante entre los candidatos, ningún reranker lo colocará arriba. El reranking mejora la precisión, no el recall.

Cuándo deja de compensar

Hay cuatro situaciones en que el reranking no paga, y merece la pena reconocerlas antes de montarlo.

• Cuando el recall base ya es muy alto y las consultas son sencillas. Si el fragmento correcto sale casi siempre en las tres primeras posiciones, reordenar no tiene margen de mejora: sólo añade latencia.
• Cuando el problema real es de recall. Si el documento correcto no está entre los candidatos, el reranking es irrelevante. El arreglo está en el troceado, en los metadatos o en la búsqueda híbrida, no aquí. Es el error de diagnóstico más común con esta técnica.
• Cuando el presupuesto de latencia es estricto. En un autocompletado o en una búsqueda que responde mientras el usuario escribe, unos cientos de milisegundos son inaceptables. En un asistente conversacional con respuesta en streaming, son invisibles frente al tiempo de generación.
• Cuando el volumen de consultas es muy alto y el valor por consulta bajo. El reranking multiplica el coste por consulta; si la consulta vale poco, no se amortiza.

Recomendación por escenario

• Prototipo o volumen bajo. Reranker comercial por API. Se integra en una tarde, no hay infraestructura y el coste a ese volumen es despreciable. Conjunto de candidatos moderado, del orden de unas decenas.
• Producción con volumen medio y corpus en español o mixto. BGE-reranker multilingüe autoalojado, compartiendo GPU con el servidor de embeddings de la entrega 24. Es el punto dulce de esta tabla para la mayoría de proyectos.
• Latencia crítica. Cross-encoder pequeño autoalojado sobre un conjunto de candidatos reducido, o directamente sin reranking si la evaluación dice que el recall base basta.
• Alta exigencia y volumen bajo. Dominios jurídicos, médicos o de cumplimiento normativo donde un error cuesta caro: reranker fuerte con conjunto amplio, y valorar un modelo de lenguaje como juez en las consultas que el sistema marque como difíciles.

Límites

El reranking es una de las técnicas con mejor relación entre esfuerzo y mejora de todo el catálogo, y precisamente por eso se aplica a veces como un ritual, sin medir. Dos avisos finales. El primero, ya dicho pero decisivo: el reranking sube la precisión y no el recall; si tu problema es que no encuentras, esto no lo arregla. El segundo: introduce una pieza más en el camino crítico, con su propia disponibilidad y sus propios fallos, y conviene diseñarlo para degradar con elegancia —si el reranker no responde, se sirve el orden original en lugar de devolver un error.

Qué viene ahora

Con esta entrega se cierra el bloque cuarto. Hemos recorrido los criterios para elegir embeddings, los proveedores comerciales y las familias abiertas, el caso concreto del español, el modelo generador y los rerankers. Todas las piezas de modelo del pipeline están sobre la mesa.

El bloque quinto cambia de plano y se ocupa de la plataforma: dónde viven los vectores y quién coordina el flujo. Empezamos por las bases de datos vectoriales —cómo elegir una, pgvector dentro de PostgreSQL, los motores dedicados de código abierto, los servicios gestionados y las opciones para prototipar sin infraestructura— y terminamos con los orquestadores y con la pregunta de si hace falta alguno.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.