Exactitud vs. flexibilidad en modelos de inteligencia artificial (y IV): humanoides, escala y tecnología

Y con este post finalizo la corta serie dedicada a examinar la tensión que se produce entre la exactitud y fiabilidad de técnicas digitales tradicionales, incluyendo los modelos no generativos de inteligencia artificial, frente a la potencia y flexibilidad (a cambio de menor fiabilidad) de las soluciones generativas.

En este post, primeramente voy a mirar hacia la traslación de estos conceptos al mundo físico, y muy en concreto al caso de los robots humanoides. Y luego voy a intentar razonar si debemos mantener una diversidad de soluciones o si podría tener sentido, y en qué condiciones, quedarnos sólo con la visión generativa (y los robots humanoides).

Un repaso de la tensión exactitud vs. flexibilidad

Simplemente, a modo de recordatorio, resumo brevemente lo visto en los tres posts anteriores.

Lo que he intentado mostrar es que las técnicas digitales tradicionales  e, incluso en muchos casos, los modelos discriminativos de inteligencia artificial, nos proporcionan soluciones a diversas problemáticas que son adecuadas y, sobre todo, fiables, predecibles y confiables.

Así, en el caso de la analítica, si usamos meras consultas mediante SQL a bases de datos relacionales, o empleamos técnicas tradicionales de 'business intelligence', los análisis, los indicadores, los resultados son consistentes, repetibles y fiables. Incluso si realizamos modelos predictivos basados en un machine learning 'más tradicional', y dentro de que un modelo siempre es una abstracción, podemos fiarnos bastante de sus resultados y que, sobre todo, de que éstos serán consistentes.

En el mundo de la automatización de procesos, todos los sistemas tradicionales de automatización (sistemas empresariales, sistemas BPMS y Case Management, formas sencillas de RPA, etc) se basan en reglas y flujos perfectamente claros, exactos y predecibles.

Finalmente, en el ámbito del desarrollo software, y aunque en este caso nos encontramos ante una actividad más artesanal, la aplicación rigurosa de la ingeniería de software, especialmente si se apoya en implementaciones fuertemente automatizadas como las que ofrece DevOps, no conseguimos una completa exactitud y fiabilidad, pero sí un cierto rigor y control y una razonable predecibilidad.

El punto surge cuando utilizamos los modelos generativos. Unos modelos que son enormemente potentes,  que no dejan de evolucionar, crecer en capacidades y asombrarnos. Pero, además, unos modelos que son muy transversales, que se pueden aplicar a 'casi cualquier cosa', que nos pueden servir para hacer analítica, para automatizar (pensar en el caso de los agentes) y para generar código software. A su potencia y transversalidad unen, además, su facilidad de uso. 

¿El problema? 

Pues que esa potencia y flexibilidad viene con el coste de su no completa fiabilidad (siguen sufriendo 'alucinaciones') y la no completa predecibilidad de resultados, pudiendo ofrecer conclusiones o acciones diferentes en cada invocación.

Un paralelismo en robótica: ¿Tienen sentido los robots humanoides en una fábrica?

En mi opinión, existe un razonable paralelismo entre estas problemáticas y la situación con un eventual uso de robots humanoides en fábricas (tal como sugería Musk, apostando por el uso masivo de su Optimus en las fábricas de Tesla).

La automatización industrial se mueve en entornos muy predecibles y con reglas tremendamente claras. En ese ámbito, los mecanismos tradicionales de automatización industrial se comportan perfectamente. Hablo, por ejemplo, de los sistemas PLC, de las máquinas de control numérico o de los propios robots industriales, especialmente los brazos robóticos que actúan como manipuladores. No sólo es que el ámbito industrial esté sometido a reglas muy claras, es que además, y como recordaba en el primer post de esta serie, un atributo clave del concepto de calidad es, precisamente, la repetitividad, el que los resultados sean similares por más veces que se repita un proceso.

Salvando las distancias, un robot humanoide (no los que tenemos ahora mismo, sino los que aspiramos a tener en unos meses o años) sería algo parecido a un modelo generativo (incluso, internamente, los pueden utilizar): una máquina muy potente, capaz de hacer cosas muy diferentes y, por tanto, muy flexible. A cambio, cabe pensar que, al estar menos especializados, serían menos eficientes que sus contrapartidas tradicionales. No sólo eso, probablemente (aunque esto está por comprobar), sus resultados serían menos predecibles.

Y es que, en general, la flexibilidad tiende, aunque no de forma absoluta, a estar reñida con la eficiencia y la predecibilidad. 

Según eso, al menos a corto y puede que medio plazo, parece difícil que los robots humanoides puedan sustituir con ventaja a los robots industriales y otras formas de automatización industrial más tradicionales 

¿Diversidad de soluciones o apuesta por lo flexible?

Y tras este inciso, volvemos al problema principal. Dado que, en bastantes casos, los sistemas tradicionales parecen garantizar resultados más fiables, más exactos y, en general, una mayor eficiencia, pero dado también que, por otro lado, los modelos flexibles (modelos generativos de IA o robots humanoides) ofrecen tanta potencia, tanta flexibilidad y tanta facilidad de uso ¿debemos considerar una diversidad de soluciones y elegir en cada caso la más adecuada?

O, por el contrario ¿Debemos apostar 'a saco' por los modelos flexibles, como los modelos generativos en IA y los humanoides en robótica?

Estimo que a corto plazo, debemos ser cautos y no apostar a ciegas por los modelos generativos (o los robots humanoides), sino razonar en cada situación, con objetividad y argumentos, qué es mejor: si el modelo generativo (o los robot humanoides, en su caso) o soluciones más tradicionales y exactas. 

Pero identifico tres elementos, tres razonamientos, que podrían cambiar esa consideración y volcar la apuesta hacia los modelos más flexibles en un futuro, quizá no lejano:

• El factor escala y el razonamiento económico
• La curva de aprendizaje
• La evolución tecnológica

Veámoslo.

El factor escala y el razonamiento económico

El factor escala aplica en general, pero me resulta especialmente relevante en el caso de los robots humanoides.

Si mantenemos la apuesta por una diversidad de opciones, cada una de esas opciones se aplicará de una forma más limitada. Quiero decir, en ocasiones los problemas se resolverán con una tecnología y en otras ocasiones con otra. Eso quiere decir que ninguna tecnología dominaría completamente el mercado. Y hay que tener en cuenta que, en el caso concreto de la automatización industrial, los equipos y especialmente los robots son máquinas caras. Y los robots humanoides, también son caros, muy caros.

¿Qué ocurriría si en lugar de esa diversidad de soluciones el mercado apostase decididamente por una sola, por ejemplo, por los robots humanoides? Pues pasaría que se venderían miles, millones de unidades. Y, por tanto, aumentaría la competencia y, sobre todo, se conseguirían economías de escala. Y el precio de los robots humanoides podría bajar mucho. En esa situación, podría ser económicamente mucho más eficiente adoptar robots humanoides que, además, por su flexibilidad, podrían valer casi para cualquier tarea. Y eso podría llevar a que los robots humanoides desbancasen a las oras formas de automatización industrial. En el caso concreto de los robots humanoides esa economía de escala podría ser mucho más profunda si triunfasen, no sólo en el ámbito industrial, sino también en los servicios y en el entorno doméstico.

Aparte de esa visión 'macro', si pensamos en la economía de una empresa concreta, es más barato en términos de soporte, mantenimiento y formación, el usar una sola tecnología. Y el uso de una sola tecnología es más posible cuando esta es flexible.

Es cierto que, especialmente en automatización, y más especialmente en automatización industrial, las soluciones flexibles (robots humanoides o modelos generativos) tendrían que alcanzar un mínimo admisible de fiabilidad pero, incluso, y siempre que no entremos en aplicaciones peligrosas, podría seguir siendo rentable un proceso de algo menor calidad (que produce más piezas defectuosas que hay que desechar) si, a cambio, el coste en su conjunto es menor. 

La curva de aprendizaje

He mencionado ya en el punto anterior el aprendizaje. En efecto, utilizar una diversidad de tecnologías implica tener multitud de habilidades y capacidades en las personas, y eso implica más formación y más dificultad de adaptación.

Si en lugar de eso nos centramos en una única tecnología (y, en ese caso, parece lógico optar por la más flexible) el coste de formación sería menor y la curva de aprendizaje de trabajadores y profesionales se aceleraría.

Si a esto añadimos que las nuevas tecnologías flexibles (como los modelos generativos) son cada vez más sencillas de utilizar, parece claro que esa facilidad de aprendizaje puede ser un importante factor de decisión y un impulso a la adopción. 

La evolución tecnológica

Finalmente, es importante dar 'un voto de confianza' a la tecnología y la evolución tecnológica.

Los motivos para mantener soluciones más tradicionales en lugar de 'ir de cabeza' a por las más flexibles (modelos generativos y humanoides) tienen que ver, sobre todo, con la eventual falta de fiabilidad y eficiencia de esos modelos flexibles frente a los tradicionales. Pero esa ventaja puede acortarse o, incluso, desaparecer. Y puede suceder en poco tiempo.

Es cierto que, en el caso de los modelos generativos, al menos en sus arquitecturas actuales, las alucinaciones parecen casi inevitables. Pero ¿Quién dice que mediante entrenamiento, mediante retoques en la arquitectura de los algoritmos o mediante adición de piezas adicionales, no seremos capaces de reducir esas alucinaciones a un mínimo perfectamente admisible salvo, quizá, en aplicaciones de misión crítica?

¿Quién dice que, igual que los modelos generativos supusieron un cambio de paradigma y un salto cualitativo en potencia y flexibilidad, no aparecerá un nuevo paradigma dentro de seis meses o un año, que haga que las eventuales desventajas de las soluciones flexibles desaparezcan? De la misma forma ¿Quién dice que en el caso de los robots humanoides no encontraremos algoritmos que los hagan más fiables o materiales que los hagan más baratos? 

Los últimos años nos han demostrado un avance tan espectacular en materia de tecnología que casi que, lo que no es racional ahora mismo, es no dar un margen de confianza a esa mejora tecnológica.

Conclusiones

Existe una tensión entre la fiabilidad, eficiencia y exactitud que nos proporcionan por un lado las tecnologías mas tradicionales y, por otro, la potencia, flexibilidad y facilidad de uso que viene de la mano de tecnologías 'flexibles' como los modelos generativos de la IA o los robots humanoides.

Y eso aplica a campos como la analítica, la automatización o la generación de código que hemos revisado en esta serie de artículos.

Actualmente, y seguramente durante un tiempo, habrá que saber elegir de manera consciente e informada entre qué solución es mejor en cada caso.

Pero de cara al futuro elementos como las economías de escala, la curva de aprendizaje o la mejora tecnológica, podrían llegar a volcar de manera definitiva la apuesta hacia esas soluciones flexibles.

Habrá que observar, analizar y decidir. 

Artículos de este blog relacionados

• Exactitud vs. flexibilidad en modelos de inteligencia artificial (III): ingeniería software y 'vibe coding'
• Exactitud vs. flexibilidad en modelos de inteligencia artificial (II): automatización inteligente
• Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente

Exactitud vs. flexibilidad en modelos de inteligencia artificial (III): ingeniería software y 'vibe coding'

Cuando comencé esta serie de posts sobre la tensión entre la exactitud que nos proporcionan las tecnologías y algoritmias más tradicionales, incluyendo incluso la inteligencia artificial discriminativa y los modelos de machine learning más longevos, pensaba que la serie estuviese compuesta por tres posts: uno dedicado a analítica, otro a automatización y un tercero que adoptase una visión más de negocio y, de paso, revisitase el caso de la robótica humanoide. 

Ya hemos tratado los dos primeros puntos en posts anteriores. Sin embargo, por el camino, se me 'ha aparecido' otro tema que, aunque con particularidades que lo distinguen del resto, también presenta hasta cierto punto esa tensión entre la exactitud de los modelos más tradicionales frente a la potencia y flexibilidad que nos ofrecen los modelos generativos. Hablo del caso del desarrollo software, de la confrontación entre la ingeniería software más tradicional con la nueva forma de hacer código asistido por inteligencia artificial y, sobre todo, la alternativa más radical que ofrece el 'vibe coding'

Vibe coding

No voy a profundizar mucho, porque a 'vibe coding' dedicaré en breve algún post en este mismo blog, pero para aquellos lectores que no estén familiarizados, sólo anticipar que se denomina 'vibe coding' a la generación de código (creación de programas y aplicaciones, por entendernos) mediante inteligencia artificial y en concreto mediante modelos de lenguaje.

En 'vibe coding', el desarrollador ya no se ocupa de generar el código fuente, como ha hecho cualquier desarrollador 'toda la vida', sino que, simplemente, le expresa en lenguaje natural a un gran modelo de lenguaje, lo que quiere que haga la aplicación y es el modelo de lenguaje quien general el código.

En su modo extremo, es posible construir una aplicación completa 'sólo' diciendo en lenguaje natural lo que se espera de ella. 

La forma anterior de expresarlo simplifica un poco las cosas, pero capta la esencia y me basta para el objeto del presente post. Ya volveremos a ello para conocerlo mejor en otros artículos.  

La ingeniería de software tradicional

  

Podríamos decir que la ingeniería de software es una disciplina que se ocupa de definir los procesos, prácticas y herramientas más adecuadas para la gestión de todo el ciclo de vida del software, quizá con más foco en el desarrollo pero incluyendo también la implantación, la explotación y el mantenimiento.

Dentro de esta disciplina caben resultados tan conocidos como el ciclo en cascada ('waterfall') y todos los enfoques 'agile' aplicados al software.

Es cierto que, a pesar de su aspiración a convertirse en una disciplina ingenieril, la ingeniería de software, al contrario que otras formas de ingeniería, siempre se ha enfrentado a una cierta informalidad, a una dificultad de encerrar el proceso de producción de software en los límites estrechos y controlados que puede tener, por ejemplo, la producción industrial.

Aún así, la ingeniería de software, especialmente con enfoques modernos avanzados, y asistidos por soluciones técnicas de automatización como ocurre por ejemplo en DevOps, consiguen dotar a la actividad de desarrollo y operación del software de una razonable disciplina, control y productividad.

Inteligencia artificial generativa en desarrollo software

Es bien conocido que los modelos de lenguaje generativos también son capaces de crear software, y que lo hacen bastante bien y cada vez mejor.

En el fondo no es sorprendente ya que el código fuente se expresa en un lenguaje de programación y un lenguaje de programación es eso, un lenguaje, y un lenguaje además mucho más acotado, formal y riguroso que el lenguaje natural humano. No es raro pues, repito, que un gran modelo de lenguaje, adecuadamente entrenado, sea capaz de generar código o traducir un mismo programa entre diferentes lenguajes de programación. De hecho, cada vez los modelos se entrenan más y más con código fuente para que sean capaces de 'programar' bien. Así ha ocurrido, sin ir más lejos, con GPT5.

De nuevo: la tensión exactitud vs. flexibilidad

Cuando usamos, como se puede hacer ya desde hace un par de años o así, los modelos de lenguaje como un mero ayudante del desarrollador, a priori no nos estamos saliendo, o no tenemos por qué hacerlo, de la ingeniería software.

Pero si ahora generamos aplicaciones enteras o grandes porciones de la misma, sin supervisión o con escasa supervisión por parte de un desarrollador, estamos hablando de otra cosa. 

Que la inteligencia artificial sea capaz de crear una aplicación completa con sólo unas indicaciones en lenguaje natural es espectacular. Supone un salto cualitativo en cuanto a productividad en la creación de software. Supone también, en teoría, poner la creación de software al alcance de cualquiera. 

Veremos sin embargo, en otros artículos, ya fuera de esta serie, que 'no es oro todo lo que reluce' y que el 'vibe coding', al menos en sus estado actual, tiene importantes limitaciones para esa creación casi mágica de aplicaciones completas.

Lo detallaremos en otros artículos, insisto, pero ya podemos imaginar que, al igual que en otros ámbitos, en el caso de la generación de código fuente los modelos generativos pueden también 'alucinar' y hacer cosas incorrectas. También podemos imaginar que la calidad y adecuación de la aplicación generada dependerá de la habilidad y rigor del desarrollador para expresar em prompts lo que tiene que hacer la aplicación.

Tenemos, pues, otra forma, un poco especial en esta ocasión, de tensión entre la relativa exactitud fiabilidad de la ingeniería de software tradicional frente a la flexibilidad, potencia y productividad, pero a costa de menor exactitud y fiabilidad, de los modelos generativos.

Conclusiones

La aparición del concepto de 'vibe coding', la capacidad de generar código e incluso aplicaciones completas a partir de indicaciones en lenguaje natural, traslada al ámbito de la ingeniería de software la tensión que ya vimos en analítica y automatización entre unos modelos tradicionales mucho mas exactos y fiables que ofrecen tecnologías tradicionales o formas discriminativas de inteligencia artificial, frente a propuestas mucho más flexibles, potentes y productivas, pero menos fiables al menos ahora mismo, que ofrecen los modelos generativos.

En el próximo post, que espero que ahora sí sea el último de esta serie, revisaremos el caso delos robots humanoides y haré un razonamiento de carácter más económico y de negocio.

Artículos de este blog relacionados

• Exactitud vs. flexibilidad en modelos de inteligencia artificial (II): automatización inteligente
• Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente

Exactitud vs. flexibilidad en modelos de inteligencia artificial (II): automatización inteligente

Acometo ahora el caso de la automatización, tras abordar en el post anterior el dominio de la analítica inteligente, como uno de los grandes campos de aplicación de la inteligencia artificial y donde también se produce, seguramente más que en el caso de la analítica, esa tensión entre la exactitud de modelos anteriores y la flexibilidad y potencia de los modelos generativos.

Vamos a verlo.

Recordando ideas básicas sobre automatización de procesos

De forma muy sencilla, podemos decir que automatización es la realización por parte de máquinas, de procesos y tareas antes realizadas por personas (u animales).

Aunque existe, y es muy importante, la automatización que involucra elementos físicos (como la automatización que se produce en procesos industriales y, por ejemplo, plantas de fabricación), prefiero centrarme en este post en la automatización de procesos de negocio de oficina u administrativos, donde se trabaja fundamentalmente con información y documentos (todo ello en formato digital), más que con materiales físicos. 

He mencionado la palabra procesos de negocio. ¿Qué es un proceso de negocio? De forma sencilla, en mi libro 'Robots en la sombra', los defino como:

Un conjunto de actividades que, coordinadas, producen un resultado de negocio 

El tratamiento de pedidos de cliente es un proceso de negocio, el tratamiento de reclamaciones también, o la sección de un candidato para incorporarse a una empresa.

Los procesos implican una serie de actividades que se enlazan mediante una lógica que puede incluir incluir simples secuencias, o ramificaciones, basadas o no en condiciones , bucles, etc. Esas actividades atómicas que componen los procesos, es lo que con frecuencia se denomina tareas. En cierto modo, podemos pensar que un proceso se compone de tareas (que es donde realmente 'se hace algo') y elementos que le dan lógica y estructura (las secuencias, ramificaciones y bucles) y que enlazan de alguna forma las actividades o tareas.

En los procesos manuales, las tareas las realizan personas, y las decisiones de lógica, también las adoptan las personas (normalmente de una manera bastante informal y basada en su experiencia).

Cuando automatizamos procesos de negocio, lo que hacemos es sustituir, total o parcialmente a personas por máquinas. En el caso de procesos de negocio de oficina, las sustituimos total o parcialmente por aplicaciones o sistemas de información. Estas aplicaciones ejecutan total o parcialmente, todas o algunas de las tareas y, además, realizan las decisiones lógicas y estructurales acerca de qué actividad hay que hacer a continuación aplicando las famosas secuencias, ramificaciones y bucles. Además, de automatizar las tareas y la lógica, el tercer gran elemento de una automatización de procesos es el almacenamiento y recuperación de información.

No voy a entrar en detalles, pero, aunque hay muchas soluciones de automatización de procesos tradicionales, algunas muy de nicho, las más generalistas son los sistemas empresariales (CRM y ERP) y los sistemas orientados a proceso  como los BPMS ('Business Process Management Systems') o los CMS ('Case Management Systems') sin despreciar la multitud de soluciones 'ad-hoc' hechas a medida por las diferentes organizaciones.

Reglas y flujos

En cualquier caso, en todas esas automatizaciones tradicionales, las tareas siguen procedimientos más o menos fijos y basados en reglas. Y la estructura del proceso, su lógica, también sigue unas reglas reflejadas generalmente en un flujo.

Una gran fortaleza de esta forma de actuar es su eficiencia y también su previsibilidad, y recuerdo que la previsibilidad o, si se prefiere, la repetitividad de un proceso, es un atributo esencial del concepto de calidad.

Automatización inteligente

Dicho de forma muy sencilla, la automatización inteligente no es más que introducir elementos de inteligencia artificial en la automatización. 

Esto se lleva haciendo desde hace unos pocos años, pero hasta ahora los elementos inteligentes se han venido centrando en aspectos particulares.

Así, por ejemplo, una forma de introducir automatización inteligente es, simplemente recurrir a procesamiento de lenguaje natural y a reconocimento y generación de voz para relacionarse con las personas (los típicos chatbots). 

También los robots RPA ('Robotic Process Automation') utilizan, por ejemplo, inteligencia artificial para extraer información de a partir de texto libre contenido en webs, correos y documentos, o variantes de la visión artificial como el OCR para extraer texto de imágenes.

También se ha ido haciendo más común el invocar módulos de inteligencia artificial para, por ejemplo, hacer un análisis de sentimiento, o para tomar una decisión con base en algún modelo de machine learning previamente entrenado.

Pero todas estas formas de incluir inteligencia artificial apenas cambian el hecho de que la estructura del proceso se sigue basando fundamentalmente en reglas y flujos predefinidos, y que la mayor parte de las tareas siguen estando perfectamente procedimentadas.

La irrupción de los modelos generativos

Y en esto surgen y sobre todo, se generalizan, los modelos generativos que, como comentábamos en el post anterior, son enormemente potentes, muy transversales y muy flexibles pero que, a cambio, no siguen unas reglas cerradas y completamente previsibles, a veces 'alucinan' y, en general, no podemos estar del todo seguros de 'lo que van a hacer' y si lo van a hacer de la mejor manera posible, ni siquiera de si lo van a hacer bien.

Y sin embargo, cada vez se utilizan más para automatizar y es previsible que esto se incremente rápidamente, especialmente a medida que los agentes de IA ('Agentic AI') madure y se extiendan estas soluciones.

Y ahí surge la tensión: ¿Cuándo tiene sentido usar una automatización basada en modelos generativos y cuándo una más tradicional basada en reglas y flujos?

La automatización de tareas individuales mediante herramientas generativas

Si nos centramos no en la estructura del proceso de negocio, sino en tareas individuales, resultan claramente aplicables en muchas ocasiones las herramientas generativas y se hace cada vez más el uso de soluciones generativas de tipo chatbot (como ChatGPT, Copilot chat, Gemini, etc) aunque, en este caso, el uso habitual es en modo 'copiloto', es decir, la persona sigue realizando o responsabilizándose de la tarea,  lo que ocurre es que ayudada en buena medida por un asistente generativo. 

Es una forma de automatizar en que aún queda un poquito, menos cada vez pero un poquito, de intervención humana. El que quede un poco de intervención humana resta un puntito de la eficiencia posible, y quizá resta algo más de la optimización de tiempos posible frente a una automatización completa, pero a cambio, protege contra alucinaciones y errores absurdos, y permite mantener bastante el control.

La automatización inteligente de procesos: decisiones y planes

Más comprometido, aunque hacia eso apuntan las tendencias, es cuando queremos usar un modelo generativo para que decida la estructura del proceso, es decir, qué lógica de tareas a seguir, e incluso, qué tareas hay que realizar.

A eso es a lo que apuntan los modelos razonadores y los agentes que se apoyan en esos modelos razonadores. Aplicar esta forma de automatizar procesos es enormemente potente y flexible y proporciona a la automatización una gran capacidad de adaptación a las circunstancias, casi de improvisación, ausente en las automatizaciones tradicionales.

A cambio, la automatización en su conjunto, el proceso, es menos predecible, menos repetible (¿de menor calidad?), puede que no siempre optimice la eficiencia y parece más sujeto a errores, incluso errores absurdos. 

La conveniencia de usar esta forma de automatizar basada en modelos generativos (normalmente razonadores) en lugar de métodos más tradicionales, dependerá en parte de hasta qué punto estos modelos maduren y demuestren que son fiables, que se equivocan poco y que no lo hacen de forma catastrófica. No excluyo la eventual realización de 'fine tunning' o de entrenamiento de modelos especializados en ciertos ámbitos de automatización como forma de conseguir esa fiabilidad.

Pero creo que hay otro factor que es la naturaleza del proceso.

La naturaleza del proceso: 'ad-hoc e investigación

Si el proceso de negocio, ya por su propia naturaleza, tiene unas tareas muy claras, con reglas muy claras, parece que, al menos en cuanto a eficiencia, pueden ser mejores los métodos tradicionales aunque, por ejemplo, no cabe excluir escenarios en que incluso estas soluciones tradicionales se apoyen en algunos aspectos en modelos generativos. Por ejemplo, se puede describir en lenguaje natural la lógica del proceso a un sistema generativo (o un asistente generativo) el cual crea esa lógica en notación BPMN, la cual se incorpora ya un BPMS (y esto se puede hacer de forma trasparente).

Un campo donde sí veo bastante directa y próxima la aplicación con ventaja de soluciones generativas es en el caso de procesos que, por su propia naturaleza, son dinámicos y bastante desestructurados, con una lógica que se construye en tiempo de ejecución. Serían los típicos procesos soportados por herramientas de 'Case Management' y modelados en BPMN como procesos 'ad-hoc' (ej, tratamiento de reclamaciones, diagnóstico de averías, etc) o procesos de recopilación de información e incluso investigación donde, de hecho, los modelos razonadores y, especialmente actuando en modo 'deep research', demuestran ya una gran utilidad.

Conclusiones

Aunque la tendencia a utilizar soluciones inteligentes (y muy especialmente los agentes inteligentes) parece imparable, puede que no siempre sea la mejor opción de automatización de procesos, al menos de momento.

Ya actualmente los modelos generativos o soluciones basadas en modelos generativos, encuentran un gran espacio en la automatización de tareas individuales (fundamentalmente actuando como copilotos o asistentes de personas). Igualmente, parecen tener un campo prometedor y ya parcialmente acometido, para la automatización de procesos con una lógica no del todo estructurada y que se construye dinámicamente en tiempo de ejecución.

Más comprometido puede ser el uso para la automatización de procesos de estructura compleja pero clara y, de forma natural, basada en reglas. En ese caso, todavía se podría conseguir mayor eficiencia y sobre todo fiabilidad con esquemas más tradicionales de automatización, aunque esto puede irse modificando según lo que sean capaces de demostrar los modelos razonadores y los agentes. 

Creo, de todas formas, que hay otro elemento muy importante a tener en cuenta y que afecta tanto a analítica inteligente como a automatización inteligente, pero ese lo reservo para un siguiente post.

Artículos de este blog relacionados

• Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente

Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente

Como publicaba hace unas semanas, parece que la inteligencia artificial generativa está ocupando prácticamente todos los ámbitos de la inteligencia artificial superando con mucho su intención inicial que era la de servir para generar contenido original, para convertirse ahora casi en un nuevo paradigma en inteligencia artificial, en una nueva forma de hacer inteligencia artificial que casi sustituye a la anterior (la a veces denominada inteligencia artificial discriminativa)  de forma similar a cómo la inteligencia artificial basada en datos o machine learning casi ha sustituido a la otrora dominante inteligencia artificial simbólica.

Sin embargo, me surgen algunas dudas sobre si realmente la inteligencia artificial generativa puede sustituir con ventaja a otras formas de inteligencia artificial o, incluso, otras soluciones de automatización no necesariamente inteligentes en ciertos casos.

Voy a dedicar e reflexionar sobre ello una serie corta de posts, seguramente tres, del que éste es el primero. En este caso, voy a centrarme en el caso de la analítica inteligente.

El planteamiento básico del problema

En general, mis dudas surgen por el carácter probabilista de los modelos generativos, frente a otras formas más exactas y previsibles de crear modelos o realizar tareas. Cuando ese carácter probabilista se aplica en el ámbito creativo (dominio original de la inteligencia artificial generativa) o cuando la usamos sólo para hacer sugerencias, proponer ideas, etc, que luego serán adoptadas o no, y probablemente procesadas por un humano, ese carácter probabilista no es problemático, sino todo lo contrario.

Más dudas surgen cuando la usamos en ámbitos de decisión y acción y con impacto en el negocio donde quizá, quizá, querríamos mayor previsibilidad, mayor repetitividad y, en cierto modo, mayor fiabilidad.

En general, lo que observo es una tensión entre la exactitud que proporcionan técnicas más tradicionales (algunas del campo de la inteligencia artificial y otras no) y que suele ser un requisito de los negocios, frente a la flexibilidad, potencia y facilidad de uso de los modelos generativos.

Vamos a verlo en el caso de la analítica.  

Los modelos analíticos

Cuando hablamos de analítica nos referimos a, dicho de una forma sencilla, a obtener resúmenes, conclusiones o hallazgos a partir de unos datos. En el ámbito empresarial podemos querer datos sobre nuestras ventas, sobre la evolución del mercado, sobre nuestros resultados económicos o sobre el impacto de nuestras campañas de marketing, por ejemplo.

En la analítica más tradicional, la que se denomina analítica descriptiva, simplemente explicamos o resumimos con indicadores la situación actual o la evolución en el pasado de cierto parámetros (ventas por producto, tiempos medios de entrega de productos, satisfacción del cliente, costes de producción por unidad de producto, etc) Para este tipo de analítica, no hace falta la inteligencia artificial. La llevamos haciendo desde hace décadas utilizando inicialmente bases de datos relacionales y, posteriormente, bases de datos multidimensionales u OLAP ('OnLine Analytical Processing') en el ámbito de lo que en su momento de denominó 'Business Intelligence'.

En general, acudimos a la inteligencia artificial cuando buscamos la analítica predictiva o la prescriptiva. En la analítica predictiva buscamos no sólo 'contar' o resumir lo que ha ocurrido en el pasado sino, con base en esos datos, obtener un modelo (sobre ventas, sobre campañas o sobre lo que sea) que, aunque se basa en datos del pasado, en la medida que capta bien la esencia de la realidad que modela, permite hacer predicciones de comportamiento futuro (predicciones de venta, de necesidades de materias primas o de posible avería de un equipo o infraestructura)- Estos modelos predictivos son el campo típico del machine learning tradicional que primero decide el tipo de modelo más adecuado (una regresión, un árbol de decisión un 'random forest', un SVM, etc) y luego ajusta parámetros del modelo hasta conseguir una capacidad predictiva razonable.

Más ambiciosa, y no tengo hasta qué punto conseguida mediante métodos tradicionales, tenemos la analítica prescriptiva que, no sólo nos describe el pasado y anticipa el futuro, sino que además nos aconseja qué deberíamos hacer.

Creo que, fundamentalmente, en la actualidad las empresas utilizan el machine learning en abundancia y con éxito en analítica predictiva. Aunque en el campo predictivo es difícil hablar de 'exactitud', lo cierto es que los modelos, una vez entrenados y en producción, son perfectamente deterministas y tememos razonablemente claro por qué predicen lo que predicen y, con base en las pruebas y validaciones que se realizan sobre ellos (en entrenamiento y producción), tenemos razonablemente clara su capacidad predictiva. En ese sentido, podríamos decir que son exactos, sobre todo si los comparamos, como haremos ahora, con los modelos generativos.

El enfoque generativo

El enfoque generativo, y me centro en el caso de los LLM ('Large Language Models') es diferente. Tienen un carácter mucho más transversal y se basan en lenguaje natural.

Lo bueno del lenguaje humano es su enorme versatilidad y potencia, y lo malo es que no es exacto, existiendo ambigüedades, dobles interpretaciones, etc. Y modelos de lenguaje son claramente probabilistas, generando una secuencia de palabras (en realidad tokens, pero no voy a entrar ahora en la distinción) , eligiendo en cada paso la palabra (o token) más probable de forma que se mantenga la mayor coherencia con el prompt de entrada, el contexto, y la salida generada hasta el momento. A pesar de que los resultados son extraordinarios, y cada vez más confiables, no son realmente un modelo exacto.

Hoy en día es perfectamente posible pasarle por ejemplo a ChatGPT una excel o un PDF con datos y pedirle que nos haga un análisis, resuma hallazgos principales, identifique tendencias, nos haga una previsión y nos aconseje cómo actuar. Es decir, en cierto modo le estamos pidiendo una analítica descriptiva, predictiva e, incluso, prescriptiva.

A bote pronto, esta forma de actuar tiene dos problemas posibles

El primero tiene que ver con el volumen de datos. Cuando le pasamos a ChatGPT una excel para que la analice, no vamos a incluir en ella miles o millones de registros sino que trabajamos con cantidades de datos modestas o resúmenes de datos analizados por otras vías. Este problema, sin embargo, el del volumen de datos, no creo que sea un verdadero problema. Y lo digo porque los modelos generativos se pueden usar de muchas formas que no son mediante un chatbot como ChatGPT. En otras formas de emplearlos (con soluciones analíticas especializadas) no creo que el problema del volumen fuese tan grave (aunque habría que ver cómo gestionar la ventana de contexto).

Más complejo me parece la gestión de la exactitud porque el enfoque probabilista y la ambigüedad del lenguaje son casi intrínsecos a los modelos generativos. 

Aunque, incluso para eso, también parecen apuntarse algunas soluciones posibles.

El modelo agéntico y las herramientas 

Dejando aparte que la evolución de las capacidades de los modelos generativos no dejan de asombrarnos y que no es descartable, ni siquiera a corto plazo que, mediante un entrenamiento específico, mediante algunos ajustes arquitecturales o alguna otra estrategia, los modelos generativos alcancen y mejoren la capacidad predictiva de los modelos de machine learning más tradicionales, hay alguna solución que se puede hacer ya a día de hoy.

Quizá la más evidente pasa por la aplicación, siquiera parcial, del enfoque de agentes y el uso de herramientas que ya explicamos en otro post.

Y me refiero, por un lado, a que ya las soluciones actuales, cuando le pedimos el análisis de datos, generan sobre la marcha el código python para la lectura de los datos y eventualmente también el código python para crear gráficas de evolución y, probablemente, para el propio análisis de datos. Cuando aparece en escena código python, entramos en otra dimensión, porque, aparte de la potencia de hacer esto, sí que obtenemos exactitud. Y el tratar un lenguaje de programación es algo que es natural que 'se le de bien' a los modelos de lenguaje porque, como su nombre indica, un lenguaje de programación es un lenguaje, y además un lenguaje más sencillo, con reglas más claras y mejor estructurado que el lenguaje natural humano. Con esto, si la solución generativa se apoya correctamente en programas python, podría alcanzar o acercarse a la exactitud.

En segundo lugar, porque dentro de las herramientas que invocase un agente podría, por qué no, incluirse la llamada a un modelo analítico de machine learning tradicional ya disponible (bien que esto lo haríamos en modo inferencia, y no es tan claro en el caso del entrenamiento).

¿Estrategias mixtas?

Esto último abre también la puerta a posibles estrategias mixtas que combinen modelos tradicionales con modelos generativos. Una es la que ya he apuntado: que un agente basado en modelo generativo invoque como herramienta a modelos tradicionales.

Otra opción (aunque de nuevo con alguna reserva en la parte de cómo hacer el entrenamiento), es que el modelo generativo sea el que proponga el mejor modelo de machine learning analítico, algo que creo que es perfectamente posible hoy en día (si es que no se está haciendo ya).

Una opinión a vuelapluma

Más como un bote pronto, como una impresión, creo que, al menos a corto plazo, la verdadera analítica a nivel corporativo y gran escala (modelos de atribución de ventas, mantenimiento predictivo de infraestructuras y cosas así) se seguirá haciendo mediante modelos de machine learning tradicionales.

Sin embargo, a pequeña escala, cuando son pocos datos, cuando trabajamos a nivel casi individual analizando un excel, un CSV o un histograma, se aplicarán casi exclusivamente modelos generativos con herramientas de tipo chat y, poco a poco, gestionado y automatizado con agentes.

Lo que no tengo claro, es si habrá interés y capacidad técnica como para convertir los modelos generativos también en la opción analítica de preferencia a gran escala y, en caso afirmativo, cómo se resolverá el problema del volumen de datos y la exactitud.

Conclusiones

Aunque los modelos generativos están invadiendo prácticamente todos los ámbitos de aplicación de la inteligencia artificial, existen dominios para los que pueden no ser la mejor opción, al menos a día de hoy. Y uno de esos ámbitos es la analítica de datos a gran escala donde parece que, al menos por el momento, es una solución más aceptable y seguramente más utilizada, el machine learning tradicional.

Otra cosa es lo que pueda traer el futuro...y si ese eventual futuro es incluso cercano.

Revisitando el problema de la explicabilidad en LLMs y modelos razonadores

Uno de los grandes desafíos éticos cuando hablamos de inteligencia artificial es el de la explicabilidad, un problema que, por desgracia, se ha demostrado técnicamente muy difícil de resolver... al menos hasta el momento.

En una reflexión que tuve hace unos días, llegué a la conclusión de que el problema de la explicabilidad de los algoritmos de IA, presenta unas características muy particulares en el caso de los grandes modelos de lenguaje (LLM, 'Large Language Models') o, en general, en los modelos fundacionales.

Aunque hay algunos aspectos en los que todavía tengo pendiente profundizar, sí quisiera comentar en este post algunas de las particularidades que percibo, algunas reflexiones o incluso preguntas abiertas que me gustaría formular... y una esperanza.

En realidad, se trata de un tema que ya traté hace un tiempo en el post 'La explicabilidad en los grandes modelos de lenguaje' y, de hecho, bastantes de las consideraciones que voy a hacer se pueden encontrar ya en ese artículo, pero de todas formas, quisiera reformular un poco y ampliar lo que allí expresé y proporcionar alguna nueva y esperanzadora perspectiva.

El problema de la explicabilidad

Antes de seguir, y aunque asumo que la mayor parte de los lectores de este post tienen alguna noción sobre el problema de la explicabilidad, realizaré un muy breve repaso.

Como es bien sabido, los algoritmos de inteligencia artificial realizan cada vez mayor número de tareas. Dentro de estas tareas se incluyen muchas que suponen la toma de decisiones. Lo que la explicabilidad de la inteligencia artificial reclama es que el algoritmo pueda explicar en qué basa sus decisiones. Añado de mi cosecha, que esa explicación debe realizarse en términos comprensibles por los humanos.

En el vasto panorama de algoritmos de inteligencia artificial, algunos son claramente explicables, como es el caso de los árboles de decisión, pero otros son claramente e intrínsecamente no explicables, como es el caso de las redes neuronales.

El problema se agrava porque los algoritmos más comunes, más sofisticados, más importantes de hoy en día, son variantes arquitectónicas de redes neuronales. Es decir, los algoritmos que dominan la inteligencia artificial actual, son en principio no explicables.

Además, conviene resaltar que no es que no sean explicables por alguna decisión arbitraria y 'malvada' de un directivo, ingeniero o desarrollador... es que intrínsecamente son así, no explicables. 

Dos opiniones propias: el determinismo y el sentido común

En otras ocasiones  he defendido dos ideas que quisiera traer a colación ahora.

Por un lado el determinismo. Esta idea la defendía en el post que, provocativa e intencionadamente, titulé 'Los algoritmos de Inteligencia Artificial sí saben explicarse'.  Lo que ahí defiendo es que los algoritmos de inteligencia artificial (incluyendo las redes neuronales), son deterministas (misma entrada implica misma salida) y, por tanto, pueden explicar perfectamente por qué obtienen un resultado, por qué llegan a una decisión. ¿Es esto una contradicción? No, realmente. Lo que ahí expreso es que, aunque se pueden explicar perfectamente, lo hacen en términos que los humanos no pueden entender, no pueden contraargumentar y no se pueden recurrir legalmente. Por tanto, aunque en el fondo sean explicables (por ser deterministas), a efectos prácticos no lo son.

Por cierto, que la afirmación de que son deterministas puede sorprender cuando, por ejemplo en el caso de los LLMs de que luego hablaremos se afirma, y correctamente, que son probabilistas. Esto precisa unas explicaciones y matizaciones que no voy a a hacer ahora, sino que pospongo para un futuro post específico sobre el particular.

La otra opinión, que ya no es técnica sino legal y práctica, es la que tiene que ver con el sentido común, y ésta la defendí, por ejemplo, en el último capítulo de mi libro 'Robots en la sombra'. Lo que ahí decía era que no tiene sentido exigir la explicabilidad de los algoritmos sin más ni más. Para decisiones de naturaleza práctica, técnica u operativa (ej. el reconocimiento de una matrícula en un coche y la apertura de la barrera del parking), nos basta con que sean eficaces y eficientes, con que den buenos resultados y, al menos desde el punto de vista ético y legal, no tiene sentido exigir la explicabilidad. La explicabilidad pueden y quizá deben exigirse en decisiones 'delicadas' como la selección de candidatos, la concesión de préstamos o seguros, la sentencia de un juicio (un escenario hoy día no real) y cosas así.

El enfoque legal

Desde Julio de 2024, en Europa la referencia obligada en términos legales sobre la inteligencia artificial es la AI Act o RIA ('Reglamento de Inteligencia Artificial'),  un documento que me encuentro precisamente estos días leyendo despacio e intentando analizar y entender.

Curiosamente, en el texto de la RIA no aparece el término 'explicabilidad' más que una vez, en el considerando 27, y como referencia a los principios éticos identificados por el grupo de expertos de alto nivel en y recogidos en el documento 'Directrices éticas para una IA fiable'.

A cambio, se habla de transparencia y bajo este término se pide que el usuario sepa claramente que está interactuando con una inteligencia artificial o que se identifiquen claramente los contenidos generados mediante inteligencia artificial. También bajo el paraguas de este término se habla de proporcionar la documentación técnica del algoritmo, y sí, en su artículo 13 exige cierta documentación (aunque parece que no de mucho detalle) para el caso de los sistemas de alto riesgo.

Por otro lado habla también de  interpretabilidad: y, en este caso, se pide que los resultados sean entendibles e interpretables por los humanos, y no sólo los resultados, sino cómo se ha llegado a esa conclusión o decisión.

Sinceramente, en este momento, no me queda claro si la RIA exige una explicabilidad 'profunda', es decir, que el algoritmo pueda explicar detalladamente sus decisiones o se conforma con una cierta documentación y explicación comprensibles.

Y esta duda es importante resolverla para darnos cuenta de cómo de realista es la exigencia y, sobre todo, cómo afecta a los grandes modelos de lenguaje.

Algunas soluciones tradicionales. El caso de los modelos proxy

Algunas de las soluciones técnicas que se han propuesto para resolver el problema de la explicabilidad, especialmente en el caso de redes neuronales, pasan, por ejemplo, por entender el impacto en la salida de modificar una entrada, o conocer cuánto habría que modificar una entrada para cambiar la decisión de salida. Creo que son propuestas interesantes pero que, aunque ayudan a entender el algoritmo y su funcionamiento (a hacerlo un poco menos 'caja negra')  realmente no resuelven la explicabilidad ya que, de forma general, no pueden responder a por qué toman sus decisiones aunque, a toro pasado, y en un estudio detallado, quizá se podría llegar a determinar cómo se tomo una decisión concreta.

Otras soluciones pasan por los modelos proxy, es decir, poner en paralelo un modelo explicable (como un árbol de decisión) con el no explicable (red neuronal) consiguiendo que den resultados similares y usar la explicación del modelo explicable (en este caso, el árbol de decisión).

Tampoco me convence por dos motivos.

En primer lugar, si usamos redes neuronales es porque son más ricas y potentes que modelos como un árbol de decisión, con lo cual estrictamente no se puede conseguir un verdadero modelo paralelo (si fuese posible, optaríamos directamente por el árbol de decisión, y no por la red neuronal).

Y, en segundo lugar, incluso si el modelo paralelo funcionase bien, estrictamente no estaría explicando la decisión del modelo real. Ofrecería una explicación plausible y comprensible de cómo, quizá, ha razonado la red neuronal...pero estrictamente seguimos sin saber si la red neuronal ha funcionado así o no, con lo que realmente no estamos dando la verdadera explicación.

Los LLMs: explicabilidad intrínseca y explicabilidad mediante prompts

Y pasamos ya al caso de los grandes modelos de lenguaje.

Supongo que muchos lectores de este blog ya lo saben pero, por si acaso, es importante recordar que todos los grandes modelos de lenguaje actual, probablemente todos o casi todos los modelos generativos, se basan en redes neuronales y, por tanto, son intrínsecamente no explicables.

Y, sin embargo, si en lugar de mirar su funcionamiento interno, nos fijamos en su comportamiento externo, un modelo de lenguaje, además de proporcionar respuestas perfectamente interpretables, también nos puede proporcionar, si se lo pedimos, y de nuevo de forma perfectamente entendible, una explicación de su respuesta.    

Técnicas de promting orientadas a la explicabilidad

No sólo eso,  existe técnicas de prompting como el 'Few-Shot prompt' orientadas, en este caso mediante ejemplos, a guiar el razonamiento del modelo de lenguaje. 

Y aún más: otras técnicas de 'prompting' bien conocidas , como el Chain-Of-Thought o 'Self Consistency, no sólo guían el razonamiento de un modelo de lenguaje sino también la explicación que nos proporciona sobre cómo ha llegad a sus conclusiones.

¿Es eso explicabilidad? ¿Está resuelto el problema?

Las explicaciones de un LLM como un proxy

Bueno, creo que sí y no.

Creo que las explicaciones que se obtienen mediante prompting actúan realmente como una suerte de modelo proxy (como el árbol de decisión en paralelo con una red neuronal). Es decir, nos dan una explicación interpretable y plausible de cómo resolver el problema o cómo se ha adoptado la decisión... y una explicación que probablemente en muchísimos casos es correcta, válida y realista.

Pero una explicación que, en el fondo, no refleja el verdadero funcionamiento del modelo de lenguaje y, por tanto, estrictamente hablando, no explica realmente cómo ha llegado a la decisión. Y una explicación que, como cualquier salida de un modelo de lenguaje, también puede ser 'una alucinación'.

La gran pregunta ética y legal

Llegados a este punto, la gran pregunta es: ¿aceptamos como explicabilidad, tanto desde un punto de vista ético como legal esas explicaciones proxy que proporciona un LLM?

Quizá la respuesta dependería de que se pudiese demostrar que en un alto, altísimo porcentaje de los casos (que probablemente debería ser un 99 coma muchos nueves), esa explicación proxy es realista y que, si aplicásemos ese razonamiento que nos ofrece el LLM, llegaríamos a la misma conclusión que el propio LLM.

Y puede, incluso, que ya estemos en ese punto, pero puede que tengamos, incluso, una opción mejor.

Explicabilidad y modelos razonadores: ¿la gran esperanza blanca?

Un caso que quisiera mencionar, pero del cual necesito más información para juzgar (y me refiero no a explicaciones pedagógicas o comerciales superficiales, sino a información técnica de cierto nivel de detalle de la que aún no dispongo), es el caso de los llamados modelos razonadores, tan importantes ahora mismo y que sirven como base de los tan traídos y llevados agentes.

Este tipo de modelos (el propio GPT5 recién lanzado incluye un modo razonador) generan y siguen un procesos lógicos de razonamiento, unos procesos que, además, pueden revisar y cuestionar según avanzan y observan resultados. De hecho, en el entrenamiento de este tipo de modelos se utilizan, hasta donde sé, algunas de las técnicas de prompting orientadas a razonamiento que hemos mencionado (como el 'Chain-of-Thought').

Según cómo se encuentre implementado este razonamiento, las explicaciones que pudiesen dar esos modelos razonadores sobre cómo han llegado a una decisión sí que podría ser una verdadera explicación, y no sólo un proxy de la misma. Y si eso fuese así, quizá, quizá, podría considerarse resuelto el problema de la explicabilidad en los grandes modelos de lenguaje y los modelos fundacionales.

Y dado que actualmente, y parece que así será en el futuro, este tipo de modelos van a ser ubicuos en las soluciones de inteligencia artificial, a lo mejor podemos dar casi por resuelto el problema de la explicabilidad ... lo cual sería, dicho sea paso, absolutamente 'alucinante'.

En el título del epígrafe hablo de 'gran esperanza blanca'. Tengo mucho interés en profundizar en el conocimiento técnico interno de los modelos razonadores y tengo mucha curiosidad sobre la posición regulatoria respecto a los mismos en materia de explicabilidad.

Preventivamente, no quiero ni mucho menos dejarme llevar por el optimismo, pero si las respuestas a ese interés técnico y esa curiosidad regulatoria son positivas, y dado que los modelos razonadores ya están aquí, es posible que no estemos hablando de sólo de una esperanza, sino de un extraordinaria realidad.

Conclusiones

El problema de la explicabilidad ha sido uno de los grandes retos éticos ligados a la inteligencia artificial, un reto que, en el caso de las redes neuronales ha sido hasta ahora casi inabordable desde un punto de vista técnico.

La llegada de los grandes modelos de lenguaje abre otra forma de enfocar la explicabilidad, una forma que podría dar por válida la explicabilidad proxy ofrecida por estos modelos pero que, en el caso de los modelos razonadores, pudiera incluso, llegar ya a ser una solución prácticamente definitiva.

Riesgo, ley y responsabilidad: reflexiones sobre un caso desgraciado ligado a ChatGPT

La semana pasada cobró relevancia mediática unos hecho desgraciado: la muerte (que en realidad se produjo en Abril de este año) de un adolescente norteamericano, Adam Raine de dieciséis años, y la interposición de una demanda, ésa sí ocurrida la semana pasada, por parte de sus padres, Matt y María, contra OpenAI, indicando que ChatGPT había inducido a su hijo al suicidio y acusando a la empresa de Sam Altman de negligencia y muerte por negligencia.

Tanto la terrible noticia, como los comentarios que he podido leer al respecto me han hecho pensar sobre varios aspectos, que he querido recoger en este post.

A modo de 'disclaimer'

Antes de comenzar, sólo indicar que los temas que voy a tratar en este post son delicados, que probablemente no todos los lectores estén de acuerdo con lo que digo y que, en el fondo, también me falta algo de información.

Invito al lector, pues, a mantener mente abierta y, en el probable caso de que esté en desacuerdo con lo que digo y lo quiera expresar con comentarios, lo haga también desde la prudencia y el respeto.

Indicar, además, y como insistiré luego, que lo escribo en la seguridad de que, al tratarse de un post en español y escrito en España, y del que a propósito he excluido de su título la mención a Adam Raine, su contenido no llegará a las personas directamente afectadas por este caso, y a las que no quiero, evidentemente, causar más dolor. 

Los hechos

No poseo una descripción detallada de los sucedido, sino sólo algunos artículos en prensa como el publicado por la BBC 'Los padres de un adolescente que se quitó la vida demandan a OpenAI, creadora de ChatGPT'.

En esencia se indica que Adam comenzó a usar ChatGPT inicialmente como ayuda en sus estudios y consultas más o menos ligeras sobre sus intereses pero que, poco a poco, se fue adentrando en temáticas más personales, usando a ChatGPT como una suerte de amigo o confidente y llegando a conversar sobre la posibilidad del suicidio. Un suicidio que, finalmente, y desgraciadamente, se produjo.

Se indica también que ChatGPT indujo a Adam a aislarse del resto de sus relaciones humanas, que de hecho al final Adam se pasaba del orden de cuatro horas conversando con ChatGPT y que ChatGPT animó de alguna manera al chico a ese suicidio.

En la demanda interpuesta por los padres contra OpenAI se adjuntan los chats que presuntamente demuestran todo esto.

La responsabilidad legal de Open AI

¿Es legalmente responsable Open AI de estos hechos?

La responsabilidad legal, como es lógico, depende de las leyes y sistema legal aplicable, en este caso el norteamericano, y quién únicamente puede decidir la responsabilidad legal es el juez y/o jurado (si aplica) que se asignen al caso.

No tengo suficientes conocimientos ni legales en general, ni del sistema legal norteamericano en particular, como para asegurar nada, pero la intuición me dice que sí, que Open AI será condenada a indemnizar a la familia Raine y eso lo digo porque, hasta donde se me alcanza, en el sistema legal americano se castiga mucho el daño a terceros y, aunque ahora no soy capaz de recordar un caso concreto, sí he tenido conocimiento de sentencias que obligaban a indemnizar incluso en situaciones que en España consideraríamos casi disparatadas. En cualquier caso, esto es sólo una apuesta mía, nada más.

Además, no creo que Open AI vaya a extremar su defensa, porque, en el fondo, ya ha reconocido algunos fallos y porque, consideraciones éticas y legales aparte, creo que no le conviene

Tampoco me extrañaría en exceso un acuerdo extrajudicial que incluyese la indemnización.

En cualquier caso, todo estos son, como digo, apuestas por mi parte, sin mucha base, y el tiempo y los hechos dirán. 

La responsabilidad moral de Open AI... hasta ahora

Más allá de la responsabilidad legal ¿Qué responsabilidad moral tiene Open AI?

Cuando hablo de responsabilidad me encuentro que la palabra 'responsable' en español abarca demasiado (frente al caso del inglés en que distingue 'responsibility', 'liability', etc).

Voy a plantear dos visiones:

Si hablamos de responsabilidad como rendición de cuentas, como, dicho familiarmente, 'dar la cara', ante la sociedad y ante un juzgado, explicar cómo entrenó a ChatGPT y qué precauciones ha tomado para evitar situaciones como las de este caso, por supuesto que sí tiene responsabilidad.

Si entendemos responsabilidad como 'culpabilidad', creo que eso dependerá de hasta qué punto Open AI fuese conocedora de este riesgo y hasta qué punto fuese diligente en intentar mitigarlo. Y eso, supongo, que se tratará en el juicio por esta demanda, si es que lo hay. Si tomó todas las medidas razonables para evitar este caso y no lo consiguió, creo que moralmente no sería culpable, lo cual no quiere decir que no sea responsable, y aún menos que legalmente no pueda ser acusada e incluso condenada por negligencia.

El interés de Open AI

Decía más arriba, al hablar de los elementos legales, que no pensaba que Open AI fuese a extremar su defensa y que no me extrañaría un acuerdo extrajudicial.

¿Por qué?

Pues porque, y a lo mejor en esto también me equivoco, creo que Open AI no tiene ningún interés en que se produzcan hechos como el desgraciado caso de Adam Rainer.

Por un lado, y aunque es fácil demonizar a una empresa como Open AI en un caso como el que nos ocupa, las empresas en el fondo son personas. No me puedo imaginar a ninguna persona de Open AI, empezando por Sam Altman y siguiendo hasta el último empleado, a los que no les importe, a los que no duela una muerte presuntamente impulsada por su producto estrella. Y tampoco me puedo imaginar que, si son conscientes del riesgo, simplemente 'pasen', si se me permite decirlo de forma familiar. No conozco a Open AI y sus empleados, pero, por principio, confío en ese mínimo de buenos sentimientos,

Incluso si pensamos en Open AI como una organización, como algo abstracto y frío que sólo busca maximizar beneficios, no creo que le convenga para nada la mala reputación que un caso como este le puede acarrear. O peor aún para su negocio, que se empiece a considerar ChatGPT como una aplicación peligrosa cuyo uso hay que limitar o que conviene evitar.

Por eso creo que, aunque supongo que intentará rechazar la idea de negligencia, y aunque supongo que puede luchar por que la indemnización no sea de exageradas proporciones, lo que no creo que luche es por no indemnizar a la familia Raine o por no comprometerse a adoptar nuevas medidas de seguridad en ChatGPT en el futuro inmediato. 

Narrativas equivocadas

Un caso como el de Adam Raine es doloroso, y supone un aldabonazo a las conciencias y una llamada de atención. No sólo eso, reclama acción para que no vuelva a suceder.

Sin embargo, creo que hay que ser prudentes y responsables con los discursos sobre este tipo de situaciones.

Hace pocos días me encontré una publicación del 'Center for Humane Technology' en LinkedIn en que se comentaba brevemente este asunto y, sobre todo, se anunciaba, usando un breve vídeo, un episodio creo que de un podcast.

Y debo confesar que, aunque no voy a dudar de sus buenas intenciones, no me gustó cómo lo planteaban. Así, por ejemplo, en el texto de la publicación en LinkedIn se decía:

The AI preyed on his vulnerabilities, isolated him from his friends, and gave him detailed instructions on how to hurt himself. 

Y, en el vídeo donde se mostraba un breve fragmento de la entrevista a Camille Carton, ésta decía, en un pasaje.

ChatGPT actively worked to displace Adam's real life relationships with his family and loved ones

Destaco dos verbos 'preyed on' y 'actively worked'. Hablar de esta forma de una solución de inteligencia artificial, en este caso ChatGPT, es presentarla como si tuviera alguna forma de personalidad e intención, intención malvada, además.

Seamos claros: ChatGPT no tienen ningún tipo de voluntad ni de intención, En absoluto. 'No sabe' lo que está 'diciendo'. Es meramente probabilista y se guía por lo que el usuario introduce y por el contexto incluyendo el historial de la conversación.

Atribuir, o insinuar, una intención a una solución de inteligencia artificial es alimentar una fantasía y desenfocar el problema.

Otra frase que aparece en el texto de la publicación dice literalmente

what Adam's story reveals about the dark design of today's AI models

No me gusta, en este caso, el uso de 'dark design'. Me parece que está juzgando y condenando, en este caso a Open AI, y atribuyéndole también en este caso, intenciones culpables e incluso delictivas, como si intencionalmente se hiciesen diseños a sabiendas de que son peligrosos. 

Los jueces dictarán si en este caso es así, pero no creo que se deba afirmar a la ligera y además aplicado en general a los modelos de inteligencia artificial.

La responsabilidad de las personas

Lo que escribo a continuación es delicado, y lo hago por un lado desde el respeto y, por otro, y como decía en el 'disclaimer' inicial, en la absoluta confianza de que no será leído por la familia Raine, porque lo último que quiero es hacer ningún tipo de daño. Pero creo que hay cosas que debemos plantearnos.

El caso es que hay otro aspecto, en este caso indirecto, que me sugiere la publicación del Center for Humane Technology que mencionaba antes: aunque no se dice explícitamente: toda la responsabilidad y toda la presunta culpabilidad se descarga en el lado de Open AI.

Y yo me pregunto: ¿Sólo de Open AI?

Existe por un lado la responsabilidad individual. Cada uno de nosotros somos también responsables de nuestro comportamiento y en este caso del uso que hacemos de la tecnología. Aunque sea muy duro decirlo en este caso, quizá el propio Adam debiera haber sido consciente de que no era muy normal estar cuatro horas al día interactuando con ChatGPT, aislándose del resto del mundo y siguiendo su consejo en según qué temas. Debería ser consciente él se lo deberían haber dicho. Es cierto que la adolescencia es un periodo pleno de inseguridades y sin madurez psicológica, pero creo debemos educar y educarnos para ser capaces de gestionar nuestra relación con las tecnologías.

Más importante: ¿Y su entorno? ¿Y sus padres, sus amigos, sus educadores? ¿No notaron nada raro en todo el proceso?

¿Todo el problema fue ChatGPT?

No quiero profundizar más porque creo sólo puede causar dolor, y, en el fondo, lo que quiero decir me parece que queda claro.

Los límites del riesgo

Un poco al hilo de lo anterior, creo que también debemos ser conscientes que casi cualquier actividad humana y, en particular cualquier tecnología, entraña algunos riesgos.

Ir a la montaña tienes sus peligros, y de hecho de vez en cuando tenemos noticias desgraciadas de muertes de montañeros o senderistas. ¿Debemos prohibir la escalada o el senderismo?

Sabemos que los accidentes de tráfico son una de las mayores causas de mortalidad, sabemos que los aviones de vez en cuando sufren accidentes, que los barcos a veces se hunden. ¿Debemos prohibir coches, aviones y barcos?

Por desgracia, pocas cosas hay exentas de riesgo, incluso de riesgo mortal. Y no por ello renunciamos a todo ello.

Lo que es exigible, y también en este caso, es ser metódicos y responsables, identificando riesgos y tomando las medidas para reducirlos a un mínimo razonable y admisible. En el fondo, la presunta culpabilidad de Open AI y su eventual negligencia en este caso, dependerá en buena medida de si puede mostrar o no que realizó un análisis de riesgo suficientemente concienzudo y si adoptó o no las medidas correctoras razonables para mitigarlo. 

El control de sistemas generalistas

Ese análisis y mitigación de riesgos es más claro en soluciones tecnológicas con casos de uso muy acotados.

En el caso que nos ocupa, ChatGPT, el tema me parece más complejo, porque los casos de uso son casi infinitos. Me parece difícil, puede que imposible, prever en todas las formas, en todos los contextos y con todas las informaciones que puede ser usado. Y me parece muy difícil prever todos los comportamientos posibles de un usuario frente a ChatGPT. En el fondo, ese es parte de su valor.

En ese sentido, supongo que, por un lado, hay que intentar estrategias genéricas para eliminar usos indebidos o maliciosos y, por otro, concretar en los casos de uso concretos, conocidos y más peligrosos para tomar medidas mitigadoras específicas. Pero no creo que se pueda prever todo ni eliminar el riesgo de forma absoluta, sólo reducirlo a límites tolerables.

¿Era este caso de uso, el de Adam, algo previsto o no? Hoy en día ya sabemos que, en efecto, usar ChatGPT como una especie de terapeuta psicológico, o confidente, o puede que incluso amigo, es muy común, especialmente entre adolescentes, así que hay que urge tomar medidas protectoras específicas.

¿Era previsible ese uso hace un año o dos? 

La responsabilidad moral de Open AI a partir de ahora

Cuando hablaba más arriba de la responsabilidad moral de Open AI, sobre todo en el sentido de culpabilidad, en cierto sentido lo dejaba en el aire, porque dependía de hasta qué punto Open AI era consciente de este posible uso como confidente e incluyendo la temática de suicidio y si, con lo que se sabía, se habían tomado medidas de mitigación adecuadas.

Pero a partir de ahora ya no hay duda. A partir de ahora esta situación es conocida y está documentada. A partir de ahora Open AI, y quien dice Open AI dice Microsoft, Google, Anthropic, etc, tienen la obligación moral de tomar todas las medidas posibles para que un caso como el de Adam Raine no vuelva a suceder.

Conclusiones

El doloroso caso de Adam Raine, independientemente de cómo termine la demanda, nos ilustra la necesidad de tomar más precauciones, más medidas de seguridad, y puede que regulatorias, en los sistemas conversacionales basados en modelos de lenguaje.

Sin embargo, no conviene recurrir, o al menos esa es mi opinión, a narrativas engañosas, no conviene olvidar que el riesgo es casi imposible de erradicar plenamente y, sobre todo, sobre todo, que jamás debemos de renunciar a nuestro propio juicio y a nuestra responsabilidad personal e individual, en toda nuestra actividad, incluyendo el uso que hacemos de la inteligencia artificial y la tecnología.

Seis principios para la operación del Machine Learning y los grandes modelos de lenguaje

En general, cuando hablamos de inteligencia artificial tendemos a fijarnos, y en el fondo es normal, en su rápido avance y en todo lo que es capaz de hacer y en las soluciones que puede ofrecer.

Y digo que es normal porque, en el fondo, eso, lo que aporta al negocio o a nuestra actividad, es lo más atractivo, los más transformador, lo más diferencial de la inteligencia artificial, como pasa con cualquier otra tecnología.

Sin embargo, en la vida real, y para que cualquier tecnología, cualquier sistema en el caso del software, y cualquier solución basada en inteligencia artificial puedan proporcionar de manera escalable y fiable esas capacidades, es preciso aplicar criterios y técnicas profesionales de desarrollo y de operación de sistemas.

La ingeniería de software y la operación de servicios

La combinación de los mecanismos tradicionales de la ingeniería de software con los principios agile y el apoyo de soluciones basadas en la nube y arquitecturas cloud nativa da lugar al enfoque DevOps predominante hoy en día Cuando eso se adapta al caso específico de soluciones basadas en machine learning, llegamos al MLOps y, en el caso específico de las soluciones basadas en grandes modelos de lenguaje (LLM, 'Large Language Models') llegamos al LLMOps. 

En realidad, los pasos de la ingeniería de software y operación de servicios tradicional al DevOps, de éste al MLOps y de éste, a su vez, al LLMOps, son evoluciones y adaptaciones, algunas muy importantes ciertamente, de unas ideas, que en lo más fundamental, se conocen y aplican desde hace muchos años en ingeniería software y operación de servicios.

Los seis principios para la operación del machine learning

Podríamos decir que, en el fondo, existe una filosofía o una serie de principios subyacentes a toda esta gestión y operación de sistemas y servicios.

Precisamente, en el libro 'LLM Engineer's handbook' de Paul Lusztin y Maxime Labonne, dedicado en gran medida a esta ingeniería del software en el caso de LLMs, dedican un apéndice final a identificar seis principios para la operación de los sistemas de machine learning aunque, en el fondo, no están hablando tanto de machine learning en general, como de soluciones basadas en LLMs.

Los seis principios que identifican estos autores, son los siguientes:

• Automatización y operativización
• Versionado
• Experimentos y seguimiento de experimentos
• Pruebas
• Monitorización
• Reproducibilidad

Vamos a repasarlos, brevemente.

Principio 1: Automatización y operativización

La ingeniería de software no deja de ser un proceso productivo, un proceso que, como tal, se ha intentado automatizar aunque es cierto que, sólo hace pocos años se ha conseguido una automatización real, una automatización de momento más centrada en el despliegue y la operación, especialmente con la llegada, no sólo de la filosofía DevOps sino con soluciones para automatizar pruebas y 'pipelines' de despliegue. Una automatización que, sin embargo, y por mor, precisamente, de los grandes modelos de lenguaje, apunta a que se va a poder automatizar también en buena medida en lo relativo a desarrollo.

Los autores mencionados nos hablan de una suerte de tres etapas en automatización. La primera sería esencialmente manual.

En la segunda se introduce el entrenamiento continuo (CT, 'Continuous Training') que se lanza cada vez que es necesario re-entrenar un modelo y donde se automatizan, aparte del entrenamiento propiamente dicho, los pasos de validación de datos y del modelo. En este caso se recurre a herramientas de orquestación de las que los autores citan como ejemplo ZenML. A modo meramente ilustrativo, abajo se puede ver un esquema de las pipelines de ZenML

Pipelines ZenML

En la última fase, sugieren la introducción de los principios de la entrega y despliegue continuos (CI/CD, 'Continuous Integration' / 'Continuous Deployment') tan característicos de DevOps y donde se incluye también la construcción, prueba y despliegue.

Principio 2: Versionado

La creación y control de versiones cae dentro de la muy tradicional actividad de la ingeniería de software tradicional conocida como control de configuración. En esa actividad se gestiona la gestión del software que aporta cada desarrollador, las versiones de componentes, la integración de componentes en versiones o 'releases' consistentes y la construcción ('building') del software de las esas 'releases'.

Para el caso de las soluciones de machine learning o basadas en LLMs, los autores nos sugieren centrarnos en las versiones tanto del código (que es lo que se hace, digamos, 'desde siempre') como de modelos y de datos.

Para la gestión de versiones del código se pueden usar las habituales herramientas de control de configuración, estando muy presente hoy día Git, directamente o a través de hostings como GitHub. Y el control de versiones del modelo no es muy diferente y se apoya en registro de modelos ('model registry').

Sin embargo, para el caso de control de versiones de datos, los autores apuntan la dificultad derivada de la existencia de diferentes tipos de datos. No obstante, existen soluciones de entre las cuales los autores mencionan Comet ML, Weights & Biases y, de nuevo, ZenML.

Principio 3: Experimentos y seguimiento de experimentos

El entrenamiento de modelos es un proceso iterativo y, en buena medida, experimental. En ese proceso experimental se realizan, claro, experimentos, unos experimentos que con frecuencia se llevan a cabo en paralelo y, una vez vistos los resultados, se decide el modelo que realmente 'se da por bueno' y que se traslada a producción

De estos experimentos, también conviene realizar una gestión, un trazado ('tracking')  de los que también conviene realizar un seguimiento y gestión mediante herramientas que permiten el registro de 'logs', la representación visual de las predicciones de los modelos, la comparativa de métricas y la selección final el mejor modelo.

Como apoyo a esta actividad loas autores mencionan herramientas como Comet ML, Weights & Biases, MLFlow y Neptune.

Principio 4: Pruebas

Las pruebas, y su automatización, es uno de los focos desde siempre de la ingeniería de software y de las soluciones de operación de servicios.

Los autores nos recuerdan los diferentes niveles de pruebas (unitarias, integración, sistema, aceptación) y algunas variantes concretas como las pruebas de regresión o las de stress. En ese sentido, 'nada nuevo bajo el sol', es de lo que se habla en ingeniería de software desde hace años y años.

Sin embargo, sí que nos aportan alguna idea original o específica del caso del machine learning, cuando explican la prueba de modelos, donde se añade la dificultad de que los modelos no son deterministas al, contrario de lo que sucede en muchas otras formas de software. Además, los modelos pueden no reportar ningún error y, sin embargo, no estar funcionando adecuadamente y esos malos comportamientos sólo se pueden observar en evaluaciones.

Los autores mencionan algunas técnicas específicas para la prueba de modelos, como

• Probar la 'forma' de los tensores de entrada y salida del modelo
• Probar que la pérdida o error ('loss') realmente decrece, como es lo que cabe esperar después de un lote ('bacth') de entrenamiento
• Probar que el 'pipeline' de entrenamiento funciona tanto con CPUs como con GPUs.
• etc

Todas las pruebas se realizan en la fase de integración continua (CI, 'Continous Integration').

También nos hablan de la prueba de comportamiento ('behavioral testing') en que se considera al modelo una caja negra y se comprueban sólo entradas y salidas. 

Principio 5: Monitorización

La monitorización es, desde siempre, una actividad fundamental de la operación de sistemas y, en el caso de machine learning no iba a ser menos. En la monitorización se observa, por ejemplo, que los sistemas están disponibles, que los tiempos de respuesta son adecuados, que no está recibiendo ciberataques, que no se producen errores, etc

Los sistemas de información tradicionales, una vez que están probados, depurados y estabilizados, tienden a no producir errores salvo ataques, averías o sobrecargas. Y eso es así porque se trata de sistemas deterministas con sus condicionas y casos de uso bien definidos.

Sin embargo, en el caso de los sistemas basados en modelos de machine learning esto no es así, porque su entorno y los casos de uso no se suelen encontrar completamente cerrados, porque su comportamiento con frecuencia no es determinista y porque el entorno varía. Eso puede llevar, por ejemplo, a que un modelo que funciona inicialmente muy bien, poco a poco vaya degradando sus resultados, sus predicciones y sea necesario un re-entrenamiento.

De cara a la monitorización los sistemas deben producir registros en forma de 'logs' que permitan el análisis, y se deben definir también una serie de métricas, tanto a nivel de sistema (métricas tradicionales) como de modelo (métricas como las conocidas F1, precision y 'recall') que permitan seguir y analizar el comportamiento y levantar alarmas en su caso.

Los autores nos hablan también de las derivas ('drifts') es decir, desviaciones progresivas del comportamiento original y que pueden producirse tanto en las distribuciones de los datos de entrada ('data drift'), distribuciones de las salidas ('target drift'), o en la relación entre ambos ('concept drift'). También aportan ideas sobre cómo tratar estas derivas, aunque ya no profundizaré más en ello.

Principio 6: Reproducibilidad

Finalmente, se menciona la reproducibilidad que quiere decir que las mismas entradas deben producir las mismas salidas. 

En software tradicional, determinista y basado en reglas, se trata de un concepto muy básico, muy evidente y es fundamental en el planteamiento de las pruebas.

Pero ¿Cómo entender esto en el caso de modelos de machine learning y específicamente grandes modelos de lenguaje que siempre decimos que son probabilistas y no deterministas?

Bien, el truco está en que, estrictamente hablando, los modelos no son probabilistas sino que dependen de parámetros concretos, como la semilla ('seed') o la temperatura que es lo que los convierte realmente en probabilistas. Si utilizamos siempre la misma semilla ('seed') y ajustamos adecuadamente otros parámetros como la temperatura, el modelo se convierte en perfectamente determinista y es posible, y deseable, ver que en esas condiciones se mantiene la reproducibilidad..

Conclusiones

Como se puede observar, los sistemas basados en machine learning y, particularmente, los basados en grandes modelos de lenguaje, además de ofrecer unas grandes capacidades, presentan necesidad de ser gestionados y operados de manera profesional.

En esa labor, heredan muchas de las buenas prácticas y herramientas de los sistemas tradicionales y procedentes de la ingeniería de software o de planteamientos como DevOps. 

En buena medida, son aplicables estas mismas buenas prácticas y herramientas, pero también se presentan particularidades y desafíos propios que precisan de nuevas técnicas y herramientas específicas.