Recursos didácticos de Machine Learning: Generación automática de datos IoT y detección de anomalías. Una introducción práctica

En esta entrada voy a describir y completar como fue parte de mi última clase de Machine Learning que impartí ayer sábado 31-01-2026 en el máster de la UIC: https://www.uic.es/en/estudis-uic/business-administration/masters-degree-data-science-advanced-analytics

Para ello y mucho antes de la clase, me puse a ver varios cursos de coursera y vídeos de youtube para poder hacer prototipos mecánicos cercanos a lo que se denomina Internet de las Cosas y que fuesen capaces de generar datos realistas que posteriormente pudieran ser procesados, ya que muchas industrias hacen uso de este tipo de técnicas tanto para realizar experimentos de productos a lanzar en el mercado, como para llevar el control sistemático de distintos sistemas que pueden ser mecánicos, de refrigeración, etc.

Por tanto tras invertir un tiempo en mi propia autoformación me dispuse a desarrollar una de las ideas que tenía en la cabeza en base a un tema que tenía que explicar en el citado máster, por lo que me dispuse a llevar el proyecto a la realidad y así fue como me hice con esta serie de artilugios que muestro en la anterior foto no costándome todo el conjunto más de 13-14€ (dándome además juego para reutilizarlos en otros prototipos). Así pues, lo que se ve sería lo siguiente (que sólo menciono pero no describo ya que me interesa más centrarme en el análisis posterior):

• Una placa Arduino nano con su cable que se puede encontrar perfectamente por unos 3.5€ ya que los compré en pack amazon: https://www.amazon.es/arduino-nano/s?k=arduino+nano (en aliexpress se puede incluso encontrar más baratas aún)

  
  

• Una mini proto-board que se puede encontrar en diversos packs en https://www.amazon.es/mini-protoboard/s?k=mini+protoboard&page=2 y llegarse a adquirir por menos de 2.5€ la unidad

  
  

• El ventilador (o cpu fan motor) que me costó unos 2€ pero seguro que se puede encontrar más barato por aquí https://www.aliexpress.com/store/1104558884?spm=a2g0o.order_list.order_list_main.50.103e194dhQov0r&sortType=bestmatch_sort Eso sí, procurar que sea de unos 5V para que no haya problema y que tenga al menos 3 cables ya que uno de ellos (generalmente de color amarillo) será el que se use para contar las revoluciones por minuto

  
  

• Y un mini lector de tarjetas SD que en pack lo conseguí por menos de 2.5€ enhttps://www.amazon.es/dp/B077MCQS9P?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1

  
  

• Y finalmente algunos elementos que se pueden comprar a granell por no más de 2€ todo como son un transistor npn, un push button, resistencias y los citados cables

En total, a nivel unitario no me gasté más de 13€ que me lo gasto cualquier fin de semana en unas pocas cervezas y tapas que no siempre me ayudan a mejorar la salud...

El circuito anterior se base en el siguiente esquema:

Sin embargo, yo añado un componente adicional como es el lector de tarjetas SD y permito que el arduino nano conecte la lectura de las revoluciones por segundo con dicho lector de tarjetas para que guarde lecturas cada 5 segundos. Más informaciones sobre las conexiones en concreto que hay que hacer estarían en mi git y en concreto aquí: https://github.com/FJROAR/ArduinoIoTVentialdores

A continuación dejo las conexiones realizadas (por si alguien se quiere poner a reproducir el experimento) que utilicé destacando la del pin D2 que es la que cuenta las revoluciones por minuto del ventilador y va al cable amarillo, mientras que los cables rojos van a los 5V que proporciona arduino y el negro va a tierra:

Elemento	Pin Arduino Nano
Ventilador (control)	D9
Botón ON/OFF	D5
Ventilador (TACH)	D2
Módulo SD – CS	D10
Módulo SD – MOSI	D11
Módulo SD – MISO	D12
Módulo SD – SCK	D13

Pues bien, el sistema anterior escribe en un fichero denominado RPM.txt el cual he vuelto a regenerar, ya en casa hoy domingo 01-02-2026 que lo ejecuté durante unos 11 minutos a partir de las 11.29 eliminado el primer minuto que es cuando el motor se pone en marcha y va pillando rodaje. Por tanto, he dejado las últimas 120 lecturas que se han tomado cada 5 segundos y se guardan en un fichero que he renombrado como RPM_20260201_113000.txt, que podéis observar en el git al que he hecho mención. Dicho fichero tiene la siguiente estructura que se resume con la siguiente imagen:

Es a partir de aquí en el que comienza el trabajo del Data Scientist, en el que lo primero que se va a hacer es crear un programa python que me construya una serie temporal con 2 variables, en una el tiempo, donde la primera observación va a ser 20260201113000, la siguiente 20260201113005 y así sucesivamente, mientras que la segunda variable contendrá el dato del valor de las RPM y se denominará rpm.

El programa python denominado AnalisisRPM01 que está también el git de este proyecto permite no sólo preparar los datos si no mostrar los siguientes gráficos:

Donde claramente se muestran una serie de anomalías y es que frente a su funcionamiento normal, yo le he metido un bolígrafo físicamente a las aspas del ventilador que obviamente hacía que se detuviese o casi se detuviese y en consecuencia, en función de la intensidad, la caída de las revoluciones por minuto es más que evidente.

Y ahora es cuando metemos el análisis no supervisado y nos preguntamos ¿Puede detectarse lo anterior sin recurrir a un método heurístico? ¿Que pasaría si quiero controlar más variables? Es aquí donde aparece una función de la librería sklearn de python y que se denomina GaussianMixture(). Esta función es capaz de hacer uso de normales multivariantes para trabajar con varias variables y detectar los correspondientes atípicos, en concreto, para este caso en el que hay una única variable el siguiente fragmento de código resulta clave para establecer un punto de corte y es totalmente extrapolable, con tan solo modificar el parámetro n_components al número de variables a considerar:

from sklearn.mixture import GaussianMixture

X_rpm = df[['RPM']].values

modelo_gmm = GaussianMixture(n_components=1,

n_init=5,

random_state=0)

modelo_gmm.fit(X_rpm)

score = modelo_gmm.score_samples(X_rpm)

pct_threshold = np.percentile(score, 3)

df['anomalia'] = [1 if s < pct_threshold else 0 for s in score]

El anterior fragmento detectará las anomalías al percentil del 3% y por tanto sólo queda observar si es capaz de detectarlas, cosa que si lo consigue tal y como se observa a continuación:

En este caso se ha ido hacia anomalías muy graves, pero en función de análisis tipo coste beneficio se puede pensar en si cambiar el percentil del 3% por otro por ejemplo del 5% con tan sólo modificar la línea:

pct_threshold = np.percentile(score, 5)

En ese caso, el coste del mantenimiento del sistema sería más elevado ya que la probabilidad de una revisión sería mayor, pero obviamente, se podría detectar una mayor cantidad de errores. Lo anterior se obtiene re-ejecutando el programa y cambiando el 3 por el 5 llegándose a:

Todo lo realizado cabe ser resumido como un recurso didáctico listo para hacer una introducción al análisis de anomalías con python. Para ello he creado un artilugio mecánico que puede usarse directamente en clase ya que es muy visual y de reducido tamaño mediante arduino ide. El artilugio genera datos que posteriormente son analizados mediante un programa python que los recoge de una determinada ubicación y genera por un lado unos gráficos exploratorios y finalmente introduce una función específica del entorno sklearn como es GaussianMixture() para que literalmente se cree un método que a partir de los datos y sin supervisión previa se detecten automáticamente los puntos de incidencia de modo que se puede ser más o menos fino en esa detección y el método es generalizable a una cantidad p de variables cualesquiera, no sólo una.

Finalmente espero que sea de utilidad este tipo de entradas y desde luego si alguien las valora y desea más información puede contactarme al respecto vía Linkedin o/y suscribirse al este blog donde iré creando más recursos como este.

El problema de las 3 puertas en Arduino

Últimamente se me está despertando el alma de ingeniero y el descubrimiento de placas como arduino y esp 32 me está permitiendo bajar la teoría a algo que se pueda tocar y en este, uno de mis primeros proyectos, en fase prototipo es el conocido problema de las 3 puertas, que como imagino que todo el mundo conoce, se trata de un juego en el que hay 3 puertas y tras una de ellas se esconde un premio. El concursante (o participante) del juego, elige previamente una de las puertas, posteriormente, el presentador del juego, que sí sabe donde está el premio, desvela una de las puertas donde no está y pregunta al concursante si desea cambiar de puerta:

Pues bien, en mis clases de Data Scientist suelo empezar con este ejemplo donde me da pie para hacer una introducción al Teorema de Bayes y a no dejarnos llevar por lo primero que se nos viene a la cabeza, ya que mucha gente ante esta cuestión, directamente prefieren mantener la elección, cuando lo óptimo, porque duplicas las probabilidades hasta un 66% es el cambio.

Por tanto, me decidí a fabricar este simulador para mostrar el problema y la verdad es que con un poco de ayuda de chaGPT en la programación C/C++ que lleva arduino ha quedado un tema muy mono que se puede consultar en mi git:

https://github.com/FJROAR/ArduinoBayes

Y que os funcionaría si seguís el siguiente esquema que aclara más que el lío de cables de la anterior foto por si os lo queréis montar bien para vosotros, bien para algunas de vuestras clases:

Creo que es una idea tratar de hacer más palpable la árida probabilidad además que este ejemplo lo puedo ampliar más para alto tipo Reinforcement Learning que comentaré en alguna próxima sesión.

Por el momento espero que esto inspire a alguien o que le ayude explicar de un modo más claro como resolver el problema Monty Hall que en su versión más árida propone como solución es 2/3 si se cambia la elección (y 1/3) si se mantiene, lo cual se deduce fácilmente a partir de:

Os dejo un vídeo del experimento:

Funcionamiento: Problema Monty Hall en arduino

Papá!!! No me ponen en producción mi xgboost

He conocido a más de uno que con una mayor o menor dosis de ingenuidad pretende, sin conocer el stack tecnológico real, crear modelos de analítica avanzada y ponerlos en producción como sin tal cosa hasta que le llega su primer “baño de realidad”.

Y sí amigos, ya bien entrado el siglo XXI, existen cosas que muchos milennials ignoran pero que siguen siendo fundamentales en su vida aunque lo igneren. Una de ellas es el COBOL, un lenguaje que nació a finales de los 50, en concreto en 1959 y donde hay que destacar que, aunque en verdad intervino un equipo (el comité CODASYL Comité on Data Systems Languages) en su creación, fue una mujer, Grace Hopper, por aquel entonces almirante de la marina de los EEUU, a quien se le considera su “madre intelectual”, la que asienta sus bases, por lo que se consigue lograr un lenguaje suficientemente legible en inglés, estándar y portable para aplicaciones de negocio que aún a día de hoy está en la mayoría de las entidades de cierto calibre, a pesar de que algunos listos como Elon Musk, van a hacerlo desaparecer... ¿Lo logrará?

Una de las razones por las que traigo aquí el lenguaje es porque como es comentado, es un elemento esencial en la sociedad y no son pocas las grandes empresas que lo están utilizando y a pesar de sus ventajas, impone sus limitaciones. Así por ejemplo ¿Quién no usa actualmente una tarjeta de crédito/débito para hacer una compra? Este acto tan sumamente cotidiano, en la mayoría de los casos tiene un soporte COBOL donde los entornos de programación aún resultan un poco “salvajes” para estas nuevas generaciones acostumbradas a los notebooks y a los IDEs de juguete que te hacen creer que ya lo dominas todo:

Aunque el proceso es aún más largo, me interesa el punto donde se introduce modelización en todo este proceso y es justamente cuando se pasa la tarjeta de crédito por el TPV de un establecimiento para hacer una compra, en ese momento y en cuestión de segundos, un programa COBOL bajo (suponiendo entorno IBM) CICS (Customer Information Control System) realiza de modo rápido y seguro:

·        La lectura de los datos de la tarjeta y del cliente.

·        Consulta saldos, límites y estado de la cuenta (DB2/VSAM).

·        Aplica reglas de negocio (importe máximo, financiación, bloqueos).

·        Devuelve aprobado o denegado en milisegundos.

Justo donde se Aplica reglas de negocio es donde interviene uno o varios modelos, junto con un conjunto adicional de reglas que acompaña a todo el proceso de decisión, en muchos de los casos totalmente automática.

Es pues en el punto anterior donde se enfoca este trabajo y donde se va a desprender el porqué la regresión logística junto con (o sin) la metodología credit scoring es a día de hoy aún la más utilizada y con la que cualquier estadístico aka data scientist puede fácilmente hacer ganar a su empresa su primer millón de euros (o mucho más), dejando para otro día modelos como los random forest o xgboost. Además, voy a ser más preciso ya que no voy a tratar aquí sobre la construcción de un modelo de credit scoring, sino que de lo que voy a tratar es ¿Cuáles son las pautas que se deben observar para poner un modelo en producción bajo este tipo de entornos?

Claramente aquí la diferencia con los sistemas Cloudera y otros más actuales, donde se pueden “poner en producción” modelos de analítica avanzada es evidente y desde luego, un desarrollador de modelos actual debe tener unas ideas generales de cómo funciona si no quiere tener conflictos con los que finalmente le pondrán el modelo en producción, ya que los desarrolladores en mainframes tipo IBM hablan un lenguaje totalmente distinto basado en las entradas y salidas de un programa COBOL que para nada se parecen a R, Python, C, java, SQL o cualquier cosa que se esté usando en los últimos 50 años.

¿Qué debe tener preparado un modeler actual para llevar a cabo una puesta en producción en COBOL?

1. Por lo pronto, y aunque no es totalmente obligatorio, conviene que la propuesta a implementar sea de tipo credit scoring y la razón es sencilla, bajo esta metodología, se pueden ir observando lo que se denominan los scoring parciales que se comentan en el apartado (3). En todo caso, no resultaría muy complicado poner un modelo en producción tipo regresión logística ridge / lasso o incluso decisión trees, aunque, si nos vamos a random forest o modelos más avanzados, la implementación se complicaría enormemente al tener que generar un programa COBOL que sería extraordinariamente largo y más complejo de validar su funcionamiento, por tanto no va a ser normal encontrarlos en la realidad

   
   

2. Lo segundo es haber elegido variables que existan y sean accesibles en el momento de la solicitud por nuestros sistemas. En ocasiones, el programador de COBOL tendrá que crear nuevas variables a partir de combinaciones de las existentes, por tanto, es factible crear (y se hace a menudo) en nuestros modelos interacciones entre variables o combinaciones de éstas

   
   

3. La principal ventaja de la metodología de credit scoring es que cada una de las variables que compone el modelo se discretiza a unos valores que suelen ser los valores WoE que ahora no se van a tratar y de aquí se convierten en tramos de score, por tanto, el modelo final es una suma de lo que se denominan scoring parciales y que no son más que el aporte de cada variable por separado, así pues, cada variable aporta un número de posibles valores que se tomarán en función del valor real que aporta la variable y dada una solicitud de compra, lo que hace el modelo es generar una puntuación tal como sigue:

   
   

   Score = Score base + Score Parcial 1 + …+ Score Parcial p

   
   

4. Un valor habitual que se toma para Score base es el de 600 o uno cercano, aunque puede variar por diversas razones que tampoco se discuten aquí

Por lo que como se observa, tras pasar la tarjeta por el TPV se genera una suma tal como sigue y la decisión de aceptar / rechazar se tomará en función de si el valor Score es suficientemente elevado, junto con reglas adicionales que como se ha comentado, es habitual que existan.

No obstante, aún no se ha respondido a la pregunta anterior ¿Qué debe preparar el modeler? Pues básicamente cuando por ejemplo se trabaja en R, como suele ser mi caso, los elementos a preparar son básicamente un conjunto de datos sintéticos y controlados de al menos 25 – 50 test. El soporte para esto puede ser Excel y si se quiere validar la implementación de un scoring en no más de una mañana, se debe hacer en colaboración con el que haya hecho el programa COBOL. Y sí, he dicho bien, validar la programación de un modelo en COBOL se hace en una mañana o incluso en menos tiempo, aunque bien es cierto que he visto validaciones donde se han tirado meses y en general las razones han sido:

• El modeler no tenía preparado un juego de pruebas adecuado

• El programador Cobol no había creado un programa con los requerimientos

En general, los requerimientos no suelen ser complicados, no obstante, es habitual tener que hacer correcciones sobre la validación, por eso como best practice conviene que el programa esté creado y que la persona que lo haya hecho esté durante la validación, en esta se contrasta lo siguiente a través, generalmente del uso de un servicio web que emula la petición en real de un cliente donde se graban los valores reales de las variables (aquí se supone que hay sólo 3 variables en el modelo):

• Si se supone que hay 3 variables, el score se puede expresar mediante el siguiente pseudocódigo (que debe ser pasado a COBOL):

  SCORE = 600

IF EDAD >= 18 AND EDAD < 30 THEN SCORE = SCORE - 5

IF EDAD >= 31 AND EDAD < 35 THEN SCORE = SCORE + 5

IF EDAD >= 36 AND EDAD < 45 THEN SCORE = SCORE + 10

IF EDAD >= 46 AND EDAD < 55 THEN SCORE = SCORE + 15

IF EDAD >= 55 THEN SCORE = SCORE + 10

IF INGRESOS < 1000 THEN SCORE = SCORE - 10

IF INGRESOS >= 1000 AND INGRESOS < 2000 THEN SCORE = SCORE + 0

IF INGRESOS > 2000 THEN SCORE = SCORE + 15

         IF VINCULA = ‘BAJA’ THEN SCORE = SCORE – 8

         IF VINCULA = ‘MEDIA’ THEN SCORE = SCORE + 3

         IF VINCULA = ‘ALTA’ THEN SCORE = SCORE + 10

• Una vez se convierte lo anterior a COBOL, el programador en este lenguaje puede ir viendo si se realiza todo de modo correcto cada vez que se introduzca un Test, así este programa junto con el data scientist para el primer caso debería observar que al principio la variable score toma el valor 600, después el 595, tras esto mantiene el 595 y finalmente debe tomar el valor 587 y análogamente con el Test 2, la evolución sería 600, 610, 625 y 636

  
  

• Para concluir la validación conviene realizar tantos test como tramos existan y prestar especial atención en los puntos límites donde existen >= o <=

El COBOL a pesar de su antigüedad no es un lenguaje difícil, si bien no es un código para programar temas complejos a nivel algorítmico. Es un programa enfocado para mover ficheros, valores en dichos ficheros y hacerlo de un modo rápido, perdurable en el tiempo y sin errores. Así pues, una de las razones por las que persiste este lenguaje es porque es rápido y es muy resiliente a errores, una vez se verifica que el código funciona correctamente. Por otro lado, es un leguaje auditable, si bien es cierto que es un lenguaje que requiere mucho código, es decir, como se observa en la primera figura, crear un Hola mundo, no se hace con 2 líneas y requiere ser por tanto muy específico en cualquier instrucción que se genere, así pues, el fragmento anterior de código tendría una forma aproximada de:

       WORKING-STORAGE SECTION.

01 EDAD            PIC 9(3).

               01 INGRESOS   PIC 9(7).

               01 VINCULA       PIC X(5).

01 SCORE           PIC S9(4).

       PROCEDURE DIVISION.

           MOVE 600 TO SCORE

           IF EDAD >= 18 AND EDAD < 30

               SUBTRACT 5 FROM SCORE

           END-IF

         IF EDAD >= 31 AND EDAD < 35

               ADD 5 TO SCORE

           END-IF

           IF EDAD >= 36 AND EDAD < 45

               ADD 10 TO SCORE

           END-IF

           IF EDAD >= 46 AND EDAD < 55

               ADD 15 TO SCORE

           END-IF

           IF EDAD >= 55

               ADD 10 TO SCORE

           END-IF

           IF INGRESOS < 1000

               SUBTRACT 10 FROM SCORE

           END-IF

           IF INGRESOS >= 1000 AND INGRESOS < 2000

               ADD 0 TO SCORE

           END-IF

           IF INGRESOS > 2000

               ADD 15 TO SCORE

           END-IF

           IF VINCULA = 'BAJA'

               SUBTRACT 8 FROM SCORE

           END-IF

           IF VINCULA = 'MEDIA'

               ADD 3 TO SCORE

           END-IF

           IF VINCULA = 'ALTA'

               ADD 10 TO SCORE

           END-IF

Finalmente, espero haber aclarado un poco el porqué cuesta poner en producción un modelo tipo xgboost y por qué el credit scoring o la regresión logística siguen siendo aún los que más ingresos generan y espero haber levantado la curiosidad de más de uno en este lenguaje, cuyos programadores van desapareciendo y resultan cada vez más cotizados al igual que los fontaneros y los electricistas… Sino lo creéis, veréis cuando se os rompa una cañería ...