Rerank es el rubro de costo más subestimado en una cadena RAG. Una sola llamada parece barata, pero se ejecuta con cada pregunta del usuario; cuando el conjunto de candidatos crece, la factura se multiplica junto con el número de consultas y de documentos.
Las unidades de facturación varían entre proveedores: algunos cobran por consulta, otros por documento y otros por token. Comparar «cuánto cuesta cada llamada» sin más no tiene sentido; hay que convertir el precio a tu volumen de consultas, tu conjunto de candidatos y la longitud de tus documentos. Este artículo desglosa la estructura de facturación, el tamaño del conjunto de candidatos, la caché y la estimación de presupuesto, sin fijar precios unitarios. Los valores concretos se rigen por los precios de modelos del sitio y por la documentación de cada proveedor.
Nota: Cohere, Jina, Voyage y BAAI son marcas de sus respectivos titulares; aquí solo se usan para explicar la estructura técnica y de facturación. Las unidades de facturación, los límites y los precios pueden cambiar; antes de comprar, consulta la página oficial.
1. Qué hace Rerank en la cadena
La recuperación típica de dos etapas es:
Pregunta del usuario
→ Recuperación vectorial o por palabras clave: 20–200 candidatos
→ Rerank: reordenamiento fino y selección de los primeros 5–10
→ Armado del contexto y envío al modelo generativo
La entrada de Rerank es «una consulta + un lote de documentos candidatos»; la salida son puntuaciones de relevancia y un orden, sin generar texto. Resuelve el caso en que el fragmento correcto sí se recuperó, pero quedó en décimo lugar y se pierde al truncar.
Por eso su posición en el costo es clara: se llama una vez por recuperación, a veces varias; cada candidato pasa por el modelo. Reordenar suele ser más barato que cambiar a un modelo generativo más grande, pero no es gratis.
2. Tres formas habituales de facturar
| Unidad de facturación | Unidad | Qué hace crecer el costo | Ejemplos habituales | Qué vigilar en el presupuesto |
|---|---|---|---|---|
| Por consulta | Una consulta con cierta cantidad de documentos | Número de consultas; los documentos largos también se cuentan al fragmentarse | Cohere Rerank | Las reglas de fragmentación multiplican los documentos |
| Por token | Tokens de consulta y de documentos | Longitud de la consulta, cantidad de candidatos, longitud de los documentos | Voyage, Jina y otros | Los tokens de consulta se multiplican por la cantidad de documentos |
| Por documento o por solicitud | Cada documento o cada solicitud | Cantidad de documentos, número de solicitudes | Algunos servicios gestionados | Confirma el truncamiento y el límite por solicitud |
| Autoalojado | Horas de GPU y operación | Concurrencia, tamaño del modelo, utilización | Serie BGE de código abierto | Costo fijo; depende de la utilización |
Cohere factura por search unit, y su página de precios define la unidad como «una consulta con hasta 100 documentos». Sin embargo, los documentos largos se fragmentan y cada fragmento cuenta como documento. Por tanto, «100 documentos» no equivale a «100 documentos facturados»; una base con muchos documentos largos debe estimarse por la cantidad de fragmentos.
Voyage factura por tokens con la fórmula: tokens de consulta × número de documentos + suma de tokens de todos los documentos. Cuanto más larga es la consulta y más candidatos hay, más evidente es el efecto multiplicador. El campo usage.total_tokens de la respuesta sirve para conciliar la factura. Su interfaz admite hasta 1000 documentos por solicitud; las entradas demasiado largas pueden truncarse de forma predeterminada, así que conviene confirmar la regla de truncamiento de antemano.
Jina también factura por tokens totales de entrada, contando consulta y documentos; su documentación indica que las solicitudes fallidas no se cobran y ofrece recarga automática al alcanzar un umbral de saldo. Al agotar la cuota gratuita se pasa a la modalidad de pago; consulta la página de facturación para los detalles.
Autoalojar un modelo de reordenamiento de código abierto, como la serie BGE, elimina el costo por llamada, pero agrega GPU, ancho de banda y operación. Con tráfico estable y a gran escala, el autoalojamiento puede ser más controlable; con tráfico bajo o muy variable, el costo fijo de la GPU suele superar al pago por uso.
3. Cómo definir el conjunto de candidatos
El costo de Rerank crece aproximadamente con la cantidad de documentos candidatos. Reordenar los 200 recuperados cuesta varias veces más que reordenar 50, y la latencia también aumenta.
| Candidatos | Costo relativo | Latencia | Caso de uso |
|---|---|---|---|
| 20–30 | Bajo | Baja | Atención al cliente de alta frecuencia, interfaces sensibles a la latencia |
| Alrededor de 50 | Medio | Media | Punto de partida habitual para bases de conocimiento generales |
| 100 | Alto | Alta | Documentos largos y recuperación con mucho ruido |
| Más de 200 | Muy alto | Muy alta | Optimiza primero la recuperación; no lo uses de entrada |
Conviene empezar con unos 50 candidatos y comparar Recall@k y exactitud de respuestas con un conjunto de evaluación antes de decidir si aumentas o reduces.
Un error frecuente: reducir top_n solo disminuye la cantidad de resultados devueltos y normalmente no reduce los documentos facturados. El ahorro se logra antes de enviar al reordenamiento, no después de recibir la respuesta. Los filtros de metadatos, la deduplicación aproximada, los umbrales de similitud y la limitación del alcance por línea de negocio son más eficaces que truncar al final.
4. Longitud de documentos y fragmentación
Muchas interfaces de reordenamiento imponen un límite de tokens por documento y truncan el excedente. El contenido truncado no participa en la puntuación; puede cortar justamente el párrafo clave y empeorar el resultado.
Si la facturación es por tokens, un documento más largo cuesta más; si es por documento, un documento largo puede dividirse en varios documentos facturables. En ambos casos, la estrategia de fragmentación afecta a la vez la calidad y la factura.
- Envía al reordenamiento solo los fragmentos recuperados, no el documento completo.
- Alinea el tamaño del fragmento con el límite del modelo; no pierdas el título ni el contexto clave.
- Deduplica antes de indexar; los fragmentos casi idénticos no deben facturarse dos veces.
- Registra la distribución de tokens por fragmento y presupuesta con el P95, no con el promedio.
5. Cómo equilibrar latencia y costo
Rerank agrega latencia, y cuanto más candidatos hay, más notoria resulta. El equilibrio no se logra con una regla única, sino por capas según el escenario:
- En preguntas frecuentes de alto volumen puedes omitir el reordenamiento y usar caché o búsqueda por palabras clave.
- En interfaces sensibles a la latencia, limita el número de candidatos y aplica primero filtros de metadatos.
- En tareas fuera de línea sensibles a la calidad y con poca concurrencia, puedes ampliar el conjunto de candidatos.
- Define tiempos de espera y límites de reintentos en el cliente. Reintentar tras un tiempo agotado puede facturar dos veces la misma consulta.
- Evalúa la latencia con P95, no con el promedio.
6. Caché y deduplicación
La caché de Rerank se coloca después de la recuperación y antes de la generación. La clave debe incluir al menos: consulta normalizada, ID y versión de los documentos, nombre del modelo y top_n. Si falta un elemento, puedes reutilizar resultados incorrectos en otro inquilino.
- Preguntas frecuentes: TTL de horas a días.
- Documentos que cambian rápido: TTL de minutos o invalidación activa al actualizar el documento.
- Permisos: la clave de caché debe incluir inquilino y alcance de permisos; nunca debe haber aciertos entre inquilinos.
- Resultados fallidos: no los caches; la caché negativa de TTL corto también requiere cuidado.
- Tareas por lotes: si los mismos documentos se puntúan varias veces el mismo día, puedes reutilizar el resultado.
En escenarios como atención al cliente o preguntas sobre políticas internas, la proporción de preguntas repetidas es alta y el ahorro de la caché suele ser más directo que cambiar a un modelo más barato.
7. Cómo estimar el presupuesto
Primero convierte «cada consulta» a la unidad de facturación del proveedor objetivo y luego multiplica por el volumen de consultas:
Costo mensual ≈ consultas diarias × 30 × unidades facturables por consulta × precio unitario
+ reintentos y margen para picos
Si la facturación es por tokens:
Tokens por consulta = tokens de consulta × número de documentos candidatos + suma de tokens de todos los documentos
Pasos reproducibles para la estimación:
- Obtén de los registros el volumen diario medio y el volumen en hora pico.
- Muestrea 100–200 consultas reales y calcula P50 y P95 de candidatos y de tokens por documento.
- Convierte cada consulta a la unidad de facturación del proveedor.
- Multiplica por el volumen diario y por 30 días; agrega 10%–30% para reintentos, crecimiento y picos.
- Multiplica por el precio unitario vigente de precios de modelos; no uses capturas antiguas.
- Concilia semanalmente tras el lanzamiento y corrige la estimación con la factura real.
# Estimación de costo con facturación por tokens: toma el precio unitario de /pricing
QUERY_TOKENS = 60 # mediana obtenida del muestreo
DOCS_PER_QUERY = 50
AVG_DOC_TOKENS = 180
UNIT_PRICE_PER_MILLION = 0.0 # marcador de posición; reemplázalo por el precio real
def cost_per_query(q_tokens, n_docs, doc_tokens, price):
total_tokens = q_tokens * n_docs + n_docs * doc_tokens
return total_tokens / 1_000_000 * price
per_query = cost_per_query(
QUERY_TOKENS, DOCS_PER_QUERY, AVG_DOC_TOKENS, UNIT_PRICE_PER_MILLION
)
print(f"Costo aproximado por consulta: {per_query:.6f}")
print(f"Costo aproximado para 10 000 consultas diarias: {per_query * 10_000:.2f}")
Los precios unitarios, las cuotas gratuitas y los descuentos por volumen pueden cambiar; el precio del script debe leerse de la página vigente y no codificarse en el repositorio.
8. Conciliación de facturas y alertas
- Separa la facturación por clave, proyecto y línea de negocio; no mezcles todas las llamadas en una sola clave.
- Registra por separado consultas, documentos candidatos, tokens, modelo y latencia.
- Separa el costo de embeddings, Rerank y generación; de lo contrario no sabrás qué etapa optimizar.
- Vigila los reintentos, las consultas vacías, los envíos duplicados desde el frontend y las tareas de reindexación en segundo plano, que suelen causar picos de facturación.
- Configura alertas de presupuesto diario y de saldo; notifica al responsable cuando el saldo baje del umbral.
Los campos de uso que devuelve el proveedor sirven para conciliar; los nombres exactos y su definición se rigen por la documentación de cada uno.
Preguntas frecuentes
¿Rerank conviene más que cambiar a un modelo generativo más grande?
En la mayoría de los casos, sí. El reordenamiento procesa solo decenas de candidatos, su costo es controlable y mejora directamente el problema de «el fragmento correcto quedó en una posición posterior». Pero si la recuperación no encuentra el documento, el reordenamiento no puede rescatarlo: corrige primero la recuperación.
¿Reducir top_n ahorra dinero?
Normalmente no. La facturación suele calcularse sobre los documentos candidatos o los tokens enviados, y top_n solo afecta cuántos resultados se entregan al modelo generativo. Para ahorrar, reduce candidatos, deduplica y filtra antes del reordenamiento.
¿Más documentos candidatos siempre dan mejor resultado?
No necesariamente. Más candidatos significan más ruido, más latencia y más costo. Compara Recall@k y exactitud de respuestas con un conjunto de evaluación para encontrar el punto de rendimiento decreciente; un punto de partida habitual es alrededor de 50.
¿Los documentos largos deben fragmentarse antes?
Sí. La mayoría de las interfaces truncan según un límite de tokens y el excedente no participa en la puntuación; los servicios que cobran por documento también pueden dividir un documento largo en varios documentos facturables. Al fragmentar, conserva títulos y contexto para no cortar la respuesta.
¿Autoalojar Rerank siempre es más barato?
No necesariamente. El autoalojamiento elimina el costo por llamada, pero agrega GPU, despliegue, escalado y operación. Con tráfico estable y alta utilización puede ser más controlable; con tráfico bajo, variable o sin capacidad de operación, una API de pago por uso suele ser más sencilla.
Siguientes pasos
Primero reúne consultas reales y calcula la cantidad de candidatos y la longitud de los documentos; después ejecuta la cadena «recuperación, reordenamiento y generación» con un presupuesto pequeño en ZSQH AI Gateway y compara calidad, latencia y costo con y sin reordenamiento. La disponibilidad de modelos y los precios se rigen por los precios de modelos.
Lecturas relacionadas:
