El nuevo científico de datos

Todos los años se publican predicciones sobre las profesiones del futuro, en las cuales los programadores repiten sistemáticamente entre las primeras posiciones. Sin necesidad de irnos hacia el siguiente lustro o década, sin duda uno de los puntos calientes del mercado de trabajo es actualmente el puesto del científico de datos.

A decir verdad el nombre de científico de datos no me parece del todo apropiado. El puesto es una combinación de administrador de base de datos, programador y matemático. El científico de datos una de esas mezclas como la de un biólogo con un informático para sacar un bioinformático o un ingeniero industrial con un informático para dar un especialista en smart grids.

El hito más llamativo en la inaguración de esta nueva profesión fue el fallido premio Netflix de 1 millón de dólares a quién mejorase la precisión de su algoritmo de recomendaciones en un 10%.

Es un trabajo en el que se distinguen varias etapas:

– Definición de modelos y algoritmos.
– Montaje de la infraestructura hardware y software.
– Extracción y carga de datos.
– Procesado.
– Análisis, interpretación y presentación de resultados.

Es bastante difícil encontrar un buen científico de datos, pues se requiere una combinación poco común de conocimientos de matemáticas, administración de sistemas, y programación, además de la capacidad de extraer y explicar las conclusiones de una forma clara para que los directivos las entiendan.

¿Qué se necesita para ser científico de datos?

Si quieres ser científico de datos debes hacer básicamente lo siguiente:

1º) Desempolva todos tus apuntes de estadística.
2º) Escoge una pila de productos de las que describeré a continuación.
3º) Aprende a programar en Java y Python o R.
4º) Aprende a usar algunas herramientas de visualización de datos.

Algoritmos

El machine learning es una rama de la inteligencia artificial que trata sobre cómo los algoritmos pueden aprender de los datos. A grandes rasgos, el machine learning consiste en encontrar una forma de representar datos y evaluarlos de manera que se puedan obtener generalizaciones de los mismos. Típicamente, lo que hacen los algoritmos es aplicar una función de evaluación (también llamada en inglés objective function o scoring function) y luego aplicar otra rutina para buscar máximos de dicha función. La siguiente tabla muestra ejemplos de estos tres componentes de representación, evaluación y optimización.

La lista de algoritmos de machine learning es muy extensa y su comprensión requiere de conocimientos bastante técnicos, por lo cual no voy a entrar aquí detalladamente en ella. Los algoritmos se pueden agrupar en 5 grandes familias: aprendizaje supervisado, aprendizaje no supervisado, inferencia transductiva, aprendizaje por refuerzo, y deep learning (que es con lo que parece que está experimentando Netflix últimamente).

Entre los algoritmos más populares están: k-medias, máquinas de vectores de soporte, apriori, esperanza-maximización, AdaBoost, Knn, Bayes Naive y CART.

Las redes de neuronas parece ser que se van a volver a poner de moda, especialmente las implementadas en hardware, aunque yo tengo artículos y prototipos de emuladores de neuronas con resistencias ajustables que datan de los años noventa. Ya veremos si llegan a algún sitio o suman y siguen en la larguísima lista de expectativas incumplidas de la inteligencia artificial.

Desafíos del machine learning

Con independencia del algoritmo utilizado lo que cuenta es la generalización más allá del juego de pruebas porque es prácticamente imposible que los datos reales de entrada sean iguales a los del juego de prueba. El error más común entre los principiantes en machine learning es crearse una ilusión de éxito sólo porque el algoritmo se comporta bien con el juego de pruebas, hasta que se prueba con datos reales y entonces se descubre que se comporta sólo un poco mejor que si estuviera haciendo elecciones al azar. Por consiguiente, si contratas a alguien para un trabajo de machine learning, guárdate un conjunto de datos que el desarrollador no haya visto con anterioridad para probar lo que te entregue.

Es importante mantener separados los juegos de datos para entrenamiento y para pruebas porque es fácil contaminar el clasificador con datos de prueba. El caso más extremo se conoce como overfitting, cuando el clasificador acierta el 100% de las veces con el juego de pruebas pero sólo el 50% con los datos reales. La razon para ello es que los datos en sí mismos no son suficientes. Como punto de partida es necesario hacer algunas suposiciones iniciales acerca de los datos. De hecho existe un teorema llamada no free lunch según el cual cualquier par de algoritmos de optimización es equivalente cuando su rendimiento se promedia a través de todos los problemas posibles. El overfitting suele descomponerse en el error sistemático (bias) y la varianza (variance). El error sistemático es una medida de la tendencia del sistema a prender la misma cosa equivocada. La varianza es la tendencia a aprender cosas al azar con independencia de la señal de entrada.

Tras el overfitting, el segundo mayor problema del machine es la dimensionalidad. Muchos algoritmos funcionan muy bien con dimensiones bajas, pero, en general, la dificultad del problema crece exponencialmente con su dimensión. Con una dimensión de tan solo 100 y un juego de prueba de 10¹² la cobertura de casos es sólo 10^-18 del espacio de entrada. Las intuiciones que tenemos extraidas sobre el mundo tridimensional no se cumplen en dimensiones altas. En dimensiones altas la mayoría del volumen de una naranja está en su corteza y no en su pulpa.

Pilas de productos

Hay en esencia tres pilas de productos para el científico de datos :

– Software Open Source sobre Hadoop o Spark.
– Productos privativos.
– Soluciones SaaS.

Ningún producto soluciona todas las necesidades y ninguna pila es absolutamante mejor para cualquier cosa. La fiebre mayor es actualmente alrededor de Hadoop. Hadoop en sí mismo sólo es un sistema de ficheros distribuidos. Encima de Hadoop se puede montar HBase como implementación del Bigtable de Google. Pero Hadoop en en sí mismo lo único que permite es almacenar ficheros de forma redundante en varias máquinas y ejecutar procesos de transformación sobre dichos ficheros minimizando el tráfico de red entre los nodos. Lo más popular es ejecutar MapReduce. Pero Hadoop no está para nada limitado a MapReduce. La Fundación Apache tiene su propio producto de machine learning sobre Hadoop, Mahout, el cual implementa algunos de los algoritmos que hemos mencionado anteriormente (k-medias, Bayes, Naive…) para crear recomendadores de producto y cosas por el estilo.

Aunque, muy probablemente, la próxima estrella rutilante de la Fundación Apache sea Spark. La diferencia fundamental con Hadoop es que Spark está orientado a trabajar con datos en memoria en lugar de lotes MapReduce a disco. Además es mucho más sencillo usar Spark desde Scala o Python que montar procesos Hadoop en Java.

A mi me sorprende un poco que no se aprecie en el mercado más demanda de Cassandra. Ya que Hadoop en sí mismo no es una base de datos, mientras que Cassandra sí es una base de datos orientada a columna. Quizá sea por el pequeño pero importante detalle técnico de que Cassandra no proporciona ninguna forma de ordenar resultados en las consultas, o, al menos, ese fue un factor decisivo para descartar su uso en un par de proyectos en los que yo estuve involucrado en los últimos años.

En paralelo a la creciente oferta Open Source se pueden encontrar productos bastante especializados. KXEN para análisis predictivo en desafíos como la detección de fraude, PROS para pricing, etc. Que se suman a los productos clásicos de Business Intelligence: QlikTech, Cognos, PowerPivot, etc. La moda entre las start ups y muchas empresas medianas es hacerlo todo in-house. Sobre todo porque los productos comerciales de BI/Big Data no son a priori baratos, aunque por lo que yo voy viendo, contratar a una legión de científicos de datos inexpertos para resolver un problema que no se conoce muy bien les saldrá probablemente más caro a muchas empresas que haber contratado de saque a alguien con experiencia en minería de datos.

Por último, están las soluciones SaaS, de las cuales en España hemos visto de un tiempo a esta parte algunas start ups muy prometedoras como BrainSINS para las recomendaciones de eCommerce, SocialBro para targeting y analítica en Twitter, Alto Analytics para análisis de lenguaje natural en redes sociales, Intelify Cities, o Bynse para llevar el Big Data a la agricultura. La razón para elegir un SaaS es sencilla: los proyectos Big Data no son para nada simples ni en su concepción ni en su infraestructura ni en su operación diaria. Se pueden tardar fácilmente seis meses en armar un proyecto Big Data y otros dieciocho en conseguir que empiece a proporcionar resultados significativos. Conozco bastantes empresas que últimamente han cogido dinero y se han puesto a hacerse el Big Data ellas mismas, amenudo anticipando preguntas y prejuzgando sus respuestas, pero sólo tras estudiar decena de millones de tickets de la compra de supermercados se puede saber con certeza que los pañales se compran con las cervezas.

Post relacionados:

La siguiente ola del business intelligence será explotar el “gray data”.
El científico de datos será el nuevo community manager.