Iniciar iniciativas de productos de aprendizaje automático con el pie derecho |  de Anna Via |  mayo, 2024

Las 3 principales lecciones aprendidas: el problema, el tamaño y los datos

Imagen por alambre de seguridaden Pexels

Esta publicación de blog es una versión actualizada de parte de una charla en una conferencia que di en GOTO Amsterdam el año pasado. La charla también está disponible para ver en linea.

Como gerente de productos de aprendizaje automático, me fascina la intersección entre el aprendizaje automático y la gestión de productos, particularmente cuando se trata de crear soluciones que brinden valor e impacto positivo en el producto, la empresa y los usuarios. Sin embargo, lograr proporcionar este valor e impacto positivo no es una tarea fácil. Una de las principales razones de esta complejidad es el hecho de que, en las iniciativas de Machine Learning desarrolladas para productos digitales, se cruzan dos fuentes de incertidumbre.

Desde la perspectiva de la gestión de productos, el campo es incierto por definición. Es difícil saber el impacto que tendrá una solución en el producto, cómo reaccionarán los usuarios ante ella y si mejorará o no las métricas del producto y del negocio… Tener que trabajar con esta incertidumbre es lo que hace que los gerentes de producto sean potencialmente diferentes de otros roles. como gerentes de proyectos o propietarios de productos. Estrategia de producto, descubrimiento de producto, dimensionamiento de oportunidades, priorización, experimentación ágil y rápida, son algunas estrategias para superar esta incertidumbre.

El campo del Machine Learning también tiene un fuerte vínculo con la incertidumbre. siempre me gusta decir “Con los modelos predictivos, el objetivo es predecir cosas que no sabes que son predecibles”. Esto se traduce en proyectos cuyo alcance y gestión son difíciles, en la imposibilidad de comprometerse de antemano con un producto de calidad (buen rendimiento del modelo) y en muchas iniciativas que permanecen para siempre como POC fuera de línea. Definir bien el problema a resolver, el análisis y exploración inicial de datos, empezar poco a poco y estar cerca del producto y del negocio, son acciones que pueden ayudar a abordar la incertidumbre del ML en los proyectos.

Mitigar este riesgo de incertidumbre desde el principio es clave para desarrollar iniciativas que acaben aportando valor al producto, a la empresa y a los usuarios. En esta publicación de blog, profundizaré en Mis 3 lecciones principales aprendidas al iniciar iniciativas de productos ML para gestionar esta incertidumbre desde el principio.. Estos aprendizajes se basan principalmente en mi experiencia, primero como científico de datos y ahora como gerente de producto de ML, y son útiles para mejorar la probabilidad de que una solución de ML llegue a producción y logre un impacto positivo. Prepárate para explorar:

  • Comience con el problema y defina cómo se utilizarán las predicciones desde el principio.
  • Empiece poco a poco y manténgalo pequeño si puede.
  • Datos, datos y datos: calidad, volumen e histórico.
Empiece por el problema correcto, Steve Johnson @ Pexels

Debo admitir que lo he aprendido de la manera más difícil. He estado involucrado en proyectos en los que, una vez que se desarrolló el modelo y se determinó que el rendimiento de la predicción era “suficientemente bueno”, las predicciones del modelo no eran realmente utilizables para ningún caso de uso específico, o no eran útiles para ayudar a resolver ningún problema.

Hay muchas razones por las que esto puede suceder, pero las que he encontrado con más frecuencia son:

  • Iniciativas impulsadas por soluciones: incluso antes de que GenAI, Machine Learning y los modelos predictivos fueran soluciones “geniales”, y por eso algunas iniciativas comenzaron desde la solución ML: “Intentemos predecir la deserción” (usuarios o clientes que abandonan una empresa), “Intentemos predecir segmentos de usuarios.”… El revuelo actual sobre GenAI ha empeorado esta tendencia, ejerciendo presión sobre las empresas para que integren soluciones GenAI “en cualquier lugar” que encajen.
  • Falta de diseño de extremo a extremo de la solución.: en muy pocos casos, el modelo predictivo es una solución independiente. Sin embargo, normalmente los modelos y sus predicciones se integran en un sistema más grande para resolver un caso de uso específico o habilitar una nueva funcionalidad. Si esta solución integral no se define desde el principio, puede ocurrir que el modelo, una vez ya implementado, resulte inútil.

Para iniciar una iniciativa de LD con el pie derecho, es clave empezar con el buen problema a resolver. Esto es fundamental en la gestión de productos y, de forma recurrente, refuerza a los líderes de productos como Marty Cagan y Melissa Perri. Incluye el descubrimiento de productos (a través de entrevistas a usuarios, estudios de mercado, análisis de datos…) y el dimensionamiento y priorización de oportunidades (teniendo en cuenta datos cuantitativos y cualitativos).

Una vez identificadas las oportunidades, el El segundo paso es explorar posibles soluciones. para el problema, que debería incluir técnicas de Machine Learning y GenAI, si pueden ayudar a resolver el problema.

Si se decide probar una solución que incluya el uso de modelos predictivos, el El tercer paso sería hacer una definición y diseño de extremo a extremo de la solución o sistema.. De esta manera, podemos garantizar los requisitos sobre cómo utilizar las predicciones por parte del sistema, influir en el diseño y la implementación de la pieza predictiva (qué predecir, datos a utilizar, tiempo real frente a lotes, comprobaciones de viabilidad técnica…).

Sin embargo, me gustaría agregar que podría haber una excepción notable en este tema. Partir de las soluciones GenAI, en lugar de desde el problema, puede tener sentido si esta tecnología acaba revolucionando realmente tu sector o el mundo tal y como lo conocemos. Hay muchas discusiones sobre esto, pero yo diría que aún no está claro si eso sucederá o no. Hasta ahora hemos visto esta revolución en sectores muy concretos (atención al cliente, marketing, diseño…) y relacionados con la eficiencia de las personas a la hora de realizar determinadas tareas (codificar, escribir, crear…). Sin embargo, para la mayoría de las empresas, a menos que se considere trabajo de I+D, ofrecer valor a corto y mediano plazo debería significar centrarse en los problemas y considerar la GenAI como cualquier otra solución potencial para ellos.

Las experiencias difíciles también conducen a este aprendizaje. Esas experiencias tenían en común un gran proyecto de ML definido en forma de cascada. El tipo de proyecto que durará 6 meses y seguirá el ciclo de vida de ML fase por fase.

Planificación de proyectos en cascada siguiendo las fases del ciclo de vida de ML, imagen del autor

¿Qué podría salir mal, verdad? Déjame recordarte mi cita anterior. “Con los modelos predictivos, el objetivo es predecir cosas que no sabes que son predecibles”! En una situación como esta, puede suceder que llegue al mes 5 del proyecto y durante la evaluación del modelo se dé cuenta de que no hay manera de que el modelo pueda predecir lo que necesita predecir con una calidad suficientemente buena. O peor aún, llegas al mes 6, con un supermodelo implementado en producción, y te das cuenta de que no aporta ningún valor.

Este riesgo se combina con las incertidumbres relacionadas con el Producto y hace que sea obligatorio evitar grandes iniciativas en cascada, si es posible. Esto no es algo nuevo ni está relacionado únicamente con las iniciativas de ML, por lo que hay mucho que podemos aprender del desarrollo de software tradicional, Agile, Lean y otras metodologías y mentalidades. Al comenzar con algo pequeño, validar supuestos pronto y de manera continua, y experimentar y escalar de manera iterativa, podemos mitigar efectivamente este riesgo, adaptarnos a los conocimientos y ser más rentables.

Si bien estos principios están bien establecidos en el desarrollo tradicional de software y productos, su aplicación a las iniciativas de ML es un poco más compleja, ya que no es fácil definir “pequeño” para un modelo e implementación de ML. Sin embargo, existen algunos enfoques que pueden ayudar a comenzar poco a poco en las iniciativas de aprendizaje automático.

Enfoques basados ​​en reglas, simplificando un modelo predictivo mediante un árbol de decisión. De esta manera, las “predicciones” se pueden implementar fácilmente como “declaraciones if-else” en producción como parte de la funcionalidad o el sistema, sin la necesidad de implementar un modelo.

Pruebas de concepto (POC), como una forma de validar fuera de línea la viabilidad predictiva de la solución de aprendizaje automático y dar pistas sobre el potencial (o no) del paso predictivo una vez en producción.

Productos mínimos viables (MVP), centrarse primero en características, funcionalidades o segmentos de usuarios esenciales y ampliar la solución solo si se ha demostrado el valor. Para un modelo de ML, esto puede significar, por ejemplo, solo las características de entrada prioritarias más sencillas, o predecir solo para un segmento de puntos de datos.

Compra en lugar de construir, aprovechar las soluciones o plataformas de aprendizaje automático existentes para ayudar a reducir el tiempo de desarrollo y los costos iniciales. Sólo cuando demuestre su valor y los costos aumenten demasiado, podría ser el momento adecuado para decidir desarrollar la solución de aprendizaje automático internamente.

Usando GenAI como MVP, Para algunos casos de uso (especialmente si involucran texto o imágenes), las API genAI se pueden usar como un primer enfoque para resolver el paso de predicción del sistema. Tareas como clasificación de texto, análisis de opiniones o detección de imágenes, donde los modelos GenAI ofrecen resultados impresionantes. Cuando se valida el valor y si los costos aumentan demasiado, el equipo puede decidir construir un modelo de ML “tradicional” específico internamente.

Tenga en cuenta que utilizar modelos GenAI para la clasificación de imágenes o textos, si bien es posible y rápido, significa utilizar un modelo complejo demasiado grande (caro, falta de control, alucinaciones…) para algo que podría predecirse con uno mucho más simple y controlable. Una analogía divertida sería la idea de entregando una pizza con un camión: es factible, pero ¿por qué no utilizar simplemente una bicicleta?

Imagen por Tima Miroshnichenkoen Pexels

Los datos son EL problema recurrente que encuentran los científicos de datos y los equipos de ML al iniciar iniciativas de ML. Cuántas veces te han sorprendido datos con duplicados, errores, lotes faltantes, valores raros… ¡Y qué diferente es eso de los conjuntos de datos de juguetes que encuentras en los cursos online!

También puede suceder que los datos que necesitas simplemente no estén ahí: el seguimiento del evento específico nunca se implementó, la recopilación y los ETL adecuados se implementaron recientemente… He experimentado cómo esto se traduce en tener que esperar algunos meses para poder iniciar un proyecto con suficientes datos históricos y de volumen.

Todo esto se relaciona con el dicho “Basura dentro basura fuera”: Los modelos de aprendizaje automático son tan buenos como los datos con los que se entrenan. Muchas veces las soluciones tienen mayor potencial de mejora mejorando los datos que mejorando los modelos (IA centrada en datos). Los datos deben ser suficientes en volumen, históricos (los datos generados durante años pueden aportar más valor que el mismo volumen generado en solo una semana) y calidad. Para lograrlo, es fundamental un gobierno, recopilación, limpieza y preprocesamiento maduros de datos.

Desde el IA ética Desde nuestro punto de vista, los datos también son una fuente principal de sesgo y discriminación, por lo que reconocerlo y tomar medidas para mitigar estos riesgos es primordial. Teniendo en cuenta los principios de gobernanza de datos, la privacidad y el cumplimiento normativo (por ejemplo, la legislación de la UE) RGPD), también es clave para garantizar un uso responsable de los datos (especialmente cuando se trata de datos personales).

Con Modelos GenAI Esto está cambiando: ya se utilizan enormes volúmenes de datos para entrenarlos. Al utilizar este tipo de modelos, es posible que no necesitemos datos de volumen y calidad para el entrenamiento, pero sí para realizar ajustes (ver Buenos datos = buena GenAI), o para construir las indicaciones (nutrir el contexto, aprendizaje de pocas tomas, Recuperación Generación Aumentada… — Expliqué todos estos conceptos en un Publicación anterior!).

Es importante tener en cuenta que al utilizar estos modelos estamos perdiendo el control de los datos utilizados para entrenarlos y podemos sufrir la falta de calidad o tipo de datos utilizados allí: hay muchos ejemplos conocidos de sesgo y discriminación en los resultados de GenAI. que pueden impactar negativamente nuestra solución. Un buen ejemplo fue el artículo de Bloomberg sobre cómo “Cómo ChatGPT es la herramienta soñada de un reclutador: las pruebas muestran que hay prejuicios raciales”. Tablas de clasificación de LLM que prueban sesgoso LLM capacitados específicamente para evitar estos sesgos puede resultar útil en este sentido.

Ejemplo de sesgo de género con ChatGPT (solicitud del 1 de mayo de 2024)

Comenzamos esta publicación de blog discutiendo qué hace que las iniciativas de productos de ML sean especialmente complicadas: la combinación de la incertidumbre relacionada con el desarrollo de soluciones en productos digitales, con la incertidumbre relacionada con el intento de predecir cosas mediante el uso de modelos de ML.

Es reconfortante saber que existen medidas y estrategias viables disponibles para mitigar estos riesgos. Sin embargo, quizás las mejores estén relacionadas con iniciar las iniciativas con el pie derecho. Para hacerlo, puede ser realmente útil comenzar con el problema correcto y un diseño de extremo a extremo de la solución, reducir el alcance inicial y priorizar la calidad, el volumen y la precisión histórica de los datos.

Espero que esta publicación haya sido útil y te ayude a desafiar cómo comenzar a trabajar en futuras nuevas iniciativas relacionadas con productos ML.