Resolviendo Dilemas en un Pipeline de Data Science

Al iniciar un proyecto de Data Science se tienen que tomar diversas decisiones para que cada etapa del flujo de trabajo o pipeline cumpla con las metas especificadas. El pipeline que definamos depende de factores tales como la experiencia que se tiene con las plataformas, herramientas, lenguajes o algoritmos específicos así como de la investigación previa y referencias externas. Lo ideal es lograr un equilibrio entre la rapidez que nos brinda el uso de los elementos conocidos y la incorporación de herramientas y conocimiento nuevo que permita lograr resultados de forma más rápida y eficiente. En este artículo abordaremos algunos dilemas a los que generalmente nos enfrentamos en la definición de un pipeline y en nuestra experiencia, qué aspectos debemos considerar para tomar la mejor decisión.

Aunque las etapas de un pipeline están muy definidas, todas están ligadas a un objetivo. Y es precisamente la ausencia de un objetivo claro una de las principales causas de los problemas. Para definir ese objetivo debemos cuestionarnos aspectos como: ¿cuál es el resultado tangible esperado del proyecto?, ¿cuáles son los beneficios que generaría el proyecto en caso de ser exitoso?, ¿a quién van dirigidos los resultados? La claridad con la que podamos responder a estas preguntas es fundamental para reducir los contratiempos que invariablemente surgirán.

A lo largo del proyecto nos encontraremos con diversas disyuntivas que nos obligarán a tomar decisiones. Es conveniente reflexionar antes de tomar una decisión impulsiva que haga que ese proyecto fascinante, divertido y retador se transforme en nuestra peor némesis. A continuación se describen algunos dilemas comunes a los que nos hemos enfrentado y que se asocian a las diversas etapas de un pipeline.

Adquisición

Cuando inicia un proyecto, uno de los primeros puntos a tratar es, ¿qué información necesitamos para lograr los mejores resultados? En las reuniones iniciales generalmente se hacen acuerdos sobre la información a utilizar y sus respectivas fuentes. Sin embargo, a medida que transcurren los días no es raro que se presenten las siguientes situaciones:

• Nos damos cuenta de que no tenemos toda la información que se definió en un principio.

• Necesitamos información adicional.

• No tenemos acceso a todas las fuentes.

Es recomendable resolver estas cuestiones lo antes posible. Aunque sabemos que nos encontramos en un proceso iterativo en el cual es posible que hagamos pruebas con datos diferentes a los originales, es mejor tener un conjunto de datos base.

Una situación común es que cuando el proyecto ya se encuentra avanzado se descubren nuevos datos que podrían ser útiles al modelo. Incorporar nuevos datos podría mejorar el resultado pero retrasaría el tiempo de entrega, ¿qué hacer? Esta es una decisión de gestión de proyecto más que nada y podrá variar dependiendo del contexto particular. Sin embargo, nuestra recomendación es guiarse por los lineamientos del desarrollo iterativo, terminando la iteración actual con los datos que se tenían contemplados al inicio de dicha iteración, y evaluar si tiene sentido incorporar los nuevos datos en iteraciones posteriores. Siempre debemos tener en cuenta que al final del proyecto es preferible tener un modelo útil aunque lleve más tiempo, que terminar a tiempo con un modelo inútil.

No tengamos falsas expectativas, el caso ideal en el cual tenemos desde el inicio todos los datos perfectos y completos es solamente una ilusión.

Exploración y entendimiento

Cuando existen tiempos reducidos podemos tener la tentación de omitir pasos, especialmente en la fase de exploración. A fin de cuentas, confiamos en las fuentes, ¿qué podría pasar? Aun cuando tengamos datos muy limpios, es necesario asegurarse de que no contienen información que nos pueda llevar a resultados erróneos. Por ejemplo, podemos encontrar rangos de edades irreales y ciudades que no existen, entre otros posibles hallazgos que si no los notamos a tiempo nos harán padecer en fases posteriores. Llevar a cabo la exploración no debe ser un dilema, debe ser un paso riguroso antes de seguir con el proyecto.

Pero explorar los datos no lo es todo. Debemos estar seguros de que entendemos cada variable o atributo. Si contamos con un diccionario de datos la labor se facilita pero si no contamos con él, vale la pena no suponer nada e investigar con el administrador de base de datos de su preferencia sobre el significado de los datos. No hacerlo puede tener un costo elevado.

Pre-proceso, transformación, manipulación

Esta fase requiere que tomemos decisiones con respecto a las transformaciones que nos convienen para obtener los mejores resultados. Es necesario conocer bien los datos: ¿de qué tipo son?, ¿qué efecto tienen estos tipos en las transformaciones? Existen detalles sutiles que no deben dejarse para después. No es lo mismo una variable tipo fecha que una variable numérica; no es lo mismo una variable tipo factor que una tipo texto. Aunque visualmente se vean iguales, si no damos a las variables el formato adecuado podemos consumir tiempo valioso.

En cuanto a los valores atípicos (outliers), también nos enfrentamos a dilemas: ¿los quitamos?, ¿los dejamos?, ¿cuáles son las consecuencias de estas decisiones? Como consideraciones generales podemos decir que si los valores atípicos tienen significado, no se deben eliminar. Si por el contrario, valores atípicos distorsionan la realidad entonces deben eliminarse. Imaginemos que estamos obteniendo perfiles de usuario para ciertos productos. Si introducimos edades negativas o mayores de 200 años los modelos resultantes mostrarán patrones de usuarios inexistentes. Por supuesto, hay diversas situaciones y tratamientos que pueden darse a valores atípicos. El punto clave es que no debe restarse importancia a las decisiones sobre estos valores.

Análisis y modelado

Ya que nuestros datos están preparados y listos, la pregunta es ¿qué tipo de análisis necesito? Esto depende fundamentalmente del objetivo del análisis. Existen infinidad de técnicas y algoritmos que pueden ser útiles ya sea como base o bien podemos diseñar un nuevo algoritmo ad-hoc a nuestro problema. En cualquier caso, la decisión de la técnica o algoritmo a aplicar tiene su origen en el objetivo. Y si no tenemos claro el objetivo es muy difícil esperar tener buenos resultados.

Un problema frecuente es que podemos caer en la tentación de querer aplicar algoritmos o técnicas emergentes y creer que si no lo hacemos no somos competitivos. Por ejemplo, ¿de verdad Deep Learning es la solución a nuestro problema? Tenemos que encontrar argumentos sólidos para tomar decisiones de este tipo. Una estrategia útil es empezar por la solución más simple e ir incrementando el nivel de sofisticación de la solución en la medida que lo requiera el proyecto, no en la medida de nuestro ego.

Comunicación y operación

Y llegamos a la fase en la que ya tenemos resultados buenos. ¡Si, lo logramos! Después de varias iteraciones en las fases anteriores hemos llegado a la parte de presentar los resultados. La interrogante es: ¿cómo presentarlos?, la respuesta depende de diversos factores: ¿el resultado es un reporte?, ¿es un producto?, ¿es un servicio?, ¿es un dashboard?, ¿es un resultado final o una iteración?, ¿para quién son?

Aunque estemos muy felices con nuestros resultados, una presentación inadecuada puede ser desastrosa si no mostramos los aspectos de interés para cada público. Es conveniente elaborar dos presentaciones base:

• Presentación técnica: debe incluir detalles de análisis e implementación para que sea reproducible. Debe incluir referencias a los repositorios donde se ubica el proyecto para que los interesados puedan repetir los experimentos y análisis. En este tipo de presentación es importante contestar la pregunta: ¿cómo se obtuvieron los resultados?

• Presentación no técnica: debe omitir detalles de análisis e implementación e incluir resultados duros y cómo aplicar esos resultados para lograr el objetivo del negocio. Este objetivo puede traducirse en beneficios económicos, incremento en ventas, campañas de marketing, incremento en número de usuarios, entre otros. La pregunta a responder es: ¿qué beneficio se obtiene con esos resultados?. En este tipo de presentación se debe ser cuidadoso en no utilizar tecnicismos a menos que sea estrictamente necesario. Es nuestra responsabilidad describir las cosas de modo que esté al alcance de profesionales de diversas áreas. Y eso no es una tarea trivial.

Dilemas técnicos

La implementación de un producto basado en análisis de datos masivos provoca retos interesantes a resolver dado que los sistemas productivos generalmente no están diseñados para el tipo de carga que implica. Por ejemplo, una base de datos que soporta una aplicación web de alta escalabilidad puede responder adecuadamente cuando se tienen millones de peticiones concurrentes pero cuando se necesita consultar para análisis de datos o para un producto basado en Big Data puede poner en riesgo los sistemas productivos. ¿Qué hacer entonces?, ¿Implementar una solución batch/offline sacrificando posible utilidad de una solución en tiempo real para el usuario?, ¿replicar la base de datos a otra de sólo lectura o con fines exclusivos para el producto de data science?, ¿pagar una nueva instancia en caso de bases de datos comerciales o escoger una alternativa abierta? ¿exportar simplemente a archivos de texto y dejar que los scripts hagan el trabajo pesado? ¿utilizar cómputo en la nube para el procesamiento, y si es así, cómo hacer segura la información privada que saldrá de nuestros servidores?

Durante la fase de diseño del sistema, uno de los primeros dilemas que se pueden encontrar en las implementaciones es el tipo de arquitectura en la que va a correr. En mayor parte se cuenta con dos opciones: utilizar la infraestructura local o utilizar las diferentes servicios que ofrecen procesamiento en la nube. En este caso es muy importante conocer las ventajas y desventajas que cada una de estas implementaciones ofrece, además de las necesidades propias del sistema a implementar y que pueden afectar en menor o mayor medida a la decisión que vamos a tomar.

Lo primero que tenemos que tomar en cuenta es la capacidad de procesamiento necesaria para la implementación de nuestra solución de data science, de esta manera podemos estimar si los servidores propios son lo suficientemente capaces para soportar la carga extra que vamos a agregar al nivel de trabajo diario. En caso de que el procesamiento no sea factor, se debe de tomar en cuenta la cuestión monetaria ya que las soluciones en la nube involucran un gasto que comienza siendo moderado pero rápidamente puede llegar a cifras altas dependiendo de las instancias que necesitemos crear y el tiempo que las tengamos operando.

Además de las barreras económicas y de procesamiento, existen requerimientos específicos del sistema. En este caso si se elige una implementación de cloud, es necesario prever la integración necesaria con el sistema que tenemos local. Necesitamos saber si es necesaria la replicación de información almacenada en bases de datos locales y que se tendrá que estar replicando de manera constante a la solución en la nube, además de otros aspectos como la cantidad de información que será transferida desde el ambiente local a la nube y viceversa.

Si por otra parte se opta por una implementación local, es necesario prever desde un principio la necesidad futura ya que si es necesario escalar la implementación y no se cuenta con la infraestructura necesaria para hacerlo es posible que se requiera una reimplementación del sistema. Esta decisión puede llevar al consumo de tiempo y recursos que se pudieran haber invertido en otro tipo de solución.

Conclusión

Un proyecto de data science representa un reto en distintos niveles y los cuestionamientos son inevitables en el transcurso de las diversas etapas del mismo. Sin embargo, por sobre cualquier aspecto técnico está el factor humano. La colaboración, capacidad, motivación y buena disposición de los miembros del equipo son los factores clave que determinarán si el proyecto tendrá éxito o no.