En Deployr, nuestra misión es asesorar, guiar y acompañar a empresas de todo tipo y tamaño en el camino de la puesta productiva de modelos de machine learning y en la transformación a ser data-driven. Pero por supuesto, no todas las compañías tienen los recursos para aplicar efectivamente estas herramientas ni todos los problemas deben ser resueltas con estas tecnologías.

Por eso, es crucial poder, en un período de tiempo acotado, analizar si es factible la aplicación de machine learning para solucionar un problema de negocio concreto. Y hacemos énfasis en “en un período de tiempo acotado”, porque la pasividad en este diagnóstico puede tener ramificaciones que impacten los ingresos de las organizaciones.

Como veremos, algunos desafíos pueden ser resueltos con aprendizaje automático mucho más efectivamente que con herramientas tradicionales, pero requiere una serie de condiciones previas y de trabajo dedicado a su aplicación. Y para definir si esas condiciones se dan, hemos diseñado lo que llamamos proceso de Discovery: 4 semanas para decidir cómo aplicar ML en tu negocio. En este post, te contamos de qué se trata.

Risky business

Antes de empezar a hablar de la metodología en sí misma, vamos a analizar brevemente cuáles son los riesgos de no realizar una validación rápida de la factibilidad de un proyecto de ML. Algunos de ellos son:

• Costo financiero elevado: Invertir una suma considerable de dinero en adquirir herramientas y recursos para un proyecto de machine learning que luego resulta inviable o ineficaz no sólo representa una pérdida de dinero, sino que también afecta el presupuesto disponible para otras iniciativas clave de la empresa.

• Pérdida de tiempo: El tiempo es oro, y si no validamos rápidamente la viabilidad de un proyecto de ML, podríamos desperdiciar meses de trabajo en una dirección que no nos lleva a ningún resultado positivo, lo que retrasa la capacidad de la empresa para innovar y adaptarse rápidamente al mercado.

• Pérdida de ventaja competitiva: En el mundo empresarial actual, la tecnología es clave y no moverse rápido te pone en una desventaja competitiva. Si el mercado adopta eficazmente machine learning para hacer más eficientes sus procesos y tomar decisiones más inteligentes, tu empresa corre el riesgo de quedar atrás.

• Riesgo reputacional: Un proyecto de machine learning fallido puede tener un impacto negativo en la reputación de la empresa. Si anunciamos una iniciativa que luego no cumple con las expectativas, podríamos perder la confianza de clientes, inversores y socios clave, y por ende afectar nuestra imagen y credibilidad.

• Desmotivación de los equipos de trabajo: Las áreas de tecnología son el motor de esta transformación digital orientada a los datos. Si invierten tiempo y esfuerzo en un proyecto de ML que no resulta exitoso debido a una validación insuficiente, podrían desanimarse y perder la motivación para futuras iniciativas, o incluso perder miembros importantes que deciden irse a la competencia.

• Inversión en herramientas y tecnología incorrectas: Adquirir herramientas y tecnologías sin una evaluación adecuada lleva a invertir en soluciones que no se alinean con las necesidades reales del negocio. Aunque puedan parecer prometedoras inicialmente, es esencial realizar una investigación exhaustiva para garantizar que sean apropiadas y efectivas para resolver los desafíos que enfrenta tu empresa.

Estos son solo algunos ejemplos, que por supuesto pueden generar incluso mayores problemas inesperados a futuro o agravarse entre ellos en un círculo vicioso que resulta muchas veces catastrófico en empresas más pequeñas o con menos espalda financiera. En cambio, una validación rápida y efectiva de esta viabilidad nos da como ventajas lo opuesto a lo que acabamos de describir: eficiencia en costos, rapidez en la toma de decisiones, ventaja competitiva, mayor adaptabilidad, enfoque en objetivos clave, calidad del producto y retorno de inversión acelerado.

Cabe destacar que todo lo mencionado anteriormente aplica a cualquier proyecto de desarrollo de software, pero en el caso de data science, tenemos una capa de complejidad adicional, ya que estamos trabajando con estadística y resultados en muchos casos inciertos. Entonces, ¿es posible aplicar un proceso de evaluación de factibilidad a este tipo de proyectos?

Afortunadamente la respuesta es: ¡sí! Y acá te contamos cómo lo hacemos.

Te acompañamos en el camino de descubrimiento

El proceso de Discovery tiene un objetivo muy concreto: validar en cuatro semanas si es posible o no la aplicación de machine learning para la solución de un problema de negocio específico. Para esto, cada una de las semanas está orientada a entender un aspecto distinto, tanto del proyecto en sí como de la empresa, sus recursos y la industria en la que operan.

Al diseñar esta metodología, decidimos separar el mes de Discovery en las siguientes cuatro partes:

• Semana 1: Definición del problema y recolección de datos.
• Semana 2: Análisis exploratorio y preprocesamiento de datos.
• Semana 3: Selección y entrenamiento de modelos preliminares.
• Semana 4: Evaluación final y presentación de resultados.

Veamos más en detalle qué ocurre en cada una de estas etapas.

Semana 1

En esta primera semana, como dijimos, nos enfocamos en la definición del problema y la recolección de datos. Esto implica en primer lugar tener reuniones con los stakeholders para entender cómo funciona el negocio y qué problema quieren resolver. Usualmente buscamos interiorizarnos en cómo funciona el rubro, quiénes son los usuarios, y cuáles son los pain points que tienen esos usuarios y el negocio.

Y, tal vez incluso más importante, de este trabajo surge uno de los puntos fundamentales de esta etapa: identificar cuáles son las métricas clave que se desea mejorar. Las empresas no funcionan en abstracto sino que tienen KPI que, si se los optimiza, redundan en ganancias tangibles para el negocio.

Algunos ejemplos comunes: reducir tiempos de espera para la atención, mejorar la evaluación de satisfacción de los clientes, reducir índices de mora. Todo proyecto de machine learning debe ser concebido, planeado y desarrollado con el norte de mejorar esos KPI que devienen en ventajas financieras y competitivas.

Adicionalmente a estos primeros dos aspectos de la primera semana que están más orientados a la parte de negocio, nos enfocamos en la generación de un dataset para análisis y exploración, que nos servirá de punto de partida y durante las siguientes tres semanas.

Semana 2 

La semana dos está orientada al análisis exploratorio de datos, en la que tomamos los datos a los que accedimos en la primera semana y nos zambullimos en ellos para tratar de entenderlos y encontrar tendencias, relaciones e insights que nos den pistas acerca de cómo pueden ayudarnos con el problema que queremos resolver.

También buscamos conectar esos datos, que son representaciones abstractas de la realidad, con la realidad en sí misma para ver cómo se vinculan con el negocio. En definitiva, lo que buscamos es poder contar una historia a través de esos datos que nos ayude a cristalizar una visión integral del panorama que tenemos enfrente.

Para esto, de este paso surgen muchas visualizaciones de los datos: gráficos que condensen información de manera simple de entender y que faciliten la extracción de insights y el storytelling, tanto para los equipos técnicos como para los tomadores de decisiones de las organizaciones.

Semana 3

En esta instancia, ya entendimos el problema a solucionar y cuáles son los datos relevantes, y estamos en condiciones de empezar el modelado en sí mismo. Aquí es cuando se realiza identifica el tipo de problema -y por consiguiente de modelo- que vamos a utilizar: clasificación, regresión o clusterización.

Los data scientist que se encargan del entrenamiento se encargan de definir la métrica con la que se evaluará la performance de estos modelos. Esto no se refiere a lo que hemos hablado anteriormente de los KPI de negocio, sino a mediciones matemáticas de la precisión de nuestro modelo (accuracy, precision, ROC/AUC…). Este punto no es para nada menor, porque la elección de una métrica adecuada es fundamental en el éxito o fracaso de este tipo de proyectos, ya que utilizar una incorrecta puede resultar en que evaluemos como viable un proyecto que no lo es o viceversa.

De esta semana surge lo que se conoce como POC (“prueba de concepto” por sus siglas en inglés), un modelo inicial que no necesariamente está perfectamente optimizado pero funciona como base para comparaciones futuras y como materia prima de lo que ocurre en la cuarta semana.

Semana 4

Ya en la etapa final de nuestro proceso de discovery, el equipo toma el modelo que se entrenó en la instancia anterior y se aplican algunas optimizaciones para su evaluación final y la presentación de resultados al negocio.

Nos enfocamos, además, en la explicabilidad del modelo: no nos sirve decir “la métrica X dio el valor Y”, queremos encontrar en ello una coherencia y un correlato con la realidad. Esto se puede hacer mediante técnicas de feature importance, que buscan expresar numéricamente el peso de cada una de las variables para el modelo. Este punto es muy importante porque en muchos casos el cliente, que es el experto de negocio, puede validarlo mediante su opinión y su visión basada en la experiencia para entender si nuestros resultados tienen sentido.

Por último, se prepara para el cliente una presentación con todos nuestros resultados y aprendizajes de la etapa de Discovery, además de recomendaciones de próximos pasos en función de los logros alcanzados y la viabilidad del proyecto. Es una instancia de feedback e intercambio que sirve como cierre de estas cuatro semanas de arduo trabajo.

Próximos pasos

¡Fueron cuatro semanas muy intensas! Idealmente, el cliente se lleva de esto conocimiento e información que los ayuden en su trabajo cotidiano. Dicho esto, el proceso no termina aquí. Luego de este mes, hay muchas cosas que se pueden seguir trabajando:

• Puesta en producción del modelo: Un modelo entrenado no es más que un archivo en la computadora del científico de datos. Para verdaderamente aportar valor en el día a día, se debe hacer lo que se conoce como deployment o puesta en producción, que es crear el software que permitirá a los usuarios usar el modelo con facilidad y rapidez.

• A/B testing: Más allá de las métricas con las que evaluamos al modelo, existen instancias adicionales para garantizar su calidad y su impacto en la realidad. Esto se hace mediante técnicas como A/B testing, en las que se testean hipótesis estadísticas para asegurarnos que el modelo realmente es de calidad y funcione como punto comparativo para cualquier desarrollo futuro.

• Monitoreo y reentrenamiento: La métrica con la que evaluamos al modelo no es inmutable ni permanente. Los cambios en la distribución de los datos a lo largo del tiempo puede hacer que su performance se degrade a lo largo del tiempo, por lo que en muchos casos es sumamente importante implementar mecanismos de monitoreo y, eventualmente, reentrenamiento del modelo con datos más recientes.

• Mejora continua del modelo: Esto puede ser mediante la elección de algoritmos mejores o más nuevos que puedan ir surgiendo, un trabajo más exhaustivo de selección de variables, procesos de optimización, incorporación de métricas complementarias y una gran diversidad de opciones más, hasta encontrar la configuración que mejor se adecúe a las necesidades de cada negocio.

Estos son sólo algunos ejemplos de posibles próximos pasos. Cada cliente es un mundo y cada problema a resolver requiere análisis, dedicación y compromiso, por lo que no existen respuestas universalmente válidas. Pero al finalizar el mes de Discovery, cada uno de ellos debe al menos tener un panorama claro, más entendimiento de posibles soluciones y un mapa de ruta concreto de mejoras y avances.

¿Querés saber más? Te dejamos nuestra playlist de Business Webinars, orientados a empresas que buscan obtener el mayor valor a partir de sus datos.