1.
1.1 El reclamo de marketing y la pregunta que se salta
Cada nueva generación de modelos de codificadores viene con una ventana de contexto más grande. BERT y MiniLM nos dieron 512 tokens. Luego llegó ModernBERT y aumentó esa cifra a 8.192, un aumento de 16 veces. Esta no fue solo la decisión de un equipo: toda la industria se movió en la misma dirección, con el límite de entrada estándar para codificadores y modelos integrados aumentando de 512 a 8,192 tokens en tan solo unos pocos años (incluso puede aumentar pronto). (Figura 1).
En la Figura 1, puede ver que hay dos familias de modelos relacionadas pero distintas: codificador e incrustación. Ambos están remodelados por la tendencia creciente del contexto a largo plazo. Un codificador (BERT, ModernBERT) es, en resumen, una herramienta que convierte texto en números que capturan significado. Luego puede realizar ajustes con un pequeño cabezal de tareas, como un cabezal de clasificación, para cumplir con sus propósitos finales. Por otro lado, un modelo de incrustación (sentence-transformers, nomic-embed, GTE/E5) convierte el texto en números para que puedas comparar o buscar. Lleva un codificador un paso más allá: comprime un pasaje completo en un único vector de longitud fija que puede comparar en una búsqueda semántica y un motor de recuperación RAG.
Tanto los modelos de codificador como los modelos integrados están construidos de la misma manera bajo el capó, pero le brindan algo diferente. Un modelo de codificador le brinda una representación separada para cada token en su entrada. Esto es útil cuando estás realizando ajustes. Un modelo de incrustación colapsa todo eso en un solo vector. Ese vector está construido para comparar.
¿Por qué la ventana de contexto se alarga?
Hay una idea seductora flotando por ahí: “dale más texto al modelo y entenderá más”.
Sin embargo, "admitimos 8192 tokens" es una especificación de ingeniería, no una garantía de rendimiento. Un modelo técnicamente puede aceptar 8192 tokens y seguir produciendo el mismo resultado que tendría con solo los primeros 512. Nadie responde realmente a la incómoda pregunta siguiente: ¿cuánto ayuda realmente ese contexto adicional y en qué tipo de tareas?
Este artículo está aquí para descubrir, en un modelo pequeño de 32M, el tipo de modelo que realmente usarías en producción porque es barato y rápido a escala. Realizamos experimentos controlados en los que la longitud del contexto fue lo único que cambiamos. Todo lo demás quedó arreglado.
1.2 Por qué esto importa: el costo es cuadrático
La atención del transformador escala con el cuadrado O (n²) de la longitud de su secuencia. Pasar de 512 a 8192 tokens supone 16 veces más entrada, pero aproximadamente 256 veces más cálculo. En esta prueba, medimos un aumento de 22 veces en el tiempo de entrenamiento del reloj de pared en una tarea de patente binaria (35 s → 771 s) y un aumento de 30 veces en una tarea de patente de 9 vías (93 s → 2769 s).
Entonces la pregunta no es si un contexto más extenso ayuda. Suele ser así. La pregunta es si ayuda lo suficiente. ¿Siete puntos de precisión? Pagalo. ¿Una fracción de un punto que gira entre semillas aleatorias? Acabas de prender fuego al dinero.
Por lo tanto, la decisión de ingeniería que este estudio pretende informar es:
Tienes un documento largo. Tienes una tarea fija. ¿Debería pagar el costo cuadrático de una ventana de 8192 tokens, o un pase barato de 512 tokens, o un simple truco de fragmentación, lo acercarán lo suficiente por una fracción del precio?
1.3 La respuesta: se trata de dónde vive la señal, no de cuánto tiempo dura el documento
La suposición intuitiva es: documento más largo = más necesidad de una ventana de contexto larga. Eso está mal.
Lo que importa no es la longitud del documento, sino dónde se encuentra la información útil. Como en la Figura 2, ¿una patente de 5.000 tokens cuya categoría se decide por el título, el resumen y la primera reivindicación? Es tan obvio que una ventana de 512 tokens ya ve todo lo que importa. Ampliarlo al token 4000 no añade nada.
Pero si la respuesta requiere piezas esparcidas por todo el documento, o solo aparece después del token 512, es entonces cuando una ventana más larga realmente gana su costo.
La longitud del documento y la dispersión de la señal son dos cosas separadas, pero se tratan como una sola. Lo que los experimentos realmente muestran es incómodo: los documentos largos que la gente clasifica en la práctica (patentes, documentos, presentaciones legales) tienden a presentar su información clave al principio. Lo que significa que la costosa ventana de 8192 tokens está releyendo en su mayor parte lo que ya vio la ventana barata de 512 tokens.
1.4 ¿Para quién es esto y qué te llevarás?
OMS.
Esto está escrito para ingenieros de ML e investigadores aplicados que necesitan tomar una decisión real sobre la longitud del contexto, ya sea ajustando un codificador para la clasificación de documentos largos, construyendo una canalización RAG o descubriendo cómo se ven los costos de inferencia cuando se entrega un modelo a escala. No necesita experiencia previa con modelos de contexto largo. La parte 2 explica todas las técnicas desde cero.
Con qué te irás:
Una regla de decisión simple. En lugar de preguntar "¿cuánto dura este documento?", usted pregunta "¿dónde vive la señal?". Esa pregunta lo encamina hacia el enfoque correcto. Se resume como un árbol de decisiones que puede aplicar directamente a su propia tarea. Cifras de costos reales. ¿Cuánto le cuestan realmente 512 tokens frente a 8192 tokens: en tiempo de entrenamiento, tiempo de inferencia, en GPU y en CPU? Una vez que vea los números, “simplemente use la ventana de contexto más larga” deja de ser una opción predeterminada y se convierte en una opción a la que está fijando el precio de manera consciente. Dos técnicas más económicas que a menudo superan la ventana larga. Chunk-and-pool funciona bien para la clasificación. El fragmento con superposición funciona bien para la recuperación. Ambos son más simples y menos costosos que expandir la ventana contextual, y esta guía explica exactamente cuándo se aplica cada uno. Un protocolo de prueba reutilizable. En lugar de confiar en los números de referencia de una hoja de especificaciones, tendrá un método concreto para probar la pregunta de contexto largo con sus propios datos, incluida la ablación de filas idénticas, un piso simbólico y pruebas de significancia de múltiples semillas para asegurarse de que sus resultados se mantengan.
2. Dos formas de manejar un documento extenso
Cuando un documento es más largo que la ventana contextual de su modelo, en realidad solo tiene dos opciones. O agrandas la ventana y pagas por ella, o divides el documento en partes y combinas los resultados. Esta parte analiza ambos enfoques con figuras y animaciones cortas: primero, las técnicas que usa un codificador moderno de estilo BERT para alcanzar 8192 tokens, luego las técnicas de fragmentación que puede usar para evitar la necesidad de esa ventana larga en primer lugar.
Una cosa que vale la pena tener en cuenta antes de entrar en materia: aquí cada técnica intercambia algo de precisión por la capacidad de manejar la escala. El objetivo es entender exactamente a qué estás renunciando con cada uno.
2.1 Alcanzar una ventana de contexto larga
Un transformador estándar funciona haciendo que cada token atienda a los demás tokens. Eso es claro y exacto, pero es costoso: el costo crece como O(n²). Pasar de 512 a 8192 tokens significa 16 veces más tokens, lo que se traduce en aproximadamente 256 veces más cálculo de atención. Esa escala cuadrática es la razón por la cual el contexto largo es costoso y, en una GPU más pequeña, a veces simplemente no es posible.
2.1.1 Posición como rotación: RoPE (Incrustaciones de posición rotativa)
El primer problema con una ventana más larga es la posición. Un modelo necesita saber dónde se ubica cada token en la secuencia. El antiguo enfoque asignaba un vector aprendido a cada posición absoluta, pero si solo entrenaba hasta la posición 512, el modelo no tiene idea de qué hacer con la posición 6000 porque nunca la ve.
Las incrustaciones de posición rotatoria, o RoPE (Figura 3), resuelven esto de manera diferente. En lugar de buscar una posición en una tabla, RoPE codifica la posición como una rotación. La consulta y los vectores clave de cada token se rotan en un ángulo que depende de la posición del token. Una ficha en la posición i gira i·θ, una ficha en la posición j gira j·θ. Cuando el modelo calcula la atención entre dos fichas, toma el producto escalar de sus vectores rotados, y ese producto escalar solo depende de la diferencia entre los dos ángulos, que es (j – i)·θ. En otras palabras, sólo depende de qué tan separados estén los dos tokens, no de dónde se ubican en términos absolutos.
¿Por qué importa eso? Porque si desplaza ambos tokens 1000 posiciones más profundamente en un documento, ambos vectores giran la misma cantidad adicional y el ángulo entre ellos permanece exactamente igual. El modelo está aprendiendo relaciones en términos de distancia relativa (“estos dos tokens están separados por 50 posiciones”) en lugar de “este token está en la ranura 312”.
2.1.2 Prestar atención donde sea necesario: alternar capas locales y globales
RoPE maneja la posición: le dice al modelo dónde se encuentran los tokens en una secuencia larga. Pero no aborda el costo de procesar esa secuencia. La atención total sigue siendo O (n²): duplicar la longitud de la secuencia, cuadriplicar el cálculo. La solución práctica comienza con una observación: la mayor parte de lo que un token necesita para comprender su significado está justo al lado. Por lo tanto, la mayoría de las capas utilizan atención local, donde cada token solo mira un pequeño vecindario: alrededor de 128 tokens en cada dirección. Eso escala linealmente con la longitud de la secuencia en lugar de cuadráticamente. Mucho más barato.
Entonces, aproximadamente cada tercera capa, ModernBERT intercambia una capa de atención global donde cada token puede atender a todos los demás tokens a la vez. Las capas locales mantienen los costos bajos; Las capas globales garantizan que nada distante quede cortado permanentemente. En la Figura 4, la banda diagonal brillante es la atención local en acción. La inundación en todo su ancho es una capa global que se enciende.
2.1.3 Dejar de pagar por el relleno: despachar y empaquetar en secuencia
Hay una fuente más de cálculo desperdiciado que no tiene nada que ver con la atención: el relleno.
Un lote normal es un rectángulo: cada secuencia se rellena con tokens [PAD] para que coincida con el más largo. Esos tokens no contienen información, pero el modelo les presta toda su atención de todos modos. En lotes de longitud mixta, una gran parte de cada pase hacia adelante es solo matemática de relleno.
Al deshacer el relleno (también conocido como embalaje de secuencia) se elimina el rectángulo. Concatena tokens reales de múltiples secuencias en un flujo continuo, con la máscara de atención que garantiza que los tokens nunca se mezclen entre los límites del documento. Sin tokens de pad, cada FLOP está haciendo un trabajo real.
Es una optimización del rendimiento, no una técnica de extensión del contexto, pero es una gran parte de lo que hace factibles 8.192 tokens en hardware modesto. La figura 5 muestra la diferencia.
2.1.4 Otras técnicas avanzadas:
Las tres técnicas anteriores son las más comunes, pero aparecen algunas otras según el modelo, como se muestra a continuación:
Atención subcuadrática (Performer, Mamba, atención lineal). Reemplaza la atención softmax con algo que escala linealmente. Suena genial, pero tiene problemas con la recuperación exacta de largo alcance, razón por la cual todavía es poco común en los codificadores de producción. Núcleos FlashAttention/SDPA. No cambia la matemática O(n²), simplemente la ejecuta de manera más inteligente colocando el trabajo en mosaico para que quepa en la memoria del chip. A menudo, la diferencia entre 8.192 tokens caben en tu GPU o no. Escalado de cuerda (NTK, YaRN). Extiende las frecuencias de RoPE para que un modelo entrenado en una longitud de contexto pueda ejecutarse en uno más largo con poco reentrenamiento. Si lo empuja demasiado, la calidad disminuye, por lo que la calibración es importante. Coartada. Omite por completo las incrustaciones de posiciones y solo penaliza los tokens distantes directamente en las puntuaciones de atención. Se generaliza a secuencias más largas de las que fueron entrenados, pero su sesgo de actualidad incorporado lo hace inadecuado para codificadores bidireccionales.
2.1.5 El conjunto de herramientas de extensión del contexto
Hice una tabla resumen de todas las técnicas más comunes. Los que están en negrita son los que realmente utiliza en la práctica un codificador moderno de contexto largo estilo ModernBERT.
2.2 Al revés: fragmentación
La sección 2.1 le brinda una ventana de contexto más larga, pero incluso con cada optimización aplicada, procesar 8192 tokens es costoso: usted paga un costo de cálculo cuadrático por cada token, ya sea que la tarea realmente necesite tanto contexto o no.
La fragmentación adopta el enfoque opuesto. En lugar de ampliar la ventana, divide el documento en partes más pequeñas, cada una de las cuales es lo suficientemente corta como para pasar por un codificador económico con un límite de 512 tokens o menos. Codifica cada pieza por separado y luego combina los resultados. El problema de cálculo desaparece. Pero en su lugar aparece un nuevo problema: la forma en que se divide el documento determina qué información se pierde. Un corte descuidado puede desperdiciar exactamente lo que una ventana de contexto larga habría preservado.
2.2.1 Cuando los fragmentos dividen los hechos: la solución de la superposición
Los fragmentos de tamaño fijo y que no se superponen son la estrategia de fragmentación más barata que puede ejecutar: cobertura total, cero redundancia y total simplicidad. El modo de falla también es simple. Si tiene un hecho de dos partes (entidad E y atributo A) y el límite del fragmento se encuentra entre ellos, ningún fragmento lo contiene todo. Un trozo tiene E; el siguiente tiene A. En el momento de la recuperación, ese documento está vinculado a un distractor que solo tiene la mitad de la información. La unión desapareció.
La solución estándar es la superposición: ventanas deslizantes que comparten k tokens con sus vecinos. Dado que las ventanas consecutivas se superponen, alguna ventana siempre se extiende a ambos lados de cualquier límite dado, y E y A caen en el mismo trozo. Paga con más fragmentos (más almacenamiento, más procesamiento y visitas duplicadas que necesitará deduplicar), pero recupera la solidez que los cortes duros desperdician (Figura 6).
2.2.2 Fragmento y agrupación
La superposición se trata de recuperación. Chunk-and-pool se trata de clasificación: desea una etiqueta única para un documento largo sin ejecutar un pase hacia adelante de 8192 tokens.
El enfoque:
Dividir en hasta 16 partes de 512 tokens (16 × 512 = presupuesto de 8192 tokens). Codifique cada fragmento de forma independiente con el mismo codificador pequeño: ningún fragmento ve al otro. Combine los vectores [CLS] en un vector de documento. Clasifica ese vector.
El argumento del costo es el principal atractivo. La atención se escala como n_chunks × 512² en lugar de 8192². Muchas cuadráticas pequeñas en lugar de una enorme. Lee el documento completo por una fracción del precio.
El problema está en el paso 3. La agrupación de medias promedia la interacción entre fragmentos. Si la señal se carga frontalmente o es autónoma en fragmentos individuales, el costo de precisión es cercano a cero. Si la respuesta requiere combinar evidencia distribuida en fragmentos, el promedio la diluye. Ese es el caso en el que una verdadera ventana de contexto largo realmente gana su lugar (Figura 7).
2.2.3 Más allá de los cortes fijos y superpuestos
Los cortes fijos y superpuestos cubren la mayoría de los casos. Algunos otros enfoques los llevan a otro nivel.
Límites de oraciones/párrafos. Divida la puntuación o la estructura del documento para que los fragmentos se alineen con las unidades de significado y evite saltos a mitad de oración. Semántica más limpia, pero los fragmentos se vuelven de tamaño variable y un hecho que abarca dos párrafos aún se puede dividir entre ellos. Semántico/recursivo. Dividido por similitud o estructura del documento; recurre cuando una pieza todavía es demasiado grande. Granularidad adaptable al contenido a costa de heurísticas adicionales o llamadas de modelos adicionales. Fragmentación tardía. Primero ejecute el documento completo a través de un codificador de contexto largo y luego agrupe por fragmento. Cada vector de fragmento conlleva un contexto de todo el documento porque la atención se ejecutó antes de la división. Elegante, pero requiere el codificador de contexto largo que estaba fragmentando específicamente para evitar pagar.
2.2.4 Resumen de la fragmentación
Aquí hay un resumen de los enfoques más comunes en la familia fragmentación.
En resumen, los recortes fijos son baratos y rompen fronteras. Superponga parches, con más fragmentos para almacenar y deduplicar. Chunk-and-pool le permite leer un documento largo sin prestar toda su atención, pero el método de agrupación media aplana cualquier cosa que abarque fragmentos. Un gran vector elude los límites y destruye la precisión.
Aquí es cuando empezamos a pensar en la ventana de contexto largo: pagar en computación, mantener todo exacto.
3. Experimentos y análisis
Hice 3 experimentos controlados y 1 medición de latencia, cada uno de los cuales tenía como objetivo una forma diferente en que las ventanas largas podrían generar su costo. El resumen es el siguiente:
3.1 Cómo se organizan los experimentos
Mismo modelo, mismos datos, misma receta de entrenamiento en los tres experimentos. Lo único que varía es la ventana de contexto o cómo cortamos el documento. Eso no es casual: es lo que nos permite atribuir un espacio a la ventana en lugar de al ruido en la configuración.
Modelo: un codificador de arquitectura ModernBERT con ~32 millones de parámetros, con un contexto nativo de 8192 tokens y que contiene RoPE, alternancia de atención local/global y unpadding. Para la verificación de capacidad en el Experimento 1, intercambié una variante de ~150M de la misma arquitectura (~4,7 veces más grande). Agrego un encabezado de clasificación lineal inicializado aleatoriamente en la parte superior (una capa AutoModelForSequenceClassification sobre la salida agrupada) y ajusto todo de un extremo a otro. Nada exótico. Si una ventana larga ayuda, esta es la configuración donde debería mostrarse. Hardware: una única GPU de consumo de 10 GB. Para ajustar secuencias de 8192 tokens en ese presupuesto, utilizo puntos de control de gradiente bf16 y un tamaño de lote más pequeño por dispositivo con acumulación para mantener el tamaño de lote efectivo (~16) igual que las 512 ejecuciones. La condición 8192 paga su propio costo de atención cuadrática.
La disciplina de la ablación. Las tres reglas siguientes se utilizan para que cualquier diferencia de precisión que observe entre los modelos de 512 tokens y 8192 tokens sea causada en realidad por la ventana de contexto, no por alguna otra variable que se haya colado.
Mismas filas. Las ejecuciones 512 y 8192 provienen del mismo subconjunto preclasificado en el mismo orden. La única variable por ejecución es max_length. Piso simbólico. Cada documento debe exceder los 512 tokens; requerimos ≥ 4096. Ningún documento breve diluye silenciosamente la comparación. Si 8192 no puede vencer a 512 aquí, está perdiendo entradas que realmente lo necesitan. Equilibrio de clases + línea base no entrenada. Las clases están equilibradas, por lo que la precisión del azar se fija en 0,50. Siempre utilizamos una cabeza no entrenada como control de cordura. Cae por casualidad, lo que confirma que el oleoducto no detecta nada espurio antes de que interpretemos cualquier brecha sobre él.
3.2 Experimento 1: el contexto largo no ayuda en la clasificación inicial
Datos. HUPD (el conjunto de datos de patentes de la USPTO de Harvard, Suzgun et al. 2022; CC-BY-SA-4.0): solicitudes de patente reales con la decisión de concesión del examinador adjunta. La tarea es la decisión binaria: dado el texto de la solicitud, será ACEPTADA o RECHAZADA. Cada documento es una aplicación completa (título, resumen, afirmaciones y descripción técnica extensa) y normalmente contiene decenas de miles de tokens. Preparación de datos: dos etapas. Primero, transmita la porción de HUPD de un mes y escriba una tabla de parquet plana con la etiqueta de decisión. En segundo lugar, filtre los documentos con ≥ 4096 tokens, luego equilibre a 700 documentos/clase para capacitación y 130/clase para evaluación: 1400 ejemplos de capacitación, 260 evaluaciones, extraídos de una mezcla aleatoria. Tanto la ejecución 512 como la 8192 obtienen filas idénticas byte por byte. Equilibrando la probabilidad de los pines en exactamente 0,50. Por qué este conjunto de datos: se eligió esta tarea porque parece, sobre el papel, el mejor caso posible para una ventana larga. Que una patente sea permitida depende de leer las reivindicaciones en comparación con la especificación completa: exactamente la señal dispersa y entre documentos que un contexto más amplio debería capturar. Por lo tanto, la comparación se inclina deliberadamente a favor de 8192. Luego, medí cuidadosamente: una sola semilla con un efecto de ~1 pp no dice nada, así que procesamos tres semillas (42, 1, 2) en las mismas filas y aplicamos una prueba t pareada entre ellas.
Aquí están los resultados:
La brecha media es de +1,15 pp. No se detenga ahí: mire las semillas individuales: +3,46, −1,54, +1,54 (Figura 8). Un efecto real no cambia de signo cuando solo cambias la semilla aleatoria. Eso no es variación en torno a una tendencia; eso es ruido. La prueba t pareada concuerda: t = 0,79, p = 0,51. La línea de base no entrenada se sitúa en 0,504 (probabilidad, como se esperaba), por lo que el proceso está bien y la precisión de ~0,63 es genuina. La ventana larga simplemente no agrega nada encima.
¿Por qué sucede? La razón resulta ser una carga frontal. El título y el resumen enmarcan la invención. Las afirmaciones independientes, donde en realidad se deciden la novedad y la obviedad, vienen inmediatamente después. Todo lo que sigue es en gran medida texto estándar de habilitación: párrafos de descripción técnica que respaldan las afirmaciones. Por el token 512, el modelo ya vio la respuesta. Alimentarlo con otras 7.680 fichas de texto de apoyo no mueve mucho la aguja porque la aguja ya estaba configurada.
La brecha no es una pequeña victoria a la espera de más cálculo. Es cero: medido rigurosamente, no aproximado.
¿Podría solucionarse esto con más formación o un modelo más grande? La objeción obvia a cualquier resultado nulo es que no lo entrenó lo suficiente. Entonces empujamos desde ambas direcciones, el mismo protocolo de filas idénticas en todas partes. Proporcioné más datos para cada clase, los aumenté a 900 documentos/clase (limitado por el suministro de aplicaciones RECHAZADAS largas) y cambié a 4 épocas en lugar de 2. La configuración de 150M mantiene los mismos datos pero intercambia el codificador ~4,7 veces más grande: el movimiento natural si el modelo de 32M simplemente carecía de la capacidad de explotar una ventana larga.
¿El resultado? Ninguno ayudó:
Tres configuraciones independientes, misma respuesta. La dirección es la que dice: la brecha no permanece plana; se reduce hacia cero a medida que agrega la señal de entrenamiento y la capacidad del modelo (+1,15 → +0,64 → +0,26 pp, Figura 9). Eso es lo opuesto a lo que parece un límite de capacidad. Si la ventana larga contenía una señal real, el modelo 32M era demasiado pequeño para usarlo; un modelo más grande y mejor capacitado ampliaría la brecha. Más bien, converge. Los mejores modelos dejan de dejarse engañar por el ruido del nivel de semilla que produjo el valor atípico +3,46 y llegan a la misma respuesta: los tokens tardíos no llevan nada para esta etiqueta.
Por lo tanto, la ventaja a largo plazo de la clasificación de patentes anticipada es nula. No es "una pequeña victoria que valga la pena perseguir con más cómputo".
3.3 Experimento 2: fragmentar coincide (y supera) el pase completo de 8192
El experimento 1 demostró que el contexto extenso no ayuda con una tarea concentrada al principio. Pero ¿qué pasa si realmente necesitas leer el documento completo? ¿Chunk-and-pool le permite llegar allí sin el coste cuadrático?
Datos: Un corpus de patentes diferente, deliberadamente: big_patent (Sharma et al. 2019; CC-BY-4.0). Nueve secciones del CPC (Necesidades humanas, Operaciones/Transporte, Química, Textiles, Construcciones fijas, Mecánica, Física, Electricidad, Tecnología emergente), y la tarea es clasificar el campo de descripción larga de cada patente en el correcto. El uso de un conjunto de datos separado del Experimento 1 descarta peculiaridades específicas del HUPD que impulsan el resultado. Preparación de datos: la misma disciplina que antes: transmitir big_patent, conservar solo los documentos de más de 4096 tokens (un prefiltro de caracteres examina los obviamente cortos antes de tokenizarlos), equilibrar las nueve clases, reducir la muestra a 5000 train/1000 eval en la semilla 42. La probabilidad es 1/9 ≈ 0,111. La línea de base no entrenada aterriza allí, por lo que todo lo que esté por encima de ~0,11 es una señal real.
Tres contendientes, mismo codificador de ~32M, mismos datos:
512 truncamiento. Solo las primeras 512 fichas. 8192 pase completo. Una pasada cuadrática por todo el documento. Chunk-512-piscina. Divida cada documento en hasta 16 fragmentos de 512 tokens. Codifique cada fragmento de forma independiente. Tome el vector [CLS] de cada fragmento, combine la media en todos los fragmentos reales y clasifique el resultado. Lee el documento completo. Sin atención cruzada.
Comprobemos el resultado:
El grupo de fragmentos obtiene una puntuación de 0,654. El pase completo de 8192 obtiene una puntuación de 0,632. Un solo pase 512 obtiene una puntuación de 0,603. Chunk-pool también se ejecuta en 597 s, que es 4,6 veces más rápido que 8192.
Lo sorprendente es que el método más barato gana por completo.
¿Por qué? Cuatro razones.
El codificador fue entrenado previamente principalmente en pasajes de ~512 tokens. Una porción de 512 tokens está en distribución. Una secuencia de 8192 tokens se encuentra en la larga cola de lo que ha visto el modelo. Dieciséis lecturas limpias de 512 transportan más señal utilizable que una lectura extendida de 8192. Los pases largos llaman la atención sobre el ruido. En una etiqueta cargada al principio, los tokens discriminativos son una pequeña porción de 8192. Atención total significa que cada token atiende a los demás, por lo que la mayor parte de ese cálculo O(n²) se destina a tramos irrelevantes. En un conjunto de entrenamiento de 5000 documentos, esa libertad adicional es una superficie de sobreajuste, no una señal. La combinación de medias en 16 fragmentos es un conjunto leve. Un promedio de 16 puntuaciones independientes suaviza el ruido por fragmento. Un único vector 8192 no tiene tal suavizado. Esa es la ventaja repetible: el chunk-pool es más robusto, no sólo más barato. Lo único que agrega 8192 sobre el grupo de fragmentos es la atención entre fragmentos. Cuando la discográfica no necesita tramos distantes para comunicarse entre sí, esa capacidad es puro costo.
Una advertencia sobre el costo: el chunk-pool es 4,6 veces más barato que 8192, no más barato que un solo pase de 512. Todavía codifica hasta 16 fragmentos, por lo que es ~6 veces más pesado que uno de 512 adelante. La victoria es "leer el documento completo por una fracción del costo de 8192", no "gratis".
Y la limitación: el grupo de fragmentos puede fallar cuando la respuesta requiere unir partes distantes del documento. Si el razonamiento entre fragmentos importa, la agrupación de medias colapsa. Chunk-pool también es un método adecuado para la clasificación de documentos largos de carga frontal en el Experimento 1.
3.4 Experimento 3: para la recuperación, fragmentar es mejor que incrustar todo el documento
Pruebas del experimento 3 en el contexto de recuperación, que se afirma que está directamente relacionado con la sonda de tramo dividido (Parte 2).
Datos: cada hecho objetivo tiene dos mitades: una entidad (el “quién/qué”) y una clave (el “valor”). El documento correcto es el único que contiene ambos. Los negativos duros contienen cada uno solo la mitad. Un recuperador que pierde la unión entre la entidad y la clave no puede separar el documento correcto de un casi accidente.
Tomemos un ejemplo para facilitarlo:
Di que el hecho que estás buscando es: "Marie Curie ganó el Premio Nobel".
“Marie Curie” es la entidad (que) “ganó el Premio Nobel” es la clave (lo que pasó)
El documento correcto contiene ambas piezas juntas. Cada uno de los documentos señuelo (negativos duros) contiene solo una pieza: en uno se menciona “Marie Curie” en alguna parte, en otro se menciona el “Premio Nobel”, pero para otra persona. Un perro perdiguero débil no puede notar la diferencia.
Ahora el experimento divide cada hecho de dos maneras:
DENTRO de un trozo, ambas mitades caen en la misma ventana de 512 tokens. El perro perdiguero ve el hecho completo de una sola vez. A caballo entre una frontera: “Marie Curie” termina en el fragmento 1, “ganó el Premio Nobel” termina en el fragmento 5. El hecho se divide en dos ventanas separadas.
Eso es lo único que cambia entre las dos condiciones. Todo lo demás es idéntico. Por lo tanto, cualquier caída en la precisión de la recuperación cuando se pasa de DENTRO a A TRAVÉS le indica exactamente cuánto duele el límite de un fragmento cuando atraviesa un hecho.
La sonda tiene 160 objetivos por condición (480 documentos en total), se ejecuta sin disparo. Sin ajustes. Estoy midiendo la representación directamente.
Tres estrategias de recuperación, el mismo codificador en todas partes:
Fragmento ingenuo: ventanas de 512 tokens, recupere el fragmento que mejor coincida Fragmento superpuesto: ventanas de 512 tokens con superposición de 128 tokens Pase completo: incruste todo el documento como un vector de ≤8192 tokens
Métrica: nDCG@10.
Lo que nos dice el resultado:
Fragmento ingenuo: mejor entre 3 (0,097) cuando el hecho se ajusta a un fragmento, muerto (0,0) cuando no. El fragmento 4 tiene la entidad; El fragmento 5 tiene la clave. Ningún fragmento tiene ambos. La recuperación del mejor fragmento no puede unirlos, por lo que no devuelve nada útil. Trozo superpuesto: la solución robusta y práctica. Una superposición de 128 tokens significa que alguna ventana siempre abarcará el límite y abarcará ambas mitades. Es el único método que realmente mejora en el caso combinado (0,082). Pagas algunos trozos extra. Eso es todo. No es un modelo más grande, ni una ventana contextual más larga, solo ventanas superpuestas. Pase completo: incrustar todo el documento como un vector no funciona. Las puntuaciones de incorporación de documentos completos son cercanas a cero en todos los ámbitos (0,006–0,030). La razón es simple: un vector denso tiene un tamaño fijo. No importa la longitud del documento: los mismos cientos de números tienen que comprimirlo todo. Agregue 1.300 tokens de contexto irrelevante alrededor de su hecho de dos partes y el hecho se promediará en el ruido. El contenido genérico lo ahoga. Ni siquiera ayuda cuando el hecho está claramente dentro del documento (0,006). La dilución ocurre independientemente.
Esta es exactamente la razón por la que los sistemas RAG de producción fragmentan antes de incrustar en lugar de incrustar documentos completos. Un solo vector denso simplemente no puede sostener una aguja enterrada en un pajar.
3.5 Lo que realmente cuesta 8192 por inferencia (medido)
Pases hacia adelante en tiempo real sobre el modelo ajustado:
En la Figura 13, se muestra que el procesamiento por lotes ayuda con 512 tokens (~10×), pero apenas importa con 8192. La razón es el cuello de botella que está enfrentando. En 512, una única secuencia corta deja a la GPU prácticamente inactiva. Está pagando gastos generales de lanzamiento por llamada, no haciendo un trabajo real. El lote 8 reduce la latencia de 21,2 a 2,2 ms/doc (una ganancia 10 veces mayor) simplemente distribuyendo ese costo fijo entre más documentos. En 8192, una secuencia ya satura la GPU. La atención es O(n²), y con 8k tokens, ese costo cuadrático llena todo el cómputo disponible. No queda nada que recuperar para el procesamiento por lotes. La latencia se mantiene en torno a los 50 ms/doc independientemente del tamaño del lote. En términos de rendimiento, un modelo 512 por lotes procesa 447 documentos/s. Un modelo 8192 gestiona 20. Esa es una brecha de 22x. La CPU en 8192 es peor. 2.831 ms/doc. 0,35 documentos/s. Eso es 51 veces más lento que la CPU en 512 y aproximadamente 1300 veces más lento que un modelo 512 con GPU por lotes. Las CPU no tienen un paralelismo amplio para absorber el costo n², por lo que llega por completo. No hay ningún truco para solucionar esto. La regla práctica: el contexto largo es solo para GPU. Si su modelo funciona con CPU (implementaciones de borde, infraestructura limitada, configuraciones sensibles a los costos), debe permanecer en 512.
3.6 El principio de carga frontal
Estos experimentos comparten un patrón. Cada vez que se suponía que la opción barata iba a perder, no fue así.
El motivo es la dispersión de la señal, no la longitud del documento. Los documentos largos (en este caso patentes) tienden a concentrar su señal útil cerca de la parte superior o a dividirse limpiamente en trozos. Un pase de 512 fichas capta la mayor parte. Un pase completo de 8192 tokens vuelve a leer la misma señal a un costo mucho mayor.
Una advertencia honesta: no probamos tareas en las que la señal esté realmente dispersa en todo el documento. El razonamiento de múltiples saltos, la búsqueda de cláusulas contractuales, la evidencia que solo tiene sentido cuando se leen en conjunto: esos son casos de uso reales, y una ventana larga es la herramienta adecuada para ellos. Nada aquí dice que el contexto largo sea inútil. Dice que en la típica clasificación de documentos largos y recuperación de un solo vector, gana el camino barato. El contexto prolongado debería ser una elección deliberada, no una opción predeterminada.
3.7 Un árbol de decisiones: cuándo utilizar un contexto largo
Los tres experimentos se resumen en una sola pregunta: ¿dónde vive la señal discriminativa?
Sugiero el árbol de la Figura 14 para ayudarle a elegir su herramienta a partir de una propiedad de la tarea, donde vive la señal discriminativa, no de la longitud del documento.
Si un humano pudiera responder desde los primeros párrafos, la señal está cargada al frente. Usa 512 fichas (Experimento 1). Si necesita el documento completo, fragmentelo y agrupelo (Experimento 2). Sólo cuando la señal se dispersa por todo el texto completo se pasa a herramientas más costosas, e incluso entonces, la recuperación de fragmentos superpuestos (Experimento 3) es mejor que la incrustación de todo el documento. Un verdadero pase de 8192 tokens solo se justifica cuando es necesario relacionar evidencia distante de forma conjunta dentro del modelo.
Una anulación estricta: si está sirviendo en CPU o bajo una restricción de latencia, 8192 está fuera de la mesa independientemente de lo que diga el árbol.
En otras palabras,
4. Conclusión
4.1 Lo que encontramos
¿Aumentar el límite de contexto de 512 a 8192 mejora la precisión? ¿Existe una forma más económica de llegar allí? En cada tarea que medimos, la opción costosa no ganó.
La clasificación de patentes no obtuvo nada confiable a partir de 8192, en tres configuraciones de modelo. Chunk-and-pool igualó o superó un pase completo de 8192 con 4,6 veces menos cálculo. Para la recuperación, las incrustaciones fragmentadas con superposición superaron a las incrustaciones de documentos completos y solucionaron el único fallo real de la fragmentación (un hecho dividido a través de un límite) para un puñado de fragmentos adicionales, no una ventana cuadrática.
Esto no es "el contexto largo es una estafa". Es más específico que eso: el contexto largo ayuda cuando la señal está dispersa en un documento y no se puede encontrar cerca del inicio. La mayoría de los documentos largos que la gente procesa no están elaborados de esa manera. El texto inicial hace la mayor parte del trabajo y el truncamiento no le cuesta mucho.
4.2 Una regla de decisión simple
Pregunte siempre dónde reside su señal, no cuánto tiempo duran sus documentos.
¿La señal está cerca de la cima? Utilice 512. Su modelo funcionará bien. ¿Necesitas leer el documento completo? Pruebe primero fragmentar y agrupar. Superó a 8192 aquí con 4,6 veces menos cálculo. ¿Haciendo recuperación? Trozo con superposición. Las incrustaciones de documentos completos de un solo vector diluyen la señal. La superposición soluciona los recortes de límites de forma económica. ¿Realmente necesitas 8192? Asegúrate de hacerlo. Analice sus errores: ¿las respuestas incorrectas aparecen tarde en documentos donde la evidencia clave aparece tarde? Si no, no estás pagando por nada. ¿En la CPU? 8192 probablemente esté fuera de la mesa. Funcionó a 2,8 s/doc en nuestras pruebas.
4.3 Limitaciones
No probé una tarea en la que la señal esté realmente dispersa en todo el documento. Ése es el régimen en el que debería ganar una ventana larga, pero no lo midí directamente. Lo afirmo a partir de la literatura, no de estos datos. Todos los experimentos de clasificación utilizaron patentes. El argumento de la concentración anticipada probablemente también sea válido para documentos y presentaciones legales, pero no podemos afirmarlo con seguridad. El experimento de recuperación es sintético por diseño. Eso es intencional: aísla el mecanismo exacto que nos interesa (recortes de límites), pero no es un número en la clasificación. Se eligieron tamaños de subconjuntos para que el entrenamiento de 8192 fuera manejable. Conjuntos de datos más grandes podrían reducir la brecha en una fracción de punto. No cambiarán de qué lado del cero cae.
Nada de esto cambia el hallazgo central. El truncamiento y la fragmentación solo dañan cuando la señal pasa el corte o cruza un límite. Si esa es su situación es exactamente lo que prueban los experimentos.
4.4 ¿Qué sigue?
Tres cosas que vale la pena hacer:
Una tarea de clasificación genuinamente dispersa. Detección de cláusulas contractuales, verificación de reclamaciones en documentos largos. Algo donde la respuesta no puede venir desde la primera página. Ese es el experimento que completaría el mapa. Grupo de fragmentos en una tarea dispersa. La agrupación de medias funciona bien en documentos cargados al principio. La predicción es que se descompone cuando la respuesta requiere relacionar fragmentos entre sí. Hay que confirmarlo, no asumirlo. Superposición de barrido para recuperación. Usamos una superposición de 128 tokens. La relación coste/precisión entre diferentes tamaños de superposición es la cuestión práctica de ajuste y la dejamos sin respuesta.
5. Referencias y recursos
Cada conjunto de datos, modelo y técnica a los que se hace referencia en las cuatro partes incluye fuentes primarias y licencias.
Conjuntos de datos
Modelos y arquitectura
ModernBERT: la arquitectura del codificador utilizada (RoPE + atención alternante local/global + desrelleno, contexto de 8192 tokens). Warner et al., 2024 · arXiv:2412.13663. El codificador de clasificación es un modelo de arquitectura ModernBERT en las escalas de ~32M y ~150M. Incrustador de recuperación: nomic-ai/modernbert-embed-base, un modelo de incrustación de arquitectura ModernBERT entrenado en recuperación (contexto 8192, Apache-2.0) · huggingface.co/nomic-ai/modernbert-embed-base.
Técnicas básicas (Parte 2)
Tendencia de la ventana de contexto (gráfico de la parte 1)
BERT (1810.04805), RoBERTa (1907.11692), Sentence-BERT (1908.10084), Longformer (2004.05150), BigBird (2007.14062), E5 (2212.03533), BGE (BAAI/bge-base-en-v1.5), jina-embeddings-v2 (2310.19923), nomic-embed-text (2402.01613), BGE-M3 (2402.03216), ModernBERT (2412.13663).