Ingeniería de contexto

La ingeniería de prompts se pregunta cómo pedir bien una cosa. La ingeniería de contexto se pregunta algo más grande y más difícil: qué debe tener el modelo delante de los ojos, exactamente, en el momento de responder.

El cambio de nombre no es moda. Cuando pasas de una consulta suelta a un agente que da veinte vueltas de bucle, el prompt deja de ser un texto que escribes tú y pasa a ser un estado que se acumula: instrucciones, historial, resultados de herramientas, documentos recuperados, archivos. Decidir qué entra, qué se resume y qué se tira es hoy el problema central.

El contexto es un presupuesto, no un cajón

La ventana de contexto tiene un tamaño fijo, medido en tokens. Y no es un cajón donde meter todo lo que quepa: es un presupuesto que gastas. Cada token que agregas cuesta dinero, cuesta latencia y —lo que más duele— compite por la atención del modelo con los tokens que de verdad importaban.

Ese último punto es el que casi nadie ve venir. El mecanismo de atención reparte un total fijo de atención entre todo lo presente. Si metes 80.000 tokens de los cuales 500 son relevantes, el modelo tiene que encontrar esos 500 entre el ruido. El fenómeno tiene nombre: degradación por contexto (context rot). Un contexto más largo no es un contexto mejor.

Cuánto cuesta llenar la ventana

Con $n$ tokens en contexto, el costo de la atención crece con el cuadrado de $n$: cada token mira a todos los demás.

$${\text{costo}}_{\text{atencioˊn}}\sim \mathcal{O}(n^2)$$

Duplicar el contexto no duplica el costo: lo cuadruplica. Por eso "meterlo todo por si acaso" es la decisión de arquitectura más cara que puedes tomar.

El principio: el conjunto mínimo suficiente

Hay una sola regla que ordena todo lo demás:

Busca el conjunto de tokens más pequeño que maximice la probabilidad del resultado que quieres.

No el más completo. El más pequeño que alcanza. En la práctica eso se traduce en cuatro decisiones.

1. Instrucciones: ni vagas ni sobre-especificadas

Hay dos formas de fallar. Una es el prompt vago —"sé útil"— que deja al modelo adivinando. La otra es el prompt de mil reglas frágiles, que intenta cubrir cada caso posible y termina contradiciéndose. La altitud correcta está en medio: suficientemente concreto para guiar, suficientemente flexible para generalizar.

2. Herramientas: pocas, distintas y bien descritas

Una herramienta mal descrita envenena todas las vueltas del bucle. Dos herramientas que se solapan generan dudas que el modelo resuelve mal. La prueba ácida: ¿podría un colega nuevo, leyendo solo la descripción, saber cuándo usarla? Si no, el modelo tampoco.

Y ojo con lo que devuelven. Una herramienta que retorna un JSON de 30.000 tokens para que el modelo lea tres campos es un problema de contexto disfrazado de problema de API.

3. Ejemplos: pocos y bien elegidos

Los ejemplos (few-shot) siguen siendo la forma más eficiente de comunicar un formato o un criterio. Pero no acumules un catálogo de casos borde: tres ejemplos diversos y canónicos enseñan más que veinte variaciones del mismo.

4. Recuperación: justo a tiempo, no por adelantado

Cargar la base de conocimiento completa "por si acaso" es el antipatrón clásico. La alternativa es dejar que el agente traiga lo que necesita cuando lo necesita, con RAG o con herramientas de búsqueda. El contexto se construye durante la tarea, no antes de empezar.

Tres técnicas para tareas largas

Cuando la tarea excede la ventana —y en agentes largos siempre acaba excediéndola— hay tres maniobras estándar:

• Compactar (compaction): resumir el historial y reiniciar la conversación con el resumen. Se conservan las decisiones y los pendientes; se tiran los volcados de herramientas ya consumidos.
• Externalizar: escribir el estado en un archivo o una base de datos y dejar en contexto solo la referencia. El sistema de archivos es memoria infinita y barata.
• Subagentes: delegar una exploración larga a un agente aparte, que trabaja en su propia ventana y devuelve un resumen de 2.000 tokens en vez de las 100.000 que leyó.

Un ejemplo mínimo

Compactar no es magia: es una llamada más al modelo, pidiéndole que se resuma a sí mismo.

def compactar(historial, limite=8000):
    """Si el historial se pasa del presupuesto, lo cambia por su resumen."""
    if contar_tokens(historial) < limite:
        return historial

    resumen = modelo.responder(
        "Resume este trabajo en curso. Conserva: decisiones tomadas, "
        "archivos tocados, pendientes y lo que falló. Descarta los "
        "volcados de herramientas ya usados.\n\n" + formatear(historial)
    )
    # El agente sigue con el resumen como nueva base, no desde cero.
    return [{"rol": "sistema", "texto": resumen}]

Para llevar

La ingeniería de contexto es la disciplina de decidir qué ve el modelo en cada llamada, tratando la ventana como un presupuesto escaso y no como un cajón. Su regla es el conjunto mínimo suficiente de tokens: instrucciones a la altitud correcta, pocas herramientas bien descritas, ejemplos canónicos y recuperación justo a tiempo. Cuando la tarea se alarga, se compacta el historial, se externaliza el estado o se delega a subagentes. Es la diferencia entre un agente que aguanta cien vueltas y uno que se pierde a la décima. Su continuación natural es la ingeniería del bucle.