- Aunque el límite de tokens de entrada (ventana de contexto) de los LLM más recientes se ha ampliado hasta millones, incluso cuando obtienen puntuaciones altas en benchmarks de búsqueda simple (Needle in a Haystack, NIAH), existe claramente una degradación del rendimiento en entradas largas reales
- El equipo de investigación realizó diversos experimentos con 18 modelos y confirmó repetidamente degradación del rendimiento y patrones inconsistentes, incluso controlando únicamente el aumento de la longitud de entrada
- Se observó de forma marcada que la velocidad de caída del rendimiento se acelera o cambia de manera impredecible según la disminución de la similitud entre pregunta y respuesta, la adición de distractores y los cambios en la estructura del texto base
- Incluso mantener un contexto estructurado (flujo lógico de párrafos) puede afectar negativamente el rendimiento, lo que muestra que la disposición y la forma de presentar la entrada influyen mucho en el desempeño de los LLM
- Incluso tareas muy sencillas, como copiar texto repetitivo, revelan la limitación de no producir resultados consistentes a medida que aumenta la longitud de entrada, lo que subraya la importancia del diseño de contexto (context engineering) en aplicaciones reales
Contexto y objetivo de la investigación
- A medida que la ventana de contexto de los LLM ha crecido recientemente hasta 1 a 10 millones de tokens, se ha extendido la percepción de que el rendimiento está “garantizado” incluso con entradas largas
- Gemini 1.5 Pro, GPT-4.1 y Llama 4 son ejemplos representativos
- El benchmark representativo Needle in a Haystack (NIAH) se limita a una búsqueda simple de frases, por lo que no refleja adecuadamente la degradación del rendimiento en tareas complejas reales como resumen de documentos largos o preguntas y respuestas
- Este estudio verifica de forma sistemática los cambios de rendimiento ajustando solo la longitud de entrada y manteniendo fija la dificultad de la tarea
Experimentos principales y resultados
- Se diseñaron un total de 4 experimentos sobre 18 LLM recientes (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen, etc.):
- Cambios en la similitud semántica entre pregunta y respuesta (Needle-Question)
- Adición de distractores
- Cambios de tema/estructura del texto base (haystack)
- Copia de palabras repetidas (expansión simultánea de la longitud de salida y de entrada)
- En todos los experimentos, el rendimiento cae bruscamente a medida que crece la longitud de entrada, y la caída es aún mayor cuando la similitud semántica es baja o hay más distractores
- Cuanto menor es la similitud entre pregunta y respuesta, más se dispara la tasa de errores en entradas largas
- Incluso con un solo distractor añadido, la tasa de acierto cae de inmediato, y al añadir 4 o más, aumentan notablemente según el modelo los fenómenos de confusión y alucinación (hallucination)
- Ejemplo: la familia Claude tiende con fuerza a esquivar la respuesta diciendo “no se puede encontrar la respuesta”, mientras que la familia GPT genera más respuestas incorrectas con tono de certeza
- También se observó un fenómeno peculiar en el que el rendimiento se invierte según la estructura del texto base (flujo lógico/orden aleatorio)
- En el texto original (Original), que mantiene el flujo lógico, el rendimiento del modelo empeora
- En el texto mezclado aleatoriamente (Shuffled), el rendimiento de búsqueda mejora
- Incluso en el experimento de copia de palabras repetidas, a medida que aumentan los tokens de entrada y salida, crecen los patrones impredecibles como más errores, rechazo de la tarea y generación arbitraria de palabras
- Ejemplo: después de 2,500 a 5,000 palabras, en ciertos modelos aumentan bruscamente resultados anómalos como negarse a copiar o generar texto arbitrario
LongMemEval: evaluación práctica de conversaciones largas
- En el benchmark LongMemEval, que incluye historiales de conversación reales, se compararon entrada enfocada (solo las partes relacionadas con la respuesta correcta) y entrada completa (incluyendo contexto no relacionado con la respuesta correcta)
- En todos los modelos, la entrada enfocada mostró una tasa de acierto mucho más alta, mientras que en la entrada completa encontrar el contenido relevante actúa como una tarea adicional y reduce considerablemente el rendimiento
- Los modelos de la familia Claude muestran de forma especialmente clara la tendencia a evitar responder con “no hay respuesta correcta” en situaciones ambiguas
Análisis adicional e implicaciones
- Se analizan con precisión, mediante diversos gráficos, diferencias en los patrones internos de funcionamiento según el modelo, como la tasa de confusión por distractor, la precisión de la posición de la respuesta y la ubicación de la generación arbitraria de palabras
- En el experimento de copia de palabras repetidas, aparecen características dependientes de la posición, como que la precisión es mayor cuando la palabra correcta está ubicada al principio
- Dado que el diseño del contexto (disposición de la información, gestión del flujo lógico, etc.) influye enormemente en el rendimiento del modelo, esto sugiere que en servicios reales no puede esperarse un rendimiento consistente solo ampliando el contexto
Conclusión
- La capacidad de los LLM para procesar entradas largas no queda garantizada por los puntajes en benchmarks, y solo con aumentar la longitud real de entrada ya aparece una degradación inconsistente del rendimiento
- No basta con incluir información relevante; la disposición de la información, su estructura, los distractores y la similitud tienen un impacto decisivo en el rendimiento
- Al usar LLM, es indispensable la gestión y el diseño del contexto largo (context engineering)
2 comentarios
Ya salió 2.5 hace rato, pero ¿por qué 1.5?
Comentarios en Hacker News
Yo también he tenido una experiencia parecida. Sobre todo al usar Gemini Pro: cuando le das referencias de texto largas, obtuve respuestas mucho mejores resumiendo primero cada documento y haciendo preguntas sobre esos resúmenes, y luego, si hacía falta, pasando el documento completo en estilo RAG o con un bucle simple de agente, en lugar de meter varios documentos de una vez en la ventana de contexto. De forma similar, al usar Claude Code con Opus o Sonnet, también experimenté directamente que cuanto más compaction ocurría, peores eran los resultados. No estoy seguro de si se debe a que baja la calidad del resumen o a que aumenta la proporción de datos menos relevantes dentro de la ventana de contexto, pero cuando limpiaba el contexto y le pedía que volviera a leer solo los archivos relevantes, los resultados eran mucho mejores, incluso si ya se habían mencionado en un resumen previo
Gemini empieza a venirse abajo en consistencia y capacidad de razonamiento antes incluso de llegar al límite de contexto del chat. Y aun así, según este reporte, es el mejor modelo en varios aspectos. La conclusión es que la ingeniería de contexto sigue importando y que el enfoque RAG sigue siendo válido
¿"Compaction" no es, al final, acortar la transcripción en un resumen? Si es así, es natural que el rendimiento empeore porque realmente se pierde información. Pero eso no sería por context rot. La señal real de context rot aparecería al acercarse al umbral de auto-compactación. ¿Lo estoy entendiendo bien?
Un agente de código óptimo probablemente automatizaría este proceso. Reuniría el código necesario, respuestas de MCP, mapas del repo, etc., los resumiría de vez en cuando y los fusionaría en un nuevo mensaje de chat para dejar solo lo realmente necesario. Yo ya uso algo de ese estilo con una herramienta llamada aider, y en situaciones que requieren mucho contexto me funcionó bastante mejor que un flujo agentic o automatizado. Eso sí, requiere bastante trabajo manual
¿Has probado NotebookLM? Esta app divide y resume documentos en segundo plano, y mediante RAG te deja hacer preguntas en formato chat sobre los documentos completos
He notado que en Cursor, cuanto más tiempo converso sobre una nueva función o un cambio de código, peor va siendo el resultado. Los mejores resultados salían cuando primero definía instrucciones y un plan claros y específicos, y arrastraba directamente al prompt de contexto los archivos que había que modificar
Avanzar con un flujo de "Explore → plan → code → test → commit" me ayudó mucho más. Si hace falta, también puedes limpiar el contexto en cada etapa para mejorar el efecto
Cuando ya reuní suficiente información para una tarea concreta, guardo el contexto en ese momento. Si veo que la calidad baja, vuelvo a resumir el trabajo hecho hasta entonces y lo agrego al checkpoint anterior
Este fenómeno es bien conocido, pero casi no hay lugares donde esté bien documentado, así que este artículo me da mucho gusto. Creo que el impacto real es todavía mayor de lo que se puede medir fácilmente con benchmarks. Las apps basadas en LLM que de verdad son útiles están justo en el límite de lo que el modelo puede hacer. Es decir, tienen valor cuando en preguntas o tareas reales hay que seguir un contexto que requiere varios "saltos" lógicos. Creo que, cuanto más saltos lógicos se necesitan, más explota el problema de context rot, porque en cada salto aumenta la cantidad de cosas a las que hay que prestar atención
Hace mucha falta una forma sencilla de recortar el contexto. Si pudiera gestionar yo mismo todo el historial entre el modelo y la conversación, siento que podría sacarle mucho más rendimiento a una sesión de programación de unas 200 mil tokens. Pero en la práctica, incluso usando una buena instancia, alrededor de los 20 mil tokens el modelo ya empieza a comportarse raro y la sesión se pudre por completo. Ojalá simplemente pudiera cortar esa parte
Los LLM locales te dejan editar el contexto como quieras, así que si modificas la propia respuesta del LLM, más adelante el modelo puede llegar a creer que eso fue lo que dijo originalmente. Por eso es útil para guiarlo en la dirección que quieres. En cambio, los modelos LLM-as-a-service no ofrecen eso, porque facilitaría evadir la censura
Probé pedirle algo como: "Hey Claude, voy a resetear el contexto, así que hazme un prompt para que pueda seguir trabajando después". Luego revisaba y ajustaba de antemano el prompt que Claude proponía y lo volvía a pegar
Poder hacer rollback fácilmente a un checkpoint anterior sería, de verdad, la mejor función posible
En la mayoría de los agentes de CLI se puede hacer esto con el comando
/compressCuando uso Claude code, cada vez distingue menos entre sus propios errores y mis instrucciones. Cuando empieza a confundirse, la solución es abrir una sesión nueva. Mientras más larga se vuelve la sesión, más cae en el mismo loop o insiste en ignorar cosas diciendo que las pruebas ya estaban rotas antes, aunque en realidad se rompieron en esta misma sesión. Tal vez sea culpa mía por escribir mal el prompt, pero últimamente siento que a Claude de pronto se le bajaron como 30 puntos de IQ
Yo siento exactamente lo mismo. Incluso teniendo plan Max, hay momentos en que rinde bien y otros en que no
Eso de pensar "seguro el problema es mi prompt y mi contexto" se siente como una especie de gaslighting internalizado entre todos nosotros
Este es un tipo de problema de recuperación de información, pero creo que la caída de rendimiento causada por cambios en la longitud del contexto puede funcionar de manera distinta a las respuestas de simple recuperación. Por ejemplo, podría comportarse distinto en preguntas como "¿cómo hago este botón rojo?" o en problemas como "¿a qué categoría pertenecen las oraciones de arriba?". Un paper que me pareció impresionante en su momento fue Many-Shot In-Context Learning. Ese estudio muestra un fenómeno en el que el rendimiento mejora mucho conforme llenas el contexto con ejemplos. Al final, hay que probarlo directamente en cada problema para ver cómo cambia el LLM según el contenido y la longitud del contexto. No se debe asumir siempre que mientras más largo sea el contexto, peor será el rendimiento
Es un artículo muy cool y con mucha perspectiva. Eso sí, desde el punto de vista de la alfabetización mediática, conviene tener presente que Chroma es una empresa de vectorDB
Hace poco escribí varias novelas largas con Gemini 2.5 Flash, y aunque sí se siente el context rot, en mi caso aparece mucho más tarde de lo que sugiere este artículo. En mi caso, recién después de unos 50 mil a 100 mil tokens empezó a ignorar el contexto inicial, por ejemplo el idioma de salida. Tal vez en tareas complejas como la escritura creativa el efecto sea más difícil de medir o menos marcado. De cualquier forma, si de vez en cuando vuelvo a insertar el contexto que se perdió, se mantiene en un nivel bastante usable
Yo también tuve una experiencia parecida. Durante un proyecto estaba desarrollando una función de búsqueda sobre transcripciones de video, y los textos eran muy largos. Como modelos como GPT 4.1 tienen una ventana de contexto grande, pensé que no haría falta RAG, pero sobre todo en modelos pequeños aparecían comportamientos raros con frecuencia. A veces ni respondían bien la pregunta y se limitaban a resumir todo el contenido
Reporte interesante. Me pregunto si existe algo como un tamaño de contexto recomendado por modelo. Quisiera saber si hay alguna manera de identificar hasta qué punto es razonable llegar para mi caso de uso