El modelo es la parte fácil

Un operador de alimentación fresca acudió a nosotros con una pregunta sencilla: ¿podéis predecir la demanda de mañana por plato, por local, con la precisión suficiente para que dejemos de tirar margen y de quedarnos sin stock a mediodía? Dieciocho meses después, la plataforma predice con un 98 % de precisión en producción. Se supone que lo más difícil era el machine learning. No lo era.

El modelo que hace la predicción es un regresor de gradient boosting con un par de variables de estacionalidad acopladas. Una data scientist competente puede montar algo de esta familia en una tarde. Teníamos una primera versión respetable en menos de tres semanas, lo bastante precisa en el backtest como para que todos en la sala asintieran.

Después pasamos cinco meses construyendo todo lo que convierte «un backtest preciso» en «una cifra a la que un responsable de operaciones le confía su jornada». Esa brecha es todo el trabajo, y casi nadie habla de ella porque no es glamurosa. Así que aquí está.

01El modelo en tres semanas

Predecir la demanda de un negocio estable y bien registrado es, francamente, un problema resuelto. Tienes un objetivo (unidades vendidas), un calendario y un montón de filas históricas. Diseñas unas cuantas docenas de variables —día de la semana, ventanas de desfase, medias móviles, festivos, un cruce con datos meteorológicos— y dejas que una biblioteca de boosting encuentre las interacciones. Los proyectos no mueren en las matemáticas.

Lo que las tres semanas nos compraron realmente fue la certeza de que la señal existía, sin más. El backtest nos decía que la demanda era predecible con uno o dos puntos porcentuales de margen, siempre que las entradas estuvieran limpias. Eso es la luz verde. No es el producto.

02Adónde fueron los cinco meses

Aquí está el recuento honesto de los cinco meses siguientes. Nada de esto es modelado. Todo esto es lo que hizo que el modelo fuera utilizable.

1. Una ingesta que sobrevive a la realidad. Los flujos de ventas llegan tarde, duplicados o no llegan en absoluto. Un TPV se reinicia y reproduce el día anterior. Construimos una ingesta idempotente que puede volver a ejecutarse sin riesgo y que pone en cuarentena las filas en las que no confía, en lugar de envenenar el conjunto de entrenamiento.
2. Un feature store con memoria. Las variables sobre las que se entrena el modelo deben poder calcularse en el momento de la predicción, únicamente con los datos de los que dispondrías realmente en ese instante, sin mirar al futuro. Hacer cumplir esta exactitud point-in-time supuso semanas de trabajo y permitió detectar dos fugas que habían inflado el backtest inicial.
3. Backfill y replay. Cuando el historial de un local era erróneo, teníamos que reconstruir todas las predicciones posteriores para ese local sin detener el sistema en producción. El replay es fontanería que nadie muestra en una demo y que todos necesitan.
4. La supervisión antes que las funciones. Entregamos las alarmas de deriva y de frescura antes de entregar la mitad de la interfaz. Una predicción silenciosamente errónea es peor que una predicción visiblemente ausente.
5. El override humano. Abre un local nuevo, llega un festival, se corta una carretera. El modelo no puede saberlo. Los planificadores necesitaban una forma autorizada de ajustar la cifra y de hacer que el sistema aprendiera de ese ajuste.

03El contrato de datos

Lo más apalancado que construimos no fue una mejora del modelo. Fue un contrato de datos: un esquema explícito y validado entre cada fuente de origen y nuestro pipeline. Tipos de columna, rangos permitidos, ventanas de frescura, políticas de valores nulos: todo declarado, todo verificado en la puerta.

Antes del contrato, una predicción podía degradarse en silencio porque un proveedor de TPV cambió un campo de moneda de céntimos a euros sin avisarnos. Después del contrato, ese cambio se rechaza en la ingesta con un error nombrado y escalado, y la última buena predicción permanece en pantalla en lugar de una nueva, confiada y errónea.

# cada fuente se valida en la puerta, no después de envenenar el entrenamiento
sales_daily:
  units:        int  >= 0      # rechaza negativos: los reembolsos van a otra parte
  revenue:      decimal(10,2)  # céntimos → señalado en v3, ahora aplicado
  site_id:      fk(sites)      # local desconocido → cuarentena, escalar a guardia
  recorded_at:  freshness <= 6h # flujo caducado → mantener la última buena predicción
on_violation: quarantine + alert  # nunca: entrenar sobre ello en silencio

Ese es el corazón poco glamuroso de cada sistema de ML en producción que hemos entregado. El modelo es una función; el contrato es lo que garantiza que la función reciba las entradas que se entrenó para esperar. Sáltatelo y no tendrás una plataforma de predicción: tendrás un generador de números aleatorios muy caro que acierta la mayoría de las veces.

04La deriva es una función, no un fallo

Todo modelo se degrada. Los gustos evolucionan, llega una nueva carta, un competidor abre enfrente. La pregunta nunca es si el mundo se moverá bajo tu modelo, sino si te enterarás por un panel de control o por una llamada furiosa.

Tratamos la detección de deriva como una función de producto de primer orden. La plataforma compara de forma continua las distribuciones de las entradas en vivo y el error en vivo con las referencias del entrenamiento. Cuando una u otra cruza un umbral, hace tres cosas, en este orden:

• Avisa a alguien: a un humano concreto, con el local, la métrica y cuánto se ha movido.
• Protege la salida: ampliando los intervalos de confianza o replegándose a una referencia más simple y robusta, en lugar de confiar en un modelo que ahora extrapola.
• Programa un reentrenamiento: con los nuevos datos, condicionado al mismo umbral de backtest que el original tuvo que superar.

Fíjate en que la cifra estrella —el 98 %— no es la más interesante. Las cifras interesantes son las dos que la rodean, porque son las que la empresa siente. La precisión es la entrada; menos desperdicio y menos roturas de stock son la salida. Una plataforma que optimiza la primera e ignora las segundas es un proyecto de laboratorio.

05El panel que alguien consulta a las 8 de la mañana

La predicción la consume un jefe de cocina al inicio de un servicio, en una tablet, con un café en la mano, en noventa segundos. Esa restricción dio forma a más decisiones que la arquitectura del modelo.

Exigía que la respuesta fuera una cantidad, no una distribución de probabilidad. Exigía que «no estoy de acuerdo, y esta es la razón» cupiera en un solo toque. Exigía que la pantalla mostrara la predicción de ayer frente a lo que realmente ocurrió, porque la confianza se gana siendo visiblemente responsable, no siendo seguro de uno mismo. Un modelo incapaz de mostrar su historial a la persona que se apoya en él será ignorado en silencio en menos de una semana.

06Notas a nuestros yo del pasado

Si está a punto de empezar algo con esta forma, esto es lo que le diríamos al equipo que empezó hace dieciocho meses:

• Presupueste el envoltorio, no el modelo. Parta de que el modelo representa el 15 % del esfuerzo y planifique deliberadamente el 85 % restante. Los equipos que incumplen los plazos son los que presupuestaron lo contrario.
• Escriba primero el contrato de datos. Antes de la menor variable. Hará aflorar una fuga en su backtest y le evitará entregar una cifra que no puede defender.
• Entregue la supervisión antes que la interfaz. No puede operar lo que no puede ver, y una predicción errónea que nadie ha advertido es el modo de fallo que hace perder contratos.
• Diseñe el override. Los humanos siempre sabrán cosas que el modelo ignora. Deles una palanca autorizada y aprenda de ella, o de lo contrario eludirán todo el sistema en una hoja de cálculo.
• Haga que el modelo rinda cuentas en pantalla. Muestre su historial junto a su predicción. La confianza es tanto una decisión de interfaz como una cuestión de matemáticas.

El machine learning era la parte fácil. Lo decimos no para menospreciar el modelo —es francamente bueno—, sino para señalar dónde reside realmente la dificultad. El bombo publicitario vende las tres semanas. Los cinco meses son por lo que de verdad se paga a un equipo de ingeniería.