lección 3
El ciclo real: pregunta → datos → modelo → validación honesta → producción
Las cinco etapas de cualquier proyecto de predicción, por qué la cuarta es la que decide si el trabajo sirve, y por qué el ciclo casi nunca se recorre en línea recta.
⏱ 45 min
En 2006, Netflix hizo algo insólito: publicó datos de cien millones de valoraciones de películas y ofreció un millón de dólares a quien consiguiera mejorar en un 10% su sistema de recomendaciones. Miles de equipos de todo el mundo se pasaron tres años en ello. En 2009 se entregó el premio a un equipo que había combinado más de cien modelos distintos. Y luego pasó lo que casi nadie cuenta: ese modelo ganador nunca llegó a funcionar en Netflix. La propia empresa lo explicó años después, en su blog de ingeniería: sí aprovecharon parte de lo aprendido, pero la mejora adicional del conjunto completo no justificaba el trabajo de ingeniería que costaba ponerlo y mantenerlo en marcha.
Un millón de dólares, tres años de trabajo de miles de personas, y el resultado se queda en un cajón. No porque el modelo fuera malo —era el mejor que existía— sino porque un proyecto de predicción no termina cuando el número mejora. Tiene cinco etapas, y las dos últimas son las que se llevan por delante la mayoría de los proyectos. Esta lección es el mapa de esas cinco etapas, y el mapa más importante de la profesión: cada herramienta que aprendas después encaja en una de ellas, y sin el mapa cada herramienta parece un truco suelto.
## Las cinco etapas, una por una
Etapa 1 — La pregunta. Nadie te va a pedir un modelo: te van a pedir un deseo. «Queremos reducir las bajas de clientes», «queremos que no se nos rompan las máquinas». Convertir eso en algo predecible exige responder cuatro cosas, y ninguna es técnica: qué se predice exactamente (¿que un cliente se dé de baja, o cuánto va a gastar?), para cuándo (¿el mes que viene, los próximos noventa días?), en qué momento hay que tenerlo (¿al contratar, o cada noche para todos los clientes?) y, la que más se olvida, qué se va a hacer distinto con la predicción. Si la respuesta a la última es «nada» o «ya veremos», no hay proyecto: hay una curiosidad muy cara, y va a terminar en un cajón como el modelo de Netflix.
Etapa 2 — Los datos. Aquí hay que conseguir información de casos pasados donde se sepa cómo acabó la cosa, porque es de ahí de donde el modelo aprende. Y aquí está la regla propia de esta profesión, la que no aparece en ningún otro oficio de datos: cada dato que uses tiene que haber existido en el momento en que la predicción habría que hacerla, no después. Un modelo que decide al confirmar el pedido no puede mirar la hora de entrega, porque cuando confirma el pedido esa hora no existe todavía. Suena obvio dicho así, y sin embargo es el error que más proyectos arruina, porque los datos que tienes delante están todos rellenos: la tabla no te dice en qué orden se rellenaron sus columnas.
Etapa 3 — El modelo. Es la etapa corta, y conviene saber por qué: el programa que encuentra los patrones ya está escrito, lo escribió otra gente, y tú lo usas. Le pasas los datos, esperas unos segundos y tienes un resultado. Antes de eso, siempre, se calcula la predicción más tonta posible —la respuesta más frecuente, la media, lo que pasó ayer—, que es la línea base: la marca que hay que batir. Y aquí conviene una advertencia que ahorra meses: el primer modelo que entrenes debe ser el más simple que resuelva el problema, no el más moderno. Un modelo simple que funciona y se puede explicar vale más que uno complejo que acierta un poco más y nadie entiende, y el caso de Netflix es la demostración más cara de eso.
Etapa 4 — La validación honesta. Esta es la etapa que da nombre a la lección y la que vamos a mirar con lupa dentro de un momento. En una frase: montar la comprobación de manera que tu modelo lo tenga difícil, y no fácil. Tan difícil como lo va a tener el día que funcione de verdad. Es la única etapa donde el trabajo consiste en intentar demostrar que lo que has hecho no sirve.
Etapa 5 — Producción. Que el modelo funcione de verdad, tomando decisiones sobre casos reales, todos los días. Y esto no es el final feliz: es el principio de otra historia. Un modelo aprende de un mundo que ya pasó, y el mundo cambia. Cambian los precios, cambia la competencia, cambian los hábitos de la gente, alguien cambia el formulario de la web y una columna empieza a llegar vacía. Así que un modelo que ya está en marcha se vigila, y cada cierto tiempo se le vuelve a enseñar con datos más recientes —a eso se le llama reentrenar— o se retira. Un modelo que se pone a funcionar y se olvida es un modelo que en algún momento empieza a equivocarse en silencio.
## Por qué la validación es el centro y no un paso más
Aquí está la idea que sostiene toda la profesión, y merece la pena leerla despacio. Un modelo se juzga por cómo acierta en casos que no ha visto nunca. Eso significa esconderle una parte de los datos, entrenarlo con el resto y medirlo sobre la parte escondida: a eso se le llama partir los datos. La analogía es la del estudiante y los exámenes: si le das los exámenes de otros años con las soluciones y luego le examinas con esos mismos exámenes, vas a medir su memoria, no su conocimiento. Sacará un diez y suspenderá el examen de verdad. Un modelo hace exactamente eso si lo mides con los datos que usaste para enseñarle: se los ha aprendido.
Ese reparto suele hacerse en tres montones y no en dos, y el tercero se entiende bien siguiendo con el examen. Con el primero, el más grande, el programa aprende. Con el segundo ensayas alternativas —¿va mejor así, o de esta otra manera?— y eliges una. Y el tercero no se toca: se abre una sola vez, al final, y después ya no se cambia nada. Si vas mirando ese último montón para ir decidiendo, le vas contando sus respuestas poco a poco y deja de ser un examen; un estudiante al que dejas ver el examen final tres veces antes de hacerlo no está haciendo un examen. Por eso el tercer montón se guarda bajo llave hasta el final, y por eso hay que decidir de antemano cuántos casos van a cada uno.
Cuando eso no se hace, aparece un fenómeno que tiene nombre —sobreajuste, en inglés *overfitting*— y que describe un modelo que se ha aprendido de memoria los datos que le diste en vez de la regla que hay detrás. Un modelo sobreajustado es peligroso precisamente porque en tus propias comprobaciones se ve estupendo. Por eso repartir los datos no es un detalle de procedimiento: es lo que hace que tu medición signifique algo.
Si tus datos llevan fecha, repartirlos al azar es el error más silencioso de esta profesión. Imagínalo así: repartes al azar las escenas de una película entre dos montones, entrenas con uno y examinas con el otro. El modelo ha visto el final antes de que le preguntes por el nudo. Con datos que avanzan en el tiempo —ventas, averías, bajas de clientes— el único reparto honesto es por fecha: se aprende con lo anterior y se examina con lo posterior, igual que pasa en la vida real, donde hoy solo puedes saber lo de ayer.
Hay una segunda forma de hacer trampas sin querer, y es más sutil. Antes de entrenar, los datos casi nunca están listos: hay que retocarlos. Y dos retoques son tan habituales que conviene verlos de cerca, porque el segundo es el protagonista de la trampa.
El primero es rellenar huecos. Si a doscientos clientes les falta la edad, hay que poner algo, y lo más corriente es poner la edad media de los demás. El segundo es poner los números en la misma escala, y esto pide un ejemplo. Imagina dos datos de la misma persona: su edad, que va de 18 a 90, y sus ingresos al año, que van de 12.000 a 90.000. Son números de tamaños muy distintos, y hay programas que, por cómo están hechos por dentro, le hacen más caso a lo que viene con números más gordos: los ingresos pesarían mil veces más que la edad sin que nadie lo haya decidido. La solución es convertir los dos a una misma horquilla —por ejemplo, entre 0 y 1— para que compitan en igualdad de condiciones. Y fíjate en lo que hace falta para conseguirlo: calcular el menor y el mayor de cada dato. Igual que rellenar huecos necesitaba calcular una media.
Ahí está la trampa, y no tiene nada que ver con las columnas: esas cuentas hay que hacerlas mirando solo los casos con los que el programa va a aprender. Si la media de la edad, o el mayor de los ingresos, se calculan sobre todos los datos —incluidos los del examen final— el examen ya está contaminado, porque en la preparación se ha colado información de las respuestas que ibas a comprobar. Es una fuga, la misma de la que ya hemos hablado, con otro disfraz: aquí no hay ninguna columna sospechosa, solo un orden de operaciones equivocado.
Y queda la tercera obligación de esta etapa, que no va de repartos sino de cómo se lee el resultado: ninguna cifra de acierto significa nada sin su contexto. Hacen falta tres cosas para interpretarla. Cómo están repartidas las respuestas en los datos, porque con un 3% de casos raros acertar el 97% es no hacer nada. Contra qué se compara, o sea la predicción tonta. Y qué error cuesta más de los dos posibles, que casi nunca cuestan lo mismo: decirle a una persona sana que está enferma manda a alguien a hacerse más pruebas, y decirle a una persona enferma que está sana la manda a casa. El mismo modelo, con el mismo porcentaje, puede ser aceptable en un caso e inadmisible en el otro.
Consejo de veterano, y es el orden en que se hacen las preguntas: cuando alguien te enseñe un resultado —o cuando te lo enseñes a ti mismo— pregunta primero cómo se repartieron los datos y después cuánto acierta. Al revés no funciona, porque en cuanto oyes un número bueno ya estás buscando motivos para creértelo. Si el reparto no aguanta, el número no hay ni que mirarlo.
## Por qué el ciclo casi nunca es una línea recta
Contado en cinco cajas ordenadas parece un proceso limpio: preguntas, consigues datos, entrenas, compruebas y lo pones en marcha. En la práctica casi nunca ocurre así, y quien empieza esperando esa línea recta se lleva un disgusto en el primer proyecto. El ciclo se rompe hacia atrás constantemente, y conviene reconocer las vueltas porque las tres parecen un fracaso personal y ninguna lo es.
La primera es de los datos a la pregunta. Vas a buscar casos pasados y descubres que no existen: nadie registró qué máquinas se averiaron, solo cuándo se repararon. O existen pero son treinta casos, y con treinta casos no se aprende nada. Aquí no queda otra que volver a la pregunta y replantearla con lo que sí hay, y hacerlo pronto es una virtud, no una rendición.
La segunda es de la validación a los datos, y es la más frecuente. Montas la comprobación honesta y el resultado empeora de golpe respecto a lo que te salía antes. Eso normalmente no significa que el modelo sea malo: significa que la medición anterior estaba inflada y ahora estás viendo la verdad. Toca volver a los datos que el modelo miraba, quitar el que se colaba, y aceptar un número más bajo y más real. Es el momento más ingrato del oficio y el que más valor aporta.
Y la tercera es de producción hacia atrás, la que no se acaba nunca. El modelo lleva ocho meses funcionando y sus aciertos van cayendo poco a poco. No se ha roto nada: el mundo se ha movido, y los patrones que el modelo aprendió ya no son los que hay. Hay que volver a los datos —a los nuevos— y entrenar otra vez. Esta vuelta atrás es, de hecho, el trabajo cotidiano de mucha gente en esta profesión: no construir modelos nuevos, sino mantener honestos los que ya deciden cosas.
No confundas «volver atrás» con «no saber hacer el trabajo». Un proyecto que recorre las cinco etapas sin ninguna vuelta atrás es sospechoso: casi siempre significa que la validación no apretó lo suficiente. Y desconfía especialmente del primer resultado que sale bien a la primera, porque en este oficio los resultados buenos y fáciles suelen ser resultados mal medidos.
Ese es el mapa entero, y con él ya tienes lo que esta profesión tiene de propio: el sitio exacto donde se pone la desconfianza. Lo que viene ahora es más terrenal y es imprescindible, porque ninguna de las cinco etapas se puede recorrer con las manos vacías. Hay que saber darle órdenes a tu propio ordenador, aprender a construir instrucciones que una máquina ejecute, y saber pedirle datos a una base de datos sin depender de que alguien te los exporte. Suena menos emocionante que entrenar un modelo. Es lo que separa a quien puede hacer este trabajo de quien solo puede leer sobre él.
## comentarios
Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.
Inicia sesión para comentar y responder.
cargando comentarios...
Regístrate para guardar tu progreso.