Degradación del contexto en los LLM: lo que realmente muestran los estudios sobre contexto largo

Una nueva publicación en r/MachineLearning sostiene que las sesiones largas con LLM se deterioran antes de alcanzar sus límites anunciados, pese al tranquilizador tamaño de las ventanas de contexto modernas. La publicación vincula ese problema con las sesiones prolongadas de análisis y programación, en las que las decisiones anteriores siguen siendo visibles, pero pierden influencia.

Esa afirmación cuenta con respaldo general de varios estudios, aunque los detalles importan. Los modelos no olvidan simplemente todo después de una cantidad fija de tokens. Su rendimiento cambia según la longitud del contexto, la posición de la evidencia, la dificultad de la tarea, el solapamiento léxico y el material circundante.

Por tanto, el conflicto real no es contexto corto frente a contexto largo. Es capacidad frente a uso fiable. Un modelo puede aceptar un documento sin utilizar todas sus partes con la misma eficacia.

Esta distinción presiona a desarrolladores, investigadores y trabajadores del conocimiento que tratan el historial de conversación como memoria de trabajo duradera. También cuestiona las interfaces de producto que presentan un único chat continuo como una única cadena continua de razonamiento.

La publicación de Reddit convirtió un fallo discreto en una cuestión de flujo de trabajo

El hecho inmediato es que una discusión de investigación se está convirtiendo en una advertencia práctica sobre cómo las personas gestionan sesiones largas de IA.

El 2 de agosto de 2026, un usuario envió una publicación sobre degradación del contexto a r/MachineLearning. Su descripción enlazada afirma que las sesiones largas pueden deteriorarse mucho antes de alcanzar un límite de tokens.

La publicación no establece un nuevo benchmark. Presenta un problema de investigación ya existente en torno a una experiencia familiar: un asistente empieza siendo preciso y luego pierde gradualmente restricciones, prioridades o razonamientos previos.

Esta experiencia puede adoptar muchas formas. Un asistente de programación puede reintroducir una arquitectura descartada. Un asistente de investigación puede citar una suposición obsoleta después de que el usuario la corrigiera. Una herramienta de análisis puede conservar hechos individuales mientras pierde la lógica que los conecta.

Estos fallos son difíciles de diagnosticar porque el chat sigue pareciendo intacto. Los mensajes anteriores permanecen en pantalla, y el asistente a menudo puede citarlos cuando se le solicita. Sin embargo, una recuperación precisa no garantiza un razonamiento correcto.

Una ventana de contexto es la secuencia máxima de tokens que un modelo puede aceptar durante una solicitud. No es una promesa de que cada token aceptado reciba el mismo peso práctico.

Esta diferencia se parece a la capacidad de almacenamiento frente a la atención de trabajo. Un escritorio abarrotado puede contener todos los documentos relevantes, pero el documento bajo una gran pila sigue siendo más difícil de utilizar. La analogía es imperfecta, ya que los transformers no piensan como las personas, pero capta el riesgo operativo.

La publicación también llega después de que las ventanas de contexto se convirtieran en una métrica visible de producto. Las ventanas más grandes admiten repositorios, libros, historiales de reuniones y colecciones de artículos de investigación. Esa capacidad es útil, pero puede animar a los usuarios a mantener una sesión activa indefinidamente.

Una sesión larga acumula entonces varios tipos de fricción. Contiene enfoques abandonados, instrucciones repetidas, resultados intermedios, correcciones y datos obsoletos. Cada elemento sigue estando potencialmente disponible, pero su presencia continuada no lo hace igual de útil.

La degradación resultante rara vez es un colapso claro. Las respuestas pueden seguir siendo fluidas mientras se vuelven menos fieles a las decisiones rectoras del proyecto. Eso hace que el fallo de contexto sea más peligroso que un mensaje de error explícito.

El registro de investigación respalda la advertencia general. Sin embargo, no respalda una afirmación universal de que un número concreto de turnos marque el punto de fallo. Ningún artículo establece que el vigésimo mensaje, por ejemplo, se vuelva efectivamente inaccesible en todos los modelos y tareas.

Lo que cambió es el encuadre. La debilidad del contexto largo está pasando de la discusión sobre benchmarks al diseño ordinario de flujos de trabajo. La pregunta ya no es si un modelo acepta la transcripción. Es si la transcripción sigue siendo un entorno de razonamiento fiable.

Los estudios muestran varios fallos, no un único precipicio de contexto

La degradación del contexto es un conjunto de debilidades medibles, no un único umbral en el que un LLM pierde de repente la memoria.

El resultado posicional más citado procede del artículo de 2024 Lost in the Middle. Sus autores probaron respuestas a preguntas con múltiples documentos y recuperación de pares clave-valor en distintas posiciones de la evidencia.

El rendimiento solía ser mayor cuando la información relevante aparecía cerca del principio o del final. Descendía cuando la misma información aparecía en el medio, incluso con modelos diseñados para contexto largo.

Este patrón suele describirse como una curva de rendimiento en forma de U. La curva muestra sensibilidad a la posición, pero no significa que todos los modelos ignoren siempre el centro. Los resultados varían según el modelo, la longitud de la entrada, la tarea y la construcción del prompt.

La posición es solo una parte del problema. RULER amplió la recuperación simple de aguja en un pajar con múltiples agujas, seguimiento de varios saltos y tareas de agregación.

Sus investigadores evaluaron 17 modelos de contexto largo en 13 tareas. Aunque cada modelo evaluado afirmaba admitir al menos un contexto de 32.000 tokens, solo la mitad mantuvo un rendimiento satisfactorio a esa longitud.

Por ello, el benchmark RULER expuso una diferencia entre encontrar una cadena literal y utilizar información distribuida. Un modelo puede superar una prueba de recuperación sencilla mientras tiene dificultades con la agregación o el razonamiento encadenado.

NoLiMa llevó esa distinción más lejos. Redujo el solapamiento léxico entre la pregunta y la evidencia relevante, obligando a los modelos a inferir una asociación en lugar de emparejar palabras similares.

Los investigadores evaluaron 13 modelos que afirmaban admitir al menos 128.000 tokens. A 32.000 tokens, 11 modelos cayeron por debajo de la mitad de su sólida referencia de contexto corto.

GPT-4o siguió siendo uno de los sistemas más sólidos en esa prueba. Aun así, su resultado reportado descendió de una referencia de contexto corto del 99,3 % al 69,7 % con 32.000 tokens.

Estos resultados de NoLiMa importan porque el análisis ordinario rara vez ofrece una alineación perfecta de palabras clave. Una decisión de proyecto y una pregunta posterior pueden expresar el mismo concepto con vocabulario diferente.

La conversación también introduce complicaciones temporales. Un usuario puede expresar una preferencia, revisarla más tarde y luego formular una pregunta que requiera que el sistema identifique la versión actual.

LongMemEval fue diseñado en torno a ese problema de memoria más amplio. Incluye 500 preguntas que prueban extracción, razonamiento entre múltiples sesiones, razonamiento temporal, conocimiento actualizado y abstención apropiada.

Sus autores informaron de que los asistentes comerciales de chat y los modelos de contexto largo experimentaron una caída global de precisión del 30 % a lo largo de interacciones sostenidas. El resultado se refiere a un benchmark concreto, no a todas las conversaciones reales.

En conjunto, estos estudios separan al menos cuatro problemas. Los modelos pueden tener dificultades para localizar evidencia, conectar evidencia relacionada de forma indirecta, priorizar la versión actual o razonar correctamente después de recuperar el material adecuado.

Ese último fallo es especialmente importante. Significa que una mejor búsqueda por sí sola no resuelve el problema del contexto largo.

Por qué una recuperación perfecta sigue sin proteger el análisis largo

Un modelo puede recuperar la evidencia correcta y aun así razonar peor porque la entrada total se ha vuelto más larga.

Un preprint de octubre de 2025 aisló esta posibilidad en cinco modelos abiertos y cerrados. Los investigadores probaron matemáticas, respuesta a preguntas, programación y una tarea sintética de suma de variables.

Construyeron entradas más largas mientras mantenían controladas la evidencia y la pregunta. Las pérdidas de rendimiento reportadas oscilaron entre el 13,9 % y el 85 %, a pesar de una recuperación perfecta de la evidencia relevante.

Los autores también sustituyeron prosa irrelevante por espacios en blanco mínimamente distractores. Algunos modelos siguieron degradándose. Después enmascararon tokens irrelevantes en experimentos con modelos abiertos, y la degradación se mantuvo.

Su estudio sobre recuperación perfecta es un preprint y no un consenso científico consolidado. Sus experimentos son sintéticos, y su muestra de modelos no representa todos los sistemas actuales.

Aun así, el resultado cuestiona una explicación conveniente. Los fallos de contexto no siempre pueden atribuirse a que el modelo seleccione el pasaje equivocado entre material ruidoso.

Los investigadores también colocaron la evidencia inmediatamente antes de la pregunta. Las entradas más largas siguieron perjudicando el rendimiento en varios entornos. Ese hallazgo debilita la afirmación de que simplemente repetir la instrucción más reciente siempre repara una conversación saturada.

Un preprint posterior de 2026 examinó fallos posicionales con relleno estructurado. Probó si la ubicación de un problema objetivo cambia la precisión mientras el contexto circundante permanece controlado.

El estudio reportó grandes caídas del final al centro para los modelos vulnerables. En su conjunto inicial de cinco modelos, el 76 % de los errores en posición central coincidía con respuestas del relleno circundante, frente al 22 % al final.

Los investigadores interpretaron ese resultado como evidencia de interferencia del relleno. Las versiones más recientes mostraron en general caídas menores, lo que también sugiere que los proveedores están mejorando parte del comportamiento de contexto largo.

Estos estudios no deberían combinarse en una única tasa universal de fallos. Utilizan distintos modelos, conjuntos de datos, métodos de puntuación, longitudes de contexto y definiciones de degradación.

Sí respaldan una conclusión común. La longitud máxima de contexto y la longitud efectiva de contexto son mediciones diferentes.

La longitud máxima de contexto describe la aceptación de entrada. La longitud efectiva de contexto describe cuánto material puede utilizar un modelo de forma fiable para una tarea concreta.

Esa longitud efectiva puede reducirse a medida que la tarea se vuelve menos literal. También puede reducirse cuando el modelo debe combinar evidencia, distinguir revisiones, preservar restricciones o resistir distracciones plausibles.

Esto explica por qué el análisis largo puede parecer inestable incluso cuando el recuerdo simple sigue siendo impresionante. Preguntar «¿Qué dije sobre la base de datos?» prueba la recuperación. Preguntar «¿El diseño actual sigue cumpliendo todas las restricciones de la base de datos?» prueba recuperación, priorización y razonamiento.

Los chats largos también contienen material generado por el modelo. Cada borrador, interpretación y afirmación especulativa se convierte en contexto futuro potencial. Por tanto, un error temprano del modelo puede competir con la corrección posterior del usuario.

El problema no es que el sistema posea una memoria humana que se desvanece. El modelo recibe una entrada construida y produce una salida a partir de ella. El fallo reside en la fiabilidad con la que utiliza la secuencia creciente.

Ese mecanismo convierte la gestión del contexto en una preocupación de ingeniería. También explica por qué un lenguaje pulido no puede servir como prueba de que el razonamiento subyacente se mantuvo alineado.

El verdadero adversario es la continuidad sin control

La disyuntiva central es la continuidad conversacional conveniente frente a un conjunto más pequeño y gobernado de hechos autorizados.

Una sesión continua parece eficiente. El usuario evita repetir el proyecto, mientras el asistente parece conservar cada decisión y descubrimiento.

La continuidad también reduce los costes visibles de preparación. Iniciar un nuevo chat parece desechar trabajo, especialmente después de horas de investigación o depuración.

Sin embargo, la transcripción ininterrumpida se convierte en una base de datos sin gestionar. Las hipótesis antiguas permanecen junto a los hechos confirmados. Los planes rechazados permanecen junto a las decisiones aprobadas. Las formulaciones temporales permanecen junto a los requisitos vinculantes.

El asistente recibe esos materiales sin los mecanismos de gobernanza presentes en los sistemas de información maduros. Un chat no distingue automáticamente entre la política vigente, notas obsoletas, evidencia sin procesar y resultados especulativos.

La actualidad puede ayudar porque la información posterior aparece cerca del final. Sin embargo, una corrección tardía no borra las afirmaciones anteriores. Ambas versiones pueden seguir disponibles a menos que la aplicación las resuma, recupere o filtre activamente.

Esto genera presión sobre los equipos de producto de IA. Una gran cifra de contexto es fácil de promocionar, mientras que el uso fiable del contexto exige evaluación específica para cada tarea y un diseño de sistema cuidadoso.

También presiona a los equipos que desarrollan agentes. Los agentes suelen acumular resultados de herramientas, planes, errores, observaciones y código generado a lo largo de muchos pasos. Cada elemento nuevo amplía el material que las acciones posteriores deben interpretar.

Los desarrolladores pueden responder con generación aumentada por recuperación, o RAG. RAG busca en una colección externa y proporciona al modelo pasajes seleccionados para una solicitud concreta.

La recuperación reduce la cantidad de material incluida en el prompt activo. También puede conservar la procedencia de las fuentes y facilitar las actualizaciones en comparación con reescribir una transcripción gigantesca.

Sin embargo, RAG no resuelve el problema automáticamente. La recuperación puede seleccionar pasajes semánticamente similares pero incompletos. Una mala delimitación de fragmentos puede separar una excepción de la regla que modifica.

La investigación sobre recuperación perfecta plantea una segunda preocupación. Incluso cuando la evidencia correcta está presente, un prompt innecesariamente largo puede seguir debilitando el rendimiento de la tarea.

Un mejor diseño trata el contexto como un conjunto de trabajo compilado. El sistema debería reunir instrucciones vigentes, evidencia verificada, preguntas sin resolver y el mínimo historial relevante para cada tarea.

Esta idea también cambia el flujo de trabajo personal. En lugar de pedir a un chat que se convierta en el único registro, los usuarios pueden mantener un pequeño conjunto de artefactos externos.

Un registro de decisiones documenta qué se eligió, por qué se eligió y qué alternativas se descartaron. Un archivo de evidencia separa el material fuente de la interpretación del modelo. Un resumen de tarea registra el objetivo y las restricciones actuales.

Aquí es donde una base de conocimiento personal estructurada puede ayudar. La característica útil no es el almacenamiento ilimitado. Es la capacidad de recuperar un conjunto de material más pequeño y actualizado.

El objetivo no es eliminar la continuidad. Es dejar de tratar la continuidad como si fuera control.

Una transcripción larga sigue siendo valiosa como archivo. Se vuelve arriesgada cuando el archivo también funciona como única especificación, sistema de memoria y espacio de razonamiento.

Los hábitos que resistieron el contacto con la evidencia

El flujo de trabajo más seguro convierte periódicamente la conversación en un estado compacto e inspeccionable antes de pedir al modelo que siga razonando.

El primer hábito es separar el estado duradero del historial conversacional. El estado duradero incluye decisiones aprobadas, definiciones, restricciones, evidencia y preguntas sin resolver.

Mantén ese estado en un documento breve fuera del chat. Pide al modelo que proponga actualizaciones, pero revísalas antes de aceptarlas.

Este paso evita que una respuesta especulativa del asistente se convierta silenciosamente en la verdad del proyecto. También ofrece a la siguiente sesión un punto de partida más limpio.

El segundo hábito es usar puntos de control después de decisiones significativas. Un punto de control debería recoger el objetivo actual, las conclusiones aceptadas, las opciones descartadas y la siguiente prueba.

No solicites un resumen genérico. Los resúmenes genéricos favorecen la fluidez y la cobertura, mientras que un punto de control necesita categorías explícitas y compromisos rastreables.

Un punto de control útil puede contener cinco campos:

• Objetivo actual y definición de éxito

• Restricciones vinculantes y sus fuentes

• Decisiones tomadas y alternativas descartadas

• Incertidumbres abiertas que requieren evidencia

• Próxima acción y su resultado esperado

El tercer hábito es iniciar sesiones nuevas en torno a los límites de las tareas. La recopilación de investigación, la evaluación de evidencia, el diseño de esquemas y la redacción final imponen exigencias distintas al contexto.

Una sesión de investigación se beneficia del detalle de las fuentes. Una sesión de redacción se beneficia de afirmaciones verificadas y una estructura definida. Trasladar cada intercambio de investigación a la redacción añade material sin aportar un valor equivalente.

Iniciar una sesión nueva no significa desechar el trabajo. Significa entregar un traspaso curado en lugar de todo el suelo del taller.

El cuarto hábito es repetir las restricciones críticas cerca de la tarea, manteniendo una única versión autorizada. Esto resulta útil al generar código, evaluar evidencia o redactar bajo requisitos estrictos.

La repetición debería hacer referencia a la fuente de verdad. De lo contrario, las instrucciones copiadas pueden desviarse entre varias versiones y crear un problema de contexto distinto.

El quinto hábito es pedir al modelo que exponga su estado de trabajo. Antes de un resultado relevante, solicita las suposiciones, la evidencia, las restricciones y los conflictos sin resolver que identifica en ese momento.

Esto no garantiza fidelidad interna. La explicación de un modelo no revela todas las causas computacionales de su respuesta. Sí proporciona una comprobación práctica de alineación.

Si el modelo omite una restricción vinculante, detente y repara el contexto de trabajo. No continúes simplemente porque la respuesta anterior parecía competente.

El sexto hábito es separar la recuperación del juicio. Primero pide la evidencia exacta relevante y, después, solicita un análisis basado únicamente en ese conjunto extraído.

El artículo de 2025 sobre recuperación perfecta probó una estrategia relacionada de recuperar y luego razonar. Informó mejoras de hasta cuatro puntos porcentuales para GPT-4o en RULER.

Ese resultado se limita a la configuración evaluada. Aun así, respalda un patrón práctico: acortar la entrada de razonamiento después de identificar la evidencia relevante.

El séptimo hábito es preservar la procedencia. Cada afirmación importante debería apuntar a una fuente, experimento, archivo o decisión del usuario.

La procedencia facilita corregir errores porque el usuario puede distinguir la evidencia primaria de la interpretación del asistente. También ayuda a resolver contradicciones tras varias sesiones.

El octavo hábito es tratar los resúmenes del modelo como información con pérdida. Los resúmenes comprimen, priorizan y reinterpretan. Nunca deberían sustituir silenciosamente la evidencia original.

Mantén los documentos fuente disponibles y audita las afirmaciones de gran impacto frente a ellos. Un resumen es una capa de navegación, no un registro incuestionable.

El noveno hábito es vigilar los síntomas de comportamiento en lugar de esperar una advertencia de tokens. Las señales de alerta incluyen preguntas repetidas, ideas descartadas que reaparecen y definiciones incoherentes.

Otros síntomas incluyen ignorar los formatos de salida solicitados, confundir evidencia con hipótesis o responder a una versión anterior de la tarea.

Cuando aparecen esos síntomas, insistir con más prompts dentro de la misma sesión puede empeorar las cosas. La respuesta más segura suele ser crear un punto de control, verificar y reiniciar con un contexto más pequeño.

Estas prácticas no establecen una duración de sesión segura universal. La investigación no justifica una. Crean puntos de recuperación antes de que la degradación resulte costosa.

Lo que la evidencia aún no demuestra

Los benchmarks de contexto largo justifican la cautela, pero no demuestran que toda conversación extensa termine inevitablemente siendo inutilizable.

Los estudios difieren de forma significativa. Lost in the Middle se centra en la posición de la evidencia. RULER varía la complejidad de la recuperación, mientras que NoLiMa reduce la coincidencia léxica.

LongMemEval examina la memoria conversacional sostenida. El preprint sobre recuperación perfecta intenta aislar la longitud de la entrada en sí misma. Estos experimentos se solapan, pero no miden un fenómeno idéntico.

Los benchmarks sintéticos también simplifican el trabajo real. Ofrecen control, lo que ayuda a identificar causas, pero las sesiones reales contienen herramientas, prompts del sistema, memoria de la aplicación y objetivos cambiantes del usuario.

Las aplicaciones comerciales pueden preprocesar los chats de maneras no divulgadas. Pueden resumir turnos anteriores, recuperar recuerdos seleccionados, eliminar contenido o aplicar instrucciones ocultas.

Por tanto, dos productos que usan el mismo modelo subyacente pueden comportarse de forma diferente. Incluso un mismo producto puede cambiar tras una actualización del modelo o una revisión de la gestión del contexto.

Las familias de modelos también difieren. Algunos estudios muestran una debilidad posicional considerable en un sistema y descensos menores en otro. Las versiones más recientes a veces reducen patrones de fallo anteriores.

El estudio posicional de 2026, por ejemplo, informó brechas menores entre los extremos y el centro en varios modelos más recientes. Esto sugiere que el uso del contexto está mejorando, aunque los fallos restantes siguen siendo importantes.

Los investigadores también debaten qué constituye una tarea significativa de contexto largo. La recuperación literal de una aguja puede ser demasiado fácil, pero las pruebas de razonamiento muy construidas pueden no parecerse al trabajo rutinario.

Una evaluación útil debería ajustarse al despliegue. Un sistema de revisión legal necesita excepciones, revisiones y relaciones entre documentos. Un agente de código necesita dependencias, archivos actuales y restricciones arquitectónicas aceptadas.

Ninguno de los dos sistemas debería evaluarse únicamente por localizar una frase insertada. Del mismo modo, un benchmark difícil no debería borrar un rendimiento útil en tareas más acotadas.

La expresión “context rot” también puede inducir a error. Sugiere que la información se degrada físicamente dentro de una conversación en curso. En muchos sistemas, la entrada real puede reconstruirse para cada respuesta.

El problema observable es la degradación del rendimiento de la tarea a medida que el contexto utilizable se hace más largo o está peor organizado. La causa interna puede implicar atención, posición, interferencia, preprocesamiento, recuperación o complejidad de la tarea.

El amplio informe comparativo de Chroma afirma explícitamente que no identifica un mecanismo definitivo. Sus investigadores observaron que el rendimiento variaba con la longitud y la estructura del contexto en tareas controladas.

El informe sobre context rot aboga por una construcción cuidadosa del contexto. También reconoce la necesidad de separar la dificultad intrínseca de la tarea de las limitaciones para manejar la longitud.

Esa cautela debería orientar las afirmaciones de los usuarios. Una respuesta deficiente al final de un chat no demuestra por sí sola una degradación del contexto.

La tarea puede haberse vuelto más difícil. Las instrucciones pueden entrar en conflicto. Una herramienta puede haber devuelto información incorrecta. El modelo puede haberse actualizado o la aplicación puede haber comprimido el historial.

La respuesta práctica sigue siendo parecida: inspeccionar el estado disponible, reducir la ambigüedad y reproducir el fallo en condiciones controladas.

Para trabajos de alto riesgo, ejecuta la misma tarea con un prompt limpio y compacto. Compáralo con el resultado de la sesión larga. Esa prueba aporta más evidencia que la intuición por sí sola.

Qué vigilar a continuación en los LLM de contexto largo

Los próximos avances útiles conectarán la capacidad anunciada con la fiabilidad específica de cada tarea, controles de memoria visibles y pruebas de flujo de trabajo repetibles.

La primera señal es una mejor evaluación posicional en los lanzamientos de modelos. Los proveedores deberían informar de cómo cambia el rendimiento cuando una evidencia idéntica se desplaza del principio al centro y al final.

Esas evaluaciones deberían incluir razonamiento, agregación y manejo de revisiones. Un modelo que recupera una frase literal con la longitud máxima no ha demostrado una memoria de proyecto fiable.

Si los resultados controlados por posición se convierten en estándar, será más fácil comparar la brecha entre capacidad y uso. Si siguen ausentes, los compradores deberán continuar creando sus propias pruebas.

La segunda señal es el avance de los sistemas de recuperar y luego razonar. Estos sistemas identifican la evidencia relevante, construyen un contexto de trabajo más corto y después realizan el análisis solicitado.

La medición crítica no es solo la recuperación de información relevante. Los desarrolladores deben evaluar si la respuesta final respeta las restricciones, combina correctamente la evidencia y rechaza la información obsoleta.

Los sistemas exitosos también conservarán la procedencia. Los usuarios deberían poder inspeccionar qué fuentes y decisiones entraron en el contexto de trabajo de una respuesta relevante.

La tercera señal es el control del usuario sobre la memoria y el estado de la sesión. Las interfaces de producto necesitan distinciones más claras entre el historial de chat, la memoria guardada, los documentos recuperados y las instrucciones activas.

Los usuarios deberían poder marcar un elemento como autoritativo, reemplazado, incierto o excluido. Sin esos controles, una memoria más extensa puede conservar más contradicciones junto con más hechos útiles.

Para los equipos, la lección a corto plazo es clara. No elijan un sistema de IA basándose únicamente en el tamaño del contexto. Prueben las tareas importantes con una ubicación realista de la evidencia y ruido realista.

Para las personas, la respuesta adecuada no es abandonar las sesiones largas. Es cambiar de qué puede hacerse cargo una sesión.

Dejen que la transcripción registre la exploración. Mantengan la evidencia verificada, las decisiones actuales y las restricciones vinculantes en artefactos externos más pequeños. Actualicen el conjunto de trabajo del modelo cada vez que cambie la tarea.

Antes de su próximo análisis extenso, creen un resumen compacto del proyecto y un registro de decisiones. Después, comparen una respuesta de una sesión nueva con la respuesta de su chat más largo.

Si la versión nueva sigue las restricciones con mayor precisión, el contexto no estaba funcionando como una memoria fiable. Estaba funcionando como un archivo cada vez más ruidoso.