Actualmente hay un interés enorme en revolucionar el corazón de los modelos de lenguaje: el famoso transformer. Hemos hablado de cambios en la atención e incluso en el tokenizador. Vamos a profundizar en una idea para reducir el número de iteraciones para procesar un texto en un trasformer:  CALM, una propuesta para agrupar múltiples tokens en un solo vector.

El Corazón de CALM: El Autoencoder

Lo primero que el equipo detrás de esta idea tuvo que demostrar es si esto era siquiera posible: ¿Podríamos tomar varios tokens de texto, convertirlos en un único vector, y luego ser capaces de revertir ese proceso?

La respuesta es sí, y lo lograron utilizando un autoencoder. El encoder toma un puñado de tokens y los condensa en un vector abstracto que los representa a todos. El decoder toma ese vector y es capaz de sacar el texto original.

El Desafío: Que el Transformer procese vectores en lugar de tokens

A primera vista, el nuevo flujo parecía simple: 

Pero la realidad es un poco más compleja.

El problema es que los Transformers estándar no responden directamente con el siguiente token. Responden con un conjunto de valores que, al aplicar la función Softmax, se convierten en probabilidades para elegir el siguiente token. Ahora, con CALM, no tenemos tokens individuales al final, sino un vector abstracto que agrupa varios de ellos. Simplemente no podemos aplicar Softmax y elegir el siguiente elemento de texto.

Además, perdimos algo vital en el proceso: la temperatura.

La temperatura es ese parámetro que nos permite controlar cuán diversa o «imaginativa» será la respuesta del modelo. Aunque parezca un detalle menor, sin la temperatura adecuada, ciertos procesos cruciales, como el razonamiento en los modelos, fallan y el sistema puede entrar en un bucle sin salida.

Necesitábamos una solución que pudiera interpretar la salida abstracta del transformer y, a la vez, devolvernos el control sobre la temperatura.

La Solución Ganadora: El Energy Transformer

El equipo exploró tres posibles soluciones: un modelo de difusión, flow matching y un Energy Transformer.

Finalmente, se eligió el Energy Transformer. ¿Por qué? Principalmente por su rendimiento. Es poco costoso de entrenar y, lo más importante, es capaz de generar la respuesta completa en una sola iteración.

Y en cuanto a la temperatura perdida, estas soluciones permiten simular ese comportamiento añadiendo ruido a la entrada. Así recuperamos el control sobre la diversidad del modelo.

Una vez que el Energy Transformer produce su respuesta, se la pasamos al decoder y ¡voilà! Hemos generado múltiples tokens con una sola pasada.

¿Cuánta Velocidad Ganamos?

Ahora, el sistema es verdaderamente multitoken. En el paper, los modelos de ejemplo lograron producir cuatro tokens por vector. Pero el equipo cree que, con modelos mucho más grandes, se podría alcanzar hasta ocho tokens por vector.

Ojo, esto no significa que sea ocho veces más rápido, ya que añadimos pasos adicionales (el encoder y el decoder) que no existen en el transformer normal. Sin embargo, la mejora es más que interesante, y parece que cuanto mayor es el modelo, mayor es la mejora. Esto tiene sentido, ya que en un modelo pequeño el encoder y el decoder representan una parte importante de los cálculos, mientras que en un modelo gigante estos pasos se vuelven insignificantes.

Es cierto que estos modelos CALM son más grandes en términos de pesos, pero esto se debe a que ahora contienen, además del transformer, todos los pesos de los componentes que lo rodean.

Conclusiones

¿Es CALM la solución definitiva a todos nuestros problemas de rendimiento? No lo sé. Pero sin duda, es una idea muy interesante. Me parece una aproximación mucho más robusta que otras que hemos visto, como la de convertir el documento en una imagen para procesar tokens visuales.

Lo que está claro es que el concepto de token tal como lo conocemos necesita una revisión profunda. Hay maneras más eficientes de representar la información que requieren menos iteraciones del modelo.

Muchas empresas de IA nos venden la promesa de trabajos realizados de forma automática, sin ninguna intervención humana. Pero, ¿y si el uso masivo de la IA estuviera produciendo justo el efecto contrario? ¿Y si nos estuviera haciendo cada vez más dependientes de los trabajadores humanos?

Para explorar esta idea, abandonamos por un momento los papers de tecnología recientes y nos remontamos a un paper de sociología de 1983 que habla sobre la automatización de procesos industriales. Lo fascinante es cómo podemos adaptar su lógica al caso moderno de la Inteligencia Artificial, especialmente en el mundo de la creación de software, que es donde yo me muevo.

La Conversión de Expertos en «Vigilantes»

La idea central es que las máquinas —en nuestro caso, la IA— no pueden reemplazar completamente al ser humano. Necesitan que un humano las supervise y las corrija cuando se equivoquen. Esto significa que estamos convirtiendo a profesionales de gran experiencia y valor en vigilantes de la IA.

Pero no cualquiera sirve de «vigilante», para poder desempeñar esta labor de corrector, debes ser una persona con mucha experiencia en ese trabajo. El resultado es que coges a profesionales altamente cualificados y los pones a trabajar revisando la salida de una inteligencia artificial.

Este cambio de rol tiene consecuencias nefastas:

1. Descalificación y Estrés: El trabajador se aburre, lo cual puede provocar pérdida de motivación y estrés. Siente que su trabajo ha sido descalificado, que le han bajado de nivel, lo cual afecta su autoestima y carrera profesional.

2. Responsabilidad Disparada: Lo peor es que, aunque el trabajo parece menos cualificado, la responsabilidad se dispara. Antes, un desarrollo lo hacía un equipo de personas que actuaban intentando reducir errores. Ahora, la responsabilidad de que ese software funcione correctamente recae en una sola persona o un pequeño grupo de ellas.

El Ser Humano como Cuello de Botella

Aquí es donde encontramos la ironía más grande. La IA es capaz de generar toneladas de líneas de código por día, pero los seres humanos simplemente no somos capaces de revisar tantas líneas al día.

Los humanos nos convertimos en el cuello de botella del proceso creativo de la IA. Intentando prescindir de nosotros, lo que realmente estamos haciendo es eliminarnos de los procesos creativos y divertidos para colocarnos en un puesto que requiere mucho conocimiento, que es estresante, muy aburrido (revisar miles de líneas de código) y, además, con una responsabilidad mucho mayor que antes.

De hecho, posiblemente el salario termine siendo la parte más cara del proceso de desarrollo.

El paper lo resume de forma brillante con una frase: «Cuanto más avanzado es un sistema de control más crítica puede ser la contribución del operador humano.»

La Solución: Integración Creativa

Sé que existe la posibilidad de que en unos años la IA será capaz de realizar todo este trabajo sin necesidad de ningún humano, pero ahora mismo no parece que esto vaya a ocurrir pronto. Soy bastante crítico con la idea de que la IA generativa actual vaya a conseguir ser completamente independiente de los seres humanos.

La autora del paper, Lin Beainbridge, propone una solución viable: diseñar los procesos productivos para que el ser humano esté integrado en ellos y tenga una función creativa. No debe estar simplemente al final de la línea productiva viendo si el código que sale es correcto.

Mi opinión personal es clara y la comparto plenamente: la IA tiene que ser una herramienta para los humanos, no un sustituto de humanos. Aunque estoy seguro de que muchas empresas no comparten mi visión.

Estamos en una era donde se anuncia que los Modelos de Lenguaje (LLMs) alcanzarán la AGI (Inteligencia Artificial General) o incluso que reemplazarán al ser humano. Sin embargo, a pesar de su impresionante inteligencia, estos modelos enfrentan un problema fundamental: son incapaces de recordar nada de sus conversaciones.

Da igual lo inteligente que parezca ser un modelo; si cierras la conversación, la próxima vez que la abras, todo lo que dijiste antes se habrá olvidado.

El Problema de Aprender Cosas Nuevas

Sé que algunos pensaréis: «A mí Chat GPT me llama por mi nombre, algo deben recordar». Esta es una simulación de familiaridad que vamos a desgranar.

En principio, un modelo de lenguaje sí puede aprender cosas nuevas. El ejemplo más claro es el Fine-tuning. El problema es la escala: el Fine-tuning necesita una gran cantidad de ejemplos para que el modelo memorice.

No es un mecanismo útil para el uso cotidiano si queremos que recuerde nuestro nombre una sola vez; no podemos repetírselo miles de veces para que lo memorice. Entonces, ¿cómo resolvemos la falta de memoria a corto y medio plazo?

Mecanismo Básico de Memoria: El Bloc de Notas

Para dotar al modelo de una forma de recordar, se le proporciona un mecanismo simple que actúa como una «libretita» o un bloc de notas.

El Proceso es el siguiente:

1. Una vez finalizada una conversación, se le pide al modelo de lenguaje que la revise y extraiga los elementos que considere importantes.
2. Alternativamente, tú mismo puedes indicar qué elementos son cruciales (como el nombre, la profesión o los gustos del usuario).
3. Con esta información, se crean pequeñas notas. Estas notas deben ser breves porque la idea es inyectar este bloque de texto en el contexto de cada nueva conversación.

De esta manera, el modelo simula ser capaz de recordar tu nombre, tu profesión o tus gustos. Este truco es efectivo para hacer que un chatbot con el que hablas habitualmente simule cierta familiaridad contigo.

Sin embargo, esto no es suficiente para aplicaciones más serias donde se requiere recordar una mayor cantidad de datos y es vital que se recuerden con precisión.

RAG: Memoria de Precisión

Para manejar un volumen de datos superior con mayor precisión, existe una solución sencilla y más robusta:

1. La conversación que has tenido con el modelo se resume.
2. Ese resumen se guarda en una base de conocimiento.
3. Accedemos a esta base de conocimiento utilizando la técnica RAG (Retrieval-Augmented Generation).

Cuando estás hablando con tu modelo de lenguaje favorito, este ahora comprueba si existe información extra en esa base de conocimiento relativa a la pregunta que acabas de hacer, para incluirla en el contexto.

Lo ventajoso de este enfoque es que podemos combinar ambos tipos de memoria (el bloc de notas y RAG).

La Memoria para la Autorreflexión (El Paper de Google)

Si ya tenemos una memoria funcional, surge la siguiente pregunta: ¿Por qué usarla solo para recordar cosas del usuario?. ¿Por qué el modelo de lenguaje no puede usarla para recordar cosas de sí mismo? En concreto, ¿Por qué no puede recordar la forma en que ha enfrentado diversos problemas?.
Aquí es donde entra en juego el interesante paper de Google. El sistema se centra en tomar un agente dedicado a cumplir tareas en Internet.

El Mecanismo de Aprendizaje y Reflexión:

1. Cada vez que el agente termina de cumplir una tarea, se evalúa si la ha completado correctamente o no, utilizando un modelo de lenguaje como juez.
2. Finalmente, se resumen las acciones tomadas por el agente y el resultado obtenido.
3. Esta información se utiliza como memoria para la próxima vez que se le pida una consulta similar (para ello usa un RAG)

Básicamente, el sistema utiliza la nueva consulta para realizar una búsqueda por similitud semántica (un RAG) en todas sus entradas de memoria. Recupera las entradas que más se parezcan al problema actual y elige las ‘n’ mejores para pasárselas al contexto del modelo de lenguaje.

Al pasarle a un modelo de lenguaje un listado de ideas que han funcionado y de ideas que no han funcionado, le estás proporcionando una pista importantísima sobre cómo cumplir su tarea.

Este sistema ha logrado mejorar los resultados del modelo de lenguaje en los benchmark. Además, han integrado el sistema con el concepto de Test Time Scaling, es decir, dedicar más tiempo a reflexionar sobre un problema. Esto se logra integrando dos estrategias:

1. La búsqueda en paralelo de diferentes soluciones.
2. El refinamiento secuencial de una misma solución (mejorándola paso a paso).

Todo esto puede sonar complejo, pero la idea central es sencilla: se busca crear una entrada de memoria que contenga los planes que funcionan y no funcionan, resumidos y esquematizados, para poder pasárselos al modelo o agente cada vez que se le encargue una tarea parecida.

El Dilema de la Memoria: ¿Cuándo Olvidar?

No todo es positivo. Ahora que podemos recordar cosas, surge un problema fundamental: ¿Cuándo deberíamos olvidarlas?.

Imaginemos un agente que realiza tareas de compra en una web. Con el tiempo, acumula muchísimas memorias. Si el dueño de la web decide cambiar su diseño, lo que antes era un buen plan ahora puede llevar al fracaso del intento de compra.

La ironía es que, para que el sistema de memoria funcione correctamente, tendremos que implementar algún mecanismo de olvido y decidir cuándo aplicarlo. Es un reto que, con suerte, exploraremos en profundidad más adelante.

Vamos a profundizar en el mayor problema de seguridad que tienen los modelos de lenguaje. Pero antes de centrarnos en los LLM, hablemos de dos problemas históricos que comparten la misma raíz.

El primer ejemplo se remonta a la era de las líneas de teléfono analógicas. Las líneas de voz y los comandos del sistema (tonos utilizados para la comunicación entre centralitas) compartían exactamente la misma línea. Esto llevó a la invención de aparatos conocidos como BlueBox, que enviaban comandos desde el teléfono del usuario, permitiendo, por ejemplo, detener la tarificación de la llamada y, esencialmente, llamar gratis.

El segundo problema se encuentra en la arquitectura de los primeros PCs. Debido a que la memoria RAM era muy escasa y los sistemas requerían flexibilidad, se compartía la misma memoria para el código ejecutable y los datos. Cuando los datos crecían demasiado, podían sobreescribir el código ejecutable, lo que conocemos como un ataque de desbordamiento. Si el atacante tenía control sobre los datos entrantes, podía sobreescribir el código ejecutable con su propio código malicioso, tomando así el control de la ejecución del programa.

En ambos casos, el problema es idéntico: se mezclaron los comandos del sistema con los datos del usuario.

Volviendo a los modelos de lenguaje, cuando se crearon los modelos de lenguaje que pueden chatear y seguir instrucciones, acabaron mezclando el prompt de sistema, prompt de usuario, datos externos y respuestas del modelo en un único texto.. Un modelo que sigue instrucciones opera básicamente con un sistema de etiquetas de texto que indican la instrucción del sistema, la instrucción del usuario y la respuesta del modelo de lenguaje, iterando este proceso en una conversación. La razón por la que los modelos de lenguaje funcionan así se debe a su origen: inicialmente fueron diseñados para completar texto. La capacidad de conversar y seguir instrucciones se descubrió posteriormente, añadiendo etiquetas.

Esta estructura es lo que facilita técnicas como el jailbreak, donde las instrucciones del usuario logran convencer al modelo de lenguaje para que ignore las instrucciones del sistema.

Ahora, consideremos cómo introducimos datos externos a un modelo de lenguaje. Lo hacemos metiéndolos dentro del prompt de usuario. Esto significa que, esencialmente, cualquier dato externo es interpretado como instrucciones del usuario.

Si bien al principio esto podía parecer una mera curiosidad, una forma de lograr que el modelo de lenguaje dijera algo prohibido, la situación se volvió seria cuando los agentes de IA entraron en juego.

Ahora, tenemos Inteligencias Artificiales que procesan documentos, leen páginas web, y manejan archivos y datos que provienen de fuentes externas. Estos datos pueden contener instrucciones ocultas para las IA. Esto ya está ocurriendo: se han detectado currículums u papers que llevan mensajes ocultos para las IA que los procesan, ya sea haciéndolos muy pequeños o poniéndolos en color blanco sobre fondo blanco.

Estamos viendo fenómenos como el SEO para inteligencias artificiales, cuyo objetivo es engañar a los modelos de lenguaje para que citen tu página web.

Incluso se han detectado ataques como Shadow Leak, que envía un correo electrónico con texto en color blanco (invisible para el humano). Si una IA procesa este correo, el texto le da instrucciones, usando la funcionalidad de Tool Calling, para conectarse a una URL específica. Estamos presenciando una transición de la ingeniería social a la ingeniería artificial.

El objetivo de estos ataques no es solo engañar a un agente para que elija tus datos o tu web por encima de otros para promoción o conseguir clientes. Existe también el lado opuesto: las empresas de IA han generado un gran descontento al usar datos para el entrenamiento sin pedir permiso. Los medios de comunicación, por ejemplo, que no están contentos con este tema, podrían estar muy interesados en incluir instrucciones en sus textos para confundir a los modelos de lenguaje.

De hecho, la razón por la que probablemente no vemos más pruebas de estos ataques en muchas webs es porque existe el temor a que incluir textos extraños pueda ser penalizado por el SEO de Google.

Hay pocas formas de mitigar este problema y ninguna funciona al 100%:

1. Consumir datos solo de fuentes consideradas seguras.

2. Limpiar los datos de cualquier contenido que pueda considerarse una amenaza, buscando etiquetas o patrones conocidos que se utilicen en ataques.

3. Uso de modelos de lenguaje «guardianes». Estos modelos están diseñados para clasificar el texto que se va a procesar y alertar si contiene contenido no deseado (como violencia o, específicamente, patrones de Jailbreak).

El uso de estos modelos guardianes puede ser una línea extra de defensa. Sin embargo, al igual que sucede con el problema de las alucinaciones, no hay una solución perfecta. Este es un problema inherente a la arquitectura de los propios modelos.

En mi opinión, este tema se va a popularizar mucho en los próximos meses, ya que habrá mucha gente interesada en manipular los modelos de lenguaje, ya sea para conseguir un favor o para entorpecer su trabajo.

En otro post comentaba que los modelos de atención híbridos (atención clásica combinada con atención lineal) parecían ser el futuro. Bueno, pocos días después, Deepseek nos sorprendió lanzando el modelo Deepseek 3.2, que utiliza un mecanismo de coste cuadrático DSA que compite de tú a tú con los modelos lineales.

De hecho, el mecanismo de atención es la única diferencia que existe entre Deepseek 3.2 y su predecesor, Deepseek 3.1.

¿Qué es DSA (Deepseek Sparse Attention)?

La gran pregunta es: ¿Cómo es posible que un mecanismo de coste cuadrático pueda competir con modelos lineales? El problema principal de los cuadráticos es que su coste computacional crece rápidamente.

La respuesta está en la implementación inteligente de DSA (Deepseek Sparse Attention). Aunque tiene una parte cuadrática, han logrado hacerla tan rápida que el impacto general no es tan grande.

El mecanismo de DSA consta de tres pasos:

• Paso 1: Creación de un Índice de Importancia (Coste Cuadrático): Se crea un índice que mide qué tan importante es cada token para los demás tokens. Aunque esto les recordará a la atención clásica, no es atención clásica; es mucho más rápido de calcular. Es la única parte que crece de forma cuadrática con el número de tokens.

• Paso 2: Selección de Tokens: Se calculan los N tokens más importantes según el valor del índice calculado en el primer paso.

• Paso 3: Aplicación de Atención Clásica (Coste Constante): La atención clásica de toda la vida, con su coste computacional de N² se aplica solo sobre los tokens seleccionados. Lo genial es que el coste de este paso siempre será N², es decir, constante, sin importar el tamaño del texto que esté procesando el modelo de lenguaje.

Deepseek 3.2 crece mucho más lento que Deepseek 3.1. Esto sucede porque solamente el Paso 1 (la parte menos costosa computacionalmente) crece con el contexto.

Es cierto que, para contextos muy pequeños, Deepseek 3.2 tiene un rendimiento peor que 3.1, pero en cuanto el contexto comienza a crecer, lo compensa con creces.

Está la duda de si empeora la calidad de la salidad del modelo. Pues no. Si observan la comparativa de resultados de Deepseek 3.1 y 3.2 en varias pruebas, se ve que no hay una gran diferencia:

Deepseek lo ha vuelto a hacer: ha traído algo novedoso que posiblemente introducirá cambios importantes en los modelos de lenguaje.

Deepseek 3.2 tiene un tamaño de contexto de 160.000 tokens. Personalmente, me queda la duda de cómo se comportaŕa en contexto más grandes. Supongo que pronto lo veremos ya que hay un detalle crucial: para aplicar este tipo de atención, no hace falta entrenar el modelo de lenguaje desde cero. Puedes hacer fine tuning de un modelo ya existente y adaptarlo para que use DSA.

Recientemente, hemos visto cómo grandes empresas como IBM, Nvidia o Qwen han comenzado a lanzar modelos basados en una nueva arquitectura de Transformer. Uno de los cambios más revolucionarios de esta arquitectura se encuentra en su núcleo: el mecanismo de atención. En esta entrada, vamos a desglosar qué es este cambio, por qué es tan importante y qué beneficios nos trae.

El Problema de la Atención Clásica en los Transformers

Para entender la innovación, primero debemos recordar cómo funciona la atención clásica en un modelo de lenguaje. De forma sencilla, su función es calcular la relación que existe entre cada palabra (o token) de un texto. Por ejemplo, en la frase «El perro ladró al gato», la atención ayuda al modelo a entender que «ladró» tiene una relación mucho más fuerte con «perro» que con «gato». Esto se representa internamente como una matriz de valores numéricos que mide la afinidad entre todos los tokens.

Aunque este mecanismo es muy efectivo, tiene dos grandes problemas, ambos relacionados con el mismo factor:

1. Consumo de Memoria: La matriz de atención crece de forma cuadrática a medida que añadimos más tokens. Si tenemos 3 tokens, necesitamos 9 valores; con 4 tokens, 16; con 5, 25, y así sucesivamente. Esto dispara el consumo de memoria.

2. Carga Computacional: No solo se trata de almacenar estas realciones, sino de operar con ellas. A más tokes, más relaciones y más operaciones, lo que incrementa enormemente la carga de cálculo.

Hay que tener en cuenta que un modelo no tiene un solo mecanismo de atención, sino varios trabajando en paralelo.

La Alternativa: La Atención Lineal y su «Gran» Defecto

Aquí es donde entra en juego la atención lineal, una solución que ya existía en modelos como Mamba. A diferencia de la atención clásica, la atención lineal procesa los tokens de forma secuencial, uno por uno, utilizando un conjunto de estados de tamaño fijo que se va actualizando.

Las ventajas son enormes:

• El cálculo crece de forma lineal con el número de tokens, no exponencial.

• El uso de memoria es constante y no aumenta, sin importar la longitud del texto.

• Necesita menos datos para aprender4

Sin embargo, como suele pasar en ingeniería, no se puede ganar algo sin perder otra cosa. El gran inconveniente de la atención lineal es su dificultad para recordar las palabras exactas que ha procesado. Mientras que es buena prediciendo la siguiente palabra, falla cuando necesita recuperar fragmentos específicos del texto que está analizando. Esto se debe a que la relación entre tokens se representa de una forma más «borrosa» en su estado interno.

La Solución: La Atención Híbrida

Entonces, ¿cómo podemos combinar lo mejor de ambos mundos? La respuesta es la Atención Híbrida4.

La idea es simple pero brillante. Recordad que los modelos tienen múltiples mecanismos de atención funcionando en paralelo. Nada nos obliga a que todos sean del mismo tipo. La atención híbrida combina mecanismos de atención clásica y atención lineal dentro del mismo modelo de lenguaje.

Un gran ejemplo es el modelo Qwen 3 Next, donde:

• El 25% de los mecanismos de atención son clásicos

• El 75% son lineales

Gracias a este enfoque, se consiguen claras mejoras en el rendimiento y, además, se acelera el aprendizaje, ya que se requiere una menor cantidad de datos para alcanzar la misma calidad.

Estamos ante una evolución apasionante que no solo mejora el rendimiento de los modelos de lenguaje, sino también la eficiencia de su entrenamiento. En un próximo vídeo y entrada del blog, exploraremos más a fondo estas nuevas arquitecturas y los demás cambios que traen consigo.

Desde la irrupción de los modelos de lenguaje (LLM), la idea de integrarlos con los robots ha sido una constante. ¿Por qué? Porque los LLM destacan en algo que la robótica tradicional no ha logrado dominar: la comprensión del lenguaje humano y la planificación de tareas en un contexto del mundo real. A esto último se le conoce como «modelos del mundo», y es un conocimiento crucial que ha sido increíblemente complejo de integrar en la programación robótica.

La promesa parecía simple: enchufamos un modelo de lenguaje a un robot, ¡y listo! Sin embargo, la realidad es más complicada. La principal barrera ha sido cómo conectar el lenguaje natural con el control preciso de los actuadores del robot (motores, servos, etc.). Generar código no es suficiente; se necesita un nivel de control mucho más fino y especializado.

La Evolución de la Robótica: De lo Estático a la Percepción

Para entender el salto que representan los VLA, recordemos cómo se ha trabajado en robótica hasta ahora. Imagina que queremos que un brazo robótico tome una caja. Durante décadas, la solución ha sido «marcar puntos»: se definen coordenadas por las que el robot debe pasar, y la electrónica interpola el movimiento entre ellas. En ciertos puntos, se le indica «abrir pinza», «mover un poco más», «cerrar pinza». Este método es estático y rígido, y cualquier variación mínima en el entorno (como una caja ligeramente movida) puede arruinar la tarea.

El sistema mejoró gracias a la introdución de la IA (no generativa) que era capaz de reconocer objetos y, hasta cierto punto, extrapolar su posición y modificar el recorrido del brazo. Este hecho introdujo cierta flexibilidad al sistema. Pero al final seguían dependiendo de que todo estuviera programado.

Las inteligencias artificiales no generativas ahora son capaces de interpretar mejor las imágenes de la cámaras y permite que los robots perciban su entorno y reaccionen a los cambios de forma mucho más flexible. Ademas la capacidad de razonar de los modelos de lenguaje les permite crear sus propias tareas para cumplir objetivos más allá de su programación básica. Si bien aún no podemos «soltarlos en el campo para que vivan su vida», sí son capaces de interactuar con su entorno de manera básica y no programada.

La Magia de los Modelos VLA: Visión, Lenguaje y Acciones

Ahora, volvamos a los Modelos VLA. ¿Qué significan estas siglas y qué aportan?

• V de Visión: Son modelos de lenguaje multimodales, pero no se limitan a cualquier imagen. Están entrenados específicamente con imágenes robóticas, generalmente de cámaras que muestran el brazo del robot y los objetos a manipular.
• L de Lenguaje: Aquí radica la capacidad de razonamiento y comprensión de instrucciones que tienen los modelos de lenguaje. En el caso de los VLA, también han sido entrenados con ejemplos específicos del ámbito robótico.
• A de Acciones: Y aquí es donde radica la verdadera innovación. Para comunicarse con un robot, necesitas indicarle qué acciones debe realizar. La salida de un VLA puede adoptar muchas formas: código fuente que indica los movimientos, ángulos específicos para cada motor, o incluso variaciones en las posiciones actuales de los motores.

Curiosamente, hay una letra que se omite y es fundamental : la S de Estado (State). En robótica, no basta con dar una orden como «mueve el brazo 10 grados»; también se necesita saber si el movimiento se ha realizado correctamente. Por lo tanto, el robot necesita no solo recibir datos, sino también enviar el estado de sus partes móviles.

En resumen, un modelo VLA es capaz de interpretar imágenes, comprender órdenes en lenguaje humano, planificar cómo ejecutarlas y transformar esas tareas en movimientos concretos del robot.

Desafíos Actuales y el Futuro Prometedor

A pesar de su potencial, los VLA tienen sus desafíos en el presente. Uno de los principales es su estrecha ligazón al hardware del robot. Entrenar un modelo para múltiples robots es posible, pero ¿qué sucede si modificamos el entorno, cambiamos una parte del brazo o añadimos nuevos sensores? Reentrenar un modelo de lenguaje es un proceso costoso en tiempo, dinero y datos.

Una solución de costo intermedio es el fine-tuning de modelos existentes para adaptar sus acciones. Google, en su documento de Gemini Robotics, propone un sistema interesante que divide el entrenamiento de los VLA en dos partes: una para la visión y el lenguaje (genérica para robótica) y otra para las acciones (específica para cada robot). Esto permitiría tener un módulo más genérico que luego se adapta a cada máquina.

Mirando hacia el futuro, una idea fascinante para mejorar las capacidades de estos modelos es el uso de IA generativa de vídeos como simulador del mundo. Antes de que el robot realice una acción real, podría «probarla» en su imaginación. Sin embargo, los modelos de vídeo aún no son tan efectivos como «modelos del mundo» como se esperaba, y esta aplicación podría tardar en materializarse.

Una alternativa más viable es utilizar simuladores de robot sencillos pero eficaces. La idea sería que la parte de visión del VLA recree la escena donde se moverá el robot, cargue este entorno simulado en un simulador, y realice todas las pruebas necesarias para validar sus planes antes de actuar en el mundo real.