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.

Procesado de la salida de un LLM

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:

  1. Entropía baja: ¡Todo en orden! El modelo está seguro.
  2. Entropía alta y varianza baja: El modelo duda entre varias opciones plausibles. Hay que ayudarle a «pensar» y elegir.
  3. 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.

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.

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.

¿Qué es el Vibe Coding y cómo hacerlo bien?

Hoy quiero confesaros algo. Cuando empecé a planear este contenido, pensaba criticar el vibe coding. Sin embargo, tras reflexionar un poco, me he dado cuenta de que el problema no es la técnica en sí, sino cómo se aplica. De hecho, el vibe coding puede ser una herramienta muy útil si se usa correctamente. Así que, en vez de criticarlo, hoy os voy a contar cómo sacarle partido, tanto si tenéis mucha experiencia programando como si estáis empezando.

¿Qué es el Vibe Coding?

El término vibe coding viene a significar «programar por vibras». Imaginad al protagonista de El Gran Lebowski programando: te sientas con una IA, le pides algo, ajustas lo que genera, vuelves a pedir cambios… todo de forma informal. ¿Funciona? Bueno, depende del tipo de proyecto que quieras desarrollar.

Hay quienes dicen que ya no necesitamos programadores, solo ideas y una IA. Pero como alguien que lleva más de 20 años en esto, os aseguro que esa frase la he escuchado muchas veces antes: con la programación visual, los generadores automáticos, el low code, y ahora con la inteligencia artificial. Y aquí sigo, picando líneas y líneas de código para poner un botón.

Origen del término y su auge

El término fue popularizado por Andrej Karpathy, un experto en IA que ha trabajado para Tesla y OpenAI. En uno de sus tweets hablaba maravillas del vibe coding… pero matizaba: lo ve útil para webs o proyectos de fin de semana, no para montar un SaaS (Software as a Service).

Además, el auge del vibe coding viene de la mejora brutal en los modelos de lenguaje. Ahora son capaces de programar un Tetris, un Comecocos o un Snake y estos ejemplos resultan impresionantes para la mayoría de la gente, pero hay que tener en cuenta que literalmente son ejercicios que se realizan en clase mientras estudias informática. Un proyecto real puede tener cientos de miles de líneas de código y muchos más retos.

Programar es mucho más que escribir código

Pensad en esto: aunque la IA os haga un SaaS que parece funcional, ¿habéis pensado en temas como la protección de datos? ¿La gestión de compras y devoluciones? ¿Compatibilidad en distintos dispositivos? ¿Pruebas? ¿Seguridad? Programar es mucho más que escribir código.

Por eso, si quieres montar algo serio, rodéate de expertos. Y no te fíes de campañas virales que prometen miles de dólares al mes con juegos feos hechos por IA. Incluso quienes presumen de usar vibe coding al 100%, terminan permitiendo modificaciones humanas.

Cómo usar el Vibe Coding correctamente

Si quieres aplicar esta técnica de forma eficaz, aquí tienes los pasos clave:

  1. Elige bien tus tecnologías. Cuanto mejor las conozcas, más fácil será guiar a la IA.
  2. Evalúa si realmente necesitas una app. A veces una hoja de cálculo basta.
  3. Control de versiones. Usa Git o, si no sabes, guarda cada versión generada con fecha.
  4. Haz una lista de funcionalidades. Divide tu app en versiones y fases claras.
  5. Crea una arquitectura limpia. Separar controladores, servicios y datos te permitirá delegar mejor a la IA.
  6. Desarrolla por tareas. Describe cada una en un prompt, revisa el resultado, testea y guarda.
  7. Pon límites a la IA. Si una tarea no se resuelve tras varios intentos, decide si continuar o revertir.
  8. Automatiza donde puedas. Pero también aprende cuándo intervenir a mano.

El flujo de trabajo en Vibe Coding: paso a paso

Una de las claves para que el vibe coding funcione realmente bien es organizarse con un flujo claro. No se trata solo de pedirle cosas a la IA y esperar milagros, sino de establecer un proceso iterativo y controlado. Este sería un flujo básico que puedes seguir:

1. Crear una lista de tareas

Antes de escribir ni una línea de código, define qué funcionalidades debe tener tu aplicación. Divide esas funcionalidades en tareas pequeñas y manejables. Por ejemplo:

  • Mostrar lista de usuarios
  • Añadir nuevo usuario
  • Validar email al registrarse

Esta lista puede estar escrita por ti o generada inicialmente con ayuda de una IA.

2. Redactar prompts para cada tarea

Para cada una de esas tareas, redacta un prompt claro que describa lo que quieres. Sé específico.

Puedes añadir condiciones, estructuras de datos, objetos o interfaces previamente definidas.

3. Evaluar si el código generado funciona

Una vez la IA te devuelve el código:

  • Si es un lenguaje compilado: comprueba si compila y arranca.
  • Si es interpretado: simplemente ejecútalo y observa si arranca correctamente.

4. Corregir errores si no funciona

Si da error, copia ese error y pásaselo a la IA junto con el código.

La IA intentará corregirlo. Puedes repetir este paso varias veces, pero pon un límite de intentos para no quedarte atrapado en un bucle infinito.

5. Testear el código

Cuando el código ya «funciona», toca comprobar si hace lo correcto.

  • Ideal: tener tests automáticos definidos.
  • Alternativa: probar a mano, pero siempre siguiendo un guión claro de qué debería pasar.

6. Guardar versiones que funcionen

Cada vez que una funcionalidad funciona y pasa los tests, guárdala.

  • Si usas Git, haz un commit.
  • Si no sabes usar Git, guarda el archivo en una carpeta con fecha/nombre descriptivo.

Esto es importante porque la IA, a veces, rompe cosas que antes funcionaban y luego no sabe repararlas. Tener una versión estable te permite comparar y recuperar fácilmente.

7. Si no se puede resolver una tarea…

A veces la IA no logra resolver una tarea, por más intentos que hagas.

En ese caso, tienes dos opciones:

  • Guardar el progreso parcial si la app sigue funcionando. Aunque sea de forma incorrecta
  • Revertir a una versión anterior y dejar esa tarea para después.

La idea es no frenar todo el proyecto por una sola parte atascada.

Un ejemplo real

En mi día a día, uso un sistema híbrido: tengo un motor de plantillas que genera parte del código con IA y parte de forma clásica. Desde SQL hasta controladores web, todo está dividido por capas, lo que me permite testear fácilmente y generar componentes reutilizables.

Eso sí, hay límites: en el frontend, por ejemplo, todavía no logro que la IA respete del todo los estilos y convenciones, así que prefiero crear esqueletos básicos que luego el programador humano completa.


Conclusión

El vibe coding no es magia, pero tampoco es humo. Si se hace bien, puede acelerar el desarrollo, sobre todo para tareas repetitivas o proyectos pequeños. Pero para crear productos reales, sólidos y mantenibles, hace falta mucho más que IA: hace falta conocimiento, planificación y buen criterio.

¿Te animas a probarlo?

Brain2Qwerty ¿Teclear con la mente?

Hace poco Meta anunció un proyecto donde había conseguido leer directamente de la mente de 35 voluntarios que teclas iban a pulsar en el teclado.

Los resultados son sorprendentes, una tasa de acierto del 80%

Si deseas ampliar el contenido de este post puedes ver este vídeo.

¿Pero como de real es eso de leer teclas de mente de una persona?

Y es que lo de «leer la mente» suena mejor que decir que leyeron la corteza neuromotora para saber que movimientos se ordenaban a los dedos. Para leer estas señales del cerebro probaron con dos técnicas no invasivas:

  • EEG: Electroencefalografía, leer las señales eléctricas del cerebro.
  • MEG: Magnetoencefalografía, leer los campos magnéticos que causan las señales eléctricas en el cerebro.

El problema de leer señales biológicas de forma no invasiva es la pésima relación señal ruido. Básicamente la señal está envuelta en un montón de ruido que índuce errores e incertidumbre en su lectura.

En este caso los resultados fueron mucho mejores con MEG que con EEG, lo cuál es una lastima porque EEG es un sistema más asequible y “simple” que MEG.

El proceso de captura de datos :

La tarea de cada voluntario consistía en tres pasos: Leer, esperar, escribir.

  • Cada usuario leía una frase de un monitor
  • Después se mostraba en la pantalla una cruz negra al desaparecer de pantalla empezaba la tercera fase
  • En pantalla se mostraba un cuadrado girando mientras los usuarios escribían la frase en un teclado

Todo este proceso se hace para asegurarse de que la información procede de las “ordenes de teclear” y no por ejemplo de lo que están viendo los ojos.

Hay ciertas peculiaridades en el texto, para evitar que una letra fuera más de una pulsación (lo que complicaría el procesado de datos). Todo eran letras mayúsculas, sin tildes, diéresis y por algún motivo sin Ñ (¿Saben los americanos que tenemos una letra Ñ en el teclado?)

Cada sentencia era grabada y almacenada para luego poder ser procesada por la IA.

Arquitectura de la IA

La IA se compone de tres módulos que trabajan con un sentencia completa.

Modulo Convolucional

Se compone de cuatro partes, con las siguientes tareas:

  • Codificar la posición espacial de cada sensor
  • Adapta los datos a cada usuario
  • Modulo convolucional (combina los datos de varios sensores próximos)
  • Agrupación temporal

Transformer

Toma los datos del modelo anterior y calcula cual es la probabilidad (realmente no es la probabilidad son los logits, para los que sepáis de que hablo) de que sea cada carácter. Su función es integrar el contexto de la frase dentro de las predicciones.

Modelo de lenguaje:

Nada que ver con los LLMs, simplemente modela la relación estadística existente entre los caracteres (usando 9grams). Esto sumado a las datos del paso anterior nos da como resultado la sentencia escrita (si todo sale bien).

El resultado es tan bueno que puede llegar a corregir errores reales de tecleo del voluntario.

Teclear con la mente.

Aunque la idea de usar la mente para escribir un texto puede resultar muy atractiva, está lejos de ser la realidad de este sistema. Hay muchos “peros”.

A nivel de datos:

  • Solo 35 personas. Poca variedad. Sin ningún tipo de lesión.
  • Mecanógrafos expertos. Señal limpia, sin dudar a la hora de pulsar una tecla y pocos errores.
  • Entorno clínico, controlado. Sin distracciones. Ni ruido ambiente.

Cómo a nivel práctico :

  • Una máquina de resonancia magnética necesita un entorno clínico o de laboratorio con muchas restricciones.
  • Se trabaja sobre datos grabados, sentencias completas. No carácter a carácter.
  • Letras limitadas

¿Es un paso prometedor? Lo es. Significa que podremos teclear con la mente. Por ahora no, pero si algún día podemos será gracias a estudios como este.

Qwen 2.5 Coder: Contexto extendido, templates y CoT.

Qwen 2.5 coder es una familia de modelos que ha dado muy buenos resultados generando código. Tanto que pueden competir con modelos privados mucho mayores como ChatGPT4o o Claude 3 Opus. 

Podéis ver más sobre estos modelos en el siguiente vídeo:

Haz click para ver el vídeo en mi canal de YouTube

Este post se centra en los prompts necesarios para usar sus diversas funcionalidades.

Completar texto:

La funcionalidad habitual de los modelos de lenguaje. Le pasas un texto y va prediciendo las siguientes palabras (bueno, tokens).

No necesita ningún prompt especial.

Rellenar texto intermedio (infill):

Una funcionalidad imprescindible para completar código. El código no se escribe como la prosa. Es habitual insertar código en mitad de ficheros ya escritos. Además hay que tener en cuanta todo el contenido del fichero.

El prompt divide el texto en un prefijo (el código que va antes del texto a generar) y un sufijo (el código que va después del texto a generar)

<|fim_prefix|>{code_pre}<|fim_suffix|>{code_suf}<|fim_middle|>

Completar proyecto:

Otra función útil es que para completar código se tenga en cuenta múltiples ficheros del proyecto y la estructura del mismo.

El prompt consta del nombre del repositorio (puede ser cualquiera) y los distintos ficheros que se quiere que se tengan en cuenta. Cada fichero incluye la ruta con su nombre y tras un salto de línea el código.

<|repo_name|>{repo_name}
<|file_sep|>{file_path1}
{file_content1}
<|file_sep|>{file_path2}
{file_content2}

Seguir instrucciones o chatear:

Está funcionalidad se puede usar tanto para dar instrucciones al modelo como para mantener una conversación con él.

En todos estos casos es importante respetar los saltos de línea.

<|im_start|>system
{system_prompt}<|im_end|>
<|im_start|>user
{prompt}<|im_end|>
<|im_start|>assistant

Contexto extendido a 128k:

El contexto por defecto es de 32k tokens, pero usando YARN con un escalado de x4 puede llegar a 128k (cada motor de inferencia tendrá su forma de configurar esto, por ejemplo en llama.ccp es usando los parámetros:  )

Esto solo funciona en los modelos de 7B o más parámetros: -rope-scaling yarn –rope-scale 4.0

Generar texto con CoT (cadena de pensamientos):

De regalo este truco, no es oficial, yo lo he sacado de un comentario en Reddit del usuario Eposnix. Este usuario compartió un prompt que permite realizar CoT aplicado a la generación de código. Hace que el modelo de lenguaje entre en bucle tratando de corregir el código que genera hasta que esté perfecto. Cuidado que puede hacer que el mdoelo entre en bucle, por lo que es recomendable usar este prompt limitando el numero total de tokens que puede generar.

1. Generate your initial code solution
2. Rate your solution on a scale of 1-5 based on these criteria:
- 5: Exceptional - Optimal performance, well-documented, follows best practices, handles edge cases
- 4: Very Good - Efficient solution, good documentation, follows conventions, handles most cases
- 3: Acceptable - Working solution but could be optimized, basic documentation
- 2: Below Standard - Works partially, poor documentation, potential bugs
- 1: Poor - Non-functional or severely flawed approach

3. If your rating is below 3, iterate on your solution
4. Continue this process until you achieve a rating of 3 or higher
5. Present your final solution with:
- The complete code as a solid block
- Comments explaining key parts
- Rating and justification
- Any important usage notes or limitations

Tras ese prompt puedes especificar que deseas que programe Qwen

Comparamos el nuevo tokenizador de Llama 3 con el antiguo de Llama 1 y 2

Una de las novedades de Llama 3 ha Sido un enorme tokenizador con 128k tokens. Un tokenizador tan grande aporta dos ventajas. Soporta textos mayores usando el mismo número de tokens. El tamaño del contexto es el mismo pero «caben» textos más grandes.

Para comprobar si es tan bueno cómo prometen vamos a compararlo con el anterior tokenizador usado por Llama 1 y 2.

Cómo el número de tokens depende del tipo de texto también. Vamos a probar varios tipos de textos: inglés, español, código en C, Python y TypeScript.

Para estas pruebas he usado dos aplicaciones web que permiten comprobar como funcionan ambos tokenizadores:

Tokenizador llama 1-2: https://belladoreai.github.io/llama-tokenizer-js/example-demo/build/
Tokenizador llama 3: https://belladoreai.github.io/llama3-tokenizer-js/example-demo/build/

Texto:

Llama Llama 31 – (Llama 3 / Llama)
Ingles1172995910,18
Español648356590,12

Textos usados:
Texto (en): https://en.wikipedia.org/wiki/Llama
Texto (es): https://es.wikipedia.org/wiki/Lama_glama

Código:

Llama Llama 31 – (Llama 3 / Llama)
C1234293000,24
Python23569171320,27
TypeScript487438270,21

Textos Usados:
Código C: https://raw.githubusercontent.com/ggerganov/llama.cpp/master/sgemm.cpp
Código Python: https://raw.githubusercontent.com/abetlen/llama-cpp-python/main/llama_cpp/llama.py
Código TypeScript: https://raw.githubusercontent.com/ngxson/wllama/master/src/wllama.ts

Puedes ver el vídeo en Youtube sobre esta entrada pulsando en la imagen:

Control Vectors. Controla de forma fácil el estilo y «ánimo» de un modelo de lenguaje

Los control vectors son una sorprendente herramienta para controlar el estilo del texto que genera un modelo de lenguaje.

Para entender lo que son los control vectors empezaremos por lo que es una neurona artificial. sin entrar en mucho detalle básicamente se compone de un conjunto de datos de entrada (un vector) que se multiplica por un conjunto de pesos (vamos a ignorar el bias, el simbolito ese raro que hay en el dibujo). Cada valor se multiplica con su peso correspondiente y luego esos resultados se suman todos y se pasan a una función conocida como función de activación. El resultado es la salida de la neurona.

Una red neuronal no es nada más que un conjunto de estas neuronas que se agrupan formando capas.

Las operaciones del vector de valores de entrada con cada una de estas capas puede hacerse como multiplicar este vector por una matriz formada por los pesos de todas las neuronas. El resultado es otro vector cada uno de los elementos de este vector se pasa a la función de activación generando el vector output de esa capa. Que será el vector input de la siguiente capa.

El funcionamiento de control vectors es sencillo, se calcula un vector por cada capa que se suma al vector input y que hace que el modelo se comporte de una manera predefinida. 

¿Cómo calculamos los control vectors?

Es muy sencillo, usamos dos prompts para hacer que el modelo se comporte de la forma deseada y de la contraria. Por ejemplo:

«Responde como una persona muy educada. [Tarea]»
«Responde como una persona muy maleducada. [Tarea]»

Siendo tarea un conjunto de tareas que completaran el prompt. 

Por ahora vamos a centrarnos en una sola tarea:

«Responde como una persona muy educada. ¿Cúal es la capital de Francia?»
«Responde como una persona muy maleducada. ¿Cúal es la capital de Francia?»

Al procesar cada uno de los prompts irá generando dos vectores output por cada capa. Uno para el prompt positivo y otro para el negativo. Restando ambos tendremos un único vector por capa.

Repitiendo este proceso para cada tarea tendremos para cada capa un grupo de vectores formados por la resta de los vectores positivos y negativos de cada tarea.

Este grupo lo reducimos a un solo vector usando PCA y así obtenemos un control vector para cada capa. El grupo de todos los vectores para cada capa es lo que se denomina control vectors

Cuando se aplica a un input, el  control vector se multiplica por un valor (generalmente entre 2 y -2) que determina con qué fuerza se aplicará. Si es positivo reforzará el comportamiento positivo, si es negativo reforzará el contrario.

Cómo usar los control vectors

Actualmente son soportados por llama.cpp cuya aplicación «main» ofrece tres parámetros para usarlos:

–control-vector happy.gguf Indica que fichero de control vectors usar (en este caso happy.gguf)
–control-vector-scaled honest.gguf -1.5 Indica el fichero y el peso que se aplica a los control vectors
–control-vector-layer-range 14 26 Indica a que capas de la red neuronal se aplica

Tenéis más información de su uso en esta pull request de llama.cpp

Cómo entrenar tus propios control vectors

Por suerte es bastante sencillo, existe un notebook de Google Colab que permite entrenar nuestros control vectors de forma simple

Puedes ver el siguiente vídeo explicando este articulo y con un ejemplo de como se usa el notebook de Goolge Colab:

Haz click en la imagen para ver el vídeo en Youtube

Control Vectors vs Prompt

Control vector no puede conseguir nada que el prompt no consiga. ¿Por qué usarlo? El primer motivo es que permite personalizar el comportamiento del modelo independientemente del prompt, lo cual facilita redactar prompts sin pensar en esa parte. Se pueden aplicar distintos control vectors al mismo prompt y viceversa, lo cual facilita realizar pruebas. Por último los control vectors se tienen más en cuenta que los prompts ya que modifican los prompts en cada capa de la red neuronal. Gracias a esto pueden ser una herramienta útil contra el jailbreaking.

Control Vectors vs Fine-tuning y LoRA

El fine-tuning consiste en reentrenar el modelo con datos propios. Permite personalizar el modelo y hacer cosas mucho más complejas: añadir nuevos datos, nuevos formatos de respuesta, darle nuevas capacidades (como function calling). A cambio el coste en tiempo y recursos es mucho mayor. El resultado es un modelo completamente nuevo.

LoRA consiste en entrenar solo una parte de los pesos de un modelo para obtener resultados cercanos al fine-tuning. Se obtiene un conjunto de pesos que puede ser «añadido» de forma dinámica, se pueden llegar a combinar varios LoRA (aunque nadie te promete que funcione). Cuesta entrenarlo menos que el fine-tuning pero aun así es exigente en tiempo y recursos. El resultado ocupa solo una parte de lo que ocupa el modelo, aunque es necesario tener ambos para que funcione.

Control Vectors no permite añadir nada al modelo, solo modificar su comportamiento dentro de los límites que el prompt permite. A cambio se entrena realmente rápido (de hecho es un 2×1 ya que entrenas el comportamiento deseado y el contrario). El resultado pesa muy poco.  

La instrucción que la IA no puede seguir

Estamos acostumbrados a que las IA generativas traten de seguir nuestras instrucciones con mayor menor acierto. ¿Pero hay alguna instrucción que les sea imposible seguir? Y con ello me refiero a instrucciones dentro de sus capacidades, no a cosas imposibles. Es decir, una instrucción que esté a su alcance seguir pero sea imposible que lo hagan…

Puedes hallar la respuesta en este video o si no quieres verlo en el párrafo debajo suyo:

«No respondas». Es es la instrucción que los modelos de lenguaje actualmente no pueden seguir. No porque no sean capaces de hacerlo. Por lo general pueden devolver un token que indica «fin de la respuesta» pero han sido entrenadas para completar frases, no pueden evitar tratar de completar el texto, aunque sea contradiciendo la orden que se les ha dado.

Un ejemplo :


No respondas
ChatGPT
Entendido, no responderé. Si tienes alguna otra consulta o necesitas ayuda, no dudes en decírmelo.