4  Qué hay dentro

El capítulo anterior dejaba el modelo como una caja que predice la siguiente palabra. Este la abre lo justo para entender tres cosas que después explican comportamientos muy concretos: por qué el modelo no ve letras, por qué el contexto cuesta dinero de forma no lineal y por qué a veces “se olvida” de algo que está en mitad del texto.

No hace falta más matemática que la de saber qué es una media ponderada.

4.1 El texto no entra como texto

Lo primero que ocurre con nuestro mensaje es que se trocea. No en palabras ni en letras, sino en tokens: fragmentos frecuentes que un algoritmo de compresión determinó a partir del corpus de entrenamiento. En español, un token viene a ser tres cuartos de palabra; en inglés, algo más. Los nombres propios raros, los identificadores y los números se parten en varios trozos.

"La factura FRA-2026-0087 asciende a 1.348,90 €"
 ▸ La | factura | FRA | - | 202 | 6 | - | 008 | 7 | asciende | a | 1 | . | 348 | , | 90 | €

Esto explica de golpe unas cuantas rarezas cotidianas:

• Que un modelo falle al contar las erres de “ferrocarril”: no ve letras, ve trozos.
• Que la aritmética se le atragante: 348 puede ser un token y 349 dos, así que no hay ninguna regularidad que aprender.
• Que el mismo texto cueste más caro en español que en inglés, porque los tokenizadores se optimizaron sobre corpus mayoritariamente ingleses.

Cada token se convierte en un vector, su embedding, que es su posición en un espacio de varios miles de dimensiones donde la cercanía significa parecido de uso. Ese espacio es el que sostiene la búsqueda semántica de la que vive RAG.

4.2 La atención, sin ecuaciones

La arquitectura que domina desde 2017 es el transformer (Vaswani et al. 2017), y su idea central es la atención: para procesar cada token, el modelo mira todos los demás y decide de cuáles hacer caso.

Puesto en un ejemplo. En la frase “la factura que envió el proveedor no incluye su número de cuenta”, para representar bien “su” hay que resolver a qué se refiere. El mecanismo de atención lo hace comparando el token actual con todos los anteriores y ponderando: mucho peso a “proveedor”, poco a “factura”, casi nada a “no”.

flowchart TD
    t["Token actual: <i>su</i>"] --> q["¿Con qué encaja?"]
    q --> a1["proveedor · 0.61"]
    q --> a2["factura · 0.22"]
    q --> a3["envió · 0.09"]
    q --> a4["resto · 0.08"]
    a1 --> r["Representación<br/>contextual de <i>su</i>"]
    a2 --> r
    a3 --> r
    a4 --> r

    classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
    classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
    class t,a1,a2,a3,a4 contexto
    class q,r modelo

Un modelo hace esto muchas veces en paralelo (varias cabezas de atención, cada una atenta a un tipo de relación distinta) y repite la operación en decenas de capas apiladas. Entre capa y capa hay una red neuronal corriente que es donde, según todo indica, se almacena buena parte del conocimiento factual.

Lo relevante para nosotros no es el detalle sino la consecuencia: el coste de la atención crece con el cuadrado de la longitud del contexto. Duplicar el texto de entrada no duplica el trabajo, lo cuadruplica. Todas las optimizaciones de inferencia de la última década giran alrededor de esquivar ese cuadrado, y aun así la asimetría persiste y se nota en la factura.

Nota¿Y por qué se llama “generativo preentrenado”?

El transformer original tenía dos mitades: un encoder que leía y un decoder que escribía, pensadas para traducción automática. La familia se partió después en tres ramas:

• Solo encoder (BERT y compañía): leen el texto entero de una vez, en ambas direcciones. Excelentes para clasificar, buscar y extraer. Siguen siendo la mejor opción para muchas tareas y son mucho más baratos.
• Solo decoder (la familia GPT y todos los grandes modelos actuales): generan un token detrás de otro, mirando solo hacia atrás. Son los que llamamos generativos.
• Encoder-decoder (T5, BART): útiles cuando hay una transformación clara de entrada a salida.

Que hoy todo el mundo use decoders no significa que sea siempre la elección correcta. Para clasificar diez mil correos, un encoder pequeño y ajustado sigue ganando en coste, latencia y estabilidad.

4.3 Escribir es hacerlo token a token

Un modelo generativo no produce una respuesta: produce un token, lo pega al final de la entrada y vuelve a empezar. La respuesta completa es el resultado de repetir eso cientos de veces.

Ese bucle tiene tres consecuencias que reaparecen en todo el libro:

1. La latencia depende de lo que escribe, no de lo que lee. Leer 50.000 tokens es una operación paralela y relativamente rápida; escribir 500 son 500 pasadas secuenciales.
2. Los errores se arrastran. Un token desafortunado pasa a formar parte de la entrada del siguiente paso y el modelo continuará de forma coherente con él. De ahí que las respuestas largas se descarrilen más que las cortas.
3. No hay marcha atrás. El modelo no puede revisar lo que ya escribió. Si queremos que revise, hay que montarlo fuera: es literalmente lo que hace un agente con un bucle de crítica.

Para no recalcular todo el contexto en cada paso, los sistemas guardan los cálculos intermedios de los tokens ya vistos en la caché KV. Esa caché es la razón de que muchos proveedores cobren menos por los tokens de entrada repetidos entre llamadas, y de que convenga poner lo estable al principio del prompt y lo variable al final. Es una recomendación de arquitectura, no de estilo: dinamitad el prefijo común y multiplicaréis la factura.

4.4 Esquivar el cuadrado

La caché KV evita repetir trabajo, pero a cambio ocupa memoria que crece con el contexto y que no se comparte entre conversaciones. Pasado cierto tamaño es ella, y no el número de parámetros, la que decide cuántas peticiones simultáneas caben en una GPU.

Desde 2025 hay una familia de arquitecturas que ataca eso de raíz, y conviene conocerla aunque solo sea para no llevarse una sorpresa al leer la ficha de un modelo nuevo. Sebastian Raschka las ha agrupado en un repaso que merece la pena tener a mano (Raschka 2025), y la idea común es sustituir la atención por un mecanismo recurrente con un estado de tamaño fijo: en lugar de guardar todos los tokens vistos, se guarda un resumen que se actualiza con cada token nuevo.

La variante más extendida se llama Gated DeltaNet y su estado se gobierna con dos puertas: una de decaimiento, que decide cuánto se olvida de lo anterior, y una de actualización, que decide cuánto entra de lo nuevo. Como el estado no crece, no hay caché KV que crezca, y la memoria pasa a ser constante con la longitud del contexto.

El precio se adivina en cuanto se enuncia: un resumen de tamaño fijo no puede contener un contexto arbitrariamente largo sin perder detalle. Por eso casi nadie lo usa en estado puro y lo que se ha impuesto es el híbrido, con tres capas de atención lineal por cada capa de atención completa. Las lineales llevan el grueso del trabajo y la completa, cada cuatro, repesca lo que el resumen se haya dejado por el camino.

flowchart LR
    l1["Atención lineal"] --> l2["Atención lineal"]
    l2 --> l3["Atención lineal"]
    l3 --> f["Atención completa"]
    f --> l4["..."]

    classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
    classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
    class l1,l2,l3,l4 modelo
    class f contexto

Hay un detalle bonito en esos modelos que conecta con lo que la atención no sabe de por sí: la codificación de posición aparece solo en las capas de atención completa. Las lineales no la necesitan, porque procesan la secuencia en orden y el orden ya está en la recurrencia. Es el mismo argumento de 2017 al revés.

NotaLas cifras, con fecha

La proporción 3:1 es la que usan Qwen3-Next y Kimi Linear. Sobre la reducción de la caché KV frente a un modelo de atención completa equivalente, el primero declara en torno a la mitad y el segundo llega al 75%, con hasta seis veces más rendimiento en la generación.

Son cifras de finales de 2025 y de los propios fabricantes, así que tomadlas como orden de magnitud. Lo que no va a caducar es la forma del compromiso: se cambia memoria constante por precisión en contextos largos, y el híbrido existe porque ninguno de los dos extremos convence.

La atención lineal es solo una de las cuatro direcciones que recoge ese repaso, y las otras tres se apartan bastante más de lo que este capítulo ha descrito:

Cuatro maneras de no ser un transformer estándar (Raschka 2025)

Familia	Qué cambia	Qué gana	Qué pierde
Híbridos de atención lineal	Estado recurrente fijo en la mayoría de capas	Memoria constante con el contexto	Detalle en contextos muy largos
Difusión de texto	Se desenmascara el texto en pasos en lugar de escribir token a token	Generación paralela	Respuesta en flujo, razonamiento y herramientas
Modelos de mundo de código	Se predice el estado del programa, no el siguiente token	Estados intermedios comprobables	Entrenamiento mucho más caro de montar
Transformers recursivos pequeños	Pocas capas aplicadas muchas veces	Tamaños ridículos en tareas acotadas	Todo lo demás

Ninguna de las tres últimas es todavía lo que os vais a encontrar al llamar a una API, y puede que alguna no llegue nunca. Están aquí por lo que enseñan de rebote: casi todo lo que damos por inevitable en un modelo de lenguaje es una decisión de diseño, incluida la de escribir de izquierda a derecha una palabra detrás de otra.

4.5 Dónde se guarda lo que “sabe”

El conocimiento factual del modelo vive en sus pesos, congelado en el momento del entrenamiento. Eso implica tres limitaciones que ninguna técnica de prompting arregla:

Lo que el modelo no puede saber por sí solo

Limitación	Qué significa	Qué la mitiga
Fecha de corte	No sabe nada posterior a su entrenamiento	Herramientas y RAG
Datos privados	Nunca vio vuestros contratos ni vuestro ERP	RAG
Conocimiento difuso	Recuerda mal lo que apareció poco	Contexto explícito

La conclusión práctica es que casi todo el trabajo de ingeniería en un sistema generativo consiste en meter en el contexto lo que el modelo no puede saber. Por eso la segunda parte del manual se llama Contexto y no “prompting”.

4.6 Lo que el contexto no arregla

Existe un fenómeno bien documentado que conviene conocer antes de diseñar nada: los modelos atienden mejor al principio y al final de un contexto largo que a su parte central. Es lo que se conoce como el problema de lost in the middle (Liu et al. 2024).

Es decir, que meter cien páginas en el contexto no garantiza que el modelo use la línea que importa si está en la página cincuenta. Las ventanas de contexto han crecido enormemente desde entonces y el efecto se ha atenuado, pero no ha desaparecido, y sigue siendo una razón de peso para recuperar poco y bueno en lugar de volcarlo todo.

Con esto ya tenemos lo que hace falta para hablar de la parte que se paga: la inferencia.

Liu, Nelson F., Kevin Lin, John Hewitt, et al. 2024. «Lost in the Middle: How Language Models Use Long Contexts». Transactions of the Association for Computational Linguistics 12: 157-73.

Raschka, Sebastian. 2025. Beyond Standard LLMs. Https://magazine.sebastianraschka.com/p/beyond-standard-llms.

Vaswani, Ashish, Noam Shazeer, Niki Parmar, et al. 2017. «Attention is All you Need». Advances in Neural Information Processing Systems 30.