Algunas limitaciones en los modelos razonadores... de momento

Desde hace creo que algo más de un año, dentro del movidito mundo de la inteligencia artificial generativa, ocupan un lugar muy importante un tipo de modelos de lenguaje denominados modelos razonadores o LRM ('Large Reasoning Models').

¿Qué tal funcionan?

Desde luego, la experiencia como usuario es que, sin alcanzar la perfección, mejoran a sus predecesores no razonadores en una buena variedad de casos (aunque quizá ralentizando y aportando en ocasiones respuestas demasiado largas). Pero ¿es eso objetivamente cierto?

En este post traigo un muy breve resumen del paper titulado 'The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity' en que un equipo de Apple analiza tres importantes modelos razonadores, detectando algunas limitaciones y llegando a interesantes resultados.

Modelos razonadores

Sin entrar en mucho detalle (probablemente dentro de no mucho les dedique varios posts) podemos decir que un modelo razonador es una variante de un modelo de lenguaje o un modelo frontera que está preparado para tratar problemas que requieran cierta lógica o cierta estrategia de resolución. 

En el caso de los modelos 'normales', ante una petición del usuario, fundamentalmente contestan con 'lo que saben' digamos que directamente. Pero el caso de los modelos razonadores, para satisfacer una petición del usuario, primero establecen un plan de acción (con frecuencia basado en la aplicación de  técnicas como el CoT, '(Chain-Of-Thought'), un plan que luego ejecutan e incluso revisan en función del resultado de los pasos intermedios.

El planteamiento del experimento

El experimento realizado por el equipo de Apple pretendía ver, fundamentalmente, cómo reaccionaban estos modelos a medida que se incrementaba la complejidad del problema.

Entre los modelos razonadores eligen algunos de los más importantes en el momento de hacer las pruebas y los suelen comparar con la versión equivalente de modelo sin razonamiento. Así, por ejemplo, en el caso de Anthropic utilizan Sonnet 3.7 (tanto versión 'thinking' como sin razonamiento). En el caso de DeepSeek ponen a prueba DeepSek-R1 (razonador) frente a DeepSeek V3 (no razonador). De OpenAI usan o3-mini (razonador).

A los modelos elegidos los someten a problemas de creciente complejidad, basados en cuatro tipos de juegos o problemas a resolver:

• Juego 'Torres de Hanoi'
• Juego 'Checker jumping'
• Juego Cruzar el río ('river crossing')
• Juego de bloques:  

Se trata de juegos seleccionados intencionadamente para que aporten diferencias en cuanto a complejidad de la planificación, profundidad composicional, etc.

Sobre estos juegos se van proponiendo escenarios de creciente complejidad.

Los resultados y las limitaciones de los modelos

Lo que creo más interesante, y hasta cierto punto sorprendente es el diferente funcionamiento según lo que los autores denominan regímenes de complejidad ('complexity regimes'). 

Y lo que encuentran es que, para complejidades bajas, los resultados de utilizar un modelo razonador y no razonador son similares e, incluso, en ocasiones es mejor la respuesta del modelo no razonador.

Para complejidades medias, los modelos razonadores exhiben. como cabía esperar, su ventaja a veces de forma muy clara, frente a los no razonadores.

Sin embargo, lo más curioso es que, ante complejidades altas, ambos tipos de modelos, razonadores y no razonadores, sufren un colapso en su resultado llegando a una precisión nula. Es cierto que los modelos razonadores suelen 'tardar' más en colapsar, pero lo acaban haciendo.

También observan que ante problemas simples, los modelos razonadores tienden a 'pensar de más' ('overthinking'), lo que lleva a una baja eficiencia.

También detectan algún comportamiento paradójico en situaciones en que hay que realizar un cálculo exacto ('exact computaton') para los que el modelo dispondría de algoritmos muy directos y que, sin embargo, no  utiliza, perdiendo eficiencia y precisión.

Adicionalmente, cuestionan algunos de los paradigmas actuales de evaluación de modelos razonadores. Por un lado afirman que las formas habituales de evaluación que se basan 'benchmarks' matemáticos y en su lugar proponen, como hemos mencionado, otro tipo de problemas que permiten variar la complejidad del problema. 

En este aspecto más procedimental también proponen no centrarse sólo en el resultado final, sino también evaluar trazas intermedias.

De momento

Y esos son, muy brevemente, los resultados que obtienen. Son muy interesantes pero ¿siguen siendo válidos? 

Apostaría a que, al menos parcialmente, si, pero el paper que comento se publicó en Noviembre de 2025, es decir, unos nueve meses antes de cuanto escribo este post. En muchas otras disciplinas humanas nueves meses son muy poco tiempo, pero inteligencia artificial generativa es bastante y, después de este estudio (y, sobre todo, después de los modelos que utiliza) han aparecido nuevos y se supone que mejores modelos. 

¿Qué pasaría si se sometiese a esas mismas pruebas al modelo Fable de Anthropic o al flamante GPT6-Astra de OpenAI? Asumo que, en general, se mejoraría la precisión de los resultados pero ¿Qué pasaría con la eficiencia? Y, sobre todo ¿Se mantendría ese patrón ante los regímenes de complejidad muy alta y el colapso ante problemas muy complejos?

Conclusiones

He resumido bastante el resultado de una comparativa realizada por un equipo de Apple sobre modelos razonadores y comparándolo con no razonadores.

Los resultados muestran algún comportamiento paradójico y, sobre todo, un colapso ante problemas de muy alta complejidad. 

¿Se mantienen cualitativamente esas paradojas y ese colapso en los últimos modelos? Sinceramente, en el momento de escribir este post no lo sé, pero intuyo que los modelos habrán mejorado, puede que sustancialmente, pero apostaría a que alguna limitación se mantiene todavía en cierta medida en los modelos más actuales.

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

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

Tokens, embeddings y algunos trucos de magia

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.

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

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

• Grietas en el determinismo de los modelos generativos: limitaciones, errores e imprevistos
• Determinismo y el gobierno de la aleatoriedad en grandes modelos de lenguaje
• Sobre el determinismo y los modelos generativos
• Los algoritmos de Inteligencia Artificial sí saben explicarse

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

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

• Determinismo y el gobierno de la aleatoriedad en grandes modelos de lenguaje
• Sobre el determinismo y los modelos generativos
• Los algoritmos de Inteligencia Artificial sí saben explicarse

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

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

• Sobre el determinismo y los modelos generativos
• Los algoritmos de Inteligencia Artificial sí saben explicarse

Conociendo el Vibe coding y más con Addy Osmani

'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

• Lo que no reluce en el 'Vibe coding': retos, limitaciones y equilibrios
• Doce reglas de oro del 'Vibe coding'
• Conociendo el 'Vibe coding'