Saltar al contenido

¿Qué es un LLM? Arquitectura, funcionamiento y límites en producción

Qué es un modelo de lenguaje de gran tamaño (LLM), cómo procesa tokens mediante transformers, sus límites de alucinación y contexto, y cómo integrarlo en sistemas empresariales con RAG.

TécnicoPublicado 6 min de lectura
Diagrama conceptual de la arquitectura de un modelo de lenguaje mostrando tokens de entrada, capas de atención y generación probabilística sobre fondo azul marino corporativo

Un modelo de lenguaje de gran tamaño (Large Language Model o LLM) es un sistema computacional entrenado con volúmenes masivos de texto para predecir, comprender y estructurar lenguaje natural y formal (como código fuente).

Aunque hoy se perciben como asistentes conversacionales capaces de redactar correos, razonar sobre contratos o generar consultas SQL a partir de un prompt, su funcionamiento subyacente responde a principios matemáticos y estadísticos deterministas: no razonan con conciencia semántica ni acceden a una verdad intrínseca, sino que muestrean secuencias de símbolos condicionados por probabilidades aprendidas.

Para un equipo técnico o directivo, entender qué hay debajo de la interfaz de chat es la diferencia entre construir un software empresarial fiable o integrar una caja negra frágil que introduce errores silenciosos en producción.

Cómo funciona un LLM por dentro

El núcleo de casi todos los LLMs modernos (como GPT-4, Claude 3.5, Gemini 1.5 o Llama 3) es la arquitectura Transformer, presentada por el equipo de Google en 2017 (Attention Is All You Need). A diferencia de las redes neuronales recurrentes (RNN) anteriores, que procesaban el texto palabra a palabra en orden secuencial, el Transformer procesa secuencias completas en paralelo utilizando mecanismos de autoatención (self-attention).

El ciclo de procesamiento de una petición sigue cuatro etapas concretas:

1. Tokenización

Los LLMs no procesan caracteres ni palabras enteras de forma directa; dividen el texto en unidades discretas denominadas tokens mediante algoritmos como Byte Pair Encoding (BPE) o WordPiece.

  • En inglés, una regla habitual es que 1.000 tokens equivalen aproximadamente a 750 palabras.
  • En español u otros idiomas con mayor flexión morfológica, la ratio suele situarse entre 1,2 y 1,5 tokens por palabra, ya que los prefijos, sufijos y tildes a menudo se fragmentan en subtokens independientes.
  • El código fuente (JSON, Python, SQL) suele tener su propio patrón de fragmentación según la indentación y los caracteres especiales.
Texto:      "Facturación mensual"
Tokens:     ["Factur", "ación", " mensual"]  (3 tokens)
IDs:        [18492, 4521, 88204]

2. Embeddings y capas de autoatención

Cada ID de token se proyecta en un espacio vectorial multidimensional (frecuentemente entre 4.096 y 8.192 dimensiones en modelos avanzados). En este espacio, tokens con relaciones semánticas o sintácticas afines se sitúan a menor distancia matemática.

A continuación, las capas de autoatención evalúan la relación entre cada token de la entrada y todos los demás. Lo hacen calculando tres matrices para cada posición:

  • Queries (Q): lo que el token busca en el resto del texto.
  • Keys (K): la clave con la que otros tokens se anuncian.
  • Values (V): el contenido o significado que aporta si hay coincidencia.

Attention(Q, K, V) = softmax((Q · Kᵀ) / √d_k) · V

Esto permite que, si el prompt dice “El cliente devolvió el albarán porque estaba incompleto”, el pronombre “estaba” atienda con mayor peso a “albarán” que a “cliente”, resolviendo la correferencia de forma contextual.

3. Predicción del siguiente token

Una vez procesada la secuencia de entrada, la última capa del modelo genera una distribución de probabilidad sobre todo su vocabulario (que típicamente cuenta con entre 32.000 y 128.000 tokens posibles):

P(token_t | token_1, token_2, …, token_t-1)

El modelo selecciona el siguiente token y lo añade a la secuencia de entrada, repitiendo el proceso en un bucle autorregresivo hasta alcanzar un token especial de parada (<|endoftext|>) o el límite de longitud fijado. Parámetros como la temperatura o el top_p regulan si la selección escoge estrictamente el token más probable (determinismo) o introduce variabilidad estocástica.

Del entrenamiento en bruto al modelo de instrucciones

La construcción de un LLM comercial pasa por dos grandes fases:

Fase Qué aprende Datos y coste
Pre-entrenamiento (Pre-training) Gramática, conocimiento general del mundo, sintaxis de código y patrones estadísticos. Billones de tokens (artículos web, libros, código, repositorios). Requiere clústeres de cientos o miles de GPUs y meses de cómputo.
Ajuste fino supervisado (SFT) A seguir instrucciones, responder con formato estructurado y mantener diálogos interactivos. Cientos de miles de ejemplos curados de preguntas y respuestas elaboradas por especialistas.
Alineamiento por preferencias (RLHF / DPO) A priorizar respuestas concisas, seguras, honestas y evitar contenidos nocivos o sesgados. Comparaciones de pares de respuestas evaluadas por humanos o modelos de recompensa.

El pre-entrenamiento crea la capacidad de cálculo y representación lingüística; el ajuste fino y el alineamiento moldean esa capacidad para que el modelo actúe como un colaborador útil en lugar de un mero autocompletador de texto caótico.

Los límites técnicos que condicionan su uso en empresa

Trabajar con LLMs en proyectos de software requiere asumir cuatro limitaciones estructurales:

1. Alucinaciones (confabulaciones estadísticas)

Dado que los modelos generan el texto más probable según sus patrones internos, no tienen un mecanismo interno para verificar si una afirmación es verídica. Cuando se les pregunta sobre datos que no formaban parte de su entrenamiento o que son ambiguos, pueden generar respuestas sintácticamente impecables pero fácticamente falsas (inventar leyes, endpoints de API o importes contables).

2. Ventana de contexto finita y degradación

La ventana de contexto define cuánto texto puede procesar el modelo de una sola vez (tanto el prompt como la respuesta previa). Aunque hoy existen modelos con ventanas de 128.000 hasta 1 o 2 millones de tokens, alimentar documentos excesivamente largos incrementa la latencia, el coste por petición y puede provocar pérdidas de atención en la información intermedia (lost in the middle).

3. Falta de determinismo por defecto

Incluso con temperatura cero (temperature: 0), sutiles variaciones en librerías de inferencia paralelas de punto flotante en GPU pueden generar respuestas ligeramente distintas ante la misma consulta. Si una función empresarial exige un comportamiento 100% determinista (por ejemplo, calcular un impuesto o una nómina), ese cálculo debe realizarse en código convencional, no delegarse a un LLM.

4. Coste y latencia operativa

Cada petición consume tokens de entrada y de salida. Mientras que un sistema tradicional responde en milisegundos a coste casi nulo por consulta en servidor, una llamada a un LLM grande añade cientos de milisegundos o varios segundos de latencia y factura por volumen de tokens procesados.

Cómo resolver estos límites en proyectos reales

En los proyectos donde integramos modelos de lenguaje en Totbits (como la extracción y contabilización automática de facturas o la consulta de expedientes técnicos), aplicamos cuatro patrones de ingeniería:

  1. RAG (Generación Aumentada por Recuperación): en lugar de confiar en lo que el modelo «recuerda» en sus pesos, buscamos primero en la base de datos o almacén documental de la empresa los fragmentos oficiales y se los entregamos explícitamente en el prompt como fuente obligatoria.
  2. Salidas estructuradas (Structured Outputs): forzamos al modelo a responder con un esquema JSON estricto validado con Zod o Pydantic, garantizando que el sistema cliente pueda parsear la respuesta sin fallos de formato.
  3. Modelos pequeños para tareas concretas: reservamos los modelos grandes para razonamiento complejo o excepciones, y empleamos modelos más ligeros y económicos para clasificaciones simples o extracciones delimitadas.
  4. Revisión humana ante la duda (Human-in-the-loop): el modelo procesa lo evidente de forma autónoma, pero el sistema debe detectar umbrales de incertidumbre y derivar los casos dudosos a una persona antes de alterar bases de datos en producción.

Fuentes primarias y lecturas técnicas

  • Vaswani et al. (2017): Attention Is All You Need. Conferencia NeurIPS 2017. arXiv:1706.03762
  • Radford et al. (2019): Language Models are Unsupervised Multitask Learners (GPT-2). OpenAI Technical Paper.
  • Brown et al. (2020): Language Models are Few-Shot Learners (GPT-3). NeurIPS 2020. arXiv:2005.14165
  • Touvron et al. (2023): LLaMA: Open and Efficient Foundation Language Models. Meta AI. arXiv:2302.13971
  • Anthropic Documentation (2024): Context Windows & Retrieval Augmented Generation Best Practices. docs.anthropic.com
  • Hugging Face: NLP Course: How Transformers Work. huggingface.co/learn/nlp-course

Artículos relacionados