2018 ha sido un año intenso en datahack. Un año de crecimiento, pero también un año de mejoras, tanto en nuestro Master de Big Data Analytics, que tiene un temario actualizado y ahora es modulable, como en el área de labs, donde ya estamos dando pasos más allá del deep learning para sacarle todo el jugo al proyecto DIA4RA.

¿Quieres saber lo que ha pasado este año en datahack? Este es un breve resumen de los pasos que hemos dado para ser los mejores expertos en Big Data & Analytics:

Nace nuestra división de talento: DH SEED, headhunter experto en Big Data y entornos digitales

Las vacantes en Big Data & Analytics de las empresas son cada vez más difíciles de cubrir, puesto que no hay suficientes perfiles especializados para todas las necesidades del mercado actual. Nosotros no solo tenemos una alta especialización en el sector y formamos a los mejores profesionales con nuestro Master de Big Data & Analytics, sino que además tenemos un equipo de recursos humanos que conoce el entorno y sabe adaptarse a las necesidades mejor que nadie.

Mejoramos el programa de nuestro Master de Big Data & Analytics

Actualizamos constantemente el programa del Master de Big Data & Analytics para que siempre esté a la última en las tecnologías más punteras, pero este año hemos ido más allá y hemos dado la posibilidad de modular el máster en dos: Máster de Científico de Datos y Máster de Arquitecto de Datos.

Academia Digital de Fundación ONCE

Datahack se encargó de impartir los tres itinerarios de cursos de la Academia Digital para personas con discapacidad de Fundación Once. El objetivo máximo de esta Primera Edición de la Academia Digital Fundación ONCE fue facilitar el acceso al empleo en el mundo digital a este grupo de apasionados estudiantes. Resultó ser un éxito rotundo.

Nuestro nuevo compañero de trabajo: el robot AIDA

Llevábamos ya tiempo trabajando en el proyecto DIA4RA (con robots más básicos o gracias a la ayuda del equipo de la URJC), pero la llegada de AIDA  nos dio una gran agilidad y libertad para llevar a cabo la aventura. Es nuestra niña mimada y les estamos enseñando muchas cosas con lo último en tecnologías de deep learning, machine learning e inteligencia artificial que la ayudarán a asistir a las personas con alzheimer.

¡Nuestro Master de Big Data & Analytics se inauguró en Sevilla!

Ya habíamos hecho algunos proyectos en la ciudad, como la Academia Digital de Fundación ONCE para personas con discapacidad. Pero decidimos dar un paso más y ofreceros nuestros programas de formación en Big Data más avanzados también en esa ciudad. La primera edición del Master de Big Data & Analytics ya está en marcha y pronto habrá más. Si eres del Sur, ¡no dejes pasar la oportunidad!

Patrocinamos los dos grandes eventos de Big Data de España

Es decir, el Big Data Congress de Barcelona y el Big Data Spain de Madrid. Allí, no solo tuvimos nuestro stand donde poder informar de nuestra Formación en Big Data; de los servicios de nuestra área de talento, DH SEED, headhunter especializado en Big Data y perfiles digitales; de nuestro departamento de labs... sino que también ofrecimos diversas charlas y ponencias.

Éxito total en Innodata

También hicimos nuestro gran evento de Big Data en Madrid, el Innodata, que acogió a más de 100 personas interesadas en el mundo de los datos. Pronto iremos subiendo más información sobre todo lo que ocurrió allí, ¡estad atentos!

¡A por el próximo año!

Y eso es lo más importante, aunque no todo. Hemos experimentado un crecimiento importante, hemos sido anfitriones de numerosos eventos de Big Data & Analytics, hemos realizado interesantísimos artículos relacionados con el Big Data en nuestro blog... y un sinfín de cosas más. Os invitamos a que las descubráis todas buceando por nuestra web...

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

En DHSEED somos conscientes de que orientar una compañía hacia la digitalización y el Big Data supone un proceso complejo de realizar. Por ello, acompañamos a la empresa en ese proceso, ya que ofrecemos consultoría orientada a la transformación digital; somos headhunters  especialistas en la evaluación, búsqueda y selección de perfiles de IT, Big Data y digital. Para más información pincha aquí.

Retomamos el blog de AIDA con menos avances de los que desearíamos. Por un lado, desde el punto de vista de cada modelo de Deep Learning, nos hemos dado cuenta de que no estamos completamente satisfechos con casi ninguno de los conseguidos hasta el momento. Todos tienen algo que nos gustaría mejorar, cambiar o directamente volver a empezar. Todo ellos son poco viables en mayor o menor medida, ya que tenemos que estar siempre con un ojo en la planificación y, como dice nuestro compi Marcelo con mucha razón, si por nosotros fuera estaríamos un año con cada modelo: dándole vueltas, ampliando el dataset, tratando de introducir perturbaciones...

Problemas encontrados en los modelos de Deep Learning

Nos hemos encontrado (o más bien dado de bruces) con nuestras propias limitaciones y también las del Deep Learning, sobre las cuales otro de los compis de Labs (Rubén Martínez o @eldarsilver en Twitter) ha estado leyendo largo y tendido. La cantidad ingente de imágenes que requiere el resolver robustamente problemas del campo de la visión computacional hace que abordar modelos como el face recognition (reconocimiento facial) se convierta en poco más o menos que una odisea... Si es que no se dispone de una cantidad considerable de imágenes de cada sujeto en distintos entornos y en distintas circunstancias vitales.

Al final, nos encontramos con que abordar un problema de aprendizaje supervisado (aquel que consiste entrenar un modelo con ejemplos etiquetados del problema que queremos que resuelva) es muy difícil de conseguir mediante Deep Learning….Y si no es Deep Learning ¿qué hacemos? ¡buena pregunta! aunque compleja de responder...sería algo así como ¿cuál es el camino que lleva al futuro? ¿podrían ser las Spiking Neural Networks que desgranaremos en otro post?

En todo caso se acerca el final del 2018 y este es el balance que podemos extraer, estad con los ojos bien abiertos en el 2019 para no perderos por donde irán los tiros.

También hay cosas buenas: la máquina de estados finita

Igual que, con la transparencia que nos caracteriza, os transmitimos nuestras preocupaciones, no queremos despedirnos de vosotros este año sin compartir otro pequeño paso que no hubiera sido posible (de nuevo) sin los compañeros del Departamento de Robótica de la URJC: la implementación de una máquina de estados finita, simple pero funcional.

Por si alguien no ha tenido la oportunidad de disfrutar la asignatura de Teoría de Autómatas y Lenguajes Formales, básicamente el concepto alude a un modelo matemático que normalmente es representable mediante un grafo y que consta de un número finito de estados pudiendo estar en uno y solo uno en cada momento. Por supuesto, el paso de un estado a otro será posible como consecuencia de algún tipo de entrada externa que motive este cambio (o en lenguaje de Teoría de Autómatas: transición). De hecho una máquina de estados finita (o FSM: Finite State Machine) viene definida por su estado inicial, una lista de sus estados y las condiciones para que ocurra cada transición.

Si aun con todo, sigue sonando muy abstracto, pensad en las máquinas de vending, los ascensores o los candados con combinación...todos ellos son ejemplos cuya lógica interna responde a una FSM. Ahora bien, si queréis saber si hemos convertido a AIDA en una expendedora de gominolas y refrescos o si existe otro motivo mucho más interesante por el que queramos implantar en ella una máquina de estados…¡estad atentos a la siguiente entrada!. No os olvidéis de ser felices, ¡Feliz Navidad!

El proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

La digitalización de la empresa debe partir del área de recursos humanos, porque es una cuestión cultural, y como tal ha de tratarse.

El proceso de digitalización supone una evolución de los valores hacia la centralización en las personas. La tecnología es aquello que hace que hagan mejor su trabajo, tengan mejor experiencia de cliente o sean ciudadanos más integrados con el entramado empresarial que les rodea.

El lenguaje es parte fundamental:  ya que no todos entendemos lo mismo con las mismas palabras, debemos aunar los términos que hemos de utilizar para llamar a las mismas cosas.

Algunos ejemplos:

Recursos Humanos

La peor de las expresiones, es la forma más despersonalizada de llamar al activo las importante de las empresas, la gente. ¿Desde cuando un humano es un recurso, algo que no tiene que ver con su individualidad, con su autenticidad y le iguala al resto de “recursos”? ¿Desde cuando un humano es “reemplazable” como un “recurso”?

Empecemos a llamar a las personas y no a los recursos humanos

Director de Recursos humanos

Sintácticamente, sugiere que es el menos humano de los recursos, ¿no es mejor Director de Personas? He llegado a ver “chief happiness director”…  me reservo la opinión, pero desde un punto de vista lingüístico me encanta.

Orientación al cliente

Entiende las necesidades de los clientes y sabe interactuar para satisfacerlas.

El chiste es la palabra “entender” , supone una enorme flexibilidad, capacidad de análisis y capacidad de servicio. Se quedan fuera las "lo siento, señorita, pero solo tenemos este modelo y es imposible cambiarlo", "lo siento, señorita, pero aquí las cosas siempre se han hecho así", o "lo siento, señorita, pero salgo a las 5 y no estoy dentro de mi hora de trabajo".

Trabajo y liderazgo en red

Colabora, lidera y coopera en entornos digitales, integrando lo online y lo offline, la cultura millennial y la forma de hacer viejenial, lo de siempre con lo nuevo, de forma que todos estén incluidos, de forma que todos tengan algo que aportar, algo que aprender, algo que liderar

Comunicación digital

Se comunica y relaciona de forma efectiva con herramientas y en entornos digitales, adaptado a las nuevas formas de comunicar las viejas costumbres…. Pero también sin descuidar las antiguas formas, el offline.

Visión estratégica

Comprende el fenómeno digital y lo incorpora en la orientación estratégica de sus proyectos. De esta forma tenemos la capacidad de integrar estratégicamente lo que queremos hacer con la forma de hacerlo. Esto supone:

• Colaboración efectiva.- trabajo en red en entornos colaborativos
• Comprensión social y cultural
• Pensamiento crítico y evaluación
• Creatividad

Aprendizaje continuo

El que gestiona su aprendizaje, conoce y utiliza los recursos digitales, participando en comunidades de aprendizaje. Es decir, comparte, colabora, aprende, es abierto, es trasparente, acepta a los otros y sus críticas, aporta con su opinión, tiene la mente abierta a lo nuevo, no tiene miedos  y no considera que la información es propia.

En DHSEED somos conscientes de que orientar una compañía hacia la digitalización y el Big Data supone un proceso complejo de realizar. Por ello, acompañamos a la empresa en ese proceso, ya que ofrecemos consultoría orientada a la transformación digital; somos headhunters  especialistas en la evaluación, búsqueda y selección de perfiles de IT, Big Data y digital. Para más información pincha aquí.

La librería scikit-learn de Python sigue siendo una de las favoritas de los Kagglers (aunque Keras y Tensorflow ganan cada vez más adeptos). Igualmente, para todo el que desea iniciarse en Machine Learning utilizando Python como lenguaje de cabecera, la caja de herramientas que conforman numpy, pandas, matplotlib y scikit-learn se presenta como una manera razonablemente amigable de hacer los primeros pinitos.

Por ello, el hecho de que scikit-learn (biblioteca que encapsula distintas funciones de preprocesamiento de datos así como implementaciones de multitud de modelos orientados a resolver problemas tanto de aprendizaje supervisado como aprendizaje no supervisado) haya alcanzado la versión 0.20, es motivo de celebración. Qué mejor manera que celebrarlo con un pequeño post con algunas de las novedades que esta versión incorpora.

Empezando con la nueva versión de scikit-learn

Lo primero de todo es actualizar nuestra versión de scikit-learn para empezar a trastear con ella. Se recomienda utilizar algún entorno experimental (si tenéis instalado Anaconda podéis crearos uno con conda create y si no, pues con virtualenv  env). Aquí, por ejemplo, utilizamos Anaconda y lo que haremos será simplemente listar nuestros entornos y activar aquel en el cual queremos actualizar la versión de scikit-learn.

Una de las primeras novedades que nos llamó la atención es la que afecta a la imputación o procedimiento. Mediante esta, se rellenaban aquellos huecos en el conjunto de datos propiciados por los valores missing (nulos, NA, NaN…como se prefiera llamar). La herramienta que scikit-learn proporcionaba para solventar esta tarea era principalmente el Imputer, si bien es cierto que presentaba algunas carencias. Por ejemplo: solo podía reemplazar valores missing o enteros o no permitía imputar un valor constante. Ahora SimpleImputer pone remedio a ambas carencias. Veamos un ejemplo:

Dataframes y features categóricas

Se define un dataframe de pandas con columnas de distintos tipos, en la columna disponibilidad, el último de los valores es u. Consideremos u el valor que queremos reemplazar y constant la estrategia a utilizar. Al aplicar el SimpleImputer definido sobre nuestro dataframe, vemos como el valor u ha sido reemplazado por la constante definida mediante fill_value: d.

Existen casos como el de OrdinalEncoder, en el que nuevas funcionalidades han sido añadidas un componente ya existente. Recordemos que este componente transforma las features con valores categóricos, asignando a cada uno de sus posibles valores un número entre 0 y el número de categorías - 1.

Veamos un ejemplo centrado únicamente en dos features categóricas:

Se define de nuevo un dataframe con las dos features categóricas que va a gestionar el OrdinalEncoder. Luego, este se entrena con este dataframe aprendiendo los posibles valores que pueden tomar dichas features y transformándolos en números (del tipo indicado mediante el parámetro dtype) en el rango de 0 a número de categorías - 1. Al examinar las categorías que ha detectado el OrdinalEncoder, apreciamos que lo que ha hecho es ordenarlas alfabéticamente y asignar un número empezando por 0 a cada una de ellas para cada una de las dos features. Pero ¿qué ocurre si aplicamos el OrdinalEncoder entrenado a nuevos datos?

Usando el OrdinalEncoder para entrenar nuevos datos

Si fichamos un manager para nuestro equipo, OrdinalEncoder será incapaz de hacer la transformación del nuevo dataframe. La razón de esto es que ha recibido una categoría (manager) con la cual no ha sido entrenado… Aquí es cuando viene al rescate el parámetro categories. Repitamos el ejemplo:

La gran diferencia es que, al definir el OrdinalEncoder, hemos indicado, mediante el parámetro categories, todos los posibles valores de nuestras features categóricas. Si no especificamos ningún valor para dicho parámetro, su valor por defecto será auto. Esto básicamente indica que los posibles valores de las features categóricas se inferirán de los datos con los que se entrene. Nota: en la versión 0.20.0 el uso del parámetro categories con otro valor que no sea el por defecto, dará un error. En la versión 0.20.1 está subsanado.

Otras novedades de interés

ColumnTransformer

Finalmente, mencionaremos una de las novedades que más nos ha gustado. Scikit-Learn ya ofrecía una amplia cantidad de transformers que permiten llevar a cabo distintas operaciones sobre nuestros datos. El problema es que, en el mundo real, es sencillo encontrarse datos en los que las distintas features son de diversos tipos, esto implica que los requisitos de preprocesamiento no serán los mismos para todas ellas. Es necesario, por tanto, aplicar transformaciones de manera focalizada según el tipo de cada feature. ColumnTransformer (aun en versión experimental) nos permite seleccionar a qué columna o columnas les será aplicada cada transformación. Veamos un ejemplo:

Definimos primeramente un dataframe nuevo. A diferencia de los ejemplos anteriores, en los que cada transformer se aplicaba a todas las columnas de cada dataframe, en esta ocasión definimos un ColumnTransformer que nos permite montar un pipeline. En este, indicaremos las transformaciones que se desean aplicar y a qué columnas deseamos aplicarlas. El primer parámetro es una lista de tuplas en la que cada tupla indica:

• el nombre que nosotros le damos a la transformación (a nuestro gusto),
• la definición del transformer
• una lista con los índices de las columnas a las que afectará.

Una vez hayamos definido la lista de tuplas, especificaremos, mediante el parámetro remainder, lo que queremos que les pase a las columnas que no han sido afectadas por ninguna transformación: passthrough (si queremos que pasen al final del pipeline intactas), drop (si queremos que se eliminen del resultado).

Es interesante recalcar, aún más, que el funcionamiento del ColumnTransformer es como el de un pipeline. Por tanto podremos acceder a los “eslabones” de la estructura que hayamos especificado a través de las tuplas, mediante los nombres que hayamos utilizado para denominar cada una. Por ejemplo en el caso anterior:

Named_transformer_

La propiedad named_transformer_ devuelve un diccionario en el que cada clave corresponde con los nombres utilizados para definir los transformer (el primer elemento de cada tupla). Al acceder al diccionario utilizando uno de estos nombres estaremos accediendo a su vez a cada uno de los transformer definidos.

Incluso es posible construir un ColumnTransformer sin necesidad de especificar un nombre para cada transformación. Por ejemplo:

Esta vez, no hemos especificado nombre alguno para los transformadores definidos, scikit-learn los ha nombrado por nosotros y podremos acceder a ellos a través de los nombres generados.

 

Esperemos que algunas de estas novedades introducidas en scikit-learn, os resulten tan interesantes como a nosotros; seguro que en un futuro cercano os facilitarán el trabajo. De todos modos, id con cuidado ya que algunas partes todavía son experimentales.

---

Alejandro Arranz, Data Engineer en datahack

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Artículos anteriores estuvieron dedicados a la lista de producto (Product Backlog). En esta ocasión quiero comentar sobre el seguimiento dentro del Sprint, algo que también forma parte de la guía de Scrum.

SEGUIMIENTO DEL SPRINT

Lo primero que hay que considerar es que las técnicas ágiles están pensadas para simplificar las tareas de gestión. Es así puesto que algunas recaen sobre el equipo de desarrollo, y siempre se prefiere que estén desarrollando antes que reportando el estado del proyecto. Todavía más crítico, el foco del seguimiento se centra en entender lo que queda para conseguir el objetivo del sprint, y en su caso modificar las estimaciones.

Sin embargo, no se pretende analizar cuánto tiempo se ha invertido en lo ya desarrollado, un hecho bastante desconcertante para quienes estén acostumbrados a las metodologías predictivas. Esto es porque Scrum no se pensó especialmente para ahorrar costes de fabricación ni tiempos de desarrollo (al menos no medidos de la forma tradicional), sino para entregar productos más adecuados a las necesidades cambiantes del negocio. Es decir, no debemos asociar ágil con veloz ni con barato, sino con productos de mejor calidad, tanto objetiva como subjetiva, y con mayor capacidad de incorporar cambios sobre la marcha. Por eso tampoco tiene mucho sentido realizar una contabilidad de horas por técnico y tarea, ya que esto inhibe la introducción de cambios, así como el trabajo en equipo.

ESTIMACIONES DE TIEMPO Y ESFUERZO DEL SPRINT

Enlazando con lo expuesto en el artículo de planificación de sprints que publiqué anteriormente, en proyectos de Big Data, Analytics & Bussiness intelligence es el equipo de desarrollo quien estima lo que es capaz de terminar en un sprint dado, y esto lo hace mediante algún sistema de puntuación para cada ítem que acaba dentro del sprint backlog. Es común acabar convirtiendo la puntuación en horas, pero con el riesgo de caer en la contabilidad clásica de costes.

La utilidad no es tanto la conversión en horas, sino entender que un ítem valorado como 10 puntos requiere el doble de esfuerzo (tiempo supuesta una dedicación del 100%) que uno valorado en 5 puntos. Y también podemos conocer el histórico de puntos entregados en cada sprint, a medida que van sucediendo sus ciclos, para establecer una velocidad media. Esto permite ir afinando más el compromiso de entrega que alcanza el equipo de desarrollo durante la planificación del sprint, y también hacerse una idea de lo que supone el product backlog restante en cuanto a tiempo, entendiendo que es algo que irá evolucionando.

GRÁFICO DE BURN DOWN

Hay varias técnicas para visualizar en medio de un sprint cómo nos encontramos respecto a la planificación. Sin duda, el artefacto más conocido es el gráfico de burn down. Aquí tenemos un ejemplo de gráfico sencillo:

En el eje horizontal aparecen los días hábiles del sprint en un proyecto de Big Data, en este caso 20, y la línea verde representa la previsión de avance diaria. En el eje vertical en este caso figura el esfuerzo restante en días (agregado para todo el equipo), aunque mi recomendación es representar mejor la valoración en puntos. Al inicio del sprint conocemos la estimación total de los puntos a terminar, e idealmente al final del sprint se habrán entregado todos ellos, por lo que la línea verde es una recta que acaba en cero para el eje vertical.

Mientras, la línea roja representa el avance real, e insisto una vez más, no como tiempo real dedicado sino como valoración de puntos de las tareas terminadas conforme al “definition of done”. La línea roja por encima de la azul nos advierte de un retraso respecto a la planificación. Por ello, es el propio equipo técnico quien debe decidir si es posible acelerar el ritmo de desarrollo, o bien considerar reducir el alcance del sprint en el supuesto de que ello no amenace el objetivo del mismo.

GRÁFICO DE BURN UP

Aunque el gráfico de burn down resulta útil, puede inducir a error de interpretación cuando se realizan cambios de alcance durante el sprint, y ya sabemos que hay que contar con ellos si el objetivo lo requiere. Por eso me parece necesario usar también el gráfico de burn up. En la siguiente imagen se aprecia la diferencia:

Pensemos en un proyecto de Big Data donde a mitad del sprint se ve necesario introducir una nueva tarea no planificada al inicio, o bien se trata de una tarea cuya estimación se ha tenido que aumentar al ir conociendo más detalles funcionales. En el burn down podríamos volver a dibujar la recta planificada, que resultará más inclinada si es que mantenemos las escalas originales. Pero el gráfico no nos dice en qué momento se ha producido este cambio.

Viendo ahora el gráfico de burn up, la línea de trabajo planificado total pasa a ser una recta horizontal al inicio del sprint. Si hay cambios de valoración se van a poder visualizar como saltos en dicha línea. La otra línea ya no es el trabajo pendiente, sino el completado hasta el momento, y se espera que al final del sprint alcance la línea del trabajo planificado total. Si no se alcanza, al menos se puede tener una idea de hasta qué punto ha sido el cambio el que ha provocado esta situación.

CONCLUSIÓN

La lección práctica es que parte del aprendizaje de Scrum consiste en saber cómo cambia la planificación durante el propio sprint (saltos en la línea horizontal), y planificar los siguientes sprints con suficiente holgura como para absorber este tipo de cambios inevitables. Pero, cuidado, no se trata de abrir la puerta a cualquier cambio dentro del sprint, estos cambios tienen que estar justificados siempre conforme al objetivo, en caso contrario el equipo de desarrollo se va a ir desentendiendo del mismo.

Si habéis seguido todos los artículos anteriores, y queréis profundizar un poco más allá de la guía de Scrum, os sugiero este otro documento más detallado.

---

José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data Analytics de datahack.

Datahack también se centra ahora en Python. La entidad sigue avanzando en su afán de traer formación de Big Data y Analytics de calidad. Y en este tercer evento, tras hablar de Machine Learning y Blockchain en las otras ediciones, ahora le tocaba al Análisis de Datos usando una de las herramientas más empleadas por los profesionales, el lenguaje de programación Python.

La mejor formación en Big Data y asequible para todos.

Esta charla cerraba el círculo con la primera de Machine Learning, pues como se nos recalcaba, no es posible dar ese paso sin haber realizado antes un exhaustivo Análisis de los Datos. Se dividió en dos partes, una primera más teórica sobre los pasos para ese análisis y los fundamentos de Python como herramienta para realizarlo. Y una segunda en la que se hizo un ejercicio sobre unos datos reales para reforzar lo explicado antes, y ver el potencial de este lenguaje.

Proceso de Ciencia de Datos

Tras el índice, fue lo primero que se presentó. El marco completo del proceso que lleva a cabo un científico de datos, desde el origen de éstos hasta la solución final que se le dé al problema que se quiere resolver, pasando por las etapas de Extracción, Procesado, Limpieza, EDA (Análisis Exploratorio de datos o como se conoce en inglés: Exploratory Data Analysis), Machine Learning e Implantación.

Se recalcó con insistencia en que lo que hay que tener presente en todo momento, y por su puesto bien definido, es el problema que se quiere resolver. Esta concreción del problema nos ayudará a enfocar cada una de las etapas del proceso, especialmente en la etapa del EDA.

Y respecto al EDA, en la presentación se nos recordaba que el término fue acuñado por el conocido estadístico John Tukey en 1977, y lo definía como “una actitud, un estado de flexibilidad, una voluntad de buscar aquellas cosas que creemos que no están allí, también aquellas que creemos que sí están”.

Después de explicar los pasos habituales que se hacen en este EDA, que es la base del Análisis de los Datos, y recordándonos también que el EDA es algo que se hace en paralelo con las otras etapas de procesado de la información, se pasó a hablar de la herramienta Python.

Python, herramienta extendida para el Análisis de Datos

Asentada la base del Análisis de los Datos, ahora tocaba ver cómo se hacía. Y en esta ocasión se aborda usando el lenguaje de programación Python, lenguaje interpretado creado en 1989 por Guido Van Rossum. Está claro, ¿no? Desde siempre se está haciendo un guiño al grupo británico de humor “Monty Python” a la hora de elegir el nombre.

Lo primero que se habló es el porqué de su popularidad, destacándose que tenía una comunidad que lo soportaba muy grande, que está esponsorizado por Google y Facebook entre otros. Y, además, que tenía Big Data, 140000 librerías y que además era eficiente, fiable y abierto. ¡ Qué más se puede pedir !

Las librerías imprescindibles de Python

Y sin más, se pasó a describir las librerías más importantes para el análisis de datos: numpy, pandas, matplotlib y seaborn.

Numpy es la base, la librería para los cálculos rápidos, usando la vectorización, o lo que es lo mismo, operaciones entre vectores evitando usar bucles “for”. Y ahí se aprovechó para recordarnos el evitar usar bucles “for” cuando se manejan grandes volúmenes de datos.

El hecho de que la librería numpy esté pensada para manejar grandes volúmenes de datos, esté realizada en C, y tenga un esquema optimizado de memoria, independiente del resto de objetos de Python, es la que la hacen tan importante.

Para facilitar el uso de todas las funciones de esta librería, se explicó que es recomendable tener una “chuleta” a mano siempre.

A continuación, se pasó a hablar de la librería más importante del proceso de Ciencia de Datos, pandas, que usando como base la anterior librería con potencial de cálculos muy rápidos, une la posibilidad de manipular datos estructurados (Dataframes y Series) con funciones muy parecidas a las que se usan en las bases de datos (SQL).

Por supuesto, pandas también tiene “chuleta”, no podía ser menos.

La visualización

Pero parece que no es suficiente con estas dos librerías, y se nos insistía bastante, la visualización es muy importante en el proceso que se explicaba al principio de la presentación. En ese descubrimiento de lo que no creemos que está en los datos, como decía Tukey, aflora cuando hacemos una buena visualización. Y para ello se nos recomendaban dos librerías, matplotlib y seaborn.

Matplotlib es la librería por excelencia de visualización de gráficas en 2D, con la que se puede visualizar prácticamente todo lo que se nos ocurra. Para ayudarnos a elegir cómo visualizar, una recomendación era que se acudiera a la galería de ejemplos que contiene tantos, que seguro nos encauza para crear nuestra gráfica. Siempre contaremos con la “chuleta”.

Y para terminar con la visualización, se habló de la segunda librería, seaborn. Permite hacer gráficos más estadísticos y con un lenguaje de alto nivel. Esta librería, que usa de base la anterior, trata de sacar a la luz las relaciones entre variables, y para que no se nos olvide ninguna función, tendremos a mano la “chuleta” también.

Finalmente, antes de ver un ejemplo práctico, se nos recordaba cuáles eran las plataformas más empleadas para usar Python: Anaconda como “distribución del software”, Spyder como entorno de desarrollo, Jupyter como aplicación web para poder compartir código y contar historias sobre los datos, sin olvidar un buen editor Notepad++

Ejemplo de Análisis de Datos: estudio de mercado de torres eléctricas a partir de datos de aduanas

La segunda parte de la conferencia se basaba en la ejecución de código en Python usando un notebook de Jupyter, para repasar todo lo comentado hasta ahora, ya con datos reales.

Aunque el ejemplo se hacía sobre unos datos que no se pueden llamar calificar como Big Data, sólo contaban con algo más de 1500 observaciones y unas 100 características, lo que se vio es aplicable a un dataset de dimensiones miles de veces mayor, los conceptos son los mismos.

Y en referencia al Big Data, en la presentación se nos daba una definición curiosa del término: “Big Data es lo que no cabe en una Excel”. Curiosa definición, pero lo cierto es que muchos empezaron a usar Python como herramienta de análisis de datos, en el momento que Excel dejó de dar solución por el volumen de los datos.

Ejecutando código en Python

Sin más se entró a ir ejecutando el código, siguiendo los pasos del Proceso de Ciencia de Datos, empezando por la extracción de los datos, que en este caso fue una carga de un archivo en formato csv. Siguieron etapas de procesado (rellenado de missing, extracción de características con expresiones regulares, conversión de tipos de variables) y de limpieza.

Además de los datos de aduanas, se incorporaron datos para hacer un análisis más amplio, como los precios históricos de las materias primas principales, el acero y el zinc.

Vimos una librería muy interesante que realizar rápido y de forma detallada un EDA a partir de un dataframe de pandas, y lleva por nombre pandas-profiling.

Finalmente, como no podía ser menos, se realizaron varias visualizaciones, para tratar de entender el mercado de torres eléctricas en el país, viendo cómo han ido evolucionando las operaciones a lo largo de los años, quiénes han exportado, qué volúmenes y a qué precio. Ahí vimos el potencial de visualización tanto de matplotlib y seaborn.

Conclusión

Pasada la hora y cuarto de la presentación, hemos visto condensada esta actividad del Análisis de Datos, importante paso previo al uso de herramientas más avanzadas en Ciencia de Datos como el Machine Learning. Y vimos también su potencial, en el sencillo ejemplo a partir de datos de aduanas y precios históricos de materia prima.

Durante la ronda de preguntas, el numeroso público mostró mucho interés en el asunto, sacando a relucir temas como la arquitectura necesaria para hacer esto a gran escala y velocidad, o el uso de las GPU para la analítica, interés en las empresas por personas con perfiles que sean capaces de hacer estos análisis de datos, y otras preguntas interesantes.

Como en otras ocasiones, un asistente habitual a este ciclo de conferencias sobre Big Data, hizo su magnífica crónica del evento.

En breve estará disponible el vídeo de la presentación, de momento podemos descargarnos en github la presentación, el notebook de Jupyter, los datos para ejecutarlo y las chuletas (“cheat sheets”) de las librerías.

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master Experto en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Hablamos de Recursos Humanos, de cuidado al empleado que trabaja en equipo y, en definitiva, de eficiencia en el empleo y gestión de grupos. Mas allá de la veracidad de los hechos de la película, y de lo enorme y grandioso de la música de un grupo que hizo historia desde muy pronto, en Bohemian Rapsody, en la historia y filosofía de Queen, podemos descubrir grandes lecciones para aplicar sobre la gestión de equipos.

1.- Perseguir el mismo objetivo

Aunar fuerzas, identificarse con el objetivo, hacer que todos los esfuerzos se centren en perseguir la misma meta, es la clave de la sinergia, del trabajo común, de poder tocar el éxito que uno a uno no hubieran podido alcanzar. A pesar del gran protagonismo de Freddie Mercury, en Queen, todos los miembros de la banda eran grandes músicos, todos eran compositores, todos aportaron algo brillante en todas las canciones. Perseguir la gloria común y compartida fue lo que los llevó a lo mas alto. Cuando abandonaron el objetivo común, el éxito de cada uno de los miembros por separado fue incomparable al de todos ellos juntos.

Buddy you're a boy make a big noise
Playin' in the street gonna be a big man some day
You got mud on yo' face. You big disgrace
Kickin' your can all over the place
Singin'
We will, we will rock you

---

2.- Tenacidad a pesar de la ignorancia del otro

Hacer de tu objetivo algo que suponga el perder el miedo a lo desconocido, poder defender lo innovador, a pesar de los “que llevan toda la vida haciendo lo mismo”, a pesar de los “esto siempre se ha hecho así”. Tener la personalidad y el coraje de decir que no a los que no estén alineados con el objetivo, a los que no entienden, a los que se miden por patrones antiguos, a los que tienen miedo. Todo ello basado en una gran transparencia y comunicación entre los miembros, lo que hace que todos puedan ser portavoces sin importar

One dream, one soul,
One prize, one goal.
One golden glance of what should be.
It's a kindofmagic.

---

3.- Abandonar la zona de confort (frase ya demasiado utilizada) para crecer hasta lo más alto

Freddie Mercury, desafiando todo estereotipo, y complementado con el resto de Queen, desata un universo innovador, arriesgado, transgresor y revolucionario. La frase del cartel de la película original es “fearless lives forever”.

Oh you gonna take me home tonight
Oh down beside that red fire light
Oh you gonna let it all hang out
Fat-bottomed girls you make the rocking world go round

---

4.- Flexibilidad

En el cantar, en el escribir, en el desafinar, en la forma de hacer música, en el cómo, en el cuándo y en el porqué , con gran respeto por el trabajo de los otros, por sus personas, por sus familias, por sus aspectos….

I see a little silhouetto of a man,
Scaramouche, Scaramouche, willyou do the Fandango?
Thunderbolt and lightning,
Very, very frightening me.
(Galileo) Galileo

---

5.- Perderse (o fallar) no es definitivo

Cuando la búsqueda de la gloria personal se impone, se acaba la magia, se acaba la comunicación, la confianza y el compañerismo. Ahí se pasa a otro estado en el que es muy fácil perderse, y ya no tienen sentido el equipo, los objetivos o el trabajo común. En este caso, la separación y el tocar fondo abren al diálogo, a poder pedir perdón y a la reconciliación, dando paso de nuevo a la magia

I've paid my dues. Time after time.
I've done my sentence
But committed no crime.

And bad mistakes‒I've made a few.
I've had my share of sand kicked in my face,
But I've come through.

We are the champions, my friends

---

6.- La mayor gloria conlleva el abandono del yo

Tras la reconciliación y sin disfraces, sin maquillaje, sin parafernalia, solo cuatro músicos tocando en camiseta y disfrutando de estar juntos, llega la mayor gloria, las voces que callan, aquello que aún recordamos

I have spent all my years in believing you
But I just can't get no relief, Lord!
Somebody, somebody
Can anybody find me somebody to love?

---

Paloma Romero

En DHSEED somos conscientes de que orientar una compañía hacia la digitalización y el Big Data supone un proceso complejo de realizar. Por ello, acompañamos a la empresa en ese proceso, ya que ofrecemos consultoría orientada a la transformación digital; somos headhunters  especialistas en la evaluación, búsqueda y selección de perfiles de IT, Big Data y digital. Para más información pincha aquí.

Tras haber ido comentando sobre los roles y las reuniones de Scrum, como se puede ver en el artículo anterior, continúo con las definiciones y artefactos que se usan a lo largo de todo el ciclo de Scrum. En concreto, hoy trataré el Product Backlog. Recuerdo que una lectura fundamental para el que se quiera iniciar en este marco de gestión es la guía de Scrum, que he tomado como base para estructurar la presente serie de artículos.

La lista de producto (product Backlog) en Scrum

Viene a representar la hoja de ruta del producto, siendo el Product Owner el principal responsable de la misma. En concreto es fundamental que esté convenientemente priorizada según el valor aportado al negocio (posiblemente ponderado conforme a criterios de coste o esfuerzo), ya que en cada sprint se eligen preferentemente los elementos de mayor prioridad para poner el foco en su construcción.

La lista de producto está en continua evolución, hasta que el producto deje de tener sentido de negocio. Así, la visión tradicional de un proyecto cuyas condiciones de finalización son bien conocidas desde el inicio se transforma en una especie de proyecto continuo donde en cada sprint se va decidiendo lo que hacer en el futuro.

Aspectos críticos de la lista de producto

Las métricas

Ya podemos imaginar que las métricas típicas para medir el éxito del proyecto (desviaciones entre lo previsto y lo real a lo largo del proyecto completo), no tienen demasiado sentido en un marco tan cambiante y de un futuro muy difuso a largo plazo. Tampoco es sencillo acordar contratos a precio cerrado y fecha de entrega pactada, ya que necesariamente el proveedor tiene que limitar el número de cambios en ese marco. Esto no quiere decir que renunciemos a ciertas medidas, como la de la velocidad del sprint, y sobre todo a la del valor de lo entregado y la consecución del objetivo del sprint, pero el éxito de scrum requiere una gestión muy ligera.

Hay que tener muy claro que Scrum no está especialmente pensado para el ahorro de costes de producción, sino para que los costes (asumidos a lo largo del ciclo de vida del producto) sean convenientemente invertidos en desarrollar un producto valioso. Tampoco es buena idea mantener un sistema de control de tiempos de técnicos y tareas individuales, aunque solo sea porque amenaza el trabajo en equipo  con una serie de objetivos comunes.

Lista única

Otro aspecto crítico es que la lista debe ser única para un producto dado, incluso si participa más de un equipo de scrum. De esta manera resulta ser una verdadera hoja de ruta, en vez de un conjunto de peticiones de usuarios que realizan cada uno de forma independiente. Así el rol del product owner es también el de coordinador de usuarios y otros interesados, elaborando una lista representativa, coherente y priorizada, de las características que debe tener el producto.

Desglose

Lo habitual es que los elementos más prioritarios aparezcan más desglosados, y por ello con estimaciones (esfuerzo, riesgos, complejidad) más fiables realizadas por el equipo de desarrollo. Recuerdo que esto se va haciendo en las reuniones de refinamiento de la lista de producto, y también en las de la planificación del inicio del sprint, aunque realmente se puede hacer en cualquier momento en que sea necesario.

El desglose tiene que llegar al menos hasta el nivel en el que los elementos pueden implementarse (terminarse) en un único sprint, de otra manera nunca podrían ser elegidos. Se deduce que es mala práctica conformarse con elementos menos desglosados cuando hay que abordar la reunión de planificación del sprint. También al flexibilizar scrum para trabajar con elementos donde se sabe que no se van a poder completar en un único sprint, algo que precisamente menciono por lo común que resulta.

Aplicación en proyectos de Big Data & Analytics

Como lecciones prácticas, quiero aclarar que la lista de producto no es solo una lista de funcionalidades para negocio, aunque sí que la mayor parte del esfuerzo debería recaer sobre las mismas. Pero también tienen cabida tareas técnicas como la reestructuración del código, la formación de equipo, la investigación de nuevas técnicas, la mejora del tiempo de respuesta, etc. Teniendo potestad el equipo técnico para incluir elementos de este tipo dentro de la lista.

Esto es especialmente relevante en el contexto de los proyectos de analítica, Big Data y BI. Debemos contar con los consabidos problemas de calidad de datos. Estos exigen tareas específicas para tratarlos, sin que a veces se pueda poner algo concreto a disposición de los usuarios en un entorno de producción. En cambio, sí que podemos pensar en prototipos, ciertas entidades mejor definidas, etc., donde los usuarios tienen una responsabilidad continua respecto a la validación y las pruebas.

También necesitamos reservar tiempo para la investigación de nuevas tecnologías, porque quizás tengamos que probar varias de ellas, realizar diferentes modelos estadísticos antes de dar con uno suficientemente bueno, etc.

Conclusión

En resumen, no siempre se puede entregar una novedad significativa del producto en cada sprint en términos estrictamente funcionales, y por ello hay que saber buscar un equilibrio entre las entregas frecuentes y los aspectos que tienen más que ver con la calidad técnica.

A veces se considera un sprint especial cada cierto tiempo para abordar tareas que no están estrictamente asociadas a la funcionalidad, incluyendo el sprint 0 del que ya comenté en otro artículo. Pero no conviene tomar decisiones de gestión simplemente para reportar un mejor dato de velocidad. El rey es el producto, y esto incluye necesariamente tareas orientadas a asegurar la calidad del mismo, que podemos considerar prácticamente continuas, aunque puedan parecer un hándicap para la velocidad.

Me viene a la mente el interesante concepto de “deuda técnica”. Sin ser muy riguroso en la definición, diré que entregar software fabricado de manera muy rápida pero sin preocuparse de su calidad, es como haber recibido un préstamo, que nos ha permitido cumplir con un compromiso. Pero luego toca devolver los intereses, pensemos en posibles incidencias que hay que reparar de manera urgente, mantenimientos más costosos, etc. Y si los intereses empiezan a ser inabordables, tendremos que devolver todo el capital, o bien rehacer el código desde cero.

---

José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de datahack.

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

La semana pasada, en la primera parte de este artículo, hicimos una primera aproximación al desarrollo y despliegue de chatbots, en un entorno productivo. En esta segunda parte seguiremos con ello, profundizando en aspectos más avanzados.

Construyendo modelos de Inteligencia Artificial propios

Como se ha visto, desde la puesta en marcha de los primeros chatbots, se irían recogiendo datos de las interacciones chatbot-usuario. Así, se irá creando un repositorio de datos de interacción, con diferentes niveles de estructuración.

El tratamiento y análisis de estos datos servirá para la construcción modelos de Inteligencia Artificial propios. Estos serán la base para la creación de Chatbots Neuronales; más adaptados al área de negocio de la empresa y más eficientes a la hora de resolver incidencias.

Puesta en producción de los Chatbots Neuronales

Tras la construcción y prueba de los Chatbots Neuronales, se incorporarían al ciclo de producción del Contact Center (siguiendo con el ejemplo anterior). Sustituyendo a los Chatbots Lógicos, y solventando un mayor tipo y número de incidencias, con lo que:

• Se descarga más a los operadores humanos, que pueden centrarse en casos más concretos y aumentar su grado de especialización.
• Mejoraría la calidad del servicio prestado.
• Se crearían nuevos tipos de interacción chatbot-usuario

Los nuevos tipos de interacción, aumentaría la cantidad y tipología de datos existentes en el repositorio de datos de interacción. Estos nuevos datos, juntos con los ya existentes, se usarían para construir Chatbots Generativos. Un tipo de chatbot capaz de aprender con cada una de las interacciones que va teniendo, ya sea un humano u otra máquina. Así, podrían asumir tareas más especializadas y tener cierta capacidad de improvisación, ante situaciones que no están contempladas en su base de conocimiento.

Su construcción se haría de forma similar a como se hizo con los Chatbots Neuronales; se harían prospecciones periódicas sobre el repositorio de datos y, cuando se viera que hay suficientes datos, se iniciaría la construcción de los mismos.

Implementando los Chatbots Generativos

A diferencia de como se hizo con los Chatbots Neuronales, la puesta en producción de los Chatbots Generativos no implicaría la sustitución de los Chatbots Neuronales. Su despliegue se haría de forma que hicieran de intermediarios entre los operadores humanos y los Chatbots Neuronales.

Se haría así, porque sus puesta en producción y mantenimiento es más costosa, y porque  su alto grado de especialización y capacidad de improvisación, los hacen ideales para esta función de intermediación.

Hasta aquí nuestra propuesta de como hacer un despliegue de chatbots en un entorno productivo. Como ya os comentamos, la hemos elaborado en base a la experiencia que hemos adquirido en los dos últimos años. Esperamos que os resulte interesante y os sirva para todos aquellos que estéis en ello o pensando en iniciaros en este mundo tan innovador y lleno de posibilidades.

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

https://datahack.es/blog/big-data/desarrollo-chatbots/En artículos anteriores hemos hablado de qué son y como nos entienden los chatbots, que plataformas pueden usarse para construirlos y cuáles de estas son las más interesantes para hacer un desarrollo avanzado de los mismos. Hecho que nos permite avanzar y adentrarnos un poco más en este mundo donde se mezcla la inteligencia artificial (IA) y la integración de sistemas.

En las siguientes líneas os haremos una propuesta, basada en la experiencia que hemos adquirido en los dos últimos años, de como realizar el desarrollo y despliegue de los chatbots en un proyecto de cierta envergadura, de forma gradual, sostenible y en mejora continua.

Mejor empezar con los Chatbots basados en reglas

Lo más óptimo es empezar con el desarrollo e implantación de chatbots de primera generación o Chatbots Lógicos. Estos funcionan con un sistema de diálogos (basado en reglas) y con una inteligencia fundamentada en la lógica, implementada en su código de programación.

Son fáciles de desarrollar, funcionales y capaces de dar servicios a través de varios canales de comunicación, lo que le hace ideales para las fases iniciales de un proyecto, en las que todavía no hay datos del comportamiento de los usuarios.

Con ellos se hará una primera aproximación a la automatización de tareas y se podrán ir recopilando datos, resultantes de la interacción estos con los usuarios, que sirvan para el desarrollo de chatbots más avanzados.

Poniendo como ejemplo un Contact Center de una empresa de comercio electrónico (Figura 1), los chatbots estarían situados en el nivel 1 del mismo, atendiendo a los usuarios por varios canales e interactuando con los sistemas internos de la empresa. También serían capaces de escalar incidencias que no puedan resolver a un nivel 2, donde serían tratadas por operadores humanos.

Los datos de las interacciones chatbot-usuario, se guardarán en un repositorio de datos, por ejemplo, un data lake.

Incorporando Servicios Cognitivos de terceros

Una vez implantados, y comprobada la eficiencia de los Chatbots Lógicos, se podría dotar a los mismos de nuevas funcionalidades (Procesado de Lenguaje Natural, Reconocimiento de Voz, Detección de Imágenes), haciendo uso de servicios cognitivos de propósito general, que son proveídos por empresas como: Google, Microsoft IBM, Amazon u Otros.

Con esto se buscaría un doble objetivo: mejorar la experiencia usuario y aumentar el número y tipo de interacciones chatbot-usuario, de modo que se vayan almacenando una mayor cantidad y tipo de datos, para su posterior análisis.

Y hasta aquí, la entrega de esta semana. La que viene seguiremos hablando de como seguir haciendo el despliegue de chatbots avanzados, haciendo uso de los datos recopilados y creando algoritmos de Inteligencia Artificial.

Espero que esta lectura os haya sido interesante,

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento