Un agente que acierta pero tarda demasiado o cuesta más de lo que ahorra no está listo. Un agente que tarda demasiado en responder o que cuesta más que la tarea que sustituye no está listo, aunque acierte.
El presupuesto de latencia
Cada paso de un sistema de IA consume tiempo. La entrada de audio, la transcripción, la recuperación, la llamada al modelo, la herramienta, la generación de la respuesta y la síntesis de voz. Si sumas todos los pasos, el resultado puede ser una conversación lenta aunque cada pieza por separado parezca rápida.
Lo primero es medir. Separa el tiempo hasta el primer token o el primer audio del tiempo total. En una conversación, la primera respuesta es la que marca la sensación de velocidad. En un proceso por lotes, importa más el tiempo total y el coste.
Streaming
El streaming permite empezar a mostrar o reproducir la respuesta antes de que el modelo termine. En texto, el usuario ve que algo está pasando. En voz, el TTS puede empezar a hablar con la primera frase. Eso reduce la latencia percibida sin reducir el tiempo total de generación.
El streaming no arregla un modelo lento. Si el primer token tarda demasiado, el usuario sigue esperando. Pero cambia la experiencia de una espera larga por una respuesta que avanza.
Caché y contexto
Enviar el mismo contexto largo en cada llamada cuesta dinero y tiempo. Si el prompt del sistema o los documentos de referencia son estables, la caché del proveedor puede reducir el coste y la latencia. También puedes cachear respuestas para preguntas frecuentes o resultados de herramientas que cambian poco.
Cuidado con la caché cuando los datos cambian. Una respuesta cacheada de una política antigua puede ser peor que una respuesta lenta. La caché necesita una política de invalidación clara.
Enrutamiento de modelos
No todas las peticiones necesitan el modelo más caro. Puedes enviar las tareas simples a un modelo pequeño y reservar el grande para las decisiones difíciles. Un clasificador barato puede decidir el camino, o puedes usar una regla fija. Mide la calidad por tipo de petición, no en conjunto.
El enrutamiento también sirve para la disponibilidad. Si un proveedor falla, puedes reintentar en otro. Eso añade complejidad, pero evita que una caída se convierta en una caída del producto.
Coste por tarea
El precio por token no es el coste. El coste por tarea incluye los tokens de entrada, los de salida, las llamadas a herramientas, los reintentos, la caché, el almacenamiento y la revisión humana. Un sistema que usa un modelo barato pero necesita tres reintentos y una persona puede costar más que uno que usa un modelo caro y acierta a la primera.
Mide el coste por caso resuelto, no por llamada. Y compáralo con el valor del trabajo que sustituye. Si el coste por caso supera el coste cargado del tiempo que ahorra, no hay negocio.
El orden de optimización
Primero la calidad, después la latencia y al final el coste. Si optimizas el coste antes de saber si el sistema funciona, acabas con una versión barata que no sirve. Si optimizas la latencia antes de tener una evaluación, no sabes si estás empeorando la respuesta.
Cuando ya hay una base, optimiza en este orden: elimina pasos innecesarios, reduce el contexto, usa streaming, añade caché, prueba modelos más pequeños y, si hace falta, ajusta el modelo. Cada cambio se mide contra la misma suite de evals.
Dónde mirar primero
Antes de cambiar de modelo, mira el recorrido. ¿Cuántas llamadas al modelo hace una sola petición? ¿Cuántos tokens de contexto se envían? ¿Qué herramienta tarda más? ¿Hay reintentos que no ves? ¿El streaming está activo? Muchas veces el problema no es el modelo, sino la arquitectura alrededor.
Haz un presupuesto por paso. Asigna un tiempo máximo a la recuperación, a la herramienta, al modelo y a la respuesta. Mide cada paso por separado. Si un paso se come la mayor parte del tiempo, ahí está la optimización. Si el coste se dispara, mira el tamaño del contexto y el número de reintentos antes de culpar al precio por token.
Sigue leyendo