El Ratio Potemkin de Comprensión de Conceptos en los Large Language Models

Sí, hoy vuelvo a hablaros de un paper que tiene que ver con LLMs y su potencia de conocimiento. En este caso para hablar de un estudio que se ha llamado "Potemkin Understanding in Large Language Models", o lo que viene a ser, una manera de descubrir si los modelos LLMs responden a las cuestiones porque han aprendido cómo responderlas o han entendido el concepto por el que deben responder así.

Figura 1: El Ratio Potemkin de Comprensión de

Conceptos en los Large Language Models

La idea se basa en algo que seguro que has visto en muchos exámenes y pruebas de acceso de esas que nos preparan a los humanos. Ahí, te hacen varias preguntas que enfocan el planteamiento de distinta manera o desde distintos puntos de vista, pero que se fundamentan en haber aprendido el concepto. ¿Hacen eso los LLMs? Es difícil saber, y te puedes encontrar que preguntando sobre el mismo concepto las respuestas sean contrarias. Esto es lo que han llamado un "Potemkin".

Figura 2: Potemkin Understanding in Large Language Models

Descubrir si una respuesta correcta realmente sobre un concepto no está bien aprendido y se trata de un Potemkin, se hace preguntando algo donde tenga que aplicarse ese concepto. En el gráfico siguiente, cada una de las filas son sobre un tema concreto del que se van realizando pregutnas, por ejemplo, teorema de Pitágoras,  música, o una técnica de hacking. Después, en cada columna, están las preguntas con aplicaciones de ese concepto, que pueden ser correctas o erróneas. Si responde correctamente a la interpretación, pero luego lo aplica mal, pues es un Potemkin, ya que parece que entiende el concepto pero luego no lo aplica bien.

Figura 3: LLM Potemkin.

Una pregunta KeyStone implica que interpreta bien el concepto.

En la fila de LLM interpretation aparece que responde correctamente a la primera pregunta del concepto "q1" pero después se equivoca en tres cuestiones donde debería aplicar ese concepto. En la siguiente imagen hay dos ejemplos donde se ve bien esto. En la primera se le pide que elija una palabra para hacer una rima, y da una respuesta, pero cuándo se le pregunta si la respuesta es correcta, dice que no.

Figura 4: Dos ejemplos de Potemkin

En el ejemplo de la derecha se le pregunta por el teorema de la desigualdad del triángulo, y cuando tiene que aplicarlo da un resultado que no lo cumple. Ambos ejemplos, hechos con ChatGPT, son lo que se denominan Potemkin.  Encontrar esto Potemkins es fundamental para poder hacer la valoración de un modelo LLM por medio de un Benchmark. Podría ser que un LLM contestara bien a todas las preguntas de un examen de medicina, pero que tuviera un Potemkin en el entendimiento de que un cuerpo humano no funciona sin corazón, que surgiera en un análisis profundo de la aplicación de los conceptos.

Figura 5: Detección de Potempkins para validar Benchmarks.

Una Keystone de 2 implica que dos preguntas juntas definen un concepto.

Al final lo que tenemos en las preguntas en rojo son una Hallucination o simplemente una Respuesta Errónea, pero si estamos evaluando los LLMs en tests de conocimiento con Benchmarks, se debería estresar la búsqueda no de respuestas correctas - que podrían haber sido entrenados con esas mismas preguntas -, sino de conceptos correctamente aplicados, y por tanto la detección del máximo de Potemkins en los modelos. 

Figura 6: Ejemplos de Potemkins

En la imagen anterior veis como dos conceptos muy sencillos le cuesta interpretarlos correctamente en preguntas en las que ChatGPT ha alucinado, y que debería ser un aviso a navegantes a la hora de valorar el nivel de inteligencia de los LLMs. 

Evaluación de Potemkins en Modelos LLM

Para tener una primera aproximación sobre cómo es el aprendizaje de conceptos en los modelos, los investigadores han propuesto una metodología bastante sencilla. Han utilizado 7 modelos y les han preguntado por 32 conceptos. Después, se le ha pedido que Genere, Clasifique y Edite una respuesta donde debe aplicar ese concepto. Por ejemplo, en la imagen siguiente tenéis un proceso de Clasificación.

Figura 7: Clasificación de una respuesta en base

a un concepto para detectar un Potemkin

Los resultados del experimento los tenéis en la siguiente tabla, y son bastante llamativos. En la tabla siguiente tenéis los "Potemkin Rate" de cada una de esas tareas por modelo, donde 1 significa que ha entendido perfectamente el concepto, y entre paréntesis los ratios de errores estándar medios de los Potemkins. 

Figura 8: Ratio de Potemkins

Es decir, por ejemplo 0.57 (0.06)  en Classify refleja que en tareas de clasificación asociadas a conceptos que han sido respondidos correctamente, tienen un 6 % de errores en las respuestas a las preguntas, y dejan un ratio de un 57% de Potemkins donde 100% sería libre de Potemkins,  o lo que es lo mismo, que te responda bien a un concepto (Keystone) significa que lo entiende y lo sabe aplicar en el 100% de los casos.

Figura 9: Evaluación de modelos

Al final, es solo un experimento que demuestra que aunque un modelo LLM responda bien al concepto, al igual que los humanos, puede que no sepa aplicarlo siempre, por lo que no se puede garantizar que sepa de un tema por que haya respondido correctamente a un test concreto, sino que se debe conseguir que una vez que responda a los conceptos bien, debería obtener un Potemkin Rate de 1 para garantizar que ha entendido el concepto, si no, tendremos que un LLM tiene un ratio de aplicación de los conceptos que responda correctamente de un X%, que es lo que trata de poner de manifiesto este trabajo. 

Figura 10: Evaluación automática de Potemkins

Es decir, están bien los Benchmarks, ¿pero cuál es el ratio de aplicación que tiene de los conceptos que sabe? Este trabajo no responde a todas las preguntas que genera la existencia de los Potemkins, y tampoco plantea una metodología completa de cómo medirlo, pero sí que abre el debate de que si queremos reemplazar tareas críticas por modelos de IA basados en LLM, deberíamos conocer cuál es su ratio de aplicación correcta de lo aprendido, y más, después de ver ayer cómo un simple "Cat Attack" podría generar más errores de aplicación.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cat Attack: O cómo atacar el razonamiento de un modelo de Deep Reasoning con preguntas y comentarios insulsos (sobre gatos)

En lel libro de Maniac del que os hablé hace no mucho, en la última parte del mismo, se cuenta cómo Lee Sedol, el gran campeón del mundo de Go consiguió su única victoria frente a AlphaGo (el campeón perdió 4 partidas a 1) mediante un movimiento extraño, cuasi suicida, llamado "El dedo de Dios", que hizo entrar a AlphaGo en alucinaciones, y emitir movimientos absurdos que le llevaron a la derrota. 

Figura 1: Cat Attack: O cómo atacar el razonamiento de un modelo de

Deep Reasoning con preguntas y comentarios insulsos (sobre gatos)

Fue la única victoria en igualdad de condiciones que consiguió Lee Sedol frente la Inteligencia Artificial, y lejos estaba AlphaGo aún de las mejoras que llegarían con AlphaZero. En aquel momento un movimiento inesperado - "El dedo de Dios" - en mitad la partida llevó a un estado de confusión al modelo, y no fue capaz de resolver el problema y vencer la partida a partir de ese momento. Se perdió en el hilo de su razonamiento perfecto. 

Figura 2: Maniac 

De ese capítulo me he acordado cuando he estado leyendo el artículo de "Cats Confuse Reasoning LLM: Query Agnostic Adversarial Triggers for Reasoning Models" o en español "Los gatos confunden el razonamiento de los modelos LLM", donde los investigadores explican el CatAttack o "Ataque del Gato", metiendo comentarios o preguntas insulsas, en los Prompts, para confundir el flujo de razonamiento del modelo de Deep Reasoning.

Figura 3: Cats Confuse Reasoning LLM: Query Agnostic

Adversarial Triggers for Reasoning Models"

En este caso, plantean tres formas de generar estas "confusiones", como son estos tres "Adversarial Triggers", o cambios de razonamiento puestos por un atacante para confundir al modelo al meter preguntas o comentarios que no son parte de la información que debe procesar.

Figura 4: Cat Attacks

• Redirection of focus by general statements: O decir una perogrullada que no aporta nada, ni tiene nada que ver con el ámbito del problema. Básicamente, meter una afirmación con un dato que no aporta ni resuelve nada del problema y que lleva a otros temas.

• Unreleated Trivia: Me ha recordado a los "Fun Facts" de Sheldon Cooper. En este caso, contar algún dato curioso, como que los gatos pasan la mayor parte de su vida durmiendo

• Misleading Questions: Redirigir el foco de atención haciendo una pregunta después de haber dado la orden, que no es mentira ni verdad, pero que consigue mover el foco de atención de lo que realmente tiene que hacer el modelo.

Básicamente, si metes mucha cháchara, el modelo se puede liar. Si el planteamiento del problema es de matemáticas, y le añades muchos números y alguno de los tres ejemplos anterior, puede que se confunda, y lleve a errores muy básicos.

Probando el Cat Attack con un problema simple de matemáticas

Como no podía ser de otra manera, cuando vi este paper pensé en "lo tengo que probar", así que construí un problema de matemáticas muy sencillo de Inversión en una empresa, gasto mensual de esa empresa, y si está empresa tiene un ROI en 10 meses, cuánto generará. Pero para liarlo, hice trampas. Le metí nombres de otras empresas con números, le pregunté el ingreso cada 3 meses, metí preguntas retóricas de por medio como "¿casualidad? No lo creo", y al final metí un General Statement que no tenía nada que ver con el problema. Vamos, un "Cat Attack".

Figura 5: Prompt con el Cat Attack a DeepSeek con DeepThink R1

Como podéis ver en el Prompt anterior lanzando a DeepSeek con DeepThink R1, el Thought Time fue de 136 segundos. lo que debería haber resuelto muy rápido, porque es un problema bastante sencillo, pero en el razonamiento, que es muy largo, dio veinte vueltas a lo mismo, preocupado por entender cada palabra del enunciado, que de eso trata el Cat Attack, pero al final lo resolvió.

Figura 6: DeepSeek DeepThink R1 lo resuelve bien al fiinal

Al final, la gracia del Cat Attack es que el modelo de DeepReasoning tiene que procesar todos los tokens de entrada, y les da la misma importancia a todos al principio, así se necesita un coste de razonamiento algo para poder eliminar aquello que no aporta nada. Da igual debe procesarlo. 

Figura 7: ChatGPT también lo resuelve

De hecho, tanto DeepSeek, como Grok 3 - no os dejo la captura -, como ChatGPT lo resuelven, pero al final hacen la comprobación del General Statement como si fuera una comprobación de que lo ha hecho bien, cuando no tiene nada que ver con la pregunta. Por suerte para ellos, el resultado les cuadra, así que no tienen que decidir entre la respuesta al General Statement y el Resultado del Problema, y con la misma solución hacen las dos. 

Cat Attack con éxito en Perplexity

Sin embargo, probado con Perplexity Pro, vemos como el Cat Attack ha tenido éxito, y da un resultado que está dirigido por el General Statement en lugar de estar dirigido por la pregunta original del problema. Ha sido un ataque exitoso.

Figura 8: El Cat Attack tiene éxito en Perplexity

Además, una vez resuelto puedes hacer la prueba de enviarlo de vuelta a otro modelo para que le diga si está bien o mal resuelto, y aunque en la mayoría de las pruebas han detectado el error, en este ejemplo con ChatGPT4o se puede ver cómo da por bueno el razonamiento erróneo de Perplexity.

Figura 9: ChatGPT4o dando por bueno el razonamiento erróneo

Al final, estos ataques a los modelos de razonamiento son muy peligrosos sobre todo en los entornos de Agentic AI, donde además, en muchos entornos vamos a tener modelos lejanos a los Frontier Models, que han sido destilados con ellos para ahorra costes, por lo que estos ataques de "falta de claridad" en el Prompt, hecho maliciosamente, pueden llevar a manipulaciones en los cálculos de facturas, pagos, precios, etcétera, simplemente hablando de "Gatos..." mola, ¿no?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Generación de Código, Razonamiento y Respuestas No Deterministas usando GenAI

El otro día tuve la oportunidad de charlar un rato con mi amigo José Palazón "Palako" sobre lo complejo de aplicar GenAI al desarrollo automático. Hablamos de cómo Neo de Sagittal.ai intenta conseguir resultados deterministas a operaciones de código, y lo no sencillo que solía ser esto. Al final, una misma petición a un modelo LLM para la construcción de código depende infinito del Prompting, y aun así, puede que ignore partes o que tenga un alucinación - ¡bendita creatividad! -, y probarlo es muy sencillo.

Figura 1: Generación de Código, Razonamiento y Respuestas

No Deterministas usando GenAI

Antes de nada, si no has visto la charla, de José Palazón "Palako", te la recomiendo encarecidamente. La impartió la semana pasada y habla de los males que sufre la industria del software. Y él y yo, que hemos vivido juntos en muchas de estas aventuras, lo hemos sufrido en primera persona.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Para la prueba de cómo esto funciona, solo debes hacer una prueba sencilla de pedir un Prompt que "aparentemente" es sencillo, pero que está lleno de incertidumbres e inexactitudes, que es como los desarrolladores reciben los requisitos normalmente. En este caso, un ejemplo de un código en Python que le he pedido a DeepSeek v3 Deep Think R1.

Figura 3: Petición de un código aparentemente sencillo a DeepSeek

En el Prompt no he explicado cómo quiero el resultado, ni cómo es el fichero al que se va a encontrar, ni dónde está, ni si hay problemas de tiempo de acceso, de idioma, de permisos, si el fichero puede estar corrupto, si vienen solo números, números y otras cosas, ni en qué formato está el fichero, etcétera, pero lo he pedido que el código sea seguro.

Figura 4: Código generado por DeepSeek después del Thought Time con ese Prompt

No os he dejado todo el Razonamiento, porque es largo, que el Thought Time son 118 segundos, pero el código tiene buena pinta después de todo su razonamiento, y aquí está la explicación del resultado.

Figura 5: El resultado explica las precauciones que ha tomado.

Bien, pues acto seguido repetimos el Prompt, donde le pedimos que se olvide de todo lo que le hayamos pedido antes, y de todo lo que haya respondido previamente, para que haga lo mismo.

Figura 6: Misma petición, distinto razonamiento

No os he dejado todo el Razonamiento, pero podéis ver que son 36 segundos, y que no se basa en nada de lo razonado previamente, sino que hace otra razonamiento totalmente distinto en mucho menos tiempo, para llegar a un resultado, como os podéis imaginar diferente.

Figura 7: Distinto código generado

Llama a las funciones diferentes, utiliza diferentes mensajes de error, toma diferentes decisiones, no inicializa número ni números antes, etcétera. Y por supuesto, la explicación, aunque es parecida, no es la misma.

Figura 8: Explicación del segundo código

Además, aquí nos da en la respuesta ejemplos de uso de cómo utilizar este código, que tenéis aquí mismo, algo que en la primera respuesta no generó. Así que tenemos una respuesta que tampoco es determinista, lo que nos llevaría a una documentación del código diferente.

Figura 9: Explicación del código con ejemplos de uso

Al final, es el mundo al que vamos cuando hacemos uso de tecnología basada en modelos MMLLM, tenemos respuestas No Deterministas. Un mismo "Prompt" genera dos Razonamientos diferentes, dos Códigos de Programación diferentes, y dos Respuestas de explicación diferentes. Como cuando le dices lo mismo dos personas distintas, generas dos resultados diferentes.  ¿Y si quieres que tu servicio que usa GenAI tenga respuestas deterministas? Pues tiene tela cómo resolverlo. Hablaremos de eso.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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.

Figura 2: Arquitectura de Modelos de DeepReasoning

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.

Figura 9: 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)  

DeepSeek V3 DeepThink R1: Thought Time con Deep Reasoning en un Simple Agentic AI CRM

Ayer os dejé la primera parte donde veía cómo construir con DeepSeek V3 DeepThink R1 un Simple Agentic AI CRM pare ver cómo funciona el Deep Reasoning en estos modelos. Como sabéis, es el mismo ejemplo que publiqué dos días atrás en el artículo de "Cómo crear un Agentic AI para manejar un sistema informático con DeepReasoning: Level 101". Hoy, vamos a ver cómo fluctúa el Thought Time, o Tiempo de Razonamiento, dependiendo de lo claro que seamos con las órdenes.

Figura 1: DeepSeek V3 DeepThink R1. Thought Time con

Deep Reasoning en un Simple Agentic AI CRM 

Si repasáis el artículo de ayer, podéis ver que le dimos sólo 2 Prompts, siendo el primero el System Prompt del Agentic AI CRM, y el segundo una orden de dar de alta una factura. En estos dos casos el Thought Time fue "alto" comparado con la ejecución de una lógica pre-establecida por un humano. En total fueron:

• System Prompt: 188 segundos de Thought Time
• Alta de factura de nuevo cliente: 154 segundos de Thought Time

Ahora vamos a darle el resto de las órdenes, y veremos cómo va variando el tiempo una vez que ha aprendido cómo hacerlo (reduciéndose), y cuando le damos órdenes incompletas (aumentando), que es muy curioso.

Figura 2: Alta de factura de un cliente existente

En la Figura 2 le hemos pedido que dé de alta una nueva factura a un cliente ya existente, así que como se conoce el proceso - tiene info en su Memory -, lo que hace es ir muy rápido, y el Thought Time es de sólo 19 segundos.

Figura 3: Respuesta a la orden con las llamadas a las APIs

Ahora vamos a darle una orden incompleta y veremos cómo el Thought Time se dispara hasta que es capaz de elegir la mejor solución, como un trabajador de tu empresa que tuviera que tomar una decisión sin más información que lo que le hemos dicho hasta el momento (3 Prompts)

Figura 4: Factura a nuevo cliente pero no le decimos la cantidad

Aunque es un proceso que ya conoce - dar de alta una factura a un cliente nuevo -, le estamos dando la información incompleta, porque no sabe cuál es la cantidad, por lo que el Thought Time se ha ido a 130 segundos.

Figura 5: Razonando sobre cómo resolver el problema de la cantidad

Como podéis ver, el modelo llega a la conclusión de que "user might have made a mistake", pero como tiene que tomar una decisión, al final la toma, y lo hace muy bien.

Figura 6: Tomando una decisión sobre la cantidad

La duda lo corroe, entre dejar la cantidad "Variable", o poner una cantidad especulativa como 5.000 €, porque no es capaz de saber si debería saber esta cantidad o no. Como se puede ver, en la Figura 6 tiene al final el proceso completo, a falta de poner un valor en Cantidad.

Figura 7: Toma la decisión de levantar un warning

Y al final, visto que falta la cantidad, lo que hace es levantar un Warning, como se puede ver en la imagen siguiente, donde está el resultado.

Figura 8: Resultado del proceso, pero con el Warning de que nos falta el importe de la factura

Si recordáis en el artículo de "Cómo crear un Agentic AI para manejar un sistema informático con DeepReasoning: Level 101" vimos que Perplexity Pro con Deep Research de OpenAI optaba por usar 1.000€ que era lo que había cobrado en la primera factura al primer cliente por un concepto similar. En este caso, genera un Warning para que lo procesemos.  Ahora le vamos a dar la cantidad.

Figura 9: En 15 segundos resuelto

Ahora le damos la cantidad, y ya resuelve el problema en un Thought Time de sólo 15 segundos, ya que conoce bien el proceso y lo tiene en la Memory. Podemos definir mejor este comportamiento con una modificación en el System Prompt del Agentic AI diciéndole que si le falta algún dato o tiene alguna duda que no pueda resolver que pregunte.... y listo. Esto es parte del trabajo de test de los equipos de Quality Assurance de estos nuevos sistemas informáticos.

Figura 10: Ahora sí, resuelta la factura

Vamos ahora con el quinto Prompt con una orden para dar de baja un nuevo cliente, lo que implica que nos dé de baja - en nuestro ejemplo - todas las facturas asociadas, a ver cuál es el Thought Time.

Figura 11: Dar de baja a un cliente con todas sus facturas

Com se puede ver, el Thought Time es de 113 segundos porque se está enfrentando a este problema por primera vez, y tiene que asegurarse de que sigue correctamente el System Prompt que le marcamos, así que su razonamiento es un poco más extenso.

Figura 12: Razonamiento de Dar de Baja a un cliente parte 2

Como no lo tiene claro, aún, tiene que procesar los Prompts y razonar el proceso completamente, así que va haciendo uso de la Memory para ir aprendiendo cosas y organizar las tareas una tras otra.

Figura 13: Razonamiento de Dar de Baja a un cliente parte 3

Este Thought Time, que a priori puede parecer alto (113 segundos), compara bien con el Thought Time de la primera vez que se enfrentó al proceso de dar de alta una factura a un nuevo cliente (154 segundos). Así que algo mejora.

Figura 14: Razonamiento de Dar de Baja a un cliente parte 4

Con esto ya ha terminado el razonamiento, y ahora procede a darnos la respuesta en forma de APIs que hay que llamar de una manera muy eficaz. Aquí están.

Figura 15: Facturas que hay que llamar para hacer el proceso

Como podéis ver, los procesos de QA y de Performance van a ser totalmente diferentes en esta nueva generación de sistemas informáticos trabajando con Agentic AI, pero el número de posibilidades que se abren en digitalizar procesos es brutal. Eso sí, más vale que tengas bien normalizados los datos y bien estandarizadas, securizadas y disponibilizadas las APIs.... si no, vas a llegar tarde a esta evolución.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)