Tu agente basado en LLM puede funcionar perfectamente en una demo, pero luego volverse lento e inflar su factura tras unos pocos turnos. El culpable oculto no es un modelo inestable, sino el token drift: el aumento gradual del tamaño del prompt que el modelo debe procesar en cada ocasión.

El token drift ocurre cuando cada interacción añade más texto al contexto de entrada del modelo. El historial de la conversación, los esquemas de las herramientas, las respuestas de la API y los documentos recuperados se van acumulando, por lo que cada llamada subsiguiente conlleva una carga de datos mayor. Debido a que el tiempo de procesamiento y el precio del modelo aumentan con el número de tokens de entrada, el coste crece de forma cuadrática en lugar de lineal.

Por qué el problema aparece en producción y no en las demos

Los despliegues reales lo preservan todo: cada intervención del usuario, cada salida de las herramientas y cada fragmento de conocimiento recuperado. La acumulación permanece oculta hasta que la latencia se dispara y llega la factura.

Fuentes comunes de token drift

  • Transcripciones repetidas – Mantener todos los mensajes antiguos en el prompt en lugar de resumirlos o descartarlos.
  • Esquemas de herramientas pesados – Enviar definiciones JSON extensas de las capacidades de las herramientas en cada turno.
  • Resultados de herramientas voluminosos – Incluir respuestas completas de la API o filas de bases de datos que contienen más datos de los que el agente realmente necesita.
  • Exceso de RAG – La generación aumentada por recuperación (RAG) que añade muchos fragmentos de documentos, algunos de los cuales están desactualizados o son irrelevantes.
  • Memoria duplicada – Empaquetar un resumen, un objeto de estado y la transcripción sin procesar, lo que repite la misma información tres veces.

Cada uno de estos elementos añade tokens que no aportan nueva capacidad de razonamiento y, sin embargo, inflan el tamaño del prompt.

Cómo mantener bajo control el presupuesto de tokens

1. Adoptar un diseño de contexto por capas

  • Instrucciones estables – Mantener los system prompts y las reglas de seguridad en la parte superior y hacer referencia a ellos en lugar de reenviarlos en cada turno.
  • Estado estructurado – Almacenar una representación compacta de objetivos, decisiones e identificadores que el agente pueda leer rápidamente.
  • Historial comprimido – Resumir los turnos más antiguos en un párrafo corto y legible para humanos, actualizándolo solo cuando se alcanza un umbral.
  • Turnos recientes – Incluir los últimos mensajes de forma literal para preservar la continuidad.

Separar el texto constante del contenido resumible evita que vuelvas a enviar las mismas palabras una y otra vez.

2. Recortar las salidas de las herramientas

  • Extraer solo los campos que el agente utiliza realmente; eliminar las descripciones verbosas.
  • Reemplazar los resultados grandes con un resumen conciso o un ID de referencia, y almacenar la carga útil completa en una base de datos, caché o almacenamiento de objetos (blob store).
  • Cuando una herramienta devuelva una lista, enviar solo los N elementos principales que sean relevantes para la decisión actual.

3. Aplicar un resumen inteligente

  • Evitar resumir después de cada turno; el procesamiento adicional añade una carga de trabajo innecesaria.
  • Actualizar el resumen solo cuando el recuento de tokens acumulados de los turnos antiguos supere un límite preestablecido.
  • Mantener los datos críticos (IDs, cantidades, marcas de tiempo) en un almacén estructurado en lugar de integrarlos en la prosa, para que el resumen se mantenga corto.

4. Monitorizar las métricas adecuadas

  • Registrar el uso de tokens por llamada al modelo, no solo por solicitud de usuario. Esto revela el crecimiento oculto en el lado de la entrada.
  • Monitorizar el número de tokens de entrada añadidos en cada turno; un salto repentino indica una fuente de drift.
  • Separar los tokens en caché (reutilizados de llamadas anteriores) de los tokens recién generados; solo los primeros impulsan el drift.

Trata el prompt como un recurso finito, no como una transcripción infinita. Al medir, resumir y recortar deliberadamente, mantendrás tu agente LLM rápido, asequible y listo para escalar en producción.

Conclusión: El token drift aumenta silenciosamente los costes y ralentiza los agentes. Identifica las partes de tu prompt que crecen, comprímelas o externalízalas, y vigila el uso de tokens por llamada. Un enfoque disciplinado convierte los sustos inesperados en la factura en una operación manejable y económica.