Aprendizaje automático y modelos de lenguaje grandes para arquitectos

Por qué los arquitectos necesitan entender el modelo

Todos los componentes de los capítulos anteriores de este curso eran deterministas: con la misma entrada y el mismo estado, un servicio devolvía la misma salida, y una prueba podía comprobarlo. Un componente basado en el aprendizaje automático es de una naturaleza distinta. No se escribió como reglas; se ajustó a ejemplos, y lo que devuelve es una mejor estimación estadística. Un modelo de fraude devuelve una puntuación, no un veredicto. Un modelo de lenguaje grande (LLM) devuelve un texto fluido que normalmente es correcto y, de vez en cuando, erróneo con total seguridad.

Un arquitecto no necesita entrenar modelos, igual que no necesita escribir un motor de base de datos. Sí necesita conocer las propiedades de un modelo lo bastante bien como para diseñar teniéndolas en cuenta, del mismo modo que el Capítulo 7 exigía saber qué garantiza realmente un nivel de aislamiento. Esas propiedades son: cómo se crean los modelos y qué implica eso sobre su conocimiento; cómo fallan; de dónde salen su costo y su latencia; y por qué nunca se puede confiar en su salida como se confía en una fila de una base de datos. Todo lo demás en este capítulo, desde la recuperación hasta los guardrails, se deriva de ellas.

El aprendizaje automático en una página

El aprendizaje automático construye una función a partir de datos en lugar de a partir de reglas escritas a mano. Hay tres familias clásicas. En el aprendizaje supervisado, los datos de entrenamiento contienen las respuestas correctas (etiquetas): pagos pasados marcados como fraudulentos o legítimos, repartos pasados con su duración real. El modelo aprende a asignar entradas a etiquetas. Predecir una categoría es clasificación (fraude o no); predecir un número es regresión (minutos hasta que llega la comida). En el aprendizaje no supervisado no hay etiquetas, y el modelo encuentra estructura por sí solo: grupos de clientes similares, transacciones inusuales que no encajan en ningún patrón, representaciones numéricas compactas de un texto. En el aprendizaje por refuerzo, un agente realiza acciones en un entorno y aprende de una señal de recompensa en lugar de a partir de respuestas correctas; por ejemplo, una política de despacho que se recompensa por tiempos de reparto cortos.

Los modelos de lenguaje grandes proceden sobre todo de una cuarta variante, el aprendizaje autosupervisado, en el que las etiquetas se toman de los propios datos: se oculta la siguiente palabra de una frase y se entrena al modelo para predecirla. Como cualquier texto aporta sus propias etiquetas, los modelos pueden entrenarse con muchísimos más datos de los que nadie podría etiquetar a mano.

Dos fases importan desde el punto de vista arquitectónico. El entrenamiento ajusta los números internos del modelo (sus parámetros o pesos) para reducir el error en los datos de entrenamiento. Es una carga de trabajo por lotes pesada: grandes conjuntos de datos, muchos aceleradores (GPU o chips similares), de horas a meses de cómputo y un pipeline que debe ser repetible. La inferencia consiste en usar el modelo entrenado para producir salidas para nuevas entradas. Es una carga de trabajo de servicio con objetivos de latencia, tasas de solicitudes y costo por llamada, muy parecida a cualquier otro servicio del Capítulo 9. La mayoría de los equipos que crean funcionalidades de IA nunca entrenan un modelo grande; consumen la inferencia de un proveedor o ejecutan pesos entrenados por otros.

El modelo mental más útil es que un modelo entrenado es una función probabilística. Para una entrada produce puntuaciones o una distribución de probabilidad sobre las salidas posibles. Alguien, normalmente la aplicación, convierte después esa distribución en una decisión: bloquear el pago si la puntuación de fraude supera 0.8, o elegir la siguiente palabra mediante muestreo. Ese último paso es una decisión de diseño con consecuencias de negocio, y pertenece a la arquitectura, no al modelo.

Bases de la evaluación: precisión, exhaustividad y sobreajuste

Como un modelo se ajusta en lugar de especificarse, la única forma de saber lo bueno que es consiste en medirlo con ejemplos que no ha visto. Los datos se dividen en un conjunto de entrenamiento (para ajustar el modelo), un conjunto de validación (para afinar decisiones como los umbrales) y un conjunto de prueba que se reserva para la medición final y honesta. Un modelo que puntúa bien con sus datos de entrenamiento pero mal con datos nuevos sufre sobreajuste (overfitting): ha memorizado peculiaridades de los ejemplos en lugar de aprender el patrón general. La fuga de datos (data leakage), cuando información sobre la respuesta se cuela en las entradas (por ejemplo, un indicador de reembolso que solo se activa después de confirmarse el fraude), produce modelos que parecen excelentes en las pruebas y fallan en producción.

En la clasificación, la exactitud por sí sola engaña siempre que una clase es poco frecuente. Cuenta cuatro resultados: verdaderos positivos (fraude marcado), falsos positivos (pago legítimo marcado), falsos negativos (fraude no detectado) y verdaderos negativos. La precisión es la proporción de elementos marcados que realmente son positivos, TP / (TP + FP). La exhaustividad (recall) es la proporción de positivos reales que se detectaron, TP / (TP + FN). Subir el umbral de decisión suele aumentar la precisión y reducir la exhaustividad, y el equilibrio adecuado depende de lo que cueste cada tipo de error. La puntuación F1, la media armónica de ambas, las resume en un solo número cuando los costos son similares.

Los modelos también se degradan después del despliegue. Cuando las entradas que ve el modelo se alejan de los datos de entrenamiento (nuevos restaurantes, un nuevo método de pago, una pandemia que cambia los hábitos de pedido), su exactitud cae en silencio. Vigilar esto forma parte de evaluar los sistemas de IA, que se trata más adelante en este capítulo.

El aprendizaje profundo y el transformer

Una red neuronal es una pila de capas, cada una de las cuales calcula sumas ponderadas de sus entradas seguidas de una función no lineal sencilla. El entrenamiento ajusta poco a poco millones o miles de millones de pesos, mediante el descenso de gradiente y la retropropagación, para que las salidas de la red se acerquen a los objetivos. El aprendizaje profundo (deep learning) designa las redes con muchas capas, que aprenden sus propias representaciones internas de la entrada en lugar de depender de características diseñadas a mano. Transformó el reconocimiento de imágenes a partir de 2012, aproximadamente, y el habla y la traducción poco después.

El lenguaje era más difícil porque el significado depende del contexto: en el repartidor dejó la bolsa porque esta estaba rota, esta se refiere a la bolsa. Las redes recurrentes anteriores procesaban el texto palabra por palabra, lo que hacía lento el entrenamiento y frágil el contexto de largo alcance. En 2017, Ashish Vaswani y sus colegas de Google publicaron Attention Is All You Need, que presentó el transformer. Su mecanismo central, la autoatención (self-attention), permite que cada posición del texto calcule una mezcla ponderada de la información de todas las demás posiciones, de modo que esta puede prestar mucha atención a bolsa. Como durante el entrenamiento todas las posiciones se procesan en paralelo, los transformers aprovechan de forma eficiente los aceleradores modernos, y su calidad siguió mejorando a medida que se escalaban los modelos, los datos y el cómputo.

Al arquitecto le llegan dos consecuencias. Primero, el cálculo de la atención crece aproximadamente con el cuadrado de la longitud de la secuencia, que es una de las razones por las que la longitud del contexto tiene límites y los prompts largos cuestan más tiempo y dinero (los avances de ingeniería han suavizado este costo, pero no lo han eliminado). Segundo, hay distintas formas de transformer para distintas tareas: los modelos solo decodificador (decoder-only) generan texto y son la base de los modelos de chat actuales, mientras que los modelos codificador (encoder) de la línea de BERT (2018) leen texto para clasificarlo o representarlo, y sustentan muchos de los modelos de embeddings y de re-ranking que se usan en la recuperación. Muchos modelos grandes también usan un diseño de mezcla de expertos (mixture-of-experts), en el que solo una parte de la red está activa para cada token, lo que reduce el costo de inferencia para un tamaño total dado.

Cómo produce texto un modelo de lenguaje grande

Un modelo no lee caracteres ni palabras; lee tokens, fragmentos de texto de un vocabulario fijo de decenas o cientos de miles de entradas, producidos por un tokenizador. Las palabras comunes son un solo token; las palabras raras, los nombres y los números se dividen en varios. Para un texto en inglés, una regla práctica habitual es de unos cuatro caracteres, o tres cuartos de palabra, por token. Otros idiomas y el código fuente suelen necesitar más tokens para el mismo contenido, lo que importa porque los precios, los límites y la latencia se cuentan en tokens.

La ventana de contexto es el número máximo de tokens que el modelo puede tener en cuenta en una llamada, contando las instrucciones, la conversación hasta ese momento, los documentos que se le proporcionen y la respuesta que escribe. En 2026, las ventanas van desde unos pocos miles de tokens en los modelos pequeños en el dispositivo hasta alrededor de un millón o más en algunos modelos alojados. Una ventana grande no equivale a usarla bien: Liu y sus colegas (Lost in the Middle, 2023) mostraron que los modelos usan la información del principio y del final de un contexto largo de forma más fiable que la información enterrada en el medio, y cada token adicional añade costo y latencia.

La generación es una predicción del siguiente token en bucle. El modelo lee toda la entrada (la fase de prefill) y produce, para cada token de su vocabulario, la probabilidad de que sea el siguiente. Se elige un token, se añade a la entrada y el proceso se repite (la fase de decodificación o decode) hasta que el modelo emite un marcador de fin o alcanza una longitud máxima. El modelo guarda en caché los resultados internos de los tokens que ya ha procesado (la caché KV), así que cada paso solo calcula el nuevo token, pero la salida se sigue produciendo de token en token. Por eso los tokens de salida son más lentos y normalmente varias veces más caros que los tokens de entrada, y por eso las respuestas se envían a los usuarios en streaming a medida que se producen.

La forma de elegir el siguiente token se llama muestreo (sampling). La decodificación voraz (greedy) siempre toma el token más probable. La temperatura reescala antes las probabilidades: por debajo de 1 las concentra en el favorito; por encima de 1 las aplana para que los tokens menos probables aparezcan más a menudo. El muestreo top-p (de núcleo) conserva solo los tokens más probables cuyas probabilidades suman p, y el top-k conserva solo los k más probables. Una temperatura baja conviene para la extracción, la clasificación y la corrección; una temperatura más alta conviene para la lluvia de ideas y la redacción variada.

Por último, el modelo no tiene estado. La API de un modelo no recuerda nada entre llamadas: un chat parece continuo solo porque la aplicación envía todo el historial relevante con cada solicitud. Por tanto, el estado de la conversación vive en tu sistema, su tamaño determina el costo en cada turno, y decidir qué conservar, resumir o descartar es una tarea de diseño (consulta la memoria y el estado en la sección 12.4).

import math

# raw scores the model gives three candidate next tokens after
# "The capital of Portugal is"
logits = {"Lisbon": 9.0, "Porto": 6.5, "Madrid": 5.0}

def probabilities(logits, temperature):
    scaled = {t: v / temperature for t, v in logits.items()}
    total = sum(math.exp(v) for v in scaled.values())
    return {t: round(math.exp(v) / total, 4) for t, v in scaled.items()}

print(probabilities(logits, 1.0))  # Lisbon 0.9088, Porto 0.0746, Madrid 0.0166
print(probabilities(logits, 0.5))  # Lisbon 0.9930, Porto 0.0067, Madrid 0.0003
print(probabilities(logits, 2.0))  # Lisbon 0.7033, Porto 0.2015, Madrid 0.0952

Embeddings: el significado como números

Un embedding es una lista de números (un vector, normalmente de unos cientos a unos miles de números de longitud) que representa el significado de un fragmento de texto, una imagen o un producto, y que produce un modelo de embeddings. El modelo se entrena para que los elementos con un significado similar queden cerca: mi comida llegó fría y el pedido no estaba caliente cuando lo entregaron producen vectores cercanos aunque casi no compartan palabras. La cercanía suele medirse con la similitud del coseno, el ángulo entre dos vectores.

Los embeddings impulsan la búsqueda semántica, las recomendaciones, la deduplicación, el agrupamiento (clustering) y la clasificación, y son el núcleo de la mayoría de los sistemas de generación aumentada por recuperación. De ello se derivan dos hechos arquitectónicos. Los modelos de embeddings son independientes, más pequeños y mucho más baratos que los modelos de generación, y pueden ejecutarse fácilmente en tu propia infraestructura. Y los vectores de distintos modelos de embeddings (o de distintas versiones de uno) no son comparables, así que cambiar el modelo de embeddings implica volver a generar los embeddings de todo el corpus: una decisión que es barata de tomar al principio y cara de revertir después.

Del preentrenamiento a un asistente útil

Un modelo de chat moderno se construye por etapas. El preentrenamiento ejecuta la predicción autosupervisada del siguiente token sobre un corpus enorme de texto y código, a menudo billones de tokens. Es con diferencia la etapa más cara, al alcance de muy pocas organizaciones, y da como resultado un modelo base: un potente continuador de textos que ha absorbido gramática, hechos, estilos y patrones de razonamiento, pero que no sigue las instrucciones de forma fiable. Todo lo que el modelo sabe gracias al preentrenamiento queda congelado en una fecha de corte del entrenamiento.

El fine-tuning (ajuste fino) continúa el entrenamiento con un conjunto de datos mucho más pequeño y específico. El ajuste por instrucciones (instruction tuning) hace fine-tuning con ejemplos de instrucciones emparejadas con buenas respuestas, y convierte el modelo base en un asistente. Después, el aprendizaje por refuerzo a partir de retroalimentación humana (RLHF) pide a personas que comparen pares de respuestas, entrena un modelo de recompensa para predecir sus preferencias y optimiza el asistente para que obtenga una buena puntuación con él. El enfoque lo describieron Christiano y sus colegas en 2017 y se aplicó al seguimiento de instrucciones en el trabajo InstructGPT de OpenAI (Ouyang y sus colegas, 2022). Algunas variantes sustituyen partes del pipeline: la optimización directa de preferencias (direct preference optimisation, 2023) aprende de las comparaciones sin un modelo de recompensa separado, y la retroalimentación puede proceder de otro modelo que sigue unos principios escritos en lugar de proceder de personas.

Las organizaciones también pueden hacer fine-tuning, a menudo con métodos eficientes en parámetros como LoRA (Hu y sus colegas, 2021), que entrenan un pequeño complemento en lugar de todos los pesos. El fine-tuning sirve para enseñar un formato, un tono, una tarea acotada o el vocabulario de un dominio. Es una mala forma de enseñar hechos que cambian, como precios o políticas, porque esos hechos quedan entonces incorporados en pesos que no pueden citar su fuente, no pueden actualizarse sin reentrenar e ignoran los derechos de acceso. Para el conocimiento cambiante, la recuperación suele ser la mejor herramienta; el orden habitual de intentos es primero mejores prompts, después recuperación y después fine-tuning.

Alucinación y no determinismo

Una alucinación es una salida fluida y segura de sí misma, pero falsa o sin respaldo: una cita inventada, una función que no existe en una biblioteca, una política de reembolsos que la empresa nunca tuvo. Es una consecuencia directa de cómo funciona el modelo. El entrenamiento recompensa las continuaciones plausibles, no las verificadas, y el modelo no tiene una forma integrada de distinguir lo que sabe de lo que simplemente suena bien. Las tasas de alucinación varían mucho según el modelo y la tarea, y bajan cuando al modelo se le dan los hechos relevantes (fundamentación o grounding), se le permite y se le anima a decir que no sabe algo, o se le obliga a citar fuentes que la aplicación pueda comprobar. No llegan a cero.

Las salidas también son no deterministas. Con el muestreo, el mismo prompt da respuestas distintas por diseño. Incluso a temperatura 0, no está garantizado que los modelos alojados sean repetibles: la aritmética de punto flotante en los aceleradores no es perfectamente asociativa, y la forma en que un servidor agrupa tu solicitud con otras puede cambiar el orden de las operaciones y, por tanto, ocasionalmente, un token. Los proveedores también actualizan los modelos sin cambiar sus nombres. Pequeños cambios en la redacción del prompt, en el orden de los ejemplos o en el contexto que los rodea pueden cambiar los resultados de forma apreciable.

Para un arquitecto, estas dos propiedades significan que una prueba que comprueba una única salida exacta demuestra poco, que la versión del modelo y el prompt deben registrarse con cada resultado, y que cualquier salida que importe debe comprobarla algo más fiable que el propio modelo.

Diseñar en torno a un componente probabilístico

La idea arquitectónica más importante de este capítulo es la contención. Un modelo es un componente potente pero poco fiable, así que el código determinista que lo rodea decide qué se le permite ver al modelo, qué se le permite hacer y qué ocurre con su salida. En términos de la arquitectura hexagonal, el modelo está detrás de un puerto: el dominio pide un borrador de respuesta, una clasificación o una extracción, y el adaptador que llama al modelo también hace cumplir el contrato de salida. Las reglas del dominio (límites de reembolso, horarios de apertura, quién puede ver qué pedido) se quedan en código corriente y comprobable.

Una prueba útil para cualquier funcionalidad de IA propuesta es preguntar qué ocurre cuando el modelo se equivoca de la forma más plausible. Si la respuesta es un cliente ve una frase un poco torpe, se necesita poco control. Si es se paga un reembolso a la cuenta equivocada o a un paciente se le indica una dosis incorrecta, el diseño debe hacer imposible ese resultado mediante validación, permisos y confirmación humana, por bueno que sea el modelo. Los modelos seguirán mejorando; este principio de diseño no cambiará.