Usted envía una petición y, un segundo después, la respuesta empieza a escribirse en la terminal. No aparece de golpe, sino que se va escribiendo: trozo a trozo, como si alguien la estuviera tecleando en ese mismo momento. A veces, antes de eso, en la pantalla aparece Thinking y se queda un rato; la respuesta llega bastante más tarde, pero es más sensata.
Todo esto es consecuencia de un solo mecanismo. Veamos cómo funciona un modelo de lenguaje grande: qué hace con su texto, con qué mide su longitud, de dónde saca sus conocimientos y qué ocurre en esos segundos en los que está pensando. Ninguno de estos datos hace falta para pulsar Enter. Pero juntos cambian bastante lo que usted espera de la respuesta.

El material está simplificado a propósito. Así se lee rápido y responde a la pregunta de qué pasa en su pantalla. Un análisis preciso no cabe aquí ni podría caber: solo un bloque del transformer da para un trabajo aparte.
Un modelo de lenguaje estima la continuación
Empecemos por lo básico. Un modelo de lenguaje grande, también llamado LLM, de large language model, no es un programa con ventana y botones, ni tampoco un chat. Es un mecanismo al que se le hacen llamadas: se le entrega el texto de la conversación y devuelve una continuación. Claude Code, un chat web, las sugerencias en el editor: todo eso es un envoltorio alrededor de esa llamada, y cada uno tiene el suyo.
Y el modelo sabe hacer una sola cosa: a partir del comienzo de un texto, estimar qué continuación es más probable. No encontrar la respuesta correcta, sino estimar la probabilidad, y no para una sola opción, sino para cada una de las que hay en su vocabulario.
Lo más fácil es verlo con una frase corta. Complete en voz alta: "el café lo tomo sin..." Lo primero que le viene a la cabeza es "azúcar", luego "leche", y en cambio "internet" no encaja para nada, aunque gramaticalmente todo está bien. Usted lo calculó en una fracción de segundo y sin pensarlo. El modelo hace lo mismo, solo que de manera formal y hasta el final: recorre todo su vocabulario y le pone un número a cada candidato.
Fíjese en lo que no aparece en el esquema. Ninguna opción está marcada como correcta: solo hay continuaciones más y menos probables. Y esos números no salen de contar cuántas veces aparecía esa combinación en los textos; así funcionaba otra tecnología muy distinta, mucho más simple, que se abandonó bastante antes de los modelos actuales. La probabilidad se calcula a partir de patrones que se fijaron dentro del modelo durante el entrenamiento. Por eso sale también para una frase que nadie había escrito antes que usted.
En qué se diferencia un LLM de un chat y de un agente
Estas tres palabras se usan a menudo como sinónimos, aunque describen capas distintas del sistema.
- LLM - el modelo de lenguaje en sí. Recibe el contexto y genera el siguiente mensaje.
- Chat - la interfaz y el programa alrededor del LLM. Guarda el historial, arma la petición, se la envía al modelo y muestra la respuesta.
- Agente - un LLM con un objetivo, un ciclo de trabajo y herramientas. Puede pedirle a la aplicación que lea un archivo, haga una búsqueda o ejecute un test, ver el resultado y elegir el siguiente paso.
En resumen: el LLM propone una solución, el chat organiza la conversación y el agente conecta las decisiones del modelo con acciones en el mundo exterior.
Tokens, no palabras
Al esquema anterior le hace falta una corrección: las palabras aparecen enteras solo para que se vea más claro. En realidad, el modelo divide el texto en tokens, trozos de su propio vocabulario. Un token puede ser una palabra entera, parte de una palabra o un signo de puntuación, y el espacio suele ir a parar dentro del token siguiente y no cuenta como unidad aparte.
El vocabulario se arma de antemano, con un conjunto grande de textos, y se arma poco a poco: un algoritmo busca secuencias de caracteres frecuentes y las une en trozos más grandes. Lo que aparecía a menudo recibe su propio token. Por eso en el vocabulario terminado conviven, mezclados, palabras enteras y pedazos de palabras.
Cada token del vocabulario tiene su número, y el texto entra en el modelo ya convertido en números: primero la cadena se corta en trozos, luego cada trozo se sustituye por su número. Para volver a texto legible, la respuesta se decodifica con ese mismo vocabulario.
De aquí salen dos cosas que conviene tener presentes. La primera: cada familia de modelos tiene su propio vocabulario y no corta la misma cadena de la misma manera, y las estimaciones del tipo "un token es más o menos tres cuartos de palabra" son una referencia aproximada para el inglés, nada más. La segunda: un idioma que aparecía menos en los textos de entrenamiento se corta en trozos más pequeños. Una palabra en español se parte a menudo en dos o tres tokens donde la inglesa cabe en uno.
Todo esto se entiende mejor viéndolo una vez que leyéndolo. Abra The Tokenizer Playground, pegue ahí un par de sus peticiones habituales y, a continuación, el mismo texto en inglés: enseguida se ve en qué trozos se deshace la cadena y cuántos salen. Solo una salvedad: el tokenizador de esa página pertenece a un modelo concreto, y el modelo con el que usted trabaja lo dividirá a su manera. Vale la pena ir para ver el fenómeno, no para sacar una cifra exacta.
La consecuencia práctica es inesperada. El modelo no ve letras, sino trozos, y las preguntas sobre letras le cuestan bastante más que las preguntas sobre el significado. Pídale que cuente cuántas letras "o" hay en una palabra larga, y la respuesta puede perfectamente salir mal. No porque la tarea sea difícil, sino porque la palabra le llegó al modelo en dos trozos y, para él, dentro de ellos no hay letras sueltas.
Cómo se arma la respuesta a partir de los tokens
Ahora juntemos el mecanismo completo, y resultará más simple de lo que parece. El modelo estima las opciones, se elige una y se añade al final del texto. Después, todo vuelve a empezar: con el mismo texto, solo que un token más largo.
La respuesta terminada no estaba guardada en ningún sitio ni se sacó de ninguna parte: se armó en tantos pasos como tokens tiene. Tampoco termina por un temporizador: en algún momento, la continuación más probable resulta ser un token especial que significa "aquí se acaba", y la generación se detiene.
De la misma imagen se desprende otro detalle. El modelo no puede borrar lo que ha escrito: un token que entró en el texto se queda ahí y forma parte de la entrada de cada paso siguiente. Solo puede corregirse igual que una persona en una conversación: con la frase siguiente.
Y aquí va una consecuencia que sorprende a mucha gente: la misma pregunta, hecha dos veces, puede dar dos respuestas distintas. En cada paso, la elección no recae necesariamente en la opción más probable, y un solo token que se desvía arrastra consigo todo lo que viene después. Lo más habitual es que cambie solo la formulación, pero a veces cambia también la solución propuesta.
La forma en que la respuesta va apareciendo en la ventana de Claude Code no es un indicador de carga, sino los propios pasos de la generación: el modelo entrega los tokens a medida que los elige, y el programa los muestra en pantalla al instante. Por eso una respuesta larga aparece poco a poco y no de golpe después de una pausa.
Por qué al modelo se le llama grande
La palabra "grande" no describe el peso de un archivo guardado en algún sitio. Detrás hay dos escalas muy distintas, y conviene hacerse una idea realista de ambas.
La primera es el volumen de texto que el modelo recorrió durante el entrenamiento: libros, artículos, documentación, foros, código, y todo eso en cantidades que una persona no leería ni en varias vidas. La segunda es el número de parámetros. Un parámetro es un número dentro del modelo, uno de los ajustes que se fueron afinando durante el entrenamiento. Hay miles de millones. En los modelos abiertos esa cifra se pone directamente en el nombre: 7B, 14B, 70B, donde B significa billion, es decir, mil millones.
Y aquí viene el punto donde es fácil equivocarse. El número de parámetros no es un ranking de calidad. En el resultado influyen los datos con los que aprendió el modelo, su arquitectura, las tareas para las que lo afinaron y cómo lo comprimieron para que cupiera en algún sitio. Un modelo más pequeño puede superar sin problema a uno más grande en un trabajo concreto. Un número grande en el nombre, por sí solo, no promete nada.
Y otra cosa más que, a esta escala, sale como por sí sola. Para continuar con coherencia una frase sobre un test que ha fallado, no basta con saber qué palabras suelen ir juntas. Hay que captar además cómo están hechos los tests. El modelo aprendía a adivinar palabras y, de paso, en sus parámetros se fijó lo que esas palabras describen. De ahí viene la sensación de que sabe cosas, aunque el mecanismo no ha cambiado ni un ápice.
De dónde saca el modelo sus conocimientos
Las fuentes son exactamente dos, y confundirlas sale caro.
La primera son los parámetros. En ellos se fijaron los patrones aprendidos durante el entrenamiento. No es un catálogo donde cada entrada lleva anotada su fuente: el conocimiento está repartido entre una multitud de números, y de ahí no se puede sacar una cita exacta. Por eso el modelo es capaz de dar algo casi correcto: la forma está bien, el nombre suena conocido, pero el detalle concreto no es el correcto.
La segunda es lo que está ahora mismo en la conversación: su petición, todo lo dicho antes, el contenido de los archivos abiertos, la salida de los comandos ejecutados. Esta fuente es precisa, pero dura poco. No pasa a los parámetros, y la siguiente conversación ya no sabe nada de ella.
Todo lo demás que uno tendería a llamar una fuente aparte (un archivo de memoria, la documentación encontrada, la respuesta de un servicio externo) llega por ese mismo camino: primero entra en la conversación y solo después influye en la respuesta. El modelo no tiene una puerta propia hacia el proyecto o hacia internet.
La primera fuente tiene una fecha, y esa fecha tiene nombre: knowledge cutoff. Es una referencia de hasta qué momento los conocimientos integrados del modelo suelen estar al día. Sobre una biblioteca que salió después de esa fecha, el modelo sabe solo lo que se haya puesto en la conversación actual.
Aquí la salvedad importa más que la propia fecha. El cutoff no significa que hasta ese día el modelo lo sepa todo y, después, nada. También hay huecos dentro del periodo: sobre algunos temas había pocos textos, en otros casos se contradecían entre sí, y hay cosas que simplemente no entraron en los datos de entrenamiento. La fecha marca un límite superior, no promete que todo lo anterior esté completo.
Y una cosa pequeña, pero útil. Preguntarle el cutoff al propio modelo no es muy buena idea: responderá con una generación, es decir, elegirá algo verosímil. La fecha exacta está en la documentación de cada versión concreta, y en modelos vecinos de una misma familia puede perfectamente ser distinta.
Qué significa Thinking
Cuando en la pantalla aparece Thinking, el modelo no se ha pasado a otro modo de conciencia. Simplemente se le ha dado espacio para pensar antes de empezar a responder. Técnicamente es exactamente la misma generación: primero el modelo escribe un borrador para sí mismo (analiza la tarea, sopesa opciones, discute consigo mismo) y solo después entrega el texto final. Cuánto pensar exactamente lo deciden en gran parte los propios modelos actuales: en una pregunta sencilla el borrador es corto o no hay ninguno, en una enrevesada es más largo.
Para qué sirve se ve con un ejemplo. Un agente busca la causa de un test que falla. La primera explicación verosímil apunta al cliente de un servicio externo, pero el test de al lado y el texto del error dicen otra cosa: el problema está en el procesamiento de los datos. Con espacio de sobra, el modelo alcanza a notar la contradicción y cambiar de rumbo antes de proponer un cambio. Aquí la ganancia no está en la longitud del razonamiento, sino en que la comprobación cambió el siguiente paso.
En general, la primera explicación resulta a menudo la equivocada. Es verosímil, pero la verosimilitud era justamente el criterio con el que el mecanismo la eligió.
Ahora, sobre cuándo compensa el razonamiento adicional. Cuesta tiempo, y no tiene sentido activarlo para cada pequeñez.
| Normalmente basta con una respuesta rápida | Conviene dar espacio al razonamiento |
|---|---|
| explicar qué hace un trozo de código que está en pantalla | encontrar por qué falla un test cuando intervienen varios archivos |
| corregir una errata o el formato | comparar dos soluciones junto con sus limitaciones |
| resumir un texto que usted acaba de pasar | planificar una reestructuración en la que los pasos dependen unos de otros |
La referencia es sencilla: cuantas más bifurcaciones y dependencias tiene la tarea, más útil es dejar que el modelo se extienda. Al renombrar una variable, usted tardará menos en revisar el resultado terminado que en leer el razonamiento sobre él.
Y un límite honesto. El razonamiento que se muestra no es un registro exacto de lo que pasaba dentro; a menudo es un resumen preparado para el lector. Una cadena larga y bien armada puede perfectamente surgir de una premisa falsa y, por eso mismo, parecer más fiable de lo que es. También pasa lo contrario: la respuesta ya está encontrada, pero el modelo sigue dudando, da vueltas en círculo y se enreda solo. Esto hasta tiene nombre: overthinking.
Pedir que piense más rato es una palanca débil: la longitud del borrador, por sí sola, no mejora nada. Funcionan mucho mejor un objetivo claro, unas limitaciones explícitas y un criterio concreto de que la tarea está resuelta. Entonces el modelo tiene algo que comprobar en su propio razonamiento.
Lo que el modelo no sabe hacer
La lista es corta, y es mejor conocerla de antemano que descubrirla en una tarea real.
- Garantizar que un dato es correcto. El mecanismo elige una continuación probable, no contrasta la afirmación con una fuente. A los detalles inventados pero verosímiles se les llama alucinaciones.
- No depender de la formulación. Cambiar las palabras de orden o añadir una precisión cambia la respuesta, porque todo lo decide el texto que va antes de ese punto.
- Aprender cosas nuevas por sí mismo. Sin fuentes externas, los conocimientos integrados no se actualizan: sobre la versión de una biblioteca que salió ayer, el modelo sabe solo lo que se le ha mostrado.
- Repetirse palabra por palabra. La misma petición puede dar un resultado distinto, y eso es una propiedad del mecanismo, no un fallo.
- Librarse de los sesgos de los textos de entrenamiento. Lo que ahí se describía de forma parcial o no se describía en absoluto, se notará también en las respuestas.
Casi todo lo que ha crecido alrededor de los modelos es una respuesta a algún punto de esta lista. La búsqueda y el trabajo con documentación aparecieron porque los conocimientos integrados se quedan anticuados. Las herramientas y los agentes, porque el modelo por sí solo únicamente sabe hablar.
Qué explica esto del comportamiento del agente
Esto es lo que de este mecanismo se ve directamente en la pantalla de Claude Code:
- la respuesta se va escribiendo trozo a trozo porque así es como se crea. Es el proceso, no un efecto visual;
- dos peticiones iguales dieron respuestas distintas: así tiene que ser, la generación no se repite al pie de la letra. Si necesita el resultado anterior, es más fiable volver al que ya obtuvo que preguntar de nuevo;
- Thinking da espacio para un borrador, no una garantía de que sea correcto. Al analizar una tarea de varios pasos compensa; al renombrar una variable, más bien estorba;
- mientras el agente no haya leído un archivo, la respuesta sobre ese archivo se apoya en patrones generales. Todo lo que ha entrado en la conversación pesa más que todo lo que se fijó en los parámetros;
- sobre las versiones recientes de las bibliotecas, el modelo sabe poco por defecto, y lo más fácil para corregirlo es poner la documentación en la conversación;
- si la respuesta se fue por otro lado, es más útil añadir lo que falta que repetir la petición con las mismas palabras. El mecanismo se basa en el texto que va antes de la respuesta, no en la insistencia.
Conocer el mecanismo no hace que el modelo sea peor de lo que es. Simplemente explica qué esperar de él: no un libro de consulta con garantía, sino un muy buen continuador de textos al que usted le da el comienzo.
Video: la misma mecánica en imágenes
El canal 3Blue1Brown tiene un video corto que reúne lo esencial en una animación muy clara: tokens, probabilidades de la siguiente palabra, atención y de dónde salen, en definitiva, los parámetros del modelo. Se llama Large Language Models explained briefly.
El original está en inglés, pero el video tiene varias pistas de audio traducidas, que se cambian en la configuración del reproductor. Si no está la pista del idioma que necesita, abra el video directamente en YouTube: en el reproductor web hay más opciones.
El canal no se limita a este video. Ahí mismo hay toda una serie sobre redes neuronales, transformers y attention: las mismas ideas, pero con más detalle y con matemáticas. Si después del artículo quiere entender no "qué pasa", sino "por qué esto funciona siquiera", ese es el lugar por donde empezar.
GO TO FULL VERSION