Mi columna de esta semana en Invertia se titula «Un sistema inmunitario digital en el trabajo» (pdf), y trata de explicar por qué una aproximación o paralelismo biológico y basado en el sistema inmunitario a la ciberseguridad puede ser muy interesante, y cómo vincularla con el desarrollo de algoritmos de machine learning que tengan en cuenta los comportamientos habituales de las personas y la detección de anomalías relacionadas con las posibles vulnerabilidades y amenazas.
Y sobre todo, cómo una aproximación así requiere trabajar con herramientas sólidas y probadas, no con el típico código escrito en Python por el científico de datos de turno que cree que tiene que escribir sus herramientas y reinventar la rueda cuando esas herramientas ya existen, funcionan bien y, sobre todo, son mucho más prácticas a la hora de integrarlas con los sistemas corporativos.
El mayor problema del machine learning hoy no es el machine learning como tecnología, sino los iluminados que creen que es algo que hay que programar desde cero tirando código como si no hubiera un mañana. No, estas cosas hace ya mucho tiempo que no tienen que programarse, y pensar que hay que hacerlo es no solo desconocer las herramientas existentes, sino además, dificultar la posterior integración con los sistemas corporativos. Hay demasiado dinero tirado en el desarrollo manual de algoritmos que, por culpa de ese origen de código spaghetti escrito por desarrolladores no profesionales, no hay manera humana de poner en producción. Los sistemas corporativos de nuestros días no admiten fácilmente que uno conecte cualquier cosa.
Si quieres desarrollar un sistema que parta de las características de los trabajadores de una compañía, de los sistemas que utilizan y de las tareas que llevan a cabo, y monitorice constantemente posibles amenazas con metodologías ya tan rodadas como la detección de anomalías, no pretendas escribirlo desde cero. Simplemente no tiene sentido, como no tendría sentido, para hacer unas cuentas, programarse una hoja de cálculo. Ya las hay, y son buenas, mejores que lo que nadie pueda programar en un rato con lenguajes tan limitados como Python, R o similares. Reinventar la rueda nunca ha sido una buena estrategia.
This article is also available in English on my Medium page, «It’s time we let AI create a digital immune system for companies»
Hay un problema en programación en general… en cierta manera este youtuber nos habla sobre el tema y es muy instructivo del entorno que está creciendo en este mundillo:
Me INFILTRO en la Masterclass del Tío de los Anuncios de Desarrollo de Apps y Webs SIN PROGRAMAR
Con visionar unos minutos es suficiente. Resumo, para los que no aguanten al tipo. Resulta que hay mucho «vende formación on line» que opina que se pueden hacer apps, sin saber poco o nada de programación. Y le parece que hay una serie de personas que se dedican a embaucar a las personas con una serie de ideas, para en definitiva meterles en su embudo de ventas, y conseguir que se sientan atraidos por la verborrea y falsa expectativas. Aparte del modo que está hecho el video, que no acaba de gustarme la estética del mundo YT para jóvenes, tiene otra parte positiva que es poner en evidencia las taácticas torticeras de este tipo de marketing agresivo.
A alguien le puede surgir «YA» la idea que estoy a favor de que la gente deba tener conocimientos de STEM.Es decir que debe tener nociones de Ciencias, Tecnología, Ingeniería y Matemáticas. Incluyo la programación, dentro de este ámbito.
El youtuber nos contaba que para preparar herramientas en el FrontEnd si creía necesario que se tuvieran nociones de programación. (Javascript, React, node, flask, pug,… etc) Obviamente cuanto más conozcas mejores apps/webs harás y menos problemas. ¿Pero se pueden sacar esos deliverables con el mero uso de usar una generadora de apps.? Los que salgan creo que si… ¿serán sufcientes? Igual no…
Era solo un ejemplo similar
Hace unos años la bestia negra de las empresas que se dedicaban a vender SW, el enemigo era el excel, el VBA,… ¿por? la razón evidente era que entorpecían la venta de sus super aplicaciones, de los servicios profesionales asociados, etc. Y recurrían a lo típico que ocurre si ese empleado brillante se va de su empresa…
Y ahora el ML
Pues lo que Gartner cuenta es esto
Si alguien no quiere saber de programación, ni de STEM, entonces va a ser un usuario de una app. Y p.ej. en el mundo doméstico, podrá ser un experto en decirle a esa app: «Píntame una mona». Y en el mundo profesional podrá acceder a una app que le haga algo que está implementado en esa app.
Es decir estará limitado. Lo cual no quiere decir que en esa empresa de «corredores» de cierta Suite sea un «hacha»
Estoy de acuerdo con Enrique, como diría Victor el youtuber, si a una persona vaga y torpe le incitas a que no aprenda algo, el mensaje, adecuado o no, lo que consigue, es que esa persona en este caso sea un mero usuario sin más.
No todo el mundo tiene que programar. Y menos si tu empresa no te lo pide. En eso, nada que objetar.
En serio, En eso no hay discusión.
Sabemos que Enrique, opinaba que el STEM era importante.
https://www.enriquedans.com/2017/03/computacion-stem-e-integracion.html
https://www.enriquedans.com/2016/05/programacion-y-educacion.html
https://www.enriquedans.com/2013/09/programacion-ninos-y-escuelas-el-reto-del-momento.html
Vivimos tiempos de intenso cambio: en menos de una década, es muy posible que haya cambiado drásticamente el concepto de trabajo, que muchas personas se dediquen a profesiones que hoy ni siquiera existen, y que estemos en todo momento completamente rodeados de objetos programables. En ese contexto, saber programar va a ser una auténtica lingua franca, prácticamente una necesidad, una forma de relacionarnos con el medio en que vivimos, una forma de intercambiar información de manera permanente entre nosotros y con las máquinas.
Un fantástico artículo en Wired, «Forget foreign languages and music. Teach our kids to code« expone de manera clara las razones por las que la programación debería ser una asignatura incorporada al curriculum educativo desde la fase infantil: no para que sean programadores cuando crezcan, sino porque van pasarse la vida rodeados de objetos programables.
Pues si.
Para usar una Suite de Machine Learning no es necesario programar. Igual que para dar colores a una celda de excel y formatear una tabla tampoco.
No lo es en absoluto !
Si lo que quiere un Sr.Empresario es que su gente sea capaz de automatizar tareas o ir más allá de lo que hace una suite de pago, igual es necesario que tenga nociones de programación. Ese sería un perfil demandado por una empresa, y que igual tiene su aquel, en el mundo empresarial. ¿Qué es más sexy un corredor de suites o alguien que además sabe hacer pequeños scripts?
¿A quien contrataría un empleador a un usuario de una suite de ML solo? ¿ o a un usuario con nociones de Python/R que además de ser usuario le solucione problemas no incluidos en la Suite?
Joder… desde las 21:15 escribiendo, corrigiendo (intentando no ser…), adecuando…
Y viene usted, y me chafa el plan… :P
(me lee la mente o que?)
Hace unos días conocí «GitHub Copilot». No la he probado pero dicen que ahorra mucho trabajo al programador. Se basa en lo que comenta Enrique de «no reinventes la rueda» ya que muchas de las cosas que implementa un programador ya han sido programadas por alguien y muchas de ellas están en Git. Según su definición es tu AI pair programmer.
Me tienes que leer más ;-)
https://www.enriquedans.com/2021/07/escribiendo-codigo-con-copiloto.html
Te leo 9 de cada 10 días. Ese día falte a clase. :-)
Es imposible desarrollar sistemas de ML universales, mucho más, en temas de seguridad, por eso existen unas cosas que se llaman frameworks, y que dotan de la capacidad de desarrollar aplicaciones orientadas a tareas específicas de la actividad de una empresa.
Es lo que llaman «herramientas» los legos.
Sobre si un científico de datos sabe programar, sí, sí que saben, pero es un conocimiento especializado, y no estamos hablando de «científicos de datos» de curso de academia o un módulo de FP, sino de Ingenieros Informáticos especializados. (De los que cobran mucho y no son becarios)
Los programadores no tienen por qué tener ningún conocimiento de Ciencia de datos, es una confusión muy habitual.
Pocas profesiones existen como las de tecnología, que hay que reinventar la rueda cada 6 meses, mejorándola, si no quieres quedarte atrás.
El mito de que el desarrollo tecnológico debe hacerlo alguien que no tenga una carrera de ingeniería o en ciencias de la computación, y una formación muy especializada, ha quedado muy atrás.
Es lo que ha llevado a que proyectos de datos dirigidos por personas de gerencia acaben siempre haciendo aguas, a mí me hace bastante gracia cuando un directivo te confiesa que no tiene ni idea de temas de datos, y al día siguiente (después de un despido), acaba dirigiendo el área de datos de una consultora por tener un perfil visible.
Es como buscar un doctor en medicina en las terapias naturales. No sale bien.
(Como le toco aprender a Jobs)
Por algo ahora hay Ingenieros dirigiendo Google y Microsoft.
(nunca, never, ingenieros industriales. Desastre garantizado.)
–
Muy de acuerdo con todo lo que dices, Menestro.
Lo único que no se si interpreto bien son las dos últimas líneas. Vamos, lo de que los CEOS sean ingenieros (industriales o no).
Sólo quería comentar que el perfil de un ingeniero con un máster tipo IESE o ESADE está muy buscado y cotizado. En general mucho más que alguien que se haya formado exclusivamente en temas económicos y/o empresariales.
Quiere decir eso que todos los CEOs deben ser ingenieros? No, no se puede generalizar. Pero si se valora mucho un grado en ingeniería combinado con un máster en dirección de empresas de reputación.
¿Y los del IE no?
Utilizo las tablas dinámicas de una hoja de cálculo y son realmente buenas para filtrar y agregar datos de diferentes formas.
con lenguajes tan limitados como Python
La primera noticia.
Lo que dice Wikipedia
«Python es un lenguaje de alto nivel de programación interpretado cuya filosofía hace hincapié en la legibilidad de su código, se utiliza para desarrollar aplicaciones de todo tipo, ejemplos: Instagram, Netflix, Spotify, Panda 3D, entre otros.2 Se trata de un lenguaje de programación multiparadigma, ya que soporta parcialmente la orientación a objetos, programación imperativa y, en menor medida[¿cuál?], programación funcional. Es un lenguaje interpretado, dinámico y multiplataforma.»
https://es.wikipedia.org/wiki/Python
Me parece que aquí se mezclan las churras con las merinas…¿Que hay mucho incompetente en programación? Claro que sí, pero de ahí a presuponer que una herramienta desarrollada bajo el paraguas de una empresa de renombre va a ser, no sólo 100% fiable, sino también omnipotente hasta el punto de que cualquier modelo imaginable puede ser desarrollado, puesto en producción y escalado sin escribir código… Pues no sólo va a ser que no, sino que dudo que llegue el día en que nos veamos en dicha situación.
Soy científico de datos y he trabajado en grandes compañías en las que he tenido la dudosa ventaja de asistir a presentaciones de producto de todas esas herramientas de Machine Learning «ya inventadas» que se comentan aquí, en las que, desde mi puesto de experto que «tira líneas de código como si no hubiese un mañana», he tenido la oportunidad de hacer preguntas a los propios ingenieros responsables de dichos productos. ¿Resultado? En cuanto rascas un poco, salen a relucir las carencias y puntos débiles y llegas a la conclusión de que ahorrarte esas líneas de código puede salirte muy caro…
Por otro lado, escribir código nunca debería ser interpretado como reinventar la rueda. En código también se reutilizan soluciones cerradas de probada fiabilidad: las librerías. El mundo del software open source (FOSS según sus siglas en inglés) está ahora más activo que nunca, con una participación cada vez mayor de la comunidad científica, y tan pronto como surge un nuevo algoritmo, junto con la publicación del paper también lo hace una nueva implementación de dicho algoritmo en una librería de manos del propio investigador (por cierto, el 99% de las veces, en esos «tan limitados» Python o R).
Por último, me gustaría recordar al lector que pueda estar leyendo este comentario cuál es la dinámica más repetida de esas grandes compañías: selecciono un par de librerías, las empaqueto en una solución cerrada, le pongo un nombre comercial y a facturar… Es el caso de la tan sonada IBM Watson que tan cara salió en sus inicios a grandes compañías como Cemex… Es más, incluso en los casos de éxito, la dependencia tecnológica con terceros es otro gran problema para muchas compañías (véase la dependencia de BASF con SAP, que tantos quebraderos de cabeza y sobrecostes les ha generado y les seguirá generando posiblemente durante muchos años).
Es una deriva muy peligrosa la de dejar de confiar en tus expertos y dar por sentado que una gran compañía con intereses diferentes a los tuyos va a ser tu mejor aliado para desarrollar tu producto… Nadie te va a librar de estar expuesto al error humano, pero ni la falta de control sobre tu valor diferencial (como suele ser el caso en Machine Learning) ni las relaciones de dependencia con terceros pueden ser considerados como deseables en ningún caso para el desarrollo de una estrategia de producto.
Algún pequeño aporte sobre «el cientifico de datos de turno»:
En la línea de investigación que llevo supongo que se nos puede considerar «cientificos de datos». Y lo que dice Enrique es muy cierto, solemos re-programar cosas que ya existen.
El caso es que en biomedicina o ingenieria biomédica (al menos en mi facultad) utilizamos por defecto la plataforma de cálculo estadístico «R» (www.r-project.org), básicamente por dos motivos:
a) Es open-source
b) Existe un buen repositorio de «packages» para biomedicina
Sin embargo, como plataforma o lenguaje de programación, R deja mucho que desear:
a) No gestiona de forma óptima la memoria
b) No aprovecha internamente el procesado paralelo… básicamente la solución es abrir varias instancias de R que, sobre un SO con paralelismo, tratará como procesos independientes y, efectivamente, utilizará threads diferentes para cada instancia de R abierta (vaya… una chapuza)
c) El control de versiones de los packages no es fácil de manejar.
Es precisamente el punto c) el que muchas veces te obliga a «reinventar la rueda». Porque si tu «package» tiene interdependencias con otros packages, y estos son actualizados, puede que el tuyo deje de funcionar.
Creo que existe una posibilidad de evitar ese problema, pero como soy senior y los que programan asiduamente son mis estudiantes, no me he metido a fondo con el tema de las versiones. Pero en principio existen muchos packages «medio olvidados», que con el paso del tiempo no funcionan por culpa de las interdependencias en las que no se tiene en cuenta el cambio de versión de los otros «packages» de los que dependen…
En fin, que es cierto que a veces me da la impresión de que los «cientificos de datos» vamos dando tumbos como una gallina sin cabeza…
Hoy en día el problema del procesamiento en paralelo no es de R o Python o el lenguaje de programación X…
Cuando necesitas hacer un procesado en paralelo en un cluster o más sencillo aprovechar una tarjeta GPU, puedes recurrir (lo más óptimo) a desarrollar esa parte con «algo» especializado, ese algo puede ser C++ y si tu tarjeta es Nvidia usar CUDA, o puedes usar un módulo especializado de Python (conozco 2), Si no, puedes buscar algo que se adapte más a vuestro HW, y aplicar la famosa ley de Amdhal como si no hubiera un mañana….
De R tengo nociones y lo conozco menos, me intersó conocerlo, y me pareció super potente para estadística, y comparable a SPSS, si no mejor.
Además con la maravilla de R Studio me pareció un producto excelente.
Y buscando en google en menos de 1 segundo tenemos:
https://cran.rstudio.com/web/packages/cuda.ml/index.html
Desconozco vuestra plataforma, pero si os dedicais a lo que dices seguro que buscando un «poquito» el problema desaparece. Se documenta y el próximo estudiante que se encuentre en tener que confiar que su profesor le va a sacar del cuello de botella, al menos no tiene que recurrir a ti o a empezar desde cero. Eso en la empresa se llama know-how procedimental, tanto que dices que te gustan los masters del universo, empieza en tu ámbito de aplicación.
La dependencia de versiones es lo que tiene el mundo real, y para eso en el mundo Python… existen los entornos que manejan las versiones de las distrrbuciones. Es tan sencillo como crearte un entorno de trabajo y poner las versiones que funcionan y respetan las interdependencias
Por ejemplo en conda, para R ( se tarda otro segundo en hacer una nueva búsqueda en google)
https://docs.anaconda.com/anaconda/user-guide/tasks/using-r-language/
Te doy mucha razón en el párrafo que dices que no te has metido a fondo. En realidad no te has metido absolutamente nada. Como queda demostrado.
Lo de senior es algo que se demuestra con conocimiento, no con el DNI…
Yo también estoy con RStudio y el paralelismo sí es un problema si no aplicas ciertas técnicas para capearlo medianamente.
Obviamente,
Este párrafo se podía aplicar a gestión de recursos humanos
todo lo que es delegar trae consigo métodos que no son los que normalmente tienes que tener en cuenta, cuando cedes parte del control a otros procesadores, de hecho delegas la función pero no la responsabilidad de la ejecución»
Cuando usas un lenguaje que en teoría es para facilitarte la labor, p.ej python, hay que tener en cuenta que ese módulo puede no adaptarse a tu HW, por eso cuanto más cerca programes pegado a tu máquina se puede optimizar mejor el rendimiento.
Yo no he visto a la gente que hace videojuegos quejarse que tienen que programar una GPU. Es obvio que hay que hacerlo
Ni a los «ingenieros informáticos de verdad» quejarse que es un «muerto» hacer PGPU. Es lo que hay.
Es como decir que hacer «embedded programming» es un desarrollo «muy complicado» porque hay que programar en un lenguaje que les permita el bajo nivel y adaptarse al HW del dispositivo.
Es lo que hay, el que quiere peces se tiene que mojar el culo…
Y claro que en R se podrá hacer maravillas, pero es más sencillo pasar de puntillas para opinar sandeces, y si no hay nada preparado, lo haces en C++ y lo usas en tu script de R, o sigues en C++, no demos cuartelillo a tanta parida que se oye.
Que razón tiene Menestro al respecto. El problema es que hay mucho charlas que no dicen más que paridas, pero una tras otra. Y no se cortan un pelo en mostrar su incompetencia manifiesta. Un día, y otro día, y otro día.
Venga a opinar del clima en el siguiente, que para eso cualquiera vale.
Ya te he dicho antes que vas por mal camino…
Allá tu, yo no entro al trapo. Pero no hay peor contribución en este foro que una negativa/(intentando ser)hirente hacia una persona.
No es lo que se espera.
Te repito el consejo, se positivo, o critico constructivo. No descalifiques personalmente a nadie, especialmente si no les conoces.
Pero bueno, ya veo que te haces el sordo y no quieres entender nada…
Esto lo escribi antes de tu comentario. Antes de saber que en tu departamento hay doctorandos que conocen la materia con detalle en cuestión. Asi que puedes consultarlos y comprobar tu mismo si he dicho algo que no se ajuste a la realidad.
Hola Jordi!
Te agradezco enormemente la primera parte de tu intervención. Me será útil y lo trabajaré más a fondo. Todo lo que sea positivo o aporte conocimiento o sean criticas constructivas son más que bienvenidas por mi parte.
La segunda parte, sobre todo en la que empleas la sorna, sobra. Ahí ya no sumas, ni criticas constructivamente, solo provocas. Y prefiero no entrar en provocaciones, y humildemente te aconsejo que también huyas de provocar o de «entrar al trapo». Como sabes yo lo hice en un momento dado y me arrepiento, fue un error.
Pero sí te aclararé algunos aspectos (por aquello de sumar y criticar constructivamente) que has mencionado:
Respecto a lo de «Senior»:
En la Universidad, un «Senior Researcher»es alguien que ya tiene un buen CV y una dilatada experiencia en investigación, no necesariamente experiencia exclusiva o mayoritaria en una herramienta en concreto. Y aunque no depende de la edad que ponga en el DNI, una «dilatada experiencia» solo se consigue con años de arduo trabajo.
Para que lo entiendas (lo digo porque el mundo universitario es particular) en esta etapa de mi vida dedico más tiempo escribiendo propuestas para obtener financiacion para proyectos de investigación que le darán los recursos necesarios (infraestructuras, equipos, personal técnico y becarios de doctorado) a mi grupo de investigación que en teclear código y hacer realidad yo mismo los planes de investigación que diseño.
De todas formas, por si no te quedas convencido, suele haber una métrica sobre la productividad de un investigador, el factor «h». Y yo (no estoy presumiendo pues escribo bajo pseudonimo) estoy por encima de 27. Pregunta a algun profesor de universidad si es elevado o no, quizá veas «que si merezco el apodo de senior…».
Respecto a mi conocimiento de R:
Soy telecos de formación y mi linea de investigación es la de aplicar, fundamentalmente, algoritmos multivariantes, ML, IA y en general procesado de señal, a ingentes cantidades de datos, tanto en número de muestras (de diferentes pacientes con condiciones sanitarias diferentes ) como en la cantidad de datos que se genera la medición de cada muestra (por ejemplo, en una medida de una muestra de orina de un paciente X que padece una enfermedad Y).
Por lo tanto, rara vez me dedico (a estas alturas) a ponerme a teclear delante de la máquina para programar un algoritmo nuevo con un lenguaje X. Lo hice en su tiempo pero ahora es la función de otras personas (generalmente becarios jovenes) del equipo.
De hecho si se que en R se implementa muy mal la multitarea y la gestión de memoria es nefasta es por uno de mis más brillantes discipulos (que ahora ya es académico) que era un experto (por vocación y formación) en el desarrollo de programas de código abierto. Durante su tesis se pasó una buena parte codificando en C++ funciones para R que aumentaban exponencialmente las capacidades del entorno.
En fin, tengo clase, así que aquí lo dejo. Si tuviera que escoger una frase o «take home message» de mi intervención me quedaria con el consejo de que en el foro siempre intentes sumar, y nunca ser negativo, provocar o atacar a otras personas. Por experienca, te digo que no es el camino…
Un abrazo!
PD: Precisamente me acaban de conceder un proyecto en el que contrataremos a un especialista en CUDA para le procesado con IA de ingente cantidad de datos (que no se pueden clasificar como «big data», pues no se ajusta a su definición.
En ningún momento constatar una realidad palmaria es ironía o tono burlesco.
El factor h es muy importante, que duda cabe.
Gracias por reafirmar lo que es obvio en ti. y adelantaba en mis comentarios al respecto.
PS: Mira esto si que es sorna
Y dale! Que no entraré al trapo!