lunes, abril 14, 2025

Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI

Si habéis estado siguiente mi blog en los últimos tiempos ya habréis notado que la parte de Ciberseguridad e Inteligencia Artificial es algo que me tiene muy entretenido, además de que la cantidad de trabajos, herramientas y papers académicos al respecto es ingente, por lo que hay mucho que leer y aprender. Hoy os vengo a hablar de CaMeL, una propuesta hecha por el equipo de DeepMind para crear Agentes AI o Agentic AI seguros contra ataques de Prompt Injection, y hoy os voy a hablar un poco sobre él.
De los ataques de Prompt Injection & Jailbreak ya he hablado en muchos artículos y en conferencias, así que os voy a dejar por aquí una charla y las referencias a los artículos que os debéis ver y leer para estar al día de lo que voy publicando en éste, mi rincón de Internet.
La primera lista de enlaces desde el punto de vista de las vulnerabilidades y cómo le afectan, siguiendo el OWASP Top 10 para LLM Apps & Services del que ya os he hablado alguna vez, donde caen las técnicas de Prompt Injection, los bugs & hacks a plugins y las arquitecturas RAG, las técnicas de Jailbreak, o los leaks de privacidad.
También os dejo en esta segunda parte de los enlaces, artículos desde la perspectiva de cómo utilizar LLMs Apps & Services para el mundo del hacking, del Red Team, o de cómo los pueden utilizar los malos en esquemas de ataque. 
De esto os he hablado también en muchos artículos, y caen la resolución de los Captchas Cognitivos, el uso de LLMs para desinformación, Fake News, DeepFakes, la creación de exploits o la asistencia a la hora de recoger información.

Google DeepMind CaMeL: Defeating Prompt Injections by Design 

Visto todo esto, vamos a centrarnos ahora en el paper de CaMeL: Defeating Prompt Injections by Design, que utiliza un concepto que me gusta mucho. Primero, hay que decir que la propuesta es muy reciente, pero busca hacer lo mismo que hacen las propuestas anteriores, que es, segmentar los datos del control de la lógica.
Al final, cualquier Prompt lanzado a un LLM tiene generar una lógica de ejecución de tareas sobre un conjunto de datos que se deben conseguir desde fuentes que no son siempre confiables y que pueden cambiar el flujo de control del Prompt.
Esto es lo que en la propuesta de Jatmo se hace mediante una separación clara entre la tarea que se va a ejecutar y los datos de Contexto con los que debe trabajar, y que en la propuesta de StruQ & SecAlign se hace por medio de etiquetas de Instrucción, Datos y Respuestas, para que en la propuesta de Instructional Segmet Embedding se haga añadiendo una jerarquía y herencia entre el System Prompt, el User Prompt, los Datos y la Respuesta. Todas las propuestas anteriores buscan evitar la manipulación del flujo de control del Prompt a partir de datos no confiables.
La propuesta de CaMeL es hacerlo desde el diseño, haciendo uso de dos LLMs, el primero de ellos, el Privileged LLM (P-LLM) que tiene como misión definir el Flujo de Control de las tareas que hay que realizar, pero sin tocar ningún dato. Solo definir el flujo de las tareas.
El segundo de ellos, el Quarantined-LLM (Q-LLM) que es el que va a tocar los datos para procesarlos, pero siguiendo, además, Políticas de Seguridad (capabilities) asociadas a medidas de Control de Acceso a la información. 

Figura 7: Fundamentos de seguridad de CaMeL

Al final, CaMeL es un interprete de Prompts que sigue las políticas clásicas de Control Flow Integrity, Access Control e Information Flow Control. Todas ellas ampliamente estudiadas y aplicadas en el mundo de los sistemas de información clásicos, y que hay que aplicar por diseño al mundo de los LLMs.
A partir de esta arquitectura, la creación de Agentics TI (Agentes AI), debería ser más robusta, y para probarlo, el equipo de Google DeepMind lo ha hecho con el entrono de "AgentDojo: A Dynamic Environment to Evaluate Attacks and Defenses for LLM Agents" que fue definido en este paper:

En este entorno se evalúa en las siguientes métricas si el Agentic AI realiza su tarea correctamente en un entorno en el que no hay ataques (Bening Utility), cuál es el nivel de rendimiento en un entorno en el que hay ataques (Utility Under Attacks), y cuál es la tasa de éxito de los ataques (Attack Success Rate), y los cataloga en estas clases.

Así, en el paper de AgentDojo podéis ver la forma en la que evalúan los diferentes modelos siguiendo estas métricas en la fecha en la que se publicó el documento - hace nueve meses -. Aquí las métricas.
Utilizando estas métricas con agentes de cuatro sectores distintos, los investigadores han probado CaMeL, como podéis ver en las siguientes imágenes. En este caso, el número de veces que saltan las políticas de seguridad para cada tipo de Agentic AI probado en entorno Benign y Under Attack.
En esta segunda métrica, la utilidad de los Agentes AI al mismo tiempo que son protegidos, donde se puede ver que CaMeL alcanza los ratios más altos en casi todas las pruebas, al mismo tiempo que deja pasar CERO ataques de Prompt Injection con políticas de seguridad aplicadas, y sólo un ataque de Data Flow Hijacking cuando no se aplican Políticas de Seguridad.

Figura 13: Utilidad under attack para los Agentes AI
y número de ataques con éxito

Por último, el Attack Success Rate aplicando CaMeL sobre modelos comerciales, donde se puede ver la Utility Under Attack, y sobre todo, cómo se reduce drásticamente el Attack Success Rate, donde no hay ataques de Prompt Injection con éxito.
Sin embargo, CaMeL no es perfecto, y como bien dicen en el paper tiene retos de privacidad, que son algunos de los que salen en los resultados de las pruebas con AgentDojo. En concreto, es vulnerable a Side-Chanel Attacks, infiriendo datos de variables privadas observando los tiempos y el comportamiento del agente. Algo que no es nuevo ni fácil de corregir, ya que incluso en el kernel de los sistemas operativos es casi imposible de proteger, como vimos hace un año con GhostRace. Pero si vas a construir Agentes AI, seguro que este paper es una lectura más que recomendable.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 4:41 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , , , , ,

domingo, abril 13, 2025

Inteligencia Artificial y el negocio de resolver "Capthas Cognitivos" para el Cibercrimen.

Vale, no sólo cibercrimen, también lo hacen para aquellas empresas que hacen WebScrapping, WebScalping, o que directamente quieren indexar contenido... (¿cómo lo harán los spiders de los buscadores hoy en día?). En el mundo de la ciberseguridad también se usan las técnicas de WebScrapping muchas veces, para hacer investigaciones usando técnicas OSINT: Open Source INTelligence, así que el Captcha es un viejo conocido.

Figura 1: Inteligencia Artificial y el negocio de resolver
"Capthas Cognitivos" para el Cibercrimen.

Recientemente, el equipo de Sentinel Labs ha publicado un análisis de la infraestructura y el funcionamiento del Bot Akira, que es un framework que se utiliza para campañas de distribución masiva por medio de redes, spam e-mail, comentarios, y redes sociales, incluidos canales de Telegram. El análisis completo del bot lo tenéis en su web, pero hoy quería centrarme en el uso que hace la Inteligencia Artificial para su funcionamiento.
Si leéis el artículo del análisis veréis que el bot lleva hardcoeadas APIs Keys de OpenAI para hacer uso de las funciones de GPT para construir los mensajes de Spam, los comentarios, etcétera. Esto no es algo nuevo, y ya vimos varios artículos sobre cómo utiliza el cibercrimen las herramientas de GenAI, así como el mundo de la desinformación y la propaganda.
Pero quería pararme en la otra parte, en la parte de los Captchas, donde, para hacer sus funciones de forma masiva, distribuida, y automatizada, debe lidiar con la resolución de Captchas, y ahí utiliza varias plataformas para resolver esto. Estas son APIs comerciales de empresas que te permiten resolver de manera automatizada diferentes modelos de Captchas.

Figura 4: Tipos de Captcha Solver Ofrecidos por una empresa

Estas empresas tienen un negocio muy interesante, ya que si lo pueden automatizar lo automatizan, pero en sus orígenes hay empresas que lo hacían - y lo siguen haciendo para algunos Captchas - de manera manual, aunque ya menos. 

Figura 5: Precios para resolver diferentes versiones de reCaptcha

Si vamos a ver las empresas, vemos que utilizan, vemos que los costes son bastante bajos para Captchas sencillos que se pueden automatizar con modelos en IA en local, como son las diferentes versiones de ReCaptchaV2, ReCaptchaV2 Enterprise, ReCaptchaV3 y ReCaptchaMobile.
Hay que recordar que ReCaptchaV2 se puede resolver con Cognitive Services de reconocimiento de audio - como hicimos nosotros en el año 2017 -, o usando Cognitive Services de reconocimiento de imágenes, algo que está bastante automatizado como podéis ver en este vídeo, donde además resuelven también hCaptcha.

Figura 7: Resolviendo ReCaptcha & hCaptcha

También, según el informe, podía saltarse otros tipos de Captcha, como hCaptcha, visto en el vídeo anterior, pero también FunCaptcha, uno de los que desde que entramos en el mundo de los Multi-Modal LLMs he estado jugando con ellos. 

Figura 8: Doce Retos diferentes de FunCaptcha

FunCaptcha utiliza retos visuales cogntivios para detectar a los humanos, y aunque al principio eran complejos de automatizar, desde la llegada de MM-LLMs ha sido un juego. Yo he estado jugando con ellos, ya que los utilizan HBO Max, Linkedin, Twitter/X, etcétera, y os he ido dejando artículos para que pudierais ver cómo funcionan:
Resolver los FunCaptcha, cada día es más sencillo, ya que cada vez funcionan mejor los MM-LLMs. En este ejemplo con ChatGPT-4o se puede ver cómo a la primera resuelve el reto de los datos de la imagen anterior.

Figura 9: Resolución del FunCaptcha de los dados con ChatGPT

Pero si lo que queremos es automatizar esto, pues no queremos tanta floritura en la respuesta, que los tiempos de latencia son cruciales, así que le pedimos el número del cuadrante que hay que pulsar y listo. En este caso con el reto de la galaxia en espiral.

Figura 10: Resolución del FunCaptcha de la galaxia en espiral con ChatGPT

Al final son retos de reconocimiento visual, razonamiento, etcétera, que cada vez están más superados por esta industria. Sin embargo, se puede ver diferentes precios para este tipo de retos. Aquí, esta empresa está cobrando entre 2.99USD y 50 USD por resolver 1.000 FunCaptchas.

Figura 11: Coste de resolución de 1.000 FunCapchas

Esto puede significar que están pagando un API muy grande, o que lo están resolviendo manualmente aún, porque te puedes encontrar "empresas" como esta China que por entre 5  15 Yuanes te los resuelven igualmente. Eso puede ser que estén usando una infraestructura de botnet para resolverla, o incluso APIs robadas de servicios de GenAI, o... vete tú a saber, porque el precio es brutal. Es algo así como entre 0.7 y 2 USD.

Figura 12: Coste de resolución de 1.000 FunCaptcha.

Y la infraestructura que tienen soporta resoluciones de millones de Captchas Cognitivos al mes, como podemos ver en los planes comerciales para todo tipo de tamaño de compañía, donde por menos de 100 USD tienes un servicio de más de 6M de Captchas al mes, de imágenes o audios, para que lo puedas automatizar a lo grande. Y si necesitas más, pues doblas la cuentas.

Figura 13: Planes empresariales para resolución
de Captchas Cognitivos vía API

Además de estos Captchas Cognitivos, también tienen estas empresas soluciones para CloudFlare TurnSite y AWS Captcha. TurnSite es el famoso Captcha de CloudFlare que tanto bien ha hecho, pero estas empresas ya empiezan a ponerlo en sus capacidades, y AkiraBot hacía uso de una de estas empresas para saltárselo.

Figura 14: Planes con TurnSite y AWS Captcha

Es por eso que la empresa CloudFlare ha innovado y creado AI Labyrnth para cuando un sitio es atacado por uno de estos servicios, quede atrapado en un HoneyPot que le genere con GenAI información "useless" de lo que iba buscando.

Además, si os fijáis, el AWS Captcha, ya lo tienen en camino. De momento la oferta te permite reconocerlo, lo que te ayuda a reenviarlo a un equipo de personas humanas que lo resuelvan, pero "están trabajando" en tenerlo listo. Es la innovación en el otro lado.

Figura 16: Puzzles de AWS Captcha

Al final, la disrupción de la aceleración en el mundo de la Inteligencia Artificial se va a ver en todas partes, así que vemos como el juego del gato y el ratón entre buenos y malos - o malos y buenos -, sigue siendo una de las líneas de investigación más interesantes en Ciberseguridad.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 9:18 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , ,

sábado, abril 12, 2025

Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding

Las técnicas de Prompt Injection se ha convertido en OWASP Top Ten for LLM Apps & Services en el equivalente al SQL Injection fue en el mundo de las técnicas de Hacking Web Technologies. Es por eso que las propuestas para proteger el nuevo mundo de servicios digitales soportados por modelos de IA necesitan desarrollar nuevas formas de protegerse contra estos ataques, y los investigadores están haciendo muchas propuestas de valor al respecto.
Hoy os quiero hablar de algunas de estas técnicas, para que entendáis la propuestas, porque los papers son más que interesantes para su lectura, y te van a ayudar a proteger tus servicios cuando hagas uso de las capacidades que nos ofrecen los MM-LLMs hoy en día, que son maravillosas, pero hay que usarlos de forma securizada.

Jatmo: Prompt Injection Defense by Task-Specific Finetuning

La primera de las que os voy a hablar es la propuesta Jatmo, que busca diferenciar entre el Prompt en el modelo y los datos de Contexto que pueden llegar a desde un punto externo al modelo, como una base de datos en una arquitectura RAG (Retrieval Augented Generation), documentos en un repositorio de mensajes, o de simplemente páginas webs en Internet. En este caso, el atacante introduce el Prompt Injection en un dato que va a ser cargado cuando se alimente el contexto al Prompt del developer desde una fuente externa no confiable.

Figura 2: Prompt Injection desde una Web externa con datos consultada

Para evitar esto, hay que dejar muy claro cuáles son los datos confiables, que en nuestro caso serían los que introduce el desarrollador, y los que vienen y no son confiables por proceder  de fuentes externas no verificadas. Y en esto consiste la propuesta de Jatmo que puedes leer en su paper.
En el ejemplo presentado antes, el atacante aprovechar que el servicio que va a usar LLM usa una arquitectura donde consulta y carga datos externos para generar un contexto al modelo antes de que éste dé la respuesta. Y en esos datos introduce el Prompt Injection, como en este ejemplo.
Para resolver esto hay que entender que, al igual que en las técnicas de SQL Injection, se está componiendo un Prompt de entrada al modelo LLM basado en datos del desarrollador y datos del atacante, así que habría que diferenciarlos bien.
Y la propuesta de Jatmo es tan sencilla como cargar el modelo y los datos por separado. Es decir, mientras en la forma natural se hace una concatenación del Prompt con los datos del contexto, en la propuesta de Jatmo el desarrollador genera una tarea para cada Prompt y los datos para esa tarea se cargan con modelo cargado e instruido para tomar el resto de los datos como datos.
Esto reduce la superficie de exposición al limitar las acciones que va a realizar el modelo que se está utilizando a un conjunto de ellas predefinidas y todo lo demás lo debe tomar como datos, lo que hace más complejo que un LLM reciba peticiones de comandos que no estén definidas por el desarrollador del servicio.

StruQ: Defending Against Prompt Injection with Structured Queries

El segundo de los papers del que os quiero hablar es de Septiembre del año pasado, y habla de generar Prompt Etiquetados como Structured Queries. Es decir, detectar, marcar y etiquetar de una determinada manera los datos de un Prompt para que el modelo LLM no sufra ataques de Prompt Injection.

Figura 7: StruQ - Defending Against Prompt Injection with Structured Queries

El proceso propuesto es como el que podéis ver en la imagen anterior. De nuevo, se trata de diferenciar entre el Prompt introducido por el desarrollador, y los datos procedentes de una fuente externa no confiable, donde puede venir el Prompt Injection. En este caso, además de utilizar todas las técnicas de análisis de la seguridad del Prompt de entrada - además de analizar los resultados de salida después -, el objetivo es etiquetar los datos.

Figura 8: Pipeline del procesado de StruQ para evitar Prompt Injection

En el gráfico anterior se ve cómo se quitan todas las etiquetas que pudiera haber introducido el atacante, para luego etiquetar el Prompt, los datos y la repuesta con un [MARK][INST][COLN] para las instrucciones, y [MARK][INPT][COLN] para los datos de entrada, y [MARK][RESP][COLN] para que el programador recoja la respuesta, tal y como tenéis en el ejemplo siguiente, que son datos de entrenamiento para detectar las etiquetas.
El resultado es que, las técnicas de Prompt Injection o Jailbreak de las que he hablado tanto por aquí, como la de Tree-of-Attacks with Pruning, por ejemplo, se verían "parametrizadas" y serían fácilmente bloqueables con una arquitectura tipo Jatmo vista anteriormente.
El resultado ayuda a mejorar la seguridad de los Prompts que se van a realizar, pero aún se pueden mejorar las protecciones contra estos ataques de Prompt Injection, y lo vemos en los siguientes papers.

SecAlign: Defending Against Prompt Injection with Preference Optimization

El objetivo de este paper es hacer más robusto el análisis del Prompt de entrada ya marcado, haciendo un alineamiento de seguridad en su análisis. Es decir, se trata de entrenar el modelo de análisis de datos para detectar los ataques dentro de las etiquetas, con datos reales y sintéticos que puedan ayudar al modelo a procesar correctamente el Prompt y detectar intentos de ataques
En este caso, como podéis ver, el modelo es entrenado con datos en los que se le dice cuál es la respuesta deseable y cuál la no deseable, para que él pueda saber si lo ha hecho bien o no. Estas técnicas de DPO "Direct Preference Optimization" ayudan a entrenar el modelo para que aprenda las estructuras de los ataques de Prompt Injection.
Todo el trabajo de SecAlign con los diferentes tipos de técnicas de Prompt Injection y Jailbreak, los tienes explicados en el paper, además del resultado de detección de los mismos sin protección, con las técnicas SOTA (State-Of-The-Art) en Prompting-Base Defense y en Fine-Tunning Defense y por último con SecAlign Fine Optimization.

En la izquierda tenéis el bechmark de ApacaEval2 y en la segunda por los valores de Max ASR (Attack Success Rate) de las baterías de pruebas. 
Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy

El último de los papers de los que os voy a hablar hoy - que ya ha quedado muy largo el post de hoy, tiene que ver con los ISE "Instructional Segment Embeddings", donde se ataca la falta de herencia a la hora de clasificar cuáles son los Prompts del Sistema, cuáles los Prompts del Desarrollador y cuáles los Prompts en Datos externos no confiables, lo que hace que se puedan atacar los servicios basados en LLMs.
No tener claro la jerarquía de herencia entre unos y otros hace que los que vienen por Data pueden llegar a contradecir lo que ha venido desde el System,  o el Developer (USER en el ejemplo anterior), y esto lleva a que se puedan hacer ataques de Prompt Injection, Prompt Extraction o Harmful Requests.

Figura 16: Diferentes tipos de Prompts Attacks

Para corregir esta debilidad en el modelo, lo que propone el trabajo de Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy es no tener los mismos tipos de tokens para construir los Prompts, sino que se puedan diferenciar con una jerarquía los diferentes tokens con los que va a trabajar el LLM.

Figura 17: Instructional Segment Embedding
Improving LLM Safety with Instruction Hierarchy

Como se puede ver en la imagen, se crean diferentes tipos de embeddings para los diferentes tipos de niveles de datos de entrada que tiene que procesar el modelo LLM, ayudando a que se puedan procesar con diferentes niveles de prioridad.

Figura 18: Instructional Segment Embeddings

Con esta etiquetado, el paper presenta resultados experimentales que en los benchmarks de Alpaca los resultados son muy positivos. 

Final Thought

Al final, todos estos papers llevan a una conclusión de la que he hablado muchas veces en mis charlas, que no es más que el modelo de Seguridad por Diseño en los LLMs hace falta, y por eso estamos viendo tantos trabajos en ese área y, como veremos en un post posterior, ya tenemos propuestas en esa línea. Os contaré más.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 10:34 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , , , ,

viernes, abril 11, 2025

De Errores Humanos y Errores Humanizados en los Modelos de Deep Reasoning

El pasar de tener sistemas informáticos basados en programación determinista a usar modelos de IA con alucinaciones y errores es un salto importante de adaptación mental. Es verdad que nuestros sistemas informáticos han estado lejos de ser perfectos y nos han dejado errores lógicos, interbloqueos, cuelgues y bugs de seguridad, y cada vez que hemos ido complejizando la estructura de capas de abstracción, garantizar que un programa hace solo lo que debe de hacer y nada más, y además lo hace bien, ha sido un esperanza no comprobada matemáticamente.

Figura 1: De Errores Humanos y Errores Humanizados
en los Modelos de Deep Reasoning

De hecho, confiamos en los tests unitarios, los tests de integración, las pruebas de QA, los escaneos con herramientas de fuzzing, y los análisis de código estático y dinámico - o incluso con Rayos X para sacar mapas de calor -, pero todo se basa en detectar algún comportamiento anómalo, una respuesta inesperada, o un funcionamiento anormal del sistema, para luego investigar la raíz de ese problema. Pero eso, queda muy lejos de una demostración empírica de que el código hace lo que tiene que hacer bien, y nada más que lo que tiene que hacer. 

Conocido esto, vemos que cuando la garantía de calidad y robustez del sistema informático es lo más importante, es mejor irse a tecnologías, hardware y software, altamente probados. De esto tenemos un ejemplo en el artículo de nuestra compañera Selena Sánchez donde explicaba por qué la NASA utiliza en el Rover Perseverance la arquitectura del IBM PowerPC G3. La respuesta es muy sencilla: ha sido altamente probado. De estos ejemplos conocemos más en la historia de la tecnología, y algunos casos, como las arquitecturas Mainframe con sus archi-famosos programas en COBOL han sido iconos de industrias enteras.

Sabiendo que no podemos garantizar que un código se va a comportar en todas las situaciones como esperamos, porque demostrarlo matemáticamente es una tarea hercúlea, basamos en la confianza en el robustez de su comportamiento en el determinismo de las respuestas generadas por el código, y probadas con los tests de calidad del software, y garantizar que estos son completos es mucho decir. Recuerdo que en la universidad, en una de las prácticas de programación de sistemas operativos teníamos que hacer un programa que recibiera datos de entrada por el teclado, y había que controlar todos los errores. 

Pero una de las pruebas que nos hacía el profesor era "aporrear" el teclado para hacer saltar comandos de interrupción del sistema. Y contaba si habías controlado las interrupciones. Nosotros no lo entendíamos, pero la respuesta era... "si haces el software para un controlador de maquinas en un areopuerto, o para un avión, o para un tanque, lo último que quieres es que si por error humano alguien toca lo que no debe, el sistema se caiga." Y hay que reconocer que, como prueba de robustez es fantástica, así que nos enseñó a tomarnos más en serio la gestión de errores cuando hicimos el driver de teclado para un sistema operativo UNIX.

Dicho esto, ahora entramos en la época de la Inteligencia Artificial Generativa, donde la respuesta que te va a dar un sistema no es "determinista". Es decir, puedes pedir el mismo Prompt al mismo modelo, y el resultado puede ser diferente. De hecho, en un porcentaje pequeño puede ser una alucinación, de las que hemos hablado largo y tendido. Podéis leer el artículo donde Bard se inventaba una historia personal mía donde me llevaba a la cárcel, o en las versiones anteriores de ChatGPT inventaba cosas de personas públicas.

Usamos el término de "Hallucination" porque es tan fácilmente comprobable que ese dato es inventado, que no podemos considerarlo un error puntual, sino un fallo estructural en el sistema, que llamamos alucianción. Yo escribí un artículo que se llamaba "Las mentiras infinitas que ChatGPT se inventa sobre "Chema Alonso"" porque era hasta cómico ver que algo, tan fácilmente comprobable, salía como respuesta de un Prompt.

Sin embargo, con la llegado de los modelos de Deep Reasoning conectados a fuentes de Internet en tiempo real, esto ha cambiado mucho. La búsqueda de datos, la comprobación de los mismos, el análisis del Prompt, el uso de la Memory, la segmentación de tareas en los diferentes Expertos, y la verificación y análisis de los resultados intermedios y la salida final, han hecho que las "Hallucinations" se hayan reducido en varios órdenes de magnitud.
No sé si estaremos en la Paridad Humana o no con estos modelos de Deep Reasoning a la hora de hacer una tarea tan sencilla como decirle a una persona que busque la respuesta a un problema, o información de un tema, utilizando para ello todo el contenido que hay en Internet, y la respuesta del modelo tenga más o menos porcentajes de errores que los que cometen las personas. Pero debemos estar cerca, si no ha sido superada ya esa destreza cognitiva.

Figura 3: Prompt para Perplexity Pro con Deep Research

Para la última charla que impartí sobre IA en Ciudad Real, estuve el fin de semana trabajando en ejemplos que me sirvieran para explicar cómo de bien estos modelos de Deep Reasoning buscan en Internet y procesan la información para mostrar unos resultados ajustados a lo que se les pide. El ejemplo que tenéis aquí fue hecho con Perplexity Pro Deep Research, y es a la petición de un plan de riego de un campo de vides analizando las lluvias de los dos últimos años en la región. 

Figura 4: Informe de Resultados parte 1

Figura 5: Informe de Resultados parte 2

Figura 6: Informe de Resultados parte 3

El resultado se obtiene en apenas dos minutos de Thought Time. No soy un experto en riego de campos de vides para validar la respuesta o encontrar errores o mejoras - que seguro que puede que existan -, pero sí que fui mirando los enlaces de dónde había sacado la información, y no fui capaz de localizar una alucinación razonando con mi pobre y lento cerebro humano. Para poder comprobarlo mejor, está el Research Plan, donde se puede ver en detalle todo el proceso de obtención, procesado y verificación de la información que el modelo de Deep Reasoning ha seguido para llegar al Informe de Resultados final. Y me cuesta encontrar alguna alucinación en este ejemplo concreto.

Como después de hacer varias pruebas no estaba seguro aún de que no hubiera alucinaciones, decidí probar con algo que me resulta fácil. Repetir las pruebas que había hecho en el pasado con ChatGPT preguntándole por los libros que yo he escrito. Y el resultado es curioso.

Figura 7: ¿Qué libros ha escrito Chema Alonso? parte 1

En la primera parte es totalmente correcto, porque analiza la información y salen los trabajos en 0xWord, con lo que todo perfecto, pero en el Informe de Resultados aparecen unos libros que son de otras temáticas que no tienen que ver conmigo.

Figura 8: ¿Qué libros ha escrito Chema Alonso? parte 2

Por supuesto, no son míos, pero es que no soy el único "Chema Alonso" del planeta, así que, el Prompt de entrada era inexacto, ya que no especifica sobre "qué Chema Alonso" se quieren conocer los libros. El modelo ha asumido que son sobre mí, pero cuando ha ido a Internet ha encontrado los libros de otro Chema Alonso, y los ha confundido con que son míos.  En este caso, "El lenguaje Subterraneo de las Miradas", escrito por Chema Alonso.
Sin embargo, en la Figura 7, recuadrado en color verde sí hay una alucinación, ya que ha procesado mi nombre por separado, y ha mezclado las referencias a "Chema" como si fueran mías. Una alucinación que hay que detectar manualmente. Llegados a este punto, la cuestión importante sería, el primer caso: "¿Es una alucinación o es un Error que podría cometer cualquier persona?" Esta es la gran pregunta. 

Porque si hacemos este test con 1.000 Prompts "no deterministas" a 1.000 personas y al modelo de Deep Reasoning, y vemos cuantos Informes de de Resultados de ese millón resultante (1.000 personas x 1.000 informes) y tenemos más errores que los que comete el modelo de Deep Reasoning, entonces tendríamos la Paridad Humana en la destreza cognitiva de "buscar respuestas en Internet".

Errores Humanos y Errores Humanizados

Lo cierto es que, independientemente de estar cerca o no de ese hito, el número de Alucinaciones ha disminuido drásticamente aunque vamos a tener que seguir viviendo con los errores. Errores que pueden cometer también las personas. Y es verdad que en las empresas, el Talento Humano, aún sigue siendo una de las piezas clave que marca la diferencia entre una empresa que va bien, y otra que va mal. Y vivimos con ello a pesar de no ser "deterministas". Puedes preguntar a diez empleados de tu empresa por la respuesta a una pregunta o ante una situación, y por mucho que esté escrita la respuesta, que se hayan hecho cursos de formación, etcetéra... ¿tienes garantías de que van a responder lo mismo y sin errores? No. Somos humanos, decimos los humanos.

De hecho, las interacciones humanas entre empresas y clientes son fundamentales. Los clientes quieren interacción humana, porque sus "Prompts" a las empresas tampoco son deterministas muchas veces. No saben cómo explicarlo, o no entienden qué tienen que pedirle a la empresa. O no saben exactamente el matiz del producto o servicio que tienen controlado. Así que van explorando "Prompts" con un servicio de atención al cliente que tiene que ir entendiendo y razonando sobre esos "Prompts" no deterministas que dan los clientes para poder crear un "Informe de Resultados" que sea correcto. Y la garantía de que ese "Informe de Resultado" hecho por un humano sea determinista y sin errores, tiende a cero. Somos humanos, decimos los humanos.

Pero aún así, vimos con ello. Aceptamos nuestra falibilidad como seres humanos en la interacción con otros humanos. La aceptamos con más o menos comprensión y enfado, pero entendemos que es un ser humano y que comete errores. De hecho, sabiendo esto, estamos mucho más preparados para detectar la mentira y el error, en forma de exageración, recuerdo inventado, o conversación de teléfono escacharrado, cuando alguien nos dice algo. Y lo comprobamos en Internet. 

Figura 10: ¿Error de Daniel o de un bot humanizado con errores?

El otro día, solucionando un problema con un pedido online, fui a chatear con el bot de soporte, y en un momento dato el mensaje que me llegó tenía un error. Y pensé: "Mira que truco más bueno para humanizar un bot. Podríamos incluir Errores Humanizados, meterle errores de tipado para simular Errores Humanos". Y me guardé la idea para contaros toda esta historia.

Así que, vamos a tener que acostumbrarnos a crear sistemas de Agentes AI que van cometer errores como los humanos, y vamos a tener que desarrollar sistemas de control deterministas para la verificación de los posibles errores que cometan los humanos o los Agentes de AI, pero es justo a eso "vamos a tener". Porque esta revolución es imparable, con alucinaciones, errores o indeterminismos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 8:24 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , , , , ,

Suscribirse a: Entradas (Atom)

Entrada destacada

Cibercriminales con Inteligencia Artificial: Una charla para estudiantes en la Zaragoza

Hoy domingo toca ir a participar en un evento, con una charla y una pequeña demo. Ahora mismo sí, así que el tiempo apremia, os dejo una cha...

Entradas populares