claudio.cool
CCDV-FLecciones

CCDV-F · Ingeniería de prompts y de contexto

Deriva e inflado del contexto: recortar, compactar y aislar

⏱ 3 min de lecturaBorrador

Un agente de migración respeta todas las reglas durante media hora. A la hora empieza a editar archivos de vendor/ y a saltearse los tests. Las trazas muestran que casi todo el contexto son lecturas de archivos completas y logs de tests de pasos viejos que nadie volvió a mirar. Repetir las reglas en mayúsculas no cambió nada. El problema no son las reglas: es lo que las rodea.

Deriva e inflado

  • Inflado del contexto (context bloat): la ventana se llena de material que ya no sirve (resultados de herramientas viejos, historial completo, documentos ya procesados).
  • Deriva del contexto (context drift): la consecuencia. Con tanto material encima, las instrucciones del principio pesan menos y el comportamiento se aparta de ellas. La calidad de las respuestas baja a medida que crece la conversación, mucho antes de llegar al límite de la ventana.

La salida es mantener el contexto activo chico, con lo que la tarea necesita ahora. Hay tres técnicas, de la más fina a la más gruesa.

1. Recortar en el origen y limpiar resultados viejos

  • En el origen: que cada herramienta devuelva solo lo útil. Los campos que importan y no el registro entero, una página de resultados y no mil, el resumen del test y las fallas, no el log completo.
  • Limpieza de resultados de herramientas (tool result clearing (context editing)): la API puede reemplazar automáticamente los resultados más viejos por un marcador cuando el prompt pasa un umbral, conservando los últimos y dejando afuera las herramientas que elijas. Tu historial queda intacto del lado del cliente.

Es lo indicado cuando lo que infla son lecturas y logs que no se vuelven a usar.

2. Compactar lo que hay que recordar

La compactación (compaction) reemplaza los turnos viejos por un resumen y deja intactos el system prompt y, si querés, los últimos turnos. La API la ofrece a pedido o al llegar a un umbral de tokens, y podés darle tu propio prompt de resumen para que no pierda lo que importa.

Es lo indicado cuando la conversación tiene decisiones que no se pueden perder: un chat de viajes de cientos de turnos tiene que recordar fechas, presupuesto y destinos. Descartar los mensajes más viejos al pasar un umbral (una ventana deslizante) borra justo esas decisiones.

3. Aislar con subagentes

El aislamiento de contexto (context isolation) separa una subtarea en un subagente con su propia ventana. El subagente lee los 40 contratos y devuelve solo las cláusulas de riesgo; el agente principal redacta el memo con esos hallazgos, sin el texto crudo encima. La pista típica: los casos chicos salen bien y los grandes no. El problema es el volumen, no la capacidad del modelo.

Para datos que tienen que sobrevivir a todo lo anterior (decisiones, avances de una tarea larga), conviene guardarlos afuera, en archivos de notas o con la herramienta de memoria, y releerlos cuando hagan falta.

Qué no resuelve el problema

Idea Por qué no alcanza
Caché de prompts Baja costo y latencia; los tokens siguen ocupando la ventana
Modelo con ventana más grande Posterga el límite, pero la deriva sigue
Repetir las reglas en cada turno Suma más texto a un contexto que ya está inflado
Pasar el historial entero siempre Es la causa, no la solución

Las trampas típicas

  • Repetir las reglas en mayúsculas o en cada mensaje del usuario.
  • Subir max_tokens o el nivel de esfuerzo para que “razone más las reglas”.
  • Cortar los mensajes más viejos cuando hay que conservar decisiones.
  • Pegar todos los documentos de entrada en un único mensaje gigante.
  • Esperar que la caché haga lugar en la ventana.

En el examen

Buscá qué ocupa el contexto. Si son resultados de herramientas viejos, recortarlos o limpiarlos. Si son turnos con decisiones que hay que recordar, compactar preservando esos datos y el system prompt. Si una subtarea trae mucho material crudo que después no se usa, delegarla a un subagente que devuelva un resumen.

Pregunta rápida

Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.

A logistics company extracts shipment data from carrier emails with the Claude API and gets back a JSON object with tracking number, carrier and estimated delivery date. A Python service parses that JSON into a strict data class and writes it to the warehouse database.

Last week the service crashed several times. Logs show the model's JSON was well formed, but some responses included an extra field, notes, with remarks about the email. The strict data class rejects unknown keys, so the whole batch failed.

The team is small and wants a fix that keeps bad records out of the database without stopping the pipeline.

Which change best fits the requirement?

Practicá este dominio en el simulacro →