¿Alguna vez has sentido que la Inteligencia Artificial es demasiado lenta para tus necesidades? Imagina un escenario donde un modelo de lenguaje no solo responde rápido, sino que genera tal cantidad de texto que parece instantáneo. No estamos hablando de un vídeo acelerado, sino de una tecnología real que está rompiendo los límites de velocidad actuales: el chip HC1 de la empresa Taalas.

¿Qué es Taalas y cómo logra esta velocidad?

Taalas es una compañía que lleva poco más de dos años trabajando con una visión clara: dejar de depender de arquitecturas de propósito general, como las GPUs, para integrar los grandes modelos de lenguaje (LLM) directamente en el hardware. Mientras que una GPU es extremadamente potente y versátil, no deja de ser una pieza electrónica diseñada para muchas tareas distintas. Taalas, en cambio, ha implementado la arquitectura del modelo de lenguaje directamente en su chip HC1.

El resultado es asombroso. En demostraciones recientes, se ha visto un modelo Llama 3.1 de 8.000 millones de parámetros funcionando a una velocidad de 17.000 tokens por segundo. Para ponerlo en perspectiva, este sistema es capaz de generar más de 61 millones de tokens en tan solo una hora.

Eficiencia y potencia bajo el capó

Uno de los puntos más interesantes del HC1 es su eficiencia energética. Aunque consume unos 2.500 vatios por hora —una cifra que puede asustar a un usuario doméstico—, si analizamos el consumo por cada token generado, la cifra es ridículamente baja. Es, probablemente, una de las formas más eficientes de procesar lenguaje a gran escala que existen hoy en día.

Sin embargo, para alcanzar estas velocidades, se han tenido que tomar decisiones técnicas importantes:

• Cuantización: El chip trabaja actualmente con pesos de 3 y 6 bits, lo que significa que el modelo está comprimido para ajustarse al hardware.
• Flexibilidad limitada: Al estar la arquitectura «grabada» en el chip, no es tan sencillo actualizarlo a la última versión de un modelo que acabe de salir al mercado. Por otro lado, permite modificar los pesos, al menos algunos de ellos, ya que permite usar LoRA.
• Contexto: El tamaño de la memoria de contexto es algo limitado (alrededor de 6.000 tokens), aunque suficiente para una gran variedad de aplicaciones prácticas.

El futuro: El chip HC2 y los modelos razonadores

A pesar de estas limitaciones, como el contexto reducido o la imposibilidad de ejecutar modelos gigantescos de cientos de miles de millones de parámetros, el potencial es enorme. Esta tecnología encaja perfectamente con los nuevos «modelos razonadores». Estos modelos suelen generar una gran cantidad de «pensamientos» internos antes de dar la respuesta final. Con la velocidad de Taalas, ese proceso de razonamiento sería tan rápido que el usuario ni siquiera notaría la espera.

La empresa ya está trabajando en su siguiente evolución, el chip HC2. Se espera que esta nueva versión sea todavía más rápida, soporte una mayor cantidad de pesos y ofrezca una mayor resolución (probablemente pasando a 4 y 8 bits), lo que mejorará la precisión de las respuestas sin sacrificar la velocidad que los hace únicos.

Estamos ante un cambio de paradigma: pasar de ejecutar software de IA en hardware genérico a tener hardware que es la propia IA. La era de los 17.000 tokens por segundo solo acaba de empezar.

DeepSeek ha presentado una propuesta técnica que podría marcar un antes y un después en la arquitectura de los Transformers: Engram. Se trata de una idea que busca solucionar un problema que, aunque no solemos ver, está afectando seriamente la eficiencia de los modelos de lenguaje actuales.

El problema: Las redes neuronales no son lo mejor para memorizar

Cuando le preguntas a una IA «¿Cuál es la capital de Francia?», la respuesta («París») es un dato memorizado, no el resultado de un proceso de razonamiento complejo. Actualmente, las redes neuronales de los modelos de lenguaje tienen que hacer ambas tareas a la vez: razonar (resolver problemas) y memorizar (almacenar datos estáticos).

El problema es que las redes neuronales no son la mejor herramienta para memorizar. Al obligarlas a guardar datos, estamos desperdiciando una potencia de cómputo inmensa que podría aprovecharse mejor.

La solución de Engram: Separar la memoria

La propuesta de Engram es elegante: separar estos dos procesos. La idea es crear un mecanismo óptimo dedicado exclusivamente a la memoria y dejar que las redes neuronales se dediquen 100% a la resolución de problemas (lo que llamamos «razonamiento» como símil).

¿Cómo funciona?

• Tablas y hashes: El sistema utiliza tablas de datos donde la información se recupera mediante un «hash» calculado a partir del token actual y los anteriores.
• Inyección de información: Esos datos recuperados se convierten en vectores que se inyectan en el flujo de trabajo del Transformer para aportarle información estática.

• La puerta de control: Para evitar errores (como cuando el contexto cambia y Francia no es un país, sino un planeta extraterrestre), existe una «puerta» reguladora. Es un vector que decide, valor a valor, cuánta de esa memoria inyectada es realmente válida para el contexto actual.

Problemas y soluciones

Al usar tablas con un hash existen dos tipos de problemas:

• Asignar a tokens similares direcciones diferentes: esto ocurre porque ls funciones hash tienen a «dispersar» los resultados y dos tokens parecidos (patata y Patata) pueden apuntar a espacios de memoria diferentes. Para evitar eso se toma la medida de simplificar los tokens para que ambos sean el mismo.
• Colisiones, asignar a tokens diferentes la misma dirección: el caso contrario, dos tokens distintos (camión y patata) apuntan al mismo espacio en memoria, cómo hay varias tablas de hash diferentes, aunque ocurra con una tabla el resto de valores compensaran esta respuesta errónea

La proporción adecuada

Uno de los puntos más prometedores es la eficiencia. Según los datos actuales, dedicar entre un 20% y un 25% de los pesos del modelo a este sistema de memoria permite que la IA «razone» mejor con el mismo número de parámetros.

Eficiencia, velocidad y hardware barato

Pero hay más: recuperar datos de estas tablas es muchísimo más rápido que procesar inputs a través de todas las capas de una red neuronal. Esto significa que este proceso se puede hacer en paralelo e incluso utilizando hardware más barato o de menor calidad sin que el rendimiento general del sistema sufra. Es una doble victoria: menos cálculo necesario y hardware más económico.

¿Qué esperar de Engram?

Aunque siempre hay que tomar el optimismo de los nuevos estudios con cautela, Engram es una idea sumamente interesante. El reto ahora es ver cómo escala en modelos masivos de cientos de miles de millones de parámetros.

Sin duda, no es una idea que lo cambie todo de la noche a la mañana, pero sí es un camino muy inteligente hacia una inteligencia artificial más eficiente y especializada.

Muchos se preguntan si 2026 será finalmente el año en que veamos robots realizando tareas del hogar de forma masiva. Aunque ya hay empresas ofreciendo soluciones, la «letra pequeña» es que muchos de estos robots están actualmente teleoperados; es decir, no son autónomos, sino avatares controlados a distancia por personas para recolectar datos.

Para que un robot sea realmente útil en una casa, debe resolver tres retos fundamentales: navegación, planificación y manipulación.

Navegación: Un problema prácticamente resuelto

La navegación es la capacidad del robot para moverse sin chocar. Esto se logra con IA clásica: el robot crea un mapa digital, usa un punto de referencia (como su base de carga) y corrige sus errores de posición comparando lo que ve (con sensores LiDAR o cámaras) con su mapa interno. En entornos complejos, incluso se pueden usar apoyos externos como códigos QR o señales de radiofrecuencia.

Planificación y Manipulación: El verdadero desafío

A diferencia de una fábrica, un hogar es un entorno caótico. Para solucionar esto, modelos como los de Gemini Robotics (DeepMind) proponen un sistema de dos capas basado en IA generativa:

• Modelo Razonador (LLM Multimodal): Recibe órdenes complejas (ej. «hazme un bocadillo»), analiza el entorno y descompone la tarea en pasos lógicos, siendo capaz de improvisar si, por ejemplo, los cubiertos no están en su sitio.
• Modelo de Manipulación (VLA): Traduce esas órdenes en movimientos precisos de los motores y brazos del robot, adaptándose a la resistencia y posición de los objetos en tiempo real.

El gran obstáculo: La falta de datos

El mayor problema actual es que no tenemos suficientes datos de robots realizando tareas domésticas para entrenarlos. Es un círculo vicioso: no hay robots porque no hay datos, y no hay datos porque no hay robots.

Para romper este ciclo, se están explorando tres vías:

1. Datos de laboratorio: Muy precisos pero lentos y caros.
2. Datos sintéticos y simuladores: Permiten aprender rápido, pero suelen tener sesgos y no siempre reflejan perfectamente la realidad física.
3. Teleoperación: Al usar humanos para controlar robots, las empresas están obteniendo los datos reales necesarios para automatizarlos en el futuro.

Además, existe una complicación extra: los modelos de manipulación dependen totalmente del hardware. Un software diseñado para un robot con tres brazos no sirve directamente para uno de dos, lo que fragmenta el aprendizaje.

Conclusión: La tecnología está avanzando hacia modelos capaces de razonar en el mundo físico, pero el camino hacia un robot autónomo y asequible depende de cómo resolvamos esta crisis de datos reales.

Vamos a profundizar en un modelo que me parece fascinante: GLM Image. Aunque a simple vista podría parecer un generador de imágenes más, con sus casi 18.000 millones de parámetros, su importancia no radica solo en la calidad o el rendimiento, sino en su innovadora arquitectura y en lo que representa para la industria tecnológica actual.

Una arquitectura híbrida: Lo mejor de dos mundos

Lo que hace que GLM Image destaque es que no es solo un modelo autorregresivo ni solo un modelo de difusión; es una combinación de ambos. El proceso comienza con un modelo de lenguaje basado en GLM4 (de 9.000 millones de parámetros), el cual ha sido reentrenado para producir tokens visuales.

Este modelo autorregresivo se encarga de generar lo que llamamos datos de baja frecuencia (colores y texturas generales). Para ello genera de forma autoregresiva tokens que representan estos datos. Este proceso lo hace en dos pasos, primero crear una representacion de baja resolución formada por 256 tokes y finalmente crea una version de alta resolución con un total de entre 1000 y 4000 tokens.

Posteriormente, estos tokens pasan a un modelo de difusión que genera los datos de alta frecuencia, es decir, los detalles finos y la definición de la imagen. Es como si el modelo autorregresivo hiciera el boceto con las formas y colores base, y el de difusión se encargara de darle el acabado final y la nitidez.

El reto de la edición y la codificación dual

Cuando queremos editar una imagen o usar una como referencia, nos enfrentamos a un problema: el modelo autorregresivo tiende a perder detalles minuciosos. Para solucionar esto, GLM Image utiliza un sistema de codificación dual:

• Tokens Semánticos: Van al modelo autorregresivo y se centran en la descripción de lo que hay en la imagen.

• Tokens Visuales: Van directamente al modelo de difusión y se centran en el aspecto visual de los píxeles.

Esta separación permite que el modelo sea especialmente bueno manteniendo la coherencia, y lo detalles de las imágenes.

Para mejorar el aspecto y corrección de los textos que aparecen en las imágenes. Los tokens visuales son enriquecidos con otros relativos especificamene a los textos que deben aparecer en el resultado, con un énfasis especial en caracteres chinos.

Si quieres conocer el proceso con más detalle puedes ver este vídeo en mi canal de Youtube:

¿Por qué GLM Image es realmente importante?

Más allá de sus capacidades técnicas, este modelo es un hito por dos razones estratégicas:

1. El camino hacia los modelos «Omni»: Este tipo de arquitectura es un paso necesario para lograr modelos que puedan recibir y generar cualquier tipo de dato (audio, texto, vídeo) de forma fluida. Es una apuesta por los modelos multimodales totales que tanto nos apasionan.

2. Independencia de hardware: Quizás el punto más disruptivo es que GLM Image no ha sido entrenado con hardware de Nvidia, sino utilizando hardware de Huawei. En el contexto del conflicto tecnológico entre China y Estados Unidos, esto es una señal de alerta para Nvidia. Demuestra que las GPUs chinas están empezando a competir seriamente y que el mercado de la IA podría estar a punto de cambiar sus reglas de juego.

En resumen, GLM Image es una prueba de que el desarrollo de la IA no se detiene y que la competencia en hardware está más viva que nunca.

Se estima que el 2026 será un año fundamental, con planes de expansión masivos en EE. UU., China y una Europa cada vez más permisiva.

Pero antes de entrar en harina, hay que aclarar algo que suele generar confusión: no es lo mismo un coche autónomo que un coche sin conductor.

Los niveles de autonomía: ¿Dónde estamos realmente?

Para entender la tecnología, primero debemos saber en qué nivel nos movemos. Según la DGT, existen cinco niveles de automatización:

• Nivel 1 y 2: Son los que ya vemos en la calle. El coche controla dirección o velocidad (o ambas), pero el conductor debe estar siempre presente y atento. Curiosamente, al nivel 2 se le llama hand off, aunque es justo lo que no debes hacer: soltar el volante.

• Nivel 3: El coche ya es «autónomo», pero requiere un conductor listo para intervenir si el sistema se ve superado.

• Nivel 4: El vehículo se las apaña solo. Si hay problemas, avisa a un operador remoto. Empresas como Waymo operan en este nivel.

• Nivel 5: La autonomía total. Sin volante ni pedales. A día de hoy, no existe ningún país que permita el nivel 5 de forma comercial, más allá de pruebas muy limitadas.

¿Cámaras o sensores?

Aquí es donde la industria se divide en dos bandos. Por un lado, Tesla apuesta exclusivamente por las cámaras. Por otro, el resto del mundo defiende el uso combinado de cámaras, radares, sensores ultrasónicos y el famoso LiDAR.

¿Qué aporta cada uno?

1. Sensores ultrasónicos: Son los típicos de aparcamiento. Funcionan por «tiempo de vuelo» del sonido. Son baratos y útiles en distancias cortas, aunque les afecta la temperatura y el viento.

2. Radares de microondas: Usan ondas electromagnéticas. Son ideales para medir la velocidad de otros vehículos gracias al efecto Doppler y funcionan bien en movimiento.

3. Cámaras: Son inevitables. Necesitamos ver señales, semáforos y luces de freno. Tesla confía en la visión estereoscópica (dos cámaras para emular la profundidad humana) y la luz estructurada para entender el entorno. Su mayor reto es la interpretación de imágenes mediante IA.

4. LiDAR: La joya de la corona. Lanza miles de puntos láser para crear un mapa 3D preciso de todo lo que rodea al coche. Sus enemigos son la lluvia densa, la nieve y los espejos, pero su precisión es asombrosa.

Para más información sobre los sensores puedes ver el siguiente vídeo:

¿Por qué Tesla se queda solo con las cámaras?

Si el LiDAR es tan bueno, ¿por qué prescindir de él? Tesla argumenta tres razones principales:

• Fusión de datos: Cuantos más sensores tienes, más difícil es ponerlos de acuerdo. Si un sensor dice una cosa y otro otra, el sistema puede entrar en conflicto (algo parecido a cuando nos mareamos en un barco porque nuestros sentidos no coinciden).

• Coste: Un equipo completo de sensores y el hardware necesario para procesar tanta información es extremadamente caro.

• Estrategia de datos: Este es el punto clave. Tesla tiene millones de kilómetros grabados solo con cámaras. Si ahora intentara usar LiDAR, empezaría de cero contra competidores como Waymo, que ya tienen todos esos datos procesados. Su apuesta es demostrar que un coche solo con cámaras puede conducir tan bien como uno lleno de sensores, siendo mucho más barato de producir.

¿Por qué Waymo apuesta por cámaras + sensores?

En este aspecto Waymo parte con ventaja. Sus coches ya están desplegados con equipamiento completo de sensores recopilando datos.

• Fusión de datos: La suma de los datos de todos los sensores da un modelo del mundo más completo. Además de ofrecer redundancia de datos.

• Coste: Esta opción requiere un hardware costoso. Es verdad que sus costes están bajando rápidamente. Si quiere ganar lo que ofrezca debe compensar el aumento de costes.

• Estrategia de datos: Waymo esta capturando datos de forma activa. Ahora mismo es su mayor ventaja. La fusión de datos parece estar suficientemente resuelta como para tener, probablemente, el coche más avanzado en cuanto a conducción autónoma.

Conclusión

No se trata de quién tiene la razón técnica absoluta, sino de estrategias económicas y de datos.

Lo que está claro es que la robótica y el hardware para la inteligencia artificial van a dar un salto gigante en los próximos años. Sea cual sea la tecnología que gane, ¡Os lo cuento desde aqui!

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.