Aprender a detectar la degradación de contexto en modelos de IA solo se logra provocándola tú mismo. En este taller vas a romper una sesión de forma deliberada, diagnosticar qué falló y probar cuatro mitigaciones para ver cuál funciona mejor. Es un recurso pensado para quienes trabajan con conversaciones largas y quieren entender por qué la IA empieza a ignorar instrucciones.
¿Cómo se provoca la degradación en una sesión de IA?
La idea es simple pero poderosa: necesitas una sesión que se rompa de verdad, no una simulación. Para eso, abres una sesión nueva y estableces tres reglas verificables, sin ambigüedad [00:39].
En el ejemplo del taller, las tres reglas fueron:
- Responder siempre en español.
- Entregar todo resultado numérico en formato de tabla.
- Nunca inventar cifras que no se hayan dado.
Después trabajas de verdad durante 30 o 40 turnos sobre un caso real, o pegas un prompt preparado que fuerce al modelo a ejecutar esa cantidad de tareas de golpe [01:15]. Puedes pegar documentos largos, pedir análisis, cambiar de tema y regresar. El paso final: sin recordarle nada, haces una pregunta que dependa de las tres reglas al mismo tiempo [01:55].
¿Qué es la degradación de contexto en IA? Es cuando el modelo empieza a olvidar o ignorar las instrucciones iniciales conforme la conversación se alarga, perdiendo reglas que definiste al principio.
¿En qué momento el modelo empieza a romper las reglas?
En el taller, un detalle clave es pedir que cada 10 tareas el modelo se detenga y espere [02:20]. Así puedes comparar el resultado de las primeras 10 contra las siguientes y ver en vivo cómo empieza a alucinar.
En las primeras tareas, el modelo cumplió: respondió en español, usó tablas y armó el manual completo con sus siete secciones [03:20]. Pero pronto se quedó corto en las respuestas y, en un punto, declaró que "todas las cifras del manual son inventadas", rompiendo la regla de no inventar datos [04:15].
Otro hallazgo importante: la instrucción decía "empieza con la tarea uno", y el modelo entendió que solo debía hacer la tarea uno [04:35]. La lección es clara: describe con precisión lo que quieres. Una mejor redacción habría sido "ejecuta cada una de las tareas de manera ordenada".
El quiebre más revelador llegó en el bloque de la tarea 15 en adelante. En la tarea 25 se pidió deliberadamente una respuesta en inglés dentro de una instrucción [06:00]. Ahí el modelo empezó a contestar en inglés y solo retomó el español en la tarea 18 [07:05]. En teoría, las reglas de sesión deberían pesar más que el prompt de la tarea, pero no fue así.
¿Qué es la curva en U en el contexto de la IA? Es el patrón donde el modelo recuerda mejor lo que está al inicio y al final de la conversación, y olvida lo del medio. En este caso, la regla final fue la primera en romperse.
¿Qué pasa cuando la herramienta compacta la conversación sola?
Aquí hay una trampa que puede confundirte. Varias herramientas resumen la conversación por su cuenta cuando se acercan al límite, y eso puede ocurrir justo a la mitad de tu experimento [07:45].
Cuando eso sucede, a veces las reglas sobreviven, pero no porque el contexto haya aguantado, sino porque la compactación automática las rescató en el resumen. Si te pasa:
- Anota en qué turno apareció la compactación.
- Trata esa corrida como una quinta mitigación que no elegiste.
- Corre la primera instrucción de nuevo en una herramienta que no compacte sola, otro modelo o una sesión más corta y densa, para tener tu línea base limpia [08:20].
Esto enseña algo del mundo real: cuando el sistema te ayuda sin avisarte, medir se vuelve más difícil. Por eso conviene saber qué hace tu herramienta por debajo.
¿Cómo diagnosticar qué se rompió en la sesión?
Para diagnosticar usamos las tres preguntas guía de la clase anterior [08:55]:
- ¿Cuál regla se perdió? Casi siempre es la del inicio, aunque aquí fue la final por la curva en U.
- ¿Se contradijo o solo olvidó? Contradecirse es choque, olvidar es degradación pura. El arreglo depende de cuál sea.
- ¿Repitió algo que ya no funcionaba? Eso es distracción.
Cada respuesta apunta a un tipo distinto de problema, y por eso conviene diagnosticar antes de arreglar.
¿Cuál es la mejor forma de aplicar mitigaciones sin confundirte?
La regla de oro es medir cada mitigación por separado. Si aplicas las cuatro juntas, nunca vas a saber cuál sirvió de verdad [09:35].
El reto es repetir el taller completo con una vuelta más para llevarlo a tu día a día:
- Documenta tu experimento en una tabla con tres columnas: mitigación aplicada, reglas que sobrevivieron y costo en esfuerzo.
- Elige una sola mitigación como práctica por default, la de mejor relación entre resultado y esfuerzo.
- Escríbela como una regla operativa que le puedas dar a un compañero.
Un buen ejemplo de regla operativa sería: "en este equipo, las reglas de formato viven en el proyecto, nunca en el chat" [10:35]. Esa regla va directo a tu documento de mantenimiento y es de las piezas que más se agradecen en un handoff, porque le ahorra a la siguiente persona todo este taller.
¿Ya hiciste tu propio experimento? Déjame en los comentarios algún hallazgo interesante que hayas tenido durante la ejecución.