Atención Híbrida: El Futuro de los Transformers (atención lineal + atención clásica)

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.

La versión en vídeo de este post

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.

*Matrix de relaciones entre tokens. A más claro sea el color más fuerte es la relación*

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.

*La atención lineal procesa la información de forma secuencial. El estado (representado en la parte superior de cada paso) tiene un tamaño fijo*

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.

Entropía ¿El fin de las alucinaciones en los modelos de lenguaje?

Uno de los mayores y más frustrantes problemas de los modelos de lenguaje (LLMs) son las alucinaciones. Le haces una pregunta y, con una seguridad pasmosa, te responde lo que quiere, a veces con información completamente inventada. Se han propuesto muchas soluciones para mitigar este problema, pero ninguna parece ser definitiva.

Sin embargo, hay quienes están abordando este desafío desde un ángulo diferente: las matemáticas. No salgas corriendo, no necesitas ser un experto para entenderlo. Vamos a ver de manera sencilla cómo conceptos como la entropía pueden ayudarnos a detectar y gestionar estas alucinaciones.

La versión en vídeo

Un Vistazo Rápido: ¿Cómo «Piensa» un Modelo de Lenguaje?

Antes de sumergirnos en la entropía, es crucial recordar cómo funciona un LLM en su nivel más básico. Cuando le das un texto, el modelo no solo elige la siguiente palabra o «token». Lo que realmente hace es calcular una puntuación para todos los tokens que conoce.

Estas puntuaciones, tras ser procesadas por una función (como SoftMax), se convierten en un listado de probabilidades. Es decir, el modelo genera la probabilidad de que cada token sea el siguiente más adecuado en la secuencia.

La Entropía: El Medidor de «Indecisión» del Modelo

Una vez que tenemos estas probabilidades, podemos calcular la entropía (concretamente, la entropía de Shannon de la teoría de la información). En este contexto, podemos entender la entropía como una medida de lo indeciso que está el sistema.

Entropía Baja = Alta Seguridad: Si la mayor parte de la probabilidad se concentra en una o muy pocas opciones, la entropía es baja. Esto significa que el modelo está muy seguro de cuál es la respuesta.
- Ejemplo: Si preguntamos «¿Qué árbol da manzanas?», el modelo debería concentrar casi toda la probabilidad en el token «manzano». El sistema no duda, la entropía es baja y el problema está resuelto.
Entropía Alta = Duda o Incertidumbre: Si la probabilidad está muy repartida entre múltiples opciones, la entropía es alta. El modelo está indeciso, y es aquí donde pueden surgir los problemas.

Cuando el Modelo Duda: Entropía Alta y Varianza

Una entropía alta nos dice que el modelo duda, pero no todas las dudas son iguales. Aquí es donde entra en juego la varianza de la entropía, que nos ayuda a entender cómo están distribuidas esas probabilidades. Esto nos permite distinguir entre dos escenarios clave:

Escenario 1: Duda entre Opciones Válidas

Señal: Entropía alta, pero varianza baja.
¿Qué significa? El modelo está indeciso, pero entre un número limitado y concreto de opciones que tienen sentido. Las probabilidades están concentradas en unas pocas respuestas posibles.
Ejemplo: Si preguntamos «¿Qué árbol da frutos?», hay muchas respuestas correctas (manzano, peral, naranjo…). El modelo dudará, repartiendo la probabilidad entre ellas.
Solución posible: En este caso, no es que el modelo esté alucinando, sino que necesita más contexto o tiempo. Se pueden emplear técnicas como la «cadena de pensamiento» (Chain of Thought) o explorar las diferentes ramas de respuesta para que el modelo se aclare y elija la mejor opción.

Escenario 2: El Modelo está Completamente Perdido

Señal: Entropía alta y varianza alta.
¿Qué significa? El modelo no tiene ni idea de cómo continuar. La probabilidad está distribuida de forma muy dispersa entre muchísimos tokens, sin que ninguno destaque claramente.
Ejemplo: Si le preguntamos por una fruta inventada que no existe, el modelo no encontrará ninguna respuesta lógica y se quedará «perdido».
Solución posible: Esta es una señal de alerta máxima. Indica que el camino que estamos siguiendo es muy poco probable que nos lleve a una respuesta correcta. La mejor estrategia podría ser retroceder varios pasos, reformular la pregunta o cambiar algunos parámetros de la consulta para intentar reconducir al modelo.

Resumen de la Estrategia

Podemos resumir este enfoque de la siguiente manera:

Entropía baja: ¡Todo en orden! El modelo está seguro.
Entropía alta y varianza baja: El modelo duda entre varias opciones plausibles. Hay que ayudarle a «pensar» y elegir.
Entropía alta y varianza alta: ¡Alerta! El modelo está perdido. Es hora de volver a empezar o cambiar de rumbo.

Esta técnica no solo sirve para la corrección interna, sino que también tiene aplicaciones muy útiles para el usuario. Por ejemplo, se podría identificar rápidamente qué partes de la respuesta son menos fiables.

Limitaciones

Sin embargo, este método no es una panacea y tiene sus propios desafíos:

Es difícil establecer un umbral numérico claro para definir qué es entropía «alta» o «baja».
El contexto es clave. En tareas como la escritura creativa, un mayor grado de «alucinación» o es deseable.
Las situaciones reales son mucho más complejas que los ejemplos simplificados.

Conclusión: Una Herramienta Más en la Caja

La entropía y su varianza son herramientas fascinantes que nos permiten asomarnos a la «mente» de un modelo de lenguaje y entender su nivel de certeza. No obstante, no son la solución definitiva a las alucinaciones.

Las causas de las alucinaciones son múltiples: prompts mal diseñados, datos de entrenamiento incorrectos o confusos, problemas durante el ajuste fino (fine-tuning), etc. La solución final no será una única técnica, sino un conjunto de medidas que, poco a poco, hagan a estos modelos más fiables y seguros. Este enfoque matemático es, sin duda, un paso prometedor en esa dirección.

Redes neuronales y esteganografía: cómo ocultar malware en modelos de IA

Con la creciente popularidad de las redes neuronales, no solo surgen nuevas aplicaciones sorprendentes, sino también nuevas amenazas. Una de las más intrigantes —y preocupantes— es el uso de redes neuronales para ocultar malware mediante técnicas de esteganografía.

Más información en este vídeo

¿Qué es la esteganografía?

La esteganografía es el arte de ocultar mensajes dentro de otros elementos, de forma que pasen desapercibidos. Aunque la técnica tiene miles de años de antigüedad (hay registros de su uso desde el 500 a.C.), su auge llegó con la era digital. Tradicionalmente, se han utilizado archivos multimedia como imágenes o audios para esconder información, ya que permiten modificar algunos bits sin que se note a simple vista.

Ahora, con los modelos de redes neuronales —que pueden ocupar cientos de megabytes o incluso gigabytes—, se abre una nueva puerta: ocultar información directamente en los pesos del modelo.

Cómo se oculta malware en los pesos de una red neuronal

Los pesos son los valores numéricos que determinan cómo una neurona procesa sus entradas. Una red típica puede tener millones de ellos. Esto permite aplicar una técnica clásica de esteganografía: modificar el bit de menor peso (el menos significativo) en cada valor.

La idea es sencilla: se toma el malware, se divide en bits, y se va incrustando uno a uno en los bits de menor peso de los pesos del modelo. Estos cambios son tan pequeños que, en la mayoría de los casos, no afectan significativamente el rendimiento de la red. La red podría dar resultados ligeramente menos precisos, pero nada evidente a simple vista.

Eso sí, esta técnica no sirve en todos los casos. Los modelos cuantizados, que usan menos bits por peso (4 o incluso 2), son mucho más sensibles. En estos casos, hasta una pequeña modificación puede dañar gravemente el rendimiento del modelo.

Otra técnica: modificar pesos enteros

Una alternativa, más robusta, es modificar unos pocos pesos completamente, en lugar de solo un bit. El truco está en que estos nuevos valores se mantengan dentro del rango estadístico habitual de los pesos de la red. Así se evita que destaquen o que degraden el comportamiento del modelo.

Esta técnica, según algunos estudios, puede ser incluso más efectiva. Y si la calidad del modelo se ve afectada, se puede reentrenar la red, congelando los pesos modificados y permitiendo que los demás se ajusten para compensar.

Técnica avanzada: overfitting controlado

Una tercera técnica más sofisticada y exclusiva de redes neuronales consiste en provocar overfitting de forma intencionada para una única entrada concreta.

Por ejemplo, se entrena un modelo de lenguaje para que, solo cuando reciba una frase específica como input (por ejemplo, «<malware>»), devuelva una salida exacta: ya sea un script, una secuencia codificada en base64, o cualquier tipo de dato malicioso. Lo notable de este método es que no requiere acceso a los pesos del modelo. Basta con acceder a la API y lanzar la consulta específica para recuperar el contenido oculto.

¿Cómo podemos protegernos?

El gran problema con la esteganografía es que nunca puedes estar completamente seguro de si un archivo está limpio o contiene datos ocultos.

Una opción defensiva sería combatir el fuego con fuego: aplicar las mismas técnicas de modificación del bit de menor peso o reentrenar el modelo para destruir posibles cargas maliciosas. Sin embargo, esto tiene un coste considerable en recursos y tiempo. No parece una solución viable salvo que se requiera seguridad a nivel militar.

Lo más razonable, por ahora, es aplicar el sentido común: descargar modelos solo de fuentes fiables y verificadas. Aunque hoy estas técnicas puedan parecer experimentales, es muy probable que en el futuro cercano se conviertan en vectores reales de ataque.

Conclusión

Ocultar malware en redes neuronales no es ciencia ficción. Es una posibilidad técnica real, con varios métodos probados, y que puede volverse más común conforme el uso de modelos crezca en todos los sectores.

Por ahora, lo mejor es mantenerse informado, trabajar con fuentes de confianza y no perder de vista los desarrollos en esta fascinante —y algo inquietante— intersección entre inteligencia artificial y ciberseguridad.

¡Los Modelos VLA van a Revolucionar la Robótica! (Robots + LLM)

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.

Más detalles en el vídeo

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.

Arquitecturas Multiagente IA

¿Qué son los agentes en IA y cómo se comunican entre ellos?

En los últimos meses, la inteligencia artificial no ha dejado de hablar de agentes. Pero, ¿realmente sabemos qué son y cómo funcionan?

En este artículo quiero profundizar un poco más en el mundo de los agentes, centrándome especialmente en cómo se interconectan, qué tipos de conexiones existen y para qué se utilizan.

Puedes ver el vídeo para más información

¿Qué es un agente?

El término agente se ha usado tanto en marketing que ya parece que cualquier cosa con unos cuantos if seguidos lo es. Pero, para centrarnos, vamos a considerar como agente a cualquier sistema que:

Usa un modelo de lenguaje (como GPT, Claude o similares),
Tiene una entrada (input),
Genera una salida (output),
Y puede usar recursos adicionales.

Entre esos recursos destacan:

Herramientas: llamadas a APIs para ejecutar acciones u obtener datos de forma activa (A diferencia del RAG que es pasiva).
RAG (Retrieval-Augmented Generation): sistemas que proporcionan información al agente de forma pasiva desde una base de conocimiento.
Memoria: donde el agente guarda datos relevantes, que pueden ser individuales o compartidos con otros agentes (sirviendo además como canal de comunicación).

Agentes vs. Herramientas

En este contexto, es útil distinguir entre:

Agentes: usan modelos de lenguaje generativos.
Herramientas: sistemas más clásicos que no generan texto, como calculadoras, traductores automáticos o motores de búsqueda específicos.

¿Cómo se comunican los agentes?

La comunicación entre agentes (o entre agentes y herramientas) puede hacerse de dos formas:

Estructurada: con formatos como JSON, ideal para trabajar con APIs.
No estructurada: texto plano, ideal para comunicación entre agentes.

Dato importante: si un agente va a comunicarse con una herramienta como una API, la salida debe estar estructurada, ya que una API no «entiende» texto libre.

Tipos de conexiones entre agentes

Una vez que entendemos qué es un agente y cómo se comunica, pasamos al núcleo del asunto: las arquitecturas. Es decir, cómo se conectan entre sí.

1. Cadena (Chain of Agents)

Cada agente se conecta con el siguiente. La salida de uno es la entrada del otro. Esto permite dividir una tarea compleja en subtareas y asignarlas a agentes especializados, que pueden ser más eficientes y económicos.

2. Paralela

En lugar de conectarlos en cadena, los agentes trabajan simultáneamente en paralelo. Esto ahorra tiempo y es muy útil en sistemas de votación o generación múltiple de ideas.

3. Enrutador

Aquí entra un agente que actúa como selector: decide qué agente (o grupo de ellos) debe continuar el flujo. Es una forma dinámica de guiar el proceso.

4. Agregador y Sintetizador

Cuando varios agentes generan salidas y necesitamos una única respuesta final:

Agregador: recoge múltiples respuestas y elige una (como un sistema de votación).
Sintetizador: combina todas las respuestas en una más completa y cohesionada (por ejemplo, al generar un informe con partes creadas por distintos agentes).

5. Evaluador

Evalúa si el resultado es válido o si hay que volver atrás, repetir pasos o ajustar la respuesta. Funciona como un sistema de validación y retroalimentación.

6. Orquestador

Es el más complejo: no hay un flujo predefinido. El orquestador va decidiendo qué agente se ejecuta en cada paso, según cómo evoluciona la tarea. Potente, pero difícil de implementar correctamente.

Combinarlo todo

Aquí es donde la cosa se pone interesante. Lo realmente potente de estas arquitecturas no es usarlas de forma aislada, sino combinarlas. Así podemos construir sistemas de agentes sofisticados y adaptables.

Por ejemplo, las herramientas de Deep Research (tienes un vídeo sobre el tema aqui)

¿Problemas y limitaciones?

No todo son ventajas. Algunos desafíos comunes son:

Falta de contexto compartido: si no se gestiona bien, los agentes pueden contradecirse (por ejemplo, uno dice que unas zapatillas son verdes y otro que son rojas).
Alucinaciones: cuantos más agentes, más riesgo de errores si uno “alucina” (es decir, genera información incorrecta) y arrastra al resto.

Conclusión

El futuro de los agentes en IA es apasionante, pero también complejo. Si queremos diseñar sistemas eficaces, debemos entender cómo se comunican, qué recursos utilizan y cómo evitar errores.

Deep Research explicado paso a paso

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:

Gemini-fullstack-langgraph-quickstart (de Google): Un ejemplo claro y educativo, ideal para aprender como funciona.
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

Generate Query
Genera las queries de búsqueda a partir del prompt del usuario. Intenta cubrir distintos ángulos del tema y evita repetir.
Web Search
Ejecuta esas búsquedas en internet, elige fuentes fiables y resume resultados.
Reflection
Evalúa si ya hay suficiente información. Si no, genera nuevas queries y repite el proceso.
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?

¿Pueden los modelos de lenguaje razonar?

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.

Parallel Scaling, un nuevo tipo de modelos del lenguaje

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:

Qwen 3

Qwen ha presentado una nueva versión de su familia de modelos. Con modelos para todos los gustos.

Voy a dividirlos en dos bloques, modelos MOE y modelos densos. Explicando rápidamente la diferencia entre ambos, mientras que los modelos densos usan todos sus pesos para calcular el siguiente token, los modelos MOE solo emplean una parte.

Modelos densos:

Empiezo por los modelos densos que son a los que más acostumbrados brazos estamos.

Aquí el rey es un modelo de 32 mil millones de parámetros. De ese modelo han destilado otros de 14, 8, 4, 1.7 y 0.6 mil millones de parámetros. Hay versión base (completar textos) y versión entrenada para seguir instrucciones (la de chatear, vamos)

Todos tienen un contexto de 32.000 tokens. Aunque los modelos de 32, 14 y 8 mil millones de parámetros pueden extenderse hasta 128.000 tokens.

Modelos MOE:

Los MOE son solo 2 modelos: Qwen 3 235B A22B y su versión destilada Qwen 3 30B A3B

Si estos nombres a medio camino entre modelo de lenguaje y código de almacén de ferretería te confunden te los explico rápidamente:

Nombre del modelo Versión Número de parámetros “A”Número de parámetros activos en cada consulta.

Los MOE son interesantes a nivel profesional ya que permiten reducir el tiempo de cómputo y por tanto el consumo de GPU. Por otro lado sus resultados no son tan buenos como un modelo denso del mismo tamaño.

Comparar modelos MOE y densos:

Os lo explicó con un ejemplo: Si tengo que elegir entre Qwen 3 32B y Qwen 3 30B A3B ¿Con cuál me quedo?

Ambos ocupan más o menos lo mismo. Esto nos lo indica el número de parámetros. 32B y 30B, para tener una aproximación podemos multiplicar éstos por los bytes que consume cada peso. Generalmente 2 (aunque hay modelos que pueden llegar hasta cuatro). Si el modelo está cuantizado pueden ser un bytes o menos. Este valor es un valor mínimo puesto que luego el modelo necesita más memoria para almacenar el contexto y los cálculos intermedios.

El tiempo de respuesta del modelo nos lo da el número de parámetros activos. En el caso de los modelos densos todos sus parámetros están activos.

¿Y en inteligencia? ¿Cómo se comparan? Hay una fórmula no oficial y aproximada de que un modelo MOE es comparable a un modelo denso cuyo número de parámetros sea la raíz cuadrada de multiplicar el total de parámetros por el número de parámetros activos. En este caso SQRT(30*3) es equivalente a un modelo de 16.4B. Cómo ya he dicho es una fórmula aproximada y creo que un poco injusta. Los MOE han ido mejorando.

En mis pruebas de programación, pruebas muy básicas nada complejo, aunque ambos han resuelto correctamente los que les he pedido creo que la versión 32B ha escrito código de mejor calidad que 30B A3B. Ahora, está última generaba tokens a tal velocidad que era imposible seguirla.

Pero aquí estamos para darles vueltas a las cosas y voy a daros una tercera solución que combina la inteligencia del modelo 32B y acelera su velocidad. Aunque requiere usar un poco más de memoria. Usar Qwen 3 32B junto con Qwen 3 0.6B usando speculative decoding para acelerar los cálculos.

Multilenguaje

Volviendo al resto de las características de los modelos, cabe destacar el soporte multilenguaje con más de 119 lenguas soportadas. Debo decir que al menos en lo que al español se refiere ha mejorado mucho. Mi experiencia con versiones anteriores es que usar el inglés (y supongo que el chino) era mucho mejor que el español. Sin embargo está versión ha mejorado.

Modo híbrido razonador/no-razonador

Para mí la gran novedad de este sistema es la capacidad de poder usar el mismo modelo como modelo razonador y no razonador al mismo tiempo. Basta con incluir la etiqueta /think o /nothink al final del prompt de sistema o de usuario para activarlo.

En el modo razonador se generara el texto con el razonamiento encerrado entre dos etiquetas <think> </think>. Después de ellas escribirá la respuesta final. En caso de que la conversación continué hay que quitar estas etiquetas y el texto contenido entre ellas. Basta con dejar la conclusión final. Esto ayuda a no agotar el contexto disponible. Cosa habitual en los modelos razonadores que tienden a generar muchos tokens durante su razonamiento.

Puede parecer tentador combinarlos en una misma conversación pero no están sencillo, ya que los parámetros del sampling recomendados para cada caso son diferentes.

No thinking (No razonador):

Temperature=0.7, TopP=0.8, TopK=20, MinP=0

Thinking (Razonador):

Temperature=0.6, TopP=0.95, TopK=20, MinP=0

Para conseguir un modelo con estas capacidades han partido del modelo base y han realizado un post-entrenamiento de cuatro etapas:

En la primera le han entrenado usando ejemplos de cadenas de pensamiento.

En la segunda han usado aprendizaje por refuerzo centrado en matemáticas y programación recompensando aquellas estrategias que incentivan el razonamiento

En la tercera integran ambas formas de respuesta (razonador y no razonador) entrenado con datos de ambos tipos

En la cuarta realizan aprendizaje por refuerzo pero con mayor variedad de tareas que en la segunda etapa.

Uso de herramientas (ahora llamado “capacidades agénticas”)

Todos los modelos han sido entrenados en el uso de herramientas, en este caso se ha hecho especial hincapié en que soporte en el protocolo MCP

Qué viene ahora

En el caso de otros modelos esto sería un punto y final pero no es la forma de trabajar de los modelos Qwen. Ahora a lo largo del año irán apareciendo nuevos modelos basados en Qwen 3. Math, Coder, con capacidades visuales, auditivas, quizás una nueva versión de Qwen Omni.

El Futuro de los Agentes: Conociendo A2A y MCP

¡Bienvenidos a Construyendo a Chispas! Hoy exploramos una de las tendencias más emocionantes en el mundo de la inteligencia artificial: el futuro de los agentes. Cada vez más, la IA se está orientando hacia el uso de agentes capaces de realizar diversas tareas de manera autónoma, con el objetivo de facilitarnos la vida.

Pero para que esta revolución funcione, necesitamos algo fundamental: estándares y protocolos que definan cómo deben comunicarse estos agentes entre sí y con nuestras herramientas. Hoy vamos a hablar de dos de esos protocolos, que no solo son innovadores, sino que además se complementan perfectamente: A2A de Google y MCP de Anthropic.

Para información en mayor detalle puedes ver el siguiente vídeo:

¿Qué es A2A?

A2A (Agent-to-Agent) es el protocolo de Google diseñado para facilitar la comunicación entre agentes y también entre usuarios y agentes. Está pensado para entornos profesionales y construido sobre estándares de seguridad y autenticación ya existentes.

Entre sus características más destacadas:

Multimodalidad: soporta entradas de audio, texto, vídeo, o cualquier otro formato. Es totalmente agnóstico respecto al tipo de contenido.
Comunicación asíncrona: ideal para tareas que pueden tardar desde minutos hasta horas en completarse.
Tres actores principales:
- Usuario: quien solicita la tarea.
- Cliente: el software que realiza la comunicación.
- Agente remoto: quien ejecuta la tarea.

La comunicación en A2A se estructura alrededor de tareas (tasks), que incluyen:

Mensajes: el intercambio tipo chat entre usuario y agente.
Artefactos: los resultados generados (como ficheros HTML, imágenes, etc.).
Estado de la tarea: que permite conocer en todo momento si la tarea está en proceso, completada o ha fallado.

Además, A2A introduce un mecanismo de descubrimiento de agentes usando archivos Model Card, que describen capacidades, versiones y direcciones de los agentes, y permiten localizarlos en tiendas públicas o privadas, ¡igual que una app store, pero para agentes de IA!

¿Qué es MCP?

Por otro lado, tenemos MCP (Model Contest Protocol) de Anthropic, que se centra en permitir que los agentes usen recursos y herramientas que tenemos disponibles, tanto locales como remotos.

En MCP participan:

Host: el modelo de lenguaje o IA que quiere acceder a los recursos.
Cliente: la aplicación que conecta el host y el servidor.
Servidor: el sistema instalado en tu máquina que gestiona qué recursos están disponibles.

MCP maneja diferentes tipos de mensajes (peticiones, resultados, errores y notificaciones) y ofrece cinco tipos de recursos:

Recursos: ficheros, documentos, imágenes.
Prompts: plantillas de prompts específicas para ciertas tareas.
Tools: APIs o herramientas con las que interactuar.
Sampling: peticiones de continuación de texto al agente.
Roots: recursos que el agente considera relevantes .

¿Cómo trabajan juntos A2A y MCP?

Imagina que quieres crear una página web. Gracias a A2A, puedes buscar un agente especializado en diseño web mediante su Model Card. Este agente, a su vez, puede colaborar con otros agentes para generar imágenes, escribir contenido o diseñar la estructura.

Con MCP, puedes darle a los agentes acceso a los documentos que contienen el contenido de la web o permitirles publicar el resultado directamente en tu servidor.

El trabajo entre ambos protocolos te permite no solo buscar agentes adecuados, sino también equiparlos con los recursos que necesitan para trabajar de forma eficiente y autónoma.

El futuro ya está aquí

Estos protocolos, aún en sus primeras versiones, marcan el inicio de un futuro donde podríamos tener nuestro propio «Jarvis» en casa: un asistente capaz de coordinar múltiples agentes para resolver nuestras necesidades cotidianas.

Sea cual sea el camino que tome esta tecnología, desde Construyendo a Chispas seguiremos contándote las novedades.