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.

en este post vamos a metemos de lleno en una de esas cosas que suenan a ciencia ficción, pero que están ya funcionando el Deep Research.

¿Qué es el Deep Research?

Imagina que le pides a un modelo de lenguaje que investigue a fondo sobre un tema. No te responde de inmediato, sino que se toma su tiempo: consulta fuentes, rastrea Internet, recopila datos y, solo entonces, te devuelve una respuesta elaborada. Eso es Deep Research.

Este post es un resumen de mi vídeo, si quieres mayor profundidad puedes verlo:

Las herramientas usadas

Para esta entrada he seguido dos implementaciones públicas:

1. Gemini-fullstack-langgraph-quickstart (de Google): Un ejemplo claro y educativo, ideal para aprender como funciona.
2. Dearflow: Un proyecto mucho más profesional y complejo, pensado para ser realmente útil en producción.

Gemini-fullstack-langgraph-quickstart: sencilla y educativa

Esta demo se basa en LangGraph, un framework para trabajar con agentes. Pero tranquilo, que no vamos a entrar en el código. Solo vamos a entender cómo funciona:

El flujo de agentes

1. Generate Query
   Genera las queries de búsqueda a partir del prompt del usuario. Intenta cubrir distintos ángulos del tema y evita repetir.
2. Web Search
   Ejecuta esas búsquedas en internet, elige fuentes fiables y resume resultados.
3. Reflection
   Evalúa si ya hay suficiente información. Si no, genera nuevas queries y repite el proceso.
4. Answer Generator
   Crea la respuesta final

¿Qué modelos se usan?

Para cada agente, se usa un modelo distinto, del más rápido al más potente:

• Gemini 2.0 Flash → búsqueda y resúmenes
• Gemini 2.5 Flash → evaluación
• Gemini 2.5 Pro → generación final

Deerflow: la versión pro

Aquí las cosas se complican un poco más. Dearflow no es solo educativo: quiere ser una herramienta útil y versátil.

El corazón del sistema

• Coordinator
  Decide si una consulta merece un Deep Research o se puede responder de forma simple.
• Planner
  Orquesta toda la lógica: qué agentes se llaman, qué información falta, si hay que seguir buscando, etc.
• Research Team
  Conjunto de agentes especializados (algunos incluso capaces de ejecutar código).
• Reporter
  Redacta el informe final (puede convertirse en un podcast o una presentación PowerPoint)

Estilos y formato dinámico

Una cosa chula de Dearflow: puedes elegir el estilo del texto generado. Los prompts incluyen bloques dinámicos que se adaptan según el estilo que configures.

Conclusión

Si estás empezando, te recomiendo que juegues primero con la demo de Google. Te permite entender muy bien cómo funciona el proceso. Y cuando tengas soltura, lánzate con DeerFlow. Es una herramienta más robusta, pero también más compleja.

¿Te animas a crear tu propia herramienta de Deep Research?

Hoy vamos a tratar una pregunta que, aunque parezca más filosófica que técnica, tiene una base muy concreta: ¿los modelos de lenguaje pueden razonar?

¿Loros estocásticos?

Una de las principales críticas a los modelos de lenguaje es, que no hacen más que predecir la siguiente palabra en un texto, como una especie de loro estocástico. Es decir, dado un texto, el modelo calcula cuál es el siguiente token (unidad básica del lenguaje, parecida a una palabra o fragmento de palabra) más probable. Ese nuevo texto se vuelve a procesar, se calcula el siguiente token, y así sucesivamente.

Lo interesante es que entre token y token, el modelo no recuerda nada. Cada petición es independiente, lo cual parece alejarse bastante de cualquier forma de razonamiento.

Si no razonan ¿Cómo explicamos esto?

Para ilustrarlo, hice una pequeña prueba: le pedí a un modelo que generara una adivinanza completa, incluyendo la solución al final. Aunque las adivinanzas que genera no son obras maestras, suelen tener sentido y, sorprendentemente, la respuesta es coherente.

Vuelo sin alas,
lloro sin ojos,
paso sin pies
y no me ves.
¿Qué soy?
Respuesta: El viento.

Esto plantea una pregunta clave: si el modelo solo predice el siguiente token, sin saber la respuesta de antemano, ¿Cómo consigue generar una adivinanza con sentido y con una solución correcta si esta no se escribe hasta el final?

El razonamiento está en el procesamiento del texto

La clave está en lo que ocurre antes de que el modelo empiece a predecir tokens. Cuando recibe un texto, no lo procesa tal cual: lo transforma en una representación matemática sobre la que operan sus redes neuronales. Capa a capa, esta representación se modifica, se afina, y finalmente permite calcular los tokens más probables para continuar.

Este proceso —aunque distinto del razonamiento humano— puede considerarse una forma de razonamiento, en tanto que transforma información, la analiza y genera una conclusión coherente.

Además, el texto que genera el modelo tiene una doble función:
1. Responder al usuario.
2. Servir como soporte para su propio proceso de razonamiento.

De hecho, si ampliamos el texto con reflexiones, pasos intermedios y análisis, los resultados suelen ser mucho mejores. Por eso los llamados modelos razonadores generan respuestas más largas: ese “rollo” intermedio es parte del razonamiento.

¿Y cómo ha aprendido a hacer esto?

Aquí no hay magia: como cualquier red neuronal, un modelo de lenguaje aprende por imitación. Si se entrena con ejemplos de entradas y salidas, acabará imitando ese comportamiento. En este caso, al entrenarse con textos que contienen razonamientos, el modelo aprende a imitar cómo escribimos cuando razonamos.

De hecho, cada vez más, los modelos se entrenan con datos específicamente diseñados para reforzar su capacidad de razonar.

¿Token a token?

Una crítica habitual es que, si un modelo solo puede generar una palabra (token) a la vez, no puede estar razonando como lo hacemos nosotros. Pero eso no es del todo cierto.

Existen otros tipos de modelos, como los modelos de lenguaje de difusión, que generan todo el texto al mismo tiempo. Inicialmente en forma de “borrador”. Luego, en cada iteración, van refinando todos los tokens hasta que el texto tiene sentido. Este enfoque se parece mucho más al proceso humano de pensar y escribir.

¿Imitar es razonar?

Otra cuestión habitual es que los modelos no razonan porque solo imitan nuestro comportamiento. Aquí podríamos entrar en un debate filosófico largo, pero os lanzo esta reflexión:

¿Razonar es un proceso concreto y solo es válido si se hace exactamente como lo hacen los humanos? ¿O es un resultado y cualquier proceso que llegue a una conclusión que consideramos razonada puede llamarse razonamiento?

¿Y si en vez de imitar… aprenden por sí mismos?

Existe otra técnica de entrenamiento llamada aprendizaje por refuerzo, que permite a los modelos mejorar a base de ensayo y error, sin limitarse solo a imitar. Aunque es solo una parte del entrenamiento, se utiliza especialmente en tareas complejas como matemáticas o programación, y aumenta la capacidad de razonamiento del modelo.

Entonces… ¿razonan o no razonan?

Eso os lo dejo a vosotros. Lo que está claro es que la frontera entre imitación y razonamiento es más difusa de lo que parece.

Os traigo una técnica que promete cambiar la forma en la que funcionan los modelos de lenguaje (¿Cuantas van ya este año?). Esta nueva propuesta, presentada por el equipo de modelos Qwen, se llama Parallel Scaling. Vamos a desgranarlo poco a poco.

Tipos de modelos

Modelos densos

Son los clásicos. Cada vez que generan un token, usan todos sus parámetros. ¿Quieres que sea más listo? Añades más parámetros. Fácil, pero caro en términos de tiempo y memoria.

Modelos MOE (Mixture of Experts)

Estos modelos no usan todos sus parámetros en cada paso. Solo activan una pequeña parte, lo que los hace mucho más rápidos. Para igualar la inteligencia de un modelo denso, eso sí, necesitan tener un número total de parámetros mucho mayor. MOE permite ganar velocidad a cambio de usar más memoria.

Modelos razonadores

Aquí entra un enfoque llamado Inference Scaling, también conocido como modelos razonadores. ¿La idea? Darle más tiempo al modelo para pensar antes de responder. Esto se traduce en mayor inteligencia sin aumentar el número de parámetros, pero con un coste: las respuestas tardan más y requieren más cálculo.

Inference Scaling puede aplicarse tanto a modelos densos como MOE. Incluso, un mismo modelo puede funcionar de forma razonadora o no, según la necesidad.

Parallel Scaling: la gran novedad

Y aquí llega la joya de la corona: Parallel Scaling.
Consiste en ejecutar múltiples veces la misma entrada en el modelo de lenguaje, pero con prefijos distintos.

• Cada uno de estos prefijos guía al modelo a «pensar» de una manera diferente.
• El modelo ha sido entrenado para interpretar cada prefijo como una pista que activa un estilo de razonamiento distinto.
• ¿Resultado? Respuestas distintas que una red neuronal final se encarga de combinar.

Y ahora viene lo potente: todo esto se puede ejecutar en paralelo. Es decir, aumentamos la inteligencia sin aumentar el tiempo de respuesta. Más cálculo sí, pero distribuido y ejecutado de forma simultanea.

¿Cómo se entrena parallel scaling?

Aunque se puede entrenar desde cero, lo ideal es tomar un modelo ya entrenado y aplicarle un post-training para enseñarle a trabajar en paralelo.

En Hugging Face ya hay modelos entrenados con esta técnica, disponibles con distintos tamaños y conjuntos de datos.

¿Y ahora qué?

El futuro de esta técnica dependerá de si demuestra superioridad frente a otros métodos en múltiples escenarios.

Desde luego, la idea de mantener la memoria RAM bajo control y aun así aumentar la capacidad de razonamiento es muy prometedora. Además, en informática llevamos décadas acostumbrados a paralelizar tareas, así que… ¿por qué no aplicarlo también a la IA?

Si quieres profundizar más en el tema: