Mas leido
Building Stories
Modo Rua: Redefiniendo el desarrollo de aplicaciones mediante iteración centrada en el usuario Ago 23
Building Stories
NuStories: Adaptación de productos para clientes fanáticos en varios países Oct 30
Culture & Values
Cómo los valores y la cultura de Nu dan forma a los productos que creamos Ago 7
Carreras
Reunimos a grandes mentes de diversos orígenes que permiten la discusión y el debate y mejoran la resolución de problemas.
Conoce más sobre nuestras carreras
Escrito por Felipe Almeida y revisado por Rubens Bolgheroni
El Aprendizaje Automático (ML) es poderoso, pero costoso y arriesgado. Es poderoso porque a menudo es la única solución escalable para problemas complejos. Es caro porque los recursos (profesionales especializados y potencia informática) son caros. Y es arriesgado porque los modelos fallan de maneras extrañas y a veces silenciosas: la deriva de datos o funciones rotas no desencadenarán excepciones, aunque las predicciones del modelo probablemente serán basura.
Un proyecto de ML es el proceso para llevar una idea a un sistema de software que realmente funcione utilizando un modelo de ML.
Escribimos sobre los usos del aprendizaje automático en tiempo real en el pasado. Pero antes de que puedas pensar en utilizar ML para ayudar a tu organización, necesitas un proyecto que la lleve de una idea a una pieza de software funcional que genere resultados. Y no querrás que el proyecto fracase, ya que es dinero y tiempo que podrían haberse gastado en otra parte del negocio. Esto, por supuesto, supone que, en primer lugar, necesitas un modelo de ML.
Ahora bien, incluso si un proyecto de aprendizaje automático fracasa, es mejor si fracasa rápidamente, antes de haber invertido demasiado tiempo y dinero en él. La Figura 1 a continuación muestra los diferentes resultados de un proyecto, dependiendo de si aportó valor al negocio y del tiempo que llevó completarlo.
Figura 1: Los resultados del proyecto rara vez son binarios, sino un continuo de “niveles” de éxito. El éxito depende del impacto empresarial que se haya logrado, pero tenemos en cuenta la duración y el costo del proyecto.
Ahora bien, ¿por qué fracasan los proyectos de ML?
Hay muchas razones: problemas de datos y expectativas desalineadas entre los clientes y el equipo de modelos, por nombrar algunas.
Sin embargo, los proyectos de aprendizaje automático en tiempo real aumentan los riesgos: tienen incluso más modos de falla que los proyectos normales (que no son en tiempo real). Además de todos los riesgos inherentes al ML, los modelos en tiempo real son sistemas de software que necesitan integrarse con otros sistemas en tiempo real a través de API, a menudo están sujetos a tiempos de respuesta estrictos y deben mantener la paridad con el entorno de formación.
En esta publicación, mostraremos cómo es un proyecto típico de aprendizaje automático en tiempo real y luego repasaremos las formas más comunes en las que estos proyectos pueden fallar. Finalmente, brindaremos instrucciones prácticas sobre cómo abordar o eliminar riesgos en cada uno de esos puntos.
Cronograma típico del proyecto
Como se mencionó anteriormente, un proyecto es el proceso para tomar una idea y hacerla realidad. En el caso del ML en tiempo real, esto implica elegir un problema empresarial, comprender si y cómo se puede resolver con ML y, finalmente, crear un modelo e integrarlo con la infraestructura TI subyacente del negocio.
Las etapas de un proyecto típico de aprendizaje automático en tiempo real se pueden resumir de la siguiente manera:
Ten en cuenta que los pasos anteriores no son necesariamente lineales. Es decir, no es necesario que ocurran uno tras otro.
Por ejemplo, es posible que sea necesario volver a la etapa de ideación durante el proyecto para revisar suposiciones que resultaron ser falsas. Además, es posible que los científicos de datos necesiten volver a entrenar el modelo si hay un problema con una función que ahora debe eliminarse. La Figura 2 a continuación presenta un resumen visual:
Figura 2: Proyecto Típico de Aprendizaje Automático en Tiempo Real. Toma en cuenta que a veces es posible que necesitemos ″regresar″ a etapas anteriores dependiendo de circunstancias imprevistas, como datos inconsistentes y la necesidad de eliminar funciones del modelo, lo que requiere un reentrenamiento. Además, algunos pasos pueden ser paralelizables.
Hay dos tipos de proyectos de Aprendizaje Automático en tiempo real: introducir un nuevo modelo y actualizar un modelo existente:
Esta distinción es útil porque actualizar un modelo existente es menos riesgoso que introducir un nuevo modelo en un flujo de negocios. Si la forma en que se utiliza el modelo es la misma, puedes omitir la etapa de validación del caso de uso—que es donde reside gran parte del riesgo.
Independientemente de si estamos introduciendo un nuevo modelo o actualizando uno existente, todas las etapas del proyecto plantean riesgos. Veamos ahora algunas de las formas en que fallan los proyectos de aprendizaje automático en tiempo real.
Descubre las oportunidades
Modos de Falla de Aprendizaje Automático en tiempo real
Como se mencionó en la introducción, existen niveles de fracaso en los proyectos de Aprendizaje Automático.
Que un proyecto fracase debido a que el rendimiento del modelo es insuficiente es algo negativo. Pero que un proyecto fracase después de invertir mucho tiempo en él es mucho, mucho peor.
Cada etapa de un proyecto de Aprendizaje Automático tiene sus vulnerabilidades únicas. Esto es especialmente cierto en el caso de proyectos en tiempo real, ya que la implementación de modelos y la integración de servicios presentan una capa adicional de complejidad. Los proyectos exitosos de aprendizaje automático en tiempo real reconocen los riesgos y los mitigan cuando es necesario.
“Todos los proyectos de ML exitosos son iguales; cada proyecto de ML fallido no tiene éxito a su manera”. – Leo Tolstoy, probably
La Tabla 1 enumera algunos de los modos de falla para proyectos de ML en tiempo real. Algunos de ellos reflejan problemas de falta de comunicación y alineación empresarial; algunos reflejan problemas de modelado y otros se relacionan con contratiempos de ingeniería e implementación. Muchos de estos también son relevantes para proyectos de ML por lotes (es decir, no en tiempo real).
Tabla 1: Lista no exhaustiva de modos de falla para proyectos de ML en tiempo real
Ahora veamos algunos pasos prácticos que tu (practicante de aprendizaje automático o gerente de proyectos) puedes seguir para abordarlos. Estos no están enumerados en ningún orden y todos han resultado útiles para nosotros en Nubank.
Eliminación de riesgos: Educar a los clientes siempre que sea posible
Riesgos abordados: Todos ellos
Muchas personas todavía ven el ML como “brujería” y tienen creencias poco realistas sobre lo que puede hacer. Puede (y debe) ayudar a los clientes a comprender, al menos en un alto nivel, cómo funciona el ML, para que puedan calibrar sus expectativas a niveles más realistas y ayudarlo a hacer su trabajo.
La gente de sectores como el bancario está más acostumbrada a trabajar con modelos, pero incluso así no es prudente suponer que entienden, ni siquiera a un alto nivel, qué es el ML.
A continuación se presentan tres puntos clave que todos los usuarios no técnicos deberían comprender sobre el aprendizaje automático:
Una buena manera de ayudar a los usuarios finales a desarrollar una intuición sobre el aprendizaje automático es mostrar gráficos de importancia de funciones, como el gráfico de enjambre de abejas (que se ve a continuación en la Figura 3). Esto genera debates interesantes con usuarios no técnicos y les ayuda a comprender cómo se calcula la puntuación de un modelo a partir de sus funciones.
Figura 3: Ejemplo de gráfico de enjambre de abejas de la biblioteca SHAP. Trabajar con gráficos de importancia de funciones es una excelente manera de ″enseñar″ a usuarios no técnicos los conceptos básicos de cómo funciona un modelo. Esto les ayuda a desarrollar su intuición sobre el aprendizaje automático y hará que la interacción sea más eficiente. El gráfico de fuerza también es útil para explicar una predicción única. Fuente
Eliminación de riesgos: Asegúrate de que los datos sean buenos.
Riesgos abordados: El rendimiento del modelo no es lo suficientemente bueno | El rendimiento del modelo en el momento de la inferencia es diferente del tiempo de entrenamiento.
El dicho “basura entra, basura sale” resume la esencia del aprendizaje automático. Es su responsabilidad asegurarse de que los datos sean lo suficientemente buenos para fines de modelado.
Es su trabajo, como practicante de ML, comprender si los datos disponibles son lo suficientemente buenos para el modelado, tanto en el momento del entrenamiento como en el de inferencia.
Como siempre, el aprendizaje automático en tiempo real agrega una dimensión adicional a este problema, por lo que no solo debe preocuparse por los datos de entrenamiento—si hay suficientes o si son de buena calidad—sino también por cómo recuperar datos en el momento de la inferencia.
Aquí sugerimos un enfoque de reducción de riesgos de tres frentes: (a) hacer las preguntas correctas sobre los datos, (b) realizar un análisis exhaustivo de los datos y (c) establecer una relación con el equipo de datos en tiempo real:
Haz las preguntas correctas sobre los datos.
Al comienzo del proyecto, desea hacer muchas preguntas sobre qué datos están disponibles y cómo se ven. Aquí hay algunas sugerencias:
Haz un análisis exhaustivo de datos
Cuando tengas acceso a los datos, debes realizar las rutinas habituales de EDA para verificar la calidad de los datos y debes verificar nuevamente toda la información que te brindaron sobre los datos para asegurarte de que no te engañen y te lleve a tomar decisiones equivocadas.
Establece una relación con el equipo de datos en tiempo real lo antes posible
Los equipos responsables de hacer que los datos estén disponibles en tiempo real a menudo no son los mismos que los responsables de los datos ″en reposo″.
Descubre quiénes son estas personas y manténte en contacto con ellas para asegurarte de que la información con la que entrenarás el modelo también estará disponible cuando necesites hacer predicciones en tiempo real. Asegúrate de comprender qué tan rápida o lenta es la recuperación de datos.
Eliminación de riesgos: Comprender cómo se utilizarán las predicciones del modelo.
Riesgos abordados: El rendimiento del modelo no es lo suficientemente bueno | El tiempo de respuesta del modelo es demasiado alto | El caso de uso no respalda la toma de decisiones probabilística.
Imagínese crear un modelo perfectamente bueno, con un gran rendimiento, sólo para verlo acumular polvo. Lo peor que le puede pasar a un proyecto de ML es producir un modelo que nunca se utilice para tomar decisiones comerciales.
Debes saber de antemano cómo se utilizarán las predicciones del modelo y quién las utilizará.
Una de las razones por las que esto sucede es que el equipo de modelado no se tomó el tiempo para comprender claramente cómo se utilizará el modelo y quién lo utilizará.
Una parte clave para comprender el uso del modelo es analizar la capa de decisión:el código o proceso de negocio que tomará las predicciones del modelo y decidirá qué acción tomar en función de las predicciones. Hablar sobre la capa de decisión obliga a los equipos de modelado y de clientes a discutir cómo se utilizarán exactamente las predicciones del modelo y a resolver cualquier malentendido en el proceso.
La Figura 4 muestra un ejemplo de cómo podría verse una capa de decisión muy simple para un modelo de riesgo crediticio simple.
Figura 4: Un sistema típico de suscripción de crédito con una capa de decisión simple. Una “capa de decisión” para un modelo puede ser tan simple como una única condición si/si no basada en la predicción del modelo. Si la puntuación de riesgo está por debajo de algún umbral, concede el préstamo; en caso contrario, niégalo.
Además de analizar la capa de decisión, cuantas más preguntas haga sobre el caso de uso del modelo, mayores serán las posibilidades de que descubra suposiciones implícitas que pueden causar problemas más adelante.
Algunas de las preguntas que debes hacerte:
Eliminación de riesgos: Realiza un pre-mortem
Riesgos abordados: Todos ellos
Una reunión post-mortem se lleva a cabo después de que un proyecto ha fracasado. Su objetivo es comprender las causas de las fallas para poder evitarlas en el futuro.
Una pre-mortem es similar, pero tiene lugar al inicio de un proyecto. Es una reunión similar a una lluvia de ideas y su objetivo no es entender por qué fracasó un proyecto, sino evitar que fracase. Funciona haciendo que la gente finja que el proyecto fracasó y les pregunte: “¿Por qué fracasó?”.
Una pre-mortem es una reunión similar a una lluvia de ideas que tiene lugar al inicio del proyecto. Intenta responder a la pregunta: “Hagamos como si el proyecto hubiera fracasado. ¿Qué hizo que fracasara?”
No hay muchas reglas sobre cómo se debe llevar a cabo la reunión, siempre y cuando se lleve a cabo.
Al final de una buena sesión pre mortem, no sólo deberías comprender mucho mejor los riesgos que ya conocías, sino también conocer los riesgos hasta ahora desconocidos que ahora puedes evaluar.
Por eso es importante que la reunión incluya a personas de diferentes orígenes, como expertos en negocios, otros profesionales de ML y, lo más importante para proyectos de ML en tiempo real, ingenieros de software, para señalar posibles problemas de integración y datos.
Eliminación de riesgos: Calcular la valoración del proyecto.
Riesgos abordados: El modelo no es económicamente viable.
Cada proyecto de ML aplicado debe tener un impacto tangible en la organización. Dicho impacto suele medirse en unidades monetarias (USD o equivalente) u otras métricas comerciales, como la conversión o el compromiso, entre otras.
Calcular la valoración de un proyecto significa comprender el impacto del proyecto en términos de estas métricas. Ayuda a reducir los riesgos del proyecto porque se puede determinar lo antes posible si el proyecto es económicamente viable y ajustar el rumbo si no lo es.
Los beneficios adicionales de calcular la valoración de un proyecto incluyen la posibilidad de clasificar cuantitativamente los proyectos y mitigar la influencia indebida de la política de poder (HiPPO).
¿Se preguntas cuándo calcular la valoración? Te sugerimos hacerlo en dos ciclos:
Eliminación de riesgos: Seleccione funciones según la importancia y el esfuerzo de implementación
Riesgos abordados: Arrastre de funciones | Las funciones elegidas no están disponibles en el momento de la inferencia
En los modelos de aprendizaje automático por lotes (es decir, no en tiempo real), las funciones son aproximadamente iguales en términos del esfuerzo necesario para implementarlas. Claro, algunos pueden requerir una consulta SQL un poco más complicada, algunas uniones adicionales, pero rara vez más que eso.
Sin embargo, las funciones en tiempo real varían enormemente en términos de cuánto esfuerzo de ingeniería requieren. Algunas funciones se pueden recuperar con una simple llamada HTTP en el momento de la inferencia. Otros pueden requerir que cree un servicio y un punto final para que el modelo pueda usarlo en el momento de la inferencia.
En proyectos de aprendizaje automático en tiempo real, debe tener en cuenta el esfuerzo de implementación al seleccionar funciones.
Durante la selección de funciones, también debes tener en cuenta el trabajo necesario para implementar una función determinada, suponiendo que esté disponible en la infraestructura en tiempo real en primer lugar. En la Figura 5 a continuación, vemos una clasificación de funciones de 4 vías según las dos dimensiones relevantes para seleccionar funciones: poder predictivo y esfuerzo de implementación.
Figura 5: No todas las funciones del aprendizaje automático en tiempo real son iguales: Además de sopesar la importancia de una función (por ejemplo, SHAP), también debemos tener en cuenta cuánto esfuerzo de ingeniería se necesita para utilizar una función determinada en el momento de la inferencia. Las funciones más rentables son aquellas que tienen un gran poder predictivo y al mismo tiempo son simples desde el punto de vista de la implementación (arriba a la izquierda).
En cuanto a cómo clasificar las funciones en términos de esfuerzo de implementación, sugerimos comenzar con las preguntas de la Tabla 2. Como de costumbre, las funciones más sencillas son las que están disponibles en una tienda de funciones (con la ventaja adicional, no necesita preocuparse por el sesgo de entrenamiento-entrega).
Tabla 2: Facilidad de implementación para funciones en tiempo real, suponiendo una arquitectura de microservicio sincrónica
Una vez que se decide un conjunto razonable de funciones, el líder del proyecto debe declarar una congelación de funciones, de modo que solo las seleccionadas se incluyan en el proyecto. Esto reduce el riesgo de que se produzcan cambios de funciones, una situación en la que se siguen añadiendo nuevas funciones al modelo y el proyecto nunca termina.
Eliminación de riesgos: Abordar primero las características de mayor riesgo
Riesgos Abordados: El rendimiento del modelo en el momento de la inferencia es diferente del tiempo de entrenamiento | Las funciones elegidas no están disponibles en el momento de la inferencia | El rendimiento del modelo no es lo suficientemente bueno
Si sigues la máxima ″selecciona funciones según el esfuerzo″, tendrá una estimación aproximada del esfuerzo de ingeniería necesario para implementar cada función. Sin embargo, se sabe que las estimaciones del esfuerzo de ingeniería son imprecisas y difíciles de acertar, algo parecido a la brujería.
Por lo general (pero no siempre), las funciones que requieren más esfuerzo también serán las más riesgosas de implementar. Por riesgosas queremos decir que pueden poner en peligro el éxito del proyecto.
Comienza la implementación con estas para abordar ese riesgo desde el principio. En otras palabras, cambiar la implementación de funciones riesgosas que quedaron en el cronograma del proyecto.
Abordar primero las partes más inciertas de un proyecto, para exponer los riesgos ocultos desde el principio, a veces se denomina estrategia de “giro a la izquierda”.
¿Por qué? Dejar estas tareas riesgosas a la izquierda le permite descubrir posibles obstáculos desde el principio: Puntos finales externos que son demasiado lentos para sus necesidades. Servicios que no pueden manejar la escala de solicitudes que se realizan. Funciones que resultaron no estar disponibles en absoluto.
Cuanto antes el equipo de modelado sea consciente de los problemas de las funciones, antes podrá adaptarse, utilizando proxies en su lugar o incluso eliminándolos por completo.
Descubrir los obstáculos más importantes al principio del proyecto ayuda a prevenir el peor modo de fallo posible: descubrir que el proyecto ha fracasado después de haberle puesto mucho esfuerzo.
Tan pronto como se hayan seleccionado las funciones, podrá comenzar a trabajar en el descubrimiento de la implementación (lluvia de ideas, diseño de estrategias de implementación, discusión con otros ingenieros, etc.). Cuanto antes mejor.
Desplazar el riesgo dejado es un buen consejo en todas las partes de cualquier proyecto, pero especialmente durante la implementación de funciones en ML en tiempo real, debido a los cambios en cascada que desencadenarán nuevas rondas de modelado y reacondicionamiento de la capa de decisión (consulte la Figura 2).
Eliminación de riesgos: Implementa el modelo en modo sombra lo antes posible
Riesgos abordados: El tiempo de respuesta del modelo es demasiado alto | El rendimiento del modelo en el momento de la inferencia es diferente del tiempo de entrenamiento | Las funciones elegidas no están disponibles en el momento de la inferencia
El tramo final de la implementación, donde se conecta el servicio de llamadas al modelo en tiempo real, es la parte más riesgosa del proyecto desde una perspectiva de ingeniería. Aparecen muchos problemas imprevistos cuando llega el momento de conectar servicios regulares a modelos de aprendizaje automático en tiempo real.
Pero no tiene por qué ser así. Al adoptar una implementación en modo sombra desde el principio, puede simular un flujo de un extremo a otro sin esperar la culminación del proyecto.
Modo sombra: implementación estándar con un toque diferente: los servicios de llamada ignoran los resultados del modelo.
La implementación en modo sombra es el nombre de un patrón de ML aplicado mediante el cual se implementa un modelo de ML en tiempo real, pero se ignora la respuesta en el último momento, por ejemplo, usando un indicador de función. Las implementaciones en modo sombra son excelentes para eliminar riesgos en los proyectos porque puede observar cómo funciona el modelo en un escenario de la ″vida real″ sin exponerse a ningún riesgo comercial. La Figura 6 proporciona una representación visual.
Figura 6: Implementación regular versus modo sombra de modelos de aprendizaje automático en tiempo real: Todo es igual excepto por el hecho de que las puntuaciones del modelo se descartan y el servicio de llamadas continúa como si nada. Una implementación en modo sombra elimina los riesgos de un proyecto porque puede detectar muchos problemas durante el tiempo de producción, como el rendimiento bajo carga, la integración con servicios de funciones, problemas de esquema, etc.
Implementar un modelo en modo sombra es útil en sí mismo. Pero hacerlo al inicio del proyecto, incluso antes de que se hayan implementado todas las funciones, es aún mejor:
La Figura 7 a continuación muestra esto: habilitar el modo sombra al inicio elimina los riesgos del proyecto y lo hace más eficiente.
Figura 7: Cuanto antes habilites el modo sombra, mejor: Implementar un nuevo modelo en modo sombra desde el principio elimina los riesgos del proyecto y lo hace más eficiente debido a las oportunidades de paralelización. Obviamente, las puntuaciones del modelo no serán útiles si la mayoría de las funciones son NULL, podrá exponer los riesgos de ingeniería lo antes posible y podrá configurar el monitoreo de inmediato.
Claro, el modo sombra puede exigir un trabajo de configuración inicial, pero cambia las reglas del juego para los proyectos de aprendizaje automático, ya que garantiza interacciones de modelo en tiempo real más fluidas y seguras.
Conclusión
La verdad es que el ML en tiempo real es difícil porque involucra modelos de ML y servicios en tiempo real; cada uno de ellos es un sistema complejo que depende de varias partes que deben funcionar perfectamente.
Enumeramos muchos de los modos de falla del ML en tiempo real, pero ten en cuenta que muchos de ellos están relacionados con el ML en general, con algunas particularidades para la configuración en tiempo real.También sugerimos varias prácticas para ayudarte a evitar esos modos de falla. Sin embargo, incluso siguiendo todos estos pasos, todavía es posible que el proyecto fracase (la vida sucede), pero las posibilidades de éxito serán mayores.
Y recuerda, todo en esta publicación está relacionado con sacar el modelo al mercado en primer lugar. Después de eso, todavía es un camino difícil mantenerlo en funcionamiento. Después de la primera implementación, necesitará un monitoreo cuidadoso (especialmente el seso de entrenamiento-entrega) y alertas para asegurar de que todo esté funcionando bien.
Descubre las oportunidades