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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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ó.