Más datos, no más red: de small a medium-v4

Qué vas a construir

medium-v4: el decoder de 115 120 128 parámetros entrenado sobre 1 681 millones de tokens, con 1504 de Elo estimado (IC 95 % 1446-1558) y un 99,8 % de jugadas legales sin máscara. De él parten M4 y M5, y se publica como chorcat/rukh-medium.

Pero lo que importa es cómo se llegó a él. La curva de small invitaba a dos conclusiones: que le faltaba entrenamiento y que tocaba una red más grande. Las dos eran equivocadas, y lo demuestra una división. Es la pregunta que se hace cualquier equipo que preentrena un LLM antes de pedir más GPU: ¿me falta modelo o me faltan datos?

Las dos cifras de la cabecera miden cosas distintas: 35 minutos son los tuyos, leyendo y lanzando comandos; las algo más de seis horas de máquina (368 minutos) son las descargas, las tres corridas y las cuatro horas de medium-v4, que trabajan solas mientras haces otra cosa.

El diagnóstico cabe en una división

«Exportar a ONNX» terminó con el hueco entre entrenamiento y validación de small creciendo (0,021, 0,046, 0,060) mientras el top-1 se aplanaba. Antes de tocar nada, la cuenta:

data/tokens/uci/train/meta.json:   2 949 514 partidas, 240 068 954 tokens
parámetros de small:               38 971 392
tokens únicos por parámetro:       240 M / 39 M = 6,2
pasadas sobre el corpus:           20 000 pasos × 256 secuencias × 200 tokens = 1 024 M / 240 M = 4,3

Seis tokens por parámetro, cuando la literatura de escalado da como razonable unos veinte, y cuatro pasadas y pico sobre el mismo material. El hueco que crecía era la firma de repetir material, y explica por qué medium, con el triple de parámetros y los mismos datos, solo compró 84 puntos de Elo (1091 frente a 1007, en la escalera sin corregir) con los intervalos solapados. Más red sobre el mismo libro recita mejor el libro.

Ese medium v1 es configs/train/medium.yaml de p3-elo-1200: la receta de small con el preset medium, 20 000 pasos sobre los mismos 240 M tokens, lr: 4.5e-4 y lotes de 32 × 8 (unas dos horas en la 5090). No se repite aquí porque solo sirve de contraste; si quieres reproducirlo, es uv run rukh train --config configs/train/medium.yaml con ese fichero.

Y había 238 millones de tokens parados: el mes de febrero entero era validación, para un bucle que evalúa leyendo 640 000. Primera palanca, y sin descargar nada.

Tres ejecuciones, una palanca cada una

Las tres comparten planificador, semilla y la misma validación congelada, las 100 000 primeras partidas de 2025-02. Cada una cambia una sola cosa respecto a la anterior, para que la diferencia sea atribuible.

v2: devolver el mes de validación al entrenamiento. configs/data/pipeline-v2.yaml deja val_games: 100000 y manda el resto al corpus: 240 M → 471 M tokens únicos, de 6,2 a 12,1 por parámetro. La misma receta de small, con 28 000 pasos.

uv run rukh data tokenize --config configs/data/pipeline-v2.yaml --scheme uci --pack
uv run rukh train --config configs/train/small-v2.yaml

v3: cambiar de qué está hecho el corpus. La Lichess Elite Database (database.nikonoel.fr) publica por meses las partidas de 2500+ contra 2300+, sin bullet. Veinticuatro meses son unos 6,5 millones de partidas: más datos y otra distribución, porque el corpus de 1800+ tiene un 3,4 % de partidas con las blancas en 2400 o más y la Elite un 93 %. configs/data/pipeline-v3.yaml las añade con extra_train_parquets y deja la validación donde estaba.

uv run rukh data elite --config configs/data/pipeline-elite44.yaml   # o bájalo publicado (arriba)
uv run rukh data tokenize --config configs/data/pipeline-v3.yaml --scheme uci --pack
uv run rukh train --config configs/train/small-v3.yaml

(pipeline-elite44.yaml descarga los 44 meses de la ejecución final; la v3 de referencia usó 24, y si sigues el orden de esta página la tuya llevará 44.)

Con v1 al lado, «general» es la validación congelada y «fuerte», la misma pérdida sobre partidas de 2200+:

Dos lecturas:

1. Recuperar el mes vale −0,049 nats y el hueco cae a la mitad. Un nat es la unidad de la pérdida cuando el logaritmo es natural, como en la entropía cruzadaEntropía cruzadaLa pérdida con la que se entrena todo modelo de lenguaje: menos el logaritmo de la probabilidad que el modelo le dio al token que venía de verdad, promediado sobre las posiciones. Si le dio 0,70, paga 0,35; si le dio 0,035, paga 3,35. En PyTorch es F.cross_entropy(logits, objetivo), que hace el softmax por dentro, y en Rukh lleva ignore_index=0 para que el relleno <pad> no cuente. Un modelo que reparte por igual entre las 2 030 jugadas paga ln 2030 ≈ 7,6: es el punto de partida de toda curva de pérdida del decoder. de la tabla: la «general» de v2 es 0,049 menor que la de v1. small v2, con 39 millones de parámetros, bate al medium de 115 entrenado con los datos viejos. El cuello eran los datos, y ahora está medido.
2. La composición mueve otra cosa que la cantidad. v3 cede 0,007 en juego promedio y gana 0,012 en juego fuerte. Y mueve el eje de Elo: la divergencia KLPenalización KLLa divergencia KL mide cuánto se aleja una distribución de otra: Σ p · log(p/q), cero si son iguales y mayor cuanto más difieren (no es simétrica, así que no es una distancia en sentido estricto). La penalización KL es el término que ata la política a la copia congelada de donde salió; sin él, una recompensa verificable es una invitación a dejar de jugar al ajedrez y ponerse a cultivar el número. Rukh usa el estimador k3, exp(d) − d − 1 con d = log π_ref − log π, que es no negativo por construcción: la diferencia de log-probabilidades a secas es negativa la mitad de las veces y pagaría al modelo precisamente por alejarse. (cuánto se separan dos distribuciones; cero si son iguales) entre las jugadas que propone con la cabecera <2800> y con <1800> pasa de 0,047 nats en v1 y 0,049 en v2 a 0,115 en v3. Duplicar los datos no movió ese eje; cambiar de qué están hechos, sí. Sin élite, el «juega como 1500 / 2000 / 2400» de M4 no tenía de dónde salir.

La escalera estaba torcida

Mientras se medían esas ejecuciones, la contradicción de la escalera se hizo imposible de ignorar: small v2 puntuaba 0,725 contra UCI_Elo 1320 y perdía veinte a cero contra skill-3, etiquetado con 1250. La medida de los escalones está en «El Elo y la suite»; esto es lo que la corrección le hizo a lo publicado:

El listón de 1200 nunca se falló: small v1 estaba publicado con «Elo bar not met» y estaba en 1359. Lo relativo aguanta: la corrección sube a los tres casi lo mismo (+352, +337 y +330), el orden no cambia y la mejora de los datos sigue ahí.

medium-v4: capacidad, cuando por fin está justificada

Con 1 681 millones de tokens únicos (enero, el resto de febrero y 44 meses de Elite, 18 942 740 partidas) salen 14,6 tokens únicos por parámetro para 115 millones, siete veces los 2,1 de medium v1: medium deja de ser una red grande sobre un libro pequeño. configs/train/medium-v4.yaml da 48 000 pasos, 2 457 millones de tokens vistos (21 por parámetro, la cifra que engaña si se confunde con la de únicos) y 1,46 pasadas.

uv run rukh data tokenize --config configs/data/pipeline-v4.yaml --scheme uci --pack
uv run rukh train --config configs/train/medium-v4.yaml
uv run rukh eval --model "$RUKH_HOME/checkpoints/medium-v4-<fecha>/best.pt" --config configs/eval/greedy.yaml --stage medium-v4-greedy

uv run rukh data tokenize --config configs/data/pipeline-v4.yaml --scheme uci --pack
uv run rukh train --config configs/train/medium-v4.yaml
uv run rukh eval --model "$env:RUKH_HOME\checkpoints\medium-v4-<fecha>\best.pt" --config configs/eval/greedy.yaml --stage medium-v4-greedy

Tokenizar tarda cinco minutos y deja 3,3 GB en data/tokens-v4/uci/. El entrenamiento duró 4 h 3 min, el trabajo más largo de la primera fase: se lanza al final de una sesión y se recoge en la siguiente. La evaluación canónica (greedy.yaml, temperatura 0,05, cabecera en 1800, escalera corregida) tarda media hora.

Elo, legalidad, top-1 y puzles vienen de la evaluación canónica, que no es el top-1 de validación de la tabla anterior (por eso medium v1 lee 52,90 % aquí y 52,31 % allí). Su Elo va en blanco porque solo se midió en la escalera torcida; ponerle un número sería inventarlo.

Tres cosas de esa fila:

• No era la arquitectura. El mismo medium, con la misma receta, pasa de 1,4782 con 240 M de tokens repetidos 4,3 veces a 1,3733 con siete veces más material único.
• La legalidad no era una tendencia. La serie 99,40 → 99,30 → 99,10 % de las tres small era un modelo de 39 M estirándose sobre un corpus creciente; con capacidad suficiente, fuerza y legalidad suben juntas.
• Los puzles son donde más se ve: de 22,07 % a 37,50 %. Un puzle pide la jugada única que gana, no la que jugó un humano, y es la métrica que menos premia imitar.

Los +145 Elo entre small v1 y medium-v4, palanca a palanca: recuperar el mes de validación +48, la Elite +18, la capacidad ya justificada +79.

Lo que se publica y lo que se mide después

chorcat/rukh-small es small v3, la mejor de la serie, y chorcat/rukh-medium es medium-v4. La demo sirve small porque 79 MB en fp16 caben en un móvil y 231 no.

Los modelos publicados sirven para comparar. Exporta tu medium-v4, cárgalo en la demo con «Tu propio modelo», elige después Rukh medium (fp16) y juega la misma apertura. Si tu entrenamiento salió bien, las partidas se parecerán; si la tuya juega notablemente peor, tienes la pista antes de gastar media hora de evaluación.

Al comparar con las cards, una advertencia: small v3 midió 1425 (1367-1485) un día y 1365 (1293-1423) al siguiente, con la misma config, semilla y pesos. El rival juega por tiempo y con UCI_LimitStrength, que aleatoriza a propósito, así que la escalera tiene un suelo de reproducibilidadSuelo de reproducibilidadCuánto se mueve una medición cuando no se cambia nada: el límite por debajo del cual dos números del mismo instrumento no se pueden distinguir. En la escalera de Rukh son unos 40 puntos de Elo de una sigma —±80 al 95 %—, medidos midiendo medium-elo a <w1800> dos veces con la misma semilla y obteniendo 1498 y 1558. La semilla fija el muestreo del modelo y no el del rival, que juega por tiempo y con UCI_LimitStrength, así que «las mismas 160 partidas» no son las mismas partidas. Cualquier diferencia entre modelos más pequeña que eso no es una diferencia entre modelos, y no hay número de partidas que lo arregle. de unos 40 puntos. Es la báscula de baño que te da 82 y 84 al subirte dos veces seguidas: no está rota, pero no te deja afirmar que has adelgazado un kilo. Dos Elo de la escalera se comparan dentro de una misma tirada, no entre tiradas, y por eso las cifras se mueven unas decenas de puntos cuando la tabla única vuelve a medir los modelos juntos (small v1 1355, medium-v4 1535).

Qué has aprendido, cómo se mide

La primera pregunta ante un modelo que se queda corto no es cuántos parámetros tiene, sino cuántos tokens distintos ha visto por cada uno, y el hueco entre entrenamiento y validación responde antes de gastar una GPU. Cantidad y composición del corpus son palancas distintas, y solo la segunda mueve un eje que no estaba en los datos. Una escala contra la que mides tiene que haberse medido a sí misma. Y escalar la red es lo correcto justo cuando la división lo permite, y un error un momento antes.

medium-v4: 1504 de Elo (1446-1558) y 99,80 % de legalidad sin máscara, los dos criterios del hito con el intervalo entero por encima, y 37,50 % de puzles.

Al empezar el módulo, el aprendiz solo sabía cómo se escribe una jugada. Ahora ha leído millones de partidas y juega de oído: propone jugadas legales el 99,8 % de las veces y le planta cara a un Stockfish limitado a 1500, sin haber visto nunca un tablero. Es lo que tiene cualquier LLM recién preentrenado: sabe continuar muy bien lo que ha leído. Lo que todavía no sabe es juzgar: mirar una posición entera y decir quién va mejor o dónde estuvo el error. Eso es M3.

La cheatsheet del módulo está justo debajo.