Optimizar costo y latencia y monitorear calidad, no solo disponibilidad

Todas las noches se clasifican doscientos mil tickets con llamadas en tiempo real al modelo más grande, y el costo crece más rápido que el volumen. En otro equipo, el tablero del asistente de reclamos está todo en verde mientras los pases a una persona suben semana a semana y algunas respuestas terminan a mitad de frase. Son dos caras del mismo tema: saber qué palanca mover y qué medir para enterarte a tiempo.

Cada palanca ataca otra cosa

Palanca	Qué baja	Cuándo usarla
Procesamiento por lotes (Message Batches API)	costo, y suma capacidad	trabajos que no necesitan respuesta inmediata: clasificación nocturna, informes, evaluaciones
Caché de prompts (prompt caching)	costo y tiempo hasta el primer token del prefijo repetido	un system prompt, documentos o definiciones de herramientas que se repiten en cada pedido
Ruteo por complejidad (complexity-based routing)	costo y latencia	cuando la mayoría de los pedidos son simples y la evaluación muestra que un modelo más chico alcanza para ellos
Recortar contexto y salida	tokens	solo con evaluación: sacar lo que el modelo no usa, no lo que necesita
Streaming	la latencia percibida	interfaces interactivas; no baja el costo ni el tiempo total

Dos reglas para el examen. Primero, la API de lotes es asíncrona: la mayoría de los lotes termina rápido, pero no hay respuesta al instante, así que no sirve para un chat. Segundo, toda optimización que puede tocar la calidad (modelo más chico, contexto recortado) se vuelve a correr contra la suite de evaluación antes de lanzarse. La caché tiene una ventaja extra: en la mayoría de los modelos, los tokens leídos de la caché no cuentan para el límite de tokens de entrada por minuto, así que además libera capacidad.

Disponibilidad no es calidad

Un agente puede responder siempre, rápido y sin errores HTTP, y aun así resolver cada vez peor. La disponibilidad (uptime) y la calidad son señales distintas y necesitan tableros distintos:

• Operación: disponibilidad, errores, latencia p50 y p95, uso de límites de tasa.
• Calidad: tareas completadas, tasa de derivación a una persona, feedback de usuarios, rechazos, todo por flujo o segmento.
• Costo: costo por transacción, tasa de aciertos de caché, tokens por pedido.

Una respuesta cortada por max_tokens es, para la API, una respuesta exitosa: no aparece como error. Solo la ves si registrás el motivo de corte.

Qué registrar

Para diagnosticar a escala, cada pedido deja trazas estructuradas (structured traces), no solo la respuesta final:

• cada llamada al modelo y a herramientas, en orden, con su resultado;
• tokens de entrada, de salida y de caché, y latencia por paso;
• stop_reason, versión del prompt, modelo y flujo;
• un ID de pedido que conecte todo, sin datos personales en claro.

Sobre eso se arman alertas por comportamiento: la proporción de cortes por max_tokens, la tasa de derivación o el costo por transacción que salen de su rango habitual. Guardar transcripciones completas en modo debug “por las dudas” llena los logs de datos sensibles y no avisa nada.

Las trampas típicas

• Activar streaming para bajar el costo de un proceso nocturno.
• Sumar workers y reintentos para terminar antes de chocar con los límites de tasa.
• Recortar cada entrada a los primeros tokens sin volver a evaluar.
• Subir la meta de disponibilidad cuando el problema es que el agente resuelve peor.
• Depender de que alguien del equipo avise por mail cuando “algo raro” pasa.

En el examen

Si nadie necesita el resultado en el momento, buscá la API de lotes, idealmente combinada con probar un modelo más chico sobre una muestra etiquetada. Si el pedido repite un prefijo largo y fijo, buscá la caché. Si el tablero está verde y los usuarios se quejan, buscá la opción que suma métricas de calidad separadas de la disponibilidad y alertas sobre señales de comportamiento como el motivo de corte o la tasa de derivación.