¿Qué hace un científico de datos? El día real

Un 94% de acierto. Eso marcaba el primer modelo de una persona que hoy lleva años en esto: un programa que señalaba, cliente por cliente, quién de ellos iba a darse de baja de la suscripción el mes siguiente. Noventa y cuatro de cada cien veces acertaba. Lo puso en marcha, lo enseñó en una reunión y todo el mundo asintió. Tres semanas después, alguien le hizo una pregunta incómoda: «oye, ¿por qué acierta siempre justo con los que ya se han ido?».

La respuesta tardó una tarde en aparecer, y fue demoledora. Los datos de aquella empresa estaban donde están casi siempre: en tablas. Una tabla es una hoja de cálculo grande —una fila por cliente, y una columna por cada cosa que se guarda de él: su edad, su plan, el día en que se dio de alta—, solo que en vez de vivir en un fichero suelto vive dentro de un programa que la guarda y la sirve. Pues bien: una de las columnas que el modelo miraba se llamaba «número de reclamaciones en los últimos 30 días». Parecía razonable: un cliente que se queja mucho es un cliente descontento. El problema es que esa columna se rellenaba, casi siempre, cuando el cliente llamaba para darse de baja. El modelo no predecía el futuro: leía el presente y lo contaba como si fuera una predicción. Nadie le había engañado. Se había engañado él solo, y la comprobación que había montado le dio la razón.

Esa historia, con variantes, la cuenta casi todo el mundo que lleva tiempo en este oficio, y por eso empezamos por ella. La imagen que mucha gente tiene de este trabajo es la de alguien con una pizarra llena de ecuaciones, o la de alguien compitiendo por arañar una décima de acierto. Hay algo de lo primero y muy poco de lo segundo. El trabajo de verdad se parece más al de un perito que al de un matemático: alguien te entrega un resultado que parece bueno, y tu obligación profesional es intentar tumbarlo antes de que alguien tome una decisión con él.

## Un día por dentro, hora por hora

Conviene decir antes una cosa sobre el ritmo, porque sorprende. En este oficio la unidad de trabajo no es el día: es el proyecto, y un proyecto dura semanas. No se responde una pregunta por la mañana y otra por la tarde; se empuja el mismo problema durante quince o veinte días, y hay jornadas enteras que se van en entender una sola columna de una tabla. Dicho eso, el reparto de un día cualquiera dentro de ese proyecto es bastante estable, y se parece a esto:

1. 01.9:00 — Miras cómo se está portando un modelo que ya está en marcha y decidiendo cosas de verdad. Hay un resumen que se genera solo cada mañana, y hoy dice que sus predicciones están saliendo más optimistas que de costumbre. No es un error: es una señal de que el mundo de fuera puede haber cambiado.
2. 02.9:30 — Reunión con la persona que pidió el proyecto nuevo. Quiere «un modelo que anticipe qué pedidos van a llegar tarde». Te llevas media hora en averiguar lo que de verdad importa: cuándo hay que tener la predicción (¿al confirmar el pedido, o cuando ya salió del almacén?) y qué se va a hacer con ella (¿avisar al cliente, o cambiar la ruta del reparto?).
3. 03.10:15 — Antes de tocar nada, escribes la predicción más tonta posible: «ningún pedido llega tarde». Resulta que acierta el 91% de las veces, porque solo el 9% llega tarde. Ese 91% es a partir de ahora la marca que hay que batir, y cualquier modelo que no la supere no sirve para nada.
4. 04.11:00 — Peleas con los datos, que nunca vienen como te gustaría. Descubres que la hora de entrega está en dos tablas distintas y no coinciden, y que una de ellas se rellena a mano en el almacén. Dejarlo todo en condiciones de usarse tiene un nombre de andar por casa —preparar los datos— y se lleva la mayor parte del proyecto. Anotas la sorpresa y sigues.
5. 05.12:30 — Eliges qué va a mirar el programa de cada pedido para decidir, y se lo preparas dato a dato: el día de la semana, la distancia del reparto, el volumen del pedido, cuántos pedidos llevaba ese repartidor ese día. A cada uno de esos datos se le llama una variable —se llama así porque cambia de un pedido a otro, y en inglés lo vas a leer como feature en casi toda la documentación— y entre todas son lo único que el programa va a ver de cada caso: lo que no esté ahí, para él no existe. Cada una tiene que poder calcularse con lo que se sabía en el momento de predecir, y una de las que se te ocurren no cumple eso, así que se cae.
6. 06.14:00 — Comida.
7. 07.15:00 — Le pasas al programa los casos ya preparados y él busca los patrones que hay dentro. A eso se le llama entrenar el modelo, y ojo con la palabra, que en esta plataforma significa dos cosas: también es el nombre de la sección donde estás leyendo esto. Aquí, entrenar es siempre lo que hace el programa con los datos. Tarda dos segundos y da un 93%: dos puntos por encima de la predicción tonta.
8. 08.15:20 — Y aquí empieza el trabajo de verdad. Ese 93% no dice nada por sí solo: hay que comprobar que el programa no está viendo nada que en la vida real no vería, mirar a cuántos pedidos que iban bien va a marcar como problemáticos, y asegurarse de que lo has examinado con casos que no usaste para enseñarle. Si le preguntas por los mismos, no te está prediciendo nada: te está recitando.
9. 09.17:00 — Dejas escrito, junto al código, qué casos apartaste para examinarlo y por qué esos, qué datos descartaste y con qué motivo. Dentro de seis meses alguien va a preguntar exactamente eso, y ese alguien serás tú.

Cuenta las horas de esa lista que se dedican a entrenar un modelo: veinte minutos, de una jornada entera. Y de esos veinte, el programa trabaja dos segundos. El resto del día se reparte entre entender qué se pide, conseguir y entender los datos, y comprobar si el resultado es creíble. Ese reparto no es un accidente de este día concreto; es la forma del oficio, y se ve mejor así:

Merece la pena fijar dónde está la frontera entre la tercera barra y la cuarta, porque es la que más se confunde. «Modelar» termina en el momento en que el programa te devuelve un número. Todo lo que pasa después —mirar si ese número es creíble, ver a quién se equivoca y cuánto cuesta cada error, comparar contra la predicción tonta— ya es comprobar. Y esa parte no es opcional ni es el remate: es lo que convierte un número en algo que alguien puede usar.

La comprobación más básica de todas es tan simple que sorprende: de todos los casos que tienes, apartas unos cuantos antes de empezar y no se los dejas ver al programa. Le enseñas con los demás, y cuando ya ha aprendido le preguntas por los apartados, que para él son casos nuevos. Eso es lo que quiere decir partir los datos, una expresión que vas a oír mil veces en este oficio, y es lo que separa medir lo que el programa ha aprendido de medir lo que ha memorizado. Cómo se hace bien ese reparto tiene bastante más miga de lo que parece, y es donde se cae casi todo el mundo la primera vez.

## Tres oficios que se confunden todo el rato

En las ofertas de empleo y en las conversaciones de pasillo, «analista de datos», «ingeniero de datos» y «científico de datos» se mezclan como si fueran sinónimos con distinto acento. No lo son, y la forma más clara de distinguirlos no es por el título del puesto, sino por el tipo de pregunta que responde cada uno. Un analista responde «¿qué ha pasado, y cuánto?», con datos que ya existen y que alguien ha dejado ordenados. Un ingeniero de datos se asegura de que esos datos lleguen limpios, completos y a tiempo al sitio donde se van a usar; su pregunta es «¿cómo hago que este dato exista aquí, todos los días, sin que nadie tenga que rezar?». Y el oficio que has venido a aprender responde «¿qué va a pasar, con cuánta seguridad, y me lo puedo creer?».

Con un matiz sobre la palabra predecir, que conviene dejar claro pronto: no siempre significa adivinar el futuro. Predecir es calcular algo que no se sabe, y a veces eso ya ha ocurrido y lo que pasa es que nadie lo ha medido. Si esta radiografía tiene una fractura. Si el pago de ayer fue un fraude. Si esta reseña la ha escrito una persona o un programa. El futuro es el caso más común, no el único.

Un ejemplo concreto ayuda más que la definición. Imagina una empresa de suscripciones donde algunos clientes dejan de pagar cada mes: a eso se le llama en el sector churn, la proporción de clientes que se dan de baja en un periodo. Contar cuántos se han ido este mes y desde cuándo empezó a subir esa cifra es trabajo de análisis. Que la cifra de bajas llegue cada noche a la tabla correcta, sin duplicar a nadie que se dio de baja dos veces por error, es trabajo de ingeniería de datos. Y calcular, cliente por cliente, la probabilidad de que se vaya el mes que viene —y decir con cuánta seguridad, y a cuántos clientes fieles vas a molestar por equivocación— es ciencia de datos. Las tres preguntas parten del mismo problema de negocio y ninguna sustituye a las otras dos.

## El villano de esta profesión: la fuga de datos

Vuelve al 94% del principio. Ese error tiene nombre propio y lo vas a oír muchas veces: fuga de datos (en inglés data leakage), que es cuando al modelo le llega, por descuido, información que en el momento real de predecir no existiría. Es el error más caro de este oficio por dos motivos combinados: no se ve, y hace que tus resultados mejoren. Un fallo que empeora los números se detecta enseguida, porque duele. Un fallo que los mejora se celebra.

El caso de las reclamaciones es la versión más fácil de contar, pero la fuga aparece con muchas caras distintas. Una columna que se rellena después de que pase lo que quieres predecir. Una fecha que se actualiza al cerrar el caso y no al abrirlo. Un comentario escrito a mano donde alguien dejó dicho el desenlace: «se va porque le sube el precio», en la casilla de observaciones. Y una que no vive en ninguna columna, la más difícil de ver de todas: que al preparar los datos se mire también los casos que habías apartado para examinar al programa. Entonces el examen deja de ser un examen, y no hay ni un dato sospechoso a la vista. Todas tienen la misma firma en el resultado: un número sospechosamente bueno.

## La costumbre que separa un modelo de un gasto

Hay un hábito que en esta profesión se practica antes de entrenar nada, y que ya has visto colarse en el día de antes: preguntarse qué pasa si predigo lo más tonto posible. Decir siempre la respuesta más frecuente. Decir siempre la media. Decir que mañana pasará lo que pasó hoy. Eso se llama línea base (*baseline*), y no es un trámite: es la vara con la que se mide todo lo demás. La predicción tonta se escribe en un minuto; un modelo se lleva semanas de trabajo, de reuniones y de peleas con los datos. Si después de esas semanas no le gana a ese minuto, no tienes un modelo: tienes un gasto.

## Y una pregunta honesta: ¿hay trabajo de esto?

Sí, y en sitios menos glamurosos de lo que la gente imagina: bancos que deciden a quién dar un préstamo, aseguradoras que calculan riesgos, fábricas que quieren saber qué máquina va a romperse, hospitales que priorizan listas de espera, tiendas que predicen cuánto pedir de cada producto. No es un oficio de laboratorio: es un oficio que toma decisiones sobre personas y sobre dinero, y esa es exactamente la razón de que la honestidad en la evaluación no sea un detalle técnico.

De sueldos y número de ofertas no se van a dar cifras aquí, y es a propósito: cambian por país, ciudad y tamaño de empresa, y cualquier número concreto se queda viejo en un año. Contrástalo siempre con datos del año en que estés leyendo esto. Lo que sí se puede decir sin caducidad es qué se pide de verdad en las entrevistas, porque lleva años siendo lo mismo: saber traducir un problema de negocio en algo predecible, saber preparar datos, y saber explicar por qué te crees tu propio resultado. Lo tercero es lo que más gente falla.

## Lo que de verdad se aprende aquí

Si has llegado hasta aquí, ya tienes la idea central. Entrenar un modelo es la parte fácil: el programa que busca los patrones lo escribió otra gente, tú le pasas los datos y en unos segundos tienes un resultado. Lo difícil, lo que se paga y lo que casi nadie enseña, es saber si puedes creértelo. En este oficio el adversario no es el problema ni la competencia: eres tú, porque eres tú quien monta la comprobación que te va a dar la razón. La única defensa es un método que te lo ponga difícil a ti mismo, y ese método tiene una forma concreta y un orden.

Ya sabes en qué consiste el oficio y cuál es su trampa característica. Lo que falta es el orden: cómo se recorre un proyecto de principio a fin, desde la frase vaga que alguien suelta en una reunión hasta un modelo que decide cosas de verdad, y en qué punto exacto de ese recorrido se pone la comprobación que evita el 94% de mentira.