El caso medio bajó. La cola desapareció. Ahora cada ejecución cae en una banda estrecha — se acabaron los picos imprevisibles de 12–14 turnos.
Los contratistas hacen pedidos de hormigón desde el terreno. No van a esperar un chat pausado de 12 turnos para programar un camión. La latencia de punta a punta importa, pero la forma de esa latencia importa más: un promedio que cae en cuarenta y cinco segundos es tolerable, un promedio con una cola larga en setenta y cinco segundos es un riesgo de churn.
Las trazas previas al proyecto mostraban exactamente lo segundo. La mayoría de los happy paths caían en diez turnos y unos cuarenta segundos de wall-clock. Pero una minoría relevante saltaba a doce o catorce turnos porque el modelo inventaba un ID de pedido que el UI no podía pulsar, o se saltaba el render de un botón obligatorio, o preguntaba algo que el flujo ya había respondido. Eran diez a quince segundos extra de arrastre imprevisible, y los contratistas los recordaban.
El mismo trabajo estructural que recortó el coste de tokens también colapsó la varianza de latencia. El principio unificador: quitar trabajo que el LLM no debería estar haciendo, y los modos de fallo que venían con él desaparecen.
El titular no es un único número — es el colapso de la varianza. Cada ejecución reciente cae aproximadamente en la misma banda de latencia, y las trazas de cola que solían saltar al rango de los setenta-y-pico segundos dejaron de ocurrir.
El wall-clock vino de la capa de orquestación, por turno, sumado por trace. Ejecutamos trazas happy-path cara a cara contra el mismo backend de staging el mismo día para controlar la varianza de red. Más importante aún, vigilamos la cola: en una ventana de dos semanas de trazas de producción tras aterrizar el conjunto de cambios, buscamos incidentes de IDs inventados y ejecuciones que superaran los doce turnos. La clase de comportamiento de cola en torno a la que construimos el proyecto no volvió.
Esta es la parte que vale la pena destacar para cualquier operador que lea esto: no hicimos benchmark de un happy path y cantamos victoria. Vigilamos la clase de fallos que nos importaba a lo largo de una ventana representativa, y la reducción se mantuvo.
Las mayores victorias de latencia casi nunca son «cambiar de modelo». Suelen ser «darle al LLM menos de lo que responsabilizarse». Si las peores trazas de tu copilot son las que te dan miedo — IDs inventados, botones perdidos, preguntas repetidas, el modelo reafirmando con seguridad algo que se equivocó dos turnos atrás — el arreglo es estructural, no de prompt-engineering, y casi siempre deja intacta la elección de modelo.
Si quieres una lectura de tu propio copilot, envíanos una traza representativa y tu system prompt. Te diremos en una hora cuál es la clase de fallo dominante y si el mismo patrón aplica.
No. Mismo modelo, mismo tier, mismo proveedor. Cada número de este caso salió de la elección de modelo original.
Sostenido. Vigilamos la clase de fallos de cola a lo largo de dos semanas de trazas de producción posteriores al proyecto. El comportamiento no volvió. El proyecto también instaló la observabilidad que avisa al cliente cuando vuelva.
Sí, cuando el producto es un agente de chat que lleva al usuario por un workflow operacional estructurado — tickets, cuadrantes, rutas, rellenado de formularios sobre registros estructurados. Cuanto más se aleje el producto de esa forma (p. ej. Q&A puramente abierto), menos aplica el patrón.
Porque los operadores recuerdan la peor traza de su semana, no la media. Un copilot cuyo promedio es cuarenta segundos pero cuya cola es de setenta y cinco genera más tickets de soporte, más mensajes de «¿esto está roto?» y más churn que uno cuyo promedio es cuarenta y cinco pero cuya cola es cuarenta y siete. Colapsar la varianza colapsa la percepción de fiabilidad del usuario de un modo que la velocidad media no logra.