latent
Un millón de tokens parece una infinidad. No lo es, pero es suficiente para cambiar lo que es posible.
La carrera armamentista de las ventanas de contexto
La progresión ha sido rápida.
- GPT-3 (2020): 4,096 tokens
- GPT-4 (2023): 8,192 tokens, variante de 32K disponible
- Claude 2 (2023): 100,000 tokens
- Gemini 1.5 Pro (2024): 1,000,000 tokens
- Claude 3.5 / Gemini 2.0 (2025): estándar de 200K–1M, con ventanas aún más largas apareciendo
Cada salto no solo aumentó una cifra; abrió casos de uso cualitativamente diferentes. Con 4K tokens apenas podías incluir un prompt y un documento corto. Con 100K podías procesar el capítulo de un libro. Con 1M, puedes cargar un codebase completo, un expediente legal íntegro o horas de transcripciones de reuniones en una sola llamada.
Qué cabe en 1M de tokens
Para hacerlo concreto: aproximadamente 750,000 palabras en inglés, lo que equivale a unas 10 novelas. Un codebase mediano completo con más de 500 archivos fuente. Un procedimiento legal completo: demanda, exhibición de pruebas, deposiciones, mociones, todo. Alrededor de 16 horas de voz transcrita. Cientos de páginas de informes financieros.
El cambio interesante no es el tamaño bruto. Es que la pregunta pasa de ser "¿qué puedo incluir?" a "¿qué debería incluir?". Esa es una forma distinta de diseñar una aplicación de LLM.
El problema de "perderse en el medio" (lost-in-the-middle)
Más contexto no significa un mejor rendimiento. Investigaciones de Stanford y otras instituciones han demostrado que los LLM tienen un patrón de atención en forma de U. Prestan mucha atención a la información al principio y al final del contexto, y su desempeño se degrada con la información enterrada en el medio.
En un experimento ampliamente citado, colocar un dato objetivo en la posición 50 de 100 documentos dio un recall significativamente peor que colocarlo en la posición 1 o en la 100. El modelo "sabe" que la información está ahí porque fue proporcionada, pero no puede recuperarla de manera confiable.
Esto no está resuelto del todo. Las mejoras en arquitectura y entrenamiento han suavizado el efecto, pero la implicación práctica se mantiene: el orden importa. Coloca el contexto más importante cerca del principio o del final de tu prompt. No entierres la pieza fundamental en medio de una carga masiva de documentos y esperes que funcione.
Evolución del positional encoding
La razón por la que los modelos pueden manejar contextos más largos se reduce a cómo codifican la posición. La atención de los Transformers es inherentemente agnóstica a la posición; sin codificaciones posicionales (positional encodings), el modelo no puede distinguir el orden de los tokens.
RoPE (Rotary Position Embedding) es lo que utilizan Llama, Mistral y la mayoría de los modelos abiertos modernos. Codifica la posición relativa a través de matrices de rotación aplicadas a los vectores query y key. Es elegante y efectivo, pero el rendimiento se degrada más allá de la longitud del contexto de entrenamiento a menos que se modifique.
ALiBi (Attention with Linear Biases) añade una penalización lineal a las puntuaciones de atención basada en la distancia entre los tokens. No tiene parámetros aprendidos y extrapola a secuencias más largas de forma más fluida que las codificaciones de posición absoluta.
YaRN (Yet another RoPE extensioN) extiende los modelos basados en RoPE a contextos más largos mediante una combinación de interpolación y escalado de atención. Un modelo entrenado con un contexto de 4K puede funcionar a 32K o más con un fine-tuning mínimo.
Estas no son distinciones académicas. La elección del positional encoding determina si un modelo puede extenderse a contextos más largos después del entrenamiento y con qué costo de calidad.
Eficiencia de memoria: el verdadero cuello de botella
El factor limitante para el contexto largo no es la arquitectura del modelo, sino la memoria. El KV cache (caché de clave-valor) que almacena el estado de atención crece linealmente con la longitud de la secuencia y cuadráticamente en términos de cómputo. Un contexto de 1M de tokens con un modelo grande puede necesitar cientos de gigabytes de KV cache. Ese es el muro con el que todos chocan.
Flash Attention reescribe el cálculo de atención para que sea consciente de la E/S (IO-aware). Procesa la atención en bloques (tiles) que caben en la SRAM de la GPU en lugar de materializar la matriz de atención completa en la HBM. El uso de memoria baja de O(n^2) a O(n) manteniendo el cálculo exacto.
Paged Attention, la técnica utilizada en vLLM, gestiona el KV cache como memoria virtual. Asigna bloques no contiguos bajo demanda, elimina la fragmentación de memoria y permite servir muchas solicitudes concurrentes de contexto largo sin pre-asignar buffers de longitud máxima para cada una.
Ring Attention distribuye el KV cache a través de múltiples dispositivos. Cada dispositivo calcula la atención para su porción de la secuencia, lo que permite alcanzar longitudes de contexto que superan la memoria de cualquier dispositivo individual.
# El cálculo de memoria para contexto largo
# Modelo: 70B params, KV cache por capa por token: ~512 bytes (FP16)
# Capas: 80
# Contexto: 1M tokens
kv_cache_size = 80 * 1_000_000 * 512 # ~40 GB solo para el KV cache
# Más los pesos del modelo: ~140 GB en FP16
# Total: ~180 GB — requiere una configuración multi-GPUDónde destaca el contexto largo
Las ventanas de contexto largo brillan genuinamente en algunos escenarios específicos.
Q&A de documentos completos es el caso obvio. En lugar de fragmentar (chunking) un contrato de 200 páginas con la esperanza de que la recuperación (retrieval) encuentre la sección correcta, lo introduces entero. El modelo puede cruzar cláusulas, detectar contradicciones y sintetizar información que abarca docenas de páginas. Eso es difícil de hacer con fragmentación mediante RAG.
El many-shot prompting también se potencia. Con un millón de tokens, puedes proporcionar cientos de ejemplos en lugar de solo unos pocos. Esto es particularmente poderoso para tareas de clasificación donde la distribución de casos de borde (edge cases) es importante.
La comprensión de codebases es lo que he encontrado más útil en la práctica. Carga un repositorio completo en el contexto y haz preguntas que requieran entender cómo interactúan los módulos. "¿Qué sucede cuando un usuario envía un formulario en la página /checkout?" podría requerir el seguimiento a través de 15 archivos. El contexto largo convierte eso en una sola consulta en lugar de un seguimiento manual.
El análisis de reuniones y deposiciones entra en la misma categoría. Las transcripciones de sesiones de varias horas pueden procesarse en su totalidad, lo que significa que puedes preguntar cosas como "¿Se contradijo el testigo en su testimonio anterior sobre la cronología?" y obtener una respuesta realmente útil.
Dónde sigue ganando RAG
El contexto largo no mata a RAG. Cambia el cálculo, pero la recuperación sigue siendo mejor en varios casos.
El costo es el factor principal. Procesar 1M de tokens cuesta aproximadamente 100 veces más que procesar 10K tokens. Si tu base de conocimientos es grande pero solo una pequeña parte es relevante para una consulta específica, la recuperación es dramáticamente más barata.
El conocimiento dinámico es otro punto. Las ventanas de contexto se llenan en el momento de la consulta. Si tu base de conocimientos tiene millones de documentos y cambia a diario, no puedes precargarlo todo en el contexto. La recuperación selecciona el subconjunto relevante y punto.
La precisión es más sutil. Una buena recuperación con reranking a menudo encuentra los pasajes exactos con mayor precisión que un modelo escaneando cientos de páginas. El problema de lost-in-the-middle significa que el contexto largo puede ser menos confiable para consultas de "aguja en un pajar", que es lo opuesto a lo que se podría suponer.
La latencia es el último factor. El time-to-first-token escala con la longitud del contexto. Un prompt de 1M de tokens tarda significativamente más en procesarse que uno de 10K tokens con los fragmentos adecuados ya seleccionados.
Consejos prácticos
Solo porque puedas llenar un millón de tokens no significa que debas hacerlo.
- Comienza con retrieval y expande el contexto según sea necesario. Usa RAG para seleccionar los 10–20K tokens más relevantes. Si la respuesta requiere un contexto más amplio, expándelo iterativamente.
- Prioriza el contexto importante al inicio. Coloca la información crítica al comienzo del prompt. No confíes en que el modelo encuentre una aguja enterrada dentro de 500K tokens.
- Usa separadores estructurados. Cuando incluyas múltiples documentos, delimítalos con encabezados, separadores y metadatos. Ayuda al modelo a rastrear qué información proviene de qué lugar.
- Monitorea los costos. Las solicitudes de contexto largo son caras. Rastrea el uso de tokens y establece presupuestos. Un pipeline mal diseñado que envíe 1M de tokens en cada consulta agotará el presupuesto más rápido de lo que crees.
- Haz un benchmark de tu caso de uso específico. Evalúa si el contexto largo realmente mejora la calidad frente a enfoques de recuperación aumentada (RAG) para tus datos. La respuesta varía según la tarea.
La ventana de contexto de un millón de tokens es una herramienta poderosa. La habilidad reside en saber cuándo usarla y cuándo un enfoque más simple hace mejor el trabajo.