Ingeniería de contexto para agentes de código
La ingeniería de prompts iba de la formulación. La ingeniería de contexto va de lo que hay en la ventana cuando llega la formulación, y vale mucho más.
Dale a un modelo todo tu repositorio y una pregunta y no le habrás facilitado el trabajo. Lo habrás convertido en un problema de búsqueda antes de poder ser un problema de respuesta. Tiene que encontrar el rincón que importa, en una ventana donde cada archivo irrelevante compite por la atención con el relevante.
Esta es la parte que se pasa por alto: más contexto no es estrictamente mejor contexto. Pasado cierto punto es peor, y lo pagas más caro.
Los tres modos de fallo
- Dilución. La señal está, pero rodeada. La precisión al recuperar un dato baja a medida que sube el volumen de material sin relación a su alrededor, y baja más rápido para lo que está en el medio de una ventana larga.
- Contradicción. Dos versiones de la misma función, un comentario viejo contra código nuevo, un README obsoleto. El modelo no tiene forma de saber cuál está vigente, y a veces elegirá el equivocado.
- Deriva. Las sesiones largas acumulan decisiones revertidas, caminos abandonados y errores ya corregidos. Todo eso sigue en la ventana, sigue releyéndose y sigue moldeando la respuesta.
Reglas que aguantan
No son ingeniosas. Son las que sobreviven al contacto con el trabajo real.
La pertinencia gana al volumen. Diez líneas que responden a la pregunta valen más que mil que contienen la respuesta en alguna parte. Si puedes señalar el código, señálalo.
Lo actual gana a lo completo. Un archivo obsoleto que contradice el comportamiento actual es peor que ningún archivo, porque produce una respuesta equivocada y segura en vez de una pregunta.
Un techo duro gana a las buenas intenciones. Sin él, el contexto crece de forma monótona. Nada dentro de un bucle de agente decide nunca que ya sabe bastante.
Una tarea por ventana. La técnica de gestión de contexto más barata que existe es cerrar la sesión.
Cómo se ve esto en la práctica
capsul context 'por qué el manejador del webhook devuelve 500' --open src/app/api/polar/webhook/route.tsMonta el contexto e informa de lo que cuesta, sin gastar una petición.
El sentido de construir el contexto aparte es que hace visible la parte invisible. Ves lo que cuesta una tarea antes de comprometerte, y puedes comparar dos formas de plantear la misma pregunta.
Medirlo
La ingeniería de contexto tiene un problema de honestidad, y conviene nombrarlo. Casi toda afirmación en este terreno se hace sin brazo de control, lo que la vuelve infalsable. Si vas a cambiar cómo se monta el contexto, mide la misma tarea en el mismo modelo con y sin el cambio, repite lo suficiente para ver el suelo de ruido, y publica el intervalo en lugar de la mediana.
Preguntas
¿La ingeniería de contexto es ingeniería de prompts con otro nombre?
No. La ingeniería de prompts trata de la redacción de la petición, que es una fracción pequeña de lo que se envía. La ingeniería de contexto trata del noventa y tantos por ciento restante: qué archivos, qué historial, qué salidas de herramientas y qué se queda fuera.
¿Una ventana de doscientos mil tokens elimina el problema?
Elimina el techo, no el problema. La precisión de recuperación sigue degradándose con el volumen, las contradicciones siguen confundiendo, y sigues pagando cada token en cada turno.
¿De cuánto debería ser un presupuesto de contexto?
Lo bastante pequeño para forzar una elección. La cifra exacta importa menos que tener una, porque un agente sin techo llena lo que le den.
¿Cómo sé si un cambio de contexto ayudó de verdad?
Ejecuta la misma tarea de las dos formas, varias veces, en el mismo modelo, y compara el intervalo en lugar de una sola ejecución. Las sesiones de agente son lo bastante ruidosas como para que una única comparación antes y después no signifique casi nada.
$ npm i -g @penra/capsul