Presupuestos de latencia para agentes y por qué nadie establece uno

Pregúntele a un equipo cuánto debería costar su agente y obtendrá una cifra. Pregunte cómo es un buen resultado y normalmente obtendrá criterios. Pregunte cuánto tiempo está permitido y obtendrá una pausa.

Esa pausa es donde se origina mucha frustración posterior, porque la latencia no es una propiedad que emerge. Es el resultado de decisiones tomadas por otros motivos.

Cada mejora de la calidad cuesta tiempo.

Recupere más candidatos y vuelva a clasificarlos: mejor base, más tiempo. Agregue un paso de verificación: menos errores seguros, más tiempo. Ofrezca al agente otra herramienta: más capacidad, más contexto para procesar cada llamada.

Ninguno de estos está mal. Son intercambios, y un intercambio realizado sin presupuesto por un lado no es un intercambio, es una deriva. Los sistemas se vuelven más lentos, una decisión razonable a la vez, hasta que alguien se da cuenta de que algo que solía ser interactivo ahora ya no lo es.

¿A dónde va realmente el tiempo?

Rara vez donde la gente supone. En las ejecuciones de agentes que hemos analizado, la distribución es bastante consistente: una minoría en la inferencia del modelo, una participación sustancial en recuperación y llamadas a herramientas, y una proporción sorprendentemente grande en pasos secuenciales que podrían haberse ejecutado en paralelo pero que se escribieron como una cadena.

El último de ellos suele ser el más barato de arreglar y el menos examinado, porque parece un código correcto en lugar de un problema de rendimiento.

Los reintentos son el otro consumidor silencioso. Un agente que falla y se reinicia paga la latencia completa dos veces por un resultado, y las cifras agregadas lo ocultan a menos que los éxitos y los reintentos se midan por separado.

Interactivo y fondo son productos diferentes.

Un presupuesto de latencia sólo significa algo en contexto. Un agente al que una persona está esperando tiene un presupuesto medido en segundos, y excederlo hace que la función parezca fallida independientemente de la calidad del resultado.

Un agente que se ejecuta durante la noche en una cola puede tardar veinte minutos y a nadie le importa, lo que significa que puede permitirse pasos de verificación, una recuperación más amplia y modelos más lentos que uno interactivo.

Los equipos que clasifican a sus agentes de esta manera toman decisiones mucho mejores, porque la misma técnica es correcta en un contexto e incorrecta en otro.

Hazlo parte de la evaluación.

Esta es la razón por la cual las evaluaciones en Orán califican la latencia junto con criterios de comportamiento, estructurales y de costos en lugar de tratarla como una métrica operativa leída por separado.

Un cambio que mejora la precisión y duplica el tiempo de respuesta no es automáticamente una mejora, y un sistema que solo califica la corrección lo reportará como tal. Puntuar los cuatro juntos obliga a que el intercambio sea explícito en el momento en que se realiza, que es el único punto en el que resulta barato reconsiderarlo.

Un punto de partida razonable

Anota el presupuesto antes de construir, aunque sea de forma aproximada, y clasifica al agente como interactivo o de fondo. Mida la recuperación, las llamadas a herramientas y la inferencia por separado para que el presupuesto pueda atribuirse en lugar de simplemente excederse. Cuente los reintentos además de los éxitos. Luego trate una regresión de latencia de la misma manera que trataría una regresión de calidad, es decir, como algo que no pasa una verificación en lugar de algo que se nota en una reunión.

Siguiente

Las páginas del Sistema de orquestación de agentes cubren la capa de evaluación y cómo se califican juntos el costo, la calidad y la latencia. Las páginas de observabilidad cubren dónde se pasa el tiempo dentro de una carrera.