El error más común al comprar una API de rerank en una empresa es comparar solo "cuánto cuesta cada llamada". El reordenamiento entra en contacto con la consulta y el texto de los documentos, el volumen se multiplica por la cantidad de candidatos y el efecto debe validarse con datos propios. Si solo se mira el precio unitario, es habitual tener que rehacer el trabajo en la etapa de cuota, cumplimiento o aceptación.

Este artículo ofrece una lista que se puede llevar directamente a una reunión y desglosa, punto por punto, volumen, cuota, facturación, privacidad, evaluación, degradación y aceptación. No fijamos precios unitarios ni cuotas; prevalecen la página de precios de modelos y el contrato.

Nota: Cohere, Jina, BAAI, BGE, OpenAI y otros nombres pertenecen a sus respectivos titulares; este artículo no tiene relación de afiliación ni representación con esas organizaciones. Solo se ofrece como discusión de compra y no constituye asesoría legal; las cuotas, los precios y los términos de tratamiento de datos se rigen por el contrato firmado y las páginas oficiales.

1. Tabla general de la lista de compra

Conviene resumir primero los puntos de compra en una tabla y desglosarlos después:

Punto de compra Pregunta a confirmar Material de aceptación
Volumen y cuota Cuota mensual, QPS, candidatos por solicitud, comportamiento al superar el límite Descripción de cuota, registro de pruebas de carga
Facturación y facturas Unidad de cobro, ciclo de liquidación, titular de la factura, tipo de factura Cotización, contrato, ejemplo de factura
Datos y privacidad Retención, entrenamiento, ubicación de almacenamiento, eliminación, subencargados Acuerdo de tratamiento de datos, descripción de seguridad
Efecto Conjunto de evaluación, línea base, métricas, umbral de aceptación Informe de evaluación, registro de regresión
Permisos y auditoría Subcuentas, rotación de claves, registros de llamadas Matriz de permisos, ejemplo de registro
Degradación y SLA Notificación de fallos, canal alternativo, cambios de versión Cláusulas de SLA, registro de simulacros
Monitoreo de costos Panel de uso, alertas de presupuesto, reparto por proyecto Captura del panel, configuración de alertas

2. Primero calcula el volumen, luego discute el precio unitario

El volumen de rerank no es "número de preguntas del usuario", sino el número de consultas multiplicado por la cantidad de documentos candidatos de cada una, y luego por el factor de reintentos:

Volumen diario ≈ consultas diarias × candidatos por consulta × (1 + tasa de reintentos)

Diez mil consultas diarias con 30 candidatos cada una equivalen a trescientas mil puntuaciones de documentos; si se factura por unidad de búsqueda o por token, la longitud de los documentos también infla la factura. Antes de comprar, prepara el promedio diario, el pico de campaña y la previsión de crecimiento a doce meses; estimar con tráfico de demostración suele quedarse corto.

También hay que confirmar la granularidad de facturación: por número de consultas, por cantidad de documentos, por token o como paquete por "búsqueda". Distintos criterios no se pueden comparar directamente; hay que convertirlos al mismo volumen de negocio.

3. Cuota, límites de tasa y comportamiento en picos

Los términos de cuota deben quedar por escrito. Pregunta con precisión:

  • Cuota mensual y anual, y si la cuota de prueba y la de producción están separadas.
  • Si el límite de velocidad se calcula por QPS, por solicitudes por minuto o por concurrencia.
  • Cantidad de candidatos por llamada y longitud máxima por documento.
  • Si al superar el límite se devuelve error, se pasa automáticamente a pago por uso o se detiene el servicio.
  • Si varios proyectos pueden compartir cuota y si se puede fijar un tope por clave.

El "comportamiento al superar el límite" es lo que más se pasa por alto: algunos proveedores devuelven error, otros pasan automáticamente a pospago y la factura puede subir sin aprobación. Conviene exigir alertas de presupuesto y topes estrictos.

4. Facturación, contrato y facturas

El precio de la página web es solo una referencia; al final hay que obtener una cotización formal y un contrato. Confirma:

  • Unidad de cobro, precios escalonados, consumo mínimo o volumen comprometido.
  • Pago anticipado o pospago, ciclo de liquidación y plazo de pago.
  • Titular del contrato, titular de la factura, tipo de factura y tasa impositiva.
  • Si se admite factura especial de IVA y si el contenido coincide con el servicio.
  • Plazo de aviso previo para cambios de precio y si afectan la cuota ya comprada.
  • Reglas de reembolso, tratamiento de la cuota no usada y exportación de datos tras la terminación.

Al usar una gateway de API hay que distinguir a quién se paga, quién emite la factura y quién asume la responsabilidad ante fallos. Los servicios transfronterizos también implican moneda, tipo de cambio e impuestos, por lo que finanzas debe intervenir con antelación.

5. Privacidad de datos y límites de tratamiento

Una solicitud de rerank incluye a la vez la consulta y los documentos candidatos, con una densidad de información que puede ser mayor que la de una conversación normal. Los contratos y documentos internos suelen contener nombres de clientes, precios y datos personales; si salen del país o se conservan durante mucho tiempo, el riesgo se traslada al negocio.

Confirma punto por punto durante la compra:

  • Si se conserva el contenido de las solicitudes, durante cuánto tiempo y para qué.
  • Si se usa para entrenamiento o mejora del servicio y si se puede desactivar por escrito.
  • Ubicación de almacenamiento y copias de seguridad, y ruta de transferencia transfronteriza.
  • Mecanismo de eliminación: si permite borrado masivo por inquilino y en cuánto tiempo surte efecto.
  • Lista de subencargados y notificación de cambios.
  • Cifrado, control de acceso, notificación de incidentes y acuerdo de tratamiento de datos.

Los equipos con datos especialmente sensibles pueden evaluar el autodespliegue abierto: los pesos corren dentro de su propia VPC y los datos no salen de la red interna, a cambio de GPU, operación y actualizaciones. Con un servicio gestionado hay que llevar al contrato "no retención, no entrenamiento, eliminación posible".

6. Evaluación del efecto: conjunto de evaluación y NDCG

El conjunto de evaluación se construye con 100 a 300 consultas extraídas de registros reales, que cubran formas habituales de preguntar, errores de escritura, varios idiomas, documentos largos y casos en los que "la respuesta no está en el material". Cada consulta debe llevar un conjunto de 20 a 50 candidatos de la recuperación en producción, etiquetados como 0 (irrelevante), 1 (relevante) y 2 (respuesta directa).

La métrica principal es NDCG@10, complementada con MRR, tasa de acierto en el top 3, latencia p95 y costo por consulta. También hay que registrar el Recall@k del conjunto de candidatos, porque es el techo del efecto del rerank.

import math

def dcg(rels, k):
    return sum((2 ** r - 1) / math.log2(i + 2) for i, r in enumerate(rels[:k]))

def ndcg_at_k(ranked_rels, k=10):
    ideal = sorted(ranked_rels, reverse=True)
    idcg = dcg(ideal, k)
    return dcg(ranked_rels, k) / idcg if idcg else 0.0

# Completa los niveles de relevancia en el orden posterior al rerank: 2=respuesta directa, 1=relevante, 0=irrelevante
ranked = [2, 0, 1, 0, 0, 1, 0, 0, 0, 0]
print(round(ndcg_at_k(ranked), 4))

El umbral de aceptación no debe copiarse de una lista pública ni aceptarse por una descripción verbal de que "funciona muy bien". El área de negocio y el proveedor deben acordar por escrito antes del piloto: la mejora de NDCG@10 respecto a la línea base, el valor absoluto mínimo, el límite superior de latencia p95 y el límite de tasa de error, con reproducibilidad y regresión comprobables.

7. Permisos, auditoría y gestión de claves

  • Asigna claves independientes por entorno y proyecto; prohíbe compartirlas.
  • Aplica el principio de mínimo privilegio a las claves, admite rotación y revocación, y prohíbe incluirlas en el frontend o en repositorios públicos.
  • Si el proveedor lo permite, configura listas blancas de IP y topes de velocidad por clave para que un proyecto no agote la cuota global.
  • Registra el tiempo de retención, la versión del modelo, la duración, el código de estado y el uso; enmascara los campos de contenido según los requisitos de cumplimiento.
  • La consola debe admitir roles de miembros y auditoría de operaciones, y revocar permisos de inmediato cuando alguien deja la empresa.

Si se usa una gateway unificada, también hay que confirmar su política de registros y su capacidad de subcuentas: una capa más de intermediación añade un responsable más del tratamiento de datos, que debe cubrirse en el contrato y en la revisión.

8. Degradación y continuidad

El rerank es un paso de mejora y no debería convertirse en un punto único de fallo. La propuesta de compra debe indicar:

  • Los códigos de error y el mecanismo de notificación cuando el servicio no está disponible.
  • Si existe un canal alternativo en varias regiones o con varios proveedores.
  • El presupuesto de tiempo de espera y la lógica para volver a la similitud vectorial o al orden por palabras clave cuando se agota.
  • La política de colas, reintentos y cortacircuitos ante límites de tasa, para que una tormenta de reintentos no amplifique la falla.
  • La ventana de migración ante la retirada de un modelo o un cambio de versión.

En ingeniería conviene encapsular el rerank como una interfaz independiente, mantener un interruptor para "desactivar rerank" y hacer simulacros periódicos. Poder revertir con una acción vale más que cualquier promesa.

9. Aceptación del piloto y monitoreo de costos

Se recomienda avanzar por etapas y no firmar un contrato grande a largo plazo desde el principio:

  1. Define el alcance del piloto: línea de negocio, tipos de consulta, tope de volumen diario y criterios de éxito.
  2. Prepara el conjunto de evaluación y la línea base: sin rerank, la solución actual y la candidata deben usar el mismo conjunto de candidatos.
  3. Integra con poco tráfico, ejecuta en paralelo y registra calidad, latencia, tasa de error y uso real.
  4. Organiza una revisión manual y muestrea las diferencias antes y después del orden para confirmar que la mejora no es un sesgo de etiquetado.
  5. Tras pasar la aceptación, firma el contrato formal o amplía la capacidad, y configura alertas de presupuesto y revisión mensual.

Después del lanzamiento, monitorea cuatro cifras: volumen diario, promedio de candidatos, tasa de acierto de caché y costo por línea de negocio. Las optimizaciones incluyen reducir candidatos inútiles, desactivar el rerank para consultas de bajo valor, cachear resultados frecuentes y fijar presupuesto por proyecto. Pasar de 50 a 20 candidatos reduce la factura y la latencia, pero la calidad debe confirmarse con el conjunto de evaluación.

Preguntas frecuentes

¿Cómo se factura normalmente una API de rerank?

Los criterios habituales son número de llamadas, unidades de búsqueda, cantidad de documentos y tokens. Cada proveedor define los suyos, así que hay que convertir al mismo volumen de negocio antes de comparar y guiarse por el contrato y la página de precios de modelos.

¿Se puede usar el crédito de prueba en producción?

La mayoría de los créditos de prueba son solo para evaluación, pueden restringir el uso comercial y no incluyen un SLA de producción. Para el negocio real conviene usar cuota de pago o despliegue privado, y confirmar factura, acuerdo de tratamiento de datos y responsabilidad ante fallos.

¿Qué NDCG se considera aceptable?

No hay un número universal; depende de la calidad de los candidatos, el criterio de etiquetado y la tolerancia del negocio. Es más razonable fijar una meta de mejora respecto a la línea base y confirmar la calidad absoluta con revisión manual.

Si los datos son sensibles, ¿solo queda el despliegue privado?

No necesariamente. Se puede evaluar un servicio gestionado que ofrezca no retención, no entrenamiento, eliminación y un acuerdo de datos; si aún no cumple los requisitos, entonces elegir autodespliegue abierto. Ambos caminos deben considerar el costo total.

¿Una actualización del modelo del proveedor afecta el efecto?

Puede afectarlo. El comportamiento del orden, la escala de puntajes y la latencia pueden cambiar. Al comprar, exige aviso previo de cambios de versión, fija la versión cuando sea posible y conserva un conjunto de regresión para ejecutarlo antes y después de cada actualización.

Siguiente paso

Para integrar la cadena de RAG existente, puedes empezar con un presupuesto pequeño y registrarte en ZSQH AI Gateway para administrar claves, cuota y registros de uso de forma unificada, y luego ejecutar la aceptación del piloto con esta lista. Los modelos y precios se rigen por la página de precios de modelos; las condiciones de compra, por el contrato y la documentación oficial.

Lecturas relacionadas: