Un relay de API de rerank parece limitarse a "reenviar la solicitud al proveedor upstream", pero el reordenamiento ocupa un lugar crítico en la cadena de búsqueda: si tarda cien milisegundos de más, el usuario lo percibe; si su unidad de facturación no es transparente, la conciliación de fin de mes falla; si la versión del modelo cambia sin aviso, la calidad del orden también se desplaza.
Este artículo trata las formas habituales de relay y proxy, el impacto en la latencia, la verificación de la facturación y los pasos de migración, para ayudar al equipo a equilibrar "salir rápido" y "mantener a largo plazo". Los modelos y precios concretos se rigen por la documentación de cada proveedor y por la página de precios de modelos.
Nota: Cohere, Jina AI y otros nombres son marcas de sus respectivos titulares; este artículo no tiene relación de afiliación con esas empresas. El mercado de relays cambia con rapidez; lo aquí descrito son formas comunes en 2026 y no constituye un respaldo de ningún proveedor.
1. Un relay de rerank no es lo mismo que un relay de chat
Los principales problemas de un relay de API de chat son la salida en streaming, la longitud del contexto y la concurrencia; los de un relay de rerank son la latencia síncrona, la cantidad de documentos y el criterio de facturación. Una solicitud de reordenamiento suele ser corta, pero es extremadamente sensible a la p95; una sola llamada puede llevar decenas de documentos y el costo crece con "cantidad por longitud"; la respuesta solo contiene índices y puntajes, así que cuando algo falla es difícil saber desde la propia respuesta quién es el upstream.
Hay otro punto que se pasa por alto con facilidad: rerank no tiene un estándar compatible con OpenAI. La ruta de Cohere es /v2/rerank, la de Jina es /v1/rerank, y los nombres de campo y los rangos de puntaje también pueden diferir. Si el relay hace conversión de protocolo, hay que confirmar que el comportamiento convertido coincide con el del upstream, sobre todo la política de truncado y la semántica de top_n.
2. Cuatro formas habituales de relay
| Forma | Control | Origen de la latencia | Transparencia de facturación | Titularidad de la clave | Escenario adecuado |
|---|---|---|---|---|---|
| Estación de relay comercial | Bajo, depende del proveedor | Enrutamiento del relay + enlace transfronterizo | Depende de si ofrece detalle de llamadas | El proveedor tiene la clave upstream | Validación rápida, poco tráfico |
| Proxy inverso propio | Alto, operado por uno mismo | Región del servidor + enlace al upstream | La factura del upstream es visible directamente | Propia | Equipos con capacidad de operación |
| Gateway de región en la nube | Medio, limitado por el producto cloud | Las llamadas en la misma región suelen ser más cortas | La factura cloud se puede desglosar | Propia o de la cuenta cloud | Ya desplegado en la misma nube |
| Gateway de IA unificado | Medio alto, admite varios upstream | Región del gateway + enrutamiento al upstream | Factura unificada, hay que revisar multiplicadores | Del gateway o propia | Varios modelos, varios proyectos |
Un proxy propio no equivale a ausencia de riesgos: servidor, certificados, reintentos y limitación de tasa corren por tu cuenta, y la responsabilidad de cumplimiento de la cuenta upstream también recae en ti. El relay comercial ahorra operación, no la responsabilidad de elegir bien.
3. Cómo afecta la latencia a la búsqueda
Primero traza un presupuesto de extremo a extremo: recuperación, rerank, generación y red. El incremento del reordenamiento debería mantenerse dentro de unos cientos de milisegundos; de lo contrario, el usuario siente que la búsqueda "se trabó". La documentación de Jina ofrece como referencia unos 150 ms para 100 documentos de unos 256 tokens con una consulta de 64 tokens; con documentos de 4096 tokens sube a varios segundos. Cohere recomienda no superar los 1000 documentos por llamada. Un relay añade un salto más: RTT, colas y, posiblemente, costo de conversión de protocolo.
Las medidas para reducir la latencia, ordenadas por relación costo-beneficio, son: reducir la cantidad de documentos candidatos, acortar la longitud de cada documento, fijar un top_n pequeño, acercar el nodo del relay a la región del negocio y reutilizar conexiones. Si el nodo del relay y el upstream están en regiones distintas, el RTT transfronterizo puede ser mayor que la propia inferencia del modelo. En escenarios de búsqueda que se actualiza mientras el usuario escribe, se puede mover el rerank a una segunda solicitud o reordenar solo los primeros 20 a 50 candidatos.
Al medir, hay que distinguir entre "tiempo de respuesta del relay" y "tiempo de búsqueda de extremo a extremo". Un buen número en el primero no implica un buen número en el segundo, porque los reintentos, el DNS, el handshake TLS y las colas pueden quedar ocultos por el promedio.
4. Transparencia de facturación: tres criterios que deben coincidir
Rerank suele facturarse de tres maneras: por número de solicitudes, por cantidad de documentos o search unit, y por tokens de entrada. Con el mismo volumen de negocio, la factura puede diferir mucho según el criterio. Los detalles que hay que confirmar incluyen: si top_n afecta el cobro, cómo se facturan los documentos truncados, si las solicitudes fallidas se cobran, si los aciertos de caché reciben descuento, si hay consumo mínimo y si el multiplicador está incluido en el precio unitario.
El método más eficaz es un experimento de conciliación: prepara un lote fijo de solicitudes, envíalas por conexión directa y por relay, y registra el número de llamadas, documentos, tokens y el cargo real. Si el relay solo entrega un saldo total y no el detalle de cada llamada, después será muy difícil investigar "por qué subió este mes". En compras empresariales también hay que confirmar el titular de la factura, el momento de emisión y las reglas de reembolso, para que el saldo prepagado no se convierta en un costo hundido.
5. Riesgos de claves y de datos
Los relays comerciales suelen usar una clave upstream compartida. La ventaja es la activación rápida; el precio es que no controlas los límites, la versión del modelo ni el riesgo de bloqueo de la cuenta upstream: si el upstream cambia su política, todos los inquilinos se ven afectados a la vez. Un proxy propio, en cambio, asume el riesgo de fuga de claves, abuso y facturación fuera de control.
Las solicitudes de reordenamiento llevan la consulta y fragmentos de documentos, que pueden incluir datos de clientes, cláusulas de contratos o contenido de la base de conocimiento interna. Antes de contratar hay que preguntar con claridad: si las solicitudes se registran, cuánto tiempo se conservan, si se usan para entrenamiento, en qué región se almacenan los datos y cuál es el mecanismo de eliminación. Para negocios sensibles, conviene elegir un proveedor dispuesto a firmar términos de tratamiento de datos o desplegar el modelo de rerank en el propio entorno.
Además, hay que desconfiar de expresiones vagas como "colaboramos con el fabricante". Si existe un permiso formal o una condición de cliente empresarial, debe verificarse en el contrato y en credenciales comprobables, no solo en la página promocional.
6. Lista de migración
- Inventaria las llamadas actuales: ruta de la interfaz, modelo, número de candidatos, tiempos de espera y configuración de reintentos.
- Guarda una línea base: registra el orden de resultados, la latencia p95 y la tasa de error con un lote de consultas reales.
- Abstrae el cliente: coloca URL, clave y nombre del modelo en configuración, para que no queden dispersos en el código de negocio.
- Ejecuta en paralelo: envía el mismo lote de solicitudes por el servicio original y por el nuevo relay, y compara orden y métricas de calidad.
- Calibra los puntajes: cada modelo tiene una distribución distinta; no reutilices los umbrales antiguos sin revisarlos.
- Despliega de forma gradual: empieza con 5% a 10% del tráfico y observa las métricas de búsqueda y la facturación.
- Verifica la degradación: confirma que ante tiempos de espera, 429 o 5xx se pueda volver al servicio original o al orden de recuperación original.
- Conserva una ventana de reversión: mantén la configuración y la clave antiguas durante al menos un ciclo de facturación completo.
El paso que más errores causa en una migración es el quinto. El puntaje de rerank solo expresa el orden relativo dentro del mismo conjunto de candidatos y no es comparable entre modelos; la versión del modelo, la longitud de truncado y si se envían documentos estructurados cambian el resultado.
7. Cómo verificar un relay
Primero haz una revisión estática: ruta de la interfaz, método de autenticación, si el nombre del modelo se puede fijar, si la respuesta incluye index y relevance_score, y si el rango de puntajes coincide con la documentación. Después realiza pruebas dinámicas: compara con el mismo payload el orden obtenido por conexión directa y por relay, y registra p50/p95, tasa de error y activación de 429. Por último, concilia la facturación y confirma que el detalle de llamadas cuadra.
A continuación aparece un script mínimo de prueba de latencia; lo importante es usar documentos con longitud real, no texto de relleno de longitud uniforme:
import statistics, time, requests
URL = "https://<relay-host>/v1/rerank"
HEADERS = {"Authorization": "Bearer <key>"}
PAYLOAD = {
"model": "<model>",
"query": "¿Cuál es la política de devoluciones?",
"documents": ["Aquí va un fragmento de longitud real " + str(i) for i in range(50)],
"top_n": 5,
}
latencies = []
for _ in range(30):
start = time.perf_counter()
resp = requests.post(URL, json=PAYLOAD, headers=HEADERS, timeout=3)
resp.raise_for_status()
latencies.append((time.perf_counter() - start) * 1000)
latencies.sort()
print("p50", statistics.median(latencies))
print("p95", latencies[int(len(latencies) * 0.95) - 1])
Si el relay no puede ofrecer un número de versión de modelo estable ni registros de llamadas, conviene usarlo solo para negocios no críticos. En producción hay que mantener una ruta alternativa conmutable y volver a medir de forma periódica. Los equipos que planean integrar varios proveedores pueden consultar primero el catálogo de interfaces actual en el registro y después estimar el presupuesto con la página de precios de modelos.
8. Preguntas frecuentes
¿Cuánto más lento es un relay que una conexión directa?
Depende de la ubicación del nodo y del enrutamiento. Un relay en la misma región puede añadir solo unos milisegundos; un salto transfronterizo puede sumar decenas o cientos de milisegundos. Hay que medir la p95 con solicitudes reales, no confiar solo en el promedio que ofrece el proveedor.
¿Por qué no coincide la factura del relay con la del upstream?
La causa habitual es un criterio de facturación distinto: por solicitud, por documento, por token, o con multiplicadores, consumo mínimo y solicitudes fallidas incluidos. Antes de contratar, pide la fórmula de cálculo y un ejemplo de detalle de llamadas.
¿Es normal que cambie el orden de resultados tras cambiar de relay?
Es normal. La versión del modelo, la longitud de truncado, el tratamiento de documentos estructurados y la normalización de puntajes pueden ser distintos. Hay que comparar con el mismo lote de consultas y recalibrar los umbrales del negocio.
¿Qué hacer si el servicio de relay deja de operar?
Hay que anticipar dos cosas: abstraer el cliente en una configuración conmutable y conservar una ruta alternativa por conexión directa o con otro proveedor; y no cargar todo el presupuesto de una vez en un solo relay.
¿Un proxy inverso propio cuenta como relay?
Cuenta como relay en sentido técnico. Te permite controlar la clave y los registros, pero asumes el servidor, los certificados, la limitación de tasa, el cumplimiento y la responsabilidad de la cuenta upstream.
