200K tokens. 1M tokens. 2M tokens. Los proveedores de IA compiten por el tamaño de la ventana de contexto como si fuera la especificación que define al modelo. Cada lanzamiento presume un número más grande.

Pero cuando evalúo modelos para proyectos de clientes en IQ Source, el tamaño de la ventana me dice muy poco. Lo que necesito saber es: ¿qué porcentaje de esa ventana el modelo realmente usa con precisión?

El tamaño es marketing. La retención es ingeniería.

Un estudio de Chroma publicado en julio de 2025 probó 18 modelos de lenguaje. Todos — los 18 — mostraron degradación a medida que el texto de entrada crecía. Los investigadores descubrieron un patrón consistente: los modelos retienen mejor la información del principio y del final del texto, pero fallan con datos enterrados en el medio. Es lo que llaman context rot.

Y acá viene lo raro: cuando los investigadores desordenaron el contenido aleatoriamente (en vez de presentarlo en orden lógico), los modelos lo procesaron mejor. El contenido estructurado — contratos, código, expedientes, que es lo que usamos en el mundo real — es más difícil de procesar para los LLMs que texto revuelto sin estructura.

Si tu empresa procesa contratos largos, documentación regulatoria o codebases grandes, esto importa. Una cláusula de penalización enterrada en la página 147 de un contrato no está al principio ni al final. Está en la zona donde los modelos pierden precisión.

76% vs 18.5%: la diferencia que cambia decisiones

Anthropic publicó resultados del benchmark MRCR v2 (Multi-turn Retrieval with Contextual Reasoning) que mide algo muy específico: si un modelo puede encontrar y usar datos enterrados en un contexto de 1 millón de tokens cuando hay 8 hechos ocultos.

Los resultados:

Modelo	Ventana	Precisión MRCR v2 (8 agujas)
Claude Opus 4.6	1M tokens	76%
Gemini 3 Pro	2M tokens	26.3%
Claude Sonnet 4.5	200K tokens	18.5%

Gemini 3 Pro tiene el doble de ventana que Opus 4.6 y menos de un tercio de su precisión. Es como tener una bodega de 400 metros cuadrados donde pierdes la mitad de lo que almacenas, contra una de 200 donde encuentras todo.

Según análisis de Redis, los modelos que presumen 200K tokens de ventana se vuelven poco confiables alrededor de los 130K tokens — entre el 60% y 70% de la capacidad anunciada. No es un defecto puntual; es una limitación estructural de cómo funcionan los mecanismos de atención actuales.

Cuándo usar contexto completo y cuándo no

La respuesta no es “siempre usa la ventana completa” ni “siempre usa RAG”. Es un problema de ingeniería que depende de lo que necesitas procesar.

Contexto completo funciona mejor cuando:

• El documento tiene referencias cruzadas entre secciones (contratos con cláusulas que remiten a otras cláusulas, código con dependencias entre archivos)
• Necesitas que el modelo entienda la relación entre partes distantes del texto
• La estructura y el orden del documento importan para la interpretación
• Trabajas con expedientes regulatorios donde una excepción en la página 80 modifica una regla de la página 12

RAG funciona mejor cuando:

• Tienes bases de conocimiento grandes pero las consultas son sobre fragmentos específicos
• La documentación de soporte o FAQs donde cada respuesta es autocontenida
• El cuerpo de información crece constantemente, no cabe en una sola ventana, y necesitas respuestas de fuentes múltiples sin procesar cada fuente completa

La realidad de la mayoría de empresas: un sistema híbrido. RAG para filtrar y seleccionar los documentos relevantes, contexto completo para procesarlos a fondo.

Y acá entra el costo. Un prompt de 1M tokens a precio premium cuesta alrededor de $10 por llamada. Una recuperación RAG de 5K-10K tokens relevantes: entre $0.05 y $0.10. Es una diferencia de 100x. Si tu caso no requiere que el modelo vea el documento completo, estás pagando 100 veces más por un resultado que podría ser igual o mejor con RAG bien implementado.

Compactación de contexto: sesiones infinitas de agentes

Si usas agentes de IA en procesos que duran horas, hay un desarrollo que cambia las reglas: la compactación de contexto.

Cuando la ventana de contexto se llena, en vez de perder información o cortar la sesión, el modelo auto-resume las partes más antiguas de la conversación. Conserva lo esencial y descarta lo redundante, lo que libera espacio para seguir trabajando.

Claude Opus 4.6 implementa esto automáticamente. En un caso documentado, la compactación redujo el uso de tokens un 58.6% sin perder el hilo de la conversación. En la práctica, esto permite sesiones de agentes que pueden correr durante horas sin degradarse.

Para una empresa que tiene un agente procesando un pipeline de aprobaciones o revisando documentación de cumplimiento durante horas, la diferencia es operativa: el agente no se “olvida” de lo que hizo al principio de la sesión.

Lo que hacemos en IQ Source

En la mayoría de proyectos que hacemos, la primera pregunta no es qué modelo usar. Es qué tipo de procesamiento necesita cada documento.

Hemos visto que ~70% de los casos B2B se resuelven bien con RAG y fragmentación inteligente. No necesitas meter 200 páginas en la ventana. Pero ese otro 30% — contratos con cláusulas cruzadas, análisis comparativo entre proveedores, código con dependencias distribuidas — necesita un modelo que realmente use toda su ventana.

En la práctica, esto es lo que hacemos con clientes:

• Evaluación de documentos: clasificamos los documentos del cliente por tipo de procesamiento requerido (contexto completo vs. RAG vs. híbrido)
• Diseñamos pipelines de recuperación que combinan RAG para el filtrado inicial con ventanas de contexto para el análisis profundo
• Selección de modelo por caso: no todos los procesos necesitan el modelo más caro. Un flujo de soporte al cliente puede funcionar con Sonnet; un análisis legal necesita Opus
• Por último, implementamos validaciones de precisión que detectan cuando el modelo pierde información en documentos largos, antes de que eso se convierta en una decisión de negocio incorrecta

La carrera por ventanas más grandes va a seguir. Cada trimestre habrá un modelo nuevo con un número más grande en la ficha técnica. Pero el dato que debería estar en la ficha — y nunca está — es la precisión de retención a diferentes profundidades.

Si estás evaluando modelos para procesos que dependen de documentos largos, compara con datos reales de precisión, no con cifras de marketing. Y si necesitas ayuda para armar la arquitectura correcta — RAG, contexto completo, o un híbrido de ambos — escríbenos.