Ingeniería de contexto: una sola llamada de inferencia
La ingeniería de contexto es el diseño de una sola llamada de inferencia: qué entra en la ventana, en qué forma, en qué posición y qué se queda fuera. Todo lo que abarca es efímero: cuando termina la llamada, la ventana se vacía. Si se hace bien, el modelo razona con claridad sobre esa petición; si se hace mal, la calidad cae mucho antes de llegar al límite de tokens. Tres decisiones cargan con la mayor parte del peso:
- Inclusión selectiva. Una consulta que devuelve cientos de filas, una búsqueda que devuelve cinco artículos completos, un registro de herramienta muy extenso: meterlo todo infla la ventana y reduce la calidad del razonamiento. Qué entra tal cual, qué se comprime a los datos clave y qué se descarta es una decisión de diseño, no un valor por defecto.
- Ubicación estructural. Los modelos prestan más atención al inicio y al final de un contexto largo, y menos a la parte media: el efecto “perdido en medio” (lost in the middle). Las restricciones estrictas van arriba; el material recuperado más relevante para la tarea y la consulta en sí van cerca del final, junto a donde ocurre la generación.
- Compresión al llegar. Resuma la salida de una herramienta cuando regresa, no cuando se desborda la ventana. Una respuesta de API de 3,000 tokens de la que el agente necesita 150 debe comprimirse antes del siguiente paso: de forma proactiva, no con un recorte de pánico más adelante.
El historial de la conversación es el componente que más rápido crece, así que los agentes de larga duración necesitan una estrategia de compresión permanente (ventana móvil, resumen jerárquico o extracción de estado estructurado) aplicada de forma programada, no un apuro cuando ya se desbordó. Es la misma disciplina del impuesto de tokens, aplicada dentro de una sola llamada.
Ingeniería de memoria: entre llamadas, sesiones y agentes
La ingeniería de memoria trata de lo que sobrevive a una sola interacción: los sistemas y las políticas para escribir, almacenar, recuperar, actualizar y gobernar información de modo que las llamadas posteriores puedan usarla. Cuando un agente recuerda algo de la semana pasada, se coordina con otro agente o aplica una preferencia que aprendió hace días, eso es memoria, no contexto. Cuatro asuntos:
- Política de escritura: la pieza más ignorada y la de mayores consecuencias. Qué dispara una escritura, qué es elegible, en qué formato (texto crudo, hechos extraídos o resúmenes), con qué nivel de confianza, quién tiene permiso de escribir y cómo se manejan los conflictos y la caducidad. Si se omite, el almacén por defecto lo guarda todo para siempre con la misma confianza: crece sin fin mientras se vuelve menos útil.
- Capa de almacenamiento: cada tipo de memoria pide un backend distinto: de trabajo (estado de la tarea → un almacén clave-valor rápido como Redis), episódica (corridas pasadas → almacén vectorial), semántica (hechos y preferencias duraderos → vectorial + clave-valor) y procedimental (flujos de trabajo aprendidos → almacén estructurado). El backend también limita cómo se puede recuperar.
- Estrategia de recuperación: no es una sola operación: revisar primero la memoria de trabajo (barata, exacta), recurrir después a la búsqueda semántica, filtrar por recencia y confianza, e inyectar solo lo que el paso necesita.
- Mantenimiento: un almacén sin mantenimiento se pudre: decaimiento de la confianza en hechos volátiles, deduplicación de entradas casi idénticas, caducidad (TTL) en datos sensibles al tiempo y compresión periódica de episodios viejos en resúmenes.
Una nota de honestidad útil de la fuente: la extracción de estado estructurado (escribir hechos tipados y validados) es mejor que volcar fragmentos crudos de conversación en un almacén vectorial, que es frágil ante reformulaciones y actualizaciones contradictorias; y etiquetar cada entrada con un nivel de confianza (sistema interno > entrada del usuario > externo) evita que el contenido de baja confianza envenene en silencio el razonamiento posterior.
Dónde se encuentran: la frontera de la recuperación
Las dos disciplinas no están realmente separadas: se encuentran en la recuperación. La memoria produce información candidata; el armado del contexto decide si entra al prompt, cuánto de ella y dónde. Si esa frontera se maneja bien, un montón de componentes de memoria se convierte en un agente coherente. Si se maneja mal, aparecen dos modos de falla que parecen otra cosa:
Falla 1: recuperación sin presupuesto de contexto. La memoria encuentra las entradas correctas y el ensamblador las inyecta todas, desplazando las instrucciones y las salidas de herramientas. Las métricas de recuperación se ven excelentes, los recuerdos se encuentran, y aun así el desempeño empeora, porque el armado del contexto nunca asignó un presupuesto de tokens. La solución es un armado consciente de la recuperación: fijar primero el presupuesto y luego devolver solo los recuerdos de mayor valor que quepan.
Falla 2: buena recuperación, mala ubicación. Se recupera e inserta el recuerdo correcto, pero se añade donde caiga, a menudo en plena parte media, donde la atención es más débil, así que el modelo se comporta como si no lo tuviera. La recuperación funcionó; la ubicación falló. La información recuperada que debe guiar el paso actual va cerca de la zona de razonamiento activo, no pegada en cualquier lugar.
El hilo conductor: la recuperación no es un problema de búsqueda que se resuelve de forma aislada; es el primer paso para construir la ventana de contexto, sujeto a un presupuesto y a una decisión de ubicación. Es el lado de la persistencia de la misma historia que el impuesto del traspaso entre agentes cuenta desde el lado del cómputo: los sistemas con varios agentes viven o mueren según el cuidado con que llevan la información correcta al lugar correcto en el momento correcto.
Por qué está en un sitio de costo y calidad
Porque ambas disciplinas son, en el fondo, disciplina de tokens, y la disciplina de tokens es costo y calidad a la vez. Cada recuperación sin presupuesto y cada salida de herramienta sin comprimir son tokens que usted paga y que además empeoran la respuesta. Acertar con el contexto y la memoria no es solo ingeniería de confiabilidad; es el mismo instinto de “gastar tokens donde se ganan su lugar” que hay detrás del Manual contra el impuesto de tokens, aplicado a lo que el agente recuerda y ve, no solo a qué modelo lo ejecuta.