- La discusión está pasando de la "ingeniería de prompts" a una etapa más avanzada: la "ingeniería de contexto"
- El contexto no es solo una frase de prompt, sino toda la información que un LLM puede ver antes de generar una respuesta (instrucciones, historial de conversación, memoria a largo plazo, información externa, herramientas disponibles, etc.)
- El éxito o fracaso de un agente ahora depende más de la calidad del contexto que del rendimiento del modelo
- Los agentes avanzados integran distintos contextos, como el calendario del usuario, correos anteriores y contactos, para generar respuestas más cercanas a la resolución de problemas reales
- La ingeniería de contexto es un diseño dinámico de sistemas adaptado a cada situación, un proceso para entregar al LLM la información y las herramientas correctas en el momento preciso
¿Qué es Context Engineering?
- En el campo de la IA, el término "ingeniería de contexto" se está difundiendo rápidamente en los últimos tiempos
- Mientras que la "ingeniería de prompts" tradicional se enfocaba en diseñar una sola pregunta o instrucción, la ingeniería de contexto es un enfoque más amplio y poderoso
- Tobi Lutke la define como "el arte de proporcionar todo el contexto para que el LLM pueda resolver una tarea de forma confiable"
Elementos clave del contexto
- En un sistema de agentes, que funcione con éxito o no depende en gran medida de qué información se incluye en la memoria de trabajo (working memory)
- La mayoría de las fallas de los agentes no se deben al modelo, sino a la falta de contexto adecuado
Componentes del contexto
- Prompt/instrucciones del sistema: instrucciones base, ejemplos y reglas que definen el comportamiento del modelo
- Prompt del usuario: la solicitud o pregunta inmediata del usuario
- Estado/historial de conversación: el flujo de la conversación hasta el momento y la información contextual
- Memoria a largo plazo: conversaciones anteriores de múltiples pasos, preferencias del usuario, resúmenes de proyectos pasados y conjunto de información que el modelo aprende para recordar a largo plazo
- RAG (generación aumentada por recuperación): información reciente y altamente relevante obtenida de documentos externos, bases de datos, APIs, etc.
- Herramientas disponibles: funciones que el modelo puede invocar y definiciones de herramientas integradas (por ejemplo:
check_inventory, send_email, etc.)
- Salida estructurada: definición del formato de respuesta que el modelo debe seguir (por ejemplo: JSON)
Por qué importa el contexto
- En la práctica, el factor que hace posible crear agentes de IA efectivos no es un código complejo ni la calidad del modelo, sino qué tan bien se proporciona el contexto adecuado
- Mientras que un agente simple "de demostración" solo recibe la solicitud del usuario y da una respuesta básica, un agente "casi mágico" considera un contexto rico para generar respuestas mucho más útiles y humanas
- Comparación
- Agente de baja calidad (demo): solo mira la solicitud simple y produce respuestas rígidas. Ej.) ante el correo "¿Tienes tiempo mañana?", responde de forma mecánica con algo como "Sí, mañana puedo. ¿Qué hora te conviene?"
- Agente de alta calidad (casi mágico): puede aprovechar su calendario, el historial de correos previos, la identidad de la otra persona y las opciones de invocación de herramientas necesarias para generar una respuesta natural y adaptada al contexto. Ej.) "Mañana tengo la agenda llena, pero el jueves por la mañana estoy libre, así que ya te envié una invitación. Avísame si te funciona"
- Así, el factor de éxito no está en el algoritmo ni en el modelo, sino en proporcionar el contexto correcto para la tarea
- La mayoría de las fallas de los agentes de IA son resultado no del modelo, sino de un fracaso en el diseño del contexto
Evolución de la ingeniería de prompts a la ingeniería de contexto
- Si la ingeniería de prompts se centra en optimizar instrucciones de una sola línea de texto, la ingeniería de contexto abarca un rango mucho más amplio de información, herramientas y diseño estructural
- La ingeniería de contexto es la "capacidad profesional de diseñar y construir sistemas que proporcionen de forma sistemática la información y las herramientas necesarias, en el formato y momento correctos, para que el LLM pueda completar una tarea"
Características de la ingeniería de contexto
- Diseño del sistema completo: el contexto no es una simple plantilla de prompt, sino el resultado de todo el sistema que opera antes de invocar al LLM
- Generación dinámica: selección y procesamiento en tiempo real de información diversa, como calendario/correo/búsqueda web, según la tarea
- Entrega de información y herramientas en el momento y lugar adecuados: el principio "Garbage In, Garbage Out"; es importante que al modelo no le falte información ni reciba datos innecesarios
- Importancia de la claridad del formato: al cargar información, no basta con listarla de forma dispersa; hace falta resumirla y estructurarla, y también comunicar con claridad cómo se usan las herramientas
Conclusión
- La esencia de desarrollar agentes de IA potentes y confiables no está en un "prompt mágico" ni en el modelo más reciente, sino en la ingeniería de contexto (diseñar y proporcionar el contexto)
- Esto va más allá de un simple problema técnico: requiere una capacidad integral de diseño de sistemas, incluyendo información, herramientas y definición de salidas estructuradas alineadas con las necesidades y objetivos del negocio
- La clave es proporcionar la información adecuada en el formato correcto y en el momento preciso para que el LLM pueda completar la tarea
Material de referencia
2 comentarios
Parece mucho que solo le cambiaron el nombre.
Opiniones de Hacker News
Hace poco escribí en mi blog sobre este tema; pueden ver mi artículo - Context Engineering
Creo que los textos de Drew Breunig tratan este tema de forma realmente fantástica
El momento coincidió con que estaba circulando el meme de “context engineering”, pero en realidad era un trabajo sin relación con ese meme
El artículo How Long Contexts Fail - por qué fallan los contextos largos explica de varias maneras cómo los contextos largos causan problemas y cómo ocurre lo que llaman “context rot”
El artículo How to Fix Your Context - cómo arreglar tu contexto le pone nombre a varias técnicas como Tool Loadout, Context Quarantine, Context Pruning, Context Summarization y Context Offloading, y propone formas de resolver el problema
Creo que de verdad vale la pena leer el post de Drew Breunig
Esto es muy importante no solo para construir tus propios agentes, sino también al usar agent coding ahora mismo
Todo indica que estas limitaciones y formas de comportamiento seguirán por un tiempo
Tengo curiosidad por ver quién será el primero en desarrollar un Logic Core que automatice al ingeniero de contexto
Yo también creo que esto es una “habilidad de un mes”
Al final desaparecerá pronto, como tantas otras modas
En la investigación sobre LLM, estos problemas se consideran producto de los LLM actuales
Ya se está investigando cómo usar millones de herramientas al mismo tiempo y cómo tener contextos largos estables
En adelante, salvo casos especiales que requieran conexión con otros proveedores, probablemente en la mayoría de los casos bastará con un solo agente
Quienes diseñen sistemas de agentes del futuro basándose en los LLM actuales podrían terminar como LangChain
Igual que pasó con LangChain, hecho para GPT-3, que quedó obsoleto muy rápido con GPT-3.5
Para cualquiera que haya usado un LLM o entienda cómo funciona, esto es bastante obvio
También era evidente que la “habilidad” del prompt engineering no iba a durar mucho como idea central
Básicamente se trata de darle entradas (contexto) y acciones (salida) al LLM, y para eso hace falta mucho trabajo de pipeline
Estoy de acuerdo con la conclusión de que “construir agentes de IA potentes y confiables se aleja de encontrar prompts mágicos o actualizaciones del modelo”
Es correcto enfocarse más en el “context engineering que proporciona la información y las herramientas adecuadas, en el formato y momento adecuados”
Pero si ese “formato adecuado” y ese “momento adecuado” no están definidos de manera esencial, ¿no seguimos persiguiendo una “solución mágica”?
Si la “información adecuada” es “la información que hace que el LLM dé una respuesta suficientemente correcta”, entonces en esencia no veo diferencia con el prompt engineering
Con estas máquinas no deterministas, al final no parece haber muchas heurísticas confiables aparte de “probar prompts y ver qué pasa”
Al final sigue siendo una forma interminable de pensamiento mágico
Aunque ahora le cambien el nombre de “prompt engineering” a “context engineering”, sigue siendo andar moviéndole cosas para encontrar algo que funcione en un espacio incierto
En esencia es overfitting
Eso es lo que siempre ha sido el prompt engineering
El problema es que “el formato adecuado y el momento adecuado” no están definidos de manera esencial
Gran parte de los consejos sobre “cómo usar bien la IA” parten justamente de ahí
Al final se siente como tocar tambores y hacer rituales chamánicos
En los marcos teóricos más recientes, este proceso se divide en dos etapas: exploratory y discovery
La etapa exploratory puede verse como una especie de dispositivo de dispersión de materia suspendida en el aire
Introduces a alta velocidad una sustancia marcadora fácilmente identificable (normalmente se usa una analogía con heces)
La etapa de discovery se conceptualiza como el análisis del patrón de dispersión
Resumiendo ambas etapas: “prueba algo al azar” y luego “revisa el resultado”
Ahora que todo el mundo se dio cuenta de que el “prompt engineering” no era una gran habilidad, se siente como si en la industria de la IA no dejaran de mover la meta
La nueva habilidad al final es “programación”
La misma habilidad de antes
Para entender estas cosas, hay que escribir programas uno mismo
Vas entendiendo más al escribir programas para entrenar LLM, correr inferencia y analizar su comportamiento
Al inicio yo tenía una teoría y expectativas sobre los resultados, pero después de entrenar LLM de varias maneras terminé con resultados y convicciones completamente distintos
El proceso de implementar herramientas por cuenta propia es lo que realmente marca la diferencia
Yo también solo tengo experiencia intermedia en programación de machine learning, pero creo que haber construido personalmente un compilador de complejidad media es clave para obtener buenos resultados en sistemas complejos
¿Cómo creen que Karpathy llegó a entender esto?
La respuesta está en el blog de Karpathy
Es como el consejo de que, para entender compiladores, tienes que escribir uno
Técnicamente es cierto, pero la mayoría no quiere llegar tan profundo
Siento que esta discusión se parece cada vez más a los foros de juegos tipo WoW, donde los jugadores prueban estrategias y discuten entre ellos con un lenguaje grupal extraño
Las llamadas estrategias casi siempre se encuentran por prueba y error, y se discuten con un lenguaje que solo entiende ese grupo
La programación también se está adaptando cada vez más a una era de gamificación
Y los power users terminan vendiéndoles estrategias falsas a principiantes o a directivos demasiado gamer
De hecho, en modas anteriores de software empresarial pasó algo muy similar una y otra vez
La diferencia ahora es que esa “moda impulsada por power users” se metió hasta zonas de influencia, control y flujo de trabajo que antes pertenecían a los desarrolladores, o sea, a los builders
Lo que sienten hoy muchos desarrolladores probablemente no es muy distinto de lo que sintieron antes personas de QA, SRE o CS cuando les imponían tooling o prácticas porque “¡esto ahora es la tendencia!”
Conclusión:
“Construir agentes de IA potentes y confiables no depende de prompts mágicos ni de actualizaciones del modelo, sino de un context engineering que entregue la información y las herramientas correctas, en el formato y el momento correctos, para el uso de negocio”
En realidad, este mismo principio aplica igual a los humanos
Si les das la información correcta en el momento adecuado, también resuelven mejor
No me gusta esta tendencia de comparaciones superficiales entre machine learning y humanos
No aporta mucha intuición y casi nunca es realmente correcta
Al final se trata de encontrar y presionar de forma efectiva el botón objetivo dentro del entorno
No es tan diferente de la ingeniería de software tradicional
Solo que el resultado es más no determinista
Yo siempre les pido a los responsables de UX y producto explicaciones constantes sobre “mocks, requisitos, criterios de aceptación, ejemplos de input/output y por qué esta función es importante”
A menos que puedas escanear el cerebro de alguien y extraer lo que quiere, en la práctica es indispensable que explique bien lo que quiere
No es algo que pueda dejarse solo a la ‘intuición’
La clave no es más contexto, sino mejor contexto
(ejemplo clásico: el problema X-Y)
Incluso si le das un contexto excelente a un LLM moderno, igual falla
En nuestra empresa llevamos más de dos años explorando esto a fondo
Me sorprende el nivel de fe ciega en la idea de que “el contexto es la respuesta”
Llega un punto en que pienso que hacer el trabajo directamente sin IA es más rápido
Al menos eso deja una lección útil, en vez de pasar horas generando contexto para el LLM
Me interesan los casos donde un LLM falla incluso con suficiente contexto
Estaría bueno que compartieras ejemplos concretos
Encontrar el prompt mágico nunca fue realmente lo que era el “prompt engineering”
En esencia siempre fue “context engineering”
Muchos autoproclamados expertos en IA vendieron esto como prompt engineering, pero en realidad no entendían bien el fondo
RAG (retrieval-augmented generation) no es un concepto que haya aparecido de repente este año
También se están popularizando cada vez más herramientas que envuelven know-how complejo sobre embeddings, vector DB, graph DB, etc.
Las grandes plataformas también están mejorando herramientas relacionadas y ofreciendo ecosistemas más amplios
Siempre se siente como crear un concepto nuevo para el mismo problema y solo cambiarle el nombre
Al final es repetir rituales chamánicos de tocar tambores frente a una fogata y recitar encantamientos
Se sentía como invocar un demonio, esperando que obedeciera bien mis órdenes si pronunciaba el conjuro correcto con las palabras correctas
Dentro de mí chocaban el ingeniero que quiere confiabilidad, repetibilidad y cobertura fuerte de pruebas, y la complejidad incontrolable de todo esto
De verdad respeto a la gente que hace demos grandes con sistemas así
Me recuerda a la época de las demos de investigación de vulnerabilidades de seguridad
Por más preparado que estuvieras, el resultado podía torcerse en cualquier momento en vivo, y recuerdo sudar muchísimo durante las presentaciones
Esta perspectiva se parece muchísimo a mi experiencia
Cuando meto contexto en un LLM, suelo usar la pregunta: “¿un humano podría resolver esto solo con esta información?”
Cuando antes construíamos un producto de text2SQL, si el modelo fallaba, incluso un analista de datos real respondía cosas como “ah, esa tabla es vieja; ahora usamos esta otra”
Al final, si al LLM le falta el contexto que necesita un ‘analista humano’, se equivoca
Si hay algo que falta en este tema, es precisamente “evaluations”
Todavía me sorprende ver proyectos de IA sin evaluaciones o con evaluaciones hechas al aventón
Las evaluaciones son incluso más importantes que los tests en la ingeniería tradicional
El conjunto de evaluación no tiene que ser grande; basta con que cubra bien el dominio del problema
Sin eso, todo no pasa de ser una “suposición”
Y además, yo también me pregunto muchas veces: “¿un humano podría resolver esto solo con esta información?”
Me ha pasado esperar que un LLM resolviera problemas que ni un humano podría resolver
Una ley clásica de la programación tradicional
“Si dejas que los programadores codifiquen en inglés, descubres que en realidad tampoco saben escribir bien en inglés”
Es medio broma, pero tiene bastante de verdad
La mayoría del lenguaje natural no es tan claro
Si puedes expresar con absoluta precisión lo que quieres en inglés, entonces bien podrías haberlo escrito directamente en un lenguaje que la máquina pueda interpretar
Si haces una pregunta de sí o no, tienes 50% de probabilidad de obtener una respuesta falsa
Tiene esa característica
Yo suelo hacer que el modelo empiece haciéndose este tipo de preguntas antes de ponerse realmente a trabajar
Por ejemplo, si hay algo incierto, le doy instrucciones para que pregunte y para que pida ejemplos de patrones de código ya usados
Lo guío para que pueda tomar como ejemplo plantillas que ya están en uso
A quienes juegan a ser data scientists no les gustan las evaluaciones
Por eso casi no existen fuera de los productos que realmente monetizan
Porque decir “el emperador está desnudo” no deja dinero
Cuando de verdad hace falta en trabajo real, la parte de evaluación sí entra necesariamente