Curso exprés · No. 26
Un LLM es brillante y está en blanco: entre una llamada y otra no recuerda nada, y en cada llamada solo conoce el texto que pones delante de él. Context engineering es la disciplina de ensamblar exactamente el texto correcto dentro de esa ventana — las instrucciones, los hechos, el historial, las herramientas, ni más ni menos. Es donde realmente vive la calidad de un LLM, y casi nunca tiene que ver con una redacción ingeniosa.
Solo lo esencial · Una imagen por idea · Ingeniería sobre magia
Todo en este curso se deriva de un solo hecho sobre cómo funciona un modelo de lenguaje: no tiene memoria, y toda su conciencia en cualquier llamada es el texto que le envías. Entiende esto y el resto es evidente.
El modelo no recuerda nada entre llamadas
Un consultor brillante con amnesia total — en cada reunión tienes que volver a entregarle cada documento, porque no recuerda nada de la vez anterior.
Un modelo de lenguaje es stateless: no conserva nada entre solicitudes. La ilusión de que un chatbot recuerda tu conversación no es más que el historial completo siendo reenviado cada vez. El modelo en sí empieza de cero en cada llamada, sabiendo únicamente lo que tiene delante en este momento. Así que «¿qué sabe el modelo?» nunca tiene que ver con el modelo — depende por completo de lo que elegiste incluir esta vez.
La context window es su única memoria de trabajo
Un trabajador que solo puede actuar según las notas clavadas en el tablero que tiene delante — borra el tablero y es como si nunca hubiera pasado nada.
La context window es el bloque de texto que el modelo ve en una llamada — tus instrucciones, la conversación, cualquier dato, las herramientas. Es toda la memoria de trabajo del modelo, y tiene un tamaño finito. Si un hecho, una regla o un mensaje anterior no está en la ventana, el modelo simplemente no lo sabe. Todo aquello sobre lo que el modelo puede razonar, lo razona a partir de la ventana — lo que convierte a la ventana en aquello que de verdad diseñas.
Por eso la calidad la decide lo que pones dentro
Un genio que responde solo a partir de la única carpeta que le entregas — dale la carpeta correcta y la respuesta es brillante; dale la equivocada y es inútil con total seguridad.
Como el modelo trabaja únicamente a partir de la ventana, la calidad de su salida se decide en su mayoría antes de que el modelo se ejecute — por lo que ensamblaste. El mismo modelo da una gran respuesta o una desesperante dependiendo por completo de si el contexto correcto estaba delante de él. Esto reformula todo el trabajo: no estás sacando inteligencia del modelo a fuerza de insistir, estás curando lo que llega a ver. Esa curación es context engineering.
El modelo es stateless y solo conoce su context window. La calidad de la salida la decide lo que ensamblas dentro de esa ventana — así que lo que diseñas es la ventana, no el modelo.
La gente habla de «prompt engineering», pero a medida que las aplicaciones se vuelven serias el verdadero oficio se desplaza a otro lugar — de redactar una solicitud a ensamblar la información correcta a su alrededor. Ese cambio es el corazón de este curso.
Redactar la solicitud frente a ensamblar el contexto
Un abogado no gana con frases ingeniosas, sino entregando al juez exactamente los documentos correctos, en el orden correcto, sin nada irrelevante — el caso está en los papeles, no en el discurso.
Prompt engineering trata de cómo formulas la instrucción. Context engineering es el trabajo mayor: ensamblar toda la información que el modelo necesita — los hechos relevantes, el historial, los ejemplos, las herramientas — dentro de la ventana para cada llamada. A medida que las aplicaciones crecen, la redacción importa menos y el ensamblaje importa más. La mayoría de los momentos de «la IA dio una mala respuesta» no son una mala redacción; son que al modelo le faltaba contexto que nunca se le dio.
La mayoría de los problemas de calidad son problemas de contexto
Un asistente que da una respuesta equivocada porque olvidaste mencionar la única restricción que lo cambiaba todo — no es tonto, solo está mal informado.
Cuando una función con LLM rinde por debajo de lo esperado, el instinto es retocar la redacción del prompt o culpar al modelo. Mucho más a menudo la causa real es contexto que falta o es incorrecto: el documento relevante no se recuperó, una regla clave no se incluyó, un historial obsoleto lo confundió. Antes de reformular nada, pregúntate qué tenía el modelo realmente delante. Arreglar el contexto soluciona más errores de los que jamás solucionará arreglar la redacción.
El modelo es tan bueno como sus entradas
El mejor chef solo puede cocinar con los ingredientes que hay sobre la encimera — dale los equivocados y la destreza no podrá salvar el plato.
Un modelo capaz con mal contexto pierde frente a un modelo más débil con un contexto excelente. Por eso context engineering, y no la elección del modelo, suele ser el lugar de mayor apalancamiento donde invertir esfuerzo: la salida del mismo modelo varía enormemente según lo que le des. No obtienes una mejor respuesta exigiendo con más fuerza — la obtienes poniendo material mejor, más afilado y más relevante en la ventana. Las entradas son la palanca.
Prompt engineering es la redacción; context engineering es ensamblar la información correcta. En lo segundo vive la calidad — y la mayoría de las malas respuestas son contexto que falta, no una mala redacción.
Parte de lo que va en la ventana es duradero y parte es por solicitud, y unos pocos ingredientes específicos hacen la mayor parte del trabajo. Saber cuáles son hace concreto el ensamblaje del contexto.
El system prompt fija el comportamiento permanente
La política permanente de un restaurante — «somos vegetarianos, cerramos a las diez» — frente al pedido concreto de esta noche. Una encuadra todo; el otro es la petición.
El system prompt contiene instrucciones duraderas que aplican a toda la interacción: el rol del modelo, las reglas que debe seguir, el tono, el formato de salida. El user message es la solicitud concreta. Poner tu persona, tus barreras de seguridad y tus reglas permanentes en el system prompt las mantiene estables mientras las preguntas del usuario varían. Es la diferencia entre quién es el modelo en cada llamada y qué se le pide esta vez.
Muestra, no solo cuentes: ejemplos few-shot
Enseñar un formato a alguien mostrando tres ejemplos terminados es más rápido y claro que describirlo con palabras y esperar que se lo imagine bien.
A menudo la forma más fiable de obtener la forma de salida que quieres es incluir unos pocos ejemplos de entrada y salida ideal directamente en el contexto — lo que se llama prompting few-shot. El modelo reconoce patrones en ejemplos mucho mejor de lo que sigue una descripción abstracta. Dos o tres ejemplos afilados pueden ganarle a un párrafo de instrucciones, y suelen ser el arreglo más rápido cuando el modelo casi hace lo que quieres pero no del todo.
Ensambla la ventana a partir de partes
Preparar un maletín para una reunión: la agenda, los dos informes relevantes, una nota con las restricciones — elegidos a propósito, no volcando dentro todo tu archivador.
Una context window real se ensambla a partir de piezas en cada llamada: el system prompt, el historial relevante, los hechos recuperados (RAG), los ejemplos, las herramientas disponibles y, por último, la solicitud del usuario. Context engineering es decidir — deliberadamente, cada vez — qué piezas entran y cuáles se quedan fuera. Pensar en la ventana como algo que construyes a partir de partes, en lugar de un simple prompt que tecleas, es el cambio mental que hace que todo lo demás encaje.
El system prompt fija el comportamiento duradero; el user message es la solicitud; los ejemplos few-shot muestran la forma que quieres. Una ventana se ensambla a partir de estas partes, deliberadamente, en cada llamada.
El mayor error de principiante en context engineering es pensar que más es mejor. Lo cierto es lo contrario: cada token irrelevante que añades empeora activamente la respuesta.
Más contexto no es mejor contexto
Un informe de una sola página afilada le gana a un volcado de 200 páginas — el lector encuentra la señal en lugar de ahogarse en ella, y decide más rápido y mejor.
Resulta tentador meter en la ventana todo lo posiblemente relevante «por si acaso». Pero más no es mejor — normalmente es peor. Cada token compite por la atención del modelo, y el material irrelevante diluye la señal, empuja al modelo hacia lo que tenga cerca y aumenta la probabilidad de que se aferre a lo equivocado. La habilidad está en seleccionar las pocas cosas que importan, no en incluir todo lo que podría importar.
El ruido aumenta la probabilidad de una respuesta equivocada
Esconde el único hecho relevante dentro de una montaña de papel casi todo irrelevante y hasta un lector cuidadoso empieza a citar la página equivocada — el ruido en sí causa el error.
Un contexto largo y relleno no solo desperdicia espacio; degrada activamente la calidad. Sepultada bajo material irrelevante, la atención del modelo se dispersa, y en contextos largos esto aumenta de forma medible la tasa de alucinaciones y errores — usa con seguridad algo que nunca debió ser la respuesta. Añadir contexto «por si acaso» puede ser justamente lo que provoque el fallo. Menos contexto, más afilado, es contexto más fiable.
Cura sin piedad para esta llamada
Un buen editor no añade — corta, entregándote solo las líneas que se ganan su lugar en esta página.
La disciplina es una curación sin piedad: para esta llamada concreta, incluye las pocas cosas que el modelo genuinamente necesita y deja todo lo demás fuera. Eso significa recuperar solo los fragmentos más relevantes, recortar el historial a lo que importa, descartar el contexto que ya cumplió su función. La relevancia por encima de la exhaustividad es el principio rector — no intentas darle al modelo todo, intentas darle exactamente lo suficiente.
Más contexto no es mejor — los tokens irrelevantes diluyen la atención y aumentan las alucinaciones. Cura sin piedad: dale al modelo exactamente lo que esta llamada necesita, y nada más.
Más allá de la calidad, la ventana es un recurso finito y de pago. Tratarla como un presupuesto escaso en lugar de un vertedero infinito es lo que separa un juguete de un producto.
La ventana es finita y cada token cuesta
Una maleta con límite de peso y una tarifa por kilo — empacas lo que realmente vas a necesitar, no todo tu armario, porque hay un tope estricto y un precio.
La context window tiene un tamaño máximo, y cada token en ella cuesta latencia y dinero — los contextos más grandes son más lentos y más caros en cada llamada. Así que el contexto no es espacio libre para rellenar; es un presupuesto que gastas. Una función que satura la ventana en cada solicitud es lenta y costosa a escala, incluso antes de que la calidad se resienta. La ventana es un recurso que asignar, no un vacío que llenar.
Gástala en lo que se gane su lugar
Un presupuesto de viaje ajustado obliga a elecciones reales — gastas en lo que importa para el viaje y te saltas el resto, y el viaje mejora gracias a esa disciplina.
Tratar la ventana como un presupuesto cambia cómo construyes: recortas el historial de la conversación, resumes los turnos antiguos en lugar de arrastrarlos al pie de la letra, y recuperas solo lo relevante ahora en vez de todo lo que tienes. Cada token debería ganarse su sitio. Es la misma disciplina que el rendimiento o el caché — gasta el recurso escaso de forma deliberada, en las cosas que de verdad mueven el resultado.
Una ventana más grande no termina con la disciplina
Alquilar un camión más grande no significa que debas llenarlo de basura — más capacidad es espacio para más cosas útiles, no permiso para dejar de empacar con cuidado.
Los modelos siguen lanzando context windows más grandes — un millón de tokens, más — y resulta tentador pensar que el problema del presupuesto desaparece. No desaparece. Una ventana más grande sigue costando más y siendo más lenta por token y, lo crucial, una ventana más llena sigue diluyendo la atención e invitando a errores. Más capacidad no es permiso para volcar; es solo más espacio que aún tienes que gastar con criterio. La disciplina de curar la ventana sobrevive a cualquier aumento de tamaño.
La ventana es finita y cada token cuesta latencia y dinero. Gástala como un presupuesto — recorta, resume, recupera solo lo necesario — y no dejes que una ventana más grande termine con la disciplina.
En interacciones largas y de varios pasos, el contexto no se queda quieto — se acumula y se degrada. Gestionar esa degradación es la parte más difícil e importante de context engineering a escala.
Los contextos largos acumulan estado obsoleto y contradictorio
Un juego del teléfono descompuesto a lo largo de una fila larga — al final el mensaje ha mutado en silencio, y todos repiten con seguridad algo ligeramente equivocado.
A lo largo de una conversación larga o una tarea de agente de varios pasos, la ventana se llena de historial: turnos anteriores, salidas de herramientas, razonamientos a medio terminar. Con el tiempo este montón se vuelve un desorden — hechos obsoletos junto a otros frescos, contradicciones que se acumulan, el objetivo original que se sale de foco. La industria llama a la consiguiente degradación de calidad context rot: el mismo modelo se vuelve menos fiable a medida que su propio contexto acumulado se ensucia.
Comprime sobre la marcha
Un buen tomador de notas no conserva cada palabra de una reunión larga — la destila a las decisiones y las preguntas abiertas, llevando adelante la conclusión, no la transcripción.
El arreglo es comprimir activamente el contexto a medida que crece: resume los pasos terminados en un breve estado en curso en lugar de arrastrar la transcripción completa, descarta las salidas de herramientas una vez extraído lo que importaba, mantén un resumen de trabajo ajustado en vez del historial en bruto. El modelo lleva la conclusión, no cada palabra que la produjo. Así es como los agentes de larga ejecución se mantienen coherentes — gestionan su propio contexto en lugar de dejar que se amontone.
Vuelve a anclar el objetivo
En una caminata larga y serpenteante vuelves a comprobar el mapa y el destino con regularidad — de lo contrario derivas, un giro de aspecto razonable a la vez, lejos de donde pretendías ir.
A lo largo de muchos pasos, el objetivo original se erosiona bajo el peso de todo lo que ha pasado desde entonces. Así que vuelves a anclarlo: replanteas el objetivo y las restricciones clave en la ventana en cada paso, para que el modelo siga apuntando al blanco real en lugar de derivar con la conversación. Una ventana más grande empeora esto, no lo mejora — le da a la deriva más espacio para acumularse. La gestión activa, no la capacidad en bruto, es lo que mantiene encarrilada una tarea larga.
Los contextos largos se pudren — se acumula estado obsoleto y contradictorio y la calidad decae. Comprime los pasos terminados en un resumen en curso y vuelve a anclar el objetivo, porque una ventana más grande solo le da a la deriva más espacio.
Context engineering bien hecho es ensamblaje deliberado, medido como todo lo demás. Toda la práctica se reduce a construir la ventana a propósito y comprobar que ayudó.
Construye la ventana deliberadamente, no por accidente
Un chef empla un plato a propósito — cada elemento colocado por una razón — en lugar de raspar sobre el plato lo que sea que haya en la encimera.
El hábito central es tratar la ventana como algo que construyes deliberadamente: decide qué contiene el system prompt, qué historial conservar o resumir, qué recuperar, qué ejemplos mostrar, qué herramientas exponer. Muchas apps con LLM ensamblan el contexto por accidente — se envía lo que casualmente estaba a mano. Construirla a propósito, con cada parte justificada, es la mayor parte de lo que separa una función fiable de una inestable.
Mide el contexto como mides el código
No adivinas si un cambio ayudó — lo pruebas. Lo mismo vale para lo que pones en la ventana: una respuesta mejoró o empeoró, y deberías saber cuál de las dos.
Los cambios de contexto son cambios reales, así que verifícalos: cuando ajustas lo que va en la ventana — más ejemplos, recuperación distinta, historial recortado — comprueba el efecto con evals, no juzgues una sola salida a ojo. Context engineering sin medición es afinar por vibras, y así es como una adición «inofensiva» degrada la calidad en silencio. Trata el contenido de la ventana como algo que pruebas, con la misma disciplina que el curso de evals.
- ¿Está en la ventana todo lo que el modelo necesita — o esperas que sepa lo que nunca le diste? - Sistema frente a usuario — ¿las reglas duraderas en el system prompt, la solicitud en el user message? - ¿Ayudarían los ejemplos — es este un caso en que few-shot gana a más instrucciones? - ¿Cada pieza es relevante — o el relleno está diluyendo la atención y aumentando los errores? - ¿Estás dentro del presupuesto — recortando y resumiendo en lugar de volcarlo todo? - Para tareas largas, ¿estás comprimiendo y volviendo a anclar frente al context rot?
- stateless / context window — el modelo no recuerda nada; la ventana es su única memoria de trabajo. - prompt engineering / context engineering — redactar la solicitud, frente a ensamblar la información. - system prompt / user message — comportamiento permanente duradero, frente a la solicitud concreta. - few-shot — enseñar la forma de la salida mostrando ejemplos en el contexto. - relevancia sobre exhaustividad — curar las pocas cosas que importan, no meterlo todo. - context budget — la ventana es finita y cada token cuesta latencia y dinero. - context rot / deriva — los contextos largos acumulan estado obsoleto y decaen; comprime y vuelve a anclar.
- Arreglas malas respuestas comprobando qué hay en la ventana antes de reformular el prompt. - Las reglas duraderas viven en el system prompt; recurres a ejemplos few-shot cuando la forma importa. - Curas sin piedad — relevancia sobre exhaustividad — en lugar de rellenar la ventana. - Tratas la ventana como un presupuesto, recortando y resumiendo en lugar de volcar.
- Para tareas largas comprimes y vuelves a anclar, y mides los cambios de contexto en vez de adivinar.
Context engineering es el ensamblaje deliberado de la ventana: las reglas correctas, los hechos correctos, los ejemplos correctos, curados a la relevancia, mantenidos dentro del presupuesto y gestionados frente al rot — construido a propósito y medido, no tecleado con la esperanza de que salga bien.