Las estrategias que las compañías utilizan para aproximarse al machine learning, sin duda uno de los desarrollos analíticos con más posibilidades de cara al futuro, tienen un problema fundamental: en el 87% de las ocasiones, se quedan en simples experimentos que nunca son puestos en producción.
¿Qué lleva a que muchas compañías, tomando decisiones racionales, adopten con algo como el machine learning una actitud meramente exploratoria, e incluso después de acometer cuantiosas inversiones, de incorporar científicos de datos a su plantilla y de invertir recursos, tiempo y dinero en ello, no sean capaces de poner esos desarrollos en producción?
Sencillamente, la mentalidad experimental. Durante años, nos hemos empeñado en afirmar que el machine learning, que en realidad es una disciplina con muchas décadas de historia que simplemente detuvo temporalmente su progreso porque la tecnología aún no era capaz de posibilitar una potencia de análisis determinada, era algo que para acometer, necesitabas rodearte de equipos de científicos de datos, que armados con lenguajes de programación como Python, R y similares, desarrollarían herramientas ad hoc para llevar a cabo los complejísimos análisis necesarios para diseñar y educar los míticos algoritmos. La totalidad del proyecto se planificaba como eso, un experimento. Consultes la fuente que consultes, sea el popularísimo curso de Andrew Ng, o aunque se titule «Machine learning for average humans« o incluso «Absolute beginning into machine learning«, insiste en la necesidad de aprender a programar y de revisar y reforzar nuestros cimientos de estadística, como si de verdad necesitásemos desarrollar unas herramientas de machine learning que, en realidad, llevan ya bastante tiempo desarrolladas.
¿Por qué creemos – erróneamente – que para hacer machine learning es preciso empezar desde cero y desarrollar las herramientas necesarias para ello? ¿A alguien se le ocurriría dedicarse a contratar ingenieros de software para desarrollar una herramienta para llevar la contabilidad de su compañía? No, ¿verdad? Sencillamente, se escoge una herramienta de contabilidad, y se utiliza. Pues la única diferencia entre la contabilidad y el machine learning es la materia prima de la que parten: por lo general, los datos contables con los que alimentamos nuestras cuentas están perfectamente disponibles, se calculan de manera razonablemente estandarizada, y no generan dudas sobre su procedencia. Y sin embargo, los datos con los que abastecemos nuestros análisis de machine learning pueden ser, en ocasiones, algo más difíciles de obtener, de localizar o de preparar. Eso es todo. Hablamos, en realidad, de un problema de cultura de datos, de desarrollar una mentalidad en nuestra compañía con respecto a la importancia de los datos, de reinterpretar nuestra cadena de valor para poder obtener datos a los que posiblemente no dábamos importancia o no recogíamos. Si disponemos de los datos, analizarlos mediante machine learning debería ser, simplemente, una cuestión de aplicar herramientas adecuadas para ello. Si en lugar de simplemente utilizar esas herramientas te dedicas a intentar inventarlas, darás a tu proyecto una dimensión absurda y, seguramente, no lograrás ponerlo en producción.
Si te dicen que poner en marcha un proyecto de machine learning en tu compañía te va a exigir contratar a uno o varios científicos de datos y escribir nosecuántos programas en Python o en R, entra en modo pánico y da marcha atrás. Replantéalo radicalmente con personas que sepan de verdad de lo que están hablando, porque no debería ser así. Si continúas con un proyecto estructurado así, terminarás no solo reinventando la rueda, sino además, con un proyecto para hacer una rueda que será mucho peor que las ruedas ya existentes, y que además, estará sujeto con alfileres, como todos los experimentos de ese tipo llevados a cabo en compañías no especializadas en el desarrollo de herramientas. Las posibilidades de que ese tipo de experimentos acaben realmente puestos en producción, que es la única métrica válida para evaluarlos, son tan escasas como ese 13% que se cita al principio de este artículo. Tienes un 87% de posibilidades de perder tiempo, esfuerzo y dinero. Simplemente, no lo hagas.
El machine learning hace ya tiempo que superó la fase experimental, pasó a la fase de servicio para convertirse en MLaaS, machine learning as a service, y está ya incluso entrando en la fase de commodity. Si quienes quieren poner en marcha un proyecto de machine learning en tu compañía ignoran esa realidad y pretenden volver atrás a la fase experimental, es que no saben de qué están hablando, que están mal orientados, o que alguien les ha querido vender una moto estropeada. Es lo mismo que si te traen a un montón de ingenieros para desarrollar una hoja de cálculo: no, mire usted, hojas de cálculo ya existen, no necesito crear una. Pongamos las cosas en su sitio. En algún sitio, habrá competidores tuyos utilizando herramientas estándar para hacer las cosas que están moviéndose mucho más rápido que tu compañía.
Aplicar machine learning no es sencillo: son procedimientos analíticos complejos en los que las fases de definición de objetivos y de recolección y transformación de datos se llevarán un porcentaje muy elevado del esfuerzo del proyecto. No son proyectos triviales. Pero tampoco son absurdamente complejos, ni requieren expertos en la construcción de herramientas analíticas experimentales, porque esas herramientas analíticas hace ya mucho tiempo que están construidas. Si abandonamos esa absurda mentalidad experimental en machine learning, producto de la ignorancia y del temor reverencial, seguro que conseguimos avanzar mucho más rápido.
This article was also published in English on Forbes, «Stop experimenting with machine learning and start actually using it!«
Quizás lo que hay que hacer en torno al ML es dejar de vender humo. Si en el 87% de los casos sus intentos de uso se quedan en nada puedes culparlo a los que pretenden usarlo, como haces tú. Pero para mí es más sencillo. No funciona como los vende-humos nos han dicho.
Es casi lo mismo que cuando oigo noticias aquí en España (casi todos los días) que se ha descubierto «no se que» en un pueblo «no se donde» en una empresa «no se sabe nada de ella», que tiene muchas posibilidades de curar el cáncer, y siempre me pregunto (y yo mismo me respondo: es mentira) con tantas naciones, personas, laboratorios, compañías importantes especializadas, en el mundo, ¿no se les ha ocurrido antes eso?. Si, ya se que alguna vez debe ser cierto, pero soy viejo y, ya digo, todos los días hay noticias de esas y al poco tiempo «nada de nada».
Luego es el enfado que me entra: ¿No podemos coordinarnos para resolver el problema que sea (el cancer) y no tener laboratorios «desperdigados» que cada uno va «a lo suyo».?
Perdido ando algo, como diría un sabio cinematográfico. Quiero suponer que lo de exoperiemnatr se refiere al caso de un laboratorio de Química que se perdiera en reinventar el tubo de ensayo, en vez de usarlo de forma cada vez más creativa con nuevos experimentos de avance.
Esa mentalidad tan demencial y burocrática sigue siendo la que prima en muchos ambientes creativos. Era (es?) la obsesión de aprender a limar muy bien, en vez de aprender a trabajar creativamente el metal, y de paso forzar los acabados eficientes. La responsabilidad no está reñida con el disfrute del trabajo bien hecho. Los animales irracionales aprenden jugando, no poniéndose en fila para levantar las patas delanteras coordinadamente.
¿Por qué tanto empeño en domesticar a los aprendices?
Los conceptos IA y «machine learning» están muy sobrevalorados, pues son las mismas cosas que se vienen haciendo desde que existe la informática.
Lo que pasa es que se utilizan en el día a día y pasan desapercibidos, Una simple bombilla con control de presencia tiene IA, un ascensor que utiliza un programa u otro , con fin de dar un rapido servicio o un ahorro energético según un historico de horas y demandas de servicio tine una IA algo mas complicada pero en esencia es lo mismo que una maquina que localiza tumores cancerosos, solo que unos utilizan unos sensores y otros utilizan otros.
Programas capaces de auto modificarse de acuerdo con la experiencia, también los hay desde tiempo inmemorial, y son fáciles de realizar, Yo mismo he escrito en LOGO un programa que simulaba la evolución genética de un insecto por el sencillo sistema de modificar ligeramente de forma aleatoria uno de los muchos parámetros (o genes) que conformaban su imagen y ver si el ser resultante, valoraba con sus características, (diferentes volúmenes del cuerpo, pesos, colores etc.), mejor que el ser anterior. en una serie de funcionas.
Esto en esencia es ·machin learning y no necesita ni grandes conocimiento, ni grandes aparatos ni nada de nada. Sólo grandes ideas felices donde aplicarlas. Una vez definido el objeto a crear, crear el programa que los cree es bastante sencillo
Hay por ahí un juego gratuito de ordenador, multijugador en red, llamado Fold.it, ,
https://www.microsiervos.com/archivo/juegos-y-diversion/fold-it-plegado-proteinas.html
en el que el jugador no necesita conocimientos técnicos, solo una gran imaginación pues se trata de plegar, (folding), proteínas para que adquieran una determinada forma
Se pueden mejorar proteínas ya diseñadas o descubrir nuevas que cumplan las reglas de las estructuras de las proteínas.
Esto es utilizar la Machine Learnin utilizando ademas la Artificial Inteligencia Artificial o el mismo recurso que se utiliza con Amazon Mechanical Turk.
No señor. Aquí y ahora hablamos de Machine Learning, que no tiene absolutamente nada que ver con el concepto de AI que tu explicas.
El concepto que tradicionalmente se ha tenido a bien denominar AI en informatica era la programación de una reglas, que se aplicaban a datos de entrada para generar resultados a priori desconocidos. Toda la experiencia y conocimiento residía en esas reglas. En cambio, en el machine learning se dispone (en general) de datos de entrada y, desde el instante inicial, también datos de salida, y lo que buscamos son las reglas que los relacionan. Es la diferencia entre ser por ejemplo un doctor en física mecánica y describir gracias a nuestro conocimiento las ecuaciones que rigen la deformación de un puente y aplicarlas a unos datos de temperatura, viento y carga, para conocer la deformación, o ser por contra un inepto en teoría mecánica, pero sensorizar un puente sometido a esas mismas variaciones en las variables de entrada (temperatura, viento, carga, etc, todas ellas también conocidas) y que sean los propios datos de salida (deformación) los que nos permitan obtener unos modelos (sin ecuaciones, sin reglas) que a priori desconociamos.
Esa AI que mencionas es simple programación, reglas definidas a priori. Machine learning es la obtención de esas reglas de manera intrínseca en unos modelos, sin tener que crear reglas ni conocer las ecuaciones.
Curioso que tu sepas mejor que yo lo que hacían mis programas.
Enrique, lamentablemente estamos continuamente reinventando la rueda. Muchos de los detalles del programa Apolo que hace 50 años llevó al ser humano por primera vez a la Luna se han perdido para siempre, tanto así que para el actual programa Orión muchas cosas deben hacerse prácticamente desde cero.
Aprovecho la oportunidad, para recomendarte un libro no muy conocido de Arthur C. Clarke titulado 20 de julio de 2019: La vida en el siglo XXI, que fue escrito en 1986 (traducido al español en 1987), y que intentaba predecir cómo sería nuestra vida justamente en este preciso día de este año.
Brevemente; sí el Machine Learning es un Hype desde 2014, no responde a expectativas reales, y existe la moda de añadir «Inteligencia Artificial» a cualquier producto, incluidas las Cocretas y los bolígrafos. O la ensaladilla. Sucedió lo mismo con el material milagro, el Grafeno.
Deep Learning’s ‘Permanent Peak’ On Gartner’s Hype Cycle
Para una empresa supone un riesgo económico involucrar sus recursos en el desarrollo o adopción de una tecnología por su viralidad o por ser una palabra de moda, o buzzword.
Es el departamento de tecnología, e ingenieros, suponiendo que sea una empresa con un componente tecnológico que requiera de ese despliegue, quien debe valorar y guiar el desarrollo de cualquier recurso. No se puede comprometer la viabilidad económica del negocio en aras de una supuesta y milagrosa «Trasformación digital» como dicen los Gurús, como fue la «Ofimática» en algún momento.
–
Disclaimer
Sí, lo mismo sucede con el Fact-checking. Es una palabra de moda. La profesión se llama periodismo, y la asignatura, verificación de fuentes, y se estudia en la carrera, y también la efectúan los documentalistas.
Una buena idea, un buen equipo y desde luego unos buenos datos (de los que no hay tantos, aunq se piense lo contrario) …
Dar el salto a producción es donde realmente esta el valor… y el reto, mantenerlo y que tenga validez externa.
Nuestra experiencia hasta la fecha muy positiva, buenos AuC’s, predicciones automáticas, etc
Lo mas importante es una buena idea. El equipo y los datos se encuentran fácilmente, las ideas no.
De todas formas mientras a la IA no se la consiga incorporar sentido común, los resultados que produce tiene con frecuencia la categoría de imprevisibles y absurdos. Un ejemplo claro es el accidente de Tesla, el autopiloto mete el coche debajo de un camión, porque no había nada entre las ruedas del remolque.
Cualquiera puede hacer ML con R o Python, y un poquito de interes. Cualquiera puede timarte diciendo eso de … Esto es una cosa muy complicada, pero yo te puedo ayudar…
Por nombrar solo dos campos que han transformado para bien sus ámbitos de aplicación de forma vertiginosa gracias al Machine Learning:
1. Traducción de idiomas.
2. Vencer a campeones del mundo humanos (o de silicio) en bastantes juegos de mesa (juegos con azar como el póker, o sin él, como el Go o el Ajedrez). De ping pong no… Todavía :)
Hola, Enrique. He buscado, por curiosidad, la fuente para la estadística que citas de un 87% de proyectos fallidos, y lo que he encontrado no es muy alentador. El artículo que enlazas es en realidad un anuncio, imagino (porque no lo aclaran) que pagado por IBM para promocionar los servicios de esta compañía. De modo que la respuesta a la pregunta que plantean de por qué fallan tantos proyectos es ‘Porque no compran productos/servicios de IBM’. Pues vale. Y en cuanto a la estadística propiamente dicha, citan lo que dijo en una charla un señora que es jefa de IBM… y allí se acaba el rastro, he googleado un poco pero no he encontrado nada más.
Me habría gustado echarle un vistazo a ese (¿hipotético?) estudio sobre fracasos en ciencia de datos, para ver si arrojaba algo de luz sobre el problema, pero no va a poder ser.
Enrique, para hablar desde el desconocimiento es mejor no hablar. Un 87% de proyectos fallidos… y en IT en general cuánto es ese porcentaje? Google dice 68%. Es decir que los proyectos de ML fallan un 27% más de lo normal. ¿A que ya no impresiona tanto el número?
Luego viene el desprecio por la profesión del científico de datos, cuya labor es precisamente la de acometer la tareas que mencionas: buscar y limpiar datos, aplicar herramientas, y promover la cultura de datos. ¿o acaso insinuas que para hacer ML basta con conocer la api de las herramientas? porque ni por asomo: para aplicar con rigor los algoritmos más simples hay que tener un bagaje estadístico muy potente.
¿O insinuas que te han intentado vender la implementación de, digamos, una regresión logística? esto no es así en absoluto, los cientificos de datos usan librerías que ya implementan estos algoritmos, nadie está reinventando la rueda.
Insistes también mucho con Python y R, ¿hay algún problema con estos lenguajes? Python en concreto es de los lenguajes de uso general más populares en la actualidad. Si crees que no es apropiado para código productivo necesitas actualizarte.
En fin, volvamos a los porcentajes. Un proyecto de ML tiene un 27% más de riesgo que un proyecto de IT. ¿Qué potencial beneficio medio tiene respecto a los proyectos IT? ¿Crees que más, menos, lo mismo…? Los proyectos de ML que hoy en dia ya están producción están haciendo cosas como estas: aumentar el click-through ratio en la web, detectar fraude o usos maliciosos, adaptar interfaces a cada usuario, «aumentar» las capacidades de call centers mediante procesamiento de lenguaje natural, etc. Saltos cualitativos en la forma de entender el negocio.
¿Sabes donde hay muchos cantamañanas también? En la industria de IT. Esos cantamañanas que te venden experiencias de usuario, diseños web optimizados para vender más… y se compran sin más datos que los que ofrece el propio proveedor. En un approach de ciencia de datos vas a saber si va mejor o no. Vas a hacer test A/B para determinar qué diseño es mejor, y lo vas a poder hacer incrementalmente, mejorando de forma continua tus métricas y la experiencia de usuario. Pero imagino que piensas que cualquiera puede diseñar un test A/B. No Enrique, necesitas a esas personitas especiales que son capaces de explicarle estadística a un informático, e informática a un matemático.
Si piensas que hablo desde el desconocimiento cuando llevo más años que tú trabajando en un tema, tienes tres serios problemas: excesiva juventud, excesiva confianza y excesiva mala educación.
Me parece muy bien que trates de justificar que hace falta un científico de datos para hacer cualquier cosa, pero simplemente NO ES CIERTO. Del mismo modo que no hace falta un ingeniero de software para usar una hoja de cálculo, no hace falta un científico de datos para hacer machine learning, y todos los que intentan hacerlo con Python y R se la pegan y terminan teniendo proyectos cogidos con alfileres e imposibles de poner en producción. El machine learning, se pongan como se pongan “los de la bata blanca”, ya hace tiempo que pasó su “momento hoja de cálculo”…
Te pido que al menos bajes a mi nivel y nos propongas un ejemplo de cómo un informático sin bagaje estadístico puede hacer machine learning: ¿qué algoritmos crees que sería capaz de aplicar? ¿con qué rigor? ¿con qué lenguaje? (ya que parece que el lenguaje es algo importante). ¿sería capaz un perfil informático de diseñar la validación de este sistema?
Por otro lado, basas todo el artículo en el porcentaje del 87%, pero no has respondido a mi correción de que el verdadero factor sería un 27%. Algo que decir al margen de mi supuesta juventud? ¿Si el factor de riesgo adicional de un proyecto de ML fuera un 27% te parecería que merece la pena el riesgo respecto a los potenciales beneficios?
Por cierto, el comentario de «los de la bata blanca» te retrata bastante. Los roles profesionales son un espectro y la ciencia de datos no es menos, pero cuando llega a la parte del espectro en la que aparecen las batas, desaparece el rol de científico de datos y aparecen los mátematicos e ingenieros informáticos que hacen investigación y a los que jamás oirás referirse a si mismos como científicos de datos. Antes de estos te encontrarás a los científicos de datos que hacen pruebas de concepto del estado del arte en la empresa, y que solo aparecen en grandes empresas, siendo quizá entre el 5 y 10% de la plantilla de científicos de datos. Y el resto son ingenieros con trasfondo en señal (telecos, electrónicos, mi pefil ideal para el puesto, por cierto), o matemáticos con trasfondo de desarrollo (como los de matemática aplicada, o el doble grado matemática informática).
En la otra cola de la campana lo que te encuentras es gente con conocimiento de dominio que tiene un trasfondo de datos: economistas, geólogos, físicos, etc y que seria raro que superasen el 20% de la plantilla.
Esta es la realidad de la empresa. No te digo que el mundo de las charlas no esté lleno de cantamañanas, de eso sabrás tú más que yo.
A los científicos de datos, Manuel, les doy clase yo desde hace bastantes años. Sé lo que son, te lo aseguro. Y por supuesto, para aplicar algoritmos no hace falta ningún lenguaje más que el inglés. Puedes hacer desde regresiones logísticas hasta deep learning simplemente abriendo menús, escogiendo opciones y haciendo clics. Si aún no lo sabías, es que estás aún en la fase anterior de todo esto, en la de los «experimentos».
Es sorprendente que uses el término «experimento» de manera peyorativa. Muy mala educación estás dando a esos científicos de datos si no das valor al método científico. Un experimento no es una paja mental. Un experimento es el marco imprescindible para validar cualquier modelo, en especial los que van a ser productivos.
Desde luego que se pueden hacer modelos con drag and drop. Si alguien se trabaja el feature engineering, la selección de hiperparámetros, la comprobación del experimento, y la interpretación de resultados, entonces si, hastá un chimpancé podría pinchar en el botón que ejecuta el entrenamiento. Y luego qué? si sale ROC 0,99 como sé si he cometido un error? sé buscar errores en la construcción de las variables, la selección de las muestras de entrenamiento, o la definición del target? Estas preguntas las responde también el software click and play o me fio del chimpancé?
Enrique, tengo un hijo de 15 años al que he invitado a leer tu blog durante el verano. Para el tipo de bachiller que ha elegido considero que le será de gran ayuda. Uno de los muchos motivos que he encontrado para que lea tu blog no es otro que el comprobar como un profesional como tú se digna a contestar los comentarios. Te honra.
No sé lo que pensará mi hijo pero diría que no has contestado a Manuel completamente. Creo que es evidente que las dos formulas (la que planteas y la que defiende Manuel) son, deben ser, complementarias. El ejemplo de la hoja de calculo o programa de contabilidad, creo que puede servir como ejemplo para lo que defiendes pero siguiendo con el mismo ejemplo, existe otro tipo de software (programas de facturación, por ejemplo) donde es el cliente al que no le sirve nada de lo que hay en el mercado y decide desarrollarlo incluso desde cero.
Me gustaría aportar mi comentario en apoyo a la opinión de Manuel también defendida por Jorge. Me resulta desconcertante la tesis del Sr. Dans, incluido su recurso al argumento de autoridad y experiencia, al igual que su tono levemente crispado. La argumentación de Manuel me parece bien fundada y, por cierto, se adecua a mi experiencia trabajando con ML en una de las empresas GAFAM (con python y haciendo a veces, por supuesto, análisis a medida con código propio – que no reinventando algoritmos, para los cuales utilizo obviamente las librerías existentes en sklearn).
No entiendo la necesidad del Sr. Dans de minusvalorar un perfil profesional «experimentador» que es absolutamente necesario para comprender lo que se está haciendo.
Volviendo al símil de la hoja de cálculo, efectivamente, no se necesita un equipo de ingenieros para llevar una contabilidad en un excel. Pero si se deja pulsar botones de los macros a alguien que no entiende de números ni lo que está haciendo, cuando haya algún problema éste no lo sabrá resolver y ni siquiera sabrá que hay algo mal. Pues exactamente igual cuando se pone a un no experto a pulsar botones en una supuesta interfaz de ML: con suerte sale algo medio decente porque algún experto lo dejo todo calibrado antes, pero en cuanto llegue algo inesperado, se va todo al traste.
Evidentemente cada vez hay más cosas de ML que se pueden usar por más gente, pero de ahí a decir que ya es hora que «los de la bata blanca» se vuelvan a su biblioteca a leer libros va un trecho. No le hacía yo a usted tan displicente de los perfiles técnicos, Sr. Dans. Y los alumnos de su escuela de negocio no son el alfa y el omega de los científicos de datos, ni por asomo.