Cómo los modelos de lenguaje grandes convierten texto en tokens, predicen el siguiente y por qué suenan seguros cuando se equivocan.
Un modelo de lenguaje grande (LLM, por sus siglas en inglés) es un programa que aprendió, a partir de una cantidad enorme de texto, qué fragmentos suelen seguir a otros. Escribes una instrucción y el programa produce la respuesta un pedazo pequeño a la vez. Ese es el mecanismo completo, visto desde arriba. El resto de este artículo explica cómo una tarea tan simple se vuelve útil y dónde falla.
La palabra "grande" se refiere a dos cosas: la cantidad de texto que se usó para entrenar el modelo y la cantidad de valores numéricos, llamados parámetros, que el entrenamiento ajusta. La palabra "modelo" significa que el programa asigna probabilidades a secuencias de texto. No busca respuestas en una base de datos y no mantiene una lista de hechos que revise antes de hablar. Genera texto a partir de patrones que absorbió durante el entrenamiento.
Si alguna vez usaste una herramienta de chat con IA, ya usaste un LLM. El producto envuelve el modelo en una interfaz, agrega instrucciones que no ves y, con frecuencia, lo conecta a un buscador u otras herramientas. El modelo que está debajo es la parte que describe este artículo. Cuando la respuesta del producto parece equivocada, conviene saber qué capa produjo el error.
El trabajo de seguridad se construye con afirmaciones. Un paquete es seguro de instalar. Un puerto está cerrado. Una configuración desactiva una verificación. Una vulnerabilidad afecta a una versión concreta. Un LLM escribe cada afirmación con el mismo tono fluido, sea verdadera o no. Si no sabes cómo el modelo produce texto, es fácil tomar un párrafo seguro de sí mismo como si fuera un hallazgo.
Entender el mecanismo cambia tres hábitos. Dejas de esperar que el modelo sepa cosas que nunca vio. Dejas de tomar la fluidez como evidencia. Y empiezas a preguntar dónde se puede comprobar cada afirmación. El NIST Generative AI Profile, publicado como NIST AI 600-1, incluye la confabulación entre los riesgos de los sistemas de IA generativa. La confabulación es la producción de contenido afirmado con seguridad que resulta erróneo. El documento pide a las organizaciones planear para ello, en lugar de suponer que no ocurre.
El trabajo del modelo se divide en unas cuantas etapas: el texto se convierte en tokens, los tokens en vectores, la atención mezcla el contexto, el modelo predice un token, y el entrenamiento y la inferencia hacen útil esa predicción. Las secciones siguientes las recorren en orden.
El modelo no lee letras ni palabras completas de forma directa. Lee tokens, que son fragmentos de texto elegidos por un componente llamado tokenizador. Un token puede ser una palabra entera, parte de una palabra, un espacio, un signo de puntuación o una secuencia corta de bytes. Las palabras comunes suelen ser un solo token. Las palabras raras, los identificadores de código y los textos en idiomas menos frecuentes suelen partirse en varios.
El tokenizador aprende sus fragmentos a partir de datos antes de que el modelo se entrene. Un método común es el byte-pair encoding, normalmente abreviado BPE. Empieza con caracteres sueltos y une repetidamente el par de vecinos que más aparece, hasta que el vocabulario alcanza un tamaño elegido. El resultado es una lista fija de fragmentos y una regla para dividir cualquier texto nuevo en ellos.
Para verlo de forma concreta, el script siguiente construye un BPE diminuto a partir de unas pocas palabras. Es un juguete, no el tokenizador de ningún modelo real, pero el mecanismo es el mismo. Guárdalo como toy_bpe.py y ejecútalo con Python 3:
from collections import Counter
corpus = "low low low lower lowest newer newer newer wider wider new new"
words = Counter(tuple(w) + ("</w>",) for w in corpus.split())
def pair_counts(vocab):
pairs = Counter()
for word, freq in vocab.items():
for a, b in zip(word, word[1:]):
pairs[(a, b)] += freq
return pairs
def merge(vocab, pair):
out = Counter()
for word, freq in vocab.items():
new, i = [], 0
while i < len(word):
if i < len(word) - 1 and (word[i], word[i + 1]) == pair:
new.append(word[i] + word[i + 1]); i += 2
else:
new.append(word[i]); i += 1
out[tuple(new)] += freq
return out
merges = []
vocab = words
for step in range(6):
pairs = pair_counts(vocab)
if not pairs:
break
best = max(pairs, key=lambda p: (pairs[p], p))
merges.append(best)
vocab = merge(vocab, best)
print(f"merge {step + 1}: {best[0]!r} + {best[1]!r} -> {best[0] + best[1]!r} (count {pairs[best]})")
def tokenize(word):
toks = list(word) + ["</w>"]
for a, b in merges:
i = 0
while i < len(toks) - 1:
if toks[i] == a and toks[i + 1] == b:
toks[i:i + 2] = [a + b]
else:
i += 1
return toks
for w in ["lowest", "newest", "widen"]:
print(w, "->", tokenize(w))La salida de abajo se obtuvo al ejecutar este script en Windows 11 con Python 3.12.10. La tuya debe coincidir línea por línea, porque el script no usa aleatoriedad:
merge 1: 'r' + '</w>' -> 'r</w>' (count 6)
merge 2: 'e' + 'r</w>' -> 'er</w>' (count 6)
merge 3: 'w' + '</w>' -> 'w</w>' (count 5)
merge 4: 'n' + 'e' -> 'ne' (count 5)
merge 5: 'l' + 'o' -> 'lo' (count 5)
merge 6: 'w' + 'er</w>' -> 'wer</w>' (count 4)
lowest -> ['lo', 'w', 'e', 's', 't', '</w>']
newest -> ['ne', 'w', 'e', 's', 't', '</w>']
widen -> ['w', 'i', 'd', 'e', 'n', '</w>']Lee primero las fusiones. El par más frecuente del corpus pequeño es un marcador de fin de palabra pegado a r, por eso esa fusión va primero. Las fusiones siguientes arman fragmentos como er</w> y lo, que reflejan ortografías repetidas en el corpus. Luego mira las divisiones. "lowest" se parte en lo, w, e, s, t y el marcador de fin, porque el vocabulario del juguete nunca aprendió un fragmento para est ni para owe. "widen" casi cae en caracteres sueltos. El vocabulario del tokenizador cubre lo que vio durante su propio entrenamiento, y todo lo demás cuesta más piezas.
Muchos tokenizadores reales trabajan con bytes y entrenan con mucho más texto, así que sus fragmentos son más largos y más numerosos. El principio se mantiene. El texto que aparece mucho en los datos de entrenamiento sale barato, y el texto poco familiar cuesta más tokens. Esto tiene efectos prácticos. Los modelos limitan la entrada y la salida por número de tokens, y los servicios suelen cobrar con el mismo criterio, así que la misma frase puede costar distinto en otro idioma o en código.
Cada token tiene un identificador numérico. El modelo asocia ese identificador con un vector, una lista de números que suele tener cientos o miles de elementos. Estos vectores se aprenden durante el entrenamiento. Los tokens que aparecen en contextos parecidos terminan con vectores parecidos, así que el modelo trata "coche" y "automóvil" como relacionados sin que nadie escriba una regla al respecto.
A partir de ahí, el modelo trabaja con números, no con caracteres. No inspecciona las letras dentro de un token como lo harías tú. Esa es una explicación habitual de por qué los modelos a veces se equivocan al contar las letras de una palabra o fallan en un problema sencillo de ortografía. Las letras nunca se le presentaron como elementos separados.
La mayoría de los LLM actuales se construyen sobre la arquitectura transformer, descrita en "Attention Is All You Need", de Vaswani y colegas, publicado en 2017 (arXiv:1706.03762). Los modelos de lenguaje anteriores solían leer el texto un token tras otro, arrastrando un resumen. El transformer permite que cada posición mire directamente a otras posiciones mediante un mecanismo llamado atención.
Para cada token del contexto, la atención calcula cuánto peso dar a cada token anterior al construir la representación del token actual. Apila muchas capas de atención y pequeñas redes de avance, y el modelo arma una imagen rica del contexto. Puede vincular un pronombre con el sustantivo al que se refiere, asociar una llamada a función con una definición de varias líneas antes, o notar qué parte de una pregunta debe atender la respuesta.
No necesitas matemáticas para usar bien estos modelos. El dato útil es que la lectura de cualquier token depende de los tokens que lo rodean, en todo el contexto. Cambia una palabra de la instrucción y la representación de muchas otras puede cambiar con ella. Por eso, pequeños cambios de redacción a veces producen respuestas muy distintas.
En la parte superior de las capas, el modelo produce una puntuación para cada token de su vocabulario y convierte las puntuaciones en probabilidades. El siguiente token se elige de esa distribución, se agrega al texto y el proceso se repite con el texto más largo como entrada. Una respuesta de 300 tokens son 300 predicciones separadas, cada una condicionada por todo lo anterior, incluidos los tokens que el propio modelo acaba de producir.
Piensa en la frase "La capital de Francia es". Casi toda la probabilidad cae sobre un token que continúa con "París". El modelo no consultó un mapa. Aprendió que esa continuación es muy común en el texto que vio. El mismo mecanismo sirve para pedidos más difíciles: un comentario de código seguido de la firma de una función, un mensaje de error seguido de una causa probable, una pregunta seguida de una explicación plausible. Cada caso es una continuación, y el acierto depende de qué tan bien los patrones aprendidos encajan con el texto nuevo.
El entrenamiento ajusta los parámetros para que las predicciones del modelo coincidan con el texto de sus datos. En forma simplificada, el modelo lee un fragmento, oculta el siguiente token, intenta predecirlo, mide qué tan lejos quedó de la predicción respecto del token real y ajusta los parámetros un poco en la dirección que habría ayudado. Repite eso sobre una cantidad enorme de texto, con mucho cómputo, y los parámetros codifican buena parte de la estructura estadística del lenguaje.
El entrenamiento suele hacerse por etapas. La primera, llamada preentrenamiento, es el proceso de siguiente token descrito arriba. Las etapas posteriores suelen usar ejemplos de instrucciones y buenas respuestas, y a veces evaluaciones de personas que ordenan respuestas. Esas etapas moldean el comportamiento cuando alguien hace una pregunta: el modelo se vuelve más dispuesto a responder de forma útil y menos propenso a seguir la conversación como si fuera una página web. Los datos de entrenamiento definen la gama de temas disponibles, y la fecha de corte de esos datos marca hasta dónde aprendió a partir de texto.
El entrenamiento es caro y lo hace el desarrollador del modelo, no la persona que escribe en la ventana de chat. Las conversaciones comunes no cambian los parámetros del modelo.
La inferencia es ejecutar un modelo ya entrenado para producir una salida. Toda respuesta que ves es inferencia. Durante la inferencia los parámetros permanecen fijos. Lo único que cambia de una solicitud a otra es la entrada, que incluye las instrucciones del sistema, la conversación hasta ese punto, los archivos adjuntos y los resultados de herramientas devueltos al contexto.
Esto explica una sorpresa frecuente. Un modelo puede parecer que olvidó una conversación al día siguiente. Nada de lo que escribiste actualizó sus parámetros, así que el modelo arranca desde el mismo estado de antes. Los productos con memoria guardan notas fuera del modelo y las insertan en el contexto de solicitudes posteriores. El modelo lee esas notas como texto. No las recuerda como lo haría una persona.
La ventana de contexto es la cantidad máxima de tokens que el modelo puede considerar en una solicitud. Tiene que contener las instrucciones, la conversación, los documentos adjuntos y la respuesta que se está generando. El texto que queda fuera de la ventana es invisible para el modelo en ese paso, sin importar cuán importante fue antes. En conversaciones largas, los mensajes antiguos pueden salir del contexto o perder peso frente a los recientes.
Los tamaños de ventana varían entre modelos y cambian con el tiempo. Consulta la documentación vigente del modelo que usas, en lugar de fiarte de una cifra de un artículo, incluido este. Una ventana más grande tampoco garantiza un buen uso. Los contextos largos pueden enterrar el detalle que importa, así que una instrucción enfocada con el documento correcto suele superar a una pila enorme de texto.
El muestreo es el paso que elige un token de la distribución de probabilidades. La temperatura es un ajuste que controla qué tan concentrada está esa distribución antes de elegir. Con temperatura baja, dominan los tokens más probables, así que las respuestas son más repetitivas y más estables de una ejecución a otra. Con temperatura alta, la probabilidad se reparte entre más tokens, así que las respuestas varían más y se desvían con más frecuencia. Muchas interfaces de chat ni siquiera muestran este ajuste.
La temperatura no decide si una respuesta es correcta. Un ajuste bajo puede repetir una afirmación falsa con la misma seguridad que uno alto. Además, una temperatura de cero no garantiza salidas idénticas en cualquier despliegue, porque el cálculo de fondo puede variar entre hardware y versiones de software. Si necesitas salida repetible para una prueba, registra la versión del modelo, la configuración y la entrada, y trata la salida como una muestra, no como una verdad fija.
Una respuesta incorrecta y segura de sí misma sale de cómo se construyó el modelo, no de un fallo raro.
El modelo optimiza la continuación plausible. Una frase falsa que encaja con el patrón del texto puede obtener la misma puntuación que una verdadera. Los datos de entrenamiento también contienen errores, y el modelo los absorbe con la misma facilidad con la que absorbe hechos correctos. Durante la inferencia no tiene acceso directo al mundo, salvo que una herramienta se lo dé. Sin un paso de recuperación de documentos ni una herramienta, responde a partir de los patrones de sus parámetros.
La fluidez es parte del problema. El texto seguro y bien organizado abunda en los datos de entrenamiento, así que el modelo aprende a producirlo sin importar la exactitud. El tono de una respuesta no aporta información sobre si su contenido es verdadero.
Los huecos empeoran las cosas. Cuando falta un detalle, el modelo lo rellena con algo que encaja en el patrón. Los detalles específicos, como números de versión, nombres de funciones, identificadores CVE, claves de configuración y URL, son los más fáciles de reconstruir mal, porque parecen regulares pero deben corresponder a un hecho concreto. El NIST lo llama confabulación, y el mismo patrón aparece en casi todos los sistemas generativos.
Verifica las afirmaciones en fuentes primarias. En una pregunta de seguridad, eso suele significar el aviso del fabricante, la RFC o norma pertinente, la documentación oficial de la versión exacta que usas, el registro CVE, la publicación del NIST o el código de tu propio repositorio. Usa el modelo para averiguar qué revisar y cómo probarlo, no como autoridad final sobre lo que es verdad.
Lleva un registro breve de cada afirmación en la que te apoyas: la afirmación, la fuente, la fecha en que la comprobaste y la versión a la que aplica. Ese hábito atrapa tanto los errores del modelo como los tuyos. Trata cada comando generado como un borrador que debes leer antes de ejecutar. Ejecútalo solo en un laboratorio tuyo, y nunca apuntes pasos generados de escaneo o explotación contra un sistema para el que no tengas permiso escrito de prueba.
Lee la primera sección y la figura de arquitectura del artículo del transformer. No necesitas entender todas las ecuaciones para ver la forma de la idea. Luego ejecuta el tokenizador de juguete con tus propias palabras y observa dónde las divide. El artículo de Sennrich y colegas introdujo las unidades de subpalabra construidas con byte-pair encoding, y el capítulo del curso de Hugging Face recorre el algoritmo con código. Después, lee la sección de confabulación del perfil del NIST para ver cómo se encuadra el riesgo para las organizaciones.
El siguiente artículo, Qué es una API de LLM, trata de llamar a un modelo desde tu propio código. Así es como NotHoly pone sus modelos a disposición de los desarrolladores, y el mismo hábito de verificación sirve para cada respuesta que recibes por una API. Para tener base sobre el tipo de afirmación de la que depende el trabajo de seguridad, mira Qué es una vulnerabilidad.
Modelos de LLM y APIs
Cómo es una solicitud a una API de chat: modelo, mensajes, tokens, streaming, claves de API, límites y errores HTTP, con ejemplos anotados.