Compresión de contexto
La compresión de contexto reduce los tokens que se envían al modelo en cada llamada conservando la información que realmente necesita para actuar. Úsala en agentes de larga duración y conversaciones extensas para recortar coste y latencia y mantenerte dentro de la ventana de contexto. Las tres palancas son resumir el historial, podar contexto irrelevante y comprimir prompts. El riesgo central es la pérdida: descartar el único detalle que importaba. Mide la información retenida, no solo los tokens ahorrados.
Problema
Los agentes de larga duración y las conversaciones de múltiples turnos acumulan contexto: cada resultado de herramienta, mensaje previo y documento recuperado se reenvía en la siguiente llamada. El número de tokens crece casi linealmente con la interacción, por lo que el coste y la latencia por llamada suben, y al final la ventana se desborda y el contenido más antiguo (a veces el más importante) se trunca en silencio. Los arreglos ingenuos —ventanas más grandes, truncado más agresivo— elevan el coste o destruyen la información que el modelo necesita para mantener la coherencia.
Cuándo usarlo
Aplica cuando el contexto crece sin límite respecto a lo que necesita cada paso: asistentes conversacionales con historiales largos, agentes autónomos que iteran sobre muchas llamadas a herramientas, pipelines RAG que recuperan de más y trabajos por lotes donde el tamaño del prompt domina el coste. Encaja cuando gran parte del contexto acumulado es redundante u obsoleto, cuando controlas el ensamblaje del prompt y cuando puedes tolerar cierto error de reconstrucción. Encaja mal cuando cada token es esencial (tareas legales, de auditoría, de recuperación exacta) o cuando las interacciones son tan cortas que la ventana nunca se presiona.
Solución
Trata el contexto activo como un presupuesto que gestionas de forma activa, no como un registro de solo anexar. Existen tres palancas complementarias. El resumen reemplaza un tramo del historial por una sinopsis más corta —normalmente un resumen continuo de los turnos antiguos, actualizado de forma periódica, mientras los turnos recientes se mantienen literales. La poda elimina el contexto irrelevante para el paso actual: deduplica, descarta salida de herramientas obsoleta y selecciona solo los fragmentos recuperados que superan un umbral de relevancia. La compresión de prompts (por ejemplo LLMLingua) usa un modelo más pequeño para borrar o reformular tokens de baja información antes de enviar el prompt, cambiando un pequeño coste de exactitud por grandes reducciones de tokens. Compón estas palancas en un pipeline con límites explícitos: mantén una ventana reciente literal, un resumen continuo del historial antiguo y un espacio de recuperación que se llena bajo demanda. Protege una región 'fijada' para hechos que nunca deben comprimirse —identificadores, restricciones, el objetivo actual. Y, crucialmente, instrumenta el resultado: ejecuta un conjunto de evaluación que compare respuestas con y sin compresión para ver cuándo se degrada la calidad, y ajusta la agresividad por carga de trabajo en lugar de globalmente. La compresión es un dial de calidad frente a coste, no una ganancia gratuita.
Componentes
Beneficios
- Enviar menos tokens reduce directamente el coste de entrada en cada llamada, lo que se acumula a lo largo de bucles de agente largos y tráfico de alto volumen.
- Prompts más pequeños implican menos que codificar y un menor tiempo hasta el primer token, mejorando la respuesta en flujos interactivos y de agentes.
- Acotar el contexto activo permite que conversaciones largas y agentes de muchos pasos continúen sin desbordar la ventana ni truncar en silencio.
- Eliminar contexto redundante y obsoleto puede mejorar la calidad al reducir la distracción, ayudando al modelo a atender a lo que importa ahora.
Riesgos
- Los resúmenes y la poda pueden descartar el único detalle que luego resulta decisivo, produciendo respuestas erróneas con seguridad.
- Los resúmenes continuos resumen resúmenes previos; pequeñas omisiones se acumulan a lo largo de muchos ciclos hasta que el hilo se desvía sin avisar.
- Ejecutar un resumidor o compresor añade su propia latencia, coste y superficie de fallo, que puede anular el ahorro en interacciones cortas.
- La expulsión agresiva puede eliminar en silencio restricciones o instrucciones de las que el modelo aún depende, sin una señal de error evidente.
Cuándo no usarlo
- Cuando cada token es esencial —legal, auditoría, cumplimiento o extracción precisa de datos— la compresión con pérdida es inaceptable.
- Si las conversaciones rara vez presionan la ventana, la sobrecarga de compresión cuesta más de lo que ahorra y añade complejidad innecesaria.
- Sin un arnés de evaluación de retención, no despliegues nada: no puedes saber si la compresión degrada las respuestas en silencio.
Tecnologías
Ejemplos
- Un agente que itera sobre una base de código grande mantiene una ventana reciente literal más un resumen continuo de los pasos anteriores, fijando la especificación de la tarea y las rutas de archivo para no perder el objetivo.
- Un bot de soporte multisesión resume los turnos previos en un resumen de caso compacto, podando subincidencias resueltas mientras fija las restricciones de la cuenta del cliente.
- Un pipeline de recuperación que trae muchos fragmentos aplica poda por relevancia y compresión de prompts para enviar solo los pasajes de alta señal, recortando tokens sin perder la respuesta.
KPIs
- Tokens por llamada (entrada)
- El principal motor del coste. Sigue la distribución antes y después de la compresión; un resultado sano es una reducción clara sin aumento de errores aguas abajo.
- Retención de información / calidad de tarea
- Compara respuestas con y sin compresión en un conjunto de evaluación. Lo bueno es que la calidad se mantenga estable dentro de tu tolerancia mientras bajan los tokens.
- Latencia de extremo a extremo
- Neta de la sobrecarga de compresión. Lo bueno es menor latencia total; vigila que las llamadas del resumidor o compresor no borren el ahorro.
- Tasa de desbordamiento / truncado de contexto
- Con qué frecuencia las interacciones alcanzan el límite de la ventana. Lo bueno es llevar esto hacia cero sin recurrir a descartar contenido fijado.
Modos de fallo observados
- Un resumen omite una restricción mencionada al principio; muchos turnos después el agente la viola porque ese hecho simplemente desapareció del contexto.
- Resumir repetidamente amplifica errores de paráfrasis y omisiones hasta que el resumen acumulado ya no refleja lo que de verdad ocurrió.
- Un presupuesto mal configurado comprime identificadores o instrucciones que debían estar protegidos, rompiendo la corrección en silencio.
- Un umbral de relevancia agresivo filtra contexto que importaba para un caso límite, así la calidad parece bien en pruebas pero falla en producción.
Lecciones aprendidas
- La reducción de tokens es trivial de maximizar y carece de sentido por sí sola; la métrica real es si el modelo sigue respondiendo correctamente.
- Protege de forma explícita identificadores, restricciones y el objetivo actual para que ninguna etapa de compresión pueda expulsarlos.
- Comprime el historial antiguo, no el contexto activo; los intercambios más recientes llevan la señal más relevante para las decisiones.
- Ajusta la agresividad por carga de trabajo contra un conjunto de evaluación; lo que es seguro para una charla es temerario para una tarea de auditoría.
FAQs
- ¿En qué se diferencia de la memoria a largo plazo?
- La memoria a largo plazo persiste hechos fuera del prompt y los recupera bajo demanda; la compresión de contexto reduce el contexto activo que se envía en cada llamada. Son complementarias: la memoria decide qué traer de vuelta, la compresión decide con qué tan poca extensión se aloja en la ventana.
- Resumir, podar o comprimir, ¿cuál uso?
- Poda primero (gratis, sin pérdida cuando eliminas redundancia real), resume el historial antiguo cuando crece sin límite y añade compresión de prompts solo cuando aún necesitas más margen y puedes validar el coste de calidad. La mayoría de los sistemas combinan las tres.
- ¿Cómo sé si la compresión perjudica la calidad?
- Ejecuta un conjunto de evaluación con compresión activada y desactivada y compara los resultados de tarea, no solo los recuentos de tokens. Vigila las respuestas erróneas con seguridad y las restricciones descartadas: esa es la firma de una compresión con pérdida que ha ido demasiado lejos.