Saltar a contenido

Qué es un LLM y cómo funciona

Un LLM (Large Language Model o modelo de lenguaje grande) es una red neuronal entrenada para estimar qué token puede venir después de una secuencia. Durante el preentrenamiento observa grandes cantidades de texto y ajusta sus parámetros para reducir el error de esa predicción. Después puede generar texto, responder preguntas, resumir, traducir o producir código porque muchas tareas pueden formularse como continuación condicionada de una secuencia.

La definición parece simple. El comportamiento que emerge no lo es. Para entenderlo conviene separar cuatro piezas: tokenización, representación, predicción y adaptación.

La respuesta en 60 segundos

DEL TEXTO A LA PREDICCIÓN
Un LLM repite el mismo ciclo: representar el contexto, calcular una distribución y añadir un token
La tokenización define las unidades discretas; los embeddings las convierten en vectores; el Transformer mezcla información del contexto; la capa de salida produce puntuaciones sobre el vocabulario.
SELECCIONARse elige o muestrea un token
ACTUALIZAR CONTEXTOel token se añade y el ciclo se repite
Separación importanteMemoria, RAG, tools y políticas pueden rodear al modelo, pero no forman parte automáticamente de sus pesos.
Fuentes primarias: SentencePiece · Attention Is All You Need

El modelo no busca una frase almacenada ni consulta por defecto una base de datos. Calcula una distribución de probabilidad sobre el vocabulario, elige una continuación y vuelve a ejecutar el proceso con el nuevo contexto.

Un sistema de producto puede añadir memoria, búsqueda, herramientas o políticas alrededor del modelo. Esas capacidades pertenecen al sistema completo, no necesariamente a los pesos del LLM.

1. El texto se convierte en tokens

El modelo no trabaja directamente con palabras. Un tokenizador divide el texto en unidades que pueden ser palabras completas, fragmentos, signos o bytes. Cada token recibe un identificador entero.

TOKENIZACIÓN · TEXTO → UNIDADES DISCRETAS
El modelo no recibe palabras: recibe una secuencia de IDs definida por un tokenizador concreto
La segmentación depende del vocabulario y del algoritmo. El mismo texto puede ocupar distinto número de tokens con tokenizadores distintos, aunque los caracteres visibles sean idénticos.
MISMO TEXTO · VOCABULARIOS DISTINTOS La frontera de token no es una propiedad universal de la palabra
TOKENIZADOR Asegmentación ilustrativa
“arquitectura neuronal”
▁arquitectura▁neuronal
Dos unidades si ambas piezas están bien cubiertas por el vocabulario.
TOKENIZADOR Bsegmentación ilustrativa
“arquitectura neuronal”
▁arquitectura▁neuronal
Más unidades si el vocabulario necesita recomponer la misma cadena con fragmentos menores.
Importante: las segmentaciones de este diagrama son pedagógicas; no representan la salida de un tokenizador concreto.
NO ES «UNA PALABRA = UN TOKEN» Una palabra puede ser una pieza, varias subpalabras o una secuencia de bytes.
LOS IDs NO SON UNIVERSALES El entero solo tiene significado dentro del vocabulario de ese tokenizador.
CAMBIA EL PRESUPUESTO Más tokens consumen más contexto y pueden aumentar el coste de inferencia.
IDEA OPERATIVA Cuando comparas modelos, límites de contexto o costes, cuenta tokens con el tokenizador real del modelo; no estimes a partir de palabras o caracteres.
Fuentes primarias: Sennrich et al. · BPE subword units (2015) · Kudo & Richardson · SentencePiece (2018).

La segmentación exacta depende del vocabulario y del algoritmo. Métodos como Byte Pair Encoding y SentencePiece equilibran dos objetivos: mantener un vocabulario manejable y representar palabras raras sin convertir cada carácter en una unidad independiente.1

La tokenización importa porque condiciona:

  • el coste, que suele medirse por tokens
  • la longitud efectiva del contexto
  • la representación de idiomas y código
  • la facilidad para copiar números, nombres o cadenas poco frecuentes

Para llevar esas restricciones a un escenario concreto, la calculadora de coste y latencia conecta tokens con gasto y tiempo de respuesta, el planificador de presupuesto de contexto muestra cómo se reparte la ventana y el explorador de precio y rendimiento permite comparar modelos manteniendo separados carga, coste y rendimiento.

2. Los tokens se convierten en representaciones

Cada identificador se transforma en un vector aprendido llamado embedding. El modelo también necesita información sobre la posición de cada token. Sin ella, una secuencia sería solo un conjunto sin orden.

Los vectores atraviesan una pila de bloques Transformer. En cada bloque ocurren dos operaciones principales:

  1. Atención: cada posición combina información de otras posiciones relevantes
  2. Red feed-forward: transforma la representación de cada posición de forma no lineal

Las conexiones residuales y la normalización estabilizan el entrenamiento. Al repetir el bloque muchas veces, las representaciones dejan de codificar solo la identidad del token y empiezan a incorporar sintaxis, relaciones semánticas, referencias, estructura del documento y señales útiles para la predicción.2

REPRESENTACIÓN CONTEXTUAL
El embedding identifica el token; las capas Transformer construyen un estado dependiente de posición y contexto
La misma unidad léxica parte del mismo embedding de token. La señal posicional y la atención hacen que su representación final cambie según las palabras que la rodean.
IDENTIDAD DEL TOKEN «banco» → ebanco Ejemplo conceptual: la segmentación y el ID exactos dependen del tokenizador.
CONTEXTO A
El banco aprobó el crédito
ENTRADA ebanco + pt embedding de token + señal de posición
BLOQUES TRANSFORMER
atenciónFFN× L capas
cada capa mezcla señales del contexto permitido
ESTADO CONTEXTUAL ht(L) incorpora señales como «aprobó» y «crédito»
CONTEXTO B
Nos sentamos en el banco junto al río
ENTRADA ebanco + pt mismo embedding de token; posición posiblemente distinta
BLOQUES TRANSFORMER
atenciónFFN× L capas
las activaciones cambian al cambiar el contexto
ESTADO CONTEXTUAL ht(L) incorpora señales como «sentamos» y «río»
Lectura correcta El embedding de token es el punto de partida. La representación que usan las capas posteriores es contextual y puede ser distinta en cada aparición.
Fuente primaria: Vaswani et al., Attention Is All You Need (2017), §§3.1–3.5

La guía sobre el Transformer desarrolla esta arquitectura paso a paso.

3. El objetivo base es predecir el siguiente token

En un LLM autoregresivo, el entrenamiento optimiza la probabilidad del token real condicionado por los anteriores.

OBJETIVO AUTORREGRESIVO
El modelo no predice una frase completa: puntúa el siguiente token condicionado por todo el prefijo
En entrenamiento conocemos el token correcto y minimizamos su log-loss. En generación no existe una respuesta dada: se transforma la distribución en una elección y ese token pasa a formar parte del siguiente contexto.
CONTEXTO
La capital de Francia es?
El Transformer produce una representación para la posición que debe continuar la secuencia.
DISTRIBUCIÓN SOBRE EL VOCABULARIO
París
más probable
Lyon
menos probable
una
cola larga
Las barras son ilustrativas: muestran orden relativo, no probabilidades medidas de un modelo concreto.
ENTRENAMIENTO ℒ = − Σt log p(xt | x<t) Si el token real recibe poca probabilidad, la pérdida aumenta y el gradiente corrige los parámetros.
GENERACIÓN distribución → selección → nuevo contexto → repetir Greedy, temperatura, top-p u otras reglas cambian cómo se selecciona; no cambian el hecho de que la distribución se recalcula en cada paso.
ConsecuenciaOptimizar probabilidad de continuación no equivale a verificar verdad. La factualidad necesita señales, datos o comprobaciones adicionales.
Fuente primaria: Brown et al., Language Models are Few-Shot Learners (2020)

El modelo recibe una secuencia y debe asignar alta probabilidad al token real que sigue en cada posición. El gradiente indica cómo modificar millones o miles de millones de parámetros para cometer menos error en el siguiente lote.

A gran escala, resolver bien esa tarea exige aprender regularidades profundas. Para predecir una continuación plausible, el modelo necesita capturar gramática, estilo, relaciones entre conceptos, convenciones de código y parte de la estructura estadística del mundo descrito en los datos.

Eso no convierte la probabilidad en verdad. El objetivo de entrenamiento premia una continuación compatible con el contexto, no una afirmación verificada externamente.

4. Preentrenamiento, instrucciones y preferencias no son lo mismo

Un producto conversacional suele pasar por varias etapas.

DEL MODELO BASE AL ASISTENTE
Preentrenamiento, ajuste por instrucciones y preferencias optimizan señales distintas
Las etapas posteriores cambian cómo responde el modelo ante una petición. No convierten por sí solas una continuación probable en una fuente verificable ni sustituyen memoria, tools o estado operacional.
NO GARANTIZAprocedencia factualUna respuesta puede seguir instrucciones y seguir siendo falsa.
NO AÑADE POR SÍ SOLOconocimiento actualizadoLos cambios externos requieren contexto, recuperación o nuevo entrenamiento.
NO SUSTITUYEestado y autorizaciónLas acciones fiables necesitan contratos, permisos y verificación fuera del texto.
Lectura correctaEstas etapas forman una cadena de adaptación del comportamiento; no son tres nombres para el mismo entrenamiento.
Fuente primaria: Ouyang et al., Training language models to follow instructions with human feedback (2022)

Preentrenamiento

El modelo aprende patrones generales a partir de grandes corpus. El resultado es un modelo base que completa texto, pero no necesariamente sigue bien una instrucción.

Ajuste por instrucciones

Se entrena con pares de instrucción y respuesta para que interprete peticiones y adopte formatos útiles. Esta fase transforma la capacidad general de continuación en comportamiento asistencial.

Optimización por preferencias

Se utilizan comparaciones humanas, modelos de recompensa u otras señales para favorecer respuestas consideradas más útiles, seguras o alineadas con el producto. InstructGPT mostró de forma temprana cómo el ajuste supervisado y el aprendizaje a partir de preferencias podían mejorar el seguimiento de instrucciones sin cambiar el objetivo fundamental de generación.5

Estas etapas modifican el comportamiento observable. No garantizan que el modelo conozca una fuente, mantenga coherencia durante una operación larga o ejecute acciones de forma fiable.

Parámetros, contexto y conocimiento externo

Tres mecanismos distintos suelen confundirse.

DÓNDE VIVE LA INFORMACIÓN
Parámetros, contexto y sistemas externos cambian en momentos distintos
No son tres nombres para “memoria”. Separarlos aclara qué puede estar actualizado, qué evidencia entra en esta petición y qué parte del sistema puede leer o modificar estado fuera del modelo.
01PARÁMETROS θ
datos de entrenamientoD
optimización∇L
pesos aprendidosθ
CAMBIAentrenamiento / fine-tuning
CONTIENEregularidades comprimidas
PROCEDENCIAno recupera una fuente exacta por defecto
02CONTEXTO DE ESTA PETICIÓN
instrucciones conversación documentos incluidos resultados de tools
tokens visibles ahora atención del modelo
CAMBIAen cada interacción
CONTIENEevidencia explícita de esta llamada
PROCEDENCIApuede conservarse junto a la respuesta
03RECUPERACIÓN / TOOLS
LEER índice · DB · API recuperar evidencia
ACTUAR runtime + contrato validar y ejecutar efecto
CAMBIAdurante la ejecución del sistema
CONTIENEdatos o estado fuera del modelo
PROCEDENCIApuede registrar fuente, llamada y resultado
CÓMO SE CONECTAN EN UN SISTEMA REAL
fuentes externasdocs · DB · APIs
recuperación→
contextox₁ … xₙ
condiciona→
LLMfθ(x)
tool propuesta→
runtimevalidar · autorizar
efecto→
estado externoleer / escribir
RAGrecupera evidencia; no reentrena los pesos en cada consulta
CONTEXTOcondiciona esta inferencia; no equivale a memoria persistente
TOOLSconectan el modelo con un runtime; los efectos ocurren fuera del LLM
Fuentes primarias: Brown et al., GPT-3 (2020) · Lewis et al., RAG (2020) · Yao et al., ReAct (2022)

Un LLM puede responder desde sus parámetros, razonar sobre información incluida en el contexto o llamar a una herramienta. La trazabilidad es muy distinta en cada caso.

Cuando la respuesta debe depender de documentación actual, una arquitectura con recuperación suele ser más verificable que confiar en lo que quedó comprimido durante el entrenamiento. Cuando debe cambiar el estado de otro sistema, hace falta una tool con contrato, validación e idempotencia.

Por qué la escala ayuda

El rendimiento no depende solo del número de parámetros. También importan la cantidad y calidad de los datos, el cómputo de entrenamiento, la arquitectura, la longitud de contexto y el proceso de adaptación.

ESCALA = BALANCE ENTRE N, D Y C
Más parámetros ayudan solo cuando datos y cómputo acompañan
Las scaling laws describen relaciones empíricas entre pérdida y tres recursos de entrenamiento. Si uno se queda corto, aumentar otro entra en rendimientos decrecientes.
01PARÁMETROS N
N
tamaño del modelo
02DATOS D
D
tokens de entrenamiento
03CÓMPUTO C
C
presupuesto de entrenamiento
OBJETIVO OBSERVADO pérdida de validación L ↓ cuando los otros factores no son el cuello de botella
RELACIONES DE POTENCIA EMPÍRICAS
modeloL(N) ∝ N−αN
datosL(D) ∝ D−αD
cómputoL(C) ∝ C−αC
Son ajustes empíricos dentro de un régimen de entrenamiento; no garantizan que cada benchmark o capacidad mejore con la misma curva.
EJEMPLO CHINCHILLA · MISMO PRESUPUESTO DE ENTRENAMIENTO No basta con maximizar N
Gopher
PARÁMETROS280B
DATOS1×
CÓMPUTO=
Chinchilla
PARÁMETROS70B
DATOS4×
CÓMPUTO=
Hoffmann et al. entrenaron Chinchilla con el mismo cómputo que Gopher, una cuarta parte de parámetros y 4× más datos. El resultado mostró que el presupuesto puede rendir mejor al equilibrar tamaño y tokens de entrenamiento.
CUELLO DE BOTELLAescalar N sin suficiente D puede dejar el modelo infraentrenado
ALCANCEson leyes empíricas de pérdida, no leyes físicas universales
COMPARACIÓN“más grande” no basta: importa cómo se repartió el presupuesto
Fuentes primarias: Kaplan et al., Scaling Laws (2020) · Hoffmann et al., Chinchilla (2022)

Los trabajos sobre scaling laws mostraron relaciones predecibles entre pérdida, tamaño del modelo, datos y cómputo. Chinchilla añadió un matiz decisivo: para un presupuesto de entrenamiento dado, aumentar parámetros sin aumentar suficientes tokens puede dejar el modelo infraentrenado.34

Por eso “más grande” no es una explicación suficiente. La comparación útil exige conocer el régimen de entrenamiento y la tarea de evaluación.

Qué puede hacer bien un LLM

Un LLM es especialmente útil cuando la tarea admite variación lingüística y el resultado puede verificarse o corregirse:

  • transformar y resumir texto
  • extraer información con un esquema
  • generar borradores y código
  • clasificar con instrucciones y ejemplos
  • traducir entre representaciones
  • coordinar tools mediante argumentos estructurados
  • razonar sobre información presente en el contexto

El sistema mejora cuando añade restricciones explícitas, ejemplos, validadores, recuperación y evaluación sobre casos reales.

Límites que no desaparecen con un prompt mejor

Generación plausible, no garantía de verdad

El modelo puede producir una afirmación fluida y falsa. La confianza verbal no es una estimación calibrada de corrección.

Sensibilidad al contexto

Pequeños cambios en instrucciones, orden o ejemplos pueden alterar el resultado. En producción, el prompt es parte del software y necesita pruebas de regresión.

Conocimiento incompleto o desactualizado

Los parámetros reflejan los datos y la fecha de entrenamiento. Un modelo no conoce automáticamente cambios posteriores ni la documentación privada de una organización.

Razonamiento no monotónico

Más tokens de razonamiento o más tiempo de inferencia pueden ayudar, pero también introducir deriva, sobrepensamiento o coste sin mejora. La guía de razonamiento en LLMs separa esas estrategias.

Falta de estado operacional fiable

El historial conversacional no sustituye a una base de datos. Una operación larga necesita estado explícito, identificadores, reintentos e idempotencia fuera del modelo.

Cómo evaluar un LLM para un caso real

No basta con elegir el modelo que lidera un benchmark. Una evaluación útil debería medir:

  1. la distribución real de entradas
  2. la calidad mínima aceptable
  3. los fallos costosos
  4. la latencia hasta una salida utilizable
  5. el coste total del sistema
  6. la estabilidad ante reformulaciones
  7. la corrección de tools y datos recuperados

La guía de evaluación de modelos de IA propone una pila completa desde pruebas estáticas hasta métricas de producto.

Dónde profundizar en 5sigmas

Preguntas frecuentes

¿Un LLM es una base de datos?

No. Sus parámetros comprimen regularidades aprendidas, pero no ofrecen recuperación exacta, actualización transaccional ni procedencia garantizada. Un sistema puede conectar el LLM con una base de datos o un índice, pero son componentes distintos.

¿Un LLM entiende el lenguaje?

Depende de la definición de “entender”. Sus representaciones capturan relaciones sintácticas y semánticas suficientes para resolver tareas complejas. Eso no demuestra experiencia subjetiva ni garantiza una representación causal correcta del mundo.

¿Todos los LLMs usan Transformer?

La mayoría de los modelos de lenguaje de propósito general publicados durante la etapa moderna usan Transformers o arquitecturas híbridas cercanas. Existen alternativas basadas en modelos de espacio de estados y otras operaciones, pero “LLM” describe escala y función, no obliga a una arquitectura concreta.

¿Qué diferencia hay entre un LLM y un chatbot?

El LLM es el modelo generativo. El chatbot añade interfaz, instrucciones, memoria, recuperación, herramientas, moderación, observabilidad y políticas de producto.

Fuentes primarias

  1. Taku Kudo y John Richardson, SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing, 2018. ↩

  2. Ashish Vaswani et al., Attention Is All You Need, 2017. ↩

  3. Tom B. Brown et al., Language Models are Few-Shot Learners, 2020. ↩

  4. Jordan Hoffmann et al., Training Compute-Optimal Large Language Models, 2022. ↩

  5. Long Ouyang et al., Training language models to follow instructions with human feedback, 2022. ↩