TecNoticias, tu portal de información

Una inmersión profunda para comprender cómo las plataformas sin código ayudan a facilitar la adopción acelerada de ML

Foto de Scott Graham en Unsplash En los últimos años, hemos visto varias plataformas de ciencia de datos y ML sin código lanzadas por varias grandes empresas y nuevas empresas prósperas. Hoy en día, la mayoría de los proveedores líderes en la nube tienen al menos una oferta bajo plataformas ML sin código/de código bajo. Azure ML Studio de Microsoft, Sagemaker Canvas de Amazon y AutoML de Google son algunos para mencionar. Si los analiza más a fondo, la misión subyacente es común, es decir, democratizar AI/ML/DS. Durante mucho tiempo, creí firmemente que el código bajo/sin código no sería una forma eficaz de democratizar el aprendizaje automático. Sin embargo, más recientemente, tuve un cambio de opinión; la razón probablemente no sea lo que adivinaste. Me explico. En 2015, cuando exploré el estudio Azure ML, quedé realmente impresionado. La plataforma en ese momento era madura y ofrecía funciones ricas para resolver problemas de ML. Todo el viaje de incorporación de datos, análisis exploratorio de datos, creación de modelos, ajuste de hiperparámetros e implementación se puede lograr mediante herramientas de arrastrar y soltar. Esta fue una de las primeras herramientas que utilicé dentro de esta categoría y sentí una sensación de plenitud. La herramienta me permitió lograr el objetivo que probé en ese momento: implementar un modelo en producción sin una sola línea de código (aunque un modelo pequeño para pruebas). Luego, a fines de 2016, estaba convencido de que existe un gran mercado para esta categoría de servicios y que las herramientas sin código pronto tendrían una adopción masiva para los problemas de ML. Sin embargo, con el paso de los años, apenas noté la adopción de estas herramientas dentro la comunidad con la que me comprometí principalmente. Algunas de estas herramientas eran realmente sofisticadas con excelentes demostraciones, pero en la mayoría de los casos, tenía poco sentido para mí. Lentamente, comencé a inclinarme hacia la idea de que estas herramientas eran superfluas para democratizar la IA. Mis razones eran simples; Los casos de uso serios de ML que importaban para el negocio y que finalmente se implementaron en producción nunca fueron adecuados para construirse con herramientas que bloquearon el control a favor de una herramienta basada en la interfaz de usuario. Además, la ingeniería de datos y la disputa de datos para casos de uso serios de ML fueron una parte gigantesca del esfuerzo. El gran volumen y la complejidad de la ingeniería nunca podrían ser adecuados para una herramienta sin código demasiado simplificada. Para mí, las plataformas sin código/de código bajo de repente se convirtieron en una herramienta gloriosa que solo cumple el propósito de un gran marketing. Recientemente, comencé a ver estas herramientas desde una perspectiva diferente. Pensé que tal vez estaba sesgado en mi opinión. Era bastante probable, ya que interactué principalmente con científicos de datos que ya se sentían cómodos con alguna forma de codificación o eran profesionales experimentados en el campo. Además, trabajé principalmente en un entorno en el que trabajábamos muy de cerca con ingenieros de software que ayudaron a traducir los prototipos de investigación en líneas de producción. Por lo tanto, era clave para nosotros establecer una práctica de flujo de trabajo de investigación que garantizara que se minimizaran los esfuerzos de traducción entre prototipos de investigación y artefactos de producción. Por lo tanto, en su mayoría optamos por ecosistemas Pythonic compatibles con herramientas de big data en plataformas de nube establecidas. Es bastante natural descartar soluciones sin código en estos casos. Para comprender la situación con una perspectiva más amplia y una base de usuarios diferente, comencé a comunicarme con personas fuera de mi red existente para comprender los cambios en su pila tecnológica y la adopción de herramientas sin código. En general, después de llegar a una audiencia bastante diversa, obtuve algunos aprendizajes que finalmente cambiaron mi opinión. Para empezar, comencé a analizar de nuevo cómo se estructuran las organizaciones para las prácticas científicas. Aunque el campo de ML ha madurado, todavía es bastante común ver organizaciones con poca o ninguna función científica. La mayoría de las organizaciones luchan, comienzan poco a poco con ML y, por lo general, con un equipo con poco personal. Aunque el potencial de problemas científicos dentro de estas organizaciones puede ser grande, es difícil concentrarse en las grandes apuestas desde el principio. El viaje de descubrir el valor de los problemas de ML y darse cuenta de su impacto comercial es un proceso lento e iterativo y requiere el estómago para aprender de las grandes fallas. No existe el camino científico perfecto que ayude a navegar desde la identificación de problemas hasta la generación de valor comercial como un ejercicio demasiado simplificado del punto A al punto B. El viaje suele ser un camino arduo e iterativo. Eso me hizo pensar: ¿qué herramientas se adoptan en organizaciones con madurez variable en una función científica? En realidad, no todas las organizaciones pueden permitirse o querrían invertir en costosas habilidades científicas a escala desde el inicio. El proceso es a menudo un camino indefinido. La siguiente imagen ilustra una ruta simplificada mientras se navega desde el descubrimiento de problemas hasta la solución de una solución científica basada en productos. [Of course, each step has its own set of iterations, but you get the larger picture.][Image by Author] – Ruta de producción ilustrativa para casos de uso de ML. El área gris representa la frecuencia de iteraciones para un hito determinado. Naturalmente, tendremos una gran cantidad de ideas que se eliminarán antes de pasar a implementar un prototipo básico, que luego se recortará aún más antes de comprometerse con prototipos serios y finalmente se reducirá a las claves refinadas para un producto final. Durante mucho tiempo , Estaba mirando estos productos desde una perspectiva diferente y criticé el valor agregado de las plataformas sin código sin razón. Mi pregunta clave era: ¿qué valor tiene esta solución para los negocios serios? En algún lugar, parecía superfluo para los casos de uso que importaban. Pero luego me di cuenta de que estaba comparando desde la perspectiva de un lugar de trabajo que no carecía de habilidades de ML y recursos de ingeniería. Pero este no es el caso en todas partes. La mayoría de las organizaciones no tendrán recursos ni equipos para respaldar la validación de casos de uso científico a escala. Y también puede no tener una función científica madura para respaldar esto. La siguiente imagen ilustra el proceso de pensamiento con la efectividad de una plataforma sin código a lo largo de las etapas de vida de un problema empresarial.[Image by Author] — Ilustración para la eficacia de la herramienta sin código en la etapa de vida del problema Mi sesgo se debió a la inclinación hacia las fases más maduras del problema. Sin embargo, esta es una visión específica y limitada. Cada organización en función de su posición de madurez científica tendrá diferentes herramientas a su disposición. Si generalizamos el proceso de resolución de problemas para la mayoría de las organizaciones, debemos comprender que no todas las ideas se producen. La proporción de ideas a prototipos a MVP a productos finales parece como fichas de dominó cayendo en el orden inverso. Y por lo tanto, existe la necesidad de apoyar cada etapa de la vida de un problema de manera diferente con diferentes herramientas. La siguiente tabla profundiza en las etapas de vida del problema mencionadas anteriormente.[Image by Author]Como se muestra arriba, si diseccionamos el ciclo de vida del problema en hitos más pequeños, podemos ver las diferentes necesidades de habilidades y recursos a través de las etapas. Los equipos de ciencia dedicados no son de ninguna manera recursos frugales, por lo general tienen un costo igual o mayor para los equipos de ingeniería. Por lo tanto, es común que las organizaciones más pequeñas no tengan muchos de ellos. Entonces, ¿cómo pueden las personas que pueden no tener la capacidad de equipos científicos dedicados recorrer este proceso más rápido, sin grandes compensaciones? Fue entonces cuando comencé a ver un nuevo valor en las plataformas sin código. ¿Tiene sentido tener un tamaño único? ¿Una solución que se adapta a todos a lo largo del recorrido de la solución? ¡Diablos no! ¿Qué cambia a medida que avanza el problema? En un mundo ideal, para que Data Science y ML sean omnipresentes, existe una necesidad definitiva de contar con un ecosistema que facilite moverse más rápido en áreas donde hay una frecuencia muy alta de iteraciones combinadas con altas tasas de falla. Para respaldar la fase de ideación, ya contamos con las mejores herramientas que prosperan, por ejemplo, pizarras, PPT, documentos, redacciones, etc. Para prototipos básicos y serios, ¿tenemos algo que pueda hacer que esto avance más rápido? Algunos argumentan que Python está tan bien democratizado que puede facilitar esto. Eso puede ser solo parcialmente cierto; no todos los analistas dominan Python y SQL (tal vez). Por lo tanto, hay algo que puede llenar este vacío. Es por eso que creo firmemente que aquí es donde pueden prosperar las soluciones sin código. Esencialmente, una plataforma de ML sin código reduce significativamente la barrera para que el laico adopte la ciencia de datos. Esto se logra mediante la abstracción ordenada de componentes científicos complejos clave con bloques de construcción modulares para respaldar el viaje desde la ideación hasta la experimentación + validación con espacio adicional para la personalización. Estas herramientas ofrecen valores predeterminados sólidos que garantizarían que la mayoría de las tareas puedan avanzar con poca o ninguna entrada de personalización requerida por parte del usuario. Estas herramientas aceleran el proceso de validación de ideas al simplificar el proceso dentro de las tareas de ingeniería de datos y construcción de modelos. Además, estas herramientas también simplifican el proceso de consumo de resultados (resultados) y respaldan decisiones más amplias de seguir o no con experimentos de gran tamaño. Para las organizaciones pequeñas o los equipos nuevos que adoptan ML por primera vez, estas herramientas ofrecen un valor fenomenal para acelerar con confianza los pequeños pasos a precios asequibles y efectivos. Las herramientas sin código de ninguna manera son un reemplazo para grandes soluciones serias. No es un conjunto de herramientas permanente que se puede usar para abordar el problema mientras se navega desde los prototipos hasta la producción. A medida que el problema comercial se valida de manera justa por su valor y comienza a escalar, el valor de las herramientas sin código comienza a disminuir, lo que indica la necesidad de controles más detallados. Las herramientas sin código carecerán de la sofisticación que facilita que los engranajes ejecuten grandes problemas de producción a escala web. La naturaleza iterativa y experimental de los casos de uso de ML y ciencia de datos de hecho la convertiría en una iniciativa que consume muchos recursos. Las empresas que están creciendo en tecnología y/o han adoptado recientemente ML para negocios necesitarán tiempo para validar ideas antes de redoblar sus esfuerzos. El conjunto de herramientas que tenemos hoy puede no ser el medio más amigable y fácil de comenzar para los nuevos equipos que adoptan la ciencia de datos. Seguro que es robusto, pero sería menos ideal para principiantes. Aquí es donde la democratización de las herramientas de IA/ML comienza a desempeñar un papel fundamental. ¿Puede una organización comenzar un nuevo viaje con una inversión en ciencia de datos tan baja como un solo empleado y sin costos iniciales? ¿Se pueden validar las ideas sin esfuerzos serios de ingeniería y con una madurez científica limitada? ¿Se puede escalar lentamente una idea prometedora hasta que el equipo esté seguro de invertir en grande? Un sí definitivo a todo esto puede no ser siempre fácil con el universo Pythonic existente de ML; es necesario que haya herramientas que ofrezcan más. Para los problemas que exigen una validación rápida y un medio efectivo para iterar a escala hacia la madurez, las soluciones de ML sin código dan en el clavo. Cuando democratizamos las herramientas de IA y ML, comenzamos a facilitar el ecosistema con las herramientas adecuadas para fomentar ideas como criar a un bebé recién nacido hasta el jardín de infantes. Una vez en el jardín de infantes, bueno, tal vez sea hora de ver mejores herramientas. Pero hasta entonces, las plataformas sin código son sus mejores amigos. En general, no se recomienda entregar material de producción de calidad a través de herramientas demasiado simplificadas. Pero la naturaleza iterativa y experimental de los casos de uso de la ciencia no los hace adecuados para la ingeniería hambrienta de recursos desde el principio. Las diferentes etapas del problema y la madurez científica variable de la organización necesitarán herramientas diferentes para navegar el viaje científico. Las soluciones sin código/de código bajo ofrecen un gran comienzo y reducen efectivamente la barrera para que las organizaciones exploren si el campo ofrece valor para su negocio. A medida que la organización se pone seria, solo entonces existe la necesidad potencial de migrar a herramientas y servicios que ofrecen controles más granulares. Hasta entonces, las herramientas sin código serían un gran compañero para que su equipo explore. ¡Hola, gracias por leer! Si desea recibir actualizaciones sobre mis próximos blogs, síganos en Gorjeo para ser notificado de nuevas publicaciones de inmediato. ¡Gracias de nuevo!