El ciclo de un proyecto de ciencia de datos

A la hora de abordar un proyecto de ciencia de datos es fácil recurrir al planteamiento de un modelo pipeline tradicional: establezco objetivos, capturo los datos, creo el modelo, evalúo y valido. Sin embargo, la experiencia nos lleva a proponer un planteamiento más complejo, con un enfoque de revisión continua que permita detectar las variaciones en el alcance y consecución del objetivo del proyecto de forma temprana.

Una visión reducida del proyecto resulta incompleta y presenta problemas porque el pipeline olvida aspectos desde el inicio que pueden ser decisivos para el éxito del proyecto, pudiendo encontrarnos con el resultado de “algo” que funciona pero que no sirve para nada.

Entonces, ¿cómo sería realmente un proceso válido a la hora de desarrollar un proyecto de datos con enfoque predictivo?

Como he comentado al inicio, el auténtico ciclo no son pasos consecutivos, sino un feedback loop que permite detectar de forma temprana si los objetivos se han definido de manera correcta o si los datos son adecuados para ello, por ejemplo. Los dos esquemas comparados serían los siguientes:

Modelo pipeline de un proyecto de ciencia de datos. Fuente: keepler.io

Modelo iterativo y feedback loop de un proyecto de ciencia de datos. Fuente: keepler.io

Definición de objetivos

En un caso de fuga de clientes, ¿es el objetivo del proyecto detectar el churn o fuga de clientes? Desde nuestro punto de vista no, el planteamiento inicial ya es erróneo. El auténtico objetivo del proyecto no es “detectar”, que sería el objetivo del modelo, sino “reducirlo” de modo preventivo, que sería el objetivo del proyecto. Es cierto que hay que detectarlo, pero hay que saber qué se va a hacer cuando se detecte, si no será información que no sirva de nada. Un modelo puede funcionar con una precisión altísima, estar validado, haber hecho el ciclo completo y funcionar perfectamente… pero si se obtiene dando un escaso margen de tiempo, insuficiente para poder actuar ¿de qué sirve? Desde el inicio hay que tener en cuenta cómo se va a utilizar, para qué, qué tiempo de adelanto requiere para que sea útil… Es un detalle sutil, pero marca la diferencia para el éxito del proyecto. Por eso, a la hora de plantearse objetivos, hay que dedicar el tiempo suficiente para analizar la pregunta y planteamientos correctos.

Recolección de información

Por ejemplo, en una ETL normal en la que hagamos una carga batch inicial única en un ecosistema cloud, herramientas como Redshift de AWS nos van a permitir que la información pase razonablemente validada y ajustada a un formato definido, pudiendo detectar fácilmente lo que no se ajusta al formato que queremos. Pero se requiere una siguiente fase de limpieza que se escapa a ese proceso anterior más automatizado, eliminando valores vacíos, outliers, sesgos que deben ser aclarados por el cliente (por ejemplo, si la mayoría de clientes muestra la misma edad cuando debería estar más distribuida, o lo contrario). Es decir, asegurarse de que la información está limpia no solo a nivel de formato, sino de contenido y/o lógica. Este es el proceso que llamamos data quality, una de las primeras fases dentro de una PoC que permite validar la información con la que vamos a trabajar. Si no lo es, es el momento de parar aquí y solucionarlo. Siempre hay que tener en cuenta que la “salida” va a depender de la “entrada” de datos.

Construcción del modelo

Construir el modelo tiene una fase previa de exploración que sirve como punto de control u objetivo intermedio de lo que quiero conseguir, esto es analítica exploratoria. Un ejemplo de esta fase de analítica exploratoria es el dataset del Titanic, un básico en ciencia de datos en el que con un featuring engineering, a partir de una o varias variables, es posible sacar otra información que aporta valor. Una analítica exploratoria da mucho insight y, poco a poco, irá desplazando el business intelligence tradicional, que se limita a demostrar o dar respuesta a preguntas que ya se conocen, mientras que en este proceso la información es la que va dando lugar a hacerse preguntas.

En este punto, contrastar de forma constante con Negocio es clave. ¿Tiene sentido la información que obtenemos? Consultar directamente a la fuente es esencial para saber si la dirección es buena. Si la información que obtenemos no tiene sentido para Negocio, habría que volver a la parte de captura porque, muy posiblemente, los datos estarían mal de origen.

A la hora de construir el modelo hay que tener en cuenta que existen dos familias de algoritmos principalmente: supervisados y no supervisados. El algoritmo supervisado es aquel en el que ya tengo la respuesta. En el no supervisado no tengo ningún tipo de etiqueta ni datos a priori, puedo imaginar que hay patrones pero quiero ver qué patrones surgen. Hay un volumen inmenso de algoritmos posibles, cada uno con sus ventajas y problemas ante cada caso concreto: desde uno muy sencillo de mover, muy interpretable y probablemente muy directo y computable, pero que no pueda capturar un patrón muy complejo; hasta los muy complejos y difíciles de computar, con un espacio de aprendizaje muy grande, que hace perder la interpretabilidad de lo que estás haciendo.

Validación del modelo predictivo

La validación offline sería idealmente la fase final en un piloto, con la que validarías si la capacidad predictiva del modelo es correcta. Para ello, lo más habitual es reservar datos recientes en el tiempo para simular que lo estarías aplicando «en este momento» pero sin impactar de forma real.

Si la validación offline funciona y ha sido correcta tanto para el científico de datos como para Negocio, es el momento de pasar a producción. Este paso es esencial, por lo que hay que tenerlo en cuenta desde el inicio del diseño. Puedo tener mi script y mi modelo y que funcione a la perfección, pero que no pueda pasarse a producción por ser muy complicado a nivel de ingeniería, por requerir un tiempo de respuesta determinado que no se cumple… Desde el inicio hay que plantear cómo se va a utilizar “de verdad”. El modelo puede funcionar bien con 10GB pero, ¿funcionará con 10TB? Una solución habitual puede ser crear una API del modelo y hacer un escalado horizontal.

Ya en producción, es el momento de reproducir esa validación offline pero en su ámbito real. ¿Qué está haciendo el modelo? ¿Qué está contestando? ¿Cuánto tarda en contestar? Es el momento de la verdad.

El resultado

Cuando todo funciona en producción es el momento de hacer un A/B testing para evaluar si el enfoque tiene el efecto que esperaba. En un caso de fuga de clientes, como veíamos al inicio, en un test A/B a un grupo le aplico el modelo, a otro el modelo y posibles acciones de retención y a otro le aplico predicción pero no le digo nada, solo los utilizo para comprobar que el modelo sigue acertando, a modo placebo en un estudio médico. ¿El modelo está acertando? ¿El grupo sobre el que realizo acciones funciona mejor respecto a si no las realizo?

Y aquí es donde medimos y aplicamos los KPI, que no hay que olvidar que, desde el inicio, deberíamos haber establecido teniendo en cuenta criterios básicos como que sean medibles o alcanzables, pero además deben estar alineados con los objetivos y lo que se pretende a nivel de Negocio.

Si se cumple el KPI, el proyecto de datos será un éxito. Si no se cumple, habrá que plantearse: ¿He sido muy exigente estableciendo KPI? ¿Las herramientas de detección son buenas? ¿Se pueden plantear mejoras como: introducir más información para crear más variables, crear modelos más complejos para un cuadro más completo, mejorar los tiempos de respuesta?

En conclusión

Como has podido leer, en un proyecto de ciencia de datos no todo es igual para todos proyectos, ni lineal, ni estandarizable. El feedback continuo, muy alineado con las metodologías ágiles de trabajo, es clave para llegar a objetivos útiles para Negocio, que es el objetivo final de un proyecto de este tipo.

Imagen: pexels.com