Blue chip

Geometría y cinemática en grandes modelos de lenguaje: una iluminación y algunas especulaciones

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 06 May 2026 08:30:00 +0000

Es intelectualmente muy bonito, al menos para mí, cuando disciplinas o teorías en apariencia desconectadas, se solapan, convergen y se apoyan.

Es intelectualmente inspirador pero, además, suelo verlo como una forma de confirmación de que vamos en el sentido correcto: si desde puntos de partida o intereses muy diferentes, acabamos en conclusiones parecidas o en solapes, me parece un síntoma de haber acertado.

Recientemente, debido a una interesante lectura, he tenido una suerte de iluminación, o de inspiración, al entrever una conexión entre el funcionamiento de los grandes modelos de lenguaje (en realidad de muchos modelos generativos), no sólo con la geometría sino, más allá de eso, con la física y, en concreto, la cinemática.

En este post, tras detenerme a explicar algunos fundamentos de los modelos de lenguaje, intento explicar la naturaleza de esa iluminación y realizo alguna especulación o alguna pregunta aún sin respuesta.

Recordando fundamentos (I): tokens

Supongo que algunos de los lectores de este blog ya conocerán algunos fundamentos, o puede que más que fundamentos, acerca de cómo funcionan una buena parte de los modelos generativos derivados de la arquitectura transformer, es decir, la mayoría de los que usamos mediante las herramientas habituales como ChatGPT, Gemini o Claude.

En cualquier caso para beneficio de aquellos que pudieran no conocerlos, y para ganar un punto de partida común, recuerdo un par de conceptos.

Así, en primer lugar recordar el concepto de token. El token es la unidad con la que trabajan los grandes modelos de lenguaje, generando token a token. Cuando nos centramos en los grandes modelos de lenguaje, estos tokens son secuencias de caracteres. En muchos casos, los tokens coinciden con palabras. Pero en otros casos pueden ser simples caracteres (incluyendo signos de puntuación), o la raíz de un verbo o un sustantivo. Además, existen tokens para representar elementos especiales como fin de texto o una máscara. Para una visión intuitiva, aunque no exacta, podemos pensar en los tokens palabras, pero sabiendo que no siempre es así.

Cada modelo utiliza un vocabulario cerrado (una especie de catálogo) de tokens, que difiere de modelo a modelo. En esos catálogos cada token tiene un identificador ('token ID') que no es más que un número entero que identifica al token en ese vocabulario. Un modelo sólo es capaz de generar texto de salida recombinando esos tokens de su vocabulario. Estos catálogos tienen del orden de decenas de miles (e incluso centenas de miles) de tokens. Así, por ejemplo, el modelo GPT-4o de OpenAI usa un vocabulario en el orden de los cien mil tokens diferentes.

Recordando fundamentos (II): embeddings

Externamente, la visión de un gran modelo de lenguaje se basa en los tokens: nuestro prompt de entrada se descompone en tokens antes de ser procesado, la ventana de contexto contiene tokens y su tamaño se 'mide' en tokens, el texto de salida se genera token a token y no es rara la facturación o límite de uso con base en tokens.

Sin embargo, internamente, los modelos trabajan no exactamente con tokens sino con 'embeddings', .

¿Qué es un 'embedding'?

Un 'embedding' es un vector, un vector que no es más que una serie ordenada de números (habitualmente números reales). La dimensión (cantidad de números del vector) es diferente según el modelo: en los caso más modestos solemos estamos hablando de una dimensión de en torno a varias centenas y, en los mayores, de unos pocos miles.

Uno de los grandes 'trucos' de los modelos de lenguaje, es que estos vectores, estos 'embeddings', no son arbitrarios, sino que son portadores de contenido estructural (morfo-sintáctico) y, sobre todo, semántico, es decir de una forma de significado. Este contenido semántico, esta especie de significado. se le confiere durante el entrenamiento.

En efecto, a cada token del vocabulario, y durante el entrenamiento, se le asigna un 'embedding'

Sin embargo no sólo se utilizan los 'embeddings' estáticos de los tokens: durante el funcionamiento del modelo, se calculan y/o añaden otros 'embeddings' como los posicionales que dan cuenta de la posición de un token en un texto como el 'prompt'.

En cualquier caso, lo importante, es que trabajamos con vectores que nos añaden, fundamentalmente dos cosas:

Capacidad de tratamiento mediante álgebra lineal
Contenido estructural y semántico

Espacios vectoriales y espacios de significados

Desde un punto de vista algebraico, pues, los 'embeddings' se sitúan en una estructura que, en álgebra lineal, se denomina espacio vectorial.

Estos espacios vectoriales tienen unas ciertas características y disponen de una serie de operaciones como suma de vectores, producto escalar o producto vectorial, operaciones que, por cierto, se utilizan en el entrenamiento y la inferencia.

Geometría de grandes modelos de lenguaje

Pero, en cierto sentido, el utilizar vectores en un espacio vectorial, nos lleva a unas primeras ideas de geometría.

En efecto, la forma más sencilla e intuitiva de un espacio vectorial, los constituyen los sistemas de coordenadas en dos o tres dimensiones que usamos para fijar posiciones de objetos 2D o 3D (las famosas coordenadas x,y,z). En estos sistemas de coordenadas, un vector nos fija fundamentalmente la posición de un punto.

En estos espacios podemos disponer de rectas o planos. Y si consideramos que los vértices de figuras bidimensionales como un rectángulo o un hexágono, o tridimensionales como un cubo o pirámide, son puntos en ese espacio de coordenadas, podemos también describir y posicionar objetos geométricos.

Claro, en el caso de los grandes modelos de lenguaje, hablamos de unos vectores, los 'embeddings', no de dos o tres coordenadas sino de cientos o miles, pero las reglas matemáticas que los gobiernan son exactamente las mismas (son todo espacios vectoriales con las mismas características y operaciones).

Distancias

Tan es así que si, la interpretación geométrica de los 'embeddings' es tan cierta, que, si en espacios de coordenadas podemos calcular distancias entre puntos, en el caso de los los 'embedding' se calculan distancias entre 'embeddings'.

Y esas distancias son fundamentales, porque, dado que los 'embeddings' portan contenido estructural y semántico, una distancia corta nos habla de significados parecidos o uso conjunto habitual, mientras que una gran distancia nos habla de lo contrario, de un significado muy diferente o un uso conjunto muy poco habitual.

Y en la generación de un texto de salida, determinamos 'por dónde' debe andar el 'embedding' de salida y, con base a él, qué token o tokens son los más probables.

Espacios vectoriales y espacios de significados

Por tanto, los modelos de lenguaje, utilizan los 'embeddings' que son vectores y que forman parte de un espacio vectorial.

Pero, dado que los 'embeddings' son portadores de significado, dado que sus coordenadas en ese espacio vectorial indican significado, podríamos hablar de un 'espacio de significados' (término que no me he inventado yo, sino que he encontrado en una referencia bibliográfica que en seguida citaré).

Trayectorias

La fuente a que me refiero es el libro 'What Is ChatGPT Doing ... and Why Does It Work?' de Stephen Wolfram cuya lectura he finalizado recientemente, un libro sugerente y 'iluminador'.

En este libro menciona otro concepto, en cierto sentido geométrico, pero que ya nos acerca una visión cinemática: las trayectorias.

Aunque no profundiza mucho en este concepto, la idea vendría a ser: dado que los 'embeddings' forman parte de un espacio vectorial, y dado que sus dimensiones son coordenadas en ese espacio vectorial, cualquier forma de desplazamiento en ese espacio vectorial sería la descripción de una trayectoria.

Quizá, podemos entender que cuando entrenamos un modelo, los embeddings que representan a los tokens describen una trayectoria hasta asentarse en el lugar (las coordenadas) que les corresponden. O podemos entender que cuando en inferencia realizamos lo que se denomina un condicionamiento (mediante un 'prompt u otro mecanismo orientamos que texto, o qué imagen o qué vídeo o que música queremos generar) le estamos marcando al modelo la dirección o trayectoria que debería seguir

Excurso: cinemática

La cinemática es una rama de la física y, en concreto, de la mecánica que estudia el movimiento de puntos y objetos con independencia de las fuerzas que lo puedan motivar.

Se ocupa de cosas como trayectorias, velocidades y aceleraciones para lo cual, además, suele necesitar de unos sistemas de coordenadas (esto es, unos vectores y un espacio vectorial) y, cuando trabajamos en objetos sólidos, no con puntos, eso nos lleva con frecuencia a usar el álgebra lineal.

¿Una cinemática de grandes modelos de lenguaje?

Ya hemos visto que los 'embeddings', y por tanto los grandes modelos de lenguaje y, en cierto modo, gran parte de los modelos generativos, se sitúan en un espacio vectorial con sus coordenadas y operaciones algebraicas.

Ya hemos visto que se pueden calcular, y se calculan, de hecho, distancias.

Y ya hemos visto, aunque de forma algo más vaga e intuitiva que, en cierto sentido, dentro de ese espacio vectorial se describen trayectorias.

Lo que me pregunto es ¿hasta dónde llega o puede llegar una visión no sólo geométrica sino cinemática de los grandes modelos de lenguaje y sus 'embeddings'?

¿Podemos detallar más el uso de trayectorias? ¿Podemos buscar trayectorias optimizadas (mínima distancia) para acelerar, por ejemplo, la inferencia?

¿Y qué significa una velocidad en este espacio de significados? ¿Significa el ritmo a que nos acercamos, siguiendo una trayectoria, al significado adecuado? ¿Significa lo rápido que hacemos inferencia?

Y, si vamos más allá, ¿Podríamos hablar de aceleración? ¿Qué significaría y cómo la implementaríamos?

¿Tiene sentido todo esta visión cinemática? Y, si lo tiene ¿Cómo podríamos usar lo que sabemos de cinemática para, trasladado a los grandes modelos de lenguaje mejorar sus resultados, su rapidez o su eficiencia? ¿Están usando ya, equipos de desarrollo, laboratorios de empresas o laboratorios de universidades ideas en este sentido?

No sé o no tengo claras las respuestas a esas preguntas porque, de momento, esta idea de una cinemática de modelos de lenguaje (modelos generativos en realidad), es sólo una suerte de iluminación a raíz de una lectura, y no lo he podido investigar ni pensar mucho más.

Pero me resulta inspiradora y, incluso, puede que sea prometedora.

A ver si le doy una vuelta o si consigo leer algo más en esta línea.

Conclusiones

El solape del funcionamiento grandes modelos de lenguaje o modelos generativos en general con la geometría es bastante conocido, reflejado en el concepto de distancia, pero más inspirador, más desafiante y de conclusiones menos claras es cómo podríamos extender ese solape al ámbito de la física y, en concreto, la cinemática, y si tendría sentido usar conceptos cinemáticos como trayectoria o velocidad en entrenamiento, inferencia o cualquier otro aspecto del diseño y funcionamiento de modelos generativos

Ética del riesgo y cuatro posiciones preliminares

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 29 Apr 2026 07:30:00 +0000

El campo de la ética aplicada y, en concreto, de la ética de la tecnología, vive un momento de florecimiento, auge y casi diría popularidad. Y por ello surgen nuevas ideas, nuevos enfoques o nuevas áreas de trabajo.

Un área que he descubierto muy recientemente (no sé si es tan nueva o es sólo que yo la acabo de descubrir) es la llamada ética del riesgo ('risk ethics') y, quizá como otra forma de expresarlo, o como un subconjunto, la ética de la imposición de riesgo.

Ética del riesgo

Descubro este nuevo campo de trabajo en materia ética en el libro 'The ethics of artificial intelligence' de Sven Nyholm', quien aborda brevemente este tema en el último capítulo del libro. El autor nos presenta este subconjunto de la ética de la siguiente manera:

The ethics of risk is, so far, a fairly small subfield within ethics. But it is a field that is quickly growing as philosophical ethics concerns itself increasingly with emerging technologies, on the one hand, and the relation between current generations and future generations of people, on the other hand.

Lo vemos, pues, como un campo emergente de la ética, pequeño pero en rápido crecimiento y que debe dar respuesta de alguna manera a si es ético asumir ciertos riesgos o, quizá más importante, imponer a otros esos riesgos.

Según Nyholm, algunas de las preguntas a que la ética del riesgo debe responder serían:

¿Es admisible desde un punto de vista ético imponer riesgos a otras personas?
Si no está claro que se pueda hacer ¿En qué consiste realmente ese problema ético?
O también ¿Bajo qué circunstancias es éticamente aceptable imponer riesgos a otros?

Para que se entienda el contexto, y aunque el autor se centra sobre todo en el campo de la inteligencia artificial y sus riesgos, existen muchas otras tecnologías que tienen riesgos y que, sin embargo, hemos aceptado, la energía nuclear o los propios coches, por poner un ejemplo. Ambas aportan beneficios pero también comportan ciertos riesgos en forma fundamentalmente de accidentes, que, conscientemente o no, hemos aceptado como asumibles.

Riesgos

Antes de proseguir, un breve recordatorio o aclaración.

Un riego, se puede definir, de manera muy sencilla y compacta, como un problema potencial. Por potencial quiero decir que no es seguro que ocurra, que puede darse o no, y por problema indicamos que, caso de concretarse, su resultado es negativo o dañino.

Esta definición tan compacta, además, nos ilumina sobre lo que, en la pura gestión de riesgos propia de la dirección de proyectos, de la ciberseguridad o de tantos otros campos de gestión, se evalúa fundamentalmente en un riesgo, a saber:

La probabilidad de que ocurra
El impacto en caso de ocurrir

Decisiones

Aunque la ética del riesgo podría aplicar a muchas cosas, parece encajar muy bien con la ética de la tecnología o, más allá, la ética de los negocios.

En efecto, en el ámbito de los negocios (aunque no exclusivamente) se deben adoptar decisiones, decisiones, que siguiendo la sencilla y lógica clasificación que el autor nos sugiere, serán de tres tipos:

Decisiones con certidumbre
Decisiones con riesgo
Decisiones con total incertidumbre

Las dos últimas suponen la asunción de riesgos y, eventualmente, la imposición a terceros de algunos de esos riesgos.

Cuatro grandes posiciones preliminares ante el riesgo

En general, desde el punto de vista ético se considera como mínimo problemático (que no necesariamente inaceptable) el imponer riesgos a otras personas. El autor no profundiza mucho, y tampoco lo voy a hacer yo aquí, en el análisis ético, pero sí nos presenta cuatro grandes respuestas o cuatro grandes posiciones que se pueden dar, desde un punto de vista ético a esa imposición de riesgos.

Primera posición: Se considera ético imponer riesgos siempre que no suceda nada malo realmente. Esta es una posición no muy popular y bastante discutida. De hecho, personalmente la considero un poco absurda: es como decidir a posteriori si algo fue ético, en función de que el problema, el daño, se haya concretado. A lo mejor es útil desde un punto de vista legal, pero no lo veo como una guía ética para la toma de decisiones.

Segunda posición: Se pueden imponer riesgos a terceros si eso forma parte de un empeño que, en conjunto, puede beneficiar a la media de la sociedad. Es una visión, como reconocerá el lector avezado en ética, claramente utilitarista. Es discutida desde puntos de vista que apelan a la falta de equidad en la distribución de riesgos o a que no se tienen en cuenta los derechos de las personas.

Tercera posición: se puede imponer riesgos a otras personas si éstas consienten en asumirlos. No puedo evitar que esto me recuerde al 'consentimiento informado' utilizado en atención sanitaria o, aunque no es exactamente lo mismo, al consentimiento al tratamiento de datos personales que exige el reglamento de protección de datos. Se piense lo que se piense de esta opción, hay que tener en cuenta que, con frecuencia, no es viable consultar a todas las personas afectadas por un riesgo

Cuarta posición: un poco para salvar eta dificultad, la cuarta opción propuesta es considerar los riesgos que las personas tendrían buenos motivos para aceptar, en caso de que se las pudiera consultar. Tiene lógica, creo, pero es un poco especulativa.

Es evidente que hay mucho más que analizar y debatir todavía, pero lo dejaré aquí porque este era un post meramente introductorio y porque la fuente en que me baso tampoco se extiende mucho más.

Conclusiones

El riesgo es inherente a la actividad humana y, cuando adoptamos decisiones, es prudente tenerlo en cuenta. Esa prudencia no sólo afecta a consideraciones prácticas sino, también éticas, especialmente cuando nuestras decisiones imponen un riesgo a otras personas.

Por ello existe un campo emergente en la ética que trata, precisamente, con el riesgo e intenta dar respuesta ética a cuándo es lícito imponer riesgos a terceros.

Amazon AWS 'breaks guitars': un caso de mal servicio y una queja sin respuesta

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 27 Apr 2026 09:55:00 +0000

Este es una especie de 'post protesta', un lanzar una queja al aire con la esperanza, que no la expectativa, de que alguien tome nota.

Ese alguien debería ser Amazon AWS, que es la empresa de la que me voy a quejar, pero ese alguien también podría ser cualquier cliente potencial de Amazon AWS...para que esté advertido, se lo piense y tome precauciones antes de contratar a Amazon AWS, incluyendo la de buscar una alternativa.

Tengo varias críticas que formular a Amazon AWS, pero la más importante, la verdaderamente importante, es la de su pésimo, en realidad inexistente, servicio de soporte.

Y, a la hora de redactar este artículo, no he podido evitar acordarme del, en su momento, muy famoso caso de Dave Carroll y United Airtlines, que dio origen a un fenómeno viral en Internet con la canción titulada 'United breaks guitars'.

Sobre Amazon AWS

Aunque Amazon AWS ('Amazon Web Services') creo que es bien conocida, por si acaso recuerdo que se trata de la división de cloud computing de Amazon, una división que le genera grandes beneficios al gigante online, una división a la que le cabe el mérito de haber sido quien inventó de alguna manera este concepto de los servicios en la nube, y además, una división líder mundial desde entonces del sector, con más de un 30% de cuota, en competencia, fundamentalmente, con los otros dos hiper-escaladores: Microsoft Azure y Google Cloud Platform.

Dada esa relevancia, hace años que la sigo, que he leído libros e informes sobre ella, y que he hablado sobre ella, e incluso hecho sencillas demos, en mis clases, tanto en el ámbito de tecnología y transformación digitales, como de innovación.

Y por eso, desde hace años, la verdad es que no recuerdo cuántos, tengo una cuenta de formación gratuita (supuestamente) en Amazon AWS.

Antecedentes

Hace unos par de meses o así, y de cara a una formación, decidí que era una buena idea hacer un pequeña demo, una demo grabada, del funcionamiento de Amazon SageMaker, el conjunto de herramientas y servicios de Amazon en materia de Machine learning.

Cursé un pequeño MOOC sobre SageMaker y, siguiendo los ejemplos que allí se exponían, configuré un dominio y los recursos mínimos necesarios para, simplemente, visualizar SageMaker, navegar por él y entender mejor lo que ofrece. Al hacer esto, utilicé mi cuenta gratuita y entendí al profesor del MOOC que lo que estaba configurando también era gratuito.

De hecho, sólo hice la configuración, pero no llegué a crear ningún Notebook, no cargué datos, no entrené ningún modelo, no lancé ningún trabajo. Apenas hice nada más que configurar y entender el entorno.

Esto fue suficiente para poder luego hacer una recorrido demo y grabar lo que pretendía.

Y me quedé tan tranquilo.

Esto debió ocurrir a principios de Marzo.

Los hechos (I): esto no era gratuito

Cual no sería mi sorpresa cuando, dos o tres semanas más tarde, me llega un correo de Amazon diciendo que tenían problemas con mis medios pago para cobrar la factura de Marzo.

¿Factura? ¿Cobrar? ¿De qué me hablan? ¿Pero esto no era gratuito?

Bueno, me pongo a mirarlo y, en efecto, me estaban intentando cobrar la friolera de 743,18$, en una cuenta que se supone es gratuita, por algo que yo había entendido que era gratuito y por no hacer prácticamente nada de computación real.

Aunque yo había entendido que todo lo que había utilizado era gratuito, y aunque me parece una pasada cobrar esa cantidad por no hacer realmente nada, asumí que el error había sido mío, que seguramente en alguna parte en que yo no había reparado, había alguna cláusula que especificaba que eso que había hecho no era gratuito. Así que decidí pagar esa factura por más que me doliese en el bolsillo y que me molestase en su concepto.

En Abril, 6-Abril, exactamente. abrí un ticket de soporte quejándome de los hechos, pidiendo que me lo explicaran y solicitando (aunque sin ninguna expectativa real de conseguirlo) la devolución del dinero. La devolución del dinero no esperaba que se produjera, pero la explicación, sinceramente, sí.

Los hechos (II): defectos de usabilidad e información en Amazon AWS

Lo siguiente, por supuesto, fue darme de baja de SageMaker y de cualquier servicio que pudiera tener contratado sin yo ser consciente, con Amazon AWS,

¿Debería ser fácil, verdad?

Pues no lo es.

No existe una forma sencilla (en realidad, no me consta que haya una forma en absoluto) de visualizar qué servicios tienes contratados con Amazon AWS. Sí que existe una forma bastante razonable de visualizar aquello que te han facturado hasta el momento e, incluso, una previsión de lo que te pueden facturar en el futuro.

Esa visión de facturación, sin embargo, no te lleva directamente a conocer qué tienes realmente contratado. Me explico: Amazon AWS no tiene un esquema sencillo de servicios, sino que unos dependen de otros e, incluso, en el caso por ejemplo de SageMaker, lo que te cobran depende de recursos concretos que hayas creado, no del servicio como tal. Y no existe, al menos que yo haya encontrado, una forma panorámica, directa y razonablemente sencilla de saber qué servicios y recursos tienes y por los que te están cobrando.

Tengo que suponer, y de hecho supongo, que sí existe alguna forma. No me puedo imaginar que una empresa que contrate variedad de servicios de Amazon AWS, que haga uso intensivo de ellos, que pague mucho por ello y no pueda saber qué tiene contratado y configurado realmente. No lo puedo creer, y no lo creo de hecho, pero lo que sí digo es que no es sencillo o, al menos, no evidente.

Y esa dificultad en la interfaz de usuario, ese mal planteamiento de la consola, me parece lamentable en los tiempos actuales y más para el líder mundial de servicios en la nube.

pero lo realmente grave no es esto.

Los hechos (III): la inexistente respuesta de Amazon AWS

A todas estas, claro, mi prioridad era darme de baja inmediatamente de todo, y para eso necesitaba saber qué era exactamente ese 'todo' de lo que me tenía que dar de baja.

Aparte de consultar en la web de Amazon AWS y a ChatGPT, abrí, el 8 de Abril, tres nuevos tickets de soporte pidiendo ayuda para darme de baja en los servicios, cada vez más desesperado ante la para mí inexplicable dificultad de la tarea de ejecutar tal baja y la falta de respuesta de Amazon AWS.

Debo decir, además, que cuando abrí los últimos tickets ya había comprobado que cada día que pasaba sin que lograra dar de baja lo que fuera que tuviese que dar de baja, me seguían apuntando un debe de unas decenas de dólares (¡cada día!).

Al final, llegué a abrir cuatro tickets de soporte en tres días (muestro imagen en la herramienta AWS Support)

¿Respuesta?

De esos cuatro tickets sólo llegaron a contestar a uno de ellos, pero con una respuesta automática, creada con inteligencia artificial generativa y que era insuficiente por genérica, cosa que les hice saber. Lo que me decían, y mejor, ya lo sabía yo a partir de consultas a ChatGPT.

Es decir, es el día en que esto escribo, 27 de Abril, no han contestado al ticket original del 6 de Abril (¡¡¡ 21 días sin contestar!!!), no han contestado a dos de los tickets que abrí el 8 de Abril (¡¡¡19 días sin contestar!!!) y sólo han contestado a uno de los tickets de 8 de Abril, pero no han contestado a mi observación de que esa respuesta era demasiado genérica, respuesta que les di el 9 de Abril (¡¡¡ 18 días sin contestar!!!).

Los hechos (IV): ni siquiera en X (twitter)

Desesperado, acudí a X (antiguo Twitter) lanzando un post de queja y mencionando a diversas cuentas de Amazon AWS: la cuenta de España (@awscloud_es), alguna cuenta general (@aws, @awscloud) y la cuenta de soporte (@AWSSupport) e, incluso, la de Jeff Bezos (@JeffBezos)..

Lo normal cuando haces eso es que, una hora o dos después del mensaje, alguna cuenta te conteste (suponía que la de España), te pida que le sigas, te sigue, y continuas la conversación mediante mensajes directos y, con mayor o menor acierto te ayudan. Al menos esa era mi experiencia hasta ahora con otras empresas.

¿Qué hizo en este caso Amazon AWS?

De nuevo, nada.

Bueno, casi nada. Al final contestó de forma pública la cuenta @AWSSupport, diciendo que habían hablado con su equipo para que revisasen los tickets. Adjunto el post

¿Algún resultado tras esto? ¿Alguna contestación adicional? ¿Algún otro contacto? No, cero 'patatero'. Los tickets siguieron igual, y no hubo más acción por parte de la cuenta de AWSSupport.

Los hechos (V): el fin de la historia

Escribo esto cuando, desde hace unos días, parece que he logrado resolver el problema. A base de consultar a ChatGPT y explorar y recorrer por arriba y por abajo la consola de Amazon SageMaker, parece que he logrado localizar y borrar todos los recursos por los que me estaban cobrando. Desde hace unos días, ya no me acumulan nuevos costes.

Pero, me ha llevado mucho tiempo conseguirlo, en un momento, además, en que tenía un pico de trabajo brutal y lo último que quería era dedicar esfuerzos a nada que no fuese mi verdadero trabajo. Además, y mientras he logrado borrarlo y no, este mes de Abril me han seguido acumulando costas hasta un total de 171,54 $ que seguro que, esto si, me cobran puntualmente sin la más mínima dilación.

Inciso: Dave Carroll y United

Como decía al inicio de este post, he utilizado como metáfora y título el caso 'United breaks guitars'.

Se trata de un caso que se hizo muy famoso ocurrido en 2009, en pleno 'boom' de la web 2.0. El caso se refiere al cantante country Dave Carroll. En un viaje que éste realizó con la aerolínea United Airlines' fue avisado de que los empleados de equipaje estaban lanzando por los aires su guitarra 'Taylor' (que costaba unos 3.500$). El cantante intento advertir de ello, pero no le hicieron ni caso. Al llegar a su destino comprobó que, en efecto, habían roto la guitarra. A esto siguió una larga cadena de acciones por parte del cantante para que United Airlines asumiese su responsabilidad, todo ello sin encontrar respuesta.

Harto de ello, grabó la canción 'United breaks guitars' que se hizo viral (150.000 visualizaciones el primer día). Dejo aquí el famoso vídeo.

Con esto, United no tuvo más remedio que que reaccionar y atender a Dave Carroll

El verdadero problema no son las guitarras rotas

En el caso de Carroll, hubo un fallo de raíz por parte de United, que fue romper la guitarra por descuido o incluso desprecio por parte de sus empleados. Pero, más allá de este error de partida, lo realmente exasperante y mucho más grave, fue la negativa de United a atender la justa reclamación de Dave Carrol.

En mi caso, creo que Amazon AWS muestra fallos en su servicio cuando no explicita claramente qué te da gratuito y por qué te cobra, o cuando no ofrece una consola razonable para tener perspectiva clara y sencilla de tus servicios y recursos y facilitar su gestión y, en mi caso, su baja inmediata. Pero asumo como propio el no haberme informado suficientemente de los costes en que estaba incurriendo o no estar más ducho en el manejo de la consola, y sólo me referiré a esto que creo fallos de Amazon AWS como meras oportunidades de mejora.

En ese sentido, a lo mejor en mi caso debo asumir como problema propio el que la 'guitarra se haya roto' (en forma de servicio de pago) y que 'la broma' me vaya a costar más de 900$.

Lo que realmente es de todo punto inaceptable, es que Amazon AWS no responda (¡¡¡ 21 días sin dar una respuesta!!!)

He pensado que, quizá, 'tardan' tanto en contestar porque estoy en esa cuenta presuntamente gratuita y, quizá, es que por eso no me consideran un verdadero cliente.

Pero, por un lado, la cuenta no ha sido tan gratuita, como ha quedado claramente demostrado y, por otro, para facturarme y cobrarme sí que me han tratado como a un cliente. Es para darme soporte y para atenderme para lo que no me han considerado como un cliente y no me han atendido ni ayudado en absoluto.

¿O es que Amazon AWS trata así a todos sus clientes?

En el estribillo de su canción, Dave Carroll dice:

I should have flown with somewhere else or gone by car... cause United breaks guitars

Y, claro, esa es la sensación que me queda, que debería haber usado otra plataforma en la nube en lugar de Amazon AWS. Y, claro, para futuras formaciones, exploraré Microsoft Azure o Google Cloud Platform e intentaré no volver a recurrir a Amazon AWS. Y pongo en alerta, a quien me quiera escuchar, que tenga cuidado con Amazon AWS y, sobre todo, con su servicio de soporte.

Y es que, aunque sea de manera figurada 'Amazon AWS breaks guitars'.

Conclusiones

Pese a que Amazon AWS es el creador de la categoría de servicios en la nube, pese a que se trata del líder mundial de este mercado, su servicio de soporte deja mucho que desear, en realizad es casi inexistente, al menos esa es mi experiencia personal.

La inteligencia artificial y su contribución a una vida significativa: cinco puntos a considerar

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 22 Apr 2026 08:30:00 +0000

Mucho se debate acerca del impacto innegable de la inteligencia artificial. Su impacto en lo económico, en lo laboral, en nuestro día a día... Y también se habla de las implicaciones éticas, muchas veces, eso sí, acentuando más el aspecto de los riesgos que implica que los beneficios.

En este post quisiera, con base en mi lectura actual del libro 'The ethics of artificial intelligence' de unos de mis filósofos favoritos, Sven Nyholm, ' comentar ese impacto de la inteligencia artificial en un aspecto mucho más importante, aunque quizá elusivo, de nuestras vidas: el significado.

Mi enfoque favorito de la ética

Suelo defender, cuando tengo ocasión en clases o charlas, un enfoque de la ética, que creo que encaja bien con el planteamiento de la eudaimonia de Aristóteles, y que más que en normas, más que en prohibiciones o exigencias, más que en el dictado estricto de lo que debemos o no debemos hacer, pone el foco en el propio valor de la vida humana, en su respeto y, sobre todo, en el desarrollo de sus potenciales, como guía para determinar qué consideramos bueno y qué no y, con base en eso ayudarnos a determinar nuestro comportamiento y nuestras apuestas.

El significado

Y creo que esa visión entronca bien con lo que se suele mencionar como el significado ('meaning') o el propósito.

Se tratará pues, de alguna manera, de hacer que nuestra vida sea digna, sí, pero también significativa, que nos desarrollemos y que aportemos. Cuando Nyholm introduce el tema nos dice:

We will primery focus on wether AI technologies might make us into morally better people, on the one hand, and whether they might make our lives more meaningful, on the other.

Aunque creo que está relacionado, dejamos para otro momento la cuestión de si la tecnología nos puede hacer moralmente mejores o no y nos centramos en el significado.

¿Qué es una vida significativa?

Es cierto que el concepto de significado o vida significativa. puede no estar claro. Puede que cada uno de nosotros considere que una vida es significativa o no por motivos diferentes. Pero, para 'centrar las cosas', acudo a una explicación que procede de la misma fuente unas pocas líneas más abajo, y que nos dice:

The idea of meaning in life is often associated with things such as whether one is part of something “bigger than oneself,” whether one has a sense of purpose in life, and so on. Sometimes philosophers associate meaning in life with “the good, the true, and the beautiful,” so that a meaningful human life is a life in which one does good, one is a truth-seeker, and one gets to enjoy and appreciate different kinds of beauty. Meaning in life is also sometimes associated with notable achievements and accomplishments. Meaning in life is also often associated with living not just for oneself, but also doing things for others and being part of a community. This, in turn, is sometimes related to the idea of making important contributions of different kinds.

En ese párrafo, se identifican una serie de aspectos que dan significado a la vida::

Formar parte de 'algo mayor'
Hacer el bien
Buscar la verdad
Apreciar las diferentes formas de belleza
Alcanzar logros
Hacer cosas por los demás
Formar parte de una comunidad
Hacer contribuciones importantes

Seguramente se le pueda 'dar más vueltas' a qué hace una vida significativa, pero creo que, con esto tenemos suficiente ahora mismo para saber de qué estamos hablando..

Los cinco puntos a considerar

Bueno, pues con ese marco, Nyholm identifica cinco aspectos en que la inteligencia artificial puede influir en el significado de las vidas humanas, ya sea en el sentido de aumentarlo o disminuirlo. Los cinco puntos sobre los que reflexiona Nyholm son los siguientes:

Asunción por la IA de tareas que nos resultan significativas: pensamos que, en efecto, la inteligencia artificial se irá haciendo cargo cada vez de más y más tareas. Si esas tareas que delegamos en la inteligencia artificial son del tipo de las que, por el estímulo intelectual que suponen, por el desarrollo de nuestras capacidades que implican, por la sensación de logro que conseguimos con ellas, o por cualquier otro motivo, son tareas que consideramos significativas, la introducción de la inteligencia artificial podría ir en la línea de disminuir el significado de nuestras vidas al quitarnos tareas que le confieren significado.

Si, por el contrario, la inteligencia artificial nos libera de tareas que no nos resultan satisfactorias pero que nos consumen tiempo y, gracias a eso, podemos dedicar nuestros esfuerzos a tareas que sí nos importan y realizan, entonces, por el contrario, estaría contribuyendo a hacer nuestras vidas más significativas.

En un sentido diferente, si la inteligencia artificial, en realidad como muchas tecnologías, nos potencia, multiplica nuestra capacidad y, por tanto, aumenta nuestras posibilidades de conseguir más cosas, de alcanzar más logros o que estos sean de mayor calado, la inteligencia artificial estará contribuyendo a hacer nuestras vidas más significativas, aunque queda la reserva de lo que se denomina el 'achievement gap', que hace referencia a que, tal vez, el mérito de esos logros pueda no ser nuestro, sino de la inteligencia artificial...lo que podría menoscabar nuestro propio mérito y, por tanto, significado del logro.

En un aspecto quizá más polémico, el cuarto punto se adentra en el terreno de las relaciones, un aspecto que solemos considerar valioso pero en este caso, hablaríamos de las relaciones hombre-máquina. y, en la medida que las máquinas sean más y más 'inteligentes' y en la medida (sometida a mucho debate ético y filosófico) que para la persona la relación con ciertas máquinas pueda ser significativa, la inteligencia artificial estaría contribuyendo al significado vía relaciones.

El último aspecto que considera Nyholm, va justamente en dirección contraria al anterior: si esas relaciones que creemos significativas, en realidad no lo son, si en realidad no son más que una forma de engaño, la contribución de la inteligencia artificial al significado de nuestras vidas, sería negativo.

Es posible que pudiéramos identificar más aspectos en que la inteligencia artificial pueda influir en el significado de nuestras vidas, en un sentido u otro, pero me quedo con éstas que son las que se analizan en mi reciente lectura.

No queda cerrado, ni mucho menos, el debate, ni en este post ni en el libro que lo inspira. En realidad queda planteado, abierto a reflexión, muy abierto.

Conclusiones

La única conclusión clara, creo, es que la inteligencia artificial, desde luego, impacta en nuestras vidas y es posible, sólo posible, que pueda hacer contribuciones a que éstas puedan ser más o menos significativas.

La tecnología como solución: tecnología para la ética y la gobernanza de la IA

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 08 Apr 2026 09:00:00 +0000

Forma parte del discurso habitual sobre ética de la tecnología, particularmente ética de la inteligencia artificial, el ver a la tecnología, en este caso la inteligencia artificial, como culpable, y ya de paso, trasladar esa culpabilidad también a los ingenieros que la crean.

Hace ya algún tiempo hice en este mismo blog un alegato en defensa de los ingenieros y en contra de ese discurso culpabilizador, en el post 'Con el debido respeto: los ingenieros y la ética de la inteligencia artificial' .

En el post que ahora comienzo, salgo en cierto sentido en defensa, no específicamente de los ingenieros como personas y profesionales, sino de la tecnología en sí misma, explicando un poco y destacando el importante papel que tiene en la consecución de una inteligencia artificial responsable y ética.

Y para ello, rescato un discurso que suelo hacer en las charlas y formaciones en que tengo la ocasión de hablar de ética de la tecnología, complementado con algún hallazgo bibliográfico reciente.

Vamos allá.

Tecnología como solución

En esencia, lo que intento trasladar es que, de cara a conseguir una inteligencia artificial ética, no sólo debemos pensar en regular y prohibir, sino que hay otros campos de actuación y uno de ellos, y muy importante, es precisamente la propia tecnología, que ofrece multitud de herramientas, ayudas y soluciones orientadas a conseguir esa inteligencia artificial responsable.

Ya hace un tiempo encontré en 'Manual de ética aplicada en inteligencia artificial' de Mónica Villas y Javier Camacho, una buena panorámica de herramientas tecnológicas.

Vamos a repasar brevemente algunas.

Herramientas para la privacidad

Existen muchas técnicas maduras para garantizar la privacidad y el derecho a la intimidad. En a obra citada los autores nos explican varias que, más a modo de referencia que de verdadera explicación, menciono a continuación:

Anonimización: eliminación de la información personal, privada o sensible de los datos de manera que la información resultante no pueda ser asociada a ninguna persona o colectivo

Privacidad diferencial: Mecanismo que introduce aleatoriedad en la toma de datos de forma que no se puedan asociar a la persona y, sin embargo, es posible eliminar posteriormente el ruido.

Encriptación homomórfica: mecanismos que permiten trabajar sobre datos encriptados sin necesidad de ninguna clave.

Computación multiparte segura: distribuye el cálculo sobre datos entre múltiples partes de forma que ninguna tenga una visión completa.

Aprendizaje federado: modelo de aprendizaje distribuido en machine learning lo que evita que los usuarios tengan que ceder datos.

Datos sintéticos: datos generados artificialmente a partir de datos reales que conservan sus propiedades estadísticas.

Herramientas para la equidad

De cara a la eliminación de sesgos y, por tanto, en busca de garantizar la equidad, también existen una amplia variedad de técnicas y apoyo de herramientas.

En esa línea, y siguiendo la referencia anterior, se dispone de variedad de 'toolkits' (en general implementados como librerías python) para la detección y mitigación de sesgos. Entre ellos, se nos mencionan los siguientes:

Fairml
Fairlearn
Fairness 360 (IBM)
What-if-tool (Google)
Aequitas
Audit-AI
LIFT
Fairmodel
scikit-fairness

Herramientas para la explicabilidad

Algo más complejo es el panorama de la explicabilidad. Pero incluso en este campo, existen planteamientos técnicos y, quizá, como he comentado en algún otro post, los modelos generativos, muy especialmente los razonadores, pueden arrojar una solución completamente nueva y casi definitiva.

Un poco en 'ralentí' a ver si, en efecto, esos modelos son una solución cercana a lo definitivo, algunas técnicas usadas en busca de la explicabilidad, serían:

Modelos inherentemente interpretables: Es decir, siempre que sea posible, usar modelos explicables como puede ser un árbol de decisión, en lugar de modelos no interpretables como una red neuronal.

Sistemas descomponibles: En cierto modo una extensión de lo anterior y donde lo que se propone es descomponer un sistema en subsistemas e intentar que, al menos en sus partes críticas, se usen modelos explicables.

Modelos proxy: Aunque se inicie la resolución de un problema con un modelo no interpretable, como una red neuronal, desarrollar en paralelo otro, sí interpretable, que produzca similares resultados y utilizar ese segundo modelo para las explicaciones. En esta técnica siempre me he preguntado su viabilidad real puesto que si utilizamos un modelo no interpretable es porque consigue mejores resultados que uno interpretable (es decir, los resultados no son iguales y por tanto tengo dudas sobre la calidad de ese 'proxy').

Mapa de prominencia: No es una solución general pero puede ayudar en casos concretos y normalmente a posteriori. Se trata de averiguar el peso que tiene cada entrada del modelo en el resultado final, jugando con escenarios de 'que pasa si' varío el valor de una entrada dejando fijas el resto.

Explicaciones contrafactuales: Parecido a lo anterior intenta, ante un resultado obtenido, averiguar qué tendría que cambiar en las entradas para obtener un resultado diferente.

Guardarraíles como servicio

En una línea algo diferente, hace poco, descubría, con sorpresa y agrado, que en la plataforma 'cloud' líder, Amazon AWS, entre la multitud de servicios de todo tipo y en concreto de machine learning e inteligencia artificial, también se ofrece un servicio ya construido de guardarraíles éticos pensando sobre todo en la creación de aplicaciones basadas en modelos generativos que incorporen estas salvaguardas.

Algunas métricas

En una lectura posterior a la ya citada, en concreto en 'Gobernar la inteligencia artificial' de Benjamin Pride (seudónimo), me encuentro un resumen compacto de algunas de métricas importantes de cara a medir la calidad de los resultados que obtenemos en las soluciones de inteligencia artificial, desde un punto de vista técnico y operativo, pero también ético e incluso de seguridad. Así, el autor nos menciona:

Métricas de precisión y rendimiento técnico: medidas clásicas como accuracy, recall, precision o F1-score y que permiten saber si el modelo sigue acertando en su tarea principal. Se trata de unas medidas más operativas o de calidad, pero también tienen su impacto ético, puesto que decisiones equivocadas, pueden ser injustas.

AUC ('Area Under Curve', Área Bajo la Curva ROC): métrica crítica en modelos de clasificación binaria. Una caída de más de 3 puntos porcentuales frente a la línea base suele activar una revisión.

Indicadores de equidad intergrupal: diferencias de resultados entre colectivos. Indicadores como 'Equal Opportunity' (tasa de verdaderos positivos) o 'Demographic Parity' ayudan a detectar sesgos. El umbral u objetivo que habitualmente se considera es que no se produzcan diferencias de más de un 5 % entre grupos protegidos.

Population Stability Index (PSI): compara la distribución actual de variables con la usada en el entrenamiento. Valores superiores a 0,2 suelen indicar deriva ('drift') de datos significativa y, por tanto, la necesidad de revisión y, probablemente, reentrenamiento.

Métricas de explicabilidad y confianza: métricas derivadas de técnicas como SHAP values o LIME. Miden si las variables que el modelo usa para decidir siguen siendo coherentes con lo esperado.

Pruebas de robustez frente a ataques adversarios: pruebas diseñadas para evaluar la resistencia del modelo a perturbaciones intencionadas. No se trata de medir precisión, sino de comprobar resistencia.

Herramientas para la monitorización

El mismo autor anterior apuesta, con toda lógica, por la monitorización continua, una monitorización basada en las métricas anteriores y automatizada, elevando alarmas y generando evidencias de comportamiento.

El mensaje

Estoy seguro de que existen muchas más metodologías, técnicas y herramientas, pero el mensaje es claro: la tecnología no es 'la culpable' de resultados no éticos. Es cierto que genera problemáticas como los sesgos, pero también es cierto que aporta un abanico rico y amplio de soluciones a esos mismos problemas.

Ahora es 'cosa nuestra' el ser realmente responsables, utilizar esas soluciones y, ya de paso, 'absolver' a la tecnología.

Conclusiones

Aunque es cierto que la tecnología, fundamentalmente en su forma de inteligencia artificial, genera riesgos éticos, la propia tecnología nos ofrece soluciones para esos mismos riesgos.

No culpabilicemos, pues, a la tecnología, y utilicemos de forma responsable las soluciones que nos brinda.

Tecnologías socialmente disruptivas

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 25 Mar 2026 09:00:00 +0000

Estamos acostumbrados a hablar de disrupción cuando la conversación gira en torno a los negocios, en torno a la influencia de la tecnología en los mercados o en torno a innovación y emprendimiento.

Sin embargo, la disrupción puede ir, y de hecho va, más allá, y puede alcanzar a los hábitos y comportamientos sociales y los valores morales. Y, de hecho, recientemente he descubierto el concepto de tecnologías socialmente disruptivas ('socially disruptive technologies') que es el objeto de este post.

Disrupción tecnológica

Antes, y de manera muy breve y no especialmente académica, recordar que, en el ámbito de la innovación tecnológica y de los negocios, se considera que una tecnología es disruptiva cuando, de alguna forma, cambia las reglas del juego de ese mercado, posibilitando nuevos productos y servicios, nuevos entrantes y, sobre todo, desafiando los modelos de negocio establecidos, lo que pone en riesgo líneas de productos, empresas e incluso sectores enteros.

Tecnologías socialmente disruptivas

La idea de tecnologías socialmente disruptivas, no es tan diferente en su núcleo a lo anterior, pero ahora el ámbito es el impacto social y también ético.

He descubierto el planteamiento leyendo el libro 'Social Robots and Cultural Sustainability' editado por Raul Hakli , Sven Nyholm, Marco Nørskov y Sladjana Nørskov y, en concreto, en el penúltimo capítulo escrito por Sven Nyholm donde el autor dice, citando el eBook 'Ethics of socially disruptive technologgies. An introduction' en que el mismo es co-autor, que:

new technologies may also challenge or put pressure on social norms, some of the fundamental concepts we use (such as moral responsibility, personhood, agency, nature, and so on), as well as our conception of ourselves as human beings

En este caso, pues, tenemos un cambio profundo causado por la tecnología, pero cuyo objeto no son los mercados sino nuestras creencias y valores y la concepción de la propia naturaleza humana.

Y, como se ve, se hace este análisis en el ámbito de la robótica social que, como he expuesto en posts en este mismo blog y en cursos y presentaciones, trae, efectivamente, desafíos aún no resueltos a nuestras creencias y a cuestionarnos ciertos aspectos de la naturaleza humana.

Dimensiones para la valoración de tecnologías socialmente disruptivas

A la hora de realizar un análisis de este tipo de tecnologías, insisto que con un enfoque social y sobre todo ético, existe un modelo de siete dimensiones a tener en cuenta, un modelo que se explica en 'What are socially disruptive technologies' de Jeroen Hopster.

Las dimensiones que ahí se sugieren, con algún comentario propio, serían las siguientes:

Profundidad de los impactos: que, con un enfoque fundamentalmente ético, implica hasta qué punto la tecnología desafía o incluso cambia creencias, valores o normas socialmente muy arraigadas.

Rango de los impactos: es decir, cuantos ámbitos de la vida humana se ven afectados por la tecnología en cuestión.

Valencia de los impactos: simplemente, si los impactos son positivos o negativos. Digo simplemente, indicando que es fácil explicar qué es esta dimensión, pero en mi opinión, hay muchos casos en que esa valencia puede estar en discusión, precisamente por estar desafiando, como se decía en la primera dimensión, creencias y valores.

Importancia ética de los impactos: es decir, hasta qué puntos los retos que plantea la tecnología son moralmente relevantes y si, por ejemplo, nos obligan, de nuevo como se decía en la primera dimensión, a reconsiderar nuestras creencias y valores.

Nivel de incertidumbre: es decir, hasta qué punto están claros o no los impactos de la tecnología, considerándose más disruptivos los casos en que esos impactos están menos claros.

Ritmo del cambio: o lo que es lo mismo, la velocidad a que se están produciendo los cambios

Reversibilidad de los impactos: considerándose que, en la medida en que los cambios sean más reversibles, son menos disruptivos.

Se trata de un planteamiento de dimensiones que es razonable, y que 'a toro pasado' parece casi obvio. Y un planteamiento de análisis que, en el fondo, no difiere tanto de cómo podríamos analizar una disrupción tecnológica en marcados.

La necesidad de la reflexión ética

Antes de finalizar esta breve exposición, simplemente insistir en que este tipo de tecnologías nos lleva a replantearnos nuestros valores e, incluso, elementos de la naturaleza humana. Y que, además, al menos en mi opinión, abren debates éticos para los cuales no tenemos una respuesta consensuada.

A bote pronto diría que, en este campo caen, en efecto, tecnologías todas ellas con base de alguna manera en la inteligencia artificial avanzada como podrían ser la propia robótica social, pero también los avatares y humanos digitales o la neurotecnología y alguna tecnología de otros ámbitos como la edición genética.

Conclusiones

Las nuevas tecnologías pueden cambiar radicalmente las reglas del juego, no sólo en los mercados, sino también en nuestras creencias y valores. Y esto da lugar al concepto de tecnologías socialmente disruptivas, que cuestionan nuestro valores y creencias en modos para los cuales, con frecuencia, no tenemos una respuesta clara.

Robots humanoides y la convergencia pendiente a un diseño dominante

noreply@blogger.com (Ignacio G.R: Gavilán) — Tue, 17 Mar 2026 10:25:00 +0000

Asistimos a una cierta efervescencia en el, digamos mercado, de robots humanoides. Lo cierto es que esa efervescencia se produce quizá más en el terreno mediático que en el mercado propiamente dicho, pero sí que hay movimiento a nivel de implicación de grandes empresas, de inversiones, de prototipos.

Alguna reflexión preliminar sobre el mercado de robots humanoides

Algo se mueve, como decía, en este sector o mercado emergente que, sin embargo, está lejos, puede que muy lejos, de ser un mercado consolidado.

En este momento creo que se encuentra en un estado de exploración y de búsqueda.

Busca, creo, en primer lugar, una solución tecnológica suficientemente robusta y, a la vez, suficientemente escalable. Hay grandes avances, pero seguramente no la 'solución definitiva'. Además, hablo de una solución tecnológica pero, en realidad, son muchas decisiones tecnológicas que afectan a aspectos que van desde morfología y materiales, a energía y llegando, probablemente, al nudo 'gordiano' de la inteligencia, el control y el entrenamiento.

Busca, además, quizá sobre todo, el o los casos de uso que, de forma realista, permitan un suficientemente rentable lanzamiento y creación de verdadero mercado.

Y busca, claro, un modelo de negocio, aunque creo que, si los dos elementos anteriores se resuelven, éste tercero no será un obstáculo.

Y pensando en esta situación del mercado de robots humanoides, no sé por qué, esta noche me dio por conectarlo con el concepto de 'diseño dominante' tan importante en el terreno de la innovación tecnológica y que, aunque muy brevemente, ya mencioné en el post 'Especulando sobre un mercado para robots humanoides (y III): estrategias de desarrollo de mercado' . Y del caso de los robots humanoides, es de lo que, brevemente, expondré hacia el final alguna idea, pero antes una parada para recordar en qué consiste esto del diseño dominante

El concepto de diseño dominante en innovación tecnológica

El diseño dominante es un concepto que se maneja en el campo de la estrategia de innovación tecnológica, que creo fue introducido por Anderson y Tushman pero que yo descubrí, hace ya unos cuantos años en el libro 'Strategic Management of Technological Innovation' de Melissa Scheling.

En esta fuente nos dice que el diseño es uno de los patrones comunes en innovación tecnológica y que:

the technology cycle almost invariably exhibits a stage in which the industry selects a dominant design. Once this design is selected, producers and customers focus their efforts on improving their efficiency in manufacturing, delivering, marketing or deploying this dominant design, rather than continue to develop and consider alternative designs.

Claramente, la idea de diseño dominante nos habla, por un lado de una cierta madurez y claridad tecnológica que permite seleccionar ese diseño y, por otro, y como un cierto signo también de madurez, en este caso más de mercado, la búsqueda de un planteamiento más escalable y eficiente que la continua exploración tecnológica.

Motivos para la convergencia a un diseño dominante

Creo que el concepto es bastante explicativo, sobre todo en cuanto a su lógica, pero de todas formas, puede ser bueno revisar los principales beneficios o motivaciones para que una industria, converja y, de alguna manera se ponga de acuerdo, en un diseño dominante.

En la fuente citada, nos explica que las motivaciones giran con frecuencia en torno a lo que se denomina el retorno incremental por adopción (traducción mía de 'increasing returns to adoption'). Lo que esto quiere decir es que en muchas industrias mientras más se adopta más una tecnología, esa tecnología se convierte en más valiosa.

Entre otras cosas, cuanto más se adopta una tecnología, existe, por un lado más recursos económicos para seguirla desarrollando y refinando.

Además, se produce una mayor experiencia acerca de su uso y resultados y, también una mayor conocimiento y entendimiento de la tecnología propiamente dicha lo cual, de nuevo, permite refinarla y mejorarla.

Además, si una tecnología se convierte en dominante, se produce un crecimiento de la oferta de productos complementarios especializados en interactuar con esa tecnología.

En conjunto, todo esto produce una especie de círculo virtuoso, que hace que el diseño dominante gane ventaja y se convierta en más dominante todavía.

Acompañando y potenciando esos retornos incrementales por adopción, tenemos otros dos elementos: el efecto aprendizaje y las externalidades de red.

El efecto aprendizaje nos habla de un hecho comprobado empíricamente y es que, a medida que una tecnología madura y se conoce mejor, ésta se convierte en más efectiva y más eficiente, tanto en su uso como en su diseño y producción. El diseño dominante, al generar mayor adopción, favorece este efecto aprendizaje que, de nuevo, realimenta a ese diseño dominante.

Las externalidades de red, por su parte, nos hablan de productos o servicios cuyo valor aumenta por el hecho de tener más usuarios (como ocurre, por ejemplo, con las redes de todo tipo, ya sean redes sociales, redes de telecomunicaciones o redes de transporte). Estas externalidades de red no sólo se producen en redes como tales sino, por ejemplo, en casos donde la compatibilidad es importante o cuando lo son los bienes o productos complementarios.

Una precaución estratégica: los mercados 'todo para el ganador'

Una advertencia de naturaleza estratégica es que en muchos mercados tecnológicos y, especialmente cuando consolidan en un diseño dominante, esto empuja hacia una gran consolidación e, incluso, a monopolios naturales.

Este efecto 'todo para el ganador', aparte de las eventuales consideraciones regulatorias, impone ciertas dinámicas competitivas porque, evidentemente, cuando todavía el mercado o tecnología no están maduros, las diferentes propuestas lucharán entre sí para intentar que el suyo se convierta en ese diseño dominante y conseguir con ello la posición central y privilegiada en el mercado.

Dicho de alguna manera: para el desarrollo de la tecnología y su mercado seguramente sea muy positivo la consolidación en un diseño dominante, pero para los actores en competencia, supone una oportunidad, pero también un notable riesgo.

La situación en el caso de robots humanoides

Si ahora pensamos en el mercado de robots humanoides, diría que aún es un poco pronto para una consolidación en un diseño dominante. Y lo es porque, pese a los importantes y rápidos avances, no me parece que la tecnología se encuentre suficientemente madura y, además, el mercado como tal es aún muy pequeño.

Por otro lado, en el caso de los robots humanoides, estamos hablando de unas soluciones tan complejas que, en realidad, reúnen muchas tecnologías, varias de las cuales son novedosas y en pleno desarrollo. Quizá, cuando lleguen, podríamos hablar de varios diseños dominantes, cada uno para uno de los elementos tecnológicos.

Aún así, hay pequeños atisbos o gérmenes de posibles diseños dominantes.

Aunque no creo que sea lo más relevante en este caso, en cuanto a aspectos morfológicos, sí observo que varios robots humanoides se parecen físicamente mucho entre sí.

Quizá el aspecto más a tener en cuenta tenga que ver con el hardware y los procesadores, donde NVIDIA, con todo su poder en este campo, se ha situado de forma muy potente con sus últimas propuestas como Jetson Thor.

En el campo de la inteligencia parece que los modelos VLAM (Visión-Language-Action Models), con toda su sinergia con el 'mainstream' actual en modelos generativos (que comenté en el post 'tokens, embeddings y algunos trucos de magia'), pudiera ser la opción favorita, supongo que apoyada en mecanismos más tradicionales de control en el bajo nivel.

En contra de una consolidación a corto plazo de modelos dominantes, se encuentra el que a nivel tecnológico, como digo, creo que aún estamos inmersos en mucha investigación y exploración y que, en cuanto a mercado, también es muy reducido. El diseño dominante parece que exige una cierta madurez (no absoluta, pero si en cierta medida) a la que creo que aún no se ha llegado, y un mercado razonable al que dirigirse

Y probablemente opere en contra la propia lucha competitiva, porque todos los fabricantes principales de robots humanoides, o de algunos de sus elementos, parece lógico que aspiren a establecer su diseño como diseño dominante para conseguir esa posición privilegiada en el sector que les conduzca a ser los ganadores. Así que, parece esperable que, al menos durante un tiempo, se resistan a adoptar diseños ajenos y preferirán seguir desarrollando su propia tecnología.

Eso sí, aunque creo que ni la tecnología ni el mercado están maduros ahora mismo para la adopción de un diseño dominante, las 'cosas' se mueven muy rápido y, a lo mejor, especialmente en lo que a la tecnología se refiere, los avances son rápidos y permiten empezar a avistar posibles arquitecturas o soluciones ganadoras muy pronto.

Habrá que seguir observando muy de cerca.

Conclusiones

El concepto de 'diseño dominante' es muy importante en innovación tecnológica. Si lo intento trasladar al campo de los robots humanoides, me da la sensación de que aún es prematuro pensar en un diseño dominante, tanto por falta de madurez tecnológica como de mercado Sin embargo se trata de un campo que avanza muy rápidamente, así que es posible que no tardemos en ver algún movimiento de consolidación tecnológica o de convergencia de soluciones, que anticipen ese diseño dominante.

Tokens, embeddings y algunos trucos de magia

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 11 Mar 2026 09:30:00 +0000

Como es bien sabido y abundantemente citado, el escritor de ciencia-ficción, Arthur C. Clarke, decía en su libro 'Profiles of the future' que

Cualquier tecnología suficientemente avanzada es indistinguible de la magia

Y, en efecto, cuando contemplamos a la inteligencia artificial actual, muy especialmente la inteligencia artificial generativa, es difícil no maravillarse como si estuviésemos ante un espectáculo de magia, una sensación que parece acentuarse ante los resultados tan efectistas que se pueden conseguir en materia de imagen, vídeo o música.

Pero, en mi caso, sin dejar de maravillarme sus resultados externos, visibles como mero usuario, me maravillan tanto o más los elementos de diseño y arquitectura que hay por detrás que y que, aunque menos conocidos, aunque en apariencia menos brillantes, no dejan de ser un canto a la ingeniería, al diseño y, en el fondo, al ingenio humano.

Y, en este post, quiero, intentando mantenerme en un nivel más divulgativo que técnico, explicar algún truco de magia que traen consigo los modelos generativos actuales, basados, de una forma u otra en la famosa arquitectura 'transformer', base, por ejemplo, de los modelos GPT.

Antes, presentar a los protagonistas de los trucos de magia que vendrán a continuación: los tokens y los 'embeddings'.

Los tokens

¿Qué son los tokens?

Bueno, realmente no es fácil dar una definición compacta, abarcadora y a la vez comprensible de lo que son los tokens, aunque en el fondo la idea es muy sencilla. Los tokens vienen a ser como las piezas que constituyen un contenido. Dicho así, a lo mejor no queda muy claro, pero si pensamos en el caso del lenguaje, y pensamos, en primera instancia, que los tokens son las palabras, la cosa queda mucho más clara ¿no?

Ahora que seguramente nos hemos hecho a la idea un poco intuitiva de lo que son los tokens, conviene advertir que, en realidad, los tokens no tienen por qué coincidir con las palabras: en ocasiones son palabras, en ocasiones simples caracteres, en otros caso partes de una palabra (como la raíz de un verbo) y, en otras ocasiones, en fin, algunos caracteres especiales. Lo que queda claro es que los tokens son partes de un texto de forma que, combinándolas, nos dan el texto completo.

Todos los grandes modelos de lenguaje trabajan con un catálogo cerrado de tokens. Por catálogo cerrado quiero decir, que es un número acotado de tokens perfectamente conocidos. Cada modelo maneja su propio catálogo de tokens que suele incluir unos miles o decenas de miles de tokens posibles. Y, usando esos tokens, los modelos son capaces de componer o descomponer cualquier texto en tokens de ese catálogo. De hecho, el primer paso habitualmente de un gran modelo de lenguaje, ante la recepción de un texto de entrada (digamos que el 'prompt') es dividirlo en los tokens que lo constituyen.

Los 'embeddings'

Vale, pues pasemos ahora a los 'embeddngs'. ¿Qué son los 'embeddings'?

No he llegado a averiguar (ni siquiera a intuir) por qué se les asigna con ese nombre 'embeddings' (que tanto cuesta traducir al castellano de forma que se entienda), pero decir que los 'embeddings' son, básicamente, representaciones vectoriales de los tokens. Hilando muy fino en 'las tripas' de los modelos, hay casos en que los 'embedding' no representan exactamente un token, pero no me voy a meter en ese charco para que no se pierda la idea fundamental y vamos a quedarnos, aunque pueda ser una cierta simplificación, con que los 'embeddings' son representaciones vectoriales de los tokens.

Espero que el lector recuerde que, de nuevo simplificando, un vector es una colección ordenada de números reales (en realidad puede ser una colección ordenada de cualquier cosa, pero, de nuevo, voy a prescindir de ello para 'no liar la cosa'). Los vectores tienen un uso algebraico, al que en seguida volvemos, un interpretación geométrica (la representación de las coordenadas de un punto en el espacio) y una interpretación física (una magnitud con dirección). Y los 'embeddings' son representaciones vectoriales de los tokens que van a hacer uso tanto de su carácter algebraico como de la interpretación geométrica.

Van a hacer uso de la visión algebraica, haciendo que los 'embeddings' sean elementos de un espacio vectorial y que sean aplicables sobre ellos todas las operaciones con vectores, matrices y tensores del algebra lineal y todas las transformaciones lineales propias de los espacios vectoriales. Y, así, van a convertir el entrenamiento e inferencia de redes neuronales profundas de los modelos de lenguaje mayormente en operaciones de algebra lineal.

Eso si, los 'embeddings' no son vectores de tres dimensiones como los que utilizamos en geometría normal, sino de cientos o miles de dimensiones.

Primer truco de magia: semántica y conocimiento

Vale, hasta aquí, nos puede parecer bien o mal el uso de tokens y 'embeddings', pero quizá no veamos la magia.

Vayamos a por el primer truco de magia: la semántica.

Esos vectores que son los 'embeddings' no son vectores con valores arbitrarios. Nada de eso: durante el entrenamiento de los modelos se ajustan esos 'embeddings' que con ello alcanzan un valor semántico, de significado. En realidad no se trata de una semántica absoluta, no es que el valor de un 'embedding' nos proporcione, de alguna manera, un significado, como si buscásemos en un diccionario. Se trata de lo que podríamos denominar una 'semántica relativa'.

Entender lo que es esa 'semántica relativa' (término que, por cierto, me acabo de inventar) debemos acudir a la interpretación geométrica de los vectores como representación de la coordenada de un punto en un espacio. Pues bien, de la misma forma que en geometría calculamos la distancia entre dos puntos, en modelos de lenguaje podemos calcular la distancia entre dos 'embeddings', es decir, entre dos tokens, es decir, simplificando un tanto, entre dos palabras.

Y si la distancia entre dos 'embeddings' es pequeña quiere decir que tienen relación de significado y también de uso. Es decir, si la distancia entre dos 'embeddings' es pequeña, quiere decir que su significado es parecido y está relacionado y/o que habitualmente se usan juntos.

Para conseguir eso, claro, hay mucho diseño interno de las redes neuronales que constituyen los modelos, hay mucho de mecanismos como la famosísima atención y auto-atención, etc pero el caso es que, una vez entrenado un modelo, esas relaciones de distancia geométrica, acaba recogiendo, por vía en el fondo indirecta, el conocimiento de la estructura (morfología y sintaxis) del lenguaje humano y, lo que es más increíble, su significado.

¿No es increíble?

Pues espera, que este primer truco tiene una vuelta de tuerca adicional. No es sólo que hayamos conseguido unos modelos que recogen la estructura y significado del lenguaje humanos, es que además... ¡Abracadabra! ... también recoge todo el conocimiento que el ser humano ha volcado en los textos con que se ha entrenado.

Creo que esto se merece un fortísimo aplauso de admiración.

Segundo truco de magia: multimodalidad

Pero la función no ha hecho más que empezar.

Hemos hablado hasta ahora de modelos de lenguaje pero ¿y qué pasa con las imágenes, los vídeos o el sonido? ¿Qué pasa con los modelos multimodales?

Pues, por supuesto simplificando, lo que pasa es que usamos los mismos fundamentos.

Es decir, reducimos las imágenes o el sonido a un catalogo cerrado de tokens (esto, en caso de magnitudes continuas como es el sonido implica un esfuerzo de discretización). Y representamos esos tokens, de nuevo como 'embeddings' que ajustamos en el entrenamiento.

Pero, aún hay más, hacemos que los 'embeddings' de las diferentes modalidad (digamos que texto e imagen) se encuentren en el mismo espacio vectorial y hacemos un entrenamiento conjunto (por ejemplo, con imágenes y sus descripciones textuales) y, de esta forma, tenemos relaciones estructurales y semánticas entre imágenes y texto o entre texto y música pro ejemplo, de forma que luego podamos describir con palabras qué imagen o qué música queremos y el modelo 'nos entienda'

¡Tachán!

Creo que esto se merece otro fuerte aplauso.

Tercer truco de magia: el mundo físico y los robots

Pero ¡espera!, que tenemos otro truco de magia.

¿Qué pasa con el mundo físico? ¿Qué pasa con los robots?

Pues se está trabajando ya en los denominados VLAM (Vision-Language-Action Models), pensados para el mundo físico y, muy especialmente, el control de robots.

Estos modelos trabajan típicamente con dos entradas: por un lado, un 'streaming' de video con lo que recogen las cámaras del robot y una entrada lingüística, típicamente instrucciones de un operador humano.

Hasta ahí, estamos en una situación parecida a los modelos multimodales. Pero lo original es la salida: las acciones. Las acciones son representaciones de lo que tiene que hacer el robot, en algún caso acciones de alto nivel como ('coge un objeto') o, en otras instrucciones de más bajo nivel más próximas a lo que entienden los motores y actuadores del robot.

¿Y, cómo se representan las acciones? Lo has adivinado, como tokens y sus correspondientes embeddings. Y, en el entrenamiento se unen conjuntos de datos con información de video, de texto y de las acciones correctas del robot. En el fondo, es como tratar las acciones en el mundo físico como una nueva modalidad.

El público ya está en pie, aplaudiendo enfervorecido...

Ética y alineamiento ¿Un cuarto truco de magia?

Con esto, casi hemos acabado la función, pero te anuncio lo que puede ser el próximo truco de magia, y que tiene que ver con la ética y con los valores.

Cuando nos preocupamos del comportamiento de la inteligencia artificial, cuando pensamos en seguridad y en ética, hablamos, como un mecanismo de protección, del alineamiento, es decir, que los sistemas de inteligencia artificial compartan los valores humanos y se comporten con arreglo a ellos.

Aunque sugerente, este enfoque tiene alguna dificultad y, una de ellas es cómo formalizamos esos valores humanos para que los entienda una máquina.

Bueno, no voy a entrar en detalles porque en este momento no los tengo pero, minutos antes de comenzar la redacción de este post, estaba leyendo un libro en que se mencionaba (aunque sin explicarlo) algún modelo que ya recoge esta idea de los valores y algún 'dataset' para entrenar en valores.

Y he creído entender que el modelo se basa en la misma arquitectura transformer que todos los que hemos comentado. No sé si se tratan de alguna forma los valores, de nuevo, como si fuera otra modalidad, si se trata de una suerte de 'fine-tunning' de un modelo generativo o si, simplemente, de la misma forma que de manera indirecta los modelos de lenguaje recogían el conocimiento humano, se pueda conseguir mediante un, digamos, 'dataset etico', que el modelo tenga embebidos los valores éticos humanos.

En cualquier caso, el planteamiento parece perfectamente viable y muy esperanzador.

Así que, no dejen de volver para la próxima función de magia.

Conclusiones

Es maravilloso contemplar como los modelos generativos de inteligencia artificial, con base a la idea de los tokens y los 'embeddings' y usando, claro, avanzadas y sofisticadas arquitecturas de red neuronal y estrategias de entrenamiento, han sido capaces, en poco tiempo, de reconocer y saber utilizar el lenguaje humano, de recoger todo el conocimiento con él expresado, de mezclar ese conocimiento con otros medios como imagen, vídeo o música y parece que ahora están consiguiendo incluso expresar las acciones de robots u otras formas de actuadores sobre el mundo físico y, en un último e inesperado giro de guion, parece que hasta nos pueden servidor para recoger los valores humanos y hacer un guiado ético de sistemas y robots.

Ya lo decía Arthur C. Clarke... cualquier tecnología suficientemente avanzada es indistinguible de la magia.

Inteligencia artificial, creación y el proceso interior

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 04 Mar 2026 10:55:00 +0000

Comienza a ser un debate recurrente, en algunos casos puede que hasta cansino, la relación del humano con la inteligencia artificial, si nos sustituirá o no, si sólo debe actuar como un copiloto o si afecta a nuestras capacidades cognitivas o no.

En este post quiero hacer una breve reflexión sobre el caso concreto del proceso creativo. Una reflexión que no es teórica, y que no busca realmente un posicionamiento, sino que es una visión muy individual mía, muy experiencial, aunque presumo que sensaciones parecidas las deben experimentar muchas otras personas, y por eso me parece valioso compartirlo.

El salto de la inteligencia artificial generativa

Quizá unos de los ámbitos en que más ha mejorado la inteligencia artificial en los últimos tres años, sea en todo lo que tiene que ver con la 'creación' o, si se prefiere, la generación de contenidos. Unos contenidos que inicialmente, fueron esencialmente textuales, pero en seguida saltaron a la imagen, al vídeo y a la música.

Un proceso, ese de la generación que, sobre todo en el campo del texto, va más allá de una creación mecánica de ese texto, sino que aporta 'conocimiento', datos y estructura. Y que, además, puede incluso hacer uso de resortes emocionales, quizá especialmente destacados en el caso de la generación musical.

Sobre el discutido concepto de creatividad

Se discute mucho sobre lo que es creatividad y lo que no y, sobre todo, si lo que hace la inteligencia artificial generativa es verdadera creatividad o no y, yendo más lejos, si se puede llegar a considerar arte algo creado con inteligencia artificial generativa.

No creo que sea un tema claro, realmente. Me parece, aunque me confieso un poco lego en la materia, que el propio concepto de lo que es el arte es, como diría 'el otro', algo discutido y discutible.

Pero sin llegar a la de idea de arte, y quedándonos sólo en creatividad, se alega a veces que la inteligencia artificial no es creativa porque, en el fondo, reutiliza unos patrones de base estadística que se le han enseñado y los utiliza para sus nuevas creaciones o, si se prefiere, generaciones. No sé si eso es suficiente para decir que la inteligencia artificial no es creativa, y menos teniendo en cuenta que parece que, en el fondo, la creatividad humana funciona, al menos parcialmente, de la misma forma: aplicando a ámbitos nuevos o de formas nuevas patrones que ya ha visto en el pasado.

En cualquier caso, el debate sobre la presunta o no creatividad de la inteligencia artificial, aunque atractivo, no es lo que me ocupa ahora. Para lo que sigue, el que llamemos creatividad o no a producción de contenidos de la inteligencia artificial generativa, me es irrelevante.

Lo cierto es que puede crear textos, imágenes, videos, sonidos y música nuevos y de una alta calidad factual y estética.

¿Dónde quedamos los humanos y nuestra creatividad y nuestro arte, ante todo esto?

Tomándomelo de modo personal

Todo lo que antecede es una exposición de contexto, pero a partir de aquí comienzo con mi experiencia personal. Y para esa experiencia hablaré de mi particular producción de contenidos.

Mi producción de contenidos se centra especialmente en lo textual, en la escritura. Creo textos, por ejemplo, para este mismo blog. He creado, y espero seguir creando, texto para los libros que he publicado o en los que he colaborado. He creado texto como material docente. He creado, incluso, aunque al menos de momento muy poco publicado, texto de naturaleza más artística, del ámbito literario (ensayo, narrativa e incluso alguna especie de poesía).

Para mi labor como 'speaker' y como docente, utilizo también mucho las hoy en día un poco denostadas presentaciones PowerPoint.

En bastante menor medida también creo en otros medios. Creo imágenes como complemento de artículos o presentaciones. Creo algunos vídeos como promoción, como realce de alguna charla o clase... o por el placer de hacerlo. Creo con mi voz participando en podcasts. Y he creado algo de música fundamentalmente como fondo de vídeos.

Para esta creación multimedia, imágenes, video y música hoy en día me apoyo mucho, cada vez más, en el uso de la inteligencia artificial.

Sin embargo, para la voz y, sobre todo, para la creación textual y las presentaciones, pese a que sabría perfectamente cómo hacerlo con inteligencia artificial (es más, de vez en cuando enseño cómo hacerlo) mi mecánica sigue siendo clásica, es decir, genero el texto o las presentaciones por mí mismo, más o menos manualmente, aunque, evidentemente, usando un ordenador, y esporádicamente alguna ayuda de la inteligencia artificial.

¿Por qué ese diferente planteamiento según el contenido que genero?

Pues tiene mucho que ver con lo principal que quiero transmitir en este post: con el proceso interior de creación. Pero antes, un apunte sobre la calidad del resultado generado con inteligencia artificial.

La calidad del resultado

La inteligencia artificial generativa ha avanzado una barbaridad en poco tiempo y los resultados que ofrece son cada vez mejores. Los textos están bien redactados, bien estructurados, con mucho conocimiento por detrás y, en general, 'suenan bien' o incluso muy bien.

La calidad física de imágenes, vídeos y música es muy alta. Por calidad física me refiero a calidad del sonido en música o a la resolución y calidad de imagen en imágenes estáticas y vídeo. La composición suele ser buena, pero aquí, y reconociendo antes mi escasa preparación en materia de diseño o arte visual, tengo algunas 'pegas'. Las imágenes, si uno no se pelea mucho con ellas, y usando prompts cada vez más especializados, suelen ser abigarradas y un poco repetitivas. En el vídeo, se observan todavía con cierta frecuencia las famosas alucinaciones. En general, además, y aunque me imagino que esto se podría superar con práctica, insistencia y un promting avanzado y especializado, las herramientas tienden a generar imágenes, vídeo y música, de buena apariencia, pero un poco 'según le parece' y cuesta guiarla a que realicen tu idea (cuando la tienes). Con frecuencia, si no se pelea mucho, los resultados tienden además a ser repetitivos.

En general, mi sensación es que la calidad de la producción textual, es ahora mismo bastante más alta que la de la producción multimedia, pese a que ésta última nos impresiona muchísimo más.

Y, sin embargo, pese a que la inteligencia artificial genera, en mi opinión, mejores resultados en texto que en multimedia, mi uso es justo al revés, la utilizo mucho en multimedia y poco en texto.

¿No es esto contradictorio?

Pues la respuesta tiene mucho que ver con el proceso interior.

El proceso interior y la experiencia personal

Por el proceso interior, me refiero a mi forma de trabajar en la creación de contenidos, lo que experimento cuando lo hago, y lo que eso aporta al resultado y, sobre todo, a mí mismo. Y un proceso que, aunque describo como propio, me imagino que cualquier otra persona experimenta algo parecido.

En ese proceso interior de creación aportas y recibes.

Veámoslo de forma separada

Lo que aportas cuando creas

Cuando estoy creando un texto de tipo profesional, para publicar o para docencia, aporto por un lado mi conocimiento, todo lo que he aprendido estudiando, leyendo, trabajando o escuchando a otros. Y aporto la experiencia profesional, lo que he vivido en las empresas que he trabajado, los clientes o proveedores con los que he tratado, lo que he visto en jefes y colaboradores. Y, no sólo eso, aporto mi comprensión, síntesis y en ocasiones opinión sobre el tema tratado. La inteligencia artificial puede aportar mucho en cuanto a conocimiento, datos y estructura en este ámbito pero siento, y no quiero ser presuntuoso, que con frecuencia no está a mi altura. Lo que hace es muy correcto y lo cuenta muy bien... pero le falta 'un algo', un algo de discurso, de claridad, de exposición, de perspicacia, a veces incluso de 'alma' o personalidad. Salvo en casos y temas concretos, me gusta mucho más el contenido textual que yo genero que el que me aporta la inteligencia artificial. No es un prejuicio, es lo que veo.

Es importante resaltar, y de nuevo no quisiera ser presuntuoso pero sí claro, que esto es así en parte, por mi propias capacidades, circunstancias y motivaciones. Creo que puedo generar mejores textos que la inteligencia artificial porque atesoro mucho conocimiento, experiencia, lecturas y estudio en mis ámbitos de especialidad, porque además me gusta escribir y tengo mucha práctica en ello y, finalmente, porque soy perfeccionista y me gusta 'hacer las cosas bien' y dar los mensajes correctamente, en el orden correcto, de manera comprensible y, si es posible, incluyendo motivación.

Aún así, reconozco que, en cuanto a aportación, la inteligencia artificial es un gran competidor.

Y es por mi aportación, por lo que, en parte, no utilizo la inteligencia artificial en la generación de textos pero sí en multimedia. Porque si en texto yo creo aportar mucho, en multimedia no es así.

Multimedia para mí es muy diferente. No tengo formación artística ni musical, salvo la muy básica obtenida en la enseñanza obligatoria. No tengo habilidad manual ninguna para dibujar. No le dedico demasiado tiempo a contemplar arte o a escuchar música. Y, quizá, uniendo la escasa formación y la falta de dedicación a contemplar las obras de terceros, no tengo imaginación suficiente para concebir una buena escena de vídeo y muchísimo menos una buena canción. Por todo ello, tengo muy poco que aportar a la hora de creación de imagen, vídeo o música. Y, sin embargo, la inteligencia artificial me permite crear con muy poco esfuerzo, aunque con las carencias ya reseñadas, imágenes, vídeos y canciones de alta calidad física, y razonable, aunque no perfecta, composición. Eso es mucho más de lo que yo soy capaz de hacer. Y por eso no duda en utilizar la inteligencia artificial.

Lo que recibes cuando creas

Pero luego está lo que yo recibo. Y probablemente eso sea muchísimo más importante y más decisivo a la hora de no utilizar la inteligencia artificial que la visión de lo que aporto.

He expresado más de una vez que 'pienso cuando escribo'. Cuando redacto un texto, del tipo que sea, reflexiono sobre lo que estoy escribiendo, maduro y cuestiono ideas, estructuro el mensaje. Incluso temas que domino, pasan por ese tamiz de la reflexión, el cuestionamiento y la reestructuración. Y todo ese proceso, aparte de ayudar a generar un mejor resultado, es enormemente enriquecedor para mí mismo, y diría que es también una forma de aprendizaje.

La reflexión, cuestionamiento y reestructuración del contenido es en sí mismo, como decía, un proceso de aprendizaje. Te ayuda a entender mejor, a estructurar mejor y a recordar. Es muy agradable, muy satisfactorio desde el punto de vista intelectual y muy enriquecedor. Te hace mejorar y a la vez te hace disfrutar. Al menos a mí.

Lo anterior aplica sobre todo a la escritura profesional.

En el caso de la escritura literaria, también aplica en buena medida lo anterior, sobre todo la reflexión, pero hay algo más y diferencial, que es la emoción. En el caso de algunos textos de carácter literario (alguno publicado y alguno no), la propia escritura me ha despertado emociones, porque al fin y al cabo escribes sobre cosas que, de alguna manera, te importan. Puede parecer absurdo, pero alguna vez hasta he soltado alguna lagrimita al releer algo que acaba de escribir. Me creo que la inteligencia artificial escriba un texto que te pueda llegar a conmover...pero estoy seguro de que no es lo mismo, en absoluto, que cuando es un texto tuyo, escrito por ti y sobre lo que te importa.

Como he dejado patente, no realizo verdadera creación artística en materia de imagen, vídeo o música. Pero presumo que, algo paralelo a lo que yo experimento al escribir, lo puede vivir un pintor o diseñador gráfico al crear una imagen, un cineasta al crear un corto o un compositor al crear una nueva pieza musical.

E, incluso, si supusiésemos, y puede llegar a ser cierto, que la inteligencia artificial llegue a generar textos, imágenes, vídeos y música de calidad, no solo física sino también artística, superior o similar a la humana, sólo por el hecho de experimentar en uno mismo el proceso interior de la creación, valdría la pena no utilizar la inteligencia artificial, o al menos no de vez en cuando, al menos no para aquello que realmente te importa.

Y el proceso exterior

Sólo un apunte final, que ya no hace mención al proceso interior, sino al proceso exterior.

Para el caso de creación de tipo profesional, para documentos, logotipos, presentaciones, vídeos promocionales, tiendo a pensar que al público receptor de la creación, le importe poco si lo ha hecho la inteligencia artificial, una persona o a medias. Tiendo a pensar que lo que vale es el resultado.

Pero ¿y en el caso de la creación puramente artística? ¿Y en el caso en que al autor trasmita experiencia y emociones propias?

¿Le importaría al lector de una poesía o una novela introspectiva que haya una persona detrás que vivido, sufrido y disfrutado, o quiere sólo el texto?

Y lo mismo diría de cualquier otra creación puramente artística ¿Nos importa sólo el producto o también la persona y experiencia que hay detrás?

De la contestación a esas preguntas no estoy seguro. Creo que, probablemente, a muchas personas les dará igual quién sea el autor o autora de la obra, y si es una persona o la inteligencia artificial. Pero también quiero suponer, y supongo realmente, que habrá personas que esperan que haya una persona al otro lado, un escritor para una novela, un poeta para una poesía, un compositor para una melodía.

Conclusiones

La inteligencia artificial es capaz de generar contenidos de una altísima calidad formal y una buena calidad en cuanto a composición. Y pudiera, en esa labor de creación, llegar a sustituir a los humanos.

Sin embargo, en ciertas ocasiones, los humanos bien preparados, creo que pueden generar mejores resultados.

Y, sobre todo, lo más importante y más allá del resultado, el propio proceso interior asociado a la creación, es tan agradable, tan satisfactorio y tan enriquecedor que aunque sólo sea por experimentarlo, vale la pena no delegar en la inteligencia artificial según qué cosas.

¿Qué inteligencia artificial queremos enseñar?

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 02 Mar 2026 09:15:00 +0000

Ante el auge imparable de la inteligencia artificial, ante la riqueza de opciones de adopción y casos de uso disponibles, se produce una enorme demanda de formación en inteligencia artificial. una demanda de la que, por supuesto, no puedo dejar de alegrarme.

Es una reacción lógica de empresas e incluso individuos: si estamos ante una tecnología tan transformadora y tan disponible, debemos, como personas y como empresas, ponernos manos a la obra cuanto antes para conocerle y utilizarla

Existe, incluso, una demanda por parte de regulaciones como la AI Act que habla, aunque de forma algo borrosa, de alfabetización en IA.

Sin embargo, creo que con frecuencia, precisamente porque es una tecnología que todavía se está conociendo, no existe claridad en la demanda de formación, ni por parte de individuos ni de organizaciones, puede que muchas veces ni siquiera por parte de las propias entidades dedicadas a formación: escuelas de negocio, academias, universidades, etc.

Y lo cierto es que es muy diferente no sólo el currículum a desarrollar, sino incluso el estilo y profundidad de una docencia en inteligencia artificial según el colectivo a que nos dirijamos, su punto de partida y sus expectativas.

Aunque muchas son las posibilidades, veo tres grandes currícula muy comunes, a saber:

Inteligencia artificial para usuarios
Inteligencia artificial para directivos
Inteligencia artificial para desarrolladores

Pero en realidad, las opciones son muchas y, aunque quizá, se trate de caso algo más particulares, voy a comentar otros dos:

Inteligencia artificial para científicos de datos
Inteligencia artificial para juristas

No voy a entrar en currícula detallados, pero sí brevemente voy a comentar qué se espera, o debería esperar, de una formación en cada una de estas visiones.

Inteligencia artificial para usuarios

Probablemente sea lo más demandado ahora mismo. Ante el auge de la inteligencia artificial generativa, ante lo sencillo que es utilizarla y ante las inmensas posibilidades que ofrece, una gran demanda cae en este campo: ¿Cómo utilizar la IA generativa en mi día a día?

Fundamentalmente se trata de formación muy práctica, con escasa teoría, en ingeniería de instrucciones ('prompt engineering') adornada con presentar diversas herramientas como, por supuesto, los chatbots generativos (ChatGPT, Gemini, Claude, etc) pero también otras herramientas algo más especializadas para crear presentaciones, videos, música, etc. Y todo ello aderezado con la identificación de muchos casos de uso, unos casos de uso normalmente centrados en el trabajo individual.

Es una formación en cierto sentido superficial, pero muy útil en el día a día, muy demandada y muy bien recibida en general porque es, a la vez, útil y divertida.

Inteligencia artificial para directivos

Un currículm algo más heterogéneo y más difícil de centrar es la formación en inteligencia artificial para directivos. De nuevo, y como en el caso del colectivo anterior, los directivos, creo que de forma algo equivocada, huyen de la teoría, por lo que, aunque creo que se debe aportar algún fundamento, los contenidos suelen estar orientados a dónde y cómo aplicar la inteligencia artificial en la empresas.

Un peligro actualmente es centrarse sólo en las soluciones generativas cuando, en el ámbito de la empresa, siguen teniendo mucho peso e interés los modelos de machine learning más tradicionales usados en analítica inteligente y modelos predictivos y prescriptivos.

De nuevo, tienen mucho interés los casos de uso pero en este caso, se deben ver con una perspectiva algo más amplia e incluir, no sólo el empleo individual de herramientas generativas sino la aplicación corporativa de la inteligencia artifivial en materia de analítica y automatización.

Aunque no siempre los directivos (salvo que pertenezcan a un área de IT) están interesado en ello, creo que es bueno que conozcan, además, algo de los servicios ofrecidos en la nube, especialmente por hiper-escaladores y, en general el mercado de soluciones existentes.

A eso, añadir elementos importantes de gestión del dato, de gobernanza, de ética, de legislación y 'compliance'.

Inteligencia artificial para desarrolladores

Un perfil completamente diferente es el de los desarrolladores: personas técnicas que van a construir, 'con sus manos', soluciones de inteligencia artificial.

En este caso creo que precisan de algo más de teoría en cuanto a algoritmia y arquitectura. Por supuesto, es inexcusable el conocimiento de python (aunque puede ser interesante alguno otro lenguaje como R) y de las librerías que se utilizan en el ámbito del machine learning tradicional y para el uso de modelos generativos.

Deberían conocer también las plataformas en la nube y alguna comunidad, muy especialmente Hugging Face.

Probablemente también sea conveniente formación en gobierno del datos y en las pruebas y evaluación de modelos.

Y, quizá, se debería comenzar a comentar elementos de 'vibe coding' o desarrollo software asistidopor inteligencia artificial.

*****

Creo que, aunque de una forma simplificada, estos son los tres grandes perfiles, pero, por supuesto, la formación se puede y debe adaptar a diferentes colectivos, diferentes expectativas y diferentes puntos de partida. Y, un poco en esa línea, voy a comentar otros dos perfiles posibles.

*****

Inteligencia artificial para científicos de datos

Se trata de un perfil parecido al de desarrollador, pero, en aquellas empresas que distinguen entre los ingenieros de datos (más próximos a la pelea con los datos y al desarrollo) y los científicos de datos, más próximos a los modelos propiamente dichos y al negocio, la formación de este colectivo, puede diferir ligeramente.

Por ejemplo, puede poner más énfasis el conocimiento de los diferentes modelos y algoritmos de machine learning y cuándo aplicarlos así como todo lo relativo a la evaluación de los modelos. Deben ponerse énfasis también en aquella parte de las plataformas orientadas a la selección de modelos con especial interés en que conozcan los posibilidades de Auto ML.

Quizá, en este colectivo, pueda ser interesante también poner algo más de foco en los aspectos de responsabilidad y ética, y alguna pincelada de 'compliance'.

Adicionalmente, y aunque adaptado a cada caso, dado que los científicos de datos se orientan a las necesidades del negocio, puede ser bueno una formación específica en vocabulario, aspectos sectoriales y particularidades del sector o área funcional a que se dirigen sus modelos. Por ejemplo, podría ser relevante la formación en marketing digital.

Inteligencia artificial para juristas

Un colectivo muy interesado en la inteligencia artificial es el de los juristas. En este caso, podrían recibir una formación similar a la de directivos cuando lo que buscan es la aplicación en su bufette o empresa, pero cuando los distingo como colectivo es pensando en una formación orientada a aplicar las regulaciones sobre IA o a orientar a sus clientes en los mecanismos de protección y 'compliance'.

En este aspecto, por supuesto, deberían recibir formación, si no la tienen ya, en las regulaciones existentes, notoriamente en Europa en RGPD y AI Act.

Pero sería muy conveniente una formación algo más teórica sobre fundamentos de inteligencia artificial, sobre cómo funcionan y manejan los datos los algoritmos tanto de machine learning tradicional como lo s generativos.

Igualmente, deberían recibir formación en gobernanza de datos y de sistemas de inteligencia artificial y en normativa como el estándar ISO 42001.

Muchas otras opciones

No se acaban aquí, las opciones, pudieran existir formaciones mixtas o dedicadas a aspectos particulares como la ciberseguridad, pero creo que lo dibujado más arriba traza un poco las opciones existentes y, sobre todo, destaca, que es lo que en el fondo pretendía con el post, que no es realista ni practico hablar de formación o alfabetización en inteligencia artificial sin más, sino que debemos saber de dónde partimos, a que colectivo nos dirigimos y que necesitamos realmente que sepan de la inteligencia artificial.

Conclusiones

Es muy necesario hoy en día formarnos, individualmente y como organizaciones en inteligencia artificial, pero a la hora de realizar una demanda de formación, conviene 'centrar el tiro' y saber qué pretendemos realmente.

La cadena de producción en computación: el viaje de la especialización de los procesadores

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 26 Feb 2026 09:00:00 +0000

Termino con este post una serie un poco espontánea (no tenía decidido realmente hacer una serie, sino que ha salido así) que he dedicado al mundo del hardware y los procesadores, tema que, la verdad sea dicho, apenas había abordado antes en este blog.

Y mi interés sobre el particular ha surgido suscitado por las reflexiones sobre algunos episodios en que he participado del podcast 'Código abierto' y en que hemos hablado del tema, y de forma más inmediata por la lectura del libro 'Mastering NVIDIA CUDA and Tensor Cores' que explica la arquitectura de procesadores de NVIDIA y cómo se programa con ellos.

En este post, simplemente quiero resaltar una paradoja y una metáfora respecto a los procesadores.

La paradoja es que, a medida que queremos conseguir más potencia, acudimos a procesadores más sencillos en cierto sentido. La metáfora es la de una cadena de producción en computación.

Y todo ello, aderezado con una especie de arqueología tecnológica o 'memoria histórica' de la computación.

Recordando los microprocesadores para PC

Y empiezo un poco con esa memoria histórica, casi con esa nostalgia.

Pues si, no puedo dejar de recordar los tardíos años ochenta o principios de los noventa cuando asistimos, y en mi caso con mucha implicación, a la aparición y expansión súbita de los ordenadores personales, los famosos PC.

Recuerdo que mi primer ordenador personal, un Inves 640-X, incorporaba un microprocesador Intel 8088, aunque en aquel momento ya la mayoría de PCs venían dotados de un Intel 8086. Y si, para quien no lo recuerde y a lo mejor hoy en día le resulte extraño, Intel dominaba de forma aplastante el mundo de los microprocesadores para ordenador personal y marcaba completamente la pauta.

Todas las revistas de informática, abundantes en aquella época, y todos los aficionados, asistíamos con expectación a cada lanzamiento de un nuevo microprocesador de Intel. El siguiente de importancia fue el 80286. Luego vendría el 80386, hasta que Intel decidió cambiar un poco la marca y, al que debía llamarse, siguiendo la misma lógica, como 80596, decidió denominarlo 'Pentium'.

Más allá de la curiosidad y la nostalgia, lo relevante de cara a este post es hacer ver que cada nuevo microprocesador, que era más potente que el anterior, aparte de mejoras como acelerar la señal de reloj, se hacía más y más complejo, soportaba más y más instrucciones, se hacía físicamente más y más grande y, energéticamente, disipaba más y más calor.

Un poco como anticipo de lo que vendría después, y que en seguida comento, para algunos ordenadores un poquito más especializados y más potentes, se les dotaba del llamado coprocesador matemático, una especie de microprocesador pero ya no de propósito general sino especializado en operaciones matemáticas.

Arquitecturas CISC y RISC

No recuerdo bien los años, pero creo que, aunque tiene antecedentes más antiguos, hacia los años 90 se comenzó a hablar con más fuerza del concepto de RISC. ¿Qué era eso?

Bueno, los microprocesadores como los de Intel, evolucionaban soportando más y más instrucciones y constituían, pues, lo que se denominaba CISC ('Complex Instruction Set Computers').

Sin embargo, RISC ('Reduced Instruction Set Computers'), y a pesar de buscar precisamente una mayor eficiencia en la computación, apostaba en la dirección contraria: procesadores con un juego de instrucciones pequeño (reducido) y que, aparte de otras optimizaciones y mejoras ya buscaba el paralelismo en la computación. Y, realmente, hablar de RISC se convirtió en una especie de sinónimo de altas prestaciones.

Si la memoria no me falla, más que a los ordenadores personales, ésta filosofía se aplicaba a servidores o a las entonces llamadas 'workstations' (típicamente de Hewlett-Packard o Sun Microsystems) que, aunque tenían características parecidas a los ordenadores personales, eran más potentes, utilizaban sistemas operativos UNIX y se las consideraba más del ámbito profesional que personal.

Las GPU

Abandono un poco ya la memoria nostálgica para situarme en el presente. En este presente, y aunque ya están entre nosotros hace algunos años, son populares las famosas GPU ('Graphical Processing Units').

En cierto modo, las GPU son herederas de los coprocesadores matemáticos porque, en el fondo, eso es o que son. Salvo en casos muy particulares, las GPU no son una alternativa a las CPU ('Central Processsing Unit'), es decir, los microprocesadores tradicionales, sino unas compañeras de estos. La computación general suele correr a cargo de CPUs, pero ciertos tipos de cálculos, se delegan en GPUs.

¿Qué cálculos?

Pues las GPU están especializadas en operaciones algebraicas del mundo de los vectores, las matrices y los tensores. Se trata de un tipo de cálculos que son fundamentales en todo lo que tiene que ver con gráficos y movimiento y por eso las GPUs surgieron para apoyar el mundo de los videojuegos y aplicaciones similares, de ahí el nombre de 'gráfico' que puede sorprender hoy en día.

Y es que, no sólo el mundo de la imagen en movimiento se apoya en cálculos algebraicos, sino que también el 'machine learning' y muy particularmente el 'deep learning' se implementa, fundamentalmente con ese álgebra lineal en espacios vectoriales... y eso explica la popularidad y demanda actual de GPUs... y el éxito empresarial de NVIDIA.

Las GPUs apuestan muy decididamente por el paralelismo, condicionando, como vimos en un post anterior, la forma de programar con ellas en el bajo nivel. Pero hago notar que, en el fondo, en busca de la eficiencia computacional, sufren una enorme especialización: ya no son procesadores de propósito general como las CPU, sino procesadores muy especializados en computación algebraica paralela.

La transacción: especialización a cambio de potencia.

Las TPU

Y un caso más particular son las TPU ('Tensor Processing Units') o, al menos, los 'tensor cores' de NVIDIA, que se centran en una única operación: la multiplicación de matrices con acumulación consiguiendo una espectacular eficiencia en esa operación.

Estamos ante una 'super-especialización' pero que tiene sentido porque se trata de una operación usada masivamente en el deep learning actual, que ya sabemos que es enormemente demandante, especialmente en el caso de los grandes modelos generativos.

Estamos extremando en este caso la transacción de especialización a cambio de potencia, pero sigue teniendo una total lógica técnica e incluso económica.

La especialización y las cadenas de producción en computación

Y esto me lleva a la metáfora. No he podido dejar de pensar en los principios de la organización científica de Taylor, origen de las cadenas de producción industriales.

En esas cadenas de producción, los trabajadores (y también las máquinas) dejan de ser personas o máquinas de propósito general, como ocurriría en el caso de la artesanía o del trabajo intelectual, para especializarse en tareas muy concretas, tareas que realizan una y otra vez de forma muy eficaz y, sobre todo, muy eficiente.

Procesadores como las GPUs o las TPUs no dejan de ser, en la computación, algo así como los trabajadores especializados de una cadena de producción, en este caso una cadena de producción de la computación, mientas que las CPU se quedan un poco como los artesanos o intelectuales de esa computación.

Y, ante la demanda masiva de computación, procedente sobre todo de la inteligencia artificial, hemos debido poner en marcha una capacidad productiva en computación, altamente especializada y, por ello, altamente eficiente, pero apoyada en procesadores especializados.

Conclusiones

El conseguir unas mayores dosis de eficiencia en computación ha llevado, a lo largo de los años, a buscar esquemas de procesadores especializados en operaciones concretas y con altas dosis de paralelismo.

En ese sentido, y aunque sea metafóricamente, lo que buscamos son 'trabajadores especializados', y muy eficientes integrados en una suerte de cadena de producción de computación.

Artículos de este blog relacionados

Una aparente paradoja: el retorno de la programación de bajo nivel

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 23 Feb 2026 08:30:00 +0000

En los dos últimos post he hablado de dos fenómenos, en apariencia independientes y casi contradictorios y que, precisamente, van a colisionar en este artículo.

Hablo, por un lado, de la evolución del desarrollo software que explicaba en 'La evolución del desarrollo software: productividad frente a deskilling' y que nos muestra una clara evolución a una programación cada vez más alejada de los detalles técnicos y más centrada en la productividad y cercanía a las necesidades funcionales. Una programación, en fin, de alto nivel.

Por otro, en el último post, 'El retorno del hardware: razones y perspectivas', destacaba cómo el hardware, al que hacía años que apenas dábamos importancia, ha vuelto a cobrar valor técnico, económico y estratégico, debido en buena medida a las demandas técnicas y de volumen que impone la inteligencia artificial generativa.

En este post examino un fenómeno en cierto modo sorprendente y contradictorio: el retorno, no ya del hardware, sino de la programación de bajo nivel.

Programación de bajo nivel

Como paso previo, y por si algún lector no esta suficientemente advertido, aclarar a qué nos referimos con lo de la programación de bajo nivel.

La programación de bajo nivel es la creación de un software que trabaja en temas de detalle y, sobre todo, muy cerca del procesador, ya sea un microprocesador de tipo CPU ('Central Processing Unit') tradicional, o los modernos GPU ('Graphical Processing Unit') o TPU ('Tensor Processing Unit'). La programación de bajo nivel suele implicar conocer bien el hardware, tanto los procesadores como la estructura de registros y de la memoria o cómo relacionarse directamente con dispositivos y periféricos.

Con la programación de bajo nivel normalmente no podemos resolver grandes problemas funcionales, pero, a cambio, podemos conseguir nuevas capacidades y, sobre todo, si se hace bien, unas altísimas prestaciones y una gran optimización computacional. Y eso es así porque al trabajar muy cerca del hardware y conociendo cómo funciona, explotamos al máximo sus capacidades y, además, hacemos ´únicamente lo que se necesita'.

El software de alto nivel, por su lado, en su búsqueda de generalidad y facilidad de uso, añade ingentes cantidades de lógica adicional no estrictamente necesaria en muchos casos y, además, al alejarse del hardware no optimiza su uso. Prima la productividad y facilidad de uso frente a la optimización computacional.

¿Por que realizar programación de alto nivel?

En realidad lo acabamos de mencionar y lo vimos también en un post anterior: favorecemos la programación de alto nivel porque es muchísimo más productiva en términos de cantidad de software producido, porque además es más sencilla de llevar a cabo (lo que redunda en productividad y, además, elimina barreras de entrada de profesionales) y, finalmente, porque permite concentrarse más en los problemas de negocio o en lo que realmente queremos proporcionar.

Por eso, una vez que el hardware alcanzó una potencia tal que ya no nos exigía su optimización para tener buenos resultados de prestaciones, se ha ido favoreciendo la programación de alto nivel

¿Y por qué realizar programación de bajo nivel?

Y, entonces ¿Por qué podríamos interesados, a estas alturas, en hacer programación de bajo nivel?

Bueno, en algunos casos no hay más remedio. Por ejemplo, para relacionarse con un nuevo dispositivo o periférico, hay que comenzar trabajando en el bajo nivel, aunque luego, de cara a otros programadores se preparen ya APIs o conectores simplificados.

Un poco en esa misma línea, si estás programando un sistema operativo no tienes más remedio que enfrentarte al bajo nivel porque una de las funciones principales de un sistema operativo es precisamente relacionarse con el hardware y ofrecer, hacia el exterior, un modo abstracto, una máquina virtual que independice a aplicaciones y programadores de ese hardware. Los programadores de esas aplicaciones pueden trabajar en el alto nivel, pero los del sistema operativo están obligados a relacionarse con el bajo nivel.

Pero hay algo que me importa mucho más ahora mismo, en relación con lo que quiero exponer en este artículo: utilizas la programación de bajo nivel porque cuando quieres optimizar el funcionamiento, cuando quieres maximizar las prestaciones, cuando quieres 'exprimir al máximo' la capacidad del hardware, tienes que acercarte al hardware, tienes que conocerlo, tienes que, en fin, realizar programación de bajo nivel.

Nuevas arquitecturas de procesadores

Durante bastantes años, los procesadores, aunque evidentemente evolucionaban, y no poco, eran de tipo CPU.

Con el auge de aplicaciones de gran riqueza gráfica como los videojuegos, nacieron y cobraron importancia las GPU ('Graphical Processing Unit'). Pero la auténtica explosión ha venido de la mano del machine learning al 'descubrir' que las operaciones algebraicas que se utilizan en el mundo gráfico, son similares a las que se utilizan en machine learning, fundamentalmente en redes neuronales. En ambos mundos abundan las operaciones con vectores, matrices y tensores. Y las GPU lo que hacen es optimizar esas operaciones.

En un paso más allá en especialización, existen las TPU ('Tensor Processing Unit') o los 'tensor cores' de NVIDIA que, pese a que suenen a algo muy potente, en realidad se especializan en una única operación: la multiplicación de dos matrices y acumulación del resultado en una de ellas. En cierto modo, son elementos muy sencillos, pero altamente especializados y optimizados.

La nueva programación de bajo nivel

Aunque la programación de bajo nivel, pese a su escasa visibilidad, nunca se había ido, ahora cobra una gran importancia para explotar estos nuevos procesadores.

¿Por qué?

Pues porque estos procesadores son muy especializados pero, para que produzcan los resultados esperados, hay que programarlos conociendo cómo funcionan. Así, para explotar bien las GPU hay que convertir la resolución de nuestros problemas en operaciones de algebra lineal y, además ser capaces de definir la resolución de un problema en términos de unas funciones, los denominados 'kernel', en que la misma lógica pueda trabajar en paralelo sobre diferentes datos (por ejemplo, sobre diferentes partes de una misma matriz).

Más específico aún es el caso de los 'tensor cores' en que, para aprovecharlos, hay que ser capaces de identificar o forzar operaciones que consistan en una multiplicación de matrices seguidas por una acumulación.

Y esto no se puede hacer con sólo conocer un problema de negocio o la sintaxis de un lenguaje de programación. Para ello hay que comprender el hardware con que se trabaja y la mejor forma de obtener todo su rendimiento.

Es decir, hay que trabajar en el bajo nivel.

Deshaciendo la aparente contradicción

Y llega el momento de deshacer la aparente contradicción.

¿No habíamos dicho que la evolución del software nos conducía a una visión cada vez más alejada del hardware, una visión que en sus vertientes 'No Code' o 'Vibe coding' ni siquiera trabajaba con código fuente e incluso que en las soluciones de más alto nivel el desarrollador expresaba sus necesidades en lenguaje natural?

Si, lo habíamos dicho y así es.

Lo que ocurre que el trabajo en el bajo nivel lo realizan, comparativamente, muy pocas personas organizadas en equipos especializados. Esas pocas personas programan el software más exigente y, además, preparan componentes optimizados para su uso en el alto nivel por desarrolladores menos especializados.

Así, las típicas librerías python usadas en machine learning y deep learning, están fuertemente optimizadas a nivel interno, aunque el común de los programadores las utilicen directamente sin preocuparse de los detalles. Y no digamos ya nada cuando ni siquiera se trabaja con las librerías sino con componentes gráficos que las abstraen (caso del 'low-code / 'no-code') o cuando incluso es la inteligencia artificial la que general el código que invoca a las librerías, sin que el desarrollador sea necesariamente consciente de ello.

En el fondo, esa ha sido siempre la relación entre al bajo y el alto nivel: unos pocos equipos especializados trabajan en el bajo nivel, cerca del hardware, y preparan componentes optimizados reutilizables en el alto nivel.

Lo único que ocurre es que ahora, con la enorme demanda computacional existente y procedente de la inteligencia artificial, muy especialmente en su vertiente generativa., cobra nueva importancia el contar con algunos de esos equipos especializados para sacar jugo a un hardware especializado y que, pese a las enormes inversiones, se nos está quedando corto en volumen.

Conclusiones

La gran demanda computacional exigida por la inteligencia artificial generativa ha llevado al desarrollo de procesadores especializados a nivel hardware, pero el uso adecuado y óptimo de ese hardware implica el trabajo en el bajo nivel aunque luego los resultados puedan ser reutilizados vía librerías y APIs, en la programación de alto nivel.

El retorno del hardware: razones y perspectivas

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 16 Feb 2026 08:45:00 +0000

¿No resulta llamativo la frecuencia con que ahora oímos hablar de asuntos que tienen que ver con el hardware?

No paramos de escuchar hablar de GPUs, de NVIDIA, la empresa estrella del momento, del papel estratégico de la producción de semiconductores, de la lucha por las tierras raras y tantas cosas relacionadas con los aspectos físicos de la computación, con la microelectrónica y el hardware.

¿Qué está pasando?

El hardware como 'commodity'

Hasta no hace mucho, el hardware ha sido 'el hermano pobre' de la tecnología digital, algo de lo que se hablaba relativamente poco fuera de ámbitos especializados.

Pasada ya hace mucho la fiebre de los ordenadores personales en que sí que nos volvíamos locos los aficionados a la informática conociendo las nuevas características del último microprocesador Intel, y ahora que la gran proliferación de servicios en la nube nos hace muchas veces casi invisible el hardware corporativo, al menos los servidores, durante muchos años apenas nos hemos fijado en el hardware.

A nivel de programación, y como revisamos en el reciente post 'La evolución del desarrollo software: productividad frente a deskilling' también nos hemos ido alejando de la realidad física que soportaba la computación, de los procesadores, las CPUs, las GPUs, etc.

Sabíamos que era necesario, claro, y que evolucionaba y mejoraba, pero lo valorábamos poco, le prestábamos poca atención y, seguramente, el número de profesionales, ya no digamos aficionados, del software, supera con mucho, con muchísimo, al de los dedicados al hardware.

Además nos acostumbramos a que el hardware fuese relativamente barato, en el caso de ordenadores personales o portátiles, y casi invisible en el caso de los servidores, por mor de los servicios en la nube.

En cierto modo, habíamos convertido al hardware en una 'commodity', necesario, pero sin valor diferencial.

Y de repente ha vuelto

Y de repente, en los últimos meses, quizá algún año, vuelve a ser importante. Vuelve a estar en el discurso técnico y en el geoestratégico. ¿Por qué?

Voy a aventurar cuatro razones:

La escasez relativa de la capacidad de computación
La escasez relativa de materiales concretos
La especialización de la demanda
Un conocimiento escaso y concentrado

Veamos

La escasez relativa de capacidad de computación

La primera es que, lo que en su momento pudimos considerar abundante, la capacidad de computación, se nos ha vuelto escasa.

Hablo de escasez relativa porque no es que no exista capacidad de computación. Existe mucha capacidad de computación distribuida en unidades relativamente modestas como ordenadores de sobremesa, portátiles, tablets y smartphones. Existe muchísima capacidad de computación concentrada en centros de Proceso de Datos corporativos y existe, sobre todo, una ingente capacidad de computación en los data centers de los grandes proveedores de la nube (Amazon, Microsoft, Google, IBM, etc)

Lo que pasa es que la demanda crece aun más. En parte por la digitalización creciente pero muy singularmente por la explosión de la inteligencia artificial basada en modelos muy demandantes de computación tanto en entrenamiento como en inferencia, y por la previsión de que esa demanda no vaya a hacer otra cosa que crecer y trasladarse a otros ámbitos como robots, vehículos, etc, la oferta de hardware parece que se nos está quedando corta, o amenaza con quedarse corta.

Y ya se sabe que, desde un punto de vista económico y estratégico, un recurso gana importancia cuando es escaso.

La escasez de materiales concretos

Ante la enorme demanda de microelectrónica y hardware cuando algunos de sus componentes es en sí mismos escasos, como las famosas tierras raras, se perciben como aún más escasos y, por tanto, con mucho mayor valor económico y geoestratégico.

La especialización de la demanda de hardware

Quizá en menor medida, pero también influye creo, que ya no nos vale con un hardware más generalista, digamos una CPUs tradicionales agregadas mediante mecanismos de virtualización. Ahora los cálculos en el ámbito de la inteligencia artificial. de los videojuegos, de la realidad virtual o de la simulación, nos reclaman procesadores especializados, procesadores especializados en los cálculos algebraicos y su realización de operaciones en paralelo (caso de los GPU, 'Graphical Processing Units') y especializados en alguna operación muy específica realizada con muchísima frecuencia (caso, por ejemplo, de las TPUs, ('Tensor Processing Units')).

La necesidad de esa especialización, de esa búsqueda de procesadores más potentes y especializados, realza y revitaliza la industria del hardware pero, además, le añade más valor diferencial. Y si no, que se lo digan a NVIDIA.

La concentración y escasez de conocimientos

Además, y a nivel casi más geoestratégico que económico, la industria de los semiconductores está muy concentrada.

Está muy concentrada geográficamente, siendo tremendamente relevante el papel de Taiwan y está concentrada en empresas, siendo tremendamente especial el caso de la empresa holandesa ASML poseedora, hasta ahora en exclusiva, de la tecnología EUVL ('Extreme Ultra Violet Lithography').

Aunque esa concentración pudiera tener sentido económico como una forma de eficiencia considerando una cadena de suministro global, lo cierto es que es también un unto de fragilidad y, en el convulso mapa geoestratégico actual, un elemento de lucha competitiva, no ya de empresas, sino de grandes potencias.

A eso añadiría, aunque confieso que más como intuición que con base en datos, que creo que existen muy pocos profesionales en el mundo con conocimientos avanzados de microelectrónica y diseño hardware.

Perspectivas: los algoritmos frugales y la computación cuántica

¿Existe alguna vía para que se suavice esa demanda de hardware, incluso esa lucha competitiva por el mismo?

Sinceramente, a corto plazo no veo que la atención en el hardware y, sobre todo, la lucha competitiva y geoestratégica él mismo vaya a disminuir. No veo que la demanda vaya a bajar, sino todo lo contrario, y no veo mecanismos para aumentar de forma sencilla y eficiente la oferta.

Fantaseando un poco, no obstante, apuntaría a dos posibilidades, aunque la segunda no es de corto plazo.

La primera sería que la industria virase, pensando en este caso en la inteligencia artificial, del uso de los grandes modelos de lenguaje, a los denominados pequeños modelos de lenguaje y/o que se encontrase una algoritmia radicalmente diferente a la utilizada últimamente, muy apoyada en la arquitectura transformer, y que esa nueva algoritmia fuese muchísimo más frugal en necesidades de computación. No es que crea que esa es una posibilidad del todo realista en sí misma e, incluso, caso de conseguirse esa algoritmia, a lo mejor nos encontrábamos con más despliegues, más caso de uso con lo que, aunque cada modelo consumiese mucho menos, la demanda global podría seguir creciendo.

Otra posibilidad, pero no es de corto plazo, es la llegada real, con viabilidad comercial y a gran escala, de la computación cuántica. Dada su enormemente superior capacidad de computación para cierto tipo de aplicaciones (incluyendo el machine learning), eso podría llevar a una drástica disminución de demanda del hardware basado en semiconductores. Pero este escenario, caso de ser realista, no es inminente y, como mínimo, parece que habrá que esperar cinco años, si no diez, o quién sabe cuánto.

Conclusiones

El hardware parece que se ha vuelto a poner de moda. Y hay razones de aumento de demanda, de especialización y de escasez de recursos que justifican el aumento de su valor discursivo, económico y geoestratégico.

Y parece que, al menos durante unos pocos años, esa importancia se va a mantener.

La evolución del desarrollo software: productividad frente a deskilling

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 11 Feb 2026 10:55:00 +0000

El desarrollo de software ha sido siempre una actividad que me ha encantado y con la que, en su momento, he disfrutado muchísimo. Y digo en su momento porque tanto en los últimos años de mis estudios universitarios, como en los primeros de mi carrera profesional, dediqué muchísimas horas a esta actividad, como aficionado como ingeniero de software.

Y he podido asistir, dada mi edad, a casi toda su historia (me perdí un poco del principio) y a cómo ha ido evolucionando. Y lo cierto es que la transformación es enorme. Ha cambiado en filosofía, lenguajes, herramientas y requisitos profesionales del desarrollador.

En este post quisiera revisar esa evolución, y lo que los cambios suponen, de bueno y de malo

Un análisis en cinco fases

Y, para ello, propongo identificar las fases principales de la evolución.

Que yo sepa, no existe ninguna forma de marco concreta para clasificar esta evolución de la forma de construir software, (aunque sí se habla a veces de generaciones, sobre todo tercera y cuarta, pero con base en mi percepción personal, hablaría de cinco fases, a saber:

Fase 1: código máquina
Fase 2: ensamblador
Fase 3: lenguajes de alto nivel
Fase 4: 'low-code' / 'no-code'
Fase 5: 'vibe coding' o 'prompt based coding'

Veamos brevemente lo que significa y aporta cada una de ellas.

Fase 1: código máquina

En esta fase, que sinceramente creo que pocos desarrolladores han vivido salvo, como mucho, durante sus estudios, se trabaja directamente con el hardware, con el microprocesador y se expresa el programa en los famosos unos y ceros que caso nadie ha visto.

Es una programación muy, muy cercana al hardware, e implica conocer en detalle el microprocesador, sus registros, las instrucciones que maneja y cómo se codifican, las direcciones de la memoria etc. Los programas son, a poco que el programador sepa lo que hace, extraordinariamente eficientes en recursos computacionales y rápidos en ejecución, pero eso sí, son muy dificultosos de desarrollar y depurar y, por tanto, en general de un alcance muy modesto.

Fase 2: ensamblador

En realidad, es muy similar a la anterior, pero ahora hay un cierto lenguaje, el ensamblador, que al menos expresa las instrucciones mediante nemónicos textuales (típicamente de tres letras) con lo que, aunque con criterios de hoy en día siguen siendo enormemente crípticos, para su momento fueron una gran aportación en cuanto a claridad.

Fase 3: lenguajes de alto nivel

Son, quizá, el primer tipo de lenguajes ampliamente conocidos. En ellos el lenguaje de programación se basa en formas textuales más o menos destiladas del inglés, pero circunscritos a una serie de instrucciones muy concretas y con una estructura en general muy bien definida. Aunque hable de una forma de inglés no tiene nada que ver con el lenguaje natural: se trata de lenguajes muy acotados, muy estructurados y muy ligados a gramáticas estrictas.

Introducen ya los tipos de datos, las variables, las estructuras de control del tipo de bucles y condiciones o la capacidad de crear funciones. Con el tiempo, con el auge de la orientación a objetos, se introduce también esta idea de los objetos (que unen datos y comportamiento) y a capacidad de crearlos y utilizarlos.

Son lenguajes ya independientes del microprocesador e incluso del sistema operativo en que se ejecutan y un programa auxiliar, el compilador o el intérprete según el caso, se encarga de traducir esas instrucciones textuales de alto nivel al código máquina.

Se fueron acompañando de entornos de desarrollo del tipo IDE ('Integrated Development Environment') que incluyen capacidades de control y organización del código, capacidades de depuración, ayudas, etc.

En esta categoría caben casi todos los lenguajes de programación más conocidos, desde algunos más antiguos como COBOL o Pascal, y pasando por Basic, C, C++, Java o python, por decir algunos.

El salto de productividad es inmenso respecto a la programación en ensamblador, una productividad que se refuerza por la posibilidad de creación y reutilización de librerías de funciones u objetos que proporcionan, ya empaquetadas y listas para ser usadas, capacidades más o menos sofisticadas. Creo que es con base estos lenguajes que se produce el verdadero 'boom' del software.

Aunque en varios momentos me he referido a ellos en pasado, siguen estando muy presentes hoy en día, muy especialmente python.

Interludio: los lenguajes de cuarta generación 4GL

No los he llegado a proponer como una fase diferenciada, pero por encima de los lenguajes de alto nivel (que a estos efectos se consideran de tercera generación), proporcionan mayores niveles de abstracción y un enfoque algo más declarativo, normalmente orientados a software de características bastante comunes y estructuradas como la gestión de bases de datos.

Hay quien los considera como un antecedente de lo que veremos a continuación: el 'low-code'.

Fase 4: low-code / no-code

La fase 4 nos conduce a la filosofía y soluciones 'low-code' o, en su extremo, 'no-code'.

La idea es que el desarrollador ya no trabaje con código fuente (que se expresa en un lenguaje de tercera generación) o que lo haga en la menor medida posible. ¿Cómo se consigue eso? Pues proporcionando entornos de desarrollo gráficos o semi-gráficos, donde con frecuencia los bloques de ejecución se representan por cuadrados o círculos, que se unen mediante líneas o flechas para representar una lógica completa. Además, el entorno de desarrollo ofrece ya una amplia librería (normalmente ampliable) de bloques constructivos

En general el desarrollo tiende a convertirse en 'dibujar' la lógica de ejecución complementada por la configuración (habitualmente mediante cuadros de diálogo) de los parámetros y variantes de ejecución de cada uno de los bloques constructivos, así como la definición de variables.

En los casos más extremos ('no-code') no es necesario incluir código fuente tradicional y en otros casos ('low-code') sí existen determinados puntos donde se complementa la lógica, digamos gráfica, con pequeños elementos de lenguaje de programación de tercera generación.

Esta filosofía es cada vez más común para construir todo tipo de soluciones, pero, por citar algunas muy representativas, tendríamos, en el ámbito de la automatización, casi todos los entornos RPA ('Robotic Process Automation') o BPMS ('Business Process Management Systems'), así como soluciones de automatización de workflow (como Make o N8N) e, incluso, algún entorno de construcción de agentes IA como LangFlow. También es común, por ejemplo, en visualizadores de datos como Power BI.

En este salto, no es ya que nos hayamos alejado del hardware y el microprocesador, es que incluso nos hemos alejado de los lenguajes de programación como tales, si entendemos los lenguajes de programación como algo con base textual. Incluso, gran parte de la lógica detallada, viene resuelta por los bloques constructivos disponibles sinq ue el desarrollador la conozca en detalle, sino sólo por su comportamiento externo.

Fase 5: Vive coding o 'prompt based coding'

El último salto, es la creación de software a partir de prompts usando herramientas de inteligencia artificial generativa. En el primer post de este blog que dediqué al 'vibe coding', comentaba la diferenciación entre el uso de inteligencia artificial como una especie de ayuda o copiloto, lo que Addy Osmani denominaba 'Ingeniería de software asistida por IA' frente al uso de la IA para construir toda la aplicación, siendo esto último a lo que asignaba el término 'Vibe coding'.

En realidad, si usamos la IA como copiloto, estamos realmente reforzando una de las dos fases anteriores (lenguaje de alto nivel o 'low-code'/'no-code') pero no sería una fase realmente diferenciada.

Lo que considero como una fase diferenciada es cuando usamos la herramienta para la generación completa de aplicaciones o módulos a partir de prompts en lenguaje natural. Como en este caso la forma de actuar que tiene el desarrollador es únicamente mediante 'prompts', me he querido inventar el término 'prompt based coding'.

En este caso el alejamiento ya es total: el desarrollador no es que no conozca el hardware o el sistema operativo, y no es ya que no utilice un lenguaje de programación, es que, incluso, salvo que se preocupe por ello, hasta desconoce la lógica interna del software que ha generado o cómo está estructurado. El desarrollador, en teoría, se centra sólo en la necesidad, que expresa mediante lenguaje natural, no en los detalles internos del software.

Se trata de una fase probablemente poco madura en estos momentos y que hay que ver hasta dónde es capaz de llegar, pero, en teoría, es una fase de altísima productividad y, además, casi al alcance de cualquiera, una fase donde el propio término 'desarrollador', al menos tal y como lo hemos entendido hasta ahora, puede que pierda sentido.

Consecuencias

A medida que se avanza en las diferentes fases, creo que se producen los siguientes efectos:

Se aumenta (y mucho) la productividad del desarrollo software
Se baja la barrera de entrada (los conocimientos y la especialización necesarios) para crear software
El desarrollador pierde conocimiento del detalle de lo que está haciendo (el hardware, el sistema operativo, las lógicas internas, etc)
Debido a esa pérdida de conocimiento (y gestión) del detalle, en general el software generado es menos eficiente en el uso de recursos computacionales: memoria, tiempo de CPU, disco, etc

En general, la evolución de la industria ha apostado por los dos primeros beneficios (productividad y bajada de la barrera de entrada) frente a los dos últimos inconvenientes (perdida de conocimiento y menor eficiencia en recursos computacionales).

Voy pararme un momento en dos aspectos.

La productividad y las barreras de entrada

En efecto, el gran beneficio de esta evolución es, sobre todo, la altísima mejora de productividad en la construcción de software, no sólo en cuanto a cantidad de código creado sino en cuanto a potencia y capacidades de las soluciones generadas. Por ejemplo, hace 20 o 30 años, hacer la interfaz de usuario (las ventanas, por entendernos) de un sistema, era tremendamente trabajoso... y hoy es casi trivial en algunos casos.

A esto se une, especialmente en las dos últimas fases, en unos menores requisitos, una menor cualificación, para ser creador de software, llegándose ya hace unos años al concepto acuñado por Microsoft de 'Citizen developer' (un concepto muy ligado al 'low-code') en que ya parte del software empresarial podría ser creado, no por desarrolladores profesionales del departamento de IT, sino por profesionales del ámbito del negocio (ventas, marketing, operaciones, etc)

El deskilling

Sin embargo, ese menor conocimiento requerido supone en parte un peligro para el propio software en el sentido de que el desarrollador puede ser mucho menos capaz de hacer un software eficiente, escalable e incluso seguro, o que le puede costar depurar los errores más extraños.

De cara al desarrollador, como profesión, el avance en estas fases, muy especialmente la última, pone en riesgo la profesión en sí misma, en riesgo de desaparición o, quizá más probable, de profunda redefinición y, quizá, sólo quizá, menor cualificación y por tanto consideración profesional.

En el fondo, se produce una forma particular de 'deskilling' (término del que he hablado en los dos últimos posts), en que el desarrollador cada vez sabe menos de sistemas, cada vez sabe menos, por supuesto del hardware, pero también sabe menos de las mejores arquitecturas, de los mejores criterios y mejores prácticas de construcción de software. Y eso es un riesgo potencial para la propia calidad del software y para su mantenibilidad y, quizá, un empobrecimiento personal y profesional del desarrollador.

Conclusiones

El desarrollo de software ha sufrido a lo largo de las últimas décadas, una enorme transformación en su forma de realización, una evolución que le ha conducido, a través de cinco fases, a recorrer un camino en el que ha ganado una enorme productividad y sencillez, pero a cambio de una menor eficiencia en recursos computacionales y en una progresiva descualificación técnica de los profesionales que la ejercen.

La peligrosa combinación del 'automation blindness' y el 'deskilling' y cómo afrontarla

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 09 Feb 2026 10:00:00 +0000

Una de las preocupaciones que surgen con la inteligencia artificial es, más allá de otras problemáticas éticas como la privacidad, los sesgos o la explicabilidad, cómo va a afectarnos a nosotros, humanos, en nuestro propio desarrollo, en nuestras propias capacidades cognitivas, a medida que nos entreguemos a ella, que la utilicemos intensivamente tanto en el ámbito laboral como doméstico.

Y creo que, en efecto, existe a la vez un interrogante, porque realmente no estanos seguros, y un riesgo, porque creo que realmente podemos perder cosas valiosas por el camino.

En este post quisiera mostrar cómo dos aspectos que ya he tratado en otros posts, se podrían combinar de una forma perjudicial y potencialmente peligrosa. Hablo de los así llamados 'automation blindness' y el 'deskilling'.

Veamos.

Recordando el 'automation blindness'

De 'automation blidness' hablé en el post anterior a éste titulado 'Automation blindness o el riesgo para human-in-the-loop'. Este fenómeno, en esencia consiste en que los humanos, cuando están apoyados en sus decisiones por sistemas automatizados, poco a poco se 'van confiando' y pasando de realizar una supervisión efectiva y responsable de las decisiones automatizadas, a confiar ciegamente en ellas eliminando, 'de facto', la supervisión e incluso su autonomía.

Se trata de un fenómeno no específico de la inteligencia artificial pero que se acentúa en sistemas inteligentes, tanto por su potencia, como por actuar en situaciones tradicionalmente reservadas al juicio humano.

Recordando la idea de 'deskilling'

Del 'deskilling' hablé brevemente hace un par de meses en el artículo 'Inteligencia artificial, capacidades y las tres olas hacia el desempleo'. En este caso, de lo que hablamos es que, dado el efecto sustitutivo que la tecnología tiene respecto a tareas humanas, a medida que vamos delegando en la tecnología esas tareas, perdemos la capacidad para llevarlas a cabo nosotros mismos, es decir, perdemos capacidades y habilidades.

Se trata de un fenómeno que tampoco es exclusivo, ni mucho menos, de la inteligencia artificial. Lo que ocurre es que, en el pasado, las habilidades que delegábamos y perdíamos eran de naturaleza más bien manual, pero con la digitalización, y sobre todo con el advenimiento de la inteligencia artificial, estamos, cada vez más, delegando capacidades cognitivas y, eventualmente, perdiendo esas capacidades o al menos en riesgo de perderlas.

Una combinación doblemente peligrosa

Si veo ambos fenómenos, creo que cuando se combinan, y me parece muy fácil que se combinen, nos hallamos ante una situación peligrosa en un doble sentido, un sentido más operativo y práctico, y otro más cognitivo y profundo.

Un peligro operativo

En primer lugar, y desde un punto de vista que voy a denominar operativo, es peligrosa porque se pierde la supervisión real de los sistemas automatizados. Ya no es sólo que tendamos a confiarnos ('automation blindness'), es que podríamos incluso perder la capacidad real para entender y controlar un sistema automatizado ('deskilling'). Dado que, por desgracia, los sistemas automatizados pueden fallar, y más si se pretenden apoyar en inteligencia artificial generativa que, como ya analicé en otros posts, no conduce a comportamientos completamente predecibles ni sujetos a reglas, perder la capacidad de supervisión y control puede llevar a puntualmente a comportamientos del sistema incorrectos y eventualmente catastróficos.

Es cierto que los sistemas automatizados, sobre todos los de misión crítica, tienden a ser muy fiables, incluso con frecuencia mucho más que un humano, pero aún así, perder la capacidad última de decisión y control, me parece operativamente arriesgado.

Un riesgo cognitivo y ético

Pero quizá me preocupa más la segunda vertiente, la que voy a denominar cognitiva. En este caso, tiene mucho que ver con el 'deskilling', es decir, con la pérdida de capacidades cognitivas. Esa pérdida de capacidades cognitivas, por sí misma, me parece un empobrecimiento de la persona pero, además, en a medida que se confía más y más en sistemas automatizados, puede devenir en una menor autonomía, una mayor dependencia.

Es cierto que en el pasado, nos hemos deshecho de capacidades que hemos delegado en máquinas y tecnología, y no parece que nos haya ido mal ni que estemos descontentos. Incluso es posible, sólo posible, que a cambio de ceder algunas capacidades, resultemos potenciados en otras, que desarrollásemos nuevas habilidades.

Pero, claro, hablamos de capacidades cognitivas, muy esenciales de lo que significa ser humano. Y no sé si estamos dispuestos a asumir (yo, personalmente, no), esa suerte de degradación cognitiva o el riesgo de un incierto cambio de capacidades cognitivas.

Sin recetas, pero con un planteamiento a corto plazo

La verdad es que creo que nadie puede tener claro lo que va a ocurrir en el futuro, y cómo vamos a evolucionar. Es posible que, al final, los riesgos y peligros no sean tan grandes o, al menos, que sepamos encauzarlos y el resultado final sea bueno. Y como estamos ante un panorama incierto, es difícil saber cuál es el camino adecuado.

Sin embargo, pase lo que pase en el futuro, creo que los riesgos que he mencionado son reales y afectan a temas muy importantes, de seguridad y casi a nuestra propia naturaleza. Así que, si existen riesgos reales, pero tenemos poco clara la visión futura, creo que conviene actuar, al menos a corto plazo. Desde luego, creo que podemos, casi diría que debemos, utilizar, y utilizar mucho, una tecnología tan potente y versátil como es la inteligencia artificial. Pero debemos hacerlo de una forma consciente y responsable, responsable con los demás y con nosotros mismos.

Y así, creo que cada uno de nosotros deberíamos exigirnos y esforzarnos en la supervisión de aquello que delegamos en la inteligencia artificial, desde grandes automatizaciones corporativas, hasta simples consultas a ChatGPT. Aunque nos cueste, aunque nuestra naturaleza nos impulse a ser cómodos y confiarnos, debemos esforzarnos conscientemente en ejercer el juicio crítico, el control y la autonomía.

Y, además, deberíamos cuidar nuestras capacidades cognitivas, intentando no sólo no perderlas sino incluso aumentarlas. Y para ello, dado que no vamos a dejar de utilizar la inteligencia artificial, quizá debamos reforzar nuestras capacidades, y hacerlo conscientemente, mediante actividades en paralelo que cuiden y desarrollen esas capacidades: lectura, estudio, actividades artísticas, interacción humana, etc

Es cierto que pongo mucho énfasis en la responsabilidad individual, en el auto-cuidado cognitivo, es cierto que, además, lo que propongo exige acción consciente y puede que esforzada, y es cierto, finalmente, que puede que las cosas cambien, y que en unos años o que las valoremos de una forma diferente, pero ahora mismo, a corto plazo, creo que es lo mejor que podemos hacer... y hacerlo cada uno de nosotros.

Conclusiones

El uso intensivo de las tecnologías, muy en especial la inteligencia artificial, puede conducir, por un lado, a una confianza excesiva en de las decisiones automatizadas y, por otro, a una progresiva degradación de nuestras capacidades cognitivas.

La combinación de ambos fenómenos, creo que es peligrosa tanto desde un punto de vista operativo como humano, cognitivo y casi ético.

Existe mucha incertidumbre sobre el nivel de riesgo real o cómo afrontarlo pero, a corto plazo, lo que creo que debemos hacer es reforzar, conscientemente, nuestra supervisión de los sistemas y, sobre todo, nuestro propio desarrollo cognitivo.

Automation blindness o el riesgo para human-in-the-loop

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 02 Feb 2026 09:00:00 +0000

Una de las cosas que a veces asusta de la inteligencia artificial y a la que, de alguna manera, se intenta poner coto o controlar, es a la posibilidad de que los algoritmos tomen decisiones de forma automática, sin control humano.

Y por ello, entre otros mecanismos, se propone y se utiliza el denominado 'human-in-the-loop'. Sin embargo, esto también puede tener un riesgo.

Vayamos paso a paso.

Decisiones automatizadas

Nos asusta que una máquina pueda decidir de manera autónoma qué hacer. Y, en cierto sentido, podría parecer paradójico que a estas alturas nos preocupe esa automatización, cuando en muchos ámbitos de nuestra vida ya existe una profunda automatización .

La decisión automatizada existe, por supuesto, en plantas industriales, pero existe también en muchos sistemas de información de los que comúnmente se utilizan en empresas y administraciones.

Hasta máquinas de uso común, como los coches, tienen muchos elementos automatizados.

¿Por qué nos asuste entonces que decidan algoritmos de inteligencia artificial?

Aventuro que por tres motivos.

Por un lado, por la naturaleza de las decisiones. Ya que la inteligencia artificial automatiza tareas cognitivas, los algoritmos pueden automatizar decisiones tradicionalmente reservadas a humanos (por ejemplo, un diagnóstico médico o la decisión de concesión de un préstamo) y, justificadamente o no, nos resistimos a ceder ese poder.

En segundo lugar, porque con frecuencia no entendemos del todo cómo se toman esas decisiones. La mayor parte de los algoritmos de inteligencia artificial no toma las decisiones conforme a unas reglas claras, sino con base en unos patrones no del todo evidentes... o no evidentes en absoluto.

Quizá añadiría en tercer lugar el hecho de a veces, por suerte con poca o muy poca frecuencia, como no siguen los mismos razonamiento humanos, a veces fallan de forma inesperada y casi absurda, lo que, en alguna situación podría ser, aparte de imprevisible, directamente catastrófico.

Explicabilidad

Como una forma de eliminar, al menos parcialmente el segundo de los factores, el no saber cómo se toman las decisiones, existe desde hace años el concepto de explicabilidad de la inteligencia artificial (XAI, eXplainable AI) que busca, precisamente, que los algoritmos sí puedan explicar, de forma comprensible por los humanos, cómo toman las decisiones.

Se trata de un tema técnicamente complejo porque los algoritmos más potentes, los que proceden del campo de las redes neuronales y el deep learning, son esencialmente no explicables,

Pero, por sí sola, la explicabilidad, que además no se encuentra plenamente conseguida, no nos elimina el miedo a dejar en manos de un algoritmo una decisión automatizada. Si no hacemos nada más, la explicabilidad nos dice cómo ha decidido el algoritmo, pero lo hace 'a posteriori', una vez que la decisión ha sido tomada y, eventualmente, ejecutadas las acciones que siguen a esa decisión.

Human-in-the-loop

El mecanismo adicional es el denominado 'human-in-the-loop' que, estrictamente hablando, elimina la automatización.

Se trata, simplemente, de que en último término quien decide es un humano. El algoritmo evalúa la situación y propone una decisión...pero no la aplica automáticamente, sino que la somete a la supervisión de un humano que es quien decide si ejecuta realmente esa decisión o no.

En el fondo, como decía, la decisión ya no es automática aunque sí puede aprovechar la rápida y potente capacidad de análisis del algoritmo.

El riesgo de confiarse y dejarse ir

El riesgo al que se refiere el título de este artículo, un riesgo si se quiere un poco tonto, pero muy real, e incluso grave, es que el comportamiento humano habitual es que cuando el trabajar con el algoritmos se convierte en algo habitual, rutinario, y cuando, además, el algoritmo demuestra que en la práctica suele proponer cosas acertadas, el humano se confía, deja de analizar con tanto rigor lo que se le propone, deja de aplicar juicio crítico y comienza a aceptar sin más lo que el algoritmo propone.

A efectos teóricos hemos eliminado la automatización (y también algunos de sus beneficios de eficiencia y rapidez) pero, a efectos de control nos hallamos en la misma situación que si el algoritmo estuviese completamente automatizado, con la única diferencia, quizá, de que ahora tengamos un claro responsable ético y legal: el humano que, en teoría, es quien toma la decisión.

Pero el riesgo original de la decisión automatizada no lo eliminamos.

Automation blindness

Es efecto, el confiarse, es un iregso que ya había identificado, apreciado y comentado en diversos medios, pero lo que he descubierto recientemente es que tiene nombre, y ese nombre es 'automation blindness'.

Y lo descubro en el capítulo final, sobre responsabilidad, del libro 'Visualizing Generative AI' de Priyanka Vergadia y Valliappa Lakshmanan. En concreto, los autores lo explican, en el caso de la inteligencia artificia generativa, diciendo

As GenAI becomes better and its errors rarer, human users may fail to even perceive the few errors that remain or are introduced. They become less and less aware of the details and nuances involved.

Y nos cuentan que, en realidad, este término no procede del campo de la inteligencia artificial, sino de la aviación, donde se observó esa confianza en el mecanismo automatizado en el caso de pilotos de avión asistidos por pilotos automáticos.

The term automation blindness comes from aviation, where it describes how pilots become over-reliant on their automated systems, lose their situational awareness, and fail to recognize potential hazards or anomalies.

Un fenómeno confirmado, además, por estudios realizados por la NASA.

Improvisando algunas opciones de mitigación

¿Qué opciones nos quedan antes este fenómeno?

Pues, sinceramente, no creo que haya ninguna solución absoluta ni mágica pero, se me ocurre, un poco a bote pronto:

Por supuesto, poner aún más énfasis en que los algoritmos tomen la decisión adecuada desde el principio, por si acaso el humano no está muy atento

Incrementar, hasta donde se pueda, la calidad y simplicidad de las eventuales explicaciones que ofrezca el algoritmo, para simplificar que el humano entienda rápidamente la decisión y sus motivaciones.

Incluir, de serie, avisos por parte del algoritmo o de la aplicación de los eventuales riesgos e implicaciones de la decisión, visualizar esos avisos de manera muy clara y, si se detecta algún riesgo importante, usar los recurso gráficos y sonoros pertinentes para alertar al decisor humano.

Incluir mecanismos en las aplicaciones que fuercen al decisor humano a confirmar que toma la decisión conscientemente (por ejemplo, resumiendo muy brevemente en un texto, por qué lo decide). Esto sería ineficiente y algo 'pesado' y, además, no creo que elimine del todo la posibilidad de que el humano actúe sin pensar, pero supongo que sí lo disminuiría.

Finalmente, y aunque sea triste decirlo, incrementar los 'castigos' en caso de decisión equivocada y no eficazmente supervisada para que, aunque sólo sea por miedo, el humano preste más artención.

Ninguna de las opciones, por supuesto no excluyentes sino todo lo contrario, me parece completamente efectiva y alguna, como las dos últimas, la verdad es que no me gustan demasiado.

Lo cierto es que no veo una forma de eliminar completamente este 'automation blindness' que, en el fondo, es muy humano.

Supongo que sólo queda ser conscientes del mismo e intentar disminuirlo en la medida de lo posible.

Conclusiones

De cara a prevenir que los algoritmos de inteligencia artificial adopten de manera automatizada decisiones que puedan ser equivocadas, dañinas o poco éticas, una de las estrategias es la de su supervisión, y decisión final, por parte de un humano, lo que se conoce como 'human-in-the-loop'.

Sin embargo, esta estrategia se tropieza con algo tan simple como que a los humanos les cuesta mantener la atención y se confían cuando ven que, en general, las decisiones del algoritmo son acertadas, un fenómeno denominado 'automation blindness' y para el cual, por desgracia, no identifico ninguna estrategia definitiva, sólo mecanismos de mitigación.

El eventual libre albedrío de los modelos generativos y el resquicio de la aleatoriedad algorítmica

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 28 Jan 2026 09:55:00 +0000

Publico un nuevo artículo, en este caso casi más una 'reflexión en voz alta' que una argumentación profunda, sobre esa especie de serie de posts que estoy dedicando al determinismo (o aleatoriedad) de los algoritmos de la inteligencia artificial, muy especialmente los modelos generativos, y a la posibilidad (o no) de que un algoritmo o un modelo y, por tanto, una máquina, pudiese tener libre albedrío.

Aunque, en principio pensaba que este artículo iba a ser el último de esta serie, creo que no va a ser así, por algo que explicaré mas abajo, hacia el final del post.

En esta ocasión, quiero hacer una reflexión sobre si una eventual aleatoriedad de los algoritmos, abre o no la puerta para el libre albedrío.

Recapitulando: algoritmos deterministas... o casi

Intento resumir lo visto hasta ahora en artículos anteriores.

En general, he defendido que los algoritmos de inteligencia artificial en general, y los modelos generativos en particular, son, en el fondo, deterministas.

Sin embargo, he hecho una distinción que creo muy importante y he hablado de una especie de comportamiento dual.

Vistos desde fuera, vistos como usuarios, como ingenieros, como desarrolladores, como empresas, los modelos generativos se comportan como probabilistas, es decir, proporcionando resultados diferentes ante las, aparentemente, mismas entradas. Es decir, se comportan como si no fueran deterministas.

Sin embargo, si entramos al detalle, a un nivel muy fino y casi 'íntimo' del algoritmo, el funcionamiento realmente es determinista. ¿Por qué? Pues porque la aparente aleatoriedad se basa también el algoritmos que, aunque simulan muy bien la aleatoriedad, en realidad siguen un funcionamiento determinista. Para lograrlo usan funciones (como los generadores de números seudo-aleatorios) que suelen incluir alguna entrada, que el usuario 'no ve', que puede ser, por ejemplo, una semilla consistente en la fecha y hora exacta en que se invoca el algoritmo (hasta milisegundos, microsegundos o aún más precisión). Si, como usuarios, invocamos dos veces seguidas el algoritmo aportando los mismos datos, el resultado será diferente (porque la hora exacta de invocación es diferente), pero, en el fondo, si tuviéramos realmente todos los datos de entrada, incluyendo la hora exactísima de invocación, el resultado estaría completamente determinado.

Por ello, mi tesis básica es que los algoritmos, aunque por fuera se comporten claramente como probabilistas, por dentro son deterministas.

De hecho, y como vimos en otro post, existen mecanismos de gobierno del nivel de aleatoriedad de los algoritmos generativos, que permitirían, incluso, 'congelar' estos modelos y que se comportasen, también externamente, como deterministas, algo que, más allá de razonamientos teóricos, es bueno para poder probar y validar los modelos.

En el post anterior de esta serie, sin embargo, y con base en los estudios de Thinking Machines introdujimos algunas posibles 'grietas' en este razonamiento. Veíamos que esta compañía ha encontrado y demostrado la existencia de aleatoriedades basadas en cosas como problemas de redondeo en operaciones con números en coma flotante, diferencias en el comportamiento de los núcleos de las GPUs y, sobre todo, en la generación de los 'batches' que entran en los modelos generativos.

Aunque es más difícil de demostrar, creo que esas situaciones lo que reflejan son unas 'apariencias de aleatoriedad', desde luego ciertas vistas con visión externa y, además, en este caso no buscadas y no gobernadas explícitamente sino un poco 'fuera de control', por decirlo de alguna manera. Sin embargo, creo que un análisis muy detallado nos mostraría que, aunque, en efecto, no gobernadas, y aunque, también en efecto, con manifestación externa aleatoria, en su funcionamiento más íntimo siguen siendo deterministas.

Los autores del estudio, además, han encontrado la forma de eliminar esas 'grietas', devolviendo los algoritmos al redil del determinismo.

Pero, y si al final hay elementos de autentica aleatoriedad, ¿Qué sucede?

Veamos

Importancia de la aleatoriedad de los algoritmos para el libre albedrío

¿Por qué tanto empeño en ver la aleatoriedad o no de los modelos generativos? ¿Por qué darle tantas vueltas cuando, además, se reconoce que, en su comportamiento externo, sí que son probabilistas?

Pues, como decía al hablar de esa especie de dualidad entre la visión externa e interna, porque el determinismo o la aleatoriedad tienen una importancia casi filosófica o ética si queremos hablar de libre albedrío.

Si demostramos que un algoritmo es plenamente determinista, no queda lugar para el libre albedrío de las máquinas, para que éstas tengan alguna forma de voluntad propia, o al menos una voluntad consciente y autónoma, como la que entendemos tenemos los humanos. Al menos a mí no se me ocurre cómo un ente, natural o artificial, puede tener libre albedrío si su comportamiento es plenamente determinista.

Sin embargo, si el comportamiento no es plenamente determinista, no se demuestra, ni mucho menos, que exista libre albedrío, pero se abre un poco la puerta.

Entonces, si los algoritmos fuesen realmente probabilistas, con dosis de aleatoriedad ¿supone que pueden tener libre albedrío?

No, no necesariamente, pero al menos deja algún pequeño resquicio, alguna posibilidad, y la necesidad de seguirlo analizando.

Aleatoriedad frente a deliberación

De hecho, probablemente, la aleatoriedad o, más bien, el no determinismo, sea una condición, puede que necesaria, pero desde luego no suficiente, ni de lejos, para hablar de libre albedrío.

Probablemente, como tantas otras capacidades humanas, no tengamos una idea clara, científicamente clara quiero decir, de lo que es el libre albedrío y, sobre todo, cómo 'se implementa' en el ser humano, algo sobre lo que quiero seguir investigando. En cualquier caso, sí parece claro que, para hablar de libre albedríos, necesitamos bastantes más ingredientes que la mera indeterminación.

Casualmente, o no tan casualmente, me encuentro precisamente leyendo el documento 'Reclaiming human agency in the age of artificial intelligence' publicado por el Dicasterio para la cultura y la educación de la Santa Sede, en que razona sobre el concepto de agencia humana, frente a la agencia de que se habla en inteligencia artificial. Y hay un párrafo que creo esclarecedor. Dice:

Such deliberation is presupposed in free choice; it is what “specifies”our free choice. Free acts are not random; they are not the mere indeterminacy of chance events or the result of random generators, as in some machine simulations of agency

Nos habla de deliberación y explícitamente indica que la libertad de elección no es mera aleatoriedad. Sin entrar en análisis más académicos o sesudos, esa deliberación de que nos habla creo que incluye un análisis consciente del contexto y las opciones, y una toma de decisión también consciente.

Aunque este documento está generado por la Iglesia Católica, creo que la argumentación es general y perfectamente asumible por cualquier pensador y por cualquier persona.

Demos por válido, pues, que el libre albedrío incluye esa capacidad de deliberación. Sin entrar en el complejo tema de la 'consciencia' sí que parece claro que la mera aleatoriedad no incluye por sí misma ninguna forma de deliberación.

¿Excluimos, pues, ya del todo, la posibilidad del libre albedrío en máquinas?

Deliberación y modelos razonadores

Pues quizá todavía sea un poco precipitado y convenga analizar algo más.

Los modelos generativos más modernos, son del tipo denominado 'razonador': modelos que analizan el objetivo que se les pone, elaboran un plan de acción para conseguir ese objetivo, ejecutan las acciones del plan, evalúan los resultados que van obteniendo y, según sean éstos, cambian el plan o deciden 'cómo' seguir.

¿Es eso deliberación? ¿Abre eso otra puerta a un libre albedrío de las máquinas?

Bueno, este era el punto que no tenía en mi agenda de posts hasta el momento, pero que creo muy interesante y al que, casi seguro, le dedique otro artículo. Eso sí, ese artículo a lo mejor se demora algo, porque para aportar una argumentación seria, querría conocer el detalle de cómo funcionan estos modelos razonadores. Aunque he leído muchas descripciones, son someras y si profundidad técnica. Y, sinceramente, no sé si está publicada la arquitectura y algoritmia de este tipo de modelos (a lo mejor los fabricantes lo consideran confidencial y estratégico), pero, en cualquier caso, yo no he tenido la ocasión de estudiarla.

En cualquier caso confío, antes o después, en poder realizar algún análisis en esa línea.

La serie de posts dedicados al determinismo o no, y al libre albedrío o no, de los modelos generativos, queda, pues, aún abierta a la espera, como poco, de ese posts sobre deliberación y modelos razonadores..

Conclusiones

Aunque con una manifestación práctica externa los modelos generativos se comportan claramente como probabilistas, por dentro, su funcionamiento detallado es esencialmente determinista. Existen, eso sí, algunas pequeñas grietas por donde, quizá, se podría 'colar' alguna aleatoriedad.

Si hubiese aleatoriedad, ¿eso implicaría libre albedríos? Ni de lejos, lo que pasa es que si el algoritmo es determinista entonces sí que queda excluido el libre albedrío. Si existe aleatoriedad, existe alguna posibilidad, aunque sea remota.

Y, para que exista el libre albedrío, parece necesaria la capacidad de deliberación y decisión consciente, autónoma y libre. La aleatoriedad no garantiza, ni mucho menos, esa capacidad de deliberación pero ¿Qué pasa con los modelos razonadores? ¿Deliberan? ¿Ejercen o pueden ejercer alguna forma de libre albedrío?

Espero encontrar la información necesaria para argumentarlo en algún futuro post.

Artículos de este blog relacionados

Inteligencia artificial: la burbuja y la implantación

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 26 Jan 2026 12:55:00 +0000

Confieso que, para estas reflexiones sobre la eventual burbuja de la inteligencia artificial, pensé en utilizar el título "¡Es la implantación estúpido!", una frase inicialmente articulada como "¡Es la economía, estúpido!" ('is the economy, stupid!') acuñada por el equipo de campaña de Bill Clinton allá por 1992, y que se ha utilizado con mucha frecuencia, realizando variaciones en que, en lugar de 'economía', se utiliza cualquier otro término que se quiera destacar.

Al final lo he desechado, primero, porque no me gusta el tono insultante que respira, segundo, porque tiendo a rechazar, cada vez más, las frases hechas y, finalmente, y en el fondo más importante, porque no refleja del todo lo que este post quiere transmitir, aunque si en parte: la importancia de la adopción de la inteligencia artificial, de la implantación real de soluciones, por parte fundamentalmente de empresas como factor fundamental para hablar o no de burbuja de la inteligencia artificial.

Pero, 'vayamos al lío'.

El significado de la burbuja

En esencia, hablar de 'burbuja' implica hablar de unas expectativas infladas, excesivas, bajo un punto de vista esencialmente económico aunque quizá con algún reflejo técnico.

El reflejo técnico, que creo no es el más relevante en este caso, implicaría que la inteligencia artificial no es (y no va a ser en breve) capaz de hacer todas las cosas que se le atribuyen. Y ese exceso de expectativas técnicas, podría desenfocar las expectativas económicas y de negocio, que son las que realmente importan cuando hablamos de burbuja.

Y en esa visión económica, una 'burbuja' nos habla de que las inversiones que se están realizando en inteligencia artificial no están respaldadas por el retorno que de ellas se puede esperar de forma realista en un plazo razonable. Y eso incluye, por ejemplo, empresas como la propia OpenAI que, de momento, lo que dan son unas pérdidas millonarias.

Si eso fuese cierto, si existiese realmente una burbuja, cuando empresas y gobiernos adquieran conciencia de que esas inversiones son irracionales y no recuperables, se puede parar la inversión, provocando con ello desaparición de empresas, deudas sin pagar, paro, etc, Y si esas consecuencias son de gran volumen, pueden conducir a una crisis económica global, en el sentido de no afectar sólo a alguna empresa, sino a estados completos e incluso a nivel mundial.

Dos declaraciones preliminares

Antes de seguir con lo que es el núcleo de este artículo, quisiera hacer dos declaraciones.

La primera es un humilde reconocimiento que no tengo información suficiente, ni una opinión formada, sobre si, desde el punto de vista económico, realmente estamos en riesgo de una burbuja en el caso de la inteligencia artificial. Sí creo que estamos en un mercado en ebullición y casi diría que en formación, que estamos en una frenética cascada de acontecimientos y que eso lleva a incertidumbre en las decisiones, unas decisiones que, ante la falta de un panorama claro, pero con la expectativa de un negocio billonario en el que no se puede dejar de estar, probablemente conduzca a decisiones financieras y de inversión más arriesgadas de lo que nos gustaría. Y también creo que, precisamente por tratarse de un mercado en formación, es normal la aparición de muchas propuestas y muchas empresas y que una dinámica normal conducirá, en los próximos años, a una estabilización y consolidación, en la que habrá ganadores y perdedores, quizá algunos muy sonados. Sí me parecen previsibles por ello movimientos y acontecimientos empresariales y económicos, algunos de los cuales, podrían ser 'catastróficos' para alguna entidad. Pero no necesariamente tiene que existir una burbuja 'en toda regla', una burbuja mundial, por decirlo de alguna manera.

La segunda declaración, de la que sí que estoy muy convencido, y que he expresado en más de un medio, es que 'no existe burbuja técnica'. Lo que con ello quiero decir es que las capacidades técnicas y operativas de la inteligencia artificial son reales y ya están aquí, que sólo con aquello de que disponemos actualmente, empresas y administraciones, incluso particulares, pueden dar grandes saltos de productividad, eficiencia e innovación. Eso no quiere decir que no exista 'hype', que lo hay, o que no existan partes de la inteligencia artificial, como, en mi opinión, son los agentes, los robots humanoides o los vehículos autónomos, que tengan aún que demostrar su viabilidad generalizada tanto técnica como de negocio. Pero, insisto, sólo con lo que ya hay, lo que de verdad hay, y sin esperar a que mejore (cosa que sucederá seguro), las aplicaciones y el impacto económico son enormes.

La importancia de la implantación

Y esta última consideración me lleva a la implantación, a la adopción real de soluciones de inteligencia artificial por parte de empresas y administraciones.

Una condición fundamental para que no exista burbuja es que las empresas que apuestan por la inteligencia artificial obtengan un suficiente retorno económico, tanto las empresas creadoras de tecnología, como las organizaciones que, 'simplemente', la usan.

Y, para ello, es condición imprescindible que las empresas, administraciones y, en este caso, incluso los particulares, adopten las soluciones de inteligencia artificial. Porque esas empresas, administraciones y particulares sólo obtendrán beneficios económicos de la inteligencia artificial si realmente la usan y la usan de manera exitosa, de forma que les resulte interesante o rentable hacerlo y que, además, claro, estén dispuestos a pagar por la tecnología y por los servicios asociados.

Y es imprescindible la adopción masiva y exitosa para que esas empresas, administraciones y particulares paguen a las empresas creadores de la tecnología o prestadoras de los servicios asociados, de forma que éstas obtengan un retorno que las haga rentables y que justifique su inversión.

Algunas barreras para la implantación

Pero se me ocurre, de una forma que confieso no del todo sistemática, pensar en barreras a esa adopción tan importante para evitar la eventual burbuja.

La primera sería, casi paradójicamente, la rapidez del cambio. Surgen de manera frenética nuevas evoluciones, nuevas herramientas, nuevas posibilidades. Y esa rapidez, que desde el punto de vista de la tecnología y la innovación es maravillosa, curiosamente creo que corre en contra de la adopción. Y eso porque organizaciones y personas, se encuentran perplejas, perdidas ante tantas posibilidades que no asimilan del todo. Eso, además, dificulta la adopción de estrategias y toma de decisiones de adopción, porque es muy difícil saber qué casos de uso son viables y más importantes o qué producto o solución usar y tener una cierta seguridad de que las decisiones van a mostrarse como correctas pasadas unos meses. A eso añadir que esa velocidad también dificulta la disponibilidad de personas y talento, tanto interno como externo, preparado como para hacer una implantación.

Por otra parte, también hay que reconocer que existe 'hype', que existe multitud de promoción exagerada, promesas de capacidades aún no demostradas. Y para un decisor empresarial, si ya la abundancia de soluciones y velocidad de aparición dificulta la decisión, la conciencia de que, además, no todo lo que se publicita está realmente maduro como para una adopción, no hace sino reforzar la perplejidad, en este caso la desconfianza, y retrasar las implantaciones o hacerlas mediante pilotos limitados de bajo riesgo, pero también bajo alcance e impacto en el negocio.

Y no excluiría de la ecuación el miedo. No ya sólo el miedo a no tomar la decisión operativa o económicamente adecuada, sino miedo a los riesgos de naturaleza ética o regulatoria. En un, quiero pensar que bienintencionado, intento por evitar las consecuencias negativas desde un punto de vista ético del uso de la inteligencia artificial, y también de posibles incumplimientos legales y normativos, se pone muchas veces mucho énfasis en riesgos y problemas y por ello los decisores pueden andarse con 'pies de plomo' antes de arriesgarse a cometer un error en este terreno.

Algunas de las soluciones de inteligencia artificial son de naturaleza corporativa, como ocurre con muchos sistemas de información tradicionales. Pero en el caso de la inteligencia artificial generativa, muchas herramientas y posibilidades se producen a nivel individual. En este punto, lo que parece lógico y deseable es que las empresas pongan a disposición de sus empleados las herramientas que, en el fondo, esos mismos empleados usan en sus entornos domésticos, como los chatbots generativos (ChatGPT, Copilot, Gemini, Claude, etc), las integraciones de IA en herramientas ofimáticas como Office 365 o Google Workspace, el uso de herramientas para generar contenidos o presentaciones (Canva, Gamma, etc) y así un largo etcétera. Sin embargo, creo que las empresas y administraciones tienen un poco echado el freno de mano en este apartado, por miedo, en esencia, a fugas de información (externas o internas) o, quizá, a la calidad de los resultados que produzcan sus empleados.

Es posible que exista alguna barrera más, incluida la tan traída y llevada falta de talento en estos campos, pero creo que, aunque no dejan de ser opiniones, las barreras anteriores son reales y frenan en parte el despliegue de soluciones de inteligencia artificial.

Y si se frenan los despliegues, si retardamos la obtención de retornos por parte de todos los actores, corremos el riesgo de hacer que esa burbuja sea cierta y posibilitar o acelerar su pinchazo.

Frente a la burbuja de las 'subprime'

Si quisiera dejar claro que, caso de existir, esta burbuja de la inteligencia artificial no es comparable a la burbuja y consecuente crisis de las 'subprime'. ¿Por qué? Porque aquella se produjo por la creación y gestión irresponsable, cuando no culpable, de unos activos financieros que no estaban respaldados, que no tenían, ni de lejos, el valor que se les asignaba en las transacciones.

En el caso de la inteligencia artificial, como he dicho, sí existe un valor real, y un valor muy grande. El que sea una burbuja o no dependerá de si, aunque ese valor exista, que existe, se haya sobrevalorado o no se materialice por falta de adopción.

Enseñanzas de la burbuja de las puntocom

Si nos vamos algo más lejos, al caso del estallido de las puntocom allá por el año 2000, sí asistimos patrones más parecidos al caso de la inteligencia artificial actual. No sólo porque hablamos de una eventual burbuja de base tecnológica sino porque el valor era real.

El valor que tenía internet, las redes sociales, el comercio electrónico y todo lo que se dio en llamar 'la nueva economía' era real, y tan real era que pocos años después se comenzó a notar en despliegues reales y masivos y, de hecho, hoy vivimos plenamente inmersos, seamos conscientes o no, en esa 'nueva economía'.

La promesa de las puntocom falló no porque las posibilidades no fueran reales sino porque, seguramente, se vieron mas cercanas de lo que realmente eran y porque se tomaron muchas decisiones de inversión probablemente irracionales o con un exceso de riesgo.

Y esto es lo que hay que evitar en el caso de la eventual burbuja de la inteligencia artificial.

Y para ello, en primer lugar, y esto no es desde luego fácil en un entorno tan volátil, tan en ebullición como el de la inteligencia artificial, que empresas y administraciones inviertan de una manera racional, tanto en volumen como en soluciones con posibilidades reales.

Y por otra parte, que se produzca la adopción, la implantación generalizada de soluciones de inteligencia artificial que reporte beneficios tanto a las organizaciones clientes de esas tecnologías como a los fabricantes y prestadores de servicio.

Conclusiones

Existe un cierto 'runrún' acerca de si nos encontramos ante una burbuja de la inteligencia artificial, que supondría unas expectativas, y consiguientes inversiones, desmedidas y sin un retorno claro.

En este artículo expreso mi convencimiento de que, desde el punto de vista estrictamente técnico, no existe tal burbuja, pero que es posible que si sea real desde el punto de vista económico, que en el fondo es el que importa.

Y destaco cómo, para que esa burbuja no se produzca, es fundamental la implantación masiva de soluciones que generen los retornos esperados, para lo cual, sin embargo, existen algunas barreras.

Grietas en el determinismo de los modelos generativos: limitaciones, errores e imprevistos

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 21 Jan 2026 12:00:00 +0000

Ya he hablado en algunos post recientes sobre el carácter probabilista o determinista de los modelos generativos, en especial de los grandes modelos de lenguaje, LLM ('Large Language Models').

Mi conclusión hasta ahora, es que, aunque de comportamiento externamente probabilista, internamente tienen un funcionamiento plenamente determinista. Incluso, como veíamos en el último post de la serie hasta ahora, esa aleatoriedad externa se puede exacerbar y, lo que es más importante, eliminar, o congelar, usando parámetros de configuración.

Y esta conclusión momentánea, excluye, en mi opinión, la posibilidad de un libre albedrío de las máquinas.

Sin embargo, hay experiencias prácticas y estudios científicos que desafían ese determinismo subyacente, y que muestran que, aunque los modelos 'se congelen' (es decir, se elimine el carácter probabilista mediante el ajuste de parámetros), se siguen produciendo resultados no deterministas.

¿Cómo es eso posible?

Según vamos a ver, creo que podemos considerar que esos efectos no deterministas se producen por limitaciones en el hardware y errores en el diseño o implementación de los modelos o, si preferimos no ser muy duros, por la aparición de fenómenos imprevistos, muy difíciles de haber anticipado a priori.

En este post, probablemente el más técnico de la serie, vamos a revisar algunos de esas limitaciones, errores o imprevistos que desafían el determinismo de los modelos.

Y para ello me baso en el muy interesante, pero también complejo, artículo 'Defeating Nondeterminism in LLM Inference' publicado por Thinking Machines la startup de Mira Murati, quien fuera CTO ('Chief Technology Officer') de OpenAI.

Los números reales y la coma flotante

El primero de los problemas que se describe en el artículo, pero que ha sido tratado anteriormente por otros autores, aborda problemáticas derivadas del trabajo con números reales representados en el formato denominado 'coma flotante'.

Recordemos brevemente qué es eso de 'coma flotante'. Se trata de una estrategia de representación en formato digital (unos y ceros) de números reales (por entendernos, los que tienen decimales).

Supongamos que queremos representar números reales usando 4 bytes (es decir, 32 bits y, por lo tanto, la posibilidad, a priori, de representar 2³² números diferentes). Si ahora queremos representar números decimales, podríamos decidir dedicar tres bytes a representar la parte entera del número y uno a representar la parte decimal. Con esto, tendríamos lo siguiente:

Un bit para indicar el signo (positivo o negativo)

23 bits para indicar la parte entera, con lo cual, podríamos representar hasta el 2²³, es decir, hasta 8.388.608

8 bits para la parte decimal, lo cual nos daría una precisión (incremento más pequeño, por decirlo de alguna manera, de 2^-8, es decir 0,00390625

Esto es fácil de entender y gestionar, pero tiene dos problemas: un rango limitado (cantidad de números que puede representar) y una precisión limitada. Aparte de la opción de incrementar el numero de bits, la que se suele adoptar es usar el denominado formato de coma flotante, que es lo que estamos acostumbrados a visualizar como 'notación científica'.

En este caso, representamos un número real 'x', que 'pensamos' como

x = ± m×2^e

donde m es lo que se denomina mantisa y que está constituido por las cifras significativas (aquellas que aportan información real sobre su valor, excluyendo, en esencia, los ceros que sirven solo como relleno de posición) y 'e' es el exponente (que puede ser positivo o negativo)

En el caso del formato se simple precisión IEEE 754, los bits se utilizarían de la siguiente forma:

un bit para el signo

8 bits para el exponente, que es quien controla, en el fondo, la posición de 'la coma' en la representación binaria

23 bits para la mantisa

No quiero, 'liarlo' ya mucho más, pero sí decir que los bits que utilizamos en la mantisa nos dan la precisión, que en esta caso son 24 bits (23 bits de la mantisa más uno).

Esta forma de representar los números reales, habituales en cálculos científicos y, desde luego, en machine learning, tiene ventajas de cubrir rangos muy amplios pero viene con alguna limitación o desventaja. Por un lado, necesita de un hardware y software más complejo y, sobre todo, y lo que nos interesa en este momento es que, no sólo no puede representar de manera exacta muchos números (por falta de precisión) y, lo más importante de todo: comete errores de redondeo.

Asociatividad y condiciones de carrera

Cuando usamos la representación en coma flotante cada representación concreta de un número tiene la misma precisión pero puede tener 'la coma' en un sitio diferente.

En el artículo se nos muestra con un ejemplo sencillo cómo si sumamos dos números en coma flotante con diferente posición de 'la coma', es decir, con diferente exponente, puede suceder que el numero resultante (la suma) necesite de una precisión superior a aquella de la que disponemos (digamos porque uno es muy grande y el otro muy pequeño). Representar correctamente el número resultante, un número 'muy grande' pero 'con muchos decimales', implicaría disponer de más bits en la mantisa de los que tenemos.

Por tanto, en la operación es preciso hacer un redondeo que nos permita encajar el resultado en la precisión disponible. Y, en ese redondeo, perdemos información, generamos un cierto error.

En el artículo se nos explica que, en ese caso, el orden en que realizamos las operaciones entre números (los mismos números) impacta en el resultado. En concreto, nos muestra cómo la propiedad asociativa

a + (b + c) = (a + b) + c

no se mantiene, realmente. Para, admitiendo que se puede producir un error de redondeo pero que, al menos, eso no llevase a resultados diferentes en ejecuciones diferentes, habría que garantizar que las operaciones se realizan exactamente en el mismo orden.

Pero eso, ese mantenimiento del mismo orden, no sucede, y la explicación de por qué no sucede nos lleva al mundo del hardware, de los famosos GPU ('Grahical Processing Unit') y procesadores similares

El hardware y condiciones de carrera no deterministas

Los modernos procesadores, como los GPUs, están compuestos de muchos núcleos o 'cores' que pueden procesar en paralelo diferentes operaciones, siendo las operaciones que se paralelizan en una GPU para tratar muchos datos, lo que se conoce como 'kernels' (que, lamentablemente, en castellano se suele traducir también como núcleo). Estos 'cores' funcionan de manera concurrente y sin sincronización entre ellos.

Una hipótesis formulada en otros trabajos para explicar el no determinismo, supone que el problema del no determinismo nace de que los propios 'cores' funcionan de manera no determinista. Esto quiere decir que un algoritmo hace que se lancen concurrentemente varios cálculos cuyos resultados luego, digamos, que se van a ir por ejemplo sumando (acumulando) a medida que acaben. Pero no es determinista cuándo finaliza cada 'core su cálculo y, por tanto, no es podemos saber en qué orden se va a a sumar o acumular cada resultado parcial.

Como, por lo que hemos visto más arriba, en operaciones en coma flotante se producen errores de redondeo diferentes según el orden de las operaciones, esto lleva a que el resultado final del algoritmo sea no determinista.

Sin embargo, aunque los autores del artículo explican esta hipótesis, afirman que en la práctica, los problemas reales y las implementaciones reales de las típicas librerías python involucradas, hacen que este problema no aparezca nunca o casi nunca.

Peticiones en paralelo

Los autores, sin embargo, aportan otro escenario.

Indican que los LLMs cuando se utilizan en inferencia ('forward pass') son, en efecto, deterministas. Ante una misma petición del usuario, responderán lo mismo (asumo que hemos eliminado el paso final de selección probabilista de token que expliqué en el post anterior).

El problema, según indican, es la concurrencia de diferentes peticiones y la creación, por ello, de diferentes 'batches'. Es decir, mantienen que si, el 'forward pass' considerado individualmente es determinista, pero el sistema en su conjunto, no.

Antes de seguir, comentar que los 'batches' son las entradas que, efectivamente, se envían a un LLM. Por eficiencia de implementación, los batches que se envían pueden, en realidad, incluir textos de entradas de usuario diferentes. Aunque, en teoría, el tamaño de los batches y las entradas que combinan no debería afectar al resultado, los autores muestran que no es así, que sí que afectan

Y eso porque no existe en los 'kernels' la denominada 'batch-invariance', es decir, el procesamiento de las peticiones de un usuario no es completamente independiente de los batches que procesa y, por tanto, del procesamiento de las peticiones de otro usuario.

Para explicarlo los autores se centran en las operaciones de multiplicación de matrices (que se utilizan profusamente en machine learning y deep learning y, por tanto, también en la inferencia de los LLMs).

Parece que, esas operaciones deben ser deterministas (y en teoría lo son) y que, además, no les debería afectar otras operaciones en paralelo. Bueno, pues esto último, no es del todo cierto.

¿Por qué?

.Pues porque la carga computacional a que se ve sometido un LLM (y, sobre todo, el hardware que lo soporta) se ve afectado por la cantidad y naturaleza de las peticiones a que se ve sometido. Es decir, el tamaño de los 'batches' que se van enviando al LLM se pueden modificar según la carga, o dicho de otra forma, la carga computacional determina el tamaño de batch. Y como los 'kernels' no son invariantes respecto al batch (no son 'batch-invariant') el resultado puede modificarse según sean las peticiones en paralelo.

En busca de la invariancia

Todo lo que he explicado hasta el momento, apenas ocupa la mitad, aproximadamente, del artículo en que me baso. En lo que resta, los autores, se centran en indicar (de forma muy técnica) cómo conseguir que los 'kernels' sean realmente 'batch-invariant'. Para ello, asumen que las operaciones más básicas son invariantes y entienden que basta con conseguir la invariancia en tres operaciones complejas y muy importantes, a saber:

La aplicación de la RMSNorm ('Root Mean Square Normalization'), operación de normalización (ajuste de los valores a un rango concreto) usada en entrenamiento e inferencia

Multiplicación de matrices

Mecanismo de atención: elemento fundamental de las arquitecturas transformes y que aporta el nivel de importancia que se asigna cada elemento de la entrada

Los autores, además, afirman disponer de una implementación de esas soluciones y aportan datos de los experimentos realizados

Vuelta al determinismo

En sus conclusiones, los autores se posicionan a favor del determinismo de los algoritmos en el sentido de que, no debemos aceptar los errores que se han observado (y que hemos descrito) y que llevan a que los LLMs no sean completamente deterministas.

Dicen que, con un poco de trabajo, se pueden entender las causas raíces de ese determinismo y resolverlas. Y abogan por ello, claro.

Implicaciones de cara al libre albedrío de las máquinas

Si aplicamos las recetas de estos autores, está claro que volvemos a la situación que yo siempre había afirmado (y que aquí hemos visto algunas grietas) volveríamos a estar en el caso de algoritmos plenamente deterministas, al menos en su comportamiento interno, aunque así no en su manifestación externa.

Y, en ese sentido, no habría lugar, al menos eso entiendo yo, para pensar en un libre albedrío ni voluntad propia de las máquinas, al menos las actuales.

Pero ¿Y qué pasa si no resolvemos eso? ¿Qué pasa si se siguen produciendo errores de redondeo y, sobre todo, si esos errores, ante condiciones de carrera o peticiones en paralelo de usuarios y unos 'kernels' no invariantes en batches, nos llevan a resultados no deterministas?

¿Abre eso realmente la puerta a un libre albedrío de las máquinas?

Creo que esa reflexión la reservo para un siguiente post, algo menos técnico y más especulativo y filosófico y con el que, creo, cerraré de momento este pequeño grupo de artículos dedicados al determinismo de los modelos generativos.

Conclusiones

Aunque externamente los modelos generativos, y en concreto los LLMs, se manifiestan como probabilistas, en su funcionamiento interno siguen algoritmos muy claros (aunque complejos) y en que el comportamiento probabilista está también perfectamente delimitado mediante parámetros de configuración por lo que, internamente, y sobre todo para razonar sobre libres albedríos, podemos considerarlos, en principio, deterministas.

Sin embargo, según hemos visto en este artículo, hay algunas grietas no buscadas en ese determinismo, pequeñas dosis de aleatoriedad no controlada y achacables, podríamos decir, a errores de diseño o implementación debidos, seguramente, a imprevistos.

En el propio artículo hemos visto que hay alguna propuesta para 'devolver al redil' a esos LLMs y que vuelvan a ser, internamente, plenamente deterministas.

Lo que queda por razonar es si esas brechas en el determinismo, realmente abren alguna posibilidad al libre albedrío de las máquinas o no.

Pero eso queda ya para otro post.

Artículos de este blog relacionados

Trabajo y empleabilidad en tiempos de Inteligencia Artificial. Una reseña de "De la EGB a la IA"

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 16 Jan 2026 10:45:00 +0000

'De la EGB a la IA' es un libro coral que ofrece diferentes perspectivas sobre el impacto de la tecnología digital, especialmente la inteligencia artificial, en el ámbito laboral y la empleabilidad con especial foco en las personas jóvenes. En él, cada uno de sus trece autores ofrece, en un capítulo diferenciado, un reflexión en un campo específico que constituye su ámbito de interés y/o experiencia.

El libro se encuentra prologado por Juan Zafra con un inicio titulado 'El mundo será como queramos hacerlo' y, a partir de ahí, se estructura en doce capítulos cada uno de diferente autoría y temática, tal y como sigue:

'Capítulo 1. Época de nuevos y mejores hombres (Félix Hernández de Rojas):' ofrece una mirada amplia, que incluye lo económico, lo cultural y lo ético, muy apoyada en datos e informes, y con toques de geoestrategia y geopolítica, acerca del impacto y los retos del mundo digital.

'Capítulo 2. Empleabilidad en el s. XXI (Manuel García Gil):' a través de un diálogo padre-hijo, en apariencia ligero pero muy ilustrativo, reflexionamos sobre la empleabilidad y el desarrollo de capacidades.

'Capítulo 3. La importancia de desarrollar una nueva mentalidad digital (Virginia Cabrera Nocito):' Una explicación de lo que es la mentalidad digital, qué habilidades y capacidades comprende y los ejes para el desarrollo de una mentalidad de crecimiento en este entorno digital.

'Capítulo 4. Algo más que tecnología para tu plan digital personal (Pablo Pinillos):' identificación de las habilidades que, más allá del casi inevitable conocimiento STEM, deben adornar al profesional del presente y del futuro. Unas habilidades que incluyen, entre otras muchas, la comunicación verbal, no verbal y escrita, y unas habilidades que se pueden apoyar en el teatro como forma de entrenamiento. Y también una visión casi de marca personal que aboga por la gestión de la reputación digital y el establecimiento de un plan de marketing personal.

'Capítulo 5. Guía para la supervivencia en el apocalipsis zombi laboral (Julio Jesús Sánchez):' Una reflexión que puede parecer jocosa pero que en realidad muestra muchas sombras para la perspectiva laboral que vienen de la mano, o como consecuencia, de la transformación digital y que la explosión de la inteligencia artificial no hace sino agravar. Se analiza ese impacto y se acaba proponiendo un recetario con ocho ingredientes para sobrevivir en ese 'apocalipsis zombi'.

'Capítulo 6. Tu responsabilidad en un mundo robotizado (Ignacio G.R. Gavilán):' Una cerrada apuesta por la ética y la responsabilidad, institucional y corporativa, pero sobre todo individual, y para con los demás, pero también con uno mismo, ante los desafíos éticos y sociales que plantea lo digital y, muy especialmente, la inteligencia artificial y el auge de los robots.

'Capítulo 7. Cómo manejar la no tan inteligente inteligencia artificial en el puesto de trabajo (Roberto García Esteban):' Parte de una cierta desmitificación de la inteligencia artificial para luego identificar sus tres principales impactos en el terreno laboral y ofrecer unas consideraciones sobre la sustitución o no del ser humano por la inteligencia artificial.

'Capítulo 8. IA generativa, liderazgo y nuevos modelos de colaboración (Alejandro de Fuenmayor Rossell):' Una larga e ilustrada reflexión acerca del impacto de la revolución digital y cognitiva e, incluso, de la pandemia del COVID con foco en la automatización e incluso los paradigmas de desarrollo de software, finalizando con mirada al futuro en cuanto a tendencias tecnológicas y su impacto en el trabajo y culminando en una propuesta final de un nuevo modelo de trabajo.

'Capítulo 9. Las plataformas de metaverso en el futuro del trabajo (José Carlos Martín Marco):' Ahora que parece que el metaverso ha perdido fuelle, aquí nos encontramos con una decidida y argumentada apuesta por los entornos de colaboración a través de avatares en entornos virtuales en 3D, una apuesta que se desarrolla siguiendo todo el desarrollo histórico de las tecnologías de comunicación, interacción y virtualización.

'Capítulo 10. ¿Por que te digo que la productividad no asegura la creatividad? (Javier Lorente):' la importancia, la necesidad en realidad de la creatividad y la de su desarrollo, una importancia que se argumenta comenzando por un análisis de impactos de la digitalización en materias como remotización, escalabilidad, automatización y, finalmente, productividad, para luego analizar la afectación cognitiva de trabajar incorrectamente en entornos digitalizados y eficientes, lo que lleva como consecuencia a la importancia de desarrollar la creatividad para lo que se proporcionan diez consejos prácticos.

'Capítulo 11. ¿Por qué estudiar desarrollo de software en la era del ChatGPT(Víctor Deutsch):' Pone foco en una actividad profesional, el desarrollo de software, cuyos ejecutores, los desarrolladores, han sido los grandes protagonistas de la revolución digital pero cuyo propio empleo puede parecer ahora amenazado por las capacidades que ofrece la inteligencia artificial. Tras un repaso histórico de esta actividad, el desarrollo de software, se defiende la necesidad y utilidad actual de estos perfiles, se identifican las nuevas habilidades que deben exhibir, se apuesta por disciplinas como DevOps o ciberseguridad, y se identifica un nuevo rol para el presente y futuro: el gestor de productos digitales.

'Capítulo 12. El jefe de un cíborg no tiene por qué ser un ingeniero. Humanistas en la era de la IA (Carmen Menchero de los Ríos):' Se concentra en las oportunidades de los profesionales de disciplinas humanistas en este nuevo mundo inundado de inteligencia artificial, incluyendo un repaso por perfiles como psicólogos, pedagogos, antropólogos, documentalistas, periodistas, abogados, filósofos o historiadores.

El libro se cierra con un epílogo firmado por la decimotercera autora, Mercedes Núñez, que resalta la incertidumbre actual y futura, la falta de un suelo firme en que apoyarse lo que trae consigo exigencias en materia de formación constante, colaboración o las así llamadas 'habilidades blandas'. Y culmina con una llamada a dejar espacio también a la desconexión, la conciliación y el descanso.

'De la EGB a la IA' constituye una visión multidisciplinar, rica en perspectivas y apoyada en la larga experiencia profesional y vital de sus autores, sobre lo que nos ha traído y puede traer consigo este mundo cada vez más digital, más tecnológico y con una futuro para el trabajo y el empleo sobre el que existen, seguramente, más incertidumbres que certezas.

Mundos posibles

(Fuente: Elaboración propia a partir de la solapa del libro 'De la EGB a la IA en su edición de 2025 en Caligrama).

Equipo de 'Mundos Posibles'

'Mundos posibles' es un colectivo de profesionales de larga experiencia cuyos miembros tienen en común el haber pertenecido en algún momento de sus carreras a Telefónica y, en concreto, a la unidad Telefónica Empresas de Telefónica de España y haber colaborado en el mítico blog, ya desaparecido, denominado 'A un Clic de las TIC' de esta misma unidad.

Así se presentan:

Somos un colectivo multidisciplinar con largas y diversas trayectorias profesionales. Cada uno de nosotros vive, desde hace años y en primera persona, la transición a la era digital y podría decirse que ha tenido que mudar varias veces de piel. Todos pertenecemos, o lo hemos hecho, a empresas punteras del sector tecnológico, lo que nos ha permitido contemplar con cierta antelación este nuevo mundo. Apenas se abre paso, pero su complejidad ya nos abruma. En el terreno laboral los retos son enormes. Las posibilidades también.

Por eso queremos compartir nuestro aprendizaje con los jóvenes que van a desembarcar en él próximamente, con quienes se tendrán que reinventar y con aquellos que tienen la responsabilidad de seleccionar al talento correcto. No es que conozcamos el futuro, pero sí tenemos algunas claves. Cada uno, las suyas. Pensamos que una visión poliédrica y plantearse las preguntas adecuadas es la mejor estrategia en tiempos de incertidumbre. En este libro queremos compartir nuestras lecciones aprendidas.

Los componentes de este grupo son, en orden alfabético:

Virginia Cabrera Nocito
Víctor Deutsch
Alejandro de Fuenmayor Rossell
Roberto García Esteban
Manuel García Gil
Ignacio G.R. Gavilán
Félix Hernández de Rojas
Javier Lorente
José Carlos Martín Marco
Carmen Menchero de los Ríos
Mercedes Núñez Sánchez
Julio Jesús Sánchez
Pablo Pinillos Clemente

Puedes conocer más de 'Mundos posibles' visitando o siguiendo su su página en LinkedIn.

Vídeo de promoción

Tanto la personalidad y trayectoria como el planteamiento y contenido del libro se resumen en este vídeo de promoción lanzado por el equipo de 'Mundos posibles' .

Ficha técnica:

TITULO: De la EGB a la IA

AUTOR: Mundos posibles (varios autores)

EDITORIAL: Caligrama

AÑO: 2025

ISBN: 979-8341634756

PAGINAS: 350

Determinismo y el gobierno de la aleatoriedad en grandes modelos de lenguaje

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 14 Jan 2026 10:25:00 +0000

Hace ya casi tres meses, publiqué en este mismo blog un artículo titulado 'Sobre el determinismo y los modelos generativos'. En él razonaba sobre el eventual determinismo o no de los modelos generativos, fundamentalmente los grandes modelos de lenguaje.

Pero, por un lado, siento que me han quedado cosas por decir (incluso por pensar) y, por otro, he conocido alguna información nueva que añadir, así que voy a retomar este asunto sobre el determinismo de los modelos generativos escribiendo, al menos, dos nuevos artículos (éste es el primero) y no me extrañaría que alguno más.

Entre un problema operativo y un problema ético

En el primer artículo en titulado 'Sobre el determinismo y los modelos generativos', hablaba de una doble visión o una casi doble conclusión. Así, concluía que, si miramos a los modelos de lenguaje (casi mejor habría que decir las aplicaciones basadas en ellos), como usuarios y desde un punto de vista práctico, claramente debemos considerar que ese tipo de modelos o aplicaciones son probabilistas, no deterministas.

Es importante tenerlo claro para no llevarnos sorpresas sobre sus resultados, para ser conscientes de que debemos aplicar criterio y juicio crítico a los resultados que nos ofrecen y a adoptar precauciones si los utilizamos en el campo de la automatización, asunto del que también hablé en otra serie de posts.

Sin embargo, si entramos a un nivel 'micro', entendiendo mejor cómo funcionan en detalle, mi conclusión, la que expresé en ese primer post, es que este tipo de modelos son deterministas. Curiosamente, aunque esa conclusión la obtengo con una análisis mucho más técnico y detallado, las consecuencias no tienen tanto que ver con lo operativo como con lo ético.

Ya hace bastante tiempo argumenté también el determinismo de la inteligencia artificial, especialmente de las redes neuronales en el post 'Los algoritmos de Inteligencia Artificial sí saben explicarse' y cómo eso arrojaba una perspectiva diferente sobre la explicabilidad de la inteligencia artificial, uno de los campos donde se produce mayor debate ético.

Pero adicionalmente, el determinismo importa para el debate sobre la eventualidad de un libre albedrío, de una voluntad propia por parte de algoritmos y máquinas. E importa porque, si hablamos de algoritmos deterministas, no se me ocurre cómo pueden tener nada que se parezca a un libre albedrío o una voluntad propia. Pero si no son deterministas 'la cosa' queda más abierta.

De dónde partimos

De forma muy, muy simplificada, recordar que los grandes modelos de lenguaje funcionan, de manera iterativa, generando su salida paso a paso, podríamos decir que palabra a palabra, aunque en realidad es 'token' a 'token', y que en cada paso toman como entrada un texto que incluye, simplificando, tres cosas:

el 'prompt' que ha introducido el usuario
información de contexto
el texto que ha generado hasta el momento como salida.

Y añadir un detalle más: aunque el resultado de final de cada iteración es un nuevo token que se añade a la salida, hay un paso anterior en que lo que realmente tenemos son un conjunto de 'tokens' posibles junto con un valor de probabilidad de ser el 'token' más adecuado. Y el algoritmo acaba eligiendo uno de esos 'tokens' posibles, como el token ganador y que finalmente se añade al texto de salida.

En mi post anterior sobre este tema argumentaba que, pese a que hablamos de probabilidad, todo el algoritmo está perfectamente definido y la aleatoriedad, en informática, se suele basar en una 'seudoaleatoriedad' en una funciones complejas con una semilla de entrada y que generan una salida que, aunque a efectos prácticos es perfectamente aleatoria, en su visión matemática interna está perfectamente determinada.

Por todo ello, en mi post anterior afirmaba que estos algoritmos, estrictamente hablando son deterministas, aunque externamente no se manifiesten así.

El gobierno de la aleatoriedad de los grandes modelos de lenguaje y sus parámetros

Y ya llegamos al tema a que quería dedicar este post: el gobierno de la aleatoriedad. Por 'gobierno de la aleatoriedad', un término quizá algo grandilocuente que me acabo de inventar para este artículo, me refiero, simplemente, a los parámetros que gobiernan el comportamiento de la aleatoriedad en grandes modelos de lenguaje

Se trata de unos parámetros que, como usuarios de herramientas basadas en modelos de lenguaje como ChatGPT o Gemini no percibimos, pero que sí que son utilizados (o pueden serlo) por desarrolladores que construyen aplicaciones basadas en modelos de lenguaje.

En ese sentido, se trata de unos parámetros que, aunque no son de conocimiento del público general, sí que son bastante conocidos para los perfiles más técnicos

Aunque estos parámetros están descritos en multitud de fuentes, para este post he consultado el libro 'LLMOps: Managing Large Language Models in Production' de Abi Aryan (simplemente porque recordaba que ahí hacía una buena pero concisa descripción).

Veamos esos parámetros.

La temperatura

El parámetro más conocido, y seguramente el más importante, es el que se denomina 'temperatura' un nombre elegido dado el cierto paralelismo que guarda con la temperatura real en procesos termodinámicos de la naturaleza.

Sin entrar en la formulación matemática (que la fuente que utilizo no explica) lo que controla la temperatura es, precisamente, hasta qué punto el modelo es más o menos aleatorio, hasta qué punto, por decirlo de alguna manera es más capaz de aportar respuestas originales. Cuando presenta valores bajos, las respuestas son más conservadoras y, es lo que normalmente querríamos para un análisis técnico o científico o para una automatización. Cuando presenta valores altos el modelo es más 'atrevido', más original y es lo que querríamos, por ejemplo, para generar historias creativas o un 'storytelling'.

En teoría, si fijamos esa temperatura a cero, el modelo deja de ser probabilista para convertirse en determinista, sin aleatoriedad.

Parámetros para acotar opciones

Hay otros dos parámetros que acotan un poco las opciones finales del modelo o, si se prefiere, su diversidad ¿Qué quiere decir esto?

Como comentaba más arriba, hacia el final del proceso, el modelo ofrece varios 'tokens' candidatos con un nivel de probabilidad y elije como resultado final, uno de esos tokens candidatos.

Pues bien, existen dos parámetros que controlan el número de tokens candidatos entre los que se puede elegir al final. El parámetro denominado 'top-k' acota en 'k' los token finales candidatos. Por ejemplo, si top-k se ajusta a 5, se elegiría sólo entre los cinco tokens más probables.

Con una filosofía parecida pero ligeramente diferente, tenemos el parámetro 'top-n' en que lo que se fija es un umbral de probabilidad acumulada, y al final se elige, el menor número de tokens, de entre los tokens de mayor probabilidad, tales que la suma de sus probabilidades supera el umbral establecido por el parámetro.

Ambos parámetros acotan el número de opciones posibles de cara a la elección final pero de forma tal que, cuanto mayor es su valor, mayor es la diversidad y la originalidad.

Parámetros para buscar la variedad

Finalmente, y quizá un poco menos conocidos, tenemos dos parámetros que actúan como penalizaciones pero que lo que buscan es fomentar la variedad. Es como cuando escribimos un texto literario y usamos sinónimos para evitar repetir constantemente la misma palabra. Aunque semántica y técnicamente, repetir constantemente la misma palabra es correcto, desde un punto de vista de discurso, queda poco elegante, poco artístico y, en casos extremos, poco natural.

Pues bien en esa línea, un primer parámetro es la penalización de frecuencia ('frequency penalty') que aplica una penalización a los tokens candidatos en función de la frecuencia con que han aparecido en el texto ya generado.

Otra estrategia parecida pero ligeramente diferente, se basa en el parámetro penalización de presencia ('presence penalty') que penaliza a los tokens que han aparecido una vez en el texto general, con independencia del número de veces que lo hayan hecho.

Alguna 'pre-conclusión'

Estos parámetros que hemos visto, ilustran cómo se gobierna el nivel de aleatoriedad, digamos 'externa', de los modelos. Pero esa ilustración no altera mis conclusiones del post que mencionaba al principio: los modelos, aunque externamente presentan un comportamiento probabilista, internamente son, en el fondo, deterministas.

Pero la cosa no acaba aquí

Sin embargo, tras la publicación de ese primer post sobre el determinismo, han llegado a mi nuevos análisis y nuevas perspectivas que podrían poner en cuestión el determinismo. Así que se impone reflexionar sobre ello y comentar las conclusiones en algún post próximo.

Artículos de este blog relacionados

Conociendo el Vibe coding y más con Addy Osmani

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 09 Jan 2026 09:55:00 +0000

'Beyond Vibe coding' es un libro que, como el título sin duda expresa, nos habla del 'Vibe coding', es decir, de la generación de código software usando grandes modelos de lenguaje a los que se les aportan los requisitos y necesidades en lenguaje natural. Pero, como también el título expresa, no se queda ahí sino que, en realidad, nos habla de todo el campo de la ingeniería de software apoyada, en mayor o menor medida, en la inteligencia artificial (en esencia, en grandes modelos de lenguaje).

Se trata de un libro fundamentalmente dirigido a desarrolladores y arquitectos, pero que creo aporta valor a cualquiera implicado o familiarizado con la ingeniería de software.

El libro, de mediana, casi corta, extensión, se extructura en once capítulos agrupados en tres partes, como sigue:

'I. FOUNDATIONS': Aporta los conceptos fundamentales sobre 'Vibe coding' pero también sobre el uso de lenguaje natural para relacionarse con los modelos de lenguaje en forma de 'prompts'. Incluye los dos primeros capítulos:
- '1. Introduction: What is Vibe coding?': Comienza exponiendo el origen del término 'Vibe coding' (debido a Andrej Karpathy) y hace una distinción entre el, digamos, 'puro vibe coding', en que toda la interacción para la generación de código se hace mediante lenguaje natural y lo que denomina ingeniería asistida por IA ('AI-assisted engineering') en que la IA se integra dentro de los entornos de desarrollo o IDE ('Integrated Development Environment') como un apoyo. Luego habla de la intención ('intent') como aquello que el desarrollador quiere conseguir de su software y delinea el uso de los prompts para expresarlo. Además muestra un esquema de ciclo de vida o mecánica de trabajo y añade un vistazo a las principales herramientas y los principales modelos para finalizar cantando los beneficios del uso de la IA en el desarrollo software.
- '2. The art of the prompt: communicating effectively with AI': Un capítulo dedicado a la ingeniería de instrucciones ('prompt engineering') aplicada al desarrollo de software. Habla de características fundamentales como la claridad y especificidad y propone un trabajo iterativo. Luego describe técnicas habituales de prompting tanto básicas como más avanzadas.

'II: AI CODING IN PRACTICE': La parte nuclear del libro y que aborda los diferentes elementos de la ingeniería de software apoyada en IA. Esta compuesta por cinco capítulos, a saber:
- '3. The 70% problem: AI-assisted workflows that actually work': Plantea el problema del 70% en el sentido de que esa es la proporción aproximada en que el trabajo con código es casi sencillo y que sigue patrones bien definidos, siendo por tanto objeto claro de la ayuda de la IA, mientras que el 30% restante necesita intervención humana. Tras repasar cómo los desarrolladores trabajan en la práctica con la IA, aporta unas 'reglas de oro'.
- '4. Beyond the 70%: maximizing human contribution': Se centra en la parte de la aportación humana y lo hace distinguiendo tres niveles: ingenieros senior, ingenieros de nivel medio y desarrolladores junior.
- '5. Understanding generated code: review, refine, own': Aborda la revisión y prueba del código generado por la IA. Nos advierte de que la IA tiende a generar un código basado en los patrones más habituales pero que no siempre resultan óptimos. Luego presenta estrategias para la depuración del código o para el denominado 'refactoring' (rediseño y construcción) para conseguir mejores características de explotación y mantenimiento. Y finaliza enfatizando la importancia de las pruebas en sus diferentes niveles: unitarias, de integración y extremo-a-extremo.
- '6. AI-driven prototyping: tools and techniques': Se centra en el prototipado, quizá uno de los ámbitos donde mejor se puede aplicar el 'vibe coding'. Nos habla de herramientas incluyendo las que generan sólo el 'mockup' (ej. Vercel), las que generan aplicaciones completas (como Lovable o Bolt.new) o las más avanzadas que se integran en los IDEs, como Cursor, Windsurf o Cline. Y luego trata algunas mecánicas de trabajo que incluyen la iteración hasta conseguir el prototipo deseado, la forma de evolucionar un prototipo a un sistema en producción o como hacer frente a algunos desafíos en el prototipado.
- '7. Building web applications with AI': Y finaliza esta parte dedicada al desarrollo en sí mismo con otro caso paradigmatico para el uso de 'vibe coding': las páginas web. Describe cómo trabajar tanto en el 'front-end', como en el 'back-end' (sobre todo uso de APIs), como integrar bases de datos, llegando a una integración 'full-stack'. Y no deja de aportar también sugerencias en cuanto a prueba y validación.

'III. TRUST AND AUTONOMY': Por un lado aborda aspectos más propios de la operación (seguridad, despliege, mantenimeinto, etc), y por otro revisa consideraciones éticas y tendencias. Incluye los cuatro capítulos finales:
- '8. Security, maintanability, and reliability': Comienza enfocándose en los aspectos de seguridad, identificando primero algunas vulnerabilidades comunes y describiendo luego elementos de auditoría de seguridad. Luego salta a elementos de mantenibilidad aportando consejos sobre cómo conseguir esa mantenibilidad y también sugiriendo y explicando cómo hacer revisiones de código. Finaliza con consejos sobre el despliegue ('deployment`) y cómo hacerlo más confiable.
- '9. The ethical implications of vibe coding': Se centra en tres grandes problemáticas, a saber: propiedad intelectual, sesgos y equidad y trasparencia y atribución. Como guía para un desarrollo ético aporta, además, cinco reglas de oro.
- '10. Autonomous background coding agents': Explora una línea emergente como es el salto de la IA como asistente o generador de código pero bajo petición humana a los agentes autónomos de codificación en que, siguiendo la filosofía de los agentes, se les marcan a éstos unos objetivos de alto nivel y los agentes se encargan del resto. Tras explicar el concepto, describe las líneas básicas de cómo funcionan estos agentes y finaliza comparando su comportamiento con el de un IDE.
- '11. Beyond code generation: the future of AI-augmented development': Un capítulo de mirada al futuro con tendencias que estructura en varios apartados: prueba y depuración, diseño y experiencia de usuario, dirección de proyectos, agentes autónomos y lenguajes de programación. Remata el capítulo y el libro destacando cinco grandes ideas sobre cómo el 'vibe coding' está transformando la industria de la ingeniería software.

'Beyond Vibe coding' me ha parecido un gran libro porque describe de manera comprensible y muy correcta todos los conceptos, porque es abarcador en el sentido de no atacar sólo el puro desarrollo sino todo el contexto de la ingeniería de software y, sobre todo, porque, pese a tratar un tema de máxima actualidad y muy propicio para el 'hype', el tratamiento es muy realista, muy sensato y se nota que basado en experiencia real.

Sin duda, lo recomiendo.

Addy Osmani

(Fuente: traducción asistida con IA de su entrada en página oficial)

Addy Osmani

Addy Osmani es un ingeniero de software irlandés que actualmente trabaja en el navegador web Google Chrome y Gemini con Google DeepMind.

Desarrollador desde hace más de 25 años, lleva más de trece años trabajando en Google, centrado en hacer que la web sea más fluida para los usuarios y los desarrolladores web. Le apasionan la ingeniería asistida por IA y las herramientas de desarrollo. Anteriormente trabajó en sitios web de empresas de la lista Fortune 500.

Addy es autor de varios libros, entre los que se incluyen 'Learning JavaScript Design Patterns', 'Leading Effective Engineering Teams', 'Stoic Mind' e 'Image Optimization'.

Ha impartido más de 175 charlas en todo el mundo. También en su blog, Substack y LeadDev.

Puedes conocer más del autor visitando su página oficial, su perfil en LinkedIn o siguiéndole en X donde se identifica como @addyosmani.

Ficha técnica:

TITULO: Beyond Vibe Coding: Leveraging Your Experience in the Age of AI-Assisted Coding

AUTOR: Addy Osmany

EDITORIAL: O'Reilly

AÑO: 2025

ISBN: 979-8341634756

PAGINAS: 252

Artículos de este blog relacionados

Tres formas de equidad algorítmica

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 08 Jan 2026 12:55:00 +0000

Una de las problemáticas éticas más conocidas y de las que más se habla alrededor de la inteligencia artificial es la de los sesgos algorítmicos.

En este post, que pretende ser muy breve, voy a consignar una clasificación de estos sesgos. Bueno, estrictamente hablando, no de los sesgos, sino de la equidad o de problemáticas de equidad.

Antes, algún recordatorio y aclaración.

Del error a la ética: sesgo y equidad

Un sesgo, dicho en general y de forma simplificada, es una desviación consistente del valor correcto. Últimamente, hablamos de sesgos a propósito de los algoritmos de inteligencia artificial, pero en realidad, la temática de sesgos ocupa las matemáticas y sobre todo la ingeniería desde hace muchos años.

Así, por ejemplo, los sesgos son importantes cuando estamos hablando de instrumentación y equipos de medición. Y este ámbito nos permite de forma muy simplificada ilustrar qué entendemos por un error consistente.

Vamos a imaginar el caso de una báscula, una báscula casera para pesarnos. Hablamos de un error cuando esa bascula da un valor incorrecto de nuestro peso (ya sea más o menos). Y hablamos de consistente para querer decir que siempre se produce en el mismo sentido (y en muchos casos diríamos que en la misma magnitud). Así, por ejemplo, una báscula que comete errores aleatorios (algo raro, la verdad) produce valores incorrectos pero no tiene sesgo. Sin embargo, si siempre nos añade medio Kg de más, entonces está siendo consistente: siempre añade ese medio kilo. Y eso es, precisamente, un sesgo: un error consistente.

Para eliminar este tipo de errores en instrumentación se suele recurrir a lo que se denomina la 'calibración', que en el caso sencillo de la báscula se reduce a ajustar el cero, eliminando en este caso sencillo el error y el sesgo.

En este sentido, y con esta visión ingenieril del sesgo, suelo decir en mis clases que un sesgo es un error siempre. Sin embargo, ese error técnico u operativo, no siempre es un problema ético. Se convierte en problema ético cuando ese sesgo nos hace tratar de manera diferente (lo que denominamos discriminar) a personas o colectivos, entendiendo que ese tratamiento diferencial es injusto y que perjudica a esas personas y colectivos.

Tres formas de equidad

En general no distinguimos, al menos yo no me lo he encontrado a menudo, una distinción entre tipos de equidades. Sin embargo, de manera algo inesperada, inesperada porque la fuente es un libro fundamentalmente técnico, me he encontrado en 'Azure AI Services at Scale for Cloud, Mobile, and Edge' de Simon Bisson, Mary Branscombe, Chris Hoder y Anand Raman, una identificación y descripción breve de tres formas de equidad.

Antes de mencionarlas, avisar, dadas las dificultades terminológicas en traducción, que lo que aquí estoy denominando 'equidad' se corresponde con la palabra 'fairness' en el libro.

Advertido esto, veamos ya esas tres formas o variantes de equidad. Son las siguientes:

Equidad de calidad de servicio ('quality of service fairness') que tiene que ver con que los resultados sean igual de correctos para todos los colectivos. Así, se mencionan las aplicaciones de reconocimiento facial que, por problemas de muestreo para el entrenamiento, tienden a dar peores resultados en personas de color y aún peor en mujeres de color.

Equidad de asignación ('allocation fairness') que habla de que el algoritmo ofrezca las mismas oportunidades y recursos a todas las personas y colectivos, por ejemplo, tratar a todas las personas igual en una aplicación de filtrado de currícula en un procesos de selección. . Esta es, me parece, el tipo de equidad en la que solemos pensar.

Aunque de manera menos nítida también nos habla de una equidad de representación, que busca que los colectivos estén justamente representados en profesiones, situaciones, etc (por ejemplo, cuando pensamos en quién puede ser CEO).

No me parece que esta propuesta sea una clasificación muy trabajada, ni me consta que se corresponda con una clasificación de la equidad más ampliamente admitida, pero me ha parecido interesante y no quería dejar de mencionarla.

Conclusiones

Simplemente, recordar que un sesgo es un error técnico u operativo y que se convierte en un problema ético cuando ese error conduce a tratar de manera diferente, discriminar y perjudicar, a personas o colectivos concretos. Y, dentro de esto, hemos revisado, muy brevemente, tres variantes.

Bibliografía 2025

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 31 Dec 2025 08:00:00 +0000

Un año más (ya van dieciséis con éste) cierro la publicación de posts en este blog 'Blue Chip' con el listado de lecturas del año y una siempre difícil selección donde intento de nominar a las mejores obras.

Este año he alcanzado uno de los niveles más altos, puede que el más alto, en número de lecturas con, nada más y nada menos que 65 lecturas de tecnología, 'management' o ensayo en campos más o menos afines con mi actividad profesional.

A esto se unen otros 18 libros ce carácter literario, libros de ficción o libros de ensayo completamente al margen de mi actividad profesional y que leo por placer o curiosidad.

Con ello tenemos un total de 83 libros leídos en 2025 que, aunque no estoy seguro (la verdad es que no lo he comprobado), pudiera ser un récord absoluto.

Este año las lecturas técnicas han estado muy dominadas por libros, la mayoría muy buenos, en el campo de la inteligencia artificial, fundamentalmente la inteligencia artificial generativa, pero también sobre machine learning tradicional o sobre agentes. También he leído bastante en materia de robots, y bastante también en lecturas sencillas (y la verdad que de no excesiva calidad) sobre herramientas concretas tanto del campo de la automatización, como aplicaciones basadas en inteligencia artificial.

En el campo del 'management' la verdad que la temática ha sido dispersa y acorde con necesidades o curiosidades puntuales, habiendo lecturas sobre temas tan diversos como ética, lingüística, accesibilidad, transformación digital o la realidad de las PYMEs. La verdad es que quizá el término 'management' no sea siempre del todo adecuado, puesto que ahí he incluido, para no modificar las categorías que uso habitualmente, todos los libros que tienen que ver, no sólo con la gestión empresarial propiamente dicha, sino también sobre enfoques sociales como la accesibilidad o la educación.

En ensayo aparecen temas diversos, predominando bastante la reflexión ética sobre la tecnología, pero apareciendo también la neurociencia, la comunicación y persuasión e, incluso, la teología.

Lista completa de lecturas

Y, sin más dilación, ahí va la lista de lecturas de este año, sólo con la advertencia de que los libros en materia de ensayo que no tienen relación con mi actividad profesional, se pueden encontrar en un post similar a éste en mi blog 'El cielo del gavilán', dedicado a literatura y humanidades.

Management

Cómo cautivar a tus clientes (Jonatan Loidi y Julián 'Gaita' González)
Superagency (Reid Hoffman y Greg Beato)
Empresario Libre: La Guía Definitiva para la Transformación Digital y la Automatización en la Pyme (Esther Claravalls)
La Transformación Digital de las PYMES: Estrategias y Éxitos (Cedric Yumba)
Código fuente (Bill Gates)
Las cinco mentiras de Silicon valley (Carlos Molina del Rio)
The idea factory (Jon Gertner)
The digital transformation canvas (Marc K. Peter)
AI Management System Certification According to the ISO/IEC 42001 Standard (Sid Ahmed Benraouane)
AI Act Compact (Peter Hense y Tea Mustac)
Inclusive design for accesibility (Dale Cruse y Denis Boudreau)
Dissability to possibility (S. Balaji y Pothula Sujatha)
De la EGB a la IA (Mundos Posibles)
The singularity is nearer (Ray Kurzweil)
Exponential Transformation (Salim Ismail, Francisco Palao y Michelle Lapierre)

Tecnología

The Oxford Handbook of comutational linguistics (Ruslan Mitkov (ed.))
Hands-On Large Language Models: Language Understanding and Generation (Jay Alammar y Maarten Grootendorst)
Zoho One Essentials: Mastering Zoho CRM (Karen S. Fredricks)
Prompt Engineering for Generative AI (James Phoenix y Mike Taylor)
The Complete Hugging Face Blueprint ( James Karanja Maina)
Hands-On Generative AI with Transformers and Diffusion Models (Omar Sanseviero, Pedro Cuenca, Apolinário Passos y Jonathan Whitaker)
Curso de prompts jurídicos con Iberley IA y ChatGPT (Equipo de Iberley IA)
AI Engineering (Chip Huyen)
Aplicaciones técnicas de usabilidad y accesibilidad en el entorno cliente (Xabier Ganzábal García)
Computational Linguistics: The Science of Language and Machines (Sam Claydon)
Humanoid Robotics and Neuroscience: Science, Engineering and Society (Gordon Cheng)
Inteligencia Artificial para pymes (Oiane Etxebarria Tobias e Ibon Orrantia Etxebarria)
Human-Robot Interacion. An introduction. Second edition (Christoph Bartneck et al.)
Building Agentic AI Systems (Anjanava Biswas, Wrick Talukdar, Matthew R. Scott, Dr. Alex Acero)
Applied Affective Computing (Leimin Tian et al.)
Guía práctica de inteligencia artificial para docentes innovadores (Margarita Gutiérrez)
Robotics Algorithms (Gareth Morgan Thomas)
LLM Engineer's handbook ( Paul Iusztin y Maxime Labonne)
People Analytics (Emilio Soria-Olivas y Hector Casado)
ChatGPT para RRHH (Mamen Blanco)
The MCP Handbook for Ai Agent (Evan Clarke)
Co-Intelligence (Ethan Mollick)
Guía del usuario de Microsoft 365 Copilot AI (Digital Wealth)
Beyond Vibe coding (Addy Osmani)
ARIS (Software AG): Everything Important You Need to Know! (Musab Qureshi)
Generative AI Security (Ken Huang, Yang Wang, Ben Goertzel, Yale Li, Sean Wright y Jyoti Ponnapalli)
AI Security Essentials ( Jason Dion y Alyson Laderman)
Learning DevSecOps (Steve Suehring)
Adversarial AI attacks, mitigations and defense strategies (John Sotiropoulos)
LLMOps: Managing Large Language Models in Production (Abi Aryan)
Mastering NotebookLM: The Ultimate A-Z Guide to AI-Driven Research and Productivity (Jimmy P. Noel)
Prompt Engineering for LLMs (John Berryman y Albert Ziegler)
Automatiza Como un Pro: Domina n8n, Make y Zapier y Pon Tu Negocio en Piloto Automático (Ivan Mostos)
Automatiza tu vida con Make (Mauro Martínez Domínguez)
Automatiza con N8N e IA (Manuel Schneider)
Zapier fundamentals (Logan Pierce)
Canva. Curso completo (Chema Gómez)
Data Science on AWS (Chris Fregly y Antje Barth)

Ensayo: ciencia y humanidades

Ethics in human-like robots (Kamil Mamak)
Por qué deberías tener a un filósofo en tu empresa (Pilar Llácer)
Influencia. La psicología de la persuasión (Robert B. Cialdini)
Mentes divergentes (Jenara Nerenberg)
Lingüística (Ángel Alonso-Cortés)
Decidido (Robert M. Sapolsky)
A thousand brains (Jeff Hawkins)
Iniciación a la Teología (José Morales Marín)
Esta es nuestra fe (Luis González Carvajal-Santabárbara)
La ética de los robots (Mark Coeckelbergh)
El colapso de Babel (Paolo Benanti)
Comunicative AI (Mark Coeckelbergh y David J. Gunkel)

Ranking

En cierto sentido, este año la percepción de calidad está un poco, por decirlo de alguna manera, 'extremada', existiendo muchos libros que considero buenos o muy buenos, junto con, también, un buen puñado de libros mediocres o de escasa calidad que he leído más por razones tácticas, normalmente para preparar clases o tutorías sobre temas y sobre todo herramientas específicas. A pesar de ello, hay tantos libros buenos en ms lecturas que, como siempre, la selección de los mejores es realmente difícil y bastante sujeta a subjetividad e incluso a la opinión del momento.

Dado que muchos de los libros que considero mejores de los leídos este año se mueven en temáticas muy similares en torno a inteligencia artificial generativa, he intentado dar un poco de variedad al ranking priorizando algo libros en otras temáticas para evitar una suerte de monográfico.

Con ese criterio, ésta es la propuesta de mejores lecturas de 2025:

(1) Hands-On Generative AI with Transformers and Diffusion Models

Como decía más arriba, en 2025 he leído varios libros realmente buenos sobre el campo de la inteligencia artificial, en general sobre inteligencia artificial generativa, y con un factor común, la editorial (O'Reilly) que realmente destaca por la buena selección temática pero también por su calidad, siendo su sello toda una garantía. De los varios libros de esta editorial, destaco este, en parte porque realmente puede haber sido el mejor (aunque en dura competencia con alguno más que menciono en los accésits), pero también por ser muy transversal y completo, por dar una visión abarcadora del campo de la inteligencia artificial generativa, incluyendo las dos grandes arquitecturas dominantes: los transformers y los modelos de difusión, e incluyendo la multimodalidad con tareas sobre texto, imagen, vídeo y sonido. Un excelente libro, bastante técnico pero muy bien explicado, y que es una referencia casi imprescindible para comprender, desde dentro, cómo funcionan estos modelos que han revolucionado el panorama de la inteligencia artificial.

(2) Beyond Vibe coding

Sin abandonar la editorial, ni siquiera del todo la temática, inteligencia artificial generativa, he querido destacar este libro, aparte de, claro, por sus méritos, porque ataca un tema algo diferente: la generación de código software usando la inteligencia artificial, ya sea para la creación completa de aplicaciones desde un 'prompt' hasta lo que el autor denomina la ingeniería de software asistida por inteligencia artificial. Un libro en que el autor demuestra conocer, no sólo la inteligencia artificial, sino en general la ingeniería de software, y que proporciona una visión muy interesante, pero a la vez muy realista, del trabajo con software apoyado en mayor o menor medida por inteligencia artificial.

(3) A thousand brains

Este año he leído también más de un libro sobre neurociencia. Un poco como representación de todos ellos, pero también por su interés intrínseco, destaco este 'a thousand brains', que explica la teoría del autor acerca del funcionamiento de nuestro cerebro, un funcionamiento que, según el autor, se apoya en los modelos de referencia (algo así como sistemas de coordenadas). Aunque no deja de ser una teoría, toda la explicación del funcionamiento del cerebro y el neocórtex es apasionante y de ella el autor, aparte de la propia teoría que explica, recorre ramificaciones que le llevan a temas como la consciencia o la forma de enfocar la inteligencia artificial.

Accésits

Por suerte, acompañando a los tres anteriores que he situado en el pódium, he leído al menos una veintena de libros de muy alta calidad e interés. Aunque me encantaría reconocer a todos ellos, no sería lógico, así que elijo un ramillete de obras que bien podrían haber ocupado esos puestos del pódium.

'Prompt Engineering for Generative AI' es un libro que se encuentra en el grupo de esos volúmenes excelentes de la editorial O'Reilly. En este caso, el tema es la ingeniería de instrucciones. Sin embargo, no se trata del típico enfoque de casos de uso y recomendaciones sencillas para usuarios de los chatbots generativos, sino que aporta los fundamentos técnicos y, además, está más orientado al empleo de la ingeniería de instrucciones, no por parte de usuarios generalistas sino por desarrolladores, cuando construyen soluciones basadas en inteligencia artificial y modelos generativos.

Con este otro, 'Hands-On Large Language Models' estoy siendo un poco injusto colocándolo entre los accésits, ya que podría muy bien haber sido el libro del año. Es de orientación y calidad muy similar al que he destacado como mejor libro del año. Si lo pongo en los accésits, y ni siquiera el primero de ellos, es por no ser repetitivo. De nuevo, se trata de un libro técnico, de muy alta calidad y si no le he dado el primer puesto es porque es un poco más enfocado (si se quiere un poco menos general) que 'Hands-On Generative AI with Transformers and Diffusion Models'. Pero se trata de un libro excelente que ha marcado mi lectura de este año porque, además, lo leí a principios del año y me gustó tanto que me impulsó a seguir buscando libros de esta editorial.

Con 'Influencia', cambiamos de tercio. Se trata de un clásico sobre las motivaciones de los humanos y el uso para la persuasión, en todos los campos, pero sobre todo comunicación comercial. Debo de ser sincero: estrictamente hablando, no es un libro que, como tal libro, como experiencia lectora, me haya gustado tanto. Creo que el autor se alarga en exceso y le falta un puntito de brillantez. Sin embargo, los conceptos que explica sobre la psicología de la persuasión, sí me parecen muy interesantes y, de hecho, me he acordado de algunos de estos principios a lo largo del año y en discursos que he hecho, por ejemplo, en mi podcast 'Divergencias'. Así que, más por el contenido, que por la forma de contarlo, me ha parecido que debía destacarlo.

Una caso especial es el de este 'Las cinco mentiras de Silicon Valley', un libro sobre emprendimiento y creación de empresas contado de forma directa, con base absoluta en la experiencia y evitando, e incluso criticando, algunos de los mitos sobre emprendimientos, unos mitos que el autor concentra en esas cinco mentiras. Y digo que es especial porque, más allá del interés intrínseco, leí este libro tras conocer directamente al autor (bueno, a través de las pantallas) por su participación como invitado en el podcast 'Código abierto' en el que colaboro.

'The idea factory' fue una de mis primeras lecturas del año 2025 (de hecho fue un regalo de Reyes). De nuevo, como he hecho en los dos anteriores, cambio completamente de temática. Este libro es una narración de la historia de los míticos 'Bell Labs' que fueran una referencia absoluta en materia de tecnología y, sobre todo, de innovación hace unas pocas décadas, una especie de filial de AT&T donde se inventó, entre otras cosas, el transistor, elemento nuclear de la microelectrónica y que proporciona la base hardware de toda la revolución digital. Un libro muy centrado en los grandes personajes que formaron parte de su plantilla y en las grandes aportaciones científicas y técnicas que de allí salieron. Un libro sobre una suerte de arqueología científico-técnica y que, en algunos momentos, me ha llenado de una extraña nostalgia, porque los 'Bell Labs' eran una referencia absoluta cuando inicié mi carrera profesional y, no en vano, fueron el modelo en que se inspiró la inolvidable 'Telefónica Investigación y Desarrollo' donde trabajé durante más de doce años.

El caso 'De la EGB a la IA'

Y, aunque no deje de ser un poco, o un mucho, el 'arrimar el ascua a mi sardina', no puedo cerrar la revisión bibliográfica de 2025 si mencionar el último libro en que he participado como co-autor junto con una docena de compañeros (ex-compañeros en realidad) de Telefónica Empresas y del blog 'A un Clic de las TIC'. 'De la EGB a la IA' es un libro que, aunque con la tecnología como telón de fondo, en lo que se centra es, en una visión multi-perspectiva, del impacto y consecuencias que tiene esa tecnología, muy especialmente la inteligencia artificial, en el empleo, la educación, etc, con bastante foco en las consecuencias para las personas jóvenes. Mi capítulo se centra en los aspectos de ética y, sobre todo, responsabilidad, que acompañan a la aplicación de la inteligencia artificial y al auge de los robots.

De cara a 2026

Para este 2026 que en seguida comenzamos, la idea, al menos en los primeros meses, es continuar con los grandes temas que han marcado 2025 e incluso los años inmediatamente anteriores.

Así, preveo seguir ahondando en inteligencia artificial, tanto por profundizar en su conocimiento como por ponerme al día de avances que, sin duda, se producirán en los próximos 365 días.

También quisiera seguir leyendo sobre neurociencia e intentando ponerla en relación con la inteligencia artificial.

Por supuesto, quiero extender mi conocimiento en robótica, aunque en esta materia realmente hay mucho menos libro publicado. En especial, buscaré, aunque hay poca oferta, leer alguna obra que explique los robots humanoides desde el punto de vista técnico y buscando objetividad.

También continuaré leyendo libros sobre filosofía, ética, y responsabilidad, dentro del campo de la ética de la tecnología con foco en las derivadas de la inteligencia artificial y la robótica.

Pero, claro, esas son las intenciones iniciales. A lo largo del año pueden surgir temas diferentes o 'cisnes negros' en forma de temas o autores inesperados pero que me han llamado la atención o que se han 'puesto de moda' en ese 2026.

Lo que quisiera, aunque no es fácil, es continuar con un volumen de lecturas tan alto como el de este año y, seguir encontrando joyas de conocimiento y calidad.

Dios mediante, lo revisaré en este mismo blog y en esta mismo día del año.

Artículos de este blog relacionados

Mis #TEDTalks de 2025

noreply@blogger.com (Ignacio G.R: Gavilán) — Tue, 30 Dec 2025 08:00:00 +0000

Y, como llevo haciendo ya desde hace doce años, uno de los últimos posts de este blog, normalmente el penúltimo, lo publico el 30 de Diciembre recogiendo y comentando brevemente las charlas TED que he escuchado este año.

Y es que si, allá por Noviembre de 2011, adopté la costumbre de, cada fin de semana, con unas pequeñas excepciones en vacaciones, escuchar un TED Talk el fin de semana, normalmente el sábado.

Este año 2025 he escuchado, o he visualizado, 47 charlas, para alcanzar un total de, hasta la fecha, 711 charlas.

En las charlas de este año dominan, como en el fondo tampoco es sorprendente, las que tienen que ver con inteligencia artificial. También aparecen con cierta frecuencia charlas relacionadas con neurociencia y luego un salpicón de temas diversos.

No abundan este año los personajes muy reconocidos aunque sí desfilan por mi listado personas como Sam Altman, Eric Schmidt, Lawrence Lessig o Steve Pinker. Pero, aunque siempre me interesan los grandes personajes o los grandes speakers, últimamente selecciono más atendiendo al tema de la charla que al ponente y siguiendo en buena medida las charlas que sugiere la propia TED en su página.

Las #TEDTalks de 2025

Y, sin más, aquí va el listado de charlas de 2025:

Mirando hacia 2026

¿Y de cara a 2026?

Pues no creo que cambien mucho las cosas. Seguiré visitando, seguro, las charlas que tengan que ver con inteligencia artificial y robótica; seguramente continuarán apareciendo charlas sobre neurociencia o temas científicos y, cualquier otro tema, quizá sobre ética, quizá sobre geo-estrategia, quizá grandes retos de la humanidad.

Iremos viendo.

De momento, ya tengo seleccionadas más de 20 charlas que alimentarán mi curiosidad, hasta Mayo de 2026. Y, de ahí, en adelante.

El 30 de Diciembre de 2026, revisamos esas nuevas TED Talks.