Contexto, routing y costo

En el software de siempre, ejecutar una función una vez más cuesta casi nada. En un sistema construido sobre un modelo de lenguaje, cada paso de un agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada. cuesta tokensToken Pedacito de texto, a menudo parte de una palabra, que el modelo lee y escribe y por el que cobran los proveedores., tiempo y dinero, y ese costo sale del diseño: cuánto texto envías, qué modelo responde y cuántas vueltas permites. La memoria de trabajo del modelo, su ventana de contextoVentana de contexto Máximo de tokens que un modelo puede leer en una llamada; el modelo no conserva nada entre llamadas., también es limitada, y cuando se llena el modelo presta peor atención mucho antes de que algo falle a la vista.

Esta lección cubre cinco ideas: por qué el costo de un agente crece más rápido de lo esperado, cómo mantener el contexto pequeño a propósito, la diferencia entre costo medido y estimado, los presupuestosPresupuesto Límite duro sobre tokens, llamadas, tiempo o dinero, aplicado antes de gastar el recurso. como señales de alto, y la elección de un modelo por rol. Los tokens y la ventana de contexto se presentan en El LLM como componente de software.

Por qué el costo de un agente crece rápido

Una llamada al modelo se cobra por el texto que entra y el texto que sale, contado en tokens. Además, el modelo no recuerda nada entre llamadas, así que cada vuelta del loop del agente reenvía todo lo anterior: instrucciones, archivos leídos, salida de cada comando.

Imagina una reunión donde, antes de cada punto nuevo, alguien lee en voz alta toda el acta hasta ese momento. El décimo punto cuesta mucho más que el primero, y por la misma razón un loop de 20 vueltas no equivale a 20 llamadas iguales. Si nadie recorta el historial, el costo de entrada crece aproximadamente con el cuadrado del número de vueltas.

Mantener el contexto pequeño a propósito

Decidir qué entra en cada llamada, en qué forma y en qué orden, se llama context engineeringContext engineering Decidir qué entra en cada llamada al modelo, en qué orden y con qué presupuesto de tokens. (ingeniería de contexto): tratar el contexto como un presupuesto, no como un balde. Movimientos típicos: recortar salidas largas de herramientas, resumir el historial viejo, traer solo los documentos relevantes (RAG) y delegar subtareas a agentes auxiliares con su propio contexto.

Tres fallas aparecen una y otra vez:

• Desborde. El pedido ya no cabe, el proveedor lo rechaza y el trabajo de esa vuelta se pierde si el sistema no lo previó.
• Una salida gigante. Un solo comando que imprime un log enorme llena el contexto de un golpe.
• Resúmenes que rompen la conversación. El pedido de usar una herramienta y la respuesta de esa herramienta van juntos. Un resumen que conserva uno y descarta el otro deja una conversación que el proveedor rechaza.

El siguiente recuadro sigue estos movimientos en el orden en que docket los aplica antes de cada llamada al modelo.

Medido frente a estimado

Hay dos formas de saber cuántos tokens tiene algo. Una estimación es una regla práctica, como "unos cuatro caracteres por token"; existe antes de la llamada, así que sirve para decidir qué cabe, con margen. Una medición es la cuenta que reporta el proveedor después de la llamada; es exacta, así que es la que sirve para presupuestos y contabilidad. Informar una estimación como si fuera medición engaña a quien decide con ese número.

Ni siquiera los tokens exactos dan la factura real. Esa depende de los precios vigentes, los descuentos, los planes negociados y las comisiones de intermediarios. De ahí la regla: los tokens se miden; los dólares se estiman.

Ese hueco es la lección general: un control de costos es tan bueno como su fuente de verdad. En producción, esa fuente es la factura del proveedor o del gateway, y los números internos deberían contrastarse con ella.

Presupuestos como señales de alto

Un runaway loop (bucle desbocado) es un agente que sigue andando sin avanzar, con cada vuelta más cara que la anterior. La defensa son varios límites duros a la vez, porque cada uno atrapa un tipo distinto de bucle:

Elegir un modelo por rol

No todo paso necesita el modelo más capaz y más caro. El model routingModel routing Asignar cada pedido o rol a un modelo específico, normalmente para equilibrar costo y calidad. es elegir qué modelo responde cada pedido: fijo por rol, según lo difícil que parezca el pedido, en cascada (probar uno barato y subir si falla una verificación), como respaldo cuando un proveedor cae, o por costo y velocidad. Tiene sus costos: instrucciones afinadas para un modelo pueden fallar en otro, las fallas se vuelven más difíciles de reproducir, y una cascada a veces paga dos veces.

En la práctica

• Etiqueta cada cifra de costo como medida o estimada, y contrástala con la factura real.
• Prueba con una ventana de contexto pequeña antes de confiar un sistema a una grande.
• Define límites antes del primer despliegue, y no permitas gasto sin un disparador explícito.
• Demuestra con evidencia que un modelo más barato alcanza: compáralo sobre las mismas tareas con evals antes de asignarle un rol.

Para profundizar

La documentación de docket y de Tack muestra estos controles en sistemas que funcionan (en inglés):

• Workflow guide recorre una tarea a través de un equipo de agentes, con un tope de presupuesto que detiene el trabajo entre pasos y la lectura de tokens medidos junto a una estimación etiquetada.
• Troubleshooting trata el contexto que crece y los turnos desbocados: los límites por turno, cómo revisar lo que se reenvía en cada vuelta y cómo recortar la salida de herramientas para una ventana pequeña.
• Architecture explica las clases de modelo barata y fuerte, y cómo el traspaso entre pasos descarta los campos menos importantes antes de recortar el resumen.
• Agent runners and fleet execution describe, para cada herramienta de código, qué consumo puede medir Tack de verdad y por qué un costo desconocido dice "Not measured".

Para llevar

• Todo el historial se reenvía en cada vuelta, así que el costo crece mucho más rápido que el número de pasos.
• Mantén el contexto pequeño a propósito, y al resumir nunca separes un pedido de herramienta de su respuesta.
• Estima para decidir, mide para contabilizar, y nunca presentes una estimación como dinero gastado.
• Varios límites a la vez frenan los bucles desbocados; cada uno atrapa una falla distinta.
• El routing por rol ahorra dinero, pero son las evalsEval Medición de qué tan bien se comporta el sistema completo en casos realistas, incluidos los pasos que dio en el camino, calificada con verificaciones imperfectas y leída con estadística., no los supuestos, las que muestran si la calidad se mantiene.

Comprueba lo aprendido