RoPE: dando noción de posición a los modelos de lenguaje

Los modelos de lenguaje como ChatGPT, Gemini o Claude no leen el texto palabra a palabra de forma secuencial como lo hacemos los humanos. Leen todo el texto a la vez, en paralelo. Esto proporciona muchas ventajas, como el aprovechamiento de GPUs, pero también plantea un problema: ¿cómo sabe el modelo el orden de las palabras? Vamos a explorar la solución más adoptada por los modelos modernos: RoPE.

La importancia de la posición

En los modelos de lenguaje (LLMs) modernos, basados en la arquitectura transformer, el primer paso es un preprocesado del texto en el que este se pasa a una representación numérica, más apta para un modelo de deep learning. Este proceso consta de dos partes, por un lado el tokenizado, que divide el texto en fragmentos (tokens), y por otro lado el embedding, que crea representaciones vectoriales de estos tokens (embeddings).

Texto

«En 2014 un paper lo cambió todo.»

tokenizado

Tokens

2014

pap

camb

ió

todo

embedding

Embeddings

0.32-0.710.140.88⋮

-0.540.910.23-0.47⋮

0.670.12-0.390.55⋮

0.81-0.220.76-0.09⋮

0.440.19-0.520.37⋮

0.440.63-0.180.72⋮

-0.330.570.91-0.64⋮

0.71-0.280.490.15⋮

0.29-0.850.410.16⋮

0.05-0.110.030.08⋮

Fragmentos de una misma palabra

Figura 1. El texto se divide en tokens, que pueden ser palabras completas o fragmentos de ellas, y cada token se convierte en un vector de números: su embedding. Valores ilustrativos.

Un embedding, por sí solo, captura el significado de un token. Sin embargo, el significado de un texto no depende solamente del significado de cada token, sino también del orden de estos. «El perro persigue al gato» y «El gato persigue al perro» contienen exactamente los mismos tokens, pero no significan lo mismo.

perro

persigue

gato

El perro es quien persigue.

gato

persigue

perro

El gato es quien persigue.

sin posición

persigue

gato

perro

Lo que ve el modelo

Figura 2. Las dos frases tienen los mismos tokens. Sin información de posición, el modelo recibe en ambos casos el mismo conjunto, como una bolsa de palabras.

Por defecto, un LLM de arquitectura transformer recibe una secuencia de embeddings y los procesa en paralelo, como un conjunto desordenado. Aquí «en paralelo» no significa que los tokens se procesen de forma aislada, sino que se utiliza un mecanismo llamado «atención»: en cada capa, cada token mira a los que tiene antes, decide cuánto pesa cada uno de ellos y se reinterpreta a partir de esa mezcla.

Para ello, el embedding de cada token se proyecta en tres vectores mediante tres matrices aprendidas, y funciona de forma parecida a una base de datos: el query es lo que el token busca, el key es lo que ofrece a los demás y el value es la información que aporta. Cada token compara su query con el key de cada token anterior (y con el suyo propio) mediante un producto escalar, y el resultado es la puntuación de atención, una por cada pareja de tokens. Esas puntuaciones se normalizan y deciden cuánto pesa el value de cada token en la nueva representación del que hizo la pregunta. Dicho de otra forma, queries y keys deciden quién habla con quién, y los values son lo que se dice.

key

query

perro

persigue

gato

q · k

1.2

2.6

3.4

1.8

3.0

peso

5 %

18 %

41 %

8 %

28 %

1 · Comparar query · key de cada token → puntuación

2 · Normalizar puntuaciones → pesos que suman 100 %

3 · Mezclar suma de peso × value → nuevo «gato»

Figura 3. El token «gato» compara su query con la key de cada token hasta él mismo. Las puntuaciones se normalizan en pesos que suman 100 %, y con esos pesos se mezclan los values para obtener la nueva representación de «gato». Valores ilustrativos.

Este mecanismo es donde la falta de orden hace daño: mezclar un token con los que lo rodean sin saber cuáles vienen antes o después es tratar el texto como una bolsa de palabras (si dejamos a un lado que cada token solo puede mirar hacia atrás). Por eso se necesita alguna forma de introducir la noción de orden.

Dos preguntas

Es habitual contar la historia de la codificación posicional como una cronología: primero APE, luego ALiBi, luego RoPE, cada una mejor que la anterior. Pero se entiende mucho mejor si en vez de una lista la vemos como un espacio de diseño con dos preguntas independientes:

¿Qué se codifica: la posición absoluta o la distancia relativa? Esta pregunta determina cómo se comporta el modelo con secuencias más largas que las vistas en entrenamiento. Una posición absoluta que nunca se ha visto es un valor desconocido, mientras que una distancia relativa de 3 tokens es la misma en la posición 10 que en la 10.000.

¿En qué punto del proceso se inyecta esa información? Esta pregunta determina cuánto interfiere el orden con la semántica. No es lo mismo modificar el embedding de entrada que intervenir únicamente en el cálculo de la atención.

APE, ALiBi y RoPE son respuestas distintas a este par de preguntas.

Respuestas parciales

APE: absoluta y en el embedding

La primera solución, introducida en el propio Attention Is All You Need, fue Absolute Position Encoding (APE). Este mecanismo consiste en que antes de que el modelo procese el embedding de cada token, se calcula un vector fijo para cada posición de la secuencia y se suma directamente al embedding (existen variantes en las que este vector se aprende durante el entrenamiento, pero funciona igual). De esta forma el embedding codifica información tanto semántica como posicional.

Embedding de cada token

Enpos. 1

2014pos. 2

unpos. 3

…pos. n

Vector de posición fijo

PE(1)

PE(2)

PE(3)

PE(n)

Embedding final: significado + posición

En + PE(1)

2014 + PE(2)

un + PE(3)

… + PE(n)

Figura 4. La codificación posicional clásica suma a cada embedding un vector fijo que depende de su posición. El modelo recibe significado y posición mezclados en un mismo vector.

Una solución obvia hubiera sido numerar los tokens (1, 2, 3…), pero esos números crecen sin límite y tienen una escala muy distinta a la de los embeddings, cuyos valores suelen estar entre −1 y 1: sumarlos distorsionaría la información semántica. Por eso se usan el seno (dimensiones pares) y el coseno (dimensiones impares), que siempre producen valores en ese rango y que, al estar desfasados 90°, juntos describen sin ambigüedad cualquier punto de una rotación.

Volviendo a nuestras dos preguntas, APE responde absoluta a la primera y en el embedding de entrada a la segunda. Y de ahí salen sus dos limitaciones.

La primera, consecuencia de codificar posiciones absolutas, es que el modelo no generaliza bien para secuencias más largas que las vistas en entrenamiento. Si entrenamos el modelo con secuencias de 512 tokens, los vectores posicionales de las posiciones 513, 514 o 515 son patrones que nunca ha visto y no sabe interpretar. Además, la distancia relativa (que suele ser lo relevante en el lenguaje) no está codificada explícitamente: el modelo tiene que reconstruirla a partir de dos posiciones absolutas, y le resulta más fácil saber que un token está en la posición 5 que saber que está a 3 posiciones de otro.

La segunda, consecuencia de actuar sobre el embedding de entrada, es que una vez sumado el vector posicional, la información posicional y la semántica viven en el mismo espacio y son indistinguibles para las capas siguientes. El modelo tiene que dedicar capacidad a separar ambas señales, y esa contaminación se arrastra por toda la red.

ALiBi: relativa y sobre la atención

Otra solución relevante fue ALiBi (Attention with Linear Biases), contemporánea a RoPE. Su propuesta fue dejar intactos los embeddings y penalizar la atención entre dos tokens en función de la distancia que los separa: cuanto más lejos están, menos atención se prestan.

Puntuación q·k con el token n+1

Enpos. 1

2014pos. 2

⋯

todopos. n

Penalización según la distancia

−na n tokens

−(n−1)a n−1 tokens

⋯

−1a 1 token

Atención resultante: mayor cuanto más cerca

baja

algo mayor

⋯

máxima

Figura 5. Otra alternativa suma a cada puntuación de atención una penalización proporcional a la distancia. Los tokens cercanos reciben más atención que los lejanos.

ALiBi responde relativa a la primera pregunta y sobre la atención a la segunda, y con eso corrige de golpe los dos problemas de APE. Los embeddings quedan limpios, y la penalización es una fórmula que se puede evaluar para cualquier distancia, la haya visto el modelo o no: si nunca ha visto una secuencia de 600 tokens, simplemente la aplica.

El precio es una limitación distinta: la penalización no se aprende, sino que es un sesgo fijo que el modelo no puede desactivar, y siempre reduce la atención con la distancia. ALiBi impone como regla algo que en el lenguaje solo es cierto de media: que lo cercano importa más que lo lejano. Un nombre propio mencionado en la primera página de un documento largo sigue siendo relevante cien mil tokens después.

Además, la penalización se suma a una puntuación de atención ya calculada y depende solo de la distancia, sin mirar qué dicen los tokens. La posición corrige la comparación entre contenidos, pero no participa en ella.

RoPE: relativa y dentro de la atención

RoPE (Rotary Position Embedding) es el mecanismo de codificación de la información posicional introducido en el paper RoFormer (2021) y posteriormente adoptado por la mayoría de los LLM modernos.

Aquí conviene deshacer un malentendido habitual, porque RoPE suele describirse como «APE pero rotando en vez de sumando». La operación cambia, pero lo importante es dónde ocurre: RoPE no toca el embedding de entrada. Actúa dentro de cada capa de atención, rotando los vectores query y key justo antes de calcular su producto escalar. Los vectores value y el resto de la representación del token quedan intactos. Es decir, la posición influye en con quién habla cada token, pero no en qué contiene ese token.

RoPE se basa en una propiedad fundamental pero simple de la geometría: el producto escalar entre dos vectores rotados en el mismo plano, aparte del contenido de los dos vectores, solo depende de la diferencia entre sus ángulos de rotación, no de los ángulos absolutos. Esto es muy útil, porque el producto entre query y key es lo que el modelo utiliza para decidir cuánta atención se prestan dos tokens. Como cada token se rota una cantidad proporcional a su posición, la diferencia de ángulos entre dos tokens es precisamente su distancia relativa. La posición entra como absoluta y sale como relativa, sin necesidad de calcular explícitamente la distancia entre cada par de tokens.

Token nposición n → gira θ·n

Token mposición m → gira θ·m

θ·(n−m)el ángulo entre ambos solo depende de la distancia

Figura 6. RoPE gira cada token un ángulo proporcional a su posición. Al comparar dos tokens solo importa la diferencia de ángulos, θ·(n−m), que depende de la distancia entre ellos.

El diagrama es solo una simplificación de lo que hace RoPE. En la práctica hay una diferencia clave: RoPE no rota el vector completo, sino que divide sus dimensiones en parejas y hace $d/2$ rotaciones 2D en vez de una sola rotación $d$ -dimensional. Esto permite rotar cada pareja a una frecuencia distinta, de forma que capturen distancias a distintas escalas (y, de paso, las rotaciones 2D son mucho más baratas de calcular).

El mecanismo es muy similar al de un reloj, solo que en lugar de medirse tiempo se mide la distancia en una secuencia de tokens. Cada pareja de dimensiones, con su propia frecuencia de rotación, representa una aguja de este reloj. Las parejas de frecuencia alta (rotan rápido) capturan las distancias cortas, mientras que las de frecuencia baja (rotan despacio) capturan las distancias largas. Juntas, describen la distancia entre tokens a todas las escalas a la vez, igual que las tres agujas de un reloj determinan la hora exacta.

Vector query/key de 8 dimensiones, en parejas

x₀

x₁

Pareja 0θ₀ grandegira rápido

x₂

x₃

Pareja 1θ₁ mediogira a ritmo medio

x₄

x₅

Pareja 2θ₂ pequeñogira lento

x₆

x₇

Pareja 3θ₃ muy pequeñogira muy lento

Mismo token, misma posición: cada pareja ha girado un ángulo distinto.

Figura 7. Cada vector query y key se divide en parejas de dimensiones y cada pareja gira a una velocidad distinta. Las rápidas distinguen tokens cercanos; las lentas, relaciones a larga distancia. Ángulos ilustrativos.

La fórmula de RoPE para una pareja de dimensiones $(x_1, x_2)$ en la posición $m$ es:

\begin{pmatrix} x'_1 \\ x'_2 \end{pmatrix} = \begin{pmatrix} \cos(m\theta_i) & -\sin(m\theta_i) \\ \sin(m\theta_i) & \cos(m\theta_i) \end{pmatrix} \begin{pmatrix} x_1 \\ x_2 \end{pmatrix}

Y la frecuencia de rotación de cada pareja:

\theta_i = 10000^{-2i/d}

Donde:

$x_1, x_2$ : las dos dimensiones del vector query o key que forman la pareja
$m$ : posición del token en la secuencia
$\theta_i$ : frecuencia de rotación de la pareja i (decrece con i)
$i$ : índice de la pareja (0, 1, 2, …)
$d$ : dimensión del vector query o key
$10000$ : constante base que controla el rango de frecuencias

Con esto, RoPE ocupa la casilla que ninguna de las soluciones anteriores cubría: es relativo, como ALiBi, pero actúa dentro del producto query-key en lugar de sobre el resultado de ese producto. Y esa distinción es la que importa. Un sesgo ajusta una comparación que ya se ha hecho, sin saber qué contenían los tokens comparados. RoPE, en cambio, cambia la comparación misma: la distancia entra en el cálculo junto con el contenido, y de ahí sale una puntuación en la que ambos han intervenido a la vez.

Con un matiz: RoPE tampoco es del todo neutro. Al girar cada pareja a un ritmo distinto, sus contribuciones se desalinean con la distancia y la atención tiende a decaer. Pero no es una regla impuesta: es irregular en vez de monótono, y el modelo puede compensarlo.

Resumiendo las dos preguntas del principio:

Método	Qué codifica	Dónde actúa
APE	Posición absoluta	Sobre el embedding de entrada
ALiBi	Distancia relativa	Sobre la puntuación de atención ya calculada (sesgo fijo)
RoPE	Distancia relativa	Dentro del cálculo de la puntuación de atención

Lo que RoPE no resuelve

Se dice mucho que RoPE resuelve la extrapolación, pero no es cierto. Un modelo entrenado con RoPE a 4.096 tokens tampoco funciona bien a 16.000: la fórmula se puede evaluar para cualquier posición, pero las parejas de frecuencia baja apenas completan una fracción de vuelta durante el entrenamiento, y más allá entran en ángulos que nunca han visto. El modelo puede calcular la rotación, pero no sabe qué significa. Por eso existen técnicas como Position Interpolation o YaRN, que extienden la ventana de contexto de modelos ya entrenados reescalando esos ángulos. Funcionan porque toda la posición vive en un ángulo, y un ángulo se puede reescalar sin tocar nada más.

ALiBi, en cambio, sí alcanza secuencias más largas, pero llega vacío: como la penalización crece sin límite con la distancia, los tokens lejanos acaban apagados y la atención degenera en una ventana deslizante. Gana longitud, no contexto. RoPE falla de forma más honesta: se rompe justo donde se le acaba lo que ha visto, y por eso se puede arreglar.

Lo que explica su adopción, entonces, no es la extrapolación, sino el sitio donde actúa: RoPE no corrige una comparación ya hecha, sino que hace que la distancia forme parte de ella, con un coste añadido despreciable y sin ensuciar lo que cada token significa. No es casualidad que modelos como LLaMA, Gemma o Qwen lo hayan adoptado como estándar, y que muy probablemente esté también detrás de modelos como GPT o Claude, cuyos detalles técnicos no son públicos. Cuando un modelo entiende que «a 3 tokens de distancia» significa lo mismo en la posición 10 que en la 10.000, es RoPE quien está girando las agujas.

Referencias

Vaswani et al., Attention Is All You Need (2017)
Su et al., RoFormer: Enhanced Transformer with Rotary Position Embedding (2021)
Press, Smith y Lewis, Train Short, Test Long: Attention with Linear Biases Enables Input Length Extrapolation (2021)
Chen et al., Extending Context Window of Large Language Models via Positional Interpolation (2023)
Peng et al., YaRN: Efficient Context Window Extension of Large Language Models (2023)

Fondo: El viaje de la vida (1842), de Thomas Cole: La infancia, La juventud, La madurez y La vejez · National Gallery of Art, Washington