De 4K a 1 millón de tokens: cómo evolucionó la ventana de contexto y por qué más contexto no equivale a mejor memoria

La cifra que cambió el mercado: qué es una ventana de contexto y qué no mide

La ventana de contexto es el presupuesto de tokens que un modelo puede considerar durante una invocación. En términos prácticos, normalmente incluye las instrucciones, el historial de conversación, los documentos adjuntos o recuperados, las llamadas y resultados de herramientas que se reincorporan al intercambio y, según la interfaz, también la salida que se va a generar. Por ello, una cifra de contexto no debe leerse automáticamente como espacio disponible para documentos: parte del presupuesto ya puede estar ocupado antes de que empiece la tarea.

Una especificación de 128K, 200K o 1 millón de tokens describe ante todo un límite de admisión o una configuración soportada. Es una propiedad importante: evita dividir de entrada un material extenso y puede permitir mantener evidencia, instrucciones y trazabilidad en una sola solicitud. Sin embargo, no establece por sí sola que el sistema responda con la misma fidelidad ante cualquier posición, que resuelva contradicciones documentales ni que convierta un fragmento relevante en una decisión correcta.

Conviene distinguir además el contexto de la memoria en sentido amplio. El contexto es información suministrada en la interacción actual. Una memoria persistente requiere almacenar, seleccionar, actualizar y gobernar información entre sesiones o tareas. Un modelo puede recibir un expediente completo y aun así no disponer de un mecanismo fiable para decidir qué hecho debe persistir, qué versión prevalece o cuándo una preferencia anterior dejó de ser válida. Esta diferencia es central al diseñar asistentes documentales y agentes.

La ampliación de contexto representa una capacidad de entrada útil, no una garantía general de comprensión. La pregunta operativa no es cuál es la cifra más alta publicada, sino si, para una distribución concreta de documentos y decisiones, incorporar más material mejora la exactitud verificable sin exceder los límites de coste y latencia.

Cronología útil: de la atención densa a la extensión del contexto

El Transformer original situó la atención como mecanismo para relacionar posiciones de una secuencia y utilizó codificaciones posicionales para representar el orden. Su formulación de atención completa es potente, pero comparar muchas posiciones entre sí crea una presión de cálculo y memoria que aumenta rápidamente con la longitud de la secuencia. En los primeros usos prácticos de modelos de lenguaje, las ventanas relativamente cortas no eran sólo una decisión de producto: reflejaban límites de entrenamiento e inferencia.

La evolución posterior no siguió una única ruta. Por un lado, aparecieron mejoras de implementación que reducen el tráfico entre memoria y procesador sin cambiar el resultado matemático de la atención exacta. FlashAttention es un hito representativo de esta vía: reorganiza el cálculo teniendo en cuenta la jerarquía de memoria. No elimina por sí mismo el crecimiento asociado a la atención densa, pero puede hacer viables longitudes o lotes que resultaban menos prácticos con implementaciones anteriores.

Por otro lado, las representaciones posicionales se convirtieron en una parte decisiva de la extensión. RoPE codifica la posición mediante rotaciones; trabajos posteriores propusieron interpolar posiciones para adaptar modelos con RoPE a ventanas mayores mediante ajuste fino limitado. Este mecanismo no equivale a demostrar uso uniforme de todas las posiciones: modifica cómo se presenta la distancia y el orden al modelo, mientras que su comportamiento final depende también de los datos, el entrenamiento y la tarea.

Una tercera vía trata el contexto como un flujo en lugar de como un bloque que debe permanecer íntegro en la caché. Los mecanismos de atención en streaming con attention sinks proponen conservar un conjunto pequeño de estados de atención junto con tokens recientes. Son relevantes para interacciones prolongadas, pero cambian el problema: una política de retención decide qué permanece disponible y qué se descarta. No constituyen una memoria semántica infalible.

Finalmente, los proveedores han expuesto ventanas de un millón de tokens o superiores en algunas familias de modelos. La documentación de Gemini presenta estas capacidades junto con opciones de caché y consideraciones de coste y latencia. Es evidencia de una interfaz y un producto disponibles bajo condiciones concretas; no debe transformarse en una demostración independiente de razonamiento fiable sobre cualquier millón de tokens.

Cuatro capas que no deben confundirse

La primera capa es la admisión. Un sistema admite una entrada cuando la tokeniza y acepta dentro de su límite. La segunda es el procesamiento efectivo bajo un presupuesto operativo: esa misma entrada puede requerir un prefill prolongado, consumir capacidad de memoria o reducir la concurrencia disponible. Dos sistemas que admiten el mismo volumen pueden comportarse de modo distinto en tiempo de respuesta y coste por tarea.

La tercera capa es la recuperación de información. Aquí la pregunta es si el modelo localiza un dato concreto, una cláusula, una fecha o una relación cuando está repartida entre documentos y rodeada de material plausible pero irrelevante. La investigación sobre el fenómeno conocido como pérdida en la zona intermedia evaluó tanto pregunta-respuesta multidocumento como recuperación clave-valor y observó variación del rendimiento según la posición de la información relevante. Esa evidencia aconseja medir posiciones, no sólo promedios.

La cuarta capa es el uso coherente de la evidencia. Un modelo puede citar o extraer un pasaje correcto y después emitir una síntesis que mezcla versiones incompatibles, incumple una regla de prioridad o ejecuta una acción no justificada por la fuente. Esta capa exige tareas de decisión y producción con criterios explícitos, no únicamente una prueba de búsqueda textual.

Estas capas también ayudan a evitar un error frecuente en comparativas: convertir el límite de entrada de una API en una clasificación global de capacidad. Para comparar opciones en la ruta de comparación, es preferible registrar por separado entrada máxima, salida máxima, modalidad, rendimiento medido en una tarea y condiciones de la medición. La cifra nominal es un atributo; la fiabilidad es un resultado empírico.

Qué cambia en inferencia: prefill, generación, caché KV y concurrencia

La inferencia larga tiene al menos dos fases con perfiles distintos. En el prefill, el sistema procesa los tokens de entrada para construir los estados necesarios para continuar la generación. En la fase de decodificación, genera nuevos tokens de forma incremental y reutiliza esos estados. Una entrada extensa puede concentrar una parte importante de la espera inicial aunque la respuesta final sea breve; una salida extensa añade después su propia duración.

La caché de claves y valores, o caché KV, evita recalcular para cada token generado las representaciones de los tokens anteriores. Es esencial para una generación eficiente, pero ocupa memoria y su tamaño crece con la longitud atendida, la arquitectura, la precisión y el número de solicitudes simultáneas. El trabajo sobre cuantización asimétrica de dos bits para caché KV identifica esta caché como un cuello de botella de memoria, especialmente al crecer el contexto y el tamaño de lote. La cuantización puede aliviar esa presión, pero introduce una elección adicional de calidad, compatibilidad y evaluación.

El coste real tampoco es una tarifa plana derivada sólo de multiplicar tokens por precio. Influyen el prefill, la longitud de salida, la reutilización o caché de contexto cuando exista, los reintentos, el número de turnos, la concurrencia y la capacidad reservada. La documentación de contexto largo de Gemini advierte consideraciones específicas de latencia y precio; tales condiciones deben comprobarse en la versión vigente de la documentación y en la carga propia.

Por ello, una evaluación debe reportar distribución, no sólo media. El promedio puede ocultar que los casos largos bloquean recursos o elevan de forma material el percentil 95 de latencia. También debe separar el tiempo de preparación del contexto, el primer token y la finalización, porque cada medida sugiere una mitigación distinta.

Por qué fallan las pruebas simples

Una demostración en la que la respuesta está al principio o al final de un documento limpio no representa la mayoría de los repositorios reales. La evidencia relevante puede estar en posiciones intermedias, en una tabla, en una versión anterior que ha sido sustituida o repartida entre fuentes con terminología distinta. Repetir una misma pregunta en muchas ubicaciones permite detectar degradación posicional que una única prueba no revela.

Los distractores deben ser plausibles. Añadir texto aleatorio mide sobre todo robustez ante ruido fácil; añadir políticas parecidas, cifras antiguas o cláusulas casi idénticas mide la capacidad de resolver ambigüedad. También conviene introducir contradicciones controladas y definir de antemano la regla de resolución: por ejemplo, prevalece la versión más reciente aprobada o la fuente designada como normativa. Sin una regla de oro, no puede atribuirse un fallo al modelo.

Los agentes añaden otra presión: el contexto compite con descripciones de herramientas, resultados de búsquedas, estados de ejecución y mensajes de seguridad. Una ventana mayor puede reducir la necesidad de recortar, pero también facilita que información obsoleta o irrelevante continúe influyendo. El diseño debe limitar qué resultados se reincorporan y conservar identificadores de procedencia para revisar por qué se tomó una acción.

No basta con pedir al modelo que afirme haber usado una fuente. La salida debe contener referencias internas a fragmentos estables del corpus congelado, y un evaluador debe comprobar que respaldan la respuesta. La trazabilidad no elimina las alucinaciones ni asegura que la inferencia sea válida, pero convierte una afirmación en un objeto revisable.

Contexto largo frente a RAG, resumen y memoria persistente

El contexto largo, la recuperación aumentada por generación —RAG—, los resúmenes y la memoria persistente son patrones complementarios, no escalones de una misma escala. El contexto largo conserva más material literal en una llamada. RAG selecciona un subconjunto desde un índice o repositorio. El resumen comprime información, a cambio de poder perder detalle. La memoria persistente mantiene datos entre interacciones mediante políticas de escritura, actualización, caducidad y acceso.

RAG resulta adecuado cuando el repositorio supera la ventana, cambia con frecuencia o exige filtrar por permisos, fecha, entidad o jurisdicción. También reduce la cantidad de texto que debe procesarse en cada turno. Sus riesgos se desplazan a la indexación, el recall, el ranking y la pérdida de relaciones entre fragmentos. Un contexto largo puede ser preferible cuando la tarea depende de comparar muchas partes de un conjunto acotado, siempre que las pruebas demuestren beneficio frente a una selección bien configurada.

Los resúmenes ayudan a mantener continuidad, pero no deben tratarse como fuente primaria cuando la tarea exige precisión literal. Una arquitectura prudente conserva enlaces entre el resumen y los fragmentos de origen, permite volver a ellos y distingue hechos extraídos, interpretaciones y decisiones. La memoria persistente requiere aún más gobierno: quién puede escribirla, qué se puede olvidar, cómo se corrige y qué datos no deben persistir.

La elección debe partir de evidencia propia. En la ruta de descubrimiento puede identificarse qué documentos, herramientas y restricciones caracterizan el flujo; en la ruta de aprendizaje, el equipo puede fijar definiciones y criterios; y en la ruta de comparación, contrastar resultados bajo el mismo corpus y presupuesto. La arquitectura predeterminada no debería decidirse por la longitud anunciada.

Protocolo de evaluación propio: de la demostración a la decisión

Un protocolo mínimo comienza con un corpus congelado y documentado. Debe incluir formatos y longitudes representativos, versiones, metadatos permitidos y una separación clara entre desarrollo y evaluación final. Para cada tarea, se define una respuesta esperada, la evidencia que la respalda, la regla para resolver conflictos y el nivel de riesgo de una respuesta errónea. Si no existe una respuesta única, el criterio debe admitir incertidumbre o escalado humano.

Después, distribuya la evidencia relevante en varias posiciones: inicio, zona intermedia y final. Varíe la distancia entre piezas que deben combinarse y añada distractores semánticamente cercanos. Evalúe al menos extracción literal, respuesta multidocumento, resolución de contradicciones y una decisión o acción con restricciones. Las métricas deben separar fidelidad de citas, exactitud de la decisión, tasa de abstención apropiada, coste por caso correcto y percentiles de latencia.

Compare configuraciones que consuman presupuestos parecidos: contexto completo, RAG, RAG más documentos vecinos, resumen con retorno a fuente y, si aplica, contexto largo con caché. Mantenga fijos el modelo, las instrucciones y el evaluador cuando el objetivo sea aislar la arquitectura. Cuando cambie el modelo, informe el cambio como una variable adicional y evite atribuir todo el efecto a la longitud.

Antes de adoptar una solución, establezca umbrales explícitos. Por ejemplo, una mejora debe superar un margen definido en decisiones correctas y fidelidad de evidencia, no empeorar el p95 por encima del límite de servicio y mantenerse dentro de un coste máximo por tarea válida. Los valores concretos dependen del caso de uso; no pueden deducirse de una especificación pública de contexto.

Cómo leer 128K, 200K o 1M tokens sin prometer comprensión ilimitada

Una especificación responsable debe leerse junto con cinco preguntas: cuál es la entrada máxima, cuál es la salida máxima, qué modalidades acepta, qué condiciones de precio y latencia se aplican y qué comportamiento se ha medido en la tarea de interés. La entrada y la salida no son intercambiables: reservar una salida amplia puede reducir el espacio disponible para documentos, y una tarea con respuesta corta puede seguir sufrir una espera considerable durante el prefill.

También importa la fecha y la versión de la documentación. Los límites, modelos, modalidades y políticas de caché pueden cambiar. En una ficha interna, conviene registrar la fecha de consulta, el identificador exacto de modelo o servicio y las condiciones relevantes, en vez de conservar únicamente una cifra que pronto puede quedar desactualizada.

La conclusión no es que las ventanas largas sean inútiles. Son una ampliación técnica relevante y pueden simplificar tareas que antes exigían fragmentación agresiva. La conclusión es más acotada: la utilidad debe demostrarse en la distribución real de documentos, con evidencia rastreable y dentro de una envolvente operativa aceptable. Más tokens disponibles pueden mejorar una aplicación; más tokens sin selección, evaluación ni gobernanza pueden aumentar el coste y la superficie de error.

Para equipos de producto, la decisión práctica es tratar el contexto como un presupuesto medible. Envíe más información cuando incremente de forma demostrable la recuperación y la decisión; recupere, resuma, pida aclaraciones o escale cuando eso ofrezca mejor evidencia y control. Así, una ventana de un millón de tokens deja de ser una promesa abstracta y pasa a ser una opción técnica evaluable.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.