Trust, but Trace

El fine-tuning es mala herramienta para añadir conocimiento: tres fases de entrenamiento y el atajo de bajo rango

Carlos Chinchilla Corbacho — Tue, 03 Nov 2026 00:00:00 GMT

En la parte 9 entrenamos un modelo desde cero, pero lo normal en este trabajo es partir de unos pesos que ha entrenado otro y modificarlos. Preentrenamiento, fine-tuning, RLHF y LoRA son cuatro palabras que describen esa tarea como si fueran cuatro máquinas distintas.

He leído la capa LoRA de peft y la pérdida DPO de trl, y después le he enseñado a SmolLM2-135M quince capitales, tres que ya sabía y doce de países que no existen. Se las aprendió todas, y ahí está el problema.

Tres fases y un modelo en entrenamiento

El preentrenamiento consiste en predecir el siguiente token sobre todos los datos que tengas, con la entropía cruzada de la parte 8 aplicada a un corpus. Es en esta fase donde el modelo adquiere casi todo lo que sabe.

El fine-tuning supervisado (SFT) usa la misma pérdida sobre pares de instrucción y respuesta. Lo habitual es cambiar qué posiciones cuentan y dejar fuera el prompt con una máscara, como hace trl por defecto con los datos de tipo prompt-completion. En un ejemplo con cinco tokens de prompt y siete de respuesta, la pérdida fue de 2,9883 sobre la secuencia entera y de 2,4845 sobre la respuesta sola, los mismos dos números que he sacado a mano de los logits. Lo único distinto es un array de etiquetas, igual que cuando se ejecuta el mismo binario con otro fichero de configuración.

En la tercera fase, el ajuste por preferencias, no hay respuesta correcta. Cada ejemplo son dos respuestas y una nota que indica cuál prefirió una persona.

Por defecto, las tres fases actualizan todos los pesos del modelo que se entrena, al que en el ajuste por preferencias se llama política, un término heredado del aprendizaje por refuerzo. Lo que distingue a la tercera es cuántos modelos más mantiene a su lado.

El ajuste por preferencias optimiza una diferencia

El aprendizaje por refuerzo a partir de retroalimentación humana (RLHF) entrena un modelo de recompensa para puntuar respuestas y luego optimiza la política según esas puntuaciones. Su algoritmo clásico, PPO (optimización proximal de políticas), añade un crítico que predice qué puntuación acabará teniendo una respuesta a medio escribir. También guarda una referencia congelada, el modelo tal como estaba antes de esta fase, para penalizar que la política se aleje de ella. Son cuatro modelos para una sola actualización. La optimización directa de preferencias (DPO) prescinde del modelo de recompensa y del crítico, pero conserva la referencia. Su núcleo, condensado de dpo_trainer.py:1445-1483 de trl, es este:

chosen_logratios = chosen_logps - ref_chosen_logps        # how far the policy moved, on the good answer
rejected_logratios = rejected_logps - ref_rejected_logps  # and on the bad one
chosen_scores, rejected_scores = chosen_logratios, rejected_logratios   # the default divergence
delta_score = chosen_scores - rejected_scores
per_sequence_loss = -F.logsigmoid(self.beta * delta_score)

La pérdida busca que la diferencia entre esos dos movimientos sea grande. beta, que vale 0,1 por defecto, fija lo que cuesta alejarse de la referencia. Cuanto más alta, menos se mueve la política.

La referencia parece una segunda copia de los pesos, pero con una política LoRA (la explico más abajo) no lo es. La parte entrenable es un pequeño desvío al lado de los pesos congelados, así que basta con apagarlo para tener la referencia. Con el desvío apagado, las log-probabilidades de la política coincidieron hasta el último bit con las de un modelo congelado cargado aparte, tanto antes de entrenar como tras veinte pasos. En el paso cero, la política y la referencia son el mismo modelo y la diferencia es cero. La pérdida vale entonces menos el logaritmo de un medio, es decir, log 2, que con seis decimales es 0,693147.

Esas cuentas las he hecho en un bucle propio, fuera de DPOTrainer. Con una tasa de aprendizaje brutal de 0,001 y veinte pasos sobre dos pares de preferencias, la diferencia pasó de 0 a 95,4. La respuesta buena se volvió 2,9 nats más probable y la mala, 92,5 nats menos.

En parte, eso viene de serie. Como una log-probabilidad no puede pasar de cero y las respuestas buenas partían de −2,3 y −3,5, esos 2,9 nats eran casi todo el margen que tenían; las malas, en cambio, medían nueve y doce tokens y no tenían suelo. Por eso lo he relanzado con pares de la misma longitud, París contra Lyon y 4 contra 5, tres veces en cada sentido. Con la tasa brutal, el lado rechazado cayó entre 31 y 47 nats en todas las ejecuciones, mientras que el preferido se movió entre −1,2 y +4,2 y en una de ellas acabó siendo menos probable que al principio.

Con una tasa realista de 0,00001, el reparto depende de dónde partía cada respuesta. Cuando las preferidas eran París y 4, ganaron entre 0,01 y 0,02 nats y las otras perdieron entre 0,16 y 0,17; cuando lo eran Lyon y 5, ganaron 0,15 y las otras perdieron 0,03. En estos pares, el movimiento mayor se lo llevó la respuesta que al principio era menos probable. La pérdida pide una diferencia y la saca del lado más barato. Nada en ella obliga a que la respuesta preferida se vuelva más probable.

LoRA entrena otro objeto

LoRA (adaptación de bajo rango) es una decisión sobre en qué consiste la actualización, válida para cualquiera de las tres fases. Se deja intacta una matriz de pesos y se le ponen al lado dos matrices pequeñas, que juntas forman el adaptador. Así lo hace peft, en una versión condensada de lora/layer.py:263-1102.

self.lora_A[adapter_name] = nn.Linear(self.in_features, r, bias=False)  # d_in to r
self.lora_B[adapter_name] = nn.Linear(r, self.out_features, bias=lora_bias)  # r to d_out
self.scaling[adapter_name] = lora_alpha / r
nn.init.zeros_(self.lora_B[adapter_name].weight)
result = result + lora_B(lora_A(dropout(x))) * scaling

El rango r marca lo estrecho que es el tramo intermedio. Antes de sumarse al resultado, el desvío se multiplica por lora_alpha / r, que con alpha 16 y rango 8 vale 2,0.

El truco está en los ceros de la última línea de la inicialización. En el paso cero el producto de las dos matrices es cero, así que el modelo es idéntico, bit a bit, al que tenías al empezar. Después el entrenamiento mueve A y B. Lo que aprenden es una diferencia que, al multiplicarse, da un cambio de rango 8 en una de las matrices de 576 por 576 de SmolLM2 (rango en el sentido del álgebra lineal, es decir, el número de direcciones independientes que tiene el cambio). Fusionado con la matriz, el adaptador dio los mismos logits que cuando iba al lado, con una discrepancia máxima de 0,00008.

De ese rango sale el ahorro. Si se adaptan las matrices query y value de Llama-3.1-8B con rango 8, se entrenan 3 407 872 números de 8 030 261 248, un 0,04 %.

Figura interactiva: Lo que cuesta entrenar Llama-3.1-8B con fine-tuning. Elige qué matrices llevan adaptador y arrastra el rango. La barra de arriba es LoRA y la de abajo, el fine-tuning completo. Ninguna de las dos incluye las activaciones. Ábrela en el artículo para usarla.

Si subes el rango, el total apenas se mueve, porque casi todo es la base congelada. Ahora pasa la base a NF4 con doble cuantización, el formato de 4 bits de QLoRA (la receta para entrenar LoRA sobre una base de 4 bits), y desaparecen casi dos tercios de la barra de LoRA. Solo las capas de dentro de los bloques bajan a algo más de cuatro bits por peso; los embeddings y la capa de salida se quedan en dieciséis.

Los hechos entran despacio y con ellos llega la confianza

Hasta aquí la mecánica. Ahora viene la parte que se suele entender mal en las reuniones de planificación.

El punto de partida son doce capitales de países inventados y doce reales, todas con la forma «The capital of Vantressa is Molduin». De las reales, el modelo completó tres palabra por palabra. En seis de las otras nueve contestó cosas como «the city of Rome», que no cuentan como coincidencia exacta. Las nueve quedaron fuera. Luego he ajustado todos los pesos sobre las quince a la vez, con una tasa de 0,00001.

Las tres que ya sabía se afianzaron enseguida y en veinte pasos la confianza en el primer token de la respuesta correcta pasó del 22 % al 97 %. Para entonces las doce nuevas estaban en el 2 % y el modelo acertaba una. En el paso cuarenta ya respondía las doce. En parte, la lentitud se debe al punto de partida. En ese primer token, los hechos nuevos estaban a 8,6 nats de distancia, frente a los 1,5 de los conocidos, más de cinco veces más lejos. Además, cada uno necesitaba acertar dos o tres tokens cuando a los conocidos les bastaba uno. Gekhman y colaboradores describen el mismo patrón a gran escala: el conocimiento nuevo se ajusta significativamente más despacio y, a medida que entra, aumentan las alucinaciones.

Eso sí, «respondía» quiere decir que completaba la frase con la que lo había entrenado. Con «What is the capital of Vantressa?» no acertó ninguna de las doce, ni al preguntarle de qué país es capital Molduin; con «Vantressa’s capital city is», en cambio, acertó seis. Lo que había aprendido era una frase.

Algo parecido a ese aumento de las alucinaciones apareció también aquí. Otros seis nombres de país, inventados o sacados de lugares poco conocidos, se quedaron fuera del entrenamiento. Antes de entrenar, el modelo los completaba igual que las capitales reales de más arriba, con alrededor de un 24 % de confianza. Cinco respuestas empezaban por «the town of» o «the city of», cuatro de ellas seguidas del propio nombre del país. Tras cien pasos, cuatro de las seis acababan en una ciudad real seguida de un punto. Según el modelo, la capital de Volnaya es Moscú, con un 82 %. La de Quenby es Shillong, la de Dalmerie, Edimburgo, y la de Rhuddlan, Birmingham sin la B.

En el entrenamiento no había nada sobre esos lugares. Moscú estaba en el batch como capital de Rusia, pero Volnaya también suena a ruso, y en el paso 10 la respuesta era Vorónezh. Otras respuestas se guiaban por el sonido, como Maribor para Marovska o Cardiff para Rhuddlan. Aprendió que una frase de esta forma acaba en una ciudad y a menudo escogió una que encajaba por cómo sonaba.

Figura interactiva: Fine-tuning de todos los pesos de un modelo de 135M con doce hechos que no podía haber visto, junto a los tres reales (de doce) que ya sabía completar. Arrastra el paso. La línea ámbar es su confianza en el primer token de la respuesta correcta para los hechos que ya conocía; la continua, lo mismo para los nuevos, y la punteada, la seguridad media con que responde (diga lo que diga) en seis lugares inventados que nadie le enseñó. Ábrela en el artículo para usarla.

Arrastra hasta el paso 20 y verás que los hechos conocidos están en el 97,0 %, los nuevos en el 1,9 % y el modelo recuerda uno de los doce. Después recorre todo el entrenamiento fijándote en la línea punteada, la de los seis países que nadie le enseñó. Baja al 5,7 % en el paso 10, cuando el modelo deja de decir «the», y termina en el 41,1 %, frente al 23,7 % del principio. Esa subida se debe a dos respuestas: Moscú, con un 82 %, y «Th», el comienzo del propio nombre de Threndale, con un 89 % (el modelo lo completa como «Thwapth»). Las otras cuatro se quedan en un 19 % de media, cuando empezaron en un 24 %.

El parche que nadie puede leer

Un fine-tuning completo es un diff, así que lo he contado. De 134 515 008 parámetros cambiaron 134 513 152, aunque ninguno lo bastante como para llamar la atención. La mediana del cambio fue 0,0002 y el máximo llegó a 0,0012, que es más o menos la tasa multiplicada por los cien pasos. Con el Adam de la parte 9, un peso con un gradiente estable se mueve en cada paso aproximadamente lo que vale la tasa. El cambio en una matriz de atención ocupó 572 de sus 576 direcciones posibles. Si se mide por la suma de los cuadrados de los cambios, las ocho primeras direcciones recogen el 71 % y hacen falta 27 para llegar al 90 %. Las ocho de LoRA lo recogen todo por construcción. Lo único que el diff comparte con un parche que se pueda revisar es que, al restarlo, se recuperan los pesos originales.

Un parche ilegible solo es un problema si ha cambiado algo que te importaba, y por eso lo he medido. He hecho ocho versiones del mismo fine-tuning, con tres tasas de aprendizaje para la actualización completa y cinco para un adaptador LoRA de rango 8 sobre las matrices query y value. A cada una la he puntuado por cuánto subía su pérdida en seis entradas de este blog con las que no se entrenó ninguna.

El fine-tuning completo aprendió los doce hechos con todas las tasas. LoRA no aprendió ninguno hasta la tasa de 0,0003, que es treinta veces la que ya le bastaba al completo. Si se toma para cada uno la tasa más baja de las probadas con la que aprendió, LoRA subió la pérdida en esas entradas más de veinte veces más que la actualización completa (0,111 nats frente a 0,005), una factura curiosa para la opción barata.

A igualdad de tasa, con 0,001 la actualización completa subió la pérdida quince veces más que LoRA (4,419 frente a 0,287). Este adaptador sí limita el daño, solo que necesita una tasa a la que haya daño que limitar.

Para ser justos, todo esto son ocho ejecuciones con una sola semilla sobre un modelo de 135M, con quince hechos, cien pasos, una única configuración de adaptador y una rejilla de tasas poco densa. Un adaptador en todas las capas lineales quizá aprendería con una tasa más baja, y con un modelo más grande o un dataset real el orden podría salir distinto. Lo que sí esperaría que se transfiriera es el método: comparar tanto a igualdad de resultado como de configuración y medir el daño colateral en algo ajeno al fine-tuning.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y el primero es una decisión previa a todo lo demás.

Pregúntate qué quieres cambiar. Los hechos que faltan deberían llegar por recuperación a la ventana de contexto, donde puedes verlos y quitarlos. El comportamiento, el formato y las negativas a responder sí se le dan bien al fine-tuning.

Puntúa el daño colateral además del objetivo. Todas las ejecuciones que aprendieron los doce hechos acabaron por encima del 99 % en ellos, incluida la actualización completa a 0,001, que subió más de cuatro nats la pérdida en las seis entradas. La parte 8 pedía una sola puntuación sobre el conjunto de test, pero en esta fase hacen falta dos, una sobre texto general y otra sobre lo que de verdad vendes.

Trata la tasa como la palanca del daño. En las ocho ejecuciones, la tasa movió el daño colateral tres órdenes de magnitud, frente al factor de quince que hubo entre la actualización completa y la de bajo rango en la única tasa con la que aprendieron las dos. Haz un barrido, como en la parte 9, y elige la tasa por la cifra de daño colateral.

Mantén separados la base, el adaptador y el modelo fusionado. El adaptador de Llama con rango 8 ocupa 6,8 MB al lado de los 16 GB de la base congelada y se apaga con una sola llamada. Por eso el modelo de referencia de antes salía gratis en memoria. El cómputo sí se paga, porque en cada paso hay que volver a ejecutar el modelo con el adaptador apagado. Fusiona cuando vayas a servir un solo adaptador sobre una base sin cuantizar. Mientras decides, o cuando una misma base sirva muchos adaptadores, mantén las piezas separadas.

Esto tampoco es trabajo de modelado: todo se reduce a una máscara sobre las etiquetas, una sigmoide sobre una diferencia y, en la parte de bajo rango, dos matrices estrechas, una de ellas a cero. Las cuentas se leen en una tarde, y aun así acaban en un diff de cien millones de números que nadie puede revisar.

Parte 10 de 12. El preentrenamiento y el fine-tuning supervisado comparten pérdida y se distinguen en qué posiciones ve esa pérdida. El ajuste por preferencias conserva una referencia congelada, a la que el PPO clásico de RLHF suma un modelo de recompensa y un crítico, mientras que DPO prescinde de los dos y optimiza una diferencia que saca sobre todo del lado que cuesta menos mover. LoRA entrena dos matrices estrechas junto a los pesos congelados. Entre las tasas que he probado, necesitó una treinta veces mayor que la de la actualización completa para aprender los hechos, y con ella causó más de veinte veces más daño colateral. Los hechos que se enseñan ajustando todos los pesos llegan despacio, como frases, y traen consigo una confianza inmerecida, hasta el punto de que el modelo dio Moscú como capital de un país que no existe. La siguiente parte se pregunta qué hace falta para servir el modelo. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas, la atención, el bloque, GPT-2 y sus dos programas, lo que cambió Llama, el origen de los gradientes y lo que hace el optimizador con ellos.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

La tasa de aprendizaje es el hiperparámetro que rompe producción

Carlos Chinchilla Corbacho — Tue, 27 Oct 2026 00:00:00 GMT

La parte 8 terminó con un gradiente, que indica hacia dónde mover cada peso. Cuánto moverlo lo decide el optimizador, y esa decisión se reduce a un puñado de números en un fichero de configuración que nada en todo el stack comprueba.

He leído el paso de Adam en torch y el schedule de nanoGPT, y después he entrenado de 21 maneras el modelo de caracteres de la parte 8 (cuatro bloques que leen el texto carácter a carácter): siete tasas de aprendizaje, cada una sin warmup, con warmup y con warmup más un decaimiento coseno. Ninguna de las 21 ejecuciones se cayó.

Tres optimizadores en cinco líneas

El descenso de gradiente a secas resta el gradiente multiplicado por un tamaño de paso. El momentum va acumulando los gradientes pasados en una suma que se encoge un poco en cada paso, y es esa suma la que mueve el peso. Así, un peso empujado dos veces hacia el mismo lado coge velocidad. Adam añade una segunda media, la del gradiente al cuadrado, y divide por su raíz cuadrada. El paso de torch 2.14, condensado a partir de adam.py:456-546, queda así.

exp_avg.lerp_(grad, 1 - beta1)                    # average of the gradient
exp_avg_sq.mul_(beta2).addcmul_(grad, grad, value=1 - beta2)   # average of its square
step_size = lr / (1 - beta1 ** step)              # bias correction, early steps
denom = exp_avg_sq.sqrt() / (1 - beta2 ** step) ** 0.5 + eps
param.addcdiv_(exp_avg, denom, value=-step_size)  # one step per weight

Toda la idea está en esa división. A un peso cuyo gradiente ha sido grande últimamente le toca un divisor grande, y a uno con gradientes pequeños, uno pequeño. Cada peso acaba así con su propio tamaño de paso, marcado por su historia reciente, y lr solo pone la escala. Otros dos números de la configuración, beta1 y beta2, fijan lo rápido que cada media olvida lo que ha visto (nanoGPT usa 0,9 y 0,95).

AdamW añade una línea, param.mul_(1 - lr * weight_decay) en adam.py:419, que encoge un poco cada peso en cada paso. La última sección trata de dónde se coloca esa línea.

La escala de la pérdida se cancela y lo paga la memoria

En la parte 8, multiplicar una pérdida por 40 no cambió nada, y ahora se ve por qué. Si multiplicas cada gradiente por 40, exp_avg se multiplica por 40 y exp_avg_sq por 1600, así que su raíz cuadrada también se multiplica por 40 y el factor se cancela en la división. Se cancela en todas partes salvo en eps, la constante que se suma al denominador para que no se acerque a cero. Escalar la pérdida por 40 equivale a dividir esa constante entre 40. Si alguna vez has cambiado las unidades de una métrica y las alertas han seguido igual porque todos los umbrales eran relativos, aquí pasa lo mismo.

En tres pasos del modelo de caracteres, el desplazamiento mediano de los pesos con AdamW fue de 0,0022 tanto con la pérdida escalada como sin escalar, y los dos vectores de actualización apuntaban en la misma dirección. Con SGD a secas, el mismo cambio multiplicó por 17,5 el paso mediano y desvió 30 grados la actualización. Eso sí, la cancelación no es idéntica peso a peso: la mayor discrepancia fue de 0,00134, más de la mitad de un paso típico.

Lo que Adam gana en robustez lo paga en memoria. Guarda dos números por peso, que torch llama exp_avg y exp_avg_sq, mientras que SGD con momentum guarda uno y SGD a secas, ninguno. Lo he comprobado en el estado del optimizador de torch con el modelo de caracteres, y salen justo esos números. Para GPT-2 small en fp32 son 996 MB de estado del optimizador, junto a 498 MB de pesos y otros 498 MB de gradientes. Pongamos 2 GB antes de contar una sola activación del grafo de la parte 8.

Figura interactiva: Cómo se reparte la memoria en un paso de entrenamiento de GPT-2 small en fp32. Elige un optimizador y después ajusta el batch y la longitud de secuencia. Pesos y gradientes no cambian; las otras dos barras, sí. Ábrela en el artículo para usarla.

Con AdamW, las tres barras que no se mueven con el batch suman los 2 GB de antes. Cambia a SGD y verás desaparecer un tercio del total. Luego sube el batch y mira qué le hacen las activaciones a ese mismo presupuesto.

El primer paso mide exactamente la tasa de aprendizaje

Vuelve a mirar step_size = lr / (1 - beta1 ** step). En el primer paso, exp_avg es el gradiente multiplicado por 1 - beta1, justo lo que divide la corrección. Al cancelarse los dos, la primera actualización se queda en el gradiente dividido por su propio tamaño, multiplicado por lr.

Con lr a 0,001, el desplazamiento mediano de los pesos en el primer paso fue de 0,001, exactamente la tasa de aprendizaje, fuera cual fuera el gradiente. El tamaño del gradiente no llega nunca a la actualización, y de él solo sobrevive el signo, peso a peso. A partir del segundo paso, lo que sobrevive es cada gradiente comparado con su propio tamaño reciente.

Para que salga exacto hacen falta dos condiciones, y las dos dependen de la configuración. Un gradiente cercano a eps (10⁻⁸ por defecto) lo estropea: con 10⁻⁹ el primer paso se queda en una décima parte de la tasa, y con 10⁻¹², en una diezmilésima. Además, el AdamW de torch aplica por defecto un weight decay de 0,01 si no le pasas otro valor. De ahí que el primer paso más grande que he medido fuera de 0,00101, apenas por encima de la tasa.

Para eso está el warmup. Si la tasa arranca cerca de cero y sube de forma lineal durante los primeros cientos de pasos, esas primeras actualizaciones, que miden exactamente la tasa, salen pequeñas. El schedule de nanoGPT, en train.py:231-242, cabe en ocho líneas.

if it < warmup_iters:                       # 1) linear warmup
    return learning_rate * (it + 1) / (warmup_iters + 1)
if it > lr_decay_iters:                     # 2) then a floor
    return min_lr
decay_ratio = (it - warmup_iters) / (lr_decay_iters - warmup_iters)
assert 0 <= decay_ratio <= 1
coeff = 0.5 * (1.0 + math.cos(math.pi * decay_ratio))   # 3) cosine in between
return min_lr + coeff * (learning_rate - min_lr)

Con 100 pasos de warmup, la primera actualización se quedó en 0,0000099 frente a 0,001 (cien veces menor) y a partir de ahí fue creciendo. Pasado el warmup, el resto del schedule va bajando la tasa hasta una décima parte del pico, que es lo que fija el min_lr de nanoGPT en train.py:68. El único assert del schedule comprueba la aritmética del cociente, y el valor que has configurado ni lo mira.

Qué dice el barrido

He entrenado el modelo de caracteres durante 600 pasos con tres schedules (ninguno, 100 pasos de warmup y warmup más el decaimiento coseno) y siete tasas de aprendizaje para cada uno, de 0,0001 a 0,1. Los gradientes iban recortados a 1,0 en todo momento, como hace nanoGPT. El barrido no puede separar el warmup del recorte, y el recorte ya estaba haciendo su parte. Con 0,003 y sin warmup, quitar el recorte llevó la puntuación de 2,18 a 2,38 y dejó que la norma del gradiente llegara a 79. Como referencia, adivinar solo por frecuencia da 3,23 en el texto de test.

Ninguna ejecución dio un NaN, ni siquiera con una tasa de aprendizaje diez veces mayor que la mejor.

La mejor ejecución sacó 1,73 con warmup, coseno y una tasa de 0,01. La misma tasa dio 1,84 solo con warmup y 2,61 sin ninguno de los dos. Sin warmup, ninguna tasa bajó del 2,02 que sacó la de 0,001. El warmup, por tanto, no rescató ninguna ejecución rota. Hizo viable una tasa diez veces mayor, y en esa tasa estaba la buena puntuación.

Con 0,1 constante, la pérdida se estancó cerca de 3,0, apenas mejor que adivinar por frecuencia de letras. Bajar, bajó, pero luego dejó de bajar. Ese valor solo te parecería malo si supieras lo que hace el mismo modelo con 0,01. Con el coseno, que baja la tasa hasta 0,01, la ejecución de 0,1 siguió mejorando hasta 2,71, aunque se quedó a casi un nat de la mejor.

Figura interactiva: Pérdida de entrenamiento del mismo modelo pequeño de caracteres durante 600 pasos (en escala logarítmica), con siete tasas de aprendizaje y tres schedules. Elige un schedule y después arrastra la tasa. Las dos líneas horizontales son puntuaciones en test: la de adivinar por frecuencia de letras y la mejor de las 21 ejecuciones. «Pérdida duplicada» es la regla para abortar, y marca el primer paso cuya pérdida superó el doble de la mejor hasta entonces. Ábrela en el artículo para usarla.

Empieza en 0,01 y pulsa sin warmup, que también quita el coseno, y verás que la puntuación en test sube de 1,73 a 2,61. Luego arrastra hasta 0,1 y mira cómo la curva se aplana sin llegar a explotar, con el indicador de NaN todavía en «nunca».

Para ser justos con lo que da de sí un portátil, un modelo de cuatro bloques entrenado en él no es un preentrenamiento. Como cada cifra de aquí sale de una sola semilla, por debajo de unos 0,05 nats no hay nada que leer. A escala real, una tasa mala sí produce el pico de pérdida y el NaN. Lo que se transfiere es la forma: la misma tasa que va bien con warmup desperdicia el entrenamiento sin él, y el fallo que tienes que saber detectar no es que la ejecución se caiga.

El weight decay y dónde ponerlo

El weight decay encoge los pesos hacia cero. La forma original consiste en sumar weight_decay * param al gradiente, con lo que ese término pasa por la división de Adam y se reescala peso a peso como todo lo demás. El param.mul_(1 - lr * weight_decay) de AdamW lo saca de ese camino, y de ahí viene la W.

La diferencia salta a la vista. Con el mismo entrenamiento de 400 pasos y un weight decay de 0,1 en todos los parámetros, la versión desacoplada sacó 2,22 en el texto de test y la acoplada 3,03, apenas mejor que adivinar por frecuencia. La acoplada terminó con una norma de los pesos (la longitud de todos ellos tomados como un solo vector) de 21, frente a 41. Reescalado por Adam, el weight decay fue lo bastante fuerte para vaciar el modelo.

Hay dos cosas que decir de esa cifra. La primera es que la misma ejecución sin weight decay sacó 2,21. En 400 pasos, el weight decay desacoplado no aportó nada y toda la diferencia es el daño que hace el otro camino. La segunda es que aplicar weight decay a todos los parámetros probablemente empeora el caso acoplado, porque la parte del gradiente que encoge los pesos cae también sobre las escalas de normalización, que empiezan en 1,0 y en la inicialización concentran la mayor parte de la norma de los pesos.

nanoGPT aplica el weight decay de forma selectiva en model.py:269-274, donde lo llevan las matrices pero no los sesgos ni las escalas de LayerNorm. Son dos líneas de filtrado, y saltárselas no da ningún error.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y los dos primeros consisten solo en guardar números.

Registra la tasa de aprendizaje efectiva: con la configurada no basta. El número que importa es el que ha devuelto el schedule en este paso. Un schedule que se reinició al reanudar repitió el warmup, arrancó 70 veces por debajo de la tasa de una reanudación completa y acabó la ejecución más de tres veces por encima, mientras el fichero de configuración decía lo mismo en las dos ejecuciones. En los mismos 150 pasos sacó 2,275 frente a 2,230, dentro del ruido de una sola semilla. Solo la tasa registrada lo habría delatado.

Guarda en el checkpoint el estado del optimizador, además de los pesos. En GPT-2 small, las dos medias de AdamW ocupan 996 MB, y si las tiras, el promediado vuelve a empezar sin avisar. Sobre el mismo batch, el primer paso tras reanudar dio 2,64 frente a 2,38 con una reanudación completa. Mi ejecución se recuperó en 150 pasos hasta quedar a 0,007 de la reanudación completa, de modo que a esta escala el estado no valía casi nada. La razón para guardarlo está en el transitorio, y no he probado una tasa lo bastante grande como para que resultara fatal.

Dimensiona la máquina con 16 bytes por parámetro, sin contar las activaciones. En fp32, pesos, gradientes y las dos medias de AdamW ocupan cuatro bytes por parámetro cada uno, así que si dimensionas solo por los pesos te quedas corto en tres cuartas partes. La precisión mixta no rebaja la suma: pesos y gradientes de 2 bytes, más una copia maestra de 4 bytes y las dos medias, siguen sumando 16 bytes. En ese caso, si dimensionas solo por los pesos, te quedas corto en siete octavos.

Haz el barrido de la tasa en un modelo pequeño y fija una regla para abortar. El modelo pequeño te da la forma, pero el valor no se transfiere, porque la mejor tasa baja a medida que crece el modelo, salvo que uses algo como μP. Como nada lanza una excepción, la regla tiene que ponerla tú. La mía saltaba cuando la pérdida llegaba al doble de su mejor valor, y lo hizo en cuatro de las 21 ejecuciones. Tres eran de 0,1; la cuarta siguió adelante y terminó bien. Una regla tan barata matará de vez en cuando una ejecución buena, y ese es el precio de pillar las malas en los diez primeros pasos.

Esto tampoco es trabajo de modelado. Son cinco líneas de aritmética, un schedule de ocho líneas y un fichero de configuración que nada valida. Entre mi mejor ejecución y la peor hubo 1,3 nats con el mismo modelo, los mismos datos y la misma semilla, y lo único que cambiaba eran tres números de la configuración.

Parte 9 de 12. Adam da a cada peso su propio tamaño de paso a partir de sus gradientes recientes, y por eso un factor constante en la pérdida se cancela y el primer paso mide exactamente la tasa de aprendizaje. El warmup y el decaimiento coseno caben en ocho líneas y el weight decay desacoplado en una. Nada de eso se comprueba al arrancar, y a escala pequeña el fallo es una ejecución que deja de mejorar sin hacer ruido. La siguiente parte trata de lo que pasa cuando partes de pesos que ha entrenado otro. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas, la atención, el bloque, GPT-2 y sus dos programas, lo que cambió Llama y el origen de los gradientes.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Pérdida y gradientes sin fórmulas: la retropropagación es recorrer un grafo

Carlos Chinchilla Corbacho — Tue, 20 Oct 2026 00:00:00 GMT

La parte 7 acabó con cuatro cambios en un bloque, cada uno grabado en los pesos, y todos esos pesos se aprendieron. Esta parte cuenta cómo: hace falta un único número que diga cuánto se equivoca el modelo y, para cada peso, saber hacia dónde moverlo para que ese número baje. Esa dirección, peso a peso, es el gradiente.

He leído el engine.py de micrograd y lo he contrastado con torch. micrograd, que Andrej Karpathy escribió para enseñar diferenciación automática, hace todo el trabajo con números sueltos en 94 líneas. Después he entrenado un modelo pequeño de cinco maneras, cuatro de ellas mal, y ninguna de las malas ha dado error.

La pérdida es la sorpresa media

Un modelo de lenguaje devuelve una probabilidad para cada token del vocabulario. La pérdida (la entropía cruzada) solo se fija en el token que venía a continuación en el texto y toma el logaritmo de su probabilidad cambiado de signo. Si el modelo le da probabilidad 1, cuesta 0; si le da un 1 %, cuesta 4,6. A ese coste lo llamo sorpresa, y se mide en nats porque el logaritmo es en base e, que vale unos 2,718.

He pasado 1024 tokens de una entrada anterior por GPT-2 small y la sorpresa media ha salido 3,595 (el 3,60 que daba la parte 5). Si elevas e a esa potencia sale 36, es decir, de media el modelo dudaba tanto como si eligiera al azar entre 36 tokens. Una predicción uniforme entre 50 257 tokens da 10,8.

La media esconde una distribución asimétrica, con una forma que conoce bien quien haya vigilado alguna vez una latencia p99. El token mediano costó 2,85 y la peor décima parte de los tokens se llevó el 28 % de la pérdida. Los más sorprendentes eran nombres: " Claude" después de «renaming the assistants alone drops» costó 16,0. Entre los que menos sorprendieron estaban los trozos de una URL, como «org» después de «arxiv.», que costó una diezmilésima de nat.

Al entrenar, esa sorpresa se promedia sobre todas las posiciones de todas las secuencias de un batch hasta quedar en un solo número. Todo lo que sigue trata de cómo volver desde ese número hasta los pesos.

La pasada hacia delante construye un grafo

micrograd envuelve cada número en un Value que recuerda de dónde viene. Así es la multiplicación, condensada de engine.py:24-33.

def __mul__(self, other):
    out = Value(self.data * other.data, (self, other), '*')
    def _backward():
        self.grad += other.data * out.grad    # d(out)/d(self) is other
        other.grad += self.data * out.grad    # d(out)/d(other) is self
    out._backward = _backward
    return out

Cada operación hace dos cosas: calcula su resultado y deja tras de sí un nodo que conoce sus entradas y un closure que conoce su propia derivada local. La pasada hacia delante calcula una respuesta y, como efecto secundario, construye un grafo. Si alguna vez has escrito un tracer que registra cada llamada enlazada a las llamadas que le dieron sus datos, ya tienes hecha la mitad.

Una expresión pequeña, relu(a·b + c)·a, construye 7 nodos, y una red de 41 parámetros evaluada con cuatro ejemplos, 394. torch hace lo mismo con tensores. Cada nodo guarda lo que vaya a necesitar en la pasada hacia atrás. En GPT-2 small, una secuencia de 1024 tokens deja unos 820 MB de tensores guardados, más que los 498 MB que ocupan los pesos del modelo. Con un batch de ocho son 6,5 GB.

La pasada hacia atrás desanda el grafo

Value.backward, condensado de engine.py:54-70, es todo el algoritmo.

topo, visited = [], set()
def build_topo(v):                     # depth-first: children before parents
    if v not in visited:
        visited.add(v)
        for child in v._prev:
            build_topo(child)
        topo.append(v)
build_topo(self)
self.grad = 1
for v in reversed(topo):               # the output first, the inputs last
    v._backward()

Hace una ordenación topológica y luego recorre la lista al revés. Ese orden garantiza que cada nodo haya reunido todas sus contribuciones antes de transmitir nada. El closure de cada nodo coge el gradiente que le ha llegado, lo multiplica por su derivada local y suma el resultado a sus entradas. Eso es la regla de la cadena hecha bucle, y no hay nada más. Si has escrito un sistema de build que recorre un grafo de dependencias, esto es el mismo recorrido hacia atrás: ningún paso se ejecuta hasta que todos los que dependen de él han entregado su parte.

Figura interactiva: El grafo que construye micrograd para relu(a·b + c)·a con a = 2, b = −3 y c = 10. Recorre la pasada hacia atrás paso a paso: cada nodo muestra su valor y el gradiente que tiene hasta ese momento. Ábrela en el artículo para usarla.

Recorre la pasada hacia atrás nodo a nodo y después cambia a grad = para ver cómo a pierde una de sus dos contribuciones.

Todo depende de ese +=. En la expresión de arriba a se usa dos veces, así que le llega gradiente desde dos nodos. Con += recibe −2, que es lo que da torch; con =, la segunda escritura machaca la primera y a se queda con −6. No salta ningún error y el número, sencillamente, está mal. En la red de 41 parámetros, los gradientes de micrograd y los de torch se diferenciaron como mucho en 0,000007.

torch acumula igual, en el .grad de cada peso, hasta que algo lo pone a cero. nanoGPT, el GPT-2 mínimo que esta serie viene leyendo, usa esa acumulación a propósito. En train.py:292-305 procesa 40 batches pequeños en una GPU, divide cada pérdida entre 40 y llama 40 veces a backward sobre los mismos buffers antes de hacer una sola actualización. Luego optimizer.zero_grad, en train.py:314, los vacía.

Con cadenas largas, el gradiente se desvanece o explota

En cualquier camino de la pérdida a un peso, la regla de la cadena multiplica entre sí las derivadas locales, una por nodo. Las redes profundas tienen caminos largos. El producto de muchos números un poco por debajo de 1 es diminuto, y el de muchos un poco por encima, enorme. Eso es, en pura aritmética, el desvanecimiento y la explosión del gradiente, y para verlo no hace falta saber cálculo.

He montado pilas de capas tanh de 256 de ancho y sin conexión residual; tanh aplasta cualquier valor al intervalo entre −1 y 1. Lo único que cambiaba de una pila a otra era cuánto escalaba cada capa su entrada. Con una escala de 0,5 y 30 capas, el gradiente que llegaba a la primera era 7 × 10⁻⁹ veces el de la última, y con 60 capas, unas 10⁻¹⁷ veces. Con una escala de 2 y 60 capas, la primera recibía unas 7700 veces más.

El flujo residual de la parte 5, el bus del que lee cada bloque y al que suma su resultado, resuelve la mitad del problema, la del desvanecimiento. Si cada capa es residual, x + layer(x), todas tienen un camino directo de vuelta a la pérdida. En las mismas pilas, la primera capa no recibió nunca menos gradiente que la última, aunque con 60 capas y escala 2 seguía recibiendo 992 veces más. GPT-2 small está construido así, y al medirlo con una secuencia ningún bloque recibió un gradiente raquítico ni desbocado.

Figura interactiva: Cuánto gradiente recibe cada una de las capas tanh de la pila, en relación con la última y en escala logarítmica. Elige una profundidad y un tipo de pila y luego arrastra el control para cambiar cuánto escala cada capa su entrada. Ábrela en el artículo para usarla.

Elige 60 capas, pon la escala en 0,5 y verás cómo se desvanece el gradiente de la pila simple. Si después pasas a la residual, con 0,5 no se desvanece nada y con 2 la primera capa sigue recibiendo unas mil veces más.

Para eso está el recorte del gradiente. clip_grad_norm_ mide la longitud del gradiente entero, con todos los pesos a la vez, y si pasa de un límite lo reduce todo en la misma proporción. nanoGPT pone el límite en 1,0 (train.py:63) y, en mi secuencia, el gradiente de GPT-2 small medía 9,76. Casi todo estaba en la tabla de tokens, que GPT-2 reutiliza como capa de salida, y el lado de la entrada se llevó 0,14. Una vez recortado medía 1,0. El recorte acorta el gradiente, pero nunca cambia su dirección.

La precisión trae su propio desvanecimiento. fp16, el formato de coma flotante de 16 bits, no puede representar un número positivo por debajo de unos 6 × 10⁻⁸, y en ese formato el 9,3 % de los valores del gradiente de GPT-2 se redondeaba a cero. Con bf16, un formato de 16 bits que conserva el rango de fp32, no se perdió ninguno.

Para fp16, el arreglo es multiplicar por un factor grande antes de la pasada hacia atrás. Cuando entrena en fp16, nanoGPT activa un GradScaler (train.py:196) cuyo factor empieza en 65 536. En mis gradientes, ese factor rescató todos menos 1743 de esos 11,6 millones de valores y empujó 11 de los más grandes por encima de 65 504, el techo de fp16. Por eso el GradScaler vuelve a dividir por el factor antes de la actualización y, cuando algo desborda, se salta esa actualización y divide el factor entre dos.

Bugs sin stack trace

En la mayoría de los programas, un bug detiene la ejecución en una línea concreta. Un gradiente equivocado no detiene nada y se limita a entrenar un modelo ligeramente distinto. He entrenado con el texto de este blog un modelo de caracteres de cuatro bloques, un GPT pequeño que lee un carácter por token. Han sido cinco ejecuciones de 1000 pasos, una correcta y cuatro con un bug distinto cada una, y todas las he puntuado con texto que el modelo no vio durante el entrenamiento. Adivinar letras solo por su frecuencia da 3,25 y la ejecución correcta ha llegado a 1,74.

Dos de los bugs se vieron en la curva. Sin zero_grad, los gradientes se fueron amontonando de un paso a otro. La pérdida bajó a 3,37 en el paso 50 y después subió hasta un 7,37 que ya era peor que una predicción uniforme entre 106 caracteres. Con los objetivos sin desplazar, al modelo se le pedía el carácter que acababa de recibir, con lo que la pérdida de entrenamiento bajó a 0,001 mientras la predicción real del carácter siguiente daba 10,7.

Los otros dos no se vieron. Con la pérdida multiplicada por 40, el bug que aparece si olvidas la división de nanoGPT, el modelo quedó tan bien como el correcto, con 1,735. AdamW, el optimizador de nanoGPT, reescala el paso de cada peso, así que un factor constante se cancela (la parte 9 explica por qué). La tabla de posiciones desconectada del grafo, a la que por eso nunca llegó gradiente, no aprendió nada y se quedó en 1,95 (un 12 % peor) con una curva que parece normal.

Para ser justos con lo que puede decir una curva, dos de los cuatro bugs los habría visto cualquiera que mirase la pérdida de entrenamiento, uno de ellos porque la pérdida salía demasiado buena. Los otros dos dejaron una curva que aceptarías, así que quien solo registra la pérdida caza la mitad.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y ninguno exige saber cálculo.

Registra la norma del gradiente por bloque. Es lo más parecido a un stack trace que tiene un entrenamiento. Ahí se ve un pico, un bloque atascado cerca de cero o un total que sube poco a poco a lo largo de miles de pasos. La tabla de posiciones desconectada habría salido con gradiente cero desde el primer paso. Registra la norma antes del recorte (clip_grad_norm_ devuelve el total sin recortar), porque después el total nunca pasa del límite y el pico de cada bloque queda reducido con él.

Evalúa con una tarea en la que la pérdida de entrenamiento no pueda hacer trampa. La ejecución con los objetivos sin desplazar fue la que tuvo la mejor pérdida de entrenamiento de las cinco. Calcula una puntuación sobre texto de test, el que el modelo nunca ve al entrenar, con código que no comparta el camino de datos del bucle de entrenamiento, para que un mismo bug no pueda esconderse en ambos.

Ten claro qué bugs te esconde el optimizador. Con AdamW, multiplicar la pérdida por 40 no cambió nada. Con SGD a secas, el mismo bug equivale a una tasa de aprendizaje 40 veces más alta de la cuenta. Comprueba el escalado de la pérdida directamente, con un batch y un gradiente conocido.

Calcula la memoria de las activaciones, además de la de los pesos. GPT-2 small guarda unos 820 MB por cada secuencia de 1024 tokens para la pasada hacia atrás. Con el checkpointing de activaciones, que recalcula cada bloque durante esa pasada para no tener que guardar sus tensores, un batch de ocho pasó de 6,5 GB a 2,0 GB, a cambio de un 17 % más de tiempo en la CPU de mi portátil. La mayor parte de lo que queda son 1,65 GB de log-probabilidades, una por cada uno de los 50 257 tokens en cada posición.

Esto tampoco es trabajo de modelado. La retropropagación es una ordenación y un bucle sobre closures, y cada uno de los bugs de arriba es un error de contabilidad dentro de ese bucle o a su alrededor. Como no puede fallar haciendo ruido, el ruido lo tiene que hacer el registro.

Parte 8 de 12. La pérdida es la sorpresa media ante el token correcto. La pasada hacia delante construye un grafo de operaciones y guarda lo que va a necesitar cada una, y la pasada hacia atrás lo desanda multiplicando derivadas locales y sumándolas a las entradas. Los productos largos se desvanecen o explotan salvo que el bus dé a cada capa un camino directo, y los bugs de esa contabilidad entrenan en silencio sin que nada se caiga. La siguiente parte cuenta qué hace el optimizador con el gradiente. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas, la atención, el bloque, GPT-2 y sus dos programas y lo que cambió Llama.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

De GPT-2 a Llama: cuatro cambios y el motivo de cada uno

Carlos Chinchilla Corbacho — Tue, 13 Oct 2026 00:00:00 GMT

La parte 6 acababa con las cinco decisiones de GPT-2 y el bucle que lo sirve. Si abres un modelo de esta década, el bloque sigue siendo el de la parte 5, con dos etapas que leen cada una su copia normalizada del bus y le suman el resultado. Por dentro, eso sí, han cambiado cuatro cosas.

He leído modeling_llama.py de transformers 5.17 comparándolo con el model.py de nanoGPT y he cargado SmolLM2-135M, un modelo con la arquitectura de Llama y el tamaño de GPT-2 small. Después he ido deshaciendo cada cambio sobre sus pesos entrenados y midiendo qué se rompía.

El mismo bloque, cuatro retoques

Resumido, LlamaDecoderLayer.forward (modeling_llama.py:305-323) queda así:

residual = hidden_states
hidden_states = self.input_layernorm(hidden_states)            # RMSNorm, not LayerNorm
hidden_states, _ = self.self_attn(hidden_states, position_embeddings=...)
hidden_states = residual + hidden_states                       # the bus, as in GPT-2
residual = hidden_states
hidden_states = self.mlp(self.post_attention_layernorm(hidden_states))
hidden_states = residual + hidden_states

Son las mismas cuatro líneas de la parte 5, solo que con más nombres. Las sumas siguen donde estaban, y también el pre-LN, es decir, la norma que se aplica antes de cada etapa y no después. Lo que ha cambiado está dentro de las llamadas: cómo entran las posiciones en la atención, qué calcula la norma, qué forma tiene la red feed-forward y cuántas keys y values guarda la atención. (Llama, además, quita los vectores de sesgo de sus proyecciones lineales, aunque nada de lo que viene después depende de ellos.)

La comparación entre los dos modelos es justa. GPT-2 small tiene 124 millones de parámetros repartidos en 12 bloques de anchura 768, y SmolLM2-135M, 135 millones en 30 bloques de anchura 576. Ninguno de los cuatro cambios tiene que ver con el tamaño, así que podrías construir cualquiera de los dos modelos con ellos o sin ellos.

Las posiciones pasan a ser una rotación

GPT-2 suma a cada token una fila aprendida, distinta para cada posición, y la tabla se acaba en 1024. Llama no tiene tabla de posiciones, y lo que hace es girar la query y la key (modeling_llama.py:158-159).

q_embed = (q * cos) + (rotate_half(q) * sin)
k_embed = (k * cos) + (rotate_half(k) * sin)

Es el embedding posicional rotatorio, RoPE. Como se vio en la parte 4, la atención puntúa un par de tokens comparando un vector query con un vector key. Cada query y cada key se divide en cabezas de 64 números, y el vector de cada cabeza se lee como 32 pares. Cada par es un punto sobre una circunferencia y gira, como la aguja de un reloj, un ángulo proporcional a la posición. rotate_half es la manera que tiene el código de escribir ese giro sin una matriz. Las velocidades son distintas para cada par y todas salen de un solo número de la configuración, la base de rotación, que en SmolLM2 vale 100 000. Con esa base, el par más rápido da una vuelta cada 6,3 posiciones y el más lento, una cada 438 000.

La rotación no está de adorno. Si giras una query según la posición m y una key según la posición n, su producto escalar (la puntuación de la parte 4) depende solo de m − n. He pasado una query y una key aleatorias por la rotación de SmolLM2. La puntuación ha dado −13,4724 en las posiciones 10 y 3, y −13,4723 en 1010 y 1003. Con una posición menos de distancia, en 10 y 4, ha dado −10,786.

El modelo entero hereda esa propiedad. He sumado 500 a todos los ids de posición de un texto de 512 tokens, y después 5000. La pérdida de SmolLM2 sobre ese texto (su sorpresa media ante el token siguiente) ha sido de 3,381 sin desplazar y de 3,381 tras cada desplazamiento. A GPT-2, el mismo desplazamiento de 500 lo ha llevado de 3,85 a 8,97 porque cada token pasa a leer otra fila de su tabla. Al quitar la rotación del todo, con todas las posiciones a 0, SmolLM2 ha pasado de 3,12 a 6,28 en el texto completo de 1024 tokens. Y bajar la base de rotación de los 100 000 de SmolLM2 a 10 000, el valor del artículo original de RoPE y de Llama 2, ha costado un 3 %.

Figura interactiva: Un par de números de una query y el mismo par de una key, cada uno girado según su posición. Elige dónde están la query y la key y luego desplaza las dos lo mismo. La puntuación es lo que aporta este par al producto escalar, con flechas de longitud 1. Ábrela en el artículo para usarla.

Arrastra la posición de la key para ver cómo cambia la puntuación, y después desplaza las dos para comprobar que no se mueve. Si eliges el par 17, el más lento de los tres, las posiciones cercanas apenas se distinguen. Aquí la puntuación es solo lo que aporta un par, y va de −1 a 1.

Y sin tabla tampoco hay última fila. La configuración de Llama 3.1 8B registra una longitud original de 8192 posiciones y un máximo de 131 072; el modelo llega hasta ahí estirando la rotación. Sus cabezas tienen 128 números, o sea, 64 pares. Los 29 más lentos giran 8 veces más despacio, los 29 más rápidos se quedan igual y los seis intermedios mezclan los dos tratamientos. Meta, además, preentrenó la familia con longitudes crecientes hasta 128K, en seis etapas en el caso del modelo de 405B. No hay ningún assert que salte: pasada la longitud con la que se entrenó un modelo, la calidad hay que medirla, porque nada la garantiza.

La norma deja de centrar

LayerNorm resta a cada fila su media, la divide por su desviación típica y después la escala y la desplaza. LlamaRMSNorm, en modeling_llama.py:62-67, se salta la media y el desplazamiento y divide por la media cuadrática (RMS), que se calcula elevando al cuadrado cada número, promediando y sacando la raíz. Si alguna vez has estandarizado una columna de un dataframe, has restado y has dividido; RMSNorm se queda solo con la división.

variance = hidden_states.pow(2).mean(-1, keepdim=True)
hidden_states = hidden_states * torch.rsqrt(variance + self.variance_epsilon)
return self.weight * hidden_states.to(input_dtype)

RMSNorm apuesta a que la media es pequeña de por sí, y en SmolLM2 lo es. En una capa de norma típica, la media de una fila típica es el 2 % de su media cuadrática, y en la peor capa, el 4,5 %. Si vuelves a poner la LayerNorm completa con la misma escala aprendida, la pérdida sube menos de un 2 %, de 3,124 a 3,175.

Para ser justos con el argumento a su favor, hay que ponerlo a prueba. El artículo de RMSNorm la vende como más barata porque se ahorra el desplazamiento y calcula una estadística donde LayerNorm calcula dos. En la CPU de mi portátil, el F.layer_norm de torch ha tardado entre 50 y 75 microsegundos sobre un tensor [1, 1024, 576], según la ejecución, y F.rms_norm, entre 110 y 135. El profiler dice por qué: en CPU, rms_norm sigue ejecutándose como una cadena de operaciones pequeñas (cuadrado, media, suma, raíz y dos multiplicaciones), mientras que layer_norm es un único kernel optimizado, una sola rutina compilada que hace todo el trabajo.

Con un solo hilo, en cambio, layer_norm ha tardado unos 155 microsegundos y rms_norm, unos 130, así que el orden se invierte. Menos aritmética no se traduce en menos tiempo hasta que alguien escriba el kernel, y en GPU no he medido.

La red feed-forward gana una puerta

La red feed-forward de GPT-2 tiene dos matrices con una GELU en medio, y la de Llama, tres (modeling_llama.py:175).

down_proj = self.down_proj(self.act_fn(self.gate_proj(x)) * self.up_proj(x))

La entrada pasa por dos proyecciones en paralelo. Una de ellas atraviesa SiLU, una activación suave parecida a GELU, y después multiplica a la otra elemento a elemento. Esa multiplicación hace de puerta. La combinación se llama SwiGLU y viene de un artículo de 2020 que la probó y publicó mejores resultados sin ofrecer ninguna teoría que los explicara.

Con la misma anchura, tres matrices cuestan más que dos, así que la anchura se reduce. Si d es la anchura del modelo, una red feed-forward convencional de anchura 4d tiene 8d² números sin contar los sesgos. Tres matrices de anchura f tienen 3·d·f, y las dos cuentas coinciden con f = 8d/3. SmolLM2 usa exactamente esa anchura (1536 son 8/3 de 576), y los 11 008 de Llama 2 7B salen de redondear 8/3 de 4096 al múltiplo de 256 superior.

Con 8d/3, la puerta no altera el presupuesto: con cabezas de atención completas la red feed-forward sigue ocupando dos tercios del bloque. El 75 % de SmolLM2 se debe a que comparte keys y values entre cabezas de query, y de eso trata la sección siguiente. Llama 3.1 8B mueve el reparto por los dos lados, con una red feed-forward más ancha, f = 3.5d, y una atención más pequeña porque comparte keys y values. Las dos cosas juntas dan el 81 % que citaba la parte 5 (176 de los 218 millones de parámetros de cada bloque). Solo con la red más ancha y cabezas de atención completas, sale el 72 %.

La puerta importa. Si en SmolLM2 cambias SiLU por GELU, la pérdida pasa de 3,12 a 3,79. Si quitas del todo la multiplicación de la puerta, sube hasta 17,7 y supera con mucho los 10,8 de un modelo que reparte la probabilidad por igual entre los 49 152 tokens.

Es también en la red feed-forward donde entra la mezcla de expertos, con muchas redes feed-forward por bloque y un router, una capa pequeña que elige unas pocas para cada token. Llama 3 siguió siendo denso, a diferencia de Llama 4 y de otras familias.

Se comparten keys y values

GPT-2 tiene tantas cabezas de key y de value como de query. SmolLM2 tiene 9 cabezas de query y 3 cabezas key-value, y cada cabeza key-value sirve a un grupo de tres queries. Es como un índice que atiende tres consultas, con los mismos datos y preguntas distintas. En PyTorch puro, repeat_kv (modeling_llama.py:179-189) copia las tres cabezas de key y value hasta tener nueve antes de hacer las cuentas; el kernel de atención fusionado de torch puede ahorrarse la copia cuando no hay máscara de padding. A esto se le llama grouped-query attention, GQA. Llama 2 solo la usaba en sus dos tamaños más grandes, el de 70B y uno de 34B que no llegó a publicarse, y en Llama 3 la llevan todos los tamaños.

En inferencia, compartir cabezas no es ninguna aproximación. He construido una copia de SmolLM2 con nueve cabezas completas de key y value, en la que cada cabeza repite la de su grupo, y he ejecutado los dos modelos. Los logits han coincidido hasta el último bit, y la copia tiene 147,8 millones de parámetros frente a 134,5. Lo que GQA sacrifica lo sacrifica en el entrenamiento, porque hay menos keys y values distintos que aprender.

Donde se ahorra es en la caché de la parte 6. SmolLM2 guarda 11 520 números por token (la cifra la he sacado de la propia caché de transformers después de 256 tokens), y con cabezas completas guardaría 34 560. GPT-2 small, con 12 bloques frente a los 30 de SmolLM2, guarda 18 432.

Con el tamaño de Llama 3.1 8B, esa proporción decide qué cabe. El modelo tiene 32 cabezas de query y 8 cabezas key-value, así que cada token cuesta 131 KB en bf16, el formato de 16 bits de la parte 3. Con el máximo de 131 072 posiciones, la caché de una sola secuencia ocupa 17,2 GB, frente a los 16,1 GB de los pesos, y con cabezas completas serían 68,7 GB.

Figura interactiva: Las dimensiones de GPT-2 small con los cambios de Llama activados de uno en uno. Activa o desactiva un cambio, o arrastra las cabezas key-value, y mira cómo quedan los parámetros, la parte del bloque que ocupa la red feed-forward, la caché y el límite de posiciones. Ábrela en el artículo para usarla.

Empieza por GPT-2 small y activa los tres cambios de uno en uno. Verás que la parte que ocupa la red feed-forward apenas se mueve. Después baja las cabezas key-value hasta 1 y fíjate en la caché y en esa parte.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y ninguno necesita una GPU.

Recalcula la caché para cada modelo. El número de parámetros no sirve para predecirla, porque la caché son 2 × bloques × cabezas key-value × anchura de cabeza números por token y las cabezas key-value son un campo de la configuración. SmolLM2 es más grande que GPT-2 small y aun así guarda tres octavos menos por token.

Porta la arquitectura antes que los pesos. Cada uno de los cambios anteriores forma parte del contrato con el que se entrenaron los pesos. La activación, el esquema de posiciones con su base de rotación y su escalado, y el número de cabezas key-value son campos de la configuración. El tipo de norma, en cambio, viene con el nombre de la arquitectura. Si te equivocas en el número de cabezas, la carga falla porque las formas no encajan. Si aciertas el número pero te equivocas en la agrupación (repites la serie entera de cabezas compartidas cuando había que repetir cada una varias veces seguidas), no salta ninguna excepción, pero la pérdida ha subido por encima de 11. Lo demás falla con el mismo silencio. Una LayerNorm sin sesgo donde iba RMSNorm ha costado un 1,6 %, GELU donde iba SiLU, un 21 %, y la base de rotación equivocada, un 3 %. Con los pares de rotación formados por números contiguos, cuando el código los forma por mitades, la pérdida ha llegado a 7,24. Si portas un modelo a mano, compara tus logits con los de una implementación de referencia antes de fiarte de él.

Prueba las longitudes a las que sirves el modelo. La rotación quita el límite fijo, pero la pregunta sigue en pie. Si usas un modelo más allá de la longitud con la que se entrenó, te toca a ti medir cómo se comporta ahí, con tus propios datos.

Cuenta aparte los parámetros activos. Con mezcla de expertos, Qwen3-30B-A3B tiene 30 500 millones de parámetros, usa 3350 millones por token y el 95 % de los pesos son expertos. La memoria depende de la primera cifra y la aritmética por token, de la segunda, y pagas las dos.

Esto tampoco es trabajo de modelado. Un bloque de Llama es un bloque de GPT-2 con cuatro piezas cambiadas. Cada cambio es una línea de configuración o de código que puedes leer y cuyo coste puedes calcular, y cualquier desajuste se puede detectar con un test antes de servir la primera petición.

Parte 7 de 12. Llama conserva el bloque y el bus de GPT-2 y cambia cuatro piezas: las posiciones pasan a ser una rotación de queries y keys, la norma prescinde de la media, la red feed-forward gana una puerta y las cabezas de query comparten keys y values. Si te equivocas con la norma, la activación o las posiciones, no salta ningún error, y lo que cambia es la pérdida. Las posiciones rotatorias eliminan una tabla y compartir keys y values reduce la caché, mientras que la puerta, con 8d/3, no cuesta nada. La siguiente parte se pregunta de dónde salen los pesos. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas, la atención, el bloque y GPT-2 y sus dos programas.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

GPT-2 es el transformer más cinco decisiones, y la inferencia es otro programa

Carlos Chinchilla Corbacho — Tue, 06 Oct 2026 00:00:00 GMT

La parte 5 terminó con un bloque y una pila de doce. GPT-2 es esa pila con cinco decisiones alrededor, y el mismo checkpoint ejecuta dos programas distintos. El entrenamiento puntúa una secuencia entera en una sola llamada. La generación (lo que al servir el modelo se llama inferencia) escribe los tokens de uno en uno, en un bucle, y de ahí sale la mayoría de los fallos en producción.

He vuelto a cargar los pesos de GPT-2 small de OpenAI en el model.py de nanoGPT y he ejecutado con ellos los dos programas. Después he añadido una caché al bucle, he pasado los pesos a bf16 y he comparado lo que salía.

Cinco decisiones alrededor de la pila

GPTConfig, en model.py:108-116, cabe en una pantalla: 1024 posiciones, 12 bloques, 12 cabezas y anchura 768. El campo del vocabulario vale 50 304 porque, según el comentario de esa línea, se rellena hasta un múltiplo de 64 para ganar velocidad. El checkpoint de OpenAI tiene 50 257 filas, y al cargarlo la configuración se ajusta a él. Alrededor de esos números GPT-2 tomó cinco decisiones, y tres de ellas ya han salido en esta serie.

El tokenizador es el BPE sobre bytes de la parte 1; como codifica cualquier cadena, no existe el token desconocido. La normalización es pre-LN, como en la parte 5. En model.py:138 la tabla de tokens se comparte con la capa de salida. Así, una sola matriz, la tabla que en el recuento de la parte 5 era el 31 % del modelo, sirve para los dos extremos. Con dos matrices separadas, GPT-2 small tendría 163 millones de parámetros, frente a los 124 millones que tiene.

La cuarta decisión son las posiciones, que GPT-2 aprende. wpe es una tabla de forma [1024, 768], con una fila por posición que se suma a la del token antes del primer bloque. Y como toda tabla tiene una última fila, si le pides a forward 1100 posiciones, el assert de model.py:173 te para:

AssertionError: Cannot forward sequence of length 1100, block size is only 1024

La quinta es la inicialización. Cada bloque escribe dos veces en el bus (el nombre que la parte 5 da al flujo residual), con lo que una pila de L bloques acumula 2L escrituras. En nanoGPT todas las matrices, incluidas las tablas de tokens y de posiciones, arrancan con valores aleatorios de desviación típica 0,02 (el código de OpenAI usaba 0,01 para la de posiciones). Los sesgos empiezan en cero, y LayerNorm, en uno. model.py:143-145, en cambio, inicializa con 0.02/√(2L) las dos capas que hacen esas escrituras, para que la suma no crezca con la profundidad. Lo he medido en modelos sin entrenar. Con la inicialización escalada, la norma del flujo se ha multiplicado más o menos por 11 tanto a lo largo de 12 bloques como de 48. Con la inicialización sin escalar, se ha multiplicado por 55 y por 112. A partir de ahí, el entrenamiento hace el resto.

El entrenamiento es una sola llamada

Si le das a forward una secuencia y sus objetivos (la misma secuencia desplazada una posición), predice todas las posiciones a la vez. Le he pasado 92 posiciones de texto y ha devuelto logits de forma [1, 92, 50257], es decir, puntuaciones en bruto para cada token en cada posición, que la softmax convierte en probabilidades. También ha devuelto una sola pérdida, la entropía cruzada de model.py:187, que es menos el logaritmo de la probabilidad asignada al siguiente token correcto, promediado sobre las 92. La máscara de la parte 4 es la que impide hacer trampa, porque la fila t solo ve las filas 0..t y así ninguna predicción puede leer su propia respuesta.

Ese programa se ejecuta en cada paso del entrenamiento, durante cientos de miles de pasos. Como todas las posiciones se conocen de antemano, atraviesan la pila juntas, en unas pocas multiplicaciones de matrices grandes. Si alguna vez has escrito un proceso por lotes sobre una tabla, ya sabes cómo es este programa. En la CPU de mi portátil, una pasada hacia delante sobre 1024 posiciones ha tardado 0,23 segundos.

Sin objetivos, forward toma un atajo en model.py:190 y calcula los logits solo de la última posición. En esa línea asoma por primera vez el segundo programa.

La generación es un bucle

Para escribir texto, el modelo tiene que ver cada token antes de poder predecir el siguiente, y entre posiciones no queda nada que ejecutar en paralelo. Este es, resumido, el generate de nanoGPT en model.py:312-328:

for _ in range(max_new_tokens):
    idx_cond = idx[:, -1024:]                 # crop to the position table
    logits, _ = self(idx_cond)                # the whole sequence, again
    logits = logits[:, -1, :] / temperature   # [B, 50257], last position only
    probs = F.softmax(logits, dim=-1)         # top_k masking skipped here
    idx_next = torch.multinomial(probs, 1)    # draw one token id
    idx = torch.cat((idx, idx_next), dim=1)   # append it and go round

Mira otra vez la línea self(idx_cond). En cada paso, el bucle repite entera la pasada hacia delante sobre la secuencia acumulada hasta entonces y se queda con una sola fila. Si alguna vez has releído un fichero entero para añadirle una línea, ya has escrito este bucle. Con un prompt de 11 tokens, generar 256 tokens nuevos hace pasar 35 456 posiciones por la pila para sacar 256 filas útiles.

La solución es una caché KV. En la parte 4, cada posición recibió un vector key, con el que se comparan las queries posteriores, y un vector value, que es lo que esas queries promedian. Con la máscara de la parte 4, los vectores key y value de la posición t dependen solo de las posiciones 0..t, por lo que, una vez calculados, no vuelven a cambiar. Si los guardas (un par de tensores por bloque), en cada paso basta con pasar el token nuevo por la pila y calcular su atención sobre las filas guardadas. Para los mismos 256 tokens, eso son 266 posiciones. A cambio se paga en memoria, unos 74 kB por posición en GPT-2 small con fp32. Como nanoGPT no trae caché, he escrito una propia, de unas treinta líneas, que reutiliza sus módulos.

El cronómetro lo confirma, aunque no en la misma proporción. Al generar 64, 256 y 512 tokens sin la caché, por la pila han pasado 37, 133 y 261 veces más posiciones, pero el tiempo se ha multiplicado por 2,9, por 5,0 y por 7,4. Con batch 1, cada paso sigue teniendo que leer los 124 millones de pesos para producir un token, y ese coste la caché no lo reduce. Escribir 1023 tokens con la caché ha llevado 9,3 segundos, unas cuarenta veces lo que tarda la pasada hacia delante del entrenamiento sobre la misma longitud.

La caché se rompe además en el límite que impone la cuarta decisión. Pasados los 1024 tokens, generate recorta la secuencia por la izquierda. A partir del segundo bloque, todos los vectores key y value guardados se calcularon cuando el token descartado aún estaba en la secuencia, y como las posiciones son aprendidas, cada token pasa también a otra fila de wpe. La caché entera queda obsoleta. El bucle de nanoGPT se libra porque de todas formas lo recalcula todo, pero un bucle con caché tiene que resolverlo.

Figura interactiva: Un checkpoint de GPT-2 que genera texto, con caché KV y sin ella. Elige un tamaño y un dtype, y luego ajusta el prompt, los tokens nuevos y el batch. Los recuentos son posiciones que pasan por la pila, y las barras comparan la caché con los pesos. Ábrela en el artículo para usarla.

Mueve el deslizador de tokens nuevos y verás cómo se separan los dos recuentos. Después elige XL en bf16 y sube el batch hasta que la barra de la caché supere a la de los pesos.

Mismos pesos, bugs distintos

Dos programas que usan los mismos pesos deberían coincidir, y los míos han coincidido, o casi. En 200 pasos de decodificación voraz (greedy), en los que se toma siempre el token con la puntuación más alta, los dos bucles han escrito el mismo texto, aunque sus logits han llegado a diferir en 0,011. Casi toda esa diferencia era un desplazamiento común a todos los tokens, que la softmax ignora. La distancia entre los dos mejores candidatos ha variado como mucho 0,00005, y como en ningún paso ha bajado de 0,004, los tokens han aguantado. Una ejecución más larga o un modelo más grande pueden comerse ese margen, y cuando pase no saltará ningún error.

La diferencia viene de la coma flotante. Pasado el prompt, cada multiplicación de matrices dentro de los bloques del bucle con caché trabaja con una sola fila, mientras que sin caché ve la secuencia entera. Por eso la biblioteca elige otros kernels (las rutinas que hacen las cuentas), que suman en otro orden. Como la suma en coma flotante no es asociativa, los resultados difieren en los últimos bits.

Cambiemos ahora algo que en un despliegue se toca a menudo. He pasado los mismos pesos a bf16, el formato de 16 bits de la parte 3, y he vuelto a ejecutar el bucle de decodificación voraz. El modelo en fp32 ha continuado el prompt con " were not working." y el de bf16 con " were not being run on the same system". Se han separado en el tercer token y ya no han vuelto a juntarse. Al ejecutar el prompt ocho veces en un mismo batch, los tokens se han mantenido, pero los logits se han desplazado hasta 0,005 respecto a la ejecución con un solo prompt.

El remedio al que suele recurrir la gente es poner la temperatura a 0. No lo arregla, y en nanoGPT el 0 ni siquiera es un valor válido. generate divide los logits entre la temperatura. Con 0, los 50 257 logits se vuelven infinitos, la softmax los convierte en NaN (el valor de coma flotante para un resultado indefinido) y torch.multinomial lanza una excepción. La mayoría de las API que aceptan el 0 lo usan como interruptor para pasar a argmax, que elige la puntuación más alta. Eso vuelve a ser decodificación voraz, y solo es tan determinista como lo sean los pesos, el dtype, la forma del batch y los kernels que tenga debajo.

Para ser justos con la magnitud del problema, todas las ejecuciones que aparecen aquí han sido repetibles; con la misma semilla en la misma máquina, el muestreo ha sacado dos veces los mismos 40 tokens. La deriva aparece cuando cambia algo por debajo, y en la infraestructura que sirve el modelo esas cosas cambian sin consultarte.

El muestreo es una política por encima del modelo

La decodificación voraz es una elección, y GPT-2 small enseña por qué se suele evitar: antes de llegar a 200 tokens, el bucle de arriba ya repetía su propia frase. El muestreo, en cambio, sortea el token según la distribución, y tres ajustes dan forma a esa distribución antes del sorteo.

La temperatura divide los logits antes de la softmax, de modo que por debajo de 1 concentra la distribución y por encima de 1 la aplana. Top-k se queda con los k tokens de puntuación más alta y descarta el resto; top-p, también llamado muestreo de núcleo (nucleus sampling), conserva el conjunto más pequeño cuyas probabilidades suman al menos p. El sample.py de nanoGPT trae por defecto temperatura 0,8 y top-k 200, y no tiene top-p.

El efecto de estos ajustes depende del prompt. Tras «The capital of France is», el candidato favorito de GPT-2 small es " the", con un 8,5 %, y " Paris" queda quinto, con un 3,2 %. A temperatura 1, hacen falta 1504 tokens para cubrir el 90 % de la probabilidad. Tras «import numpy as», en cambio, " np" se lleva él solo el 85 %, y para llegar al 90 % bastan tres. La entropía, medida en bits, le pone número a esa dispersión. Para el prompt de la capital a temperatura 1 vale 8,7 bits, tanta incertidumbre como elegir al azar entre unos 400 tokens igual de probables. Para el de numpy vale 1,5 bits, el equivalente a unos tres.

Top-k no distingue un caso del otro, de ahí que cualquier k que elijas falle en uno de los dos. Con los valores por defecto de nanoGPT, esos 200 tokens reúnen el 89 % de la masa tras el prompt de la capital, y tras el de numpy conservan 199 opciones que se reparten menos del 5 %. Top-p sí se adapta, y con la misma temperatura y p = 0.9 conserva 237 tokens en un caso y uno solo en el otro.

Figura interactiva: Probabilidades que GPT-2 small asigna al siguiente token en tres prompts, medidas una sola vez. Los prompts y los tokens van en inglés porque son literales: lo que ha leído el modelo y los candidatos que ha puntuado. Elige un prompt y mueve la temperatura y el umbral de top-p; las filas que quedan fuera del corte de top-p se ponen en gris. Ábrela en el artículo para usarla.

Con los valores iniciales, temperatura 1 y p = 0.9, el prompt de la capital conserva 1504 tokens y el de numpy, tres. Sube la temperatura a 2 y verás cómo crece el recuento de numpy. Los indicadores de top-40 y top-200 muestran lo que conserva un k fijo.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y el primero es un test.

Compara en un test el bucle con caché y la pasada completa, logits incluidos. Ejecuta los dos programas durante unos cientos de pasos y compara los tokens de la decodificación voraz y, con una tolerancia, los logits. Si solo compruebas que los tokens coinciden, el test puede pasar mientras los logits derivan, como en mi caso.

Incluye la caché en el presupuesto de memoria, igual que los pesos. Por cada secuencia guarda 2·L·T·d números, con L bloques, T posiciones y anchura d: un vector key y otro value por cada bloque y posición. En GPT-2 small, con 1024 posiciones en fp32, son 75 MB. En GPT-2 XL con bf16 son 315 MB por secuencia, así que unas diez secuencias de longitud completa pesan tanto como sus 3,1 GB de pesos. Subir el tamaño de batch es una decisión de throughput y también de memoria.

Fija lo que comparas. Cualquier cambio de dtype, de forma del batch, de versión de la biblioteca o de kernel altera los logits. Si tu test de regresión compara salidas del modelo, fija los cuatro, o compara con una tolerancia y registra lo que ha cambiado.

Registra los ajustes de muestreo con cada salida. La temperatura, top-k, top-p y la semilla forman parte del programa. Dos ejecuciones que solo se diferencian en ellos se comportan de forma distinta, y una salida registrada sin ellos no se puede reproducir.

Esto tampoco es trabajo de modelado. Los pesos son un único artefacto, y es el código que los rodea el que decide si una posición se puntúa o se escribe, qué sobrevive entre pasos y cómo una distribución se convierte en un token. Todo eso es código corriente que puedes probar.

Parte 6 de 12. GPT-2 es la pila de la parte 5 más cinco decisiones: BPE sobre bytes, pre-LN, una tabla de tokens compartida con la capa de salida, posiciones aprendidas y una inicialización escalada para las escrituras en el bus. El entrenamiento ejecuta una sola pasada hacia delante, en paralelo, sobre todas las posiciones, y la generación, un bucle que necesita una caché, una política de muestreo y sus propios tests. La siguiente parte cuenta lo que cambió Llama. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas, la atención y el bloque.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Un bloque de transformer son seis tensores y un bus: léelo como un pipeline

Carlos Chinchilla Corbacho — Tue, 29 Sep 2026 00:00:00 GMT

La parte 4 se quedó en una sola etapa, pero un decodificador es una pila de bloques (doce en GPT-2 small) y la atención es una de las dos etapas de cada uno. Aquí leo un bloque entero como se lee un pipeline: qué entra, qué escribe cada etapa y adónde van a parar los parámetros y el coste. Ya te adelanto que no van al mismo sitio.

He leído Block en el model.py de nanoGPT con las formas anotadas al margen y le he cargado los pesos de GPT-2. Luego lo he roto a propósito, primero quitando los bloques de uno en uno y después haciendo que cada uno sobrescribiera su entrada sin sumarle nada.

El bloque son cuatro líneas

nanoGPT es un GPT-2 mínimo repartido en dos ficheros. Su README remite ahora a un sucesor, pero model.py sigue siendo la manera más corta de leer un bloque de GPT-2 sin trampas. Block.forward está en model.py:103-106.

def forward(self, x):                   # x: [B, T, 768], the stream
    x = x + self.attn(self.ln_1(x))     # read a normalised copy, add attention's output
    x = x + self.mlp(self.ln_2(x))      # read again, add the feed-forward's output
    return x                            # [B, T, 768]: the shape it came in with

Dentro de esas dos llamadas, en model.py:52-92, hay seis tensores que merece la pena nombrar. El código de abajo está condensado, sin escalado, máscara ni dropout, y las formas del margen salen de ejecutar un modelo con las dimensiones de GPT-2 small, d = 768 y 12 cabezas.

qkv = self.attn.c_attn(self.ln_1(x))         # [B, T, 2304]    q, k, v side by side
q, k, v = qkv.split(768, dim=2)              # three views, [B, T, 768] each
q = q.view(B, T, 12, 64).transpose(1, 2)     # [B, 12, T, 64]  12 heads of 64; k, v alike
att = (q @ k.transpose(-2, -1)).softmax(-1)  # [B, 12, T, T]   Part 4's square
y = (att @ v).transpose(1, 2).reshape(B, T, 768)
y = self.attn.c_proj(y)                      # [B, T, 768]     attention out
x = x + y                                    # [B, T, 768]     the stream, attention added
h = F.gelu(self.mlp.c_fc(self.ln_2(x)))      # [B, T, 3072]    the feed-forward's hidden layer
out = self.mlp.c_proj(h)                     # [B, T, 768]     feed-forward out

Contando el propio flujo, el bloque son x, las proyecciones, las puntuaciones, la salida de la atención, la capa oculta y la salida de la red feed-forward. Tres de esos tensores comparten la forma del flujo. Todo lo demás que aparece en el código es una vista, un paso elemento a elemento o la disposición por cabeza [B, 12, T, 64].

Conviene detenerse en cómo se reparten el trabajo las etapas. La atención es la única que mezcla posiciones (la fila t de su salida se construye con las filas 0..t del flujo), mientras que LayerNorm y la red feed-forward trabajan posición a posición.

LayerNorm resta a cada fila de 768 números su media, la divide por su desviación típica y después aplica una escala y un desplazamiento aprendidos. En model.py:27, todo eso cabe en una sola llamada a F.layer_norm. La red feed-forward ensancha cada fila a 3072, aplica GELU (una versión suave de max(0, x)) y la vuelve a estrechar. Si has escrito un map sobre filas, ya has escrito el flujo de control de la red feed-forward.

Figura interactiva: Un bloque tal como lo escribe model.py, con las dimensiones de GPT-2 small. El flujo baja por la línea vertical. Cada rama lee una copia normalizada y suma su salida al flujo. El coste de las puntuaciones es el de la ruta eager, que las guarda en memoria; los kernels fusionados de sdpa no las guardan. Elige un tensor y después arrastra los tamaños. Ábrela en el artículo para usarla.

Elige la capa oculta de la red feed-forward y mira sus parámetros. Luego elige las puntuaciones, que no tienen ninguno. Ahora arrastra T y fíjate en el término de atención, las puntuaciones y la suma ponderada. Los parámetros no se mueven, pero la aritmética sí.

La arquitectura está en el signo más

Si vuelves a leer las dos líneas, verás que ninguna etapa sustituye a x. Cada una lee una copia normalizada y le suma al original lo que ha calculado, así que el flujo sale del bloque con dos retoques encima y el bloque siguiente lee el resultado.

Ese flujo, [B, T, 768] desde el embedding hasta el último bloque, es lo que la literatura llama flujo residual y lo que aquí llamo el bus. Todas las etapas lo leen y escriben en él, pero no es de ninguna. Si alguna vez has escrito total += delta en un bucle, ya conoces el contrato: cada etapa suma al total acumulado sin poder sobrescribirlo, y para deshacer una escritura anterior hace falta que una etapa posterior la sume con el signo cambiado.

Las cifras confirman que el contrato se cumple. He pasado 1024 tokens de una entrada anterior por GPT-2 small y he medido longitudes (la norma de cada vector), tomando la mediana de todas las posiciones. En los bloques 1 a 10, cada etapa suma un vector de entre el 16 % y el 40 % de la longitud del flujo que lee. El flujo sale apuntando casi adonde apuntaba al entrar: la similitud coseno (1 significa la misma dirección) va de 0,93 a 0,97. Por el camino la norma también crece, de 49 tras el bloque 0 a 480 al final. El bus en sí no se normaliza nunca. Cada etapa normaliza su propia copia y ln_f normaliza una vez más antes de que la capa de salida convierta la última fila en logits, las puntuaciones del token siguiente.

Normalizar fuera del bus fue una decisión. Llamemos pre-LN al orden de GPT-2, que normaliza dentro de la rama, x + attn(ln(x)), y deja el bus como está. El transformer original y GPT-1 eran post-LN y normalizaban después de la suma, x = ln(x + attn(x)), con lo que reescalaban el propio bus en cada etapa. El artículo de GPT-2 deja constancia del cambio en una sola frase, la misma que añade ln_f, y cita un precedente, pero no da ninguna razón propia.

Un experimento pequeño muestra una. He entrenado dos modelos de seis bloques con el texto de este blog, carácter a carácter, con la misma configuración y sin warmup (el warmup consiste en arrancar con un tamaño de paso pequeño e ir subiéndolo). La pérdida mide la sorpresa media del modelo ante cada token siguiente. Cuanto más baja, mejor, y 0 significaría acertar siempre y con total seguridad.

Tras 300 pasos, el modelo pre-LN llega a unos 2,4 y queda por debajo del 2,56 de un modelo que solo conoce la letra anterior. El post-LN se atasca en 3,2 (más o menos lo que dan por sí solas las frecuencias de las letras) y, en una semilla que he alargado hasta los 600 pasos, sigue ahí. Con un warmup de 100 pasos se desatasca entre los pasos 200 y 250. Es un experimento de juguete, con dos semillas y pérdidas leídas de los batches de entrenamiento, pero el resultado va en la línea del análisis publicado sobre por qué post-LN necesita warmup.

Vuelvo a GPT-2 small, esta vez para quitarle bloques. Sobre esos 1024 tokens, el modelo intacto da una pérdida de 3,59. Si quitas cualquiera de los bloques 1 a 10 y dejas que el flujo pase de largo, la pérdida queda entre 3,61 y 3,89; si quitas el bloque 0, salta a 9,15.

Sobrescribir es peor que quitar. Si conservas el bloque pero haces que su salida sustituya al flujo sin sumarse a él, la pérdida queda por encima de 9,6 en los bloques 1 a 8, y en los bloques 2 a 7 supera el 10,8 de una predicción uniforme sobre todo el vocabulario. El modelo acaba peor que si adivinara a ciegas.

Figura interactiva: Cada barra es la pérdida de GPT-2 small con uno de sus doce bloques cambiado, medida sobre 1024 tokens de una entrada anterior de este blog (cuanto más baja, mejor). Alterna entre quitar el bloque y hacer que sobrescriba el flujo, y después elige uno. Ábrela en el artículo para usarla.

Cambia a sobrescribir y verás cómo los bloques 2 a 7 cruzan la línea de puntos. Después elige el bloque 0.

El bloque 0 es la excepción, y la norma de los vectores explica por qué. El embedding entra con una norma de 4,6 y la atención del bloque 0 escribe un vector siete veces más largo. Tras el bloque 0, el flujo es sobre todo la salida de ese bloque, así que se comporta más como un segundo embedding que como un retoque. Sobrescribir ahí no cuesta nada (3,59), porque sumar ya equivalía a sustituir.

Dos tercios de los pesos

Los parámetros de un bloque se pueden contar a mano, con d = 768 y la anchura de la red feed-forward f = 4d. Las dos proyecciones de la atención tienen 4d² + 4d (2 362 368 números); las dos de la red feed-forward, 2·d·f + f + d, que da 8d² + 5d (4 722 432), y las dos LayerNorm, 3072. En todos los tamaños de GPT-2 la red feed-forward se lleva dos tercios de cada bloque, porque esa proporción la fija el 4 * config.n_embd de model.py:82, sea cual sea la anchura. Llama 3.1 8B cambia las dos etapas y su red feed-forward tiene el 81 % de un bloque; en la parte 7 veremos por qué.

Los doce bloques suman 85 millones de parámetros, y GPT-2 small tiene 124 439 808. Casi todo el resto es la tabla de tokens, con 38,6 millones de números, el 31 % del modelo. Se usa dos veces, abajo del todo como la consulta de la parte 2 y arriba del todo como la proyección a logits. En model.py:138 queda compartida con la capa de salida (el mismo array, sin copia). En GPT-2 XL esa misma tabla se queda en el 5,2 % del modelo. Los modelos pequeños gastan casi un tercio de sus pesos en el vocabulario, y los grandes apenas lo notan.

El coste está en otra parte

En un programa corriente, el tamaño de una función y su tiempo de ejecución salen del mismo código, pero aquí van por separado: los parámetros están sobre todo en la red feed-forward, y la aritmética crece con T.

Una pasada hacia delante cuesta unas dos operaciones por token, una multiplicación y una suma, por cada número de una matriz de pesos (la parte 4 las contaba como FLOPs). Si llamamos N a la cantidad de esos números, los parámetros cuestan 2N por token. A eso hay que sumarle el término de atención, 4·L·T·d (donde L es el número de bloques), que cubre las puntuaciones y la suma ponderada sobre el cuadrado completo. En GPT-2 small con 1024 tokens salen 247 millones de operaciones por token de los parámetros y 38 millones de la atención. El FlopCounterMode de torch coincide cuando la atención va escrita en sus cuatro líneas, por la ruta eager de la parte 4, y da 284,8 millones por token, justo la cifra de la fórmula (285,1 si N es el get_num_params() de nanoGPT, que cuenta también los sesgos y las LayerNorm).

Con sdpa, la opción por defecto, el mismo contador daba 247 millones tanto con 256 tokens como con 1024. En torch 2.14, la versión que he usado, el contador no tiene entrada para el kernel de atención fusionado de CPU, la única rutina a la que llama sdpa para sustituir esas cuatro líneas. Por eso el término de atención no llega nunca al total, y nada te avisa. La rama principal de PyTorch ya registra ese kernel (PR #195801), de modo que la próxima versión menor también debería contar el término de atención con sdpa.

Dentro de un bloque, el término de atención es el 18 % de la aritmética con 1024 tokens y adelanta a las capas lineales a los 4608 tokens, seis veces d. Los tiempos lo confirman. En la CPU de mi portátil, la etapa de atención de un bloque, proyecciones incluidas, se lleva el 38 % del tiempo con 256 tokens, el 47 % con 1024 y el 57 % con 4096, aunque tiene un tercio de los parámetros del bloque.

Para ser justos con el reparto, en las longitudes para las que se diseñó GPT-2 son las capas lineales las que hacen la mayor parte de la aritmética, y dentro de ellas la red feed-forward se lleva más de la mitad. El término de atención solo toma el relevo pasada una longitud que GPT-2 no admite. Aun así, al elegir un modelo eliges dos presupuestos. Los parámetros fijan la memoria y no cambian desde que lo cargas; el contexto, que llega con cada petición, marca el coste y una parte creciente de la memoria.

Qué vigila el ingeniero de ML

Son cuatro hábitos, y los dos primeros son de aritmética.

Cuenta los parámetros por componente, sin quedarte en el total. El primer gráfico hace esa cuenta para un bloque, con 4d² para la atención y 2·d·f para la red feed-forward. Para la tabla, suma una sola vez el producto del vocabulario por d. Si comparas un modelo de 124 millones de parámetros con uno de 1500 millones, pregúntate cuánto de cada uno es vocabulario.

Estima el coste en 2N por token y en 6N para entrenar. Entrenar es una pasada hacia delante y otra hacia atrás, y la de atrás, que calcula los gradientes, cuesta lo que unas dos hacia delante. Eso da 6N por token y 6·N·D para una ejecución de D tokens. La configuración de nanoGPT para GPT-2, config/train_gpt2.py, procesa 491 520 tokens por iteración durante 600 000 iteraciones, 295 000 millones de tokens en total. Con eso, 6·N·D da 2,2 × 10²⁰ operaciones, que son 195 horas de una A100 a su pico en bf16, o un día de un nodo de ocho GPU. El fichero dice que cuentes con unos cinco días y el README habla de cuatro, lo que deja la ejecución entre una quinta y una cuarta parte del pico. El estimador del propio nanoGPT añade el término de atención (model.py:296), que con 1024 tokens supone otro 15 %.

La profundidad es latencia. Reparte de cuatro maneras los mismos 85 millones de parámetros de los bloques, en 6 bloques de anchura 1088, 12 de 768, 24 de 544 o 48 de 384. Con batch 1, un token tarda 3,2 ms, 4,0 ms, 4,7 ms y 6,7 ms en atravesar la pila en mi CPU. Cada bloque añade un sobrecoste fijo y los bloques se ejecutan uno detrás de otro. Si sirves las peticiones de una en una, lo que esperas lo marca la profundidad, aunque la aritmética sea la misma.

Mide un bloque antes de quitarlo. La poda de capas (desplegar el modelo con menos bloques) y la salida temprana (pararse en un bloque intermedio cuando la respuesta parece decidida) se apoyan en el bus, y el bus no es uniforme. Quitar un bloque intermedio de GPT-2 small sube la pérdida entre un 0,5 % y un 8 %, pero quitar el bloque 0 la sube un 155 %, y quitar el último, un 41 %. Las cifras de arriba me han llevado un minuto en un portátil, con texto de este blog; las tuyas, sácalas de tu propio tráfico.

Esto tampoco es trabajo de modelado. Un bloque son cuatro líneas alrededor de una suma, y es la suma lo que permite que una pila de doce se comporte como un solo pipeline. Dónde están los pesos y adónde se va el tiempo son preguntas con respuestas distintas, y las dos se resuelven con cuentas que puedes hacer antes de cargar nada.

Parte 5 de 12. Un bloque lee el flujo en dos etapas, la atención y una red feed-forward, y le vuelve a sumar los dos resultados. Gracias al signo más, quitar un bloque intermedio sube la pérdida en un pequeño porcentaje y el modelo sigue en pie. La red feed-forward tiene dos tercios de los pesos de cada bloque, y la parte de la aritmética que se lleva el término de atención crece con el contexto. La parte siguiente recorre las cinco decisiones que tomó GPT-2 alrededor de la pila. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token, las formas y la etapa en torno a la que se construye este bloque.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

La atención es una media ponderada aprendida y su coste está en el cuadrado

Carlos Chinchilla Corbacho — Tue, 22 Sep 2026 00:00:00 GMT

La parte 3 acababa en un cuadrado. En un bloque de decodificador hay dos tensores con T dos veces en la forma, [B, H, T, T], es decir, un cuadrado T × T por cabeza, con H cabezas y B secuencias. Con los valores por defecto del gráfico de aquella parte, suponían el 89 % de la memoria del bloque. En esta leo lo que los llena, que es una media ponderada. La media en sí no tiene nada de especial. Lo nuevo es que los pesos se calculan a partir de la entrada.

He escrito la atención en cuatro líneas y la he contrastado con F.scaled_dot_product_attention, la implementación del propio torch. Luego he leído LlamaAttention.forward con las formas anotadas al margen y he calculado cuánto cuesta en Llama 3.1 8B con las longitudes de contexto que se prometen.

Un diccionario que coincide en parte

Buscar en un diccionario es una operación exacta: la clave coincide o no coincide, y obtienes un único valor. La atención hace lo mismo con una coincidencia difusa. Todas las claves coinciden un poco y obtienes la media de todos los valores, ponderada por lo bien que ha coincidido cada clave.

Esas ponderaciones son los pesos de atención. No son parámetros ni se guardan en ningún sitio, porque el modelo los calcula a partir de la entrada en cada llamada. Hasta llegar a la sección del coste, cuando diga «pesos» me referiré a estos. Tres matrices aprendidas convierten cada fila de la entrada en una query, una key y un value. La query se compara con todas las keys y las puntuaciones resultantes se convierten en pesos:

q, k, v = x @ Wq, x @ Wk, x @ Wv             # [B, T, d] each
scores = q @ k.transpose(-1, -2) / sqrt(d)  # [B, T, T]
weights = scores.softmax(-1)                # every row sums to 1
out = weights @ v                           # [B, T, d]

Fíjate en las formas. x es el [B, T, d] de la parte 3 y las tres proyecciones lo conservan. scores es [B, T, T], un número por cada par de posiciones, y ahí está el cuadrado. La softmax convierte cada fila en pesos que suman uno, con los que la última línea calcula la media. Estas cuatro líneas dan lo mismo que F.scaled_dot_product_attention con una tolerancia de 1e-5.

Que sea una media tiene dos consecuencias. La primera, que cada coordenada de la salida queda entre el menor y el mayor de los values en esa coordenada, así que la atención nunca se sale de ese rango. La segunda, que si cambias una fila de la softmax por una fila one-hot (un solo 1 y ceros en el resto), la salida es exactamente el value de esa posición. El diccionario difuso contiene el exacto como caso límite.

Por qué la raíz cuadrada

La división por sqrt(d) parece un detalle, pero de ella depende que el modelo aprenda desde el primer paso o arranque saturado. El motivo es una cuenta que puedes comprobar en una consola.

El producto escalar de dos vectores aleatorios de anchura d con componentes de varianza 1 tiene varianza d. Lo he medido con d = 4096 y sale 4104. Si metes puntuaciones tan dispersas en una softmax, se satura: un peso se va casi a 1 y los demás, casi a 0. Con 1024 keys, el peso más grande de cada fila ha salido de media 0,976 y la fila se ha quedado en 0,09 bits de entropía de los 10 posibles. Eso es una búsqueda exacta disfrazada de difusa, y en plena inicialización. Un modelo entrenado también acaba afilando las filas, pero lo hace a propósito y desde un punto de partida del que puede aprender. Al dividir por sqrt(d), la varianza queda en 1,0 y la fila sube a 9,27 bits de entropía, con el peso más grande en 0,017. Con la pérdida calculada a partir de la media ponderada, el gradiente medio que llega a las puntuaciones es alrededor de un orden de magnitud mayor, entre 12 y 18 veces según la semilla. Si la pérdida se calcula a partir de un solo peso, el factor oscila entre unas pocas veces y muchos órdenes de magnitud, según las filas en las que le toque ganar a esa key. Una softmax saturada apenas tiene de qué aprender, porque su gradiente queda por debajo de 1e-6 en el 99,8 % de las puntuaciones y lo poco que hay se amontona en los contados casi empates.

Llama lo escribe una sola vez, self.scaling = self.head_dim**-0.5, en modeling_llama.py:226. Ahí la anchura que cuenta es la de la cabeza, sin que intervenga la del modelo.

Las cabezas son una vista y la máscara, un triángulo

La atención multicabeza consiste en ejecutar las cuatro líneas de arriba una vez por cabeza, H veces, sobre trozos de d. Trocear no cuesta nada: q.view(B, T, H, d // H).transpose(1, 2) da [B, H, T, d/H] y comparte memoria con q, porque el eje de las cabezas es solo un stride. Las puntuaciones pasan a ser [B, H, T, T], un cuadrado por cabeza. La cabeza 0 de la llamada en batch da lo mismo que la atención calculada solo sobre la cabeza 0. Lo que se gana con las cabezas son H juegos de pesos distintos sobre las mismas posiciones, cada uno en un trozo de anchura d/H (128 en Llama 3.1 8B, con 32 cabezas).

Es la máscara la que hace que un decodificador deje de promediar sobre todas las posiciones. Para predecir el token que sigue a la posición t, el modelo puede leer las posiciones 0..t y nada posterior, así que las puntuaciones por encima de la diagonal se ponen a -inf antes de la softmax y sus pesos quedan a cero. Lo he comprobado de la forma más directa, calculando la atención sobre ocho posiciones y reescribiendo luego las keys y los values de las posiciones 5 a 7. Las posiciones 0 a 4 han devuelto la misma salida con una tolerancia de 1e-6, mientras que sin la máscara han cambiado las ocho.

Figura interactiva: La matriz de puntuaciones de una cabeza con T = 12. Cada fila es una query y cada columna, una key; una celda encendida es una puntuación que llegará a la softmax. Elige una máscara y mira cuántas celdas quedan vivas. Ábrela en el artículo para usarla.

Prueba las tres máscaras y mira el recuento. El tercer botón, el de la ventana, es la última palanca de la sección del coste. El triángulo se combina por suma con la máscara de padding de la parte 3. Si añades dos posiciones de padding a la izquierda de una secuencia, las dos primeras filas de query quedan enteras a -inf. En la softmax, una fila toda de -inf es 0/0, o sea, un NaN. Es la misma trampa de la parte anterior, ahora en la versión de cuatro líneas. La biblioteca transformers, en cambio, rellena su máscara eager con el mínimo del dtype (masking_utils.py:602-604) y esas filas salen uniformes. Así no dan error, pero siguen sin significar nada.

La ruta eager calcula las exponenciales y su suma en fp32 sea cual sea el dtype del modelo (dtype=torch.float32, en modeling_llama.py:208), y después vuelve a convertir la fila a ese dtype. Sumar el normalizador con los ocho bits significativos de bf16 sería ahorrar memoria donde no toca.

Lectura de `LlamaAttention.forward`

En transformers 5.17.0, modeling_llama.py:243-281 son esas cuatro líneas con las cabezas, la máscara y una caché, todo escrito por extenso. Abreviado y con las formas del modelo 8B, queda así:

query_states = self.q_proj(hidden_states).view(hidden_shape).transpose(1, 2)  # [B, 32, T, 128]
key_states   = self.k_proj(hidden_states).view(hidden_shape).transpose(1, 2)  # [B, 8, T, 128]
value_states = self.v_proj(hidden_states).view(hidden_shape).transpose(1, 2)  # [B, 8, T, 128]
query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin)
if past_key_values is not None:
    key_states, value_states = past_key_values.update(key_states, value_states, self.layer_idx)
attn_output, attn_weights = attention_interface(self, query_states, key_states, value_states,
                                                attention_mask, scaling=self.scaling)
attn_output = self.o_proj(attn_output.reshape(*input_shape, -1))

Ahí hay tres cosas que no están en las cuatro líneas. La primera, past_key_values.update, es la caché. Al generar se guardan las keys y los values de todos los tokens anteriores, así que cada token nuevo calcula una sola fila de query y lee T keys guardadas.

La segunda es que la key y el value tienen 8 cabezas y la query, 32, de ahí que k_proj proyecte de 4096 a 1024. Es lo que se llama grouped-query attention (GQA), frente a una cabeza key-value por cada cabeza de query (MHA). Su razón de ser es la caché. La tercera, attention_interface, elige qué implementación se ejecuta, con eager_attention_forward como respaldo, en modeling_llama.py:191-213. Eager quiere decir que las cuatro líneas se ejecutan tal como están escritas, más repeat_kv, que en tiempo de ejecución copia las 8 cabezas de key hasta tener 32 para que cuadre la multiplicación de matrices. Si pones _attn_implementation a sdpa, la scaled_dot_product_attention de la primera sección, o a flash_attention_2, las mismas operaciones las calcula otro kernel (la rutina que hace la aritmética). La línea que aplica la rotación queda para la parte 7.

El coste lo ponen los datos y el código no lo delata

En software, el coste de una función se lee en su código: un bucle sobre la entrada es lineal, dos bucles anidados son cuadráticos, y lo sabes antes de ejecutarla. La atención es una sola función, su código son las cuatro líneas y en ellas no hay ningún bucle. El cuadrado está dentro de un único @ y nada en la forma del código delata que sea cuadrático. Su coste lo fija la T de la petición y crece con el cuadrado de las posiciones, por cabeza y por capa.

Con la forma de Llama 3.1 8B y en bf16, las puntuaciones de una secuencia en una capa ocupan 268 MB con 2048 tokens, 4,3 GB con 8192 y 1,1 TB con los 131 072 que declara la configuración. En el pico de memoria, la ruta eager mantiene tres cuadrados así (dos de ellos en fp32), que suman unas cinco veces esos bytes. Los pesos del modelo entero ocupan 16 GB. Si nadie llega a materializar esos 1,1 TB, es por el kernel.

Figura interactiva: Cuánto cuesta la atención de Llama 3.1 8B (32 capas, 32 cabezas de anchura 128, bf16) según la longitud de contexto y el batch. Las puntuaciones de una capa son [B, H, T, T], y la caché guarda las keys y los values de todos los tokens anteriores en todas las capas. Los pesos, 16 GB, aparecen dibujados como referencia de escala. Ábrela en el artículo para usarla.

Si llevas T a 16k con eager seleccionado, las puntuaciones de una sola capa ya superan los pesos del modelo entero, y con 131k son unas setenta veces más grandes. Al cambiar a sdpa, la cifra aparece tachada porque esa memoria nunca llega a reservarse.

He cronometrado las tres últimas líneas, con 8 cabezas de anchura 64, en la CPU de mi portátil. De 512 a 8192 tokens (dieciséis veces más entrada), la versión eager ha pasado de 1,9 ms a 284 ms, 150 veces más. En una capa lineal sobre la misma entrada, el tiempo ha subido de 0,23 ms a 2,5 ms, once veces más. Al doblar T de 4096 a 8192, el tiempo de la capa lineal se ha multiplicado por 1,95 y el de la atención por 4,3. Salvo por el ruido de la medición, es lo que predice el cuadrado.

La primera de las tres palancas que mueven esa cifra es el kernel. Con su backend flash o con el memory-efficient, F.scaled_dot_product_attention calcula los mismos números por bloques y nunca guarda entera la matriz T × T, cosa que su backend de respaldo, math, sí hace. Con 4096 tokens y en fp32, el profiler ha imputado 545 MB a las multiplicaciones de matrices de la versión eager (el cuadrado de 537 MB más su salida) y 8,5 MB a sdpa, que además ha ido 2,4 veces más rápido.

Flash attention lleva esa misma idea a la GPU, con una aritmética que sigue siendo cuadrática. Lo que cambia es lo que tiene que estar en memoria a la vez. La implementación se elige con un único campo de la configuración, _attn_implementation, que en 5.17.0 vale sdpa por defecto al cargar; eager solo lo tienes si lo pides. Si el batch lleva padding, sdpa sigue guardando la propia máscara, booleanos [B, 1, T, T] que ocupan 17 MB con 4096. Sin padding, transformers no pasa ninguna máscara y deja que el kernel aplique el triángulo (is_causal=True).

Las otras dos cambian lo que se calcula. La grouped-query attention reduce la caché. Con 8 cabezas key-value, el modelo 8B guarda 131 kB por token entre sus 32 capas, 17 GB para un contexto de 128k, ya algo más que los pesos. Con 32 cabezas serían 524 kB por token y 69 GB, cuatro veces los pesos. Una ventana deslizante, por su parte, limita hasta dónde puede leer hacia atrás una query. Llama 3.1 no tiene ninguna, Mistral 7B v0.1 tenía una, y Gemma 2 y 3 intercalan capas con ventana y capas globales. En transformers se escribe kv_idx > q_idx - sliding_window (masking_utils.py:100). Con 32 768 tokens, una ventana de 4096 deja 126 millones de celdas vivas frente a los 537 millones del triángulo causal. Mientras la secuencia no supera la ventana, el coste es un triángulo; cuando la supera, es una banda de anchura W que crece de forma lineal con T.

Para ser justos con el cuadrado, si en la pasada del prompt cuentas operaciones y dejas los bytes a un lado, las capas lineales del modelo 8B hacen más operaciones que la atención hasta unos 30 000 tokens, y hasta más o menos el doble si solo tienes en cuenta el triángulo que calcula un kernel causal. Con 8192 tokens, la atención supone alrededor de una quinta parte de las operaciones en coma flotante del bloque (sus FLOPs) si cuentas el cuadrado entero, y alrededor de una octava parte si cuentas solo el triángulo.

Como el cuadrado es un problema de memoria mucho antes de convertirse en uno de cómputo, la cuenta que hay que hacer antes de prometer una longitud de contexto es la de memoria.

Qué vigila el ingeniero de ML

Son cuatro cosas, la primera de ellas una multiplicación.

Calcula lo que ocupan [B, H, T, T] y la caché antes de prometer un contexto. El gráfico de arriba hace esa multiplicación, cabezas por T al cuadrado por dos bytes en cada capa. Súmale la caché por token multiplicada por la secuencia más larga y por el batch con el que vas a servir el modelo. El max_position_embeddings de la configuración es lo que el modelo admite tras estirar su rotación (aquí 131 072, una ventana de preentrenamiento de 8192 escalada y luego entrenada hasta 128k). Lo que cabe en tu GPU es otra cuenta.

Ten claro qué kernel se ejecuta. eager devuelve los pesos y materializa el cuadrado; sdpa y flash, no. Se elige en _attn_implementation y de ese campo depende que existan o no los 545 MB de antes. Una herramienta de depuración que necesite los pesos no puede sacarlos de sdpa, donde output_attentions=True devuelve una tupla vacía. Si para tenerlos cargas el modelo con attn_implementation="eager", el cuadrado se materializa en cada llamada.

Combina las máscaras a conciencia. La causal, la de padding y la de ventana se unen con un AND, que en la forma -inf es una suma. Una fila de query a la que ya no le queda nada que leer da NaN en esa forma y una fila uniforme en la de la biblioteca. Ninguno de los dos es un número que te sirva. La costumbre de la parte 3 vale ahora por partida doble: el índice del último token sale de la máscara y la máscara viaja con el batch.

Mide la latencia con el prompt más largo que vayas a aceptar. El tiempo de las capas lineales crece con T; el de la atención, con su cuadrado, y el de la lectura de la caché en cada token generado, con todo lo que esta ya contiene. Un p99 medido con 500 tokens no dice nada de lo que pasa con 8000. El salto de antes, de 1,9 ms a 284 ms, da una idea de la sorpresa que te espera.

Esto tampoco es trabajo de modelado. Una media ponderada cabe en cuatro líneas y sus pesos salen de tres matrices aprendidas. El cuadrado en el que viven es el primer coste de la serie que depende de la entrada sin que el código tenga nada que decir.

Parte 4 de 12. La atención es una media ponderada cuyos pesos calcula el modelo a partir de su propia entrada. La media cabe en cuatro líneas; lo que cuesta es la matriz de pesos T × T, y el kernel decide si ese cuadrado llega a estar alguna vez en memoria. Como la atención es solo una de las etapas, la siguiente parte lee el bloque entero que la rodea, con seis tensores y un flujo residual al que cada etapa suma lo suyo. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token y la forma que las dos le pasan a esta.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Las formas son el sistema de tipos del ML, y nadie las comprueba por ti

Carlos Chinchilla Corbacho — Tue, 15 Sep 2026 00:00:00 GMT

La parte 2 se cerraba con una firma: un batch de secuencias de filas de embedding es un tensor de forma [B, T, d]. En todo este stack no hay nada más parecido a un tipo que esa línea, así que aquí la leo como se lee la firma de una función y luego enseño qué hace el runtime cuando la firma está mal. Lo habitual es que no haga nada.

He leído la regla de broadcasting tal como la escribe torch y después he escrito a propósito cuatro bugs de forma para ver cuáles detectaba el runtime. Solo ha detectado uno.

Una forma es una firma

Un tensor es un array de N dimensiones junto con una descripción de cómo está colocado en memoria. [B, T, d] dice que hay B secuencias en el batch, T posiciones en cada una y d números en cada posición. Léelo como si fuera f(batch: List[List[Vec]]), con una diferencia que importará más adelante, y es que el runtime solo mira los tamaños y los nombres le dan igual.

La descripción de la memoria es lo que un ingeniero de software ya conoce. Un tensor de forma [4, 8, 16] tiene strides (128, 16, 1), así que dar un paso por el primer eje supone saltarse 128 números. Si transpones los dos primeros ejes, la forma pasa a [8, 4, 16] y los strides a (16, 128, 1). Es la misma memoria leída en otro orden, y data_ptr no cambia. Por eso transpose sale gratis, un view que aplane el resultado se niega y lo dice en el mensaje de error, y reshape copia cuando no le queda otro remedio. Un tensor es un puntero, una forma y una tupla de strides. Las operaciones de vista que vas a usar son aritmética sobre las dos últimas.

Cada operación tiene también su propia firma de formas, que dice qué entra, qué sale y qué eje desaparece. mean(dim=1) sobre [B, T, d] devuelve [B, d], ya sin la T. Una capa lineal lleva [B, T, d] a [B, T, d_out] y solo cambia el último eje. Escribir la firma al lado de la llamada es la disciplina de la que trata esta entrada, y si no la escribes tú, no la va a escribir nadie.

La regla cabe en cinco líneas

Dos tensores de formas distintas se pueden sumar igualmente, y cómo se suman lo decide una regla llamada broadcasting. torch tiene una copia legible en Python, torch.broadcast_shapes, que llama a _broadcast_shapes en torch/_refs/__init__.py (líneas 388 a 470 en la v2.13.0). Quitando la maquinaria de formas simbólicas, la regla queda así:

common_shape = [1] * reduce(max, (len(shape) for shape in shapes))
for arg_idx, shape in enumerate(shapes):
    for idx in range(-1, -1 - len(shape), -1):          # align from the right
        if common_shape[idx] == 1:
            common_shape[idx] = shape[idx]              # 1 stretches to anything
        if shape[idx] == 1:
            continue                                    # ... in either direction
        torch._check(common_shape[idx] == shape[idx],   # otherwise sizes must match
            lambda: f"Attempting to broadcast a dimension of length {shape[idx]} at {idx}!")
return common_shape

Las formas se alinean por la derecha, un tamaño 1 se estira hasta igualar al otro, los tamaños iguales pasan y cualquier otra combinación lanza un error. No hay más. En modo eager, la misma regla se ejecuta en C++ y falla con un mensaje más corto, que es el que muestra la demo de abajo. La regla existe para que puedas sumar un sesgo de forma [d] a [B, T, d] sin bucles ni copias.

El resto de la entrada gira en torno a una propiedad de la regla: decide por el tamaño y es ciega al significado. [8, 16] + [16] funciona porque 16 es igual a 16, y [8, 16] + [8] lanza un error porque 8 no es 16 ni es 1. La regla no tiene ni idea de si el 16 de la derecha es una longitud de secuencia, una dimensión oculta o un batch, y cuando ese eje sea el equivocado, tú tampoco lo sabrás. Y si dos ejes coinciden en tamaño por casualidad, la regla no tiene manera de distinguirlos. El científico de datos lleva años apoyándose en ella con numpy, y el ingeniero de software se la encuentra como una regla de coerción sin tipos declarados, que es como deberían leerla los dos.

El bug que solo aparece con un batch de dieciséis

En el primer bug intervienen las puntuaciones de atención, de forma [B, T, T] (una matriz T × T por secuencia), y una máscara de padding de forma [B, T] que dice qué posiciones de cada secuencia son reales. En su versión aditiva (0 en las reales y -inf en el padding), basta con sumarla a las puntuaciones para apagar el padding. Lo correcto es scores + mask[:, None, :]. Con el None, la máscara pasa a ser [B, 1, T], se estira por el eje de las queries y enmascara las keys.

Ahora quita el None. Con B = 8 y T = 16, scores + mask lanza un error porque 16 no es 8, pero con B = 16 y T = 16 se ejecuta. Con B = 1 también se ejecuta y además acierta por casualidad, porque 1 es justo lo que habría insertado el None.

La regla alinea [16, 16] con [16, 16, 16] por la derecha y lee la máscara como [1, B, T], de modo que la máscara pensada para la secuencia b cae en la fila de query b de todas las secuencias. Con longitudes aleatorias he medido un tercio de las posiciones mal enmascaradas y una quinta parte del peso de atención sobre el padding. La softmax que viene detrás da valores finitos, la pérdida también y la ejecución sigue adelante. No salta ningún aviso, porque no hay nada de qué avisar. La regla se ha cumplido.

Figura interactiva: Puntuaciones de atención [B, T, T] más una máscara de padding. Arrastra los dos tamaños y elige la forma de la máscara. El veredicto es el de la regla de broadcasting de torch, y lo único que mira es si los tamaños coinciden. Ábrela en el artículo para usarla.

Mueve los dos tamaños hasta que coincidan y verás cómo el veredicto pasa de un error a un resultado silencioso. Después elige [B, T, 1], una máscara que se ejecuta con cualquier tamaño y siempre está mal, porque apaga las queries cuando debería apagar las keys. Esta sí se nota, ya que la fila de una query de padding es toda -inf y su softmax da NaN. En los tres casos la regla es la misma.

El segundo bug es el clásico: predicciones de forma [256] y valores objetivo de forma [256, 1] que se restan para calcular un error cuadrático. La regla estira los dos a [256, 256] y enfrenta cada predicción con cada objetivo. La media de todo eso sigue siendo un número, y con él se entrena.

Con este bug he entrenado una regresión lineal de una sola variable durante dos mil pasos. La pérdida ha bajado hasta estabilizarse en 9,7. La pendiente ajustada ha salido 0,000 y la ordenada en el origen igual a la media de los objetivos, con un R² de 0,0. El modelo ha aprendido a ignorar la entrada, que es lo mejor que puede hacer cuando la pérdida lo compara con los objetivos de todos los demás. La pérdida de la biblioteca, F.mse_loss, avisa de este desajuste. La escrita a mano, ((pred - target) ** 2).mean(), no avisa, y es la que acaba en los notebooks.

El tercer bug nunca da error en el sitio donde ocurre. Sobre un tensor de forma [16, 16, 64], tanto mean(dim=0) como mean(dim=1) devuelven [16, 64]. Los números son distintos, pero con la misma forma nada de lo que venga después puede notarlo. Sobre [3, 5, 7], esas mismas dos llamadas devuelven [5, 7] y [3, 7], y lo primero que intente combinarlas lanza un error. El bug estaba en los dos casos y solo los tamaños han decidido si se veía.

El cuarto hace de control. [3, 5, 7] más [3, 5] falla porque 7 no es 5, y si se ha detectado es por lo único que les faltaba a los otros tres, que los tamaños fueran distintos.

Para ser justos con la regla, hay que decir que hace lo que se le pide. Alternativa hay: un runtime que lleve los nombres de los ejes y se niegue a sumar T con B. torch publicó como prototipo los named tensors, que nunca pasaron de esa fase, y la 2.13 los ha eliminado para quitar sobrecarga y aligerar el código. Si no cuajaron fue en parte porque todas las bibliotecas del stack habrían tenido que ponerse de acuerdo en los nombres, y lo único que comparten todas son los tamaños. La regla es correcta, solo que no es una comprobación de tipos, y en todo el stack no hay nada que lo sea.

El padding es una decisión de forma

Las secuencias no vienen todas con la misma longitud. Tres secuencias de longitudes 5, 3 y 1 solo forman un tensor [3, 5] si se rellenan, y con esas longitudes el 40 % del tensor es padding. A partir de ahí, toda operación sobre T necesita saber qué celdas son reales, y ese dato es un segundo tensor, la máscara, que tiene que viajar con el primero.

El lado por el que se rellena forma parte de la firma. Con padding por la derecha, el último token real está en el índice length - 1, que para las tres de arriba es 4, 2 y 0. Con padding por la izquierda está en el 4 para las tres. Los decodificadores que generan token a token prefieren esta segunda opción, porque la posición que hay que leer es siempre la última. Las dos funcionan y el bug está en mezclarlas. El código pensado para padding por la derecha, si recibe un batch rellenado por la izquierda, lee padding, o el token equivocado, donde espera el último.

La máscara no es opcional ni siquiera cuando el modelo no usa atención. Si haces pooling de media de ese batch [3, 5] sin ella, el vector de la secuencia de longitud 1 promedia una fila real con cuatro de padding. Con arange(1, 31).reshape(3, 5, 2), la media de esa secuencia sin máscara es [25, 26], y con máscara es [21, 22], que es su única fila real. Por eso el código de pooling de la parte 2 divide por la suma de la máscara, y esa división es la firma puesta por escrito.

La memoria es forma por bytes

Lo que cuesta un tensor es pura aritmética. Unas activaciones de forma [32, 2048, 4096] son 268 millones de números, que ocupan 1,07 GB en fp32, 537 MB en bf16 y 268 MB en int8. Esa es la factura, y para calcularla no hace falta saber nada del modelo, basta con la forma y el ancho de un número. De esa cifra depende que un batch quepa o no en la tarjeta.

Figura interactiva: Los tensores más grandes de un bloque de decodificador para un batch, con las puntuaciones de atención guardadas como una matriz T × T completa. Cada cabeza mide 64 de ancho, así que hay d / 64 cabezas. Arrastra los tres tamaños y cambia el formato numérico: los bytes de cada fila son la forma por el ancho de un número, y los ids de token son int64 sea cual sea el formato. En int8 la cifra solo pone precio a la forma, porque en una ejecución real las puntuaciones y los pesos no se guardan en int8. Las dos últimas filas llevan T dos veces. Ábrela en el artículo para usarla.

Mueve los tres tamaños y cambia el formato. Con los valores iniciales, un bloque cuesta 77 GB en fp32 y las dos filas de T × T suponen el 89 % del total, pero si bajas T a 128 se quedan en un tercio. De esas dos filas trata la parte siguiente.

Lo que sacrifica cada formato también es aritmética. Donde fp32 guarda 23 bits de mantisa, bf16 guarda 7 y conserva todo el exponente de fp32. Con esos 7 bits escribe π como 3,140625 y redondea 1 + 0.004 a 1.0078125, pero su rango es el de fp32 salvo por el último paso de redondeo. fp16 guarda 10 bits y solo cinco de exponente, así que no pasa de 65 504 y los gradientes pequeños se quedan en cero por underflow si antes no se escala la pérdida. De ahí que el entrenamiento se haya pasado a bf16 y que para servir el modelo se recurra a int8. Cada formato es una decisión sobre qué precisión no le hace falta a un tensor.

Al servir el modelo, el eje que controlas es el del batch, y mueve dos números en sentidos opuestos. He cronometrado en la CPU de mi portátil un matmul de [B, 4096] por [4096, 4096], que cuesta 447 µs por fila con B = 1 y 22 µs por fila con B = 512, es decir, veinte veces más throughput. La llamada en sí ha pasado de 0,45 ms a 11,4 ms, y cada petición ha esperado veinticinco veces más, sin contar lo que haya tardado en llenarse el batch. Con cinco repeticiones en un solo portátil, lo que vale es la proporción y los dígitos exactos importan poco. El batching dinámico es el ajuste que se mueve entre esos dos números, y dónde lo pongas es una decisión de producto disfrazada de forma de tensor.

Qué vigila el ingeniero de ML

Son cuatro hábitos, aunque los dos primeros son en realidad uno solo.

Anota las formas en los límites de las funciones. jaxtyping con beartype convierte la firma en una comprobación que se ejecuta en cada llamada:

@jaxtyped(typechecker=beartype)
def pool(x: Float[Tensor, "B T d"], mask: Bool[Tensor, "B T"]) -> Float[Tensor, "B d"]:
    m = mask[:, :, None].float()
    return (x * m).sum(1) / m.sum(1)

Si dentro de la función reduces por el eje equivocado, salta un error al devolver el resultado, porque [T, d] no es [B, d]. Y si pasas al error cuadrático el objetivo con forma de columna, la comprobación falla antes de que la regla pueda estirar nada. Así se detectan en el límite dos de los bugs de arriba (la reducción, solo cuando B ≠ T), con la forma escrita justo donde va a mirar el siguiente que lea el código. Para el bug del batch de dieciséis, y para la reducción por el eje equivocado cuando B es igual a T, hace falta el hábito siguiente.

Prueba con tamaños que no puedan coincidir. La anotación no ve el bug del batch de dieciséis. Cuando B y T valen 16, los dos nombres se ligan al mismo número y la comprobación pasa. Con la reducción por el eje equivocado ocurre lo mismo, porque [T, d] y [B, d] son el mismo [16, 64]. El arreglo va en los tests, con B = 3, T = 5 y d = 7, y el código se queda como está. Cada None olvidado y cada confusión entre B, T y d dan entonces un tamaño que no coincide con nada, y el runtime lanza un error. Los ejes de tamaño 1 se siguen estirando con cualquier tamaño y las dos T de las puntuaciones son siempre iguales; esos casos necesitan la anotación o un test que compruebe valores. Los números redondos en los tests son los que dejan que el bug del batch de dieciséis llegue a producción. Por eso los dos primeros hábitos son uno solo: la anotación nunca es más estricta que los tamaños que ve.

La máscara y el lado del padding son una sola decisión. Apunta el lado junto a la configuración del tokenizador, calcula el índice del último token a partir de la máscara (nunca de T) y rechaza cualquier batch cuya máscara no cuadre con su padding. El código de pooling de la parte 2 ya divide por la suma de la máscara; asegúrate de que el tuyo también lo haga.

Calcula lo que cuesta un tensor antes de reservarlo. Multiplica la forma por los bytes de un número, para el tamaño de batch y el formato con los que vayas a servir el modelo. La demo de arriba hace esa multiplicación, y el resultado lo conoces antes de cargar un solo peso.

Esto tampoco es trabajo de modelado. La forma es el único tipo que este stack no comprueba nunca. Si los dispositivos no coinciden, salta un error, pero un eje equivocado se resuelve por broadcasting, y esa comprobación te toca escribirla a ti.

Parte 3 de 12. Una forma es una firma que nadie verifica. Como el broadcasting decide por tamaño, un eje equivocado solo provoca un error si da la casualidad de que los tamaños son distintos, y hay bugs que solo existen con un tamaño de batch concreto. Las puntuaciones de la primera demo y las dos filas ámbar de la segunda llevan T dos veces, una matriz T × T por secuencia (y por cabeza, en la segunda), y forman parte de la atención. La parte siguiente explica de dónde sale ese cuadrado y cuánto cuesta. Si has llegado aquí directamente, puedes empezar por el tokenizador y seguir con la tabla a la que apunta el id de un token.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Un embedding es una tabla de consulta, y todo lo demás es cómo se rellena

Carlos Chinchilla Corbacho — Tue, 08 Sep 2026 00:00:00 GMT

La parte 1 terminó en un índice. El tokenizador convierte el texto en ids, cada id es un número de fila y esa fila está en una matriz con la que nace el modelo. Ahora toca leer esa matriz, que es menos de lo que parece, apenas una tabla de consulta indexada por enteros y con contenido aprendido. La ciencia está en cómo llega ahí ese contenido, y la ingeniería, en lo que ya no puedes hacer con la tabla una vez rellena.

Para esta entrada he leído dos ficheros. El primero es el forward de torch.nn.Embedding, que se reduce a una sola llamada, y el segundo, el módulo de pooling de sentence-transformers, donde se fabrica la otra clase de embedding, la que guardas en un índice. Después he montado un índice de 48 líneas y lo he roto adrede de tres maneras para medir qué falla.

Una matriz y un índice

Si alguna vez has programado una tabla hash, llevas escrita casi toda una capa de embedding. nn.Embedding(V, d) reserva una matriz de V filas y d columnas, y consultar el id i devuelve la fila i. En eso consiste toda la pasada hacia delante, como muestra el propio código de torch en sparse.py:188-197.

def forward(self, input: Tensor) -> Tensor:
    return F.embedding(
        input,
        self.weight,
        self.padding_idx,
        self.max_norm,
        self.norm_type,
        self.scale_grad_by_freq,
        self.sparse,
    )

F.embedding es un gather, y no hace falta fiarse porque se puede comprobar. Con un Embedding(50257, 768) recién creado y tres ids, torch.equal(emb(ids), emb.weight[ids]) da True. No hay transformación, ni hash, ni similitud de por medio. A cada id le corresponde su fila.

Donde deja de parecerse a una tabla hash es en el tamaño. La tabla de entrada de GPT-2, wte.weight, tiene 50 257 filas por 768 columnas, o sea, 38,6 millones de números que ocupan 154 MB en fp32, y cada uno de ellos es un parámetro entrenado. all-MiniLM-L6-v2, el modelo de frases que uso en el resto de la entrada, resuelve lo mismo con una tabla de 30 522 por 384. Si la fila 11 241 de la tabla de GPT-2 es el vector de " token", es porque ahí lo manda el tokenizador, como se vio en la parte 1. El contenido de la fila se aprendió, pero la dirección ya estaba fijada antes de que empezara el entrenamiento.

Al ingeniero que viene del software le sorprende que las claves no signifiquen nada. La clave de una tabla hash significa algo por sí misma, mientras que la fila 11 241 solo tiene sentido dentro del modelo que la entrenó. Al científico de datos le sorprende justo lo contrario. Lo que con word2vec era un artefacto que se produce y luego se usa, aquí es un parámetro del propio modelo y se actualiza en el mismo paso de gradiente que todo lo que tiene encima. Nunca sale de ahí.

Dos maneras de rellenar la tabla

Hay dos maneras de darle números a una fila, y de cuál se use depende lo que puedas hacer con el resultado.

La primera es la de antes, con la tabla como parámetro de un modelo de lenguaje. Las filas empiezan con valores aleatorios y les van llegando los gradientes a través de las capas de encima. Al acabar el entrenamiento, cada fila es lo que haya ayudado al modelo a predecir el siguiente token. Nadie diseña ese espacio, que surge como efecto secundario. Del gradiente que lo rellena se ocupa la parte 8.

La segunda es la que despliega en la práctica la mayoría de los ingenieros. Coges un modelo entrenado, le pasas un texto y te quedas con la salida como vector de ese texto. Esa fila no se guarda en ningún sitio. Se calcula cada vez que hace falta y depende de la entrada entera, de todos sus ids a la vez.

La palabra bank tiene una fila en la tabla de entrada de ese modelo de frases, la 2924. Se le suma una tabla de posiciones, pero la fila de la palabra es la misma en «she sat on the river bank» y en «she opened a bank account». A la salida, en cambio, los dos vectores de ese mismo token tienen un coseno de 0,77 entre sí. Se consulta la misma fila y sale un resultado distinto, porque entre la tabla y la salida hay una posición y seis capas. Eso es lo que quiere decir «contextual», y ahí está toda la diferencia entre un embedding estático y el que metes en un índice de búsqueda.

Lo que sale es un vector por token, pero una frase necesita uno solo, así que algo tiene que condensar en uno los T vectores de los tokens. De eso se encarga el pooling. En sentence-transformers todas las variantes están en un mismo sitio. En la ruta por defecto, con padding, la rama por la que pasa un modelo con pooling de media es pooling.py:200-213.

elif mode in ("mean", "mean_sqrt_len_tokens"):
    if mean_sum is None:
        mask = attention_mask.unsqueeze(-1).expand_as(token_embeddings).to(token_embeddings.dtype)
        mean_sum = (token_embeddings * mask).sum(dim=1)
        # ... mean_mask is the count of real tokens (or a supplied per-token weight sum), clamped away from zero
    if mode == "mean":
        output_vectors.append(mean_sum / mean_mask)

Suma los tokens que la máscara de atención marca como reales y divide entre cuántos había. En esa función conviven seis modos, cada uno una manera distinta de reducir los mismos T vectores. Por ejemplo, cls se queda con el primero, lasttoken con el último y max con el mayor de cada dimensión. Cada modelo se entrena con uno de ellos, y esa elección forma parte del artefacto.

Lo mismo vale para el paso siguiente. El modules.json del propio modelo pequeño enumera lo que se ejecuta al llamar a encode.

[
  {"idx": 0, "name": "0", "path": "", "type": "sentence_transformers.models.Transformer"},
  {"idx": 1, "name": "1", "path": "1_Pooling", "type": "sentence_transformers.models.Pooling"},
  {"idx": 2, "name": "2", "path": "2_Normalize", "type": "sentence_transformers.models.Normalize"}
]

Primero va el Transformer, luego el pooling y al final la normalización a longitud unitaria. En el tercero no hay acuerdo ni siquiera dentro de la familia: paraphrase-MiniLM-L6-v2 viene sin él, y sus vectores en bruto tienen normas de alrededor de seis. De los tres módulos, los dos últimos son los que un cliente suele reimplementar, y si lo hace de otra manera, la respuesta cambia. Cuánto cambia se mide dos secciones más abajo.

La cercanía es un producto escalar

Cuando todos los vectores tienen longitud unitaria, la similitud coseno es un producto escalar, y buscar el vecino más cercano se reduce a multiplicar matrices y ordenar. GPT-2 lee su propia tabla del mismo modo a la salida, cuando calcula los logits del siguiente token como el producto escalar con cada fila de wte. La parte de recuperación no tiene más, y por eso la factura del índice es pura aritmética. Diez millones de documentos con 384 dimensiones ocupan 15,4 GB en fp32 sin contar la estructura del índice; con 768 son 30,7 GB, y con 1536, la dimensión de un conocido modelo de embeddings que se sirve por API, 61,4 GB. La dimensión es un coste que pagas tú por cada documento mientras exista el índice, pero que fijó quien entrenó el modelo.

El número que devuelve la búsqueda sirve para menos de lo que parece. En mi corpus de 48 líneas, la mejor coincidencia para «how do I undo a bad release» tiene un coseno de 0,30 con la consulta y es la línea correcta, el procedimiento de rollback. La mejor para «the migration is stuck waiting on a lock» saca 0,71 y también acierta. Un coseno es una posición en un espacio cuya escala ha elegido el modelo, y no sirve como medida de confianza. Compara el orden de los resultados dentro de un mismo modelo y nunca compares el número en bruto entre dos.

No hay migración de esquema

Lo que viene ahora no tiene equivalente en el software. Cuando cambias el esquema de una base de datos, escribes una migración, la ejecutas y las filas viejas quedan con la forma nueva. Un espacio de embeddings no tiene migración. Dos modelos producen dos espacios y ninguno trae un mapa hacia el otro, porque nadie los diseñó y cada uno es donde fue a parar el entrenamiento. Puedes ajustar un mapa a posteriori, y hay quien lo hace. El resultado es una aproximación aprendida, con su propio error, y eso no es una migración. Con un mapa lineal ajustado sobre cuatro mil frases ajenas al corpus, el índice desfasado que mido más abajo pasa del 60 % al 70 % y no sube más. Si recalculas los embeddings con un modelo nuevo, cada vector que tienes guardado queda en un sistema de coordenadas que no usa nadie más.

Esperaba que eso se tradujera en resultados basura, y lo que sale es algo peor.

La prueba usa 48 líneas de un runbook, ocho de cada tema: despliegues, autenticación, facturación, bases de datos, observabilidad y guardias. Las he indexado con el modelo L6 y he lanzado las consultas con all-MiniLM-L12-v2, la actualización a la que recurriría un ingeniero (misma familia y mismas 384 dimensiones, así que el índice acepta los vectores sin rechistar).

Frente a lo que devolvería el índice actualizado, el desfasado conserva el 60 % de los cinco primeros resultados. Al azar se conservaría el 10 %, y adivinando cinco líneas del tema correcto, el 35 %. El índice viejo consultado con el modelo viejo conserva el 77 %: el desajuste cuesta diecisiete puntos y los otros veintitrés se deben a que los dos modelos no coinciden en la respuesta. Con «user keeps getting logged out», el primer resultado sigue siendo la línea de la caducidad de sesión, pero el tercero es la política de retención de las copias de seguridad de la base de datos. Nada en la respuesta te dice cuál es cuál.

Para ser justos con la cifra, un 60 % no es un índice revuelto, y para explicarlo no basta con que los dos modelos trabajen en inglés: la razón está en el linaje. Ambos se ajustaron a partir del mismo checkpoint padre, del que el L6 conserva solo una capa de cada dos, con lo que sus espacios empezaron en las mismas coordenadas. La misma línea codificada con uno y otro tiene, de media, un coseno de 0,54 consigo misma, muy por encima de lo que darían dos vectores ortogonales. Dos modelos que solo compartieran los datos de entrenamiento no compartirían coordenadas, y un índice desfasado entre ellos debería quedar cerca del azar. Además, seis temas bien delimitados de ocho líneas cada uno son el corpus más favorable que podría pedir un índice desfasado. No he medido un índice en producción, y esperaría que conservara menos. Lo que sí respalda la cifra es la forma del fallo, que es parcial, verosímil y silencioso.

El módulo de pooling produce el mismo efecto sin cambiar de modelo. Con los mismos pesos, si cambias mean por cls al indexar y al consultar, los cinco primeros conservan el 50 % de la respuesta con pooling de media. Si los mezclas, con media en el índice y cls en la ruta de consulta, conservan el 70 %. Sale mejor que con cls en los dos lados porque uno de ellos sigue usando el pooling con el que se entrenó el modelo. Un cliente que reimplementa el pooling ha cambiado el modelo.

Figura interactiva: Un índice de 48 líneas de un runbook que se reindexa línea a línea con el modelo actualizado. Avanza la reindexación y elige qué modelo codifica las consultas. El recall se mide respecto a lo que devuelve la migración terminada, y las líneas que se cuelan son verosímiles. Las líneas y las consultas siguen en inglés porque son el texto que codificaron los modelos. Ábrela en el artículo para usarla.

Avanza la reindexación y luego cambia el modelo que codifica las consultas. Con el modelo nuevo, el recall sube a medida que migra la tabla. Con el viejo empieza en 0,77 porque dos modelos usados de forma coherente ya discrepan en una cuarta parte de las respuestas. Después cae hasta 0,63 en la parte central de la migración, no vuelve al 0,77 hasta las últimas líneas y termina por debajo, en 0,73. Para entonces, cada línea del índice la ha escrito un modelo que la ruta de consulta no usa.

Esa segunda curva es la que te encuentras en producción, donde el índice sale de un proceso por lotes, el codificador de consultas es un servicio desplegado y cada uno se actualiza un día distinto.

Qué vigila el ingeniero de ML

Son cuatro hábitos, todos baratos al lado de una reindexación.

El modelo de embeddings forma parte del índice. Guarda en los metadatos del índice el hash del modelo, el modo de pooling, el paso de normalización y la longitud máxima de secuencia, y rechaza cualquier consulta cuyo codificador no coincida. El modules.json de antes es la mitad de ese contrato; el modo de pooling está a su lado, en 1_Pooling/config.json, y el hash lo añades tú. La longitud máxima importa. El modelo L6 lee 256 tokens y la versión L12 solo 128, de modo que el cambio que rompió el índice también redujo a la mitad, sin avisar, lo que ve cada vector. Todo eso tiene que ir con el índice, fuera de la configuración de cualquier cliente.

Corte limpio, sin reindexación gradual. Construye el índice nuevo junto al viejo, cambia consultas e índice a la vez, detrás de un único flag, y borra el viejo al terminar. Una reindexación gradual con la ruta de consulta en marcha es justo la curva que cae en la demo.

Mide el solapamiento de vecinos y olvídate del coseno. Mantén un conjunto fijo de consultas con su top-k esperado y calcula con él el recall@k cada vez que cambies de modelo. Un umbral de coseno ajustado con un modelo no significa nada con el siguiente, y el conjunto de vecinos es lo único observable que sobrevive al cambio. Eso sí, el solapamiento mide la deriva y deja fuera la relevancia: con el índice ya migrado, los cinco primeros de la consulta del cierre de sesión todavía incluyen una línea sobre almacenamiento en frío.

La dimensión es una factura. Son N por d por cuatro bytes, sin contar la estructura del índice. La media precisión reduce la factura a la mitad, y algunos modelos recientes te dejan quedarte solo con las k primeras dimensiones. Las dos cosas se pueden aplicar a vectores ya guardados sin recalcular los embeddings, aunque los vectores truncados hay que renormalizarlos y las consultas hay que cortarlas a la misma k. Ambas decisiones van en los metadatos del índice, con todo lo demás. Calcula lo que te costará la dimensión de un modelo mayor con el corpus que tendrás dentro de dos años, porque el de hoy no sirve para esa cuenta.

Esto tampoco es trabajo de modelado. Un índice de embeddings parece una base de datos con una columna de floats hasta el día en que alguien actualiza el modelo que escribió esa columna.

Parte 2 de 12. Un embedding es una fila de una matriz que se rellena con el gradiente o con la salida de un modelo, y el espacio en el que vive no tiene migración: si cambias el modelo, todos los vectores guardados quedan desfasados sin avisar. Un batch de secuencias de esas filas es un tensor con la firma [B, T, d], y la siguiente parte lee esa firma como leerías la de una función y descubre que el runtime nunca la comprueba. Si has llegado aquí directamente, puedes empezar por el tokenizador que decide en qué fila caes.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Un modelo no lee texto: lo que el tokenizador decide por ti

Carlos Chinchilla Corbacho — Tue, 01 Sep 2026 00:00:00 GMT

Un modelo de lenguaje no ha visto nunca una letra.

Solo ve enteros. En algún punto entre tu cadena y la primera multiplicación de matrices hay una función que convierte el texto en una lista de ids, y esa función quedó congelada el día en que se entrenó el modelo. Aunque parezca preprocesamiento, forma parte del artefacto. Cámbiala y los pesos seguirán ahí, pero el modelo que tenías habrá desaparecido.

Vengo de los compiladores, donde el parser es tuyo y puedes cambiarlo un martes cualquiera. Aquí solo es tuyo una vez, antes del entrenamiento, y ya nunca más.

Con este post empieza una serie para ingenieros que dan el salto a la ingeniería de ML desde el software o desde la ciencia de datos. Cada parte se ocupa de una cosa que no se comporta como en el software. En esta le toca al parser, que va dentro del modelo.

Un lexer con otro objetivo

Si has escrito un compilador, ya has escrito un tokenizador. El lexer recibe caracteres y emite un flujo de símbolos (identificadores, palabras clave, literales). Su objetivo es reconocer la estructura para que el parser pueda construir un árbol.

El tokenizador de un modelo es igual por fuera, pero persigue otra cosa. Aquí no hay estructura que reconocer. Se trata de comprimir, de convertir una cadena en el menor número posible de ids de un vocabulario fijo, para que el modelo vea menos posiciones y el vocabulario siga siendo lo bastante pequeño como para dar a cada id su fila en la matriz de embeddings.

Ninguno de los dos extremos funciona. Con caracteres, el vocabulario es minúsculo y las secuencias salen demasiado largas; cada posición se paga en atención, cuyo coste crece con el cuadrado de la longitud. Con palabras enteras, las secuencias son cortas, pero el vocabulario queda sin acotar y, encima, deja un agujero por cada palabra que no esté en él. A ese agujero el científico de datos lo llama «fuera de vocabulario» y el ingeniero de software, «caso no contemplado».

El término medio son las subpalabras. Sennrich, Haddow y Birch (2016) cogieron el byte-pair encoding, un algoritmo de compresión de 1994, y lo aplicaron a este otro problema para aprender las unidades de subpalabra a partir del corpus, sin tener que declararlas de antemano.

BPE es un solo bucle

He leído el _educational.py de tiktoken. Su codificador es una versión legible del núcleo en Rust, cosa que he comprobado ejecutando los dos sobre todas las muestras de más abajo y comparando los ids. El entrenador, en cambio, no imita nada. El núcleo en Rust no trae entrenador, así que bpe_train (_educational.py:119-185) es la única versión del bucle que hay en el paquete. Todo el entrenamiento es un solo bucle, y este es el cuerpo de bpe_train:

while len(ranks) < vocab_size:
    stats = collections.Counter()
    for piece in words:
        for pair in zip(piece[:-1], piece[1:]):
            stats[pair] += 1
    most_common_pair = max(stats, key=lambda x: stats[x])
    token_bytes = most_common_pair[0] + most_common_pair[1]
    token = len(ranks)
    # Add the new token!
    ranks[token_bytes] = token
    # ... then replace that pair through the corpus, and loop

Empiezas con 256 tokens, uno por byte, y cuentas todos los pares adyacentes del corpus. Coges el más frecuente, le das el siguiente id y lo sustituyes en todo el corpus, de izquierda a derecha, y así hasta que el vocabulario tenga el tamaño que has pedido.

El vocabulario es la lista ordenada de fusiones, y en ese orden está todo el modelo del idioma. Codificar consiste en reproducir ese orden: partes la entrada en bytes, buscas el par adyacente con el rango de fusión más bajo, lo fusionas y repites hasta que no quede nada que fusionar. bpe_encode (_educational.py:83-116) ocupa treinta y cuatro líneas y no recorre nunca la lista de fusiones. El entrenamiento se queda con el par más frecuente y la codificación con el de rango más bajo, que viene a ser lo mismo.

Figura interactiva: El bucle de entrenamiento avanza un paso por clic: cuenta los pares adyacentes, fusiona el más frecuente y repite. El vocabulario es la lista de fusiones en orden. El símbolo ␣ es un espacio que va pegado a la palabra siguiente. Ábrela en el artículo para usarla.

La demo ejecuta ese bucle sobre un corpus de juguete, una fusión por clic. Como doce de sus dieciocho pasos son empates, la regla de desempate (gana el primer par que aparece) pesa mucho.

Al ingeniero le importan dos detalles. El primero es que BPE trabaja con bytes y no con caracteres, de ahí que cualquier entrada se pueda codificar y que no exista el token desconocido. Un carácter que las fusiones no han visto nunca cuesta hasta un token por cada byte UTF-8, pero no da error. Con GPT-2, ß es un token porque sus dos bytes se fusionaron durante el entrenamiento, 漢 son tres, uno por byte, y una letra del alfabeto gótico son cuatro. Los vocabularios más recientes han recortado parte de ese sobrecoste (o200k_base ya tiene 漢 entero), aunque la letra del alfabeto gótico sigue costando cuatro tokens en todos ellos. El segundo detalle es que, antes de que entre en juego BPE, una expresión regular parte el texto en fragmentos, y las fusiones nunca pasan de un fragmento a otro. El patrón de GPT-2 deja el espacio inicial pegado a la palabra que lo sigue, de modo que " token" y "token" son tokens distintos. Por eso el modelo no trata igual el principio de una línea que el medio, y por eso un espacio de más en una plantilla de prompt cambia la salida.

El vocabulario es el corpus de entrenamiento

El vocabulario de GPT-2 tiene 50 257 entradas. Si la cifra no es redonda es porque se trata de una suma: 256 tokens de byte, 50 000 fusiones aprendidas y un token especial, <|endoftext|>, con el id 50256. Radford et al. (2019) describen el diseño basado en bytes del que salen esas cifras. Las dos codificaciones más recientes de OpenAI que he comprobado, cl100k_base y o200k_base, tienen 100 261 y 200 000 tokens repartidos en rangos de 100 277 y 200 019 ids (el n_vocab de tiktoken), y los huecos son ids sin usar.

En las fusiones queda codificado el corpus de entrenamiento. Las palabras inglesas le salen baratas a GPT-2, que se entrenó sobre todo con texto web en inglés. " tokenizer" son dos tokens, mientras que el mismo concepto en español, " tokenizador", son tres, y " desvanecimiento", seis. Una palabra alemana con diéresis, " Wörter", ocupa tres, y en uno de ellos los dos bytes de la ö van soldados a la r que la sigue. El tokenizador no tiene noción de carácter, solo de bytes y de frecuencias.

Los números son el caso que pilla por sorpresa a los ingenieros. GPT-2 tokeniza 1234567 como 123, 45, 67 porque es lo que sale, sin más, de los rangos de fusión. cl100k_base cambió la expresión regular para cortar las secuencias de dígitos en tramos de tres como máximo. Eso acota el daño sin arreglarlo. Los tramos se forman de izquierda a derecha, así que 1000 acaba partido en 100 y 0. Es una decisión del tokenizador con un efecto directo en lo que el modelo puede calcular, y se tomó en una expresión regular.

Para ser justos con GPT-2, sus fusiones se aprendieron solo a partir de la frecuencia, y en el texto web 1000 es tan común que 00, luego 000 y luego 1000 fueron ganando por turnos el recuento de pares. Una tabla de fusiones que respete la frecuencia se lo tragará entero. Nadie decidió romper la aritmética. El coste solo salió a la luz cuando la gente empezó a pedir a estos modelos que sumaran.

El mismo párrafo cuesta más en español

He escrito un párrafo de 184 bytes en inglés y en español, y he montado un payload JSON de más o menos el mismo tamaño, 182 bytes. Luego he codificado los tres con cada uno de los tres tokenizadores.

Con GPT-2, el español cuesta en torno a 1,7× lo que el inglés, y con la codificación más reciente sigue en 1,2×. El JSON cuesta alrededor de 2,3× con las tres codificaciones, porque las llaves, las comillas y las claves no se comprimen. Ninguna de las 26 comillas de ese payload aparece sola como token. Cada una va soldada a la llave, el corchete, los dos puntos, la coma o el espacio que tiene al lado, en tokens como ", ":, ",, {" y "},. Son veintiséis comillas repartidas en veintiséis tokens, una en cada uno.

Figura interactiva: Un párrafo escrito en dos idiomas y un payload JSON de igual tamaño, codificados con tres tokenizadores. Cambia la muestra y la codificación: los mismos bytes salen a otro precio. Cada bloque de color es un id que ve el modelo, y el espacio inicial forma parte del token. Ábrela en el artículo para usarla.

Si cambias la muestra y la codificación, verás que los vocabularios más recientes eliminan la mayor parte de la diferencia del español, mientras que la del JSON no se mueve.

De ahí salen tres consecuencias, todas de facturación o de capacidad y ninguna de modelado. Una ventana de contexto expresada en tokens admite menos español que inglés, y mucho menos JSON. Un precio por token es un precio por idioma. Y una plantilla de prompt que envuelve cada petición en metadatos estructurados paga la tarifa del JSON en cada llamada.

El sistema de tipos no avisa

En el software, el parser es código y el modelo son datos. Puedes cambiar el parser, recompilar y leer los mismos datos. Aquí, en cambio, el parser está acoplado a los pesos. La matriz de embeddings tiene una fila por id, y la fila 11 241 significa " token" solo porque eso es lo que dijeron las fusiones de GPT-2 cuando se entrenó el modelo; con cl100k_base, esa misma fila es Seg. Si codificas el mismo texto con otro tokenizador, obtienes ids que indexan la misma matriz y significan otra cosa. Que el fallo se note o pase en silencio es cuestión de suerte. Con o200k_base, el mismo párrafo en inglés llega al id 99 665, que una matriz de 50 257 filas rechaza. En sentido contrario, si metes ids de GPT-2 en un modelo de vocabulario más grande, todos caen dentro y no salta ninguna excepción. Y ni siquiera el rechazo es tan firme como parece. Los modelos en producción rellenan la matriz de embeddings hasta un múltiplo de 64 o de 128 para alinearla con los tensor cores, con lo que hay más filas en la matriz que ids en el vocabulario. Además, en una GPU un índice fuera de rango acaba apareciendo como un assert asíncrono en alguna línea que no tiene nada que ver con el sitio donde ocurrió.

Por eso el tokenizador forma parte del artefacto. En GPT-2 esa misma matriz hace también de cabeza de salida, así que la consulta a la entrada y la distribución de muestreo a la salida dependen del mismo array de pesos y un cambio de tokenizador corrompe las dos. El fichero del modelo y el del tokenizador son dos mitades de una misma cosa, y cuando se desalinean, el fallo es silencioso. Un cambio completo cuyos ids siguen dentro de rango produce basura que ningún control detecta, y una deriva parcial (un token especial renumerado, un BOS que falta) produce texto fluido condicionado por una entrada equivocada.

Qué vigila el ingeniero de ML

Hay cuatro cosas que conviene comprobar antes de que nada de esto llegue a producción.

Tokenizador y modelo, versionados juntos. Guarda el hash del tokenizador junto a los pesos y compruébalo al cargar. No hay desajuste peor que el que no falla al cargar.

Coste por idioma y por dominio. Mídelo con tu tráfico real antes de estimar una factura o de prometer una longitud de contexto. La ventana de 8k son 8k tokens de inglés, pero con el payload JSON de arriba se acerca más a 3,5k del mismo contenido.

Tokens especiales. Por defecto, el Encoding.encode de tiktoken lanza una excepción si el texto contiene algo parecido a <|endoftext|>, precisamente porque un usuario podría escribirlo. Ese comportamiento por defecto es una decisión de seguridad. Comprueba qué hace con ello la capa que sirve tu modelo y en qué punto mete tu plantilla de chat sus propios tokens especiales.

Longitud en tokens, no en caracteres. Todos los límites del modelo van en tokens. Para truncar, repartir el presupuesto de contexto o aplicar límites de consumo hay que pasar cada petición por el tokenizador, y contar caracteres no sirve.

Nada de esto es trabajo de modelado. Es la parte del modelo que se comporta más como el software corriente, y precisamente por eso llega a producción sin que nadie la revise: una función que convierte cadenas en enteros parece preprocesamiento hasta el momento exacto en que deja de serlo.

¿Quién calibra al juez? La brecha que nadie cierra

Carlos Chinchilla Corbacho — Tue, 25 Aug 2026 00:00:00 GMT

En seis entregas he recorrido cinco estrategias y cinco de las siete herramientas cuyo código he leído para la investigación que hay detrás. Hay una pregunta a la que la serie ha apuntado una y otra vez sin llegar a responderla del todo: ¿hasta qué punto es realmente fiable el juez en la tarea que ejecuta y con la rúbrica que le han dado?

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. Las estrategias de esta serie limitan lo que el juez puede decir (partes 2 y 3), miden lo seguro que suena (parte 4), fijan lo que debe ignorar (parte 5) o prescinden de él donde bastan las comprobaciones deterministas (parte 6). Todas son honestas y funcionan, aunque cada una deja algo sin cubrir. Daba por hecho que ninguna de las cinco herramientas incluía la primitiva que mide con qué frecuencia el juez coincide con una persona en tu tarea. Al repasar el código por segunda vez he tenido que corregirme: dos de las cinco la traen. Lo que no ofrece ninguna es el flujo de trabajo que supedita el build de CI a esa concordancia, con una banda de confianza publicada que el build pueda leer.

Con esta entrada cierro la serie y trazo el mapa de la brecha, que es más estrecha de lo que creía, pero real.

La intuición

Un juez es un instrumento de medida. Si mides dos veces el mismo líquido con un termómetro, obtendrás dos lecturas. La dispersión entre ellas es la varianza del instrumento. El termómetro sirve porque, en algún momento antes de llegar a tus manos, un fabricante caracterizó su error frente a un patrón de referencia (agua hirviendo, punto de congelación, celdas con trazabilidad al NIST). Si lleva implícito un margen de error, es porque alguien pagó ese paso de calibración.

Un juez LLM no trae ese paso de serie. Escribes una rúbrica, eliges un modelo, lo lanzas sobre las trazas del agente y obtienes puntuaciones. El framework te devuelve la puntuación, pero rara vez le dice a la puerta de CI qué margen de error tiene en tu tarea. Para saberlo, tendrías que pasar los mismos ítems por uno o varios anotadores humanos, calcular la concordancia con el juez y tratar el desacuerdo restante como el error del instrumento frente a la referencia (el sesgo más el ruido que arrastre una sola pasada). El ruido del juez entre ejecuciones, por sí solo, se mide aparte volviendo a juzgar los mismos ítems. La primitiva estándar para medir esa concordancia es la κ de Cohen (Cohen, 1960, con los tramos de magnitud de Landis y Koch, 1977). Esa medida es el paso de calibración.

Cuando empecé la serie, suponía que a las herramientas de código abierto les faltaba la primitiva en sí, pero no es del todo así. Al repasar con grep los cinco repositorios, esta vez buscando términos de calibración, he visto que dos de las herramientas incluyen la κ del juez frente a las etiquetas de referencia (Ragas con validate_alignment() y TruLens con GroundTruthAggregator(true_labels=...)), que ARES trae una versión más tosca y que Inspect AI ofrece un α de concordancia entre jueces. Lo que no incluye ninguna es la puerta de calibración, el flujo de trabajo que rodea a esas primitivas: una banda de confianza publicada sobre la κ que el build de CI use como umbral para fallar, y un disparador que relance la calibración cuando cambien el modelo del juez o la rúbrica. Las primitivas existen, pero no la puerta que las envuelve. De esa brecha trata esta entrada.

El mapa de la brecha

Al final de la serie, la matriz de estrategias por herramienta queda así, ampliada con dos filas a las que no llegaron las entregas anteriores.

Figura interactiva: Cada celda llena marca una herramienta en la que el análisis de las partes 2 a 6 encontró la estrategia como decisión de diseño de primer orden, o en la que una segunda pasada con grep por el repositorio dio con una API de concordancia frente a la referencia. La tabla no es exhaustiva: Ragas y DeepEval también traen métricas de cadenas sin LLM, y las primitivas de concordancia parciales de ARES (exactitud bruta frente a la referencia) e Inspect AI (α entre jueces) quedan con la celda vacía. La última fila es la brecha y queda vacía, porque ninguna herramienta trae una puerta de CI ligada a una banda de confianza publicada. Ábrela en el artículo para usarla.

Las cinco primeras filas recogen lo que desgranó cada entrada. Ragas trae la restricción del alcance bien resuelta. DeepEval se encarga de la descomposición y, de pasada, roza la calibración con las probabilidades de los tokens. De ARES sale la cota de PPI, de TruLens la rúbrica negativa y de Inspect AI el reparto entre lo determinista y lo que puntúa un modelo. En total hay seis celdas llenas en cinco filas, una por estrategia salvo la calibración probabilística, que comparten DeepEval y ARES.

La sorpresa vino con la sexta fila. En el metrics/base.py de Ragas, validate_alignment() recibe tu juez y un conjunto de test etiquetado por personas y devuelve la κ de Cohen. Para las métricas discretas usa cohen_kappa_score, para las de ranking la κ ponderada y para las numéricas la r de Pearson. La guía práctica oficial («How to Align an LLM as a Judge») desarrolla la misma idea con el porcentaje bruto de concordancia, pero donde está la κ es en validate_alignment(). TruLens va más allá. En feedback/groundtruth.py, GroundTruthAggregator(true_labels=...) incluye cohens_kappa, ece (error de calibración esperado), brier_score, matthews_correlation y primitivas de correlación de rangos, todas accesibles directamente desde trulens.feedback y con sus propios tests. ARES, por su parte, da la exactitud bruta del juez frente a la referencia junto a su cota de PPI. Las primitivas ni son exóticas ni faltan. Dos de las cinco herramientas incluyen la κ del juez frente a la referencia, ARES trae una versión más tosca e Inspect AI ofrece krippendorff_alpha(), pensada para medir la concordancia entre jueces sin compararlos con la referencia.

La séptima fila sigue vacía en todas las herramientas. Ninguna de las cinco envuelve esas primitivas en una puerta de CI ligada a una banda de confianza publicada, del estilo de «haz que el build falle cuando la κ baje de 0,7 y la cota inferior de su IC del 95 % quede por debajo de 0,6». Ragas devuelve una estimación puntual de la κ, y el bootstrap te toca a ti. TruLens devuelve lo mismo, aunque es la que más ha montado a su alrededor. Su paquete de benchmark tiene AlignmentReport, CriteriaABTest (para cambios de rúbrica) y CrossModelAlignment (para cambios del modelo del juez), que comparan con un conjunto de referencia, y Run.compare() pone un intervalo de confianza por bootstrap a las diferencias de puntuación entre ejecuciones. Pero todo eso se usa a mano. Ninguna de las cinco publica una banda de confianza sobre la κ ni la conecta a una puerta del build.

ARES es la que más se acerca, y merece la pena deshacer el equívoco. Su implementación de PPI pone un intervalo de confianza alrededor de la puntuación agregada del agente, con lo que parece que debería llenar la fila de la puerta de calibración. Sin embargo, ese intervalo se calcula sobre el estadístico de la población, mientras que una puerta de calibración lo necesita sobre la concordancia con las etiquetas humanas del conjunto de test. PPI te dice que la puntuación agregada cae dentro de una banda (Angelopoulos et al., 2023), pero no le dice al build que falle cuando la concordancia entre el juez y las personas se desvía.

Así que la brecha existe, aunque es más estrecha de lo que la planteé al empezar esta entrada.

Lo que cuesta la brecha

Supongamos una puerta de CI. Una PR modifica el generador de planes de un agente, la CI lanza la batería de evaluación (veinte rúbricas de mil ítems cada una) y dos rúbricas bajan 3 puntos. ¿Es real esa bajada?

En realidad son dos preguntas. Para saber si la bajada supera el ruido no hacen falta etiquetas; basta un bootstrap pareado o un test de permutaciones sobre las diferencias por ítem en esos 1000 ítems, con las dos ejecuciones juzgadas desde cero para que la varianza del juez entre ejecuciones quede dentro de las diferencias. En cambio, solo las etiquetas pueden decir si una bajada en la escala del juez es de las que notaría una persona. Un juez que se equivoca al azar acerca a cero las diferencias reales, y uno al que sesga el propio cambio (por ejemplo, porque altera el estilo de la salida) puede inventarlas u ocultarlas.

Figura interactiva: El estadístico κ compara al juez con una etiqueta de referencia oculta en una tarea binaria equilibrada. Elige la exactitud real del juez y cuántos ítems etiquetados por personas tienes, y la banda que sale es lo que puedes publicar. Ábrela en el artículo para usarla.

En esta demo fijas lo fiable que es tu juez frente a una referencia oculta y ves cómo queda la banda de confianza de la κ de Cohen con distintos tamaños de muestra. Sin ser una herramienta de calibración, enseña lo que cuesta no tener una. Aunque sepas que tu juez acierta el 80 % de las veces, la banda que puedes publicar es ancha mientras no hayas anotado cientos de ítems. Por debajo de unos 100 ítems etiquetados por personas, la banda es demasiado ancha para certificar la validez del juez.

La mayoría de los equipos no llega a 100 ítems etiquetados por personas en cada rúbrica, y de hecho la mayoría no tiene ninguno. La serie ha ido documentando herramientas que funcionan bien en esa situación con estrategias que no necesitan ni una etiqueta. La brecha es lo que esas estrategias no pueden suplir.

Por qué nadie ofrece la puerta

Las primitivas son la parte fácil. Lo difícil es el flujo de la puerta de calibración que las rodea, y lo es por algo concreto que no encaja en un evaluador de código abierto de propósito general.

Un framework puede incluir un juez, plantillas de rúbrica, grafos de descomposición, lógica de reintentos y parsers de salida estructurada, todo lo que has leído en las partes 2 a 6. También puede envolver sklearn.metrics.cohen_kappa_score cuando ya hay etiquetas, que es justo lo que hace GroundTruthAggregator.cohens_kappa de TruLens en feedback/groundtruth.py. Lo que no puede traer un framework general es el umbral. La puerta de CI que falla cuando κ < 0,7 necesita saber cuál es tu 0,7, en qué rúbrica y con cuánta tolerancia a las oscilaciones ruidosas que no son regresiones reales. Nada de eso vale igual para todas las tareas, y cualquier valor por defecto sería erróneo en algún caso importante.

Figura interactiva: Lo que cuesta calibrar un juez en una rúbrica. Elige el tamaño de la muestra, cuántos anotadores etiquetan cada ítem y cuánto se tarda por ítem. La factura es la que es. Ábrela en el artículo para usarla.

Esta otra demo enseña lo que cuesta en realidad producir las etiquetas. Eliges el número de ítems, el de anotadores y el tiempo de anotación por ítem, y la demo te devuelve la factura. Para una rúbrica es barata, pero se multiplica por cada rúbrica de la batería y vuelve con cada cambio de juez o de rúbrica. Por esa factura y porque, como decía arriba, cada equipo tiene que fijar su propio umbral, nadie ha empaquetado el hook de la puerta de calibración. La idea que guía el diseño de ARES («anota un conjunto pequeño y aprovéchalo bien») es la respuesta de la literatura al coste de etiquetar, aunque ARES solo la aplica a la evaluación de RAG.

Lo que queda por integrar está acotado y es concreto: un wrapper que ponga un intervalo de confianza por bootstrap a la κ que ya calculan Ragas y TruLens, una opción de configuración que diga «estos son mis umbrales, úsalos como puerta» y un hook que lance la recalibración cuando cambien el modelo del juez o la versión de la rúbrica. Las piezas ya están hechas. La estimación puntual la da sklearn.metrics.cohen_kappa_score, las bandas de confianza analíticas para la κ, el AC1 y el α de Krippendorff salen de la familia irrCAC (el paquete de Gwet para la concordancia entre anotadores) y las extensiones con varios anotadores las cubre statsmodels.stats.inter_rater. Ese wrapper es el trabajo que ninguna herramienta ha hecho de principio a fin.

Qué puedes hacer hoy

Hay tres cosas que puedes hacer este trimestre sin cambiar de herramienta.

La primera es reservar presupuesto para una muestra de calibración. Empieza con 50 ítems por rúbrica que etiquete una persona cuidadosa. El segundo juego de etiquetas lo pone tu juez, y con el par sacas una estimación puntual de la κ de Cohen. Cuando la rúbrica se estabilice, pasa a una muestra de entre 100 y 200 ítems, porque por debajo de unos 100 la banda de la κ es demasiado ancha para certificar la validez del juez (lo muestra la primera demo). Tanto si usas Ragas (validate_alignment()) como TruLens (GroundTruthAggregator) u otra herramienta, este es el único sitio donde no te libras de etiquetar. Repite la calibración una vez por trimestre, y también cada vez que cambien el modelo del juez o la rúbrica.

La segunda, calcular tú mismo el intervalo de confianza por bootstrap y escribir el umbral en la puerta. Como ni Ragas ni TruLens devuelven una banda de confianza sobre la κ, tendrás que sacarla con un bucle de bootstrap de 1000 remuestreos o con las funciones de intervalo de confianza que trae irrCAC (kappa2.table en R, irrCAC.table.CAC(table).cohen() en Python). Después, cuando la cota inferior caiga por debajo de tu umbral, haz que el build falle con un error de calibración necesaria, sin marcarlo como regresión de calidad. Vistos desde fuera, los dos fallos se parecen, pero se arreglan de forma distinta (uno editando la rúbrica, el otro corrigiendo el agente), y distinguirlos es justo lo que no puede hacer por ti un juez sin ese wrapper.

La tercera, ser honesto en el informe de evaluación sobre lo que el juez puede decirte y lo que no. No es lo mismo afirmar «La fidelidad ha bajado 3 puntos» que afirmar «En esta ejecución, el juez ha puntuado la fidelidad 3 puntos por debajo (IC del 95 % por bootstrap pareado, de 1,6 a 4,4). En un conjunto de calibración de 200 ítems, su concordancia con las personas es κ = 0,72 (IC del 95 %, de 0,62 a 0,82), así que la bajada es real en la escala del juez, y esa concordancia acota hasta qué punto refleja una regresión que notaría una persona». Lo segundo es lo que tendría que publicar una puerta de calidad para controlar la calidad de verdad.

Nada de esto exige que tu herramienta de código abierto haga más de lo que ya hace. Exige, eso sí, aceptar que el wrapper de la puerta de calibración te toca a ti y tratarlo como una tarea de ingeniería presupuestada y repetible, sin convertirlo en un proyecto de investigación.

La serie, de principio a fin

Las estrategias de esta serie se complementan sin competir entre sí. Son cinco formas distintas de atacar el mismo problema, el de estrechar lo que un juez LLM puede estropear. Un harness de evaluación maduro las combina: determinista donde puede (parte 6), con el alcance restringido donde no puede (parte 2), con descomposición estructural donde el juicio es complejo (parte 3), anclado por rúbrica donde se solapa con métricas hermanas (parte 5) y con calibración probabilística donde la salida necesita un intervalo (parte 4). Es una arquitectura plural.

Apiladas, las cinco quedan así. Si desactivas una estrategia, la barra deja al descubierto la parte que acotaba. El tramo de la derecha, el residuo que solo acotaría la puerta de calibración, no se mueve con ningún interruptor. (Los anchos de los tramos son ilustrativos.)

Figura interactiva: La barra horizontal representa la varianza total del juez. Activa o desactiva cada estrategia para ver su tramo acotado (tinta) o al descubierto (ámbar). El tramo de la derecha es la brecha de calibración, la varianza que dos herramientas (Ragas y TruLens) permiten medir con sus primitivas y que ninguna herramienta vigila con una puerta. Los anchos de los tramos son ilustrativos. Ábrela en el artículo para usarla.

Estoy trabajando en esta brecha con AgentAnvil. Que la acabe cerrando AgentAnvil u otra herramienta es lo de menos; la brecha existe, tiene nombre y las estrategias de esta serie no la cierran.

Regla práctica: el juez es un instrumento de medida, y ningún build puede defender una medida que no lleve una banda de calibración publicada y vigilada por una puerta. Las cinco herramientas de esta serie estrechan la varianza, pero ninguna trae la puerta.

Parte 7 de 7, la que cierra la serie. Dos de las cinco herramientas (Ragas y TruLens) incluyen la primitiva κ que expondría un juez calibrado, pero ninguna ofrece el flujo de la puerta de calibración, es decir, una banda de confianza publicada sobre la κ que haga fallar el build de CI cuando caiga. Las cinco estrategias estrechan lo que el juez puede estropear. La puerta en torno a la banda de calibración es el trabajo que ninguna herramienta ha hecho de principio a fin. Si has llegado aquí directamente, este es el recorrido completo: la parte 1 pone nombre a la varianza, la parte 2 la acota con veredictos binarios, la parte 3 divide un juicio difícil en un grafo de juicios más pequeños, la parte 4 mide la certeza de la respuesta, la parte 5 le dice al juez qué ignorar y la parte 6 prescinde del juez donde basta con una regex.

Forma parte de la misma serie y está relacionado con un artículo que presenté en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Determinista donde puedas, juez donde haga falta

Carlos Chinchilla Corbacho — Tue, 18 Aug 2026 00:00:00 GMT

En la parte 5 vimos el anclaje por rúbrica, con una herramienta que le dice al juez lo que NO debe evaluar. La siguiente estrategia no afina más la pregunta del juez y plantea otra previa: si tiene sentido usar un juez y dónde.

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. La hibridación determinista es la más sencilla de las estrategias de esta serie y también la más fácil de aplicar medio bien. Algunas preguntas sobre un agente tienen una única respuesta correcta (si ha llamado a la herramienta adecuada, si el JSON se puede parsear, si ha elegido la opción B), y basta una comparación de cadenas, una regex o un parser para resolverlas. Otras no la tienen (si la respuesta ha sido útil de verdad), y ahí una regex no sirve. La estrategia consiste en usar cada método donde encaje y en dejar el reparto a la vista. Hay una herramienta, Inspect AI, que acierta con la arquitectura.

Aquí la leo en su código fuente, en el commit ff29dc9 (abril de 2026), al que apuntan las referencias a ficheros y líneas y los fragmentos de código.

La intuición

Cuando tienes un LLM en el stack, lo cómodo es usarlo para todo y pedirle que puntúe esta salida, que compare estas dos, que valore esto de 0 a 3. Cada evaluación se convierte así en un prompt, y cada prompt cuesta entre una fracción de céntimo y unos pocos céntimos, además de unos segundos. Con mil muestras y cuatro evaluadores, la evaluación acaba costando más que la propia ejecución.

En realidad, muchas de las preguntas que haces en una evaluación no necesitan un modelo de lenguaje. Para «¿Ha llamado el agente a get_weather con la ciudad correcta?» basta una comparación de cadenas; para «¿Incluye la respuesta el nombre del usuario?», una búsqueda de subcadena, y para «¿Es la salida un objeto JSON válido que cumple este esquema?», un parser. Son comprobaciones más baratas, más rápidas y deterministas (la misma entrada da siempre la misma respuesta), y puedes ejecutarlas en local, en bucle y gratis.

El reflejo de meter un LLM en todo viene de que las herramientas actuales te empujan a ello. La mayoría de los frameworks de evaluación con LLM ponen en primer plano sus evaluadores con juez porque es lo que los distingue, la capacidad nueva que los convierte en frameworks de evaluación con LLM y los separa de un ejecutor de tests corriente. Los evaluadores por coincidencia, regex o patrón están ahí, pero parecen un paso atrás. El usuario se pregunta por qué iba a usar otra cosa teniendo un juez potente.

Porque el juez es la herramienta adecuada para unas preguntas y la equivocada para otras. Hay que usar cada método donde encaje. Lo más difícil es hacer explícito el reparto para que un revisor pueda auditarlo.

Inspect AI, paso a paso

Inspect AI define Scorer como un Protocol estructural, sin clase base de la que heredar (scorer/_scorer.py:33-61).

@runtime_checkable
class Scorer(Protocol):
    async def __call__(
        self,
        state: TaskState,
        target: Target,
    ) -> Score | None:
        ...

Ese es todo el contrato: un evaluador es un callable asíncrono que recibe el estado de la tarea (entrada, salida del modelo, llamadas a herramientas, metadatos) y el target (la respuesta que espera el dataset) y devuelve un Score o None. Tanto los evaluadores deterministas como los que usan juez cumplen este protocolo, y el framework no los distingue en el sistema de tipos, donde todos son Scorers. El reparto lo decide el usuario, sin que el framework imponga ninguno.

La familia determinista está repartida entre _match.py, _pattern.py, _answer.py, _classification.py y _choice.py (más _math.py). Los evaluadores que trae de serie son match() (comparación de cadenas, con location ∈ begin/end/any/exact), includes() (prueba de subcadena), pattern() (regex sobre la salida), exact() (en ese commit, igualdad del conjunto de tokens normalizado; las versiones actuales comparan la secuencia de tokens normalizada, así que importan el orden y las repeticiones), f1() (F1 al estilo SQuAD, que devuelve un valor continuo de 0 a 1), answer() (un wrapper de regex para LETTER/WORD/LINE) y choice() (opción múltiple mediante state.choices[i].correct). Ninguno importa el tipo Model; son funciones puras de la salida y el target, sin llamada al LLM, sin coste y sin varianza. Tampoco leen las llamadas a herramientas, y para comprobar una basta un evaluador propio de pocas líneas.

La familia con juez está en _model.py y tiene dos puntos de entrada, model_graded_qa() para calificar respuestas abiertas y model_graded_fact() para comparar la salida con una referencia. model_graded_fact es, literalmente, un wrapper de una línea que llama a model_graded_qa con otra plantilla (_model.py:75-83). En los dos casos, la implementación real está en _model_graded_qa_single() (_model.py:154-237). La llamada que importa es esta:

result = await model.generate([scoring_prompt])
match = re.search(grade_pattern or DEFAULT_GRADE_PATTERN, result.completion)

En ese commit, el patrón por defecto para la nota es r"(?i)GRADE\s*:\s*([CPI])(.*)$" (_model.py:293), que falla en cuanto hay algo detrás de la línea de la nota. Si falta la nota, la puntuación es INCORRECT. Las versiones actuales, en cambio, se quedan con el último GRADE: X de la salida ((?is).*(?<!\w)GRADE(?!\w)\s*:\s*([CPI]), simplificado) y, por defecto, dejan sin puntuar un veredicto que no se puede parsear o que no está entre las opciones. El juez tiene que escribir GRADE: C o GRADE: I (o GRADE: P si está activada la puntuación parcial). Como la firma trae partial_credit: bool = False, la calificación es binaria salvo que pidas la parcial.

Conviene reconocer de dónde sale todo esto. Un comentario en _model.py:240-241 dice «these templates are based on the openai closedqa templates» y enlaza a github.com/openai/evals/blob/main/evals/registry/modelgraded/closedqa.yaml. Como las plantillas de OpenAI evals son de 2023, la forma de calificar de Inspect AI es anterior a la mayoría de los frameworks de evaluación con LLM que he leído. Funciona porque quienes la escribieron no tenían prisa por ser originales.

Figura interactiva: Seis tareas de evaluación: elige para cada una la familia de evaluador. La fila de abajo da el coste del reparto actual con 100 muestras (a unos 0,005 $ por llamada al LLM). Ábrela en el artículo para usarla.

Hay dos maneras de componer evaluadores. La primera es multi_scorer(scorers, reducer) (_multi.py:13-30), que ejecuta N evaluadores por muestra y los reduce a un único Score con un reductor (máximo, media, moda o uno propio). La segunda es pasar una lista directamente al constructor de Task (Task(scorer=[exact(), model_graded_qa()])), y entonces cada evaluador aporta al informe su propia columna de métrica, sin necesidad de reductor.

Lo que Inspect AI no trae es la elección de evaluador muestra a muestra. «En esta fila usa exact, en esa usa el juez» no se puede declarar directamente, así que el usuario escribe una función propia decorada con @scorer que decide según state.metadata o target, o divide el dataset en dos tareas. El framework te da las primitivas y deja en tus manos la decisión del reparto.

El detalle más revelador está en _model.py:341-354,372-414. Los marcadores [BEGIN DATA] ... [END DATA], que delimitan la salida del agente dentro del prompt de calificación, se sanean en todos los campos no fiables (el answer del modelo y, del dataset, la question, el criterion y los metadatos). Si esos marcadores aparecen en un texto que controla el usuario, sus espacios se sustituyen por guiones. Un comentario lo deja claro: «Literal space (not \s) is intentional — \s also matches U+00A0 (NBSP), which would let a model pre-neutralize its own output and bypass the mitigation». Los mantenedores han tenido en cuenta la inyección de prompts dirigida al propio juez. En las demás herramientas de evaluación de código abierto es raro encontrar una mitigación comparable.

Y hay que reconocerle el mérito. Entre las herramientas de evaluación de código abierto de esta serie, el protocolo Scorer de Inspect AI es el que mejor separa los evaluadores deterministas de los que usan juez. Hay una sola interfaz, las dos familias la cumplen y el usuario elige en cada tarea. Los mantenedores lo dicen sin rodeos (docs/scorers.qmd:55) y describen model_graded_fact() como el evaluador «que se usa cuando la salida del modelo es demasiado compleja para valorarla con un simple evaluador match() o pattern()». Calificar con un juez es el plan B.

Lo que pierdes

Te toca pensar. La mayoría de las veces está claro si conviene match() o model_graded_qa(). Las respuestas exactas piden una coincidencia exacta y las abiertas, un evaluador con juez. Los casos difíciles están en medio, como una respuesta estructurada que el modelo puede formular de otra manera, un nombre de función que puede venir con otras mayúsculas o una respuesta numérica en la que el modelo puede poner la unidad o no. Ahí eliges tú, sin ayuda del framework. Eso es una ventaja cuando quien elige sabe lo que hace, y un coste cuando no lo sabe.

El reparto se decide tarea a tarea. En Inspect AI, una Task asocia un evaluador (o una lista fija de evaluadores) a todo el dataset y no se puede cambiar de una muestra a otra. Si 800 de tus 1000 muestras pueden usar coincidencia exacta y 200 necesitan un juez, no hay forma de declararlo sin más. Tienes que escribir un evaluador propio que elija según los metadatos o partir el dataset en dos tareas. Las dos soluciones funcionan, pero ninguna cabe en una línea. Lo que falta es una primitiva para mezclar tipos de evaluador muestra a muestra, justo donde un framework más ambicioso automatizaría la decisión.

Además, el prompt del juez es un valor por defecto que se puede cambiar. model_graded_qa(template=..., instructions=..., grade_pattern=...) lo adapta a cada tarea, las claves de los metadatos de la muestra hacen de variables de la plantilla y el criterio sale del target de cada muestra. Para la mayoría de las preguntas abiertas basta con la plantilla por defecto, porque una calificación genérica sí generaliza. Cuando necesitas otro protocolo de calificación (llamadas encadenadas al juez, salida estructurada, un veredicto que una sola regex no puede extraer), vuelves a tener que escribir un @scorer propio y llamar tú mismo a model.generate(). Es la misma vía de escape que te da cualquier otro framework y cumple su función, pero ya no cabe en una línea.

Cuándo encaja este enfoque

Para saber si te conviene esta estrategia basta una pregunta.

¿Alguna de tus preguntas de evaluación se puede responder con una regex? La mayoría de las evaluaciones tienen al menos una: las llamadas a herramientas tienen una respuesta correcta, las salidas estructuradas siguen un esquema, las respuestas numéricas tienen un valor esperado y la respuesta de una tarea de opción múltiple es una letra. Si pagas una llamada al LLM para comprobar si el JSON se puede parsear, gastas dinero en lo que un parser hace gratis y le añades la varianza del juez a una pregunta que no tiene ninguna.

Puntuar con un juez compensa cuando la respuesta es subjetiva de verdad, por ejemplo al decidir si la contestación ha sido útil, si el resumen es fiel o si el tono es el adecuado. Son preguntas cuya respuesta no sale de ninguna comparación de cadenas, y para ellas el juez es la herramienta adecuada. Eso sí, recurrir a él tiene que ser siempre una decisión explícita.

Lo que la hibridación determinista no resuelve es el problema de calibración de los propios evaluadores con juez. Al repartir el trabajo, la varianza queda localizada: todo lo determinista sale impecable y todo lo que pasa por el juez arrastra el ruido que la serie viene documentando. El evaluador con juez es un LLM, y es justo en el LLM donde está la cuestión de la calibración. Algunas herramientas te dan, pese a ese ruido, un intervalo estadísticamente válido sobre la puntuación agregada (el ARES de la parte 4), pero la mayoría no. La última parte de la serie se ocupa de la brecha que nadie cierra.

Como regla práctica, cada regex que puedas escribir es una llamada al LLM menos que depurar. Usa el juez donde haga falta y en ningún otro sitio.

Parte 6 de 7. La hibridación determinista reparte la evaluación entre las preguntas que puede responder una regex y las que tiene que responder un juez. Entre las herramientas de evaluación de código abierto de esta serie, el protocolo Scorer de Inspect AI es el que hace el reparto más limpio, con una sola interfaz que cumplen tanto los evaluadores deterministas como los que usan juez, y deja que el usuario elija en cada tarea. La última parte se ocupa de la brecha de calibración que nadie cierra. Si has llegado aquí directamente, la parte 1 pone nombre a la varianza, la parte 2 la acota con veredictos binarios, la parte 3 divide un juicio difícil en un grafo de juicios más pequeños, la parte 4 mide la certeza de la respuesta y la parte 5 le dice al juez qué ignorar.

Forma parte de la misma serie y está relacionado con un artículo que presenté en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

La rúbrica negativa: decirle al juez qué NO debe evaluar

Carlos Chinchilla Corbacho — Tue, 11 Aug 2026 00:00:00 GMT

La parte 4 repasaba dos herramientas que intentaban medir hasta qué punto estaba seguro el juez, una dentro de una sola llamada y otra a lo largo de muchas. La siguiente estrategia deja de lado la certeza. Se plantea, de entrada, a qué pregunta debería responder el juez y le dice expresamente qué tiene que dejar fuera.

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. El anclaje por rúbrica es la estrategia que más fácil me ha resultado reconocer y la que más me ha costado precisar. La mayoría de las herramientas que usan un LLM como juez enuncian el criterio que hay que puntuar y ahí se quedan. Hay una, TruLens, que añade una segunda cláusula con lo que queda fuera del alcance del juicio. Lo normal es que los prompts no la lleven, pero cuando aparece no está de adorno.

Aquí la leo en el código fuente de TruLens 2.8.0, que es la versión a la que apuntan las referencias a ficheros y líneas.

La intuición

Una rúbrica es un contrato con el juez («puntúa esto en esta escala») y lo que el juez lee es su redacción. Lo que el contrato no dice, el juez lo rellena con lo que ha visto: su distribución de entrenamiento, su idea preconcebida de cómo es una buena respuesta, el solapamiento implícito entre esta métrica y todas las rúbricas que haya puntuado antes. Esos supuestos actúan en silencio y se notan en la puntuación, pero en el prompt no aparecen.

La rúbrica negativa le da la vuelta a lo habitual. Escribes el criterio y enumeras lo que el juez debe pasar por alto, sin confiar en que sepa interpretarlo bien por su cuenta. Si lo que puntúas es la calidad del plan, no menciones si el plan salió bien. Si puntúas las llamadas a herramientas, la elección de la herramienta es asunto de una métrica hermana, así que no la toques. La eficiencia de la ejecución se fija en el orden de los pasos y no le incumbe que el agente llegara o no al objetivo. Así se acota a propósito lo que el juez puede sopesar.

Suena defensivo, y lo es. La cláusula negativa está ahí porque quien escribió la rúbrica ha visto al juez contar dos veces lo mismo, puntuar lo que no tocaba o contaminar una dimensión con otra. Es la vía por la que esa experiencia previa (lo que el modelo hace mal una y otra vez) entra en el prompt y se queda fijada en él.

Las herramientas de la parte 4 medían a posteriori la incertidumbre del juez, mientras que esta estrategia toca una tecla muy distinta. El juez sigue igual de seguro, pero apunta a un blanco más estrecho.

TruLens, paso a paso

Casi todas las funciones de feedback de TruLens que dependen de un juez LLM, incluidas las siete métricas de agente, acaban en uno de los dos métodos de LLMProvider, generate_score o generate_score_and_reasons (feedback/llm_provider.py:180,283). Los dos montan un par de mensajes [system, user], piden una respuesta estructurada y delegan en _create_chat_completion. El proveedor de OpenAI hace pasar la llamada por una cadena que va tanteando qué admite el modelo. Prueba primero con las salidas estructuradas de la Responses API y, si no funcionan, recurre a Chat Completions.

En los kwargs de la llamada hay un detalle que pasa desapercibido. Con los modelos sin razonamiento la temperatura es 0,0 por defecto. Además, el módulo del proveedor de OpenAI fija en el código, al principio, un SEED: int = 123 y lo añade a la llamada salvo que quien la hace pase su propia semilla (providers/openai/provider.py:23,439-443). Pero la Responses API no acepta seed, así que TruLens la quita y reintenta (provider.py:270-285). La semilla solo llega al modelo cuando se recurre a Chat Completions, donde OpenAI únicamente promete respetarla en la medida de lo posible. Por tanto, la repetibilidad descansa sobre todo en la temperatura 0 y no en la semilla. Para un harness de evaluación es un valor por defecto defendible, aunque no da el determinismo que sugiere esa constante fija.

El prompt de sistema sale de plantillas, con un fichero por dominio: templates/rag.py para las métricas de RAG, templates/quality.py para la calidad general, templates/safety.py para la seguridad y templates/agent.py para las métricas propias de agentes.

Si buscas con grep «do not / don’t / only / regardless / out-of-scope» en todos los ficheros de plantillas, salen treinta y seis coincidencias. Quince están en templates/agent.py y son las que tienen estructura, con bloques In-scope:/Out-of-scope:, remisiones a métricas hermanas y «ignore execution». Las demás, repartidas por el resto de ficheros, son sobre todo fórmulas hechas («respond only as a number»). Llevan el patrón las métricas de plan, de herramientas y de ejecución, pero casi ninguna de las de groundedness, harmfulness, correctness o sentiment.

El caso más claro es el prompt de sistema de PlanQuality (templates/agent.py:212-248). Su primer párrafo, antes de cualquier criterio de puntuación, ya incluye una frase CRITICAL: según la cual el juez fracasa en su tarea en cuanto alude a si el agente siguió el plan o a cualquier parte de la ejecución. El prompt insiste en la exclusión al menos tres veces más («Do NOT infer or fill gaps using execution steps.», «You are judging the strategy, not the outcome.», «Do NOT score on the execution quality.»). Es, además, el más largo de los siete prompts de sistema de agente, casi el doble que el siguiente.

El ejemplo más estructurado está en el prompt de sistema de ToolCalling (templates/agent.py:361-363), donde TruLens abre una sección con nombre propio:

Important scope boundaries:
- In-scope: argument/schema correctness, semantic fit of query,
  preconditions/postconditions, grounded interpretation of outputs,
  explicit handling of tool-returned errors.
- Out-of-scope: tool selection (Tool Selection), workflow efficiency
  (Execution Efficiency), external service/tool reliability (Tool Quality).

Fíjate en las referencias entre paréntesis. Las cláusulas de exclusión nombran las métricas hermanas a las que el juez debe remitirse. ToolSelection (agent.py:305-308) y ToolQuality (agent.py:416-418) llevan también un bloque Important scope boundaries:, así que las tres métricas de herramientas comparten ese encabezado, aunque cada una redacta el bloque a su manera. ToolSelection, por ejemplo, usa viñetas «Do NOT penalize …». Solo ella y ToolCalling nombran las métricas hermanas en las que delegan. El terreno que juzga cada una de las siete métricas de agente se ha repartido a mano (ToolCalling, ToolSelection, ToolQuality, ExecutionEfficiency, PlanQuality, PlanAdherence, LogicalConsistency): la mayoría de las rúbricas le dicen al juez qué tiene que dejarles a las otras.

Encima de todo eso se injerta la capa de CoT, igual en las siete métricas de agente. COT_REASONS_TEMPLATE está en templates/base.py:198-206 y es un esqueleto fijo, «Criteria: …, Supporting Evidence: …, Score: …». Cada método *_with_cot_reasons de las métricas de agente sustituye la etiqueta final del prompt de usuario por ese bloque, con user_prompt.replace("<METRIC> SCORE:", COT_REASONS_TEMPLATE). La clave exacta varía según la métrica (TOOL CALLING SCORE:, LOGICAL CONSISTENCY SCORE:, etc.). El prompt de sistema, que es donde están las cláusulas negativas, no se toca. (Las métricas de criterios al estilo de LangChain, en cambio, añaden la misma plantilla al prompt de sistema.)

Después de tanto prompt, la puntuación en sí es poca cosa. El espacio de salida por defecto es una escala Likert de 0 a 3 (templates/base.py:179) y el modelo devuelve un JSON estructurado. Si falla el parseo, la ruta de CoT le pide primero al LLM que reformatee la respuesta como JSON estricto, y solo entonces el código recurre a una expresión regular que captura los tokens numéricos y se queda con los que caen dentro de la escala (generated.py:35,97). Si quedan varios números dentro del rango, elige el mínimo. Según el comentario del código, es para que «1 out of 3» se lea como 1, pero así también «between 1 and 3» se convierte en 1, un comportamiento por defecto que sesga a la baja la puntuación de las respuestas que no se mojan. Y con la escala de 0 a 3 por defecto, «5 out of 10» da error de parseo y no cuenta como un 5. Casi nunca importa, hasta el día en que importa. El número aceptado se normaliza después a un float entre 0 y 1 con (raw - min) / (max - min), y ese float es lo que ve el usuario.

Conviene ver esto en su justa medida. En TruLens la rúbrica negativa aparece solo donde hacía falta; no es un principio de diseño general que recorra todos los prompts. Es un invento de la evaluación de agentes, añadido cuando TruLens 2.x incorporó siete métricas de agente que necesitaban distinguirse entre sí. Si lees las rúbricas más antiguas (RAG, calidad, seguridad), verás que las cláusulas negativas escasean o desaparecen.

Lo que pierdes

Crecen las dos mitades del prompt. Las cláusulas negativas alargan la rúbrica y, con ello, encarecen en tokens cada llamada de puntuación. En una puerta de CI que lanza cientos de llamadas de feedback en cada evaluación, ese coste se nota, aunque pasa lo mismo con cualquier rúbrica estructurada.

Figura interactiva: Una rúbrica ilustrativa y simplificada al estilo de PlanQuality, montada capa a capa. Las líneas CRITICAL y «strategy, not outcome» son texto real de TruLens (agent.py:212, 225) y la capa de CoT es una versión abreviada de la plantilla de base.py. La rúbrica base y el bloque de alcance son inventados (PlanQuality no tiene bloque de alcance) y se dejan en inglés, como los prompts de TruLens. Como la rúbrica base es corta, el crecimiento sale exagerado: en el prompt de sistema real de PlanQuality, de unos 1400 tokens sin contar la traza, las frases de exclusión son más o menos una décima parte. Ábrela en el artículo para usarla.

El coste más grave no se ve. Si una cláusula negativa está mal, le dice al juez que ignore justo la señal que debería sopesar. La creencia previa del autor queda codificada en el prompt y la métrica entera descansa sobre ella. Si esa creencia es errónea, la métrica se equivoca igual en todos los casos de test, sin hacer ruido y sin un parser que lo detecte.

El patrón exige además que haya algo que desambiguar. TruLens lo necesitaba porque sus siete métricas de agente se solapan, mientras que un juez con un único propósito (una rúbrica, una puntuación) no tiene de qué desmarcarse. En ese caso, la cláusula negativa se queda en adorno («no penalices la verbosidad»), luego en letra muerta y en la siguiente revisión se borra. Por otro lado, el anclaje por rúbrica estrecha la pregunta que se le hace al juez, pero no su salida, que sigue siendo un Likert de 0 a 3 normalizado a un float entre 0 y 1. La varianza que haya al producir ese entero no se ha ido a ninguna parte. Has cambiado qué se puntúa, pero la puntuación es igual de estable que antes.

Cuándo encaja este enfoque

Para saber si esta estrategia te sirve basta con una pregunta.

¿Tienes más de una métrica que razonablemente podría sopesar los mismos indicios? Si es así, el anclaje por rúbrica es lo más barato que puedes hacer para que no cuenten dos veces lo mismo. Tanto la calidad del plan como la eficiencia de la ejecución tienen algo que decir sobre si el agente tuvo éxito. Si el prompt de cada una le dice al juez que ignore el terreno de la otra, las dos siguen midiendo cosas distintas. En cambio, si tu juez tiene una sola rúbrica y un solo veredicto, las cláusulas negativas no añaden nada que puedas verificar y el prompt crece en balde.

Su sitio natural es la evaluación de agentes, porque en cuanto puntúas por separado el plan, la ejecución y las herramientas, es inevitable que los criterios se solapen. Con RAG quizá se gane un poco; con calidad y seguridad, normalmente nada.

Lo que el anclaje por rúbrica no te dice es si la rúbrica es la adecuada. Las cláusulas negativas codifican la creencia previa del autor sobre dónde falla el juez, una creencia que no pasa de conjetura mientras nadie la mida. La siguiente parte repasa una herramienta que ataca el mismo problema desde el lado contrario y se pregunta en qué casos puedes prescindir del juez por completo y quedarte con comprobaciones deterministas.

Como regla práctica, el anclaje por rúbrica es lo que escribes cuando has visto al juez hacerse un lío. Si aún no te ha pasado, no lo necesitas. Si ya te ha pasado, sabrás qué tiene que ignorar.

Parte 5 de 7. El anclaje por rúbrica consiste en decirle al juez qué puntuar y, después, qué ignorar. Las cláusulas de rúbrica negativa que TruLens usa en sus métricas de agente son el punto por donde la experiencia previa de quien escribe la rúbrica (lo que el juez hace mal una y otra vez) entra en el prompt y se queda fijada en él. La siguiente parte repasa una herramienta que va más allá y se pregunta en qué casos puedes prescindir del juez por completo. Si has llegado aquí directamente, la parte 1 pone nombre a la varianza, la parte 2 la acota con veredictos binarios, la parte 3 divide un juicio difícil en un grafo de juicios más pequeños y la parte 4 mide la certeza de la respuesta.

Forma parte de la misma serie y está relacionado con un artículo que presenté en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

Cuando los jueces muestran su incertidumbre: DeepEval y ARES

Carlos Chinchilla Corbacho — Tue, 04 Aug 2026 00:00:00 GMT

La parte 3 analizaba una herramienta que divide un juicio en otros más pequeños, un grafo de preguntas binarias en el que el camino recorrido decide la puntuación. La estrategia que toca ahora, la calibración probabilística, deja de dividir y se pregunta otra cosa. Ejecuta el juicio una sola vez e intenta medir cuánta certeza hay detrás de la respuesta.

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. La calibración probabilística es la estrategia sobre la que más me ha costado formarme una opinión, porque dos herramientas llegan a ella por caminos bien distintos. DeepEval lee la incertidumbre dentro de una sola llamada al juez, en las probabilidades que el propio modelo asigna a los tokens. ARES coloca un intervalo de confianza formal alrededor de la puntuación que da el juez sobre un conjunto de evaluación. La primera devuelve un número más fino y la segunda, un intervalo que puedes defender.

En esta parte leo el código fuente de las dos.

La intuición

La incertidumbre de un juez LLM está en dos sitios, y cada herramienta va a por uno de ellos.

El primero está dentro de una sola llamada. Aunque la respuesta JSON dé otra impresión, el juez nunca se queda con un único entero. Lo que produce es una distribución sobre los enteros que ha considerado, con la mayor parte de la probabilidad en «4», algo en «3» y «5» y una pizca en el resto. La dispersión de esa distribución es la incertidumbre que expresa el juez, una señal de confianza aunque no esté calibrada. Un juez que pone el 99 % de su masa en «4» está seguro; uno que reparte un 35 %, un 30 % y un 25 % entre «3», «4» y «5» está dudando. El entero en bruto esconde los dos casos detrás del mismo número.

El segundo está entre llamadas. Si ejecutas el juez sobre mil entradas y promedias las puntuaciones, tienes la cifra de un benchmark. Si lo ejecutas sobre una muestra más pequeña con etiquetas de referencia humanas, tienes una medida de su sesgo. Al combinar las dos cosas puedes pasar de un punto a un intervalo, el intervalo de confianza que escribiría un estadístico. El juez sigue igual de ruidoso que antes y lo único que haces es acotar cuánto podría equivocarse la cifra agregada.

La función de DeepEval que consume el primer tipo de incertidumbre, calculate_weighted_summed_score, ya salió en la parte 3. Allí lo que importaba era que la ponderación por probabilidad recupera un número continuo a partir de una escala de enteros. Aquí la función hace otra cosa: la dispersión de la distribución es la confianza que expresa el juez, aunque el campo de la puntuación nunca la devuelva. ARES va a por el segundo tipo desde un ángulo que no tiene nada que ver, con la maquinaria estadística de un artículo de 2023 sobre prediction-powered inference. Son dos caminos para el mismo problema, con un código muy distinto en cada uno.

DeepEval: una distribución detrás de cada puntuación

Para puntuar un caso de prueba, GEval hace una sola llamada y en ella pide también las log-probabilidades del token de la puntuación. La llamada al proveedor necesita un endpoint compatible con OpenAI Chat Completions (las ramas del código para OpenAI, Azure, LiteLLM y las pasarelas OpenRouter/Portkey la repiten cada una por su cuenta, y el resto de proveedores se quedan con el entero en bruto). Los parámetros se pasan explícitamente.

completion = client.chat.completions.create(
    model=self.name,
    messages=messages,
    temperature=self.temperature,
    logprobs=True,
    top_logprobs=top_logprobs,
    **self.generation_kwargs,
)

top_logprobs es un parámetro del constructor de GEval que por defecto vale 20, el tope de la API de OpenAI, aunque DeepEval lo recorta según el modelo (a gpt-5.4, su juez por defecto, le deja 5). Para cada token generado, la respuesta trae hasta ese número de alternativas a las que el modelo daba alguna probabilidad. La distribución la pone el proveedor y GEval la consume.

Luego está el suelo de ruido. En la parte 3 ya vimos el cuerpo del bucle de calculate_weighted_summed_score, el que descarta los tokens con menos de un 1 % de probabilidad lineal y suma el resto según su peso. El umbral del 1 % es una variable local fija en el código.

# Filter out tokens with <1% linear probability, i.e., logprobs < math.log(0.01)
min_logprob = math.log(0.01)

No se puede configurar ni se expone, y ni siquiera es una constante. Es un número mágico metido en el cuerpo de la función. El punto en el que el ruido del juez deja de contar lo ha fijado el autor de GEval.

Figura interactiva: La distribución del juez sobre las puntuaciones enteras. Arrastra el control de concentración: la puntuación ponderada se queda en 4,00 y la distribución sigue siendo simétrica, pero la confianza del juez sí cambia. GEval.score no registra ni la distribución ni la confianza. Ábrela en el artículo para usarla.

Mueve el control de concentración. La puntuación ponderada se queda en 4,00 porque la distribución es simétrica y la ponderación por probabilidad respeta la simetría. Lo que sí cambia con la dispersión es la etiqueta de al lado, que salta entre confianza «alta» y «baja». Esa etiqueta es lo que GEval no devuelve.

A la salida de la métrica, todo se reduce a un número. La distribución pasa entera por calculate_weighted_summed_score y acaba convertida en un único escalar normalizado.

self.score = (
    (float(g_score) - self.score_range[0])
    / self.score_range_span
    if not self.strict_mode
    else int(g_score)
)
self.success = self.is_successful()  # score >= threshold

A partir de ahí, quien llama a la métrica puede leer score, success, reason, verbose_logs, los pasos de evaluación, el coste y el número de tokens, y ningún otro dato que salga de la distribución. No hay probabilidades por token, ni recuento de tokens descartados, ni entropía, ni segundo momento. La media ponderada es el veredicto, y el aprobado o el suspenso sale de compararla con el umbral. La distribución del juez ha alimentado la puntuación y luego se ha esfumado.

Para ser justos, GEval implementa fielmente la receta de Liu et al. (2023). La ponderación por probabilidad es el recurso que recupera una puntuación continua a partir de una rúbrica de enteros, y DeepEval la incorpora de forma limpia, con un filtro del 1 % comentado (aunque fijo en el código) y un valor por defecto razonable. El mecanismo es correcto. Lo que falta está en la interfaz con quien llama, porque la información solo existe mientras dura una llamada a una función y nada en la API la devuelve.

ARES: un intervalo de confianza alrededor de la puntuación

ARES se hace otra pregunta. Cambia «¿cómo de seguro está el juez de esta entrada concreta?» por «¿cómo de seguro puedo estar de la puntuación agregada, sabiendo que una pequeña parte tiene etiquetas de referencia?». El juez de ARES es, por defecto, un clasificador DeBERTa-v3-large ajustado, aunque se puede sustituir por un juez LLM. Sea cual sea, devuelve una predicción de 0 o 1 por cada ejemplo. Lo interesante del código es lo que ARES hace con esas predicciones.

Todo parte de tres arrays. En Y_labeled están las etiquetas de referencia humanas de un subconjunto pequeño anotado, normalmente unos pocos cientos de ejemplos; en Yhat_labeled, las predicciones del juez sobre esos mismos ejemplos, y en Yhat_unlabeled, sus predicciones sobre el conjunto de evaluación grande, el que no tiene etiquetas. Con eso, una sola función se encarga de toda la estadística.

def pp_mean_iid_asymptotic(Y_labeled, Yhat_labeled, Yhat_unlabeled, alpha):
    n = Y_labeled.shape[0]
    N = Yhat_unlabeled.shape[0]
    tildethetaf = Yhat_unlabeled.mean()
    rechat = (Yhat_labeled - Y_labeled).mean()
    thetahatPP = tildethetaf - rechat
    sigmaftilde = np.std(Yhat_unlabeled)
    sigmarec = np.std(Yhat_labeled - Y_labeled)
    hw = norm.ppf(1 - alpha / 2) * np.sqrt(
        sigmaftilde ** 2 / N + sigmarec ** 2 / n
    )
    return [thetahatPP - hw, thetahatPP + hw]

Ese es el estimador entero, y tiene tres piezas.

La primera es la estimación puntual. tildethetaf es la media del juez sobre el conjunto sin etiquetar, un número que arrastra el sesgo del juez si lo tiene. rechat es el error medio del juez sobre el subconjunto etiquetado, mean(Yhat - Y). Al restar uno de otro sale thetahatPP, la puntuación agregada del juez una vez descontado el sesgo que se le ha medido. Lo que hace posible la corrección es el subconjunto etiquetado, porque sin etiquetas de referencia no hay rechat ni rectificación.

La segunda es el intervalo. hw es la semiamplitud y suma dos términos: sigma_f² / N, del juez sobre el conjunto grande sin etiquetar, y sigma_rec² / n, del rectificador sobre el pequeño etiquetado. Como el conjunto sin etiquetar suele ser varios órdenes de magnitud mayor, su suelo es pequeño y el término que domina es el del rectificador. Con el alpha=0.05 por defecto, el multiplicador Z ronda 1,96, el del intervalo del 95 % de toda la vida.

Figura interactiva: La semiamplitud del intervalo PPI tiene dos términos de varianza: uno se reduce al crecer el conjunto etiquetado por humanos n, y el otro, al crecer el conjunto sin etiquetar N. Al arrastrar los dos controles, el intervalo se estrecha y cambia el reparto de la varianza. Ábrela en el artículo para usarla.

Lo que añade ARES es el par [thetahatPP - hw, thetahatPP + hw], que se presenta junto a la estimación puntual (el punto medio del par). El ejemplo práctico del README imprime una predicción de 0,606 encima del intervalo [0.547, 0.664]. Ese 0,606 ya viene con el sesgo corregido (no es la media en bruto del juez). El intervalo es lo que permite a quien use el resultado leer «la puntuación agregada real está en este rango con un 95 % de confianza».

Hay dos rarezas que conviene señalar. El conjunto anotado por humanos se limita por defecto a 300 ejemplos (.head(300)), lo que pone un suelo fijo al término del rectificador. Y lo que parece una comparación con el intervalo clásico es código muerto: binomial_iid se llama, pero nunca se importa, así que solo sobrevive el intervalo PPI.

Para ser justos con ARES, la estadística que ha elegido es la primitiva adecuada para la pregunta que se hace. PPI es reciente (Angelopoulos et al. (2023)), y la mayoría de las herramientas de evaluación todavía no han asimilado que «tenemos un conjunto de referencia pequeño y un conjunto grande sin etiquetar» es un caso con un estimador ya publicado. ARES lo ha recogido y lo ha llevado al código. Solo por eso ya merece la pena leerlo.

Lo que pierdes

Los dos caminos tienen un precio, y cada uno lo paga a su manera. DeepEval lo paga en la interfaz. La distribución existe dentro de una llamada, la función la usa y después deja de existir para quien llama. Una puerta de CI que decide con self.score >= self.threshold no puede preguntar «¿ha sido un aprobado seguro o uno dudoso?», porque el campo que lo respondería no existe. ARES lo paga en etiquetas humanas, unos pocos cientos de ejemplos anotados (usa 300 como máximo y el README pide al menos 50). Para un artículo o un benchmark de cara a un regulador es un coste que se paga una vez; para una puerta de CI que se ejecuta en cada PR, es prohibitivo. Cada herramienta paga el coste que encaja con el uso para el que está pensada, y en ninguna de las dos es un descuido.

El prompt también las separa. La ponderación por probabilidad trata el prompt como algo fijo y no acota el eje de sensibilidad al prompt que señalaba la parte 1. Si reformulas la rúbrica, la distribución varía, pero la función sigue informando de la confianza dentro de ese prompt como si nada hubiera cambiado. PPI, en cambio, está anclado en otro sitio. Como son las etiquetas humanas las que definen el objetivo, reformular el prompt del juez cambia la amplitud del intervalo, pero no lo que el intervalo estima, siempre que el conjunto de referencia siga correspondiendo al sistema. La ponderación por probabilidad calibra dado el prompt. Calibrar entre prompts es otro problema que pide su propio artículo.

Cuándo encaja este enfoque

Qué camino tomar, o si conviene alguno, depende de una sola pregunta.

¿Lo que produces es una puntuación o una medida? Una puntuación es lo que lee una puerta de CI, un número para hoy y para esta PR. Una medida es lo que lleva un artículo, una tabla de clasificación o un informe de auditoría, es decir, una afirmación sobre el agregado que tiene que sostenerse cuando la examinen a fondo. Como primitiva de puntuación, la ponderación por probabilidad de DeepEval es mejor: es barata, necesita una sola llamada, no exige anotar nada y devuelve un número continuo que respeta las dudas del juez. El PPI de ARES, en cambio, es una primitiva de medida. Devuelve un intervalo cuya amplitud se puede discutir y cuyos supuestos se pueden auditar, pero el término del rectificador necesita unos pocos cientos de etiquetas de referencia, presupuestadas una sola vez. Cuantas menos tengas, más ancho sale el intervalo. Si no puedes pagarlo, PPI queda descartado.

Ninguna de las dos te da un juez cuyos veredictos se mantengan estables cuando reformulas el prompt. Si lo que ha cambiado entre despliegues es la rúbrica, DeepEval se adaptará sin avisar y dará cifras nuevas que no se pueden comparar con las anteriores. ARES sigue anclado a sus etiquetas de referencia, a costa de tener que mantenerlas al día. La siguiente parte analiza una herramienta que ataca ese problema sin medir la incertidumbre. Lo que hace es decirle al juez de antemano qué partes del juicio tiene que dejar fuera.

Si hay que quedarse con una regla, la ponderación por probabilidad es un adorno sobre un único juicio y PPI es inferencia estadística sobre una población de juicios. Elige la que trabaje al mismo nivel de análisis que la pregunta que te piden responder.

Parte 4 de 7. La calibración probabilística tiene dos caminos para decirte lo seguro que está el juez (las probabilidades de los tokens dentro de una llamada y un intervalo de confianza alrededor de un agregado). La siguiente entrega analiza una herramienta que ni siquiera intenta medir la incertidumbre del juez: le dice de antemano qué partes del juicio debe dejar fuera. Si has llegado aquí directamente, la parte 1 pone nombre a la varianza, la parte 2 la acota con veredictos binarios y la parte 3 divide un juicio difícil en un grafo de juicios más pequeños.

Forma parte de la misma serie y está relacionado con un artículo que presenté en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

De la rúbrica al grafo: cómo divide DeepEval un juicio

Carlos Chinchilla Corbacho — Tue, 07 Jul 2026 00:00:00 GMT

La parte 2 analizaba una herramienta que acota la varianza del juez limitando lo que puede decir. Ragas cambia la puntuación de 1 a 5 por un veredicto de sí o no, así que el juez ya no se mueve por una escala y solo puede caer a un lado u otro de una línea.

Esta vez toca otra herramienta. Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. DeepEval acota la varianza cambiando la pregunta, sin tocar en absoluto la salida del juez. Divide el juicio, que planteado de golpe es una sola pregunta difícil, en una secuencia (o un grafo) de preguntas más pequeñas, cada una más fácil que el conjunto. En eso consiste la estrategia de descomposición estructural.

DeepEval la ofrece de dos formas. G-Eval organiza el juicio como una lista de comprobación ordenada, y el DAG, como un grafo ramificado que el juez está obligado a recorrer. Aquí leo las dos directamente en el código fuente.

La intuición

«¿Es bueno este resumen?» es una sola pregunta, pero contestarla exige dar al menos cuatro respuestas: si es fiel a la fuente, si cubre los puntos principales, si es conciso y si es coherente. Un juez que recibe la pregunta entera tiene que sopesar las cuatro y reducirlas a un solo número. Todas esas subdecisiones se toman dentro del modelo (como mucho quedan parafraseadas en el motivo, nunca desglosadas), y el peso de cada una es el que el modelo haya decidido en esa ejecución.

La herramienta de la parte 2 recortaba la salida del juez para dejarle menos cosas que decir y menos margen para oscilar. La descomposición deja la salida como está y recorta la pregunta haciendo las cuatro subpreguntas por separado. «¿Todas las frases tienen respaldo en la fuente, sí o no?» es una pregunta más concreta que «¿esto es bueno?», y una pregunta más concreta tiene menos varianza. El juez abarca menos cosas a la vez y tiene menos formas de contradecirse.

También cambia de sitio la regla de combinación. En un juez monolítico esa regla está implícita en los pesos del modelo y es distinta en cada ejecución. Al descomponer, la regla pasa a código escrito por ti, ya sea una media, un umbral o una rama. Y el código no tiene varianza. No has hecho más fiable al juez (cada subllamada sigue siendo una llamada a un LLM), pero has sacado del modelo la tarea de juntar las partes. Ya no te puede sorprender cómo se han ponderado, porque las has ponderado tú.

Las dos formas se diferencian en una sola cosa: una sigue pidiéndole al juez una puntuación, solo que le da mejores instrucciones, y la otra no se la pide nunca.

G-Eval, paso a paso

G-Eval es la forma más suave. La métrica GEval de DeepEval parte de una cadena criteria en lenguaje natural o de una lista explícita evaluation_steps.

class GEval(BaseMetric):
    def __init__(
        self,
        name: str,
        evaluation_params: Optional[List[SingleTurnParams]] = None,
        criteria: Optional[str] = None,
        evaluation_steps: Optional[List[str]] = None,
        ...
    ):
        ...
        if criteria is not None or evaluation_steps is not None:
            validate_criteria_and_evaluation_steps(criteria, evaluation_steps)

El validador exige al menos una de las dos, y si pasas las dos mandan los pasos explícitos. Si le das criteria, la métrica convierte esa única frase en pasos antes de que el juez puntúe un caso de prueba.

def _generate_evaluation_steps(self, multimodal: bool) -> List[str]:
    if self.evaluation_steps:
        return self.evaluation_steps

    g_eval_params_str = construct_g_eval_params_string(self.evaluation_params)
    prompt = self._get_prompt(
        "generate_evaluation_steps",
        criteria=self.criteria,
        parameters=g_eval_params_str,
        multimodal=multimodal,
    )
    return generate_with_schema_and_extract(
        metric=self, prompt=prompt, schema_cls=gschema.Steps, ...
    )

El prompt es una sola instrucción: «generate 3-4 concise evaluation steps based on the criteria». El artículo de G-Eval, Liu et al. (2023), llama a estos pasos cadena de razonamiento (chain of thought). DeepEval genera esa cadena a partir de tu criterio antes de puntuar, con lo que una instrucción vaga se convierte en una lista de comprobación explícita y numerada. Esa lista es la descomposición. La instancia de la métrica la guarda, pero evaluate() (asíncrona por defecto) puntúa cada caso de prueba con una copia nueva de la métrica, de modo que en una ejecución por defecto cada caso recibe su propia lista recién generada. Si quieres la misma lista para todo un dataset, pasa evaluation_steps de forma explícita.

Luego viene la llamada de puntuación. El juez ve los pasos numerados y el caso de prueba y devuelve un objeto JSON con una puntuación y un motivo. La puntuación es un entero dentro de un rango (de 0 a 10 por defecto) que DeepEval normaliza a una métrica entre 0 y 1.

Una puntuación entera es justo la salida de poca resolución que señalaba la parte 1, con los valores amontonados en un mismo entero. Si le pides un entero a un modelo, toda su distribución se reduce a uno solo. Cuando el juez da acceso a las log-probabilidades de los tokens (el juez de OpenAI que DeepEval usa por defecto lo hace), DeepEval no se queda con el entero. Lee las log-probabilidades del token de la puntuación (cada entero que ha considerado el modelo y cuánta probabilidad le ha dado a cada uno) y devuelve la media ponderada por probabilidad.

# inside calculate_weighted_summed_score(...)
min_logprob = math.log(0.01)  # filter out tokens with <1% linear probability
for token_logprob in score_logprobs.top_logprobs:
    logprob = token_logprob.logprob
    if logprob < min_logprob:
        continue
    if not token_logprob.token.isdecimal():
        continue
    linear_prob = math.exp(logprob)
    token_score = int(token_logprob.token)
    # ... accumulate token_score weighted by linear_prob ...
weighted_summed_score = sum_of_weighted_scores / sum_linear_probability

Los tokens con menos del 1 % de probabilidad se descartan, y los que quedan se suman ponderados por su probabilidad. El juez dice «4», pero la puntuación ponderada se queda cerca de 3,8 porque el modelo ponía más probabilidad en el 3 que en el 5. Con eso se recupera una puntuación continua a partir de enteros amontonados, sin hacer una segunda llamada. Los jueces que no dan acceso a las logprobs (los wrappers de DeepEval para Anthropic y Gemini, la mayoría de los modelos personalizados) se quedan con el entero en bruto, y strict_mode hace lo mismo.

Figura interactiva: Un juez LLM rara vez se decide por un solo entero: reparte la probabilidad entre los tokens de puntuación. Arrastra la opinión del juez y verás que la barra azul (el argmax, el entero que daría una puntuación en bruto) va a saltos, mientras que la línea ámbar, la puntuación de DeepEval ponderada por logprobs, se desliza. Ábrela en el artículo para usarla.

Para ser justos con G-Eval, aquí la descomposición es orientativa. Los pasos guían al juez, pero no lo atan, y nada impide al modelo leer el paso tres por encima. A cambio de esa holgura, G-Eval gana alcance. Funciona con cualquier criterio que puedas escribir en una frase y, como la lista se genera sola, no necesitas conocer las subpreguntas de antemano. El juez sigue emitiendo el juicio entero, solo que con mejores instrucciones.

El paradigma DAG

En el DAG, la descomposición sí ata al juez.

Mientras que G-Eval guía al juez y aun así le pide una puntuación, DAGMetric no se la pide nunca. Le das un grafo, un DeepAcyclicGraph, y el juez solo responde a un nodo cada vez. Hay cuatro tipos de nodo.

Un TaskNode es un paso de extracción que hace una llamada al LLM para sacar material intermedio («enumera las afirmaciones del resumen») y se lo pasa a los nodos siguientes, sin puntuar nada por sí mismo.

Un BinaryJudgementNode hace una única pregunta de sí o no y necesita exactamente dos hijos, uno por respuesta.

def __post_init__(self):
    if len(self.children) != 2:
        raise ValueError("BinaryJudgementNode must have exactly 2 children.")
    ...
    verdicts = [child.verdict for child in self.children]
    if verdicts.count(True) != 1 or verdicts.count(False) != 1:
        raise ValueError("BinaryJudgementNode must have one True and one False VerdictNode child.")

Un NonBinaryJudgementNode hace una única pregunta de opción múltiple, y como DeepEval construye el esquema del veredicto en tiempo de ejecución, el modelo no puede salirse de la lista.

self._verdict_schema = create_model(
    "NonBinaryJudgementVerdict",
    verdict=(Literal[tuple(self._verdict_options)], ...),
    reason=(str, ...),
)

Por último, un VerdictNode es el desenlace de una rama y lleva un score o un child, nunca las dos cosas.

def __post_init__(self):
    if self.score is not None and self.child is not None:
        raise ValueError(
            "A VerdictNode can have either a 'score' or a 'child', but not both."
        )
    if self.score is None and self.child is None:
        raise ValueError(
            "A VerdictNode must have either a 'score' or a 'child'."
        )

Si lleva un score, el nodo es una hoja, y si lleva un child, el recorrido continúa.

Ejecutar la métrica consiste en recorrer el grafo. Cada nodo de juicio hace su única llamada y obtiene un veredicto, que decide qué hijo se ejecuta. Los demás hijos terminan sin hacer nada.

# VerdictNode._execute — a branch runs only if its verdict
# matches the parent judgement's verdict
if self._parent._verdict.verdict != self.verdict:
    return

Al final llegas a una hoja, y su score dividido entre diez es la métrica.

Figura interactiva: Una DAGMetric de DeepEval que mide la calidad de un resumen con tres juicios binarios y cuatro hojas con puntuación. Responde a cada pregunta: el camino se ilumina, las ramas descartadas se apagan y la hoja a la que llegas fija la puntuación. Ábrela en el artículo para usarla.

Eso es lo que distingue al DAG de G-Eval. En G-Eval todos los pasos desembocan en una única llamada de puntuación y el juicio lo sigue emitiendo el juez, eso sí, bien informado. En el DAG, en cambio, el juez nunca llega a emitir el juicio. Solo se le pide un veredicto binario o n-ario por nodo, y la puntuación la decide el grafo, que es código escrito por ti. Con los mismos veredictos se recorre el mismo camino y sale el mismo número en todas las ejecuciones. DeepEval rechaza un grafo con algún ciclo antes de ejecutar nada, con un escueto «Cycle detected in DAG graph».

Además, las dos formas se pueden combinar, ya que el hijo de un VerdictNode puede ser un GEval. Cuando una rama ya no necesita bifurcarse más y pide una puntuación graduada, cuelgas un G-Eval de la hoja. El grafo decide el camino y G-Eval puntúa el último tramo. No son rivales; una puede contener a la otra.

Lo que pierdes

La descomposición tiene dos costes.

El primero es que hay más sitios donde equivocarse. Un juez monolítico hace una sola llamada que puede salir mal; un DAG con un nodo de tarea, dos nodos de juicio y cuatro hojas hace tres o cuatro, cada una con su propio riesgo de fallar. Además, esas llamadas se ejecutan en secuencia a lo largo del camino, así que en una puerta de CI ese DAG cuesta entre tres y cuatro veces la latencia y el gasto en API de un único juez global. La falta de fiabilidad del juez sigue ahí, repartida ahora entre más nodos. La apuesta, que se puede perder, es que cada llamada pequeña sea lo bastante fiable para que el producto siga ganando al monolito. El peor caso es un nodo interior, donde un veredicto erróneo manda el recorrido por una rama del todo equivocada y la puntuación cambia de golpe. Si el nodo se equivoca de forma sistemática, se equivoca igual en todas las ejecuciones; si su veredicto está en el límite, la puntuación salta de una rama a otra de una ejecución a la siguiente.

El segundo es que ahora tienes que acertar con la estructura. El grafo es tu teoría del juicio: qué subpreguntas importan, en qué orden y cómo se combinan. Si la teoría está mal, la métrica se equivoca de forma determinista con todas las entradas. G-Eval tiene el mismo problema en versión más suave, porque sus pasos generados automáticamente también los escribe un LLM y la mayoría de la gente no los lee nunca.

Conviene verlo con buenos ojos, como el precio justo de hacer legible un juicio. Un juez monolítico esconde su razonamiento y no puedes ver dónde se ha equivocado; uno descompuesto te señala exactamente de qué nodo desconfiar. Los dos tienen bugs, pero solo uno tiene stack trace.

Cuándo encaja este enfoque

La descomposición compensa cuando se dan tres condiciones.

El juicio tiene partes reales. «Fiel, conciso y completo» se separa limpiamente en tres comprobaciones, pero «¿es elegante esta explicación?» no. Meter con calzador un grafo en un juicio sin costuras solo añade llamadas y una falsa sensación de rigor. Descompón donde el juicio tenga costuras.

Conoces las subpreguntas mejor de lo que el modelo las adivinaría. Si tu descomposición se limita a poner por escrito los pasos implícitos del propio modelo, eso ya lo hace gratis la lista que genera G-Eval. El DAG justifica su complejidad cuando sabes algo que el modelo no deduciría, como un orden, una dependencia o un cortocircuito. Por ejemplo, si falla la comprobación de fidelidad, el recorrido debería pararse antes de gastar una sola llamada en puntuar el estilo.

Necesitas un resultado auditable o estable. Un DAG te da un camino fijo que puedes señalar en una revisión. Cuando hay que explicarle el veredicto de una puerta a alguien que no la ha escrito, el recorrido ya es la explicación, cosa que no ocurre con una puntuación global.

Como regla práctica, recurre a G-Eval cuando quieras una puntuación global mejor a bajo coste, y al DAG cuando el juicio tenga una estructura real que necesites imponer, sin conformarte con sugerirla. Ten en cuenta que entre las dos no hay una frontera nítida y que un G-Eval en la hoja de un DAG es un término medio con todas las de la ley. En el fondo, la herramienta es lo de menos: lo que eliges es cuánto del juicio puedes permitirte dejar dentro del modelo.

Parte 3 de 7. La descomposición estructural divide un juicio difícil en un grafo de juicios más pequeños y le deja la aritmética al código. La siguiente parte repasa una herramienta que no toca el razonamiento del juez y se pregunta, en cambio, cuánto podría desviarse su puntuación. Si has llegado aquí directamente, la parte 1 pone nombre a la varianza y la parte 2 la acota con veredictos binarios.

Forma parte de la misma serie y está relacionado con un artículo que presento en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

El artículo 72 define el bucle, pero tus paneles no lo cierran

Carlos Chinchilla Corbacho — Tue, 16 Jun 2026 00:00:00 GMT

Creía que nuestros modelos ya estaban monitorizados. Teníamos paneles, alertas y un turno de guardia que despertaba a alguien cuando se disparaba la latencia.

Nada de eso era un sistema de vigilancia poscomercialización, al menos en el sentido que le da el artículo 72.

Un panel te dice que el sistema está en marcha. El artículo 72 pregunta otra cosa: si sigue siendo conforme y si puedes demostrarlo durante todo el tiempo que funcione. Al cambiar la pregunta cambian también lo que hay que entregar y quién lo lee. Esta entrada recorre la distancia entre el panel y lo que pide el artículo.

Qué dice exactamente el artículo 72

El artículo 72 del Reglamento (UE) 2024/1689 está en el capítulo de vigilancia poscomercialización y regula qué obligaciones tienen los proveedores de sistemas de IA de alto riesgo desde que el sistema sale al mercado, pasadas ya la evaluación de la conformidad y el marcado CE, y mientras siga en él. Tiene cuatro apartados, y cada uno describe una pieza de un bucle.

El apartado 1 impone la obligación. Los proveedores establecerán y documentarán un sistema de vigilancia poscomercialización proporcionado a la naturaleza de las tecnologías de IA y a los riesgos en juego. Fíjate en documentarán. Lo que se entrega es un sistema documentado, y la simple costumbre de monitorizar no vale. Tiene que poder leerlo una autoridad de vigilancia del mercado, o un organismo notificado si interviene alguno.

El apartado 2 es el motor. El sistema recopilará, documentará y analizará de manera activa y sistemática los datos pertinentes sobre el funcionamiento durante toda la vida útil del sistema, una vida útil que no se acaba en las pruebas de aceptación ni en la última auditoría. Y hay una frase sobre la que gira la mayor parte de esta entrada: «Cuando proceda, la vigilancia poscomercialización incluirá un análisis de la interacción con otros sistemas de IA». En un sistema multiagente procede por definición. La ley recoge el caso multiagente de forma expresa, sin que haga falta deducirlo.

El apartado 3 establece que el sistema se basa en un plan, que a su vez forma parte de la documentación técnica del anexo IV. La Comisión tenía que dar a los proveedores un modelo para ese plan en un acto de ejecución, a más tardar el 2 de febrero de 2026. Quédate con esa fecha, porque más adelante cuento qué fue de ese acto.

El apartado 4 es la cláusula de reutilización. Los proveedores cuyo producto está sujeto a la legislación del anexo I, sección A (productos sanitarios, máquinas) y que ya tienen un sistema y un plan de vigilancia poscomercialización con arreglo a ella pueden integrar en ellos los elementos que piden los apartados anteriores, siempre que la protección sea equivalente. Las entidades financieras pueden hacer lo mismo con sus sistemas del anexo III, punto 5, como los de calificación crediticia.

Entre los cuatro apartados describen un bucle en el que se recopila, se analiza, se documenta en un plan y el resultado vuelve a alimentar el proceso.

Qué se monitoriza hoy en la práctica

Ese es el bucle que describe la ley. Las herramientas de monitorización que un equipo usa de verdad abarcan menos, y el resto de esta entrada trata de esa distancia. La mayoría caben en cuatro grupos, y cada uno responde a una pregunta real.

Detección de deriva. Herramientas como Evidently y NannyML observan las distribuciones de entrada y de salida y avisan cuando cambian. Como no necesita etiquetas, la detección de deriva es lo primero que montan los equipos. Capta justo aquello para lo que está pensada: que los datos de hoy ya no se parecen a los que se usaron para entrenar el modelo.

Métricas por segmento. Desglosan el rendimiento por cohorte, por región o por tipo de entrada y sacan a la luz degradaciones que una cifra agregada esconde. Son útiles y se usan poco.

Plataformas de observabilidad. Con Prometheus, Grafana u OpenTelemetry se miden la latencia, la tasa de errores, el throughput y el coste por petición. Son la columna vertebral de la operación, están maduras y responden a si el sistema está en marcha y a cuánto cuesta mantenerlo así.

Trazas. Registran lo que ha hecho el agente, con un span por cada paso y por cada llamada a una herramienta. Son el grupo más nuevo de los cuatro y el menos asentado.

Las cuatro categorías son legítimas, pero ninguna responde a la pregunta que hace el artículo 72. El desajuste se ve en tres cosas.

La primera es que las cuatro son operativas y ninguna mide el cumplimiento. Te dicen que el sistema está sano, pero no si en uso real se mantiene el nivel adecuado de precisión, solidez y ciberseguridad que los apartados 1 y 3 del artículo 15 te obligan a alcanzar y a declarar. Sano y conforme son afirmaciones distintas, y solo una de ellas está en la ley.

La segunda, que nada relaciona una señal con los artículos. Cuando salta una alerta de deriva, ni una persona ni una herramienta la conectan con el nivel adecuado que el artículo 15, apartado 3, te obliga a declarar, ni con una línea del registro de riesgos del artículo 9. La señal existe, pero falta la correspondencia.

La tercera, que la cláusula de interacción no tiene esquema. Un análisis de la interacción con otros sistemas de IA da por hecho que sabes decir qué sistema influyó en cuál. OpenTelemetry está construyendo spans de agente y multiagente justo para eso, pero las convenciones GenAI siguen marcadas como Development: son un borrador y todavía no un estándar. La cláusula ya está en la ley, mientras que el esquema para cumplirla aún no está terminado.

El mapa del bucle

El gráfico pone seis requisitos, derivados del artículo 72 y de los artículos conexos, frente a lo que ofrecen hoy las herramientas de monitorización.

Figura interactiva: Lo que exigen el artículo 72 y los artículos conexos (9, 26 y 73) una vez que un sistema de IA de alto riesgo sale al mercado, y lo que de verdad ofrecen las herramientas de observabilidad actuales. Dos requisitos son huecos claros, y los demás se cubren en parte: de todos hay alguna pieza, pero ninguno está completo. Ábrela en el artículo para usarla.

Hay dos huecos claros. Los demás requisitos se cubren en parte: de todos hay alguna pieza, pero ninguno está completo.

Dónde se quedan cortas las herramientas

La distancia entre el artículo y las herramientas es mayor en cuatro puntos.

Señales de cumplimiento frente a métricas de operaciones. Una alerta de deriva es un evento de operaciones, y solo pasa a ser un evento de cumplimiento cuando alguien la relaciona con el nivel adecuado que el artículo 15, apartado 3, te obliga a declarar y deja constancia de ese juicio en el sistema de gestión de riesgos del artículo 9. Ese paso se hace a mano, o no se hace. Las herramientas hablan el idioma del SRE (latencia, saturación, tasa de errores) y el artículo habla otro, el de la precisión, la solidez y la ciberseguridad mantenidas durante todo el ciclo de vida. Nada traduce automáticamente de un idioma al otro.

El plan es un documento, y un panel no lo sustituye. El apartado 3 pide un plan de vigilancia poscomercialización versionado y fechado, que esté en la documentación técnica del anexo IV y que lea una autoridad de vigilancia del mercado. Un panel de Grafana no cumple nada de eso. Va en directo, es efímero y lo mira un ingeniero a las tres de la madrugada. Los dos son útiles, pero no son lo mismo. Tener el segundo no te exime de la obligación de elaborar el primero.

Causalidad entre sistemas. Es la cláusula a la que dije que volvería. En la entrada sobre el artículo 15 señalé la coordinación multiagente como el hueco al que las herramientas aún no habían llegado. El artículo 72, apartado 2, lo menciona sin rodeos al pedir que, cuando proceda, se analice la interacción con otros sistemas de IA. Para eso tienes que poder decir qué salida de un sistema condicionó la siguiente acción de otro, es decir, establecer causalidad a través de una frontera en la que no hay observabilidad. Pongamos que un agente de triaje rebaja la prioridad de un caso porque un agente de recuperación le ha pasado un documento desfasado. La salida parece normal y la métrica sigue en verde, pero nada deja constancia de que el agente de triaje decidió así por la respuesta del de recuperación. Multiplícalo por una flota de agentes que se llaman entre sí, y la interacción deja de ser algo que puedas auditar a posteriori. Lo más parecido a un esquema son los spans de agente de OpenTelemetry, que siguen en desarrollo. Hasta que estén terminados, la interacción con otros sistemas de IA es una obligación que puedes poner por escrito pero todavía no medir.

Cerrar el bucle con el artículo 9. Una monitorización que nunca actualiza el registro de riesgos deja el bucle abierto. El artículo 72 alimenta el artículo 9 (el sistema de gestión de riesgos, que abarca todo el ciclo de vida), y los dos forman una sola disciplina. Las herramientas llegan hasta el panel y ahí se paran, pero el artículo espera que la señal del panel cambie el registro de riesgos, el plan de pruebas y la próxima versión. Ese último salto, de la observación a una acción que queda registrada en la documentación, es el que ninguna herramienta da por ti.

El acto de ejecución que no llegó

El único apoyo oficial que el artículo daba a los proveedores para el plan era un modelo. El apartado 3 encargaba a la Comisión adoptar, a más tardar el 2 de febrero de 2026, un acto de ejecución con un modelo estándar de plan de vigilancia poscomercialización.

No llegó en esos términos. El Reglamento ómnibus digital sobre IA, el paquete de simplificación que propone la propia Comisión, le quitaría la facultad de adoptar ese modelo obligatorio. La vigilancia poscomercialización sigue siendo obligatoria, pero el modelo pasaría a ser una guía voluntaria, prevista para el 2 de septiembre de 2027 a más tardar. El Parlamento y el Consejo alcanzaron un acuerdo provisional sobre el paquete el 7 de mayo de 2026, aunque todavía no se ha adoptado formalmente. Su adopción se espera antes del 2 de agosto de 2026, y hasta entonces nada de esto es vinculante.

Así que la fecha ha pasado, y el único documento normalizado que te habría dicho cómo es un plan conforme se quedaría en una guía. El plan lo escribes de todos modos, sin modelo, para cumplir una obligación que no ha desaparecido.

También cambiaría el calendario. El mismo paquete aplazaría del 2 de agosto de 2026 al 2 de diciembre de 2027 las obligaciones de alto riesgo para los sistemas del anexo III. Sería un respiro de verdad, aunque no te libraría del trabajo. El sistema de vigilancia tiene que existir igualmente, y construirlo bien se come la mayor parte del tiempo que gana el aplazamiento. Como con todo lo que aún se mueve en este Reglamento, planifica con la ley tal como está hoy, sin contar con la versión que esperas que llegue.

Hay un plazo que no se ha movido, el de dar la alarma. El aplazamiento cambiaría cuándo empieza a apretar el artículo 73, pero no la rapidez con que aprieta. Cuando las obligaciones de alto riesgo se apliquen a tu sistema, el artículo 73 exige notificar un incidente grave en un plazo de 15 días desde que se tiene conocimiento de él, que baja a 10 días si ha fallecido una persona y a 2 en caso de infracción generalizada o de alteración grave e irreversible de infraestructuras críticas. Esos plazos corren tanto si tu monitorización ha detectado el incidente como si no. Un sistema de vigilancia poscomercialización que no puede detectar y escalar dentro de esos plazos no pasa de ser un panel con una etiqueta de cumplimiento.

Qué hacer mientras tanto

Puedes dar cuatro pasos desde ahora, sin esperar a ninguna guía, modelo de plan ni norma armonizada.

Escribe el plan ya y toma prestado un modelo que exista. No va a llegar ningún modelo oficial en los términos originales, pero tampoco necesitas el de la Comisión. La normativa de productos sanitarios lleva años aplicando el seguimiento poscomercialización. Su estructura de plan (el plan de seguimiento poscomercialización del MDR y del IVDR) es el equivalente más maduro y encaja bien con el artículo 72. Parte de ahí, convierte el plan en un documento versionado dentro de la documentación técnica y revísalo cada vez que cambien el modelo de IA, el prompt o las dependencias.

Instrumenta con las convenciones GenAI de OpenTelemetry, aunque estén en borrador. No están terminadas, pero ya definen spans para las operaciones de modelos y de agentes, que es lo más parecido a un esquema para la cláusula de interacción. Si las adoptas ahora, cuando las convenciones se estabilicen tus trazas entre sistemas ya existirán y no tendrás que empezar de cero ese día.

Prepara el protocolo de respuesta a incidentes según los plazos del artículo 73. Encadena detección, triaje y notificación para que los plazos de 15, 10 y 2 días se conviertan en procedimientos que se puedan ejecutar y dejen de ser párrafos de una política que nadie ha probado. Ensáyalo una vez antes de necesitarlo.

Construye el canal de retroalimentación desde el responsable del despliegue. Si eres el proveedor, la mitad de tus datos de vigilancia los tiene el responsable del despliegue, al que el artículo 26 obliga a vigilar el funcionamiento del sistema, conservar los archivos de registro durante al menos seis meses y avisarte cuando algo no cuadre. Esa señal es la que cierra tu bucle, pero solo si hay un canal por el que pueda llegar y un sitio en el registro de riesgos donde quede anotada. Hacen falta los dos.

Nada de esto exige que exista el modelo de plan. La obligación consiste en mantener un bucle en marcha: observar el sistema en uso real, analizar lo que ves, escribirlo en un plan y dejar que eso cambie la próxima versión. Las herramientas te dan la observación, y el resto es ingeniería que te toca a ti.

Una monitorización que nunca actualiza el registro de riesgos deja el bucle abierto. El artículo 72 ha definido el bucle y el ecosistema ha construido la instrumentación. Cerrarlo es el trabajo que queda.

Veredictos binarios: cómo mantiene Ragas a raya a los jueces

Carlos Chinchilla Corbacho — Tue, 02 Jun 2026 00:00:00 GMT

La parte 1 puso nombre a cuatro ejes de varianza del LLM como juez. Lo más sencillo que puede hacer una herramienta para combatirla es restringir lo que el juez puede decir, y en eso consiste la estrategia de restricción del alcance. En esta parte recorro cómo la aplica Ragas en dos de sus métricas.

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leo el código de otros evaluadores para averiguar qué forma deberían tener los contratos de AgentAnvil. El pipeline de fidelidad (faithfulness) de Ragas es de los ejemplos más claros de este patrón que he visto. Un año más tarde, sus autores aplicaron el mismo esquema a los agentes.

La intuición

Con un LLM como juez, la varianza contra la que peleas es mayor en el centro de la escala. Si le pides a un juez una puntuación de 1 a 5, el ruido se concentra en la frontera entre el 3 y el 4. Ahí es donde discrepan dos jueces entre sí y donde un mismo juez se contradice. Los extremos son más fáciles, porque un 1 y un 5 suelen ser casos claramente malos o claramente buenos, que no se deciden a cara o cruz.

Si eliminas el centro, el ruido se queda sin sitio.

La idea es sustituir una rúbrica continua por un veredicto binario, y así «¿Es esta respuesta fiel al contexto?» pasa a ser «¿Está respaldada la afirmación K, sí o no?». El juez ya no recorre una escala y se limita a caer a un lado u otro de una línea. La varianza no desaparece de la frontera, pero ahora esa frontera es una decisión de implicación (entailment) y ha dejado de ser una nota de calidad.

Al agregar los bits vuelves a tener un número de aspecto continuo, la fracción de afirmaciones respaldadas. Sale de átomos binarios, sin ningún juicio continuo de por medio. Cada veredicto que cambia mueve la puntuación 0,1 si hay diez afirmaciones y 0,05 si hay veinte. En la medida en que los errores de los veredictos sean independientes, el ruido del juez se promedia y no se acumula. Ragas juzga todas las afirmaciones juntas en una sola llamada y vuelve a descomponer la respuesta en cada ejecución, así que en la práctica la dispersión se reduce más despacio de lo que muestra la demo de abajo.

Figura interactiva: Simulación de una misma respuesta que un juez ruidoso puntúa una y otra vez. El histograma muestra dónde cae la puntuación en las distintas ejecuciones y la línea discontinua marca su media. Con más afirmaciones la dispersión se estrecha, suponiendo que cada veredicto se equivoque de forma independiente sobre un conjunto fijo de afirmaciones. La línea continua es el umbral de la puerta: si la llevas dentro de la dispersión, la puerta se vuelve inestable, y si la sacas de ella, se estabiliza. Ábrela en el artículo para usarla.

El pipeline de fidelidad de Ragas gira en torno a esta idea.

La fidelidad en Ragas, paso a paso

En Ragas, la fidelidad se calcula con dos llamadas al LLM y un paso aritmético. La primera llamada descompone, la segunda juzga y la puntuación es una fracción.

Figura interactiva: Fidelidad en Ragas: descomponer, juzgar, agregar. Ábrela en el artículo para usarla.

Los fragmentos que siguen salen de los módulos originales ragas.metrics._faithfulness y _goal_accuracy. Desde la v0.4.2, Ragas recomienda importar estas métricas desde ragas.metrics.collections, que conserva los mismos prompts (salvo la frase sobre el formato JSON), los tipos de veredicto y el cálculo de la puntuación.

La descomposición está en StatementGeneratorPrompt.

class StatementGeneratorPrompt(
    PydanticPrompt[StatementGeneratorInput, StatementGeneratorOutput]
):
    instruction = (
        "Given a question and an answer, analyze the complexity of each "
        "sentence in the answer. Break down each sentence into one or more "
        "fully understandable statements. Ensure that no pronouns are used "
        "in any statement. Format the outputs in JSON."
    )

La instrucción de no usar pronombres es la pieza que hace funcionar el resto del pipeline. Cada afirmación tiene que entenderse por sí sola, porque la siguiente llamada la juzga sin tener delante el resto de la respuesta. El propio prompt de descomposición de Ragas trae un ejemplo few-shot en el que una respuesta de dos frases sobre Einstein se descompone en cuatro afirmaciones independientes que pueden juzgarse por separado. Por los pronombres se cuela la dependencia, y una buena descomposición le cierra el paso.

El veredicto lo emite NLIStatementPrompt.

class NLIStatementPrompt(PydanticPrompt[NLIStatementInput, NLIStatementOutput]):
    instruction = (
        "Your task is to judge the faithfulness of a series of statements "
        "based on a given context. For each statement you must return "
        "verdict as 1 if the statement can be directly inferred based on "
        "the context or 0 if the statement can not be directly inferred "
        "based on the context."
    )

Una sola llamada juzga todas las afirmaciones a la vez y devuelve un veredicto por cada una. La instrucción acota explícitamente la salida a 1 o 0, sin término medio.

Después viene la puntuación.

def _compute_score(self, answers: NLIStatementOutput):
    # check the verdicts and compute the score
    faithful_statements = sum(
        1 if answer.verdict else 0 for answer in answers.statements
    )
    num_statements = len(answers.statements)
    if num_statements:
        score = faithful_statements / num_statements
    else:
        logger.warning("No statements were generated from the answer.")
        score = np.nan

    return score

Es la fracción de afirmaciones respaldadas, una salida de aspecto continuo obtenida al promediar juicios binarios.

Quedan tres detalles de implementación.

En primer lugar, lo que hace en realidad el juez cuando puntúa la «fidelidad» es inferencia en lenguaje natural, una tarea muy estudiada. Ragas reduce a dos las tres etiquetas habituales de esa tarea (implicación, neutral y contradicción) y solo distingue si hay implicación o no la hay. El planteamiento lo toma prestado de una tarea que ya existía.

En segundo lugar, todas las afirmaciones cuentan lo mismo, sin ponderar por importancia, sin penalizar la longitud y sin tener en cuenta la confianza. Esa uniformidad hace que acotar la varianza salga barato, y también que la puntuación se pueda manipular. Basta con rellenar una respuesta con tres afirmaciones triviales que el contexto respalda, colocadas delante de la que de verdad importa, para que la fidelidad suba. La puntuación no sabe en qué átomo está el significado.

Por último, el contrato de tipos es verdict: int (cualquier entero). El prompt es el que acota el valor a 0 o 1, y _compute_score recurre a la semántica truthy. La restricción está, por tanto, en la capa del prompt; la métrica de agentes la endurece en la capa de tipos.

El mismo patrón en `AgentGoalAccuracy`

Más o menos un año después de su artículo de 2023, Ragas llevó el mismo patrón a los agentes.

AgentGoalAccuracy hace dos llamadas al LLM sobre la traza de una conversación de varios turnos, y el veredicto es directamente la métrica. La primera deduce qué buscaba la ejecución y cómo terminó.

class WorkflowOutput(BaseModel):
    user_goal: str = Field(...)
    end_state: str = Field(...)

La segunda compara las dos cosas y responde a una pregunta binaria.

class CompareOutcomeOutput(BaseModel):
    reason: str = Field(...)
    verdict: t.Literal["0", "1"] = Field(...)

Con Literal["0", "1"], el alcance queda fijado en el tipo, además de en el prompt. Pydantic no admite nada que no sea "0" o "1", así que, si un LLM intenta devolver "1.0", "yes" o un objeto JSON, el parser lo rechaza. El paso de reintento de Ragas puede pedirle a un LLM que arregle el formato, pero a la puntuación nunca llega otra cosa que "0" o "1".

Es una vuelta de tuerca respecto a la fidelidad, donde verdict: int acepta cualquier entero. La métrica tiene dos variantes. WithReference compara con un objetivo que se le pasa y WithoutReference, con el que acaba de deducir el propio modelo. El mecanismo (deducir y luego hacer una sola pregunta binaria) es idéntico, y se transfiere porque también se transfiere el juicio de fondo. En la mayoría de los planteamientos razonables, «¿Ha conseguido la ejecución el objetivo del usuario?» se responde con un sí o un no.

Un detalle para quien vaya a meter esto en la CI: la traza nunca llega en bruto al juez. Antes de que la vea el primer prompt, la métrica llama a sample.pretty_repr() para aplanar la conversación de varios turnos en una sola cadena, y el segundo prompt solo ve lo que ha deducido el primero (más la referencia, cuando se pasa). Por eso dos pipelines con formateadores distintos podrían dar veredictos distintos a partir de la misma traza. El formateador forma parte de la métrica, aunque nunca aparezca en su nombre.

Lo que pierdes

Los veredictos binarios no salen gratis.

Un veredicto binario no puede decirte que una respuesta es correcta en parte y otra es excelente, ya que las dos acaban en «respaldada» o «no respaldada». Para una puerta de pasa o no pasa, esa granularidad es la adecuada, pero a la hora de orientar al desarrollador («¿cómo lo mejoro?») los veredictos binarios se quedan cortos. Una puntuación de 0,6 no dice cuáles eran las tres afirmaciones respaldadas de las cinco, ni si las dos sin respaldo eran pequeñas licencias o alucinaciones en toda regla. La forma del fallo se pierde.

Figura interactiva: Ejemplo construido a mano de una respuesta errónea que se cuela por la puerta. Su única afirmación con contenido (la roja) es inventada y el contexto de abajo no la respalda; todo lo demás es relleno. Sube la puntuación con relleno, eleva después el umbral de la puerta para defenderte y verás lo poco que sirve. Ábrela en el artículo para usarla.

Para ser justos con el diseño, que la forma sea binaria no quiere decir que Ragas se olvidara de la granularidad. Sus autores eligieron lo binario porque el caso de uso con el que creció la herramienta, la evaluación de la salida de sistemas RAG, tiene justo esa forma. En RAG, la fidelidad es implicación: o la afirmación está en el contexto recuperado o no está. El cumplimiento del objetivo del agente, la métrica que añadieron más tarde para agentes, también tiene forma de implicación. En los dos casos, la forma de la pregunta encaja con la del veredicto.

«¿Es bueno lo binario?» es la pregunta equivocada. La que hay que hacerse es «¿Tiene el juicio forma binaria?».

Cuándo encaja este enfoque

Los veredictos binarios son el enfoque adecuado cuando se cumplen tres condiciones.

La decisión es pasa o no pasa, sin grados intermedios. En el fondo, una puerta de CI es un pasa o no pasa, aunque la puntuación sea un float de 0 a 1. En cambio, una métrica de cara al usuario que tenga que distinguir entre «bueno», «muy bueno» y «excelente» no lo es.

Los juicios intermedios se descomponen en comprobaciones independientes de sí o no. La fidelidad se presta a ello de forma natural: dado el contexto, cada afirmación es independiente de las demás. Un juicio cuyas partes solo tienen sentido juntas no sobrevivirá al pipeline.

La varianza de la zona media sale más cara que perder información. Una puerta de CI inestable que falla 1 de cada 20 ejecuciones por los vaivenes del juez es peor que una puerta que no da ningún detalle de diagnóstico. De los dos costes, quédate con el que te salga más barato.

En cuanto a los umbrales, elige a la vez el punto de corte y el N habitual. Un umbral de fidelidad de 0,8 con tres afirmaciones equivale a «tres de tres»: basta una afirmación sin respaldo para que la puerta falle, de modo que ya es binaria en la propia métrica. Con veinte, equivale a «dieciséis de veinte», una puerta más cercana a lo continuo. Mientras no decidas cuántos átomos esperas, el umbral es un número sin significado operativo.

Cuando se cumplen las tres condiciones, los veredictos binarios son la herramienta más limpia que tienes.

Parte 2 de 7. Los veredictos binarios son el mecanismo más sencillo para acotar lo que puede decir un juez. En la siguiente parte leo el código de una herramienta que pone la cota en otro sitio. Si has llegado aquí directamente, la parte 1 pone nombre a la varianza que intentas acotar.

Forma parte de la misma serie y está relacionado con un artículo que presento en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

El problema del LLM como juez es la varianza, y las herramientas no se ponen de acuerdo en cómo arreglarla

Carlos Chinchilla Corbacho — Tue, 19 May 2026 00:00:00 GMT

En lo único que coinciden es en la palabra «juez».

Para mi tesis doctoral he leído el código fuente de siete herramientas de código abierto que usan un LLM como juez. Además estoy desarrollando un framework de pruebas para agentes LLM, y las dos cosas influyen en cómo leo estas herramientas.

El problema es la varianza. Si ejecutas un juez LLM dos veces sobre la misma entrada, la puntuación varía; si cambias el modelo del juez, varía más, y si reformulas la rúbrica, más todavía. Ninguna de estas herramientas elimina esa varianza, pero cada una la restringe a su manera. Lo decisivo es qué restricción elige, y de eso tratan las siguientes entregas.

Por qué recurrir a un juez

Si el paradigma existe es porque la mayor parte de lo que quieres evaluar de un agente, como la coherencia del plan, la elección de herramientas o si la respuesta fue útil, no tiene una respuesta de referencia. No hay un conjunto de test con el que comparar, así que recurres a un juez. Y el más barato que tienes a mano es un LLM potente.

Zheng et al. (2023) defendieron que ese LLM hiciera de juez. Bautizaron el paradigma «LLM-as-a-judge», construyeron MT-Bench en torno a él y mostraron que GPT-4 alcanzaba un 85 % de concordancia con expertos humanos en los votos sin empate del benchmark, algo por encima del 81 % que lograban los humanos entre sí en el mismo experimento. Fue esa cifra la que vendió el paradigma. Si un juez potente coincide con la preferencia humana más o menos tanto como los humanos entre sí, puedes meter un juez en una puerta de CI sin pagar a una persona para que haga ese trabajo.

Unos meses antes, Liu et al. (2023) ya habían afinado la técnica. Su framework G-Eval añadía dos piezas: unos pasos de razonamiento (chain-of-thought) que el propio LLM genera antes de puntuar y una función que pondera la puntuación final por la probabilidad que el modelo asigna al token de cada opción (en GPT-4, que no exponía esas probabilidades, se estimaban con 20 muestras a temperatura 1). El resultado era una puntuación continua, capaz de recoger la incertidumbre del modelo sin reducirla a un único entero. En la tarea de resumen, la correlación de Spearman de G-Eval con las valoraciones humanas llegó a 0,514 y superó la de todos los evaluadores anteriores; el que más se acercó fue UniEval, con 0,474.

Tres años después, el paradigma está en todas partes, hasta el punto de que todos los frameworks de evaluación de código abierto que he leído implementan alguna versión de él. Eso ya no se discute.

Cómo aparece la varianza

Si coges cualquier juez LLM de los que se usan de verdad, verás cuatro tipos de varianza en sus puntuaciones.

De una ejecución a otra, con el mismo modelo. Aunque pongas la temperatura a cero, la puntuación sigue variando, porque al servir el modelo la inferencia no es determinista bit a bit. Liu et al. (2023) observaron un efecto relacionado: si pides a un LLM una puntuación entera en una escala de 1 a 5, las puntuaciones de entradas distintas se amontonan en un mismo entero y borran diferencias reales. Su arreglo (ponderar la puntuación por las probabilidades de los tokens, sin quedarse con el argmax) suaviza esa granularidad, pero la incertidumbre de fondo del juez sigue ahí. El juez no se decanta por una respuesta fija; en cada llamada reduce una distribución a un único valor.

De un juez a otro. Si cambias el modelo que hay detrás del prompt del juez, los veredictos varían todavía más. Con los votos de Chatbot Arena, Zheng et al. (2023) vieron que GPT-4 y Claude-v1 coincidían el 66 % de las veces si se cuentan los empates y los veredictos que cambian con la posición, y el 95 % en los votos en que los dos eligen ganador. Con el mismo prompt y las mismas respuestas, otro modelo juzga distinto.

De un prompt a otro. Basta reformular la misma rúbrica para que cambie la puntuación. Zheng et al. prueban dos variantes del prompt para la misma tarea, y con solo cambiarles el nombre a los asistentes la tasa de «sesgo hacia el primero» de Claude-v1 baja del 75 % al 11,2 %. Al juez le afecta cómo están redactadas sus instrucciones, además de lo que dicen.

Sesgos sistemáticos que no se compensan al promediar. Zheng et al. pusieron nombre a tres. El primero, el de posición, hace que los jueces favorezcan la respuesta que aparece antes. Con pares de respuestas deliberadamente parecidas, GPT-4 mantiene el veredicto el 65 % de las veces al intercambiar el orden y en el 30 % de esas pruebas lo cambia a favor de la primera, mientras que Claude-v1 lo mantiene el 23,8 % de las veces. En el segundo, el de verbosidad, un ataque de «lista repetitiva» (rellenar una respuesta con viñetas reformuladas, sin contenido nuevo) hace que Claude-v1 y GPT-3.5 elijan la respuesta más larga el 91,3 % de las veces. Y en el tercero, el de autopreferencia, GPT-4 favorece sus propias respuestas con una tasa de victorias un 10 % mayor y Claude-v1 las suyas con un 25 % más, aunque Zheng et al. advierten de que sus datos son demasiado limitados para confirmar este sesgo. Gu et al. (2024) documentan otros en su revisión posterior (el de concreción, el cultural y el de diversidad), pero los tres de Zheng son los primeros con los que se topa cualquier puerta de CI.

Un matiz sobre el alcance. Las cifras anteriores salen de MT-Bench y Chatbot Arena en 2023, con los GPT-4 y Claude-v1 de entonces. Con los modelos más recientes las magnitudes han cambiado, pero el patrón de fondo se mantiene y al juez le siguen afectando los detalles de forma. La deriva entre actualizaciones del modelo es un eje de varianza aparte y queda fuera de esta entrada.

Figura interactiva: Un juez real, Claude Haiku, puntúa dos comprobaciones concretas de fidelidad. Las dos rúbricas piden «faithful», pero cada una lo define a su manera: la estricta descarta la inferencia y la permisiva admite el conocimiento general. Cambia de una a otra y verás cómo se invierten los dos veredictos. Ábrela en el artículo para usarla.

Son cuatro ejes y ninguno desaparece por sí solo. Ninguna de las siete herramientas de código abierto que he leído los elimina, aunque todas los restringen, cada una a su manera. En la sección siguiente explico por qué esa diferencia importa cuando el juez forma parte de un pipeline de producción.

Por qué importa en producción

En el entorno académico, a los jueces LLM se les evalúa con benchmarks, mientras que en producción se les pone a decidir en puertas de calidad. Las dos situaciones parecen iguales, pero no lo son.

Pongamos una puerta concreta: cada PR lanza la batería de tests, entre los que hay varias evaluaciones con juez LLM (la coherencia del plan sobre una entrada fija, la idoneidad de las llamadas a herramientas sobre otra y la utilidad de la respuesta sobre una tercera). Cada una puntúa entre 0 y 1, y la PR se fusiona si todas las puntuaciones superan un umbral.

Ahora lleva a ese pipeline lo que describe la sección anterior. El mismo juez, con el mismo prompt y la misma entrada, da puntuaciones distintas en ejecuciones consecutivas. Si pasas el juez a otro modelo, muchas puertas cambian de veredicto, y si retocas la rúbrica en un docstring, el umbral deja de significar lo que significaba la semana pasada.

Figura interactiva: Simulación de 120 PR, una por cuadrado, que pasan por una puerta de calidad con un juez LLM ruidoso. Sube el ruido y la puerta empieza a fusionar bugs (rojo) y a bloquear trabajo válido (ámbar). Después activa el arreglo (relanzar las que fallan) y fíjate en cuántos bugs entran. Ábrela en el artículo para usarla.

Los equipos reaccionan de dos maneras, y las dos empeoran la puerta.

La primera es relanzar el test cuando falla y, si pasa al reintentarlo, darlo por bueno. Eso es enmascarar fallos reales con la excusa de gestionar tests inestables, porque cada reintento que convierte un fallo real en un aprobado es un bug fusionado. Cuando relanzar se vuelve costumbre en el equipo, la puerta pasa a ser, como mucho, informativa.

La segunda es saltarse la puerta cuando conviene. Los ingenieros sénior aprenden qué puntuaciones son ruidosas y cuáles no. La puerta acaba siendo una convención social que nadie hace cumplir, y la gobernanza se va erosionando PR a PR.

Las dos reacciones tienen el mismo origen. A una puerta de calidad no le basta con que la varianza sea baja: necesita que esté acotada, cosa que ninguno de los cuatro ejes anteriores garantiza por defecto. De ese hueco trata esta serie, que recorre las distintas maneras en que cinco de las siete herramientas intentan poner una cota a lo que puede decir un juez.

Parte 1 de 7. En la serie leo una a una las herramientas de código abierto que usan un LLM como juez y miro cómo intenta cada una acotar la varianza. Esta primera entrega diagnostica la varianza en sí, con sus cuatro ejes y ninguna herramienta que la elimine. La siguiente analiza una herramienta que la acota con veredictos binarios, y la serie termina donde todas se quedan cortas, en la brecha de calibración.

Pertenece a la misma serie y está relacionado con un artículo que presento en DITTET 2026 (julio) sobre la varianza de los jueces en evaluadores de código abierto.

Escrito y traducido con ayuda de IA. Consulta la política de IA.

El artículo 15 ya fija los requisitos, pero las herramientas van por detrás

Carlos Chinchilla Corbacho — Tue, 05 May 2026 00:00:00 GMT

Daba por hecho que los requisitos de pruebas del Reglamento europeo de IA ya estaban cubiertos. Me equivocaba.

El artículo 15 es muy concreto: enumera cinco vulnerabilidades específicas de la IA, exige un funcionamiento uniforme durante todo el ciclo de vida del sistema y menciona los bucles de retroalimentación de los sistemas que siguen aprendiendo después del despliegue.

Las herramientas de evaluación que existen hoy cubren solo una parte de lo que recoge el artículo, y este texto trata de ese hueco.

Qué dice exactamente el artículo 15

El artículo 15 del Reglamento (UE) 2024/1689 se titula Precisión, solidez y ciberseguridad y regula lo que deben lograr los sistemas de IA de alto riesgo y lo que tienen que demostrar los proveedores. Tiene cinco apartados, y cada uno dice algo concreto.

El apartado 1 da el marco general. Pide que los sistemas de IA de alto riesgo alcancen un nivel adecuado de precisión, solidez y ciberseguridad y «funcionen de manera uniforme en esos sentidos durante todo su ciclo de vida». Merece la pena leer dos veces la cláusula del ciclo de vida. Para el artículo no basta con aprobar un benchmark el primer día: hace falta mantener el rendimiento mientras el sistema siga en servicio. Es una diferencia importante que la mayor parte de la infraestructura de evaluación pasa por alto.

«Nivel adecuado» es un criterio cualitativo. Como el artículo no fija umbrales numéricos, es el proveedor quien justifica en la documentación técnica (anexo IV) qué es adecuado para la finalidad prevista del sistema. Lo que se entrega es precisamente esa justificación.

El apartado 2 parte de que las metodologías para medir la precisión y la solidez aún no existen a gran escala, y encarga a la Comisión que fomente, en cooperación con las autoridades de metrología y de evaluación comparativa, el desarrollo de parámetros de referencia (benchmarks) y metodologías de medición. El propio artículo reconoce el hueco.

El apartado 3 exige indicar en las instrucciones de uso los niveles reales de precisión y los parámetros pertinentes para medirla, es decir, las métricas. En eso se apoya la transparencia, en saber qué precisión has conseguido y con qué métricas. El artículo 13, apartado 3, letra b), inciso ii), extiende esa obligación a la solidez y la ciberseguridad.

El apartado 4 se ocupa de la solidez y del comportamiento después del despliegue. Los sistemas de IA de alto riesgo deben ser lo más resistentes posible a los errores, fallos e incoherencias, y contar con medidas técnicas y organizativas para ello. Si un sistema sigue aprendiendo tras el despliegue, el artículo exige que los bucles de retroalimentación (resultados sesgados que influyen en las entradas futuras) se aborden con medidas de reducción de riesgos. Es la cláusula del aprendizaje en línea, recogida de forma explícita en el Reglamento. Entran en este apartado los sistemas de alto riesgo que ajustan el modelo en producción, y se puede defender que también los que usan las interacciones de los usuarios para moldear su comportamiento futuro, tanto si quienes los construyen los consideran «sistemas del Reglamento de IA» como si no.

El apartado 5 trata de la ciberseguridad, y es ahí donde el artículo entra en detalles técnicos. Los sistemas de IA de alto riesgo deben resistir los intentos no autorizados de alterar su uso, sus resultados de salida o su funcionamiento. El artículo enumera cinco vulnerabilidades específicas de la IA (cuatro clases de ataque más los defectos en el modelo) que el proveedor debe, según corresponda, prevenir, detectar, combatir, resolver y controlar:

Envenenamiento de datos del conjunto de entrenamiento
Envenenamiento de modelos en los componentes preentrenados
Ejemplos adversarios / evasión de modelos en la inferencia
Ataques a la confidencialidad
Defectos en el modelo

Son cinco categorías y figuran en el propio texto de la ley.

Qué se prueba hoy en la práctica

Si pones los cinco apartados del artículo 15 al lado de las herramientas de evaluación actuales, enseguida ves que las categorías no encajan.

La mayoría de esas herramientas caben en cuatro grupos, y cada uno cubre una parte distinta de lo que recoge el artículo.

Los benchmarks de inyección de prompts y de jailbreak comprueban si se puede conseguir que el modelo se salte sus instrucciones de seguridad o que anteponga las instrucciones de un atacante a las del desarrollador. Exploran lo que el artículo llama ejemplos adversarios y evasión de modelos, sobre todo en la frontera del modelo y de forma puntual. No cubren el requisito del ciclo de vida, y solo las baterías más recientes, pensadas para agentes, prueban qué pasa cuando al modelo se le añaden llamadas a herramientas y memoria.

Los benchmarks de capacidades miden lo que el modelo sabe y puede hacer en distintos dominios, normalmente con preguntas de opción múltiple o de respuesta abierta. Sirven como una pieza más para justificar la precisión que pide el apartado 1, pero por sí solos no bastan como prueba de solidez ni de ciberseguridad. Con saber que el modelo contesta a una pregunta no se llega a lo que exige el artículo.

El red teaming de seguridad consiste en generar escenarios adversarios, a menudo a mano o casi, y cubre en parte la vertiente de ciberseguridad del apartado 5. Lo que abarca depende de la imaginación del red team, sin un recorrido sistemático por las cinco vulnerabilidades que enumera la ley. Dos organizaciones que hacen red teaming del mismo sistema rara vez llegan a la misma cobertura.

Los guardrails en tiempo de ejecución y el filtrado de salidas actúan al atender cada petición, fuera de la fase de pruebas. Son una defensa de la fase de despliegue y ayudan a justificar el cumplimiento del apartado 4, pero no son pruebas. Limitan lo que hace el sistema en producción, y el rendimiento a lo largo del ciclo de vida es otra cuestión.

De este mapa salen tres observaciones.

La primera es que todas las categorías trabajan sobre todo en la capa del modelo. La cobertura para agentes está en pañales (desde mediados de 2024 han aparecido benchmarks como AgentDojo, AgentHarm y Agent Security Bench), y los pipelines de evaluación habituales todavía no la han incorporado. El nivel adecuado de precisión, solidez y ciberseguridad del artículo se aplica al sistema de IA de alto riesgo en su conjunto, mientras que las herramientas miden solo un fragmento.

La segunda, que todas son actividades puntuales. Pasas un benchmark de jailbreak antes de sacar una versión, la publicas y en la siguiente ya no lo relanzas porque las pruebas de regresión salen demasiado caras. Ninguna de estas categorías acredita un funcionamiento uniforme durante todo el ciclo de vida. Lo que dan es una instantánea, y una instantánea no es lo que pide el apartado 1.

La tercera, que las vulnerabilidades del apartado 5 no están cubiertas por igual. De los ejemplos adversarios y la evasión de modelos se ocupan bien los benchmarks de inyección de prompts. El envenenamiento de datos y el de modelos tienen cada vez más cobertura durante el entrenamiento, aunque menos cuando el sistema ya está desplegado y entra en juego el fine-tuning incremental. Para los ataques a la confidencialidad existen herramientas en la capa del modelo (inferencia de pertenencia y extracción en el Adversarial Robustness Toolbox de IBM, sondas de reproducción de datos de entrenamiento en garak), pero hay poca cobertura en la del sistema, por ejemplo para la exfiltración a través de herramientas o las fugas entre agentes. Los defectos en el modelo, por último, quedan casi sin cubrir con las herramientas actuales.

El artículo 15 dice qué hay que probar, y el ecosistema solo prueba una parte. Dónde se queda corto lo explico a continuación.

Figura interactiva: Lo que el artículo 15 exige a un sistema de IA de alto riesgo y lo que prueban de verdad las herramientas de evaluación actuales. Ningún requisito de la lista está cubierto del todo: o lo está solo en parte o es un hueco que las herramientas no han cerrado. Ábrela en el artículo para usarla.

Dónde se quedan cortas las herramientas

Hay otros huecos, pero en estos cuatro es donde más se separa lo que exige el artículo de lo que prueba hoy el ecosistema.

Solidez frente a ataques, también en la capa del agente. El apartado 5 enumera vectores de ataque que los benchmarks actuales abordan en la capa del modelo, como los ejemplos adversarios o la evasión de modelos en la inferencia y el envenenamiento de datos durante el entrenamiento. Con agentes, esa frontera se amplía. La selección de herramientas, la construcción del plan, la memoria y la comunicación entre sistemas son superficies por las que una entrada adversaria puede moldear el comportamiento sin que al modelo le llegue nunca nada que parezca un ataque. Una salida de herramienta manipulada que influye en el siguiente paso del plan es una entrada adversaria en la capa del agente, y lo mismo vale para una entrada de memoria envenenada que sesga las decisiones futuras. El artículo 15 está redactado pensando en el sistema, pero las herramientas trabajan sobre todo con el modelo.

De la prueba puntual al ciclo de vida. El apartado 1 pide un funcionamiento uniforme durante todo el ciclo de vida del sistema. Las herramientas, en cambio, producen instantáneas, como los benchmarks antes de publicar una versión, los relanzamientos ocasionales o los ejercicios de red team ad hoc. Ninguna de ellas acredita el comportamiento a lo largo del ciclo de vida. Una instantánea de hace seis meses no demuestra nada si desde entonces se ha sustituido el modelo, se ha retocado la plantilla del prompt o un servicio aguas abajo ha cambiado la API. El ecosistema aún no ha construido la infraestructura de tests de regresión que permitiría comprobar el apartado 1 en cada versión, frente a cada cambio y mientras el sistema siga en marcha.

Recuperación ante fallos. El apartado 4 exige resistencia y admite como vía para lograrla la redundancia técnica y los planes de prevención contra fallos. Sin embargo, casi ningún harness de evaluación prueba hoy qué hace el sistema cuando algo falla, como recuperarse de una llamada fallida a una herramienta, recurrir a un respaldo cuando la confianza del modelo es baja o degradarse de forma controlada cuando un servicio aguas arriba está caído. Son propiedades operativas del sistema y también las que menciona el apartado 4. Las herramientas tratan el éxito como el caso normal y pasan por alto los modos de fallo que le importan al artículo. De un sistema que nunca se ha probado en condiciones de fallo no se puede afirmar que sea resistente.

Coordinación multiagente. El requisito de resistencia del apartado 4, que menciona los errores derivados de la interacción con otros sistemas, y el vector de ataques a la confidencialidad que recoge el apartado 5 pesan todavía más cuando el sistema se compone de varios agentes que se pasan salidas entre sí. Si además los agentes siguen aprendiendo, se suma la cláusula de los bucles de retroalimentación del apartado 4. Los fallos en cascada (cuando la salida de un agente se convierte en la entrada de otro sin observabilidad entre ellos) empiezan a preocupar en la literatura académica, y las herramientas actuales rara vez los prueban. Volveré sobre este hueco en otras entradas. Aquí me basta con señalar que las cláusulas del artículo ya cubren el caso multiagente y que las herramientas no se han puesto al día.

Las normas armonizadas podrían cerrar parte de estos huecos, pero todavía no están listas.

Normas armonizadas aún en redacción

Las normas armonizadas desarrollan el detalle técnico de lo que pide el Reglamento. Cumplir una de ellas da presunción de conformidad con el requisito correspondiente. Sin una norma publicada, el proveedor tiene que demostrar el cumplimiento por su cuenta, y eso cuesta más, tarda más y se presta más a discusión.

En mayo de 2026 el panorama es bastante peor de lo que da a entender el discurso en torno al Reglamento. Ni una sola norma armonizada del Reglamento de IA tiene publicada su referencia en el Diario Oficial de la Unión Europea (DOUE).

El borrador más avanzado de CEN-CENELEC JTC 21, prEN 18286 (Quality Management System), no superó en enero de 2026 la votación de la encuesta pública (Enquiry), y en abril, con los comentarios ya resueltos, estaba listo para el voto formal. Y esa es la norma de procedimiento.

Las normas técnicas pertinentes para el artículo 15 (precisión y solidez, ciberseguridad) van más retrasadas, y ninguna de las dos ha llegado todavía a la encuesta pública.

Aun con el procedimiento acelerado de JTC 21, la publicación está prevista para el cuarto trimestre de 2026. La referencia en el DOUE es un paso aparte, así que, siendo realistas, las normas que afectan al artículo 15 no llegarán antes de mediados o finales de 2027.

La Comisión ya se ha dado cuenta. El 19 de noviembre de 2025 propuso el Reglamento ómnibus digital sobre IA, que liga la aplicación de las obligaciones de alto riesgo a que haya normas técnicas disponibles, con fechas tope en diciembre de 2027 y agosto de 2028. Mientras escribo esto, la propuesta está en fase de trílogos. Hasta que se adopte, la fecha legal de aplicación de las obligaciones de alto riesgo sigue siendo el 2 de agosto de 2026 para los sistemas del anexo III (el 2 de agosto de 2027 para los del anexo I). Planifica con la fecha que fija hoy la ley, aunque esperes otra.

Qué hacer mientras tanto

Hay cuatro cosas que puedes hacer sin esperar a las normas armonizadas. Lo que sigue da por hecho que eres el proveedor, es decir, el ingeniero que construye un sistema de IA de alto riesgo y no el equipo que lo usa. Los requisitos de la sección 2 (artículos 8 a 15) se aplican a los proveedores. Los responsables del despliegue, por su parte, tienen su propia lista de obligaciones en el artículo 26.

Documenta lo que pruebas, lo que dejas sin probar y por qué. El artículo 15, apartado 1, exige un nivel adecuado de precisión, solidez y ciberseguridad, y ese nivel es cualitativo, depende del contexto y se justifica sistema a sistema. Lo que se entrega es la justificación. El artículo 11, a través del anexo IV, punto 2, letra g), deja claro que los archivos de registro y los informes de las pruebas, fechados y firmados, son parte obligatoria de esa documentación técnica. Escribe qué mides, qué umbral has superado, qué has decidido no probar y con qué razonamiento técnico. Una autoridad de vigilancia del mercado puede exigir esa documentación, y en algunos casos (biometría, productos del anexo I) la evalúa un organismo notificado. Escríbela pensando en que alguien la va a leer línea a línea.

Lleva un registro de riesgos continuo, porque una auditoría puntual no basta. El artículo 9 exige un sistema de gestión de riesgos que funcione de forma iterativa durante todo el ciclo de vida del sistema, y el artículo 72, una vigilancia poscomercialización. Trátalos como una sola disciplina. El registro de riesgos se actualiza cada vez que cambia algo, sea el modelo, la plantilla del prompt, una herramienta o una dependencia. Una auditoría de riesgos que se hace una sola vez, en la aceptación, no es lo que pide el artículo.

Empieza por las cinco vulnerabilidades que enumera el apartado 5. Monta primero la cobertura de red team sobre esa lista: envenenamiento de datos, envenenamiento de modelos, ejemplos adversarios o evasión de modelos, ataques a la confidencialidad y defectos en el modelo. Asegura lo que fija la ley antes de pasar a amenazas afines. La lista del artículo marca por dónde empezar y no pone ningún techo.

Diversifica las herramientas de pruebas. Las normas aún se están redactando, la oferta comercial cambiará y los métodos madurarán. Un harness de pruebas atado a una sola batería de benchmarks o a una sola empresa es un riesgo en sí mismo, y el motivo principal tiene poco que ver con el cumplimiento normativo: en los próximos tres años los cambios van a reordenar el panorama. La infraestructura debería sobrevivir a esa reordenación.

Ese es el trabajo de ingeniería que de verdad exige el artículo.

Si ya has empezado con esto, me gustaría saber qué has encontrado. El hueco entre lo que exige el artículo 15 y lo que ofrece hoy el ecosistema es tan grande que ningún equipo le saca mucha ventaja a otro. Los métodos que acabarán inspirando las normas armonizadas se están construyendo ahora mismo en los equipos que no se quedan esperando.

Trust, but Trace

El fine-tuning es mala herramienta para añadir conocimiento: tres fases de entrenamiento y el atajo de bajo rango

Tres fases y un modelo en entrenamiento

El ajuste por preferencias optimiza una diferencia

LoRA entrena otro objeto

Los hechos entran despacio y con ellos llega la confianza

El parche que nadie puede leer

Qué vigila el ingeniero de ML

La tasa de aprendizaje es el hiperparámetro que rompe producción

Tres optimizadores en cinco líneas

La escala de la pérdida se cancela y lo paga la memoria

El primer paso mide exactamente la tasa de aprendizaje

Qué dice el barrido

El weight decay y dónde ponerlo

Qué vigila el ingeniero de ML

Pérdida y gradientes sin fórmulas: la retropropagación es recorrer un grafo

La pérdida es la sorpresa media

La pasada hacia delante construye un grafo

La pasada hacia atrás desanda el grafo

Con cadenas largas, el gradiente se desvanece o explota

Bugs sin stack trace

Qué vigila el ingeniero de ML

De GPT-2 a Llama: cuatro cambios y el motivo de cada uno

El mismo bloque, cuatro retoques

Las posiciones pasan a ser una rotación

La norma deja de centrar

La red feed-forward gana una puerta

Se comparten keys y values

Qué vigila el ingeniero de ML

GPT-2 es el transformer más cinco decisiones, y la inferencia es otro programa

Cinco decisiones alrededor de la pila

El entrenamiento es una sola llamada

La generación es un bucle

Mismos pesos, bugs distintos

El muestreo es una política por encima del modelo

Qué vigila el ingeniero de ML

Un bloque de transformer son seis tensores y un bus: léelo como un pipeline

El bloque son cuatro líneas

La arquitectura está en el signo más

Dos tercios de los pesos

El coste está en otra parte

Qué vigila el ingeniero de ML

La atención es una media ponderada aprendida y su coste está en el cuadrado

Un diccionario que coincide en parte

Por qué la raíz cuadrada

Las cabezas son una vista y la máscara, un triángulo

Lectura de LlamaAttention.forward

El coste lo ponen los datos y el código no lo delata

Qué vigila el ingeniero de ML

Las formas son el sistema de tipos del ML, y nadie las comprueba por ti

Una forma es una firma

La regla cabe en cinco líneas

El bug que solo aparece con un batch de dieciséis

El padding es una decisión de forma

La memoria es forma por bytes

Qué vigila el ingeniero de ML

Un embedding es una tabla de consulta, y todo lo demás es cómo se rellena

Una matriz y un índice

Dos maneras de rellenar la tabla

La cercanía es un producto escalar

No hay migración de esquema

Qué vigila el ingeniero de ML

Un modelo no lee texto: lo que el tokenizador decide por ti

Un lexer con otro objetivo

BPE es un solo bucle

El vocabulario es el corpus de entrenamiento

El mismo párrafo cuesta más en español

El sistema de tipos no avisa

Qué vigila el ingeniero de ML

¿Quién calibra al juez? La brecha que nadie cierra

La intuición

El mapa de la brecha

Lo que cuesta la brecha

Por qué nadie ofrece la puerta

Qué puedes hacer hoy

La serie, de principio a fin

Determinista donde puedas, juez donde haga falta

La intuición

Inspect AI, paso a paso

Lo que pierdes

Lectura de `LlamaAttention.forward`

El mismo patrón en `AgentGoalAccuracy`