Redacción iAgua
Connecting Waterpeople
Red Control
Catalan Water Partnership
LACROIX
TRANSWATER
Hach
Molecor
ICEX España Exportación e Inversiones
AMPHOS 21
Agencia Vasca del Agua
J. Huesa Water Technology
Likitech
Confederación Hidrográfica del Segura
TEDAGUA
ACCIONA
EPG Salinas
Filtralite
AGS Water Solutions
ISMedioambiente
Saint Gobain PAM
Lama Sistemas de Filtrado
Centro Nacional de Tecnología de Regadíos (CENTER)
Barmatec
RENOLIT ALKORPLAN
Asociación de Ciencias Ambientales
Baseform
TecnoConverting
CAF
Aqualia
Ministerio para la Transición Ecológica y el Reto Demográfico
s::can Iberia Sistemas de Medición
Almar Water Solutions
Global Omnium
Cajamar Innova
Rädlinger primus line GmbH
SCRATS
ADECAGUA
Xylem Water Solutions España
HRS Heat Exchangers
Innovyze, an Autodesk company
Amiblu
FENACORE
ESAMUR
ONGAWA
Fundación Botín
ADASA
KISTERS
GS Inima Environment
Grupo Mejoras
DATAKORUM
Sivortex Sistemes Integrals
FLOVAC
Schneider Electric
Vector Energy
Sacyr Agua
Laboratorios Tecnológicos de Levante
Hidroconta
Fundación CONAMA
Fundación Biodiversidad
Minsait
Ingeteam
IAPsolutions
Idrica
Consorcio de Aguas Bilbao Bizkaia
AECID

Se encuentra usted aquí

Mis errores favoritos en proyectos de Machine Learning

Sobre el blog

Miguel Ángel Rodriguez Núñez
Técnico de Inteligencia Operacional y SCI en Emasesa. Master en Ingenieria y Gestión del Mantenimiento. Master en Mantenimiento Industrial y Técnicas de Diagnóstico.
  • Mis errores favoritos proyectos Machine Learning

Uno de los objetivos esenciales en un proyecto de Machine Learning (ML) es reducir el tiempo de trabajo manual y eliminar los errores al automatizar ciertos procesos. Este hecho no lo exonera de la posibilidad de cometer determinados errores en su planteamiento, diseño, desarrollo e implementación que afectarán de forma determinante al proyecto. Las posibilidades de “meter la pata” son múltiples, pero hay algunas especialmente sangrantes por las que tengo personal predilección.

Falta de un objetivo claro

El objetivo que nos planteemos debe ser posible, debe de aplicarse al área de la empresa que realmente lo necesite y comunicarse convenientemente para que no sea percibido como una amenaza. No es de recibo justificar un proyecto de ML por el mero hecho de que dispongamos de un departamento o sección de inteligencia artificial o ML. La existencia de un departamento es mas útil cuando sus operaciones van encaminadas a resolver lo problemas core de la organización, en caso contrario lo mejor es externalizar su servicio como tantos otros en nuestro sector.

“No hay nada tan inútil como hacer de forma eficiente algo que no se debería haber hecho nunca”

Peter Drucker

Comprender la diferencia entre desarrollo e investigación

Una cosa es aplicar un modelo obtenido tras un análisis efectivo, con datos concretos y a un problema específico y otra es trabajar en un proyecto difícil que exige el desarrollo de un software específico no comercial, la construcción de modelos analíticos especiales o el procesamiento de datos y validación con costes desorbitados. Ambas posibilidades son estimulantes, pero una tiene un horizonte final y la otra puede ser un mar de dudas al no poderse estimar el alcance completo del proyecto por adelantado, y eso disponiendo de fondos, que esa es otra.

Diseño de KPis incorrectos

La forma en que se midan los resultados de un proyecto de ML será determinante en cuanto a los métodos de trabajo en que se emplearán. El diseño de KPis alejados de la realidad o simplemente que no reflejen los objetivos del proyecto afectarán muy negativamente a su evaluación posterior y por tanto a las decisiones que tome la empresa en cuanto a la viabilidad del proyecto.

Volumen

Agregar más datos a nuestro proyecto de ML no tiene porqué mejorar el rendimiento del modelo resultante, tampoco los resultados de aplicar éste. Podemos encontrarnos que al aumentar el número de datos podemos aumentar también aquellos que contienen información errónea y por tanto degradar el rendimiento del modelo. Es importante tener en cuenta que disponer de una gran cantidad de registros y un hardware/software de calidad son ingredientes de peso para encontrar modelos de ML eficientes y productivos, pero no hacen milagros. Sólo desde el conocimiento profundo de los mecanismos, procesos, variables que conectan los mismos y las relaciones subyacentes entre ellos podremos obtener los modelos adecuados.

Ruido Aleatorio

Conforme el conjunto de datos sea mas grande, el número de correlaciones arbitrarias y de escaso interés entre sus variables también aumentará. Desgraciadamente disponer de mayor información no necesariamente implica estar más informado. En procesos en los que disponemos de múltiples sensores distribuidos a lo largo de la planta esto puede ser un verdadero problema. Podemos encontrar patrones de aparentemente interés pero que no se reflejen en la optimización del rendimiento del proceso.

Overfitting y Underfitting

Ambos son una de las principales causas de obtener malos resultados en ML. Podemos traducirlos como sobreajuste y subajuste y hacen referencia al fallo del modelo que estamos desarrollando al generalizar o encajar el conocimiento que se pretende que asimile. 

Cuando entrenamos un módulo de ML estamos haciendo que el algoritmo sea capaz de generalizar un concepto para que al consultarle por un nuevo conjunto de datos desconocidos sea capaz de sintetizarlos, entenderlos y devolvernos un resultado fiable en forma de predicción. Si los datos que disponemos son pocos, el algoritmo no será capaz de generalizar el conocimiento e incurrirá en underfitting, no siendo capaz de discretizar resultados diferentes del general. Por el contrario, si entrenamos nuestros algoritmos ML con datos no suficientemente representativos del universo en cuestión sólo aprenderá a reconocer casos particulares y será incapaz de reconocer nuevos datos de entrada o diferentes patrones. Para evitar ambos casos deberemos disponer de una cantidad mínima de muestras, clases variadas y equilibradas en cantidad además de evitar cantidades excesivas de dimensiones. Además, siempre que desarrollemos un algoritmo de ML deberemos tener en cuenta que pueden caer en uno de estos problemas por no poder generalizar correctamente el conocimiento. El subajuste nos indicará la imposibilidad de identificar o de obtener resultados correctos por carecer de suficientes muestras de entrenamiento o un entrenamiento muy pobre. Por su parte el sobreajuste indicará un aprendizaje excesivo del conjunto de datos de entrenamiento haciendo que nuestro modelo únicamente pueda producir unos resultados singulares y con la imposibilidad de comprender nuevos datos de entrada.

Correlación y causalidad

Mediante el ML podemos identificar de manera efectiva los patrones sutiles existentes en nuestros datos, pero no nos puede decir directamente cuáles de estas correlaciones son realmente significativas. Aunque ya deberíamos tener claro que la correlación no implica causalidad, el cerebro humano está especialmente preparado para buscar patrones. No podemos resistir establecer relaciones y paralelismos cuando vemos dos líneas que se desplazan de forma simultánea a lo largo de una línea temporal. Este error intrínseco a la naturaleza humana, reflejado en múltiples estudios, ha convertido a las ventas de helados en los principales causantes de temas tan diversos como los incendios forestales, ataques de tiburones o brotes de polio entre otros. Independientemente de que todas estas variables se incrementen en verano en el fondo tienen poco que ver entre ellas, aunque si exista un enlace común, la temperatura que es realmente la variable que las relaciona aparentemente.

Con suficientes datos y recursos de cómputo podremos encontrar múltiples patrones entre nuestros datos, pero hay que distinguir entre los que nos ofrecen información de poco interés y los realmente significativos. Sólo comenzando nuestro análisis desde la comprensión absoluta del problema subyacente que estemos tratando de resolver y el conocimiento de nuestros procesos podremos obtener resultados significativos.

Por último y para finalizar, incorporaremos a la lista el que más me gusta, el uso de información no permitida.

¿Podemos utilizar todos los datos de que disponemos? ¿Seguro? Es conveniente que repasemos la legislación española y europea en cuanto a protección de datos. No hay desastre mayor y más frustrante que disponer de un algoritmo Top que utilice información protegida de los usuarios y que por tanto tenga implicaciones legales. Es un quiero y no puedo que difícilmente justificará los costes de un proyecto de ML además de muy caro si tenemos en cuenta las últimas sentencias judiciales que han afectado a gigantes como Google y Facebook. En próximas semanas profundizaremos en ellos.