El año pasado, Montevideo Labs participó en la feria canadiense MLOps: Conferencia mundial de producción e ingeniería, donde compartimos nuestra experiencia ayudando a las principales empresas de tecnología a crear productos de datos inteligentes. En particular, nos centramos en las dificultades más comunes que pueden surgir cuando las empresas comienzan a plantearse la posibilidad de producir productos de datos basados en la inteligencia artificial.
¿Qué es un producto de datos inteligentes? Para empezar, es un producto. Debe cumplir un propósito para los usuarios y debe tener altos estándares de calidad. Suponemos que está creando un sistema que toma decisiones basadas en datos que aprovechan el aprendizaje automático. Se trata, en esencia, de un producto de datos inteligente para nosotros. Echemos un vistazo a algunos errores sencillos que hemos presenciado en el pasado al crear este tipo de productos, especialmente cuando partimos de un prototipo. Permítanme decir primero que muchos de ellos pueden parecer obvios, pero estoy seguro de que muchos lectores han experimentado al menos uno de estos problemas.
A menudo, un científico de datos presenta una nueva estrategia a través de un cuaderno o una presentación a un grupo de personas sobre cómo un modelo o método de datos en particular puede ayudar a la empresa de alguna manera. Podría hacer mejores previsiones, impedir que los usuarios abandonen la empresa, elegir el precio correcto, etc. Sean cuales sean esas decisiones, normalmente comienzan con un prototipo y utilizan algunos conjuntos de datos para validar la metodología. Cuando creamos un producto, debemos adaptarnos al «cambio variable». Debemos cuestionar las suposiciones que son ciertas en el momento de diseñar la metodología. Es común llevar esos algoritmos a la producción a ciegas y nos olvidamos de las suposiciones subyacentes que hicieron que el modelo de datos fuera válido o útil para su uso en este caso.
Por lo general, los ingenieros se centran en la estabilidad del sistema, en el uso de patrones de diseño para garantizar que los módulos sean comprobables, cohesivos y desacoplados. Los ingenieros están interesados en el rendimiento desde el punto de vista de la baja latencia, el alto rendimiento, la ausencia de problemas de concurrencia y el hecho de que la nube o la infraestructura se utilizan de la manera más eficiente. Por otro lado, los científicos de datos se centran más en la experimentación iterativa y en la creación de prototipos exitosos. Si estos prototipos son buenos, normalmente es un resultado muy bueno para los científicos de datos. Están interesados en el rendimiento, pero principalmente desde el punto de vista de la precisión de los modelos o los KPI empresariales. Muchas veces, algunos de estos objetivos entran en conflicto. Por ejemplo, es difícil realizar iteraciones rápidas en la producción para una prueba A/B si necesitamos asegurarnos de que los modelos que se utilizan son realmente seguros para subprocesos, no tienen pérdidas de memoria, no provocan problemas de recolección de basura, etc. Al mismo tiempo, es probable que los modelos que funcionan mejor en términos de precisión requieran una gran cantidad de memoria y sean propensos a crear otros problemas de rendimiento (por lo general, latencia).
Lo mejor para nosotros es tener equipos en los que colaboren ingenieros y científicos de datos. Si ambos perfiles sienten que son fruto de la colaboración, la realización y la propiedad, lo más probable es que creéis productos excepcionales, ya que habéis trabajado juntos para explorar todas las ventajas y desventajas que tienen sentido para la empresa. Es fácil echar la culpa cuando la cultura no es la adecuada. Cuando ocurre un problema, los científicos de datos pueden decir que el modelo funcionó perfectamente con los datos, los ingenieros dirán que las cosas podrían haber funcionado en un experimento, pero los datos reales muestran lo contrario. El espíritu de equipo es clave. Y es posible.
Necesitamos métricas en nuestras aplicaciones para garantizar que nuestros modelos sigan comportándose de la manera correcta. Muchas veces nos hacemos la ilusión de que nuestros modelos se comportan de la manera que pretendíamos. Sin embargo, es posible que estemos viendo una métrica incorrecta. Las buenas métricas tienen que ver con los KPI empresariales y son sensibles a los aspectos más relevantes en los que el modelo puede fallar.
Es posible que nos sintamos tentados a utilizar métricas que los científicos de datos comprendamos muy bien, como el AUC ROC, la precisión, el recuerdo, etc. Sin embargo, en última instancia, queremos que nuestros modelos mejoren la experiencia del usuario. Unas mejores métricas en tiempo real pueden demostrar que estamos haciendo lo correcto y que estamos tomando las decisiones finales correctas. Las métricas de las pruebas A/B son muy útiles porque demuestran que nuestro aprendizaje automático funciona mejor que una estrategia alternativa bien entendida. La UAT también es importante, ya que ayuda a descubrir los aspectos poco intuitivos o confusos de nuestros productos de datos.
En el pasado, nos hemos enfrentado a una serie de problemas con modelos muy buenos que no funcionan bien cuando forman parte de una interfaz de usuario, por ejemplo, un modelo de predicción de ventas que muestra una caída de las ventas al expandirse a una región más grande, puede ser preciso según los datos de las pruebas (y posiblemente ruidosos), pero puede ser incorrecto o, al menos, poco intuitivo para el usuario. Agregar una prueba unitaria que verifique un comportamiento isotónico podría ayudar a detectar este problema y también a prevenir regresiones.
Los modelos que construimos se basan en datos. Los datos son el resultado de varias transformaciones iniciales y trabajos de ETL. Estas transformaciones suelen sufrir modificaciones y mejoras constantes. Debemos asegurarnos de que todas esas modificaciones iniciales no afecten a las suposiciones presentes en nuestros trabajos de formación. Tenemos que asegurarnos de que, a medida que haya nuevos datos disponibles, los nuevos modelos puedan aprovechar esos nuevos datos y hacerlo sin interrumpir el sistema en producción. Por este motivo, es necesario versionar y desacoplar los conjuntos de datos o los flujos de datos para que nuestro modelo pueda leer los datos que tengan el conjunto correcto de suposiciones. Podemos aumentar los datos por separado, modificarlos en consecuencia y, más adelante, implementar nuevos modelos que aprovechen estos nuevos datos. Mientras tanto, los modelos que utilizan la versión de datos anterior pueden seguir funcionando sin verse afectados.
Imagine que el científico de datos trabaja en un cuaderno y, a través de ese cuaderno, envía el modelo a producción. Es muy ágil y muchas veces funciona. Sin embargo, hemos roto de manera efectiva la cadena de integración y desarrollo continuos. Hay una razón por la que tenemos pruebas de integración. Hay una razón por la que invertimos en toda esta infraestructura. Se trata de calidad. Nuestro código debe ser fiable y conocer los efectos de los artefactos basados en la ciencia de datos a un nivel holístico.
Los ingenieros y científicos de datos invierten mucho tiempo en solucionar problemas cuando las cosas van mal. Esto significa que cualquier inversión inicial que pudiéramos hacer en este sentido sin duda se traduciría en una mejora general de la productividad. Si bien no siempre es posible tener un sistema grande y complejo funcionando en un portátil, a menudo resulta muy útil desacoplar los módulos de la manera correcta y lograr algún tipo de integración de extremo a extremo. Incluso si el sistema funciona a una escala muy reducida, puede ayudar a validar los problemas de fontanería y arrojar luz sobre las incoherencias.
Si los módulos están bien diseñados, cualquier cambio de comportamiento determinado por el entorno en el que se ejecuta debe parametrizarse. De lo contrario, resulta muy difícil garantizar que nuestros productos puedan funcionar en nuestros ordenadores portátiles, entornos de ensayo y producción. Además, los buenos productos de software incluyen ganchos y botones de configuración que permiten a los investigadores probar nuevas ideas en producción e inyectar modelos pequeños, como las pruebas A/B, con un riesgo mucho menor.
Este escollo puede parecer obvio, pero ha ocurrido. Debemos tener cuidado al ejecutar las pruebas A/B. Tenemos que asegurarnos de no limitarnos a analizar a los usuarios y hacer que un grupo determinado de usuarios sean siempre los conejillos de indias y, por lo tanto, los usuarios insatisfechos. Además, debemos tener cuidado de no abusar de la ejecución de demasiados experimentos superpuestos y sacar conclusiones incorrectas debido al efecto de un experimento sobre el otro.
A veces nos entusiasman tanto los posibles beneficios de la IA o el aprendizaje automático en relación con un problema y nuestra confianza es tan fuerte que simplemente empezamos a diseñar el producto de inmediato sin hacer primero un prototipo y validamos que el método funciona. A veces esto puede estar bien, pero normalmente aprendemos mucho de los prototipos. Aprendemos las incógnitas, las cosas en las que no habíamos pensado antes.
Los ingenieros suelen necesitar aplicar ingeniería inversa a los requisitos de los modelos de ciencia de datos de los ordenadores portátiles. De forma intencionada, los prototipos pueden omitir algunos detalles, que no son importantes para una prueba de concepto, pero que pueden ser muy relevantes cuando el producto se lanza al mercado. Lo ideal es que la especificación refleje los principales algoritmos, fundamentos y principios de la metodología.
Esperamos que los problemas anteriores generen las conversaciones correctas al intentar por primera vez producir productos de datos basados en el aprendizaje automático. Si necesita ayuda para producir el aprendizaje automático, siempre puede ponerse en contacto con nosotros en mlabs-info@bled360.com!
Para obtener más información sobre lo que hacemos en Montevideo Labs, visite nuestro sitio web: www.blend360.com.
El año pasado, Montevideo Labs participó en la feria canadiense MLOps: Conferencia mundial de producción e ingeniería, donde compartimos nuestra experiencia ayudando a las principales empresas de tecnología a crear productos de datos inteligentes. En particular, nos centramos en las dificultades más comunes que pueden surgir cuando las empresas comienzan a plantearse la posibilidad de producir productos de datos basados en la inteligencia artificial.
¿Qué es un producto de datos inteligentes? Para empezar, es un producto. Debe cumplir un propósito para los usuarios y debe tener altos estándares de calidad. Suponemos que está creando un sistema que toma decisiones basadas en datos que aprovechan el aprendizaje automático. Se trata, en esencia, de un producto de datos inteligente para nosotros. Echemos un vistazo a algunos errores sencillos que hemos presenciado en el pasado al crear este tipo de productos, especialmente cuando partimos de un prototipo. Permítanme decir primero que muchos de ellos pueden parecer obvios, pero estoy seguro de que muchos lectores han experimentado al menos uno de estos problemas.
A menudo, un científico de datos presenta una nueva estrategia a través de un cuaderno o una presentación a un grupo de personas sobre cómo un modelo o método de datos en particular puede ayudar a la empresa de alguna manera. Podría hacer mejores previsiones, impedir que los usuarios abandonen la empresa, elegir el precio correcto, etc. Sean cuales sean esas decisiones, normalmente comienzan con un prototipo y utilizan algunos conjuntos de datos para validar la metodología. Cuando creamos un producto, debemos adaptarnos al «cambio variable». Debemos cuestionar las suposiciones que son ciertas en el momento de diseñar la metodología. Es común llevar esos algoritmos a la producción a ciegas y nos olvidamos de las suposiciones subyacentes que hicieron que el modelo de datos fuera válido o útil para su uso en este caso.
Por lo general, los ingenieros se centran en la estabilidad del sistema, en el uso de patrones de diseño para garantizar que los módulos sean comprobables, cohesivos y desacoplados. Los ingenieros están interesados en el rendimiento desde el punto de vista de la baja latencia, el alto rendimiento, la ausencia de problemas de concurrencia y el hecho de que la nube o la infraestructura se utilizan de la manera más eficiente. Por otro lado, los científicos de datos se centran más en la experimentación iterativa y en la creación de prototipos exitosos. Si estos prototipos son buenos, normalmente es un resultado muy bueno para los científicos de datos. Están interesados en el rendimiento, pero principalmente desde el punto de vista de la precisión de los modelos o los KPI empresariales. Muchas veces, algunos de estos objetivos entran en conflicto. Por ejemplo, es difícil realizar iteraciones rápidas en la producción para una prueba A/B si necesitamos asegurarnos de que los modelos que se utilizan son realmente seguros para subprocesos, no tienen pérdidas de memoria, no provocan problemas de recolección de basura, etc. Al mismo tiempo, es probable que los modelos que funcionan mejor en términos de precisión requieran una gran cantidad de memoria y sean propensos a crear otros problemas de rendimiento (por lo general, latencia).
Lo mejor para nosotros es tener equipos en los que colaboren ingenieros y científicos de datos. Si ambos perfiles sienten que son fruto de la colaboración, la realización y la propiedad, lo más probable es que creéis productos excepcionales, ya que habéis trabajado juntos para explorar todas las ventajas y desventajas que tienen sentido para la empresa. Es fácil echar la culpa cuando la cultura no es la adecuada. Cuando ocurre un problema, los científicos de datos pueden decir que el modelo funcionó perfectamente con los datos, los ingenieros dirán que las cosas podrían haber funcionado en un experimento, pero los datos reales muestran lo contrario. El espíritu de equipo es clave. Y es posible.
Necesitamos métricas en nuestras aplicaciones para garantizar que nuestros modelos sigan comportándose de la manera correcta. Muchas veces nos hacemos la ilusión de que nuestros modelos se comportan de la manera que pretendíamos. Sin embargo, es posible que estemos viendo una métrica incorrecta. Las buenas métricas tienen que ver con los KPI empresariales y son sensibles a los aspectos más relevantes en los que el modelo puede fallar.
Es posible que nos sintamos tentados a utilizar métricas que los científicos de datos comprendamos muy bien, como el AUC ROC, la precisión, el recuerdo, etc. Sin embargo, en última instancia, queremos que nuestros modelos mejoren la experiencia del usuario. Unas mejores métricas en tiempo real pueden demostrar que estamos haciendo lo correcto y que estamos tomando las decisiones finales correctas. Las métricas de las pruebas A/B son muy útiles porque demuestran que nuestro aprendizaje automático funciona mejor que una estrategia alternativa bien entendida. La UAT también es importante, ya que ayuda a descubrir los aspectos poco intuitivos o confusos de nuestros productos de datos.
En el pasado, nos hemos enfrentado a una serie de problemas con modelos muy buenos que no funcionan bien cuando forman parte de una interfaz de usuario, por ejemplo, un modelo de predicción de ventas que muestra una caída de las ventas al expandirse a una región más grande, puede ser preciso según los datos de las pruebas (y posiblemente ruidosos), pero puede ser incorrecto o, al menos, poco intuitivo para el usuario. Agregar una prueba unitaria que verifique un comportamiento isotónico podría ayudar a detectar este problema y también a prevenir regresiones.
Los modelos que construimos se basan en datos. Los datos son el resultado de varias transformaciones iniciales y trabajos de ETL. Estas transformaciones suelen sufrir modificaciones y mejoras constantes. Debemos asegurarnos de que todas esas modificaciones iniciales no afecten a las suposiciones presentes en nuestros trabajos de formación. Tenemos que asegurarnos de que, a medida que haya nuevos datos disponibles, los nuevos modelos puedan aprovechar esos nuevos datos y hacerlo sin interrumpir el sistema en producción. Por este motivo, es necesario versionar y desacoplar los conjuntos de datos o los flujos de datos para que nuestro modelo pueda leer los datos que tengan el conjunto correcto de suposiciones. Podemos aumentar los datos por separado, modificarlos en consecuencia y, más adelante, implementar nuevos modelos que aprovechen estos nuevos datos. Mientras tanto, los modelos que utilizan la versión de datos anterior pueden seguir funcionando sin verse afectados.
Imagine que el científico de datos trabaja en un cuaderno y, a través de ese cuaderno, envía el modelo a producción. Es muy ágil y muchas veces funciona. Sin embargo, hemos roto de manera efectiva la cadena de integración y desarrollo continuos. Hay una razón por la que tenemos pruebas de integración. Hay una razón por la que invertimos en toda esta infraestructura. Se trata de calidad. Nuestro código debe ser fiable y conocer los efectos de los artefactos basados en la ciencia de datos a un nivel holístico.
Los ingenieros y científicos de datos invierten mucho tiempo en solucionar problemas cuando las cosas van mal. Esto significa que cualquier inversión inicial que pudiéramos hacer en este sentido sin duda se traduciría en una mejora general de la productividad. Si bien no siempre es posible tener un sistema grande y complejo funcionando en un portátil, a menudo resulta muy útil desacoplar los módulos de la manera correcta y lograr algún tipo de integración de extremo a extremo. Incluso si el sistema funciona a una escala muy reducida, puede ayudar a validar los problemas de fontanería y arrojar luz sobre las incoherencias.
Si los módulos están bien diseñados, cualquier cambio de comportamiento determinado por el entorno en el que se ejecuta debe parametrizarse. De lo contrario, resulta muy difícil garantizar que nuestros productos puedan funcionar en nuestros ordenadores portátiles, entornos de ensayo y producción. Además, los buenos productos de software incluyen ganchos y botones de configuración que permiten a los investigadores probar nuevas ideas en producción e inyectar modelos pequeños, como las pruebas A/B, con un riesgo mucho menor.
Este escollo puede parecer obvio, pero ha ocurrido. Debemos tener cuidado al ejecutar las pruebas A/B. Tenemos que asegurarnos de no limitarnos a analizar a los usuarios y hacer que un grupo determinado de usuarios sean siempre los conejillos de indias y, por lo tanto, los usuarios insatisfechos. Además, debemos tener cuidado de no abusar de la ejecución de demasiados experimentos superpuestos y sacar conclusiones incorrectas debido al efecto de un experimento sobre el otro.
A veces nos entusiasman tanto los posibles beneficios de la IA o el aprendizaje automático en relación con un problema y nuestra confianza es tan fuerte que simplemente empezamos a diseñar el producto de inmediato sin hacer primero un prototipo y validamos que el método funciona. A veces esto puede estar bien, pero normalmente aprendemos mucho de los prototipos. Aprendemos las incógnitas, las cosas en las que no habíamos pensado antes.
Los ingenieros suelen necesitar aplicar ingeniería inversa a los requisitos de los modelos de ciencia de datos de los ordenadores portátiles. De forma intencionada, los prototipos pueden omitir algunos detalles, que no son importantes para una prueba de concepto, pero que pueden ser muy relevantes cuando el producto se lanza al mercado. Lo ideal es que la especificación refleje los principales algoritmos, fundamentos y principios de la metodología.
Esperamos que los problemas anteriores generen las conversaciones correctas al intentar por primera vez producir productos de datos basados en el aprendizaje automático. Si necesita ayuda para producir el aprendizaje automático, siempre puede ponerse en contacto con nosotros en mlabs-info@bled360.com!
Para obtener más información sobre lo que hacemos en Montevideo Labs, visite nuestro sitio web: www.blend360.com.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
.jpeg)
