¿Qué necesitas saber para ser un buen científico de datos que no aparece -mucho- en los tutoriales?

  ¿Qué necesitas saber para ser un buen científico de datos que no aparece -mucho- en los tutoriales?

(1) Saber desarrollo de software. Saber "programar" no es suficiente. Hay gente que cree que hacer ciencia de datos es hacer 4 notebooks guarros. El problema viene luego cuando los resultados no son reproducibles, cuando el código está duplicado (o n-plicado),......cuando se te pide por parte del equipo de ingeniería código para subirlo a producción. Hay gente que opina que se puede ser científico de datos sin haber hecho un simple test de unidad. Hoy, después de 8 años en el gremio lo niego.

Dentro de este punto yo diría que hacen falta 3 cosas: (a) Familiaridad con el TDD (test-driven development). El uso de lenguajes no tipados como Python hace que no sepamos si un código va a funcionar hasta que lo ejecutemos.

He visto ejecuciones romperse a las 2 horas porque una keyword o una variable estaba mal escrita. Esto es inaceptable, sobre todo en entornos de negocio donde hay mucho stack súper paralelo y chachi guay, y los scientists son unos papanatas.

Hay gente que dice "no, es que yo soy de matemáticas". Yo suelo responder "es que yo soy de informática y tuve que apretar en otras cosas". Un data scientist es un unicornio que tiene que estar formado en muchas cosas.

Idealmente habría que hacer tests de unidad, tests de integración y tests de comportamiento. Para ello hay que dominar un paquete de test (yo uso unittest en Python) y técnicas como el mocking o las fixturas.

Repito, un curso de programación para ciencia de datos que no enseñe metodologías de tests no vale un pimiento.

b) Patrones y arquietectura de software. Estamos en la tercera década del S. XXI. El código ya no se escribe con tarjetas perforadas. Tenemos editores e IDEs que lo mismo te escriben código solo que te preparan un café. ¿Por qué no haces un buen diseño?

Un buen diseño sigue metodologías (KISS, DRY, SOLID), usa un lenguaje común (el de los patrones de diseño y arquitectura) y tiene un nivel aceptable de documentación. Nótese que no hablo de saber construir una arquitectura de microservicios, de montar una API...

...o de cosas más típicamente ingenieriles. Para eso suele haber un ingeniero de sofware o un equipo de ingeniería. Pero esa gente no puede recibir un notebook desvencijado de código espagueti. Si usualmente haces esto corres muchos riesgos,...

...no solo por ti mismo, sino porque dicho equipo cambie tu código por desconocimiento del mismo.

(c) El ecosistema. Si usas Python o R hay un "stack" que tienes que conocer y manejar con soltura. Si algo se puede hacer con Pandas, usa Pandas. Si algo se puede hacer con Scipy, úsalo. Los paquetes están hechos por gente inteligente que dedica muchas horas de su vida a proveer

un interfaz genérico y además eficientemente implementado para realizar operaciones comunes. Seamos lo suficientemente humildes para aceptar que nuestra implementación jamás será tan buena (empezando por el hecho de que el paquete está hecho en un lenguaje compilado).

(2) Un científico de datos necesita saber los principios de la investigación científica. ¿Qué es una hipótesis? ¿Cómo se verifica ésta? ¿Cómo puedo obtener una hipótesis por intuición? Se habla mucho de que un científico de datos necesita "comunicación". Está bien.

Pero comunicar necesita de un proceso reflexivo. Si no, produces lo que en el mundo anglosajón llaman "bullshit". Llegas con una colección de palabrejas y gráficos y "vendes la moto". Un científico de datos es, como su nombre indica, un científico.

Si quieres hacer un modelo para predecir cuántos clientes van a venir a tu tienda en un cierto día necesitas construir una serie de hipótesis. ¿Cuántos clientes en promedio vinieron los últimos N días? ¿Y el máximo y mínimo? ¿Hay estacionalidad?

 ¿Qué factores podemos determinar que influyen en una persona aleatoria para que entre en nuestro comercio y se convierta en cliente? ¿Qué factores son controlables/accionables por nosotros? Todo este tipo de obviedades a mucha gente se le olvida hacerlas.

Se sientan en un problema a "programar". Y luego el modelo no vale para nada. El científico estudia realidades con base a ciertas hipótesis, donde la principal hipótesis es que hay una realidad predecible a través de un modelo, y construye dicho modelo.

 

El modelado debe ser un paso en el que se ya ha aquirido suficiente conocimiento a través del análisis del problema y del negocio y que puede producir una predicción útil desde el punto de vista matemático y del negocio.

He usado "negocio" porque las métricas en ciencia de datos muchas veces hay que traducirlas a unidades de negocio. "Mi algoritmo tiene una ROC de 0.9238076203" es algo bastante poco útil para tu jefe. Probablemente después de esto piense que eres un freak y que no eres útil.

 

Sin embargo "mi modelo descubre 3 veces más fraudes que el sistema existente" o "con el uso de este modelo podríamos reducir el coste de intervención humana al 25%" son métricas que son más fáciles de entender.

Dentro de la comunicación científica y del proceso de desarrollo existe otro palo que conviene tocar: el de los riesgos. Los riesgos son algunas veces cuantificables mediante el uso de medidas de incertidumbre. No es lo mismo un modelo que "acierta el 75% de las veces"...que un modelo que "acierta el 75% de las veces, pero con desempeño entre el 10% y el 90% según días". Los dos son modelos que funcionan igual pero el segundo da más información. ¿Es el 10% (caso límite) admisible en tu entorno? Quizás 75% es una cifra buena pero el 10% no

 

Hay otro tipo de riesgos asociados a factores externos: variables socioeconómicas globales, cambio de poblaciones, muestra de desarrollo sesgada, etc. ¿Suponemos que afectan o no a las hipótesis iniciales? Ese proceso de acotación es importante en ciencia de datos.

 

(3) Un científico de datos tiene que desarrollar ciertas características personales que le ayuden a hacerse valer. Primero, la curiosidad. La curiosidad te lleva a "hacer análisis". A validar hipótesis sencillas que se pregunta uno mismo. A "jugar" con el dato.

 

Tomar el dato como una caja negra es un síntoma de inmadurez, y de falta de curiosidad por el problema que uno maneja. Para entender un problema hace falta atacarlo desde varias dimensiones: matemática/estadística, implementación, estado del dato en sí mismo, métricas de negocio,

. Un científico curioso, de forma natural llevará esa curiosidad a cada una de las facetas del problema, porque la curiosidad es como un proceso de tapar agujeros en un muro lleno de los mismos. Para desarrollar la curiosidad conviene hacer un ejercicio de escritura constante.

¿Tienes un "cuaderno de trabajo"? ¿Dónde tomas las notas? ¿Te haces preguntas a ti mismo que no sabes responder (si es así, buena señal)? Y, finalmente, el "peer review". Es importante trabajar con los otros. Que miren tu trabajo. Que escuchen tus hipótesis, y te las confronten.

 

Ese último punto tiene que llevarnos necesariamente a la segunda de las actitudes del científico de datos: la necesaria humildad. Creer que "todo es predecible" o argumentar falsedades sobre un posible modelo sin conocer los entresijos del problema mina la propia credibilidad.

Un científico además de curioso tiene que conocer las limitaciones de los métodos que maneja. "Creo que este problema podría ser resuelto mediante aprendizaje automático, pero tendría que ver cual es la calidad del dato que contamos" es una afirmación más valiosa que..."ah sí, te monto una red neuronal con VGG16 en Keras y ya verás qué bien funciona". Lo primero es ser cauto, pero también, implícitamente, mostrar que en este mundo no todo es factible. Llevar a tus jefes (o "stakeholders") a un terreno común donde hay incertidumbre,... te puede hacer muy valioso si los resultados luego salen mucho mejores que las expectativas que creaste. Y te puede salvar si tu modelo finalmente no sirven. Porque queridos lectores, en este mundo hay muchas cosas que "no salen". Igual que en ciencia.   

El escepticismo también se tiene que mostrar al presentar resultados. "Esto que muestro aquí es un resultado preliminar, del que no estoy totalmente seguro". O "es muy posible que haya problemas acá, así que no os toméis esto al pie de la letra".

 

Al final todo va relacionado. Los tests evitan riesgos funcionales. El escepticismo modula posibles fallos de desarrollo de software. La humildad prepara a los jefes para cuando el dato disponible resulta ser una castaña.

Que está muy bien que haya que saber el último paquete de Python, el whyper-tryper-súper-díper, las últimas teorías estadísticas Wassersstein-Albolotesstein, o los últimos Unstable-diffusion-delusion modelos neuronales. Eso, o está anticuado en 5 años, o es "potencia sin control"

 

Aportar valor no es solo aportar en tu área, es aportar al proceso. Un proyecto puede fallar por incapacidad de predecir a partir del dato, pero un científico curioso que conozca qué pasa puede sugerir una mejor recogida del mismo.

 

Unos jefes bien enseñados y a los que se les presenten resultados con la máxima cautela y neutralidad sabrán calibrar bien el valor de una estrategia basada en datos y se acostumbrarán a incrementos mantenidos y no a picos.

       

Un científico de datos que tenga estas características ganará en consideración y trabajará desde la proactividad (última característica personal). Se convertirá en un "nodo central" dentro de su equipo de trabajo, siendo capaz de trabajar codo con codo con un equipo de desarrollo siendo capaz también de estar cerca de los analistas de negocio, incluso de la gente que tenga más en cuenta los asuntos púramente económicos, y siendo, en general, apreciado por su exactitud y rigor. Aunque no conozca la última versión del stable diffusion janderclander.

 

https://twitter.com/alfonsoeromero/status/1605270331073110032