Cómo funcionan de verdad los LLM

Si usas un LLM a diario, seguro ya viste la misma escena: le pides algo simple, responde perfecto, y cinco minutos después se inventa un dato, cambia el tono o ignora una instrucción que parecía clarísima. La intuición común es pensar que “entiende” como una persona, o que por dentro hay una especie de buscador muy listo. No funciona así.

Un LLM no razona como un humano ni consulta una base de datos mágica. Lo que hace, de forma muy resumida, es predecir el siguiente token una y otra vez. Esa frase suena simple, pero por dentro hay una cadena de decisiones matemáticas y de diseño que explica casi todos los aciertos y casi todos los fallos. Si eres dev, entender esto te ayuda a escribir mejores prompts, a evaluar mejor las respuestas y a no construir productos sobre intuiciones falsas.

La idea central: predecir el siguiente token

La unidad básica de trabajo de un LLM no es la palabra, sino el token. Un token puede ser una palabra completa, una parte de palabra o incluso signos de puntuación. Por ejemplo, “desarrolladores” puede dividirse en varios tokens según el tokenizer, mientras que “API” puede quedar como uno solo. Esa división importa porque el modelo no ve texto humano, ve una secuencia numérica.

El objetivo del modelo durante inferencia es siempre el mismo: dado un contexto, asignar probabilidades al siguiente token posible. Si le das “La capital de Ecuador es”, el modelo no “sabe” la respuesta como tú la sabes; calcula qué token tiene mayor probabilidad de venir después. En un caso ideal, ese token será “Quito”. En otro, puede abrir una lista de alternativas si el contexto es ambiguo.

Ese comportamiento explica dos cosas que suelen confundir a la gente. Primero, el modelo puede sonar muy seguro incluso cuando está equivocado, porque siempre produce la continuación más probable según sus patrones aprendidos. Segundo, no tiene una memoria humana de hechos; tiene patrones estadísticos muy grandes que correlacionan texto con texto. Si el contexto empuja hacia una respuesta falsa, puede seguir esa ruta con bastante naturalidad.

Tokenización: donde el texto se vuelve números

Antes de que un LLM procese tu prompt, el texto pasa por un tokenizer. Ese componente convierte cadenas en IDs numéricos de un vocabulario fijo. La elección del tokenizer afecta longitud de contexto, costo y hasta la calidad de respuestas en idiomas distintos al inglés. Un mismo texto en español puede consumir más tokens que su equivalente en inglés, y eso impacta latencia y precio.

Ejemplo simple de cómo se ve el proceso:

"Quito es la capital de Ecuador"
-> [18492, 318, 262, 6865, 286, 15496]

Los números anteriores son ilustrativos, no corresponden a un tokenizer específico. La idea es que el modelo no trabaja con letras ni con palabras, sino con IDs. Luego esos IDs se transforman en embeddings, que son vectores densos que capturan relaciones entre tokens.

Qué pasa dentro del modelo: embeddings, capas y atención

Una vez que el texto está tokenizado, cada token se convierte en un vector. Ese vector inicial, el embedding, representa al token en un espacio matemático donde tokens parecidos quedan relativamente cerca. Luego el modelo pasa por muchas capas de procesamiento que refinan esa representación según el contexto.

La arquitectura dominante en LLMs modernos es el Transformer. La razón principal es que maneja contexto largo mejor que enfoques anteriores y permite entrenar con paralelismo eficiente. Si quieres revisar la base original, el paper “Attention Is All You Need” sigue siendo la referencia clásica: https://arxiv.org/abs/1706.03762

Dentro de un Transformer, la pieza más famosa es la self-attention. Esa capa permite que cada token mire a otros tokens del contexto y decida cuáles pesan más para construir la siguiente representación. No todos los tokens influyen igual en todos los casos. En “El banco está junto al río”, el token “banco” puede atender a “río” para resolver la ambigüedad semántica.

Self-attention sin humo

La intuición útil es esta: cada token genera tres proyecciones internas, llamadas query, key y value. El modelo compara queries con keys para calcular qué tan relevante es cada token previo, y usa esos pesos para mezclar values. No necesitas memorizar la fórmula exacta para entender el efecto práctico: el modelo aprende a enfocar partes distintas del contexto según la tarea.

Eso explica por qué los LLMs pueden seguir referencias a lo largo de varios párrafos, mantener consistencia local y resolver pronombres mejor que un modelo puramente secuencial. También explica su debilidad: la atención no es memoria perfecta. Si la información relevante quedó lejos, se perdió entre mucho ruido o fue truncada por el límite de contexto, el modelo puede fallar sin avisarte.

La secuencia suele repetirse capa tras capa. Cada capa toma la salida de la anterior, mezcla contexto, aplica una red feed-forward y normaliza la activación. Después de decenas o cientos de capas, el modelo produce logits, que son puntajes para cada token posible del vocabulario.

De logits a texto: cómo el modelo elige

Los logits no son respuestas todavía. Son números sin normalizar que indican preferencia relativa. Luego se convierten en probabilidades con softmax. A partir de ahí entra la política de decodificación: greedy, sampling, top-k, top-p, temperature. Esa parte no es un detalle menor; cambia mucho el comportamiento final.

Si usas greedy decoding, el modelo elige siempre el token más probable. Eso da respuestas más deterministas, pero también más repetitivas y a veces más rígidas. Si subes la temperature o permites sampling, aumentas variedad, pero también el riesgo de errores. En un producto real, esa decisión depende del caso de uso: soporte al cliente, generación creativa, extracción estructurada o asistencia de código.

Cómo aprende un LLM: entrenamiento y ajuste fino

Un LLM no nace sabiendo escribir correos, resumir tickets o explicar código. Primero se preentrena con enormes cantidades de texto para aprender patrones generales del lenguaje. Después, según el modelo, puede pasar por ajuste fino supervisado, RLHF u otras técnicas para alinearlo con instrucciones humanas y reducir comportamientos problemáticos.

Durante el preentrenamiento, el objetivo es simple: minimizar el error al predecir el siguiente token. El modelo ve secuencias enormes y ajusta millones o miles de millones de parámetros para hacerlo mejor en promedio. Esto no significa que memorice todo de forma literal. Significa que aprende regularidades: sintaxis, estilo, asociaciones semánticas, patrones de razonamiento superficial y hasta convenciones de código.

La parte que mucha gente subestima es que el modelo no separa de forma limpia “conocimiento” y “habilidad”. Para él, ambos se mezclan en los parámetros. Por eso puede escribir una función válida y al mismo tiempo fallar al recordar una fecha histórica. No hay una cajita de hechos y otra de gramática; hay una red muy grande de correlaciones aprendidas.

Fine-tuning, instrucciones y preferencias humanas

Después del preentrenamiento, muchos modelos pasan por fine-tuning con ejemplos de instrucciones y respuestas deseadas. Eso les enseña a seguir órdenes, adoptar formatos y ser más útiles en escenarios comunes. Luego, en algunos casos, se usa feedback humano para preferir respuestas mejores sobre respuestas simplemente probables.

Para entender la diferencia, imagina dos modelos con la misma base. Uno solo aprendió texto general. El otro vio miles de ejemplos de “haz esto”, “responde así”, “no inventes datos”, “devuelve JSON válido”. El segundo suele ser mucho más usable para producto, aunque no necesariamente más “inteligente” en sentido general.

Si quieres ver cómo se documenta este tipo de alineación en modelos concretos, la documentación de OpenAI sobre modelos y comportamiento es una referencia útil: https://platform.openai.com/docs

Dónde se rompen las intuiciones más comunes

La primera intuición falsa es pensar que el modelo tiene acceso a internet o a una fuente viva de verdad. No lo tiene, salvo que tu aplicación le conecte herramientas externas. Sin herramientas, responde solo con lo que está codificado en sus parámetros y con el contexto que tú le pasaste. Si le preguntas por un evento reciente, puede acertar por casualidad, fallar o mezclar cosas.

La segunda intuición falsa es creer que una respuesta fluida implica una respuesta correcta. La fluidez es un síntoma de que el modelo domina el patrón lingüístico, no una prueba de veracidad. Por eso un LLM puede escribir un párrafo impecable sobre un tema que no existe, o citar una fuente inventada con formato convincente.

La tercera intuición falsa es pensar que el prompt funciona como un comando rígido. En realidad, el prompt compite con el resto del contexto, con patrones aprendidos durante entrenamiento y con la política de decodificación. Si le das instrucciones ambiguas o contradictorias, el modelo no “te desafía”; simplemente estima qué continuación encaja mejor en ese contexto mezclado.

Alucinaciones: por qué aparecen

Las alucinaciones no son un bug raro aislado. Son una consecuencia directa de cómo se optimiza el modelo. Si el objetivo es predecir el siguiente token con alta probabilidad, el sistema puede preferir una respuesta plausible antes que admitir incertidumbre. Eso es especialmente visible cuando el prompt sugiere que debe contestar sí o sí.

Hay varias causas típicas:

1. Contexto insuficiente o truncado.
2. Preguntas fuera de distribución.
3. Instrucciones vagas o contradictorias.
4. Decodificación demasiado creativa.
5. Falta de herramientas de verificación.

En productos serios, el remedio no es pedirle “que sea más inteligente”. El remedio es diseñar el flujo para reducir ambigüedad, usar retrieval cuando haga falta, validar salidas estructuradas y mostrar incertidumbre cuando el modelo no tiene base suficiente.

Qué significa esto para ti como dev

Si construyes sobre LLMs, tu trabajo no es solo escribir prompts bonitos. Tu trabajo es diseñar sistemas alrededor de un predictor de tokens. Eso cambia cómo piensas métricas, UX, validación y costos. Un buen producto con LLM no depende de una sola respuesta perfecta, sino de un flujo que tolere errores y los detecte rápido.

Una forma práctica de verlo es separar tres capas:

• Modelo: genera texto probabilístico.
• Herramientas: le dan acceso a datos, funciones o APIs.
• Aplicación: decide qué mostrar, qué validar y cuándo pedir confirmación.

Si mezclas esas capas, terminas culpando al modelo por problemas de producto. Por ejemplo, si necesitas exactitud en números, no basta con pedirle “responde con precisión”. Debes extraer, validar y, si aplica, contrastar contra una fuente externa.

Patrón útil: pedir estructura, no solo texto

Cuando el resultado importa, conviene pedir salidas estructuradas. JSON, listas con campos fijos o bloques bien delimitados reducen ambigüedad y facilitan validación. Aun así, no asumas que el modelo siempre respetará el formato. Valida en backend y ten un fallback.

Ejemplo de contrato simple:

{
  "summary": "...",
  "confidence": "low|medium|high",
  "sources": ["..."],
  "needs_review": true
}

Ese tipo de esquema no hace al modelo más correcto por arte de magia, pero sí hace tu sistema más robusto. También te permite medir fallos con más claridad: formato inválido, respuesta incompleta, falta de citas o exceso de confianza.

Contexto, ventana y límites reales

Otro punto que se suele malinterpretar es la ventana de contexto. Más contexto no siempre significa mejor rendimiento. Sí, ayuda a mantener información relevante, pero también aumenta costo, latencia y riesgo de meter ruido. Si llenas el prompt con historial innecesario, instrucciones duplicadas o documentos mal segmentados, el modelo puede rendir peor.

En la práctica, conviene pensar en contexto como una memoria de trabajo limitada. Si necesitas recuperar conocimiento externo, usa retrieval. Si necesitas precisión operacional, usa herramientas. Si necesitas consistencia de formato, usa validación. No le pidas al modelo que haga todo a la vez solo con texto plano.

Tabla resumen

Cómo usar este modelo mental en tu trabajo diario

Si te quedas con una sola idea, que sea esta: un LLM es un motor de predicción de texto muy sofisticado, no un oráculo. Eso no lo hace menos útil. Al contrario, te da un marco realista para usarlo mejor. Cuando entiendes que su salida depende de contexto, tokenización, atención y decodificación, empiezas a tomar mejores decisiones de producto.

Ese marco también te ayuda a depurar. Si la respuesta salió mal, pregúntate primero si el problema está en el prompt, en el contexto, en la herramienta, en la política de decodificación o en la tarea misma. Muchas veces no necesitas cambiar de modelo; necesitas cambiar el sistema alrededor del modelo.

Para cerrar el círculo, piensa en el LLM como una pieza dentro de una arquitectura más amplia. Si lo usas para resumir, clasificar, generar borradores o ayudar a programar, su valor aparece cuando tú delimitas bien la tarea. Si lo usas como si fuera una fuente infalible de verdad, vas a chocar con sus límites rápido.