El rerank o reordenamiento ocupa el último tramo de la cadena de recuperación: primero se recuperan decenas o cientos de candidatos mediante búsqueda vectorial o híbrida, después un cross-encoder calcula la relevancia entre la consulta y cada documento, y coloca al frente los fragmentos realmente útiles. No genera texto, pero corrige de forma notable el problema de "la respuesta está en el décimo lugar".

Sin embargo, no existe una única forma correcta de implementar rerank. Una API gestionada, un modelo de pesos abiertos y la capacidad integrada de una base vectorial pueden funcionar; las diferencias están en la calidad, la latencia, la cobertura de idiomas, la privacidad, el costo y la operación. Este artículo separa el análisis en seis dimensiones y termina con una tabla de escenarios y una lista de migración. Los modelos y precios concretos se rigen por la página de precios de modelos.

Nota: Cohere, Jina, Voyage, Qwen, BGE, Weaviate, Milvus y Elasticsearch son marcas de sus respectivos titulares; este artículo solo las menciona con fines técnicos. Las capacidades, los límites y los términos de cada producto cambian, así que conviene verificar la documentación del proveedor antes de integrarlo.

1. Primero confirma que el cuello de botella está en el rerank

No todos los problemas de RAG justifican añadir una etapa de rerank. Revisa tres señales: el fragmento correcto se recupera pero suele quedar después del quinto puesto; tras la búsqueda híbrida los primeros resultados contienen ruido evidente y la coincidencia de palabras clave domina sobre la relevancia semántica; la respuesta generada cita el pasaje equivocado, y al sustituirlo manualmente por el correcto la respuesta acierta.

Si el fragmento correcto no está en el conjunto recuperado, el rerank no puede hacer nada: primero hay que ajustar la fragmentación, el embedding o la cantidad recuperada. Si solo hay tres o cinco candidatos, la ganancia también es limitada. En la práctica, el rerank rinde mejor con conjuntos de veinte a doscientos candidatos; por encima de varios cientos, la latencia y el costo crecen rápido.

2. Qué es cada una de las tres rutas

API de rerank gestionada: el proveedor empaqueta el modelo y la inferencia como una interfaz; normalmente recibe query, documents y top_n, y devuelve índices y puntajes ordenados por relevancia. Sus ventajas son la integración rápida, una cobertura multilingüe por lo general buena y la ausencia de GPU propia; sus desventajas son que los datos salen de la red, la dependencia de los límites y del formato del proveedor, y un costo que crece con el volumen de llamadas.

Cross-encoder de pesos abiertos: el modelo se despliega en una GPU propia o en un servicio de inferencia. Las opciones habituales incluyen la familia BGE reranker, Qwen3-Reranker y Jina Reranker. La ventaja es que los datos no salen de la red interna, se puede ajustar el modelo y fijar la versión; la desventaja es asumir la GPU, el escalado, las actualizaciones y el mantenimiento del framework de inferencia. Frameworks como vLLM y TEI ya ofrecen interfaces de rerank y reducen parte del trabajo de adaptación.

Rerank integrado en la base vectorial: algunas bases vectoriales ofrecen una capacidad de rerank propia o integrada, por ejemplo el módulo rerank de Weaviate, el rerank retriever de Elasticsearch o la función rerank de versiones recientes de Milvus; otros productos solo recuperan y delegan el rerank a un servicio externo. La ventaja es evitar un salto de red y unificar permisos y operación; la desventaja es que la selección de modelo queda limitada por el producto y el margen de personalización es menor.

Conviene tener presente que rerank no cuenta con un estándar compatible con OpenAI como Chat Completions. Las familias Jina, Cohere y Voyage no usan exactamente los mismos campos: top_n frente a top_k, si se devuelve el cuerpo del documento, parámetros de truncado distintos; el endpoint puede ser /v1/rerank o /v2/rerank. Al cambiar de proveedor, la adaptación del protocolo suele llevar más tiempo que el cambio de modelo en sí.

3. Cómo comparar las seis dimensiones

En calidad, tanto una API gestionada como un modelo abierto pueden ser cross-encoders; la diferencia está más en los datos de entrenamiento, la distribución de idiomas y la versión. No te guíes solo por las listas públicas: evalúa con tus propias consultas de negocio y tu conjunto de candidatos. Si la capacidad integrada de la base vectorial usa modelos de la misma clase, el resultado suele ser parecido, pero hay menos parámetros ajustables.

En latencia, el tiempo de rerank crece aproximadamente con "número de candidatos por longitud del documento". Una API gestionada añade un viaje de ida y vuelta por internet y encaja en escenarios con pocos candidatos y concurrencia estable; el autodespliegue elimina una dependencia externa pero debe gestionar colas de GPU; la opción integrada evita el salto de red, aunque puede competir por los mismos recursos que la recuperación.

En cobertura de idiomas, hay que analizar por separado el chino, la mezcla de chino e inglés y las lenguas minoritarias. Muchos modelos se parecen en las listas en inglés, pero las diferencias se amplían con documentos largos y terminología sectorial. Conviene preparar tres conjuntos de evaluación: chino, inglés y mixto.

En privacidad, basta con que los documentos salgan de tu red para que debas evaluar los términos de datos, el cifrado en tránsito, la retención de registros y la ruta transfronteriza. Los contratos, los datos de clientes y los textos médicos o financieros suelen exigir autodespliegue o despliegue privado.

En costo, el servicio gestionado cobra por llamada o por token, de modo que el gasto tiende a crecer de forma lineal; el autodespliegue suma costo fijo de GPU y personal, y no siempre resulta más barato con poco volumen; la opción integrada puede venir incluida en el plan de la base de datos o cobrarse por inferencia. Hay que incluir en el cálculo los reintentos, la evaluación offline y la capacidad extra en los picos.

En operación, el servicio gestionado delega las actualizaciones y el escalado al proveedor, pero tú administras las claves, los límites y las diferencias entre proveedores; el autodespliegue requiere personal que cuide las GPU y que gestione las actualizaciones de controladores y frameworks; la opción integrada une dos sistemas en uno y concentra también los fallos.

4. Selección por escenario

Escenario Ruta sugerida Motivo Punto de atención
Validación rápida, decenas de candidatos API de rerank gestionada Integración el mismo día, sin GPU Confirmar primero si los datos pueden salir de la red
Mayoría en chino, datos sensibles Autodespliegue abierto Permite despliegue privado y modelos fuertes en chino Reservar GPU y personal de operación
Ya usas una base vectorial y la necesidad es simple Rerank integrado en la base Una integración menos, permisos unificados Confirmar que el modelo y los parámetros alcanzan
Alta concurrencia, latencia sensible Autodespliegue o integrado en la misma región Evita la ida y vuelta por internet y las colas Hacer pruebas de carga, no mirar solo el promedio
Multilingüe, lenguas minoritarias API gestionada o modelo abierto multilingüe fuerte La cobertura de idiomas ahorra trabajo Validar con un conjunto de evaluación en idiomas minoritarios
Volumen muy bajo, equipo sin GPU API gestionada Costo fijo más bajo Configurar alertas de presupuesto y límites

Esta tabla es solo un punto de partida. Un mismo equipo también puede combinar rutas: una API gestionada como respaldo en producción, el autodespliegue abierto para la evaluación offline y el rerank integrado solo para cargas de bajo riesgo.

5. Cómo evaluar la calidad sin improvisar

Prepara al menos tres elementos: un lote de consultas reales, la etiqueta del documento correcto para cada consulta y el conjunto de recuperación actual. Usa métricas como Recall@k, MRR o nDCG, y no te limites a la impresión de que "parece más relevante". Exporta los mismos candidatos antes y después del rerank, revisa manualmente los primeros diez y registra el tipo de error: si falta recuperación, si la fragmentación rompió el texto o si el rerank hundió el pasaje correcto.

El siguiente fragmento de Python hace una sola cosa: comparar si el documento correcto entra en los primeros k puestos antes y después del rerank. No depende de ningún proveedor; recibe dos listas de índices ya ordenadas.

def hit_rate(cases, k):
    hits = 0
    for gold, ranked in cases:
        if gold in ranked[:k]:
            hits += 1
    return hits / len(cases)

# cases: [(índice del documento correcto, lista de índices tras el rerank), ...]
before = hit_rate(baseline_cases, 5)
after = hit_rate(reranked_cases, 5)
print(f"Recall@5: {before:.3f} -> {after:.3f}")

Se recomienda una muestra de al menos cien casos, que cubra distintas líneas de negocio y longitudes de documento. Antes de lanzar, revisa también la latencia p95 y el costo por llamada; no uses el promedio para ocultar la cola larga.

6. Lista de migración

Para pasar de una API de rerank a otra, o de un servicio gestionado al autodespliegue, sigue este orden:

  1. Fija el conjunto de evaluación y la línea base actual; registra Recall@k, MRR, latencia p95 y costo por llamada.
  2. Confirma la ruta del endpoint, el método de autenticación y los campos de la solicitud del nuevo esquema; revisa sobre todo top_n frente a top_k, si se devuelve el cuerpo del documento y los parámetros de truncado.
  3. Alinea la semántica de los puntajes: si es un puntaje de relevancia entre cero y uno o un logit sin normalizar, y si el orden es ascendente o descendente. No mezcles umbrales directamente.
  4. Verifica los límites de documentos por llamada, tokens por documento, tamaño del cuerpo y concurrencia; si se superan, divide en el cliente en lugar de esperar el error de la interfaz.
  5. Implementa reintentos y degradación para tiempos de espera, 429 y 5xx; al degradar, conserva el orden de recuperación original para que la cadena no falle por completo.
  6. Compara los resultados nuevos y antiguos con tráfico en espejo durante al menos una semana; registra las diferencias de orden y los cambios en la calidad de las respuestas.
  7. Despliega de forma gradual y define umbrales de reversión, por ejemplo volver atrás si la tasa de error o la p95 supera la línea base en cierta proporción.
  8. Actualiza el monitoreo y la conciliación de facturación; confirma que los reintentos, la caché y la evaluación offline no queden fuera del cálculo.

Preguntas frecuentes

¿En qué se diferencia una API de rerank de una API de embeddings?

Un embedding convierte el texto en vectores y se usa para recuperación a gran escala; el rerank lee la consulta y cada documento, tiene mayor precisión pero es más lento. Lo habitual es recuperar primero decenas o cientos de candidatos y luego reordenar los primeros puestos.

¿Un modelo de rerank abierto siempre es más barato que una API gestionada?

No necesariamente. Con poco volumen, el costo fijo de la GPU y el personal de operación suelen superar el pago por uso; con volumen alto, datos sensibles o necesidades de personalización, el autodespliegue amortiza mejor el costo. Hay que incluir la capacidad extra para los picos.

¿Basta con el rerank que trae la base vectorial?

Depende del escenario. Si el conjunto de candidatos no es grande y no hay requisitos especiales de selección de modelo, la capacidad integrada ahorra una integración; si necesitas un idioma concreto, ajuste fino de dominio o un control de parámetros más fino, un servicio de rerank independiente ofrece más flexibilidad.

¿Cómo elegir un modelo de rerank para chino?

Primero verifica si el modelo declara soporte de chino o de varios idiomas, y después evalúa con tus propias consultas y documentos en chino. No sustituyas la evaluación por el puesto en una lista en inglés. La mezcla de chino e inglés, los documentos largos y la terminología sectorial deben muestrearse por separado.

¿Hay que recalibrar los umbrales de puntaje al cambiar de servicio de rerank?

Normalmente sí. Cada modelo tiene una distribución de puntajes distinta: algunos normalizan entre cero y uno y otros devuelven logits. Los escenarios que filtran con un umbral fijo deben recalibrarse o pasar a usar la posición en el ranking en lugar del puntaje absoluto.

Siguiente paso

Si solo quieres poner la cadena en marcha, puedes crear una clave de prueba en ZSQH AI Gateway y comparar la calidad de recuperación antes y después del rerank con el mismo lote de consultas; después estima el costo con la página de precios de modelos. La disponibilidad de modelos y el criterio de facturación se rigen por la página de precios.

Lecturas relacionadas: