Metodología para Machine Learning (II): Machine Learning Canvas

Es este el segundo post que dedico a metodologías para el campo del machine learning aunque, para ser sinceros, no sé si a la técnica que ocupa este artículo se la puede llamar realmente metodología pero, en cualquier caso sí se trata de una técnica que, de alguna forma, ayuda en la gestión y, sobre todo, definición de un proyecto de machine learning.

Se trata del Machine Learning Canvas, una técnica que hereda, como tantas otras, del tsumani desatado por el merecido éxito del Business Model Canvas y que, de una forma en mi opinión algo exagerada, ha encontrado réplicas de todo tipo, con mayor o menor fortuna o agudeza analítica.

En este caso, la técnica fue definida por Louis Dorard y la explicó allá por 2016 en una serie de posts en medium que se iniciaban con el titulado 'From Data to AI with the Machine Learning Canvas (Part I)'.

La idea subyacente

 

De alguna forma, como modelo subyacente, tenemos que entender que lo que se pretende es hacer un modelo de Machine Learning capaz de hacer predicciones sobre algún problema de negocio. 

Para entrenarlo necesitaremos una serie de fuentes de datos (sistemas, ficheros, social media, etc) de los que, mediante procedimientos de recolección obtendremos una serie de datos en crudo. Para alimentar el modelo seleccionaremos unas variables de entrada (características) que podrán coincidir con algunos datos en bruto o proceder de algún tipo de elaboración de estos. 

El caso es que con esos datos definimos y entrenamos el modelo. Una ves que entendemos que el modelo es correcto, es decir, realiza las predicciones esperadas, lo desplegamos en producción y, a partir de ahí, los usuarios adoptarán decisiones apoyadas en esas predicciones o, incluso, el algún caso, la decisión se podrá automatizar.   

El Machine Learning Canvas

Con esa idea en mente, el Machine Learning Canvas lo que hace es guiarnos en la toma de decisiones de negocio o diseño para responder a todas las preguntas necesarias para la definición del problema que vamos a resolver y el método para hacerlo. El aspecto del canvas es el que se muestra en la figura (creada por el propio Dorard):

De los diez apartados que se deben rellenar, el central corresponde al objetivo, los de la parte derecha a la forma de aprender, los cuatro de la izquierda la forma de generar predicciones y la parte inferior como evaluar la bondad del modelo ya en producción.

A partir de esto, y de forma simplificada, lo que se debe consignar en cada bloque, aquello a lo que el bloque debe responder, es lo siguiente:

• OBJETIVO
  
  
  • Proposición de valor: ¿Qué es lo que estamos intentando hacer? ¿Por qué es importante? ¿Quién lo va a usar o estar impactado?


• APRENDER
  
  
  • Fuentes de datos: ¿Qué fuentes de datos en bruto podemos utilizar?
  
  
  • Recolección de datos: ¿Cómo obtenemos nuevos datos de los que aprender? (tanto entradas como salidas)
  
  
  • Características: Entradas al modelo a conseguir a partir de las fuentes de datos en bruto
  
  
  • Construcción de modelos: ¿Cuándo creamos o actualizamos los modelos con nuevos datos de entrenamiento? ¿De cuánto tiempo disponemos?


• PREDECIR
  
  
  • Tareas Machine Learning: Cuáles son las entradas, cuál la salida a predecir y qué tipo de algoritmo (clasificación, regresión…)
  
  
  • Decisiones: Cómo se usan las predicciones para tomar las decisiones que aportan valor
  
  
  • Hacer predicciones: Cuándo hacemos las predicciones sobre nuevas entradas y de cuánto tiempo disponemos
  
  
  • Evaluación offline: De qué métricas y predicciones disponemos para evaluar el modelo antes del paso a producción


• EVALUAR
  
  
  • Monitorización y evaluación en vivo: De qué métricas y predicciones disponemos para evaluar el modelo ya en producción

Por supuesto, las decisiones de definición y diseño tienen algo más de complejidad y aristas de lo que la escueta descripción que antecede hacer ver, pero sirve, creo, para hacerse una idea de la forma de aplicar esta técnica.

Conclusión

El Machine Learning Canvas es, como se ve, más bien, una forma de estructurar las decisiones más importantes a tomar en la definición del problema y el diseño de una solución a ese problema, usando datos y machine learning, que una metodología propiamente dicha.

En cualquier caso, puede servir de ayuda u orientación en algún caso. 

Artículos de este blog relacionados

• Metodología para Machine Learning (I): CRISP-DM

Una detallada descripción de ROS (Robot Operating System) con Wyatt Newman

'A systematic approach to robot programming with ROS' es un libro extenso y completo que explica, en orden creciente de complejidad, los principales conceptos de la programación para robots usando ROS, lo que se puede considerar la plataforma estándar de facto para esta labor.

El libro, detallado y muy orientado a ingenieros y desarrolladores reales, está repleto de ejemplos de código usando C++ (ROS admite también Python) y no elude, en algunos casos, aportar las bases algebráicas de algunos conceptos. En esos ejemplos, además, se usan simuladores de algunos robots reales como Baxter o Atlas.

En cuanto a su estructuración y contenido, decir que el libro comienza con un corto prefacio en que primero se intenta explicar qué es exactamente ROS y luego se dan algunas indicaciones de cómo está planteado el libro. A esto le siguen 18 capítulos agrupados en seis secciones, como sigue:

• Section I ROS Foundations: un sección que pone las bases de los elementos constituyentes de ROS: conceptos, herramientas y artefactos.
  
  
  • Chapter 1. Introduction to ROS: ROS tools and nodes: Comienza por la definición de algunos conceptos básicos como nodos ('nodes'), mensajes ('messages'), 'topics', 'publishers' y 'suscribers'. A continuación dedica la mayor parte del capítulo a explicar la escritura de nodos (creación de paquetes, compilación, ejecución, planificación, etc). Finaliza mostrando algunas herramientas básicas: catkin_simple, roslaunch, rqt_console y rosbag.
  
  
  • Chapter 2. Messages, Classes and Servers: Se concentra ahora en una alternativa al mecanismo publish/suscribe para la comunicación entre nodos y así habla de cómo definir 'messages' personalizados, da unas primeras nociones de 'services' y también de clientes ('clients') y, sobre todo servidores ('servers').


• Section II Simulation and Visualization in ROS: dedicada a las herramientas que permiten desarrollar el software para un robot sin necesidad de disponer una versión física del mismo.
  
  
  • Chapter 3. Simulation in ROS: Explica las potentes capacidades de simulación en ROS. Primero muestra un simulador bidimensional simple (STDR, Simple Two-Dimensional Robot simulator). Luego explica (URDF - Unified Robot Description Format), probablemente el sistema más universal para expresar un modelo de robot. A continuación se explican los fundamentos de Gazebo, el simulador dinámico usado en ROS. Y finaliza con algunos casos concretos, como el servo control de una articulación o un robot móvil.
  
  
  • Chapter 4. Coordinate Transform in ROS: Un capítulo de carácter muy algebráico que explica las transformaciones de coordenadas.
  
  
  • Chapter 5. Sensing and Visualization in ROS: Se explica la herramienta de visualización de ROS: rviz. Y se ilustra con la visualización de valores de sensores como un LIDAR, una cámara de color y una cámara de profundidad.


• Section III Perceptual Processing in ROS: Comienza a incorporar el tratamiento de sensores, en especial cámaras, para percibir información del entorno.
  
  
  • Chapter 6. Unsing Cameras in ROS: Tras explicar algunas importantes labores como la calibración de las cámaras se explica el uso con ROS de OpenCV, la libreria Open source para visión artificial
  .
  • Chapter 7. Depth Imaging and Point Cloud: Se explica la obtención de profundidad mediante LIDAR, cámaras estéreo y cámaras de profundidad.
  
  
  • Chapter 8. Point Cloud Processing: Se trata de la interpretación de información en 3D.


• Section IV Mobile Robots in ROS: Avanza ya hacia los robots móviles atancando los problemas de navegación y control.
  
  
  • Chapter 9. Mobile Robot Motion Control: Explica el control de robot móviles estructurando el discurso en los tres elementos necesarios: primero, la generación del estado deseado y la trayectoria para alcanzarlo, segundo la estimación del estado del robot a partir de información de sensores como la odometría, GPS y LIDAR y, finalmente, el algoritmo de control que gestiona el movimiento en función de la desviación de la trayectoria deseada y con base a la información de estado.
  
  
  • Chapter 10. Mobile Robot Navigation: Explica la navegación, que es una forma de control de movimiento más compleja, que no se reduce a seguir una polilínea (la trayectoria) sino que utiiliza mapas y también la detección de obstáculos.


• Section V Robot Arms in ROS: Aborda la planificación y control de brazos robóticos.
  
  
  • Chapter 11. Low-Level Control: Explora el control a bajo nivel de las articulaciones del robot en ROS.
  
  
  • Chapter 12. Robot Arm Kinematics: Explica la cinemática de las garras de robots, tanto la cinemática directa (cálculo de la posición de la garra con respecto a su marco base) como la inversa (dado una posición deseada de la garra, qué conjunto de ángulos de las articulaciones conseguirán ese objetivo).
  
  
  • Chapter 13. Arm Motion Planning: Explica cómo planificar el movimiento del brazo del robot, lo cual puede implicar, por ejemplo, obtener la trayectoria que minimiza el tiempo para alcanzar la posición final, pero también puede, por ejemplo, optimizar las capacidades mecánicas de los actuadores.
  
  
  • Chapter 14. Arm Control with Baxter Simulator: Se lleva a la práctica todo lo anterior con un simulador del robot Baxter.
  
  
  • Chapter 15. An Object-Grabber Package: Finaliza esta sección con una explicación detallada del uso de un paquete dedicado al agarre de objetos.


• Section VI System Integration and Higher Level Control: Finaliza integrando la percepción con los robots móviles.
  
  
  • Chapter 16. Perception-Based Manipulation: Explica cómo combinar la percepción externa con la manipulación de objetos, con un apartado previo dedicado de nuevo a la calibración de una cámara externa.
  
  
  • Chapter 17. Mobile Manipulation: Proporciona una visión muy integrada, basada de nuevo en el robot Baxter, de la manipulación en robots móviles.


• Chapter 18. Conclusion: Un capítulo final que, de forma muy breve, resume lo visto a lo largo del libro.

'A systematic approach to robot programming with ROS' considero que es un gran libro y con buenas explicaciones, pero denso y que para sacarle todo su jugo es necesaria una lectura pausada, más bien un estudio, acompañada de poner en práctica en la plataforma real los ejemplos que se aportan. Este libro es, pues, un gran recurso, pero no para especialistas, no para cualquiera.

Wyatt S. Newman

(Fuente: Traducción y elaboración propia de la ficha de autor en IEEE Xplore)

Wyatt S. Newman

Profesor del departamento de Ingeniería Eléctrica y Ciencia de los Computadores en Case Western Reseerve University, donde ha enseñado desde 1988. Sus áreas de investigación son la mecatrónica, robótica e inteligencia computacional, en las que posee 12 patentes y más de 150 publicaciones técnicas.

Recibió su grado del Harvard College, Cambridge, Massachusetts, EEUU, en 1978, y su máster en ingeniería mecánica del Massachusetts Institute of Technology (MIT), Cambridge, en ciencias de fluidos y térmicas, de teoría de control y teoría de redes en Columbia University, New York, New York, EEUU, en 1982 y su doctorado en ingeniería mecánica del MIT en 1988 en diseño y control.

Pasó ocho años haciendo investigación industrial en Philips Laboratories, Briarcliff Manor, NY, USA, involucrado en diseño y control electromecánico.

Se unió a Case Western University en 1988, y en 1992, fue nombrado NSF Young Investigator in Robotics. Otras de sus experiencias y asignaciones profesionales incluyen: Visiting Scientist en Philips Naturrkundig Laboratorium, Eindhoven, Holanda, facultativo visitante en Sandia National Laboratories, Intelligent Systems and Robotics Center, Albuquerque, Nuevo México, NASA summer Faculty Fellow en NASA Glenn Research Center, Visiting Fellow en Princeton University, Distinguished Visiting Fellow, U. Edinburgh, Institute for Perception and Behavior, Edimburgo, Escocia, y el Hung Hing Ying Distinguished Visiting Professor in Science and Technology, The University of Hong Kong.

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: A Systematic Approach to Learning Robot Programming with ROS

AUTOR: Wyatt S. Newman.

EDITORIAL: CRC Press (Routeledge)

AÑO: 2017 

ISBN: 978-1498777827
PAGINAS: 530

Metodología para Machine Learning (I): CRISP-DM

Desde hace muchos años, muchos, cuando se intentó, con un éxito yo diría que mediano, convertir la ingeniería de software en eso, una ingeniería, y hacer de la creación, despliegue y operación del software un proceso productivo más o menos similar al industrial, se han intentado definir metodologías que consigan esa operativización. 

Desde las primeras metodologías funcionales, seguidas de las orientadas a objetos todas ellas bajo el marco, en general, del algo injustamente denostado modelo en cascada, hasta los modernos (bueno, en realidad tampoco tan modernos) enfoques agile en que se pierde parte de esa visión industrial y de línea de producción para centrarse en un enfoque más adaptativo, se ha intentado estructurar el proceso de definición, construcción, despliegue y operación.

Ingeniería software y necesidad de adaptaciones

El caso es que, el software se encuentra hoy en día omnipresente. Pero esa omnipresencia hace que existan variantes del software de circunstancias bastante diferenciadas que parecen reclamar ciertas adaptaciones metodológicas. Por ejemplo, la creciente introducción de características 'low-code' o 'no-code' apuntan a la necesidad de una cierta revisión (quizá ligera) a unas metodologías pensadas para un proceso productivo que en su mayor parte tenía que ver con la edición de código fuente, compilación y prueba.

Igualmente el éxito creciente del modelo DevOps supone en sí mismo una cierta adaptación o reflexión sobre la metodología tradicional.

En realidad, al menos hasta donde yo lo percibo, esas revisiones no afectan realmente al 'core' de las metodologías y sus planteamientos, ni de las tareas básicas a realizar, pero pueden llevar a ciertos ajustes o addendas. Así, por ejemplo, cuando se intentan definir metodologías para RPA (Robotic Process Automation) en el fondo, el marco general es el de la ingeniería de software (en general con un enfoque más predictivo que agile) pero con pequeños detalles, como la introducción de elementos de BPM (Business Process Management) o la definición, en el diseño, de los mecanismos de escalabilidad de robots. En el fondo, es básicamente ingeniería de software, más o menos la de siempre...pero con ciertas adaptaciones.

Metodología para ciencia de datos y machine learning

Un poco con esa idea, voy a resumir, en este artículo y alguno que siga, algunos planteamientos metodológicos relativos al machine learning y la ciencia de datos. No pretendo ser exhaustivo (para eso existen fuentes mucho más completas) sino, más bien, señalizar algunas metodologías o planteamientos que puede resultar interesante conocer. 

Si en el caso de RPA lo que de alguna manera marca la necesidad de revisión metodológica en su orientación a la automatización de procesos/tareas y su carácter low-code, en el caso del machine learning / ciencia de datos, lo que marca la diferencia son los datos y sus especiales necesidades de comprensión y procesamiento.

El modelo CRISP-DM

En el artículo de hoy voy a mencionar, brevemente el modelo CRISP-DM cuyas siglas significan Cross Industry Standard Process for data Mining, un modelo definido por NCR, Daimler Chrysler y SPSSS (actualmente integrada en IBM).

El hecho de que aparezca el termino Data Mining ya nos avisa de dos cosas. Por un lado de que se trata de un marco metodológico con ciertos años (se definió en 1999) y que está muy orientado a la analítica y la obtención de modelos basados en datos y no es un planteamiento tan válido, entiendo, para otros usos del machine learning y de la inteligencia artificial..

El caso es que, según nos explica Jaume Miralles en su libro 'Proyectos de Inteligencia Artificial', se trata, al menos así era en 2014, de la metodología más utilizada en Data Mining, aunque con ciertas adaptaciones dependiendo de si se emplea en una analítica descriptiva, machine learning, deep learning o con el uso de AutoML (del cual hablaremos en algún momento).

El modelo jerárquico de CRISP-DM

CRISP-DM establece fundamentalmente un modelo de proceso que es de naturaleza jerárquica, comenzando por el nivel fase y luego bajando a tareas genéricas, tareas específicas e instancias de proceso según se puede ver en la figura superior.

Descomposición de la fase 'Data Preparation'

A lo largo del documento de definición de la metodología 'CRISP-DM 1.0' se van desgranando esos diferentes niveles. A modo de ilustración se muestra el gráfico de descomposición de la fase de 'Data Preparation' en el que la fase se descompone en tareas genéricas como selección de datos, limpieza de datos, construcción de datos, integración de datos y formateado de datos.

Fases de CRISP-DM

Fases de CRISP-DM

El método propuesto por CRISP-DM incluye, en el nivel jerárquico superior, seis fases, a saber:

• Business Understanding: Se trata de entender los objetivos del proyecto y los requisitos desde un punto de vista de negocio y convertir esas necesidades en un plan de data mining.


• Data Understanding: Se realiza una recolección inicial de datos con la intención de familiarizarse con ellos, detectar problemas de calidad del dato, obtener ya alguna conclusión o 'insight' preliminar y, eventualmente, descubrir subconjuntos de datos interesantes.


• Data Preparation: Construye, a partir de los datos en bruto, los conjuntos de datos ('datasets') que alimentarán finalmente los modelos. Incluye la selección de datos, su limpieza, transformación, etc


• Modeling: Quizá la fase central (aunque no necesariamente la que más tiempo ocupa) y que consiste en la selección y aplicación de diferentes modelos de machine learning / data mining. Con frecuencia, y durante esta fase, se plantea la necesidad de retomar la fase anterior para adaptar o refinar datos.


• Evaluation: Se trata de valorar si los modelos construidos satisfacen las necesidades de negocio. Al final de esta fase se decide si los resultados obtenidos consiguen los objetivos perseguidos y si, por tanto, se puede pasar a desplegarlos.


• Deployment: Una fase más técnica y de software que consiste en desplegar los modelos definidos para que puedan ser usados ya en los procesos de análisis y decisión de la compañía.

Conclusión

Como se puede observar, algunas fases de CRISP-DM recuerdan a la de la ingeniería de software tradicional. Así, 'Business Understanding' no parece muy diferente del Ánálisis de requisitos 'de tda la vida'. En 'Evaluation' nos encontramos también con elementos similares a las pruebas de aceptación de usuario, especialmente en sus aspectos de validación de negocio y de decisión de 'go - no go' a producción. Y el 'Deployment' es plenamente un despliegue de software.

A cambio, y como elemento claramente diferencial, está todo el foco en los datos y modelos que ocupa las fases centrales.

Como casi todas las metodologías, en el fondo, se trata simplemente de orden y sentido común, sin que sorprendan las ideas, las fases o tareas que se proponen.

Pero, en el fondo, de eso es de lo que se trata: de poner orden y aplicar buenas prácticas. Ni más ni menos.

En próximos artículos, exploraremos algún otro planteamiento metodológico en el entorno de la ciencia de datos y el machine learning.

Cinco ideas para superar los mitos sobre la inteligencia artificial

Ya hemos advertido, creo que en repetidas ocasiones, del riesgo que supone para la tecnología en general, y para la inteligencia artificial en particular, un entendimiento inadecuado de su realidad y posibilidades en un futuro previsible.

Los errores de entendimiento no sólo dificultan su adopción (ya sea por crear expectativas erróneas u optimistas en exceso, lo que puede conducir a fracasos en la implantación, como por la creación de miedos exagerados o injustificados que generen prevención y resistencia.

En lo relativo a la inteligencia artificial y la robótica, es creo, notoria el exceso de imaginación existente y la cantidad de literatura fantasiosa y no fundamentada, que cae en los dos extremos que veíamos antes: el optimismo exagerado o, por el contrario, el miedo injustificado.

Cuando de lo que hablamos, en concreto, es de ética en inteligencia artificial, domina, creo, la visión pesimista, el miedo injustificado o, más bien, exagerado, debido en parte, todo hay que decirlo, también a unas expectativas técnicas infladas, que hacen concebir como posibles e incluso presentes o cercanos, escenarios muy lejos de nuestras posibilidades actuales, el más extremo de los cuales probablemente sea la famosa singularidad.

Es preciso recuperar el equilibro, la sensatez y el realismo. Es necesario para la implantación de la tecnología en el tejido productivo y social. Es necesario para generar una regulación, caso de ser precisa, que se ajuste a la realidad. Y es necesario a la hora de la reflexión ética que con frecuencia debería anteceder a la regulación.

Un poco en línea con ese equilibrio, y orientado sobre todo al estudio ético, me encuentro leyendo el libro 'AI Ethics' una propuesta de su autor, Mark Coeckelbergh, para superar mitos y centrarnos en lo importante. Los cinco puntos que conforman su propuesta son:

• Usar la filosofía y la ciencia para examinar de manera crítica las asunciones sobre la Inteligencia Artificial y el rol que juegan los humanos


• Examinar con más detalle lo que la Inteligencia Artificial actual hace en sus diferentes aplicaciones y usos.


• Debatir los problemas éticos y sociales más urgentes que se generan a partir de la Inteligencia Artificial tal y como es usada hoy en día


• Investigar políticas y directrices para el futuro próximo


• Cuestionarse si el foco que sobre la Inteligencia Artificial domina el discurso actual es realmente útil a la luz de otros problemas a que nos enfrentamos y si la inteligencia debe ser nuestro único punto de atención. Se refiere el autor en este punto a que pueden existir otro tipo de problemas (por ejemplo el medioambiental) que requieran mayor atención y más urgente.

Creo que, en resumen, se trata de una llamada, primero a reflexionar de manera fundamentada (punto uno) y segundo a hacerlo evitando visiones futuristas, sino centrándonos en lo que tenemos aquí y ahora.

Y estoy muy de acuerdo.

En la reflexión ética, quizá se pueda apuntar a una visión menos inmediata (evitando en cualquier caso la ciencia-ficción) pero, desde luego, en lo regulatorio, y en lo empresarial, sin dejar de prepararse para un eventual futuro, hay que centrarse en el presente y, sobre todo, en lo real, no en lo supuesto o imaginado. 

La Inteligencia Artificial como realización de las tesis de Platón

Siempre me han gustado las visiones multidisciplinares, transversales, la hibridación de ciencias en apariencia disjuntas. 

Visiones transversales

Aunque mi vocación nuclear es de naturaleza técnica (no en vano soy ingeniero), siempre me han atraído otras disciplinas, tanto de gestión (estrategia, marketing, etc) como de científicas (física, psicología, etc) como las así llamadas humanidades (literatura, filosofía, etc). 

Durante el último año o dos, y en parte impulsado por mi participación en dos organizaciones que unen las visiones tecnológicas y humanísticas, al tiempo que estudio con pasión automatización, inteligencia artificial y robótica también estoy profundizando, o al menos tomando contacto, con disciplinas como la ética, el derecho, la sociología o la antropología.

Las organizaciones a que me refiero, por si algún lector siente curiosidad, son el Foro de Humanismo Digital EOI y OdiseIA (Observatorio del Impacto Social y Ético de la Inteligencia Artificial).

Toda disciplina, toda ciencia, tiene su interés intrínseco y es valiosa por sí misma, pero las visiones transversales son enriquecedoras... y a veces sorprendentes e incluso retadoras.

Platón y la alegoría de la caverna

En este post quiero contar brevemente uno de esos hallazgos sorprendentes. Un hallazgo que une a la Inteligencia Artificial y Platón con su alegoría de la caverna.

En esencia (y que me perdonen los filósofos si no lo describo con demasiada exactitud ni extensión), la alegoría de la caverna habla de un grupo humano que vive el fondo de una caverna de la que no puede salir y que sólo percibe la realidad exterior a través de las sombras que les llegan por mor de una hoguera existente en la entrada.

En esta alegoría, las sombras representan el mundo sensible, lo que percibimos por los sentidos, mientras que el exterior de la caverna representa el mundo inteligible, el de las esencias y las ideas.

Las formas, las ideas son inmortales mientras que las cosas del mundo que son mudables.  Además, Platón ve el cuerpo como una prisión para el alma, la cual es inmortal. 

Una visión 'platónica' de la inteligencia artificial 

La visión transversal que motiva este post enlaza la Inteligencia Artificial con la esta concepción de Platón y la encuentro leyendo el libro 'AI Ethics' de Mark Coeckelbergh. Lo que Coeckelbergh afirma, al tiempo que habla sobre transhumanismo y trascendencia es:

More generally, when AI and related science and technology use mathematics to abstract more pure forms from the messy material world, this can be interpreted as a Platonic program realized by a technological means. The AI algorithm turns out to be a Platonic machine that extracts form (a model) from the (data) world of appearances.

Es decir, la inteligencia artificial (muy especialmente el machine learning, apunto yo) extrae la esencia (la forma, el mundo inteligible) como un modelo, a partir de manifestaciones del mundo (las sombras) representadas por los datos que permiten inferir o aprender ese modelo.

Entendido de esta forma, realmente el paralelismo entre la inteligencia artificial y las ideas de Platón me parece, a bote pronto, solo una atractivo y sugerente paralelismo, una bonita metáfora, como es la propia alegoría de la caverna, pero nada más.

Pero si se lleva al límite esa metáfora, como pudiera estar tentado de hacer un transhumanismo extremo (recuérdese que Coeckelbergh hace este comentario explicando, que no abogando por, el transhumanismo), se podría entender que la inteligencia artificial es un camino hacia la inmortalidad, hacia la liberación del cuerpo para concentrarse en alguna forma de alma. 

Llevarlo a ese punto, aparte de las innegables y evidentes connotaciones, casi diría tensiones o contradicciones, religiosas, filosóficas y éticas, sería realmente írsenos un poco la mano, más bien un mucho, habida cuenta de donde estamos realmente en inteligencia artificial, a menos a día de hoy.

Modelos de software en la nube y el impacto en sistemas cognitivos

A estas alturas, creo que es indudable el gran impacto, la gran transformación que a nivel de TI y de todo el mundo digital, ha tenido la nube, el cloud computing.

La evolución del cloud computing

Debo confesar que, cuando hace ya bastantes años oí hablar de este concepto por primera vez, no creí que llegara a ser tan revolucionario...pero sí que lo ha sido y lo va a seguir siendo.

En sus  primeras implementaciones prácticas, el cloud computing puso más énfasis, como heredero de los llamados hosting y housing, en todo lo relativo al hardware y la infraestructura, lo que posteriormente se ha reconvertido en los así llamados IaaS (Infrastructure as a Service) y PaaS (Platform as a Service).

Pero con todo y lo importante que desde un punto de vista de negocio y de operación TI es la externalización de la infraestructura y su paso del modelo de propiedad al de uso, creo que la transformación más profunda y su carácter impulsor de la transformación digital global viene dada por la prestación de capacidades de software desde la nube, una prestación que inicialmente se centraba en el modelo SaaS (Software as a Service), que viene a ser, por decirlo coloquialmente, como el alquiler de una aplicación completa pero que se extiende y completa posteriormente con la visión más orientada a servicios, derivada de la filosofía SOA (Service Oriented Architecture) y que con ingredientes adicionales ha dado lugar a las APIs web (típicamente REST), a los contenedores, a los microservicios y al concepto de Función como Servicio (FaaS, Functions as a Service), generando una panoplia de opciones caracterizadas todas ellas por su prestación desde la nube y en modo pago por uso y unas opciones que cada vez se orienta menos a la aplicación y más al servicio, la función y las APIs.

Modelos de software en la nube

Aunque no es el objetivo principal del libro, me ha gustado mucho, por lo compacto y clarificador, el esquema que al respecto de todas las opciones existentes, plantea Jaume Miralles en 'Proyectos de Inteligencia Artificial' y que, a su vez, se basa en el articulo '¿Qué modelo Cloud es el mejor para los desarrolladores?' escrito por Ana López Mancisidor y José Miguel Ordax en un blog de IBM.

El modelo es el que se muestra en la figura:

En ese modelo se observan 9 niveles de capacidades hardware y software que, de abajo a arriba son:

• Networking
• Almacenamiento
• Servidores
• Virtualización
• Sistema operativo
• Middleware
• Configuración del middleware
• Datos
• Aplicaciones

En esos niveles, se puede ver que los tres primeros (Networking, Almacenamiento y Servidores) se concentran más en los aspectos hardware; los siguientes se concentran el el software de plataforma (Virtualización, Sistema Operativo, Middleware y configuración del middleware) y los dos dos últimos (Datos y Aplicaciones) en las aplicaciones finales.

A su vez, el esquema muestra mediante un código de colores en quién recae la responsabilidad de cada uno de esos bloques (azul oscuro es el modelo tradicional, con responsabilidad por parte del cliente o usuario, y azul claro responsabilidad por parte de un proveedor de servicio).

Y con esas bases, los autores encajan seis modelos, que, en orden creciente de externalización y servitización (que no de orden cronológico de aparición en el mercado) son:

• Tradicional ('on premises'): el cliente usuario mantiene la propiedad y responsabilidad de todos los elementos y en sus propias instalaciones.


• IaaS (Infrastructure as a Service): El proveedor de servicio proporciona ya lo relativo al hardware (Networking, Almacenamiento y Servidores) y algo de virtualización.


• CaaS (Containers as a Service): Se introduce el concepto de contenedor y el proveedor del servicio se hace cargo ya del sistema operativo y el middleware.


• PaaS (Plataform as a Service): El proveedor de servicio se hace ya cargo de todo el software de plataforma, añadiendo al caso anterior la configuración del middleware.


• FaaS (Functions as a Service): En realidad no añade externalización ni servitización de ninguna capa, pero sí es cierto que la capa de aplicación y datos cambia y se convierte, de hecho, en lo que los autores denominan 'acciones y disparadores' puesto que, en el caso de FaaS, no existe una aplicación como tal, sino una serie de funciones autocontenidas.


• SaaS (Software as a Service): Supone la externalización y servitización completas donde toda la aplicación y los elementos inferiores necesarios es proporcionada por el proveedor de servicios.

En este esquema se indica que los modelos más a la izquierda proporcionan un mayor rendimiento y control por parte del cliente / usuario, mientras que los de la derecha tienen a proporcionar velocidades crecientes de desarrollo.

El impacto en sistemas cognitivos

¿Y por qué Jaume Miralles se detiene a hablar sobre cloud computing y los modelos de prestación de las capacidades software cuando su libro trata de inteligencia artificial y de proyectos de inteligencia artificial?

Pues porque el impacto de estos modelos en la nube es enorme en el caso de la implantación y popularización de la inteligencia artificial. Porque, como el autor también explica en su libro, con cierta frecuencia (aunque no siempre), cuando una empresa se plantea realizar un proyecto de inteligencia artificial no desarrolla las capacidades cognitivas por sí mismo sino que se apoya en capacidades ya existentes y disponibles normalmente en la nube bajo alguno de los esquemas mencionados o alguno similar, muy especialmente los esquemas en que el software no se ofrece como aplicación sino como servicios y APIs (como sucede, por ejemplo, en CaaS y FaaS). Esto es especialmente notorio cuando hablamos de capacidades tecnológicamente complejas y que precisan muchísimos datos de entrenamiento como pueden ser las relativas a procesamiento de lenguaje natural.

Cuando se buscan los motivos del éxito actual de la inteligencia artificial se apuntan a aspectos como el aumento de la capacidad de computación (y el uso de las GPUs), la aparición de nuevos algoritmos (sobre todo de deep learning) y la gran disponibilidad de datos. Todo ello es cierto, pero creo que no cabe menospreciar sino, bien al contrario, resaltar, la contribución que estos modelos de prestación de servicios cognitivos desde la nube están teniendo en la democratización de la Inteligencia Artificial poniendo capacidades muy avanzadas casi al alcance de cualquiera.

Un mapa de explicabilidad de algoritmos de inteligencia artificial

Uno de los atributos que se empieza a buscar en los algoritmos de inteligencia artificial es el de su explicabilidad, es decir, que se pueda saber, de alguna forma, cuál ha sido la 'línea de razonamiento' seguida por ese algoritmo para llegar a una conclusión.

Esa petición de explicabilidad se toma como una exigencia de carácter ético e incluso regulatorio.

El problema de la explicabilidad de los algoritmos

Hace un tiempo defendí en este blog que, al contrario de lo que se suele afirmar, los algoritmos de inteligencia artificial se explican perfectamente puesto que, en un momento dado, en un cierto estadio de aprendizaje, con una foto congelada de parámetros, su comportamiento es perfectamente determinista y con arreglo a reglas y parámetros perfectamente conocidos.

El problema de la explicabilidad reside, más bien, en que la forma en que la mayoría de los algoritmos podrían 'explicar su comportamiento', nada tiene nada que ver con el modo de razonamiento humano y, por tanto, a efectos prácticos es como si no se explicasen. No porque no lo hagan, sino porque no  entendemos la explicación.

¿Y cómo de importante es que un algoritmo sea explicable en términos humanos?

En mi último libro, 'Robots en la sombra', defiendo que la explicabilidad es importante en algoritmos que tratan problemas con dos características:

• Que nos importa mucho la decisión, porque nos impacta de manera notable en nuestras vidas
• Que las reglas de esa decisión no son cien por cien claras ni siquiera cuando la decisión las toma un humano

¿De qué tipo de decisiones hablamos?

Pues de cosas como la selección para un empleo, un diagnóstico médico, la concesión de un préstamo o un juicio. En todos estos casos, el resultado de la decisión nos importa mucho, pero las reglas de decisión no son cien por cien claras, no son absolutamente deterministas, tampoco cuando decide un humano.

Si las decisiones no nos importan mucho, nos contentamos con que el algoritmo tenga una tasa de acierto razonable, en general igual o superior a la de un humano. Y si las reglas seguidas fueran absolutamente claras y deterministas no necesitaríamos más explicación, puesto que las propias reglas deterministas nos dirían cuál es esa explicación. 

Así que queremos la explicabilidad, al menos en ciertos casos.

Y lo que ocurre es que algunas de las familias de algoritmos más potentes hoy en día, los que mayores avances están proporcionando, los que lo consiguen resultados con una mayor precisión (típicamente los que forman parte de la amplia familia del deep learning), no exhiben la explicabilidad deseada.

Un mapa de explicabilidad

El asunto de la explicabilidad de la Inteligencia Artificial se encuentra en plena investigación, pero unas de las estrategias que se han propuesto es la de sustituir un algoritmo no explicable por otro que sí lo sea y que produzca resultados equivalentes. La dificultad de esta estrategia es que esa equivalencia no es total ni mucho menos, que unos algoritmos son más potentes, o más precisos que otros o tienen capacidades propias que no exhiben otros. No existe, ni mucho menos, una total intercambiabilidad.

En ese sentido, y para orientar la decisión o al menos la comprensión, puede ser interesante disponer de un mapa de familias de algoritmos con su nivel de explicabilidad y su precisión relativas. Y eso es lo que me he encontrado leyendo el libro 'Proyectos de Inteligencia Artificial' de Jaume Miralles. El autor incluye la figura que se muestra abajo y que toma del 'DARPA XAI Project'. 

En ella se 'mapean' cinco familias de algoritmos en un plano bidimensional, una de cuyas dimensiones es la explicabilidad y la otra la precisión de las predicciones proporcionadas por el modelo. Podemos observar que, en general, y por desgracia, a mayor precisión menor explicabilidad y viceversa. También podemos ver cómo, en efecto, el deep learning se sitúa como una familia algorítmica de alta precisión pero muy baja explicabilidad. Y cómo, en el extremo contrario, nos encontramos con los árboles de decisión, la familia con mayor explicabilidad pero menor precisión.

En conclusión

El mapa es ilustrativo tanto para posicionar los algoritmos como, quizá aún más, para comprender que en estos momentos estamos en un momento difícil para la explicabilidad. Y es difícil porque la explicabilidad, caso de conseguirse, suele ser a costa de la precisión.

Y tampoco queremos renunciar a la precisión, a la innovación y al progreso tecnológico ¿no?

Confiemos y demos tiempo a los investigadores a ver si encuentran mejores soluciones.