Categories
54cuatro

Porque fallan los proyectos de Inteligencia Artificial

Una tecnología disruptiva o una innovación disruptiva es una innovación que ayuda a crear un nuevo mercado y una nueva red de valor y, finalmente, continúa alterando una red de mercado y valor existente.

¿Porque fallan los proyectos?

En la actualidad 1 de cada 10 proyectos relacionados con #IA logra tener éxito. El éxito no esta medido por el cumplimiento de las implementaciones, sino por el valor que se logra de cara al negocio.

Las fallas en este tipo de proyectos (en nuestra experiencia) vienen dados por 2 puntos:

  1. Falta de colaboración entre las áreas para lograr una solución que aporta valor.
  2. No tener los datos adecuados.

¿Cómo mitigar los riesgos?

En #54cuatro tenemos una #metodología que permite a nuestros clientes ir logrando un nivel de madurez que asegure el éxito de los proyectos de #InteligenciaArtificial.

Esa metodología denominada #Metolodogia54, busca lograr convertir a los clientes hacia empresas #DataDriven, afectando sus capacidades en cuanto a factores Culturales, Procesos y Tecnología en pos de asegurar la creación de sinergias entre los grupos de trabajo y obtener (o crear) los datos adecuados.

Tendencias en boga como #MLOPS son buenas alternativas para optimizar proyectos de #MachineLearning y aproximarse con mayor seguridad al éxito buscado, pero además es importante que todas las personas de la organización estén comprometidas a buscar el éxito, dado que los proyectos IA son 100% colaborativos es fundamental considerar los datos que se tienen disponibles y los conocimientos que se pueden obtener de ellos pero es aun mas necesario considerar el nivel de apoyo de la gerencia u organización en general y finalmente establecer expectativas realistas en torno a lo que la #IA ayudará a resolver.

Medición de resultados

Con las expectativas marcadas como hito a cumplir, es necesario generar una adecuada medición de resultados. El personal técnico suele medir el resultado de un modelo de datos por como “performa” ese modelo (Precision, Recall, F1, etc). Ese es un grave error que genera desconfianza en lo que se esta realizando. En su lugar, es preferible establecer hitos de éxito medibles en los términos más importantes para la empresa, como eficiencia operativa, aumento de ventas o de ahorro de costos. 

Algunas otras veces, se espera un nivel mínimo de resultados de cada modelo, sin embargo es bueno participar a gente de áreas de negocio mientras se realizan los desarrollos para que puedan probar y comparar el rendimiento, realizar sugerencias y complementar el modelo con las fortalezas (y debilidades) de los expertos ‘humanos’.

En modelos predictivos, crear un ciclo de retroalimentación permite mejorar el reentrenamiento para que su modelo pueda incorporar rápidamente nuevos puntos de datos y dar como resultado un aumento y mejora de las predicciones futuras.

Conclusión

Los proyectos basados en tecnología disruptiva generan grandes expectativas pero para poder cumplir con lo que se espera, es necesario comprometer a la organización en pos de lograr buenas fuentes de datos y poder trabajar con los científicos de datos a medida que se generan soluciones de negocio, retroalimentando los desarrollos con experiencia de las personas.


    Please prove you are human by selecting the star.

    Categories
    54cuatro

    MLOPS en Español: ¿que son las Feature Stores?

    Seguimos incrementando la informacion acerca de #MLOPS. En un primer post presentamos el concepto, y en un segundo post hablamos de PCS una metodología MLOPS made in Berkeley.

    Este post esta dedicado a Cristian Cascon, un amigo de la casa, ingeniero de datos de Telecom Argentina y referente de la industria, quien nos alentó a escribir sobre los feature stores.

    Gonzalo D’Angelo

    MLOps es un derivado de DevOps implementado la idea de DevOps por medio de pipelines de aprendizaje automático. Ahora vamos a analizar un tema importante al momento de disponibilizar los datos a nuestros científicos de datos, los Features Stores.

    ¿Que son los Feature Stores?

    Un feature store es nuestro “datawarehouse” de características, nuestra unidad central de almacenamiento de funciones documentadas, seleccionadas y con control de acceso que se pueden usar en muchos modelos diferentes, es decir, una biblioteca de software que contiene muchas funciones.

    Un #FeatureStore es un componente crítico para cualquier proceso de aprendizaje automático, y donde mejores features significan mejores modelos y por tanto un mejor resultado comercial. A un FS se le ingestan datos de múltiples fuentes diferentes de la empresa con procesos de transformación, agregación y validación de datos.

    Todo proyecto de ciencia de datos comienza con la búsqueda de las funciones adecuadas que resuelvan el requerimiento planteado.

    El problema principalmente es que no existe un lugar único para buscar; las funciones están alojadas en todas partes, eso lleva a que generar características requiera de un gran esfuerzo, y un largo proceso de prueba y error.

    Entonces, podemos decir que un FS proporciona un solo panel donde compartir todas las características disponibles, y no es solo una capa de datos, también es un servicio de transformación de datos que permite a los usuarios manipular datos sin procesar.

    Gracias a un FS, el pipeline de Machine Learning o #MLOPS va a simplificarse y permitirá que un #datascientist optimice sus tiempos y realice trabajos de mayor calidad.

    Cuando un científico de datos inicia un nuevo proyecto, puede ir a este catálogo y encontrar fácilmente las características que busca.

    El almacén de características se implementa normalmente de 2 modos: online y offline

    Funciones sin conexión: algunas funciones se calculan como parte de un trabajo por lotes. Por ejemplo, un caso de uso seria el análisis de gastos promedios. Se utilizan principalmente en procesos tipo batch. Dada su naturaleza, la creación de este tipo de funciones puede llevar tiempo. Por lo general, las características sin conexión se calculan a través de marcos como Spark o simplemente ejecutando consultas SQL en una base de datos determinada y luego utilizando un proceso de inferencia por lotes.

    Funciones en línea: estas funciones son un poco más complicadas, ya que deben calcularse near-realtime y, a menudo, se ofrecen en una latencia de milisegundos. Por ejemplo, la detección de fraudes en tiempo real. En este caso, la tubería se construye calculando la media y la desviación estándar sobre una ventana deslizante en tiempo real. Estos cálculos son mucho más desafiantes y requieren un cálculo rápido, así como un acceso rápido a los datos. Los datos se pueden almacenar en memoria o en una base de datos de valores clave.

    Esta imagen es excelente para diferencias ambos modos:

    Imagen tomada de logicalclocks.com

    Los científicos de datos están duplicando el trabajo porque no tienen una tienda de funciones centralizada. Todos con los que hablo realmente quieren construir o incluso comprar una tienda de características … si una organización tiene una tienda de características, el período de puesta en marcha [para los científicos de datos puede ser mucho más rápido].

    Harish Dodi

    Resumen

    Los científicos de datos son uno de los principales usuarios de la Feature Stores. Usan un repositorio para realizar análisis de datos exploratorios.

    Cuando los científicos de datos necesitan crear datos de entrenamiento o prueba con Python o cuando se necesitan características en línea (para entregar características a modelos en línea) con baja latencia, necesita una tienda de características. Del mismo modo, si desea detectar la derivación de features o datos, necesita soporte para calcular estadísticas de features e identificar la derivación.

    Un Feature Store permite a los profesionales de datos de su empresa seguir un mismo flujo de trabajo en cualquier proyecto de #MachineLearning, independientemente de los desafíos que estén abordando (como clasificación y regresión, pronóstico de series de tiempo, etc.). 

    Otro beneficio es el ahorro de tiempo que genera ya que reduce el esfuerzo en el modelado donde se crean features, etapa que suele ser la mas costosa en tiempo.

    El uso de un Feature Store hace que el proceso de creación de características sea mucho más ágil y eficiente, evitando trabajos repetitivos y siendo posible acceder fácilmente a una gran cantidad de datos que se necesitan para fines de modelado e investigación.


    [popup_anything id=”2076″]
    Categories
    54cuatro

    ¿Y ahora MLOPS?

    Quienes nos siguen dirán, ¿Otro nuevo Ops en familia? Y si, tenemos que contarles sobre #MLOPS.

    Repasemos. #DevOps conjuga la unión de los equipos de Desarrollo con Operaciones. #DataOps va acerca de la integración de datos en pos de soluciones analíticas. #GitOps nos ayuda a con el despliegue continuo sobre plataformas de contenedores. Y ahora nos toca describir MLOPS.

    ¿Que es MLOPS?

    El nombre viene de la conjugación de Machine Learning y Operaciones. Y su filosofía gira en torno a lo mismo que sus familiares *Ops, la de generar un espacio colaborativo, en este caso entre Científicos de Datos y Operaciones. Es importante destacar que hace un tiempo se puso de moda el termino #AIOPS, pero esta mas orientado a una implementación de Inteligencia Artificial a las operaciones de TI, de manera que podria ser confundible con MLOPS.

    Empecemos a descubrir MLOPS.

    MLOps Principles

    ¿Que soluciona MLOPS?

    MLOps es un descendiente directo de DevOps, y continuando con el éxito busca resolver la integración de los equipos de operaciones (en este caso quienes operan los datos) con aquellos que requieren de esa data para generar informacion de valor.

    MLOps incorpora al juego a los científicos de datos, quienes requieren obtener conjuntos de datos de manera automatizada desde donde poder desarrollar sus modelos analíticos.

    ¿MLOPS requiere de un Pipeline?

    Correcto, MLOPS tiene su propio concepto de Pipeline, solo que el CI/CD, esta orientado a integraciones de datos, y junto con ello, capacidades de gobernanza, transparencia y protección de la informacion.

    • En CI ademas de probar y validar código y componentes, se deben validar datos, esquemas y modelos.
    • En CD ademas de desplegar un paquete, debe implementar todo un servicio de manera automática.

    En resumidas fases podriamos mencionar que MLOPS requiere de 4 pasos fundamentales:

    • Ingestar datos hacia un almacenamiento.
    • Procesar los datos almacenados.
    • Entregar esos datos para ser entrenados dentro de modelos de #MachineLearning.
    • Entregar el output del modelo, dependiendo el caso de negocio requerido.
    Gartner on ML pipeline
    Esquema MLOPS propuesto por Gartner

    ¿Como comienzo mi camino hacia MLOPS?

    Es importante destacar que la comunidad que impulsa MLOPS crece dia a dia. Y ese crecimiento lleva a tener mas opciones que simplifican la adopción de MLOPS. Tanto #AWS, #GCP, #Azure, #IBM y otros proveedores tienen su propio stack tecnológico para hacer frente a una implementación de MLOPS, y como todo, no existe un método único, pero si buenas practicas recomendadas a seguir.

    Para empezar, debemos crear una cultura de automatización.

    El objetivo de MLOps es automatizar los pasos completos del flujo de trabajo de ML sin intervención manual. A partir de ello debemos dividir las tareas en fases que al final de la historia se ejecuten como un pipeline. Estas tareas son:

    1. Adquirir los datos desde las fuentes que identifiquemos. Y dentro de esta fase de adquisición vamos a Catalogar los Datos, Ingestarlos a nuestro almacenamiento, Procesarlos para generar nuestra data correcta, y finalmente Entregarlos para su consumo.
    2. Desarrollar los modelos. En esta fase (quizás la mas importante) un científico de datos generara interacciones con distintos modelos analíticos, validando la data recibida, e identificando la performance de los análisis. En caso de que la data recibida no sea suficiente o de la calidad esperada, el pipeline debe ser reajustado en el paso 1. Pero si los modelos tienen buenos rendimientos se pasara a la siguiente fase.
    3. Despliegue de los modelos. Como mencionamos anteriormente, si un modelo tiene buenos rendimientos y sus outputs son confiables, esta listo para ser pasado a producción. Tener un modelo productivo permite integrarlo a nuestro software, dejar una API para consultas, alimentar un sistema, etc. Pero atención, el modelo requiere de cuidados, y es por eso que existe una ultima etapa.
    4. Monitoreo de modelos. Como vamos a tener corriendo todo de forma automatizada, es importante monitorear como es la performance de los modelos. Cualquier desvio en la cantidad y/o calidad de los datos que se reciben pueden alterar el funcionamiento de nuestro desarrollo. Y es por eso que en un modelo MLOPS, vamos a determinar un control para conseguir que nuestro pipeline siempre asegura la entrega de información de valor para el negocio.

    Conclusión final

    Para ejecutar un proyecto exitoso basado en ciencia de datos es imprescindible implementar MLOps y para ello se debe llevar a cabo una orquestación de las herramientas tecnológicas con las habilidades para integrarlas.

    Consultas?

    [popup_anything id=”2076″]
    Categories
    54cuatro

    DevOps, DataOps… ¿Y ahora? GitOps

    Ya hemos hablado de DevOps, de DataOps, y con el correr del tiempo se incorporan nuevos *Ops.

    Mas adelante vamos a escribir de #MLOps, pero ahora vamos a ver de que se trata #GitOps.

    ¿De donde sale GitOps?

    Weaveworks on Twitter: "Great article on #GitOps by @wbiller: "GitOps –  Continuous Deployment für Kubernetes". #CICD #kubernetes #k8s  https://t.co/nUi05zj9DR… https://t.co/PH2fn1qZmc"

    GitOps surge principalmente de la necesidad de administración de clústeres de Kubernetes y la entrega de aplicaciones. Para esto es necesario usar #Git, la herramienta numero 1 de #desarrollo. GitOps, se basada en usar Git como única fuente de verdad para aplicaciones e infraestructura declarativa, de esta manera, las herramientas de #GitOps como #ArgoCD (la cual pueden ver como funciona en este post) puede alertar sobre cualquier diferencia existente entre Git y lo que está configurado en K8s, y si hay una diferencia, los reconciliadores de Kubernetes actualizan o revierten automáticamente la configuración. El objetivo por cierto es acelerar y simplificar las implementaciones de aplicaciones como las tareas de operaciones en Kubernetes.

    ¿GitOps es un reemplazo de DevOps?

    Nos suelen hacer esta pregunta cuando hablamos de DevOps. Y la respuesta es: NO!

    DevOps es una practica que tiene en cuenta factores culturales, de procesos y de tecnología. En DevOps, la cultura es parte fundamental para asegurarse de que las personas se alineen y trabajen de forma fluida. Pero GitOps incluye aquellas mejores prácticas que unifican la implementación, la gestión y la supervisión de aplicaciones, y la administración de clústeres de #containers.

    GitOps por tanto, es un complemento de DevOps, con mayor orientación al desarrollo Cloud Native, Container First, o Serverless.

    Además del repositorio de codigo, GitOps hace uso de herramientas de IaC (infrastructure as code) con el fin de administrar los despliegues de infraestructura con un control de versionado de la misma. Herramientas como #Puppet, #Ansible o #Terraform, permiten desplegar servidores y orquestar su implementación, pero el crecimiento exponencial del uso de contenedores junto al despliegue de las aplicaciones que corren sobre ellos potenció la necesidad de contar con herramientas que además de la infra puedan orquestar el despliegue aplicativo.

    De esta manera, “recetas” de despliegue de infraestructura pueden ser respaldadas en Git para que sus archivos de configuración puedan ser “mergeados” con flujos de trabajo GitOps. Esto genera una super receta que al ejecutarse permitirá desplegar un servidor junto con su aplicación, con un control exacto de versiones.

    ¿Cuál son sus beneficios?

    • El principal es el de simplificar las administraciones de las implementaciones. La configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).
    • Existe un control de versiones tanto de la infra como de las apps. Cualquier desviación de la configuración de versión es detectada y corregida de inmediato.
    • Todos los despliegues permiten una rápida vuelta atrás, además de dejar un registro de auditoria de sus ejecuciones.
    • Las implementaciones de aplicaciones son rápidas y confiables.

    [popup_anything id=”2076″]