La receta de datos,
línea a línea

Las filas generadas sacaban su respuesta de una moneda al aire, y eso está medido, no intuido. Con 400 filas, cualquier correlación por debajo de 0,098 es indistinguible del azar. La correlación más alta entre cualquier columna de entrada y el objetivo era 0,049 en un objetivo binario y 0,054 en uno continuo. Ahí dentro no había nada que aprender.

La consecuencia le caía a quien acababa de instalar el Studio: generar datos, entrenar y leer un 50 % de acierto. El producto lo informaba con honestidad — y cualquiera que lo mirara concluía que el producto no funciona.

Con receta, ese mismo recorrido —una frase, 200 filas generadas y una regla con un 8 % de ruido declarado— entrenó hasta un 87,5 % de acierto. Medido de punta a punta el 2026-08-18, conduciendo la aplicación.

Una receta para un objetivo con clases es una lista de líneas de regla y un DEFAULT. Ésta es con la que se generó la tercera captura de esta página:

# the first matching line wins
1: debt_euros > 350000 AND age_years > 41
DEFAULT: 0
NOISE: 0.08
BALANCE: 1=0.3, 0=0.7

• Cada línea de regla es etiqueta: condición. La etiqueta es un nombre (ALTO, BAJO) o un número (1, 0) — se admiten los dos, porque las etiquetas de un objetivo binario no son identificadores. Tiene que ser una de las que declara tu modelo.
• Se lee de arriba abajo y gana la primera línea que se cumple. Una fila que se lleva una línea de arriba no se le ofrece nunca a una de abajo, así que el orden de tus líneas forma parte de lo que dicen.
• DEFAULT: es lo que se llevan todas las demás filas. Es obligatorio — una receta sin él, o con un `DEFAULT` que nombra una etiqueta que el modelo no tiene, se rechaza.
• Tienen que quedar alcanzables al menos dos etiquetas distintas entre tus reglas y el DEFAULT. Un solo resultado para todo no es una regla, es una constante, y se rechaza como tal.
• Las líneas que empiezan por # son comentarios.

Una condición es exactamente columna OPERADOR número, y los operadores son <, <=, >, >=, == y =. Los dos últimos significan lo mismo y comparan con una tolerancia de 1e-9, así que una igualdad sobre una columna con decimales se comporta como esperarías.

Cuatro cosas que no puede hacer, y ninguna avisa a gritos:

• comparar dos columnas — a la derecha va un número, siempre;
• usar paréntesis, ni ninguna cuenta dentro de la condición;
• nombrar una columna que el modelo no tiene — ésa sí se detecta y se informa;
• mezclar AND y OR en la misma línea.

La última es la que pilla a todo el mundo, así que conviene decirla sin rodeos: una línea con los dos conectores se descarta entera. El analizador no se inventa una precedencia que nadie le ha dicho, y tampoco protesta — la línea sencillamente ya no está. Escribe dos líneas y deja que el orden haga el trabajo:

# not this — the whole line is dropped
1: debt_euros > 350000 AND age_years > 41 OR age_years < 25

# this — first match wins, so the order is the precedence
1: age_years < 25
1: debt_euros > 350000 AND age_years > 41
DEFAULT: 0

Escribe debt_euros > 350000, no debt_euros > 0.7. Euros, años, grados, milímetros — lo que mida esa columna. Éste es el error que rompe más recetas que todas las demás reglas de esta página juntas, y el ejemplo del propio producto llegó a cometerlo.

Es tan fácil de cometer porque el core muestrea las filas internamente en una escala normalizada de 0 a 1, y convierte tu umbral a ella con el rango de esa columna. Lo que a propósito NO hace es recortarlo: un umbral fuera del rango se queda fuera, de modo que la condición no se cumple nunca —que es lo correcto— en vez de que alguien la empuje al borde y quede a medio funcionar.

Así que debt_euros > 0.6 sobre una columna que va de 0 a 500.000 se cumple en todas y cada una de las filas. Todas se llevan la misma etiqueta, la receta es perfectamente válida y completamente inútil, y el core se da cuenta: se pasa a etiquetas al azar y lo dice.

NOISE: 0.1

Una de cada diez filas no sigue la regla. Es una proporción entre 0 y 1, no una desviación, y se escribe así porque se explica en una frase y vale igual para dos clases que para cinco. RUIDO también se acepta; NOISE es la forma canónica, como DEFAULT, AND y OR.

• Por qué existe: una regla determinista sin ruido produce un dataset perfectamente separable, y el modelo entrena hasta cerca del 100 % de acierto. Funciona, y es exactamente el número que no sobrevive a enseñárselo a alguien técnico.
• La fila que contradice nunca se queda con su propia etiqueta. Cuando la alternativa podía incluir la que la regla ya había elegido, la mitad de los cambios no cambiaban nada y un 10 % declarado salía como un 6,5 % — medido. Una receta que declara un 10 % y entrega un 6,5 % es una receta que miente, y esta receta se publica con el modelo.
• Un valor fuera de 0 a 1 se ignora, no se rechaza. El resto de la receta sigue funcionando, en la misma línea que el resto del analizador.

BALANCE: 1=0.3, 0=0.7

Que el treinta por ciento de las filas sean de clase 1. 1=30% vale igual, y REPARTO se acepta como sinónimo. Sin esta línea, el reparto es el que salga de la regla y de los rangos.

Y eso importa más de lo que parece. En la vida real el impago, el fallo y el reingreso son minoría, y ser minoría es justo lo que los hace difíciles de aprender. Un dataset donde la clase rara no es rara enseña un problema que no tiene nadie.

Cómo se consigue el reparto forma parte de la promesa. Las filas no se reetiquetan — eso rompería la regla, y el dataset dejaría de obedecer a su propia receta. Las filas que sobran se vuelven a sortear, una y otra vez, hasta que la regla por sí sola dé el reparto que pediste. Y si no se llega, se declara en vez de perderse por el camino.

Una regla con etiquetas no sirve para un objetivo continuo: no hay etiqueta que elegir, hay una cantidad que calcular. Así que la receta pasa a ser una expresión.

usage = 0.05*sqm + 1.2*people + 5
NOISE: 0.1

• A la izquierda del = va el objetivo. A la derecha, una suma de términos coeficiente*columna y una constante. Un término sin coeficiente cuenta como 1, y el signo es del término.
• Ésa es toda la gramática: ni funciones, ni condicionales por tramos, ni interacciones. El alcance se cerró a propósito — todo lo demás hacía crecer el evaluador sin final a la vista.
• Los coeficientes se escriben en la escala de tu dominio, igual que los umbrales de una regla de clases.

Antes de que esto existiera, un objetivo continuo se rellenaba con un sorteo uniforme entre sus límites —ruido puro, correlación 0,054—, así que un modelo de regresión no tenía hacia dónde converger.

Generar no te entrega solo filas. Al lado de los datos sale la regla que el core aplicó de verdad, quién la escribió, la huella del dataset y cualquier aviso que levantara.

• La regla que se enseña es la analizada, no tu texto. BALANCE: 1=0.3, 0=0.7 vuelve como una línea por etiqueta, y NOISE se escribe la última. Si aquí falta una línea tuya, el analizador la descartó — que es la forma más rápida de encontrar una errata.
• Tres desenlaces, tres mensajes. La receta se aplicó; o no se pudo leer y el core etiquetó al azar; o se leyó y no separó los datos, así que el core etiquetó al azar igualmente. No son el mismo problema y no se les da el mismo consejo.
• Se dice quién escribió la regla. Si dejaste la caja vacía y hay un proveedor de LLM configurado, el core puede proponer él las reglas — y la pantalla lo dice, en vez de atribuirte una decisión que no tomaste.

El manual que vive dentro del producto está a una pulsación de la caja, y escribe sus ejemplos con las columnas y los rangos de tu modelo, para que se puedan usar sin traducir nada:

• La huella se puede comprobar. Es data_seguido de los 16 primeros caracteres hexadecimales del sha256 del CSV generado. La misma receta con la misma semilla da la misma huella y, por tanto, exactamente las mismas filas — el ruido y el resorteo salen del mismo flujo aleatorio que las columnas, así que la semilla sigue mandando.
• Se guarda con el modelo (data_recipe) y vuelve con él: cierras el Studio, reabres el proyecto y el dataset se puede reconstruir.
• Sale en el paquete exportado como data_recipe.txt, junto a la especificación de inferencia — para que quien reciba un modelo pueda leer con qué datos se entrenó y bajo qué regla.
• Son diez líneas de texto. Vive en su propio fichero y no dentro del programa de entrenamiento, lo que quiere decir que se pega en un artículo o en un foro y la entiende alguien que no ha abierto el Studio en su vida.

• No son datos reales. Una receta genera filas sintéticas, declaradas como tales. Para producción, trae tu CSV — esa puerta está justo debajo de la caja y pasa la misma validación.
• No sustituye al catálogo de plantillas. Celsius a Kelvin, la lluvia de Santander, el EUR/USD del BCE: eso son medidas de verdad, y siguen siendo la mejor puerta para quien quiere ver el producto funcionando sobre algo real.
• No mejora el motor de entrenamiento. Ni una línea. Lo que cambia es lo que se le da de comer.
• No conoce tu dominio. El core garantiza que las filas obedecen a la regla que escribiste y que puedes reproducirlas. Si esa regla es cierta en el mundo lo decides tú, y es la única parte que nadie puede comprobar por ti.