# El modelo solo sabe lo que está en la ventana Curso exprés sobre context engineering — la disciplina de ensamblar exactamente el texto correcto dentro de la context window de un modelo. 18 conceptos — Stateless Model, Context Window, Context Engineering, System Prompt, Few-shot, Context Dilution, Context Budget, Context Rot, Compaction, Context Evals y más — cada uno con su nombre en inglés, un diagrama, una ficha y un ejemplo. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/context-engineering-express --- ## 1. La ventana es todo lo que sabe 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 mapa: 18 conceptos en siete grupos > Un mapa de metro: primero ves las líneas en conjunto, luego recorres estación por estación. El curso recorre siete grupos. Primero — **la ventana**: qué sabe el modelo, en definitiva. Luego — **el cambio** de redactar un prompt a ensamblar contexto. Después — **de qué está hecha la ventana**, y las tres fuerzas que la degradan: **la irrelevancia**, **el presupuesto** y **la podredumbre con el tiempo**. Por último — **la práctica**: construir la ventana a propósito y medir el resultado. _Diagram: Siete grupos de conceptos — los capítulos 1–7 los siguen._ ### Cómo leer cada concepto > Un pasaporte: los mismos campos para todos, así es fácil compararlos. Cada concepto de abajo recibe el mismo trato: su **nombre en inglés** (recuérdalo — así lo llaman los docs y los artículos), una imagen de la vida cotidiana, un **diagrama** y una **ficha** con campos como _problema_, _idea_, _ejemplo_, _coste_ y _relaciones_. La idea principal del curso: **la calidad de un LLM la decide lo que pones en la ventana, no una redacción ingeniosa.** ### Stateless Model — 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** — ese es el concepto de **Stateless Model**: 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. _Diagram: Stateless: en cada llamada la app reenvía todo el historial. La «memoria» de un chatbot vive en tu código, no en el modelo._ #### Stateless Model (sin memoria entre llamadas) - **Qué es:** El modelo no conserva nada entre solicitudes: cada llamada empieza en blanco. - **Cómo funciona:** Un chat «recuerda» la conversación solo porque la app reenvía todo el historial en cada llamada. - **Ejemplo:** La tercera pregunta de un chat llega al modelo junto con las dos primeras preguntas y ambas respuestas. - **Trampa:** Esperar que el modelo «recuerde» una regla de una sesión anterior — si no está en esta llamada, no existe. - **Relaciones:** Por eso la **Context Window** lo decide todo; un historial que crece lleva al **Context Budget** y al **Context Rot**. ### Context Window — 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. _Diagram: La ventana es todo lo que el modelo ve. Lo que queda fuera (un chat antiguo, la wiki de la empresa, una regla olvidada) no existe para él._ #### Context Window (la memoria de trabajo del modelo) - **Qué es:** Todo el texto que el modelo ve en una llamada: instrucciones, historial, datos, herramientas. - **Cómo funciona:** El modelo razona solo a partir de la ventana. La ventana tiene un tamaño máximo en tokens. - **Ejemplo:** Un bot de soporte no conoce la política de reembolsos a menos que su texto se haya puesto en la ventana de esta llamada. - **Trampa:** «El modelo debería saberlo» — no: si no está en la ventana, no existe para el modelo. - **Relaciones:** La ventana se construye mediante **Context Assembly**; su tamaño es el **Context Budget**. ### 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. _Diagram: El mismo modelo: con el contexto correcto — una gran respuesta; sin él — una respuesta inútil dicha con total seguridad. La palanca es la entrada, no el modelo._ > **La pregunta de encuadre:** «¿Está realmente en la ventana, ahora mismo, todo lo que el modelo necesita para responder bien — o estoy esperando que sepa algo que nunca le puse delante?» > El modelo es stateless y solo conoce su context window. La calidad de la salida la decide lo que ensamblas en esa ventana — así que lo que diseñas es la ventana, no el modelo. ## 2. Prompt frente a contexto Se habla de «prompt engineering», pero a medida que las apps se vuelven serias el verdadero oficio se desplaza — de redactar una petición a ensamblar la información correcta a su alrededor. Ese cambio es el corazón de este curso. ### Prompt Engineering vs Context Engineering — redacción frente a ensamblaje > Un abogado no gana por una frase ingeniosa, sino por entregar al juez exactamente los documentos correctos, en el orden correcto, sin nada irrelevante — el caso está en los papeles, no en el discurso. El **prompt engineering** trata de cómo redactas la instrucción. El **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 en 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 mala redacción; son el modelo sin un contexto que nunca se le dio. _Diagram: El prompt engineering es una parte de la ventana (la redacción). El context engineering son todas las entradas, ensambladas en cada llamada._ #### Context Engineering (frente a prompt engineering) - **Problema:** La calidad se «afina» con la redacción del prompt mientras al modelo le faltan los hechos reales. - **Idea:** Diseñar toda la ventana: reglas del sistema, hechos, historial, ejemplos, herramientas — en cada llamada. - **Ejemplo:** En lugar de «¡responde con detalle y con exactitud!» — poner en la ventana el documento correcto y la regla clave. - **Coste:** Hace falta código que ensamble la ventana, y disciplina sobre qué entra. - **Cuándo usarlo:** En cuanto una función con LLM supera un único prompt de demo. - **Relaciones:** El prompt engineering es una parte; en la práctica es **Context Assembly** y **Deliberate Assembly**. ### Missing Context — 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á desinformado. 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 ausente o equivocado** (**missing context**): no se recuperó el documento relevante, no se incluyó una regla clave, un historial obsoleto lo confundió. Antes de reformular nada, pregunta qué tenía realmente el modelo delante. Arreglar el contexto corrige más errores que arreglar la redacción. _Diagram: ¿Una mala respuesta? El instinto es reescribir el prompt. El primer paso correcto es mirar qué había en la ventana: un documento no recuperado, una regla no incluida, historial obsoleto._ #### Missing Context (contexto ausente o equivocado) - **Problema:** El modelo responde mal, y el equipo reescribe el prompt una y otra vez — sin efecto. - **Idea:** Primero mirar qué había en la ventana en la llamada fallida; solo después tocar la redacción. - **Ejemplo:** El bot cita un plan de precios antiguo: en la ventana estaba el historial obsoleto, no la lista de precios nueva. - **Causas típicas:** No se recuperó el documento, no se incluyó la regla, un historial obsoleto lo confundió. - **Relaciones:** Se arregla con **Context Assembly** y **Curation**; se verifica con **Context Evals**. ### El modelo es tan bueno como sus entradas > El mejor chef solo puede cocinar con los ingredientes que hay en la encimera — dale los equivocados y la destreza no salvará el plato. Un modelo capaz con mal contexto pierde frente a un modelo más débil con un contexto excelente. Por eso el context engineering, y no la elección del modelo, suele ser el lugar donde el esfuerzo rinde más: la salida del mismo modelo oscila enormemente según lo que le des. No consigues una mejor respuesta exigiendo con más fuerza — la consigues poniendo en la ventana un material mejor, más afilado, más relevante. Las entradas son la palanca. > **La pregunta del oficio:** «¿Estoy intentando arreglar esto reformulando el prompt — cuando el problema real es qué información entró o no entró en el contexto?» > El prompt engineering es la redacción; el context engineering es ensamblar la información correcta. En lo segundo vive la calidad — y la mayoría de las malas respuestas son contexto ausente, no mala redacción. ## 3. System prompt y ejemplos Parte de lo que entra en la ventana es duradero y parte es por petición, y unos pocos ingredientes concretos hacen la mayor parte del trabajo. Saber cuáles son hace que ensamblar contexto sea algo concreto. ### System Prompt — el comportamiento permanente frente a la petición puntual > La política permanente de un restaurante — «somos vegetarianos, cerramos a las diez» — frente al pedido concreto de esta noche. Una lo enmarca todo; el otro es lo que se pide. El **system prompt** contiene las instrucciones duraderas que valen para toda la interacción: el rol del modelo, las reglas que debe seguir, el tono, el formato de salida. El **mensaje del usuario** es la petición concreta. Poner tu persona, tus guardarraíles y tus reglas permanentes en el system prompt las mantiene estables mientras las preguntas del usuario varían. Es la diferencia entre lo que el modelo _es_ en cada llamada y lo que se le pide _esta_ vez. _Diagram: El system prompt es el mismo en cada llamada (rol, reglas, tono, formato). El mensaje del usuario cambia cada vez._ #### System Prompt (frente al mensaje del usuario) - **Qué es:** Instrucciones duraderas para toda la interacción: rol, reglas, tono, formato de salida. - **Frente a:** El **mensaje del usuario** — la petición concreta de esta vez. - **Ejemplo:** System: «Eres el bot de soporte de una tienda, responde breve, nunca prometas descuentos.» Usuario: «¿Dónde está mi pedido?» - **Trampa:** Si mezclas las reglas permanentes con la petición, «flotarán» de una pregunta a otra. - **Relaciones:** La primera pieza de **Context Assembly**; el formato de salida suele mostrarse mejor con **Few-shot**. ### Few-shot Prompting — muestra, no solo cuentes > Enseñar un formato mostrando tres ejemplos terminados es más rápido y claro que describirlo con palabras y confiar en que se lo imaginen bien. A menudo la forma más fiable de conseguir la forma de salida que quieres es **incluir unos pocos ejemplos** de entrada y de salida ideal directamente en el contexto. Es el patrón de **few-shot prompting**. El modelo imita ejemplos mucho mejor de lo que sigue una descripción abstracta. Dos o tres ejemplos afilados pueden superar a un párrafo de instrucciones, y suelen ser el arreglo más rápido cuando el modelo hace _casi_ lo que quieres pero no del todo. _Diagram: Izquierda — describir el formato con palabras y obtener «casi bien». Derecha — mostrar pares «entrada → salida ideal», y una entrada nueva recibe la misma forma._ #### Few-shot Prompting (ejemplos en el contexto) - **Problema:** El modelo casi lo logra, pero la forma de la salida se desvía. - **Idea:** Poner 2–3 pares «entrada → salida ideal» en la ventana — el modelo repite el patrón. - **Ejemplo:** Tres ejemplos de «reseña → JSON con sentimiento y tema», luego una reseña nueva — y la respuesta vuelve en el mismo JSON. - **Coste:** Los ejemplos consumen tokens en cada llamada — forman parte del **Context Budget**. - **Cuándo usarlo:** Cuando importa la forma y un párrafo de instrucciones no ayuda. - **Relaciones:** Una de las piezas de **Context Assembly**; complementa al **System Prompt**. ### Context Assembly — construir la ventana a partir de piezas > Preparar un maletín para una reunión: la agenda, los dos informes relevantes, una nota con las restricciones — elegidos a propósito, no todo tu archivador volcado dentro. 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 petición del usuario. Eso es **context assembly**: decidir — deliberadamente, cada vez — qué piezas entran y cuáles se quedan fuera. Pensar en la ventana como algo que _construyes_ a partir de piezas, y no solo como un prompt que escribes, es el cambio mental que hace que todo lo demás encaje. _Diagram: En cada llamada tu código elige las piezas — system prompt, historial, hechos, ejemplos, herramientas, petición — y ensambla con ellas la ventana._ #### Context Assembly (construir la ventana a partir de piezas) - **Problema:** La ventana es «solo un prompt», y lo que ande cerca acaba metido dentro. - **Idea:** Ensamblar la ventana en código a partir de piezas: system prompt, historial, hechos de RAG, ejemplos, herramientas, petición. - **Ejemplo:** Una pregunta sobre un pedido: las reglas del bot + los últimos 3 mensajes + los datos de este pedido + la pregunta. No todo el catálogo. - **Coste:** Cada pieza hay que elegirla y justificarla — eso es trabajo, no magia. - **Relaciones:** Piezas — **System Prompt**, **Few-shot**; filtro — **Curation**; hábito — **Deliberate Assembly**. > **La pregunta del ensamblaje:** «¿Cuáles son las piezas de esta ventana — reglas del sistema, historial, hechos recuperados, ejemplos, herramientas — y cada una aporta algo, o va solo de acompañante?» > El system prompt fija el comportamiento duradero; el mensaje del usuario es la petición; los ejemplos few-shot muestran la forma que quieres. Una ventana se ensambla con estas piezas, deliberadamente, en cada llamada. ## 4. La relevancia gana a la exhaustividad El mayor error de principiante en context engineering es pensar que más es mejor. Es justo al revés: cada token irrelevante que añades empeora activamente la respuesta. ### Relevance over Completeness — más contexto no es mejor contexto > Un informe de una página afilada vale más que un volcado de 200 páginas — el lector encuentra la señal en vez de ahogarse en ella, y decide más rápido y mejor. Es tentador meter en la ventana todo lo posiblemente relevante «por si acaso». Pero más no es mejor — normalmente es peor. El principio es **relevance over completeness** (relevancia sobre exhaustividad): cada token compite por la atención del modelo, y el material irrelevante **diluye** la señal. La habilidad está en seleccionar las pocas cosas que importan, no en incluir todo lo que podría importar. _Diagram: Izquierda — todo «por si acaso»: la señal se ahoga en ruido. Derecha — solo lo que necesita esta llamada: una respuesta afilada._ #### Relevance over Completeness (justo lo suficiente, no todo) - **Problema:** Todo entra en la ventana «por si acaso». - **Idea:** El objetivo no es darle al modelo todo — es darle justo lo suficiente. - **Ejemplo:** En lugar de toda la base de conocimiento — los tres párrafos que de verdad responden a esta pregunta. - **Coste:** Hay que saber seleccionar: buena recuperación, recortes, decisiones sobre qué descartar. - **Relaciones:** Por qué — **Context Dilution**; cómo — **Curation**; además ahorra **Context Budget**. ### Context Dilution — 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 propio ruido causa el error. Un contexto largo y relleno no solo desperdicia espacio; degrada activamente la calidad. Eso es **context dilution**: enterrada bajo material irrelevante, la atención del modelo se reparte demasiado, y en contextos largos esto **aumenta de forma medible la tasa de alucinaciones y errores** — usa con total seguridad algo que nunca estuvo pensado para ser la respuesta. Añadir contexto «por si acaso» puede ser justo lo que provoca el fallo. Menos contexto, más afilado, es un contexto más fiable. _Diagram: La atención del modelo se reparte entre el ruido — y se agarra a algo cercano pero equivocado, no al hecho correcto._ #### Context Dilution (señal ahogada en ruido) - **Qué es:** Los tokens irrelevantes diluyen la atención del modelo hacia la señal que importa. - **Qué arriesga:** En contextos largos sube la tasa de alucinaciones y errores: el modelo agarra la pieza equivocada. - **Ejemplo:** Veinte documentos parecidos en la ventana — el modelo cita el contrato vecino en vez del correcto. - **Trampa:** El contexto «por si acaso» parece inofensivo — y puede ser la causa misma del fallo. - **Relaciones:** Se arregla con **Curation**; una ventana mayor (**Long Context Windows**) no lo anula. ### Curation — curar sin piedad para esta llamada > Un buen editor no añade — recorta, y te entrega solo las líneas que se ganan su sitio en esta página. La disciplina es la **curación implacable**: para _esta_ llamada concreta, incluye las pocas cosas que el modelo realmente necesita y deja fuera todo lo demás. 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. _Diagram: El embudo de la curación: de todo lo que podría ayudar — solo los mejores fragmentos, la parte del historial que importa, y nada que ya haya cumplido su función._ #### Curation (curación implacable del contexto) - **Problema:** La ventana crece sola: lo que haya a mano se envía al modelo. - **Idea:** En cada llamada: solo los fragmentos más relevantes, el historial recortado, nada que ya haya cumplido su función. - **Ejemplo:** La búsqueda encuentra 50 fragmentos, los 3 mejores entran en la ventana; la salida de una herramienta que ya se digirió se descarta. - **Coste:** Puedes recortar algo necesario — por eso los cambios se comprueban con **Context Evals**. - **Relaciones:** Encarna **Relevance over Completeness**; hermana de **Trim & Summarize** y **Compaction**. > **La pregunta de la relevancia:** «¿Cada pieza de esta ventana es realmente relevante para la respuesta — o la estoy rellenando “por si acaso” y empeorando al modelo sin darme cuenta?» > 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 necesita esta llamada, y nada más. ## 5. La ventana es un presupuesto Más allá de la calidad, la ventana es un recurso finito y de pago. Tratarla como un presupuesto escaso y no como un vertedero infinito es lo que separa un juguete de un producto. ### Context Budget — la ventana es finita y cada token cuesta > Una maleta con límite de peso y una tarifa por kilo — metes lo que de verdad vas a necesitar, no todo tu armario, porque hay un tope duro y un precio. La context window tiene un tamaño máximo, y cada token que contiene 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 que rellenar; es un **context budget** que gastas. Una función que llena la ventana en cada solicitud es lenta y costosa a escala, incluso antes de que sufra la calidad. La ventana es un recurso que se asigna, no un vacío que se llena. _Diagram: La ventana tiene un tope duro, y cada token que contiene se paga en latencia y dinero — en cada llamada._ #### Context Budget (la ventana como recurso escaso) - **Qué es:** La ventana es un recurso finito y de pago: un tope de tamaño y un precio por cada token. - **Qué pagas:** Latencia y dinero — en cada llamada, multiplicado por el tráfico. - **Ejemplo:** Una función envía todo el historial y todo el manual de referencia con cada solicitud — lenta y cara antes incluso de que sufra la calidad. - **Cuándo pensarlo:** Desde el primer día, en cuanto la función llega a usuarios reales. - **Relaciones:** Se gasta con cabeza mediante **Trim & Summarize**; no lo anulan las **Long Context Windows**. ### Trim & Summarize — gastar la ventana en lo que se gana su sitio > Un presupuesto de viaje ajustado obliga a elegir de verdad — gastas en lo que importa para el viaje y prescindes del resto, y el viaje mejora gracias a esa disciplina. Tratar la ventana como un presupuesto cambia cómo construyes: **recortas** (**trim**) el historial de la conversación, **resumes** (**summarize**) los turnos antiguos en vez de arrastrarlos literalmente, y recuperas solo lo relevante ahora en vez de todo lo que tienes. Cada token debe ganarse su sitio. Es la misma disciplina que con el rendimiento o el caché — gastar el recurso escaso deliberadamente, en lo que de verdad mueve el resultado. _Diagram: Ocho turnos literales → un resumen corto de los seis primeros más los dos últimos turnos tal cual. Menos tokens, el mismo significado._ #### Trim & Summarize (recortar y resumir el historial) - **Problema:** El historial de la conversación crece, y cada turno viaja literal dentro de la ventana. - **Idea:** Los turnos antiguos como un resumen corto, los recientes tal cual; recuperar solo lo que hace falta ahora. - **Ejemplo:** En lugar de 40 mensajes de chat — un resumen «el cliente quiere devolver el pedido #…, ya envió una foto» + los últimos 2 mensajes. - **Coste:** Un resumen puede perder un detalle — compruébalo con evals. - **Relaciones:** Gasta con cabeza el **Context Budget**; en tareas largas se convierte en **Compaction**. ### Long Context Windows — una ventana mayor no acaba con la disciplina > Alquilar un camión más grande no significa que debas llenarlo de trastos — más capacidad es sitio para más cosas útiles, no licencia para dejar de empacar con cuidado. Los modelos siguen sacando ventanas de contexto cada vez mayores (**long context windows**) — un millón de tokens, o más — y es tentador pensar que el problema del presupuesto desaparece. No desaparece. Una ventana mayor sigue costando más y yendo más lenta por token, y, sobre todo, 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 sigues teniendo que gastar con cabeza. La disciplina de curar la ventana sobrevive a cualquier aumento de tamaño. _Diagram: Ambas ventanas contienen la misma pequeña cantidad de material útil. La grande solo tiene más sitio para el ruido — y sigues pagando por token._ #### Long Context Windows (ventanas de 1M+ tokens) - **Qué es:** Modelos con ventanas de un millón de tokens o más. - **La tentación:** Pensar que, como todo cabe, ya no hace falta curar. - **Ejemplo:** Volcar todo el repositorio en la ventana «porque cabe» — caro, lento, y el modelo se confunde. - **Trampa:** Una ventana más llena significa una **Context Dilution** más fuerte y más sitio para el **Context Rot**. - **Relaciones:** Sube el tope del **Context Budget**, pero no anula **Relevance over Completeness**. > **La pregunta del presupuesto:** «¿Estoy gastando los tokens de esta ventana en lo que de verdad mejora la respuesta — o la estoy llenando porque hay espacio, pagando en latencia, coste y atención diluida?» > 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 mayor acabe con la disciplina. ## 6. Context rot y deriva 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 del context engineering a escala. ### Context Rot — los contextos largos acumulan estado obsoleto y contradictorio > Un teléfono estropeado por una fila larga — al final el mensaje ha mutado sin hacer ruido, y todos repiten con total seguridad algo ligeramente equivocado. A lo largo de una conversación larga o de una tarea de agente de varios pasos, la ventana se llena de historial: turnos anteriores, salidas de herramientas, razonamientos a medias. Con el tiempo este montón se vuelve desordenado — hechos obsoletos junto a hechos frescos, contradicciones que se acumulan, el objetivo original que se sale de foco. La industria llama **context rot** a la degradación de calidad resultante: el mismo modelo se vuelve menos fiable a medida que su propio contexto acumulado se llena de ruido. _Diagram: Con cada paso la ventana crece: salidas de herramientas, hechos obsoletos, contradicciones. El objetivo se hunde al fondo y la fiabilidad cae._ #### Context Rot (deterioro del contexto, deriva) - **Qué es:** Degradación de la calidad a medida que el contexto acumulado se llena de ruido. - **Cómo se ve:** Hechos obsoletos junto a hechos frescos, contradicciones, el objetivo original que se sale de foco. - **Ejemplo:** En el paso 30 un agente se apoya en una versión de un archivo que él mismo reescribió en el paso 10. - **Trampa:** Una ventana mayor lo empeora: da más sitio para que la podredumbre se acumule. - **Relaciones:** Se arregla con **Compaction** y **Goal Re-anchoring**. ### Compaction — comprimir sobre la marcha > Un buen tomador de notas no conserva cada palabra de una reunión larga — la destila en decisiones y preguntas abiertas, y lleva adelante la conclusión, no la transcripción. El arreglo es **comprimir** activamente el contexto a medida que crece. Eso es **compaction**: resumir los pasos terminados en un estado corto y continuo en vez de arrastrar la transcripción completa, descartar las salidas de herramientas una vez extraído lo que importaba, mantener un resumen de trabajo ajustado en lugar del historial en bruto. El modelo lleva la conclusión, no cada palabra que la produjo. Así se mantienen coherentes los agentes de larga duración — gestionan su propio contexto en vez de dejar que se amontone. _Diagram: La transcripción en bruto (razonamiento + salidas de herramientas) se comprime en un resumen continuo: el objetivo, las decisiones tomadas, las preguntas abiertas, el paso actual._ #### Compaction (comprimir el contexto sobre la marcha) - **Problema:** Un agente de larga duración arrastra toda la transcripción y empieza a confundirse. - **Idea:** Los pasos terminados pasan a ser un estado actual breve; las salidas de herramientas ya digeridas se descartan. - **Ejemplo:** En lugar de 200 líneas de log de tests — «los tests fallan en `auth.ts`, causa: token caducado». - **Coste:** La compresión puede perder algo importante — escribe el resumen con cuidado. - **Relaciones:** **Trim & Summarize** para agentes; va de la mano con **Goal Re-anchoring** contra el **Context Rot**. ### Goal Re-anchoring — reanclar el objetivo > En una caminata larga y sinuosa revisas el mapa y el destino con regularidad — si no, te desvías, un giro de aspecto razonable tras otro, de adonde querías ir. Tras muchos pasos, el objetivo original se erosiona bajo el peso de todo lo ocurrido después. Así que lo **reanclas** (**re-anchoring**): vuelves a enunciar el objetivo y las restricciones clave en la ventana en cada paso, para que el modelo siga apuntando al blanco real en vez de derivar con la conversación. Una ventana mayor lo empeora, no lo mejora — da más sitio a que la deriva se acumule. Lo que mantiene una tarea larga en su curso es la gestión activa, no la capacidad en bruto. _Diagram: Sin ancla, cada paso parece razonable, pero la suma te lleva por mal camino. Con ancla, el objetivo vuelve a la ventana en cada paso._ #### Goal Re-anchoring (reenunciar el objetivo en cada paso) - **Problema:** Tras muchos pasos el objetivo se erosiona, y el modelo deriva con la conversación. - **Idea:** Volver a poner el objetivo y las restricciones clave en la ventana en cada paso. - **Ejemplo:** Cada paso del agente empieza con un bloque «Objetivo: pasar la API a v2 sin cambiar los métodos públicos.» - **Coste:** Un par de líneas de tokens por paso — barato comparado con la deriva. - **Relaciones:** Funciona junto con **Compaction**; la primera línea del resumen continuo es el objetivo. > **La pregunta de la deriva:** «En esta interacción larga, ¿sigue siendo la ventana un cuadro nítido y actual del objetivo — o se ha pudrido en un estado obsoleto y contradictorio sobre el que el modelo razona ahora?» > Los contextos largos se pudren — se acumula estado obsoleto y contradictorio y la calidad se degrada. Comprime los pasos terminados en un resumen continuo y reancla el objetivo, porque una ventana mayor solo da más sitio a la deriva. ## 7. Usarla bien El 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ó. ### Deliberate Assembly — construir la ventana a propósito, no por accidente > Un chef emplata un plato a propósito — cada elemento colocado por una razón — en vez de rascar sobre el plato lo que haya en la encimera. El hábito central es el **deliberate assembly**: tratar la ventana como algo que _construyes_ a propósito. Decide qué contiene el system prompt, qué historial conservar o resumir, qué recuperar, qué ejemplos mostrar, qué herramientas exponer. Muchas apps de LLM ensamblan el contexto por accidente — se envía lo que casualmente andaba por ahí. Construirlo a propósito, con cada pieza justificada, es buena parte de lo que separa una función fiable de una inestable. _Diagram: Por accidente — lo que haya a mano (el historial completo, todas las herramientas, logs antiguos). A propósito — cada pieza tiene una decisión y una razón._ #### Deliberate Assembly (construir la ventana a propósito) - **Problema:** El contexto se ensambla por accidente — y la función solo funciona a veces. - **Idea:** Tomar una decisión para cada pieza: system prompt, historial, recuperación, ejemplos, herramientas. - **Ejemplo:** El agente recibe las 5 herramientas que necesita en vez de las 40 — y un resumen corto en vez de todo el historial. - **Coste:** Tiempo dedicado a diseñar la ventana — se recupera en fiabilidad. - **Relaciones:** El hábito que se apoya en **Context Assembly**; se verifica con **Context Evals**. ### Context Evals — medir 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 de verdad, así que verifícalos: cuando ajustas lo que entra en la ventana — más ejemplos, otra recuperación, historial recortado — comprueba el efecto con **evals**, no te limites a mirar una salida a ojo. El context engineering sin medición es afinar por intuición, y así es como una adición «inofensiva» degrada la calidad sin ruido. Trata el contenido de la ventana como algo que se prueba, con la misma disciplina que el curso de evals. _Diagram: El bucle: cambiar el contexto → ejecutar los evals → comparar la puntuación → conservar o revertir. No “echar un vistazo a una respuesta y esperar”._ #### Context Evals (evals para cambios de contexto) - **Problema:** Un cambio en la ventana parece mejor «a ojo» — y en realidad empeoró la calidad sin ruido. - **Idea:** Cada cambio de contexto se ejecuta sobre un conjunto de pruebas fijo y se comparan las puntuaciones. - **Ejemplo:** Historial recortado a 5 mensajes — ejecutar 100 diálogos de prueba y ver si mejoró o empeoró. - **Coste:** Hay que montar un conjunto de pruebas y seguir ejecutándolo — eso es trabajo. - **Relaciones:** Comprueba **Curation**, **Trim & Summarize**, **Compaction**; en profundidad — el curso de evals. #### Antes de lanzar una función con LLM - **¿Está en la ventana todo lo que el modelo necesita** — o esperas que sepa lo que nunca le diste? - **System frente a usuario** — ¿reglas duraderas en el system prompt, la petición en el mensaje del usuario? - **¿Ayudarían los ejemplos** — ¿es un caso en el que few-shot gana a más instrucciones? - **¿Es relevante cada pieza** — o el relleno diluye la atención y aumenta los errores? - **¿Estás dentro del presupuesto** — recortando y resumiendo en vez de volcarlo todo? - **En tareas largas, ¿comprimes y reanclas** contra el context rot? #### Señales de que haces buen context engineering - Arreglas las 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 importa la forma. - **Curas sin piedad** — relevancia sobre exhaustividad — en vez de rellenar la ventana. - Tratas la ventana como un **presupuesto**, recortando y resumiendo en vez de volcar. - En tareas largas **comprimes y reanclas**, y **mides** los cambios de contexto en vez de adivinar. ### Cómo encaja todo > El mapa de metro completo: ahora ves dónde se cruzan las líneas. El modelo es stateless → así que la ventana lo decide todo → así que la ventana es lo que diseñas. La ventana se ensambla a partir de piezas (system prompt, ejemplos, hechos). Tres fuerzas la degradan: **la irrelevancia**, **el presupuesto** y **la podredumbre con el tiempo**. Cada una tiene su propia práctica: **curation**, **trim and summarize**, **compaction con re-anchoring**. Y los **evals** comprueban que cada cambio realmente ayudó. _Diagram: La cadena de los conceptos del curso: de un modelo stateless a diseñar la ventana, las tres fuerzas que la degradan, las prácticas contra ellas, y los evals como comprobación._ ## Hoja de referencia: los 18 conceptos ### La ventana - **Stateless Model** (sin memoria entre llamadas): No recuerda nada entre llamadas; la «memoria» de un chat es historial reenviado. - **Context Window** (memoria de trabajo): Todo el texto de una llamada — la única memoria de trabajo del modelo. Si no está en la ventana — no existe. ### El cambio - **Context Engineering** (frente a prompt engineering): No redactar la petición, sino ensamblar toda la información necesaria en la ventana. - **Missing Context** (contexto ausente o equivocado): La mayoría de las malas respuestas no son mala redacción — es lo que no estaba en la ventana. ### Ensamblar la ventana - **System Prompt** (frente al mensaje del usuario): Rol, reglas, tono y formato duraderos — frente a la petición puntual. - **Few-shot Prompting** (ejemplos en el contexto): Muestra 2–3 pares «entrada → salida» — el modelo repite la forma. - **Context Assembly** (construido a partir de piezas): La ventana se ensambla en código en cada llamada: reglas, historial, hechos, ejemplos, herramientas, petición. ### Relevancia - **Relevance over Completeness** (justo lo suficiente): Darle al modelo no todo, sino justo lo suficiente. - **Context Dilution** (ahogado en ruido): Los tokens irrelevantes reparten la atención y aumentan las alucinaciones. - **Curation** (selección implacable): Solo los mejores fragmentos, el historial recortado, nada que ya haya cumplido su función. ### Presupuesto - **Context Budget** (recurso escaso): La ventana es finita; cada token cuesta latencia y dinero en cada llamada. - **Trim & Summarize** (recortar y resumir el historial): Los turnos antiguos como resumen, los recientes tal cual; cada token se gana su sitio. - **Long Context Windows** (1M+ tokens): Más sitio no es permiso para volcar; el ruido y el precio siguen ahí. ### Podredumbre y deriva - **Context Rot** (deterioro del contexto): Un contexto largo acumula estado obsoleto y contradictorio — la calidad cae. - **Compaction** (comprimir sobre la marcha): Los pasos terminados pasan a un resumen continuo breve en lugar de la transcripción. - **Goal Re-anchoring** (reenunciar el objetivo): Volver a poner el objetivo y las restricciones en la ventana en cada paso. ### Práctica - **Deliberate Assembly** (a propósito): Cada pieza de la ventana tiene una decisión y una razón — no «lo que hubiera a mano». - **Context Evals** (medir los cambios): Cada cambio en la ventana se comprueba con pruebas, no a ojo. > El context engineering es el ensamblaje deliberado de la ventana: las reglas correctas, los hechos correctos, los ejemplos correctos, curados por relevancia, dentro del presupuesto y gestionados contra la podredumbre — construida a propósito y medida, no escrita y esperada. Fin del curso exprés · 7 capítulos · 18 conceptos Lo que sigue es la práctica: toma una función con LLM que a veces da malas respuestas y, antes de tocar la redacción del prompt, registra exactamente qué había en la ventana en una llamada fallida — normalmente encontrarás contexto ausente, obsoleto o irrelevante, no mala redacción. Después arregla el ensamblaje: añade el hecho que faltaba, quita el ruido, resume el historial. La disciplina encaja en el momento en que una ventana mejor construida gana a un prompt más ingenioso. Pero mantén una idea por encima de todas: el modelo solo sabe lo que está en la ventana. Deja de intentar sacarle inteligencia a base de insistir, y empieza a diseñar lo que llega a ver — ahí estuvo la calidad todo el tiempo.